access got garbled data from ld2.acq instructions
in the vga console driver.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
Cc: Jes Sorensen [EMAIL PROTECTED]
diff --git a/arch/ia64/kvm/mmio.c b/arch/ia64/kvm/mmio.c
index 351bf70..e6f194a 100644
--- a/arch/ia64/kvm/mmio.c
+++ b/arch/ia64/kvm
Xu, Anthony wrote:
unnecessary divergence is
undesirable.
Good point, we should keep kvm/ia64 and xen/ia64 the same code base as
possible.
It would be nice, but the KVM codebase has already been modified a lot,
just the reformatting in order to be acceptable to the Linux kernel. I
don't
Hi,
Just an update on this problem - it seems that it's
drivers/video/console/vgacon.c that gets miscompiled. If I use
gcc-3.4.3 or gcc-4.3.0 I get a booting kernel, if I use RHEL5's
gcc-4.1.2 snapshot, it doesn't. Tried 4.2.0 as well with negative
results.
Cheers,
Jes
Hi,
Having had a ton of problems booting my self-compiled recent kernels
under KVM, I started tracking down the patch causing the issues. It
looks like it's patch e087db510cd96a75a614f6f6fcd5499ab21cb087 which
simply changes the packing attributes to struct screen_info. Given that
we on ia64
Isaku Yamahata wrote:
I'd rather have PARAVIRT_NR_IRQ set from Kconfig if possible given that
all of these are constants anyway. If we cannot do that, then it would
be better to do the #if FOO_NR_IRQ PARAVIRT_NR_IRQ in the various
header files for Xen/KVM/lguest so we don't get the clutter in
Make NR_IRQ overridable by each pv instances.
Pv instance may need each own number of irqs so that
NR_IRQS should be the maximum number of nr_irqs each
pv instances need.
This really looks dodgy.
+#ifdef CONFIG_PARAVIRT
+
+/* Determine the maximal NR_IRQ which each pv instances require.
+ *
Isaku == Isaku Yamahata [EMAIL PROTECTED] writes:
Isaku introduce pv_info which describes some randome info about
Isaku underlying execution environment.
Hi Isaku,
I am missing some of the patches in this series for some reason.
However, I'd like to open the discussion and ask why you are
Isaku Yamahata wrote:
Our justification is as follows.
The difference is its scope. pv_ops for virtualization and
machine vector is for platform difference.
- pv_ops does cover the area which shouldn't belong to machine vector.
For example, ia64 intrinsics paravirtualization.
It shouldn't
Dong, Eddie wrote:
Rather than making these binary patches, why not make them fast
syscalls and using a vdso page. Some of the priviledged instructions
are simply reads and we could have that information in a read-only
data page, so there is no need to do a context switch at all. Others
could
Isaku Yamahata wrote:
I'm willing to introduce something like PARAVIRT_NR_IRQS,
but I don't see how PARAVIRT_NR_IRQS solves the issues.
What I want here is to define by cpp
#define PARAVIRT_NR_IRQS\
max(
Dong, Eddie wrote:
My understanding is that code such as IVT table are well tuned and you
are really
difficult to pursuade people to replace those privilege resource access
instruction
to use vdso or something equalvalent such as mov GRx=CRy. For those C
code
previlige resource access, like
Robert == Robert Nagy [EMAIL PROTECTED] writes:
Robert Hi. I am trying to get Xen working on my altix system. The
Robert problem is that It does not matter which Xen version I am
Robert using (i've tested: unstable from the mercurial repository and
Robert the stable version too), the kernel
Alex Williamson wrote:
Jes,
This first chunk seems to serve no purpose other than to cause
'defined but not used' warnings in the build. I must have forgotten to
use no_warns=y before committing it. Can we leave these ifdef'd out
until you actually use them? Thanks,
Yeah, ok for me -
Alex Williamson wrote:
On Tue, 2007-06-19 at 10:04 +0200, Jes Sorensen wrote:
diff -r f5c03237a7f0 -r 5f526ad0298b
xen/arch/ia64/linux-xen/sn/kernel/sn2_smp.c
--- a/xen/arch/ia64/linux-xen/sn/kernel/sn2_smp.cTue Jun 19 09:35:38
2007 +0200
+++ b/xen/arch/ia64/linux-xen/sn/kernel
-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 6acbcc85 -r f5c03237a7f0 xen/arch/ia64/linux-xen/sn/kernel/io_init.c
--- a/xen/arch/ia64/linux-xen/sn/kernel/io_init.c Mon Jun 18 17:04:56
2007 +0200
+++ b/xen/arch/ia64/linux-xen/sn/kernel/io_init.c Tue Jun 19 09:35:38
2007 +0200
Hi,
Here's a working global_tlb_purge for sn2 - it's slw and
inefficient, but at least it boots.
Cheers,
Jes
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
simple global tlb purge implementation for SN2. ptcga isn't
propagated between nodes so IPI a CPU on each node to get the job
done. This is _slow_ and inefficient, but it works for now.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r f5c03237a7f0 -r 5f526ad0298b xen/arch/ia64/linux-xen/sn
PROTECTED]
# Date 1182179096 -7200
# Node ID 6acbcc855bc2f6094901c53226ff218f091c
# Parent 534211a668f5617451847b883098fdb323498696
Introduce machine vector for platform specific fixups for dom0. This
is required to map SN2 specific registers to dom0.
Signed-off-by: Jes Sorensen [EMAIL
together with the patch I just posted for Xen to map in the
SHUB registers etc.
Cheers,
Jes
Use ioremap() on SN2 specific PIC and TIO registers rather than
manually setting the __IA64_UNCACHED_OFFSET bits in the address we get
from the PROM.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
---
arch
Isaku Yamahata wrote:
On Wed, Jun 13, 2007 at 05:12:47PM +0200, Jes Sorensen wrote:
We could do that, but I think we should do it on top of my patch. Ie.
I think it's better to have a too large heap per default and then let
the users reduce it rather than the other way round. What do you think
Isaku Yamahata wrote:
On Thu, Jun 14, 2007 at 09:45:01AM +0200, Jes Sorensen wrote:
I agree that it is safe bet to increase the default value.
What I wanted to say is
I don't insist on the dafault value and I just hoped you to add
xenheap_megabytes support.
However you seem to dislike
[EMAIL PROTECTED] wrote:
Quoting Jes Sorensen [EMAIL PROTECTED]:
I was hoping someone could point me to a link with a 'how to boot domU
for dummies' now that dom0 has booted.
Here is how I do it:
I create a partition for domU.
I copy the entire dom0 filesystem to domU partition.
I modify
Dietmar Hahn wrote:
You can start xend with the debug option:
export XEND_DEBUG=1
xend start
Maybe you can see some problems there.
Hi Diemar,
That actually made a different - it seems to run when I set XEND_DEBUG=1
not very logical, but at least something happend :-(
When I try and launch
[EMAIL PROTECTED] wrote:
Quoting Jes Sorensen [EMAIL PROTECTED]:
[EMAIL PROTECTED] ~]# xm create -c xxx
Using config file /etc/xen/xxx.
[EMAIL PROTECTED] ~]# Error:
I also get a ton of these on the console of dom0
I am not so up to date.
Isaku recently posted a patch about this issue. I
Alex Williamson wrote:
On Thu, 2007-06-14 at 17:56 +0900, Isaku Yamahata wrote:
On Thu, Jun 14, 2007 at 10:43:30AM +0200, Jes Sorensen wrote:
I don't modifying my patch, but I think adding xenheap_megabytes_support
as a boot time option is a different patch from mine. I think we agree
Hi,
So I kinda got bored of booting Xen on that little test box I have here
and tried it out on a medium sized system instead. I ran into a couple
of issues in the sn2 specific code and some with default values in the
dom kernel being set to silly low numbers . like CONFIG_NR_CPUS.
Basically
Tristan == Tristan Gingold [EMAIL PROTECTED] writes:
Tristan On Thu, Jun 07, 2007 at 04:34:01PM -0600, Alex Williamson
Tristan wrote:
Next on my TODO list for this is driver domains. This is where it
might get complicated. Somehow I need to make the driver domain
aware that a PCI bus makes
Isaku Yamahata wrote:
On Fri, Jun 08, 2007 at 10:08:38AM +0200, Jes Sorensen wrote:
I see, so the addresses are calculated by dom0, not by Xen? Yes they
match my memory map, but because I have a hole in that space in the
physical map I see evtchn_set_pending() (in Xen) trying to scribble
based on the size of
CONFIG_NR_CPUS. Hardcoding to 256 means things break when trying to
boot medium to large systems.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r a87acf37aa00 -r c275cb400f8c include/asm-ia64/irq.h
--- a/include/asm-ia64/irq.hTue Jun 12 22:02:27 2007 -0600
+++ b
Jes Sorensen wrote:
Hi,
This one is needed to boot more than 40 CPUs or we run out of IRQ
sources.
Cheers,
Jes
Ok let me try once more, this time with a correct patch. Sorry for
the noise.
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1181738302 -7200
# Node ID
to compile
a smaller Xen.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 96617c4f19aa -r 21714d18a758 xen/include/asm-ia64/config.h
--- a/xen/include/asm-ia64/config.h Tue Jun 12 20:41:08 2007 -0600
+++ b/xen/include/asm-ia64/config.h Wed Jun 13 15:42:07 2007 +0200
@@ -111,8
on xen_pstart rather than
address from ELF image as dom0 meta-physical memory must match real
physical window.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 44a59dc86626 -r ce09d8e7f733 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cFri May 11 14:27:18 2007 +0200
+++ b
Isaku Yamahata wrote:
On Wed, Jun 13, 2007 at 03:43:57PM +0200, Jes Sorensen wrote:
For the bigger systems we need a slightly bigger heap or the heap
will overflow. Unfortunately there is no easy way to determine the
size dynamically this early in the boot process before the nodes have
been
Isaku Yamahata wrote:
On Thu, Jun 07, 2007 at 06:01:17PM +0200, Jes Sorensen wrote:
Hi,
When dom0 boots it prints out a couple of lines like these:
Xen p2m: assign p2m table of [0x0030, 0x00302400)
Xen p2m: to [0x01b04000, 0x01b043ffc000) (65536 KBytes)
I
Hi,
When dom0 boots it prints out a couple of lines like these:
Xen p2m: assign p2m table of [0x0030, 0x00302400)
Xen p2m: to [0x01b04000, 0x01b043ffc000) (65536 KBytes)
I am trying to figure out where the addresses in the first line
originate from. They are
Isaku == Isaku Yamahata [EMAIL PROTECTED] writes:
Isaku On Tue, May 22, 2007 at 07:32:28PM -0600, Alex Williamson
Isaku wrote:
In this case NUM_MEM_DESCS should be very small since it's only
adding the descriptors we add for xen and the rest is dynamically
sized based on the number of entries
Alex Williamson wrote:
On Tue, 2007-06-05 at 09:13 +0200, Jes Sorensen wrote:
diff -r a72f0131bd89 -r 6828cbe7e55d xen/include/asm-ia64/config.h
--- a/xen/include/asm-ia64/config.h Thu May 31 14:47:08 2007 -0600
+++ b/xen/include/asm-ia64/config.h Tue Jun 05 09:11:21 2007 +0200
@@ -29,7
1181027481 -7200
# Node ID 6828cbe7e55d4a7fccfbbc19358376070555d01d
# Parent a72f0131bd8903f9cd918e27ecdb1f11d551f28d
Set NODE_SHIFT to something a bit more realistic
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r a72f0131bd89 -r 6828cbe7e55d xen/include/asm-ia64/config.h
--- a/xen/include/asm-ia64
reality a bit
closer and save some memory in the heap arrays.
With this patch a 4-node SGI Altix is able to boot dom0.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 765d90fd0f63 -r 41dfd6d9d0d4 xen/arch/ia64/linux-xen/setup.c
--- a/xen/arch/ia64/linux-xen/setup.c Wed May 30 11:05:04 2007
[EMAIL PROTECTED]
# Date 1180966210 -7200
# Node ID 0e990d1f021a0e720c004a4d6517ba8412f0814c
# Parent 5ea5522aa0d56923444183bb3264cafd37576c8b
Set PADDR_BITS to 48 to match reality and save about 5KB per node.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 5ea5522aa0d5 -r 0e990d1f021a xen
through a bunch of physical pages to dom0 as they are required
for various things on SN2 (basically our SHUB chip on each node).
Cheers,
Jes
On Thu, May 24, 2007 at 04:28:21PM +0200, Jes Sorensen wrote:
Sorry, but there's more to it than that, there are other drivers and
there is the whole
Alex == Alex Williamson [EMAIL PROTECTED] writes:
AlexFirst, there are a couple ways that NUMA is described and
Alex implemented in Linux. Many of us are more familiar with the
Alex ACPI approach (or DIG as Jes might call it). This is
Alex comprised of ACPI static tables and methods in
Isaku Yamahata wrote:
On Thu, May 24, 2007 at 04:20:07PM -0600, Alex Williamson wrote:
this one that convert to Linux style. Are there other opinions on this
before we set a precedent? Thanks,
I don't insist on any particular styles.
If linux style under ia64 directory is the consensus,
Isaku Yamahata wrote:
On Fri, May 25, 2007 at 10:55:18AM +0200, Jes Sorensen wrote:
Probably I should have be clearer.
Your patch left the line * indent-tabs-mode: nil unmodified.
So I wanted to suggest
- * indent-tabs-mode: nil
+ * indent-tabs-mode: t
Whoops! Admittedly I only looked
Isaku Yamahata wrote:
On Thu, May 24, 2007 at 11:42:56AM +0900, Isaku Yamahata wrote:
elilo tries the physical address given by its elf header at first,
then tries to relocate the image only when administrater allows elilo
to relocate explicitly with warning message.
I only took look at
Akio Takebe wrote:
Hi, Jes
Just a single node, 2 sockets
Xen on ia64 create a vcpu for dom0 by default.
If you want to create more vcpus,
add dom0_max_vcpus=N in bootparameter of xen.
I see the below in your log. Xen get information of your node.
(XEN) Brought up 2 CPUs
Whoops,
Isaku Yamahata wrote:
On Thu, May 24, 2007 at 10:34:22AM +0200, Jes Sorensen wrote:
dom0 needs the metaphysical addresses or nothing can work as we use the
node info for talking to the PCI controllers, memory controllers (IPIs
and TLB flushes) etc.
I don't understand why 'must match' here
Isaku Yamahata wrote:
On Thu, May 24, 2007 at 12:28:46PM +0200, Jes Sorensen wrote:
I don't agree here.
I think fixing it with P=M requires much bigger efforts than
paravirtualizing the files under sn/ directory.
Looking around sn/ directory, I found that address conversion
functions
Isaku == Isaku Yamahata [EMAIL PROTECTED] writes:
Isaku 9 / 14
Isaku,
This is really awful :-( The Xen/ia64 codebase has already had the
benefit of being formatted sanely, please don't migrate sane code over
to the broken style just because it's being moved around.
Best regards,
Jes
the split.
Cheers,
Jes
Lindent the dom_fw_foo code to revert formatting that was done as
part of splitting up the files.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 71d13b19219e xen/arch/ia64/xen/dom_fw_dom0.c
--- a/xen/arch/ia64/xen/dom_fw_dom0.c Thu May 24 16:41:59 2007 +0200
+++ b/xen
Alex Williamson wrote:
On Tue, 2007-05-22 at 15:09 +0200, Jes Sorensen wrote:
Hi,
We need some more SAL calls emulated on SN2.
Are we getting to a point that we should should expand the machine
vectors when running on Xen to include a platform specific SAL emulator?
For example
9858f0f884ff3f28415cf2f03630d6a4082248f7
# Parent 7cb47b607563bb356dad2a2fb1555bc261076f94
Don't scrub pages when running on Medusa
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 7cb47b607563 -r 9858f0f884ff xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Tue May 22 17:16:55 2007 +0200
Just a single node, 2 sockets
Jes
fs0:\efi\SuSE elilo x2 root=/dev/sda3
ELILO
Uncompressing Linux... done
Loading file net0:initrd...done
Loading file net0:vmlinuz-xen...done
Uncompressing... done
__ ___ ___ __ _
\ \/ /___ _ __ |___ / /
of dom0 image based on xen_pstart rather than
address from ELF image as dom0 meta-physical memory must match real
physical window.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 44a59dc86626 -r ce09d8e7f733 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cFri May 11 14:27:18
anywhere
with dom0 on an SN2. Also reduce the verbosity of the emulated calls a
bit.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r ce09d8e7f733 -r a00f130f36c7 xen/arch/ia64/xen/fw_emul.c
--- a/xen/arch/ia64/xen/fw_emul.c Tue May 22 14:53:26 2007 +0200
+++ b/xen/arch/ia64/xen/fw_emul.c
of super simple console driver with polled input support. In
addition switch driver to use ia64_sn_console_putb() post-boot to get
interactive response.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r a00f130f36c7 -r 7cb47b607563 xen/arch/ia64/xen/sn_console.c
--- a/xen/arch/ia64/xen
Tristan Gingold wrote:
- enhance fake SAL code in geust domain pseudo physical address space.
Currently only break code is embedded.
Make it smarter to handle virtual addresses.
- convert virtual address into pseudo physical address
and pass pseudo physical address to Xen.
- use
[EMAIL PROTECTED] wrote:
The basic answer is you can't do that reliably.
I don't have Xen code under my hand now, but there are a few examples in such
direct write for some PAL calls and some EFI calls.
But they may fail: the TLB may not have the entry and there is currently no
way to
297cdf44fc2d6f578a2f56976aedf296c039d119
Update sn_sal.h to latest 2.6.20 version
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 297cdf44fc2d -r 7941568b1f89
xen/include/asm-ia64/linux/asm/sn/README.origin
--- a/xen/include/asm-ia64/linux/asm/sn/README.origin Thu Mar 01 14:27:48
2007 +0100
+++ b/xen/include/asm-ia64
and
destination address to handle this and catch IO ports above
0x1000 and map them down to a safe area.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 7941568b1f89 -r d7568a1a2481 xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c Thu Mar 01 14:37:15 2007 +0100
+++ b/xen
18dd07d55851bcc7c33771fc8cc12a2385b8fd34
emulate sn2 specific SAL calls for dom0
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 18dd07d55851 -r 207e879bfb4b xen/arch/ia64/xen/fw_emul.c
--- a/xen/arch/ia64/xen/fw_emul.c Tue Jan 16 04:02:16 2007 +0100
+++ b/xen/arch/ia64/xen/fw_emul.c Wed Feb
Hi,
Some more build stuff for sn2.
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1172671391 -3600
# Node ID 5786fbec40fb3a6754a832b984c027b2d69599b2
# Parent 207e879bfb4bc56e78bdc15619f231d7699c3832
more sn2 IO build fixes
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff
Kevin == Tian, Kevin [EMAIL PROTECTED] writes:
Kevin Yeah, memory map may be sparse on ia64, but, only at physical
Kevin level. You can always present a compact pseudo physical layout
Kevin to a domain, despite of sparse or not in real physical.:-) BTW,
Kevin is it possible to save memmap into
Tang == Tang, Wei [EMAIL PROTECTED] writes:
Tang Tang, Wei would like to recall the message, Welcome to the
Tang Xen-ia64-devel mailing list.
Hello Tang,
Please note that there is no such thing as email recall. The fact you
sent this out doesn't mean it get deleted from other peoples' inboxes.
Tristan Gingold wrote:
On Thu, Dec 28, 2006 at 05:52:57PM +0100, Jes Sorensen wrote:
[...]
With these patches applied I am seeing PAL warnings about unimplemented
PAL call 42 and then a cachable vs uncacheable access in xenmisc.c.
Anyone else seeing this?
Yes, PAL call 42 has never been
to Isaku's NUMA patches.
Alex, I'd appreciate it if you apply this one, it's important for sn2.
Thanks,
Jes
Respect memory attributes when mapping EFI_RUNTIME and reserved pages.
Not all of these pages are writable and/or cachable!
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 533e06b4151c
address zero in
order to be able to run those underpriviledged operating systems that
cannot handle modern computers (a certain thing that nobody likes to
talk about comes to mind here).
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 665284c4a8e7 xen/arch/ia64/xen/dom_fw.c
--- a/xen/arch
Hi,
This one solves the problem where sn2_send_IPI() would cause a page
fault because sn_nodepda is not yet available at the time we try and
deference it to get the nasid.
This patch falls back to making the SAL call until sn_nodepda is
available.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED
9411fcd9abdeb59fa5a2b3c3f54e1d0432d616c4
# Parent aabb5fba6a2e12beec379f24fe9ddd656d09c98f
Check we are running under Xen before trying to dereference
xen_start_info! xen_start_info is NULL on ia64 if running raw
hardware.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r aabb5fba6a2e -r 9411fcd9abde
linux-2.6
# Node ID cc58c14826cd9e25be9653dbbe9ebb1b9f27579d
# Parent 9411fcd9abdeb59fa5a2b3c3f54e1d0432d616c4
No need to allocate contiguous_bitmap out of the low pages pool as all
pages are directly accessible on an ia64.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 9411fcd9abde -r cc58c14826cd
Tristan Gingold wrote:
On Fri, Dec 15, 2006 at 11:09:03AM +0100, Jes Sorensen wrote:
Hi,
This one falls in the micro optimisation area, but still. No reason to
zero initialize global variables.
Hi,
just FYI, gcc is supposed to automatically put 0 initialized variables into
bss. See `-fno
Hi,
This patch changes kernel_start() to use ia64_platform_is() and not
init the 16550 driver on sn2. In addtion this eliminates the need for
the old hpsim test function.
This patch is relative to the sn2+machvec branch!
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
Cheers,
Jes
# HG changeset
Hi,
This one falls in the micro optimisation area, but still. No reason to
zero initialize global variables.
Cheers,
Jes
No need to init global variables to zero as it will place them in the
data segment rather than the bss segment.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r
Alex Williamson wrote:
On Fri, 2006-12-15 at 10:39 +0100, Jes Sorensen wrote:
Hi,
This patch changes kernel_start() to use ia64_platform_is() and not
init the 16550 driver on sn2. In addtion this eliminates the need for
the old hpsim test function.
I don't know if Xen currently runs under
Alex Williamson wrote:
Hi Jes,
Thanks for the cleanup. I've added most of these to the mercurial
tree here:
http://free.linux.hp.com/~awilliam/xen-ia64-machvec/
I found a couple more README.origin files that needed updating and
reworked parts of patch 4 (adding lots more #ifdef XEN
Alex Williamson wrote:
Hi Jes,
Thanks for the cleanup. I've added most of these to the mercurial
tree here:
http://free.linux.hp.com/~awilliam/xen-ia64-machvec/
I found a couple more README.origin files that needed updating and
reworked parts of patch 4 (adding lots more #ifdef XEN
Jes == Jes Sorensen [EMAIL PROTECTED] writes:
Jes Alex Williamson wrote:
[snip]
Jes Thats why I didn't add sn_sal.h to the README.origin since it was
Jes unclear
Sorry, managed to hit some strange keycombo that sent it off ...
[EMAIL PROTECTED]@[EMAIL PROTECTED] IMAP GUI click-click-wush-wush
Extra dummy files needed for sn2+machvec support
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166019915 -3600
# Node ID 9c94e874e26580cee01452151fe0ada3f503375c
# Parent c02ede89a6e48d459e6dd586297246966de00eb0
add new dummy files needed to build sn2 and machvec support
Changes to make the tree build again after applying the news files,
without enabling machvec+sn2 support.
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166020323 -3600
# Node ID f936608bf9f88acae521a9cbe86ae253eede6fde
# Parent 9c94e874e26580cee01452151fe0ada3f503375c
Initial
Small makefile changes to enable sn2+machvec support.
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1166027894 -3600
# Node ID 94d0822ebbf8d439688fa963368d5589f818901b
# Parent 10c1f9a049e3f6eaceda7b29200fff0a020cf325
enable build of sn2 + machvec support
diff -r
Jes == Jes Sorensen [EMAIL PROTECTED] writes:
Jes Hi, Here are the core files from Linux - all from 2.6.19 this
Jes time needed for sn2+machvec.
Jes This patch set basically pulls it all from 2.6.19 and moves the
Jes files around in the linux/linux-xen dirs as Alex requested.
Forgot
Jes == Jes Sorensen [EMAIL PROTECTED] writes:
Jes Changes required for the new sn2+machvec files to build under
Jes Xen. Cheers, Jes # HG changeset patch # User
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
___
Xen-ia64-devel mailing list
Xen-ia64
Jes == Jes Sorensen [EMAIL PROTECTED] writes:
Jes Small makefile changes to enable sn2+machvec support. Cheers,
Jes Jes
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http
Alex Williamson wrote:
On Fri, 2006-12-01 at 15:13 +0100, [EMAIL PROTECTED] wrote:
Original files copied from Linux, requires for initial SN2 and machine
vector support.
Hi Jes,
I'm having trouble figuring out which Linux version each of these
came from. I think it's important that
.
This reduces the Xen boot time by roughly 150 seconds on a small
Altix with 6GB of RAM.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 66609699c9d0 xen/common/page_alloc.c
--- a/xen/common/page_alloc.c Fri Dec 08 14:29:42 2006 +0100
+++ b/xen/common/page_alloc.c Mon Dec 11 15:54:10
Hi,
I am seeing build errors after updating my tree today. Not sure if this
has already been reported?
Cheers,
Jes
gcc -O2 -fomit-frame-pointer -DNDEBUG -std=gnu99 -Wall
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement
-D__XEN_TOOLS__ -D_LARGEFILE_SOURCE
Alex Williamson wrote:
On Mon, 2006-11-27 at 16:45 +0100, Jes Sorensen wrote:
Alex Williamson wrote:
Sorry I haven't really been able to test this on ZX1 before posting the
patches. I tried to add all the stuff I thought was needed.
Are the patches known to work on DIG? That would narrow
Alex Williamson wrote:
Ok, the first problem was actually pretty easy, the hp directory
under arch/ia64 wasn't getting built. Now I get to here:
(XEN) Time init:
(XEN) System Time: 38776ns
(XEN) scale: 281426057
(XEN) Boot processor id 0x0/0x0
(XEN)
SUZUKI Kazuhiro wrote:
Hi Jes,
I tried this and attached the output below. I was wondering why we
seem to allocate pages to MCA handlers on 64 processors even if we
only boot 8, but thats a detail.
It's OK. The mca_data is allocated up to NR_CPUS(=64) in MCA
initialization routine.
Alex Williamson wrote:
On Fri, 2006-11-24 at 17:28 +0100, Jes Sorensen wrote:
Ok, it seems we're seeing major operator error here. This time it should
be there - otherwise please shoot me :(
Hi Jes,
I tried a quick boot test, but never got any console output on an HP
box. It seemed
Alex Williamson wrote:
Sorry I haven't really been able to test this on ZX1 before posting the
patches. I tried to add all the stuff I thought was needed.
Are the patches known to work on DIG? That would narrow the
debugging quite a bit. Unless we start adding IOMMU support, the zx1
SUZUKI Kazuhiro wrote:
Hi Jes,
Thanks for your information. But I could not find the cause of
error though I checked your boot log. Please build and test in MCA
debug mode which is enabled to define IA64_MCA_DEBUG_INFO in
xen/arch/ia64/linux-xen/mca.c.
Hi Kaz,
I tried this and
Kazuhiro == SUZUKI Kazuhiro [EMAIL PROTECTED] writes:
+#ifndef XEN
static struct timer_list cpe_poll_timer;
static struct timer_list cmc_poll_timer;
+#else /* XEN */
+static struct timer cpe_poll_timer;
+static struct timer cmc_poll_timer;
+#endif
Hi Kazuhiro,
Any chance we
Tristan == Tristan Gingold [EMAIL PROTECTED] writes:
Tristan I think UINT64 and BOOLEAN should be reserved for ACPI. We'd
Tristan better to remove all UNIT64 and BOOLEAN in xen ia64 code.
Tristan That's just my opinion but we can do this cleanup later.
That one gets my vote too :) We should
Tristan Gingold wrote:
Le Mardi 26 Septembre 2006 10:24, Jes Sorensen a écrit :
Hmmm, so why did it make no difference whether I changed those
addresses?
This is not an early crash. Xen boots rather far before crashing.
Any idea if there's some hard coded places that I need to track down
Tristan Gingold wrote:
Changing the physical loading address shouldn't that hard.
I'd suggest you *not* working on relocation yet.
Hi Tristan,
Changing the address for loading works, except that our machines are not
all the same and I'd have to set it individually for each one. I'd
rather
Tristan Gingold wrote:
Changing the address for loading works, except that our machines are not
all the same and I'd have to set it individually for each one. I'd
rather start looking at the relocation so we get an infrastructure for
that sorted.
Ok, so this is more urgent that I previously
Alex Williamson wrote:
On Tue, 2006-09-26 at 17:04 +0200, Jes Sorensen wrote:
Hi,
This is a small speedup, but I think it's a good thing to dotm.
Hi Jes,
Looks good to me, but this needs to go to xen-devel since it's common
code. Thanks,
Hi Alex,
There's still something else
Hi,
This is a small speedup, but I think it's a good thing to dotm.
Jes
Small speedup for the boot allocator to avoid it scanning through a
space which is known to be empty.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 7b250cf49e50 xen/common/page_alloc.c
--- a/xen/common
Tristan Gingold wrote:
Le Vendredi 22 Septembre 2006 15:16, Jes Sorensen a écrit :
Hi Kouya,
Thank you for your suggestion - I tried making this change, but it made
no difference at all. I think elilo relocates it or something like that,
otherwise we would have the same problem with the Linux
1 - 100 of 112 matches
Mail list logo
