Bug 8023
Summary: | ehci_hcd driver bug | ||
---|---|---|---|
Product: | Drivers | Reporter: | Alexander N. Golovko (alexandro) |
Component: | USB | Assignee: | David Brownell (dbrownell) |
Status: | CLOSED CODE_FIX | ||
Severity: | high | CC: | greg, protasnb, raquacontact |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.20 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 5089 | ||
Attachments: |
This is normal start without any kernel params, when I get this bug
lspci lsusb with my Ralink usb dongle attached ifconfig after my wireless stops working dmesg with acpi=noirg dmesg with irqpoll, gives some errors dmesg with noacpi dmesg with pci=noacpi dmesg with pci=routeirq |
Description
Alexander N. Golovko
2007-02-16 12:56:12 UTC
PCI USB controller based on VIA VT6212L chip. Alexander, can you please test with the latest kernel (2.6.23+)? Thanks. I have similar problem to this, so instead of opening a new bug report, I will add it here as the original reporter seems to be not interested in this bug anymore. Most recent kernel where this bug did *NOT* occur: ?? Distribution: arch linux Hardware Environment: celeron coppermine 2x, Abit VP6 motherboard, Edimax (Via chipset) USB 2.0 controller Software Environment: Problem Description: same as original reporter This computer does not have USB 2.0 on a motherboard. I wanted to use wireless USB card (rt73 chipset) at high speed, because on usb 1.1 speed I could not use my internet conection to its full potencial. I bought Edimax USB 2.0 PCI card with 4 USB slots. My wireless card stops working after couple of seconds, mostly under 2 minutes of uptime. If I unload ehci_hcd module, everything is fine and working, except for the slow speed, which is why I bought this new controller at first. I did a search on this bug and found various methods to solve it, so I tried all of those without success. I tried booting with these parameters (each one separately) : acpi=noirq irqpoll noacpi pci=noacpi pci=routeirq None of those helped, some even made things worse. I will add dmesg and other info here. Created attachment 14597 [details]
This is normal start without any kernel params, when I get this bug
Created attachment 14598 [details]
lspci
Seems like most of the people having this problem have VIA chipsets on usb controller.
Created attachment 14599 [details]
lsusb with my Ralink usb dongle attached
Created attachment 14600 [details]
ifconfig after my wireless stops working
Card seems to be reckognized and working, but I can not ping anything.
Created attachment 14601 [details]
dmesg with acpi=noirg
Created attachment 14602 [details]
dmesg with irqpoll, gives some errors
My computer was very slow with this parameter.
Created attachment 14603 [details]
dmesg with noacpi
Created attachment 14604 [details]
dmesg with pci=noacpi
Created attachment 14605 [details]
dmesg with pci=routeirq
This time it did not work since boot. Normally it does and the dies after a while.
One last thing - after my device stops working, lsusb command gives me these errors: can't get hub descriptor: Operation not permitted cannot read device status, Operation not permitted (1) The desired output is still there though. I am not sure if this means something. This problem is not related only to wireless card, I get troublesome performance also with usb disk and flash memory. I tested this usb controller in other computer with Windows installed and it worked fine, so it is not a HW problem. I switched to new 2.6.24 kernel and it seems to be working ok. This report should be closed I asume. $ lsusb Bus 005 Device 032: ID 04fc:0c15 Sunplus Technology Co., Ltd Bus 005 Device 031: ID 04fc:0c15 Sunplus Technology Co., Ltd and from the dmesg, errors like: [25566.613764] hub 5-0:1.0: Cannot enable port 2. Maybe the USB cable is bad? [25568.162343] hub 5-0:1.0: connect-debounce failed, port 2 disabled This happens with two Zaapa 750GB USB 2.0 (SATA to USB) drives. They are directly connected to the backplate, and have a power supply of their own. If I have four of these connected simultaneously, the error happens even earlier. I'm marking this closed, since 2.6.24 seems to behave. The issue in comment #15 is completely unrelated. |