Subject: Re: uvm_fault() panic with 4.99.21 in fifo_poll()
To: Arnaud Lacombe <firstname.lastname@example.org>
From: Antti Kantee <email@example.com>
Date: 07/22/2007 02:50:19
On Sat Jul 21 2007 at 23:35:32 +0000, Arnaud Lacombe wrote:
> I had a panic this evening while shutting down my laptop. Here is the
> end of the msgbuf:
> wsdisplay0: screen 4 added (80x25, vt100 emulation)
> acpiacad0: AC adapter online
> acpi0: power button pressed, shutting down!
> syncing disks... done
> unmounting file systems..
> uvm_fault(0xca8abe00,0, 1) -> 0xe
> dumping to dev 0,1 offset 264823.dump 383 382 ....
> I've been able to get a core, but the kernel was not build with
> debugging information, so the trace is not really helpful:
> #0 0xc03a90df in cpu_reboot ()
> #5 0xc03a524e in kdb_trap ()
> #6 0xc03b39f5 in trap ()
> #7 0xc0102cdf in calltrap ()
> #8 0xc035ba89 in fifo_poll ()
> #9 0xc035abeb in VOP_POLL ()
> #10 0xc0328a9a in selscan ()
> #11 0xc0328e95 in selcommon ()
> #12 0xc0329149 in sys_select ()
> #13 0xc03b3406 in syscall_plain ()
> #14 0xc01004b7 in syscall1 ()
It would be interesting to know the file system this vnode is on.
You might be able to extract that information even without debugging
symbols by some offset tricks. The vnode address is the first argument
Anyway, I'm guessing the vnode was reclaimed before this call and
therefore vp->v_data is NULL. Maybe some fs can block in reclaim
(although that would be a bit too easy)?
> It looks similar to http://mail-index.netbsd.org/port-i386/2007/04/17/0007.html
> I'll update tonight to the latest -current and see if it happens
> again ...
*might* even be related to
who knows? (if someone does, please tell me ;)
Antti Kantee <firstname.lastname@example.org> Of course he runs NetBSD
"la qualité la plus indispensable du cuisinier est l'exactitude"