-
Important Announcement for the TrueNAS Community.
The TrueNAS Community has now been moved. This forum has become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
"Shutdown" doesn't
- Thread starter Z300M
- Start date
- Status
74m
Explorer
- Joined
- Jul 13, 2013
- Messages
- 66
http://download.freenas.org/9.10/STABLE/201604261518/x64/
For me, the reboot bug appears in all the latest versions...
For me, the reboot bug appears in all the latest versions...
74m
Explorer
- Joined
- Jul 13, 2013
- Messages
- 66
Yesterday i remembered that there was a "bug" in the first version of the board. Something with the C1 vs C2 steppings. I dont get it completely, but you can read this here.
And here is a user with a similar problem which could be fixed with a RMA exchange.
1) So... just a hypothesis: Maybe we have a X10SLF-7 from the old "bugged" version and the happy users have a new revision like the dude with the RMA exchange...?!
2) If there is a connection between the stepping thing (which occurs with usb) and our problem - could using a sata device for the freenas-boot fix our problem?
I remember that i checked my SN as described in the first link and my board is one of the affected C1 versions.
Guys, what do you think? Maybe you could check your SN and we can see if there is a relation between the working and not working boards?
Sadly i dont know if we can check the stepping or SN in the shell or something?
Maybe all of the above theories are bullshit, but i think we should check this. ;)
Greetings
74m
And here is a user with a similar problem which could be fixed with a RMA exchange.
1) So... just a hypothesis: Maybe we have a X10SLF-7 from the old "bugged" version and the happy users have a new revision like the dude with the RMA exchange...?!
2) If there is a connection between the stepping thing (which occurs with usb) and our problem - could using a sata device for the freenas-boot fix our problem?
I remember that i checked my SN as described in the first link and my board is one of the affected C1 versions.
Guys, what do you think? Maybe you could check your SN and we can see if there is a relation between the working and not working boards?
Sadly i dont know if we can check the stepping or SN in the shell or something?
Maybe all of the above theories are bullshit, but i think we should check this. ;)
Greetings
74m
My assessment is that all that is unrelated. My system is working perfectly fine from the IPMI interface (I'm able to power down / shut down from both the IPMI web and iKVM viewer) - so it's not the same issue.
I'm using a SATADOM for my boot disk.
Today, I contacted Supermicro - so far (no surprise) they have claimed issue has nothing to do with the BIOS or IPMI versions.
At the moment he's indicating that the same FAQ you referenced (Supermicro FAQ 16767 ) applies.
I'm using a SATADOM for my boot disk.
Today, I contacted Supermicro - so far (no surprise) they have claimed issue has nothing to do with the BIOS or IPMI versions.
At the moment he's indicating that the same FAQ you referenced (Supermicro FAQ 16767 ) applies.
Solution: Reboot your server every 20 minutes... duh!
I'm kidding of course. This issue does seem very... odd.
I'm rolling back my BIOS to version 3.0 and IPMI FW version to 1.92 for some testing as part of tech support with Supermicro - mobo was shipped with these versions.
In this combination, I do not recall having this issue but then again my system build is fairly new so it could be something that never caught my attention.
In this combination, I do not recall having this issue but then again my system build is fairly new so it could be something that never caught my attention.
I've now done some testing with BIOS v3.0 and IPMI v1.92:
- 3 x shutdown with UPTIME < 10 min (PASS)
- 2 x shutdown with UPTIME = 15 min (FAIL)
- 1 x shutdown with UPTIME = 20 min (PASS)
- 1 x shutdown with UPTIME = 45 min (PASS)
- 1 x shutdown with UPTIME = 70 min (FAIL)
I recorded the shutdown sequence from the console via the iKVM and result is quite interesting - the shutdown sequence seems to be interrupted (refer to attachment).
My gut feel is that maybe fix for Bug# 14537 is having an influence?
In the meantime, I'll report back to the Supermicro tech support.
- 3 x shutdown with UPTIME < 10 min (PASS)
- 2 x shutdown with UPTIME = 15 min (FAIL)
- 1 x shutdown with UPTIME = 20 min (PASS)
- 1 x shutdown with UPTIME = 45 min (PASS)
- 1 x shutdown with UPTIME = 70 min (FAIL)
I recorded the shutdown sequence from the console via the iKVM and result is quite interesting - the shutdown sequence seems to be interrupted (refer to attachment).
My gut feel is that maybe fix for Bug# 14537 is having an influence?
In the meantime, I'll report back to the Supermicro tech support.
Attachments
74m
Explorer
- Joined
- Jul 13, 2013
- Messages
- 66
Hi,
good news from here. For me, i have solved the bug. I hope this is working for you too. The trick is...
*drum roll*
*drum roll*
;)
to enable the "headless mode" in the "ACPI Settings" under the "Advanced"-Tab in the BIOS.
After press "save and reset" in the BIOS, i had to do a full shutdown via ipmi. Only after the full shutdown, the new settings seems to be enabled. Since then, all my shutdowns worked. Shutdowns via cronjobs, shutdowns via CLI and shutdowns via GUI.
Here are my test results:
headless mode disabled:
The point of reboot with headless disabled:
The shutdown with headless enabled:
Greetings and good luck,
74m
good news from here. For me, i have solved the bug. I hope this is working for you too. The trick is...
*drum roll*
*drum roll*
;)
to enable the "headless mode" in the "ACPI Settings" under the "Advanced"-Tab in the BIOS.
After press "save and reset" in the BIOS, i had to do a full shutdown via ipmi. Only after the full shutdown, the new settings seems to be enabled. Since then, all my shutdowns worked. Shutdowns via cronjobs, shutdowns via CLI and shutdowns via GUI.
Here are my test results:
headless mode disabled:
- 3 x shutdown with uptime = 15 - 20 min: fail
- 1 x shutdown with uptime = 180 min: fail
- nearly every shutdown with an uptime for more about 30 mins (for the last months): fail
- 4 x shutdown with uptime = 15 - 20 min: okay
- 1 x shutdown with uptime = 90 min: okay
- 1 x shutdown with uptime = 10 hours: okay
The point of reboot with headless disabled:
The shutdown with headless enabled:
Greetings and good luck,
74m
Great work 74m! Since I'm already in communication with a Supermicro tech support guy, I'll ask him about it.
Regarding your question on SATADOM, my InnoDisk 16GB SATADOM-MV 3IE (iSLC) requires a separate power connection. The mobo has a DOM power connector (JSD1) right next to the SATA connectors which is great. But unfortunately in the case of my InnoDisk SATADOM, the default cable was a 3-pin molex cable so I wasn't able to use a direct connection to the mobo - I couldn't be bothered trying to find the right cable (the guys I bought it from didn't have one).
Regarding your question on SATADOM, my InnoDisk 16GB SATADOM-MV 3IE (iSLC) requires a separate power connection. The mobo has a DOM power connector (JSD1) right next to the SATA connectors which is great. But unfortunately in the case of my InnoDisk SATADOM, the default cable was a 3-pin molex cable so I wasn't able to use a direct connection to the mobo - I couldn't be bothered trying to find the right cable (the guys I bought it from didn't have one).
@74m Thank you very much posting the solution! I just finished installing FreeNAS 9.10 on a brand new X10SL7 build and of course the first time I told it to shut down it rebooted. I had put a mental pin on this thread in case the issue came up for me and tried your solution, worked like a charm! It pays off to read as many threads as possible before starting a noob build...
Current feedback from Supermicro tech support is that enabling "headless mode" in "ACPI Settings" as a fix for this issue doesn't make sense to him.
He is indicating the following:
"Issue is not related to BIOS and IPMI but rather with MEI driver support in OS.
Unfortunately, SW support is pretty limited."
Can anyone provide feedback on MEI driver support in FreeNAS / FreeBSD?
He is indicating the following:
"Issue is not related to BIOS and IPMI but rather with MEI driver support in OS.
Unfortunately, SW support is pretty limited."
Can anyone provide feedback on MEI driver support in FreeNAS / FreeBSD?
I had asked the Supermicro tech support if there is a similar black-list workaround (per Supermicro FAQ# 16767) for FreeNAS (FreeBSD).
That was a few weeks back but did not receive a reply - I just sent him a follow up.
Otherwise, we'll have to get a developer at iXsystems or FreeBSD to comment on MEI driver support - nobody seems to have provided any feedback within the forum.
Did you log a bug?
That was a few weeks back but did not receive a reply - I just sent him a follow up.
Otherwise, we'll have to get a developer at iXsystems or FreeBSD to comment on MEI driver support - nobody seems to have provided any feedback within the forum.
Did you log a bug?
I received an update from Supermicro tech support.
There is no or he is not aware of a similar black-list workaround.
He suggests trying to disable ASPM (Active State Power Management) in BIOS - I'll try this later today.
One of his other comments is trying to duplicate the issue in Windows and pinpoint it to HW issue - I don't have a spare disk to try but this is a good idea as part of the analysis.
There is no or he is not aware of a similar black-list workaround.
He suggests trying to disable ASPM (Active State Power Management) in BIOS - I'll try this later today.
One of his other comments is trying to duplicate the issue in Windows and pinpoint it to HW issue - I don't have a spare disk to try but this is a good idea as part of the analysis.
74m
Explorer
- Joined
- Jul 13, 2013
- Messages
- 66
Hey,
thanks for your response kyp.
I didn't log a bugticket because I already did it in the past. Then I thought the bug was resolved with the headless mode...
Actually the bug is partly resolved - for me! I shutdown my server two times a day. At the evening and at the morning with a shutdown script. At the evening the shutdown works flawlessly after my "headless mode"-change. In the morning the server will mostly reboot for one time. I think there is a daemon or something active which causes an error and the shutdown won't work. Sadly I can't find anything useful in the logs.
But the fact is: After enabling the headless mode, all shutdowns worked perfectly. After my boot-stick-change, and a few settings here... a few cronjobs there... one of my two scheduled shutdowns will not work. So I think I have to check whats the difference between my morning and my evening shutdowns. I will let you know when I make progress.
Greetings
74m
thanks for your response kyp.
I didn't log a bugticket because I already did it in the past. Then I thought the bug was resolved with the headless mode...
Actually the bug is partly resolved - for me! I shutdown my server two times a day. At the evening and at the morning with a shutdown script. At the evening the shutdown works flawlessly after my "headless mode"-change. In the morning the server will mostly reboot for one time. I think there is a daemon or something active which causes an error and the shutdown won't work. Sadly I can't find anything useful in the logs.
But the fact is: After enabling the headless mode, all shutdowns worked perfectly. After my boot-stick-change, and a few settings here... a few cronjobs there... one of my two scheduled shutdowns will not work. So I think I have to check whats the difference between my morning and my evening shutdowns. I will let you know when I make progress.
Greetings
74m
Hi,
I've been doing some additional work on this topic, including discussion with the FreeBSD community.
Firstly, there is no mei driver in FreeBSD (the community and Supermicro tech support have confirmed).
I've tried removing the LAN cable - I hooked up keyboard and monitor directly to the server, but again I have the same effect (sporadically). So Wake On LAN can be ruled out as a cause.
Next, I did some testing with a standard FreeBSD 10.3 install to USB disk (no FreeNAS). After numerous attempts to try to reproduce the issue (~ 20) with varying UPTIMEs - mainly 15-20 min, I could not. The testing was performed using "shutdown -p now" command and with acpi headless mode = disabled in BIOS (the default setting).
I think I can only conclude that something in FreeNAS is having an influence here.
I'm considering raising a ticket but there is a conflicting result reported by 74m relating to headless mode.
I've been doing some additional work on this topic, including discussion with the FreeBSD community.
Firstly, there is no mei driver in FreeBSD (the community and Supermicro tech support have confirmed).
I've tried removing the LAN cable - I hooked up keyboard and monitor directly to the server, but again I have the same effect (sporadically). So Wake On LAN can be ruled out as a cause.
Next, I did some testing with a standard FreeBSD 10.3 install to USB disk (no FreeNAS). After numerous attempts to try to reproduce the issue (~ 20) with varying UPTIMEs - mainly 15-20 min, I could not. The testing was performed using "shutdown -p now" command and with acpi headless mode = disabled in BIOS (the default setting).
I think I can only conclude that something in FreeNAS is having an influence here.
I'm considering raising a ticket but there is a conflicting result reported by 74m relating to headless mode.
Last edited:
- Status
Similar threads
- Locked
- Locked