OSDev.org

I have a driver for UHCI which is operating on a real machine, able to enumerate devices and even able to read sectors off a mass storage device that is connected to a hub.

What I can't do is get the HC to deliver an IRQ to the CPU on real HW -- but it does work fine on QEMU and Bochs.

I disable EHCI. I have USBINTR=0x0F (fully enabled). I have PCICMD=0x05 (Bus master, interrupt, and I/O enable). I have all the USB registers set up correctly -- enough to do transfers just fine with polling.

The INT_LN=9 and INT_PIN=D and I have an ACPI IRQ redirection entry from 9 to 9 (level triggered, active high). I have configured the IO-APIC entry 9 to broadcast to logical destination 0xFF, level-triggered, active-high, and CPU vector 0x50 using the same code I use successfully for all my other drivers.

I have tried all kinds of settings to USB_LEGKEY, enabling and disabling the USBPIRQEN bit, clearing the R/WC bits. Linux seems to enable USBPIRQEN, but other I've seen other code snippets that don't set it. I do notice that the system likes to set the "SMI caused by USB interrupt" bit, even though I have done nothing to allow that. Not sure if that is the problem though.

I have the timer interrupt run a function which checks USB status and starts an operation with IOC bits set. The USB status bits for IOC are being toggled correctly, which is supposed to generate an IRQ. It repeatedly and correctly completes the transaction, but no dice with the IRQ. I also tried causing a HC halt, which is supposed to generate an error and an IRQ.

This is what Linux says about the HC:

00:1d.0 USB Controller: Intel Corporation N10/ICH7 Family USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI])
Subsystem: Dell Unknown device 01de
Flags: bus master, medium devsel, latency 0, IRQ 225
I/O ports at ff80

I spent the day scouring the Internet, to no avail. I'm not sure what to try next. Any ideas?

Hi Matthew,

I had the same problem recently when moving from Bochs to real hardware. I didn't get any interrupts until I set the USBPIRQDEN bit in the legacy word, but I can see you've tried that. For reference I write a value of 0xAF00 in order to set USBPIRQDEN and clear all the write to clear bits.

eddyb suggested a good tip on another thread: You could try setting the BIOS to disable USB 2.0 support to make sure the EHCI is disabled before you start.

Unfortunately, none of my test machines have that option. I will have to look for something older.

I've discovered that despite IRQ_LN=9 the actual IRQ is being delivered on PIRQD# which is routed to IRQ 0x0A. I put an interrupt handler on that (I thought I did it earlier, but a bug intervened) and now I am getting IRQs delivered. Constantly delivered, in fact. It is level-triggered, so I assume the level is not being de-asserted. The very first interrupt delivered has USB status bits set, but every single interrupt afterwards has them at zero.

Not sure why this is. I am clearing USB STATUS and the PCI STATUS indicates that the interrupt is de-asserted. I send an EOI to the LAPIC. Trying to figure out what else is missing. I'll let you know if I sort it out.

I was able to get things under control by masking the IO-APIC redir entry before the handler and unmasking it afterwards.

Strangely, setting the PIRQEN bit in the USB_LEGKEY register seems to have only one effect: having the PCISTATUS bit for interrupt-asserted be set to 1 when the IRQ is raised. It does not affect the actual generation of IRQs.

Now I am still trying to work out why the IRQ_LN=9 when it actually is IRQ10. I am examining the dump of the ACPI information and it is not helping: the PCI routing table says that address 0x001dffff pin A is routed to LNKF and LNKF has current resource INT=0x09. So you'd think it would be IRQ9. Sigh...

Another note: The Intel MP spec tables say that (bus: 0, srcirq: 0x74) is mapped to the INTIN 15 entry of my IO-APIC. Decrypting that according to section D.3 it says that Device 0x1d has pin A routed to entry 15.

So that disagrees with ACPI and the PCI configuration space which has Device 0x1d function 0 INT_LN=9 and INT_PN=A.

Stranger and stranger.

I have checked the Intel MP tables, which suggest the UHCI controller should use IRQ 21.

I have checked ACPI PCI routing tables, which suggests IRQ 9.

The ICH7 registers also say IRQ 9.

And the PCI configuration itself says INT_LN=9.

The PCIe configuration says all MSIs are disabled.

But the IRQ is clearly happening on IRQ10. So, what gives? Why is all the configuration information wrong? And what is the UHCI HC using to configure itself?

edit: I found that IRQ21 is also being raised consistently. So perhaps Intel MP tables are correct. But I wonder why all the others are not? If the UHCI HC is not getting its configuration from the ICH7 registers, where from?

I think I have an answer: you need to make sure the "\_PIC" method is invoked on argument value 1 (IOAPIC mode) before enumerating the PCI routing tables using ACPI.

At least that ensures that the ACPI PRT agrees with the Intel MP specification table.