WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] 2.6.38 PV Guest boot failure - error while pinning mfn..

On 2011-03-21, at 4:30 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:

> On Sun, Mar 20, 2011 at 02:19:43PM -0700, Shriram Rajagopalan wrote:
>> On Sun, Mar 20, 2011 at 2:05 PM, Shriram Rajagopalan 
>> <rshriram@xxxxxxxxx>wrote:
>> 
>>> On Sun, Mar 20, 2011 at 1:45 PM, Konrad Rzeszutek Wilk <
>>> konrad.wilk@xxxxxxxxxx> wrote:
>>> 
>>>> On Sun, Mar 20, 2011 at 04:05:43PM -0400, Konrad Rzeszutek Wilk wrote:
>>>>> On Sat, Mar 19, 2011 at 06:22:17PM -0700, Shriram Rajagopalan wrote:
>>>>>> The kernel is built from konrad's tree, devel/next-2.6.39
>>>>>> commit:f4ddaaf4338999227b3f724615d8aecbe88d3f04
>>>> 
>>>> Ok. So you got Stefano's latest goodies:
>>>> 
>>>> * devel/bootup-fixes.v3:
>>>>     watchdog, SP5100: Check if firmware has set correct value in tcobase.
>>>>     xen: update mask_rw_pte after kernel page tables init changes
>>>>     xen: set max_pfn_mapped to the last pfn mapped
>>>>     x86: Cleanup highmap after brk is concluded
>>>> 
>>>>>> 
>>>>>> 64 bit PV guest, 64 bit dom0, xen 4.1.0-rc7-pre
>>>> 
>>>> Is the 64-bit dom0 kernel == 64-bit domu kernel?
>>>> 
>>> no. dom0 is 2.6.32.27 (from xenbits pvops tree).
>>> 
>>>> 
>>>>>> I have not been able to boot a pv domU, with the above kernel.
>>>>> 
>>>>> You might need this git commit:
>>>>> 31fd38842ab07b95440f24c6180d9a2c14b35111
>>>>> 
>>>>> tc/cmos: Check if ACPI is disabled, and if so don't attempt
>>>>> 
>>>>> If you pull my tree, you should be able to cherrypick.
>>>> 
>>>> Did that. No use. Still same error.
>>> FYI, this throws a warning
>>> linux-2.6/drivers/rtc/rtc-cmos.c:1000: warning: ‘return’ with no value, in
>>> function returning non-void
>>> 
>>> 
>>>> Also do 'earlyprintk=xenboot' in your PV guest and see what it tells you
>>>> (if anything).
>>>> 
>>>> No extra messages in xen's log.
>>> 
>>> Just for the heck of it, I copied out an .config from a pvops domU (2.6.32)
>> 
>> and tweaked it a bit - basically disabling backend drivers, rtc,
>> hpet_emulate_rtc.
>> 
>> I got this in console (xm create -c)
>> Started domain ubuntu-pv64 (id=5)
>> (early) [    0.000000] Initializing cgroup subsys cpuset
>> (early) [    0.000000] Initializing cgroup subsys cpu
>> (early) [    0.000000] Linux version 2.6.38-xenu (root@athos) (gcc version
>> 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #28 SMP Sun Mar 20 14:05:47 PDT 2011
>> (early) [    0.000000] Command line: root=/dev/xvda1 ro earlyprintk=xenboot
>> console=hvc0 3
>> (early) [    0.000000] ACPI in unprivileged domain disabled
>> (early) [    0.000000] released 0 pages of unused memory
>> (early) [    0.000000] Set 0 page(s) to 1-1 mapping.
>> (early) [    0.000000] BIOS-provided physical RAM map:
>> (early) [    0.000000]  Xen: 0000000000000000 - 00000000000a0000 (usable)
>> (early) [    0.000000]  Xen: 00000000000a0000 - 0000000000100000 (reserved)
>> (early) [    0.000000]  Xen: 0000000000100000 - 000000007d800000 (usable)
>> (early) [    0.000000] bootconsole [xenboot0] enabled
>> (early) [    0.000000] NX (Execute Disable) protection: active
>> (early) [    0.000000] DMI not present or invalid.
>> (early) [    0.000000] No AGP bridge found
>> (early) [    0.000000] last_pfn = 0x7d800 max_arch_pfn = 0x400000000
>> (early) [    0.000000] init_memory_mapping:
>> 0000000000000000-000000007d800000
>> 
>> The errors on xen's side are still same. MFN mapping error as stated
>> earlier.
> 
> And you are using 'xm' or 'xl'? Try the either one just to make sure it is
> not something silly there.
> 
Tried both. Same issue.
Btw, if you have a working domU, can you please test Rafael's patch for the 
HIBERNATE_INTERFACE ? he replied to my 
"PATCH v3 3/5 Add visible HIBERNATION_INTERFACE and hide HIBERNATION" with his 
version of the refactoring patch. 
I can compile the code but am not able to test it due to this boot issue. And 
before you ask, yes, all bugs reported here were without his patch.

 If it works out okay, we might be able to push the remaining 3 bits of the 
freeze-thaw patch via his tree, hopefully.
Shriram
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel