Bug 494245
Summary: | X server deadlock | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Woodhouse <dwmw2> | ||||
Component: | xorg-x11-drv-evdev | Assignee: | Peter Hutterer <peter.hutterer> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 11 | CC: | bojan, kcrashcore, mcepl, mcepl, peter.hutterer, xgl-maint | ||||
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-11-05 22:45:20 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: |
|
Description
David Woodhouse
2009-04-05 23:38:00 UTC
Turns out the evdev driver _does_ check for errno == ENODEV. But only if the read() call returns zero. Not if it returns -1. Doh. There are still plenty of opportunities for deadlock even if we fix that, though. comment #2 fixed in xorg-x11-drv-evdev-2.2.1-2. http://koji.fedoraproject.org/koji/taskinfo?taskID=1278824 For the rest - if I read this right this would mean we must not print anything to the logs during the signal handler since xf86Msg will always allocate for the matching verbosity string. I need to check this further. (In reply to comment #2) > For the rest - if I read this right this would mean we must not print anything > to the logs during the signal handler since xf86Msg will always allocate for > the matching verbosity string. That seems to be the case. I had to downgrade evdev to 2.2.1-1 because X was locking up for 3-5 minutes at 100% load every time my bluetooth kb or mouse woke up from sleep. wait, you're saying -2 locks up and -1 doesn't? -1 still locks up, just not for as long. not sure what the change was that started it. changed kernels, dongles and evdev so far but have not had time to look further. I think Carlos' version of "locks up" is different to mine. Mine is a deadlock in glibc which I don't think it's ever going to recover from. It sounds like it might just be that in Carlos' case it takes a long time to re-open the Bluetooth input devices when they reconnect. I've seen similar behaviour. Carlos, is the X server _completely_ dead while this is happening? Do you have any non-Bluetooth input devices? Does the on-screen clock or anything else update while it's "locked up"? There are various other bugs with removal and addition of Bluetooth devices, including the one described in bug #494246, which means that removal events from the kernel have the wrong path and thus HAL never realises the device went away. So you get new devices being added which share /dev/inputX device nodes with other devices that HAL thinks exist. Carlos, can you show /var/log/Xorg.0.log from after this has happened? I'm seeing this on F-10 folks. Same SIGALRM/Interrupted system call loop in strace. It happens completely intermittently, X locks up and the screen is not released even if I kill it hard. Switching to RL 3 also doesn't help. Please note: I do not remove _any_ devices - it just decides to do this on its own. I'll attach the Xorg.0.log.old file. Created attachment 339762 [details]
X stuck in an infinite loop
One other detail, if it matters. I hibernate/thaw at least once a day and as you can see from the log, the X server was started 2 days ago, when this last happened. Bojan: please open a separate bug for this issue. It's not related to evdev, the server is stuck in drmCommandWrite. Thanks. Bug #496019 submitted. Should be fixed with evdev 2.2.1-3. http://koji.fedoraproject.org/koji/taskinfo?taskID=1301448 This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] Closing per comment 13. Please reopen if the issue still persists. |