> Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
Note sun3 still uses gcc 4.5.4 but also panicked by this old bug,
so probably this problem was triggered by not gcc 4.8 but struct disk
changes (struct disk_geom was added in <sys/disk.h> rev 1.58),
which increased sizeof(struct fd_softc) from 248 bytes to 296 bytes.
(i.e. now struct fd_softc could be allocated in a different pool block,
probably near the wrong pointer of the struct disklabel)
Anyway, this fix should be pullued up to netbsd-7.
(probably I'm the only user of floppy on sun3 though)
- We don't need this lock.
- uvm does nothing between taking it and calling the fault handler.
- Now that the uvm_aobj shares vmobjlock with the {ttm,gem} uvm
object, we must not hold the lock when we call uvm_obj_wirepages on
the uvm_aobj.
XXX pullup to netbsd-7
Apply fix that got missed as this file got moved from dist/gcc to dist/libgcc:
Somehow emacs tries to unregister frame info for a symbol it did not register.
Don't abort for now. This worked before because the previous version of gcc
did not bother unregistering. Adding debugging printfs makes emacs core
dump, where other programs work fine.
XXX: pullup 7
Fix panic() on opening fd(4), caused by a wrong pointer passed to memset().
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
I'm not sure why this 18 year old bug didn't cause problem before
(at least my old 5.99.23 kernel worked), but probably it's triggered
by new gcc 4.8 which might do more aggressive memory allocation.
The problem is found by Nobuyoshi Sato on trying eject(1) against fd(4).
Should be pulled up to netbsd-7.
joerg