Bug 24973 - [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
Summary: [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-07 05:21 UTC by Daniel Klaffenbach
Modified: 2019-11-20 08:02 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg from 2.6.32-rc6 after X crash (42.09 KB, patch)
2009-11-07 05:21 UTC, Daniel Klaffenbach
no flags Details | Splinter Review
Xorg log file after crash (24.17 KB, application/octet-stream)
2009-11-07 05:22 UTC, Daniel Klaffenbach
no flags Details
xorg config file (620 bytes, application/octet-stream)
2009-11-07 05:23 UTC, Daniel Klaffenbach
no flags Details

Description Daniel Klaffenbach 2009-11-07 05:21:25 UTC
Created attachment 31034 [details] [review]
dmesg from 2.6.32-rc6 after X crash

I just tested KMS with 2.6.32-rc6 for my Radeon Xpress 200M in a HP nx6125.

When the system boots KMS selects the wrong resolution for the framebuffer (800x600 instead of 1024x768). In dmesg it says:

[drm] LVDS-11: set mode 1024x768 16
[drm] crtc 1 is connected to a TV
[drm] TV-9: set mode 800x600 17

However, I do not have any other monitors/TVs connected (just the laptop panel). But the worst thing of all is that X behaves abnormally:
- X also uses 800x600
- X (or let's say my XSession) does not load correctly
- to make my XSession start up completely I need to switch to VT1 and back to VT7
- when issuing "xrandr --output LVDS --auto" Xorg crashes immediately

I had KMS enabled in 2.6.31 and it worked - this is why this bug seems to be a regression.

The packages I am using:
- XServer 1.7.1
- mesa 7.6
- libdrm 2.4.15
- xf86-video-ati git master

I did compile all the X packages with debug support, but still gdb does not produce any useful output:
(gdb) bt full
#0  0xb71a57f1 in ?? () from /usr/lib/xorg/modules/drivers/radeon_drv.so
No symbol table info available.
#1  0x0000009c in ?? ()
No symbol table info available.
#2  0x00000000 in ?? ()
No symbol table info available.


I am going to attach my xorg.conf, dmesg and Xorg.log. This crappy Xpress 200M chipset makes nothing but troubles in newer kernel versions. With an old system (Ubuntu 7.10) it runs stable. With KMS and/or newer video-ati version not even suspend2ram is working any more - but this is a different story.
Comment 1 Daniel Klaffenbach 2009-11-07 05:22:16 UTC
Created attachment 31035 [details]
Xorg log file after crash
Comment 2 Daniel Klaffenbach 2009-11-07 05:23:23 UTC
Created attachment 31036 [details]
xorg config file

My xorg config file. Note that I have AIGLX and Compositing disabled.
Comment 3 Marius Groeger 2010-03-07 05:08:25 UTC
I see the same issue on my T43 (r300) with these components:
- kernel 2.6.33
- xserver-xorg-video-ati 6.12.191+git20100302.e6dc8866-0ubuntu0sarvatt~karmic
- no xorg.conf
- KMS: modeset=1 dynclks=1

Please let me know if I can provide any kind of log or dump to help finding a solution. The core issue seems to be, as Daniel reported, too, the false detection of an S-Video connection while there is none present.
Comment 4 Alex Deucher 2010-03-08 13:16:15 UTC
(In reply to comment #0)
> Created an attachment (id=31034) [details]
> dmesg from 2.6.32-rc6 after X crash
> 
> I just tested KMS with 2.6.32-rc6 for my Radeon Xpress 200M in a HP nx6125.
> 
> When the system boots KMS selects the wrong resolution for the framebuffer
> (800x600 instead of 1024x768). In dmesg it says:
> 
> [drm] LVDS-11: set mode 1024x768 16
> [drm] crtc 1 is connected to a TV
> [drm] TV-9: set mode 800x600 17
> 
> However, I do not have any other monitors/TVs connected (just the laptop
> panel). But the worst thing of all is that X behaves abnormally:
> - X also uses 800x600
> - X (or let's say my XSession) does not load correctly
> - to make my XSession start up completely I need to switch to VT1 and back to
> VT7
> - when issuing "xrandr --output LVDS --auto" Xorg crashes immediately

Is this still an issue with 2.6.33 or drm-next?
Comment 5 Alex Deucher 2010-03-08 13:21:25 UTC
(In reply to comment #3)
> I see the same issue on my T43 (r300) with these components:
> - kernel 2.6.33
> - xserver-xorg-video-ati 6.12.191+git20100302.e6dc8866-0ubuntu0sarvatt~karmic
> - no xorg.conf
> - KMS: modeset=1 dynclks=1
> 
> Please let me know if I can provide any kind of log or dump to help finding a
> solution. The core issue seems to be, as Daniel reported, too, the false
> detection of an S-Video connection while there is none present.
> 

Are you getting a crash as well or just the tv-out getting detected as connected?

Do either of your laptops have a tv-out port?  Is the issue that your laptops do not have tv-out ports at all in which case they shouldn't be listed, or that they have ports, but they are being detected as connected when they are not?
Comment 6 Marius Groeger 2010-03-08 23:16:48 UTC
Thanks for picking this up, Alex.

> Are you getting a crash as well or just the tv-out getting detected as
> connected?

No crash, just the tv-out getting detected as connected.

> Do either of your laptops have a tv-out port?  Is the issue that your laptops
> do not have tv-out ports at all in which case they shouldn't be listed, or that
> they have ports, but they are being detected as connected when they are not?

The latter, in my case. I do have an S-video output (yellow cinch connector) but nothing's connected to it.

> Is this still an issue with 2.6.33 or drm-next?

I am using 2.6.33 final using the mainline-ppa builds for ubuntu.
Comment 7 Daniel Klaffenbach 2010-03-09 06:49:10 UTC
(In reply to comment #4)
> Is this still an issue with 2.6.33 or drm-next?
Nope. For me the TV-out/xrandr issue seems to be fixed. By now I am using 2.6-master, mesa-master, radeon-master and libdrm-master.

My laptop has a TV-out port and it is now being reported as "disconnected", which is true. Now I do also get the full resolution in X and the framebuffer console.
Comment 8 Marius Groeger 2010-03-09 07:19:18 UTC
> > Is this still an issue with 2.6.33 or drm-next?
> Nope. For me the TV-out/xrandr issue seems to be fixed. By now I am using
> 2.6-master, mesa-master, radeon-master and libdrm-master.

Daniel, your reply is confusing, since it seems to still /be/ an issue with 2.6.33. Have you tried that kernel before switching to 2.6-master?
Comment 9 Daniel Klaffenbach 2010-03-09 07:48:38 UTC
(In reply to comment #8)
> Daniel, your reply is confusing, since it seems to still /be/ an issue with
> 2.6.33. Have you tried that kernel before switching to 2.6-master?
I did not try 2.6.33 (only git master). If I remember correctly the issue disappeared (for me) in the _final_ release of 2.6.32:

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.32
* drm/radeon/kms: Disable TV load detect on RS400,RC410,RS480
Comment 10 Marius Groeger 2010-03-09 09:12:41 UTC
Thanks for clearing this up, Daniel. Seems I have to take it from here on my own, as the issue is definitely present with 2.6.33 on my r300 (Thinkpad T43).
Comment 11 Marius Groeger 2010-08-02 03:03:13 UTC
I verified this issue is still present with 2.6.35rc6 and the current X packages on xorg-edgers. Something new I noticed with Ubuntu 10.04: if I set GRUB_GFXMODE=1400x1050 (the native resolution of the LVDS) in /etc/defaults/grub, then the console actually uses the correct resolution. Howerver, once X starts, the new FB switches to 800x600. The Xorg.0.log indicates that S-Video is falsely detected as being connected, while in fact nothing is attached. 

What can I do to further isolate the cause of this issue?
Comment 12 Alex Deucher 2010-08-02 07:25:08 UTC
(In reply to comment #11)
> I verified this issue is still present with 2.6.35rc6 and the current X
> packages on xorg-edgers. Something new I noticed with Ubuntu 10.04: if I set
> GRUB_GFXMODE=1400x1050 (the native resolution of the LVDS) in
> /etc/defaults/grub, then the console actually uses the correct resolution.
> Howerver, once X starts, the new FB switches to 800x600. The Xorg.0.log
> indicates that S-Video is falsely detected as being connected, while in fact
> nothing is attached. 
> 
> What can I do to further isolate the cause of this issue?

Unfortunately, load detection for tv-out is inherently unreliable on a lot of boards (You can end up with false positives and false negatives).  The best option is to force the tv-out connection on or off in your console or xorg config.
Comment 13 Marius Groeger 2010-08-02 11:33:07 UTC
(In reply to comment #12)
> Unfortunately, load detection for tv-out is inherently unreliable on a lot of
> boards (You can end up with false positives and false negatives).  The best
> option is to force the tv-out connection on or off in your console or xorg
> config.

Fair enough, however that's what I tried but it doesn't seem to work either. I have this definition in xorg.conf:

  Section "Monitor"
          Identifier      "S-Video Monitor"
          Option          "Enabled" "false"
  EndSection

According to the Xorg.0.log it is picked up:

  (II) RADEON(0): Output S-video using monitor section S-Video Monitor

but then this:

  (II) RADEON(0): Output LVDS connected
  (II) RADEON(0): Output VGA-0 disconnected
  (II) RADEON(0): Output DVI-0 disconnected
  (II) RADEON(0): Output S-video connected
  (II) RADEON(0): Using exact sizes for initial modes
  (II) RADEON(0): Output LVDS using initial mode 800x600
  (II) RADEON(0): Output S-video using initial mode 800x600

Is there any other way to disable a connector? How to do it on the console?
Comment 14 Alex Deucher 2010-08-02 11:57:53 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > Unfortunately, load detection for tv-out is inherently unreliable on a lot of
> > boards (You can end up with false positives and false negatives).  The best
> > option is to force the tv-out connection on or off in your console or xorg
> > config.
> 
> Fair enough, however that's what I tried but it doesn't seem to work either. I
> have this definition in xorg.conf:
> 
>   Section "Monitor"
>           Identifier      "S-Video Monitor"
>           Option          "Enabled" "false"
>   EndSection


It's:
Option "Enable" "False"
However, some older xservers (maybe recent ones too), do not deal with enable false, you need to use:
Option "Disable" "True"
Comment 15 Marius Groeger 2010-08-03 05:25:41 UTC
(In reply to comment #14)
> Option "Enable" "False"
> However, some older xservers (maybe recent ones too), do not deal with enable
> false, you need to use:
> Option "Disable" "True"

Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are accepted and confirmed in Xorg.0.log, but the resolution is still switch to 800x600. For some reason the probing seems to override the xorg.conf setting. Any further ideas?
Comment 16 Daniel Klaffenbach 2010-08-03 06:31:26 UTC
(In reply to comment #15)
> Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are
> accepted and confirmed in Xorg.0.log, but the resolution is still switch to
> 800x600. For some reason the probing seems to override the xorg.conf setting.
> Any further ideas?
Two things:
1) Option "Ignore" "true" in xorg.conf for your S-Video port
2) or try adding "radeon.tv=0" to your kernel commandline.

Option 2 does not work for me as the machine seems to freeze with it. However you might have more luck ;)
Comment 17 Marius Groeger 2010-08-03 10:42:11 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are
> > accepted and confirmed in Xorg.0.log, but the resolution is still switch to
> > 800x600. For some reason the probing seems to override the xorg.conf setting.
> > Any further ideas?
> Two things:
> 1) Option "Ignore" "true" in xorg.conf for your S-Video port
> 2) or try adding "radeon.tv=0" to your kernel commandline.

Great, the Ignore option did the trick! Thanks a bunch!

While it still feels like a bug, I'd understand if nothing can be done to it so we might just as well close it as WONTFIX. You guys decide...
Comment 18 Alex Deucher 2010-08-03 11:28:11 UTC
(In reply to comment #17)
> Great, the Ignore option did the trick! Thanks a bunch!
> 
> While it still feels like a bug, I'd understand if nothing can be done to it so
> we might just as well close it as WONTFIX. You guys decide...

"Ignore" means you won't be able to use the connector at all during the life of the xserver.  If the Disable/Enable options are broken, that's most likely a xserver issue.
Comment 19 Marius Groeger 2010-08-03 23:21:06 UTC
(In reply to comment #18)
> "Ignore" means you won't be able to use the connector at all during the life of
> the xserver.  If the Disable/Enable options are broken, that's most likely a
> xserver issue.

Yes thats probably right and I guess I should open a new bug for this. I was however referring to the original problem of the connector not being probed properly as unconnected. So here again my call to you to decide whether this is fixable at all or to just close this bug as a WONTFIX.
Comment 20 Martin Peres 2019-11-20 08:02:01 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/964.


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.