Re: [Xen-devel] Re: Xen-4.0.x doesn't start on 32bit / pvops 2.6.32.19

[Stefan Kuhne <stefan.kuhne@xxxxxxx>]

Am 16.08.2010 12:44, schrieb Pasi Kärkkäinen:
> On Mon, Aug 16, 2010 at 12:15:41PM +0200, Stefan Kuhne wrote:

Hello Pasi,

>> On 64bit system boots until mount of rootfs.
>>
> 
> So does 64bit kernel boot/work OK?
> 
I think so.
But command line forgot "root=..." and I don't know why.

>> But 32bit boots until:
>> (XEN) d0:v0: unhandled page fault (ec=0009)
>> (XEN) Pagetable walk from c009fc00:
>> (XEN)  L3[0x003] = 0000000039820001 00001820
>> (XEN)  L2[0x000] = 0000000039fdd067 00001fdd
>> (XEN)  L1[0x09f] = 000007fffffff063 ffffffff
>> (XEN) d0:v0: reserved bit in page table (ec=0009)
>>
>> Is anybody running an 32bit System?
>> I need 32bit because of my destination Distro is only in 32bit available.
>>
> 
> Based on the full bootlog the problem is in the dom0 kernel, not in Xen 
> hypervisor.
> Did you try earlier versions of the dom0 kernel? Which version introduces 
> this problem?
> 
Only 2.6.13.14 from xen-4.0.1-rc5.

> I think 2.6.32.10 booted/worked for me on 32bit..
> 
How can I get this version?

> <snip>
> 
>> (XEN) *** LOADING DOMAIN 0 ***
>> (XEN)  Xen  kernel: 32-bit, PAE, lsb
>> (XEN)  Dom0 kernel: 32-bit, PAE, lsb, paddr 0x1000000 -> 0x19f5000
>> (XEN) PHYSICAL MEMORY ARRANGEMENT:
>> (XEN)  Dom0 alloc.:   0000000038000000->000000003c000000 (245760 pages
>> to be allocated)
>> (XEN) VIRTUAL MEMORY ARRANGEMENT:
>> (XEN)  Loaded kernel: c1000000->c19f5000
>> (XEN)  Init. ramdisk: c19f5000->c1ed6800
>> (XEN)  Phys-Mach map: c1ed7000->c1fd7000
>> (XEN)  Start info:    c1fd7000->c1fd747c
>> (XEN)  Page tables:   c1fd8000->c1fef000
>> (XEN)  Boot stack:    c1fef000->c1ff0000
>> (XEN)  TOTAL:         c0000000->c2400000
>> (XEN)  ENTRY ADDRESS: c1798000
>> (XEN) Dom0 has maximum 4 VCPUs
>> (XEN) Scrubbing Free RAM: .............................done.
>> (XEN) trace.c:89:d32767 calc_tinfo_first_offset: NR_CPUs 128,
>> offset_in_bytes 258, t_info_first_offset 65
>> (XEN) Xen trace buffers: disabled
>> (XEN) Std. Loglevel: All
>> (XEN) Guest Loglevel: All
>> (XEN) **********************************************
>> (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
>> (XEN) ******* This option is intended to aid debugging of Xen by ensuring
>> (XEN) ******* that all output is synchronously delivered on the serial line.
>> (XEN) ******* However it can introduce SIGNIFICANT latencies and affect
>> (XEN) ******* timekeeping. It is NOT recommended for production use!
>> (XEN) **********************************************
>> (XEN) 3... 2... 1...
>> (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
>> input to Xen)
>> (XEN) Freed 152kB init memory.
> 
> 
> So Xen starts fine, and it boots the dom0 kernel here.
> 
> 
>> mapping kernel into physical memory
>> Xen: setup ISA identity maps
>> about to get started...
>> [    0.000000] Reserving virtual address space above 0xf5800000
>> [    0.000000] Initializing cgroup subsys cpuset
>> [    0.000000] Initializing cgroup subsys cpu
>> [    0.000000] Linux version 2.6.32.19 (root@FB5-Cluster) (gcc version
>> 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #1 SMP Mon Aug 16 11:19:14 CEST 2010
> 
> <snip>
> 
>> [    0.000000] NX (Execute Disable) protection: active
> 
> 
> Did you try without NX? (ie. turn it off in the BIOS). 
> 
I've tested a lot.
I'll try it again.

>> [    0.000000] 302MB HIGHMEM available.
>> [    0.000000] 721MB LOWMEM available.
> 
> Does dom0_mem=512M help? 
> 
I'll test it.

>> (XEN) d0:v0: unhandled page fault (ec=0009)
>> (XEN) Pagetable walk from c009fc00:
>> (XEN)  L3[0x003] = 0000000039820001 00001820
>> (XEN)  L2[0x000] = 0000000039fdd067 00001fdd
>> (XEN)  L1[0x09f] = 000007fffffff063 ffffffff
>> (XEN) d0:v0: reserved bit in page table (ec=0009)
>> (XEN) Pagetable walk from c009fc00:
>> (XEN)  L3[0x003] = 0000000039820001 00001820
>> (XEN)  L2[0x000] = 0000000039fdd067 00001fdd
>> (XEN)  L1[0x09f] = 000007fffffff063 ffffffff
>> (XEN) ----[ Xen-4.0.1-rc6  x86_32p  debug=n  Tainted:    C ]----
>> (XEN) CPU:    0
>> (XEN) EIP:    e019:[<c17a56a1>]
> 
> You'd have to use gdb on the kernel vmlinux file to resolve which
> funtion this address points to.. to see why/where it crashes.
> 
I never has debugged a Kernel.

Attachment: signature.asc
Description: OpenPGP digital signature

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