[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080227203655.GA30054@elte.hu>
Date: Wed, 27 Feb 2008 21:36:55 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Roland Dreier <rdreier@...co.com>, linux-kernel@...r.kernel.org,
Thomas Mingarelli <thomas.mingarelli@...com>
Subject: Re: hpwdt oops in clflush_cache_range
* Thomas Gleixner <tglx@...utronix.de> wrote:
> > [ 0.004000] Intel(R) Xeon(R) CPU 5160 @ 3.00GHz stepping 06
>
> This one has 36bit physical address space. You can verify that via
> /proc/cpuinfo
>
> > [ 8425.910898] ACPI: PCI Interrupt 0000:01:04.0[A] -> GSI 21 (level, low) -> IRQ 21
> > [ 8425.915097] hpwdt: New timer passed in is 30 seconds.
> > [ 8425.915139] BUG: unable to handle kernel paging request at ffffc20001a0a000
> > [ 8425.919087] IP: [<ffffffff8021dacc>] clflush_cache_range+0xc/0x25
> > [ 8425.919087] PGD 1bf80e067 PUD 1bf80f067 PMD 1bb497067 PTE 80000047000ee17b
>
> While the physical address of your ioremap is 47000ee000.
>
> 2^ 36 == 1000000000
> ----> 47000ee000
>
> So the fault is not very surprising. Unfortunately we do not check,
> whether physaddr is inside the valid physical address space. I whip up
> a patch to do that.
also note that the driver would have faulted in a similar same way
anyway, the first time it tried to access that ioremap range. It's just
that due to the clflush we took the fault first in ioremap().
via the physical range check we'll do a more graceful exit and the
driver wont crash either. (it will just not work)
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