Shutdown no longer powers off computer (Dapper laptop)

Bug #31993 reported by Peter Whittaker on 2006-02-19
20
Affects Status Importance Assigned to Milestone
Ubuntu
High
Unassigned
acpi (Ubuntu)
Medium
Unassigned
linux (Ubuntu)
Medium
Unassigned

Bug Description

ThinkpadA20m running Dapper Flight3+.

Select Shutdown from System menu. Should power off machine (known to work properly as recently as 0131, perhaps more recently).

Now, gets as far as displaying message on console "will now power off", never powers off: screen is on, power inidcator light is on, all other activity appears stopped (no disk, no fan).

Recent possibly relevant changes:

0217: acpi-support (0.54) to 0.58
0215: acpid (1.0.4-1ubuntu8) to 1.0.4-1ubuntu10
0213: acpi-support (0.53) to 0.54
0213: ubuntu-minimal (0.97) to 0.98
0213: ubuntu-standard (0.97) to 0.98

(Of course, system has all other updates since Flight2 applied as well.)

Assigned to ACPI since this seems to be a power management issue.

Acer Aspire 5024WLMi.

I've got the same problem.
In Breezy the shutdown has worked (as well as in other distros, on other kernels), but doesn't work in Dapper any more (actually in none of the Dapper flight versions it worked).

When I turn off the computer:
 - it closes all the services running,
 - than shows the "will now halt" message,
 - than the screen goes blank, the fan is working (in the highest speed) and it doesn't turn off.

Soft:
  - kernel 2.6.15.5
  - acpi-support 0.59
  - acpid 1.0.4-1ubuntu10

Alexandre Payment (alp) on 2006-02-23
Changed in acpi:
status: Unconfirmed → Confirmed

20060303, all latest updates applied (kernel 2.6.15-17-686, gnome-power-manager 2.13.92+CVS20060302-0ubuntu1, acpi-support 0.59, acpid 1.0.4-1ubuntu10).

System, log out, shutdown powers off system when booting with acpi=force.

Default boot (apmd instead of acpid), still get screen not off and power indicator (the Thinkpad's {z} light) not off.

In general, ACPI=force seems more reliable than just a few days ago.

For me the "force" options doesn't work - it doesn't change anything.

I think the bug is related somehow with xserver, because when I didn't start the xserver, then the "reboot" and "shutdown" have worked correctly.

My boot options:
boot/vmlinuz-2.6.15-18-amd64-generic root=/dev/hda11 ro console
=tty0 noapic noapci acpi=force quiet splash

This bug appears for me too on Bi-Opetron system, however I posted my comments in Bug #36158 , it seems to be another report for the same problem.

Hannes Ovrén (kigurai) wrote :

I have a similar bug, but my computer hangs at "Sending all the processes the TERM signal".

With:
/boot/vmlinuz-2.6.15-20-amd64-generic root=/dev/hda11 ro console
=tty0 quiet splash

(no "noapic" and no "noapci" tags)

... it works correctly for me (Acer Aspire 5024WLMi).

Asraniel (asraniel) wrote :

it does not with the travelmate 8100 here.
it powers down, everything is shutoff, expect the screen (which is black, but powered on) and a few other things i cant remember.
This is a very critical issue, it nearly killed my laptop twice because i put it in my backpack, while it was still on. the laptop was very hot when i took him out..

Asraniel (asraniel) wrote :

with travelmate 8103

Asraniel (asraniel) wrote :

it gets realy annoying, and is a danger for the laptop because of overheating

Asraniel (asraniel) wrote :

the laptop can overheat and die because of things like that

Phil Bull (philbull) wrote :

Assigning to desktop-bugs for comments.

Changed in acpi:
assignee: nobody → desktop-bugs
Phil Bull (philbull) wrote :

Could someone attach a copy of the dmesg output from around the time of this hang please?

Thanks

Asraniel (asraniel) wrote :

how can we do that? i mean before the hang it does not mean much. should we just reboot and them make the dmesg command?

Phil Bull (philbull) wrote :

Hmmm, could you attach the dmesg output from just after boot-up and maybe /var/log/acpid too. I think this issue will be pretty tricky to debug.

Patrik Jansson (patrikja) wrote :

Confirmed (for Vaio VGN-S4HP laptop, Dapper beta): poweroff worked fine for Breezy, but does not work after dist-upgrade. For me most things are still on and the fan goes up to maximum after the last message in the shut-down sequence.

Also, the "lock screen" which Breezy did at lid-close no longer does anything.

Linux utca 2.6.15-21-386 #1 PREEMPT Fri Apr 21 16:43:33 UTC 2006 i686 GNU/Linux

patrikj@utca:~$ more /proc/cmdline
root=/dev/sda3 ro quiet

Matt Zimmerman (mdz) wrote :

Please don't assign bugs; this is clearly not a desktop issue.

Please tell us which kernel last worked correctly for you

Changed in acpi:
assignee: desktop-bugs → nobody
Asraniel (asraniel) wrote :

it never worked for me in dapper, i tested since flight 5. in breezy it works as it should.$

i would like to add that it shuts down the computer correctly 30% of the time. but most of the time it does not.

Download full text (3.2 KiB)

Matt Zimmerman skrev:
> Please don't assign bugs; this is clearly not a desktop issue.
>
>
Sorry - this was my first use of Launchpad (I probably should have read
some documentation first). I did not conciously "assign" the bug in any
way - I just added a comment to the already existing bug report without
changing any default values.

> Please tell us which kernel last worked correctly for you
>
> ** Changed in: acpi (Ubuntu)
> Sourcepackagename: acpi => linux-source-2.6.15
> Assignee: Ubuntu Desktop Bugs => (unassigned)
>
with Ubuntu, kernel 2.6.12-9-386 poweroff worked (and still does when I
just tried even though many other errors are generated by booting the
dapper beta system with the breezy kernel). Some differences between the
dmesg for the old and new boot are below. (I grepped for ACPI, tried to
reorder into the same order and noted the differences.)

Tell me if I should submit any more data or try something else.

/Patrik

dapper beta:
ACPI: Subsystem revision 20051216
ACPI: bus type pci registered
ACPI: Looking for DSDT ... not found!
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
ACPI: Embedded Controller [EC0] (gpe 23) interrupt mode.

ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 19 (level, low) -> IRQ 225
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 17 (level, low) -> IRQ 217
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 225
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 21 (level, low) -> IRQ 177
ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 17 (level, low) -> IRQ 217
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 209
ACPI: PCI Interrupt 0000:00:1f.1[B] -> GSI 18 (level, low) -> IRQ 201
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 18 (level, low) -> IRQ 201
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 169
ACPI: PCI Interrupt 0000:06:05.0[A] -> GSI 21 (level, low) -> IRQ 177
ACPI: PCI Interrupt 0000:06:05.0[A] -> GSI 21 (level, low) -> IRQ 177
ACPI: PCI Interrupt 0000:06:05.2[C] -> GSI 20 (level, low) -> IRQ 233
ACPI: PCI Interrupt 0000:06:08.0[A] -> GSI 20 (level, low) -> IRQ 233
ACPI: PCI Interrupt 0000:06:0b.0[A] -> GSI 22 (level, low) -> IRQ 50

breezy:
ACPI: Subsystem revision 20050729
ACPI: bus type ide registered
ACPI: Embedded Controller [EC0] (gpe 23)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0

ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 21 (level, low) -> IRQ 21
ACPI: PCI Interrupt 0000:00:1d.3[A] -> GSI 17 (level, low) -> IRQ 17
ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 23 (level, low) -> IRQ 23
ACPI: PCI Interrupt 0000:00:1f.1[B] -> GSI 18 (level, low) -> IRQ 18
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 18 (level, low) -> IRQ 18
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
ACPI: PCI Interrupt 0000:06:05.0[A] -> GSI 21 (level, low) -> IRQ 21
ACPI: PCI Interrupt 0000:06:...

Read more...

Ahmed Kamal (kim0) wrote :

I agree to the "shuts down the computer correctly 30% of the time". It's just flaky!!

It was getting better, but now it's worse.
Hardware: Toshiba Satellite A105-S361 laptop.
reboot=h seems to help but not all the time

Phil Bull (philbull) wrote :

Apologies mdz/Patrik, I made the bad assignment.

Sorry...

Indkoeti (nicolas-vogt) wrote :

Hello, have the same problem with my toshiba Satellite M40. But it allredy didn't work in breezy

Indkoeti (nicolas-vogt) wrote :

Sorry forget to tell you, although it dind't work in breezy it works with FC5, suse 10.0 and gentoo

The workaround mentioned by Roax (boot with acpi=force) is inappropriate in this case owing to ACPI-related problems on this laptop (ThinkPad A20m, 1999 BIOS). While booting with acpi=force is largely successful (save for some messages re modules not loaded to prevent EPROM damage), and while performance with acpi=force "seems better", S3 sleep is unreliable (recorded in other bugs).

So for the moment I am stuck with manually turning the machine off once "shutdown" is "complete". Ironically, restart works fine, the machine powers itself off and on again.

Note: Bug continues with latest Dapper (all updates as of 20060516) applied.

Onkar Shinde (onkarshinde) wrote :

After latest update of acpi-support in dapper I faced similar problem with shutdown. Mine was hanging at the stage of shutting down LVM. I removed LVM (which wasn't needed anyway) and it is working perfectly now.

I will try to verify this on my PC and let you guys know. Meanwhile should I mark this as acpi-support bug?

Onkar Shinde (onkarshinde) wrote :

Wrong package. This is related to ACPI. So rejected

Changed in linux-source-2.6.15:
status: Confirmed → Rejected
Changed in acpi:
status: Unconfirmed → Confirmed
Matthew Garrett (mjg59) wrote :

No, really, acpi bugs belong to the kernel. "acpi" is a small tool that prints out information about acpi status.

Changed in linux-source-2.6.15:
status: Rejected → Confirmed
Changed in acpi:
status: Confirmed → Rejected
Peter Whittaker (pwwnow) wrote :

FYI, when I opened this bug, I misassigned it because I didn't understand the wheres and hows of power management: My laptop WAS NOT and IS NOT running ACPI, it is running APM. This is most definitely not an ACPI bug, ACPI is (most likely) a red herring, at least in my case. As Matthew points out, this belongs in kernel land.

Frank Bennett (biercenator) wrote :

I am experiencing this same problem on a desktop. The machine is based on an AOpen i945GTm-VHL motherboard that uses laptop memory and a Pentium-M cpu. I'm using a TV for the monitor, and the display is lost (sync rate issue maybe) as the machine goes down, so I haven't a clue where in the process it hangs. It fails to power off a little over 50% of the time.

This particular box is running MythTV, and it's meant to be off when idle. Until this is solved, we'll be running it as a server, 24/7. If there is any other information I can supply that will help, let me know.

Frank Bennett (biercenator) wrote :

I should have mentioned above that the machine is running a custom compiled 2.6.17.13 kernel, with software suspend and acpi enabled, and apm disabled. The config is attached.

Markus Kienast (elias1884) wrote :

I have to confirm the not powering down bug for Edgy!

I get the message
[SOME.NUMBER] Power Down
but the system does not power down.

My Laptop showed this messages for several hours, since I did shutdown the machine and left at night without waiting for the laptop to actually power down. The next day it was still on and showing this message.

Hardware: Vaio VGN-S560P

Breezy did the same, Dapper worked while there was some delay between the moment it could power down (for example when hibernate did turn of the HDD) and the actual power down.

Markus Kienast (elias1884) wrote :

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this linux-source-2.6.15 kernel bug to the new "linux" package. We appreciate your patience and understanding as we make this transition. Also, if you would be interested in testing the upcoming Intrepid Ibex 8.10 release, it is available at http://www.ubuntu.com/testing . Please let us know your results. Thanks!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions