"Shutdown" doesn't

[kyp]

I've gone to IPMI ver 03.27 and BIOS ver 03.0a (which is the latest) and still had the issue - it remains unresolved.
Also, tried rolling back firmware to my as delivered state (IPMI ver. 01.92 and BIOS ver. 03.00 - current state) but again same problem.
The Supermicro tech I was dealing with did not think it was related to firmware version.

Could you do a few repeat tests?
The issue is sporadic but reproducible.
I've got an open bug ticket item still in works.

 

[Kei]

I cannot provide my setup now because I'm on vacation... Sorry. However it seems like the issue happens very frequently, provided the uptime has been long enough.

Sent from my LG-D855 using Tapatalk

 

[74m]

I can report a 100% reproducible routine:
Every morning (monday - friday) the server starts at 6:00 (via WOL) and shuts down at 7:00. In this one hour I'm downloading a backup from a online server. At 7:00 starts my shutdown script. After there is no IP pingable the shutdown begins at 7:03. This 7:03 shutdown fails every morning! The script will then start again at 7:15 and the second and correct shutdown begins at 7:18. From this time the server will stay off until the evening. I've get a email for every cronjob and so for every shutdown...

So in this hour I'm not using any services like afp, nfs or cifs. The download is a scp file transfer directly to my zfs mainpool.

______

Guys, may I remind you of my posting #25 in this thread? I think of getting a new X10SLF-7 just to check out if the shutdown is working with a actual version.
By all this testing I think we should compare our steppings (SNs) just to see I we all have a C1 version...

A quote from the origin X10SL7-F thread in this forum:

The board serial number has year and month manufactured information after
first two letters.

For example, ZM 137S99999

That means board has been manufactured on July 2013.

If you get a board for September or later, then it should be using C2 chipset.

My SN is NM138Sxxxxxx. So its manufactured on august 2013 and its definitely a C1 version.

 

[Kei]

I've just bought my X10SLF-7, flashed to IT mode 20.4 and I do have this problem. Can I provide useful info?

Sent from my LG-D855 using Tapatalk

 

[74m]

Ah ok, so your board is probably manufactured later than september 2013?
It would be nice if you can check the SN - just to be sure.

 

[Kei]

Wait, I might have a pic on my phone

Sent from my LG-D855 using Tapatalk

 

[Kei]

Just my luck! How can I know the manufacturing date?

Sent from my LG-D855 using Tapatalk

 

[74m]

Ok, thank you Kei. Your board is from january 2016. Read my quote above to see how to read the SN.
So I think I can forget my C1-stepping-complot. Thank you! ;)


Gesendet von iPhone mit Tapatalk

 

[Z300M]

Is it possible that the default BIOS settings have changed since the version with which mine (and boards of similar age) came -- 1.1, I think -- and that those settings have stayed intact even when I updated to ver. 2.00? That boards with a later BIOS came with different defaults and that these are the cause of the problem?

 

[Kei]

Anything if I can help with this problem. Please tell me what do I need to check in the BIOS settings when I come back next week.

Sent from my LG-D855 using Tapatalk

 

[74m]

I mentioned above that my shutdowns in the evening failed for 100%. For some reason (I dont know why) every morning the shutdown works flawlessly (uptime ~78 minutes, just a backup download via scp) for the last 9 days. I have changed nothing in my settings... Anyway, the evening shutdown takes two attempts every evening.

Any news from you guys?

 

[kyp]

I'm still waiting on an update for Bug# 16039 ....

 

[engmsf]

I have been running Freenas since 8.3.1 and through to 9.3 stable with no issues with shutdown via the GUI. I just simply hit the shutdown in the GUI or sometimes if I am lazy, hit the power button on the computer, and the system completely shutdown.

That all changes a few nights ago when I upgraded to 9.10. A shutdown is a reboot now, arghh.

 

[Ruff.Hi]

I got a X10SLF-7 a few days ago and I am having the same issue ... shut down results in reboot. I have a couple of wrinkles for you ...

1) every shut down results in a reboot. It doesn't matter about the up-time
2) if I pull the front panel power / reset wires from the motherboard, shut down results in shut down

I'll get BIOS / IPMI and mobo manufacturer date - will post them later.

Edit1: I just booted up without the UPS attached (ie NAS straight into wall power outlet). Booted to standard console freenas menu (1 to 14) ... issued shutdown ... and it shut down - no problem (with power / reset wires in the motherboard). I have booted it up again and will try shutdown again once I have walked the dog.

Edit2: NAS shut down after dog walk (about 30 mins). It did complain (a lot) about the lack of UPS.
SN of motherboard starts with 'NM164S' ... so - manufactured in April 2016.

 

[kyp]

I've got my front panel fully connected to the mobo, and never considered the UPS.
In the end I don't think up-time has anything to do with it - I'm still sporadically getting this issue, even with long up-times.

The fact remains that I never experienced this issue pre 9.10-STABLE-201604181743 (as far as I can re-call).
I haven't yet rolled back to verify.
If you're still system testing the new build, maybe this is something you can try and report the results?

I've kind of given up hope that it will be fixed in 9.10 - think I'll wait for 10 stable to be released and re-asses the behavior.

 

[74m]

Hey guys,
pull out the front panel power and reset wires does not work for me. :(
I'm pretty sure I already tried to remove the UPS but this also does not the trick...

I remember that the reboot-bug already occurs in earlier versions of freenas (8.x - 9.2), but in this time this was not a problem for me because the server was online 24/7.

 

[Ruff.Hi]

The 'pull the front panel power cable' might be heavily related to the up time as I only did that for the 2nd+ shutdowns. So ... I might be confusing the lack of power cable with the 'up time'.

Edit: Spoke too soon. Just issued a shutdown and it rebooted. System had been up all day.

 

[Mark Holtz]

Unfortunately... I am also experiencing the same issue. My FreeNAS server is constantly on 24/7, and I had to shut it down to move it to a new location. Instead of shutting down from the web console, it rebooted. If I go local into the console, I can manually shut it down from there.

 

[kyp]

Hey guys, this might be a solution.
This is directly from the FreeBSD handbook: http://www.pl.freebsd.org/doc/handbook/acpi-debug.html

11.13.2.5. System Powers Up After Suspend or Shutdown

First, try setting hw.acpi.disable_on_poweroff="0" in /boot/loader.conf. This keeps ACPI from disabling various events during the shutdown process. Some systems need this value set to 1 (the default) for the same reason. This usually fixes the problem of a system powering up spontaneously after a suspend or poweroff.

I've only just added this to my tunable so still need to monitor before I can make any definitive conclusion.
Would be good if you can also try and report back.

By the way I'm now running Corral.

 

[styno]

Thanks for sharing, but it is not working for me, in fact, it is not even there when I am trying to find it with sysctl.
(also on Corral)

Code:

# sysctl -a hw.acpi | grep disable
hw.acpi.disable_on_reboot: 0
# sysctl -d hw.acpi.disable_on_poweroff
sysctl: unknown oid 'hw.acpi.disable_on_poweroff'
# sysctl -a | grep disable_on
hw.acpi.disable_on_reboot: 0