Re: [xen-unstable test] 18851: regressions - FAIL

[David Vrabel <david.vrabel@citrix.com>]

On 04/09/13 11:41, Ian Jackson wrote:
> Jan Beulich writes ("Re: [xen-unstable test] 18851: regressions - FAIL"):
>> On 02.09.13 at 17:10, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> ...
>>> I'm not sure why my osstest push gate didn't catch this, but the
>>> regression is indeed caused by the change from Jeremy's old tree to
>>> Linux 3.10.y.
> 
> It appears that the push gate didn't catch it because it's host
> specific, and it got lucky and didn't run a test on that host.
> 
>> So how do we want to deal with that? Linux maintainers - any
>> chance you could help out? The staging tree having been stuck
>> for over a week is certainly less than ideal...
> 
> David Vrabel pointed out that more modern kernels have a different
> interpretation of things like "dom0_mem=256M", and can waste lots and
> lots of actual memory on pointless bookkeeping for future expansion
> (which the kernel envisages but we do not).
> 
> I have changed it to "dom0_mem=256M,max:256M".  I got a push of this
> change at "Wed, 4 Sep 2013 03:50:14 +0100".  I don't think any of the
> test runs yet reported have used this change.

Woodlouse's e820 as seen by the kernel looks like:

[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x0000000000099fff] usable
[    0.000000] Xen: [mem 0x000000000009a800-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x00000000d7f8ffff] usable
[    0.000000] Xen: [mem 0x00000000d7f9e000-0x00000000d7f9ffff] type 9
[    0.000000] Xen: [mem 0x00000000d7fa0000-0x00000000d7fadfff] ACPI data
[    0.000000] Xen: [mem 0x00000000d7fae000-0x00000000d7fdffff] ACPI NVS
[    0.000000] Xen: [mem 0x00000000d7fe0000-0x00000000d7fedfff] reserved
[    0.000000] Xen: [mem 0x00000000d7ff0000-0x00000000d7ffffff] reserved
[    0.000000] Xen: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec02fff] reserved
[    0.000000] Xen: [mem 0x00000000fee00000-0x00000000feefffff] reserved
[    0.000000] Xen: [mem 0x00000000ff700000-0x00000000ffffffff] reserved
[    0.000000] Xen: [mem 0x0000000100000000-0x00000001884d1fff] usable
[    0.000000] Xen: [mem 0x00000001884d2000-0x0000000227ffffff] unusable
[    0.000000] Xen: [mem 0x000000fd00000000-0x000000ffffffffff] reserved

That last reserved entry I think confuses the early setup and it does
odd things like:

[    0.000000] Set 266338518 page(s) to 1-1 mapping

Possibly relevant kernel thread here:

http://lkml.indiana.edu/hypermail/linux/kernel/1110.1/01213.html

I note that the e820 as seen by Xen does not have this reserved region

(XEN) Xen-e820 RAM map:
(XEN)  0000000000000000 - 000000000009a800 (usable)
(XEN)  000000000009a800 - 00000000000a0000 (reserved)
(XEN)  00000000000e6000 - 0000000000100000 (reserved)
(XEN)  0000000000100000 - 00000000d7f90000 (usable)
(XEN)  00000000d7f9e000 - 00000000d7fa0000 type 9
(XEN)  00000000d7fa0000 - 00000000d7fae000 (ACPI data)
(XEN)  00000000d7fae000 - 00000000d7fe0000 (ACPI NVS)
(XEN)  00000000d7fe0000 - 00000000d7fee000 (reserved)
(XEN)  00000000d7ff0000 - 00000000d8000000 (reserved)
(XEN)  00000000e0000000 - 00000000f0000000 (reserved)
(XEN)  00000000fec00000 - 00000000fec03000 (reserved)
(XEN)  00000000fee00000 - 00000000fee01000 (reserved)
(XEN)  00000000ff700000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000000228000000 (usable)

So it must be being added by Xen?

David