[lkml]   [2011]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [tip:x86/urgent] x86, setup: When probing memory with e801, use ax/bx as a pair

* Chris Samuel <> wrote:

> On Thu, 5 May 2011 10:10:59 PM Ingo Molnar wrote:
> > Thanks for the update!
> My pleasure.
> > Note that the noapic and the scsi-sync-scan boot parameter suggests
> > that there's two regressions remaining.
> 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.

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

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

> > The stock kernel wont boot - you can work it around via boot
> > options but most users wont be able to do that.
> 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

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.



 \ /
  Last update: 2011-05-06 14:07    [W:0.039 / U:0.184 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site