Re: Netbook mit Windows 7 schiesst Intel Pro/1000 GT Adapter ab

On Mon, Mar 29, 2010 at 12:27:12PM +0200, Oliver Fromme wrote:
> Rolf Witt <fbsd-de(at)donut.de> wrote:
> > Ich habe hier ein Aldi-Netbook Medion Akoya E1212 mit einem RaLink
> > WLAN-Adapter bzw. einer 100MBit Realtek PCI On Board Netzwerkkarte,
> > welches unter Windows 7 Professional läuft.
> >
> > Egal ob WLAN- oder Ethernet Connect, sobald ich etwa ein Flashvideo
> > abspiele, meldet der FreeBSD (7.3 Prerelease stable) auf dem ein Squid
> > (2.7.STABLE) als Proxy läuft zuverlässig den allgemein beliebten em0
> > Watchdog timeout.
> > Wenn ich TSO auf dem FreeBSD-Rechner abschalte ist der Fehler weg.
> > Ich habe es bereits mit diversen Netzwerkeinstellungen auf Windows-Seite
> > probiert und probehalber mal den Ethernet-Anschluss an einen anderen
> > Switch verlegt. Alles ohne Erfolg.
> > Mit einer billigen Realtek 8169 (glaube ich) tritt das Problem, auch mit
> > TSO an, nicht auf.
> >
> > Meine Windows XP bzw. Windows 7 x64 Maschinen können den Fehler nicht
> > provozieren.
> >
> > Die Hardware, die den Heimserver betreibt, ist ein betagter
> > Fujitsu-Siemens Pentium III (850MHz) Scenic Rechner (diese Miditower mit
> > der verschiebbaren grünen Frontplatte) mit einem Intel PRO/1000 GT
> > Desktop Adapter, der ansonsten schon mehrere Jahre erstaunlich stabil
> > und zuverlässig läuft.
>
> Zunächstmal würde ich empfehlen, TSO ausgeschaltet zu lassen,
> um das Problem zu umgehen. Auf der angegebenen Hardware wird
> sich vermutlich sowieso kein Unterschied feststellen lassen.
>
> Übrigens, eine Realtek-8169 unterstützt TSO überhaupt nicht,
> insofern ist es nicht verwunderlich, dass das Problem dort
> nicht auftritt, auch wenn TSO vermeintlich eingeschaltet ist.

Falsch.
8169'er unterstützen allesamt TSO.
Aktuelle Realtek Chips sind keineswegs so schlecht wie ihr Ruf.
Allerdings braucht es im Treiber einige Workarounds, damit das läuft,
von daher ist das in einigen FreeBSD Versionen abgeschaltet.
Aber Realtek ist da nicht allein, dass die Workarounds für TSO brauchen.

[51]cicely13> ifconfig
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=399b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC>

re0: <RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet> port 0xc800-0xc8ff mem 0xdb800000-0xdb8000ff irq 12 at device 0.0 on pci2
re0: Chip rev. 0x04000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211B media interface> PHY 1 on miibus0
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
re0: Ethernet address: 00:01:08:00:79:92
re0: [FILTER]

re0(at)pci0:2:0:0: class=0x020000 card=0x816914db chip=0x816910ec rev=0x10 hdr=0x00
    vendor = 'Realtek Semiconductor'
    device = 'Single Gigabit LOM Ethernet Controller (RTL8119)'
    class = network
    subclass = ethernet

Und ja - das umschalten von TSO auf nonTSO macht Performance
Unterschiede - jedenfalls beim Messen von künstlichen Situationen.

> Warum das Problem mit einigen Clients auftritt und mit ande-
> ren nicht, kann ich nicht sage, da ich Deinen Netzwerkaufbau
> nicht kenne (welche Ports sind womit verbunden?).
>
> Einen PR aufzumachen, ist sicherlich eine gute Idee.
> Vorher aber evtl. nochmal auf ein aktuelles 7-stable gehen;
> zuletzt gab es vor ca. zwei Wochen Commits im em(4)-Source,
> bei denen es der Beschreibung nach auch um Watchdog-Timeouts
> ging.
>
> Falls das Problenm bestehen bleibt und Du einen PR aufmachst,
> gibt unbedingt die genau Hardware an (der entsprechende Aus-
> schnitt aus »pciconf -lv«) und die Ausgaben eines verbose-
> Boot, die mit dem NIC zu tun haben.

Ich denke auch, dass sich das der em-Guru ansehen sollte.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message