Re: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch

[Yinghai Lu]

the patch is good.

I tried LinuxBIOS with kexec.

without this patch: I need to disable acpi in kernel. otherwise the
kernel with acpi support can boot the second kernel, but the second
kernel will hang after

time.c: Using 14.318180 MHz HPET timer.
time.c: Detected 2197.663 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )

YH

On 1/2/06, Vivek Goyal  wrote:
> Hi Andi,
>
> Can you please include the following patch. This patch has already been pushed
> by Andrew.
>
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15...
>
> This patch is regarding remembering at boot up time where i8259 is connected
> and restore the APIC settings back during kexec boot or kdump boot. This
> enables getting timer interrupts in new kernel in legacy mode.
>
> This patch is needed to make kexec and kdump work on some systems,
> especially opteron boxes. Otherwise the second kernel does not receive
> timer interrupts during early boot hence hangs.
>
> I understand, that you are inclined towards remembering all the APIC states
> and simply restore it back instead of putting hooks. This will work
> well for kexec but not for kdump because in kdump system can crash on
> non-boot cpu.
>
> Restoring BIOS APIC state can make sure that BIOS designated boot cpu will
> always be able to see timer interrupts in legacy mode but same does not
> hold good if new kernel boots on some other cpu as is the case with kdump.
>
> In case of kexec boot, we relocate to boot cpu but in case of kdump we
> don't because it was suggested that in some extreme cases of crash, boot cpu
> might not respond even to NMI and relocation to boot cpu will not be
> possible.
>
> Can you please re-consider this patch for inclusion.
>
> Thanks
> Vivek
>
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch

[Andrew Morton]

Yinghai Lu  wrote:
> the patch is good.
>
> I tried LinuxBIOS with kexec.
>
> without this patch: I need to disable acpi in kernel. otherwise the
> kernel with acpi support can boot the second kernel, but the second
> kernel will hang after
>
> time.c: Using 14.318180 MHz HPET timer.
> time.c: Detected 2197.663 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )

Please don't top-post.
> On 1/2/06, Vivek Goyal  wrote:
> > Hi Andi,
> >
> > Can you please include the following patch. This patch has already been pushed
> > by Andrew.
> >
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15...

IIRC, I dropped this patch because of discouraging noises from Andi and
because underlying x86_64 changes broke it in ugly ways.  It needs to be
redone and Andi's objections (whatever they were) need to be addressed or
argued about.

Right now the patch is rather dead.

[LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch

[Vivek Goyal]

On Thu, Jan 05, 2006 at 04:38:48PM -0800, Andrew Morton wrote:
> Yinghai Lu  wrote:
> > the patch is good.
> >
> > I tried LinuxBIOS with kexec.
> >
> > without this patch: I need to disable acpi in kernel. otherwise the
> > kernel with acpi support can boot the second kernel, but the second
> > kernel will hang after
> >
> > time.c: Using 14.318180 MHz HPET timer.
> > time.c: Detected 2197.663 MHz processor.
> > Console: colour VGA+ 80x25
> > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> > Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> > Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )
>
> Please don't top-post.
> > On 1/2/06, Vivek Goyal  wrote:
> > > Hi Andi,
> > >
> > > Can you please include the following patch. This patch has already been pushed
> > > by Andrew.
> > >
> > > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15...
>
> IIRC, I dropped this patch because of discouraging noises from Andi and
> because underlying x86_64 changes broke it in ugly ways.  It needs to be
> redone and Andi's objections (whatever they were) need to be addressed or
> argued about.

Andrew, as per my information this patch has not broken anything. It was
other patch which tried to initialize ioapics early which had broken some
sysmtems and that patch has already been dropped.

Andi's main concern with this patch is that it has got special case
knowledge of 8259 and legacy stuff. He would rather prefer, saving all the
APIC states early during boot and restore it back during reboot.

This shall work well for kexec but will not work for kdump as we might
crash on a non-boot cpu and second kernel will come up on a non-boot cpu.
Just restoring the APIC states shall ensure that kernel can boot well on
BIOS designated boot cpu but it does not hold good for other cpus. One
example is that other cpus will not receive timer interrupts during early
boot.

Hence there does not seem to be any escape route except relocate
to boot cpu after crash and second kernel comes up on BIOS designated
boot cpu. But after crash relocating to boot cpu might not be a very
reliable thing to do.

Thanks
Vivek

[LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch

Andrew Morton  writes:
> Please don't top-post.
> > On 1/2/06, Vivek Goyal  wrote:
> > > Hi Andi,
> > >
> > > Can you please include the following patch. This patch has already been
>
> pushed
> > > by Andrew.
>
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15...
>
> IIRC, I dropped this patch because of discouraging noises from Andi and
> because underlying x86_64 changes broke it in ugly ways.

Ok.  I just as extensively as I could and I can't find the under laying
x86_64 changes that Andi mentioned he was working on.  I have looked
in current -mm and in Andi merge and experimental quilt trees.  It
could be that I'm  blind but I looked and I did not see them.

Even in the discussion where this was mentioned there never was a 
semantic conflict.  But rather two patches passing so close they
touched the same or neighboring lines of code.
> It needs to be
> redone and Andi's objections (whatever they were) need to be addressed or
> argued about.

The difference was one of approach.  Andi wanted us to treat the apics
as black boxes and save and restore register values with no regard as
to what the registers did.  This is theoretically more future proof,
but it looses flexibility.

My approach is to treat the apics as something we understand, and
simply save off the one small piece of information from the boot
time state that we can't discover any other way.

The x86_64-ioapic-virtual-wire-mode-fix.patch in 2.6.15-mm1 actually
takes advantage of the fact we understand what the apics are doing
to change the destination cpu, in the kexec on panic case.  This
is something that cannot be done if we simply saved off the registers.
> Right now the patch is rather dead.

Current the referred to patch applies just fine, to 2.6.15,
and except for a conflict with the above mentioned patch which
applies fine to 2.6.15-mm1 as well.

Putting the apics in a state where we can use them if fundamental
so to booting a kernel so this is something we need to resolve
if we want kexec to be usable.

A revived version of the patch that applies without patch
follows.

Eric

[LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch

[Andi Kleen]

On Fri, Jan 06, 2006 at 01:02:16AM -0700, Eric W. Biederman wrote:
> Andrew Morton  writes:
> > Please don't top-post.
> > > On 1/2/06, Vivek Goyal  wrote:
> > > > Hi Andi,
> > > >
> > > > Can you please include the following patch. This patch has already been
> >
> > pushed
> > > > by Andrew.
> >
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15...
> >
> > IIRC, I dropped this patch because of discouraging noises from Andi and
> > because underlying x86_64 changes broke it in ugly ways.
>
> Ok.  I just as extensively as I could and I can't find the under laying
> x86_64 changes that Andi mentioned he was working on.  I have looked
> in current -mm and in Andi merge and experimental quilt trees.  It
> could be that I'm  blind but I looked and I did not see them.
>
> Even in the discussion where this was mentioned there never was a 
> semantic conflict.  But rather two patches passing so close they
> touched the same or neighboring lines of code.
> > It needs to be
> > redone and Andi's objections (whatever they were) need to be addressed or
> > argued about.
>
> The difference was one of approach.  Andi wanted us to treat the apics
> as black boxes and save and restore register values with no regard as
> to what the registers did.  This is theoretically more future proof,
> but it looses flexibility.

Well I still think it would be better to do it in the generic way,
but i'm not feeling very strongly about it anymore.
> to change the destination cpu, in the kexec on panic case.  This
> is something that cannot be done if we simply saved off the registers.
> > Right now the patch is rather dead.
>
> Current the referred to patch applies just fine, to 2.6.15,
> and except for a conflict with the above mentioned patch which
> applies fine to 2.6.15-mm1 as well.

It conflicts with the x86-64 timer routing rewrite I did, but that's currently
on hold because it has some other issues.  I can merge them later, no problem.

-Andi

[LinuxBIOS] [PATCH] i386 io_apic: Use correct index variable when computing the apic that is in ExtInt mode.

Somehow in all of the chaos this one line bug fix got merged with
the another patch and was then discarded when issues were found
with that other patch.

From: Vivek Goyal

A minor fix to the patch which remembers the location of where i8259 is
  connected.  Now counter i has been replaced by apic.  counter i is having
  some junk value which was leading to non-detection of i8259 connected to
  IOAPIC.

---

arch/i386/kernel/io_apic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

b5a215b462de26a1e6c21f607677796f0bb446aa
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index 7554f8f..f2dd218 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -1649,7 +1649,7 @@ static void __init enable_IO_APIC(void)
    for(apic = 0; apic < nr_ioapics; apic++) {
    	int pin;
    	/* See if any of the pins is in ExtINT mode */
-		for(pin = 0; pin < nr_ioapic_registers[i]; pin++) {
+		for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
    		struct IO_APIC_route_entry entry;
    		spin_lock_irqsave(&ioapic_lock, flags);
    		*(((int *)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);

[LinuxBIOS] [PATCH] x86_64 io_apic: memorize at bootup where the i8259 is

Currently we attempt to restore virtual wire mode on reboot, which only
works if we can figure out where the i8259 is connected.  This is very
useful when we are kexec another kernel and likely helpful to an peculiar
BIOS that make assumptions about how the system is setup.

Since the acpi MADT table does not provide the location where the i8259 is
connected we have to look at the hardware to figure it out.

Most systems have the i8259 connected the local apic of the cpu so won't be
affected but people running Opteron and some serverworks chipsets should be
able to use kexec now.

In addition this patch removes the hard coded assumption that the io_apic
that delivers isa interrups is always known to the kernel as io_apic 0.
There does not appear to be anything to guarantee that assumption is true.

This patch does not do a blind save and restore of ioapci registers
as that looses the flexibility that is present when you understand what
the registers actually do.  Currently in the kexec on panic case we actually
use that flexibility to route interrupts all interrupts to the cpu we
are rebooting on.

---

arch/x86_64/kernel/io_apic.c |  143 ++++++++++++++++++++++++++++++++----------
 1 files changed, 108 insertions(+), 35 deletions(-)

6a51f08f75e2087c50d088c8af21fb98f0ae87a6
diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index ac7a273..de4ad4e 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -46,6 +46,9 @@ static int no_timer_check;

int disable_timer_pin_1 __initdata;

+/* Where if anywhere is the i8259 connect in external int mode */
+static struct { int pin, apic; } ioapic_i8259 = { -1, -1 };
+
 static DEFINE_SPINLOCK(ioapic_lock);

/*
@@ -360,7 +363,7 @@ static int find_irq_entry(int apic, int 
 /*
  * Find the pin to which IRQ[irq] (ISA) is connected
  */
-static int find_isa_irq_pin(int irq, int type)
+static int __init find_isa_irq_pin(int irq, int type)
 {
    int i;

@@ -378,6 +381,31 @@ static int find_isa_irq_pin(int irq, int
    return -1;
 }

+static int __init find_isa_irq_apic(int irq, int type)
+{
+	int i;
+
+	for (i = 0; i < mp_irq_entries; i++) {
+		int lbus = mp_irqs[i].mpc_srcbus;
+
+		if ((mp_bus_id_to_type[lbus] == MP_BUS_ISA ||
+		     mp_bus_id_to_type[lbus] == MP_BUS_EISA ||
+		     mp_bus_id_to_type[lbus] == MP_BUS_MCA) &&
+		    (mp_irqs[i].mpc_irqtype == type) &&
+		    (mp_irqs[i].mpc_srcbusirq == irq))
+			break;
+	}
+	if (i < mp_irq_entries) {
+		int apic;
+		for(apic = 0; apic < nr_ioapics; apic++) {
+			if (mp_ioapics[apic].mpc_apicid == mp_irqs[i].mpc_dstapic)
+				return apic;
+		}
+	}
+
+	return -1;
+}
+
 /*
  * Find a specific PCI IRQ entry.
  * Not an __init, possibly needed by modules
@@ -871,7 +899,7 @@ static void __init setup_IO_APIC_irqs(vo
  * Set up the 8259A-master output pin as broadcast to all
  * CPUs.
  */
-static void __init setup_ExtINT_IRQ0_pin(unsigned int pin, int vector)
+static void __init setup_ExtINT_IRQ0_pin(unsigned int apic, unsigned int pin, int vector)
 {
    struct IO_APIC_route_entry entry;
    unsigned long flags;
@@ -905,8 +933,8 @@ static void __init setup_ExtINT_IRQ0_pin
     * Add it to the IO-APIC irq-routing table:
     */
    spin_lock_irqsave(&ioapic_lock, flags);
-	io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1));
-	io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0));
+	io_apic_write(apic, 0x11+2*pin, *(((int *)&entry)+1));
+	io_apic_write(apic, 0x10+2*pin, *(((int *)&entry)+0));
    spin_unlock_irqrestore(&ioapic_lock, flags);

enable_8259A_irq(0);
@@ -1185,7 +1213,8 @@ void __apicdebuginit print_PIC(void)
 static void __init enable_IO_APIC(void)
 {
    union IO_APIC_reg_01 reg_01;
-	int i;
+	int i8259_apic, i8259_pin;
+	int i, apic;
    unsigned long flags;

for (i = 0; i < PIN_MAP_SIZE; i++) {
@@ -1199,11 +1228,48 @@ static void __init enable_IO_APIC(void)
    /*
     * The number of IO-APIC IRQ registers (== #pins):
     */
-	for (i = 0; i < nr_ioapics; i++) {
+	for (apic = 0; apic < nr_ioapics; apic++) {
    	spin_lock_irqsave(&ioapic_lock, flags);
-		reg_01.raw = io_apic_read(i, 1);
+		reg_01.raw = io_apic_read(apic, 1);
    	spin_unlock_irqrestore(&ioapic_lock, flags);
-		nr_ioapic_registers[i] = reg_01.bits.entries+1;
+		nr_ioapic_registers[apic] = reg_01.bits.entries+1;
+	}
+	for(apic = 0; apic < nr_ioapics; apic++) {
+		int pin;
+		/* See if any of the pins is in ExtINT mode */
+		for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
+			struct IO_APIC_route_entry entry;
+			spin_lock_irqsave(&ioapic_lock, flags);
+			*(((int *)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
+			*(((int *)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+			spin_unlock_irqrestore(&ioapic_lock, flags);
+
+
+			/* If the interrupt line is enabled and in ExtInt mode
+			 * I have found the pin where the i8259 is connected.
+			 */
+			if ((entry.mask == 0) && (entry.delivery_mode == dest_ExtINT)) {
+				ioapic_i8259.apic = apic;
+				ioapic_i8259.pin  = pin;
+				goto found_i8259;
+			}
+		}
+	}
+ found_i8259:
+	/* Look to see what if the MP table has reported the ExtINT */
+	i8259_pin  = find_isa_irq_pin(0, mp_ExtINT);
+	i8259_apic = find_isa_irq_apic(0, mp_ExtINT);
+	/* Trust the MP table if nothing is setup in the hardware */
+	if ((ioapic_i8259.pin == -1) && (i8259_pin >= 0)) {
+		printk(KERN_WARNING "ExtINT not setup in hardware but reported by MP table\n");
+		ioapic_i8259.pin  = i8259_pin;
+		ioapic_i8259.apic = i8259_apic;
+	}
+	/* Complain if the MP table and the hardware disagree */
+	if (((ioapic_i8259.apic != i8259_apic) || (ioapic_i8259.pin != i8259_pin)) &&
+		(i8259_pin >= 0) && (ioapic_i8259.pin >= 0))
+	{
+		printk(KERN_WARNING "ExtINT in hardware and MP table differ\n");
    }

/*
@@ -1217,7 +1283,6 @@ static void __init enable_IO_APIC(void)
  */
 void disable_IO_APIC(void)
 {
-	int pin;
    /*
     * Clear the IO-APIC before rebooting:
     */
@@ -1228,8 +1293,7 @@ void disable_IO_APIC(void)
     * Put that IOAPIC in virtual wire mode
     * so legacy interrupts can be delivered.
     */
-	pin = find_isa_irq_pin(0, mp_ExtINT);
-	if (pin != -1) {
+	if (ioapic_i8259.pin != -1) {
    	struct IO_APIC_route_entry entry;
    	unsigned long flags;

@@ -1240,7 +1304,7 @@ void disable_IO_APIC(void)
    	entry.polarity        = 0; /* High */
    	entry.delivery_status = 0;
    	entry.dest_mode       = 0; /* Physical */
-		entry.delivery_mode   = 7; /* ExtInt */
+		entry.delivery_mode   = dest_ExtINT; /* ExtInt */
    	entry.vector          = 0;
    	entry.dest.physical.physical_dest =
    				GET_APIC_ID(apic_read(APIC_ID));
@@ -1249,12 +1313,14 @@ void disable_IO_APIC(void)
    	 * Add it to the IO-APIC irq-routing table:
    	 */
    	spin_lock_irqsave(&ioapic_lock, flags);
-		io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1));
-		io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0));
+		io_apic_write(ioapic_i8259.apic, 0x11+2*ioapic_i8259.pin,
+			*(((int *)&entry)+1));
+		io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
+			*(((int *)&entry)+1));
    	spin_unlock_irqrestore(&ioapic_lock, flags);
    }

-	disconnect_bsp_APIC(pin != -1);
+	disconnect_bsp_APIC(ioapci_i8259.pin != -1);
 }

/*
@@ -1623,20 +1689,21 @@ static void setup_nmi (void)
  */
 static inline void unlock_ExtINT_logic(void)
 {
-	int pin, i;
+	int apic, pin, i;
    struct IO_APIC_route_entry entry0, entry1;
    unsigned char save_control, save_freq_select;
    unsigned long flags;

-	pin = find_isa_irq_pin(8, mp_INT);
+	pin  = find_isa_irq_pin(8, mp_INT);
+	apic = find_isa_irq_apic(8, mp_INT);
    if (pin == -1)
    	return;

spin_lock_irqsave(&ioapic_lock, flags);
-	*(((int *)&entry0) + 1) = io_apic_read(0, 0x11 + 2 * pin);
-	*(((int *)&entry0) + 0) = io_apic_read(0, 0x10 + 2 * pin);
+	*(((int *)&entry0) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+	*(((int *)&entry0) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
    spin_unlock_irqrestore(&ioapic_lock, flags);
-	clear_IO_APIC_pin(0, pin);
+	clear_IO_APIC_pin(apic, pin);

memset(&entry1, 0, sizeof(entry1));

@@ -1649,8 +1716,8 @@ static inline void unlock_ExtINT_logic(v
    entry1.vector = 0;

spin_lock_irqsave(&ioapic_lock, flags);
-	io_apic_write(0, 0x11 + 2 * pin, *(((int *)&entry1) + 1));
-	io_apic_write(0, 0x10 + 2 * pin, *(((int *)&entry1) + 0));
+	io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&entry1) + 1));
+	io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry1) + 0));
    spin_unlock_irqrestore(&ioapic_lock, flags);

save_control = CMOS_READ(RTC_CONTROL);
@@ -1668,11 +1735,11 @@ static inline void unlock_ExtINT_logic(v

CMOS_WRITE(save_control, RTC_CONTROL);
    CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
-	clear_IO_APIC_pin(0, pin);
+	clear_IO_APIC_pin(apic, pin);

spin_lock_irqsave(&ioapic_lock, flags);
-	io_apic_write(0, 0x11 + 2 * pin, *(((int *)&entry0) + 1));
-	io_apic_write(0, 0x10 + 2 * pin, *(((int *)&entry0) + 0));
+	io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&entry0) + 1));
+	io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry0) + 0));
    spin_unlock_irqrestore(&ioapic_lock, flags);
 }

@@ -1684,7 +1751,7 @@ static inline void unlock_ExtINT_logic(v
  */
 static inline void check_timer(void)
 {
-	int pin1, pin2;
+	int apic1, pin1, apic2, pin2;
    int vector;

/*
@@ -1705,10 +1772,13 @@ static inline void check_timer(void)
    init_8259A(1);
    enable_8259A_irq(0);

-	pin1 = find_isa_irq_pin(0, mp_INT);
-	pin2 = find_isa_irq_pin(0, mp_ExtINT);
+	pin1  = find_isa_irq_pin(0, mp_INT);
+	apic1 = find_isa_irq_apic(0, mp_INT);
+	pin2  = ioapic_i8259.pin;
+	apic2 = ioapic_i8259.apic;

-	apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X pin1=%d pin2=%d\n", vector, pin1, pin2);
+	apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n",
+		vector, apic1, pin1, apic2, pin2);

if (pin1 != -1) {
    	/*
@@ -1726,17 +1796,20 @@ static inline void check_timer(void)
    			clear_IO_APIC_pin(0, pin1);
    		return;
    	}
-		clear_IO_APIC_pin(0, pin1);
-		apic_printk(APIC_QUIET,KERN_ERR "..MP-BIOS bug: 8254 timer not connected to IO-APIC\n");
+		clear_IO_APIC_pin(apic1, pin1);
+		apic_printk(APIC_QUIET,KERN_ERR "..MP-BIOS bug: 8254 timer not "
+				"connected to IO-APIC\n");
    }

-	apic_printk(APIC_VERBOSE,KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
+	apic_printk(APIC_VERBOSE,KERN_INFO "...trying to set up timer (IRQ0) "
+				"through the 8259A ... ");
    if (pin2 != -1) {
-		apic_printk(APIC_VERBOSE,"\n..... (found pin %d) ...", pin2);
+		apic_printk(APIC_VERBOSE,"\n..... (found apic %d pin %d) ...",
+			apic2, pin2);
    	/*
    	 * legacy devices should be connected to IO APIC #0
    	 */
-		setup_ExtINT_IRQ0_pin(pin2, vector);
+		setup_ExtINT_IRQ0_pin(apic2, pin2, vector);
    	if (timer_irq_works()) {
    		printk("works.\n");
    		nmi_watchdog_default();
@@ -1748,7 +1821,7 @@ static inline void check_timer(void)
    	/*
    	 * Cleanup, just in case ...
    	 */
-		clear_IO_APIC_pin(0, pin2);
+		clear_IO_APIC_pin(apic2, pin2);
    }
    printk(" failed.\n");

[LinuxBIOS] [PATCH] x86_64 io_apic: memorize at bootup where the i8259 is

[Yinghai Lu]

On 1/6/06, Eric W. Biederman  wrote:
> @@ -1249,12 +1313,14 @@ void disable_IO_APIC(void)
>                * Add it to the IO-APIC irq-routing table:
>                */
>               spin_lock_irqsave(&ioapic_lock, flags);
>           io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1));
>           io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0));
>           io_apic_write(ioapic_i8259.apic, 0x11+2*ioapic_i8259.pin,
>                   *(((int *)&entry)+1));
>           io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
>                   *(((int *)&entry)+1));
>         spin_unlock_irqrestore(&ioapic_lock, flags);
> }
>
>   disconnect_bsp_APIC(pin != -1);
>   disconnect_bsp_APIC(ioapci_i8259.pin != -1);
>
> }

There is a typo

+               io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
+                       *(((int *)&entry)+1));

===>

+               io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
+                       *(((int *)&entry)+0));

YH

[LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch

Yinghai Lu  writes:
> the patch is good.
>
> I tried LinuxBIOS with kexec.
>
> without this patch: I need to disable acpi in kernel. otherwise the
> kernel with acpi support can boot the second kernel, but the second
> kernel will hang after
>
> time.c: Using 14.318180 MHz HPET timer.
> time.c: Detected 2197.663 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )

Yes. This is the reason the patch was written.  Every bios that
implements acpi has this problem.

Eric