Re: 2.6.20-rc3: known unfixed regressions - x86_64 boot failure: "IO-APIC + timer doesn't work"

Re: 2.6.20-rc3: known unfixed regressions - x86_64 boot failure: "IO-APIC + timer doesn't work"

[Yinghai Lu]

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

Please check the latest version. ( 01/02/2007)

YH

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: timer_01022007.diff --]
[-- Type: text/x-patch; name="timer_01022007.diff", Size: 8611 bytes --]

[PATCH] x86_64: check_timer with io apic setup before try_apic_pin

In the check_timer, it forget to set up the io apic before try_apic_pin for
timer. So add set_try_apic_pin to set up the io apic pin. otherwise the 
try_apic_pin will not work.

also add remove_irq_to_pin to corresponging to add_pin_to_irq to make irq_2_pin
more complete and make the set io apic more convenient.

Also add add_irq_entry in mparese.c to add apic/pin pair to mp_irqs in case 
some nvidia based MB have wrong io apic pin entry for timer. Some ck804 based 
MB, MPTABLE or ACPI assume timer is on ioapic pin2. but HW is set to pin0. or 
reversing case.

the check_timer will try 
1. apic1, pin1 with 8259 IRQ0 disabled
2. apic=0, pin=0 with 8259 IRQ0 disabled
3. apic=0, pin=2 with 8259 IRQ0 disabled
4. apic1, pin1 with 8259 IRQ0 enabled
5. apic2, pin2, pure 8259A routing on the 8259 as reported by BIOS

without the patch:
..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> .. failed
..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled<7>APIC error on CPU0: 00(40) .. failed
..TIMER: trying IO-APIC=0 PIN=2 fallback with 8259 IRQ0 disabled<3> .. failed
..TIMER: trying IO-APIC=0 PIN=0 8259A broadcast ExtINT from BIOS<7>number of MP IRQ sources: 84.
testing the IO APIC.......................


.................................... done.

with the patch:
..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> .. failed
..TIMER: trying IO-APIC=0 PIN=2 fallback with 8259 IRQ0 disabled<7>number of MP IRQ sources: 85.
testing the IO APIC.......................


.................................... done.                                     
 
cc: Andi Kleen <ak@suse.de>
cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Yinghai Lu <yinghai.lu@amd.com>

diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 2a1dcd5..e200d0a 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -273,10 +273,17 @@ static void add_pin_to_irq(unsigned int irq, int apic, int pin)
 	struct irq_pin_list *entry = irq_2_pin + irq;
 
 	BUG_ON(irq >= NR_IRQS);
-	while (entry->next)
+	while (entry->next) {
+		if (entry->apic == apic && entry->pin == pin) 
+			return;
+		if (entry->pin == -1) 
+			break;
 		entry = irq_2_pin + entry->next;
+	}
 
 	if (entry->pin != -1) {
+		if (entry->apic == apic && entry->pin == pin) 
+			return;
 		entry->next = first_free_entry;
 		entry = irq_2_pin + entry->next;
 		if (++first_free_entry >= PIN_MAP_SIZE)
@@ -286,6 +293,39 @@ static void add_pin_to_irq(unsigned int irq, int apic, int pin)
 	entry->pin = pin;
 }
 
+static void remove_pin_to_irq(unsigned int irq, int apic, int pin)
+{
+	struct irq_pin_list *entry = irq_2_pin + irq;
+	struct irq_pin_list *pri;
+	struct irq_pin_list *next;
+
+	BUG_ON(irq >= NR_IRQS);
+
+	for (;;) {
+		if (entry->apic == apic && entry->pin == pin) {
+			if(entry->next) {
+				next = irq_2_pin + entry->next;
+				entry->apic = next->apic;
+				entry->pin = next->pin;
+				entry->next = next->next;
+				next->apic = -1;
+				next->pin = -1;
+				next->next = 0;
+			} else {
+				entry->apic = -1;
+				entry->pin = -1;
+			}
+			return;
+		}
+		pri = entry;
+		if (pri->next) 
+			entry = irq_2_pin + pri->next;
+		else
+			break;
+	} 
+
+}
+
 
 #define DO_ACTION(name,R,ACTION, FINAL)					\
 									\
@@ -1570,6 +1610,22 @@ static inline void unlock_ExtINT_logic(void)
  * fanatically on his truly buggy board.
  */
 
+static void set_try_apic_pin(int apic, int pin, int type)
+{
+	int idx;
+	int irq = 0;
+	int bus = 0; /* MP_ISA_BUS */
+	int irqflag = 5; /* MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH */
+
+	idx = find_irq_entry(apic,pin,type);
+
+	if (idx == -1) 
+		idx = add_irq_entry(type, irqflag, bus, irq, apic, pin);
+
+	add_pin_to_irq(irq, apic, pin);
+	setup_IO_APIC_irq(apic, pin, idx, irq);
+}
+
 static int try_apic_pin(int apic, int pin, char *msg)
 {
 	apic_printk(APIC_VERBOSE, KERN_INFO
@@ -1588,7 +1644,7 @@ static int try_apic_pin(int apic, int pin, char *msg)
 		}
 		return 1;
 	}
-	clear_IO_APIC_pin(apic, pin);
+
 	apic_printk(APIC_QUIET, KERN_ERR " .. failed\n");
 	return 0;
 }
@@ -1599,6 +1655,7 @@ static void check_timer(void)
 	int apic1, pin1, apic2, pin2;
 	int vector;
 	cpumask_t mask;
+	int i;
 
 	/*
 	 * get/set the timer IRQ vector:
@@ -1621,33 +1678,60 @@ static void check_timer(void)
 	pin2  = ioapic_i8259.pin;
 	apic2 = ioapic_i8259.apic;
 
-	/* Do this first, otherwise we get double interrupts on ATI boards */
-	if ((pin1 != -1) && try_apic_pin(apic1, pin1,"with 8259 IRQ0 disabled"))
-		return;
+	apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n",
+		vector, apic1, pin1, apic2, pin2);
 
-	/* Now try again with IRQ0 8259A enabled.
-	   Assumes timer is on IO-APIC 0 ?!? */
-	enable_8259A_irq(0);
-	unmask_IO_APIC_irq(0);
-	if (try_apic_pin(apic1, pin1, "with 8259 IRQ0 enabled"))
-		return;
-	disable_8259A_irq(0);
+	if (pin1 != -1) {
+		/* Do this first, otherwise we get double interrupts on ATI boards */
+		/* set_try_apic_pin will call disable_8259A_irq */
+		set_try_apic_pin(apic1, pin1, mp_INT);
+		unmask_IO_APIC_irq(0);
+		if (try_apic_pin(apic1, pin1,"with 8259 IRQ0 disabled"))
+			return;
+
+		clear_IO_APIC_pin(apic1, pin1);
+		remove_pin_to_irq(0, apic1, pin1);
+	}
 
 	/* Always try pin0 and pin2 on APIC 0 to handle buggy timer overrides
 	   on Nvidia boards */
-	if (!(apic1 == 0 && pin1 == 0) &&
-	    try_apic_pin(0, 0, "fallback with 8259 IRQ0 disabled"))
-		return;
-	if (!(apic1 == 0 && pin1 == 2) &&
-	    try_apic_pin(0, 2, "fallback with 8259 IRQ0 disabled"))
-		return;
+	for (i = 0; i <= 2; i += 2) 
+	if (!(apic1 == 0 && pin1 == i)) {
+		/* set_try_apic_pin will call disable_8259A_irq */
+		set_try_apic_pin(0, i, mp_INT); 
+		unmask_IO_APIC_irq(0);
+		if (try_apic_pin(0, i, "fallback with 8259 IRQ0 disabled"))
+			return;
+
+		clear_IO_APIC_pin(0, i);
+		remove_pin_to_irq(0, 0, i);
+	}
+
+	if (pin1 != -1) {
+		/* set_try_apic_pin will call disable_8259A_irq */
+		set_try_apic_pin(apic1, pin1, mp_INT);
+		unmask_IO_APIC_irq(0);
+
+		/* Now try again with IRQ0 8259A enabled.
+		   Assumes timer is on IO-APIC 0 ?!? */
+		enable_8259A_irq(0);
+		if (try_apic_pin(apic1, pin1, "with 8259 IRQ0 enabled"))
+			return;
+		disable_8259A_irq(0);
+
+		clear_IO_APIC_pin(apic1, pin1);
+		remove_pin_to_irq(0, apic1, pin1);
+	}
 
 	/* Then try pure 8259A routing on the 8259 as reported by BIOS*/
-	enable_8259A_irq(0);
 	if (pin2 != -1) {
 		setup_ExtINT_IRQ0_pin(apic2, pin2, vector);
+		add_pin_to_irq(0, apic2, pin2);
+		enable_8259A_irq(0);
 		if (try_apic_pin(apic2,pin2,"8259A broadcast ExtINT from BIOS"))
 			return;
+		clear_IO_APIC_pin(apic2, pin2);
+		remove_pin_to_irq(0, apic2, pin2);
 	}
 
 	/* Tried all possibilities to go through the IO-APIC. Now come the
diff --git a/arch/x86_64/kernel/mpparse.c b/arch/x86_64/kernel/mpparse.c
index 0807256..5f7a95a 100644
--- a/arch/x86_64/kernel/mpparse.c
+++ b/arch/x86_64/kernel/mpparse.c
@@ -314,6 +314,34 @@ static int __init ELCR_trigger(unsigned int irq)
 	return (inb(port) >> (irq & 7)) & 1;
 }
 
+int add_irq_entry(int type, int irqflag, int bus, int irq, int apic, int pin)
+{
+	struct mpc_config_intsrc intsrc;
+	int idx;
+
+	intsrc.mpc_type = MP_INTSRC;
+	intsrc.mpc_irqflag = irqflag; /* conforming */
+	intsrc.mpc_srcbus = bus;
+	intsrc.mpc_dstapic = (apic != -1) ? mp_ioapics[apic].mpc_apicid: MP_APIC_ALL;
+
+	intsrc.mpc_irqtype = type;
+
+	intsrc.mpc_srcbusirq = irq;
+	intsrc.mpc_dstirq = pin;
+
+	mp_irqs [mp_irq_entries] = intsrc;
+	Dprintk("Int: type %d, pol %d, trig %d, bus %d,"
+		" IRQ %02x, APIC ID %x, APIC INT %02x\n",
+			intsrc.mpc_irqtype, intsrc.mpc_irqflag & 3,
+			(intsrc.mpc_irqflag >> 2) & 3, intsrc.mpc_srcbus,
+			intsrc.mpc_srcbusirq, intsrc.mpc_dstapic, intsrc.mpc_dstirq);
+	idx = mp_irq_entries;
+	if (++mp_irq_entries >= MAX_IRQ_SOURCES)
+		panic("Max # of irq sources exceeded!!\n");
+	return idx;
+
+}
+
 static void __init construct_default_ioirq_mptable(int mpc_default_type)
 {
 	struct mpc_config_intsrc intsrc;
diff --git a/include/asm-x86_64/mpspec.h b/include/asm-x86_64/mpspec.h
index 017fddb..1ddfd4d 100644
--- a/include/asm-x86_64/mpspec.h
+++ b/include/asm-x86_64/mpspec.h
@@ -165,6 +165,7 @@ extern int mp_bus_id_to_pci_bus [MAX_MP_BUSSES];
 extern unsigned int boot_cpu_physical_apicid;
 extern int smp_found_config;
 extern void find_smp_config (void);
+extern int add_irq_entry (int type, int irqflag, int bus, int irq, int apic, int pin);
 extern void get_smp_config (void);
 extern int nr_ioapics;
 extern unsigned char apic_version [MAX_APICS];

Re: 2.6.20-rc3: known unfixed regressions - x86_64 boot failure: "IO-APIC + timer doesn't work"

[Tobias Diedrich]

Yinghai Lu wrote:
> Please check the latest version. ( 01/02/2007)

Works for me, with both BIOS versions / routing variants.

patches/series:
patch-2.6.20-rc4
patch-2.6.19-rc3-nokmem
myconfig
ccache
timer_01022007.diff
hpet-quirk

dmesg diff:
--- dmesg-20070108-2.6.20-rc4-bios-0402	2007-01-08 01:51:57.000000000 +0100
+++ dmesg-20070108-2.6.20-rc4-bios-0609	2007-01-08 01:52:05.000000000 +0100
@@ -13,14 +13,15 @@
 Entering add_active_range(0, 0, 159) 0 entries of 256 used
 Entering add_active_range(0, 256, 261856) 1 entries of 256 used
 end_pfn_map = 1048576
-DMI 2.3 present.
-ACPI: RSDP (v000 Nvidia                                ) @ 0x00000000000f7ce0
-ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003fee3040
-ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003fee30c0
-ACPI: SSDT (v001 PTLTD  POWERNOW 0x00000001  LTP 0x00000001) @ 0x000000003feec2c0
-ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003feec400
-ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003feec200
-ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000
+DMI 2.4 present.
+ACPI: RSDP (v002 Nvidia                                ) @ 0x00000000000f7b70
+ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003fee30c0
+ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003feec5c0
+ACPI: SSDT (v001 PTLTD  POWERNOW 0x00000001  LTP 0x00000001) @ 0x000000003feec7c0
+ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x00000098) @ 0x000000003feec900
+ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003feec980
+ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003feec700
+ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x03000000) @ 0x0000000000000000
 Entering add_active_range(0, 0, 159) 0 entries of 256 used
 Entering add_active_range(0, 256, 261856) 1 entries of 256 used
 Zone PFN ranges:
@@ -37,8 +38,6 @@
   DMA32 zone: 3524 pages used for memmap
   DMA32 zone: 254236 pages, LIFO batch:31
   Normal zone: 0 pages used for memmap
-Nvidia board detected. Ignoring ACPI timer override.
-If you got timer trouble try acpi_use_timer_override
 ACPI: PM-Timer IO Port: 0x1008
 ACPI: Local APIC address 0xfee00000
 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
@@ -48,13 +47,17 @@
 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
 ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
 IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
+ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
 ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
+ACPI: IRQ0 used by override.
+ACPI: IRQ2 used by override.
 ACPI: IRQ9 used by override.
 ACPI: IRQ14 used by override.
 ACPI: IRQ15 used by override.
 Setting APIC routing to flat
+ACPI: HPET id: 0x10de8201 base: 0xfefff000
 Using ACPI (MADT) for SMP configuration information
 mapped APIC to ffffffffff5fd000 (        fee00000)
 mapped IOAPIC to ffffffffff5fc000 (00000000fec00000)
@@ -72,10 +75,8 @@
 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
 Initializing CPU#0
 PID hash table entries: 4096 (order: 12, 32768 bytes)
-trying to force-enable HPET
-HPET force-enabled at 0xfef00000
 time.c: Using 25.000000 MHz WALL HPET GTOD HPET/TSC timer.
-time.c: Detected 2009.512 MHz processor.
+time.c: Detected 2009.511 MHz processor.
 Console: colour VGA+ 80x60
 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
 Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
@@ -84,7 +85,7 @@
 Aperture too small (32 MB)
 No AGP bridge found
 Memory: 1025348k/1047424k available (3242k kernel code, 21444k reserved, 1470k data, 200k init)
-Calibrating delay using timer specific routine.. 4023.44 BogoMIPS (lpj=6703119)
+Calibrating delay using timer specific routine.. 4023.45 BogoMIPS (lpj=6703124)
 Mount-cache hash table entries: 256
 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
 CPU: L2 Cache: 512K (64 bytes/line)
@@ -95,11 +96,10 @@
 ESR value after enabling vector: 00000000, after 00000004
 ENABLING IO-APIC IRQs
 init IO_APIC IRQs
- IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
-..TIMER: vector=0x20 apic1=0 pin1=0 apic2=-1 pin2=-1
-..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> .. failed
-..TIMER: trying IO-APIC=0 PIN=2 fallback with 8259 IRQ0 disabled<6>Using local APIC timer interrupts.
-result 12559465
+ IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
+..TIMER: vector=0x20 apic1=0 pin1=2 apic2=-1 pin2=-1
+..TIMER: trying IO-APIC=0 PIN=2 with 8259 IRQ0 disabled<6>Using local APIC timer interrupts.
+result 12559463
 Detected 12.559 MHz APIC timer.
 testing NMI watchdog ... OK.
 NET: Registered protocol family 16
@@ -168,7 +168,7 @@
 usbcore: registered new device driver usb
 PCI: Using ACPI for IRQ routing
 PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
-number of MP IRQ sources: 16.
+number of MP IRQ sources: 15.
 number of IO-APIC #2 registers: 24.
 testing the IO APIC.......................
 
@@ -210,7 +210,6 @@
 IRQ to pin mappings:
 IRQ0 -> 0:2
 IRQ1 -> 0:1
-IRQ2 -> 0:2
 IRQ3 -> 0:3
 IRQ4 -> 0:4
 IRQ5 -> 0:5
@@ -225,7 +224,7 @@
 IRQ14 -> 0:14
 IRQ15 -> 0:15
 .................................... done.
-hpet0: at MMIO 0xfef00000, IRQs 2, 8, 31
+hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31
 hpet0: 3 32-bit timers, 25000000 Hz
 pnp: 00:01: ioport range 0x1000-0x107f could not be reserved
 pnp: 00:01: ioport range 0x1080-0x10ff has been reserved
@@ -312,9 +311,9 @@
 ACPI: Fan [FAN] (on)
 ACPI: Processor [CPU0] (supports 8 throttling states)
 ACPI: Getting cpuindex for acpiid 0x1
-ACPI: Thermal Zone [THRM] (28 C)
+ACPI: Thermal Zone [THRM] (24 C)
 Real Time Clock Driver v1.12ac
-hpet_acpi_add: no address or irqs in _CRS
+hpet_resources: 0xfefff000 is busy
 Linux agpgart interface v0.101 (c) Dave Jones
 loop: loaded (max 8 devices)
 tun: Universal TUN/TAP device driver, 1.6

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。

Re: 2.6.20-rc3: known unfixed regressions - x86_64 boot failure: "IO-APIC + timer doesn't work"

[Linus Torvalds]

On Mon, 8 Jan 2007, Tobias Diedrich wrote:
>
> Yinghai Lu wrote:
> > Please check the latest version. ( 01/02/2007)
> 
> Works for me, with both BIOS versions / routing variants.

Yinghai, Eric, can you please send me the latest version with 
 (a) explanations for the changelogs
 (b) sign-off's (and acks for Eric, please) on it..

Let's get this one off the table.

		Linus

[PATCH 1/4] x86_64 io_apic: Implement remove_pin_to_irq

[Eric W. Biederman]

To try different irq routing combinations so we can make an informed
guess as to how to route irqs when the BIOS gets it wrong we need
the ability to modify our irq routing data structures.

This adds remove_pin_to_irq which removes the mapping from and apic pin
to an irq.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/kernel/io_apic.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 2a1dcd5..7365f5f 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -286,6 +286,29 @@ static void add_pin_to_irq(unsigned int irq, int apic, int pin)
 	entry->pin = pin;
 }
 
+static void remove_pin_to_irq(unsigned int irq, int apic, int pin)
+{
+	struct irq_pin_list *entry = irq_2_pin + irq;
+
+	BUG_ON(irq >= NR_IRQS);
+
+	while (entry->next && ((entry->apic != apic) || (entry->pin != pin)))
+		entry = irq_2_pin + entry->next;
+
+	if (entry->pin == apic && entry->pin == pin) {
+		if (entry->next) {
+			struct irq_pin_list *next = irq_2_pin + entry->next;
+			*entry = *next;
+			next->pin = -1;
+			next->apic = -1;
+			next->next = 0;
+		} else {
+			entry->pin = -1;
+			entry->apic = -1;
+		}
+	}
+}
+
 
 #define DO_ACTION(name,R,ACTION, FINAL)					\
 									\
-- 
1.4.4.1.g278f

PATCH 2/4] x86_64 io_apic: Implement irq_from_pin

[Eric W. Biederman]

Another helper needed for guessing the routing of the timer
irq.

irq_from_pin looks at the irq_2_pin mapping and figures
out which irq is connected to a given apic and pin combination.

We need to know this to avoid guessing an apic pin that is already
in use by another irq.

Despite the nested loops this is O(N) walk through the irq_2_pin
data structure.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/kernel/io_apic.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 7365f5f..5ad210f 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -262,6 +262,20 @@ static void set_ioapic_affinity_irq(unsigned int irq, cpumask_t mask)
 }
 #endif
 
+static int irq_from_pin(int apic, int pin)
+{
+	int irq;
+	for (irq = 0; irq < NR_IRQS; irq++) {
+		struct irq_pin_list *entry = irq_2_pin + irq;
+		while (entry->next && ((entry->apic != apic) || (entry->pin != pin)))
+			entry = irq_2_pin + entry->next;
+
+		if ((entry->pin == pin) && (entry->apic == apic))
+			return irq;
+	}
+	return -1;
+}
+
 /*
  * 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
-- 
1.4.4.1.g278f

[PATCH 3/4] x86_64 io_apic: Implment update_irq0_entry

[Eric W. Biederman]

To guess different irq routing strategies for irq 0 we
need the ability to update our data structures to reflect
our guess.

update_irq0_entry updates the mp routing table information
to reflect our current guess as to the routing of the timer
irq.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/kernel/io_apic.c |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 5ad210f..1e68377 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -446,6 +446,37 @@ static int __init find_isa_irq_apic(int irq, int type)
 	return -1;
 }
 
+static int update_irq0_entry(int apic, int pin)
+{
+	int irq = 0;
+	int idx;
+	int isa_bus;
+
+	/* Figure out the isa bus, by convention it is bus 0,
+	 * but be prepared for someone being creative.
+	 */
+	for (isa_bus = 0; isa_bus < MAX_MP_BUSSES; isa_bus++)
+		if (test_bit(isa_bus, mp_bus_not_pci))
+			break;
+	if (isa_bus >= MAX_MP_BUSSES)
+		isa_bus = 0;
+
+	idx = find_irq_entry(apic, pin, mp_INT);
+	if (idx == -1) {
+		idx = mp_irq_entries;
+		if (++mp_irq_entries >= MAX_IRQ_SOURCES)
+			panic("MAX # of irq sources exceeded!!!\n");
+	}
+	mp_irqs[idx].mpc_type = MP_INTSRC;
+	mp_irqs[idx].mpc_irqtype = mp_INT;
+	mp_irqs[idx].mpc_irqflag = 0;	/* Use bus defaults */
+	mp_irqs[idx].mpc_srcbus = isa_bus;
+	mp_irqs[idx].mpc_srcbusirq = irq;
+	mp_irqs[idx].mpc_dstapic = mp_ioapics[apic].mpc_apicid;
+	mp_irqs[idx].mpc_dstirq = pin;
+	return idx;
+}
+
 /*
  * Find a specific PCI IRQ entry.
  * Not an __init, possibly needed by modules
-- 
1.4.4.1.g278f

[PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Eric W. Biederman]

To a large extent this reverts b026872601976f666bae77b609dc490d1834bf77
while still keeping to the spirits of it's goal, the ability to
make smart guesses about how the timer irq is routed when the BIOS
gets it wrong.

The code for testing timer routing of a normal apic pin and
and an ExtINT pin has been moved into functions to make the
code easier to read.

I have assumed that we don't want to enable anything with the i8259
unless we are in ExtINT mode.  Reading the patch log indicates
that this seems to be most if not all of the time.

Compared to the pre b026872601976f666bae77b609dc490d1834bf77 state
two heuristic guess have been added:
-  If we cannot make the BIOS supplied timer on an apic pin work we
   guess apic 0 pin 2. As that is the architectural default.
-  When that fails and the BIOS does not provided us with an ExtINT
   mapping we try apic 0 pin 0 as an ExtINT.

Compared to Andi's previous version:
- I do not turn on irq0 in the i8259 and see if the io_apic
  works.  It is not clear that is ever needed.
- I do not guess that irq0 is connected as an ordinary interrupt
  to ioapic 0 pin 0.  I can't see how misprogramming that pin will buy
  us anything especially as it worked as an ExtINT in my testing, on
  one of the Nvidia boards.
- I guess that ExtINT mode and thus irq0 trough the i8259 works
  through apic 0 pin 0.  As this is the architectural default.

By using the architectural defaults our guesses are as
safe as they can be and are likely to work in most of the
cases.  If this still leaves some people out in the cold
we can look at adding some more smart guesses, but my hunch
is that anything more needs to be chipset specific.

Yinghai Lu thanks for your contributions on the infrastructure
support.  While I did not use it directly I did look at your code
when double checking mine to see if looked correct.

Tobias.  I don't have a box with the problem yours does, and this
doesn't quite try any of the cases you have been asked to test
so could you please test this one?

I have tested this on an Nvidia board that reports that apic 0 pin 2
works when it does not and this code successfully programs apic 0 pin 0
into ExtINT mode.

I have not addressed the fact the code for local apic ExtINT guesses 
are a mess and appear to be broken.  That code appears to have been
that way for a long time and no one has seemed to care.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/kernel/io_apic.c |  164 +++++++++++++++++++++++++++++++-----------
 1 files changed, 123 insertions(+), 41 deletions(-)

diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 1e68377..4891959 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -1631,23 +1631,16 @@ static inline void unlock_ExtINT_logic(void)
 	spin_unlock_irqrestore(&ioapic_lock, flags);
 }
 
-/*
- * This code may look a bit paranoid, but it's supposed to cooperate with
- * a wide range of boards and BIOS bugs.  Fortunately only the timer IRQ
- * is so screwy.  Thanks to Brian Perkins for testing/hacking this beast
- * fanatically on his truly buggy board.
- */
-
-static int try_apic_pin(int apic, int pin, char *msg)
+static int do_check_timer_pin(int apic, int pin)
 {
-	apic_printk(APIC_VERBOSE, KERN_INFO
-		    "..TIMER: trying IO-APIC=%d PIN=%d %s",
-		    apic, pin, msg);
-
+	apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER trying IO-APIC=%d PIN=%d",
+			apic, pin);
 	/*
 	 * Ok, does IRQ0 through the IOAPIC work?
 	 */
+	unmask_IO_APIC_irq(0);
 	if (!no_timer_check && timer_irq_works()) {
+		apic_printk(APIC_VERBOSE, " .. success\n");
 		nmi_watchdog_default();
 		if (nmi_watchdog == NMI_IO_APIC) {
 			disable_8259A_irq(0);
@@ -1657,11 +1650,87 @@ static int try_apic_pin(int apic, int pin, char *msg)
 		return 1;
 	}
 	clear_IO_APIC_pin(apic, pin);
-	apic_printk(APIC_QUIET, KERN_ERR " .. failed\n");
+	remove_pin_to_irq(0, apic, pin);
+	apic_printk(APIC_VERBOSE, KERN_ERR " .. failed\n");
+	return 0;
+}
+
+static int check_bios_timer_pin(int apic, int pin)
+{
+	/* 
+	 * Test the BIOS supplied ioapic pin for the i8254
+	 */
+	if (pin == -1)
+		return 0;
+
+	return do_check_timer_pin(apic, pin);
+}
+
+static int check_timer_pin(int apic, int pin)
+{
+	int irq, idx;
+	/* 
+	 * Test the architecture default i8254 timer pin
+	 * of apic 0 pin 2.
+	 */
+
+
+	/* If the apic pin pair is in use by another irq fail */
+	irq = irq_from_pin(apic, pin);
+	if ((irq != -1) && (irq != 0)) {
+		apic_printk(APIC_VERBOSE,KERN_INFO "...apic %d pin % in use by irq %d\n",
+			apic, pin, irq);
+		return 0; 
+	}
+
+	/* Add an entry in mp_irqs for irq 0 */
+	idx = update_irq0_entry(apic, pin);
+
+	/* Add an entry in irq_to_pin */
+	add_pin_to_irq(0, apic, pin);
+
+	/* Now setup the irq */
+	setup_IO_APIC_irq(apic, pin, idx, 0);
+
+	/* And finally check to see if the irq works */
+	return do_check_timer_pin(apic, pin);
+}
+
+static int check_ExtINT_pin(int apic, int pin, int vector)
+{
+	if (pin == -1)
+		return 0;
+
+	apic_printk(APIC_VERBOSE,KERN_INFO "..ExtINT trying IO-APIC=%d PIN=%d",
+			apic, pin);
+	/*
+	 * legacy devices should be connected to IO APIC #0
+	 */
+	setup_ExtINT_IRQ0_pin(apic, pin, vector);
+	if (timer_irq_works()) {
+		apic_printk(APIC_VERBOSE, " .. success\n");
+		nmi_watchdog_default();
+		if (nmi_watchdog == NMI_IO_APIC) {
+			setup_nmi();
+		}
+		return 1;
+	}
+	/*
+	 * Cleanup, just in case ...
+	 */
+	clear_IO_APIC_pin(apic, pin);
+	apic_printk(APIC_VERBOSE, " .. failed\n");
 	return 0;
+	
 }
 
-/* The function from hell */
+/*
+ * This code may look a bit paranoid, but it's supposed to cooperate with
+ * a wide range of boards and BIOS bugs.  Fortunately only the timer IRQ
+ * is so screwy.  Thanks to Brian Perkins for testing/hacking this beast
+ * fanatically on his truly buggy board.
+ */
+
 static void check_timer(void)
 {
 	int apic1, pin1, apic2, pin2;
@@ -1689,37 +1758,50 @@ static void check_timer(void)
 	pin2  = ioapic_i8259.pin;
 	apic2 = ioapic_i8259.apic;
 
-	/* Do this first, otherwise we get double interrupts on ATI boards */
-	if ((pin1 != -1) && try_apic_pin(apic1, pin1,"with 8259 IRQ0 disabled"))
-		return;
+	apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n",
+		vector, apic1, pin1, apic2, pin2);
 
-	/* Now try again with IRQ0 8259A enabled.
-	   Assumes timer is on IO-APIC 0 ?!? */
-	enable_8259A_irq(0);
-	unmask_IO_APIC_irq(0);
-	if (try_apic_pin(apic1, pin1, "with 8259 IRQ0 enabled"))
-		return;
-	disable_8259A_irq(0);
 
-	/* Always try pin0 and pin2 on APIC 0 to handle buggy timer overrides
-	   on Nvidia boards */
-	if (!(apic1 == 0 && pin1 == 0) &&
-	    try_apic_pin(0, 0, "fallback with 8259 IRQ0 disabled"))
-		return;
-	if (!(apic1 == 0 && pin1 == 2) &&
-	    try_apic_pin(0, 2, "fallback with 8259 IRQ0 disabled"))
-		return;
+	/* 
+	 * If the BIOS has supplied an ioapic pin for the 8254 try that.
+	 */
+	if (check_bios_timer_pin(apic1, pin1))
+ 		return;
 
-	/* Then try pure 8259A routing on the 8259 as reported by BIOS*/
-	enable_8259A_irq(0);
-	if (pin2 != -1) {
-		setup_ExtINT_IRQ0_pin(apic2, pin2, vector);
-		if (try_apic_pin(apic2,pin2,"8259A broadcast ExtINT from BIOS"))
-			return;
-	}
+	/*
+	 * If the BIOS has not properly supplied the ioapic pin for the 8254
+	 * try the architectural default.  It is a common BIOS implementation
+	 * mistake to forget the ACPI source override for irq 0.
+	 */
+	if (check_timer_pin(0, 2))
+ 		return;
+
+	apic_printk(APIC_QUIET,KERN_ERR "..MP-BIOS bug: 8254 timer not "
+				"connected to IO-APIC\n");
 
-	/* Tried all possibilities to go through the IO-APIC. Now come the
-	   really cheesy fallbacks. */
+	/*
+	 * Ok there are no more good canidates for an apic pin.
+	 * Start testing diffeernt ways of enable ExtINT.
+	 */
+	apic_printk(APIC_VERBOSE,KERN_INFO "...trying to set up timer (IRQ0) "
+				"through the 8259A ...\n");
+
+	/* 
+	 * If the BIOS has supplied programming information for ExtINT
+	 * or we have derived by looking at the ioapics try that.
+	 */
+	if (check_ExtINT_pin(apic2, pin2, vector))
+ 		return;
+
+	/* 
+	 * If the BIOS has not supplied the ExtINT pin to the i8259
+	 * or the BIOS supplied value does not work guess the
+	 * architectural default of apic 0 pin 0. 
+	 */
+	if (check_ExtINT_pin(0, 0, vector))
+		return;
+
+	apic_printk(APIC_VERBOSE," failed.\n");
 
 	if (nmi_watchdog == NMI_IO_APIC) {
 		printk(KERN_WARNING "timer doesn't work through the IO-APIC - disabling NMI Watchdog!\n");
-- 
1.4.4.1.g278f

Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Adrian Bunk]

On Mon, Jan 08, 2007 at 09:11:24AM -0700, Eric W. Biederman wrote:
> 
> To a large extent this reverts b026872601976f666bae77b609dc490d1834bf77
> while still keeping to the spirits of it's goal, the ability to
> make smart guesses about how the timer irq is routed when the BIOS
> gets it wrong.
>...

That's code where every changed line has a great potential of causing a 
different kind of breakage on someone else's computer.

Your comment therefore translates to "revert commit 
b026872601976f666bae77b609dc490d1834bf77 for 2.6.20 and try to find a 
better solution for 2.6.21".

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:

> On Mon, Jan 08, 2007 at 09:11:24AM -0700, Eric W. Biederman wrote:
>> 
>> To a large extent this reverts b026872601976f666bae77b609dc490d1834bf77
>> while still keeping to the spirits of it's goal, the ability to
>> make smart guesses about how the timer irq is routed when the BIOS
>> gets it wrong.
>>...
>
> That's code where every changed line has a great potential of causing a 
> different kind of breakage on someone else's computer.

Why does this piece of code give every one the screaming hebie jebies?
I read it I understand it, it is code.

This code is not a terribly sensitive delicate heuristic, and Andi has
already broken it as much as it can possibly be broken.  It's not like
the code is on a SMP fastpath full of carefully orchestrated races
that are safe because within certain limits even stale values are ok.

This is code is straight forward logic, you tell the computer what to
do and it does it.  Of those things we can do only very few of
them are correct, and we are seeking to enhance our ability to find
correct solutions by adding intelligent guesses.  As long as the first
guess is trust the BIOS the rest of this code is largely a don't
care.  As Andi proved by breaking all the rest of this.  Or why
don't I have more testers just crawling out of the wood work,
screaming for this code to be fixed?

Plus this code can only cause one type of breakage.   A failure to
work around a broken BIOS and make the IRQs work.

> Your comment therefore translates to "rexvert commit 
> b026872601976f666bae77b609dc490d1834bf77 for 2.6.20 and try to find a 
> better solution for 2.6.21".

If that is the practical translation I am fine with it.

Linus said he wanted to try in the 2.6.20 timeframe.  Although things
have probably dragged on much to long.

The heuristics tests in my patch actually do what they try to do. 
Unlike Andi's where only trusting the BIOS supplied default works.
So from where we are it is a clear benefit.  b026872601976f666bae77b609dc490d1834bf77
is broken.  I just found it easier and more evolutionary to starting
with a working code base.  Not that my result is radically different
codewise from what Andi and tried.

Everything that worked in 2.6.19 should also work.  Except for the ATI
case we still have all of the other heurstic work abounds supplied by
quirks instead of supplied manually, and the ATI fix was to not enable
interrupts on the i8259 and then expect the ioapic to work, which we
have sensibly made a global default.

I really don't care how we do it, or in what timeframe.  But what I have
posted is the only way I can see of making it better, than what we had
in 2.6.19.

I would like to see my code take the conversation to talking about
what intelligent guesses we should try when the BIOS get's it wrong
instead of being stuck where we have with Andi's code about how do we
make the heuristic guesses we want to try actually run.

Now if someone wants to see a beautiful history we can revert Andi's commit
Implement the code motion parts of mine into functions.  Implement what it
takes to make those functions safe to call multiple times, and then call
extra times as heuristic guesses to get the hardware correct.  There
might be some sense in that, although it feels like trying to hard to me.

I definitely think in the 2.6.21 timeframe it makes sense to put this code in
on i386 as well.  Otherwise the maintenance will just be crazy.

Eric

Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Adrian Bunk]

On Mon, Jan 08, 2007 at 02:45:00PM -0700, Eric W. Biederman wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> 
> > On Mon, Jan 08, 2007 at 09:11:24AM -0700, Eric W. Biederman wrote:
> >> 
> >> To a large extent this reverts b026872601976f666bae77b609dc490d1834bf77
> >> while still keeping to the spirits of it's goal, the ability to
> >> make smart guesses about how the timer irq is routed when the BIOS
> >> gets it wrong.
> >>...
> >
> > That's code where every changed line has a great potential of causing a 
> > different kind of breakage on someone else's computer.
> 
> Why does this piece of code give every one the screaming hebie jebies?
> I read it I understand it, it is code.
> 
> This code is not a terribly sensitive delicate heuristic, and Andi has
> already broken it as much as it can possibly be broken.  It's not like
> the code is on a SMP fastpath full of carefully orchestrated races
> that are safe because within certain limits even stale values are ok.
> 
> This is code is straight forward logic, you tell the computer what to
> do and it does it.  Of those things we can do only very few of
> them are correct, and we are seeking to enhance our ability to find
> correct solutions by adding intelligent guesses.  As long as the first
> guess is trust the BIOS the rest of this code is largely a don't
> care.  As Andi proved by breaking all the rest of this.  Or why
> don't I have more testers just crawling out of the wood work,
> screaming for this code to be fixed?
> 
> Plus this code can only cause one type of breakage.   A failure to
> work around a broken BIOS and make the IRQs work.

We just got a completely different bug reported that was confirmed to be 
caused by Andi's patch:
   AMD64/ATI : timer is running twice as fast as it should [1]

> > Your comment therefore translates to "rexvert commit 
> > b026872601976f666bae77b609dc490d1834bf77 for 2.6.20 and try to find a 
> > better solution for 2.6.21".
> 
> If that is the practical translation I am fine with it.
>...
> I really don't care how we do it, or in what timeframe.  But what I have
> posted is the only way I can see of making it better, than what we had
> in 2.6.19.
>...

My whole point is that for 2.6.20, we can live with simply reverting 
Andi's commit.

What to do for 2.6.21 is a completely different story.

> Eric

cu
Adrian

[1] http://bugzilla.kernel.org/show_bug.cgi?id=7789

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Linus Torvalds]

On Mon, 8 Jan 2007, Adrian Bunk wrote:
> 
> We just got a completely different bug reported that was confirmed to be 
> caused by Andi's patch:
>    AMD64/ATI : timer is running twice as fast as it should [1]

Yeah. I have to say, that with my main goal for 2.6.20 being a stability 
release, and the APIC setup scaring me too, I'm starting to strongly lean 
towards just reverting the thing, and then having this whole thing 
re-introduced early during the 2.6.21 cycle with the new information we 
have (ie the clues about exactly why the dang thing broke in the first 
place).

After all, the only reason I didn't want to revert the commit initially 
was that it did clean things up, and I wanted to understand why it didn't 
work. I think we understand why it caused problems, and I think we can fix 
them, but on the other hand, we're already deep into -rc4 with this, so 
let's just revert for now and then clean it up correctly after the 2.6.20 
release.

		Linus

Re: [discuss] [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Andi Kleen]

> We just got a completely different bug reported that was confirmed to be 
> caused by Andi's patch:
>    AMD64/ATI : timer is running twice as fast as it should [1]

I have such a machine that showed this problem and when I wrote the patch I 
tested it on it (and on a couple of others of course). No twice as fast on 
my testing.

In fact there are two types of ATI machines: ones that have a BIOS workaround
for the original Linux issue and ones that don't. Keeping both
happy is not easy.

So I'm somewhat dubious on that. Where is that report?

> 
> My whole point is that for 2.6.20, we can live with simply reverting 
> Andi's commit.

I agree. It's more problematical than I expected. Reverting is 
the best option right now.

-Andi

Re: [discuss] [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Adrian Bunk]

On Tue, Jan 09, 2007 at 12:14:41AM +0100, Andi Kleen wrote:
> 
> > We just got a completely different bug reported that was confirmed to be 
> > caused by Andi's patch:
> >    AMD64/ATI : timer is running twice as fast as it should [1]
> 
> I have such a machine that showed this problem and when I wrote the patch I 
> tested it on it (and on a couple of others of course). No twice as fast on 
> my testing.
> 
> In fact there are two types of ATI machines: ones that have a BIOS workaround
> for the original Linux issue and ones that don't. Keeping both
> happy is not easy.
> 
> So I'm somewhat dubious on that. Where is that report?

Follow the link [1] in my email (and the bug is already assigned to 
you).

> > My whole point is that for 2.6.20, we can live with simply reverting 
> > Andi's commit.
> 
> I agree. It's more problematical than I expected. Reverting is 
> the best option right now.
> 
> -Andi

cu
Adrian

[1] http://bugzilla.kernel.org/show_bug.cgi?id=7789

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:

> On Mon, Jan 08, 2007 at 02:45:00PM -0700, Eric W. Biederman wrote:
>> Adrian Bunk <bunk@stusta.de> writes:
>
> We just got a completely different bug reported that was confirmed to be 
> caused by Andi's patch:
>    AMD64/ATI : timer is running twice as fast as it should [1]

Odd. I didn't think Andi's code worked well enough that we could hit
anything but the default trust the BIOS case.  I guess someone had
the right hardware to perform that miracle.

>> I really don't care how we do it, or in what timeframe.  But what I have
>> posted is the only way I can see of making it better, than what we had
>> in 2.6.19.
>>...
>
> My whole point is that for 2.6.20, we can live with simply reverting 
> Andi's commit.
>
> What to do for 2.6.21 is a completely different story.

That is where I figured we were when we first hit this bug.

I have always found the ways of stable tree maintainers to be
mysterious.  Sometimes holding back code with minimal risk sometimes
insisting we cleanup things instead of reverting things.

So I have just decided to write the code and let other people figure
out when it should be merged :)  And of course when my code has
problems to address them.

Eric

Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.

[Tobias Diedrich]

Eric W. Biederman wrote:
> Tobias.  I don't have a box with the problem yours does, and this
> doesn't quite try any of the cases you have been asked to test
> so could you please test this one?

Works fine with BIOS 0402.

patches/series:
patch-2.6.20-rc4
patch-2.6.19-rc3-nokmem
myconfig
ccache
x86_64_io_apic_fix_eric_20060108
hpet-quirk

dmesg:
Linux version 2.6.20-rc4-amd64 (ranma@melchior) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #56 Tue Jan 9 22:40:56 CET 2007
Command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose netconsole=@192.168.8.241/,514@255.255.255.255/ ro
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fee0000 (usable)
 BIOS-e820: 000000003fee0000 - 000000003fee3000 (ACPI NVS)
 BIOS-e820: 000000003fee3000 - 000000003fef0000 (ACPI data)
 BIOS-e820: 000000003fef0000 - 000000003ff00000 (reserved)
 BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 261856) 1 entries of 256 used
end_pfn_map = 1048576
DMI 2.3 present.
ACPI: RSDP (v000 Nvidia                                ) @ 0x00000000000f7ce0
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003fee3040
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003fee30c0
ACPI: SSDT (v001 PTLTD  POWERNOW 0x00000001  LTP 0x00000001) @ 0x000000003feec2c0
ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003feec400
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003feec200
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 261856) 1 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  DMA32        4096 ->  1048576
  Normal    1048576 ->  1048576
early_node_map[2] active PFN ranges
    0:        0 ->      159
    0:      256 ->   261856
On node 0 totalpages: 261759
  DMA zone: 56 pages used for memmap
  DMA zone: 1358 pages reserved
  DMA zone: 2585 pages, LIFO batch:0
  DMA32 zone: 3524 pages used for memmap
  DMA32 zone: 254236 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
mapped APIC to ffffffffff5fd000 (        fee00000)
mapped IOAPIC to ffffffffff5fc000 (00000000fec00000)
Nosave address range: 000000000009f000 - 00000000000a0000
Nosave address range: 00000000000a0000 - 00000000000f0000
Nosave address range: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 40000000 (gap: 3ff00000:b0100000)
Built 1 zonelists.  Total pages: 256821
Kernel command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose netconsole=@192.168.8.241/,514@255.255.255.255/ ro
netconsole: local port 6665
netconsole: local IP 192.168.8.241
netconsole: interface eth0
netconsole: remote port 514
netconsole: remote IP 255.255.255.255
netconsole: remote ethernet address ff:ff:ff:ff:ff:ff
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
trying to force-enable HPET
HPET force-enabled at 0xfef00000
time.c: Using 25.000000 MHz WALL HPET GTOD HPET/TSC timer.
time.c: Detected 2009.512 MHz processor.
Console: colour VGA+ 80x60
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Checking aperture...
CPU 0: aperture @ b2c2000000 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Memory: 1025348k/1047424k available (3242k kernel code, 21444k reserved, 1470k data, 200k init)
Calibrating delay using timer specific routine.. 4023.49 BogoMIPS (lpj=6703198)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 02
ACPI: Core revision 20060707
ACPI (tbget-0289): Table [DSDT] replaced by host OS [20060707]
enabled ExtINT on CPU#0
ESR value after enabling vector: 00000000, after 00000004
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x20 apic1=0 pin1=0 apic2=-1 pin2=-1
..TIMER trying IO-APIC=0 PIN=0<3> .. failed
...apic 0 pin  2n use by irq 2
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..ExtINT trying IO-APIC=0 PIN=0 .. success
Using local APIC timer interrupts.
result 12559469
Detected 12.559 MHz APIC timer.
testing NMI watchdog ... OK.
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using MMCONFIG at f0000000
PCI: No mmconfig possible on device 00:18
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Firmware left 0000:01:07.0 e100 interrupts enabled, disabling
PCI: Transparent bridge - 0000:00:06.0
Boot video device is 0000:07:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK2] (IRQs 5 7 9 *10 11 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 5 *7 9 10 11 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK5] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK6] (IRQs *5 7 9 10 11 14 15)
ACPI: PCI Interrupt Link [LNK7] (IRQs 5 7 9 10 *11 14 15)
ACPI: PCI Interrupt Link [LNK8] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LP2P] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 5 7 9 10 *11 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 5 7 9 *10 11 14 15)
ACPI: PCI Interrupt Link [LMC1] (IRQs 5 7 9 *10 11 14 15)
ACPI: PCI Interrupt Link [LAZA] (IRQs 5 7 9 10 *11 14 15)
ACPI: PCI Interrupt Link [LPMU] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 5 7 9 *10 11 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 5 *7 9 10 11 14 15)
ACPI: PCI Interrupt Link [LIDE] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LFID] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSA2] (IRQs 5 7 9 10 11 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC6] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC7] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC8] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [AMC1] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APMU] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [AAZA] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [ASA2] (IRQs 20 21 22 23) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
IOAPIC[0]: Set PCI routing entry (2-8 -> 0x28 -> IRQ 8 Mode:0 Active:0)
IOAPIC[0]: Set PCI routing entry (2-13 -> 0x2d -> IRQ 13 Mode:0 Active:0)
IOAPIC[0]: Set PCI routing entry (2-4 -> 0x24 -> IRQ 4 Mode:0 Active:0)
pnp: PnP ACPI: found 11 devices
SCSI subsystem initialized
libata version 2.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 02000000
.......     : arbitration: 02
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 001 01  0    0    0   0   0    1    1    20
 01 001 01  0    0    0   0   0    1    1    21
 02 001 01  1    0    0   0   0    1    1    22
 03 001 01  0    0    0   0   0    1    1    23
 04 001 01  1    0    0   0   0    1    1    24
 05 001 01  1    0    0   0   0    1    1    25
 06 001 01  0    0    0   0   0    1    1    26
 07 001 01  1    0    0   0   0    1    1    27
 08 001 01  1    0    0   0   0    1    1    28
 09 001 01  0    1    0   0   0    1    1    29
 0a 001 01  1    0    0   0   0    1    1    2A
 0b 001 01  1    0    0   0   0    1    1    2B
 0c 001 01  0    0    0   0   0    1    1    2C
 0d 001 01  1    0    0   0   0    1    1    2D
 0e 001 01  0    0    0   0   0    1    1    2E
 0f 001 01  0    0    0   0   0    1    1    2F
 10 000 00  1    0    0   0   0    0    0    00
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ1 -> 0:1
IRQ2 -> 0:2
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
hpet0: at MMIO 0xfef00000, IRQs 2, 8, 31
hpet0: 3 32-bit timers, 25000000 Hz
pnp: 00:01: ioport range 0x1000-0x107f could not be reserved
pnp: 00:01: ioport range 0x1080-0x10ff has been reserved
pnp: 00:01: ioport range 0x1400-0x147f has been reserved
pnp: 00:01: ioport range 0x1480-0x14ff could not be reserved
pnp: 00:01: ioport range 0x1800-0x187f has been reserved
pnp: 00:01: ioport range 0x1880-0x18ff has been reserved
PCI: Bridge: 0000:00:06.0
  IO window: d000-dfff
  MEM window: fdc00000-fdefffff
  PREFETCH window: 40000000-400fffff
PCI: Bridge: 0000:00:0a.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: b000-cfff
  MEM window: fdb00000-fdbfffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0f.0
  IO window: a000-afff
  MEM window: fda00000-fdafffff
  PREFETCH window: e8000000-efffffff
PCI: Setting latency timer of device 0000:00:06.0 to 64
PCI: Setting latency timer of device 0000:00:0a.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
PCI: Setting latency timer of device 0000:00:0f.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
fuse init (API version 7.8)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
PCI: Setting latency timer of device 0000:00:0a.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0a.0:pcie00]
Allocate Port Service[0000:00:0a.0:pcie03]
PCI: Setting latency timer of device 0000:00:0b.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
Allocate Port Service[0000:00:0b.0:pcie03]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
Allocate Port Service[0000:00:0c.0:pcie03]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
Allocate Port Service[0000:00:0d.0:pcie03]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie03]
PCI: Setting latency timer of device 0000:00:0f.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0f.0:pcie00]
Allocate Port Service[0000:00:0f.0:pcie03]
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input1
ACPI: Power Button (CM) [PWRB]
ACPI: Fan [FAN] (on)
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Getting cpuindex for acpiid 0x1
ACPI: Thermal Zone [THRM] (25 C)
Real Time Clock Driver v1.12ac
hpet_acpi_add: no address or irqs in _CRS
Linux agpgart interface v0.101 (c) Dave Jones
loop: loaded (max 8 devices)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
netconsole: eth0 doesn't exist, aborting.
ahci 0000:06:00.0: version 2.0
ACPI: PCI Interrupt Link [APC7] enabled at IRQ 16
IOAPIC[0]: Set PCI routing entry (2-16 -> 0x69 -> IRQ 16 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:06:00.0[A] -> Link [APC7] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:06:00.0 to 64
ahci 0000:06:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
ahci 0000:06:00.0: flags: 64bit ncq pm led clo pmp pio slum part 
ata1: SATA max UDMA/133 cmd 0xFFFFC20000064100 ctl 0x0 bmdma 0x0 irq 16
ata2: SATA max UDMA/133 cmd 0xFFFFC20000064180 ctl 0x0 bmdma 0x0 irq 16
scsi0 : ahci
ata1: SATA link down (SStatus 0 SControl 300)
scsi1 : ahci
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-7, max UDMA7, 488397168 sectors: LBA48 NCQ (depth 31/32)
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access     ATA      SAMSUNG SP2504C  VT10 PQ: 0 ANSI: 5
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda4 < sda5 sda6 >
sd 1:0:0:0: Attached scsi disk sda
sd 1:0:0:0: Attached scsi generic sg0 type 0
pata_amd 0000:00:04.0: version 0.2.7
PCI: Setting latency timer of device 0000:00:04.0 to 64
ata3: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
ata4: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
scsi2 : pata_amd
ata3.00: ATAPI, max UDMA/33
ata3.01: ATAPI, max UDMA/66
ata3.00: configured for UDMA/33
ata3.01: configured for UDMA/66
scsi3 : pata_amd
ata4: port disabled. ignoring.
ata4: reset failed, giving up
scsi 2:0:0:0: CD-ROM            _NEC     DVD_RW ND-3500AG 2.1A PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 2:0:0:0: Attached scsi CD-ROM sr0
sr 2:0:0:0: Attached scsi generic sg1 type 5
scsi 2:0:1:0: CD-ROM            PIONEER  DVD-ROM DVD-106  1.22 PQ: 0 ANSI: 5
sr1: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
sr 2:0:1:0: Attached scsi CD-ROM sr1
sr 2:0:1:0: Attached scsi generic sg2 type 5
block2mtd: version $Revision: 1.30 $
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 23
IOAPIC[0]: Set PCI routing entry (2-23 -> 0x71 -> IRQ 23 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCL] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.1: debug port 1
PCI: cache line size of 64 is not supported by device 0000:00:02.1
ehci_hcd 0000:00:02.1: irq 23, io mem 0xfe02e000
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 22
IOAPIC[0]: Set PCI routing entry (2-22 -> 0x79 -> IRQ 22 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [APCF] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 22, io mem 0xfe02f000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
USB Universal Host Controller Interface driver v3.0
usbcore: registered new interface driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
usb usb2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
i2c /dev entries driver
i2c_adapter i2c-0: nForce2 SMBus adapter at 0x1c00
i2c_adapter i2c-1: nForce2 SMBus adapter at 0x1c40
it87: Found IT8716F chip at 0x290, revision 0
it87: in3 is VCC (+5V)
it87: in7 is VCCH (+5V Stand-By)
md: raid1 personality registered for level 1
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
GACT probability on
Mirror/redirect action on
u32 classifier
    Performance counters on
    input device check on 
    Actions configured 
nf_conntrack version 0.5.0 (4091 buckets, 32728 max)
IPv4 over IPv4 tunneling driver
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP bic registered
TCP cubic registered
TCP westwood registered
TCP htcp registered
TCP vegas registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
usb 1-2: new high speed USB device using ehci_hcd and address 2
Bridge firewalling registered
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3200+ processors (version 2.00.00)
powernow-k8:    0 : fid 0xc (2000 MHz), vid 0x8
powernow-k8:    1 : fid 0xa (1800 MHz), vid 0xa
powernow-k8:    2 : fid 0x2 (1000 MHz), vid 0x12
ACPI: (supports S0 S1 S3 S4 S5)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 200k freed
usb 1-2: configuration #1 chosen from 1 choice
hub 1-2:1.0: USB hub found
hub 1-2:1.0: 4 ports detected
usb 2-3: new full speed USB device using ohci_hcd and address 2
usb 2-3: configuration #1 chosen from 1 choice
usb 2-4: new full speed USB device using ohci_hcd and address 3
usb 2-4: configuration #1 chosen from 1 choice
usb 1-2.3: new low speed USB device using ehci_hcd and address 5
usb 1-2.3: configuration #1 chosen from 1 choice
input: Logitech USB-PS/2 Optical Mouse as /class/input/input2
input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:02.1-2.3
usb 1-2.4: new low speed USB device using ehci_hcd and address 6
usb 1-2.4: configuration #1 chosen from 1 choice
input: HID 046a:0001 as /class/input/input3
input: USB HID v1.00 Keyboard [HID 046a:0001] on usb-0000:00:02.1-2.4
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59.
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 21
IOAPIC[0]: Set PCI routing entry (2-21 -> 0x81 -> IRQ 21 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APCH] -> GSI 21 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:08.0 to 64
forcedeth: using HIGHDMA
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
pl2303 2-4:1.0: pl2303 converter detected
usb 2-4: pl2303 converter now attached to ttyUSB0
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
eth0: forcedeth.c: subsystem: 01043:8239 bound to 0000:00:08.0
ACPI: PCI Interrupt Link [AMC1] enabled at IRQ 20
IOAPIC[0]: Set PCI routing entry (2-20 -> 0x89 -> IRQ 20 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [AMC1] -> GSI 20 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:09.0 to 64
forcedeth: using HIGHDMA
eth1: forcedeth.c: subsystem: 01043:8239 bound to 0000:00:09.0
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
IOAPIC[0]: Set PCI routing entry (2-17 -> 0x91 -> IRQ 17 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
e100: eth2: e100_probe: addr 0xfdeff000, irq 17, MAC addr 00:02:B3:1C:8B:4F
gameport: EMU10K1 is pci0000:01:08.1/gameport0, io 0xd400, speed 1203kHz
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
IOAPIC[0]: Set PCI routing entry (2-18 -> 0x99 -> IRQ 18 Mode:1 Active:1)
ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 18
ALSA sound/pci/emu10k1/emu10k1_main.c:1176: vendor=0x1102, device=0x2, subsystem_vendor_id=0x80641102, subsystem_id=0x8064
ALSA sound/pci/emu10k1/emu10k1_main.c:1201: Sound card name=SB Live 5.1
Adding 1951856k swap on /dev/sda6.  Priority:-1 extents:1 across:1951856k
EXT3 FS on sda5, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ReiserFS: dm-4: found reiserfs format "3.6" with standard journal
ReiserFS: dm-4: using ordered data mode
ReiserFS: dm-4: journal params: device dm-4, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: dm-4: checking transaction log (dm-4)
ReiserFS: dm-4: Using r5 hash to sort names
lp: driver loaded but no devices found
ppdev: user-space parallel port driver
eth0: no IPv6 routers present

-- 
Tobias						PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。