# NETDEV WATCHDOG: eth1: transmit timed out [Risolto]

## flocchini

```
NETDEV WATCHDOG: eth1: transmit timed out

eth1: Transmit timeout, status 0c 0005 c07f media 08.

eth1: Tx queue start entry 4  dirty entry 0.

eth1:  Tx descriptor 0 is 9008a03c. (queue head)

eth1:  Tx descriptor 1 is 9008a03c.

eth1:  Tx descriptor 2 is 9008a03c.

eth1:  Tx descriptor 3 is 9008a03c.

eth1: link up, 10Mbps, half-duplex, lpa 0x0000

eth1: link up, 10Mbps, half-duplex, lpa 0x0000
```

sono ormai 10 giorni che questo problema mi attanaglia: ho 2 sk di rete, una onboard (eth0, che va da dio) e eth1, su slot pci ovviamente, che dopo un po' (quasi random, circa un paio d'ore) a bomba (800 kb/s di traffico), a prescindere dal servizio, si inchioda con quel dannato messaggio. Ho cambiato cavo, cambiato scheda (era una pro100 intel, ora ho su una realtek ma nn cambia). L'unica e' riavviare il servizio di rete, e a quel punto per altre 2 ore la cosa funziona. Ho cercato ovunque, trovando anche questo http://lists.us.dell.com/pipermail/linux-poweredge/2005-November/023540.html

che consiglia di aggirare il problema con  ethtool -K eth0 tso off ma ottengo in risposta un bell "Cannot set device tcp segmentation offload settings: Operation not supported"

In pratica il server e' inutilizzabile verso l'esterno

un po' di info: mobo asrock dual vsta (via pt880pro/ultra), conroe E6300

emerge info

```
Portage 2.1.1-r2 (default-linux/x86/2006.1, gcc-4.1.1, glibc-2.4-r4, 2.6.18-gentoo-r6 i686)

=================================================================

System uname: 2.6.18-gentoo-r6 i686 Intel(R) Core(TM)2 CPU          6300  @ 1.86GHz

Gentoo Base System version 1.12.6

Last Sync: Fri, 29 Dec 2006 14:00:01 +0000

distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]

app-admin/eselect-compiler: [Not Present]

dev-java/java-config: 1.2.11

dev-lang/python:     2.3.4, 2.4.3-r4

dev-python/pycrypto: 2.0.1-r5

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.60

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2

sys-devel/binutils:  2.16.1-r3

sys-devel/gcc-config: 1.3.14

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.17-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i686-pc-linux-gnu"

CFLAGS="-O2 -march=pentium-m -msse3 -fomit-frame-pointer"

CHOST="i686-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"

CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"

CXXFLAGS="-O2 -march=pentium-m -msse3 -fomit-frame-pointer"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig ccache distcc distlocks metadata-transfer parallel-fetch sandbox sfperms strict"

GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/"

LINGUAS="it"

MAKEOPTS="-j5"

PKGDIR="/usr/portage/packages"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

PORTDIR_OVERLAY="/usr/local/portage"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

USE="x86 X acpi alsa_cards_ali5451 alsa_cards_als4000 alsa_cards_atiixp alsa_cards_atiixp-modem alsa_cards_bt87x alsa_cards_ca0106 alsa_cards_cmipci alsa_cards_emu10k1x alsa_cards_ens1370 alsa_cards_ens1371 alsa_cards_es1938 alsa_cards_es1968 alsa_cards_fm801 alsa_cards_hda-intel alsa_cards_intel8x0 alsa_cards_intel8x0m alsa_cards_maestro3 alsa_cards_trident alsa_cards_usb-audio alsa_cards_via82xx alsa_cards_via82xx-modem alsa_cards_ymfpci alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol avi berkdb bitmap-fonts bzlib cdinstall cdparanoia chroot cli cracklib crypt cups divx4linux dlloader dri dvd elibc_glibc encode fortran gdbm gif gpm iconv imagemagick imlib2 input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kernel_linux libg++ linguas_it mad mpeg ncurses nls nptl nptlonly oss pam pcre perl png ppds pppd python qt quicktime readline reflection samba sdl session smp spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU utf8 video_cards_fbdev video_cards_mga video_cards_nv video_cards_nvidia video_cards_vesa xorg xvid zlib"

Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS

```

lspci

```

0000:00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0308

0000:00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1308

0000:00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2308

0000:00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3208

0000:00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4308

0000:00:00.5 PIC: VIA Technologies, Inc.: Unknown device 5308

0000:00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7308

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge

0000:00:02.0 PCI bridge: VIA Technologies, Inc.: Unknown device a208

0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

0000:00:0a.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0680 Ultra ATA-133 Host Controller (rev 01)

0000:00:0c.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0680 Ultra ATA-133 Host Controller (rev 02)

0000:00:0f.0 IDE interface: VIA Technologies, Inc.: Unknown device 0591 (rev 80)

0000:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07)

0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

0000:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)

0000:00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3337

0000:00:11.7 Host bridge: VIA Technologies, Inc.: Unknown device 287e

0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 7c)

0000:00:13.0 Host bridge: VIA Technologies, Inc.: Unknown device 337b

0000:01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85)

```

Il sistema e' appena stato ricompilato visto che prima girava su un northwood ed era un po' che non aggiornavo... messo gcc nuovo, kernel nuovo... Gli slot pci sn gia' apposto perche' ho cambiato scheda, cambiato slot, e sugli altri 2 ho 2 controller eide che funzionano benissimo. Test della ram ok, non un errore lasciandolo girare x una notte. Gia' provato a limitare l'acpi al boot con il parametro pci=noacpi e successivamente proprio levandolo dal kernel in fase di compilazione... nada de nada, nemmeno rimettendo un kernel 2.6.9 (il piu' vecchio che ho in giro)

Help   :Crying or Very sad: 

----------

## flocchini

uppettino uppettonzolo... nessuno ha idee? Cambiando modulo (ho messo su un'altra pro100 x scrupolo) e usando e100 e non eepro100 la rete cade x un secondo e torna subito su senza bisogno di intervento mio, pero' non va bene lo stesso

----------

## gutter

Una domanda: questa scheda a cosa è collegata?

----------

## flocchini

ad una cpv fastweb perfettamente funzionante su tutte le porte (gia' fatti stress test con un altro pc, la colpa non e' sua ne' del dhcp visto che ho anche forzato l'ip statico)

Insomma, il probl sta nel server incriminato per forza, difficilmente nell'hardware e molto probabilmente in qualche configurazione astrusa relativa alla rete.

Grazie per l'interessamento   :Wink: 

----------

## gutter

Potresti postare il risultato di:

```
# mii-tool -v eth1
```

 :Question: 

----------

## IlGab

```
eth1: link up, 10Mbps, half-duplex, lpa 0x0000
```

Provato a fissare la velocità a 100 Full-duplex sia sulla scheda di rete sia sull'apparato a cui è collegata ?

----------

## Trifaux666

 *IlGab wrote:*   

> 
> 
> ```
> eth1: link up, 10Mbps, half-duplex, lpa 0x0000
> ```
> ...

 

non e' possibile, le cpv fastweb non sono configurabili :/

[OT] flocchini, quanto tempo!!!  :Very Happy:  [/OT]

----------

## flocchini

 *gutter wrote:*   

> Potresti postare il risultato di:
> 
> ```
> # mii-tool -v eth1
> ```
> ...

 

ecco qua 

```
cube ~ # mii-tool -v eth1

eth1: no autonegotiation, 10baseT-HD, link ok

  product info: Intel 82555 rev 4

  basic mode:   autonegotiation enabled

  basic status: autonegotiation complete, link ok

  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

  link partner: 10baseT-HD

```

la centralina fw come dice trifa (quanto tempo davvero!  :Wink:  ) non e' configurabile, 10mbit half duplex e basta

----------

## gutter

Prova a lanciare:

```
# mii-tools --force 10baseT-HD eth1
```

Po lancia un:

```
# mii-tool -w eth1
```

vatti a fare una passeggiata  :Wink:  e se quando torni non funziona ancora, posta i log dell'ultimo comando.

----------

## flocchini

 *gutter wrote:*   

> Prova a lanciare:
> 
> ```
> # mii-tools --force 10baseT-HD eth1
> ```
> ...

 

ehehe arrivi tardi... gia' fatto, infatti l'autonegotiation e' gia' off (vedi sopra)   :Rolling Eyes: 

 *gutter wrote:*   

> 
> 
> Po lancia un:
> 
> ```
> ...

 

questo invece mi era sfuggito... Vediamo domattina, stanotte dovrebbe esserci traffico... Alla prossima puntata   :Laughing:   (per la serie ridiamo per non piangere :p )

----------

## flocchini

eccoci...

```
cube boot # mii-tool -w eth1

02:19:39 eth1: no autonegotiation, 10baseT-HD, link ok

04:01:52 eth1: no autonegotiation, 10baseT-HD, link ok

04:01:52 eth1: no autonegotiation, 10baseT-HD, link ok

04:01:52 eth1: no autonegotiation, 10baseT-HD, link ok

```

per disperazione butto su il 2.6.19-r2 e vediamo se cambia qsa... Nessuno mi leva dalla testa che sia una errata gestione degli irq per la nuova mobo...

----------

## flocchini

uppo per dire che con il 2.6.19-r2 sembra tutto misteriosamente risolto: stessa config (make oldconfig rulez) e un reboot e tutto fila liscio, ormai da giorni. Quando ho un po' di tempo spulcio il changelog ma dubito di riuscire a capire effettivamente cosa sia successo, torno a sostenere la tesi degli irg mal gestiti sul chipset pt880pro evidentemente sistemati nella nuova relase

Mi irrita pero' non sapere cosa diavolo fosse...

----------

## .:chrome:.

con il 2.6.19 molti driver hanno cambiato struttura, soprattutto quelli di alcune schede di rete e... attenzione, attenzione... del bus PCI.

io mi azzarderei a pensare che sia un problema di interrupt gestiti in modo errato, e detto tra noi non è nemmeno un'ipotesi da scartare a priori: schede madri AsRock e schede di rete Realtek non sono certamente il meglio che ci sia in giro

----------

## flocchini

lo scherzo lo faceva con una pro100 intel... la realtek e' stata una soluzione transitoria (la asrock purtroppo no...). Cmq come gia' detto anche io immaginavo un problema di interrupt mal gestiti, se dici che hanno toccato parecchio e' facile che abbiano anche sistemato il mio problema  :Wink: 

----------

## .:chrome:.

 *flocchini wrote:*   

> lo scherzo lo faceva con una pro100 intel... la realtek e' stata una soluzione transitoria (la asrock purtroppo no...). Cmq come gia' detto anche io immaginavo un problema di interrupt mal gestiti, se dici che hanno toccato parecchio e' facile che abbiano anche sistemato il mio problema 

 

in realtà non è che siano stati a lavorare proprio su quello, ma ho visto molti cambiamenti in sottosistemistrettamente correlati. questo potrebbe giustificare eccome un cambio di comportamento a livello del bus PCI. non è ovviamente una certezza, è solo una mia supposizione, però non è nemmeno del tutto infondata... credo...

----------

