On Thu, 17 Apr 2003 22:05:06 +0200 Ottavio Campana <ottavio@campana.vi.it> wrote:
| I'm trying to have usb working on my pc, based on a dual athlon and a
| motherboard GA-7DPXDW with linux 2.4.20 with the patch for xfs from sgi
| and the patch for the sensors.
|
| I was reading the linux-usb faq and I found:
| > Sometimes a BIOS fix will be available for your motherboard, and in
| > other cases a more recent kernel will have a Linux fix. You may be
| > able to work around this by passing the noapic boot option to your
| > kernel, or (when you're using an add-in PCI card) moving the USB
| > adapter to some other PCI slot. If you're using a current kernel and
| > BIOS, report this problem to the Linux-kernel mailing list, with
| > details about your motherboard and BIOS.
|
| So I'm writing hoping to be helpful. Usb works, but I have to pass
| noapic to the kernel. Otherwise I get "device not accepting address"
| when I plug a device in the usb port. The motherboard has been bought in
| september. I remember the older mobos had the southbridge b1, which had
| a faulty usb. My mobo has got the southbridge b2, which works.
|
| Is there anything useful I can do?
|
| Can you please explain me what "noapic" does? I think it changes the way
| interrupts are handled, but I'm not sure. Do I miss something when I
| pass noapic to the kernel?
It tells the kernel not to use the IO APIC and APIC devices for interrupt
routing, so the kernel drops back to the legacy PC interrupt controller
devices instead. A small SMP machine (or UP with IO APIC(s)) would
usually only have one IO APIC, which typically has 24 interrupt lines,
while the PIC (Programmable Interrupt Controller) device has 8 interrupt lines,
and a current/modern system has 2 of those. Thus using "noapic" (typically)
reduces the number of available device interrupt lines from 24 to 15 (15 since
8 PIC2 interrupt lines feed into one of the PIC1 interrupt lines, called
cascading) [all this for a low-end/small SMP system].
Having more interrupt lines allows interrupts to be non-shared.
Shared interrupts usually work OK (with some restrictions), but they
always cause a little bit more device driver overhead because for any one
shared interrupt, all of its device drivers are called whenever that
interrupt occurs, so that they can determine if they need to handle their
device(s).
I don't know of any measurements that have been done with apic vs. noapic.
My opinion is that in some heavy workloads it would be possible to see
some small differences in the results. In a desktop workload, you wouldn't
see any differences.
As far as USB interrupt routing with APIC support, there was a patch a
few days ago on the acpi-devel mailing list that might fix the problem.
It's in this archive:
http://sourceforge.net/mailarchive/forum.php?thread_id=1976718&forum_id=6102
You can try it and see if it helps you.
(I can forward it to you if you need it that way.)
Please let us know how it goes.
-- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:22 EST