| Summary: | Xorg slow when acpid running | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Olivier LAHAYE <aol002> | ||||||
| Component: | Server/DDX/Xorg | Assignee: | Xorg Project Team <xorg-team> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | major | ||||||||
| Priority: | high | CC: | jesserayadkins, malattia | ||||||
| Version: | 6.8.99.903 (6.9 RC3) | Keywords: | patch | ||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
*** Bug 5139 has been marked as a duplicate of this bug. *** Problem still present in 6.8.99.903 release. This is caused by repetitous calling of lnxACPIGetEventFromOs on socked from acpid after acpid has exited. I.e. return status of read() should be checked. In my case, it's reproducible by starting X server, running xterm and make /etc/init.d/acpid stop. CPU is eaten to 100%. Created attachment 4216 [details] [review] Disable ACPI event reporting on any read() error This patch simply disables ACPI event reporting if an error or EOF is returned from the read() call for whatever the FD was (either acpid's socket or kernel's /proc/acpi/event). A differrent approach could implement (re)opening /proc/acpi/event on EOF as that can only happen when using acpid socket because if ACPI is enabled in the kernel the /proc/acpi/event is always compiled in. Will try to implement it shortly. Created attachment 4217 [details] [review] Try to re-lnxACPIOpen() if an error happens while read()-ing This patch tries to re-open the ACPI event handler if an error condition arises while read()-ing. Such error can only happen on acpid's socket as the kernel will always provide /proc/acpi/event if ACPI is enabled. Still a finer errno management could be done (EINTR?) but I can't tell if it would be useful or not. (In reply to comment #5) > Try to re-lnxACPIOpen() if an error happens while read()-ing Obviously this will prevent acpid (or any other acpi-event deamon) from restarting. /proc/acpi/event contention is really an ugly thing... I belive this is fixed in 7.1. Please try it and see if it resolves your issue. Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future. Assuming it was fixed in 7.1. Reopen if it persists. (In reply to comment #9) > Assuming it was fixed in 7.1. Reopen if it persists. > I'm using 7.2 from Debian, I just tried restarting acpid and the bug is still there. (In reply to comment #10) > (In reply to comment #9) > > Assuming it was fixed in 7.1. Reopen if it persists. > > > > I'm using 7.2 from Debian, I just tried restarting acpid and the bug is still > there. In the event that you're still having this issue, can you attach your Xorg.log with logverbose set so that you'll catch all messages? (-logverbose 9 will work). I've got xserver 1.9.0 and I'm not seeing this. Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server. |
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.
SUMUP: acpi (maybe acpid?) makes X server extremely slow on certain operations (can be observed when using vmware). More details below. When booting normaly (acpid started before dm), the X server is not running correctly (despite the fact that from the user point of view, everything seems correct). The problem can be observed when using vmware running WinXP: typing in a cmd.exe is extremely slow. BUT, if I issue a service acpid stop, then vmware runs at full speed. It's NOT a vmware problem as the problem can be traced without using vmware. vmware is only a tool to observe the problem. if acpid is started befor X, then I strace X, I've the following trace (looping) --------------------------------------------------- select(256, [1 3 4 5 6 14], NULL, NULL, {1, 0}) = ? ERESTARTNOHAND (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 sigreturn() = ? (mask now []) gettimeofday({1132651336, 426779}, NULL) = 0 gettimeofday({1132651336, 426799}, NULL) = 0 select(256, [1 3 4 5 6 14], NULL, NULL, {0, 979000}) = 0 (Timeout) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 gettimeofday({1132651337, 405654}, NULL) = 0 gettimeofday({1132651337, 405675}, NULL) = 0 gettimeofday({1132651337, 405696}, NULL) = 0 --------------------------------------------------- If I kill acpid (service acpid stop) then speed becomes normal and the trace looks like: --------------------------------------------------- select(256, [1 3 4 5 6 14], NULL, NULL, {0, 967000}) = 1 (in [5], left {0, 967000}) read(5, "", 80) = 0 gettimeofday({1132651348, 438712}, NULL) = 0 gettimeofday({1132651348, 438732}, NULL) = 0 --------------------------------------------------- but it seems that X eats 100% of CPU time despite the fact that now, applications like vmware runs at full speed.... realy strange. (linked with https://bugs.freedesktop.org/show_bug.cgi?id=4718 ?) The vmware package is VMwarePlayer-1.0.0-18007 used when discovering the problem, but vmware full release is also afected, and I think that many other X programms are affected as "strace X" 2>/tmp/debug.log revelals the problem without anything running on the X server. I've also reported the bug at Mandriva http://qa.mandriva.com/show_bug.cgi?id=19914