Date: Mon, 14 Sep 1998 02:02:07 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Andrzej Bialecki <abial@nask.pl> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Help, DEVFS/MFS is broken... Message-ID: <Pine.BSF.3.95.980914015349.1526D-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.4.02A.9809132345080.20680-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry about that.. here's the problem: The MFS directly calls specfs with some vnode. I don't understand why it needs to do this (even with a pointer from eivind) but obviously this can't work with DEVFS as the specfs won't know what to do with devfs based vnodes. I tried to make a picoBSD floppy on my -current machine (NON ELF) but it failed so I cannot get the vnode to see what kind of vnode it is. It looks (from the faiure of my first patch) that the vnode in question is not derived from the DEVFS, but if it's not from DEVFS and it's a device, then where on earth is it coming from? Alternatively, if it's not a device vnode, why is specfs being called to handle it? If you could get a pico kernel to print out the kind of vnode (as much info abut it as possible) that is being passed to specfs that would make my life a lot easier! julian On Mon, 14 Sep 1998, Andrzej Bialecki wrote: > Hi, > > This is yet another call for help to all those who know the filesystems, > to help fix this bug before 3.0-R... This is a genuine bug which panics > system in 100% cases, and makes any system using DEVFS and MFS unusable. > Below is an excerpt from my earlier posting, including the stack trace. > > I tried several times to contact Julian Elischer, but it looks like he > disappeared in a black hole... > > PS. If it's any good, I can open a PR on this... > > Andrzej Bialecki > > -------------------- ++-------++ ------------------------------------- > <abial@nask.pl> ||PicoBSD|| FreeBSD in your pocket? Go and see: > Research & Academic |+-------+| "Small & Embedded FreeBSD" > Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ > -------------------- ~-+==---+-+ ------------------------------------- > > > From abial@nask.pl Sun Sep 13 23:53:10 1998 > Date: Thu, 27 Aug 1998 11:46:13 +0200 (CEST) > From: Andrzej Bialecki <abial@nask.pl> > To: Julian Elischer <julian@whistle.com> > Cc: freebsd-current@FreeBSD.ORG > Subject: It's MFS panic.. (Re: Panic with DEVFS) > > > On Wed, 26 Aug 1998, Andrzej Bialecki wrote: > > > I'm totally lame when it comes to FS internals, but this looks to me > > as if some delayed action (caching? cleaning? read-ahead? whatever?) > > is causing this. > > ...but it looks like I was right after all. Below is the trace (no > crashdump available yet - I'm working on it). Source tree is about four > days old. > > One important notice, though: this time I was able to reliably crash > _without_ disabling any device, and even when not touching /dev at all - > it was enough to do just an 'ls -l' of some directory a few times to > produce sufficient number of dirty pages... The only thing that is common > in all these cases is: > > * root on MFS > * DEVFS/SLICE kernel > > and it seems these two definitely don't like each other.. :-( > > So, here's the stack trace (taken by hand.. :-<< ): > > _panic() > _mfs_strategy(ap=...) at _mfs_strategy+0x3c [../../ufs/mfs/mfs_vnops.c:137] > _bwrite(bp=...) at _bwrite+0xaf [../../kern/vfs_bio.c:891] > * _vop_stdbwrite(ap=...) at _vop_defaultop+0x15 [../../kern/vfs_default.c:131] > * _bawrite(bp=...) at _bawrite+0x2c [../../kern/vfs_bio.c:1122] > * _spec_fsync(ap=...) at _spec_fsync+0x76 [../../miscfs/specfs/spec_vnops.c:509] > _mfs_fsync(ap=...) at _mfs_fsync+0x16 [../../ufs/mfs/mfs_vnops.c:118] > _sched_sync() at _sched_sync+0xa4 [../../kern/vfs_subr.c:499] > _kproc_start(udata=...) at _kproc_start+0x32 [../../kern/init_main.c:248] > _fork_trampoline(...,...,...,...,...) at _fork_trampoline+0x30 > > The lines marked with stars ('*') in other panics were replaced with the > following lines: > > _vop_stdbwrite(ap=...) at _vop_stdbwrite+0xe [../../kern/vfs_default.c:285] > _vop_defaultop(ap=...) at _vop_defaultop+0x15 [../../kern/vfs_default.c:131] > _vfs_bio_awrite(bp=...) at _vfs_bio_awrite+0x103 [../../kern/vfs_bio.c:1122] > _spec_fsync(ap=...) at _spec_fsync+0x1e [../../miscfs/specfs/spec_vnops.c:503] > > I also tried to do a 'show object' which printed: > > db> show object > Object 0xf019bb75: type=1694529634, size=0x65007864, res=1166738538, ret=1694529635, flags=0x7363 > > Fatal trap 12: page fault while in kernel mode > ... > fault code = supervisor read, page not present > ... > current process = 4 (syncer) > interrupt mask = bio > > and at this point I gave up... > > I'll try to get the coredump, if you're interested in having it... > > Andrzej Bialecki > > +---------------------+------------------------+--------------------------+ > | <abial@nask.pl> | When in problem or in | if(halt_per_mth > 0) { | > | Research & Academic | doubt, run in circles, | fetch("FreeBSD"); | > | Network in Poland | scream and shout. | } | > + --------------------+------------------------+--------------------------+ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980914015349.1526D-100000>