2.6.35-rc[1-5] + Radeon-kms: 3D graphic performance
in [Kernel]
|
From: trapDoor on 22 Jul 2010 20:30 Hi Alex, This is with regard to thread 'Blank (disconnected) screen during boot with latest 2.6.35-rcX kernels'. You asked me in your last e-mail if I could do a bisect to find out what caused a regression I mentioned about - in 3D graphic performance in kernels 2.6.35-rc + radeoon-kms. I started the bisect but unfortunately I haven't finished due to some problems I came across and I'm not sure if I can continue it. I'm pointing below how the bisect went and - if you'd like to take a look - at the last point I explained why I stopped. I did notice some pattern during this unfinished bisect though. And I think it may narrow down the regression to its source. ------ 1. boot from 2.6.35-rc5-git4: git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linus-git cd linux-git git bisect start # marking kernel 2.6.35-rc1 as bad git bisect bad 67a3e12b05e055c0415c556a315a3d3eb637e29e # marking kernel 2.6.34 as good git bisect good e40152ee1e1c7a63f4777791863215e3faa37a86 Bisecting: 4139 revisions left to test after this (roughly 12 steps) [f8965467f366fd18f01feafb5db10512d7b4422c] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 ------ 2. boot from 2.6.34-04401-gf896546 [f8965467f366fd18f01feafb5db10512d7b4422c] git bisect good Bisecting: 1978 revisions left to test after this (roughly 11 steps) [d79df0b1eda0099a22cbcece01ce5e7d222450de] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6 ------ 3. boot from 2.6.34-06562-gd79df0b [d79df0b1eda0099a22cbcece01ce5e7d222450de] git bisect bad Bisecting: 1102 revisions left to test after this (roughly 10 steps) [ac3ee84c604502240122c47b52f0542ec8774f15] Merge branch 'dbg-early-merge' of git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb ------ 4. boot from 2.6.34-05459-gac3ee84 [ac3ee84c604502240122c47b52f0542ec8774f15] git bisect good Bisecting: 551 revisions left to test after this (roughly 9 steps) [7a6cb0d5497418599d2125b670926b75e673861c] Staging: Use kcalloc or kzalloc ------ 5. boot from 2.6.34-rc6-00551-g7a6cb0d [7a6cb0d5497418599d2125b670926b75e673861c] git bisect good Bisecting: 239 revisions left to test after this (roughly 8 steps) [79c4581262e225a7c96d88b632b05ab3b5e9a52c] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc ------ 6. boot from 2.6.34-05771-g79c4581 [79c4581262e225a7c96d88b632b05ab3b5e9a52c] git bisect bad Bisecting: 155 revisions left to test after this (roughly 7 steps) [5876dd249e8e47c730cac090bf6edd88e5f04327] radeon: Unmap vram pages when reclocking ------ 7. boot from 2.6.34-rc5-00156-g5876dd2 [5876dd249e8e47c730cac090bf6edd88e5f04327] At this point I get stuck as I'm unable to perform the tests: -- Gnome fails to start, system freezes right after logging in -- KDE starts but it's almost unusable - very poor 2D performance and 3D seems to not work at all: desktop lost support for transparency/translucency glxgears: just a black window appears with no gears; in the output console it shows this: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 36 requests (36 known processed) with 0 events remaining. Armagetron Advanced obviously doesn't work either - as above, just a black window comes up -- under minimal X environment (xterm) glxgears and Armagetron Advanced behave the same way as above Now I don't know if I can/how to continue this bisect. Clearly 2.6.34-rc5-00156-g5876dd2 is affected in the area I was testing. But differently and to the degree where I'm actually unable to test what I was testing. Also these issues may be not related to the original regression. They may be caused by different commit(s). To sum up: I can't specify whether kernel 2.6.34-rc5-00156-g5876dd2 is good or bad, in order to continue this bisect. Maybe I should start another bisect to solve the problem caused by this kernel, revert/apply appropriate patch(es) and then continue with the original bisect ? And then, with the next kernel, I may be able to carry on or I may be not and have to repeat what I did as a result of the 2nd bisect. Or I may bump into some other problems and have to start 3rd bisect ... I imagine that people can get into such traps but there must be some ways to solve it quicker and not get into endless bisect loop. Of course I'm not saying all this to show that I'm getting discouraged. Not at all - the more I learn about git the more I like it. It's magic, some people say - and I think they may be right. -- Regards trapDoor -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: trapDoor on 22 Jul 2010 21:20 I had sent the first e-mail too soon by accident. In Gmail interface the 'Send' and 'Save Now' buttons are dangerously close to each other, far too close I'd say .. So, what is missing there: - a brief description of the regression (it's in the previous thread) - when did it start: 2.6.35-rc1 - how I tested it - what I think is causing it I will just refer to the last point now: I think the regression is caused by the vblank stuff you mentioned in previous thread. And here is the pattern I've found during testing: Since the vblank patches have been committed (2.6.35-rc1) the glxgears app started to show the accurate number of fps, corresponding to vrefresh, and that's of course good. But in the same time when glxgears behaves properly, the performance in Armagetron Advanced decreases. During the unfinished bisect I had two 'good' and two 'bad' kernels and in each case the bad kernel had the vblank commit(s) applied (as far as I would know - just by looking at number of fps in glxgears) and performance in AA was worse than in the 'good' kernels without the vblank stuff. I'm not suggesting anything that the vblank stuff is responsible directly for the regression. I just say what I noticed. It may be that those patches cause the problem but only in specific circumstances (e.g. with some other patches). I could just revert the commit(s) on current git tree or if there will be any conflicts from some earlier version, and see what happens. I think It will be (one of) these ? commit f81f202402640c27b38e1452dcb4d3e447043f48 Author: Matthew Garrett <mjg(a)redhat.com> Date: Wed Apr 28 12:13:06 2010 -0400 radeon: Try harder to ensure we reclock in vblank The vblank interrupt on r600 doesn't seem to be especially reliable, so perform some sanity checks before the actual reclock. ------ commit 8a56df632e524a1c444c56bb7ce9fe8d94e639e0 Author: Alex Deucher <alexdeucher(a)gmail.com> Date: Mon Mar 15 17:09:05 2010 -0400 drm/radeon/kms/pm: interate across crtcs for vblank -- Regards trapDoor >>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jul 23, 2010 at 1:21 AM, trapDoor <trapdoor6(a)gmail.com> wrote: > Hi Alex, > This is with regard to thread 'Blank (disconnected) screen during boot > with latest 2.6.35-rcX kernels'. > > You asked me in your last e-mail if I could do a bisect to find out > what caused a regression I mentioned about - in 3D graphic performance > in kernels 2.6.35-rc + radeoon-kms. I started the bisect but > unfortunately I haven't finished due to some problems I came across > and I'm not sure if I can continue it. I'm pointing below how the > bisect went and - if you'd like to take a look - at the last point I > explained why I stopped. > > I did notice some pattern during this unfinished bisect though. And I > think it may narrow down the regression to its source. > > > > ------ > 1. boot from 2.6.35-rc5-git4: > git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > linus-git > cd linux-git > git bisect start > > # marking kernel 2.6.35-rc1 as bad > git bisect bad 67a3e12b05e055c0415c556a315a3d3eb637e29e > > # marking kernel 2.6.34 as good > git bisect good e40152ee1e1c7a63f4777791863215e3faa37a86 > Bisecting: 4139 revisions left to test after this (roughly 12 steps) > [f8965467f366fd18f01feafb5db10512d7b4422c] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 > > ------ > 2. boot from 2.6.34-04401-gf896546 [f8965467f366fd18f01feafb5db10512d7b4422c] > git bisect good > Bisecting: 1978 revisions left to test after this (roughly 11 steps) > [d79df0b1eda0099a22cbcece01ce5e7d222450de] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6 > > ------ > 3. boot from 2.6.34-06562-gd79df0b [d79df0b1eda0099a22cbcece01ce5e7d222450de] > git bisect bad > Bisecting: 1102 revisions left to test after this (roughly 10 steps) > [ac3ee84c604502240122c47b52f0542ec8774f15] Merge branch > 'dbg-early-merge' of > git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb > > ------ > 4. boot from 2.6.34-05459-gac3ee84 [ac3ee84c604502240122c47b52f0542ec8774f15] > git bisect good > Bisecting: 551 revisions left to test after this (roughly 9 steps) > [7a6cb0d5497418599d2125b670926b75e673861c] Staging: Use kcalloc or kzalloc > > ------ > 5. boot from 2.6.34-rc6-00551-g7a6cb0d > [7a6cb0d5497418599d2125b670926b75e673861c] > git bisect good > Bisecting: 239 revisions left to test after this (roughly 8 steps) > [79c4581262e225a7c96d88b632b05ab3b5e9a52c] Merge branch 'next' of > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc > > ------ > 6. boot from 2.6.34-05771-g79c4581 [79c4581262e225a7c96d88b632b05ab3b5e9a52c] > git bisect bad > Bisecting: 155 revisions left to test after this (roughly 7 steps) > [5876dd249e8e47c730cac090bf6edd88e5f04327] radeon: Unmap vram pages > when reclocking > > ------ > 7. boot from 2.6.34-rc5-00156-g5876dd2 > [5876dd249e8e47c730cac090bf6edd88e5f04327] > At this point I get stuck as I'm unable to perform the tests: > > -- Gnome fails to start, system freezes right after logging in > > -- KDE starts but it's almost unusable - very poor 2D performance and > 3D seems to not work at all: > desktop lost support for transparency/translucency > glxgears: just a black window appears with no gears; in the output > console it shows this: > XIO: �fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" > � � �after 36 requests (36 known processed) with 0 events remaining. > Armagetron Advanced obviously doesn't work either - as above, just a > black window comes up > > -- under minimal X environment (xterm) glxgears and Armagetron > Advanced behave the same way as above > > Now I don't know if I can/how to continue this bisect. Clearly > 2.6.34-rc5-00156-g5876dd2 is affected in the area I was testing. But > differently and to the degree where I'm actually unable to test what I > was testing. Also these issues may be not related to the original > regression. They may be caused by different commit(s). > > To sum up: I can't specify whether kernel 2.6.34-rc5-00156-g5876dd2 is > good or bad, in order to continue this bisect. > > Maybe I should start another bisect to solve the problem caused by > this kernel, revert/apply appropriate patch(es) and then continue with > the original bisect ? And then, with the next kernel, I may be able to > carry on or I may be not and have to repeat what I did as a result of > the 2nd bisect. Or I may bump into some other problems and have to > start 3rd bisect ... I imagine that people can get into such traps but > there must be some ways to solve it quicker and not get into endless > bisect loop. Of course I'm not saying all this to show that I'm > getting discouraged. Not at all - the more I learn about git the more > I like it. It's magic, some people say - and I think they may be > right. > > > -- > Regards > trapDoor > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alex Deucher on 23 Jul 2010 00:20 On Thu, Jul 22, 2010 at 9:19 PM, trapDoor <trapdoor6(a)gmail.com> wrote: > I had sent the first e-mail too soon by accident. In Gmail interface > the 'Send' and 'Save Now' buttons are dangerously close to each other, > far too close I'd say .. > So, what is missing there: > - a brief description of the regression (it's in the previous thread) > - when did it start: 2.6.35-rc1 > - how I tested it > - what I think is causing it > > I will just refer to the last point now: I think the regression is > caused by the vblank stuff you mentioned in previous thread. And here > is the pattern I've found during testing: > Since the vblank patches have been committed (2.6.35-rc1) the glxgears > app started to show the accurate number of fps, corresponding to > vrefresh, and that's of course good. But in the same time when > glxgears behaves properly, the performance in Armagetron Advanced > decreases. During the unfinished bisect I had two 'good' and two 'bad' > kernels and in each case the bad kernel had the vblank commit(s) > applied (as far as I would know - just by looking at number of fps in > glxgears) and performance in AA was worse than in the 'good' kernels > without the vblank stuff. I'm not suggesting anything that the vblank > stuff is responsible directly for the regression. I just say what I > noticed. It may be that those patches cause the problem but only in > specific circumstances (e.g. with some other patches). > > I could just revert the commit(s) on current git tree or if there will > be any conflicts from some earlier version, and see what happens. I > think It will be (one of) these ? > > commit f81f202402640c27b38e1452dcb4d3e447043f48 > Author: Matthew Garrett <mjg(a)redhat.com> > Date: � Wed Apr 28 12:13:06 2010 -0400 > > � �radeon: Try harder to ensure we reclock in vblank > > � �The vblank interrupt on r600 doesn't seem to be especially reliable, so > � �perform some sanity checks before the actual reclock. > > ------ > commit 8a56df632e524a1c444c56bb7ce9fe8d94e639e0 > Author: Alex Deucher <alexdeucher(a)gmail.com> > Date: � Mon Mar 15 17:09:05 2010 -0400 > > � �drm/radeon/kms/pm: interate across crtcs for vblank > > Those patches are only relevant when you enable dynpm (dynamic power management) which is not enabled by default. I suspect you are seeing some aspect of this bug: https://bugs.freedesktop.org/show_bug.cgi?id=28341 You might try the patches there. Alex > -- > Regards > trapDoor > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > On Fri, Jul 23, 2010 at 1:21 AM, trapDoor <trapdoor6(a)gmail.com> wrote: >> Hi Alex, >> This is with regard to thread 'Blank (disconnected) screen during boot >> with latest 2.6.35-rcX kernels'. >> >> You asked me in your last e-mail if I could do a bisect to find out >> what caused a regression I mentioned about - in 3D graphic performance >> in kernels 2.6.35-rc + radeoon-kms. I started the bisect but >> unfortunately I haven't finished due to some problems I came across >> and I'm not sure if I can continue it. I'm pointing below how the >> bisect went and - if you'd like to take a look - at the last point I >> explained why I stopped. >> >> I did notice some pattern during this unfinished bisect though. And I >> think it may narrow down the regression to its source. >> >> >> >> ------ >> 1. boot from 2.6.35-rc5-git4: >> git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> linus-git >> cd linux-git >> git bisect start >> >> # marking kernel 2.6.35-rc1 as bad >> git bisect bad 67a3e12b05e055c0415c556a315a3d3eb637e29e >> >> # marking kernel 2.6.34 as good >> git bisect good e40152ee1e1c7a63f4777791863215e3faa37a86 >> Bisecting: 4139 revisions left to test after this (roughly 12 steps) >> [f8965467f366fd18f01feafb5db10512d7b4422c] Merge >> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 >> >> ------ >> 2. boot from 2.6.34-04401-gf896546 [f8965467f366fd18f01feafb5db10512d7b4422c] >> git bisect good >> Bisecting: 1978 revisions left to test after this (roughly 11 steps) >> [d79df0b1eda0099a22cbcece01ce5e7d222450de] Merge >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6 >> >> ------ >> 3. boot from 2.6.34-06562-gd79df0b [d79df0b1eda0099a22cbcece01ce5e7d222450de] >> git bisect bad >> Bisecting: 1102 revisions left to test after this (roughly 10 steps) >> [ac3ee84c604502240122c47b52f0542ec8774f15] Merge branch >> 'dbg-early-merge' of >> git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb >> >> ------ >> 4. boot from 2.6.34-05459-gac3ee84 [ac3ee84c604502240122c47b52f0542ec8774f15] >> git bisect good >> Bisecting: 551 revisions left to test after this (roughly 9 steps) >> [7a6cb0d5497418599d2125b670926b75e673861c] Staging: Use kcalloc or kzalloc >> >> ------ >> 5. boot from 2.6.34-rc6-00551-g7a6cb0d >> [7a6cb0d5497418599d2125b670926b75e673861c] >> git bisect good >> Bisecting: 239 revisions left to test after this (roughly 8 steps) >> [79c4581262e225a7c96d88b632b05ab3b5e9a52c] Merge branch 'next' of >> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc >> >> ------ >> 6. boot from 2.6.34-05771-g79c4581 [79c4581262e225a7c96d88b632b05ab3b5e9a52c] >> git bisect bad >> Bisecting: 155 revisions left to test after this (roughly 7 steps) >> [5876dd249e8e47c730cac090bf6edd88e5f04327] radeon: Unmap vram pages >> when reclocking >> >> ------ >> 7. boot from 2.6.34-rc5-00156-g5876dd2 >> [5876dd249e8e47c730cac090bf6edd88e5f04327] >> At this point I get stuck as I'm unable to perform the tests: >> >> -- Gnome fails to start, system freezes right after logging in >> >> -- KDE starts but it's almost unusable - very poor 2D performance and >> 3D seems to not work at all: >> desktop lost support for transparency/translucency >> glxgears: just a black window appears with no gears; in the output >> console it shows this: >> XIO: �fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" >> � � �after 36 requests (36 known processed) with 0 events remaining. >> Armagetron Advanced obviously doesn't work either - as above, just a >> black window comes up >> >> -- under minimal X environment (xterm) glxgears and Armagetron >> Advanced behave the same way as above >> >> Now I don't know if I can/how to continue this bisect. Clearly >> 2.6.34-rc5-00156-g5876dd2 is affected in the area I was testing. But >> differently and to the degree where I'm actually unable to test what I >> was testing. Also these issues may be not related to the original >> regression. They may be caused by different commit(s). >> >> To sum up: I can't specify whether kernel 2.6.34-rc5-00156-g5876dd2 is >> good or bad, in order to continue this bisect. >> >> Maybe I should start another bisect to solve the problem caused by >> this kernel, revert/apply appropriate patch(es) and then continue with >> the original bisect ? And then, with the next kernel, I may be able to >> carry on or I may be not and have to repeat what I did as a result of >> the 2nd bisect. Or I may bump into some other problems and have to >> start 3rd bisect ... I imagine that people can get into such traps but >> there must be some ways to solve it quicker and not get into endless >> bisect loop. Of course I'm not saying all this to show that I'm >> getting discouraged. Not at all - the more I learn about git the more >> I like it. It's magic, some people say - and I think they may be >> right. >> >> >> -- >> Regards >> trapDoor >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Florian Mickler on 24 Jul 2010 06:50 On Fri, 23 Jul 2010 01:21:24 +0100 trapDoor <trapdoor6(a)gmail.com> wrote: > Hi Alex, > This is with regard to thread 'Blank (disconnected) screen during boot > with latest 2.6.35-rcX kernels'. > > You asked me in your last e-mail if I could do a bisect to find out > what caused a regression I mentioned about - in 3D graphic performance > in kernels 2.6.35-rc + radeoon-kms. I started the bisect but > unfortunately I haven't finished due to some problems I came across > and I'm not sure if I can continue it. I'm pointing below how the > bisect went and - if you'd like to take a look - at the last point I > explained why I stopped. > > I did notice some pattern during this unfinished bisect though. And I > think it may narrow down the regression to its source. > > > Hi Alex! I just pasted your good/bad results in my git and did look at it with git bisect visualize What I would do in your case is to try 612e06ce9c7884 radeon: Fix locking in power management paths as that is the one just before your suspected bad commit. Definitely(well 98% certainty) you can skip any powerpc-commits that are left as undecided... just try some commits in the drm/radeon range there to either validate or invalidate your suspicion about f81f202402 (one of the vblank ones) You can just do 'git reset --hard [commit you like to try]' to change the commit you want to try next. (or use git bisect skip) Cheers, Flo p.s.: oh and of course trying the patches suggested by alex in the other mail first is probably a wise thing to do... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: linux-next: OOPS at bot time Next: eeepc-laptop: fix hotplug_disabled module_param permissions |