Hardware Reset error in syslog

[Steve Ferrara]

Can anyone explain to me what is happening here? Do I have a bad cable possibly or is this a switch issue? Possible switch reboot?
Here's the syslog....I have no problems with the server presently. Just want to know if I have a potential problem at hand....thanks

vmunix: btlan4: WARNING: Command Timed Out at 8/8/1/0....
vmunix: btlan4: NOTE: Reset Driver at 8/8/1/0....
vmunix: btlan4: Hardware Reset Started on 8/8/1/0....This will take approximately 11 seconds
cmcld: lan3 failed
cmcld: lan3 switched to lan2
cmcld: Local switch has occurred since net_id 0x1 was not found on subnet 43.126.8.0.
syslog: su : + tty?? root-eplntsd
vmunix: btlan4: NOTE - Forcing speed and duplex to Connection Type 100BaseTX Full Duplex at 8/8/1/0
vmunix: btlan4: NOTE: 100Base-TX Full-Duplex started at 8/8/1/0....
cmcld: lan3 recovered
cmcld: lan2 switched to lan3

[Steven E. Protter]

Shalom Steve,

Looks like someone ran

lanadminx -X 0 100FD

The purpose of the command was to force the network card to run at full duplex 100 BaseT speed.

This can be forced at boot in the /etc/rc.config.d/hpbtlanconf

file.

SEP

[Devender Khatana]

Hi,

This seems to be a network adapter failure only as the hardware reset is initiated by the kernel.

The switchover was only because of card reset.
I do not even suspect switch for this as during many switch reset the hardware reset message do not appear.

Or could be a different speed setting at switch port and adapter.

HTH,
Devender

[Andy Torres]

Assuming the syslog entries here are listed chronologically, it appears this is what happened:

1) Some sort of interruption or failure of the lan3 device. Kinda looks like a manual reset of the lan3 device (lanadmin reset).
2) ServiceGuard kicked in and switched to lan2.
3) Speed and duplex got changed to 100 FULL on lan3.
4) ServiceGuard switched back to lan3.

Almost looks like a successful test of ServiceGuard LAN failover. The only thing missing is maybe hard-setting the speed and duplex in the hpbtlanconf file.

[Steve Ferrara]

Thanks guys,

I don't know how the lanadmin command could have been run by someone. No one was on the box. I do have 100FD set at startup...

here's the /etc/rc.config.d/hpGSC100conf (i don't see a hpbtlanconf file)

HP_GSC100_INTERFACE_NAME[0]=lan1
HP_GSC100_STATION_ADDRESS[0]=
HP_GSC100_SPEED[0]=100FD

HP_GSC100_INTERFACE_NAME[1]=lan2
HP_GSC100_STATION_ADDRESS[1]=
HP_GSC100_SPEED[1]=100FD

HP_GSC100_INTERFACE_NAME[2]=lan3
HP_GSC100_STATION_ADDRESS[2]=
HP_GSC100_SPEED[2]=100FD

HP_GSC100_INTERFACE_NAME[3]=lan4
HP_GSC100_STATION_ADDRESS[3]=
HP_GSC100_SPEED[3]=100FD

[Steven E. Protter]

Sorry,

Whenever I say someone, one must also assume a script was run.

Since you don't seem to know anything about it, I'll assume it was a startup script.

It will be around somewhere though.

After system boot:

lanadmin -x 0

Last item there is zero.

Change that to 1 if your primary lan card is lan1

lanscan

to see that.

SEP

[Andy Torres · Accepted solution]

Something caused that device to freak out. If you're the only root user that could have initiated a reset and you didn't do it, you might suspect a device failure or a network interruption, human or otherwise.

I tell the bosses that sun spots wreak havok on networks. :-)

If this is an isolated incident I might just make note of the incident, notify the network guys of the disruption, and trust ServiceGuard to take care of things as long as this connection isn't going to cause your backup program to expand your backup window with restarts. If it happens again, either your network guys are messing with you or you have a card going bad. If you have hardware coverage on the NIC, I'd have it replaced during the next available maintenance window, just for good measure.

[Steve Ferrara]

Thanks guys, I'm very satisfied with your answers.