Project

General

Profile

Actions

Bug #2232

closed

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

Added by ak over 12 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/21/2011
Due date:
% Done:

0%

Estimated time:

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)

#########

  1. 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

  1. cd /sys/dev/acpica5 && make clean && make ACPI_DEBUG=1
  2. 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


Files

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

Related issues 1 (1 open0 closed)

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

Actions
Actions #1

Updated by ak over 12 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!

Actions #2

Updated by ak over 12 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.

Actions #3

Updated by ak over 12 years ago

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

Please close my one - issue 2232

Actions #4

Updated by swildner almost 10 years ago

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

Closing, duplicate of #2167

Actions #5

Updated by swildner almost 10 years 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

Actions

Also available in: Atom PDF