Messages in this thread | | | Date | Sun, 28 Nov 1999 14:05:28 -0500 | From | Johannes Erdfelt <> | Subject | Re: [linux-usb] uhci and uninitialized usb controller |
| |
On Sun, Nov 28, 1999, Davide Rossetti <davide.rossetti@roma1.infn.it> wrote: > hi, > just to be silly: > on my bi-processor PII, ASUS board, in case I disable IRQ assigning in > BIOS (it was so to prevent SCSI and USB from sharing the IRQ), I get > (Linux 2.3.28): > a) SMP kernel: EBUSY at insmod time as in uhci.c > ... > retval = -EBUSY; > if (request_irq(irq, uhci_interrupt, SA_SHIRQ, "uhci", uhci) == 0) { > ... > > doesn't check uhci_interrupt.
Not assigning an IRQ isn't really a problem the UHCI driver can deal with. We can give a slightly more verbose error, but other than that I dunno what else we can do.
Why do you not want to share IRQ's for? It's a perfectly fine thing to do (I do it at home)
> b) UP kernel: seems someone (the pci stuff in the kernel ?) activates > and IRQ-assigns the USB interface anyway. > > my setup, with USB IRQ activated in the BIOS: > 00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Step > ping- SERR- FastB2B- > Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > <TAbort- <MAbort- >SERR- <PERR- > Latency: 32 set > Interrupt: pin D routed to IRQ 9 > Region 4: I/O ports at d400
I assume UP works fine, right?
It's more likely differences between the IO-APIC and not using it than the PCI code.
JE
- 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/
| |