Bug 246201

Summary: X eats 100% CPU time when going into DPMS' display suspend mode
Product: [Fedora] Fedora Reporter: CHIKAMA Masaki <masaki.chikama>
Component: xorg-x11-drv-siliconmotionAssignee: Adam Jackson <ajax>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: dwayne, mcepl, triage, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 05:56:44 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 Flags
mentioned Xorg.0.log file none

Description CHIKAMA Masaki 2007-06-29 06:43:40 UTC
Description of problem:
X Window Session becomes unresponsive when the XScreenSaver kicks in and then
goes into Suspend mode.  Both the keyboard and mouse becomes unresponsive. 
(same problem with https://bugs.freedesktop.org/show_bug.cgi?id=11325)

Version-Release number of selected component (if applicable):
xorg-x11-drv-siliconmotion-1.5.1-1.fc7

How reproducible:
always


Steps to Reproduce:
1. start x server
2. wait for display is suspend mode
3.
  
Actual results:
X server totaly unresposable.

Expected results:


Additional info:
Xorg.log is the same as Bug 244622.

Gdb's backtrace information when eating 100% CPU.
mmioReadST01 (hwp=0x823e000) at vgaHW.c:420
420     }
(gdb) bt
#0  mmioReadST01 (hwp=0x823e000) at vgaHW.c:420
#1  0x080c9b39 in DPMSSet (level=1) at xf86DPMS.c:168
#2  0x081b7725 in ScreenSaverTimeoutExpire (timer=0x82a7c80, now=1979878670,
    arg=0x0) at WaitFor.c:637
#3  0x081b7a14 in DoTimer (timer=0x82a7c80, now=3084518362, prev=0xb7da0000)
    at WaitFor.c:465
#4  0x081b818f in WaitForSomething (pClientsReady=0xbfffe560) at WaitFor.c:296
#5  0x080898dd in Dispatch () at dispatch.c:383
#6  0x08071735 in main (argc=10, argv=0xbfffea84, envp=Cannot access memory at
address 0xb7da0008
) at main.c:445
(gdb) i r
eax            0xff     255
ecx            0xb7da0000       -1210449920
edx            0xb7da03da       -1210448934
ebx            0xe3e3f8 14935032
esp            0xbfffe21c       0xbfffe21c
ebp            0xbfffe258       0xbfffe258
esi            0x823f210        136573456
edi            0xff     255
eip            0x184329 0x184329 <mmioReadST01+25>
eflags         0x3282   [ SF IF #12 #13 ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51

it seems looping in src/smi_driver.c line 3248 or 3249.

http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-siliconmotion.git;a=blob;h=5c7124f2799dadfd241b41cbfc37e3320cbf29e9;hb=1a803a8f91a931c00106f9d3d41cfa5d74c19f55;f=src/smi_driver.c

Comment 1 Matěj Cepl 2007-06-29 14:33:36 UTC
Created attachment 158211 [details]
mentioned Xorg.0.log file

Comment 2 CHIKAMA Masaki 2007-07-02 07:31:39 UTC
It seems something wrong in xf86ExecX86int10 src/mi_driver.c line 3161.
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-siliconmotion.git;a=blob;h=5c7124f2799dadfd241b41cbfc37e3320cbf29e9;hb=1a803a8f91a931c00106f9d3d41cfa5d74c19f55;f=src/smi_driver.c#l3161

It do success DPSM mode change using BIOS call, but result code (AX) doesn't
set properly. 

(gdb) p *(*(SMIPtr)(xf86Screens[0]->driverPrivate))->pInt10
$12 = {entityIndex = 0, scrnIndex = 0, cpuRegs = 0x57fee0, BIOSseg = 49152,
  inb40time = 0, BIOSScratch = 0x8245110 "\003P", Flags = 0,
  private = 0x82455a8, mem = 0x57f654, num = 16, ax = 20240, bx = 257, cx = 0,
  dx = 0, si = 0, di = 0, es = 0, bp = 0, flags = 12800, stackseg = 4096,
  Tag = 18432, ioBase = 0}

(I get this trace in infinity loop at line 3248. The ax should be 0x4f.)

After calling DPMS BIOS, the mmio-read stop working and go to infinity loop.

But this doesn't BIOS bug, because vbetool
(http://freshmeat.net/projects/vbetool/)
returns the proper(0x4f) result value and a mode witching works fine.

For now my workaround is to add "Option UseBIOS off" to xorg.conf.

Comment 3 Dwayne Bailey 2007-07-26 09:30:16 UTC
I seem to be experiencing the same what I think is the same problem.  Everything
works perfectly until the screensaver kicks in, mine simply blanks the screen. 
When it does that you cannot access X.  You can login remotely and then X is
sitting at 90+% cpu usage.   I can then kill X and log in again.

I'm happy to supply whatever data can help to fix this problem.  At the moment
its making my laptop usage frustrating!

I eventually removed all traces of old X.conf and got it rebuilt but the problem
persists.  I'm using gnome-screensaver but I assume its using most of
xscreensaver anyway so it is the same problem.

Comment 4 Bug Zapper 2008-05-14 13:19:38 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 5 CHIKAMA Masaki 2008-05-15 01:48:45 UTC
While I can't check on rawhide beacuase of Bug #443544,
I suppose this bug still be there.

Comment 6 Bug Zapper 2008-11-26 01:56:23 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Bug Zapper 2009-11-18 09:32:06 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Bug Zapper 2009-12-18 05:56:44 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.