various ACPI-type issues

[chconnor]

Hi ho - down to the last few issues on this install...

- motherboard has a "double click mouse to start computer" feature which works from windows shutdown but not Kubuntu.

- I have two monitors -- if the second monitor is on while Kubuntu starts up, and even if it is turned off while Kubuntu is awake, then after Kubuntu shuts down that time it will immediately reboot rather than stay off as intended. If the second monitor is turned off (i.e. unplugged from power, but connected to computer) when Kubuntu starts up, this doesn't happen. The second monitor (recently added to the system) does have USB ports on it (nothing plugged in to them).

I've read what I can understand on ACPI, read a few threads, a few tutorials like https://wiki.ubuntu.com/DebuggingACPI, etc. And I'm just not sure where the smart place to start is. My (brand new, just-released GA-Z87X-UD3H) mobo does have a firmware update available, but i'd rather avoid the risk unless it seems like the culprit. Should I do that, or try some of the kernel options to narrow things down, try a release candidate kernal, or something else?

Thanks for any direction,
-c

[chconnor]

Update: shutdown -P now gets around the reboot issue, and it looks like it'd be easy to modiy /etc/init.d/halt to hardcode that, but i wonder if it's the smart way to resolve this. Plus I'd love for the start-via-mouse-click to work (the power switch isn't easy to reach) so that's still outstanding.

Update2: modifying /etc/init.d/halt to use shutdown -P now gave an error, despite working from a terminal... regarding an inability to connect to a bus or something along those lines. Oddly, changing the line to halt -p does work, even though afaict without the "-f" it's just calling shutdown -h -P now (line 221 at http://bazaar.launchpad.net/~ubuntu-.../util/reboot.c) and that fails in the same way (dbus error).

Update3: the newer monitor (with the USB ports on it) -- when connected by VGA/d-sub (and the older monitor on DVI), the same rebooting happens. So I'm guessing it has to do with the mobo and not the monitor specifically. Guess i could cross my fingers and try the mobo firmware upgrade, but that feels a little desperate.

[chconnor]

An update... shutdown -P now doesn't actually work. The false positives stemmed from the fact that it's intermittent: it happens about 90% of the time.

Turns out to be related to the wake-on-lan feature of the motherboard. If that's turned off in bios, this never happens. If I shut down from windows, it never happens. And, interestingly, the first time I shut down from Linux after having enabled WOL in the BIOS, it doesn't happen, but most subsequent times it does.

If I boot to the desktop, confirm the net works, then unplug the net cable, then shutdown, it still happens, so that should rule out stray packets from the router(s) triggering WOL. So i'm suspecting a bug in the e1000e module or something along those lines.

Using ethtool to set the wol state of the card before shutdown doesn't seem to have any effect.

ifdown'ing the device before shutdown does seem to make it stop, which is encouraging, i guess, although again, i'd like WOL to work at some point, so i'm not sure how that will affect things.

Adding the ifdown to the halt script doesn't work, though -- i don't know much about the init.d stuff... maybe you can't run just any program at that runlevel or something... ?

[Snowhog]

Play around with "kernel" options in /etc/defaut/grub

Look for the GRUB_CMDLINE_LINUX_DEFAULT= line. Within the " " following the = you can try the following:

noapic
acpi.power_nocheck=1

Myself, I use pcie_aspm=force