Messages in this thread | | | From | Paul Ashton <nospam@[0.0]> | Subject | UHCI/USB/PCI/interrupts | Date | Tue, 27 Jul 1999 18:50:13 +0100 |
| |
I recently received a toshiba 7020CT laptop to run Linux. In order not to have to carry the port dongle around with me, I tried to get a USB mouse working but haven't had much luck. The first time I tried I managed to get the usb-uhci module installed and received some debugging info but ended up hanging the machine when I went into X. Since then I have been unable to insert the usb-uhci module on any kernel without immediately hanging the machine.
It turns out that as soon as I insert the module I get continuous interrupts calling drivers/usb/uhci.c:uhci_interrupt() on the PCI shared IRQ 11.
I've downloaded the 82371AB, PIIX4, UHCI, USB specs and tried various hacks to uhci.c but cannot get it to stop the interrupts which makes me feel that it is perhaps one of the other PCI devices that is generating the interrupt and not the USB controller.
So this is where I'm stuck. I boot 2.3.11 in single user mode, CTRL-ALT-SYSRQ-SU to mount / read-only to stop the fsck when it crashes, insert usb-uhci and get a print out of some of my debug messages. So now I know that nothing else has been loaded that might share the interrupt and yet the interrupts are still generated.
If I have nothing connected to the USB port my first interrupt has a status from inw(io_addr+USBSTS) of 0x20, i.e HC halted and so does every subsequent one. If I add the following code to get the HC running again then all subsequent interrupts have status 0, i.e. nothing generated the interrupt...
if (status == 0x20) { outw(USBCMD_RS|USBCMD_CF|USBCMD_MAXP, io_addr+USBCMD); }
So back to the docs and find out about PCI steering. The Tosh has the following PCI devices on IRQ 11: Neomagic 256AV: Pin A->IRQ 11 USB: Pin D->IRQ 11 Lucent HDSP1645 (winmodem): Pin A->IRQ 11 ESS Maestro 2E: Pin A->IRQ 11 (hmmm, I did get the opensound driver...) C-Cube multimedia something: Pin A->IRQ 11
I cannot figure out how the IRQ handler is supposed to determine which device generated the interrupt, and worse, if some device generated the interrupt but the handler isn't installed, how do the other handlers ignore it?
Nor can I find out how to steer the USB IRQ to another interrupt. I'm assuming that this is a solved problem. The BIOS doesn't have any way to specify this.
Any ideas?
Paul -- paul666 @mailandnews com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |