I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added 2.6.35-rc5 from package. In both cases suspending and resuming works fine.
Then I downloaded 2.6.35-rc5 and compiled it myself. Suspending and resuming works fine.
When trying d-r-t with the same config my machine locks up on suspending, just before machine is expected to turn off.
How can I use "git bisect" command to bisect d-r-t specific commits?
Am 20.07.2010 12:14, schrieb Rafał Miłecki:
I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added 2.6.35-rc5 from package. In both cases suspending and resuming works fine.
Then I downloaded 2.6.35-rc5 and compiled it myself. Suspending and resuming works fine.
When trying d-r-t with the same config my machine locks up on suspending, just before machine is expected to turn off.
How can I use "git bisect" command to bisect d-r-t specific commits?
Fwiw, for me (HD3200, RS780) current d-r-t resume from suspend to ram does not work. Last thing it shows is the text console with some random colored pixels, but not the X display where it was suspended from. It appeared liked the kernel was still running, but X was completely crashed and stuck. I haven't had the time yet to further debug this.
Regards Marius
W dniu 20 lipca 2010 13:15 użytkownik Marius Gröger marius.groeger@googlemail.com napisał:
Am 20.07.2010 12:14, schrieb Rafał Miłecki:
I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added 2.6.35-rc5 from package. In both cases suspending and resuming works fine.
Then I downloaded 2.6.35-rc5 and compiled it myself. Suspending and resuming works fine.
When trying d-r-t with the same config my machine locks up on suspending, just before machine is expected to turn off.
How can I use "git bisect" command to bisect d-r-t specific commits?
Fwiw, for me (HD3200, RS780) current d-r-t resume from suspend to ram does not work. Last thing it shows is the text console with some random colored pixels, but not the X display where it was suspended from. It appeared liked the kernel was still running, but X was completely crashed and stuck. I haven't had the time yet to further debug this.
Now when I managed to merge Linus's tree into d-r-t suspend works fine for me, but I get lock up after resuming. It's quite funny effect, PANEL slowly blinks for 3 times and then it freezes.
I guess I'll have to learn rebasing instead of merging, so I'll have all d-r-t specific patches on top or rc5, which will let me bisect.
OK, next question :/ How can I rebase local d-r-t onto Linus's tree? I've Linus's remote tree added and fetched but can not rebase against it.
# git rebase linus Current branch drm-radeon-testing is up to date.
# git rebase --onto linus drm-radeon-testing Current branch drm-radeon-testing is up to date.
On Tue, 2010-07-20 at 23:37 +0200, Rafał Miłecki wrote:
OK, next question :/ How can I rebase local d-r-t onto Linus's tree? I've Linus's remote tree added and fetched but can not rebase against it.
# git rebase linus Current branch drm-radeon-testing is up to date.
# git rebase --onto linus drm-radeon-testing Current branch drm-radeon-testing is up to date.
git rebase linus/master
W dniu 21 lipca 2010 00:36 użytkownik Dave Airlie airlied@redhat.com napisał:
On Tue, 2010-07-20 at 23:37 +0200, Rafał Miłecki wrote:
OK, next question :/ How can I rebase local d-r-t onto Linus's tree? I've Linus's remote tree added and fetched but can not rebase against it.
# git rebase linus Current branch drm-radeon-testing is up to date.
# git rebase --onto linus drm-radeon-testing Current branch drm-radeon-testing is up to date.
git rebase linus/master
Thanks a lot!
First bisect try gave me: bad: [d8c253f30d0eb975e5c42c31587ef718517f5067] drm/radeon: optimize default 3D state for r6xx/r7xx blits
I'm leaving today, not sure if I manage to confirm this before next week.
W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zajec5@gmail.com napisał:
First bisect try gave me: bad: [d8c253f30d0eb975e5c42c31587ef718517f5067] drm/radeon: optimize default 3D state for r6xx/r7xx blits
I'm leaving today, not sure if I manage to confirm this before next week.
I switched back to rebased drm-radeon-testing and confirmed lockup. Then reverted that single patch and it helped. I'm quite sure it's the "bad one".
I use KDE4 with effects enabled, so 3D is enabled here.
Not time to dig into this problem deeper, leaving now.
2010/7/21 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zajec5@gmail.com napisał:
First bisect try gave me: bad: [d8c253f30d0eb975e5c42c31587ef718517f5067] drm/radeon: optimize default 3D state for r6xx/r7xx blits
I'm leaving today, not sure if I manage to confirm this before next week.
I switched back to rebased drm-radeon-testing and confirmed lockup. Then reverted that single patch and it helped. I'm quite sure it's the "bad one".
I use KDE4 with effects enabled, so 3D is enabled here.
Not time to dig into this problem deeper, leaving now.
When you get back can you revert the original and test version 2 of that patch (attached). It puts back the original state, but reorganizes the emit order to reduce the number of dwords.
Alex
W dniu 21 lipca 2010 19:23 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/21 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zajec5@gmail.com napisał:
First bisect try gave me: bad: [d8c253f30d0eb975e5c42c31587ef718517f5067] drm/radeon: optimize default 3D state for r6xx/r7xx blits
I'm leaving today, not sure if I manage to confirm this before next week.
I switched back to rebased drm-radeon-testing and confirmed lockup. Then reverted that single patch and it helped. I'm quite sure it's the "bad one".
I use KDE4 with effects enabled, so 3D is enabled here.
Not time to dig into this problem deeper, leaving now.
When you get back can you revert the original and test version 2 of that patch (attached). It puts back the original state, but reorganizes the emit order to reduce the number of dwords.
Applied V2 instead of V1 and got lockup again (on resume). Reverting applied V2 (so without V1 and without V2) "fixes" lockup.
2010/7/24 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 19:23 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/21 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zajec5@gmail.com napisał:
First bisect try gave me: bad: [d8c253f30d0eb975e5c42c31587ef718517f5067] drm/radeon: optimize default 3D state for r6xx/r7xx blits
I'm leaving today, not sure if I manage to confirm this before next week.
I switched back to rebased drm-radeon-testing and confirmed lockup. Then reverted that single patch and it helped. I'm quite sure it's the "bad one".
I use KDE4 with effects enabled, so 3D is enabled here.
Not time to dig into this problem deeper, leaving now.
When you get back can you revert the original and test version 2 of that patch (attached). It puts back the original state, but reorganizes the emit order to reduce the number of dwords.
Applied V2 instead of V1 and got lockup again (on resume). Reverting applied V2 (so without V1 and without V2) "fixes" lockup.
I see the problem. The original waited for idle at the top of the default state. This new patch is v1 + wait for idle. Please remove v1 and v2 and then apply v3.
Alex
W dniu 24 lipca 2010 22:41 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/24 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 19:23 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/21 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zajec5@gmail.com napisał:
First bisect try gave me: bad: [d8c253f30d0eb975e5c42c31587ef718517f5067] drm/radeon: optimize default 3D state for r6xx/r7xx blits
I'm leaving today, not sure if I manage to confirm this before next week.
I switched back to rebased drm-radeon-testing and confirmed lockup. Then reverted that single patch and it helped. I'm quite sure it's the "bad one".
I use KDE4 with effects enabled, so 3D is enabled here.
Not time to dig into this problem deeper, leaving now.
When you get back can you revert the original and test version 2 of that patch (attached). It puts back the original state, but reorganizes the emit order to reduce the number of dwords.
Applied V2 instead of V1 and got lockup again (on resume). Reverting applied V2 (so without V1 and without V2) "fixes" lockup.
I see the problem. The original waited for idle at the top of the default state. This new patch is v1 + wait for idle. Please remove v1 and v2 and then apply v3.
Whoops, still no luck with V3 (applied as only version of patch) :| Is that possible to split changes in r6xx_default_state to track down problematic one?
The difference I noticed with V3 is that I got 5-6 screen flashes after resuming. Earlier it was about 3. However I tested it just once, can be not related.
2010/7/25 Rafał Miłecki zajec5@gmail.com:
W dniu 24 lipca 2010 22:41 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/24 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 19:23 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/21 Rafał Miłecki zajec5@gmail.com:
W dniu 21 lipca 2010 11:30 użytkownik Rafał Miłecki zajec5@gmail.com napisał:
First bisect try gave me: bad: [d8c253f30d0eb975e5c42c31587ef718517f5067] drm/radeon: optimize default 3D state for r6xx/r7xx blits
I'm leaving today, not sure if I manage to confirm this before next week.
I switched back to rebased drm-radeon-testing and confirmed lockup. Then reverted that single patch and it helped. I'm quite sure it's the "bad one".
I use KDE4 with effects enabled, so 3D is enabled here.
Not time to dig into this problem deeper, leaving now.
When you get back can you revert the original and test version 2 of that patch (attached). It puts back the original state, but reorganizes the emit order to reduce the number of dwords.
Applied V2 instead of V1 and got lockup again (on resume). Reverting applied V2 (so without V1 and without V2) "fixes" lockup.
I see the problem. The original waited for idle at the top of the default state. This new patch is v1 + wait for idle. Please remove v1 and v2 and then apply v3.
Whoops, still no luck with V3 (applied as only version of patch) :| Is that possible to split changes in r6xx_default_state to track down problematic one?
I'll try and break it down more fine grained tomorrow.
The difference I noticed with V3 is that I got 5-6 screen flashes after resuming. Earlier it was about 3. However I tested it just once, can be not related.
How about v4 (attached)? Any better?
Alex
W dniu 26 lipca 2010 07:57 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
How about v4 (attached)? Any better?
I counted up to 9 flashes after resume this time. Didn't try this again (maybe different amount of flashses).
2010/7/26 Rafał Miłecki zajec5@gmail.com:
W dniu 26 lipca 2010 07:57 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
How about v4 (attached)? Any better?
I counted up to 9 flashes after resume this time. Didn't try this again (maybe different amount of flashses).
I've broken it down into 6 patches available here: http://people.freedesktop.org/~agd5f/reduce_emit/
Alex
W dniu 26 lipca 2010 20:55 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/26 Rafał Miłecki zajec5@gmail.com:
W dniu 26 lipca 2010 07:57 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
How about v4 (attached)? Any better?
I counted up to 9 flashes after resume this time. Didn't try this again (maybe different amount of flashses).
I've broken it down into 6 patches available here: http://people.freedesktop.org/~agd5f/reduce_emit/
Thanks for this splitting your patch!
I got lock up after applying 0001 and 0002. I fixed it with attached half-revert-patch. Didn't experiment with 0003 - 0006 yet.
2010/7/26 Rafał Miłecki zajec5@gmail.com:
W dniu 26 lipca 2010 20:55 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/26 Rafał Miłecki zajec5@gmail.com:
W dniu 26 lipca 2010 07:57 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
How about v4 (attached)? Any better?
I counted up to 9 flashes after resume this time. Didn't try this again (maybe different amount of flashses).
I've broken it down into 6 patches available here: http://people.freedesktop.org/~agd5f/reduce_emit/
Thanks for this splitting your patch!
I got lock up after applying 0001 and 0002. I fixed it with attached half-revert-patch. Didn't experiment with 0003 - 0006 yet.
Weird we shouldn't need the sampler state as we emit that later based on the source surface we are copying. Can you try with all patches both with and without the sampler emit put back?
Alex
2010/7/26 Rafał Miłecki zajec5@gmail.com:
W dniu 26 lipca 2010 20:55 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/26 Rafał Miłecki zajec5@gmail.com:
W dniu 26 lipca 2010 07:57 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
How about v4 (attached)? Any better?
I counted up to 9 flashes after resume this time. Didn't try this again (maybe different amount of flashses).
I've broken it down into 6 patches available here: http://people.freedesktop.org/~agd5f/reduce_emit/
Thanks for this splitting your patch!
I got lock up after applying 0001 and 0002. I fixed it with attached half-revert-patch. Didn't experiment with 0003 - 0006 yet.
I'm an idiot. The sampler state needs to be there as it's not emitted subsequently; I was thinking it got emitted with the texture fetch constants like it does in the ddx. That was the issue all along. Thanks for tracking that down. New set of patches: http://people.freedesktop.org/~agd5f/reduce_emit/
Alex
W dniu 27 lipca 2010 17:27 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
I'm an idiot. The sampler state needs to be there as it's not emitted subsequently; I was thinking it got emitted with the texture fetch constants like it does in the ddx. That was the issue all along. Thanks for tracking that down. New set of patches: http://people.freedesktop.org/~agd5f/reduce_emit/
Following refers to patches from 27-Jul-2010 08:26.
After applying all 7 patches I get hard lockup on suspend (not even resume!). I decided to apply one by one to track this down.
Applying 0001 and 0002 doesn't cause any problem.
After applying 0003 (on top of 0001 and 0002) I get hard lockup just like in case of all patches. Attached patch shows which part of 0003 has to be reverted to make suspending (and resuming) work. I think it's still not minimal patch (maybe reverting just part of that code would be enough) but hope it's small enough to give you some idea.
W dniu 27 lipca 2010 23:53 użytkownik Rafał Miłecki zajec5@gmail.com napisał:
W dniu 27 lipca 2010 17:27 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
I'm an idiot. The sampler state needs to be there as it's not emitted subsequently; I was thinking it got emitted with the texture fetch constants like it does in the ddx. That was the issue all along. Thanks for tracking that down. New set of patches: http://people.freedesktop.org/~agd5f/reduce_emit/
Following refers to patches from 27-Jul-2010 08:26.
After applying all 7 patches I get hard lockup on suspend (not even resume!). I decided to apply one by one to track this down.
Applying 0001 and 0002 doesn't cause any problem.
After applying 0003 (on top of 0001 and 0002) I get hard lockup just like in case of all patches. Attached patch shows which part of 0003 has to be reverted to make suspending (and resuming) work. I think it's still not minimal patch (maybe reverting just part of that code would be enough) but hope it's small enough to give you some idea.
P.S. Unfortunately attached patch doesn't apply on top of all 7 patches.
2010/7/27 Rafał Miłecki zajec5@gmail.com:
W dniu 27 lipca 2010 17:27 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
I'm an idiot. The sampler state needs to be there as it's not emitted subsequently; I was thinking it got emitted with the texture fetch constants like it does in the ddx. That was the issue all along. Thanks for tracking that down. New set of patches: http://people.freedesktop.org/~agd5f/reduce_emit/
Following refers to patches from 27-Jul-2010 08:26.
After applying all 7 patches I get hard lockup on suspend (not even resume!). I decided to apply one by one to track this down.
Applying 0001 and 0002 doesn't cause any problem.
After applying 0003 (on top of 0001 and 0002) I get hard lockup just like in case of all patches. Attached patch shows which part of 0003 has to be reverted to make suspending (and resuming) work. I think it's still not minimal patch (maybe reverting just part of that code would be enough) but hope it's small enough to give you some idea.
Sorry, the count was wrong on that packet. New set of patches at the same location: http://people.freedesktop.org/~agd5f/reduce_emit/ Only 0003 had changed.
Alex
W dniu 28 lipca 2010 01:01 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/27 Rafał Miłecki zajec5@gmail.com:
W dniu 27 lipca 2010 17:27 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
I'm an idiot. The sampler state needs to be there as it's not emitted subsequently; I was thinking it got emitted with the texture fetch constants like it does in the ddx. That was the issue all along. Thanks for tracking that down. New set of patches: http://people.freedesktop.org/~agd5f/reduce_emit/
Following refers to patches from 27-Jul-2010 08:26.
After applying all 7 patches I get hard lockup on suspend (not even resume!). I decided to apply one by one to track this down.
Applying 0001 and 0002 doesn't cause any problem.
After applying 0003 (on top of 0001 and 0002) I get hard lockup just like in case of all patches. Attached patch shows which part of 0003 has to be reverted to make suspending (and resuming) work. I think it's still not minimal patch (maybe reverting just part of that code would be enough) but hope it's small enough to give you some idea.
Sorry, the count was wrong on that packet. New set of patches at the same location: http://people.freedesktop.org/~agd5f/reduce_emit/ Only 0003 had changed.
Success this time! :) Thanks for fixing this.
2010/7/28 Rafał Miłecki zajec5@gmail.com:
W dniu 28 lipca 2010 01:01 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
2010/7/27 Rafał Miłecki zajec5@gmail.com:
W dniu 27 lipca 2010 17:27 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
I'm an idiot. The sampler state needs to be there as it's not emitted subsequently; I was thinking it got emitted with the texture fetch constants like it does in the ddx. That was the issue all along. Thanks for tracking that down. New set of patches: http://people.freedesktop.org/~agd5f/reduce_emit/
Following refers to patches from 27-Jul-2010 08:26.
After applying all 7 patches I get hard lockup on suspend (not even resume!). I decided to apply one by one to track this down.
Applying 0001 and 0002 doesn't cause any problem.
After applying 0003 (on top of 0001 and 0002) I get hard lockup just like in case of all patches. Attached patch shows which part of 0003 has to be reverted to make suspending (and resuming) work. I think it's still not minimal patch (maybe reverting just part of that code would be enough) but hope it's small enough to give you some idea.
Sorry, the count was wrong on that packet. New set of patches at the same location: http://people.freedesktop.org/~agd5f/reduce_emit/ Only 0003 had changed.
Success this time! :) Thanks for fixing this.
Thanks for sticking with it and dealing with my stupid typos ;)
Alex
2010/7/20 Rafał Miłecki zajec5@gmail.com:
I've installed openSUSE 11.3 which comes with 2.6.34 kernel and added 2.6.35-rc5 from package. In both cases suspending and resuming works fine.
Then I downloaded 2.6.35-rc5 and compiled it myself. Suspending and resuming works fine.
When trying d-r-t with the same config my machine locks up on suspending, just before machine is expected to turn off.
How can I use "git bisect" command to bisect d-r-t specific commits?
The last upstream -rc to get merged into d-r-t was 2.6.35-rc4. If -rc4 works, you could try bisecting from that point: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h...
Alex
W dniu 20 lipca 2010 18:21 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
The last upstream -rc to get merged into d-r-t was 2.6.35-rc4. If -rc4 works, you could try bisecting from that point: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h...
My bad, there is some regression in 2.6.35-rc4 (or even earlier) that was fixed in 2.6.35-rc5.
Do you mind if I ask how can I locally merge current Linus's tree into local d-r-t? :)
2010/7/20 Rafał Miłecki zajec5@gmail.com:
W dniu 20 lipca 2010 18:21 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
The last upstream -rc to get merged into d-r-t was 2.6.35-rc4. If -rc4 works, you could try bisecting from that point: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h...
My bad, there is some regression in 2.6.35-rc4 (or even earlier) that was fixed in 2.6.35-rc5.
Do you mind if I ask how can I locally merge current Linus's tree into local d-r-t? :)
It's been a while since I merged a remote, but I think the following should work. If you have Dave's tree cloned, you'll need to add Linus' tree: git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Then fetch the changes from his tree: git fetch linus Then merge Linus' tree into your local tree: git pull linus
Alex
W dniu 20 lipca 2010 20:44 użytkownik Alex Deucher alexdeucher@gmail.com napisał:
Then merge Linus' tree into your local tree: git pull linus
It was just about adding "master" after last one. Thanks a lot! :)
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Dave Airlie -
Marius Gröger -
Rafał Miłecki