HP DL380G4, RHEL3-U5 network connection loss

[Rene Kapeller]

ProLiant DL380 G4
ROM V. 10/10/2005, Family 386P51, Type 03
NIC FW: 1.2.3-1
bcm5700 V. 8.3.14a

/etc/modules.conf:
alias eth0 bcm5700
alias eth1 bcm5700
alias eth2 e1000
alias eth3 e1000

History:
The DL380 was originally running with the tg3 driver on eth0 and eth1. Once every few days, the system reported a network loss on eth0 (eth1 is heartbeat) with the following error log: 'NETDEV WATCHDOG: eth0: transmit timed out'
I then replaced the tg3 driver with the broadcom driver.
The 'NETDEV' errors are now gone (and no other logs report a NIC down), but the system still loses network at the same frequency.

Current status:
Just upgraded the BIOS-ROM and the NIC fw (see on top) two hours ago.

Question:
Anyone out there experiencing the same problem?

Note: It's a production server, thus testing is not easy.

[Vipulinux]

Hi Rene

I had faced the similar issues with DL380 but lickily my NIC and Server is now stable after using the RHEL3 update 3 CD.

It should be stable with update 5 as well.
Do you still get the same error?

Regards
Vipul

[Alan_152]

did you try replacing the native driver with the HP recommended one?

http://h18000.www1.hp.com/support/files/server/us/locate/101_5561.html

[Ivan Ferreira]

Once I had this problem:

"NETDEV WATCHDOG: eth0: transmit timed out'"

And booting the kernel with the noapic option the problem was solved.

[Rene Kapeller]

Hi everyone,

1. The system is up for 2 days (which does not realy mean anything)

2. To be precise on the OS issue: I use 'Scientific Linux 3.0.5' (which is identical to 'RHEL 3 U5') and kernel-2.4.21-37.ELsmp

3. I'm currently using the latest BCM driver provided by HP (bcm5700 V. 8.3.14a)

4. I will boot with 'noapic' if it happens again

Thanks for all the replies!
Rene

[vincent kersten]

Hi Rene,
we have a a simular problem here, and
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=898761
does tell a lot on this strange behaviour.
Do you serve NFS from this machine?
Then this is probably not APIC but an extreme annoying collision between IPMI (~iLO) and broadcom.