How to find if BIOS has already enabled the device

From: Parag Warudkar
Date: Mon Jul 11 2005 - 21:57:01 EST


> On Sad, 2005-05-28 at 14:57, Parag Warudkar wrote:
> > This current problem of Hang-On-Boot if USB drive is attached does not
happen
> > with Windows - so it is some sort of additional (unnecessary?) thing which
> > Linux does and the BIOS doesn't like. (Like re-enabling the controller
even
> > if BIOS has already enabled it or some such.)

> > Alan Cox wrote:
> Provide dmesg output and we might be able to guess. The first obvious
> candidate would be the BIOS refusing to do a handover if it booted from
> USB disk.

Hi Alan

Sorry for digging this out so late - (Quick recap - My machine hangs for
couple minutes on boot if USB storage disk is attached - hang occurs in
pci_enable_device).

I have filed a bug to track this one -
http://bugme.osdl.org/show_bug.cgi?id=4711

Further analysis points towards wrong/differing IRQ assigments being the
cause of this hang. I observed that when the machine hangs, the IRQ
assignment looks like -

18: 379 IO-APIC-level eth0
19: 3 IO-APIC-level ohci1394
20: 1439 IO-APIC-level ohci_hcd, NVidia nForce3 Modem
21: 0 IO-APIC-level ohci_hcd, NVidia nForce3
22: 12884 IO-APIC-level ehci_hcd

And when it does NOT hang it looks like -
16: 3 IO-APIC-level ohci1394
18: 49277 IO-APIC-level nvidia
19: 1753 IO-APIC-level eth0
20: 6253 IO-APIC-level ohci_hcd
21: 646 IO-APIC-level ohci_hcd, NVidia nForce3
22: 2225 IO-APIC-level ehci_hcd, NVidia nForce3 Modem

Seems to me like the OHCI controller doesn't like to be assigned IRQ 19. Is
this difference in IRQ assignment normal or is it a bug somewhere?

Parag
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/