Bug 472310

Summary: [radeon.modeset] Screen locks, only hardware reset helps on x1100 (rs485)
Product: [Fedora] Fedora Reporter: Joshua Covington <joshuacov>
Component: kernelAssignee: Dave Airlie <airlied>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 10CC: kernel-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 06:53:43 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
Xorg.0.log from f9
none
Xorg.0.log from 2.6.27.5-120.fc10.x86_64 before a crash
none
dmesg from 2.6.27.5-120.fc10.x86_64 before a crash
none
Xorg.0.log.old after the crash on f9
none
dmesg.old after the crash on f9
none
dmesg-2.6.27.7-135.fc10.x86_64
none
Xorg.0.log-2.6.27.7-135.fc10.x86_64
none
dmesg-2.6.27.10-167.fc10.x86_64 with radeon.gartsize=256
none
Xorg.0.log-2.6.27.10-167.fc10.x86_64 with radeon.gartsize=256
none
dmesg-2.6.27.10-167.fc10.x86_64-1
none
messages-2.6.27.10-167.fc10.x86_64-1
none
dmesg-2.6.27.10-167.fc10.x86_64-2
none
lspci -vvn
none
iomem gartsize=128 debug=1
none
Xorg.0.log-2.6.27.10-167.fc10.x86_64 drm.debug=1 radeon.gartsize=128
none
messages-2.6.27.19-170.2.30.rc1.fc10.x86_64
none
dmesg-2.6.27.19-170.2.30.rc1.fc10.x86_64
none
Xorg.0.log-2.6.27.19-170.2.30.rc1.fc10.x86_64 none

Description Joshua Covington 2008-11-19 23:24:38 UTC
Description of problem:

I have a strange problem with my fedora.
On f10 my screen turns into 2-color strips (in almost 95% of the time) and only hardware reset helps me get rid of it. It happes randomly, but I'm almost 100% sure that the screen will block in the first 30mins from the start. Until recently this had only happened on F10 but in the last 2 days I got it 3 times on my f9 machine. I looked into the xorg-x11-drv-ati but f10 uses more updated version. the xorg-server is almost the same. but the kernel has modeseting in f10.
 The error doesn't occurr in f10 when nomodeset is used. the dmesg in f9 doesn't show anything. the xorg.0.log in f9 looks ok (compared to earlier logs when this didn't occurr).
The computer stops for a seccond and then the screen turns into the strips - no mouse, no keyboard responce.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. install latest f10 kernel on rs485m
2. wait less than 30 mins
3.
  
Actual results:


Expected results:


Additional info:
lspci:
01:05.0 VGA compatible controller: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP] (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Unknown device 010f                                                      
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-       
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-      
        Latency: 66 (2000ns min), Cache Line Size: 32 bytes                                                         
        Interrupt: pin A routed to IRQ 17                                                                           
        Region 0: Memory at c8000000 (32-bit, prefetchable) [size=128M]                                             
        Region 1: I/O ports at 9000 [size=256]                                                                      
        Region 2: Memory at c0100000 (32-bit, non-prefetchable) [size=64K]                                          
        [virtual] Expansion ROM at c0120000 [disabled] [size=128K]                                                  
        Capabilities: [50] Power Management version 2                                                               
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)                          
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-                                                         
        Kernel modules: radeonfb

Comment 1 Joshua Covington 2008-11-19 23:26:15 UTC
Created attachment 324115 [details]
Xorg.0.log from f9

Comment 2 Joshua Covington 2008-11-20 16:46:05 UTC
Created attachment 324200 [details]
Xorg.0.log from 2.6.27.5-120.fc10.x86_64 before a crash

Comment 3 Joshua Covington 2008-11-20 16:48:50 UTC
Created attachment 324201 [details]
dmesg from 2.6.27.5-120.fc10.x86_64 before a crash

Comment 4 Joshua Covington 2008-11-20 19:24:45 UTC
Created attachment 324221 [details]
Xorg.0.log.old after the crash on f9

Comment 5 Joshua Covington 2008-11-20 19:25:50 UTC
Created attachment 324222 [details]
dmesg.old after the crash on f9

Comment 6 Joshua Covington 2008-11-22 00:22:36 UTC
i tried xorg-x11-drv-ati-6.9.0-54.fc10 and with this version the screen doesn't turns into 2-color-strips. the display stays the was it was. In my opinion this happens when I try to open too many windows. Maybe a memory issue?

Comment 7 Bug Zapper 2008-11-26 05:38:30 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 8 Joshua Covington 2008-12-06 06:40:33 UTC
Created attachment 325967 [details]
dmesg-2.6.27.7-135.fc10.x86_64

This is a regression. I cannot start without nomodeset with this kernel. dmesg and Xorg.0.log attached

Comment 9 Joshua Covington 2008-12-06 06:43:17 UTC
Created attachment 325968 [details]
Xorg.0.log-2.6.27.7-135.fc10.x86_64

The corresponding Xorg.0.log file to the previous message.

Comment 10 Joshua Covington 2008-12-06 06:50:25 UTC
I think this has something to do with the xserver. modesetting actually works fine until the moment when the xserver is started. then i get black and white stripps (identical every time). Or maybe it is the ati driver. it worked fine until 6.9.0-54. installed are:

xorg-x11-server-common-1.5.3-5.fc10.x86_64
xorg-x11-server-utils-7.4-3.fc10.x86_64
xorg-x11-server-Xorg-1.5.3-5.fc10.x86_64
xorg-x11-drv-ati-6.9.0-61.fc10.x86_64

I tried this on another another rs482 (it's a live image with the lattes kernel and ati driver) - no problems there. Is this a specific problem to my pc?

Comment 11 Joshua Covington 2009-01-10 15:55:32 UTC
I have two mashines with the same rs485 and on paper they are identical. I've installed 4GB memory in one of them and 2GB in the other. The problematic card is in the mashine with 4GB (which happens to have a memory hole, too). IN the bios the card is configured to use 128MB from the main memory. Both mashines work fine untill the moment when the xserver should be started. Modesetting seems to work fine on both of them untill this moment.

Then on the mashine with 4GB I get my monitor distortion and the 2GB mashine works just fine. I used radeon.gartsize=32 and it seems to fix the problem on the laptop with 4GB.

Comment 12 Joshua Covington 2009-01-11 11:59:18 UTC
I did some more test with the machine with 4GB memory. When I remove 2Gb then it works fine. No problems at all, but with 4GB the problem occurs again. I tried setting radeon.gartsize=32/64/128/256 (in bios it is set to 128MB) and the computer boots without problem. Even with gartsize=256.

This makes me think that the xserver cannot determine the gartsize when starting up, because the kms works in all the cases, until the moment the xserver should be started. In my case the xserver needs to see any value set to gartsize in order to start properly.

I've attached the dmesg and the Xorg.0.log files with radeon.gartsize=256.

Comment 13 Joshua Covington 2009-01-11 12:00:45 UTC
Created attachment 328656 [details]
dmesg-2.6.27.10-167.fc10.x86_64 with radeon.gartsize=256

Comment 14 Joshua Covington 2009-01-11 12:02:01 UTC
Created attachment 328657 [details]
Xorg.0.log-2.6.27.10-167.fc10.x86_64 with radeon.gartsize=256

Comment 15 Dave Airlie 2009-01-11 23:22:23 UTC
just a note the BIOS specifies the stolen VRAM size which is completely separate to the GART size the driver is using. So it appears gartsize=512 (the default) causes the problem.

Can I get a dmesg boot with drm.debug=1 with no gartsize option and with gartsize

also an lspci -vvn with 4GB of RAM in the machine, and cat /proc/iomem

Comment 16 Joshua Covington 2009-01-12 16:24:26 UTC
Created attachment 328755 [details]
dmesg-2.6.27.10-167.fc10.x86_64-1

drm.debug=1 radeon.gartsize=128. Gartsize=512 doesn't work.

Comment 17 Joshua Covington 2009-01-12 16:27:23 UTC
Created attachment 328757 [details]
messages-2.6.27.10-167.fc10.x86_64-1

more messages gartsize=128

Comment 18 Joshua Covington 2009-01-12 16:28:13 UTC
Created attachment 328758 [details]
dmesg-2.6.27.10-167.fc10.x86_64-2

dmesg with drm.debug=1

Comment 19 Joshua Covington 2009-01-12 16:28:52 UTC
Created attachment 328760 [details]
lspci -vvn

Comment 20 Joshua Covington 2009-01-12 16:29:36 UTC
Created attachment 328761 [details]
iomem gartsize=128 debug=1

Comment 21 Joshua Covington 2009-01-12 16:30:38 UTC
Created attachment 328762 [details]
Xorg.0.log-2.6.27.10-167.fc10.x86_64 drm.debug=1 radeon.gartsize=128

Comment 22 Joshua Covington 2009-01-12 16:33:42 UTC
Maybe this is a bios problem. with 2gb it works fine but the same radeon/xserver/drm code doesn't like 4GB.

Comment 23 Joshua Covington 2009-01-20 09:50:06 UTC
Anything else I can do to help with this? Testing?

Comment 24 Joshua Covington 2009-02-12 20:17:00 UTC
Anything new here? It's almost a month.

By the way, my card id is 1002:5975 and it's advertised as radeon xpress 1100. Thechip should be rs482. I look at the lastest (in koji) radeon-6.10.0-2.fc10 and there i see rs482:5974 and rs485:5975. maybe my card's id isn't in the configs and therefore the driver cannot properly set it and uses some general settings that result in errors.

Comment 25 Joshua Covington 2009-02-21 12:29:09 UTC
I tried the latest xorg-x11-drv-ati-6.11.0 from http://lists.x.org/archives/xorg-driver-ati/2009-February/008479.html and I was surprised. The bug has been fixed in it. And it has LOTS of improvements. The hardware exceleration finally works even with kms enabled. It's still not as fast as it should be that's a great step forward compared to 6.10.0-2.

There are also some problems with the compiz effects and others but the main bug has been fixed. I've attached the dmesg, xorg.0.log and messages with the latest kernel-2.6.27.19-170.2.30.rc1.fc10.x86_64. Great work!

Comment 26 Joshua Covington 2009-02-21 12:30:11 UTC
Created attachment 332823 [details]
messages-2.6.27.19-170.2.30.rc1.fc10.x86_64

Comment 27 Joshua Covington 2009-02-21 12:31:00 UTC
Created attachment 332824 [details]
dmesg-2.6.27.19-170.2.30.rc1.fc10.x86_64

Comment 28 Joshua Covington 2009-02-21 12:32:01 UTC
Created attachment 332825 [details]
Xorg.0.log-2.6.27.19-170.2.30.rc1.fc10.x86_64

Comment 29 Bug Zapper 2009-11-18 07:58:54 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 30 Bug Zapper 2009-12-18 06:53:43 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.