Re: Re: Panic on boot on Sun Blade 6270

[Dan Gora <dan.gora@gmail.com>]

On Thu, Mar 11, 2010 at 10:35 PM, Jiang, Yunhong
<yunhong.jiang@intel.com> wrote:
> Why it will fail on 0xffff828bfffff0e0 ? I try to build 19913 and seems it should be 0xffff828bffffe0e0.
> If you can paste your objdump output for init_apic_ldr_phys, maybe it will be helpful.

Here is init_apic_ldr_phys from 'objdump -d xen-syms-3.4.3-rc4-pre':

ffff828c80183d48 <init_apic_ldr_flat>:
ffff828c80183d48:       55                      push   %rbp
ffff828c80183d49:       48 89 e5                mov    %rsp,%rbp
ffff828c80183d4c:       83 3d cd 73 09 00 00    cmpl
$0x0,0x973cd(%rip)        # ffff828c8021b120 <x2apic_enabled>
ffff828c80183d53:       74 4d                   je
ffff828c80183da2 <init_apic_ldr_flat+0x5a>
ffff828c80183d55:       ba 00 00 00 00          mov    $0x0,%edx
ffff828c80183d5a:       b8 ff ff ff ff          mov    $0xffffffff,%eax
ffff828c80183d5f:       b9 0e 08 00 00          mov    $0x80e,%ecx
ffff828c80183d64:       0f 30                   wrmsr
ffff828c80183d66:       b1 0d                   mov    $0xd,%cl
ffff828c80183d68:       0f 32                   rdmsr
ffff828c80183d6a:       48 89 c2                mov    %rax,%rdx
ffff828c80183d6d:       81 e2 ff ff ff 00       and    $0xffffff,%edx
ffff828c80183d73:       48 c7 c0 00 80 ff ff    mov    $0xffffffffffff8000,%rax
ffff828c80183d7a:       48 21 e0                and    %rsp,%rax
ffff828c80183d7d:       48 0d 28 7f 00 00       or     $0x7f28,%rax
ffff828c80183d83:       8b 88 c8 00 00 00       mov    0xc8(%rax),%ecx
ffff828c80183d89:       b8 00 00 00 01          mov    $0x1000000,%eax
ffff828c80183d8e:       48 d3 e0                shl    %cl,%rax
ffff828c80183d91:       48 09 d0                or     %rdx,%rax
ffff828c80183d94:       ba 00 00 00 00          mov    $0x0,%edx
ffff828c80183d99:       b9 0d 08 00 00          mov    $0x80d,%ecx
ffff828c80183d9e:       0f 30                   wrmsr
ffff828c80183da0:       eb 43                   jmp
ffff828c80183de5 <init_apic_ldr_flat+0x9d>
ffff828c80183da2:       b8 ff ff ff ff          mov    $0xffffffff,%eax
ffff828c80183da7:       a3 e0 f0 ff ff 8b 82    mov    %eax,0xffff828bfffff0e0
ffff828c80183dae:       ff ff
ffff828c80183db0:       48 be d0 f0 ff ff 8b    mov    $0xffff828bfffff0d0,%rsi
ffff828c80183db7:       82 ff ff
ffff828c80183dba:       8b 16                   mov    (%rsi),%edx
ffff828c80183dbc:       81 e2 ff ff ff 00       and    $0xffffff,%edx
ffff828c80183dc2:       48 c7 c0 00 80 ff ff    mov    $0xffffffffffff8000,%rax
ffff828c80183dc9:       48 21 e0                and    %rsp,%rax
ffff828c80183dcc:       48 0d 28 7f 00 00       or     $0x7f28,%rax
ffff828c80183dd2:       8b 88 c8 00 00 00       mov    0xc8(%rax),%ecx
ffff828c80183dd8:       b8 00 00 00 01          mov    $0x1000000,%eax
ffff828c80183ddd:       48 d3 e0                shl    %cl,%rax
ffff828c80183de0:       48 09 d0                or     %rdx,%rax
ffff828c80183de3:       89 06                   mov    %eax,(%rsi)
ffff828c80183de5:       c9                      leaveq
ffff828c80183de6:       c3                      retq

I don't quite understand why we have such different addresses.  I'm
thinking maybe I built it wrong or something.  I built it with debug
set to 'y' in Config.mk, then just did 'make dist', copied the
resultant 'dist' directory to the test machine and ran 'sh
./install.sh' on the target machine, and rebooted with:

title Xen-3.4.3-rc1.dan -- SUSE Linux Enterprise Server 11 -
2.6.27.19-5 (xen).dan
    root (hd0,0)
    kernel /xen-3.4.3-rc4-pre.gz crashkernel=128M@16M iommu=1
loglvl=all guest_loglvl=all console=vga,com1 com1=auto
    module /vmlinuz-2.6.27.19-5-xen.dan root=/dev/dm-5
resume=/dev/dm-2 splash=silent showopts console=ttyS0,115200 quiet
    module /initrd-2.6.27.19-5-xen.dan


> BTW, if SLES 11 works for you, why not continue that?

ugh.. long story.  It works in the sense that it boots and can run
VMs.  My problem is that I'm trying to get the board that our company
makes to work in an HVM guest properly..  *something* is messing with
my board's PCI bar registers and I cannot figure out what it is.  I
added printks to all the kernel functions which touch the BAR
registers and to the pciback driver as well, but neither of these is
occurring, so I figured the problem is in qemu, but to test that I
need to be able to compile it.  I thought that the easiest path there
would simply to compile the latest stuff, but it panicked early in the
hypervisor so I thought that I'd report it...

thanks,
dan