Hi Ralf, Kevin,
On Wed, Apr 29, 2009 at 04:35:23PM +0200, Ralf Baechle wrote:
> On Wed, Apr 29, 2009 at 04:14:11PM +0200, Manuel Lauss wrote:
> > FWIW, I think I fixed it: I have a small area (< 4kB) with a lot of UARTs
> > and 3 interrupt controllers in it. An ioremap() was done for each uart and
> > irq ctl area. Now there's one ioremap of the whole area and the oops is
> > gone. I don't know why, but it seems fixed. (The oops appeared after one
> > of the remapped areas was touched).
> That should be benign - especially if the mappings are for physical
> addresses < 512MB which would become mapped as KSEG1 addresses. The
> dangerous cases are where multiple mappings alias (can't happen on
> Alchemy caches) or where different machines use different cache modes
> which also shouldn't hit you because I/O addresses should be mapped
> uncachable. So you may want to try out what Kevin suggested to get to
> the root of this.
This CS is outside the KSEG0/1 areas. The code in question did an ioremap
on 3 adjacent 8-byte areas (at offset 0x8, 0x10 and 0x14 from the CS base)
for the irq controllers and then registered new irqs in a device_initcall.
I replaced this with an ioremap of a 16mb area and moved irq registration to
As I said, the oops appeared with 2.6.30 when I added support for the
TSC2007; for this I introduced yet another ioremap() for offset 0x10 (in
code unrelated to the irq stuff) for the pen-down callback.
I'm going to try Kevin's suggestion if it turns out that this whole ordeal
is not completely my own fault (which I assume it is).