| Summary: | [PATCH]X server takes 100% CPU, in endless select()/read() loop | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Max Kellermann <max> | ||||
| Component: | Protocol/Core | Assignee: | Xorg Project Team <xorg-team> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | high | CC: | erik.andren, shrek | ||||
| Version: | 6.9.0 | Keywords: | patch | ||||
| Hardware: | x86 (IA32) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | |||||||
| i915 platform: | i915 features: | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 5041 | ||||||
| Attachments: |
|
||||||
the nvidia driver is totally capable of feeding file descriptors to the main loop. it would be helpful if you could figure out what program is on the other end of fd 3 when this happens. I just found a way to reproduce that easily - the X server was connected to the ACPI daemon on file descriptor 3 (/var/run/acpid.socket). When I stopped acpid, the X server entered the state of 100% CPU consumption. Restarting acpid does not fix that once it happened. Could have happened after acpid upgrades.. Created attachment 4829 [details] [review] xorg-x11-6.8.99.901-alt-acpi.patch this patch fixed problem with ACPI Marking topic as patch. Added patch keyword (In reply to comment #3) > Created an attachment (id=4829) [edit] > xorg-x11-6.8.99.901-alt-acpi.patch > > this patch fixed problem with ACPI Is there a reason you dropped support for reading /proc/acpi/event directly? I think i'm fine with the idea of requiring acpid to be running but I'd like to know if there's a tradeoff involved. system with /proc/acpi/event usually have working acpid. however, if X server would start before acpid, then acpid couldn't start. applied with minor fixups, thanks! |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Debian X.org packages 6.9.0.dfsg.1-3 on AMD64 (Athlon64 X2), Linux 2.6.15.1, NVidia non-free driver 1.0-8174. After several days, the X server shows as using 100% CPU in top. It still works well, and due to my CPU being dual core, this is not noticeable. An strace revealed that he was reading from a socket over and over: select(256, [1 3 4 9 15 16 17 18 19 20 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 56 57 59 62], NULL, NULL, {0, 498000}) = 1 (in [3], left {0, 500000}) read(3, "", 80) = 0 There are other bug reports on X.org using 100% CPU, but my strace indicated this bug is different. I also believe (and hope) this hasn't got anything to do with the closed source nvidia driver, as this seems to happen in the main loop.