linux-kernel - Re: stable? quality assurance?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 4 Sep 2010 19:23:52 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Martin Steigerwald <Martin@...htvoll.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: stable? quality assurance?

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).

> 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?

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".

> 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.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/