Mailing List Archive

On 1/5/07 18:49, "Krysan, Susan" <KRYSANS@unisys.com> wrote:

> I cannot boot 32-bit SLES10 HVMs, SMP nor PAE, on x86_64 SLES10 xen on Unisys
> ES7000/one with Intel processors. I initially tried with HVM memory sizes of
> 2gb and 16gb, but when I give the HVMs only 512mb, they still do not boot. I
> have run both with the ES7000 configured as 8x 32gb and 16x 64gb. The HVMs
> either hang in the graphical blue SUSE Linux screen or get this kernel panic:
> Badness in smp_call_function at arch/i386/kernel/smp.c:595.
>
> At Keir¹s suggestion, I used a binary search method to narrow down changesets,
> and after building and testing multiple changesets I was able to determine
> that c/s 14436 introduces the problem.

This is the changeset that reduced the virtual HPET frequency to 1/32 that
of the virtual TSC. This was itself a bug fix (guests tend to assume that
HPET frequency is somewhat less than TSC frequency). I can¹t immediately see
how this changeset would cause issues like Œbadness in smp_call_function¹.
Any ideas, Dexuan?

-- Keir

On 1/5/07 18:49, "Krysan, Susan" <KRYSANS@unisys.com> wrote:

> I cannot boot 32-bit SLES10 HVMs, SMP nor PAE, on x86_64 SLES10 xen on Unisys
> ES7000/one with Intel processors. I initially tried with HVM memory sizes of
> 2gb and 16gb, but when I give the HVMs only 512mb, they still do not boot. I
> have run both with the ES7000 configured as 8x 32gb and 16x 64gb. The HVMs
> either hang in the graphical blue SUSE Linux screen or get this kernel panic:
> Badness in smp_call_function at arch/i386/kernel/smp.c:595.
>
> At Keir¹s suggestion, I used a binary search method to narrow down changesets,
> and after building and testing multiple changesets I was able to determine

When you get the ŒBadness in smp_call_function¹ message, do you also get a
backtrace and/or stack dump?

-- Keir

Yes, I saved this output from the 32-bit SMP (non-PAE) HVM when I ran
with changeset 14756:



<0>Kernel panic - not syncing: Fatal exception in interrupt

Badness in smp_call_function at arch/i386/kernel/smp.c:595

[<c010dc2a>] smp_call_function+0x56/0x104

[<c011a7cf>] printk+0x14/0x18

[<c010dceb>] smp_send_stop+0x13/0x1c

[<c0119ed8>] panic+0x4c/0xe4

[<c010421a>] die+0x1dd/0x1e7

[<c0104836>] do_invalid_op+0x0/0x9d

[<c01048c7>] do_invalid_op+0x91/0x9d

[<f886173d>] ide_timer_expiry+0x90/0x257 [ide_core]

[<c02001e4>] vt_console_print+0x0/0x212

[<c0119fde>] __call_console_drivers+0x34/0x40

[<c011a263>] release_console_sem+0x15a/0x194

[<c011a797>] vprintk+0x23f/0x263

[<f8861351>] ide_intr+0x17f/0x18a [ide_core]

[<c0135a92>] handle_IRQ_event+0x23/0x4c

[<f8867694>] ide_dma_intr+0x0/0x8f [ide_core]

[<c0103a2f>] error_code+0x4f/0x60

[<f8867694>] ide_dma_intr+0x0/0x8f [ide_core]

[<f886007b>] ide_uevent+0xab/0xfe [ide_core]

[<f886173d>] ide_timer_expiry+0x90/0x257 [ide_core]

[<c012007b>] do_sysctl+0x1b1/0x21f

[<c0121f90>] run_timer_softirq+0x128/0x18c

[<f88616ad>] ide_timer_expiry+0x0/0x257 [ide_core]

[<c011e544>] __do_softirq+0x58/0xc2

[<c011e5dc>] do_softirq+0x2e/0x32

[<c0104cb7>] do_IRQ+0x4b/0x53

[<c010387a>] common_interrupt+0x1a/0x20

[<c0141fe7>] __handle_mm_fault+0x3f8/0x7e8

[<c028524e>] do_page_fault+0x16e/0x525

[<c02850e0>] do_page_fault+0x0/0x525

[<c0103a2f>] error_code+0x4f/0x60



Thanks,

Sue Krysan

Linux Systems Group

Unisys Corporation



________________________________

From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
Sent: Tuesday, May 01, 2007 4:59 PM
To: Krysan, Susan; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] can't boot 32-bit SLES10 HVMs since c/s 14436
wasintroduced



On 1/5/07 18:49, "Krysan, Susan" <KRYSANS@unisys.com> wrote:

I cannot boot 32-bit SLES10 HVMs, SMP nor PAE, on x86_64 SLES10 xen on
Unisys ES7000/one with Intel processors. I initially tried with HVM
memory sizes of 2gb and 16gb, but when I give the HVMs only 512mb, they
still do not boot. I have run both with the ES7000 configured as 8x
32gb and 16x 64gb. The HVMs either hang in the graphical blue SUSE
Linux screen or get this kernel panic: Badness in smp_call_function at
arch/i386/kernel/smp.c:595.

At Keir's suggestion, I used a binary search method to narrow down
changesets, and after building and testing multiple changesets I was
able to determine


When you get the 'Badness in smp_call_function' message, do you also get
a backtrace and/or stack dump?

-- Keir