Date: Tue, 10 Mar 2009 01:38:41 +0300 From: pluknet <pluknet@gmail.com> To: Alexander Motin <mav@freebsd.org> Cc: FreeBSD-Current <freebsd-current@freebsd.org> Subject: Re: Unable to set devclass (devname: (null) Message-ID: <a31046fc0903091538gab6014cqe7a6d24fc060cf6e@mail.gmail.com> In-Reply-To: <a31046fc0903091526m33363223ja667eff83de19ff0@mail.gmail.com> References: <gp418i$kc8$1@FreeBSD.cs.nctu.edu.tw> <49B58CF6.7070104@FreeBSD.org> <a31046fc0903091504h24626240p3bb46401fedb37a@mail.gmail.com> <49B594B5.2060706@FreeBSD.org> <a31046fc0903091526m33363223ja667eff83de19ff0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/3/10 pluknet <pluknet@gmail.com>:
> 2009/3/10 Alexander Motin <mav@freebsd.org>:
>> pluknet wrote:
>>>
>>> 2009/3/10 Alexander Motin <mav@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
driver bug: Unable to set devclass (devname: (null))
dl->driver->name: atkbdc
device_get_unit(child): -1
atkbdc: atkbdc-1 already exists; skipping it
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
[...]
--
wbr,
pluknet
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a31046fc0903091538gab6014cqe7a6d24fc060cf6e>