PfSense reboot stalls the machine, no reboot cycle possible
-
Dear folks:
I am encountering trouble with the reboot process of my IBM box with pfSense 2.1. Apparently the reboot shuts down the machine and powers it off shortly (like if the power button would have been pressed).
When the machine is coming up from the power cycle, it presents a cpu fault and wouldn't restart.
Any other Linux distro reboots normally.
I already put the ACPI out of service (hints.devices and loader.conf), but that wouldn't change a thing.
I suspect the std. FreeBSD to be the cause, but I don't know how I can alter the behaviour of the shutdown/reboot itself.
Thanks for any hint.
-
Without getting a whole lot more specific about the "IBM box" HW, adding some relevant boot logs (both BSD and Linux) etc., your chances of getting a hint would be best directed to a fortune teller…
Personally, something that presents a CPU fault would belong to a garbage can.
-
Dear doktornotor, dear folks:
many thanks for your reply. Granted, an IBM Box is unspecific. I think, however, that is is a little more worthwhile than to thrown it in the waste, because the machine serves its purpose, has 6 network interfaces and is even more than according to the required specs for FreeBSD. It's old, but reliable, and I have about ten of those running.
The server is an IBM eserver xSeries 345 8670 77X. It had passed the built in IBM diagnostics all together without a flaw. The complete info-dmi, lshw, lspci are attached. I also have posted the boot log of BSD. The Linux part is currently unavailable, as the machine is in production and cannot be rebooted immediately.
As mentioned the reboot procedure behavior differs very much from Linux (or Windows, which the box did run also flawlessly) to FreeBSD.
The shutdown itself on FreeBSD is working correct, but the machine is powering OFF (fans are down), waits two seconds, and then powers on again. This is NOT done when reboot (or Shutdown -r) with Linux and/or Windows. Here the reboot cycles without turning off the power (like pressing the power switch). Even if I would not have trouble with the BMC on this, I rather would rather avoid this power cycle, since the hard disks would be spun down and up again unnecessarily.
I think the Linux / Windows way could be described as a warm reboot, while the FreeBSD is even more than a cold reboot, it is shutdown, Power off, power on, trying to restart. This seems not to be in compliance with the baseboard management controller (BMC), which marks the cpus to be faulty. When you unplug the power, the error is gone. the IBM system log doesn't report an error, too. I am certain the CPU fault to be not real, instead, the power cycle is non compliant.
On the zfs warnings: I have already shifted them to a higher value. The warning is gone, the behavior on reboot stays.
One more hint: I have activated the CPU Frequency Thermal Control driver in FreeBSD.
My specific question is and was; Where can I alter/configure the reboot behavior of freeBSD? Are there config files or kernel modules where this could be altered?
-
As for ZFS, it is not used at all… no need to mess with that.
As for ACPI - cannot see it disabled at all according the the dmesg output?!
echo "hint.acpi.0.disabled=1" >> /boot/loader.conf.local echo "hint.apic.0.disabled=1" >> /boot/loader.conf.local reboot -
Thanks for the quick reply.
Yes, acpi is back on again, after I have had it disabled according to strings similar to yours in loader.conf and in devices.hints, too.
The result was, that the boot menu of pfSense did show an option to start the machine WITH acpi on (option #1, it think), so I considered that the setting in those two files were effective. Normally, you can put acpi off with option #2, so - correct me if I am wrong - in my view acpi was really off.
But the behavior on the next reboot was the same, so I couldn't see any influence on the settings. Thus I did put them back in. However, I can put them off anytime if this helps the subject matter.
-
Hmmm… well, maybe someone with hands-on experience on the xSeries HW can chime in.... A quick Google search shows huge amounts of ACPI-related trouble with this kind of HW and BSD.