Re: BUG at domain.c:144

["Christopher S. Aker" <caker@theshore.net>]

From: "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk>
> Thanks Chris, this is very useful.
>
> It would be helpful if you could use a debug=y build of Xen and add a
> show_guest_stack() just before the BUG(). Further, it might be revealing
> to hack the following into linux-2.6.11-xen0/kernel/printk.c:vprintk to
> see how far the dom0 boot it is getting.
>
>         /* Emit the output into the temporary buffer */
>         printed_len = vscnprintf(printk_buf, sizeof(printk_buf), fmt,
> args);
> + HYPERVISOR_console_io( CONSOLEIO_write, strlen(printk_buf),
> printk_buf))

Did all three.

Full results are here:
http://www.theshore.net/~caker/xen/BUGdomain-dmesg2.txt

Here's the relevant part:

(XEN) Scrubbing Free RAM: ........................................done.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen).
Linux version 2.6.11-xen0 (root@host27.linode.com) (gcc version 3.4.3 20041212 (Red
Hat 3.4.3-9.EL4)) #1 Fri Apr 8 05:49:40 EDT 2005
<6>BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 0000000008000000 (usable)
<5>128MB LOWMEM available.
<7>On node 0 totalpages: 32768
<7>  DMA zone: 32768 pages, LIFO batch:8
<7>  Normal zone: 0 pages, LIFO batch:1
<7>  HighMem zone: 0 pages, LIFO batch:1
<6>DMI present.
(XEN) (file=/root/bk/testing/xen/include/asm/mm.h, line=157) Error pfn 000f7ef9:
ed=fc5a8d20, sd=00000000, caf=00000000, taf=00000000
(XEN) DOM0: (file=memory.c, line=1756) ptwr: Could not re-validate l1 page
(XEN)
(XEN) Guest EIP is c0114cd1
(XEN) 00000001 00000001 f7efa000 c0495e12 fbeeb000 000f7ef9 00000063 fbff2190
(XEN)        f7ef9000 c03b0478 00000000 c049492a f7ef9000 00000478 fbff2190 f7ef9000
(XEN)        c03b0478 c0489f48 c0494b1e f7ef9000 00000478 00000024 c0494bcf fbffb000
(XEN)        00241000 494d445f 0478525f f7ef9000 00000024 00008000 00018000 00000020
(XEN)        00000000 c0494cd8 c0494bcf c0491f90 c04db6a0 c03baa05 00000000 00000000
(XEN)        c0488000 00000000 c0119eee 00000000 00000088 ffffff78 c04de9a5 00000000
(XEN)        c04de9a6 00000085 c0119da8 0000000a 00000400 c03af9e0 c0489fe8 00000000
(XEN)        0002080b c0973200 c04db180 0002080b c0973200 c04db180 00000000 c048a58a
(XEN)        c0489ff8 00000000 00000000 00000000 00000000 c04db6a0 c0100066
(XEN) BUG at domain.c:145
(XEN) CPU:    0
(XEN) EIP:    0808:[<fc505853>]
(XEN) EFLAGS: 00210292
(XEN) eax: 00000000   ebx: fc5a8d20   ecx: 00000000   edx: 00000000
(XEN) esi: 00000000   edi: 00000000   ebp: 00000000   esp: fc503ee4
(XEN) ds: 0810   es: 0810   fs: 0810   gs: 0810   ss: 0810
(XEN) Stack trace from ESP=fc503ee4:
(XEN) fc5329d8 fc532a69 00000091 00000000 00000bac fc5a8d20 00000000 [fc5221d2]
(XEN)        ffbda000 00000000 000006dc 00000008 00200096 000d2535 00000000 000d2535
(XEN)        00000000 15d5ae1e 00000454 c001dbac fc5a8d94 00000000 00000000 fc5a8d20
(XEN)        00000000 ffbda000 00000000 c001dbad fef00074 00000000 f7ef9063 0181d061
(XEN)        feffbfbc 0181d066 0181d061 fc5a8d20 fbffc001 fc503fb8 c001dbad
[fc52cb9d]
(XEN)        00000000 fcfec000 00000010 c04de920 [fc513324] fcfec000 00000000
fc5a8d20
(XEN)        f7efa000 00000113 00000000 [fc5311fe] fc503fb8 00000001 fbeeb000
fbeeb000
(XEN)        f7efa000 00000113 00000000 fbffc000 000e0000 c0114cd1 00000819 00210286
(XEN)        c0489ee4 00000821 00000821 00000821 00000000 00000000 fc5a8d20
(XEN) Call Trace from ESP=fc503ee4: [<fc5221d2>] [<fc52cb9d>] [<fc513324>]
[<fc5311fe>]

 ****************************************
CPU0 FATAL TRAP: vector = 6 (invalid operand)
[error_code=0000]
Aieee! CPU0 is toast...
****************************************

> Is there anything 'unusual' about the machine you're using?

No, not at all (SuperMicro 6013P-i).  I'd would have expected others to have
encountered the same problem by now, but I'm not quite sure how to intrepret theese
results.

From: "Keir Fraser" <Keir.Fraser@cl.cam.ac.uk>

> See Ian's email also, but this definitely looks like new start-of-day
> code in 2.6.11 that needs fixing for running on Xen. If you can get a
> stack backtrace for Linux, or some printk output (Ian's email explains
> how to do both) then we can try narrowing down further.
>
> I'm surprised it fails on your Xeon system but not ours. :-(

Same here.  Hopefully this means something to you guys :-)

-Chris