Re: page fault panic tracked down (selwakeuppri())

From: Bruce Evans <bde_at_zeta.org.au>
Date: Tue, 30 Dec 2003 17:56:20 +1100 (EST)
On Sun, 28 Dec 2003, Stefan Ehmann wrote:

> Some weeks ago I posted about a panic in 5.2-BETA.
>
> After accessing a read-only ext2fs for some hours I got a "page fault"
> panic (or rarely a "getblk: size(7537385) > MAXBSIZE(65536)"). The
> backtrace was always somewhat different. You can read about it a bit
> more detailed here:
>
> http://lists.freebsd.org/pipermail/freebsd-current/2003-November/015405.html
>
> After lots of buildworld and buildkernel I finally was able to detect
> the commit that caused this panic.
>
> Current from 2003.11.09.09.00.00 runs fine for > 10 hours. Current from
> 2003.11.09.09.20.00 crashed twice within less than 2 hours.
>
> The only src/sys commit in that time is
> http://lists.freebsd.org/pipermail/cvs-src/2003-November/013515.html
> where selwakeup()s is replaced with selwakeuppri().
>
> So the problem must be somewhere in selwakeuppri().
>
> I hope this can be resolved now.

The selwakeuppri() changes aren't very related to this.  They shouldn't
affect anything except scheduling, so it looks like they just expose an
old race.

I suspect the locking changes on 2003/08/28 (ext2fs/fs.h rev.1.14
etc.).  These were obviously wrong since they broke syncing of dirty
buffers, especially at reboot time, but I didn't previously suspect
that they had locking problems.  The message in the above URL doesn't
seem to have much to do with ext2fs, but it shows a panic in lockmgr()
and the 2003/08/28 changes cause lockmgr() to be used with a different
owner.

I have farily large patches which do buffering in ext2fs in a different
way so that the 2003/08/28 changes are irrelevant.  I will send these
in private mail.

Bruce
Received on Mon Dec 29 2003 - 21:56:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:35 UTC