Re: Latest xen-unstable on IBM x440

Re: Latest xen-unstable on IBM x440

[Arun Sharma]

Nakajima, Jun wrote:

>>The point was that without specifying acpi=force, XenLinux will not
>>boot.  XenLinux can not find a root filesystem.  Scsi devices are not
>>properly detected.   It is my hope that this can be used as a
>>datapoint to aid in determining the work which still needs to be done
>>so that one day XenLinux will run on machines as easily and as well
>>as Linux does.
> 
> 
> Arun's patch allows one to set "acpi=force" for dom0 xenlinux, fulling
> enabbling ACPI in dom0 up to the level where the native Linux supports.
> What's missing there is to fall back to MPS, which is required for
> "acpi=ht".

Parsing the MPS table is working now on my machine, but interrupts are 
still not getting routed. I'm probably a couple of bug fixes away from 
getting acpi=off/ht to work.

	-Arun

Re: Latest xen-unstable on IBM x440

[Arun Sharma]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

Arun Sharma wrote:

> Parsing the MPS table is working now on my machine, but interrupts are 
> still not getting routed. I'm probably a couple of bug fixes away from 
> getting acpi=off/ht to work.
> 

People having trouble with the PCI/IOAPIC patch, could you give this 
patch a try?

It works with acpi=off and acpi=ht on my machine.

	-Arun

PS: PCI initialization is sensitive to the order of object files within 
the Makefile. I think that's a bit fragile...

[-- Attachment #2: acpi-off.patch --]
[-- Type: text/plain, Size: 5352 bytes --]

===== arch/xen/i386/Kconfig 1.21 vs edited =====
--- 1.21/linux-2.6.11-xen-sparse/arch/xen/i386/Kconfig	2005-05-03 07:27:52 -07:00
+++ edited/arch/xen/i386/Kconfig	2005-05-04 14:11:59 -07:00
@@ -961,7 +961,7 @@
 config X86_FIND_SMP_CONFIG
 	bool
 	depends on X86_LOCAL_APIC || X86_VOYAGER
-	default n
+	default y
 
 config X86_MPPARSE
 	bool
===== arch/xen/i386/kernel/apic.c 1.1 vs edited =====
--- 1.1/linux-2.6.11-xen-sparse/arch/xen/i386/kernel/apic.c	2005-05-03 07:27:53 -07:00
+++ edited/arch/xen/i386/kernel/apic.c	2005-05-04 18:14:58 -07:00
@@ -49,5 +49,11 @@
  */
 int __init APIC_init_uniprocessor (void)
 {
+#ifdef CONFIG_X86_IO_APIC
+        extern int smp_found_config;
+	if (smp_found_config)
+                /* Xen assumes IO_APIC */
+		setup_IO_APIC();
+#endif
 	return 0;
 }
===== arch/xen/i386/kernel/io_apic.c 1.1 vs edited =====
--- 1.1/linux-2.6.11-xen-sparse/arch/xen/i386/kernel/io_apic.c	2005-05-03 07:27:53 -07:00
+++ edited/arch/xen/i386/kernel/io_apic.c	2005-05-04 15:29:07 -07:00
@@ -108,6 +108,23 @@
 }
 
 /*
+ *
+ * IRQ's that are handled by the PIC in the MPS IOAPIC case.
+ * - IRQ2 is the cascade IRQ, and cannot be a io-apic IRQ.
+ *   Linux doesn't really care, as it's not actually used
+ *   for any interrupt handling anyway.
+ */
+#define PIC_IRQS	(1 << PIC_CASCADE_IR)
+
+void __init setup_IO_APIC(void)
+{
+	if (acpi_ioapic)
+		io_apic_irqs = ~0;	/* all IRQs go through IOAPIC */
+	else
+		io_apic_irqs = ~PIC_IRQS;
+} 
+
+/*
  * The common case is 1:1 IRQ<->pin mappings. Sometimes there are
  * shared ISA-space IRQs, so we have to support them. We are super
  * fast in the common case, and fast for shared ISA-space IRQs.
===== arch/xen/i386/kernel/mpparse.c 1.2 vs edited =====
--- 1.2/linux-2.6.11-xen-sparse/arch/xen/i386/kernel/mpparse.c	2005-05-03 10:44:11 -07:00
+++ edited/arch/xen/i386/kernel/mpparse.c	2005-05-05 13:06:16 -07:00
@@ -429,9 +429,7 @@
 			{
 				struct mpc_config_processor *m=
 					(struct mpc_config_processor *)mpt;
-				/* ACPI may have already provided this data */
-				if (!acpi_lapic)
-					MP_processor_info(m);
+				/* We ignore the processors in the MP table */
 				mpt += sizeof(*m);
 				count += sizeof(*m);
 				break;
@@ -482,9 +480,8 @@
 		++mpc_record;
 	}
 	clustered_apic_check();
-	if (!num_processors)
-		printk(KERN_ERR "SMP mptable: no processors registered!\n");
-	return num_processors;
+        num_processors = 1; /* Doesn't really matter */
+	return 1;
 }
 
 static int __init ELCR_trigger(unsigned int irq)
@@ -690,7 +687,7 @@
 		 * Read the physical hardware table.  Anything here will
 		 * override the defaults.
 		 */
-		if (!smp_read_mpc((void *)mpf->mpf_physptr)) {
+		if (!smp_read_mpc((void *)isa_bus_to_virt(mpf->mpf_physptr))) {
 			smp_found_config = 0;
 			printk(KERN_ERR "BIOS bug, MP table errors detected!...\n");
 			printk(KERN_ERR "... disabling SMP support. (tell your hw vendor)\n");
@@ -726,6 +723,7 @@
 static int __init smp_scan_config (unsigned long base, unsigned long length)
 {
 	unsigned long *bp = isa_bus_to_virt(base);
+        unsigned long isa_bus_off = ((unsigned long) bp) - base;
 	struct intel_mp_floating *mpf;
 
 	Dprintk("Scan SMP from %p for %ld bytes.\n", bp,length);
@@ -742,8 +740,7 @@
 
 			smp_found_config = 1;
 			printk(KERN_INFO "found SMP MP-table at %08lx\n",
-						virt_to_phys(mpf));
-			reserve_bootmem(virt_to_phys(mpf), PAGE_SIZE);
+						mpf - isa_bus_off);
 			if (mpf->mpf_physptr) {
 				/*
 				 * We cannot access to MPC table to compute
@@ -758,7 +755,6 @@
 				unsigned long end = max_low_pfn * PAGE_SIZE;
 				if (mpf->mpf_physptr + size > end)
 					size = end - mpf->mpf_physptr;
-				reserve_bootmem(mpf->mpf_physptr, size);
 			}
 
 			mpf_found = mpf;
===== arch/xen/i386/kernel/setup.c 1.45 vs edited =====
--- 1.45/linux-2.6.11-xen-sparse/arch/xen/i386/kernel/setup.c	2005-05-03 10:44:11 -07:00
+++ edited/arch/xen/i386/kernel/setup.c	2005-05-04 14:12:33 -07:00
@@ -1133,13 +1133,6 @@
 	 */
 	acpi_reserve_bootmem();
 #endif
-#ifdef CONFIG_X86_FIND_SMP_CONFIG
-	/*
-	 * Find and reserve possible boot-time SMP configuration:
-	 */
-	find_smp_config();
-#endif
-
 #ifdef CONFIG_BLK_DEV_INITRD
 	if (xen_start_info.mod_start) {
 		if (INITRD_START + INITRD_SIZE <= (max_low_pfn << PAGE_SHIFT)) {
@@ -1566,6 +1559,12 @@
 	if (efi_enabled)
 		efi_map_memmap();
 
+#ifdef CONFIG_X86_FIND_SMP_CONFIG
+	/*
+	 * Find and reserve possible boot-time SMP configuration:
+	 */
+	find_smp_config();
+#endif
 	/*
 	 * Parse the ACPI tables for possible boot-time SMP configuration.
 	 */
===== arch/xen/i386/pci/Makefile 1.9 vs edited =====
--- 1.9/linux-2.6.11-xen-sparse/arch/xen/i386/pci/Makefile	2005-05-03 10:24:40 -07:00
+++ edited/arch/xen/i386/pci/Makefile	2005-05-05 13:01:01 -07:00
@@ -10,8 +10,7 @@
 
 c-pci-y				:= fixup.o
 c-pci-$(CONFIG_ACPI_PCI)	+= acpi.o
-c-pci-y				+= legacy.o
-pci-y				+= irq.o
+c-pci-y				+= legacy.o irq.o
 
 c-pci-$(CONFIG_X86_VISWS)	:= visws.o fixup.o
 pci-$(CONFIG_X86_VISWS)		:=
===== arch/xen/i386/pci/irq.c 1.15 vs edited =====
--- 1.15/linux-2.6.11-xen-sparse/arch/xen/i386/pci/irq.c	2005-05-03 07:27:52 -07:00
+++ edited/arch/xen/i386/pci/irq.c	2005-05-05 13:07:25 -07:00
@@ -21,8 +21,6 @@
 
 #include "pci.h"
 
-#define DBG printk
-
 #define PIRQ_SIGNATURE	(('$' << 0) + ('P' << 8) + ('I' << 16) + ('R' << 24))
 #define PIRQ_VERSION 0x0100
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Latest xen-unstable on IBM x440

[Nakajima, Jun]

Natasha Jarymowycz wrote:
> On Wed, 4 May 2005 12:06:40 -0700, Nakajima, Jun
> <jun.nakajima@intel.com> wrote:
> 
> 
>> My point is that it looks like the keyboard is broken now, and it has
>> nothing to do with ACPI (PCI interrupt routing) if it's PS/2. The
>> plan for acpi=off is to use PIC mode, which is not desirable for a
>> server like IBM x440.
> 
> Perhaps I oversimplified by saying "the keyboard doesn't work".  The
> keyboard is actually attached to an RCM connected via ethernet to the
> x440.  However, that was not really the point.
> 
> The point was that without specifying acpi=force, XenLinux will not
> boot.  XenLinux can not find a root filesystem.  Scsi devices are not
> properly detected.   It is my hope that this can be used as a
> datapoint to aid in determining the work which still needs to be done
> so that one day XenLinux will run on machines as easily and as well
> as Linux does.

Arun's patch allows one to set "acpi=force" for dom0 xenlinux, fulling
enabbling ACPI in dom0 up to the level where the native Linux supports.
What's missing there is to fall back to MPS, which is required for
"acpi=ht".

Jun
 
> 
> Natasha

RE: Latest xen-unstable on IBM x440

[Nakajima, Jun]

Keir Fraser wrote:
> On 4 May 2005, at 19:00, Nakajima, Jun wrote:
> 
>> As far as I remember, acpi=ht and acpi=off means different things.
>> What IBM x440 requires is "acpi=ht", which uses ACPI tables to get
>> logical CPUs (for HT), and uses MPS to get PCI interrupt routing
>> info. 
> 
> For interrupt routing, which is what breaks, I think it is equivalent
> to acpi=off. We've fixed quite a few issues with the patch already,
> but haven't yet dug into apic.c and io_apic.c -- I think those two
> are the key to successfully booting non-acpi. I don't think it will
> be that tricky either -- mostly a case of carefully adding back code
> that was removed because it isn't used when using ACPI for irq
> routing. 

My point is that it looks like the keyboard is broken now, and it has
nothing to do with ACPI (PCI interrupt routing) if it's PS/2. The plan
for acpi=off is to use PIC mode, which is not desirable for a server
like IBM x440.

Jun

> 
>   -- Keir

Re: Latest xen-unstable on IBM x440

[Natasha Jarymowycz]

On Wed, 4 May 2005 12:06:40 -0700, Nakajima, Jun <jun.nakajima@intel.com>  
wrote:


> My point is that it looks like the keyboard is broken now, and it has
> nothing to do with ACPI (PCI interrupt routing) if it's PS/2. The plan
> for acpi=off is to use PIC mode, which is not desirable for a server
> like IBM x440.

Perhaps I oversimplified by saying "the keyboard doesn't work".  The
keyboard is actually attached to an RCM connected via ethernet to the
x440.  However, that was not really the point.

The point was that without specifying acpi=force, XenLinux will not
boot.  XenLinux can not find a root filesystem.  Scsi devices are not
properly detected.   It is my hope that this can be used as a datapoint
to aid in determining the work which still needs to be done so that one
day XenLinux will run on machines as easily and as well as Linux does.

Natasha

Re: Latest xen-unstable on IBM x440

[Keir Fraser]

On 4 May 2005, at 20:06, Nakajima, Jun wrote:

> My point is that it looks like the keyboard is broken now, and it has
> nothing to do with ACPI (PCI interrupt routing) if it's PS/2. The plan
> for acpi=off is to use PIC mode, which is not desirable for a server
> like IBM x440.

We need to fall back to default 'IO-APIC' mode, or we are going to suck 
on non-ACPI servers (plenty exist, even if they are somewhat legacy 
these days).

  -- Keir

RE: Latest xen-unstable on IBM x440

[Nakajima, Jun]

Natasha Jarymowycz wrote:
> The IBM eserver x440 is one of the machines which Linux forces
> to run with acpi=ht.  This doesn't work with Xen, presumably
> because "acpi=off to support machines with broken or no acpi support"
> is functionality not yet provided.  If I boot with acpi=force,
> I can make it through the full boot sequence but the keyboard
> doesn't work though I can log in over the net.  If I don't boot
> with acpi=force then Linux can't find a root fs under Xen.
> 
> I have two questions:
> 1. When will acpi=off support be added to Xen?

As far as I remember, acpi=ht and acpi=off means different things. What
IBM x440 requires is "acpi=ht", which uses ACPI tables to get logical
CPUs (for HT), and uses MPS to get PCI interrupt routing info. 

> 2. Does anyone have suggestions for ways to work around this
> problem to get as much functionality as possible?

I think the right thing is to get the keyboard (or maybe BIOS) fixed. Is
that USB keyboard or PS/2 keyboard connected to a USB port? Probably SMI
is happening there. 

Jun

> 
> 
> --Natasha
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Latest xen-unstable on IBM x440

[Keir Fraser]

On 4 May 2005, at 19:00, Nakajima, Jun wrote:

> As far as I remember, acpi=ht and acpi=off means different things. What
> IBM x440 requires is "acpi=ht", which uses ACPI tables to get logical
> CPUs (for HT), and uses MPS to get PCI interrupt routing info.

For interrupt routing, which is what breaks, I think it is equivalent 
to acpi=off. We've fixed quite a few issues with the patch already, but 
haven't yet dug into apic.c and io_apic.c -- I think those two are the 
key to successfully booting non-acpi. I don't think it will be that 
tricky either -- mostly a case of carefully adding back code that was 
removed because it isn't used when using ACPI for irq routing.

  -- Keir

Latest xen-unstable on IBM x440

[Natasha Jarymowycz]

The IBM eserver x440 is one of the machines which Linux forces
to run with acpi=ht.  This doesn't work with Xen, presumably
because "acpi=off to support machines with broken or no acpi support"
is functionality not yet provided.  If I boot with acpi=force,
I can make it through the full boot sequence but the keyboard
doesn't work though I can log in over the net.  If I don't boot
with acpi=force then Linux can't find a root fs under Xen.

I have two questions:
1. When will acpi=off support be added to Xen?
2. Does anyone have suggestions for ways to work around this
problem to get as much functionality as possible?


--Natasha

Re: Latest xen-unstable on IBM x440

[Keir Fraser]

On 4 May 2005, at 18:17, Natasha Jarymowycz wrote:

> 1. When will acpi=off support be added to Xen?

We're working on it, but it's likely to be a few days at least.

> 2. Does anyone have suggestions for ways to work around this
> problem to get as much functionality as possible?

Not sure there is any easy workaround. Linux's apic.c and io_apic.c 
have been stripped down more than they ought to have been in the 
process of getting acpi working: we need to work out what functionality 
needs to be re-added to get acpi=off working.

  -- Keir

Re: Latest xen-unstable on IBM x440

[Natasha Jarymowycz]

>> 1. When will acpi=off support be added to Xen?
>
> We're working on it, but it's likely to be a few days at least.

Great.  I just wanted to hear that it was days and not weeks
or months.

> Not sure there is any easy workaround. Linux's apic.c and io_apic.c have  
> been stripped down more than they ought to have been in the process of  
> getting acpi working: we need to work out what functionality needs to be  
> re-added to get acpi=off working.

Thanks, I'll wait patiently.  If you have some changes and would like
them tested, I'd be happy to run them on the x440.

-Natasha