Bug 495208 - [KMS] Radeon Xpress 200M with modesetting=1 X locks hard
[KMS] Radeon Xpress 200M with modesetting=1 X locks hard
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-10 07:35 EDT by Robert P. J. Day
Modified: 2010-05-24 14:54 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-24 14:54:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg.0.log.old file corresponding to radeon driver (43.73 KB, text/plain)
2009-04-10 13:20 EDT, Robert P. J. Day
no flags Details
Xorg.0.log without KMS and with xorg.conf : OK (67.82 KB, text/plain)
2009-04-10 14:39 EDT, Robert P. J. Day
no flags Details
Output of dmesg after the modprobe commands. (39.36 KB, text/plain)
2009-04-10 15:56 EDT, Robert P. J. Day
no flags Details
Xorg.0.log corresponding to loading radeon with modeset=1. (43.22 KB, text/plain)
2009-04-10 15:57 EDT, Robert P. J. Day
no flags Details
Output from "dmesg" with drm.debug=1, no "nomodeset", runlevel 3, "EXA". (46.61 KB, text/plain)
2009-04-25 16:54 EDT, Robert P. J. Day
no flags Details
Log after updating to koji kernel, mesa and xorg x11 drv ati driver. (29.28 KB, text/plain)
2009-05-06 09:35 EDT, Robert P. J. Day
no flags Details
Even after reverting to nomodeset and XAA, can't get desktop. (29.28 KB, text/plain)
2009-05-06 09:45 EDT, Robert P. J. Day
no flags Details
log (75.56 KB, text/plain)
2009-05-28 13:53 EDT, Mateusz M.
no flags Details

  None (edit)
Description Robert P. J. Day 2009-04-10 07:35:08 EDT
System:
  Gateway M-1626, 1280x800 display, ATI Radeon Xpress video
  Kernel: 2.6.29.1-54.fc11.x86_64 #1 SMP
  Driver: xorg-x11-drv-ati-6.12.1-10.fc11.x86_64

Had to select "simple video driver" during install, so:

/etc/X11/xorg.conf:
    Section "Device"
	Identifier "Videocard0"
	Driver "vesa"
    EndSection

Relevant modules:

$ lsmod | grep radeon
radeon                513736  0 
drm                   206012  1 radeon
i2c_algo_bit            5972  1 radeon
i2c_core               22240  4 i2c_piix4,radeon,drm,i2c_algo_bit
$

Booting normally gives me only 1024x768 resolution, and selecting

  System ->
    Preferences ->
      Display

gives me choices of only 1024x768 or 800x600.

  Booting normally generates the following in /var/log/dmesg:

[drm] Initialized drm 1.1.0 20060810
radeon 0000:01:05.0: power state changed by ACPI to D0
radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ATOM BIOS: ATI Radeon Xpress for SA1A
[drm] Detected VRAM RAM=131072K, accessible=131072K, BAR=131072K
reserve_memtype: calling reserve_ram_pages_type for 0xd7900000 0xd7980000 16
i2c-adapter i2c-0: unable to read EDID block.
radeon 0000:01:05.0: VGA-1: no EDID data
i2c-adapter i2c-1: unable to read EDID block.
radeon 0000:01:05.0: LVDS-1: no EDID data
i2c-adapter i2c-2: unable to read EDID block.
radeon 0000:01:05.0: HDMI Type A-1: no EDID data
i2c-adapter i2c-1: unable to read EDID block.
radeon 0000:01:05.0: LVDS-1: no EDID data
allocated ffff88011fc37000 1280x800 fb: 0x00040000, bo ffff88011d49c240
Console: switching to colour frame buffer device 160x50

  Rebooting again and adding "nomodeset" to the command line generated only this ATI-related content:

[drm] Initialized drm 1.1.0 20060810
pci 0000:01:05.0: power state changed by ACPI to D0
pci 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[drm] Initialized radeon 1.29.0 20080528 for 0000:01:05.0 on minor

  Is there any other info you need?
Comment 1 François Cami 2009-04-10 11:53:11 EDT
Yes, please change that "vesa" into "radeon" and test.

Please add full dmesg and full Xorg.0.log as uncompressed text/plain attachments to this bug as well from that attempt.

Thanks

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Robert P. J. Day 2009-04-10 12:14:51 EDT
As a quick test, I simply changed "vesa" to "radeon" and logged out of X, whereupon the automatic logging back in locked up the desktop hard, with only an arrow cursor sitting on a black background.  Nothing could break out of that, and I was forced to do a power cycle and reboot to runlevel 3 to change it back to "vesa" just so I could start my desktop again.

Would you like me to try "radeon" again, have it lock up, then boot back to runlevel 3 and post the contents of Xorg.0.log?
Comment 3 Robert P. J. Day 2009-04-10 12:36:03 EDT
As a stab at what the problem might be (before I upload the entire log files), here's a snippet from Xorg.0.log:

(II) RADEON(0): Printing probed modes for output LVDS
(II) RADEON(0): Modeline ""x60.0   71.11  1280 1328 1360 1440  800 803 809 823 (49.4 kHz)
(II) RADEON(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) RADEON(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) RADEON(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)

  Note the empty quotes for the 1280x800 mode line, where you would expect to see "1280x800".  That doesn't look right, does it?
Comment 4 Matěj Cepl 2009-04-10 13:03:06 EDT
(In reply to comment #2)
> Would you like me to try "radeon" again, have it lock up, then boot back to
> runlevel 3 and post the contents of Xorg.0.log?  

Yes, please.
Comment 5 Robert P. J. Day 2009-04-10 13:20:58 EDT
Created attachment 339112 [details]
Xorg.0.log.old file corresponding to radeon driver

Here's the Xorg.0.log.old file for the radeon driver.
Comment 6 François Cami 2009-04-10 14:19:08 EDT
Robert,

Thank you for the log file.

What happens if you add nomodeset to the kernel command line and try to use the "radeon" driver in xorg.conf ? Please post Xorg.0.log.old from that attempt as well.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 7 Robert P. J. Day 2009-04-10 14:39:44 EDT
Created attachment 339118 [details]
Xorg.0.log without KMS and with xorg.conf : OK

Apparently, selecting the "radeon" driver in xorg.conf and adding "nomodeset" to the kernel command line solved this.  I've attached the Xorg.0.log for what worked.
Comment 8 François Cami 2009-04-10 15:04:52 EDT
OK, pure KMS bug. 

We need to go into drm debug mode to see things clearer.

Could you please boot in runlevel 3 with nomodeset, then :
modprobe -r radeon drm
modprobe drm debug=1
modprobe radeon modeset=1
Please dump the full dmesg from this and add it here.
Then switch to runlevel 5. If you can add Xorg.0.log and /var/log/messages from this attempt (probable lock-up, considering what happened earlier) as well, it would be great.

Thanks in advance.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Robert P. J. Day 2009-04-10 15:56:05 EDT
Created attachment 339123 [details]
Output of dmesg after the modprobe commands.

The output from dmesg after unloading, then reloading drm and radeon as above.
Comment 10 Robert P. J. Day 2009-04-10 15:57:05 EDT
Created attachment 339124 [details]
Xorg.0.log corresponding to loading radeon with modeset=1.
Comment 11 François Cami 2009-04-10 16:12:46 EDT
Thanks for the logs, unfortunately the debug information is not there, not sure what happened. 

Switch to ASSIGNED, if we don't have enough data I'll let you know.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Robert P. J. Day 2009-04-10 16:27:30 EDT
Specifically which module debug information are you looking for?  And which file would it have ended up in?  I can try it again.
Comment 13 François Cami 2009-04-10 16:33:26 EDT
drm debug. 
It's in dmesg, and there should be many lines starting with drm, like in the last log attached to this bug :
https://bugzilla.redhat.com/show_bug.cgi?id=493332

Please try booting into runlevel 3 only, no "nomodeset" in the kernel command line, then remove and modprobe the modules as needed.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Robert P. J. Day 2009-04-15 07:33:20 EDT
I think a good deal of this has now been resolved here:

https://bugzilla.redhat.com/show_bug.cgi?id=495454
Comment 15 Dave Airlie 2009-04-23 20:14:37 EDT
if you boot with drm.debug=1 and you get no console can you still get the dmesg?

I've no idea why we don't pick a native mode on the console on that hw..
Comment 16 Dave Airlie 2009-04-23 21:05:10 EDT
can you also try -103 or above kernel to see if this changes, and post the dmesg + xorg log file.
Comment 17 François Cami 2009-04-24 20:58:34 EDT
Robert,

Could you please :

* upgrade your kernel to kernel-2.6.29.1-103 or later, for instance the 106 build in Koji :
http://koji.fedoraproject.org/koji/buildinfo?buildID=99183

* remove nomodeset from the kernel-2.6.29.1-103+ command line (in grub.conf)
* add drm.debug=1 to the same kernel command line (in grub.conf)

* make sure you're still using EXA in xorg.conf

* reboot and post the dmesg and Xorg.0.log log files here

Many thanks in advance

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 18 Robert P. J. Day 2009-04-25 07:15:24 EDT
I just grabbed the 106 kernel package from koji, but it depends on a similarly versioned kernel-firmware package which I don't see there.
Comment 19 Dave Airlie 2009-04-25 08:22:06 EDT
Its in the noarch subdirectory.
Comment 20 Robert P. J. Day 2009-04-25 09:16:57 EDT
Sorry, you're going to have to be more specific.  I just tried to find that package, and AFAICT, kernel-firmware only has a "102" version.  What's the URL for the koji download repository?  I am not a koji expert.
Comment 21 Robert P. J. Day 2009-04-25 09:28:05 EDT
Whoops, never mind, found it.
Comment 22 Robert P. J. Day 2009-04-25 09:47:13 EDT
OK, I made the changes suggested above, and it's initially curious that "drm.debug=1" is not recognized as a valid kernel boot option.  In any event, what I got was a scrambled and unusable X session.

I went back to using "nomodeset" and, with the 106 kernel and "EXA", I have a usable desktop.  I couldn't get copies of the log files since the system pretty much locked up on me.
Comment 23 François Cami 2009-04-25 14:04:14 EDT
"drm.debug=1" is an option for a module that's not compiled into the kernel but is in the initrd, that's why the kernel initially says it's not recognized, but it's passed to the drm just fine.

Could you boot with "3 drm.debug=1" and get at least a dmesg log please ?

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 Robert P. J. Day 2009-04-25 16:54:33 EDT
Created attachment 341326 [details]
Output from "dmesg" with drm.debug=1, no "nomodeset", runlevel 3, "EXA".
Comment 25 François Cami 2009-05-06 06:32:33 EDT
Robert,

Could you tell the following mesa/xorg-x11-drv-ati/kernel builds :

http://koji.fedoraproject.org/koji/buildinfo?buildID=100894
http://koji.fedoraproject.org/koji/buildinfo?buildID=100998
http://koji.fedoraproject.org/koji/buildinfo?buildID=100995

They contain RS690 fixes.

First thing to test is KMS+EXA, then if KMS fails, nomodeset+EXA.
If there are any problems, please post /var/log/messages with drm.debug=1 and Xorg.0.log as usual.

Thanks in advance

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 26 Robert P. J. Day 2009-05-06 07:15:59 EDT
By "KMS", I assume you mean simply *not* having a "nomodeset" parameter in the kernel boot line.  I'll get to that shortly; my testing will simply consist of trying the same things that caused grief before and I'll let you know if things work smoothly this time.
Comment 27 François Cami 2009-05-06 07:57:19 EDT
Yes, by KMS I meant not having nomodeset in the kernel command line.
Comment 28 Robert P. J. Day 2009-05-06 09:35:28 EDT
Created attachment 342642 [details]
Log after updating to koji kernel, mesa and xorg x11 drv ati driver.

This looks like a fairly obvious versioning mismatch if you read far enough down the file.
Comment 29 Robert P. J. Day 2009-05-06 09:45:13 EDT
Created attachment 342644 [details]
Even after reverting to nomodeset and XAA, can't get desktop.

With the newer kernel/mesa/ATI driver, since that failed, I reverted back to adding "nomodeset" on the boot line and "XAA" acceleration, but you can see that this no longer solves the problem (it used to).  This seems fairly serious -- I now can't get to a graphical desktop no matter what I do.  Why does X still attempt to use EXA acceleration further down that log file?
Comment 30 Robert P. J. Day 2009-05-06 12:05:56 EDT
For the time being, I've simply reverted to the vesa driver get to a desktop.  Nothing I do with the radeon driver seems to work anymore.
Comment 31 François Cami 2009-05-06 12:23:05 EDT
Thanks for testing, and especially for the logs.
You can revert to a previous version hand-picked there :
http://koji.fedoraproject.org/koji/packageinfo?packageID=95

I'll update this when we have another build.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 32 Robert P. J. Day 2009-05-06 12:35:49 EDT
Let me know when you're ready, and I'll try to do more testing ASAP, since I have a vested interest in this.  Here's my current package selection:

$ rpm -qa kernel*
kernel-doc-2.6.29.2-129.fc11.noarch
kernel-firmware-2.6.29.2-129.fc11.noarch
kerneloops-0.12-5.fc11.x86_64
kernel-devel-2.6.29.2-129.fc11.x86_64
kernel-headers-2.6.29.2-129.fc11.x86_64
kernel-2.6.29.2-129.fc11.x86_64

$ rpm -qa mesa*
mesa-libGLU-devel-7.5-0.14.fc11.x86_64
mesa-libGL-devel-7.5-0.14.fc11.x86_64
mesa-libGLU-7.5-0.14.fc11.x86_64
mesa-libGL-7.5-0.14.fc11.x86_64
mesa-dri-drivers-7.5-0.14.fc11.x86_64

$ rpm -qa xorg-x11-drv-ati*
xorg-x11-drv-ati-6.12.2-12.fc11.x86_64

Beyond that, the only changes I've been making are whether or not to choose KMS, and the acceleration mode in /etc/X11/xorg.conf.
Comment 33 Robert P. J. Day 2009-05-06 13:32:57 EDT
Can I ask whether the log files I attached identified the problem?
Comment 34 Mateusz M. 2009-05-28 13:52:40 EDT
and my problem with resolution 1366x786 on my laptop compal KHLB2 i cant get native resolution
xrandr
Screen 0: minimum 800 x 600, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 0mm x 0mm
   1024x768       61.0* 
   800x600        61.0
Comment 35 Mateusz M. 2009-05-28 13:53:35 EDT
Created attachment 345807 [details]
log
Comment 36 Bug Zapper 2009-06-09 09:36:36 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 37 Vedran Miletić 2009-09-06 02:14:27 EDT
Can you retry this with Rawhide, i.e. Fedora 12 Snap1?
Comment 38 Vedran Miletić 2009-10-15 15:28:43 EDT
Robert, juding by your bug 529026, KMS is working now?
Comment 39 Robert P. J. Day 2009-10-15 15:44:16 EDT
If by KMS you mean that second phantom display, using the koji build of firstboot seems to be working fine but, once I'm up and running, I can still sometimes generate that second display by switching display resolutions in my desktop.  So it hasn't been entirely fixed.  Is that what you were asking?
Comment 40 Vedran Miletić 2009-10-15 15:51:24 EDT
I probably wasn't clear enough.

In F12, KMS is enabled by default. Since you didn't mentioned it in other bug report, I assume KMS is working OK for you, right? (There might be other issues, but that's not the point.)

This would be really good, since this IGP's KMS support has been really problematic.
Comment 41 Matěj Cepl 2009-11-05 13:25:55 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 42 Matěj Cepl 2010-02-26 07:21:35 EST
Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]
Comment 43 Bug Zapper 2010-04-27 09:36:52 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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 44 Vedran Miletić 2010-05-24 14:54:41 EDT
Closing per comment 42.

---

Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

[This triage is part of collective effort done by students of University of
Rijeka Department of Informatics.]

Note You need to log in before you can comment on or make changes to this bug.