* Ingo Molnar <mingo@elte.hu> wrote:

quoted text
> * Andreas Herrmann3 <andreas.herrmann3@amd.com> wrote:
> 
> > Yes.
> > 
> > Meanwhile I have figured out that it is some ACPI stuff that maps the 
> > page cached. I've changed the ioremap's in drivers/acpi/osl.c to 
> > ioremap_nocache. See attached patch.
> > 
> > Now the machine boots without conflicts.
> 
> ah, nice!
> 
> but in general we must be robust enough in this case and just degrade 
> any overlapping page to UC (and emit a warning perhaps) - instead of 
> failing the ioremap and thus failing the driver (and the bootup).

btw., there's a change i did in today's x86.git: _all_ the old BIOS data 
accesses now go through early_ioremap(). This cleaned up the boot code 
quite significantly, as it's much more apparent now when we access a 
BIOS data table. (it also solves the problem when BIOS data pages are in 
reserved areas that we map via UC or dont map at all)

the same happens with all ISA ioremaps as well - no more "low 1MB is 
treated special" exceptions.

[ This also solves the 'EFI puts data pages into really high memory we
  dont have mapped yet' category of problems that BIOS writers are
  apparently busy creating right now ;-) ]

the downside is that old linear-mapped assumptions might now result in 
an early fault - boot with earlyprintk=vga or 
earlyprintk=serial,ttyS0,115200. I fixed most such assumptions already 
and booted an allyesconfig kernel on both 32-bit and 64-bit x86, but a 
few more remain still. I've enhanced the early fault printout code as 
well to make it easier to debug such things, so it should be relatively 
easy to find the rest.

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/