netdev - r8169: hard freezes on TX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <200705201520.36672.eike-kernel@sf-tec.de>
Date:	Sun, 20 May 2007 15:20:30 +0200
From:	Rolf Eike Beer <eike-kernel@...tec.de>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	netdev@...r.kernel.org
Subject: r8169: hard freezes on TX

Hi all,

I often see freezes when I do much outgoing transfer. I have never seen this 
happening on incoming transfers. When this happens the system locks up hard, 
I don't see anything in the log. Since this is my laptop I have trouble 
debugging it: there is no serial console and debugging this via netconsole 
doesn't look like a good idea.

When I say "much outgoing transfer" this means "several megabytes". If I copy 
out 30 MB I almost everytime get this. I usually copy that much only at home 
when I feed my gentoo server. That host only has a 10 MBit connection. 
Nevertheless I've also seen that on different hosts using different files on 
different protocols (ftp, scp, smb).

This is the output of lspci for my NIC:

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI 
Express Fast Ethernet controller (rev 01)
        Subsystem: Toshiba America Info Systems Unknown device ff00
        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, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: I/O ports at 4000 [size=256]
        Region 2: Memory at da000000 (64-bit, non-prefetchable) [size=4K]
        [virtual] Expansion ROM at d4000000 [disabled] [size=64K]
        Capabilities: [40] 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: [48] Vital Product Data
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ 
Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [60] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <1us, L1 unlimited
                Device: AtnBtn+ AtnInd+ PwrInd+
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s, Port 0
                Link: Latency L0s unlimited, L1 unlimited
                Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x1
        Capabilities: [84] Vendor Specific Information
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [12c] Virtual Channel
        Capabilities: [148] Device Serial Number xx-xx-xx-xx-xx-xx-xx-xx
        Capabilities: [154] Power Budgeting

Hm, is there a reason why we don't use MSI here?

Ah, one thing is missing: I've not tested it with current kernel, latest I 
tested was 2.6.21-rc7. But I've seen this on many previous version, although 
I thought it became better some versions ago. I wont bet on it, it might just 
have been luck.

Eike

Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)