Messages in this thread | | | From | Martin Steigerwald <> | Subject | Re: stable? quality assurance? | Date | Sun, 5 Sep 2010 09:59:33 +0200 |
| |
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 [unhandled content-type:application/pgp-signature] | |