Created attachment 26611 [details]
Using kernels after 2.6.34 with Radeon KMS does not work. Whenever the radeon modeule becomes active the screen goes black with vertical dottet lines. Disabling modeset lets the kernel start. KMS worked with the old code okay on this machine. Its an latop from Fujitsu-Siemens with an x700 Mobility PCIE.
I tried an bisect run, bisect log said that ce8a3eb20c4cb7d9e0c33e7560070688cd9066fc is the first bad commit. I tried to revert it ontop of 2.6.35-rc1, the vertical dotted lines disappeared, however system hangs forever with an black screen.
I attach bisect-log. If more Information is needed please tell me so.
Created attachment 26612 [details]
git bisect log
Please attach full kernel log with 2.6.34, if you can't boot because of KMS boot with: radeon.modeset=0 3
Then log as root and do (through ssh would be easier):
modprobe radeon modeset=1
Then save the kernel log (/var/log/messages usually) and attach it here
Which kernel do you mean the working 2.6.34 or the non working 2.6.35-rc1 ?
non working 2.6.35 and also a working log with 2.6.34
Created attachment 26615 [details]
/Var/log/messages from working kernel (2.6.34-rc7)
Created attachment 26616 [details]
/Var/log/messages from non-working kernel (2.6.35-rc1)
I think the error is unrelated to the problem, as airlieds drm-radeno-next tree doesnt show the bug in native_sched_clock but booting with modeset also does not work. I will also attach messages from airlieds 2.6.34-tree.
Created attachment 26617 [details]
/Var/log/messages from non-working kernel (2.6.34-drm-radeon-next)
Is it just LVDS? Does an external monitor work?
New code does not work when plugging in an flatscreen per dvi. Still boot hangs with dotted white vertical lines on lvds, whereas dvi says no cable connected.
However i noticed a new problem when plugging in dvi with 2.6.34. When i plug dvi at running time it works as espected (aka dynamically configures monitor), however when i plug dvi in at boot time the lvds becomes all white as soon X starts and only dvi works. I will open a new bugreport for this.
Please boot with drm.debug=15 and attach kernel log. Also please boot with no external monitor connected. So we can fix bug one at a time. (need log with a working and non working kernel)
I bisected to the same commit on my HP Compaq nx6325 laptop with integrated RS482. 2.6.34 was fine, 2.6.35-rc1 freezes. This is with only the LCDS, no external monitor. I'll attach logs when I get back home, if still needed.
Does reverting ce8a3eb20c4cb7d9e0c33e7560070688cd9066fc actually fix the problem? Booting with drm.debug=15 should work as well since that would re-enable the debug code that commit turned off.
Created attachment 26646 [details]
dmesg with drm.debug=15 from working kernel
Attached is log from working kernel. I am currently unable to get log from not working kernel, as soon as i modprobe radeon with modeset the system hangs, magic-sysrq does not work.
Booting with drm.debug=15 does not prevent the hang, i try to revert the commit an report back.
Reverting the commit against 2.6.35-rc1 and booting with drm.debug=15 worked (eg no crash, but white screen, which could be solved by vbetool dpms off / on), however after i rebooted and removed the drm.debug option it crashed again. Also all later tries (with and without drm.debug) crashed.
A timing problem ?
Does applying the following two patches help?
The first one isn't relevant to your hw, but the second one won't apply cleanly without it.
Oh damn, ignore my previous comment #11, as it looks like I was way to fast looking at the commit ID. For my freeze the actuall one is ce8f53709bf440100cb9d31b1303291551cf517f which is probably another bug, which I will report separately. Sorry for all the noise.
(In reply to comment #16)
> Oh damn, ignore my previous comment #11, as it looks like I was way to fast
> looking at the commit ID. For my freeze the actuall one is
> ce8f53709bf440100cb9d31b1303291551cf517f which is probably another bug, which
> will report separately. Sorry for all the noise.
The patches in comment #15 are relevant for that commit, although you'd probably want to open a new bug anyway.
The patches work, system no longer crashes. Thank you. However now i get an all white-screen as soon as kms gets activated (same white screen as described in comment #9), i can work around it with an vbetool dpms off / on cycle. Should i open a new bugreport for this, and if so which logs do you need for the new problem ?
Thank you for your time.
Although startup now works i get screenflickering when runing, also the system sometimes hangs when using 3D applications (compiz, kwin-compositing, openarena, padman), this worked without problems with the old pm-code.
Fixed by commit f8ed8b4c5d30b5214f185997131b06e35f6f7113 .