This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] dom0 pvops boot crash on very ordinary Dell R310
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Wed, 27 Oct 2010 10:15:30 +0100
Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 27 Oct 2010 02:16:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19654.64100.877881.133331@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <19654.64100.877881.133331@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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
         * 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))

Where smp_scan_config does:
        static int __init smp_scan_config(unsigned long base, unsigned long 
                                          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.


> 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