How to find if BIOS has already enabled the device

[Parag Warudkar <kernel-stuff@comcast.net>]

> 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