help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]


Hi!

I am seeking help with encircling the cause of:

[Bug 16376] random - possibly Radeon DRM KMS related - freezes
https://bugzilla.kernel.org/show_bug.cgi?id=16376

I started a bisection as described in which has been painful for me - at 
least for a first time bisection -, but after the second skip of a non-
booting kernel git points me to a kernel that is outside of the initial 
range between good and back.

good is: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33

bad is: bad: [64ba9926759792cf7b95f823402e2781edd1b5d4] Merge branch 'for-
linus' of git://git.open-osd.org/linux-open-osd

After skipping the last non booting kernel, git bisect put me to 
5be796f0b842c5852d7397a82f8ebd6be8451872 which is just 300 lines after 
2.6.33-rc2.

Obviously I am not interested in kernels prior 2.6.33. Should I just do a 
"git bisect good" without trying the kernel or is there some other remedy? 
its 11 cycles already without testing anything outside the initial 
good/bad range and it takes about half a day to be somewhat sure that a 
kernel is good, so I'd like to avoid testing versions outside this range.

My bug comment #35 contains a log of the bisection[1].

[1] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c35

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Ken Moffat]

On Tue, Aug 31, 2010 at 09:53:43PM +0200, Martin Steigerwald wrote:
> 
> Hi!
> 
> I am seeking help with encircling the cause of:
> 
> [Bug 16376] random - possibly Radeon DRM KMS related - freezes
> https://bugzilla.kernel.org/show_bug.cgi?id=16376
> 
> I started a bisection as described in which has been painful for me - at 
> least for a first time bisection -, but after the second skip of a non-
> booting kernel git points me to a kernel that is outside of the initial 
> range between good and back.
> 
> good is: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33
> 
> bad is: bad: [64ba9926759792cf7b95f823402e2781edd1b5d4] Merge branch 'for-
> linus' of git://git.open-osd.org/linux-open-osd
> 
> After skipping the last non booting kernel, git bisect put me to 
> 5be796f0b842c5852d7397a82f8ebd6be8451872 which is just 300 lines after 
> 2.6.33-rc2.
> 
> Obviously I am not interested in kernels prior 2.6.33. Should I just do a 
> "git bisect good" without trying the kernel or is there some other remedy? 
> its 11 cycles already without testing anything outside the initial 
> good/bad range and it takes about half a day to be somewhat sure that a 
> kernel is good, so I'd like to avoid testing versions outside this range.

 While you are bisecting, don't believe the version in Makefile.  I
got similarly freaked out a couple of years ago - if I understood
correctly, it's something to do with when a change was created.

 The key point is that during bisection the apparent version *can*
go back to a version that appears to be before the initial "good"
kernel.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 2054 bytes --]

Am Mittwoch 01 September 2010 schrieb Ken Moffat:
> On Tue, Aug 31, 2010 at 09:53:43PM +0200, Martin Steigerwald wrote:
> > Hi!
> > 
> > I am seeking help with encircling the cause of:
> > 
> > [Bug 16376] random - possibly Radeon DRM KMS related - freezes
> > https://bugzilla.kernel.org/show_bug.cgi?id=16376
> > 
> > I started a bisection as described in which has been painful for me -
> > at least for a first time bisection -, but after the second skip of
> > a non- booting kernel git points me to a kernel that is outside of
> > the initial range between good and back.
> > 
> > good is: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33
> > 
> > bad is: bad: [64ba9926759792cf7b95f823402e2781edd1b5d4] Merge branch
> > 'for- linus' of git://git.open-osd.org/linux-open-osd
> > 
> > After skipping the last non booting kernel, git bisect put me to
> > 5be796f0b842c5852d7397a82f8ebd6be8451872 which is just 300 lines
> > after 2.6.33-rc2.
> > 
> > Obviously I am not interested in kernels prior 2.6.33. Should I just
> > do a "git bisect good" without trying the kernel or is there some
> > other remedy? its 11 cycles already without testing anything outside
> > the initial good/bad range and it takes about half a day to be
> > somewhat sure that a kernel is good, so I'd like to avoid testing
> > versions outside this range.
> 
>  While you are bisecting, don't believe the version in Makefile.  I
> got similarly freaked out a couple of years ago - if I understood
> correctly, it's something to do with when a change was created.
> 
>  The key point is that during bisection the apparent version *can*
> go back to a version that appears to be before the initial "good"
> kernel.

I verified the version by running git log after doing the skip. And it was 
just 300 lines after Linus commited 2.6.33-rc2. Can git log be showing 
incorrect results during a bisect?

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Ken Moffat]

On Wed, Sep 01, 2010 at 06:10:24PM +0200, Martin Steigerwald wrote:
> Am Mittwoch 01 September 2010 schrieb Ken Moffat:
> > 
> >  While you are bisecting, don't believe the version in Makefile.  I
> > got similarly freaked out a couple of years ago - if I understood
> > correctly, it's something to do with when a change was created.
> > 
> >  The key point is that during bisection the apparent version *can*
> > go back to a version that appears to be before the initial "good"
> > kernel.
> 
> I verified the version by running git log after doing the skip. And it was 
> just 300 lines after Linus commited 2.6.33-rc2. Can git log be showing 
> incorrect results during a bisect?
> 
> Thanks,
 I suggest you go with the versions that git bisect selects.

 I appreciate that it takes you a long time to build and test each
kernel, but hopefully you can reach a stage where the bad commit is
identified.

 I think I've seen people report that an old commit was identified
as causing a problem, and I also think that in those cases the
problem was exposed by a later commit.

ken
-- 
das eine Mal als Tragödie, das andere Mal als Farce

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Paolo Ornati]

On Tue, 31 Aug 2010 21:53:43 +0200
Martin Steigerwald <Martin@lichtvoll.de> wrote:

> Obviously I am not interested in kernels prior 2.6.33. Should I just do a 
> "git bisect good" without trying the kernel or is there some other remedy? 

No. Git is right in asking you to test that commit: you are ignoring
branches and merges.

Example
========

Linus Tree	Usb Tree

v2.6.33-rc2
|          \
|           | commit A (version is v2.6.33-rc2)
|           | commit B ( " )
v2.6.33     | commit C ( " )
|        __/
|     __/
|  __/
|_/
X <--- MERGE

So the commit you are testing it's like "commit A": it was done before
(in time) v2.6.33, on a kernel based on v2.6.33-rc2, but was merged in
Linus' tree _after_ v2.3.33.

So this this behaviour is normal :)

-- 
	Paolo Ornati
	Linux 2.6.35.4 on x86_64

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 870 bytes --]

Am Mittwoch 01 September 2010 schrieb Paolo Ornati:
> On Tue, 31 Aug 2010 21:53:43 +0200
> 
> Martin Steigerwald <Martin@lichtvoll.de> wrote:
> > Obviously I am not interested in kernels prior 2.6.33. Should I just
> > do a "git bisect good" without trying the kernel or is there some
> > other remedy?
> 
> No. Git is right in asking you to test that commit: you are ignoring
> branches and merges.
> 
> Example
[...]
> So the commit you are testing it's like "commit A": it was done before
> (in time) v2.6.33, on a kernel based on v2.6.33-rc2, but was merged in
> Linus' tree _after_ v2.3.33.
> 
> So this this behaviour is normal :)

Thanks. That explains it. So I compile this kernel and continue bisecting 
as usual.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 2850 bytes --]

Am Mittwoch 01 September 2010 schrieb Paolo Ornati:
> On Tue, 31 Aug 2010 21:53:43 +0200
> 
> Martin Steigerwald <Martin@lichtvoll.de> wrote:
> > Obviously I am not interested in kernels prior 2.6.33. Should I just
> > do a "git bisect good" without trying the kernel or is there some
> > other remedy?
> 
> No. Git is right in asking you to test that commit: you are ignoring
> branches and merges.
[...]
> So this this behaviour is normal :)

So as to the advice of Ted in the thread "stable? quality assurance?" I am 
seeking some more help with bisecting this bug. I continued bisecting and 
stumbled upon some problems:

Quite some kernels were unbootable with an ext4 and readahead related 
backtrace[1]. These were all within an USB merge and after skipping about 
five unbootable kernels I skipped the whole range of commits in it. I 
wondered by git insisted taking me back to this range of commits, even in 
the middle of two skips, instead of automatically re-adjusting the binary 
search, so that range would not be hit again for a while. Cause then its 
would have not been hit at all eventually. Anyway, I think this problem 
got fixed prior to 2.6.34 so I am asking whether there is a patch, a commit 
that fixed it in case I should stumble about such a unbootable kernel 
again. I attached the backtrace screenshot to my bug comment[1]. Ted, I am 
not booting from USB, but from the internal harddrive. I think these 
backtraces are completely unrelated to that USB commits. I think the bug 
has been introduced before that USB merge and fixed somewhen afterwards, 
but from a quick glance I didn't find the commit that fixes it.

I am also seeking help with selecting more suitable commits to test: If 
its a Radeon KMS related freeze and everything points at it, I think the 
offending commit is in the first quarter of what git commit shows to me[2]. 
Thus I'd  like to select one commit before those drm/kms related commits 
and one after it, before testing any other commits. But I have been fooled 
by those branches and merges before and there is the range of skipped 
commits in that USB merge, thus I'd like advice on which commits to 
select. A current git bisect log I attached to [2]. I will continue 
bisecting as usual for the time being, but I really appreciate some help, 
cause its still above 1800 commits to test otherwise and I am quite 
annoyed by seeing the same roughly 11 steps even if the absolute number of 
commits got down by about somewhat:

Bisecting: 1861 revisions left to test after this (roughly 11 steps)

[1] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c37
[2] https://bugzilla.kernel.org/show_bug.cgi?id=16376#c38

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Paolo Ornati]

On Sun, 5 Sep 2010 09:53:41 +0200
Martin Steigerwald <Martin@lichtvoll.de> wrote:

> I am also seeking help with selecting more suitable commits to test: If 
> its a Radeon KMS related freeze and everything points at it, I think the 
> offending commit is in the first quarter of what git commit shows to me[2]. 
> Thus I'd  like to select one commit before those drm/kms related commits 
> and one after it, before testing any other commits.

If you "know better" than git-bisect and want to test a particular
commit, just do:

	git reset --hard commit_id

-- 
	Paolo Ornati
	Linux 2.6.35.4 on x86_64

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 1734 bytes --]

Am Sonntag 05 September 2010 schrieb Paolo Ornati:
> On Sun, 5 Sep 2010 09:53:41 +0200
> 
> Martin Steigerwald <Martin@lichtvoll.de> wrote:
> > I am also seeking help with selecting more suitable commits to test:
> > If its a Radeon KMS related freeze and everything points at it, I
> > think the offending commit is in the first quarter of what git
> > commit shows to me[2]. Thus I'd  like to select one commit before
> > those drm/kms related commits and one after it, before testing any
> > other commits.
> 
> If you "know better" than git-bisect and want to test a particular
> commit, just do:
> 
> 	git reset --hard commit_id

That part I understood from the manpage. But I seeked help to choose 
exactly which commit.

Well I now go with

martin@shambhala:~/Computer/Shambhala/Kernel/2.6.33-2.6.34-
bisect/linux-2.6> git log | head      
commit a27341cd5fcb7cf2d2d4726e9f324009f7162c00
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Mar 2 08:36:46 2010 -0800

    Prioritize synchronous signals over 'normal' signals
    
    This makes sure that we pick the synchronous signals caused by a
    processor fault over any pending regular asynchronous signals sent to
    use by [t]kill().

When I interpret the graphical display of gitk correctly this one should 
be directly before the whole lot of KMS/DRM/Radeon/Intel commits being 
merged.

Now hopefully this one boots. And is good. Then I would have skipped a 
whole lot of the revisions to test. But even when it just boots, but is 
bad, I at least know that its not in these merges.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Ted Ts'o]

On Sun, Sep 05, 2010 at 09:53:41AM +0200, Martin Steigerwald wrote:
> 
> Quite some kernels were unbootable with an ext4 and readahead related 
> backtrace[1]. 

Unfortunately, you don't have a full backtrace in the picture which
submitted as an attachment to the bugzilla.  It shows part of the
backtrace which has an ext4 and readahead stack, yes.  But we didn't
get to see the beginning of the stack trace with the IP and the reason
for the oops.  If keyboard interrupts still work, you might try seing
if you can scroll upwards and see more of the backtrace.  Or you might
try configuring your console to use a higher resolution display so
more lines can be displayed.  Or you might try getting a serial
console.

I don't recognize the display, but the problem could just as easily be
in the block layer or in the device driver for your hard drive.
(i.e., the readahead stack calls ext4, which in turn will submit a
read request to the block device layer which then submits the request
to a device driver).

But because you keep referring it to it as an ext4/readahead related
backtrace, you may have disguised the symptom enough that people who
might recognize it as, "Oh, yeah, there was this regression in the
SATA layer", wouldn't recognize it as such from your description.
That's why it's important to be careful how you describe issues; if
you had said, I don't have a complete stack trace, and I don't have
the IP and function where the fault occurred, that might have caused
people to think a bit harder about what might be the problem, instead
of thinking to themselves, "ah, well, the ext4 and readahead parts of
the kernel aren't my problem, so I'll ignore this report".

> I am also seeking help with selecting more suitable commits to test: If 
> its a Radeon KMS related freeze and everything points at it, I think the 
> offending commit is in the first quarter of what git commit shows to me[2]. 

You do know that you can restrict a git bisect to commits that modify
a particular part of the tree, right?  e.g.,

git bisect start 2.6.34 2.6.33 -- drivers/gpu/drm/radeon

					- Ted

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 4191 bytes --]

Am Dienstag 07 September 2010 schrieb Ted Ts'o:
> On Sun, Sep 05, 2010 at 09:53:41AM +0200, Martin Steigerwald wrote:
> > Quite some kernels were unbootable with an ext4 and readahead related
> > backtrace[1].
> 
> Unfortunately, you don't have a full backtrace in the picture which
> submitted as an attachment to the bugzilla.  It shows part of the
> backtrace which has an ext4 and readahead stack, yes.  But we didn't
> get to see the beginning of the stack trace with the IP and the reason
> for the oops.  If keyboard interrupts still work, you might try seing
> if you can scroll upwards and see more of the backtrace.  Or you might
> try configuring your console to use a higher resolution display so
> more lines can be displayed.  Or you might try getting a serial
> console.

Thanks for your detailled analysis. I missed posting an update to the 
thread. I did not have to go back to those kernels again and bisected the 
issue down to about 10 revisions, when Alex suggested my bug might be a 
duplicate of

[Bug 28402] random radeon/kms/drm related freezes with kernel 2.6.34
https://bugs.freedesktop.org/show_bug.cgi?id=28402

So I tried some patches in there and the vmembase at zero patch seems to 
do the trick. Although I am not sure, whether its a solution or a work-
around.

> I don't recognize the display, but the problem could just as easily be
> in the block layer or in the device driver for your hard drive.
> (i.e., the readahead stack calls ext4, which in turn will submit a
> read request to the block device layer which then submits the request
> to a device driver).

Yes, I am aware that it may not be a Ext4 problem at all. Thus I said Ext4 
/ readahead related (!) backtrace (! not bug) cause that was all I could 
see on the screen. How else should I have described that backtrace when I 
can't speculate on what I can not see?

> But because you keep referring it to it as an ext4/readahead related
> backtrace, you may have disguised the symptom enough that people who
> might recognize it as, "Oh, yeah, there was this regression in the
> SATA layer", wouldn't recognize it as such from your description.
> That's why it's important to be careful how you describe issues; if
> you had said, I don't have a complete stack trace, and I don't have
> the IP and function where the fault occurred, that might have caused
> people to think a bit harder about what might be the problem, instead
> of thinking to themselves, "ah, well, the ext4 and readahead parts of
> the kernel aren't my problem, so I'll ignore this report".

I thought thats what the provided backtrace is for. And I think that any 
developer can see that it isn't complete.

I will include a note that the backtrace is incomplete next time 
nevertheless.

It would be good to have a backtrace viewer and saver that still works in 
those conditions ;-). And when it just writes it somewhere on the swap 
partition were a tool can grab it after booting again. But when the kernel 
is completely messed up, exactly that can be very dangerous.

> > I am also seeking help with selecting more suitable commits to test:
> > If its a Radeon KMS related freeze and everything points at it, I
> > think the offending commit is in the first quarter of what git
> > commit shows to me[2].
> 
> You do know that you can restrict a git bisect to commits that modify
> a particular part of the tree, right?  e.g.,
> 
> git bisect start 2.6.34 2.6.33 -- drivers/gpu/drm/radeon

Yes, I have seen that in the git manpage, but since I wasn't absolutely 
sure, that the freeze is radeon kms/drm related I skipped that step. From 
what I learned I should have looked at git bisect visualize earlier and 
selected from commits prior and after that drm kms related merges. That 
would have spared me quite some time when my suspicion was right, like it 
turned out to be, and wouldn't have taken many more turn arounds when it 
was wrong.

Next time I know this.

Thanks for your help, I appreciate it.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Florian Mickler]

On Thu, 9 Sep 2010 16:18:49 +0200
Martin Steigerwald <Martin@lichtvoll.de> wrote:

> Yes, I am aware that it may not be a Ext4 problem at all. Thus I said Ext4 
> / readahead related (!) backtrace (! not bug) cause that was all I could 
> see on the screen. How else should I have described that backtrace when I 
> can't speculate on what I can not see?

I think, it is no big thing. The trick is probably to say nothing at all
about the cause, when it is not clear. It's a mind thing. As soon as the
association is brought up, everybody thinks along those lines.  :)

If you leave out the "ext4/readahead related", then people will still
know that it might be ext4 readahead related because you posted the
backtrace, but they will not have their mind turned to that. Instead
they will think: oh a backtrace... there were some people shouting
about backtraces in my area, let's see if it is realted. 

But of course, sometimes putting blame somewhere also does help getting
attention. After all "CORRUPTION IN FILESYSTEM XYZ" sticks out more
than "partial trace of a thing i don't know anything at all".

Cheers,
Flo

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 1766 bytes --]

Am Freitag 10 September 2010 schrieb Florian Mickler:
> On Thu, 9 Sep 2010 16:18:49 +0200
> 
> Martin Steigerwald <Martin@lichtvoll.de> wrote:
> > Yes, I am aware that it may not be a Ext4 problem at all. Thus I said
> > Ext4 / readahead related (!) backtrace (! not bug) cause that was
> > all I could see on the screen. How else should I have described that
> > backtrace when I can't speculate on what I can not see?
> 
> I think, it is no big thing. The trick is probably to say nothing at
> all about the cause, when it is not clear. It's a mind thing. As soon
> as the association is brought up, everybody thinks along those lines. 
> :)
> 
> If you leave out the "ext4/readahead related", then people will still
> know that it might be ext4 readahead related because you posted the
> backtrace, but they will not have their mind turned to that. Instead
> they will think: oh a backtrace... there were some people shouting
> about backtraces in my area, let's see if it is realted.

OTOH I thought when I put in some keywords from the backtrace in my query 
it might get the attention of the right people. When I just say unknown 
backtrace, then I am adressing no one.

> But of course, sometimes putting blame somewhere also does help getting
> attention. After all "CORRUPTION IN FILESYSTEM XYZ" sticks out more
> than "partial trace of a thing i don't know anything at all".

I wouldn't do that for sensational purposes.

Maybe next time: "Fails to boot with partially shown backtrace, with some 
ext4 / readahead function calls inside it"? Or even more general some I/O 
/ filesystem related functions?

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Theodore Tso]

On Sep 10, 2010, at 9:49 AM, Martin Steigerwald wrote:

> Maybe next time: "Fails to boot with partially shown backtrace, with some 
> ext4 / readahead function calls inside it"? Or even more general some I/O 
> / filesystem related functions?

Learn how to use a serial console so you can get a full backtrace, thus saving yourself and folks interesting in helping you valuable time?  :-)

-- Ted

Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes

[Martin Steigerwald]

[-- Attachment #1: Type: Text/Plain, Size: 1517 bytes --]

Am Freitag 10 September 2010 schrieb Theodore Tso:
> On Sep 10, 2010, at 9:49 AM, Martin Steigerwald wrote:
> > Maybe next time: "Fails to boot with partially shown backtrace, with
> > some ext4 / readahead function calls inside it"? Or even more
> > general some I/O / filesystem related functions?
> Learn how to use a serial console so you can get a full backtrace, thus
> saving yourself and folks interesting in helping you valuable time? 
> :-)

I know how to use a serial console. Actually I am no freaking idiot at all 
and I do not like being treated as such.

I just did a bisect, and these kernels were unbootable. I didn't think it 
would have been worth the effort to put that much time in it to grab my 
other notebook, remember how to set up the serial stuff and all - when all 
I wanted to do was to complete the bisect.

I already told that I missed reporting that I do not need any information 
relating that issue anymore cause I was able to skip the area with that 
unbootable kernels at all. I am sorry for that, cause then you would have 
known in advance that there is no need to do any further analysis.

Its getting a bit ridicolous now. I am done with it, since its no issue at 
all anymore. My current 2.6.36-rc3 definately boots, so does 2.6.34 and 
2.6.35 and thus the issue is gone and all is well. So can we be done with 
that now?

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]