* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Andreas Herrmann3 <[EMAIL PROTECTED]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
