I had to adjust also this in order to compile:
diff --git a/sys/arch/i386/i386/rbus_machdep.c
b/sys/arch/i386/i386/rbus_machdep.c
index 178dd73..4eb6c55 100644
--- a/sys/arch/i386/i386/rbus_machdep.c
+++ b/sys/arch/i386/i386/rbus_machdep.c
@@ -114,7 +114,7 @@ rbus_min_start_hint(size_t ram)
}
aprint_debug("rbus: rbus_min_start set to 0x%0lx\n",
- rbus_min_start);
+ (long unsigned int)rbus_min_start);
#endif
}
I'm not sure fix is correct, but I think it doesn't trigger the
issue. What actually happens is attached in cardbus_boot.txt file.
rbus_min_start is busaddr_t, so really there should be PRI_busaddr_t
macro, but casting to unsigned long seems unlikely to be the real
problem.
Given that it works with GENERIC and not wtih XEN3_DOM0, I would look
into what happens with pci memory space mapping. Read the manpage for
cardbus(4). Basically mappings are set up to put the cardbus (pci)
memory space into the host computer's memory space someplace, and the
code before what you patched is trying to avoid where physical memory is
mapped. But on xen, the whole memory layout may be different.
Why are you using PAE if you only have 1.5G of actual RAM?
I suggest trying a non-PAE XEN3_DOM0.
If the dom0 sees 512 MB, it probably will try to map the cardbus memory
to 1G. But, I don't know how that mapping is effected, or interacts
with xen memory mamagement.
Attachment:
pgpVfrcDSpq3q.pgp
Description: PGP signature