Norbert Preining <[EMAIL PROTECTED]> wrote:
>
> On Don, 24 Feb 2005, Andrew Morton wrote:
> > What does the stack backtrace from iounmap-debugging.patch say?
>
> iounmap: bad address c00fffd9
> [<c03f8430>] trap_init+0x30/0x190
> [<c03f2697>] start_kernel+0x47/0x1c0
ah hah.
trap_init() does:
void __iomem *p = ioremap(0x0FFFD9, 4);
which returns phys_to_virt(0x0FFFD9) = 0xc00fffd9
then trap_init() does:
iounmap(p);
and iounmap() does
if ((void __force *) addr <= high_memory)
return;
which doesn't work, because 0xc00fffd9 is outside 0 ... high_memory.
A quick fix is to delete that iounmap() call from trap_init(), because we
"know" how ioremap() works. Or, better, simply use phys_to_virt(0x0FFFD9)
in trap_init().
Although a better fix might be to make __iounmap() behave symmetrically:
if ((long)addr >= phys_to_virt(0xA0000) &&
(long)addr < phys_to_virt(0x100000))
return;
but that's not quite right, because we're assuming that the range to be
unmapped is wholly within the PCI/ISA region. Without a VMA there just
isn't enough info to determine that.
Does anyone have any preferences?
-
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/
