Attached is a dmesg from a system running Linux 2.6.32. The system experiences a horrifying 33 second boot delay, during which the screen is apparently off, not just blanked. Using 'radeon.modeset=0' eliminates the delay. I figured a 'git bisect v2.6.32 v2.6.31 -- drivers/gpu/drm' would catch it. Hopefully this bisection helps pin down the underlying problem: # bad: [22763c5c] Linux 2.6.32 # good: [74fca6a4] Linux 2.6.31 # bad: [df748b02] drm/ttm: fix refcounting in ttm global code. # good: [a513c184] drm/radeon/kms: Don't try to process irq when we a # good: [aadd4e17] drm/radeon: some r420s have a CP race with the DMA # good: [74bf2ad5] drm/kms: make fb helper work for all drivers. # bad: [62a8ea3f] drm/radeon/kms: Remove old init path as no hw use # good: [f0ed1f65] drm/radeon/kms: Convert R520 to new init path and # skip: [d4550907] drm/radeon/kms: Convert R100 to new init path (V2) # good: [3bc68535] drm/radeon/kms: Convert RS690/RS740 to new init pa # bad: [c010f800] drm/radeon/kms: Convert RS600 to new init path Any ideas?
Created attachment 31831 [details] dmesg from v2.6.32 radeon kms 33s hang
Do you have fbcon loaded? if not you won't get any output until X is loaded.
Of course. It's built in. Note that this problem is a regression introduced between v2.6.31 and v2.6.32. Yes, I've reported the bug against X11, but it's not an X11 bug. It was reported here as per Dave Airlie's request.
Same problem here introduced in 2.6.32-rc7, rc6 is OK. for info my card is a rv530
Does reverting these commits help? http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=d11aa88b33b071d55181a7a482b9e7494888c10e http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff
Yes for me no more delay after reverting theses two patch !
Created attachment 31852 [details] [review] manually force SS off except LVDS Does this patch help?
Created attachment 31853 [details] dmesg from v2.6.32+patch #31852
The mentioned patch didn't fix anything for me. I'm adding a new dmesg with the patch applied, in case it makes some difference there.
Yes tried the patch and it's not better. With 2.6.33-rc1 the same.. Had to go back to reverting the 2 mentioned commit : http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=d11aa88b33b071d55181a7a482b9e7494888c10e http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff
i'm having a similar problem. not only i have >33 second delay on 2.6.32 (i think it's way over 1 minute in my case), but also when the screen finally appears it sets into resolution my monitor cannot handle at all. (i think it's either too high refresh rate, or to big resolution - everything looks like diagonal stripes all over the screen). i'm currently using very old daewoo cmc-1427x crt, as a temporary replacement for my lcd. it works ok with 2.6.31, setting into 1024x768 with kms. i had to disable automatic modesetting on 2.6.32 to be able to use this kernel. i'll try to start modesetting and provide dmesg.
Any progress on a patch for this bug? ( Also, I forgot to mention previously that reverting the two commits Alex mentions in comment 5 does eliminate the issue. )
has anyone testing 2.6.33-rc8?
Nothing better with 2.6.33-rc8.. any information needed ?
Yes, the problem still exists in the latest stable 2.6.32 kernel as well as in Linus' current tree.
Created attachment 33379 [details] [review] use udelay again. does this patch help? its currently in drm-radeon-testing.
The patch resolves it for me.
Fixed in 2.6.33
*** Bug 26596 has been marked as a duplicate of this bug. ***
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.