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

["Andrew Lyon" <andrew.lyon@xxxxxxxxx>]

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