Topic: Kernel panic dopo aggiornamento

[Fumetto]

La prima volta ok... posso capire... la seconda no... devo comprendere!!!

Questa è la seconda volta che lo SME si incacchia dopo un aggiornamento, ho anche una teoria al riguado ma andiamo con ordine...
Appena aggiorno da console con la tripletta

Code: [Select]

yum update
signal-event post-upgrade
signal-event reboottutto funge... ma è la seconda volta che dopo un tempo "x" lo sme se ne va in kernel panic...
dai log vedo che

Code: [Select]

Oct  6 19:59:16 server1 kernel: icmp v4 hw csum failure
Oct  6 20:00:01 server1 su(pam_unix)[6061]: session opened for user qmailr by (uid=0)
Oct  6 20:00:01 server1 su(pam_unix)[6061]: session closed for user qmailr
Oct  6 20:01:31 server1 kernel: icmp v4 hw csum failure
Oct  6 20:15:01 server1 su(pam_unix)[6200]: session opened for user qmailr by (uid=0)
Oct  6 20:15:01 server1 su(pam_unix)[6200]: session closed for user qmailr
Oct  6 20:16:23 server1 kernel: icmp v4 hw csum failure
Oct  6 20:20:49 server1 kernel: icmp v4 hw csum failure
Oct  6 20:27:44 server1 kernel: NETDEV WATCHDOG: eth1: transmit timed out
Oct  6 20:27:44 server1 kernel: sky2 eth1: tx timeout
Oct  6 20:27:44 server1 kernel: sky2 eth1: transmit ring 176 .. 135 report=176 done=176
Oct  6 20:27:44 server1 kernel: sky2 hardware hung? flushing
Oct  6 20:30:01 server1 su(pam_unix)[6341]: session opened for user qmailr by (uid=0)
Oct  6 20:30:01 server1 su(pam_unix)[6341]: session closed for user qmailre alle 20:30 circa si è imballato tutto, la volta scorsa se ne è andata down la eth1 (lato internet) ma da console si riusciva ancora a lavorare e la eth0 (lato lan) funzionava perfettamente, stavolta alle 8:30 di mattina la bella notizia...


Ora un po di dati... la eth1 è costituita da una scheda 10/100/1000 montata su slot PCI-E

Code: [Select]

[root@server1 ~]# ethtool -i eth1
driver: sky2
version: 1.6
firmware-version: N/A
bus-info: 0000:01:00.0
[root@server1 ~]# lspci -v
...omiss...
01:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller (rev 20)
        Subsystem: SysKonnect: Unknown device 4340
        Flags: bus master, fast devsel, latency 0, IRQ 201
        Memory at ec100000 (64-bit, non-prefetchable) [size=16K]
        I/O ports at 2000 [size=256]
        Capabilities: [48] Power Management version 2
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable+
        Capabilities: [e0] Express Legacy Endpoint IRQ 0
        Capabilities: [100] Advanced Error Reporting
...omiss...
Da quello che ho capito il problema potrebbe essere dovuto a un bug del kernel (vedi qui) ma non ho trovato soluzioni ( o non le ho ben comprese io).
Se cambio scheda (non della Marvell) pensate che posso risolvere? E' un problema di quell'hardware oppure del driver che carica quella scheda da slot PCI-E e quindi anche cambiando scheda non risolvo un piffero?

Idee? Suggerimenti?

Grazie! 

[Stefano]

sarò sintetico:
- check della ram, estensivo ed intensivo
- cambia scheda

in bocca al lupo
Stefano

[Fumetto]

in bocca al lupo

Ne ho bisogno... è il server aziendale... il famoso HP di qualche tempo fa...
Adesso provo a cambiare scheda, la ram la escludo in quanto testata per circa 18 ore prima di metterlo in produzione...
Non mi spiego perchè lo fa solo dopo gli aggiornamenti... 

[Stefano]

guarda sul sito HP.. se è certificato per redhat 4.x allora troverai info

Ciao

Stefano

[Incognito]

Dando un'occhiata in giro sembra un problema del modulo sky2, ma è una cosa abbastanza vecchia, possibile che sia ancora così? (è una domanda retorica )

prova a disabilitare l'autonegoziazione:
#ethtool -A ethX autoneg off rx on tx on

Sicuramente perdi in velocità ma se non succede più nulla alla scheda è di sicuro quello.