[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080427231809.GA13848@elte.hu>
Date: Mon, 28 Apr 2008 01:18:09 +0200
From: Ingo Molnar <mingo@...e.hu>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
linux-kernel <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [patch] x86, voyager: fix ioremap_nocache()
* James Bottomley <James.Bottomley@...senPartnership.com> wrote:
> > with the PAT changes, what used to be this default and careless
> > ioremap() behavior by x86 turned into a hard cache aliasing
> > conflict. So we pretty much _have to_ default to uncached - like all
> > other sane architectures already did forever. This is a direct
> > consequence of the PAT changes which were discussed on lkml.
> >
> > But with PAT we take over from the MTRRs on x86 and using a
> > cacheable ioremap() would give us aliasing conflicts and trouble all
> > around the place.
>
> I'm not saying the patch is wrong ... or that just because it broke
> voyager it shouldn't be done. [...]
ok, but that rather crutial piece of information was not at all clear
from your mail ... ;-)
> [...] What I'm saying is that it shouldn't have been put into the x86
> tree without mailing list review.
... but the PAT patchset was all around lkml. The ioremap change was
trivial, went into v2.6.25 and was discussed on lkml:
http://lkml.org/lkml/2008/1/25/287
" that's why we changed all ioremaps to default to cache-disabled (PCD)
in latest x86.git as well. For years the x86 architecture set the
ioremap pagetable entries to cacheable by default and only the MTRRs
(and the BIOS writers) saved us from trouble. Now we try to be a bit
more defensive and avoid "BIOS bug causes only Linux to crash and burn
while other OSs work fine" type of scenarios. "
i could have included the actual patch in that mail i guess - but this
was hardly an unreviewed change and you never showed interest in the PAT
threads on lkml (or much interest in x86 threads for that matter) so
would it have made any difference in practice?
The commit was mentioned in the pull request to Linus as well, which was
Cc:-ed to lkml. The commit was upstream about 3 months before you
noticed that it broke Voyager.
But, we'd not mind at all posting 1000 x86.git patches to lkml (or
another list) every 3 months (or more frequently), if people request
that.
Ingo
--
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/
Powered by blists - more mailing lists