Date: Thu, 27 Aug 1998 10:19:57 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Andrzej Bialecki <abial@nask.pl> Cc: freebsd-current@FreeBSD.ORG Subject: Re: It's MFS panic.. (Re: Panic with DEVFS) Message-ID: <Pine.BSF.3.95.980827101756.3468B-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.4.00.9808271115470.17607-100000@korin.warman.org.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
>
> +---------------------+------------------------+--------------------------+
> | <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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980827101756.3468B-100000>