On Tue, 2007-07-24 at 21:12 -0400, Doug Chapman wrote: > On Wed, 2007-07-25 at 09:19 +0900, Yasuaki Ishimatsu wrote: > > Hi Doug, > > > > > > Yasuaki, > > > > > > With this patch it still panics in the same way. I am building with > > > CONFIG_IA64_GENERIC and booting on an HP rx6600. I do not have the ski > > > simulator either. > > > > > > > I don't know what happen on your machine. Could you send me your entire > > stack trace? > > > > Thanks, > > Yasuaki Ishimatsu > > Here is the panic with a few lines from before to show some context as > to when it happens (fairly early in boot). I have to admit I have no > clue as to why your patch causes this. I don't see anything that > appears to be related. I will see if I can get a little more data. If > you have suggestions for what might be helpful please let me know. > > > SAL Platform features: None > SAL: AP wakeup using external interrupt vector 0xff > cpu package is Multi-Core capable: number of cores=2 > cpu package is Multi-Threading capable: number of siblings=2 > ACPI: Local APIC address c0000000fee00000 > GSI 25 (level, low) -> CPU 0 (0x0000) vector 48 > 16 CPUs available, 16 CPUs total > MCA related initialization done > kernel unaligned access to 0xffffffffffffffff, ip=0xa000000100815491 > swapper[0]: error during unaligned kernel access > -1 [1] > Modules linked in: > > Pid: 0, CPU 0, comm: swapper > psr : 00001210084a2010 ifs : 800000000000030a ip : [<a000000100815491>] Not tainted > ip is at setup_arch+0x671/0x720 > unat: 0000000000000000 pfs : 000000000000030a rsc : 0000000000000003 > rnat: 89543ffffe403fc4 bsps: 0000000000010017 pr : 656960155aa66599 > ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f > csd : 0000000000000000 ssd : 0000000000000000 > b0 : a000000100815470 b6 : a000000100304a80 b7 : a0000001000132e0 > f6 : 1003e0000000000000000 f7 : 1003e0000000000000000 > f8 : 1003e0000000000000000 f9 : 1003e0000000000000001 > f10 : 10004c7ffffffff380000 f11 : 1003e0000000000000032 > r1 : a000000100d2f000 r2 : a000000100b49248 r3 : a000000100a4f220 > r8 : 0000000000000023 r9 : 0000000000004000 r10 : a000000100b536a8 > r11 : a000000100b3a8a0 r12 : a0000001008b7d60 r13 : a0000001008b0000 > r14 : 0000000000000000 r15 : a000000100a4f220 r16 : ffffffffdead4ead > r17 : 00000000dead4ead r18 : a0000001009e13fc r19 : a000000100b3a870 > r20 : 000000000001ffff r21 : a000000100b47840 r22 : 0000000000000000 > r23 : a000000100b49218 r24 : a000000100b34058 r25 : 000000000001ffff > r26 : 0000000000020000 r27 : a000000100b47828 r28 : a000000100b47820 > r29 : a0000001009e1400 r30 : 0000000000000000 r31 : a0000001009e1408 > > > > Here is the bit of code showing where the ip points to: > > (gdb) list *setup_arch+0x671 > 0xa000000100815491 is in setup_arch (arch/ia64/kernel/setup.c:570). > 565 > 566 /* enable IA-64 Machine Check Abort Handling unless disabled */ > 567 if (!nomca) > 568 ia64_mca_init(); > 569 > 570 platform_setup(cmdline_p); > 571 paging_init(); > 572 } > 573 > 574 /* > > > Yasuaki, I did a little more debugging. For one I re-verified to make sure it was the commit in question that triggered this (just to be sure). It is. Also, I added some printk's to figure out exactly what is going on. It appears that ia64_mv.setup is never getting initialized. Any idea how your patch might cause that? I am no expert at this level (or really any level) of the kernel. Hopefully this will be more obvious to someone. - Doug - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|