Bug #2232

acpi - system cannot reboot or power down - 2.13.0.336.gacd31-DEVELOPMENT

Added by ak about 3 years ago. Updated 7 months ago.

Status:ClosedStart date:11/21/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

Versions:

Workstation: Lenovo Thinkcentre M58p
DragonFlyBSD: v2.13.0.336.gacd31-DEVELOPMENT X86_64_GENERIC x86_64

#########

Problem Overview:

My system cannot reboot or power down using ACPI. It stops after the following:
Syncing disks…
done
Uptime: 11m24s

I've tried with the commands:
shutdown -p now
shutdown -r now
reboot

power down and reboot work okay with FreeBSD 9.0 RC1

#########

ACPI info from sysctl:

hw.acpi.power_button_state: S5

dfbsdp# sysctl -a | grep -i acpi
kern.cputimer.select: HPET ACPI-safe24 i8254_timer2 dummy
debug.acpi.level: NONE
debug.acpi.layer: NONE
debug.acpi.suspend_bounce: 0
debug.acpi.do_powerstate: 1
debug.acpi.acpi_ca_version: 20110211
debug.acpi.ec.timeout: 750
debug.acpi.ec.polled: 0
debug.acpi.ec.burst: 0
debug.acpi.semaphore_debug: 0
hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.power_button_state: S5
hw.acpi.sleep_button_state: S3
hw.acpi.lid_switch_state: NONE
hw.acpi.standby_state: S1
hw.acpi.suspend_state: S3
hw.acpi.sleep_delay: 1
hw.acpi.s4bios: 0
hw.acpi.verbose: 1
hw.acpi.disable_on_reboot: 0
hw.acpi.handle_reboot: 1
hw.acpi.reset_video: 1
hw.acpi.cpu.cx_lowest: C1
hw.acpi.cpu0.cx_supported: C1/1 C2/1
hw.acpi.cpu0.cx_lowest: C1
hw.acpi.cpu0.cx_usage: 100.00% 0.00% last 5000us
machdep.acpi_timer_freq: 3579545
machdep.acpi_root: 1009904

#########

dfbsdp# acpiconf -s S5
acpiconf: invalid sleep type (5)

#########

# acpidump -dt > out.asl

Output from "iasl out.asl":

your.asl 1264: Method (WQA0, 1, NotSerialized)
Warning 1088 - ^ Not all control paths return a value (WQA0)

your.asl 2122: And (CAPB, 0xFFFFFFFC)
Warning 1106 - ^ Result is not used, operator has no effect

your.asl 2123: Or (CAPB, 0x00)
Warning 1106 - ^ Result is not used, operator has no effect

your.asl 2290: DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
Error 4123 - ^ Min/Max/Length/Gran are all zero, but no resource tag

your.asl 2926: Name (NATA, Package (0x03)
Remark 5048 - ^ Initializer list shorter than declared package length

your.asl 3386: Or (0x03, PARM)
Warning 1106 - ^ Result is not used, operator has no effect

your.asl 9648: Method (_WAK, 1, NotSerialized)
Warning 1081 - ^ Reserved method must return a value (Integer/Package required for _WAK)

ASL Input: your.asl - 11164 lines, 411038 bytes, 4585 keywords
Compilation complete. 1 Errors, 5 Warnings, 1 Remarks, 1259 Optimizations

#########

Followed the debug instructions for acpi in http://www.dragonflybsd.org/docs/handbook/handbook-acpi-debug/ but cannot set the debug layers/levels

# cd /sys/dev/acpica5 && make clean && make ACPI_DEBUG=1
# mv acpi.ko /boot/kernel

Adding the below to /boot/loader.conf causes a crash during boot. The error is "Fail trap 12: page fail while in kernel mode" and then enters DD:

debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
debug.acpi.level="ACPI_LV_ERROR"

Adding those options using sysctl causes the system to hang (although I can turn on and off num lock on the keyboard in this state)

#########

Attached dmesg and messages after verbose boot

dmesg-after-boot (106 KB) ak, 11/21/2011 11:29 AM

messages (173 KB) ak, 11/21/2011 11:29 AM


Related issues

Related to Bug #2167: shutdown/reboot fails after uptime msg New

History

#1 Updated by ak about 3 years ago

I inserted lots of kprintf's to try to find out if the shutdown procedure was stopping somewhere.
(Please note: I do not know anything about the kernel and only know a little C).
This is what I found:

###########

In sys/kern/kern_shutdown.c, boot() calls "EVENTHANDLER_INVOKE(shutdown_post_sync, hoot);"

"EVENTHANDLER_REGISTER(shutdown_post_sync, module_shutdown, NULL, SHUTDOWN_PRI_DEFAULT);" is defined in sys/kern/kern_shutdown.c

This ends up in "module_shutdown(void* arg1, int arg2)" in sys/kern/kern_module.c:

for (mod = TAILQ_FIRST(&modules); mod; mod = TAILQ_NEXT(mod, link))
MOD_EVENT(mod, MOD_SHUTDOWN);

This shuts down 195 modules and then gets to mod 'rootbus' and gets stuck.

MOD_EVENT never returns when mod is 'rootbus'.

I think this because I have kprintf's before and after the MOD_EVENT in the for loop.

###########

I looked into the shutdown procedure for 'rootbus'.

It seems to call "root_bus_module_handler(module_t mod, int what, void* arg)" in sys/kern/subr_bus.c

This calls "device_shutdown(root_bus)" which then calls "bus_generic_shutdown(dev)"

bus_generic_shutdown(device_t dev)
{
device_t child;

TAILQ_FOREACH(child, &dev->children, link)
device_shutdown(child);

return(0);
}

I put kprintfs before and after the "device_shutdown(child);" in the TAILQ_FOREACH.
I can see that it goes through lots of interfaces but then gets stuck. This is the last output I see:

AK: bus_generic_shutdown(): Calling device_shutdown(): ehci0
AK: bus_generic_shutdown(): Calling device_shutdown(): 'usb3'
AK: bus_generic_shutdown(): Calling device_shutdown(): 'uhub3'
AK: bus_generic_shutdown(): Returned device_shutdown(): 'uhub3'
AK: bus_generic_shutdown(): Returned device_shutdown(): 'usb3'

###########

I don't know what it means but I hope it helps!

#2 Updated by ak about 3 years ago

From my last update it looks like the device_shutdown() on ehci0 is not returning.

I disabled ehci0 by adding hint.ehci.0.disabled="1" to /boot/loader.conf and now I am able to shutdown and reboot - yay.

So I guess its a problem with ehci shutdown stuff.

I'll try to dig a little deeper into the ehci shutdown procedure to see where it hangs.

#3 Updated by ak about 3 years ago

Looks like this is the same as issue 2167 - http://bugs.dragonflybsd.org/issues/2167

Please close my one - issue 2232

#4 Updated by swildner 7 months ago

  • Description updated (diff)
  • Status changed from New to Closed

Closing, duplicate of #2167

#5 Updated by swildner 7 months ago

One more comment (unrelated to the actual issue):

ACPI_LV_DEBUG was removed in 2009, and was only in the manual page still when this bug was filed. So the reason for the box crashing on boot was more likely one the ACPI we had at the time was having (trying to handle an unknown level) than a hint at an actual error caught by it (because it was already no longer existing in the code then). Trying to set acpi.debug.level to ACPI_LV_ERROR on a current system does not result in a crash. It boots and the acpi.debug.level sysctl shows "NONE", as it should, because it's an unknown level.

Regards
Sascha

Also available in: Atom PDF