Bug 2472
Summary: | pegasus.c Tx timed out | ||
---|---|---|---|
Product: | Drivers | Reporter: | Sander Rijken (sr) |
Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | bunk |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.5 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 5089 |
Description
Sander Rijken
2004-04-08 04:37:41 UTC
I have exactly the same thing with all my 2.6 kernels. My Hardware : AMD K6-233 USB host : 0000:00:01.2 USB Controller: Intel Corp. 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) (USB 1.0) Software : USB driver: uhci-hcd, pegasus, both modules NIC hang after a few minutes (sometimes hours) OR heavy data rate ( > 100 Kb/s ). I will add that the NIC hang faster (only a few seconds) when the system is under high load (2.00 and more). Now we know it isn't ohci specific. Here is the dmesg :Nov 2 13:51:33 BlueBox kernel: drivers/usb/net/pegasus.c: eth2: Tx timed out. Nov 2 13:51:43 BlueBox kernel: NETDEV WATCHDOG: eth2: transmit timed out Nov 2 13:51:43 BlueBox kernel: drivers/usb/net/pegasus.c: eth2: Tx timed out. Nov 2 13:51:53 BlueBox kernel: NETDEV WATCHDOG: eth2: transmit timed out Nov 2 13:51:53 BlueBox kernel: drivers/usb/net/pegasus.c: eth2: Tx timed out. (eth0 and eth1 are 3Com PCI NICs) The only thing to do is to unplug/replug the NIC. Also, ifconfig eth2 is strange : eth2 Lien encap:Ethernet HWaddr 00:05:1B:00:4C:B5 adr inet6: fe80::205:1bff:fe00:4cb5/64 Scope:Lien UP BROADCAST RUNNING MULTICAST MTU:1536 Metric:1 RX packets:49804 errors:0 dropped:0 overruns:0 frame:0 TX packets:57726 errors:10355 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:7542743 (7.1 MiB) TX bytes:19227472 (18.3 MiB) (only after a few seconds). I tried on another system : AMD K7 Barthon 2500+ Host : 0000:00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a4) Works fine but lots of intr status -84 messages in kern.log (more than one per second) Is this problem still present in kernel 2.6.13-rc6? I'm assuming this issue is already fixed. Please reopen this bug if it's still present in recent 2.6 kernels. |