Bug 6747 - Network randomly freezes (eth1 usb cable modem)
Network randomly freezes (eth1 usb cable modem)
Status: CLOSED CODE_FIX
Product: Drivers
Classification: Unclassified
Component: USB
i386 Linux
: P2 blocking
Assigned To: Alan Stern
:
Depends on:
Blocks: USB
  Show dependency treegraph
 
Reported: 2006-06-25 09:00 UTC by luminoso
Modified: 2006-08-31 11:48 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.17+
Tree: Mainline
Regression: ---


Attachments
kernel configuration file (36.08 KB, application/octet-stream)
2006-06-25 09:14 UTC, luminoso
Details
Bugfix for uhci-hcd in 2.6.17.8 (713 bytes, patch)
2006-08-21 14:03 UTC, Alan Stern
Details | Diff
dmesg for bug 6747 (22.91 KB, application/octet-stream)
2006-08-23 11:53 UTC, luminoso
Details
from /sys/kernel/debug/usbmon/3t (401.50 KB, application/octet-stream)
2006-08-23 11:55 UTC, luminoso
Details
Try to detect changes to rx_frame_errors (25.04 KB, patch)
2006-08-26 13:24 UTC, Alan Stern
Details | Diff
logs generated from patch (146.85 KB, application/x-bzip)
2006-08-28 02:31 UTC, luminoso
Details
2nd log generated from patch (30.52 KB, application/octet-stream)
2006-08-29 09:58 UTC, luminoso
Details
usbnet rx-frame-errors test patch (3.23 KB, patch)
2006-08-29 11:40 UTC, Alan Stern
Details | Diff
kernel.log output (136.67 KB, application/octet-stream)
2006-08-29 14:17 UTC, luminoso
Details
Log usbnet errors (853 bytes, patch)
2006-08-30 10:48 UTC, Alan Stern
Details | Diff
output of patch8908 (39.72 KB, text/x-log)
2006-08-30 12:40 UTC, luminoso
Details
Print rx header (814 bytes, patch)
2006-08-30 14:07 UTC, Alan Stern
Details | Diff
results of patch8912 (35.82 KB, text/x-log)
2006-08-30 15:14 UTC, luminoso
Details
Bugfix for uhci-hcd: skip to end of TD list during toggle fixup (598 bytes, patch)
2006-08-31 08:10 UTC, Alan Stern
Details | Diff
dmesg output (23.52 KB, application/octet-stream)
2006-08-31 10:35 UTC, luminoso
Details

Description luminoso 2006-06-25 09:00:50 UTC
Most recent kernel where this bug did not occur:2.6.17.1 vanilla
Distribution:Gentoo
Hardware Environment:
Software Environment:
Problem Description:Internet connection randomly freezes with Motorola SB5100
Cable Modem (USB), with no dmesg messages.

Steps to reproduce: I just installed 2.6.17.1 vanilla kernel.

---------------------------------------------------------------------------

Hi.. I am using kernel-2.6.17.1 for a few days and i had a few problems with my
network connections.
My eth1 (Motorola SB5100 Cable Modem(USB)) freezes randomly, with no justification.
It keeps showing com ifconfig and also show an ip.

It happens more freqnuently when i am using amule, dmesg don't show anything.
To have connection again i can unplug and plug the usb cable, or simply do
/etc/init.d/net.eth1 restart.
I am also using dhcpcd 2.0.7, but i think there is no problem is that, because
with 2.6.16 kernel i have
no problems at all.

--
cat /proc/version
Linux version 2.6.17-ck1 (root@khona4) (gcc version 4.1.1 (Gentoo 4.1.1)) #3 SMP
PREEMPT Sun Jun 25 15:47:02 WEST 2006
--
cat /proc/modules
cat /proc/modules
w83627hf 22672 0 - Live 0xfe54a000
hwmon_vid 2816 1 w83627hf, Live 0xfe529000
i2c_isa 3712 1 w83627hf, Live 0xfe514000
snd_seq_midi 6432 0 - Live 0xfe509000
snd_emu10k1_synth 6656 0 - Live 0xf987d000
snd_emux_synth 31616 1 snd_emu10k1_synth, Live 0xfe538000
snd_seq_virmidi 5760 1 snd_emux_synth, Live 0xfe506000
snd_seq_midi_emul 6016 1 snd_emux_synth, Live 0xf9877000
snd_pcm_oss 33696 0 - Live 0xfe52e000
snd_mixer_oss 15232 1 snd_pcm_oss, Live 0xfe50c000
snd_seq_oss 29952 0 - Live 0xfd8f7000
snd_seq_midi_event 6144 3 snd_seq_midi,snd_seq_virmidi,snd_seq_oss, Live 0xf987a000
snd_seq 46928 8
snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_oss,snd_seq_midi_event,
Live 0xfe516000
snd_emu10k1 112292 2 snd_emu10k1_synth, Live 0xfd881000
snd_rawmidi 19232 3 snd_seq_midi,snd_seq_virmidi,snd_emu10k1, Live 0xf9855000
snd_ac97_codec 88352 1 snd_emu10k1, Live 0xfd89e000
snd_ac97_bus 2176 1 snd_ac97_codec, Live 0xf982b000
snd_pcm 65284 3 snd_pcm_oss,snd_emu10k1,snd_ac97_codec, Live 0xf9862000
snd_seq_device 6412 7
snd_seq_midi,snd_emu10k1_synth,snd_emux_synth,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,
Live 0xf984b000
snd_timer 18820 3 snd_seq,snd_emu10k1,snd_pcm, Live 0xf9838000
snd_page_alloc 7816 2 snd_emu10k1,snd_pcm, Live 0xf9835000
snd_util_mem 3584 2 snd_emux_synth,snd_emu10k1, Live 0xf9833000
snd_hwdep 6916 2 snd_emux_synth,snd_emu10k1, Live 0xf9830000
snd 43748 15
snd_emux_synth,snd_seq_virmidi,snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,snd_ac97_codec,snd_pcm,snd_seq_device,snd_timer,snd_hwdep,
Live 0xf983f000
soundcore 7648 1 snd, Live 0xf982d000
---
cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0295-0296 : w83627hf
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vesafb
03f6-03f6 : ide0
03f8-03ff : serial
0400-041f : 0000:00:1f.3
0480-04bf : 0000:00:1f.0
0800-087f : 0000:00:1f.0
d000-dfff : PCI Bus #02
  d800-d8ff : 0000:02:05.0
    d800-d8ff : sk98lin
  df80-df9f : 0000:02:0c.0
    df80-df9f : EMU10K1
  dfe0-dfe7 : 0000:02:0c.1
eec0-eedf : 0000:00:1d.0
  eec0-eedf : uhci_hcd
ef00-ef1f : 0000:00:1d.1
  ef00-ef1f : uhci_hcd
ef20-ef3f : 0000:00:1d.2
  ef20-ef3f : uhci_hcd
ef40-ef5f : 0000:00:1d.3
  ef40-ef5f : uhci_hcd
ef90-ef9f : 0000:00:1f.2
  ef90-ef9f : libata
efa0-efa7 : 0000:00:1f.2
  efa0-efa7 : libata
efa8-efab : 0000:00:1f.2
  efa8-efab : libata
efac-efaf : 0000:00:1f.2
  efac-efaf : libata
efe0-efe7 : 0000:00:1f.2
  efe0-efe7 : libata
fc00-fc0f : 0000:00:1f.1
  fc00-fc07 : ide0
  fc08-fc0f : ide1
---
cat /proc/iomem
# cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cfbff : Video ROM
000d0000-000d49ff : Adapter ROM
000f0000-000fffff : System ROM
00100000-3ff2ffff : System RAM
  00100000-0035ecb4 : Kernel code
  0035ecb5-0040c467 : Kernel data
3ff30000-3ff3ffff : ACPI Tables
3ff40000-3ffeffff : ACPI Non-volatile Storage
3fff0000-3fffffff : reserved
50000000-500003ff : 0000:00:1f.1
d7f00000-f7efffff : PCI Bus #01
  e0000000-efffffff : 0000:01:00.0
    e0000000-efffffff : nvidiafb
f8000000-fbffffff : 0000:00:00.0
fc900000-fe9fffff : PCI Bus #01
  fd000000-fdffffff : 0000:01:00.0
    fd000000-fdffffff : nvidiafb
  fe9e0000-fe9fffff : 0000:01:00.0
fea00000-feafffff : PCI Bus #02
  feafc000-feafffff : 0000:02:05.0
    feafc000-feafffff : sk98lin
febffc00-febfffff : 0000:00:1d.7
  febffc00-febfffff : ehci_hcd
ffb80000-ffffffff : reserved
--
lspci -vvv
00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02)
        Subsystem: ASUSTeK Computer Inc. Unknown device 80f6
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [e4] Vendor Specific Information
        Capabilities: [a0] AGP version 3.0
                Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans-
64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev
02) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 96
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=96
        I/O behind bridge: 0000f000-00000fff
        Memory behind bridge: fc900000-fe9fffff
        Prefetchable memory behind bridge: d7f00000-f7efffff
        Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #1 (rev 02) (prog-if 00 [UHCI])
        Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 4: I/O ports at eec0 [size=32]

00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #2 (rev 02) (prog-if 00 [UHCI])
        Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 4: I/O ports at ef00 [size=32]

00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #3 (rev 02) (prog-if 00 [UHCI])
        Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 18
        Region 4: I/O ports at ef20 [size=32]

00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
Controller #4 (rev 02) (prog-if 00 [UHCI])
        Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 4: I/O ports at ef40 [size=32]

00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI
Controller (rev 02) (prog-if 20 [EHCI])
        Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin D routed to IRQ 23
        Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Debug port

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c2) (prog-if 00
[Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=96
        I/O behind bridge: 0000d000-0000dfff
        Memory behind bridge: fea00000-feafffff
        Prefetchable memory behind bridge: fff00000-000fffff
        Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC Interface
Bridge (rev 02)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE Controller
(rev 02) (prog-if 8a [Master SecP PriP])
        Subsystem: ASUSTeK Computer Inc. P5P800-MX Mainboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at <unassigned>
        Region 1: I/O ports at <unassigned>
        Region 2: I/O ports at <unassigned>
        Region 3: I/O ports at <unassigned>
        Region 4: I/O ports at fc00 [size=16]
        Region 5: Memory at 50000000 (32-bit, non-prefetchable) [size=1K]

00:1f.2 RAID bus controller: Intel Corporation 82801ER (ICH5R) SATA Controller
(rev 02) (prog-if 8f)
        Subsystem: ASUSTeK Computer Inc. Unknown device 80a6
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at efe0 [size=8]
        Region 1: I/O ports at efac [size=4]
        Region 2: I/O ports at efa0 [size=8]
        Region 3: I/O ports at efa8 [size=4]
        Region 4: I/O ports at ef90 [size=16]

00:1f.3 SMBus: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev 02)
        Subsystem: ASUSTeK Computer Inc. P4P800 Mainboard
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 17
        Region 4: I/O ports at 0400 [size=32]

01:00.0 VGA compatible controller: nVidia Corporation NV31 [GeForce FX 5600]
(rev a1) (prog-if 00 [VGA])
        Subsystem: Micro-Star International Co., Ltd. Unknown device 9124
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 96 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Expansion ROM at fe9e0000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [44] AGP version 3.0
                Status: RQ=32 Iso- ArqSz=0 Cal=3 SBA+ ITACoh- GART64- HTrans-
64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell]
(rev 12)
        Subsystem: ASUSTeK Computer Inc. A7V600/P4P800/K8V motherboard
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 96 (5750ns min, 7750ns max), Cache Line Size: 16 bytes
        Interrupt: pin A routed to IRQ 22
        Region 0: Memory at feafc000 (32-bit, non-prefetchable) [size=16K]
        Region 1: I/O ports at d800 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data

02:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)
        Subsystem: Creative Labs CT4832 SBLive! Value
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 96 (500ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 20
        Region 0: I/O ports at df80 [size=32]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:0c.1 Input device controller: Creative Labs SB Live! Game Port (rev 08)
        Subsystem: Creative Labs Gameport Joystick
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 96
        Region 0: I/O ports at dfe0 [size=8]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
--
cat /proc/scsi/scsi
cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: ST3120026AS      Rev: 3.05
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: ST3120827AS      Rev: 3.43
  Type:   Direct-Access
--

I am following just the indications to submit a bug, i neved had done it before.
If you need something more just ask.

Is .config file needed? (both of them: 2.6.16-ck11 with no problems and
2.6.17.1+2.6.17-ck1 problematic.
Comment 1 Andrew Morton 2006-06-25 09:08:04 UTC
On Sun, 25 Jun 2006 09:02:03 -0700
bugme-daemon@bugzilla.kernel.org wrote:

> Most recent kernel where this bug did not occur:2.6.17.1 vanilla

I think you mean it _did_ occur in 2.6.17.1.  That question is asking what
is the most recent kernel in which it did _not_ occur.

What net driver is that machine using?  tg3?  skge?

Comment 2 luminoso 2006-06-25 09:12:58 UTC
The last version that it did not occour is 2.6.16-ck11 (i used to use ck
sources..  i only tested vanilla just to be shore)

drivers:
-
CONFIG_USB_USBNET=y
CONFIG_USB_NET_CDCETHER=y
CONFIG_USB=y
CONFIG_USB_UHCI_HCD=y

CONFIG_SK98LIN=y 
-
is this what you are asking for?
i will also submit .config

Another thing could be important is that i cannot access to my modem status page
(http://192.168.100.1).
Comment 3 luminoso 2006-06-25 09:14:21 UTC
Created attachment 8413 [details]
kernel configuration file
Comment 4 luminoso 2006-06-25 12:03:50 UTC
I've noticed another thing.
With 2.6.16-ck11 my network was no errors. 

eth1      Link encap:Ethernet  HWaddr 00:11:80:EB:65:9A
          inet addr:217.129.133.137  Bcast:217.129.143.255  Mask:255.255.240.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:699616 errors:0 dropped:0 overruns:0 frame:0
          TX packets:586397 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:666051647 (635.1 Mb)  TX bytes:130582486 (124.5 Mb)


while with 2.6.17.1 i noticed errors 

          RX packets:699616 errors:!!WHERE!! dropped:0 overruns:0 frame:0
          TX packets:586397 errors:(and maybe here?) dropped:0 overruns:0


I can re-test it if you want (for TX packets i am not shore)
Comment 5 luminoso 2006-07-01 13:07:27 UTC
I am now using 2.6.17.3 and i noticed that I'm now capable to stay connected,
but also having lots of eth1 errors.

eth1      Link encap:Ethernet  HWaddr 00:11:80:EB:65:9A
          inet addr:217.129.133.137  Bcast:217.129.143.255  Mask:255.255.240.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:615602 errors:4027 dropped:0 overruns:0 frame:4027
          TX packets:674816 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:319488901 (304.6 Mb)  TX bytes:241017064 (229.8 Mb)

4027 and raising.
This bug is now 1/2 corrected.
I don't know if I should downgrade to 2.6.16 you stay ussing 2.6.17 in this
conditions.
Comment 6 luminoso 2006-07-01 14:03:30 UTC
After all, it stills crashing my network.
I don't know if the fact that now it took a little longer is to take in
consideration.
Also, should this be moved to Networking category instead Drivers category?
(am i alone? lol)
Comment 7 spam 2006-07-16 14:22:24 UTC
i had the same problem with 2.6.17.5, after a downgrade to 2.6.16.16 it
disapeared. 2.6.16.26 seems to have the same problem too.
Comment 8 luminoso 2006-08-03 06:16:48 UTC
still not corrected on 2.6.17.17.. please.. can i submit any more usefull
information?

eth1      Link encap:Ethernet  HWaddr 00:11:80:EB:65:9A
          inet addr:217.129.133.137  Bcast:217.129.143.255  Mask:255.255.240.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6498 errors:36 dropped:0 overruns:0 frame:36
          TX packets:5639 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2071217 (1.9 Mb)  TX bytes:2857804 (2.7 Mb)
Comment 9 luminoso 2006-08-20 10:54:47 UTC
I again!
I tested A LOT Of kernels versions and i found where the bug happen..

Kernel verion <= 2.6.16.23 is CLEAN (i think that 2.6.16.23 is the last one of
2.6.16 series)

But right on kernel >= 2.6.17 I have problems with my modem.

So, from 2.6.16.23 to 2.6.17 there is something new that cause this driver to fail.

The changelog is very very extensive and I can't figure out wich commit cause
this fail.

Also, the 2.6.17.9 stills with this bug.
I would like to know if i can do something more.
Comment 10 luminoso 2006-08-20 11:10:31 UTC
I'm sorry, where i mean 2.6.16.23 is 2.6.16.27, on my last reply.

So, after some help, i think i found the commint.


---
commit e03d72b99e4027504ada134bf1804d6ea792b206
Author: Adrian Bunk <bunk@stusta.de>
Date:   Mon Jan 9 18:34:08 2006 -0800

    [PATCH] drivers/net/sk98lin/: possible cleanups
    
    This patch contains the following possible cleanups:
    - make needlessly global functions static
    - remove unused code
    
    Signed-off-by: Adrian Bunk <bunk@stusta.de>
    Cc: Stephen Hemminger <shemminger@osdl.org>
    Cc: Jeff Garzik <jgarzik@pobox.com>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
---
Comment 11 Adrian Bunk 2006-08-20 12:59:55 UTC
I don't see anything in this patch that could even remotely cause your problem.
Except if there's a persistent bug in the driver that wasn't visible before due
to pure luck.

Since sk98lin is a driver that will not stay long-term in the kernel, can you
check whether the skge driver works for you?
Comment 12 luminoso 2006-08-20 14:13:56 UTC
I was just trying to guess wich commit made my modem start to bug..
yes, you're right.. sk98lin is for my network adapter, not for my modem.. 

I will look once more to changelog...
Comment 13 Adrian Bunk 2006-08-20 14:45:32 UTC
First, to make sure we are not hunting an already fixed issue:
- still present in 2.6.17.9?
- still present in 2.6.18-rc4?

If you want to find the commit that was causing your problem, you have to do git
bisecting:

# install git and cogito on your computer

# clone the 2.6.17 tree:
cg-clone \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.17.y.git

# start bisecting:
cd linux-2.6.17.y
git bisect start
git bisect bad
git bisect good v2.6.16

# start round
cp /patch/to/.config .
make oldconfig
make
# install kernel, boot it, check whether it's good or bad, then:
git bisect [bad|good]
# start next round


After at about 12 reboots, you'll have found the guilty commit
("...  is first bad commit").

More information on git bisecting:
  man git-bisect
Comment 14 luminoso 2006-08-21 05:25:32 UTC
2.6.18-rc4 has the bug OFFTOPIC: and some stupid mouse bug (it jumps on the screen)
2.6.17.9 has also the bug

after use git I think i found the bug:

dccf4a48d47120a42382ba526f1a0848c13ba2a4 is first bad commit
commit dccf4a48d47120a42382ba526f1a0848c13ba2a4
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Sat Dec 17 17:58:46 2005 -0500

    [PATCH] UHCI: use one QH per endpoint, not per URB

    This patch (as623) changes the uhci-hcd driver to make it use one QH per
    device endpoint, instead of a QH per URB as it does now.  Numerous areas
    of the code are affected by this.  For example, the distinction between
    "queued" URBs and non-"queued" URBs no longer exists; all URBs belong to
    a queue and some just happen to be at the queue's head.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

:040000 040000 2210205f1df6153ddaa93cf25eb0300df45b5405
c287ccdd16dae4ef945ecc1e3e58a163ba27ebad M      drivers

--

I will now restart git for 2.6.17.y and try and option named "revert" just to be
shore (i think it can help)
Comment 15 Adrian Bunk 2006-08-21 09:41:26 UTC
Thanks for the bisecting!

Reverting this patch in 2.6.17 seems to require reverting some other patches first.

But it seems to work the other way:
Can you create a non-working kernel by applying this patch agains 2.6.16.27?
Comment 16 luminoso 2006-08-21 12:32:15 UTC
YEs.. i tried.. but..

#
git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git

git cherry-pick dccf4a48d47120a42382ba526f1a0848c13ba2a4
 fatal: Needed a single revision
 Not a single commit dccf4a48d47120a42382ba526f1a0848c13ba2a4
#
Comment 17 Alan Stern 2006-08-21 13:03:02 UTC
The patch you identified (as623) did contain a bug, and a fix for it was added
in 2.6.17.8 and 2.6.18-rc4.  So your git-bisect result probably doesn't mean
anything -- unless there is a second, unidentified bug still present.

Can you provide the contents of /proc/bus/usb/devices (you may need to do "mount
-t usbfs none /proc/bus/usb" first)?
Comment 18 Adrian Bunk 2006-08-21 13:45:40 UTC
@luminoso:
The bad commit is not in the 2.6.16 tree.

Do a
  git-show dccf4a48d47120a42382ba526f1a0848c13ba2a4 > /tmp/patch-bad
in the 2.6.17 git tree.

Then go to the 2.6.16.27 sources (no matter whether they are from a git tree or
directly downloaded) and do a
  patch -p1 < /tmp/patch-bad
and compile this kernel.
Comment 19 Adrian Bunk 2006-08-21 13:48:00 UTC
@Alan:
Since both 2.6.17.9 and 2.6.18-rc4 don't work for him, it seems there is a
second bug...
Comment 20 Alan Stern 2006-08-21 14:03:52 UTC
Created attachment 8842 [details]
Bugfix for uhci-hcd in 2.6.17.8

In fact there must be two bugs: the known bug in the as623 patch plus whatever
else is still causing problems.  The second bug might not be in uhci-hcd,
however.

In any case, it would be a mistake to apply as623 and predecessors without also
applying the bug-fix patch (attached).
Comment 21 luminoso 2006-08-21 14:37:29 UTC
cat /proc/bus/usb/devices

T:  Bus=05 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.16 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.3
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.16 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc= 17/900 us ( 2%), #Int=  1, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.16 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=02(comm.) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
P:  Vendor=07b2 ProdID=5100 Rev= 1.01
S:  Manufacturer=Broadcom Corporation
S:  Product=USB Cable Modem
S:  SerialNumber=001180EB659A
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
E:  Ad=85(I) Atr=03(Int.) MxPS=   8 Ivl=64ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=06da ProdID=0003 Rev= 0.00
S:  Manufacturer=OMRON
S:  Product=87XXUPS
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=20ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.16 uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 8
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.16 ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

Thanks for all help!
I will now work on patches... I will reply soon
Comment 22 luminoso 2006-08-21 15:38:42 UTC
I patched 2.6.27 sources with commit dccf4a48d47120a42382ba526f1a0848c13ba2a4
and it was... clean! It should be buggy, right?

Then i patched again the same sources with patch "Bugfix for uhci-hcd in
2.6.17.8" and it still clean..

Should I bisect again?
I still have shore that this bug IS present in 2.6.17.9 and 2.6.18-rc4, also, I
am shore, that it happears from 2.6.16.27 to 2.6.17.
Comment 23 Alan Stern 2006-08-22 08:31:53 UTC
This is why I don't trust git-bisect.

Just as an experiment, you could take all the drivers/usb/host/uhci* files from
the 2.6.17.9 source tree and copy them into the corresponding 2.6.16.23
directory.  I think it should build okay.  Then test the resulting 2.6.16.23
kernel with the transplanted uhci-hcd driver.  If it works, you'll know the bug
is in some other driver.
Comment 24 luminoso 2006-08-22 14:53:41 UTC
@Alan:
I followed your sugestion but it doesn't work:

  CC      drivers/usb/host/uhci-hcd.o
drivers/usb/host/uhci-hcd.c:53:24: error: pci-quirks.h: No such file or directory
drivers/usb/host/uhci-hcd.c: In function 
Comment 25 Alan Stern 2006-08-23 08:08:32 UTC
Whoops...  Looks like you also need to copy drivers/usb/host/pci-quirks.h from
2.6.17.9 into the 2.6.16.23 directory.  I forgot about that one.
Comment 26 luminoso 2006-08-23 09:09:02 UTC
@Alan:
I did what you said and... yes.. the bug is where! =)
Now.. what can I do? Will I have this bug corrected?
Comment 27 Alan Stern 2006-08-23 09:49:18 UTC
Okay, good.  You have definitely proved there is a bug in the 2.6.17.9 uhci-hcd
driver.  Before it can be fixed, though, we need to find out exactly where it is.

The next step is to use the usbmon facility in 2.6.17.9.  Instructions are in
the kernel source file Documentation/usb/usbmon.txt.  You will need to turn on
CONFIG_USB_MON and CONFIG_DEBUG_FS, and you should also set CONFIG_USB_DEBUG.

Capture the usbmon data during a test run, and make sure the bug occurs.  Then
attach it here, along the dmesg log for the same period.
Comment 28 luminoso 2006-08-23 11:53:29 UTC
Created attachment 8859 [details]
dmesg for bug 6747

from 2.6.17.9 kernel
Comment 29 luminoso 2006-08-23 11:55:47 UTC
Created attachment 8860 [details]
from /sys/kernel/debug/usbmon/3t

from kernel 2.6.17.9
Comment 30 luminoso 2006-08-23 11:56:21 UTC
When start using usbmon:

eth1      Link encap:Ethernet  HWaddr 00:11:80:EB:65:9A
          inet addr:217.129.133.137  Bcast:217.129.143.255  Mask:255.255.240.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:564 errors:3 dropped:0 overruns:0 frame:3
          TX packets:336 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:233158 (227.6 Kb)  TX bytes:37243 (36.3 Kb)

At the end:

eth1      Link encap:Ethernet  HWaddr 00:11:80:EB:65:9A
          inet addr:217.129.133.137  Bcast:217.129.143.255  Mask:255.255.240.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1908 errors:12 dropped:0 overruns:0 frame:12
          TX packets:1565 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1588133 (1.5 Mb)  TX bytes:166834 (162.9 Kb)

#cat /proc/bus/usb/devices
T:  Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=02(comm.) Sub=00 Prot=00 MxPS=32 #Cfgs=  1
P:  Vendor=07b2 ProdID=5100 Rev= 1.01
S:  Manufacturer=Broadcom Corporation
S:  Product=USB Cable Modem
S:  SerialNumber=001180EB659A
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
E:  Ad=85(I) Atr=03(Int.) MxPS=   8 Ivl=64ms
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

If I can do anything more just ask!
Comment 31 Alan Stern 2006-08-23 13:40:00 UTC
I don't see any indication of problems in the usbmon log, and none in the dmesg
log except possibly the line saying "eth1: rxqlen 0 --> 4".  Are you sure that
the problem occurred and the interface froze while you were collecting the logs?

If it did, try again and after the freeze occurs do this:

   echo 2 >/sys/module/uhci_hcd/parameters/debug

and then attach a copy of /sys/kernel/debug/uhci/0000:00:1d.1.  By the way, only
the last hundred lines or so of the usbmon log are important.  You can chop off
the rest.
Comment 32 luminoso 2006-08-24 12:33:00 UTC
Hi.. I performed what you said with 2.6.17.10 kernel.
But with this kernel eth1 doesn't freeze. But, still making errors (saw in
infconfig)

usbmon here: ftp://ftp.ua.pt/incoming/luminoso/2.mon.out.tar.bz2
do you need more logging?
Comment 33 Alan Stern 2006-08-24 13:22:02 UTC
You're talking about two different problems: the framing errors and the
interface freezing.  Freezing is almost certainly caused by a bug in uhci-hcd,
and that's what I want to fix.

Now go back over your earlier tests.  With which versions of the driver does the
interface freeze?  Did it freeze when you transplanted the 2.6.17 driver back to
2.6.16?  Does it freeze under 2.6.18-rc4?

The framing errors you see in ifconfig are a completely different matter.  They
have nothing to do with uhci-hcd.  If you didn't see any of these errors in
2.6.16, it may be a result of changes in the USB network driver.  (Unless you
can prove that the framing errors never occur in vanilla 2.6.16 but they do
occur when you transplant the 2.6.17 version of uhci-hcd to 2.6.16.  If that
happens then I am wrong.)

Adrian Bunk or someone else can tell you more about the framing errors than I
can.  For the time being, let's just work on the freezing issue.
Comment 34 luminoso 2006-08-25 07:35:56 UTC
Point of situation:
-On 2.6.17.9 eth1 still freeze, but not so frequently.
-Also, when I copy uhci drivers from 2.6.17.* to 2.6.16.27 ifconfig starts to
make errors, but i didn't test if eth1 died.
-Ifconfig errors was always present with freezing issuse.

It's a quite frustrating.. it's really random.. When I started this bug it
happens in 5 minutes after computer start.. now is taking more than one day long. 

(it freezes yesterday.. but i decided:let's use a clean 2.6.17.9! It's was
giving framing erros but isn't freezing.. so why not use 2.6.17.{9,10}? 

I deleted all sources and unpacked clean tarball again.. when i was not
debugging it happend.. now I am again debugging and waiting with 2.6.17.10)

I am now again waiting.. I hope report a new usefull usbmon debug soon.

Comment 35 Alan Stern 2006-08-25 08:34:03 UTC
Don't forget to report the results from the test in comment #31 also!
Comment 36 Alan Stern 2006-08-26 13:24:33 UTC
Created attachment 8881 [details]
Try to detect changes to rx_frame_errors

Here's a patch for 2.6.17.10 which I hope will tell us exactly when the RX
frame-error count changes.  If it works, it will add some very disruptive
messages to the system log every time the value is increased.

The patch will create a new configuration option, CONFIG_KWATCH.  You will have
to turn that on and then rebuild the kernel.  Unfortunately I can't test the
patch because I don't have a USB ethernet interface.
Comment 37 luminoso 2006-08-28 02:31:11 UTC
Created attachment 8886 [details]
logs generated from patch

Hi..
I applied the patch sucefully on 2.6.17.10 sources but I am getting problems on
torning on 'CONFIG_KWATCH=y' on .config. After editing it and performing "make
clean && make" it simply disapear from .config. I think it isn't enabled.
Anyway, I make a tarball of /var/log. Maybe logs are there and I just didn't
see.

This logs are clean. I deleted all of them before restart.

Offtopic: Even when using clean tarballs my kernel is named
2.6.17.10-g9e88eb4d-dirty. How do i get rid of "-g9e88eb4d-dirty"?
Comment 38 Adrian Bunk 2006-08-28 06:58:09 UTC
The option depends on CONFIG_DEBUG_KERNEL - you have to also set this option to y.
Comment 39 Alan Stern 2006-08-28 08:55:03 UTC
Yes, I forgot to mention CONFIG_DEBUG_KERNEL because I _always_ keep that option
turned on for my work!

I don't know where the "-g9e88eb4d-dirty" comes from.  Check the topmost
Makefile to make sure it's not there.  It might have something to do with the
way you install the new kernel for booting.  What do you get from "uname -a"?
Comment 40 luminoso 2006-08-29 09:58:46 UTC
Created attachment 8895 [details]
2nd log generated from patch

Hi.. There it is new logs generated with patch, now with CONFIG_KWATCH=y
working.
I also included .config of current kernel. I checked if 'ifconfig' is showing
errors and it look like this before making the tarball: 

eth1	  Link encap:Ethernet  HWaddr 00:11:80:EB:65:9A
	  inet addr:217.129.133.137  Bcast:217.129.143.255  Mask:255.255.240.0
	  UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
	  RX packets:218676 errors:1225 dropped:0 overruns:0 frame:1225
	  TX packets:242498 errors:0 dropped:0 overruns:0 carrier:0
	  collisions:0 txqueuelen:1000
	  RX bytes:78791751 (75.1 Mb)  TX bytes:89479444 (85.3 Mb)

About the "dirty" it started to appear since Comment #18. From that patch on
all new clean tarballs have "dirty" on kernel name.

uname -a
Linux khona4 2.6.17.10-g9e88eb4d-dirty #6 SMP PREEMPT Tue Aug 29 13:00:40 WEST
2006 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux
Comment 41 Alan Stern 2006-08-29 11:40:13 UTC
Created attachment 8896 [details]
usbnet rx-frame-errors test patch

I can't tell what's going on.  If that patch was working correctly, we should
have seen any change to the rx frame error counter.

Try this patch instead of 8881.  Attaching kern.log alone will be sufficient.

The "dirty" thing might be a leftover from your attempt at using git-bisect. 
maybe something didn't get cleaned up all the way.
Comment 42 luminoso 2006-08-29 14:17:59 UTC
Created attachment 8899 [details]
kernel.log output

Here it is.. I think now it worked. =)
Comment 43 Alan Stern 2006-08-29 14:27:48 UTC
It did work.  At least, the error counter remained at 0.  But I didn't change
anything!  All the patch does is print out the value of the counter whenever a
packet is sent or received.

I don't know.  Try running with and without the patch (all you have to do is
keep two separate copies of usbnet.ko, one built with the patch and one without,
and insmod one or the other to switch between them).  See if you can get the
error counter to change from 0.
Comment 44 Alan Stern 2006-08-30 10:48:09 UTC
Created attachment 8908 [details]
Log usbnet errors

I just got a clue, and now I understand a lot better what's going on.  Forget
about those previous patches and use this one instead.	It will put a message
in the kernel log every time one of those network errors occurs.  This way
we'll be able to see exactly what sort of error it is.
Comment 45 luminoso 2006-08-30 12:40:39 UTC
Created attachment 8910 [details]
output of patch8908

Huuuuugeeeee thanks! I spend all day patching and restarting, trying to find
anything new but nothing.

Where it is the results (thanks) of the 8908patch. I will keep it running just
for in case you need more.
Comment 46 Alan Stern 2006-08-30 14:07:35 UTC
Created attachment 8912 [details]
Print rx header

You don't have to keep running that patch; what you posted is good enough. 
It's now clear where the errors are coming from.  The driver is receiving
packets that are shorter than 14 bytes (the minimum for Ethernet).  I have no
idea why this happens only under 2.6.17 and not under 2.6.16.

Here's a different patch to try.  This one will log the headers in first 8
packets received and then after that the first 8 error packets.  I hope that
seeing the header contents will give a clue as to what's wrong.
Comment 47 luminoso 2006-08-30 15:14:16 UTC
Created attachment 8913 [details]
results of patch8912

here it is... it slowed down after 45mins +/-
Comment 48 Alan Stern 2006-08-31 08:10:59 UTC
Created attachment 8920 [details]
Bugfix for uhci-hcd: skip to end of TD list during toggle fixup

I think we found it.  This patch fixes a definite bug in uhci-hcd, and it's
almost certainly the bug causing your problems.  Try it and see, but keep the
previous patch installed as well just in case.
Comment 49 luminoso 2006-08-31 10:35:22 UTC
Created attachment 8921 [details]
dmesg output

IT WORKS!!!!!!!!!!! :)
dmegs still prints attached messages, but only at startup.

Maybe it's revelant: yesterday, when testing patch8912 even it stoped, like
today, showing new information on kernel.log errors still keep raising.

But now no errors on ifconfig. Works perfect! :)
Comment 50 Alan Stern 2006-08-31 10:55:57 UTC
Patch 8912 was designed to stop after printing 16 lines (or after 8 lines if
there are no errors).  I didn't need any more debugging info than that, and so
of course you saw the errors continuing to increase even after the patch had
stopped printing.

You can drop 8912 now.  It isn't needed, because 8920 fixes the problem.  I'll
submit 8920 for inclusion in the 2.6.17.x stable series and also for 2.6.18.

If you want, you can apply 8920 to 2.6.18-rc4 (or -rc5) right now.  It should
apply to that kernel with no changes and it should fix exactly the same problem.

Since everything is now working, I'll close this bug report.
Comment 51 luminoso 2006-08-31 11:07:30 UTC
Ok, thanks for all!!!

(should i also report mouse-jumping-bug that i found (i'm a sad sad man lol) on
2.6.18-rc4?)
Comment 52 Alan Stern 2006-08-31 11:16:41 UTC
If it's still present in 2.6.18-rc5, go ahead and report it.  But start a
separate Bugzilla entry.
Comment 53 luminoso 2006-08-31 11:48:28 UTC
Here it is: bug 7008
Once again, thanks for everything.

Note You need to log in before you can comment on or make changes to this bug.