Scheda di rete

[efewfew]

Ciao, ho un problema con debian squeeze: ho aggiunto una vecchia scheda di rete ma non riesco a farla funzionare; è di una marca conosciuta ed è talmente vecchia che mi sembra strano non venga riconosciuta correttamente!
comunque se faccio lspci mi viene
04:04.0 Non-VGA unclassified device: Relatek Semiconductor Co.,Ltd. RTL8139C/8139C+ (rev 10)
e ovviamente se faccio ifconfig non mi appare, vedo solo quella integrata e la loopback

Credo sia perchè non la riconosce come ethernet controller, a differenza di quella intagrata. come faccio a farla funzionare?

[sacarde]

prova a caricare il driver:

modprobe 8139cp

description: RealTek RTL-8139C+ series 10/100 PCI Ethernet driver

[Gimli[2BV!2B]]

Ho una 8139 liscia:00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: U.S. Robotics USR997900A
Kernel driver in use: 8139tooCome suggerito da sacarde il driver (sperimentale) adatto alla tua scheda potrebbe essere l'8139cp (l'output un po' particolare di lspci sembrerebbe effettivamente indicare una revisione >= C).

Potrebbe necessitare di un firmware binario per funzionare.
Assicurati di avere installato questo pacchetto: firmware-realtek (http://packages.debian.org/squeeze/firmware-realtek) - Binary firmware for Realtek wired and wireless network adapters

Per avere più informazioni su cosa ne pensa il sistema aggiorna il database degli ID PCI (da root):
update-pciids
Dopodiché posta il risultato di questo comando:lspci -vks 00:08.0

[efewfew]

grazie 1000 Gimli per la disponibilità ad analizzare i miei log, li avevo copiati in un file di testo la settimana successiva per postarli, anche se in super ritardo, poi non ho più avuto tempo di seguire questa cosa che però mi ero tenuto da parte per cocciutaggine quando oggi ho scoperto che la scheda non veniva riconosciuta come dispositivo di rete perchè aveva la flash andata!

[Gimli[2BV!2B]]

Ah, ok, a posto così (per così dire)...

Flash andata dici? Poi si tratta di una Realtek... Ho vari dejavu. (http://www.hwupgrade.it/forum/showthread.php?t=2319888)
Varie Realtek fanno scherzetti simili a quello che dici, ma, ad oggi, le ho sempre viste risvegliarsi e tornare a funzionare perfettamente per anni.

[efewfew]

ho scritto perchè ieri stavo parlando con un un altro tecnico esterno in ufficio e fatalità è capitata fuori la questione della scheda; guardandola si è accorto che questa vecchia scheda aveva un chip montato sullo zoccolo il quale è saldato sulla scheda. mi faceva notare che il chip non aveva più un'etichetta che serviva a coprire un vetrino, il quale serviva per flasharlo. questo perchè in passato i chip costavano di più e venivano usati anche per altre schede, ora ognuna ne ha uno direttamente saldato. il fatto che non ci fosse più l'etichetta fa pensare al fatto che o è stata riflashata (senza successo) oppure la luce ha danneggiato la flash, e da qui il fatto strano che udev non riconosce nemmeno la tipologia di scheda...

[efewfew]

ritiro su questo vecchio post perchè quella scheda ha continuato a vagare e mi dicono che una centos l'ha vista correttamente e traffica :)

quindi per questione di principio ho preso una squeeze e ci ho collegato la scheda in questione che ovviamnte non viene riconosciuta. mi permetto di postare lo spezzone di output di lspci sperando che l'offerta sia ancora valida :D

lspci -vv
..
04:03.0 Non-VGA unclassified device: Realtek Semiconductor Co., Ltd. Device 812b (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. Device 8129
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+ INTx-
Latency: 0 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at <unassigned> [disabled]
..

lspci -vks 04:03.0
04:03.0 Non-VGA unclassified device: Realtek Semiconductor Co., Ltd. Device 812b (rev 10) (prog-if 20)
!!! Unknown header type 52

[Gimli[2BV!2B]]

Mah, non ho trovato traccia di alcuna

PCI\VEN_10EC&DEV_812B&SUBSYS_812911EC&REV_10

o, più semplicemente

PCI\VEN_10EC&DEV_812B

Mentre, naturalmente, esiste

PCI\VEN_10EC&DEV_8129&SUBSYS_812911EC&REV_10

La differenza tra 8129 ed 812B è un misero bit... 1001 -> 1011
Secondo me ha davvero qualcosina di storto, magari proprio solo l'identificativo (per colpa di un leggendario raggio gamma (http://en.wikipedia.org/wiki/Soft_error#Cosmic_rays_creating_energetic_neutrons_and_protons), o il vetrino a vista), oppure lo slot PCI di quella scheda madre, o magari il BIOS o la luna in capricorno...

Ipotizzando l'ID 8129 dovrebbe essere una 8129 classica, il cui supporto dovrebbe essere garantito (esempio da un kernel Sid, ma dovrebbe essere poco diverso in uno meno recente, stando ai miei ricordi):gimli@kwankey:~$ cat /boot/config-3.0.0-2-686-pae | grep 8139TOO_
CONFIG_8139TOO_PIO=y
CONFIG_8139TOO_TUNE_TWISTER=y
CONFIG_8139TOO_8129=y

Hai potuto controllare che Risponde Centos agli stessi comandi? Se riporta un codice identificativo di cui si trova traccia penserei ad un brutto rapporto della scheda con l'altro pc, salvo strambo baco software che cambia giusto un bit nell'id o, viceversa, un kernel Centos in cui han registrato il nuovo id perché han trovato un cliente/utente con una scheda come la tua.

P.S. dal mio linux-3.1-ck1/drivers/net/8139too.c
static DEFINE_PCI_DEVICE_TABLE(rtl8139_pci_tbl) = {
{0x10ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x10ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1113, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1500, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x4033, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1186, 0x1300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1186, 0x1340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x13d1, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1259, 0xa117, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1259, 0xa11e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x14ea, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x14ea, 0xab07, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x11db, 0x1234, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1432, 0x9130, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x02ac, 0x1012, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x018a, 0x0106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x126c, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1743, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x021b, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },

#ifdef CONFIG_SH_SECUREEDGE5410
/* Bogus 8139 silicon reports 8129 without external PROM :-( */
{0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
#endif
#ifdef CONFIG_8139TOO_8129
{0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8129 },
#endif

/* some crazy cards report invalid vendor ids like
* 0x0001 here. The other ids are valid and constant,
* so we simply don't match on the main vendor id.
*/
{PCI_ANY_ID, 0x8139, 0x10ec, 0x8139, 0, 0, RTL8139 },
{PCI_ANY_ID, 0x8139, 0x1186, 0x1300, 0, 0, RTL8139 },
{PCI_ANY_ID, 0x8139, 0x13d1, 0xab06, 0, 0, RTL8139 },

{0,}
};

[efewfew]

gimli sei una macchina da guerra!
non ho l'output della centos che non era mia, l'avevo data come non funzionante poi me l'hanno riportata dicendomi che l'avevano usata con successo... ma in una situazione come questa, è possibile forzare l'id della scheda a mano (tipo come si fà con i mac-address) e farla riconoscere oppure forzare l'uso di determinato driver (se si chiamano così anche in linux)

[Gimli[2BV!2B]]

Non saprei come forzare l'ID nella scheda...

Per forzare l'uso del driver dovrebbe bastare una ricompilazione del kernel (http://guide.debianizzati.org/index.php/Debian_Kernel_Howto), previa piccola aggiunta al file che ho citatostatic DEFINE_PCI_DEVICE_TABLE(rtl8139_pci_tbl) = {
{0x10ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x10ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1113, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1500, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x4033, 0x1360, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1186, 0x1300, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1186, 0x1340, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x13d1, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1259, 0xa117, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1259, 0xa11e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x14ea, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x14ea, 0xab07, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x11db, 0x1234, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1432, 0x9130, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x02ac, 0x1012, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x018a, 0x0106, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x126c, 0x1211, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x1743, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x021b, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },

#ifdef CONFIG_SH_SECUREEDGE5410
/* Bogus 8139 silicon reports 8129 without external PROM :-( */
{0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
#endif
#ifdef CONFIG_8139TOO_8129
{0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8129 },
{0x10ec, 0x812b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8129 },
#endif

/* some crazy cards report invalid vendor ids like
* 0x0001 here. The other ids are valid and constant,
* so we simply don't match on the main vendor id.
*/
{PCI_ANY_ID, 0x8139, 0x10ec, 0x8139, 0, 0, RTL8139 },
{PCI_ANY_ID, 0x8139, 0x1186, 0x1300, 0, 0, RTL8139 },
{PCI_ANY_ID, 0x8139, 0x13d1, 0xab06, 0, 0, RTL8139 },

{0,}
};