Newsgroup: it.comp.os.linux.sys
Titolo: Problema di rete

Salve a tutti,
ho un problema con la scheda di rete.
Allora prima espongo il discorso da un punto di vista operativo.
Ho due macchina una e' un portatile, l'altro e' un desktop.
Il portatile ha una scheda di rete rilevata ed apparentemente 
funzionante, il desktop ha una scheda di rete 
eth0: RealTek RTL8139 Fast Ethernet at 0xcc00, IRQ 10, 00:e0:4c:59:04:14.
eth0: Chip is 'RTL-8139C' - MAC address '00:e0:4c:59:04:14'.
ok, dunque quando faccio un ping dal desktop/server alla portatile/client 
(entrambi linux) il led fisico sulla scheda non lampeggia, 
cosa che invece accade se faccio un ping dal client al desktop.
Da questo ne deduco che i pacchetti passono in uscita sul cavo dal
server, quindi in pratica quando pingo dal client i pacchetti
arrivano alla scheda di rete del server ma dato che il server non puo'
rispondere non arriva nessun replay indietro.
Infatti quando faccio un ping dal server e poi do ifconfig vedo che
tx e' a 0 mentre errors cresce.
eth0      Link encap:Ethernet  HWaddr 00:E0:4C:59:04:14  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:10121 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          Interrupt:10 Base address:0xcc00 
route -n 
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
l'ifconfig del portatile e normale coi suo bel mac il suo bell'indirizzo ip
nessun errore e suoi bei TX incrementati per i ping.
non mi soffermo sui settaggi perche' sono quasi certo di aver fatto corre
ttamente.
tra l'altro ho provato svariate volte con settaggi diversi
Gli errore che ho sul messages sono diversi
a secondo del modulo provato.
ho provato il modulo rtl8139.o  8139too.o realtek_cb.o
il primo e' l'originale del kernel (ho provato sia le versione 2.2.19
che la versione 2.4.4 ovviamente con i moduli relativi)
il secondo e l'originale solo che vengono aggiunti dei bugfix il terzo
e' un altro modulo che stava sull'homepage dell'autore dei due moduli originali.
con rtl8139.o:
eth0: RealTek RTL8139 Fast Ethernet at 0xcc00, IRQ 10, 00:e0:4c:59:04:14.
eth0:  Tx descriptor 0 is 0008003c. (queue head)
eth0:  Tx descriptor 1 is 0008003c.
eth0:  Tx descriptor 2 is 0008003c.
eth0:  Tx descriptor 3 is 0008003c.
eth0: MII #32 registers are: 1100 782d 0000 0000 01e1 45e1 0001 0000.
eth0:  Tx descriptor 0 is 0008003c. (queue head)
eth0:  Tx descriptor 1 is 0008003c.
eth0:  Tx descriptor 2 is 0008003c.
con 8139too.o (tra l'altro se non erro questo supporta anche
la versione del chip della mia scheda cioe' la rtl8139C
eth0: Setting 100Mbps full-duplex based o
n auto-negotiated partner ability 45e1.
kernel: eth0: Tx queue start entry 4  dirty entry
 0.
 eth0:  Tx descriptor 0 is 00002000. (queu
  e head)
  eth0:  Tx descriptor 1 is 00002000.
  eth0:  Tx descriptor 2 is 00002000.
  eth0:  Tx descriptor 3 is 00002000.
  eth0: Setting 100Mbps full-duplex based o
   n auto-negotiated partner ability 45e1.
provando con windows dal portatile il messages del server 
cioe' sempre lo stesso messages di sopra:
eth0: Abnormal interrupt, status 00000040.
 eth0: Abnormal interrupt, status 00000040.
  eth0: Abnormal interrupt, status 00000040.
   eth0: Abnormal interrupt, status 00000040.
comunque sia ho sempre lo stesso errore con qualunque modulo..
il cavo non e' rotto, all'inizio era incrociato poi l'ho cambiato per
sicurezza ed ho messso hub+due cavi dritti
ah un ultima cosa, a seconda del modulo ho errori diversi non nel
messages ma nell ifconfig usando infatti quello che dovrrebbe essere
il suo driver originale 8139too.o per il suo chip
ho un ifconfig del genere
eth0      Link encap:Ethernet  HWaddr 00:E0:4C:59:04:14  
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:8 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          Interrupt:10 Base address:0xb400 
come vedete i pacchetti sono stati droppati...
ho provata anceh a cambiare slot pci, purtroppo non ho windows
ne installato ne in cd e non posso provare la scheda sotto di lui.
vi allego anche l'output di un programma di diagnostica aposta
per la mia scheda.. io non ci capisco nulla ma magari qualcuno si:
rtl8139-diag.c:v2.03 5/15/2001 Donald Becker (
bec...@scyld.com
)
 
http://www.scyld.com/diag/index.html
 Index #1: Found a RealTek RTL8139 adapter at 0xb400.
 RealTek chip registers at 0xb400
  0x000: 594ce000 00001404 80000000 00000000 0008003c 0008003c 0008003c 0008003c
0x020: 00018000 00018600 00018c00 00019200 005e0000 
0d000000 0000fff0 0000c07f (fanculo questa riga l'ho dovuta spezzare)
  0x040: 74000600 0000d68e 7e764da2 00000000 00ad10c7 00000000 0001c118 00100000
0x060: 10000000 01e1782d 00000000 00000000 00000005 000f77c0 
b0f243b9 7a36d743. (anche questa diocane)
  No interrupt sources are pending.
  The chip configuration is 0x10 0xad, MII half-duplex mode.
  EEPROM size test returned 6, 0x204a4 / 0x2.
  Parsing the EEPROM of a RealTek chip:
  PCI IDs -- Vendor 0x10ec, Device 0x8139, Subsystem 0x10ec.
  PCI timer settings -- minimum grant 32, maximum latency 64.
  Station Address 00:E0:4C:59:04:14.
  Configuration register 0/1 -- 0x8d / 0xc2.
  EEPROM active region checksum is 095c.
  EEPROM contents:
  8129 10ec 8139 10ec 8139 4020 e112 e000
  594c 1404 8d10 f7c2 8801 43b9 b0f2 071a
  df43 8a36 df43 8a36 43b9 b0f2 1111 1111
  0000 0000 0000 0000 0000 0000 0000 2000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000
  The word-wide EEPROM checksum is 0x264c.
  Would write new Default Media entry 0x0000 to offset 6, 
  the current value is 0xe112.
   The RTL8139 does not use a MII transceiver.
   It does have internal MII-compatible registers:
   Basic mode control register   0x782d.
   Basic mode status register    0x1000.
Autonegotiation Advertisement 0x01e1.
   Link Partner Ability register 0x0000.
   Autonegotiation expansion     0x0000.
   Disconnects                   0x0000.
   False carrier sense counter   0x0000.
   NWay test register            0x0005.
   Receive frame error count     0x0000.
   MII PHY #-1 transceiver registers:
   0000 0000 0000 0000 0000 0000 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000
   0000 0000 0000 0000 0000 0000 0000 0000.
  Basic mode control register 0x0000: Auto-negotiation disabled!
    Speed fixed at 10 mbps, half-duplex.
     Basic mode status register 0x0000 ... 0000.
    Link status: not established.
 Capable of <Warning! No media capabilities>.
    Unable to perform Auto-negotiation, negotiation not complete.
    This transceiver has no vendor identification.
    I'm advertising 0000:
   Advertising no additional info pages.
     Using an unknown (non 802.3) encapsulation.
    Link partner capability is 0000:.
   Negotiation did not complete.

e' un altro modulo che stava sull'homepage dell'autore dei due moduli originali.
realtek_cb non l'ho mai visto, ne' provato.
Ora sto usando 8139too (2.2.19) <-> 8139too (2.4.5)
ovviamente conosci gia' 
http://www.sourceforge.net/projects/gkernel
vado a memoria, ma potrei sbagliare, l'homepage di 8139too
Hai notato anche tu che l'ultima versione si compila solo con egcs sul
2.4.4 (non ho provato col 2.4.5)?

    eth0: Abnormal interrupt, status 00000040.
Non è che hai conflitti di irq ?

Non è che hai conflitti di irq ?
Vuoi che ti dica la verita'? non lo so!
Anzi se ce' una cosa che me' sempre rimasta oscura sono
proprio gli irq...
io so che quella scheda stava su irc 10 ...
comunque pensandoci bene non credo... il problema l'ho risolto
quanto meno aggirato... cambiato scheda e tutto funziona
c'ho messo 7 minuti a tirare su la rete a fronte di 7 giorni
con quella precedente (senza riuscirci).
Tuttavia questa cosa degli irq la devo sapere, se me la puoi
chiarire ti ringrazio.. perche' ora ho un altro problema che potrebbe
avere a che fare con questo genere di cose.
Quindi, prima cosa, da cosa si vedere se uno ha dei conflitti di irq ?
ed una volta accertato come faccio ad eliminarli ?
grazie 


beh guarda come ho scritto sull'altro messaggio mi sono talmente
in cazzato che ho cambiato scheda ed ho risolto tutto,
ho preso una 3com ed ho fatto proprio bene perche' ho risolto tutto
anche se prima o poi quella scheda la dovro' usare su un altro pc
che ho in cantina.... comunque il multicasting non era attivato nel kernel
.. tra l'altro ora devo risolvere un altro problema con ata100
spero di finire di risolvere i problema prima della fine dell'estate..
cazz voglio andare al mare!!!

 cazz voglio andare al mare!!!
Non postare alle 5 di mattina, TI FA MALE!! ;-))))
eheheh
Ciao, `matte.
-- 
err: signature too big

 ed una volta accertato come faccio ad eliminarli ?
IRQ == Interrupt ReQuest
Le cpu x86 gestiscono 16 IRQ; quando una periferica lancia un IRQ il 
processore interrompe quello che stava facendo e esegue una "subroutine" 
che si occupa di dare retta a chi ha sollevato l'irq.
Esempio classico l'hd: quando il dato è pronto lancia un irq ( quello 
dell'ide ) ed il processore se lo va a prendere.
Gli irq sono una risorsa preziosa; anche perchè parecchi sono gia 
utilizzati:
[ghigo@therra suse]$ cat /proc/interrupts
           CPU0
  0:    1006292          XT-PIC  timer
  1:      29589          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  bttv
  9:          0          XT-PIC  Trident 4DWave PCI
 10:     117131          XT-PIC  usb-uhci, usb-uhci
 11:      59277          XT-PIC  eth0, VIA 82C686A
 14:      70634          XT-PIC  ide0
 15:       1677          XT-PIC  ide1
Tieni presente che gli irq-3 e irq4 sono "utilizzato" dalle seriali. il 7 
delle "moderne" parallele; il 6 dal floppy
Per cui si ha a disposizione "normalmente" irq 2 ( che è collegato al 9 tra 
l'altro ), irq5, 10, 12 ( gli altri che mancano all'appello (8/13) ) non me 
li ricordo ).
Le periferiche isa possono essere settate su diversi irq riconfigurandole; 
generalmente non gradiscono di lavorare con irq condivisi.
Le periferiche PCI non hanno la possibilità di variare IRQ ( l'irq "scelto" 
dipende dalla slot in cui è inserito );  però è prevista la condivisione di 
IRQ ( con una leggera diminuizione delle prestazioni )., ma anche il driver 
deve essere daccordo.
Tieni presente che una periferica può non usare l'irq lasciandolo 
praticamente libero ( molti modem isa condividevano l'irq di una seriale, 
rendendo impossibile l'uso di modem e seriale contemporaneamente, ma 
alternativamente si ).
Per cui nel tuo caso la sk di rete forse condivideva l'irq 10 con un'altra 
periferica; quando quest'ultima lanciava un interrupt rispondeva l'handler 
della sk di rete che non ci capiva + nulla ....
Normalmente è il driver che dopo aver interrogato la scheda chiedendo al SO 
l'uso dell'irq si rende conto del conflitto. 
Morale: gli IRQ sono pochi e normalmente per le periferiche ISA non devono 
essere condivisi, mentre per le PCI è meglio che NON siano condivisi.
Un po' di tutto alloca IRQ; Con cat /prc/interrupt vedi gli irq che i 
driver hanno allocato ( non tutti quelli potenzialmente occupabili xchè 
alcuni driver non sono  stati ancora caricati .... )

err: signature too big
hihihi vedi poi non sai neanche settare la signature ;-)))
COGLIONEE! hahahhaha 

 COGLIONEE! hahahhaha 
Addio lamer, *plonk*.
Ciao, `matte.
