Re: panic in 8.0-CURRENT after svn from r189900 to r190389

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.

  - Damian