"Shutdown" doesn't

[kyp]

Hmm interesting.
Because I managed to add it successfully (and there is some sort of validation done before committing), I didn't go any further to find it e.g. using sysctl.
See attachment.

 

[styno]

Are you still sure there is validation? :D

(Or is this lack of validation a bug in Corral?)

 

[kyp]

Haha, interesting.
Must be some very crude validation then coz if you try variable "a.a" with value "0", then validation fails.
Not sure now if "hw.acpi.disable_on_poweroff" is legit - it's not like I invented it lol, it was in the FreeBSD handbook! - and FreeNAS is based on FreeBSD.
Maybe the folks in the FreeBSD forum can shed some light.

 

[wblock]

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.

That copy of the FreeBSD Handbook is from 2007 and covers FreeBSD 6.2. The setting does not exist in FreeBSD 11. Even that chapter of the Handbook is gone.

There are some current entries that might have similar functionality:

Code:

hw.acpi.handle_reboot: 1
hw.acpi.disable_on_reboot: 0

However, I suspect that ACPI on FreeBSD has come a long way in the last ten years. It would be worth checking that the BIOS on the system is the most recent version, as ACPI bugs are sometimes fixed.

 

[kyp]

Thanks wblock.
In FreeNAS 9.10 I had tried everything; ACPI settings in BIOS, and upgrading to the latest BIOS version, but nothing seemed to work.

When I moved to FreeNAS Corral, I did a full install and decided to use UEFI boot - not sure if this at all related, I also reset all my BIOS settings to default.
So far, with Corral, I have not seen this issue yet.
Based on your comments, I very much doubt it is because of the tunables I had set.

I will remove the tunables and monitor.
I strongly suspect that there has been improvement in the area of ACPI with Corral / FreeBSD itself, such that the issue I had with prior FreeNAS / FreeBSD versions is no longer present.

Fingers crossed this is the case, otherwise, I'll have to look into the new hw.acpi parameters you mentioned.

 

[Ericloewe]

Well, 9.10.3 moves to FreeBSD 11, so it should behave the same way as Corral.

 

[kyp]

I never actually went to 9.10.3, I jumped from 9.10.2 to Corral.
That probably explains it?

 

[Ericloewe]

9.10.3 isn't out yet. ;)

 

[kyp]

Haha k
I didn't think iX are still developing 9.10.x

 

[wblock]

You will be surprised.

 

[kyp]

Well, 9.10.3 moves to FreeBSD 11, so it should behave the same way as Corral.

You will be surprised.

After the recent important announcement, it all makes sense .....

I've now rolled back to 9.10.2-U2, and the issue is now back again.
So, it's definitely something in FreeNAS 9.10.x or FreeBSD 10.

 

[StephenFry]

Is there any progress to report on this issue? It's popped up for me, as well, and it's enormously frustrating.

This particular machine usually doesn't get shut down that often, so I may not have noticed it before, but it started appearing on a SuperMicro X9SCM-F after updating from 9.10.2-U2 to U3.
Latest (2.20) firmware and IPMI (3.38). If it matters, it is connected to a UPS.

When I shut down from the GUI, it *acts* as if it's shut down, so the interface says after a while "can't connect to web page blablah". Unlike with a proper reboot, when the page apparently waits for the machine to come back. This is why it took me a while to notice the machine was still on.

After an unwanted reboot, a neat shutdown is possible using the FreeNAS console setup, via IPMI or locally.

My solution for now is a rollback to 9.3.1 and everything works great. I had some other, much smaller, issues and weirdness with 9.10 so was always a bit weary, but it's a shame not to be able to use an up-to-date FreeNAS version.