Bug 247499

Created attachment 158787 [details]
Output of "dmesg" after adding a "D-Link DUB-A2" card.

Created attachment 158788 [details]
Additional output of "dmesg" after adding a "D-Link DUB-A2" card and reloading "ehci-hcd.ko"

Created attachment 158789 [details]
Output of "lspci -vv" after adding a "D-Link DUB-A2" card.

Created attachment 158790 [details]
Output of "dmesg" after booting with "noapic"

After adding "noapic" to the kernel options, "USB 2.0" is working
as expected, and the "USB" stick is auto-mounted after plugging
it in.

Created attachment 158791 [details]
Output of "lspci -vv" after booting with "noapic"

Try resetting the motherboard's resources in the BIOS setup if possible.
Many BIOS screens call this option "reset configuration data".
("noapic" should not be necessary.)

I have restored the "BIOS" default settings, but this doesn't change
the big picture. There is no particular entry "Reset Configuration
Data". Under normal circumstances, you save general settings like
"ACPI" interrupt routing or not or maybe even the address of the
serial ports but for the rest this seems quite uncommon, and I have
nothing comparable among the settings of my "PR440FX" mainboard.
However, I have explored various boot options, and it turns out that
adding "irqpoll" suppresses the kernel oops related to interrupt #16.
It turns out that "Error -110" -only- occurs when both the stick was
actually plugged in at boot time and "noapic" was missing from the
boot options. In all other cases, the "USB" stick connected to the
add-on "USB 2.0" card is mounted correctly.
However, only with "noapic", it's even possible to use both the
onboard "USB 1.x" device and the add-on "VIA" based "USB 2.0" card
at will with successive and successful mounting and unmounting of
the stick, as you expect as the normal and correct behaviour.

Created attachment 158830 [details]
Output of "dmesg" after booting with "irqpoll" and inserted "USB" stick

Adding "noapic" to the kernel options allows to restore a correct behaviour 
with respect to detecting and mounting the device. However, I have observed, 
that data corruption occurs when I copy data from the "USB" stick when it's 
plugged into a "USB 2.0" port. Data transfer using the onboard "USB 1.x" 
device works correctly!

Hello Joachim,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.

Cheers
Chris

The problem has somehow worsened: when adding "noapic" as kernel option,
the USB stick is neither detected not mounted. In the "dmesg" log file,
some entries appear upon insertion of the USB stick:

  usb 1-1: new high speed USB device using ehci_hcd and address 2
  usb 1-1: device descriptor read/64, error -110
  usb 1-1: device descriptor read/64, error -110
  usb 1-1: new high speed USB device using ehci_hcd and address 3
  usb 1-1: device descriptor read/64, error -110
  usb 1-1: device descriptor read/64, error -110
  usb 1-1: new high speed USB device using ehci_hcd and address 4
  usb 1-1: device not accepting address 4, error -110
  usb 1-1: new high speed USB device using ehci_hcd and address 5
  usb 1-1: device not accepting address 5, error -110

When APIC IRQ routing is enabled, the system locks up after inserting
the USB stick, because the file system gets blocked. The USB controller
seems to interfere with the on-board AIC-7880 UW-SCSI controller.
When ctrl-alt-del is typed in order to trigger a reboot, the system
complains that it cannot find /sbin/shutdown followed by some ext3
file system error message. For this reason, it is not possible to save
the output of "dmesg" but it contains a corresponding backtrace preceded
by some "irq XX: nobody cared" message.

Can you try the following parameters:

pci=routeirq

pci=biosirq

pci=noacpi

Cheers
Chris

Option "pci=noacpi" is somehow useless because the kernel disables
ACPI on this old PR440FX mainboard anyway. The remaining two options
don't make any difference. I have to report that the USB card doesn't
work under Windows 2000 either since I have replaced the previous
3CP6510 PCI hardware modem with a D-LINK DWL-G520 WLAN adapter.
I am inclined to recommend closing this bug report as "WONTFIX" since
the issue doesn't seem to be a generic kernel problem but rather a
fundamental hardware incompatibility issue related to the 440FX chip
set.
Interestingly, the onboard USB 1.0 device doesn't work under Windows
2000 either whereas it does work correctly under Linux when kernel
option "noapic" is added [bug 243587].

Okay, thanks for the update Joachim. You might like to also try nolapic as an
option when booting and see if this helps. You might like to also install
dmidecode and run it (you need to be root), attaching the output back here. You
can get the latest BIOS for your board from:

http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=221&OSFullName=All+Operating+Systems&lang=eng&strOSs=All&submit=Go%21

if you are not already running it.

Cheers
Chris

Created attachment 202121 [details]
dmidecode output for PR440FX and kernel version 2.6.22.5-76.fc7

The installed BIOS is the latest one as the board itself was manufactured
just before production was shut down.
Booting with "lapic" leads to the same IRQ mess which screws up mouse and
file system access. In this case, the system needs to be powered off.
I have a spare USB 2.0 card produced by Apdaptec with a different controller
chip. I could give that one a try, too.

Created attachment 202131 [details]
Output of "lspci -vv" after booting kernel 2.6.22.5-76.fc7 with "noapic"

Thanks for that. The spare card would narrow things down a bit. I'm CC'ing the
USB maintainer and adding a USB blocker bug which may gain this bug further review.

Could you also try:

# rmmod ehci_hcd

as I have experienced this issue myself. The above caused the device to drop
back to USB 1.0 and it seemed happy after that. Not a fix but something else to
test.

Cheers
Chris

This has nothing to do with USB. Most likely it's a busted BIOS which provides
broken ACPI tables.

Removing USB blocker then. Joachim, have you tried removing ACPI althogether with:

acpi=off

? If you have and it still isn't helping then as Pete indicated it might be time
for that Adaptec card...

(In reply to comment #18)
> This has nothing to do with USB. Most likely it's a busted BIOS which provides
> broken ACPI tables.

Likely not, as ACPI is disabled by default as stated in comment #13 and
confirmed by the following entry in "dmesg":

  ACPI: BIOS age (1998) fails cutoff (1999), acpi=force is required to
        enable ACPI
  ACPI: Disabling ACPI support
  ACPI: Interpreter disabled.
  pnp: PnP ACPI: disabled

Even adding "acpi=force" does not allow to enable ACPI on this system.

(In reply to comment #20)
> (In reply to comment #18)
> > This has nothing to do with USB. Most likely it's a busted BIOS which provides
> > broken ACPI tables.
> 
> Likely not, as ACPI is disabled by default as stated in comment #13 and
> confirmed by the following entry in "dmesg":

My bad, I should have spotted this. Have you tried:

# rmmod ehci_hcd

?

No luck after installing an Adaptec AUA-2000LP [NEC USB controller chip]:
the big picture remains the same. Without "noapic", there is a problem with
interrupt #17 [before #16]. The last line of the "dmesg" output indicates
a conflict between the AIC-7880 SCSI controller chip and the USB controller
which leads to a lock-up of file I/O:

irq 17: nobody cared (try booting with the "irqpoll" option)
 [<c0406463>] show_trace_log_lvl+0x1a/0x2f
 [<c0406e59>] show_trace+0x12/0x14
 [<c0406e71>] dump_stack+0x16/0x18
 [<c0462774>] __report_bad_irq+0x39/0x79
 [<c0462999>] note_interrupt+0x1e5/0x220
 [<c0462f33>] handle_fasteoi_irq+0x91/0xb6
 [<c04076f4>] do_IRQ+0x91/0xbd
 =======================
handlers:
[<e08dbf62>] (ahc_linux_isr+0x0/0x1cc [aic7xxx])
Disabling IRQ #17

After adding "noapic", no error -110 as before. However, the USB stick does
show up in "dmesg". Module "usb-storage" is not loaded, and loading it
manually from the command line does not complete, the shell is stuck.

(In reply to comment #22)
> After adding "noapic", no error -110 as before. However, the USB stick does
> ### not ### show up in "dmesg". Module "usb-storage" is not loaded, and
> loading it manually from the command line does not complete, the shell is
> stuck.

It is possible to unload ehci_hcd.ko but reloading it again also hangs.

Hello Joachim,

Can I take it there has been no improvement since your last update?

I have changed my desktop system and do not know when I will be able to
retest this issue. The non-ACPI PR440FX mainboard from 1996 is probably
not of real interest for a wider audience anymore. Closing as WONTFIX?