Re: LOR/page fault panic vfs_mountroot

From: Kris Kennaway (kris_at_obsecurity.org)
Date: 04/20/05

  • Next message: Stefan Ehmann: "Re: New wireless drivers committed" 
    Date: Wed, 20 Apr 2005 14:43:00 -0700
To: othermark <atkin901@yahoo.com>

    On Wed, Apr 20, 2005 at 01:04:08PM -0700, othermark wrote:
    > Current as of a few minutes ago. LOR/panic. Dual processor box.
    >
    > kernel has vlan, ipfw, and dummynet enabled, but this doesn't
    > look like the problem.
    >
    > Curiously, booting single user and mounting root there doesn't
    > panic, but it does panic if you try to 'exit' to multiuser.
    >
    > [...]
    > Timecounters tick every 1.000 msec
    > ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled,
    > default to accept, logging disabled
    > ad0: 19092MB <WDC WD200EB-32CSF0 04.01B04> at ata0-master UDMA33
    > acd0: CDROM <TOSHIBA CD-ROM XM-6702B/1007> at ata1-master UDMA33
    > ATA PseudoRAID loaded
    > SMP: AP CPU #1 Launched!
    > Trying to mount root from ufs:/dev/ad0s1a
    > lock order reversal
    > 1st 0xc0a2d740 vm page queue mutex (vm page queue mutex)
    > @ /usr/src/sys/kern/vfs_bio.c:1485
    > 2nd 0xc25e4d6c vnode interlock (vnode interlock)
    > @ /usr/src/sys/kern/vfs_subr.c:1992

    This has been reported a half-dozen times or so.

    > Fatal trap 12: page fault while in kernel mode
    > cpuid = 0; apic id = 01
    > fault virtual address = 0x4ac0c092
    > fault code = supervisor read, page not present
    > instruction pointer = 0x20:0xc0703f88
    > stack pointer = 0x28:0xe5092b78
    > frame pointer = 0x28:0xe5092b78
    > code segment = base 0x0, limit 0xfffff, type 0x1b
    > = DPL 0, pres 1, def32 1, gran 1
    > processor eflags = interrupt enabled, resume, IOPL = 0
    > current process = 73 (sysctl)
    > [thread pid 73 tid 100060 ]
    > Stopped at strlen+0x8: cmpb $0,0(%edx)
    > db> show alllocks
    > Process 73 (sysctl) thread 0xc23b2600 (100060)
    > exclusive sx sysctl lock r = 0 (0xc09d1c60) locked
    > @ /usr/src/sys/kern/kern_sysctl.c:1335
    > exclusive sleep mutex Giant r = 0 (0xc09d1620) locked
    > @ /usr/src/sys/kern/kern_sysctl.c:1273

    I think this one might be new. Please obtain a debugging traceback.

    Kris

    • application/pgp-signature attachment: stored
  • Next message: Stefan Ehmann: "Re: New wireless drivers committed"

    Relevant Pages

    • Re: [was] addition to ipfw (read vlans from bridge)..
      ... into the packet as well as the packet, then yes I like that idea, ... At the moment I plan the ipfw code to be unaware of vlan headers. ... What we need to do is make a convention so that vlan tags are always ...
      (freebsd-net)
    • Re: [was] addition to ipfw (read vlans from bridge)..
      ... I have redone this patch in a different manner. ... Basically if it is a vlan packet, take off the whole vlan header instead ... fiddling with the mbuf contents in favour of teaching ipfw (or the ... to handle vlan tags as well. ...
      (freebsd-net)
    • Re: FreeBSD Gateway problems
      ... >speed connection for 3 years now, and I've just gotten it back. ... >Well all these other How-Tos I found on FreeBSDDiary.org told me all I needed ... To use ipfw adding these options to your kernel is a good place to start: ...
      (freebsd-questions)
    • Re: natd -redirect_port
      ... > into the kernel. ... > IPFW is delivered as an bootable module. ... > You need this in rc.conf to enable ipfw, ...
      (freebsd-questions)
    • Firewall and nmap
      ... I'm compiled a Kernel using the GENERIC config-file that ... So I flushed all rools for the firewall with ipfw flush (the still ... my kernel, ipfw -c list told me that this is true.) ... Anyway, nothing changes, all ports seem to be closed running nmap, ...
      (freebsd-questions)