On Mon, Oct 16, 2006 at 02:41:40PM -0600, Alex Williamson wrote:
Yes, I think we'll need to switch to discontig/sparsemem for the dom0
kernel if the memmory map is going to reflect the bare metal hardware
memory layout. Unfortunately, just switching to discontig w/ virtual
memmap does not
On Thu, Dec 21, 2006 at 01:13:45PM +0800, Xu, Anthony wrote:
This is only used by __kernel_syscall_via_epc function in xeno domain.
previouly, break 0x19(XEN_HYPER_GET_PSR) is the second
Instruction in the bundle.
When I debugged the patch of remove the requirement (vpsr.ic==0)
Hi,
This is an initial patch to make Xen start assigning meta physical
memory in the physical ranges that match the hardware it is running
upon.
More work needs to be done in this area, but it is crucial we assign
memory correctly, in particular for dom0.
Cheers,
Jes
Currently Xen assigns
Hi, Jes
Isaku work this issue now.
Could you see his patches?
http://lists.xensource.com/archives/html/xen-ia64-devel/2006-12/msg00249.html
Best Regards,
Akio Takebe
Hi,
This is an initial patch to make Xen start assigning meta physical
memory in the physical ranges that match the hardware it
Hi Emmanuel,
Thanks for your quick response.
I'm not familiar with scheduler, I'll study it. :-)
I put comments below, maybe it's not right. :-)
Emmanuel Ackaouy write on 2006年12月22日 0:23:
Hi Anthony.
Based on the number of ticks on CPU0 that occurred between the
two stat dumps, over 16
On Thu, Dec 21, 2006 at 08:54:23AM -0500, Dave Anderson wrote:
Isaku Yamahata wrote:
The current xm dump-core on ia64 loses some registers infomation
which is saved on xen register stack.
e.g. r33, ... aren't saved in domU xendump file.
Probably ia64 specific code would be
Hi, Anthony,
checking your patch, I saw a call trace on booting Xen. It is attached
to this e-mail.
Now it became easy to understand hyperprivop codes but it seemed that
the codes related to vdso should not be removed. The concrete patch
that worked fine is also attached.
Regards,
Hi,
I report a benchmark result of this week.
semget05 seems LTP's bug (Thanks to Yamahata), so I treat it as LTP's
bug.
But semop05 failed now. It passed manually.
Details:
automatically:
semop05 1 BROK : couldn't create semaphore in setup
semop05 2 BROK : Remaining cases broken
