Created attachment 23728 [details] [review] logverbose 7 Xorg.0.log for case of misplaced desktop geometry This problem appeared with the r6xx-r7xx merge, was not present before that. Logs attached are for latest master branch git version. The first time X is started after a boot, the desktop area that kde recognizes as such (ie, it paints the wallpaper, gives you the right click menu) is a small strip at the top of the screen. Quitting X and restarting makes things behave as usual. logverbose 7 logs attached for both the initial, weird instance and the second, normal one. The only differences appear to be in the addresses being mapped. This is with a dual monitor setup because I happen to have the Thinkpad T60p plugged into the docking station at the moment, but just the panel alone displays the same problem.
Created attachment 23729 [details] [review] Xorg.0.log file on the second, working instance of X This is the logfile for the second run of X after boot, which works
Any chance that you could git-bisect this issue? Somehow I doubt that this is related to r[67]xx acceleration, but more a subtle side effect of some of the other things that changed. Is this reproducible, i.e. happens this after each reboot? I somehow doubt I can reproduce with any particular R5xx, but I will try.
Created attachment 23730 [details] [review] Xorg.0.log file using pre-merged git This is the log file using the git head before the r6xx merge. It works the first time every time. Although my first attempt at generating this logfile inadvertently triggered bug 18097 :)
It is completely reproducible with each boot. Using an updated F10 system, so this is kde 4.2.0, will try with other desktops to see what happens. Not sure git-bisect will help from the master branch perspective - the commit which triggered the bug was the merging of the r6xx-r7xx branch. Although I've never used the bisect before so will go learn how I might be able to isolate the specific bit merged from the other branch that's the troublesome one.
git bisect is easy to use: git bisect start <known-bad> <known-good> (known-bad would be the first commit you know that fails, i.e. HEAD, known-good would be the last commit you know that doesn't, i.e. the commit before the accel merger) git presents you a new tree, compile, test, then either git bad or git good depending on the test :-] That presents you a new tree, so continue. If a tree doesn't compile, just check out a tree that is nearby (select e.g. with gitk). As you said it's not 100% reproducible, you might have to test multiple times. That's unfortunate (especially as this involves booting here), but can't be helped. How often? depends on how reproducible this is, the failure rate should be as low as possible, otherwise you might end up at the wrong commit.
(In reply to comment #5) > git bisect is easy to use: > > git bisect start <known-bad> <known-good> In this particular case, I would suggest using git bisect start <known-bad> <known-good> r[5ha]*.[ch] To avoid bisecting r600-specific files, at least for the first time through.
Thanks for the git lessons! Looking just at the r5xx files as Yang suggests returns only one difference: git bisect start df71658688e47614a3f660c28ac1dc77970eb491 ad6c789ad321e56cabdaf826d661ff53ef460e59 r[5ha]*.[ch] Bisecting: -1 revisions left to test after this [047bd7059bcfec55e06a35db4a2b16d52fe8dbf6] EXA: fix for (incompatible) upstream EXA version 3. but I can't compile since so many header and source files changed in the meantime with the branch merge. Ran out of time today to try more, but figured I'd throw this out in case it rang a bell.
Should be irrelevant. This only increases(!) the size of an array that is used in the newest(!) Xserver. If the crash only happens with current git of Xserver, try df71658688e vs. 10c211913de - this actually enables the larger array. > Looking just at the r5xx files as Yang suggests returns only one difference: No, Yang suggested to look at all files except r6*. That's a difference. There are updates in rhd_* files as well.
I can't reproduce this unfortunately. A bisect would be great. Have you changed anything else like the drm?
Started the git-bisect approach in earnest just now, so went and got some a fresh tree to include today's commits Just In Case... ...and as of commit 12611c8f1b3f6e6b2ed7f6cfb1b7271d9a313bdf the problem has gone away! I wouldn't think the most recent commits would have anything to do with the bug, but there it is. I'll close this for now as "FIXED", as it _is_ reproducible (backing out to older versions brings the bug back), but it's one of those not-so-satisfying bugfixes: have no idea _why_ it should be fixed. Certainly can't stand in the way of a release, at any rate!
Darn - it isn't really gone. Data point: it _sometimes_ works on the first instance of X. Good news - so far (knock on fake wood veneer) it reliably does work on the second instance of X. But this will make isolating the problem more entertaining :(
Matthias wrote in Comment #8: > No, Yang suggested to look at all files except r6*. That's a difference. There > are updates in rhd_* files as well. Mispoke. However, the "r[5ha]*.[ch]" wildcard should have picked up rhd* files as well, and there was still just the one unrelated change. Will try to bisect my way through the r6* files too. If they're the only other things changed, then one of those changes must be the one producing this bug as an (odd) bit of unintended consequences.
Any updates? Otherwise we can release now (as few people are seeing this regression) and make a new release when this issue is fixed.
The bug has changed from Every Time to Intermittent, which means testing each step takes multiple shutdowns, so is going slowly. Certainly not worth holding up a release with all the Good Stuff you guys have done. I'll keep plugging at it as a background task.
While I can reproduce this bug by backing out to the aforementioned git commits, all recent versions have behaved properly. If I had to guess - there's some race condition in there which was exposed briefly by the addition of the r6xx code, but which subsequent code changes have obscured. It could even be in the way kde does things rather than radeonhd, as WindowMaker doesn't have the problem. So - am closing this bug. Whatever it is could resurface later - but we'll worry about it at that point. No sense trying to track it down at this point, with so many more pressing bugs to work on.
Agreed. Thanks for your work to reproduce this!
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.