UP IO-APIC fix in 2.4.22-pre?

Hi,

I was just wondering about the bugfix for UP IO-APIC that is in 2.4-ac and that went into 2.5:

http://linux.bkbits.net:8080/linux-2.5/[email protected]

Will it make it into 2.4.22? From what I understand this fixes the following problem that many of us are seeing:

hda: dma_timer_expiry: dma status == 0x24
hda: lost interrupt
hda: dma_intr: bad DMA status (dma_stat=30)
hda: dma_intr: status=0x50 { DriveReady SeekComplete }

this is on a Via chipset ATA133 capable board with 2 ATA133 Western Digital drives in a raid1 configuration. kernel is 2.4.21 patched ACPI and UP-APIC enabled.

lspci -v output:

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 3189 (rev 80)
Subsystem: Giga-byte Technology: Unknown device 5000
Flags: bus master, 66Mhz, medium devsel, latency 176 Memory at e0000000 (32-bit, prefetchable) [size=128M]
Capabilities: [80] AGP version 3.5
Capabilities: [c0] Power Management version 2

00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device b198 (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Capabilities: [80] Power Management version 2

00:09.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 08)
Subsystem: Creative Labs CT4832 SBLive! Value
Flags: bus master, medium devsel, latency 248, IRQ 17 I/O ports at d000 [size=32]
Capabilities: [dc] Power Management version 1

00:09.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 08)
Subsystem: Creative Labs Gameport Joystick
Flags: bus master, medium devsel, latency 176
I/O ports at d400 [size=8]
Capabilities: [dc] Power Management version 1

00:0b.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 54) (prog-if 00 [VGA])
Flags: medium devsel, IRQ 19
Memory at e8000000 (32-bit, non-prefetchable) [size=64M]
Expansion ROM at <unassigned> [disabled] [size=64K]

00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI])
Subsystem: Giga-byte Technology: Unknown device 5004
Flags: bus master, medium devsel, latency 176, IRQ 7
I/O ports at d800 [size=32]
Capabilities: [80] Power Management version 2

00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI])
Subsystem: Giga-byte Technology: Unknown device 5004
Flags: bus master, medium devsel, latency 176, IRQ 12
I/O ports at dc00 [size=32]
Capabilities: [80] Power Management version 2

00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI])
Subsystem: Giga-byte Technology: Unknown device 5004
Flags: bus master, medium devsel, latency 176, IRQ 11
I/O ports at e000 [size=32]
Capabilities: [80] Power Management version 2

00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
Subsystem: Giga-byte Technology: Unknown device 5001
Flags: bus master, stepping, medium devsel, latency 0
Capabilities: [c0] Power Management version 2

00:11.1 IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: Giga-byte Technology: Unknown device 5002
Flags: bus master, medium devsel, latency 176, IRQ 255
I/O ports at e400 [size=16]
Capabilities: [c0] Power Management version 2

00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio Controller (rev 50)
Subsystem: Giga-byte Technology: Unknown device a002
Flags: medium devsel, IRQ 11
I/O ports at e800 [size=256]
Capabilities: [c0] Power Management version 2

00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 176, IRQ 18
I/O ports at ec00 [size=256]
Memory at ed001000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2

thanks.

-m

On Thursday 31 July 2003 02:28, Marc Heckmann wrote:

Hi Marc,

I sent it to Marcelo yesterday. In the meantime you might want to try out the attached patch ontop of 2.4.22-pre9 and see if it fixes the problems for you.

ciao, Marc

@@ -1343,6 +1343,25 @@ static void clear_IO_APIC (void)
 
 static void mask_and_ack_level_ioapic_irq (unsigned int irq) { /* nothing */ }
 
+#ifndef CONFIG_SMP
+
+void send_IPI_self(int vector)
+{
+	unsigned int cfg;
+
+	/*
+	 * Wait for idle.
+	 */
+	apic_wait_icr_idle();
+	cfg = APIC_DM_FIXED | APIC_DEST_SELF | vector | APIC_DEST_LOGICAL;
+	/*
+	 * Send the IPI. The write to APIC_ICR fires this off.
+	 */
+	apic_write_around(APIC_ICR, cfg);
+}
+
+#endif /* CONFIG_SMP */
+
 static void set_ioapic_affinity (unsigned int irq, unsigned long mask)
 {
 	unsigned long flags;

@@ -13,8 +13,10 @@
  */
 
 #include <linux/config.h>
+#include <linux/smp_lock.h>
 #include <asm/atomic.h>
 #include <asm/irq.h>
+#include <asm/current.h>
 
 /*
  * IDT vectors usable for external interrupt sources start

@@ -213,7 +215,7 @@
 	atomic_inc((atomic_t *)&prof_buffer[eip]);
 }
 
-#ifdef CONFIG_SMP /*more of this file should probably be ifdefed SMP */
+#if defined(CONFIG_X86_IO_APIC)
 static inline void hw_resend_irq(struct hw_interrupt_type *h, unsigned int i) {
 	if (IO_APIC_IRQ(i))
 		send_IPI_self(IO_APIC_VECTOR(i));

Marc,

I just applied that patch in the 2.4 BK tree.

-pre10 will be release today with it included.

hi,

ok, I'll give it a spin and let you know.

Cheers,

-m

On Thursday 31 July 2003 17:26, Marcelo Tosatti wrote:

Hi Marcelo,

perfect :) ... Thank you.

ciao, Marc

hi,

the patch solves the bug for me.

-m