"Shutdown" doesn't

[kyp]

Sorry, I'm back again after further discussion with the Supermicro tech support.

One of the things being suggested is disabling PCIe ASPM (I have no PCIe devices) - I've done so in the BIOS but he is also asking me to do it in the kernel as well, using:

Code:

pcie_aspm=off disable_msi=1

in grub.conf

I cannot find the equivalent kernel parameters in FreeBSD and thinking these should really be set in loader.conf (in System > Tunables).

Would anyone have any idea how to do this?

 

[74m]

Hi kyp,

thanks for all your effort! As is described above, sadly my shutdown problems are not solved. I was to fast with my reports in my bug ticket, but at this time it was working... Sorry if I complicated the process with my bugticket!

However, I am also very interested in your settings (pcie_aspm=off disable_msi=1) and how we can achieve this in freenas. In the pfsense forum I found something with "hw.igb.enable_msix="0""... maybe this will help? But i cant find anything about the ASPM. Did you try to disable the ASPM stuff in the BIOS (Advanced, Chipset Configuration, System Agent Configuration, PCIe Configuration)?

 

[kyp]

Hey 74m,

There's no problem at all ... I'm usually pretty stubborn with these things - to find the root cause.
In the end I raised Bug #16039 - you are more than welcome to contribute.

About the PCIe ASPM BIOS settings (in Advanced > Chipset Configuration > System Agent (SA) Configuration > PCIe Configuration) - refer to attachment. This is what Supermicro recommended I try. Note: I kept the 'Onboard SAS controller X8 - ASPM ' because I'm actually using the SAS controller.

At this stage I'm waiting for some feedback on disabling PCIe ASPM in the kernel.

 

[Kei]

Same mobo and same issue! I'm also interested in finding out what we're supposed to edit in the grub.conf.
Anyways, did you guy verify if also "shutdown -h" may result in a reboot?

 

[kyp]

I did use "shutdown -p now" directly from console at some point during my testing and still managed to re-produce the effect.

 

[Kei]

I did use "shutdown -p now" directly from console at some point during my testing and still managed to re-produce the effect.

Sorry, do you mean "-h" ? Since I'm using an automatic script from my UPS to safely halt the system, I don't really need an actual poweroff, since the UPS would cut the power anyways. Only thing I need is to have a safe halt to avoid data corruption. Could you please confirm or deny that also the "-h" option can result in a system reboot?

 

[kyp]

Agreed, I've also got a UPS but I was just using "shutdown -p now" for my testing - trying to figure out if it was a GUI related problem or not.

 

[silverback]

Hello to All,
I developed this problem some time within the last few updates on a SUPERMICRO MBD-X9SCM-F-O. When I roll back to an April stable it seems to shutdown ok, I guess. My only hope is that if the server receive a shutdown command from the ups it doesn't reboot.

 

[kyp]

hey silverback,
You seem to confirm my suspicion - that the fix for Bug #14604 is having an influence on the reported behavior.
By any chance was the roll-back you did prior to 9.10-STABLE-201604181743?
I would encourage you to provide your feedback on the raised Bug #16039 for this issue, I haven't had any new update yet.

 

[silverback]

Hi kyp,
I rolled back to 9.10-STABLE-201604261518 and on two attempts the server shutdown. After reading your message I tried once again and got the reboot problem. I am somewhat at a loss at this point and won't have time to look into firmware and or bios issues until this weekend.

 

[Kei]

I figured out that if you type "shutdown -h", the system does indeed halt, and if the only reason you want it to halt is that you're running a script for safe poweroff in case of UPS low on battery, your problem should be solved.

 

[kyp]

I don't think you can say the problem is solved if a GUI initiated shutdown is sporadically causing a re-boot instead.
Nevertheless, I'm interested to know how many tests you did with "shutdown -h"?

 

[Kei]

I don't think you can say the problem is solved if a GUI initiated shutdown is sporadically causing a re-boot instead.

I agree that the problem is everything but solved, and indeed very annoying.

Nevertheless, I'm interested to know how many tests you did with "shutdown -h"?

Not very many actually, however I belive that this action will not trigger this bug, because I don't think that the APIs are involved. Infact not even the HDD's are powered down, but in my case it doesnt really matter because in case of UPS low on battery, the power is going out anyways.

 

[74m]

If "shutdown -h" will halt the server correctly, there is a (really dirty) workaround for my failed shutdowns. This is not a solution, but rather a little playing:
I could shutdown my server with a little script and before I execute the "shutdown -h" I trigger an other device (e.g. a dd-wrt) to send a hard shutdown via ipmitool ("ipmitool -H IP-ADRESS -U USERNAME -P PASSWORD chassis power off") 1 minute after the first script.

As I mentioned, thats not a solution but a nasty workaround. ;) But I have to say that my current "solution" with a script that checks if determined IP adresses are reachable with a ping and does a new shutdown after 15 mins is more easy...

In the meantime I tried to figure out If there a other deamons active in the correct and the failed shutdown. I'm not finished with that but i think this wont be helpfull...

 

[Kei]

It's embarassing to be dealing with these problems in 2016, mostly because it's not a consumer motherboard. Anyways, I belive I can try some "shutdown -h" in the nex days, the catch is that we must wait at least a couple of hours otherwise it could be a false positive, as other users report correct poweroff if the command is issued just after boot.

 

[Kei]

Just to report that even "shutdown -h" does not work. Fuck this man... this is the most annoying thing ever.

 

[Mirfster]

Out of curiosity has anyone tried to remove FreeNAS from the equation and see if similar results are witnessed? Perhaps trying FreeBSD, Ubuntu or other installed on a USB?

Sorry I do not run SuperMicro and do not have this issue. However, there are plenty of others who do and I would assume that there would be way more complaints if this were more widespread...

 

[Kei]

I have two more suoermicro (different model number), one with Debian and another also with FN but they seem to be immune. Definitely the one with Debian is. I'm stuck.

Sent from my LG-D855 using Tapatalk

 

[Mirfster]

Hmm... So the other SuperMicro model with FreeNAS; is it running the same version? Trying to decipher is if the issue is more or less isolated to a particular MotherBoard Model with a particular version of FreeNAS?

Seems like you have an ample variety of platforms to run different scenarios. Perhaps more cross-referencing between those having this issue would help narrow down the scope?

In all honesty, I would think that a lot more testing is required to get to the "root" cause...

• Same Motherboard
  • Different versions of FreeNAS (Would recommend not having any Pools initially to really limit the scope)
    
  • Different BIOS settings (may just want to set it to 'Defaults' as one test as well)
  • Different BIOS versions
  • With and without additional PCI cards
  • Perhaps different OS (FreeBSD, Ubuntu, etc)

As with any testing it is always best to try one thing (or just a couple at most) at a time.

Sorry I can't add more to the resolution...

 

[Z300M]

I am the OP in this thread and reported early on that Supermicro Tech Support had suggested updating both IPMI firmware and BIOS to corresponding versions (different version numbers, obviously, but versions of similar release date). I have subsequently updated the IPMI firmware to ver. 03.27, while leaving the BIOS at ver. 2.00, and Shutdown from the GUI still shuts the machine down -- or at least it did just now after an uptime of a week or more.

FreeNAS version: FreeNAS-9.10-STABLE-201606270534 (dd17351)