Bug 13683

Summary: Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
Product: Drivers Reporter: Jan Kreuzer (kontrollator)
Component: Video(DRI - non Intel)Assignee: drivers_video-dri
Status: CLOSED CODE_FIX    
Severity: normal CC: alexdeucher, florian
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.31-rc9 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg of failing modeset with drm.debug=1
dmesg r4xx_modeset=1
xrandr --verbose
xorg.log
dmesg drm.debug=1
dmesg drm.debug=1 modeset fail
dmesg drmnext r4xxatom
dmesg drmnext r4xxatom 291009
radeontool notworking
radeontool working
dmesg drm debug=5
vbios
xrandr --verbose nomodeset
xrandr --verbose nomodeset
grab misc mode info for lvds
possible fix

Description Jan Kreuzer 2009-06-30 15:47:11 UTC
Created attachment 22148 [details]
dmesg of failing modeset with drm.debug=1

When KMS is enabled the internal Laptop-Display of becomes an all white screen, instead of displaying anything useful. Notebook is an Uniwill P50CA Clone, made by Fujitsu-Siemens, Modell is Amilo A1667G. Graphics is PCIE Ati Radeon Mobility.
Comment 1 Alex Deucher 2009-06-30 15:58:36 UTC
Does loading the radeon module with r4xx_atom=1 help?
Comment 2 Jan Kreuzer 2009-06-30 16:58:30 UTC
Created attachment 22150 [details]
dmesg r4xx_modeset=1

partly. It still boots up with whitescreen, however after some time (i assume when powermgt kicks in) screen becomes black, after pressing  key screen displays console.
Attached is dmesg from r4xx_atom dmesg.
Comment 3 Jan Kreuzer 2009-07-02 08:23:49 UTC
Update, booting with r4xx_modeset lets me see the console after powermgt kicks in, however X doesnt start correct (i see the mouse, but not the login-screen). Booting without r4xx_modeset and waiting for powermgt kicking in (or closing the laptop-lid after X started) screen becomes black, after moving a key the gdm-login-screen appears and everything works. Back in the FC-5 days i had the same problem with the ati-driver, however then an option named MonitorLayout existed, setting it to LVDS,none worked back then.
Comment 4 Jan Kreuzer 2009-07-15 11:43:38 UTC
I added an vbetool dpms off / on cycle in the startup-scripts, after that the screen displays the right content. Would it be possible (as a workaround for my laptop) to do the same at kms initialization (i mean use the same bios-call that vbetool uses to activate the screen)?
Comment 5 Florian Mickler 2009-07-15 20:04:35 UTC
i had a similar symptom with my internal display using an intel grafix adapter ...

it turned out that my display was a dual channel lvds display but it got handled as a single-channel display.  (see http://bugs.freedesktop.org/22262 )

maybe that is the same problem here?
Comment 6 Jan Kreuzer 2009-07-27 14:25:07 UTC
Ping

Bug still there with linux-2.6.31-rc4. I also noticed whenever an app (eg an game) chnages the resolution the screen becomes all white, running the vbetool dpms off / on cycle displays the normal content.
Comment 7 Jan Kreuzer 2009-08-25 04:51:01 UTC
Ping.
Still the same with with 2.6.31-rc7-git1 (as of yesterday 240809).

Anyone interested to solve this ?
Comment 8 Alex Deucher 2009-08-25 05:00:31 UTC
Can you attach your xorg log and the output of xrandr --verbose?
Comment 9 Jan Kreuzer 2009-08-27 09:51:52 UTC
I have the requested Information from an Daily-F12-livecd booted with nomodeset. i hope this is sufficient. I will do an fresh installation onto an usb-drive, for testing the latest git-versions when time permits, as i dont want to sacrifice my working opensuse 11.1 installation where I tried latest git-kernel.

Fedora-versions: 
kernel-2.6.31-0.174.rc7.git2.fc12.x86_64
xorg-x11-drv-ati-6.13.0-0.2.20090821gitb1b77a4d6.fc12.x86_64

Thank you.
Comment 10 Jan Kreuzer 2009-08-27 09:52:44 UTC
Created attachment 22878 [details]
xrandr --verbose
Comment 11 Jan Kreuzer 2009-08-27 09:55:00 UTC
Created attachment 22879 [details]
xorg.log
Comment 12 Jan Kreuzer 2009-09-02 07:10:06 UTC
Created attachment 22970 [details]
dmesg drm.debug=1

When booting with drm.debug=1 modesetting (with and without r4xx_atom=1) works. Booting without drm.debug=1 results in the whitescreen. i tried this 3 times, this is reproducible.

I attached dmesg from working modeset with drm.debug=1.

Thank you for your time.
Comment 13 Jan Kreuzer 2009-09-02 07:30:51 UTC
Created attachment 22971 [details]
dmesg drm.debug=1 modeset fail

I spoke to soon. After rebooting modeset fails also with drm.debug=1.
However the dmesg shows an difference for the connectortype:

Modeset working
[drm:drm_crtc_helper_set_config], crtc: ffff88003f235000 3 fb: ffff88003eae6540 connectors: ffff88003f2357f8 num_connectors: 1 (x, y) (0, 0)

Modeset not working
[drm:drm_crtc_helper_set_config], crtc: ffff880037ead000 3 fb: ffff880037d8d240 connectors: ffff880037ead7f8 num_connectors: 1 (x, y) (0, 0)

Thank you
Comment 14 Jan Kreuzer 2009-09-11 12:41:09 UTC
Ping. Still the same with 2.6.31-rc9 and 2.6.31 final. Also the same with airlieds drm-next tree.
Comment 15 Jan Kreuzer 2009-10-17 14:31:37 UTC
Created attachment 23448 [details]
dmesg drmnext r4xxatom

Still the same with drm-next from yesterday (16-10-2009). After DPMS kicks in and blanks the screen and i move the mouse or press a key the screen appears. Attached is dmesg with drm-debug and r4xx_atom=1.
Comment 16 Jan Kreuzer 2009-10-29 08:37:00 UTC
Created attachment 23579 [details]
dmesg drmnext r4xxatom 291009

Ping.
still whitescreen, screen comes back when i do an vbetool dpms off on switch.
Comment 17 Alex Deucher 2009-10-29 14:54:16 UTC
Can you dump the regs using radeontool (radeontool regmatch '*') in the working and non-working cases and attach the dumps?  You can get radeontool here:
http://cgit.freedesktop.org/~airlied/radeontool
Comment 18 Jan Kreuzer 2009-11-03 08:38:21 UTC
Created attachment 23629 [details]
radeontool notworking

Sorry for replying late, i was at an congress.

First Attachment ist radeontool regmatch '*' with whitescreen, second one is after an vbetool dpms off / on cycle.

Thank you

Jan
Comment 19 Jan Kreuzer 2009-11-03 08:39:03 UTC
Created attachment 23630 [details]
radeontool working
Comment 20 Jan Kreuzer 2009-11-06 11:51:39 UTC
Created attachment 23679 [details]
dmesg drm debug=5

Still the same with git of today. However i noticed the increased verbosity of debug=5, so i attached a new dmesg. Maybe this helps to isolate the problem.
Comment 21 Alex Deucher 2009-11-12 17:29:33 UTC
Unfortunately, the register dumps are identical.  The only regs that are different are irrelevant to this. I guess it must be a timing or ordering issue. Can you attach your video bios?  as root:
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom
Comment 22 Jan Kreuzer 2009-11-12 18:34:38 UTC
Created attachment 23760 [details]
vbios

The vbios.
Comment 23 Jan Kreuzer 2009-11-20 08:37:49 UTC
Still the same with latest git. Is it possible that the bios lies about the connectors ? When i used the real old non-kms, non-xrandr radeon driver i had to specify MonitorLayout LVDS,none to get an screen, else i got the white-screen. I experimented with the video kernel-command-line, when i used video=1280x800 for all outputs i dont get the whitescreen instead the screen flickers and displays nothing. How could i force the kernel to use LVDS as first connector ?

Greetings Jan
Comment 24 Alex Deucher 2009-11-20 23:41:49 UTC
(In reply to comment #23)
> Still the same with latest git. Is it possible that the bios lies about the
> connectors ? 

It's possible, but not likely.  The bios claims you have local flat panel (LVDS) and a DVI-I port.  Is that what your laptop has?

> When i used the real old non-kms, non-xrandr radeon driver i had
> to specify MonitorLayout LVDS,none to get an screen, else i got the
> white-screen. I experimented with the video kernel-command-line, when i used

In those days there was a bug in the connector table parsing where LVDS was not detected on properly on ATOM systems, so you had to force it with the monitorlayout option otherwise it would ignore the panel altogether.

> video=1280x800 for all outputs i dont get the whitescreen instead the screen
> flickers and displays nothing. How could i force the kernel to use LVDS as
> first connector ?

What do you mean "first connector"?  LVDS always uses the first display controller right now even though either could drive it.  Also, from your logs it appears you don't have any other monitors attached, so it's the only thing being used.

Some LVDS panels are very picky about the timing they get and the power up sequence.  This seems to be the case with yours.  You might try Dave's drm-radeon-testing branch, specifically this commit:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=fba0a16eb5c55ae3bb9cf1306a84b83451389612
and see if it helps.
Comment 25 Jan Kreuzer 2009-11-24 08:14:27 UTC
I am already on the drm-radeon-testing branch, the latest commit i checked out is http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=44c83571e8e164840e91f3cc9fdd928889ac169b which includes your mentioned commit. Still with or without radeon.r4xx_atom=1 the white-screen.
My Laptop has the local flat-panel, an dvi-i connector and an s-video connector. The reason i asked for the connectors is, that when i use nomodeset (working panel) the ordering of the connectors of xrandr --verbose is different, although the numbering is the same. I attach both xrandr outputs.

Thank you
Comment 26 Jan Kreuzer 2009-11-24 08:17:02 UTC
Created attachment 23921 [details]
xrandr --verbose nomodeset
Comment 27 Jan Kreuzer 2009-11-24 08:21:55 UTC
Created attachment 23922 [details]
xrandr --verbose nomodeset

The first (23921) is with modeset on, the second without modeset. Without modeset LVDS is listed as first connected (identifier 0x52) and dvi follows (identifier 0x53), with modeset dvi is first (identifier 0x51), then lvds and then s-video.
Comment 28 Alex Deucher 2009-11-24 09:39:28 UTC
The order is arbitrary and has nothing to do with the underlying hardware.
Comment 29 Alex Deucher 2009-11-30 07:28:09 UTC
Created attachment 23974 [details]
grab misc mode info for lvds

Does this patch help?
Comment 30 Jan Kreuzer 2009-12-04 14:05:13 UTC
Sorry for replying late. I tested latest drm-radeon-next which contains your patch. Unfortunately still the white screen, with and without r4xx_atom.
If you need more Information please tell me. Thank you.
Comment 32 Jan Kreuzer 2009-12-06 08:13:09 UTC
I tried Dave's latest drm-radeon-next (has already the two patches from drm-radeon-testing) plus your third patch, still the white screen when modeset starts.

Thank you
Comment 34 Jan Kreuzer 2009-12-06 18:01:36 UTC
No unfortunately still the white screen. However i noticed that when i do the vbetool dpms on / off cycle there is now flickering in the non r4xx_atom case, when using r4xx_atom no flickering.
I also tried attaching an FlatPanel at the DVI-output, when i attach it before bootup the non-modesetting X also produces the whitescreen, if i attach it after boot and after starting X the laptop screen remains useable. When i attach the panel in the kms-case i get the white screen on the laptop-panel and the flatpanel goes into powersavingmode. Attaching it with modeset and r4xx_atom hangs completly. Strange  thing this latop :(.
Comment 35 Jan Kreuzer 2009-12-16 09:36:36 UTC
You rock ! ;-)

Using git of today it magically works. I dont know which commit fixed it, however i tested some options. Using r4xx_modeset=1 whitescreen (with and without new_pll option). Using r4xx_modeset=0 it works (with and without new_pll option). Should i close this bug now ?

Sidenote, Although KMS works, 3D is dogslow and logging into KDE4 crashes the system.

Greetings and many Thanks

Jan
Comment 36 Alex Deucher 2009-12-18 19:53:01 UTC
Cool.  What git tree are you using?  Linus' or Dave's?  I wonder what fixed it?  The new_pll option isn't applicable to your chip.  I guess we can close this bug then, FINALLY :)

As the the performance problems, make sure 3D is enabled (KMS requires mesa built with KMS support) and if you are still having a problem, file a bug on https://bugs.freedesktop.org
Comment 37 Jan Kreuzer 2009-12-24 11:05:37 UTC
I am on daves radeon-testing tree. I finally had time to do an bisect, git bisect shows:
7923c615b811945a9d9f456c92a7a32c34167458 is the first bad commit
commit 7923c615b811945a9d9f456c92a7a32c34167458
Author: Alex Deucher <alexdeucher@gmail.com>
Date:   Tue Dec 15 17:15:07 2009 -0500

    drm/radeon/kms: make sure mc is initialized before mapping blit bo

    We need to make sure the the MC is intialized before we map the
    blit shader object on r6xx+.

    Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 1fbfa9b9f01551f75ddf82f9a9e39a4e2fa880f5 4c669f663e8e2a5c3346c03e580e444ed2f7fae8 M      drivers
 Note that i had to mark the working revision as bad and the non working as good to get bisect to work. Afters this commit modeset works, before not. This seems strange, as the commit doesnt touch specific code for my chipset (RV410).

Merry christmas

jan
Comment 38 Jan Kreuzer 2010-02-20 16:28:40 UTC
Works in 2.6.33-rc8-git5.
Marking as closed.