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 a subsys_initcall. 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). Thank you, Manuel Lauss
