Re: panic from vector domain patch (was RE: Linus' tree broken?)

[Doug Chapman <doug.chapman@hp.com>]

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