[Fli4l_dev] Informationen zum Weekly-Tarball vom 26.4.2013 [27286]

Matthias Prager linux at matthiasprager.de
Mo Mai 6 17:02:15 CEST 2013


Hallo Harvey, Hallo Bernd,

danke für die Links. Nach allem was ich bisher so von
den Intel e1000 und e1000e Karten+Treibern mitbekommen
habe sind sie zwar scheinbar der Goldstandard
(jeder empfiehlt sie als schneller+stabiler vs. realtek),
aber hochproblematisch, oft instabil und insgesamt kommen
sie mir wie Flickschusterwerk vor. Immerhin läuft die
Treiberentwicklung open-source auf sf.net. Ich habe
selbst schon einige der Probleme mitmachen dürfen,
sei es ESXi und nicht funktionierende Karten, oder
FreeBSD und Interrupt Storms mit den Intel-LAN Karten
und nun dieser Bug auf meinem Router.

Da ich momentan nichts weiter an Informationen aus dem
Router ziehen kann werde ich ihn neu starten.
Jetzt überlege ich nur, an welcher Stellschraube ich
zuerst drehe.

Wenn man dem Internet glauben schenken darf, hat der
e1000e Treiber (momentan?) drei Problembereiche:

1) Die BQL (byte queue limits) Problematik, welche sich angeblich
durch den Befehl:
> echo max > /sys/class/net/eth1/queues/tx-0/byte_queue_limits/limit_min
Temporär beseitigen lässt.

2) Probleme mit den Stromsparzuständen (ASPM & co). Wie
in dem von Bernd verlinkten Blogpost auch zu lesen ist reicht
der Kernelparameter 'pcie_aspm=off' nicht aus, um den Karten
das Energiesparen abgewöhnen. Statt des recht invasiven Eingriffs
ins EEPROM, wie der Blogpost vorschlägt habe ich alternativ
eine Variante über setpci gefunden:
> setpci -s 01:00.0 CAP_EXP+10.b=40

3) Probleme mit PCIe 3.0 Interrupts (MSI-X).

4) Es gibt aber auch Leute die all diese drei Punkte
ausgeschlossen haben und trotzdem noch mit Problemen
kämpfen.

Ich halte Euch auf dem laufenden.

Viele Grüße,
Matthias

P.S. vielleicht wechsle ich auch erst mal auf den 3.2er
Kernel und schaue, ob es da auch Probleme gibt.

Am 06.05.2013 16:03, schrieb Harvey:
> Matthias,
> 
>>> NETDEV WATCHDOG: eth1 (e1000e): transmit queue 0 timed out
> 
> Uff. e1000e in kernel 3.8x war extrem buggy...
> 
>>> 02:00.0 Ethernet controller [0200]: Intel Corporation 82574L
>>> Gigabit Network Connection [8086:10d3]
> 
> ich habe sowas in meinem laptop und der wollte nicht mal starten ohne
> dass ich ihn von der console überzeugen musste, das die Karte ein
> Kabel drin hatte. Mit kernel 3.9 hat sich das gegeben.
> https://bugzilla.kernel.org/show_bug.cgi?id=56621
> 
>> So wie das für mich aussieht, ist dies ein Upstream Kernel Problem.
>>
> Yep, über die ganze kernel 3.8-serie...
> 
> siehe oben
> 
> Harvey
> 

Am 06.05.2013 16:14, schrieb Bernd Kuhls:> Matthias Prager
<linux at matthiasprager.de> wrote in
> news:km8bfl$ms2$1 at vm-news.spline.inf.fu-berlin.de:
>
>> Auch interessant finde ich den Output von lspci:
>>> 01:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit
>>> Network Connection [8086:10d3] (rev ff) (prog-if ff)
>>>      !!! Unknown header type 7f
>>>      Kernel driver in use: e1000e
>
> Hi,
>
> vielleicht hilft das hier?
>
http://tiagomarques.com/2013/01/intel-8257382574-e1000e-driver-aspm-l1-bug-
> network-problem/
>
> Viele Gr��e, Bernd
>



Mehr Informationen über die Mailingliste Fli4l_dev