bce driver questions

[wolffnx]

Hello,
I have a DL proliant DL360 G5 server , today the network card stop working (the system was boot fine,but no ping to server) rebooting the server was the solution, in the logs I found:

bce0: <HP NC373i Multifunction Gigabit Server Adapter (B2)> mem 0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci13
bce0: /usr/src/sys/dev/bce/if_bce.c(1281): Management firmware enabled but not running!

bce0: Using defaults for TSO: 65518/35/2048
bce0: Ethernet address: 00:1a:4b:df:3b:26
bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (1.9.6); Bufs (RX:2;TX:2;PG:8); Flags (SPLT|MSI|MFW); MFW (NOT RUNNING!)

bce0: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state = 0x00000006)

and finally:

 bce0: /usr/src/sys/dev/bce/if_bce.c(7886): Watchdog timeout occurred, resetting!
 bce0: link state changed to DOWN
 bce0: Gigabit link up!
 bce0: link state changed to UP

Any ideas???

Thanks

 

[Terry_Kennedy]

hello,i have a DL proliant dl 360 G5 server , today the network card stop working
(the system was boot fine,but no ping to server)

Is this a new(ish) install, or a system that has been running fine for some time? If the second, what changed - any FreeBSD patches applied, firmware updates, or hardware service?

bce0: <HP NC373i Multifunction Gigabit Server Adapter (B2)> mem 0xf8000000-0xf9ffffff irq 18 at device 0.0 on pci13
bce0: /usr/src/sys/dev/bce/if_bce.c(1281): Management firmware enabled but not running!

Your system apparently has a remote management feature. Since this is a HP system, it is probably an iLO. That sort of function can either use a NIC port allocated to it exclusively (normally called "dedicated") or can share a NIC port with the operating system. In the second mode, there are 2 things that want to use the NIC - the operating system and the remote management function. These can sometimes conflict with each other, particularly when using generic drivers as FreeBSD does. HP has their own drivers for Windows, etc. which have "inside information" about the other stuff going on with the NIC.

However, there's no reason for things to suddenly stop working if they were working fine previously. If this is a new install, I'd suggest having FreeBSD use the other port (Broadcom chips are often found in pairs or quads) so the remote management can have exclusive use of the first port. Alternatively, if your remote management supports it, configure it to use the dedicated port and not share one with FreeBSD.

bce0: bce_pulse(): Warning: bootcode thinks driver is absent! (bc_state = 0x00000006)

In my experience, "they all do that". It will pop up during shutdown and should be harmless.

bce0: /usr/src/sys/dev/bce/if_bce.c(7886): Watchdog timeout occurred, resetting!
bce0: link state changed to DOWN
bce0: Gigabit link up!
bce0: link state changed to UP

This is a definite problem. It could be due to a conflict with the remote management function, it could be bad hardware, or it could be a driver issue. The bce(4) code has been pretty well-behaved for a long time (the last problem I had with it was way back in FreeBSD 6.x).

 

[wolffnx]

Is this a new(ish) install, or a system that has been running fine for some time? If the second, what changed - any FreeBSD patches applied, firmware updates, or hardware service?


Is a new install, the server has the latest firmware, and the FreeBSD (11) is the default
instalation without patches, and the hardware..well..is old, the only thing i do is clean up
the fans and the motherboard in general
so, i try to disable that services in the bios(remote management,Ilo,etc) to discard
causes


However, there's no reason for things to suddenly stop working if they were working fine previously. If this is a new install, I'd suggest having FreeBSD use the other port (Broadcom chips are often found in pairs or quads) so the remote management can have exclusive use of the first port. Alternatively, if your remote management supports it, configure it to use the dedicated port and not share one with FreeBSD.

do you remember the name of the ports? i take a look

 

[Terry_Kennedy]

If one port is bce0, the next is usually bce1. Using the # ifconfig command should give you a list of what was detected on your system.

If this system was in storage not doing anything, is it possible it ended up there because it was broken?

 

[wolffnx]

If one port is bce0, the next is usually bce1. Using the # ifconfig command should give you a list of what was detected on your system.

yes,bce0 and bce1 are detected and are in use now

If this system was in storage not doing anything, is it possible it ended up there because it was broken?

mm i do not think so, i have 2 proliant dl360 g5, the two are identical, in the past were used for a proxy server, without problems (using debian)
and were taken out of production about one mont ago

 

[SirDice]

Not sure if it's going to solve the issue but it's usually a good idea to make sure the server has all the latest firmwares (BIOS, IPMI, etc).

 

[wolffnx]

Not sure if it's going to solve the issue but it's usually a good idea to make sure the server has all the latest firmwares (BIOS, IPMI, etc).

Yes, already updated the firmware of all because of this message (only happens when install FreeBSD with ZFS, not on UFS)

kernel: (da0:ciss0:0:1:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00
kernel: (da0:ciss0:0:1:0): CAM status: SCSI Status Error
kernel: (da0:ciss0:0:1:0): SCSI status: Check Condition
kernel: (da0:ciss0:0:1:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code)
kernel: (da0:ciss0:0:1:0): Error 22, Unretryable error

Later I read in some forum that this message is nothing to worry about.

 

[cwf-ml]

Well ... that's a mighty old server. 8+ years. You shouldn't use this for anything but playing around/testing. For one, if it hasn't already, your embedded SmartArray's BBWC battery will die soon, switching off the controller's write caching, which in turn gives you a good feeling how computing was like back in the day, say, 1990.

And unless you have one of these VooDoo third party hardware support contracts on these, HP will not give you the time of day on that box. It has been out of anything for some time now.

Having said that, well, it should run FreeBSD 10.3 at least. Haven't tried 11, though. As others have mentioned, it is mandatory that you let iLo use its own port - it has one, and iLo phys sharing is a tool of the devil. Doesn't work well awith FreeBSD at all.

Dont deactivate iLo, just configure it out of the way. Actually, better, configure and use it via its dedicated port. iLO (with the advanced license) is an utterly nifty tool, and even without it's moderatly useful.

If your bce trouble persists, I'd recommend scrap the thing and get a modern one. Hardware that old is usually not worth the time you put in to get it running. And trust me on that, at that age the troubles WILL keep coming, and they will add up.

Yes, I, too, would really like the industry to build server hardware that lasts 25 years, but unfortunately they just don't.

Update: with some boxes, we had success to keep them running by making the reboot once a week from crontab. There are variants of the bce chipset that occasionally go to lsleep sleep w/o ever waking up.

 

[wolffnx]

Well ... that's a mighty old server. 8+ years. You shouldn't use this for anything but playing around/testing. For one, if it hasn't already, your embedded SmartArray's BBWC battery will die soon, switching off the controller's write caching, which in turn gives you a good feeling how computing was like back in the day, say, 1990.

And unless you have one of these VooDoo third party hardware support contracts on these, HP will not give you the time of day on that box. It has been out of anything for some time now.

Having said that, well, it should run FreeBSD 10.3 at least. Haven't tried 11, though. As others have mentioned, it is mandatory that you let iLo use its own port - it has one, and iLo phys sharing is a tool of the devil. Doesn't work well awith FreeBSD at all.

Dont deactivate iLo, just configure it out of the way. Actually, better, configure and use it via its dedicated port. iLO (with the advanced license) is an utterly nifty tool, and even without it's moderatly useful.

If your bce trouble persists, I'd recommend scrap the thing and get a modern one. Hardware that old is usually not worth the time you put in to get it running. And trust me on that, at that age the troubles WILL keep coming, and they will add up.

Yes, I, too, would really like the industry to build server hardware that lasts 25 years, but unfortunately they just don't.

Update: with some boxes, we had success to keep them running by making the reboot once a week from crontab. There are variants of the bce chipset that occasionally go to lsleep sleep w/o ever waking up.

thanks for te response,yes,the hardware is old but this is for my like a lenovo t400 for FreeBSD, and old hardware that need tunning for run fine..
this model dont use battery for the SmartArray(fortunately), i have other models that include battery and you have rigth,that servers went to eternal sleep
and here i get spare parts(used) like power supply,memory,etc
for now i disable iLO and the message for network interfaces dont appear...

 

[Peter Eriksson]

Very old post but I figured I'd just chip in that I see exactly the same error on a similar machine. Even though the bce interfaces "sort of" worked for a while they would "hang" eventually. I "solved" it by installing an Intel PCI network card and use that one instead...

Running FreeBSD 12.1-RELEASE-p1 now with ZFS-boot and stuff.