From owner-freebsd-current Thu Aug 27 10:24:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13864 for freebsd-current-outgoing; Thu, 27 Aug 1998 10:24:16 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13854 for ; Thu, 27 Aug 1998 10:24:08 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA29228; Thu, 27 Aug 1998 10:20:08 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdn29206; Thu Aug 27 17:20:01 1998 Date: Thu, 27 Aug 1998 10:19:57 -0700 (PDT) From: Julian Elischer To: Andrzej Bialecki cc: freebsd-current@FreeBSD.ORG Subject: Re: It's MFS panic.. (Re: Panic with DEVFS) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ooooohhhhhhh specfs is not active if DEVFS is active so the spec_fsync should not be called...... I bet it's hard coded into MFS.. it should be replaced with a VOP_FSYNC(vn) whch would call devfs_fsync() instead...... (yech) I'll look at it right now julian On Thu, 27 Aug 1998, Andrzej Bialecki wrote: > > 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 > > +---------------------+------------------------+--------------------------+ > | | 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