[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: pv_ops dom0 USB fixed


  • To: "Ian Campbell" <Ian.Campbell@xxxxxxxxxx>
  • From: "Andrew Lyon" <andrew.lyon@xxxxxxxxx>
  • Date: Fri, 12 Dec 2008 14:26:58 +0000
  • Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Aviv Grafi <aviv@xxxxxxxxxxxx>
  • Delivery-date: Fri, 12 Dec 2008 06:27:20 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Wqp7ZYbiyBGixEdb800eUAxl/k+zkSnB6d8xgqo5WRx3mEP//a1akehPCahMjdqa6/ VJJfRB3g8Eu4Ui/9CtlpVwrFUKhcTYDi/XmtHkXARB3QNsWR+wVwHwTxSol1K5OXFmxK 0kiwmsyq4PYZHBW/xsYzYk7BIiaYLc34oRvvo=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Fri, Dec 12, 2008 at 11:47 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Fri, 2008-12-12 at 11:36 +0000, Andrew Lyon wrote:
>> On Fri, Dec 12, 2008 at 11:15 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
>> wrote:
>> > On Fri, 2008-12-12 at 09:12 +0000, Andrew Lyon wrote:
>> >> (XEN) Xen-e820 RAM map:
>> >> (XEN)  0000000000000000 - 000000000009ec00 (usable)
>> >> (XEN)  00000000000f0000 - 0000000000100000 (reserved)
>> >> (XEN)  0000000000100000 - 00000000cfdff800 (usable)
>> >> (XEN)  00000000cfdff800 - 00000000cfe53c00 (ACPI NVS)
>> >> (XEN)  00000000cfe53c00 - 00000000cfe55c00 (ACPI data)
>> >> (XEN)  00000000cfe55c00 - 00000000d0000000 (reserved)
>> >> (XEN)  00000000e0000000 - 00000000f0000000 (reserved)
>> >> (XEN)  00000000fec00000 - 00000000fed00400 (reserved)
>> >> (XEN)  00000000fed20000 - 00000000feda0000 (reserved)
>> >> (XEN)  00000000fee00000 - 00000000fef00000 (reserved)
>> >> (XEN)  00000000ffb00000 - 0000000100000000 (reserved)
>> >> (XEN)  0000000100000000 - 0000000128000000 (usable)
>> >> BIOS-provided physical RAM map:
>> >>  Xen: 0000000000000000 - 00000000000a0000 (usable)
>> >>  Xen: 00000000000a0000 - 0000000000100000 (reserved)
>> >>  Xen: 0000000000100000 - 000000000087d000 (usable)
>> >>  Xen: 000000000087d000 - 0000000000fd1000 (reserved)
>> >>  Xen: 0000000000fd1000 - 00000000ea567000 (usable)
>> >
>> > It's only peripherally related (and a bit of a stab in the dark) but
>> > since you have plenty of host RAM your pseudo-physical addresses overlap
>> > with the ACPI tables and such so it would be worth trying out the patch
>> > I just pushed to reserve these. Although I saw actual warnings and you
>> > don't seem to it's possible there are other failures due to the
>> > conflicts. Alternatively you could try limiting the domain 0 memory,
>> > e.g. with dom0_mem=3G on the Xen command line.
>> >
>> > Ian.
>> >
>> >
>>
>> I tried with dom0_mem=3G and =1G, neither seems to make any
>> difference, I also tried libata.force=noncq.
>>
>> Is it still worth trying your patch?
>
> If dom0_mem={1,3}G didn't work (and the memory map printed by the kernel
> is correspondingly truncated) then I don't think the patch will do
> anything extra.
>

I tried with the patch anyway, it didnt seem to make any difference.

I also booted the kernel on the bare metal and it works perfectly, the
sata hd is detected ok.

Anything I can do to help debug this?

Andy

>> I followed the instructions on the wiki to download the pv_ops source
>> tree, what method can I use to update the source to the latest commits
>> without downloading it all from scratch?
>
> You can basically qpop -a, update both trees and the qpush again. e.g.
>
>     1. hg qpop -a
>     2. hg -R .hg/patches pull -u
>     3. hg pull # no -u, update follows
>     4. hg update `cat .hg/patches/KERNEL_VERSION`
>     5. hg qpush -a
>
> If .hg/patches/KERNEL_VERSION doesn't change you can skip the 3rd and
> 4th steps.
>

Thanks, much quicker and easier.

Andy

> Ian.
>
>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.