Bug 8572
| Summary: | uhci_hcd:usb2 slows to 131KB/s from 846KB/s in MPS IOAPIC mode - Dell OptiPlex GX240 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Tear (tarrqt) |
| Component: | BIOS | Assignee: | Len Brown (lenb) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, bunk |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.21.3 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
Output of acpidump
Patch which disables IO-APIC on Dell OptiPlex GX240 if ACPI is not enabled patch vs 2.6.22 to remove acpi=ht blacklist entry for GX240 dmesg-acpi=ht-apic.txt dmesg-acpi=force-apic.txt i386-irq-kill-irq-compression.patch Output of lspci -vv dmesg with acpi=ht and IO-APIC enabled (another) dmesg with acpi=force and the i386-irq-kill-irq-compression.patch patch applied |
||
Created attachment 11649 [details]
Output of acpidump
Created attachment 11650 [details]
Patch which disables IO-APIC on Dell OptiPlex GX240 if ACPI is not enabled
Created attachment 11655 [details]
patch vs 2.6.22 to remove acpi=ht blacklist entry for GX240
just to set the context here...
This patch to remove the acpi=ht blacklist entry for
the the OptiPlex GX240 is already in the queue for 2.6.23.
"acpi=force" is needed on the GX240 up through 2.6.22
unless this patch is applied.
After this patch is applied, there are no known ACPI-related
issues on this box -- but lets keep this bug report in the
ACPI category until we can figure out the root cause
of the legacy mode issue.
Summarizing the e-mail thread... USB ports on back of the box always run fast, no matter if in ACPI mode, acpi=off Legacy mode, PIC mode, or IOAPIC mode: 2199226 bytes (2,2 MB) copied, 2.60062 seconds, 846 kB/s USB ports on the front of the box run at that fast speed when in ACPI mode, or when in Legacy PIC mode. But in Legacy IOAPIC mode, they run 6x slower: 2199226 bytes (2,2 MB) copied, 16.7524 seconds, 131 kB/s please attach the output from lspci -vv it is necessary to trace exactly how ACPI is configuring the interrupts for these devices. Created attachment 11656 [details]
dmesg-acpi=ht-apic.txt
The slow case:
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
PCI: Setting latency timer of device 0000:00:1f.2 to 64
uhci_hcd 0000:00:1f.2: UHCI Host Controller
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1f.2: irq 19, io base 0x0000ff80
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
PCI: Setting latency timer of device 0000:00:1f.4 to 64
uhci_hcd 0000:00:1f.4: UHCI Host Controller
uhci_hcd 0000:00:1f.4: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1f.4: irq 18, io base 0x0000ff60
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
0000:02:0c.0: 3Com PCI 3c905C Tornado at f880cc00.
PCI: Using IRQ router PIIX/ICH [8086/2440] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:1f.2[D] -> IRQ 19 (usb1)
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:00:1f.4[C] -> IRQ 18 (usb2)
PCI->APIC IRQ transform: 0000:00:1f.5[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:02:08.0[A] -> IRQ 17
PCI->APIC IRQ transform: 0000:02:0c.0[A] -> IRQ 18 (eth0)
CPU0
0: 201306 IO-APIC-edge timer
1: 1457 IO-APIC-edge i8042
2: 0 XT-PIC-XT cascade
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
12: 19218 IO-APIC-edge i8042
14: 18704 IO-APIC-edge ide0
15: 6973 IO-APIC-edge ide1
16: 56862 IO-APIC-fasteoi r128@pci:0000:01:00.0
17: 20792 IO-APIC-fasteoi Intel 82801BA-ICH2
18: 74 IO-APIC-fasteoi uhci_hcd:usb2, eth0
19: 38 IO-APIC-fasteoi uhci_hcd:usb1
NMI: 0
LOC: 201260
ERR: 0
MIS: 0
Created attachment 11658 [details]
dmesg-acpi=force-apic.txt
the fast case:
ACPI: PCI Interrupt 0000:02:0c.0[A] -> GSI 18 (level, low) -> IRQ 16
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
0000:02:0c.0: 3Com PCI 3c905C Tornado at f881ac00.
ACPI: PCI Interrupt 0000:00:1f.2[D] -> GSI 19 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.2 to 64
uhci_hcd 0000:00:1f.2: UHCI Host Controller
uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1f.2: irq 17, io base 0x0000ff80
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
hda: cache flushes supported
hda: hda1 hda2 hda3 hda4 <<6>ACPI: PCI Interrupt 0000:00:1f.4[C] -> GSI 23
(level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1f.4 to 64
uhci_hcd 0000:00:1f.4: UHCI Host Controller
uhci_hcd 0000:00:1f.4: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1f.4: irq 18, io base 0x0000ff60
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
GSI
18 0000:02:0c.0[A] (eth0)
19 0000:00:1f.2[D] (usb1) (front)
23 0000:00:1f.4[C] (usb2) (rear)
eth0 looks sane -- it is on IRQ18 in Legacy mode,
and is on GSI18 in ACPI mode, and presumably it is working
fine in both modes.
usb1 also looks sane -- it is on IRQ19 in Legacy mode,
and it is on GSI 19 in ACPI mode.
usb2 looks broken -- it is on GSI23 in ACPI mode, and is on
IRQ18 in Legacy mode. In ACPI mode there are no programmable
interrupt links for this device - it is hard-coded in the _PRT,
so one would expect it to have the same interrupt wire in both
ACPI and Legacy mode.
The other puzzle is that the issue is with the front usb ports,
which were identified via e-mail as usb1, not as usb2.
Please connfirm that in "acpi=off" mode, the issue is with
19: 38 IO-APIC-fasteoi uhci_hcd:usb1
and not with
18: 74 IO-APIC-fasteoi uhci_hcd:usb2, eth0
because it would make more sense if the issue were with usb2,
for if usb2 were mis-configured in legacy mode such that it
was taking interrupts on irq23 but looking for them on irq18,
then it would only be working because the system happened
to poll it when ethernet interrupts occurred.
Indeed, if this were the case, you'd find that it worked better
under conditions of high ethernet interrupt load, and didn't
work at all if you disconnected the ethernet cable.
Created attachment 11659 [details]
i386-irq-kill-irq-compression.patch
The ACPI-mode dmesg and /proc/interrupts in e-mail don't match --
probably because they were taken on different boots and the
probe order may have changed.
Please apply this patch to disable "irq compression", which
make make GSI = IRQ = the same number independent of probe order.
With this patch applied, please boot in ACPI+IOAPIC mode,
capture /proc/interrupts and paste them here, and attach the dmesg.
Looking up the _PRT entries for these devices in the DSDT:
0000:00:1f.2[D] is hard-coded to GSI x13 = GSI 19
Package (0x04)
{
0x001FFFFF,
0x03,
0x00,
0x13
},
0000:00:1f.4[C] is hard-coded to GSI x17 = GSI 23
Package (0x04)
{
0x001FFFFF,
0x02,
0x00,
0x17
},
0000:02:0c.0[A] is hard-coded to GSI x12 = GSI 18
Package (0x04)
{
0x000CFFFF,
0x00,
0x00,
0x12
},
This confirms the presumption above that ACPI isn't programming
anything here in IOAPIC mode -- it is just following the description
of the hard-coded interrupt connections on the motherboard.
Created attachment 11673 [details]
Output of lspci -vv
Created attachment 11674 [details]
dmesg with acpi=ht and IO-APIC enabled (another)
I booted with acpi=ht and here's what my /proc/interrupts looks like:
CPU0
0: 62 IO-APIC-edge timer
1: 5363 IO-APIC-edge i8042
2: 0 XT-PIC-XT cascade
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
12: 19599 IO-APIC-edge i8042
14: 21515 IO-APIC-edge ide0
15: 13867 IO-APIC-edge ide1
16: 114548 IO-APIC-fasteoi r128@pci:0000:01:00.0
17: 0 IO-APIC-fasteoi Intel 82801BA-ICH2
18: 2743 IO-APIC-fasteoi uhci_hcd:usb2, eth0
19: 723 IO-APIC-fasteoi uhci_hcd:usb1
NMI: 0
LOC: 423652
ERR: 0
MIS: 0
When I use the ports on rear panel (fast), the line which
increments is the following:
19: 903 IO-APIC-fasteoi uhci_hcd:usb1
When I use the ports on the front panel (slow), the line which
increments is the following:
18: 2983 IO-APIC-fasteoi uhci_hcd:usb2, eth0
Created attachment 11675 [details]
dmesg with acpi=force and the i386-irq-kill-irq-compression.patch patch applied
I applied i386-irq-kill-irq-compression.patch and
booted with acpi=force.
In addition, here's /proc/interrupts:
CPU0
0: 71 IO-APIC-edge timer
1: 1250 IO-APIC-edge i8042
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 1 IO-APIC-edge rtc
9: 1 IO-APIC-fasteoi acpi
12: 7485 IO-APIC-edge i8042
14: 8114 IO-APIC-edge ide0
15: 2959 IO-APIC-edge ide1
16: 22683 IO-APIC-fasteoi r128@pci:0000:01:00.0
17: 0 IO-APIC-fasteoi Intel 82801BA-ICH2
18: 287 IO-APIC-fasteoi eth0
19: 46 IO-APIC-fasteoi uhci_hcd:usb1
23: 0 IO-APIC-fasteoi uhci_hcd:usb2
NMI: 0
LOC: 92660
ERR: 0
MIS: 0
Front USB port is
23: 498 IO-APIC-fasteoi uhci_hcd:usb2
Rear USB port is
19: 46 IO-APIC-fasteoi uhci_hcd:usb1
Thanks for confirming that usb1 on IRQ19 works properly in both ACPI and legacy IOAPIC mode. The problematic front usb2 port appears alone on IRQ23 in ACPI mode, and it appears shared with eth0 on irq18 in MPS mode, so it is looking like the theory above is correct and that this box has a bogus MPS table entry. Please test the front usb1 in acpi=off mode with the ethernet cable detached. I expect it should be worse than slow -- it may not work at all. Also, you might be able to make it run fast by causing a lot of ethernet interrupts when you are using usb1. This would confirm the reason for the speed differences in your tests are due to the rate of ethernet interrupts on irq18. Please also test the "irqpoll" workaround in acpi=off IOAPIC mode. > Please test the front usb1
er. typo, in comment above,
please test the problematic front usb2, of course...
Mr. Brown, You are right: When I disconnected the ethernet cable and attached my USB enabled digital camera to the front USB port, nothing happened. The camera was not even detected by the kernel. When I connected the ethernet cable, the camera was detected by the kernel - in slow speed that is. I have also tried appending "irqpoll" to the kernel commandline. It seemed to make the slow transfer speed even slower (on the front port; I haven't tested the rear port.) # dd if=dsc00684.jpg of=/dev/null 4654+1 records in 4654+1 records out 2383349 bytes (2,4 MB) copied, 27.7139 seconds, 86,0 kB/s Note: I have conducted these tests with the patch named "i386-irq-kill-irq-compression.patch" applied. If this could change the test results, please let me know and I will try a vanilla kernel. Thanks for testing. The remaining problem on this machine is that the front-USB controller has a bad entry in the BIOS MPS table. Options: 1. run in ACPI mode -- which gets it right 2. run in MPS mode, but with "noapic" 3. run in MPS mode, with a patch to do #2 automatically 4. run in MPS mode, with a new patch to correct just the bad entry 5. run in MPS mode, and use the back ports, not the front ports. The ACPI issue is closed and the MPS issue is root-caused and has multiple workarounds. I recommend options #1 and #5 -- I do not recommend options 2,3,4 since it would just clutter the kernel with a model-specific BIOS workaround for a mode that most people don't use anyway. patch in comment #3 shipped in Linux-2.6.23-rc1 closed. |
Most recent kernel where this bug did *NOT* occur: None Distribution: Debian 4.0r0 ("Etch") Hardware Environment: Dell OptiPlex GX240, Pentim IV 1.7GHz Software Environment: Linux 2.6.21.3 from kernel.org Problem Description: When ACPI is disabled but IO-APIC is enabled, the USB ports on the front panel of Dell OptiPlex GX240 very slowly. (Dell OptiPlex GX240 is in the ACPI blacklist so ACPI gets set up only by acpi=ht.) This results in very slow USB performance. Copying a few photos from an USB-enabled digital camera takes five to six times longer compared to the performance when the camera is connected to one ofthe USB ports on the rear panel. If Dell OptiPlex GX240 had not been in the ACPI blacklist, this problem would show up only with kernels without ACPI compiled in. In addition, I wrote a patch which implements an IO-APIC blacklist and disables IO-APIC on Dell Optiplex GX240 if ACPI is not enabled. Please see the following threads for more information: http://marc.info/?t=118079385400003&r=1&w=2 http://marc.info/?t=117897881900001&r=1&w=2 Steps to reproduce: Find a Dell OptiPlex GX240 and boot Linux without anything appended to the kernel command line. Notice that the USB ports on the front panel work very slowly whereas the ports on the rear panel work normally. Boot with "acpi=force" *OR* "noapic" appended to the command line and notice that the USB ports on the front panel start work at normal speed.