On Mon, Nov 12, 2007 at 10:44:23AM +0000, Ralf Baechle wrote: > But even if you get that wrong the expected failure mode is different ... Ralf and me had an debug session on IRC and I finally figured out what caused the problem: CONFIG_EARLY_PRINTK via prom calls. I simply used call_o32.S from the decstation part and missed the fact, that it simply uses the normal kernel stack when calling firmware. This works quite good until the first kernel thread gets scheduled, which has a kernel stack via a CAC_BASE address. So after switching stack the next call to prom_putchar() killed the machine. Simply disabling EARLY_PRINTK gives me a working 64bit kernel, which sees the whole 512MB RAM :-) Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ]
