|
r8169/mii is still broken for me with linux-image-3.6.0-8.dmz.1-liquorix-686 and firmware-realtek=0.36+nmu2.
:: Code :: # lspci -nnvvv
<...> 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01) Subsystem: ASUSTeK Computer Inc. P5B [1043:81aa] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 44 Region 0: I/O ports at b800 [size=256] Region 2: Memory at feaff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at feac0000 [disabled] [size=128K] Capabilities: [40] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [48] Vital Product Data Unknown small resource type 00, will not decode more. Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+ Address: 00000000fee0300c Data: 4181 Capabilities: [60] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 1024 bytes, PhantFunc 0, Latency L0s <1us, L1 unlimited ExtTag+ AttnBtn+ AttnInd+ PwrInd+ RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 4096 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 unlimited, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [84] Vendor Specific Information: Len=4c <?> Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap- CGenEn- ChkCap- ChkEn- Capabilities: [12c v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Capabilities: [148 v1] Device Serial Number 1a-00-00-00-10-ec-81-68 Capabilities: [154 v1] Power Budgeting <?> Kernel driver in use: r8169 Back to top |
|||||
|
I'm now affected by this too, on the newest kernel, I don't think I had this issue back then though.
3.7.0-2.dmz.1-liquorix-amd64 - everything ok 3.7.0-5.dmz.2-liquorix-amd64 - ping & traceroute work ok, DNS seems to work as I get IPs from domains to ping/traceroute, BUT I can't use any web browser, no connection works ever; tested opera/dwb/chrome/links2/lynx logs: 3.7.0-2.dmz.1-liquorix-amd64: pastebin.com/8dqBSEd0 3.7.0-5.dmz.2-liquorix-amd64: pastebin.com/Tqf2npdj already tried: *apt-get install -t experimental firmware-linux firmware-linux-free firmware-linux-nonfree firmware-realtek - updated from 0.36+wheezy.1 to 0.37(as per the first page link: bugs.debian.org/cgi-bin/bugreport.cgi?bug=687927) to no avail *update-initramfs -k all -u -v ; reboot - afaik smxi does this on a new kernel install anyway but hey Ideas? Back to top |
|||||
|
Licaon, can you try running ifconfig eth0 txqueuelen 1000? That is, of course, where eth0 is your network device.
Back to top |
|||||
|
Strange that 3.7.0-2.dmz.1 has txqueuelen set to 1000 yet 3.7.0-5.dmz.2 sets it to 50. Anyway setting it back to 1000 does not help, tried up/down/kill dhcp/dhcp to no avail.Tried 8192 too just for kicks. Nope.
Back to top |
|||||
|
Try now, I'm no longer using BFS in 3.7.0-6.dmz.1.
Back to top |
|||||
|
is this on a regular basis or only for testing purposes?
Back to top |
|||||
|
It's for the times damentz feels bfs isn't stable or bug free enough to ship with liquorix.
Back to top |
|||||
|
@damentz: what seems to be the issue with BFS now?
3.7.0-6.dmz.1 ~ txqueuelen is 50, still not working, netstat says the TCP connections are always in SYN_SENT state :( /LE: tracking the tx_queue_len change to github.com/damentz/zen-kernel/commit/4e4f5194c5ec4d60c91fc49f813ac4103ee2a22f yielded this line :: Code :: +int sysctl_tcp_ecn __read_mostly = 1;/LE: tested on both 6.dmz.1 and 5.dmz.2 and yes, looks like forcing explicit congestion control hampers TCP connections at least on my setup ( RTL8169->1Gb->Cisco EPC 3925 ) :: Code :: tcp_ecn - INTEGER
Enable Explicit Congestion Notification (ECN) in TCP. ECN is only used when both ends of the TCP flow support it. It is useful to avoid losses due to congestion (when the bottleneck router supports ECN). Possible values are: 0 disable ECN 1 ECN enabled 2 Only server-side ECN enabled. If the other end does not support ECN, behavior is like with ECN disabled. Default: 2 Back to top |
|||||
|
Explicit Congestion Notification does not work in all locations that is why it is almost always in mode 2 "Accept ECN if the other side asks for it only" or mode 0 "Ignore ECN mark on packets and treat them as normal" by default.
mode 1 marks all your connections as "ECN enabled" and old or non-complient hardware and software may drop or block connections if you use it. Some piece of hardware or software somewhere between you and and the address you are trying to connect to probably does not support ECN packets. If you can't connect to the Internet at all it could be your router (if you have one) or your ISP that has problems with ECN packets. Back to top |
|||||
|
Interesting Licaon_kter. What kind of router do you have? I'll be reverting the default tcp_ecn change, but it would still be nice to know what kind of hardware or software blocks explicit congestion notifications.
And dark-D, I think I'll be sticking to CFS this time. I made a large number of changes to reduce the spread of latency per runtime item in CFS, and it seems to be working better than running BFS. You can view the changes here: github.com/damentz/zen-kernel/commit/0014f47e8ee9483d0a1f737c5fbec247e5f28f27 Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||