Red Hat Bugzilla – Bug 472310
[radeon.modeset] Screen locks, only hardware reset helps on x1100 (rs485)
Last modified: 2009-12-18 01:53:43 EST
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):
Steps to Reproduce:
1. install latest f10 kernel on rs485m
2. wait less than 30 mins
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:  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
Created attachment 324115 [details]
Xorg.0.log from f9
Created attachment 324200 [details]
Xorg.0.log from 18.104.22.168-120.fc10.x86_64 before a crash
Created attachment 324201 [details]
dmesg from 22.214.171.124-120.fc10.x86_64 before a crash
Created attachment 324221 [details]
Xorg.0.log.old after the crash on f9
Created attachment 324222 [details]
dmesg.old after the crash on f9
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?
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:
Created attachment 325967 [details]
This is a regression. I cannot start without nomodeset with this kernel. dmesg and Xorg.0.log attached
Created attachment 325968 [details]
The corresponding Xorg.0.log file to the previous message.
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:
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?
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.
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.
Created attachment 328656 [details]
dmesg-126.96.36.199-167.fc10.x86_64 with radeon.gartsize=256
Created attachment 328657 [details]
Xorg.0.log-188.8.131.52-167.fc10.x86_64 with radeon.gartsize=256
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
Created attachment 328755 [details]
drm.debug=1 radeon.gartsize=128. Gartsize=512 doesn't work.
Created attachment 328757 [details]
more messages gartsize=128
Created attachment 328758 [details]
dmesg with drm.debug=1
Created attachment 328760 [details]
Created attachment 328761 [details]
iomem gartsize=128 debug=1
Created attachment 328762 [details]
Xorg.0.log-184.108.40.206-167.fc10.x86_64 drm.debug=1 radeon.gartsize=128
Maybe this is a bios problem. with 2gb it works fine but the same radeon/xserver/drm code doesn't like 4GB.
Anything else I can do to help with this? Testing?
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.
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-220.127.116.11-170.2.30.rc1.fc10.x86_64. Great work!
Created attachment 332823 [details]
Created attachment 332824 [details]
Created attachment 332825 [details]
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:
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.