Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Mar 2009 14:26:03 -0700
From:      Sam Leffler <sam@freebsd.org>
To:        Damian Gerow <dgerow@afflictions.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic in 8.0-CURRENT after svn from r189900 to r190389
Message-ID:  <49CBF2EB.40705@freebsd.org>
In-Reply-To: <20090326202556.GB46908@plebeian.afflictions.org>
References:  <20090326202556.GB46908@plebeian.afflictions.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Damian Gerow wrote:
> I'm running into a similar problem here, on a Lenovo X200.  I've been able
> to narrow it down to r190100, which removed uscanner(4) from the tree:
>
>     <http://lists.freebsd.org/pipermail/svn-src-head/2009-March/005098.html>;
>
> I've verified this by checking out sources from a few hours ago, reverting
> r190100 (and, by extension, 190102), and I can now boot with the resulting
> kernel.
>
> I'm not exactly sure how it is this change is causing a panic, though.  For
> reference, here's a snippet of a boot -v on a panicing kernel:
>
> -----
> ULE: setup cpu 0
> ULE: setup cpu 1
> ACPI: <verbose ACPI stuff snipped>
> MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000
> ioapic0: Changing APIC ID to 1
> ioapic0: Routing external 8259A's -> intpin0
> MADT: Interrupt override: source 0, irq 2
> ioapic0: Routing IRQ 0 -> intpin 2
> MADT: Interrupt override: source 9, irq 9
> ioapic0: intpin 9 trigger: level
> lapic0: Routing NMI -> LINT1
> lapic0: LINT1 trigger: edge
> lapic0: LINT1 polarity: high
> lapic1: Routing NMI -> LINT1
> lapic1: LINT1 trigger: edge
> lapic1: LINT1 polarity: high
> ioapic0 <Version 2.0> irqs 0-23 on motherboard
> cpu0 BSP:
>      ID: 0x00000000   VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff
>   lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff
>   timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400
> wlan: <802.11 Link Layer>
> kernel trap 12 with interrupts disabled
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address    = 0x3c
> fault code               = supervisor write data, page not present
> instruction pointer      = 0x8:0xffffffff8056d9df
> stack pointer            = 0x10:0xffffffff80f82c70
> frame pointer            = 0x10:0xffffffff80f82ca0
> code segment             = base 0x0, limit 0xfffff, type 0x1b
>                          = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags         = resume, IOPL = 0
> current process          = 0 (swapper)
> [thread pid 0 tid 100000 ]
> Stopped at      devclass_find_internal+0x10f:   orl     $0x1,0x3c(%rax)
> db> bt
> Tracing pid 0 tid 100000 td 0xffffffff80bb6260
> devclass_find_internal() at devclass_find_internal+0x10f
> driver_module_handler() at driver_module_handler+0xb9
> module_register_init() at module_register_init+0x7d
> mi_startup() at mi_startup+0x59
> btext() at btext+0x2c
> db>
> -----
>
> Feels more like this change is triggering a problem elsewhere in the kernel.
>   
Update; the problem has been fixed in r190417.

    Sam




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49CBF2EB.40705>