linux-kernel - Re: 2.6.28-rc2-git1: spitz still won't boot

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:	Mon, 3 Nov 2008 12:12:36 +0100
From:	Pavel Machek <pavel@...e.cz>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, rpurdie@...ys.net,
	lenz@...wisc.edu, kernel list <linux-kernel@...r.kernel.org>,
	Dirk@...er-online.de, arminlitzel@....de, pavel.urban@...cz,
	Cyril Hrubis <metan@....cz>, thommycheck@...il.com
Subject: Re: 2.6.28-rc2-git1: spitz still won't boot

> On Mon, Nov 03, 2008 at 11:40:35AM +0100, Pavel Machek wrote:
> > > On Friday, 31 of October 2008, Pavel Machek wrote:
> > > > Hi!
> > > > 
> > > > ...unfortunately, 2.6.27 contains the 'reset floating' bug, and from
> > > > the point 'reset floating' is fixed, to 2.6.28-rc1, tree will not
> > > > compile, so bisect is quite hard to do. Any ideas?
> > > 
> > > Is this a regression from .27?
> > 
> > Yes, it is (*).

> > (*) Okay, so 2.6.27 does not boot due to the 'reset floating' bug.
> 
> I wouldn't say that was a bug.  That was by design of Dmitry, which
> I'm far from happy with.  If an output is being used to drive a
> reset line, you always want to actively drive it to the inactive
> state for noise immunity reasons.

Well, if it breaks boot on the machine, I think it is fair to call it
a "bug" :-).

> > 'reset floating' is fixed in 2.6.28-rc1, and compilation of spitz
> > is fixed in 2.6.28-rc2, but it still will not boot.
> 
> Compilation errors are only going to get worse as ARM continues to
> diversify.  We're entirely reliant on sfr's linux-next project to
> find build errors prior to merging, and it is unfortunate that this
> time around, sfr was on vacation on the run up to the merge window.
> Hence, there was very little build coverage of the changes that
> went in during this last merge window.  I spent most of the merge
> window fixing up all the shitty patches that people had submitted up
> until that point that either broke compilation or had runtime
> problems.

:-(.

> > So yes, some new spitz-breaking bug got introduced. But no, 2.6.27
> > will not boot due to other bug. 2.6.26 boots.
> 
> If 2.6.27 doesn't boot even with the reset fixes applied, there's a hell

No, 2.6.27 _does_ boot with reset fixes applied. (But it needs those
reset fixes to boot -- that was what I was trying to say).

> of a lot of changes that could be the culpret (and I don't remember much
> that happened before this last merge window.)  The only thing I can
> suggest is to bisect with the reset fixes on top.

With the reset & compilation fixes on top... and I'll have to search
for the small patch that fixes the compilation :-((.

If you have any idea what should I try to revert between 2.6.27 and
2.6.28-rc2, that would be helpful... bisect is not completely trivial here.

> This is precisely where we're let down by not having a Zaurus maintainer
> who knows the Zaurus issues inside out, and regularly puts effort into
> building and testing kernels for these platforms.  That's a hint for
> anyone who's reading this.

I don't think I have enough time to really maintain Zauruses... but I
can try to help with some testing. So -next is the place that should
get more testing...?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/