Re: mtrr failure, 3.1-rc1

[Linus Torvalds]

Hmm. Some of those commits are marked for stable too.

I'm adding appropriate parties to the discussion (authors and
sign-offs from the five commits that that merge brings in), but it
would also be great if you could bisect exactly which commit broke for
you. You can make it quick by just doing

  git bisect start
  git bisect bad dc43d9fa73d82083656fb9c02f4823bcdcfb9f91
  git bisect good dc43d9fa73d82083656fb9c02f4823bcdcfb9f91^

and it should take just a couple of tests. I *assume* it's the
stop_machine changes by Tejun &co, but who knows..

Anders, is this a single-CPU system?

                            Linus

On Thu, Aug 25, 2011 at 12:03 AM, Anders Eriksson <aeriksson@xxxxxxxxxxx> wrote:
>
> My old P-II has 640MB ram, but the bios only sets up WC for the first 512, so i
> add this early in the boot process:
> echo "base=0x20000000 size=0x8000000 type=write-back" > /proc/mtrr
>
> For reasons I have forgot I also have to add 'disable_mtrr_check' to the
> command line. Works great.
>
> As of merge dc43d9fa73d82083656fb9c02f4823bcdcfb9f91 This no longer works.
> Adding that line to /proc/mtrr no longer has any effect (cat /proc/mtrr shows
> only the reg00 entry).
>
> Reverting that merge on top of rc3 brings things back to normal and /proc/mtrr
> shows:
> reg00: base=0x000000000 (    0MB), size=  512MB, count=1: write-back
> reg01: base=0x048000000 ( 1152MB), size=  128MB, count=1: write-combining
> reg02: base=0x020000000 (  512MB), size=  128MB, count=2: write-back
>
> Any ideas how to track this down futher? Would be good to get it fixed for 3.1
>
> -Anders
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/