Bug 498514
| Summary: | hald-addon-input appears to make really difficult shutting down from a desktop session | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||
| Component: | hal | Assignee: | Richard Hughes <richard> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | rawhide | CC: | gianluca.cecchi, notting, richard, yunus.tji.nyan | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-05-01 20:29:25 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 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 *** This bug has been marked as a duplicate of bug 495326 *** |
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.