Re: stable? quality assurance?

[Martin Steigerwald <Martin@lichtvoll.de>]

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

Am Sonntag 05 September 2010 schrieb Ted Ts'o:
> On Sat, Sep 04, 2010 at 09:11:34PM +0200, Martin Steigerwald wrote:
> > Stop! I think we are misunderstanding.
> > 
> > Its a bug I stumpled across the bisecting process. Neither 2.6.33 or
> > 2.6.34 are affected, but some kernels in between. As such I didn't
> > think its worth reporting the bug.
> > 
> > I made a photo of part of the backtrace tough, so if you want I open
> > a bug report about it nonetheless. But I really think it has been
> > fixed during the 2.6.33 to 2.6.34 development cycle.
> 
> FYI, it's fair game to send a note to LKML with the backtrace, saying,
> I'm getting this wierd stack trace while trying to do a bisect; it
> looks like it's fixed in 2.6.34, does it look familiar?  If so,
> someone might be able to point you at the commit that fixes the bug,
> and then you can apply that patch by hand while doing the bisect at
> each step (and then unapply it before doing the next bisect
> iteration).

Thanks. As to your advice I am seeking help again with bisecting this bug. 
See the thread "help with git bisecting a bug 16376: random - possibly 
Radeon DRM KMS related - freezes". I put you on Cc for the Ext4 / 
readahead related backtrace.
 
> > For now I just skipped affected kernels in the bisection process in
> > the hope that none is the first last good or first bad one regarding
> > the freeze bug. Since for now it has all been kernels of a usb merge
> > that showed this issue, I don't think the freeze bug is in there.
> 
> Are you actually booting off of a USB device?  Even if you are, it
> seems... strange... that a series of USB patches would cause an
> ext4/readahead kernel OOPS.  Can you disable using USB devices, which
> would hopefully prevent the problem from showing up?

Nope. I think the bug is completely unrelated to the commits from the USB 
merge. I think that the USB commits just had the bad luck having been 
merged between the other bug was introduced and fixed.

> Note by the way, that you don't have to try compiling at the points
> chosen by "git bisect".  If you run into problems, you can try going
> to the head of the USB patches, and if that works, report that
> particular commit as "good" or "bad".

Yes, thats what the git reset --hard example should do. But I wondered on 
how to do it exactly. I saw "git reset --hard HEAD~3" in the manpage to go 
three commits back and only later found out that I could give a commit id 
to "git reset". Is just going to the head of that USB merge and testing 
that better than skipping the complete range? Anyway I really think that 
none of the commits in there caused or fixed that bug.

> > So I just wanted to show that I am seriously working on tracking down
> > that likely radeon kms related freeze bug and that its
> > time-consuming for me due to having lots of unbootable kernels.
> 
> Have you reported this bug to the maintainer?  Is he helping you out?
> Have you looked at the various Radeon-related commits between 2.6.34
> and 2.6.33?  I imagine there probably aren't that many of them.  You
> might try testing commits just before and after the Radeon-related
> commits, which might speed up the git bisect significantly.

Yes, of course. I also posted my previous git bisect results already. I 
wanted to add a comment with the current results yesterday, but bugzilla 
had to many MySQL connection for an extended period of time. Now I did 
with more specifically asking for help[1]

[1] 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 --]