Re: [Xen-devel] dom0 pvops boot crash on very ordinary Dell R310

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2010-10-26 at 16:57 +0100, Ian Jackson wrote:
> 
> mariner:~> ksymoops -d -K -m t -L -V <u | grep -v 'Before first
> symbol'
> DEBUG (parse): 'K' '(null)'
> DEBUG (parse): 'm' 't'
> DEBUG (parse): 'L' '(null)'
> DEBUG (parse): 'V' '(null)'
> DEBUG (convert_uname): /lib/modules/*r/ in
> DEBUG (convert_uname): /lib/modules/2.6.26-2-amd64/ out
> ksymoops 2.4.11 on x86_64 2.6.26-2-amd64.  Options used
>      -V (specified)
>      -K (specified)
>      -L (specified)
>      -o /lib/modules/2.6.26-2-amd64/ (default)
>      -m t (specified)

Looks like this picked up a host 2.6.26-2-amd64 uname? The call trace
still looks plausible so probably this is just bad logging from ksymoops
and it did pickup the correct System.map.

> >>EIP; c17d500b <smp_scan_config+35/ff>   <=====
> [snip]
> Trace; c17d50fe <default_find_smp_config+29/5d>

This seems (based on the faulting address) to be the "639 * 0x400" case
from:
       /*
         * FIXME: Linux assumes you have 640K of base ram..
         * this continues the error...
         *
         * 1) Scan the bottom 1K for a signature
         * 2) Scan the top 1K of base RAM
         * 3) Scan the 64K of bios
         */
        if (smp_scan_config(0x0, 0x400, reserve) ||
            smp_scan_config(639 * 0x400, 0x400, reserve) ||
            smp_scan_config(0xF0000, 0x10000, reserve))
                return;

Where smp_scan_config does:
        static int __init smp_scan_config(unsigned long base, unsigned long 
length,
                                          unsigned reserve)
        {
                unsigned int *bp = phys_to_virt(base);
        
which doesn't seem likely to be valid under Xen on any hardware.

This code is dependent on CONFIG_X86_MPPARSE so I guess if you disable
it things will work, although of course that shouldn't be necessary.

This code path already indirects through
"x86_init.mpparse.find_smp_config" but I can't see where Xen overrides
that hook, if indeed that would be the correct thing to do. I suspect it
is right and that this hook should be a NOP under PV Xen.

Ian.

> Trace; c1745fb0 <init_thread_union+1fb0/2000>
> Trace; c17cdd06 <setup_arch+84b/a4d>
> Trace; c1063e9a <release_console_sem+1b0/1dd>
> Trace; c1745fc0 <init_thread_union+1fc0/2000>
> Trace; 0218a600 <phys_startup_32+118a600/c0000000>
> Trace; 01a68000 <phys_startup_32+a68000/c0000000>
> Trace; 01a68000 <phys_startup_32+a68000/c0000000>
> Trace; c106439f <vprintk+30f/332>
> Trace; c1745f71 <init_thread_union+1f71/2000>
> Trace; c1745f78 <init_thread_union+1f78/2000>
> Trace; 205b0000 <phys_startup_32+1f5b0000/c0000000>
> Trace; 30202020 <phys_startup_32+2f202020/c0000000>
> Trace; 3030302e <phys_startup_32+2f30302e/c0000000>
> Trace; 5d303030 <phys_startup_32+5c303030/c0000000>
> Trace; c1800020 <md_setup_args+f30/1400>
> Trace; c174f350 <reboot_cpu+0/4>
> Trace; c1745f8c <init_thread_union+1f8c/2000>
> Trace; c102d295 <__raw_callee_save_xen_restore_fl+9/c>
> Trace; c1745fa0 <init_thread_union+1fa0/2000>
> Trace; c14e5178 <_spin_unlock_irqrestore+43/48>
> Trace; c1800670 <map.24465+0/a00>
> Trace; c174f350 <reboot_cpu+0/4>
> Trace; c1745fb0 <init_thread_union+1fb0/2000>
> Trace; c1800670 <map.24465+0/a00>
> Trace; c174f350 <reboot_cpu+0/4>
> Trace; c1745fc8 <init_thread_union+1fc8/2000>
> Trace; c17c75d9 <start_kernel+86/31a>
> Trace; c1659dee <kallsyms_token_index+4d6/c9a6>
> Trace; c14eb010 <linux_banner+0/8c>
> Trace; c18019d0 <command_line+0/800>
> Trace; c1745fd4 <init_thread_union+1fd4/2000>
> Trace; c17c70a2 <i386_start_kernel+91/96>
> Trace; c220b490 <END_OF_CODE+7a3490/????>
> Trace; c1745ffc <init_thread_union+1ffc/2000>
> Trace; c17cae57 <xen_start_kernel+535/53d>
> Trace; 1fc9dbf5 <phys_startup_32+1ec9dbf5/c0000000>
> Trace; 80980281 <phys_startup_32+7f980281/c0000000>
> Trace; c220b000 <END_OF_CODE+7a3000/????>
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel