Laptop doesn't shutdown anymore with ACPI enabled

[jackburton]

Since some time (I can't say how much, since I haven't tested that so often), my laptop doesn't shutdown correctly using ACPI. It was shutting down correctly since hrev33781.

[axeld]

FWIW my desktop machine has the same problem since a few weeks.

[michael.weirauch]

hrev34452 gcc4h2 fresh install and it did shut down correctly last night. (ThinkPad T500)

[jackburton]

Seems to be working again since a few revisions. I'd be for closing this. Axel ?

[axeld]

I'll try again shortly.

[axeld]

Problem persists in hrev34532.

[tqh]

Afaict it works on my machines, so I'm not sure if I can do that much.

[kallisti5]

FYI: My Thinkpad T43 with ACPI enabled shuts down properly as of hrev35012 x86gcc2hybrid

[tqh]

I think this might be related to #5449, can anyone not being able to shutdown fo the following?

• Check that ACPI is running, more -f /dev/acpi/namespace should work if ACPI is running
• Provide a syslog from boot

[tqh]

Should be:

• Check that ACPI is running, more -f /dev/acpi/namespace should work if ACPI is running
  
• Provide a syslog from boot
  

(I loathe the comment editor btw. Can't it be made sane.)

[bonefish]

Replying to tqh:

(I loathe the comment editor btw. Can't it be made sane.)

Just add a space before your "*" or "-" bullets and your list items will be formatted correctly. Please have a look at ​http://dev.haiku-os.org/wiki/WikiFormatting.

[tqh]

Yes, but I was thinking of linebreaks, which works everywhere, except here. Fobar according to me.

[tqh]

Can someone test if it works with hrev35726 or later?

[vegardw]

Replying to tqh:

Can someone test if it works with hrev35726 or later?

My Acer Aspire One AOA110 doesn't shut down on hrev35727

[stippi]

Hi vegarwa, did your Acer Aspire AOA110 ever shutdown with any Haiku version, though? And just to make sure, you did enable ACPI in the kernel settings file, correct? hrev35726 does not enable ACPI by default, it's just suppose to fix a bug, in case you do have it already enabled manually.

[tqh]

He has it enabled as he helped with another ACPI bug. wegardw, could you provide the syslog after you have tried to run shutdown. Just reboot after that and grab it.

[vegardw]

The attached syslog is when booting (cold boot), then trying to shut after the system has finished booting, without doing anything else first.

[tqh]

That one only seems to be one boot. I want one after you've tried shutdown.

(Or is the syslog behaviour changed so it's not written to disk or overwritten on boot?)

[vegardw]

Replying to tqh:

That one only seems to be one boot. I want one after you've tried shutdown.

(Or is the syslog behaviour changed so it's not written to disk or overwritten on boot?)

Yeah, thats just from the one boot and attempted shutdown. I booted from another haiku partition to copy out the syslog. Will do it again so you also get the subsequent reboot.

[vegardw]

attachment updated, now also with the next boot

[tqh]

To me it looks like media-server or debug-server halts shutdown.

KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x6d3a6566, ip 0x4a7490, write 0, user 1, thread 0x92
KERN: vm_page_fault: thread "media_addon_server" (146) in team "media_addon_server" (146) tried to read address 0x6d3a6566, ip 0x4a7490 ("libmedia.so_seg0ro" +0x59490)
KERN: debug_server: Thread 146 entered the debugger: Segment violation

Could you try killing media-server before shutting down?

[vegardw]

media_server, media_addon_server and debug_server killed before trying to shut down

[axeld]

For me, the problem is fixed since hrev36511. Please retest.

[jackburton]

I will.

[jackburton]

Fixed since hrev36511.

[axeld]

I'm afraid my Desktop has gotten resistant to the change; after the update it shut down 4 times in a row (which it didn't ever do before), but the last two times it didn't properly shut down.

I'll do another update soon, maybe that brings things back in order. If not, I'll just reopen that bug again.

[tqh]

I guess we need more logging. I wonder if dpc still does its job til the very end..

[tqh]

I'm trying to look into this in #5880.

If someone can reproduce pls: Try going in to kernel debugger (ctrl + alt + sys req + d) and see what the end lines of the command 'syslog' returns?

Also what 'threads' and 'sc <threadnr>' shows for any interesting threads can also help.

[axeld]

Replying to tqh:

Try going in to kernel debugger (ctrl + alt + sys req + d) and see what the end lines of the command 'syslog' returns?

Nothing interesting, I'm afraid.

Also what 'threads' and 'sc <threadnr>' shows for any interesting threads can also help.

What would be an interesting thread? I have 3 idle threads running, as well as the shutdown worker (I guess that one would have been interesting - will see next time).

In any case, the problem goes away completely if I disable SMP.

[tqh]

Then it's probably true what comments in FreeBSD say, that shutdown should only be called on the boot cpu. Also it says that interrupts should be disabled in ACPI-headers, but with interrupts disabled it doesn't work at all afaict.

[axeld]

That could explain the situation, indeed. Should be pretty easy to do, too (just disable the other CPUs, and then yield once).

[axeld]

BTW should I attach a stack trace of the shutdown worker? It's busy reading some data from PCI over ACPI.

[tqh]

Please do, I need as much info as possible.

[tqh]

#5880 suggests this might be a wifi-issue. Please try removing wifi and see if that allows proper shutdown.

[waddlesplash]

Please retest after hrev54214.