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 <>
To:	Russell King <>
Cc:	"Rafael J. Wysocki" <>,,, kernel list <>,,,,
	Cyril Hrubis <>,
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...?
(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists