4

I suspend my laptop using echo mem > /sys/power/state. That works fine and it resumes nicely. Once I try to power it off, it shuts down fine until i see the message Power down. (or similar). Needless to say, it stops there, completely.

Why? How to avoid?

8
  • 1
    How are you trying to shutdown? This is normal behavior for shutdown -H, but shutdown -P should power off.
    – psusi
    Sep 7, 2011 at 1:40
  • This is strange if you shutdown properly (as psusi suggested). Try recompiling the kernel with CONFIG_ACPI_DEBUG enabled and post the new dmesg. Oct 2, 2011 at 13:38
  • @psusi I'm using 'halt'. If I didn't suspend it works just fine. Only after one S-R cycle it doesn't power off anymore.
    – McEnroe
    Oct 3, 2011 at 5:20
  • @rozcietrzewiacz enabled acpi debug, attached two pastes, one before, one after S-R. As I'm writing this I realized the later one would have been enough :-D ...
    – McEnroe
    Oct 3, 2011 at 5:21
  • Try disabling the aspm=force, wl, and nuovu modules.
    – psusi
    Oct 3, 2011 at 13:44

2 Answers 2

1

You need to provide at least your kernel config, dmesg and lsmod output for people to be able to say anything meaningful. Shutdown functionality is ACPI-related, so I would check everything ACPI first.

5
  • I attached it. Can you elaborate on how to check acpi?
    – McEnroe
    Sep 6, 2011 at 12:07
  • lspci is not lsmod. also added dmesg to the answer. looking at kernel config everything is built in, so dmesg might provide some helpful hints about things possibly broken.
    – lkraav
    Sep 6, 2011 at 13:40
  • Thanks for pointing that out. I misread for lsmod for lspci, my bad. Attached dmesg and modules info.
    – McEnroe
    Sep 6, 2011 at 14:28
  • Does the question title mean that the device does power off normally off a cold boot with no previous suspend cycle?
    – lkraav
    Sep 6, 2011 at 18:15
  • @Ikraav: exactly.
    – McEnroe
    Sep 7, 2011 at 3:46
0

I just noticed that all your dmesg contain a call trace that indicates something tried to access the system log using a deprecated call. As you out ruled the wl driver and probably the kernel itself as well, what is left are userspace and hardware. Another look at the dmesg made me notice that the call trace refers to syslog-ng. An emerge -vuDa1 syslog-ng should not harm and may help.

5
  • Did not load wl: same problem, still prints out a stack trace. See newest dmesg.
    – McEnroe
    Oct 4, 2011 at 21:52
  • Using latest broadcom-sta version (5.100.82.38-r1), which is the most recent driver for any broadcom stuff. I'm pretty sure that's not outdated. Chipset does not seem to be supported by the kernel itself.
    – McEnroe
    Oct 4, 2011 at 21:54
  • Vanilla means unmodified. As in the latest, officially released (stable), unmodified kernel. Also, I had the problem before 3.0, too.
    – McEnroe
    Oct 4, 2011 at 21:57
  • Well, bad shot then. But I have another idea: it says "Pid: 2148, comm: syslog-ng" - maybe syslog-ng is misbehaving. What version do you have? If it's below 3.2.4, try upgrading (again, this is to take care for the evident error in dmesg, but may not yet solve the whole issue). Oct 5, 2011 at 6:16
  • About vanilla: Well, I can see that the aspect of vanilla- vs gentoo- sources is a bit of a discussion. The genpatches site claims that gentoo-sources are focused on stability and I'm used to trust gentoo-sources in that matter. But I believe you are right that vanilla should be stable. Oct 5, 2011 at 6:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .