ATA: driver bug: Unable to set devclass

[Alexander Motin]

Andriy Gapon wrote:
> on 09/11/2010 19:04 Alexander Motin said the following:
>> Andriy Gapon wrote:
>>> Since one of the recent updates (not sure which revision though) I started to get
>>> "Unable to set devclass" messages in boot dmesg.  I'd say that I see the message
>>> every other boot, i.e. not always.
>>>
>>> I added some more debug code there and here's a tack trace:
>>>
>>> driver bug: Unable to set devclass (child = 0xffffff00070d0100, devname: (null))
>>> #0 0xffffffff803ae127 at device_probe_child+0x127
>>> #1 0xffffffff803ae40c at device_probe+0x7c
>>> #2 0xffffffff803ae4a1 at device_probe_and_attach+0x11
>>> #3 0xffffffff803ae56a at bus_generic_attach+0x1a
>>> #4 0xffffffff801df93c at ata_identify+0x2ec
>>> #5 0xffffffff801dfcdb at ata_boot_attach+0x6b
>>> #6 0xffffffff803a8577 at run_interrupt_driven_config_hooks+0xf7
>>> #7 0xffffffff803a8993 at boot_run_interrupt_driven_config_hooks+0x23
>>> #8 0xffffffff8032f227 at mi_startup+0xc7
>>> #9 0xffffffff801719cc at btext+0x2c
>>>
>>> >From kgdb:
>>> (kgdb) p *(device_t)0xffffff00070d0100
>>> $1 = {ops = 0xffffff0001b07000, link = {tqe_next = 0xffffff0001a65100, tqe_prev =
>>> 0xffffff0006eb0130}, devlink = {tqe_next = 0xffffff0001a65100, tqe_prev =
>>> 0xffffff000706e318},
>>>   parent = 0xffffff0006eb0100, children = {tqh_first = 0xffffff0001a5b200,
>>> tqh_last = 0xffffff0001a5b208}, driver = 0xffffffff8079bc80, devclass =
>>> 0xffffff0001add080, unit = 0,
>>>   nameunit = 0xffffff00070931a0 "ad0", desc = 0xffffff000711e7c0
>>> "ST3320620A/3.AAF", busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89, order
>>> = 0, ivars = 0xffffff000711e5e0,
>>>   softc = 0xffffff000706a400, sysctl_ctx = {tqh_first = 0xffffff000711e600,
>>> tqh_last = 0xffffff000711e708}, sysctl_tree = 0xffffff00070f9500}
>>>
>>> Apparently sometimes something happens too soon? :-)
>> What controller is there? Any other differences/interesting things in
>> verbose dmesg? Any new "CONNECT requested" messages or anything else?
> 
> It's SB700 integrated controller (ATI IXP700/800 UDMA133 controller).
> This happens during boot, there are no other unusual ata-related messages.
> I have device ahci in kernel, but no ATA_CAM option, so PATA stuff works via
> "pure" ata code.

Hmm. There was not much changes in ATA last time and I can't expect what
of them could affect PATA. Probe code wasn't changed for long time.

This check was actually added after some ata(4) bug found two years ago.
So I am not sure your problem is something new. May be something else
just triggered it again.

-- 
Alexander Motin