Kernel Bug Tracker – Bug 13683
Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
Last modified: 2010-09-02 19:58:21 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.
Does loading the radeon module with r4xx_atom=1 help?
Created attachment 22150 [details]
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.
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.
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)?
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?
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.
Still the same with with 2.6.31-rc7-git1 (as of yesterday 240809).
Anyone interested to solve this ?
Can you attach your xorg log and the output of xrandr --verbose?
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.
Created attachment 22878 [details]
Created attachment 22879 [details]
Created attachment 22970 [details]
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.
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:
[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)
Ping. Still the same with 2.6.31-rc9 and 2.6.31 final. Also the same with airlieds drm-next tree.
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.
Created attachment 23579 [details]
dmesg drmnext r4xxatom 291009
still whitescreen, screen comes back when i do an vbetool dpms off on switch.
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:
Created attachment 23629 [details]
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.
Created attachment 23630 [details]
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.
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
Created attachment 23760 [details]
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 ?
(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:
and see if it helps.
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.
Created attachment 23921 [details]
xrandr --verbose nomodeset
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.
The order is arbitrary and has nothing to do with the underlying hardware.
Created attachment 23974 [details]
grab misc mode info for lvds
Does this patch help?
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.
Created attachment 24023 [details]
Can you try a kernel with the following patches?
The first two are already in Dave's drm-radeon-testing branch if you want to pull that and add the last one manually.
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.
Do these patches help?
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 :(.
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
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
I am on daves radeon-testing tree. I finally had time to do an bisect, git bisect shows:
7923c615b811945a9d9f456c92a7a32c34167458 is the first bad commit
Author: Alex Deucher <firstname.lastname@example.org>
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 <email@example.com>
Signed-off-by: Dave Airlie <firstname.lastname@example.org>
: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).
Works in 2.6.33-rc8-git5.
Marking as closed.