[Xen-ia64-devel] [patch] calculate dom0 metaphysical load address correctly
Hi,
This one is needed to handle system where metaphysical doesn't start
at 0x400.
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1179838406 -7200
# Node ID ce09d8e7f7334cda03f26e2493398f3cface8060
# Parent 44a59dc866263af3c33ade323d9fb5fb0451c8cd
Calculate load address 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 2007 +0200
+++ b/xen/arch/ia64/xen/domain.cTue May 22 14:53:26 2007 +0200
@@ -1109,7 +1109,8 @@ int shadow_mode_control(struct domain *d
#defineprivify_memory(x,y) do {} while(0)
#endif
-static void loaddomainelfimage(struct domain *d, struct elf_binary *elf)
+static void loaddomainelfimage(struct domain *d, struct elf_binary *elf,
+ unsigned long phys_load_offset)
{
const elf_phdr *phdr;
int phnum, h, filesz, memsz;
@@ -1126,6 +1127,7 @@ static void loaddomainelfimage(struct do
memsz = elf_uval(elf, phdr, p_memsz);
elfaddr = (unsigned long) elf-image + elf_uval(elf, phdr,
p_offset);
dom_mpaddr = elf_uval(elf, phdr, p_paddr);
+ dom_mpaddr += phys_load_offset;
while (memsz 0) {
p = assign_new_domain_page(d,dom_mpaddr);
@@ -1216,6 +1218,7 @@ int construct_dom0(struct domain *d,
unsigned long pkern_end;
unsigned long pinitrd_start = 0;
unsigned long pstart_info;
+ unsigned long phys_load_offset;
struct page_info *start_info_page;
unsigned long bp_mpa;
struct ia64_boot_param *bp;
@@ -1243,6 +1246,20 @@ int construct_dom0(struct domain *d,
if (0 != (elf_xen_parse(elf, parms)))
return rc;
+ /*
+* We cannot rely on the load address in the ELF headers to
+* determine the meta physical address the image is loaded
+* at since meta physical memory needs to match physical
+* memory of the system for NUMA awareness. Patch the address
+* to match the real one, based on xen_pstart
+*/
+ phys_load_offset = xen_pstart - elf.pstart;
+ elf.pstart += phys_load_offset;
+ elf.pend += phys_load_offset;
+ parms.virt_kstart += phys_load_offset;
+ parms.virt_kend += phys_load_offset;
+ parms.virt_entry += phys_load_offset;
+
printk( Dom0 kernel: %s, %s, paddr 0x% PRIx64 - 0x% PRIx64 \n,
elf_64bit(elf) ? 64-bit : 32-bit,
elf_msb(elf) ? msb: lsb,
@@ -1273,8 +1290,10 @@ int construct_dom0(struct domain *d,
/* The next page aligned boundary after the start info.
Note: EFI_PAGE_SHIFT = 12 = PAGE_SHIFT */
pinitrd_start = pstart_info + PAGE_SIZE;
- if (pinitrd_start + initrd_len = dom0_size)
+
+ if ((pinitrd_start + initrd_len - phys_load_offset) = dom0_size)
panic(%s: not enough memory assigned to dom0, __func__);
+
for (offset = 0; offset initrd_len; offset += PAGE_SIZE) {
struct page_info *p;
p = assign_new_domain_page(d, pinitrd_start + offset);
@@ -1327,7 +1346,7 @@ int construct_dom0(struct domain *d,
panic(Cannot allocate dom0 vcpu %d\n, i);
/* Copy the OS image. */
- loaddomainelfimage(d,elf);
+ loaddomainelfimage(d, elf, phys_load_offset);
BUILD_BUG_ON(sizeof(start_info_t) + sizeof(dom0_vga_console_info_t) +
sizeof(struct ia64_boot_param) PAGE_SIZE);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] emulate more SN2 SAL calls
Hi,
We need some more SAL calls emulated on SN2.
Cheers,
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1179839290 -7200
# Node ID a00f130f36c7e182494d0fdf0aaf2206bdfb3a6e
# Parent ce09d8e7f7334cda03f26e2493398f3cface8060
A few extra SN SAL calls that needs to be emulated to get 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 Tue May 22 15:08:10 2007 +0200
@@ -23,6 +23,7 @@
#include asm/pal.h
#include asm/sal.h
#include asm/sn/sn_sal.h
+#include asm/sn/hubdev.h
#include asm/xenmca.h
#include public/sched.h
@@ -380,7 +381,7 @@ sal_emulator (long index, unsigned long
case SN_SAL_GET_MASTER_NASID:
status = -1;
if (current-domain == dom0) {
- printk(*** Emulating SN_SAL_GET_MASTER_NASID ***\n);
+ /* printk(*** Emulating SN_SAL_GET_MASTER_NASID
***\n); */
SAL_CALL_NOLOCK(ret_stuff, SN_SAL_GET_MASTER_NASID,
0, 0, 0, 0, 0, 0, 0);
status = ret_stuff.status;
@@ -392,7 +393,7 @@ sal_emulator (long index, unsigned long
case SN_SAL_GET_KLCONFIG_ADDR:
status = -1;
if (current-domain == dom0) {
- printk(*** Emulating SN_SAL_GET_KLCONFIG_ADDR ***\n);
+ /* printk(*** Emulating SN_SAL_GET_KLCONFIG_ADDR
***\n); */
SAL_CALL_NOLOCK(ret_stuff, SN_SAL_GET_KLCONFIG_ADDR,
in1, 0, 0, 0, 0, 0, 0);
status = ret_stuff.status;
@@ -404,9 +405,9 @@ sal_emulator (long index, unsigned long
case SN_SAL_GET_SAPIC_INFO:
status = -1;
if (current-domain == dom0) {
- printk(*** Emulating SN_SAL_GET_SAPIC_INFO ***\n);
- SAL_CALL_NOLOCK(ret_stuff, SN_SAL_GET_SAPIC_INFO, in1,
- 0, 0, 0, 0, 0, 0);
+ /* printk(*** Emulating SN_SAL_GET_SAPIC_INFO ***\n);
*/
+ SAL_CALL_NOLOCK(ret_stuff, SN_SAL_GET_SAPIC_INFO,
+ in1, 0, 0, 0, 0, 0, 0);
status = ret_stuff.status;
r9 = ret_stuff.v0;
r10 = ret_stuff.v1;
@@ -416,9 +417,9 @@ sal_emulator (long index, unsigned long
case SN_SAL_GET_SN_INFO:
status = -1;
if (current-domain == dom0) {
- printk(*** Emulating SN_SAL_GET_SN_INFO ***\n);
- SAL_CALL_NOLOCK(ret_stuff, SN_SAL_GET_SN_INFO, in1,
- 0, 0, 0, 0, 0, 0);
+ /* printk(*** Emulating SN_SAL_GET_SN_INFO ***\n); */
+ SAL_CALL_NOLOCK(ret_stuff, SN_SAL_GET_SN_INFO,
+ in1, 0, 0, 0, 0, 0, 0);
status = ret_stuff.status;
r9 = ret_stuff.v0;
r10 = ret_stuff.v1;
@@ -428,9 +429,120 @@ sal_emulator (long index, unsigned long
case SN_SAL_IOIF_GET_HUBDEV_INFO:
status = -1;
if (current-domain == dom0) {
- printk(*** Emulating SN_SAL_IOIF_GET_HUBDEV_INFO
***\n);
+ /* printk(*** Emulating SN_SAL_IOIF_GET_HUBDEV_INFO
***\n); */
SAL_CALL_NOLOCK(ret_stuff, SN_SAL_IOIF_GET_HUBDEV_INFO,
in1, in2, 0, 0, 0, 0, 0);
+ status = ret_stuff.status;
+ r9 = ret_stuff.v0;
+ r10 = ret_stuff.v1;
+ r11 = ret_stuff.v2;
+ }
+ break;
+ case SN_SAL_IOIF_INIT:
+ status = -1;
+ if (current-domain == dom0) {
+ /* printk(*** Emulating SN_SAL_IOIF_INIT ***\n); */
+ SAL_CALL_NOLOCK(ret_stuff, SN_SAL_IOIF_INIT,
+ 0, 0, 0, 0, 0, 0, 0);
+ status = ret_stuff.status;
+ r9 = ret_stuff.v0;
+ r10 = ret_stuff.v1;
+ r11 = ret_stuff.v2;
+ }
+ break;
+ case SN_SAL_GET_PROM_FEATURE_SET:
+ status = -1;
+ if (current-domain == dom0) {
+ /* printk(*** Emulating SN_SAL_GET_PROM_FEATURE_SET
***\n); */
+ SAL_CALL_NOLOCK(ret_stuff, SN_SAL_GET_PROM_FEATURE_SET,
+ in1, 0, 0, 0, 0, 0, 0);
+ status =
[Xen-ia64-devel] [patch] SN2 polling console driver
Hi,
First cut at adding polling input support to the SN2 console driver.
This is slow, but it works.
Jes
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1179847015 -7200
# Node ID 7cb47b607563bb356dad2a2fb1555bc261076f94
# Parent a00f130f36c7e182494d0fdf0aaf2206bdfb3a6e
First cut 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/sn_console.cTue May 22 15:08:10 2007 +0200
+++ b/xen/arch/ia64/xen/sn_console.cTue May 22 17:16:55 2007 +0200
@@ -8,18 +8,83 @@
#include asm/acpi.h
#include asm/sn/sn_sal.h
#include xen/serial.h
+#include xen/sched.h
+
+struct sn_console_data {
+ struct timer timer;
+ unsigned int timeout_ms;
+ int booted;
+};
+
+static struct sn_console_data console_data = {
+ .timeout_ms = 8 * 16 * 1000 / 9600,
+};
+
/*
* sn_putc - Send a character to the console, polled or interrupt mode
*/
static void sn_putc(struct serial_port *port, char c)
{
- ia64_sn_console_putc(c);
+ struct sn_console_data *sndata = port-uart;
+
+ if (sndata-booted)
+ ia64_sn_console_putb(c, 1);
+ else
+ ia64_sn_console_putc(c);
}
+/*
+ * sn_getc - Get a character from the console, polled or interrupt mode
+ */
+static int sn_getc(struct serial_port *port, char *pc)
+{
+ int ch;
+
+ ia64_sn_console_getc(ch);
+ *pc = ch 0xff;
+ return 1;
+}
+
+static void sn_endboot(struct serial_port *port)
+{
+ struct sn_console_data *sndata = port-uart;
+
+ sndata-booted = 1;
+}
+
+
+static void sn_poll(void *data)
+{
+ int ch, status;
+ struct serial_port *port = data;
+ struct sn_console_data *sndata = port-uart;
+ struct cpu_user_regs *regs = guest_cpu_user_regs();
+
+ status = ia64_sn_console_check(ch);
+ if (!status ch) {
+ serial_rx_interrupt(port, regs);
+ }
+ set_timer(sndata-timer, NOW() + MILLISECS(sndata-timeout_ms));
+}
+
+
+static void sn_init_postirq(struct serial_port *port)
+{
+ struct sn_console_data *sndata = port-uart;
+
+init_timer(sndata-timer, sn_poll, port, 0);
+set_timer(sndata-timer, NOW() + MILLISECS(console_data.timeout_ms));
+}
+
+
static struct uart_driver sn_sal_console = {
+ .init_postirq = sn_init_postirq,
.putc = sn_putc,
+ .getc = sn_getc,
+ .endboot = sn_endboot,
};
+
/**
* early_sn_setup - early setup routine for SN platforms
@@ -45,8 +110,7 @@ static void __init early_sn_setup(void)
efi_systab = (efi_system_table_t *) __va(ia64_boot_param-efi_systab);
config_tables = __va(efi_systab-tables);
for (i = 0; i efi_systab-nr_tables; i++) {
- if (efi_guidcmp(config_tables[i].guid, SAL_SYSTEM_TABLE_GUID) ==
- 0) {
+ if (!efi_guidcmp(config_tables[i].guid, SAL_SYSTEM_TABLE_GUID))
{
sal_systab = __va(config_tables[i].table);
p = (char *)(sal_systab + 1);
for (j = 0; j sal_systab-entry_count; j++) {
@@ -73,11 +137,11 @@ static void __init early_sn_setup(void)
*/
int __init sn_serial_console_early_setup(void)
{
- if (strcmp(sn2,acpi_get_sysname()))
+ if (strcmp(sn2, acpi_get_sysname()))
return -1;
early_sn_setup(); /* Find SAL entry points */
- serial_register_uart(0, sn_sal_console, NULL);
+ serial_register_uart(0, sn_sal_console, console_data);
return 0;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] free initmem and add __init and __initdata.
On Tue, 2007-05-22 at 12:27 +0900, Isaku Yamahata wrote:
On Mon, May 21, 2007 at 04:46:13PM -0600, Alex Williamson wrote:
I tried removing all the __inits and __initdatas this patch added, but
it still happens, so I'd guess we need something that upstream marked as
init. Thanks,
Thank you for testing.
I attached the updated patch. The diff from the previous one is as follows.
diff -r b2b0289b0575 -r be593e2059de xen/arch/ia64/xen/xensetup.c
--- a/xen/arch/ia64/xen/xensetup.c Mon May 21 16:48:44 2007 +0900
+++ b/xen/arch/ia64/xen/xensetup.c Tue May 22 12:07:48 2007 +0900
@@ -242,7 +242,7 @@ md_overlaps(efi_memory_desc_t *md, unsig
#define MD_SIZE(md) (md-num_pages EFI_PAGE_SHIFT)
-static void init_done(void)
+static void noinline init_done(void)
{
extern char __init_begin[], __init_end[];
init_xenheap_pages(__pa(__init_begin), __pa(__init_end));
Hi Isaku,
Good thought, but I still hit the same problem. Note that dom0 boots
fine, but hits the BUG trying to boot a domU. I am running a newer gcc:
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
I'll put the __init/__initdata declarations in, but leave the actual
freeing disabled until we can track this down. Thanks,
Alex
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch] emulate more SN2 SAL calls
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, ia64_mv.oem_sal_emulator? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 14/14] memmap: allow huge size efi memory map of real machine
On Thu, 2007-05-17 at 19:43 +0900, Isaku Yamahata wrote: 14 / 14 Hi Isaku, I'm having some troubles with this one. It works fine on my main test system, but on another system, that also does not exceed the available 64 entry MDT, it fails to boot xen. I found this bug: diff -r 23fde14d35b5 xen/arch/ia64/xen/dom_fw_utils.c --- a/xen/arch/ia64/xen/dom_fw_utils.c Mon May 21 14:30:09 2007 -0600 +++ b/xen/arch/ia64/xen/dom_fw_utils.c Tue May 22 16:36:53 2007 -0600 @@ -280,17 +280,17 @@ dom_fw_setup(domain_t *d, unsigned long fw_tables_size = sizeof(*fw_tables) + fw_tables-num_mds * sizeof(fw_tables-efi_memmap[0]); +/* copy fw_tables into domain pseudo physical address space */ +for (gpaddr = FW_TABLES_BASE_PADDR; + gpaddr fw_tables-fw_end_paddr; + gpaddr += PAGE_SIZE) +assign_new_domain_page_if_dom0(d, gpaddr); + /* clear domain builder internal use member */ fw_tables-fw_tables_size = 0; fw_tables-fw_end_paddr = 0; fw_tables-fw_tables_end_paddr = 0; fw_tables-num_mds = 0; - -/* copy fw_tables into domain pseudo physical address space */ -for (gpaddr = FW_TABLES_BASE_PADDR; - gpaddr fw_tables-fw_end_paddr; - gpaddr += PAGE_SIZE) -assign_new_domain_page_if_dom0(d, gpaddr); dom_fw_copy_to(d, FW_TABLES_BASE_PADDR, fw_tables, fw_tables_size); xfree(fw_tables); Even with that fix, my system hangs at the xfree(fw_tables) call near the end of this chunk. If I skip that xfree(), we hang at the next call to xfree. Looks like we corrupted memory somewhere, but I haven't found it yet. Also, this looks a little strange to me: +/* estimate necessary efi memmap size and allocate memory for it */ +fw_tables_size = sizeof(*fw_tables) + +NUM_MEM_DESCS * sizeof(fw_tables-efi_memmap[0]) + +ia64_boot_param-efi_memdesc_size; Shouldn't this be something like: fw_tables_size = sizeof(*fw_tables) + ((ia64_boot_param-efi_memmap_size / ia64_boot_param-efi_memdesc_size) + NUM_MEM_DESCS) * sizeof(fw_tables-efi_memmap[0]); 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 in the MDT provided by firmware. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] complie qestion about open source GFW
Hi Tristan: From EDK2 buildnotes.txt, I get below info: A Word on gcc for Processor Architectures Currently gcc support is limited to IA-32 builds, generating IA-32 PE32 images. The X64 bit (Intel 64, etc.) support under the gcc compiler does not support the EFIAPI calling convention (as defined in the UEFI 2.0 specification Chapter 2), so it is not possible to build a working EFI image for an X64 environment. Since the x64 gcc does not support the EFIAPI calling convention the x64 tools do not support generating a PE32+ image. The EFIAPI calling convention is very similar to the Microsoft x64 calling convention. We have added prelinary support for the MinGW64 Tool chain. This gcc tool chain is ported to follow the Microsft X64 ABI, and therefore is compatible with the EFI specification. On Itanium?Processors the gcc compiler does not support generating a PE32+ image. Seems gcc of IA64 can not produce the image. So which complier do you use? I use gcc4.1.1 but still broke during compiling time. Hope you answer. Thx:-) Good good study,day day up ! ^_^ -Wing(zhang xin) OTC,Intel Corporation ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] fix ld.s emulation
Hi,
With this patch,
* XEN correctly emulates ld.s for HVM
* original memory attribute is preserved in vcpu-arch.vtlb
Without this, XEN infrequently calls panic_domain() by mistake for windows.
Thanks,
Kouya
Signed-off-by: Kouya Shimura [EMAIL PROTECTED]
Signed-off-by: Akio Takebe [EMAIL PROTECTED]
diff -r ac28ee0ee098 xen/arch/ia64/vmx/vmx_process.c
--- a/xen/arch/ia64/vmx/vmx_process.c Wed May 16 11:38:48 2007 -0600
+++ b/xen/arch/ia64/vmx/vmx_process.c Wed May 23 10:17:24 2007 +0900
@@ -311,6 +311,8 @@ vmx_hpw_miss(u64 vadr , u64 vec, REGS* r
if(is_physical_mode(v)(!(vadr162))){
if(vec==2){
+if (misr.sp) /* Refer to SDM Vol2 Table 4-11,4-12 */
+return vmx_handle_lds(regs);
if (v-domain != dom0
__gpfn_is_io(v-domain, (vadr 1) (PAGE_SHIFT + 1))) {
emulate_io_inst(v,((vadr1)1),4); // UC
@@ -324,9 +326,16 @@ try_again:
try_again:
if((data=vtlb_lookup(v, vadr,type))!=0){
if (v-domain != dom0 type == DSIDE_TLB) {
+if (misr.sp) { /* Refer to SDM Vol2 Table 4-10,4-12 */
+if ((data-ma == VA_MATTR_UC) || (data-ma == VA_MATTR_UCE))
+return vmx_handle_lds(regs);
+}
gppa = (vadr ((1UL data-ps) - 1)) +
(data-ppn (data-ps - 12) data-ps);
if (__gpfn_is_io(v-domain, gppa PAGE_SHIFT)) {
+if (misr.sp)
+panic_domain(NULL, ld.s on I/O page not with UC attr.
+ pte=0x%lx\n, data-page_flags);
if (data-pl = ((regs-cr_ipsr IA64_PSR_CPL0_BIT) 3))
emulate_io_inst(v, gppa, data-ma);
else {
diff -r ac28ee0ee098 xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Wed May 16 11:38:48 2007 -0600
+++ b/xen/arch/ia64/vmx/vtlb.c Tue May 22 21:42:39 2007 +0900
@@ -507,6 +507,13 @@ u64 translate_phy_pte(VCPU *v, u64 *pte,
*pte |= VTLB_PTE_IO;
return -1;
}
+/* Ensure WB attribute if pte is related to a normal mem page,
+ * which is required by vga acceleration since qemu maps shared
+ * vram buffer with WB.
+ */
+if (phy_pte.ma != VA_MATTR_NATPAGE)
+phy_pte.ma = VA_MATTR_WB;
+
//rr.rrval = ia64_get_rr(va);
//ps = rr.ps;
maddr = ((maddr _PAGE_PPN_MASK) PAGE_MASK) | (paddr ~PAGE_MASK);
@@ -530,17 +537,8 @@ int thash_purge_and_insert(VCPU *v, u64
vcpu_get_rr(current, ifa, vrr.rrval);
mrr.rrval = ia64_get_rr(ifa);
if(VMX_DOMAIN(v)){
-
phy_pte = translate_phy_pte(v, pte, itir, ifa);
-/* Ensure WB attribute if pte is related to a normal mem page,
- * which is required by vga acceleration since qemu maps shared
- * vram buffer with WB.
- */
-if (!(pte VTLB_PTE_IO) ((pte _PAGE_MA_MASK) != _PAGE_MA_NAT)) {
-pte = ~_PAGE_MA_MASK;
-phy_pte = ~_PAGE_MA_MASK;
-}
if (pte VTLB_PTE_IO)
ret = 1;
vtlb_purge(v, ifa, ps);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Serial woes with kexec on an HP RX2620
Hi, I've been trying to hunt down a problem with the serial console on the HP RX2620, whereby after kexec the console doesn't accept input, although it does produce output quite happily. I should also note that this problem does not manifest on the Tiger2 machine I have. I've been puzzling over this for a while now, and it seems like no RX interrupts are generated. Though I can't fathom why. If I force the serial driver into polling mode (with some handy #if 0 work) then everything is fine - well as fine as a polling driver can be. I have tried comparing the serial setup in the xen and linux drivers, however the implementation is quite different, making comparisons difficult at best. I have tried seeing which of the many work arounds contained in the linux driver are activated when it is used, however it seems that the answer is none, or in other words, the linux driver doesn't seem to do anything sepcial. I'll continue looking over this, but if anyone has any ideas I would be most grateful. For reference, I am using the following kexec for ia64 on xen patches (largely written by myself) http://www.vergenet.net/linux/kexec/ia64-xen/20070417/ -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Serial woes with kexec on an HP RX2620
On Wed, 2007-05-23 at 12:49 +0900, Simon Horman wrote: Hi, I've been trying to hunt down a problem with the serial console on the HP RX2620, whereby after kexec the console doesn't accept input, although it does produce output quite happily. I should also note that this problem does not manifest on the Tiger2 machine I have. Hi Simon, Are you using the serial console on the management processor or the one off the motherboard? (if the MP, ctrl-b does something, otherwise esc-( and esc-) do something) All the HP boxes setup their console in Xen through efi_setup_pcdp_console(). You likely wouldn't be getting console output if you weren't getting there at all, but perhaps something is going wrong setting up the IRQ. The MP console is a PCI UART and will use the generic interrupt polarity triggers, while the motherboard UART is special cased in pcdp_hp_irq_fixup(). The HP system will require a working IOSAPIC for the interrupt whereas the Tiger might make due with some kind of legacy interrupt routing. Since the IOSAPICs aren't enumerated till later, the interrupt isn't setup till fairly late in start_kernel(). If you're trying to get input before that, it won't work. Hopefully you can trace through those paths and find something missing. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Serial woes with kexec on an HP RX2620
On Tue, May 22, 2007 at 10:28:13PM -0600, Alex Williamson wrote: On Wed, 2007-05-23 at 12:49 +0900, Simon Horman wrote: Hi, I've been trying to hunt down a problem with the serial console on the HP RX2620, whereby after kexec the console doesn't accept input, although it does produce output quite happily. I should also note that this problem does not manifest on the Tiger2 machine I have. Hi Simon, Are you using the serial console on the management processor or the one off the motherboard? (if the MP, ctrl-b does something, otherwise esc-( and esc-) do something) All the HP boxes setup their console in Xen through efi_setup_pcdp_console(). You likely wouldn't be getting console output if you weren't getting there at all, but perhaps something is going wrong setting up the IRQ. The MP console is a PCI UART and will use the generic interrupt polarity triggers, while the motherboard UART is special cased in pcdp_hp_irq_fixup(). The HP system will require a working IOSAPIC for the interrupt whereas the Tiger might make due with some kind of legacy interrupt routing. Since the IOSAPICs aren't enumerated till later, the interrupt isn't setup till fairly late in start_kernel(). If you're trying to get input before that, it won't work. Hopefully you can trace through those paths and find something missing. Thanks, Hi Alex, thanks for the ideas, I'll see what I can find :-) -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Serial woes with kexec on an HP RX2620
Hi, Horms After kexec, what kernel do you use? Xen or linux kernel? I think you don't call iosapic_register_intr(), arguments of iosapic_register_intr() are wrong. Can you check that efi.hcdp is passed to second kernel properly? FYI In the case of xen, HP machine call the following functions. efi_setup_pcdp_console() setup_serial_console() setup_pcdp_irq() pcdp_hp_irq_fixup() And iosapic_register_intr() is called in start_kernel(). Best Regards, Akio Takebe ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Serial woes with kexec on an HP RX2620
On Wed, May 23, 2007 at 01:36:45PM +0900, Akio Takebe wrote: Hi, Horms Hi Takebe-san, After kexec, what kernel do you use? Xen or linux kernel? I am going from Xen to Xen I think you don't call iosapic_register_intr(), arguments of iosapic_register_intr() are wrong. Can you check that efi.hcdp is passed to second kernel properly? I will check. FYI In the case of xen, HP machine call the following functions. efi_setup_pcdp_console() setup_serial_console() setup_pcdp_irq() pcdp_hp_irq_fixup() And iosapic_register_intr() is called in start_kernel(). -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
