#6 0xc03de7ef in pcbmap (dep=dwarf2_read_address: Corrupted DWARF expression. ) at ../../../../fs/msdosfs/msdosfs_fat.c:263 ``interesting'' moof: about that panic, i see that getblk(vp, blkno, size, 0,0) returns NULL msdosfs_fat.c: /* getblk() never fails */ getblk() never fails? well aparently, that rele changed see vfs_bio.c line 1144 what should code do if getblk() returns NULL? 1.188 (ad 15-Feb-08): err = bbusy(bp, ((slpflag & PCATCH) != 0), slptimeo, NULL); 1.183 (ad 02-Jan-08): if (err != 0) { 1.183 (ad 02-Jan-08): if (err == EPASSTHROUGH) 1.183 (ad 02-Jan-08): goto loop; 1.183 (ad 02-Jan-08): mutex_exit(&bufcache_lock); 1.183 (ad 02-Jan-08): return (NULL); 1.31 (cgd 03-Jul-94): } *sigh* that is in getblk() yeah, I see that, but what should code do to deal? sleep(random()); goto again? <- does not understand struct buf *(vaddr_t *)random() = random(); i have no idea; i dont think the current code even assumes that it could fail one could abort the operation it could explain the lfs lossage can you append to the PR? there are some other places where we assume things succeed too... see sys/ufs/ffs/ffs_subr.c:121 need to post a diff up about that sometime there it checks in ufs_bmap is stated: * getblk() above returns NULL only iff we are * pagedaemon. See the implementation of getblk * for detail. all other places dont seem to expect getblk() to return zero heh, `only iff' in ffs_getblk() it returns ENOMEM ignoring the return value check for a moment, why does it fail for the msdosfs case so instant- and repeatably? FWIW, bbusy() returned error 11 EDEADLK duh (was EAGAIN) i'll try again is that the buf_init change again? i now have a breakpoint on the NULL return in getblk() lets crash it again panic: kernel diagnostic assertion "!ISSET(bp->b_cflags, BC_BUSY)" failed: file "../../../../kern/vfs_bio.c", line 1315 nice #4 0xc09ca35f in __kernassert (t=0xc0a62da5 "diagnostic ", f=0xc0a62d8a "../../../../kern/vfs_bio.c", Come on, let's boot again, like we did last summer. l=1315, e=0xc0a63150 "!ISSET(bp->b_cflags, BC_BUSY)") at ../../../../../../lib/libkern/__assert.c:50 #5 0xc05f4624 in getnewbuf (slpflag=0, slptimeo=0, from_bufq=0) at ../../../../kern/vfs_bio.c:1315 #6 0xc05f402b in getblk (vp=0xc7446178, blkno=14131, size=65536, slpflag=0, slptimeo=0) at ../../../../kern/vfs_bio.c:1155 #7 0xc03decef in updatefats (pmp=0xc11c8700, bp=0xc1299c54, fatbn=14131) at ../../../../fs/msdosfs/msdosfs_fat.c:436 again.... getblk-> etc bbl! Yeah, let's boot again, like we did last year. Do you remember when disks were hummin'? yeah, let's boot again, booting time is here! ahem. reminds me I should check whether the ultra45 booted. Is there a PR (or more than one) for the getblk() problem? Christos? yes I take it 38892 is the getblk() problem? yes. a lot of other things suffer because of it