Bug 794478
Summary: | [abrt] kernel: BUG: soft lockup - CPU#0 stuck for 185s! [lxdm-binary:744] | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | John Dulaney <jdulaney> | ||||
Component: | lxdm | Assignee: | Christoph Wickert <christoph.wickert> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 17 | CC: | awilliam, bwalker, christoph.wickert, dgod.osa, frankly3d, gansalmon, hicham.haouari, itamar, jonathan, kernel-maint, madhu.chinakonda, robatino, sergei.litvinenko | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Unspecified | ||||||
Whiteboard: | abrt_hash:f57e2dc9ceb911988e249f2ee010b3fb96d1bf9d AcceptedNTH | ||||||
Fixed In Version: | lxdm-0.4.1-1.fc16 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-03-23 17:42:59 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: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 752652 | ||||||
Attachments: |
|
Description
John Dulaney
2012-02-16 22:39:14 UTC
Created attachment 563767 [details]
File: backtrace
this is yet another case of softlockup not working in virtual environments. boot with nosoftlockup for now, in absence of a better solution. Roger. there is work ongoing to make this problem a non-issue. https://lkml.org/lkml/2011/12/5/490 Okay, I think that there is something else going on here. The CPU load actually does stay at close to 100%, even when there is nothing going on (from a user standpoint). I have not seen CPU load drop below 80%, and it was only that low for a few moments. 100% cpu likely a bug in lxdm, appeared in f17 because of new version of glib, have been fixed in upstream. *** Bug 732266 has been marked as a duplicate of this bug. *** Changing component to lxdm and proposing for Beta NTH. I'll look at this later today. I don't know if it's happening with bare metal or not, but it seems to occur all the time in VMs. Yes, it does occur on bare metal, too. See bug 767861 Cristoph: Poke me if I can provide anything else or if you want me to test. Discussed at 2011-03-02 blocker/NTH review meeting. Accepted as NTH due to significant impact on usability of LXDE desktop (100% CPU usage persists after logging in). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers dgod.osa, wha about the problem with switching VTs? Without this problem I would already have shipped an update. I don't see any desc of "about the problem with switching VTs", do you mean the lxdm default use the vt7? if this, modify the server command line just now. I did modify the config to use vt1 by default - but then LXDM doesn't start on boot. It is started when I run /usr/sbin/lxdm manually though. I have no problem,maybe you can give your lxdm rpm file. Sure, here are some scratch builds: Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=3916580 F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3916592 F16: http://koji.fedoraproject.org/koji/taskinfo?taskID=3916607 F15: http://koji.fedoraproject.org/koji/taskinfo?taskID=3916647 I see you modify the vt1 in patch, but you don't apply the patch to rpm. If you install or extract the rpm, view /etc/lxdm.conf in it, you will find it not changed. That is correct, I don't apply the patch to change the configuration because if I do and change to vt1, lxdm will not start reliably. It will not start on boot of after changing the runlevel, however it will start if I call lxdm as root directly. Did you try one of my packages? Can anybody else confirm these packages work or don't with console set to vt1? I try the lxdm-0.4.1-1.fc17.x86_64.rpm I can boot with or without set to vt1. if change runlevel in console with "init 5" 1 set to vt1, lxdm started at vt1 and screen chagned to vt1 2 not set to vt1, lxdm start at vt7 and screen not changed to vt7 I don't think there are any problem. I tested a little further and I still have problems but they only happen with my external display attached. With only one display everything is fine, so I will push the updates ASAP. lxdm-0.4.1-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/lxdm-0.4.1-1.fc17 lxdm-0.4.1-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/lxdm-0.4.1-1.fc16 lxdm-0.4.1-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/lxdm-0.4.1-1.fc15 Package lxdm-0.4.1-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lxdm-0.4.1-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4399/lxdm-0.4.1-1.fc16 then log in and leave karma (feedback). Ok, it seems to be working here without huge cpu load. lxdm-0.4.1-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. lxdm-0.4.1-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. lxdm-0.4.1-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |