Bug 498514 - hald-addon-input appears to make really difficult shutting down from a desktop session
Summary: hald-addon-input appears to make really difficult shutting down from a deskto...
Keywords:
Status: CLOSED DUPLICATE of bug 495326
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-30 20:11 UTC by Michal Jaegermann
Modified: 2009-05-01 20:29 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-01 20:29:25 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
a fragment of logs showing tasks after an attempted shutdown (200.88 KB, text/plain)
2009-04-30 20:11 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2009-04-30 20:11:17 UTC
Created attachment 341992 [details]
a fragment of logs showing tasks after an attempted shutdown

Description of problem:

After 'shutdown -h now', or after shutdown from a gdm menu, a system shuts down and powers off as expected.  Unfortunately this is not the case when attempting to use that from a menu on a desktop session.  A procedure is started and later on on text consoles it is possible to find a broadcast message:

The system is going down for halt NOW!

three or four times. A remote login after that is cut off and there is no more local shells available. That is it.  The system sits there and does nothing.
SysRq key, when turned on, is still active and it is possible to force a reboot that way.  Otherwise a power switch is the only remaining option.

With "show-blocked-tasks" from SysRq it looks like that a system sits
in hald-addon-input probably waiting for some event from a kernel.

Attached is everything which was registered in /var/log/messages after
attempted shutdown and when, after a system got catatonic, "show-task-states"
and "show-blocked-tasks" from SysRq was hit.  It is obvious that some output fragments never made to a disk (but that was possible to see only after a reboot).

Version-Release number of selected component (if applicable):
hal-0.5.12-26.20090226git.fc11.x86_64
kernel-2.6.29.1-111.fc11.x86_64
xorg-x11-drv-ati-6.12.2-7.fc11.x86_64
upstart-0.3.9-24.fc11.x86_64

How reproducible:
Most of the times I tried.  Initially I got that every time but when I tried to check if 'nomodeset' in boot parameters makes a difference (it does not appear to be any) a machine shut down as it was supposed to.

It appears that it is harder to repeat that hang with 2.6.29.1-102.fc11.x86_64 kernel, but not impossible, and with it at least once I got "reboot" when asking for "shutdown".  Some kind of a race between kernels and hal?

Additional info:
Selinux is not involved as on the affected system it is turned off.

Comment 1 Gianluca Cecchi 2009-05-01 11:06:59 UTC
I have the same on my laptop (Dell XPS M1330) but it happens only when I follow these steps:
1) at boot I stop grub and I add "3" to the kernel line so that I boot in runlevel 3 (sometimes when I want to change xorg.conf file)
2) in console mode I run "init 5" and I go in gdm
3) I login and work
4) At the end of my work I Select System -> Shutdown -> shutdown
5) It goes to console mode with the message 
The system is going down for halt NOW!

But it remains there

6) Only if I press the power button of the laptop it goes through the complete shutdown procedure

Comment 2 yunus 2009-05-01 17:00:27 UTC
recently I also have this issue on TravelMate 6291 laptop. I don't remember what package that causes this issue since I always perform full update. This issue really annoys me.

Do not hesitate to request for info from to solve this bug.

Thank you

Comment 3 Bill Nottingham 2009-05-01 20:29:25 UTC

*** This bug has been marked as a duplicate of bug 495326 ***


Note You need to log in before you can comment on or make changes to this bug.