noapic and usb, linux 2.4.20

noapic and usb, linux 2.4.20

[Ottavio Campana]

[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

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?

Bye

PS: can you please cc your answer to my mailbox? Thank you.

-- 
Non c'è più forza nella normalità, c'è solo monotonia.

[-- Attachment #2: Type: application/pgp-signature, Size: 244 bytes --]

Re: noapic and usb, linux 2.4.20

[Randy.Dunlap]

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