Re: [tip:x86/urgent] x86, setup: When probing memory with e801, use ax/bx as a pair

From: Chris Samuel <chris@csamuel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: mingo@redhat.com, hpa@zytor.com, thomas@m3y3r.de,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	hpa@linux.intel.com, linux-tip-commits@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [tip:x86/urgent] x86, setup: When probing memory with e801, use ax/bx as a pair
Date: Fri, 6 May 2011 22:10:32 +1000	[thread overview]
Message-ID: <201105062210.35963.chris@csamuel.org> (raw)
In-Reply-To: <20110506120452.GB17112@elte.hu>

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

On Fri, 6 May 2011 10:04:52 PM Ingo Molnar wrote:

> * Chris Samuel <chris@csamuel.org> wrote:
>
> > Understood, I would guess that the SCSI one would map to the
> > introduction of the async scsi scanning patch in 2.6.19-rc2
> > and its enablement in later Ubuntu kernels.
> 
> Yeah. Async SCSI scanning was not supposed to break any existing
> setup.

Well that'd be about my luck at the moment. ;-)

> > No idea on the APIC one but I'm happy to try and bisect both
> > cases if you'd like me to try ?
> 
> I could definitely do something about the APIC regression if
> managed to narrow down the commit range (a specific guilty commit
> would be fantastic of course). If the regression got introduced
> after the e801 regression you'll need to run:
> 
>   git cherry-pick 39b68976ac65
> 
> at every bisection step that needs that fix - but still bisect as
> if that extra commit was not there. (bisection will throw away
> that cherry-picking temporary tree so you will have to re-pick the
> commit again and again)

That's great, will try and see what I can do.  It might take a little
bit of time due to work commitments prior to a (planned) trip to
hospital next Thursday.

> Note that during bisection the current tree might jump in and out
> of regions that need this fix, so be prepared to have to do the
> cherry-picking at random places. You can attempt the cherry-pick
> at every step and you will get a conflict and it will not succeed
> if the fix is not needed. You can throw away the conflicting state
> via 'git reset --hard'.

Understood, thanks!

> > Indeed - though at the moment you can't even install a current
> > Debian release as the boot loader on the install CD locks the
> > box up. :-(
> 
> Is that hang due to one of these 3 regressions - or is it a fourth
> regression perhaps?

This is before it boots the kernel, so I'd guess something in
whatever they are using for the Squeeze install CD - perhaps
grub2 now ?

> While the installed base of your hardware is small, i think such
> old-hardware testing is still very valuable feedback to us: it
> gives us a feel for how corrosive our development process is to
> long-term (10+ years) stability.

Great, as long as this is more useful than just fixing my problems!

cheers,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 482 bytes --]