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
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 <[email protected]>
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 <[email protected]>
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 <[email protected]> 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
>
On Thu, Jul 22, 2010 at 9:19 PM, trapDoor <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> 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 <[email protected]> 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
>>
>
On Fri, 23 Jul 2010 01:21:24 +0100
trapDoor <[email protected]> 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...