Re: Unable to set devclass (devname: (null)

2009/3/22 M. Warner Losh <imp_at_bsdimp.com>:
> In message: <a31046fc0903091538gab6014cqe7a6d24fc060cf6e_at_mail.gmail.com>
>            pluknet <pluknet_at_gmail.com> writes:
> : 2009/3/10 pluknet <pluknet_at_gmail.com>:
> : > 2009/3/10 Alexander Motin <mav_at_freebsd.org>:
> : >> pluknet wrote:
> : >>>
> : >>> 2009/3/10 Alexander Motin <mav_at_freebsd.org>:
> : >>>>
> : >>>> pluknet wrote:
> : >>>>>
> : >>>>> Is it ok (and how much harmfull) to see this message?
> : >>>>>
> : >>>>> driver bug: Unable to set devclass (devname: (null))
> : >>>>>
> : >>>>> P.S.
> : >>>>> This is introduced in subr_bus.c, v1.216
> : >>>>> -                                       PDEBUG(("Unable to set device
> : >>>>> class"));
> : >>>>> +                                       printf("driver bug: Unable to
> : >>>>> set
> : >>>>> devclass (devname: %s)\n",
> : >>>>> +                                           (child ?
> : >>>>> device_get_name(child) :
> : >>>>> +                                               "no device"));
> : >>>>>
> : >>>>> where PDEBUG was moved from BUS_DEBUG to general output.
> : >>>>
> : >>>> Actually this check was introduced in rev. 1.214, just was not logged.
> : >>>> Before this change system could crash soon after this message. Now it
> : >>>> should
> : >>>> not, but related device probably will not work properly. It is probably
> : >>>> not
> : >>>> good and should be fixed, but it can be just a low memory symptom. It was
> : >>>> noticed for ata driver, but I hope it was fixed. Where have you get it?
> : >>>
> : >>> This is during the boot, see dmesg (attached).
> : >>
> : >> It does not gives much info. Can you try to add dl->driver->name,
> : >> device_get_unit(child) and device_set_devclass() result printing there?
> : >>
> : >
> : > That gives:
> : > atkbd0: [GIANT-LOCKED]
> : > atkbd0: [ITHREAD]
> : > driver bug: Unable to set devclass (devname: (null))
> : > dl->driver->name: atkbdc
> : > device_get_unit(child): -1
> : > device_set_devclass(): 17
> : >
> :
> : Well, yes. That confirms with numerous devclass_alloc_unit() EEXIST
> : hidden messages;
> :
> : atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> : atkbd0: <AT Keyboard> irq 1 on atkbdc0
> : atkbd: the current kbd controller command byte 0065
> : atkbd: keyboard ID 0x83ab (2)
> : kbd0 at atkbd0
> : kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
> : ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54
> : atkbd0: [GIANT-LOCKED]
> : atkbd0: [ITHREAD]
> : psm0: unable to allocate IRQ
> : atkbdc: atkbdc-1 already exists; skipping it
>
> Can you set a breakpoint on this line and give a traceback?
>
> : driver bug: Unable to set devclass (devname: (null))
> : dl->driver->name: atkbdc
> : device_get_unit(child): -1
> : atkbdc: atkbdc-1 already exists; skipping it
>
> Ditto
>
> : device_set_devclass(): 17
> : psmcpnp0: <PS/2 mouse port> port 0x60,0x64 irq 12 on acpi0
> : psm0: current command byte:0065
> : psm0: <PS/2 Mouse> irq 12 on atkbdc0
> : ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 55
> : psm0: [GIANT-LOCKED]
> : psm0: [ITHREAD]
> : psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons
> : psm0: config:00000000, flags:00000008, packet size:4
> : psm0: syncmask:08, syncbits:00
> : ppc0: using extended I/O port range
> : ppc0: using extended I/O port range
> : pnp_identify: Trying Read_Port at 203
> : pnp_identify: Trying Read_Port at 243
> : pnp_identify: Trying Read_Port at 283
> : pnp_identify: Trying Read_Port at 2c3
> : pnp_identify: Trying Read_Port at 303
> : pnp_identify: Trying Read_Port at 343
> : pnp_identify: Trying Read_Port at 383
> : pnp_identify: Trying Read_Port at 3c3
> : PNP Identify complete
> : isa_probe_children: disabling PnP devices
> : pmtimer0 on isa0
> : ata: ata0 already exists; skipping it
> : ata: ata1 already exists; skipping it
> : atkbdc: atkbdc0 already exists; skipping it
> : sc: sc0 already exists; skipping it
> : vga: vga0 already exists; skipping it
>
> No need for these...
>
> Warner
>

While rebuilding the kernel from newest sources, I have a dmesg from a
bit older kernel
(where atkbdc-1 was detected only once):

atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd: the current kbd controller command byte 0065
atkbd: keyboard ID 0x83ab (2)
kbd0 at atkbd0
kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000
ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 54
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: unable to allocate IRQ
atkbdc: atkbdc-1 already exists; skipping it
driver bug: Unable to set devclass (devname: (null))
KDB: stack backtrace:
db_trace_self_wrapper(c08240e7,c0c20ba4,c05ecfd1,c08239a5,0,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c08239a5,0,c0824f45,c3d7253c,c3d7253c,...) at kdb_backtrace+0x29
device_probe_child(c3de4400,c3d72500,c0823799,981,c3d72500,...) at
device_probe_child+0xf1
device_probe(c3d72500,4,c0823799,9a2,c3d72500,...) at device_probe+0x93
device_probe_and_attach(c3d72500,1,c0c20c64,c048a0a6,c3de4400,...) at
device_probe_and_attach+0x36
bus_generic_attach(c3de4400,c3de4400,c086aca8,c048a640,c3de4400,...)
at bus_generic_attach+0x19
acpi_attach(c3de4400,c3d95054,c086ade8,c0823810,80000000,...) at
acpi_attach+0xba6
device_attach(c3de4400,4,c0823799,9a2) at device_attach+0x36f
device_probe_and_attach(c3de4400,c3de4980,c0c20cf0,c0796a2e,c3de4980,...)
at device_probe_and_attach+0x4e
bus_generic_attach(c3de4980,a,c07fd14d,0) at bus_generic_attach+0x19
nexus_acpi_attach(c3de4980,c3da0054,c086ade8,c0823810,80000000,...) at
nexus_acpi_attach+0x7e
device_attach(c3de4980,4,c0823799,9a2) at device_attach+0x36f
device_probe_and_attach(c3de4980,c3d0cb6c,c0c20d6c,c079b9bc,c07fc469,...)
at device_probe_and_attach+0x4e
root_bus_configure(c07fc469,c0c20d88,c05874f6,0,c1ec00,...) at
root_bus_configure+0x1b
configure(0,c1ec00,c1ec00,c1e000,c25000,...) at configure+0xc
mi_startup() at mi_startup+0x96
begin() at begin+0x2c


-- 
wbr,
pluknet