Re: IO-APIC on nforce2 [PATCH]

Re: IO-APIC on nforce2 [PATCH]

[Len Brown]

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

Re: IRQ0 XT-PIC timer issue

Since the hardware is connected to APIC pin0, it is a BIOS bug
that an ACPI interrupt source override from pin2 to IRQ0 exists.

With this simple 2.6.5 patch you can specify "acpi_skip_timer_override"
to ignore that bogus BIOS directive.  The result is with your
ACPI-enabled APIC-enabled kernel, you'll get IRQ0 IO-APIC-edge timer.

Probably there is a more clever way to trigger this workaround
automatcially instead of via boot parameter.

cheers,
-Len

===== Documentation/kernel-parameters.txt 1.44 vs edited =====
--- 1.44/Documentation/kernel-parameters.txt	Mon Mar 22 16:03:22 2004
+++ edited/Documentation/kernel-parameters.txt	Tue Apr 13 17:47:11 2004
@@ -122,6 +122,10 @@
 
 	acpi_serialize	[HW,ACPI] force serialization of AML methods
 
+	acpi_skip_timer_override [HW,ACPI]]
+			Recognize IRQ0/pin2 Interrupt Source Override
+			and ignore it -- for broken nForce2 BIOS.
+
 	ad1816=		[HW,OSS]
 			Format: <io>,<irq>,<dma>,<dma2>
 			See also Documentation/sound/oss/AD1816.
===== arch/i386/kernel/setup.c 1.115 vs edited =====
--- 1.115/arch/i386/kernel/setup.c	Fri Apr  2 07:21:43 2004
+++ edited/arch/i386/kernel/setup.c	Tue Apr 13 17:41:31 2004
@@ -614,6 +614,12 @@
 		else if (!memcmp(from, "acpi_sci=low", 12))
 			acpi_sci_flags.polarity = 3;
 
+		else if (!memcmp(from, "acpi_skip_timer_override", 24)) {
+			extern int acpi_skip_timer_override;
+
+			acpi_skip_timer_override = 1;
+		}
+
 #ifdef CONFIG_X86_LOCAL_APIC
 		/* disable IO-APIC */
 		else if (!memcmp(from, "noapic", 6))
===== arch/i386/kernel/acpi/boot.c 1.57 vs edited =====
--- 1.57/arch/i386/kernel/acpi/boot.c	Tue Mar 30 17:05:19 2004
+++ edited/arch/i386/kernel/acpi/boot.c	Tue Apr 13 17:50:14 2004
@@ -62,6 +62,7 @@
 
 acpi_interrupt_flags acpi_sci_flags __initdata;
 int acpi_sci_override_gsi __initdata;
+int acpi_skip_timer_override __initdata;
 
 #ifdef CONFIG_X86_LOCAL_APIC
 static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
@@ -327,6 +328,12 @@
 		acpi_sci_ioapic_setup(intsrc->global_irq,
 			intsrc->flags.polarity, intsrc->flags.trigger);
 		return 0;
+	}
+
+	if (acpi_skip_timer_override &&
+		intsrc->bus_irq == 0 && intsrc->global_irq == 2) {
+			printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");
+			return 0;
 	}
 
 	mp_override_legacy_irq (



[-- Attachment #2: wip.patch --]
[-- Type: text/plain, Size: 1806 bytes --]

===== Documentation/kernel-parameters.txt 1.44 vs edited =====
--- 1.44/Documentation/kernel-parameters.txt	Mon Mar 22 16:03:22 2004
+++ edited/Documentation/kernel-parameters.txt	Tue Apr 13 17:47:11 2004
@@ -122,6 +122,10 @@
 
 	acpi_serialize	[HW,ACPI] force serialization of AML methods
 
+	acpi_skip_timer_override [HW,ACPI]]
+			Recognize IRQ0/pin2 Interrupt Source Override
+			and ignore it -- for broken nForce2 BIOS.
+
 	ad1816=		[HW,OSS]
 			Format: <io>,<irq>,<dma>,<dma2>
 			See also Documentation/sound/oss/AD1816.
===== arch/i386/kernel/setup.c 1.115 vs edited =====
--- 1.115/arch/i386/kernel/setup.c	Fri Apr  2 07:21:43 2004
+++ edited/arch/i386/kernel/setup.c	Tue Apr 13 17:41:31 2004
@@ -614,6 +614,12 @@
 		else if (!memcmp(from, "acpi_sci=low", 12))
 			acpi_sci_flags.polarity = 3;
 
+		else if (!memcmp(from, "acpi_skip_timer_override", 24)) {
+			extern int acpi_skip_timer_override;
+
+			acpi_skip_timer_override = 1;
+		}
+
 #ifdef CONFIG_X86_LOCAL_APIC
 		/* disable IO-APIC */
 		else if (!memcmp(from, "noapic", 6))
===== arch/i386/kernel/acpi/boot.c 1.57 vs edited =====
--- 1.57/arch/i386/kernel/acpi/boot.c	Tue Mar 30 17:05:19 2004
+++ edited/arch/i386/kernel/acpi/boot.c	Tue Apr 13 17:50:14 2004
@@ -62,6 +62,7 @@
 
 acpi_interrupt_flags acpi_sci_flags __initdata;
 int acpi_sci_override_gsi __initdata;
+int acpi_skip_timer_override __initdata;
 
 #ifdef CONFIG_X86_LOCAL_APIC
 static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
@@ -327,6 +328,12 @@
 		acpi_sci_ioapic_setup(intsrc->global_irq,
 			intsrc->flags.polarity, intsrc->flags.trigger);
 		return 0;
+	}
+
+	if (acpi_skip_timer_override &&
+		intsrc->bus_irq == 0 && intsrc->global_irq == 2) {
+			printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");
+			return 0;
 	}
 
 	mp_override_legacy_irq (

Re: IO-APIC on nforce2 [PATCH]

[Ross Dickson]

On Wednesday 14 April 2004 11:02, Len Brown wrote:
> Re: IRQ0 XT-PIC timer issue
> 
> Since the hardware is connected to APIC pin0, it is a BIOS bug
> that an ACPI interrupt source override from pin2 to IRQ0 exists.
> 
> With this simple 2.6.5 patch you can specify "acpi_skip_timer_override"
> to ignore that bogus BIOS directive.  The result is with your
> ACPI-enabled APIC-enabled kernel, you'll get IRQ0 IO-APIC-edge timer.
> 
> Probably there is a more clever way to trigger this workaround
> automatcially instead of via boot parameter.
> 
> cheers,
> -Len

Many thanks Len,
I cannot try it just yet (rebuilding car engine,-greasy mess
 - hopefully get to it tonight).

Just would like to add that if we cannot get Maciej's 8259 ack patch
back into the distro then we need an if statement in the check_timer()
to turn off timer_ack for nforce2 or Christian might get his hi-load back
and certainly nmi_debug=1 won't work.

e.g. for 2.4.26-rc2 io_apic.c line 1613 or 2.6.5 line 2180 
	if (pin1 != -1) {
		/*
		 * Ok, does IRQ0 through the IOAPIC work?
		 */
+		if(acpi_skip_timer_override)
+			timer_ack=0;
		unmask_IO_APIC_irq(0);

I might also grab the pci quirk source from the old nforce2 disconnect bit
patch and try it as a means of detection for automatic trigger. i.e. instead
of writing the pci config bit, set acpi_skip_timer_override instead - but then
if someone gets clock skew we would need the kern arg to turn it off - 
unless the potential for clock skew is fixed.
 
The clock skew is an interesting one, I think the clock uses tsc if available
to interpolate between timer ints and if so should it not also be used to 
validate the timer ints in case of noise? Apparently the clock speeds up not
slows down in those cases?

Regards
Ross.

> 
> ===== Documentation/kernel-parameters.txt 1.44 vs edited =====
> --- 1.44/Documentation/kernel-parameters.txt	Mon Mar 22 16:03:22 2004
> +++ edited/Documentation/kernel-parameters.txt	Tue Apr 13 17:47:11 2004
> @@ -122,6 +122,10 @@
>  
>  	acpi_serialize	[HW,ACPI] force serialization of AML methods
>  
> +	acpi_skip_timer_override [HW,ACPI]]
> +			Recognize IRQ0/pin2 Interrupt Source Override
> +			and ignore it -- for broken nForce2 BIOS.
> +
>  	ad1816=		[HW,OSS]
>  			Format: <io>,<irq>,<dma>,<dma2>
>  			See also Documentation/sound/oss/AD1816.
> ===== arch/i386/kernel/setup.c 1.115 vs edited =====
> --- 1.115/arch/i386/kernel/setup.c	Fri Apr  2 07:21:43 2004
> +++ edited/arch/i386/kernel/setup.c	Tue Apr 13 17:41:31 2004
> @@ -614,6 +614,12 @@
>  		else if (!memcmp(from, "acpi_sci=low", 12))
>  			acpi_sci_flags.polarity = 3;
>  
> +		else if (!memcmp(from, "acpi_skip_timer_override", 24)) {
> +			extern int acpi_skip_timer_override;
> +
> +			acpi_skip_timer_override = 1;
> +		}
> +
>  #ifdef CONFIG_X86_LOCAL_APIC
>  		/* disable IO-APIC */
>  		else if (!memcmp(from, "noapic", 6))
> ===== arch/i386/kernel/acpi/boot.c 1.57 vs edited =====
> --- 1.57/arch/i386/kernel/acpi/boot.c	Tue Mar 30 17:05:19 2004
> +++ edited/arch/i386/kernel/acpi/boot.c	Tue Apr 13 17:50:14 2004
> @@ -62,6 +62,7 @@
>  
>  acpi_interrupt_flags acpi_sci_flags __initdata;
>  int acpi_sci_override_gsi __initdata;
> +int acpi_skip_timer_override __initdata;
>  
>  #ifdef CONFIG_X86_LOCAL_APIC
>  static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
> @@ -327,6 +328,12 @@
>  		acpi_sci_ioapic_setup(intsrc->global_irq,
>  			intsrc->flags.polarity, intsrc->flags.trigger);
>  		return 0;
> +	}
> +
> +	if (acpi_skip_timer_override &&
> +		intsrc->bus_irq == 0 && intsrc->global_irq == 2) {
> +			printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");
> +			return 0;
>  	}
>  
>  	mp_override_legacy_irq (
> 
> 
> 

Re: IO-APIC on nforce2 [PATCH]

[Jamie Lokier]

Ross Dickson wrote:
> The clock skew is an interesting one, I think the clock uses tsc if available
> to interpolate between timer ints and if so should it not also be used to 
> validate the timer ints in case of noise? Apparently the clock speeds up not
> slows down in those cases?

If the clock is speeding up due to spurious extra timer interrupts,
how about reading the timer chip to validate the interrupts?  Doesn't
sound unreasonable to me :)

The problem with using the tsc is that the tsc frequency isn't
constant on some systems.  If it slows down, it would make valid timer
interrupts appear to be spurious.

-- Jamie

Re: IO-APIC on nforce2 [PATCH]

[Maciej W. Rozycki]

On Wed, 14 Apr 2004, Ross Dickson wrote:

> e.g. for 2.4.26-rc2 io_apic.c line 1613 or 2.6.5 line 2180 
> 	if (pin1 != -1) {
> 		/*
> 		 * Ok, does IRQ0 through the IOAPIC work?
> 		 */
> +		if(acpi_skip_timer_override)
> +			timer_ack=0;
> 		unmask_IO_APIC_irq(0);
> 
> I might also grab the pci quirk source from the old nforce2 disconnect bit
> patch and try it as a means of detection for automatic trigger. i.e. instead
> of writing the pci config bit, set acpi_skip_timer_override instead - but then
> if someone gets clock skew we would need the kern arg to turn it off - 
> unless the potential for clock skew is fixed.

 Well, the question is whether the timer->INTIN0 routing is hardwired
inside the nforce2 chipset or is it external and thus board-dependent.  
Any way to get this clarified by the chipset's manufacturer?

> The clock skew is an interesting one, I think the clock uses tsc if available
> to interpolate between timer ints and if so should it not also be used to 
> validate the timer ints in case of noise? Apparently the clock speeds up not
> slows down in those cases?

 With real hardware perhaps it can be debugged.  The interaction between
the 8254, the 8259As and the APICs seems interesting in the chipset.  
Perhaps the override to INTIN2 is to tell the timer is really unavailable
directly?  I can't see a way to have an ACPI override that specifies an
ISA interrupt is not connected to the I/O APIC (unlike with the MPS).

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: IO-APIC on nforce2 [PATCH]

[Christian Kröner]

> Just would like to add that if we cannot get Maciej's 8259 ack patch
> back into the distro then we need an if statement in the check_timer()
> to turn off timer_ack for nforce2 or Christian might get his hi-load back
> and certainly nmi_debug=1 won't work.
>
> e.g. for 2.4.26-rc2 io_apic.c line 1613 or 2.6.5 line 2180
> 	if (pin1 != -1) {
> 		/*
> 		 * Ok, does IRQ0 through the IOAPIC work?
> 		 */
> +		if(acpi_skip_timer_override)
> +			timer_ack=0;
> 		unmask_IO_APIC_irq(0);
>

Well it seems that if at least on -mm this isn't necessary.

Len, I simply applied your patch against 2.6.5-mm5-1 and it just works, great 
work! Having finally read http://bugme.osdl.org/show_bug.cgi?id=1203 I must 
say that my nforce2-board (MSI K7N2-Delta) never ever hung, wether I had the 
wrong timer setup or APIC on/off didn't harm any.

What I get now:

cat /proc/interrupts

           CPU0
  0:   25978569    IO-APIC-edge  timer
  1:       2102    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  7:          0    IO-APIC-edge  parport0
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:     147962    IO-APIC-edge  i8042
 14:     405977    IO-APIC-edge  ide0
 15:         93    IO-APIC-edge  ide1
 16:      60192   IO-APIC-level  ide2, saa7134[0]
 17:        155   IO-APIC-level  CMI8738
 19:    2209002   IO-APIC-level  nvidia
 20:    7538158   IO-APIC-level  ohci_hcd, eth0
 21:          0   IO-APIC-level  ehci_hcd
 22:         78   IO-APIC-level  ohci_hcd
NMI:          0
LOC:   25946237
ERR:          0
MIS:          0


timer setup:

ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-2, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not 
connected.
..TIMER: vector=0x31 pin1=0 pin2=-1
Using local APIC timer interrupts.
calibrating APIC timer ...


irq routing:

IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 001 01  0    0    0   0   0    1    1    31
 01 001 01  0    0    0   0   0    1    1    39
 02 000 00  1    0    0   0   0    0    0    00
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 001 01  0    0    0   0   0    1    1    51
 06 001 01  0    0    0   0   0    1    1    59
 07 001 01  0    0    0   0   0    1    1    61
 08 001 01  0    0    0   0   0    1    1    69
 09 001 01  0    1    0   0   0    1    1    71
 0a 001 01  0    0    0   0   0    1    1    79
 0b 001 01  0    0    0   0   0    1    1    81
 0c 001 01  0    0    0   0   0    1    1    89
 0d 001 01  0    0    0   0   0    1    1    91
 0e 001 01  0    0    0   0   0    1    1    99
 0f 001 01  0    0    0   0   0    1    1    A1
 10 001 01  1    1    0   0   0    1    1    D1
 11 001 01  1    1    0   0   0    1    1    D9
 12 001 01  1    1    0   0   0    1    1    E1
 13 001 01  1    1    0   0   0    1    1    C9
 14 001 01  1    1    0   0   0    1    1    B1
 15 001 01  1    1    0   0   0    1    1    C1
 16 001 01  1    1    0   0   0    1    1    B9
 17 001 01  1    1    0   0   0    1    1    A9
IRQ to pin mappings:
IRQ0 -> 0:0
IRQ1 -> 0:1
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
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ20 -> 0:20
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ23 -> 0:23
.................................... done.


This is simply great, any uncommon hi-load disappeared.
Will something like this get into mainline soon, maybe with automatic chipset 
detection?

Once again, thanks, christian.

P.S.: I will test the patch against mainline 2.6.5 kernel now and post the 
results later.

Re: IO-APIC on nforce2 [PATCH]

[Christian Kröner]

> Just would like to add that if we cannot get Maciej's 8259 ack patch
> back into the distro then we need an if statement in the check_timer()
> to turn off timer_ack for nforce2 or Christian might get his hi-load back
> and certainly nmi_debug=1 won't work.
>
> e.g. for 2.4.26-rc2 io_apic.c line 1613 or 2.6.5 line 2180
>       if (pin1 != -1) {
>               /*
>                * Ok, does IRQ0 through the IOAPIC work?
>                */
> +             if(acpi_skip_timer_override)
> +                     timer_ack=0;
>               unmask_IO_APIC_irq(0);
>

Also on mainline 2.6.5 this if-statement doesn't seem to be necessary. Len's 
patch worked on this kernel as well, setting the timer interrupt to 
IO-APIC-edge and there is no strange hi-load anymore too.

thanks, christian.

Re: IO-APIC on nforce2 [PATCH]

[Len Brown]

On Wed, 2004-04-14 at 15:57, Christian Kröner wrote:

> This is simply great, any uncommon hi-load disappeared.
> Will something like this get into mainline soon, maybe with automatic chipset 
> detection?

I'm okay putting the bootparam and the workaround into the kernel,
for it is generic and we may find other platforms need it.

But I don't have a clean way to make it automatic.
This is a BIOS bug, so chipset ID will not always work.

We could list the BIOS in dmi_scan(), but I hate doing
that b/c then the vendor releases a new version of their
broken BIOS and the automatic workaround no longer works...

-Len

Re: IO-APIC on nforce2 [PATCH]

[Craig Bradney]

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

On Thu, 2004-04-15 at 02:35, Peter Clifton wrote:
> Sorry Christian, meant to send to the list rather than just you.
> 
> I'm watching this thread with interest, I've got an ASUS A7N8X board,
> and have had annoying lockups with most kernels I've compiled myself
> from 2.4 upwards. Some luck caused me to try turning APIC off, and the
> system hasn't crashed since.
> 
> Is there any reason why turning APIC off reduces performance?
> 
> I'd be happy to provide another person to test patches (with the proviso
> that if you want detailed debugging information, you'd have to suggest
> how to obtain it, since when it locks up, it tends to lock good!)
> 
> I'm currently running 2.6.3-gentoo-r1 (Although I can't see a list of
> what patches they have already applied).
> 
> I'd be happy to try a vanilla kernel with whatever patches if that would
> help out solving the problem.

Peter, I have 2.6.3gentoo r1 on my box with a A7N8X Deluxe v2 with Ross
Dicksons 2.6.3 idlec1halt patches and its as stable as a rock. I've left
it on that kernel as there are still many discussions recently posted re
2.6.5. My 3 other PCs are on gentoo dev source 2.6.5 and are solid, but
I've left the Athlon on 2.6.3 due to the fact its working just fine now

Craig

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IO-APIC on nforce2 [PATCH]

[Peter Clifton]

Sorry Christian, meant to send to the list rather than just you.

I'm watching this thread with interest, I've got an ASUS A7N8X board,
and have had annoying lockups with most kernels I've compiled myself
from 2.4 upwards. Some luck caused me to try turning APIC off, and the
system hasn't crashed since.

Is there any reason why turning APIC off reduces performance?

I'd be happy to provide another person to test patches (with the proviso
that if you want detailed debugging information, you'd have to suggest
how to obtain it, since when it locks up, it tends to lock good!)

I'm currently running 2.6.3-gentoo-r1 (Although I can't see a list of
what patches they have already applied).

I'd be happy to try a vanilla kernel with whatever patches if that would
help out solving the problem.

Regards

Peter Clifton

Re: IO-APIC on nforce2 [PATCH]

[Ross Dickson]

On Thursday 15 April 2004 07:01, Christian Kröner wrote:
> > Just would like to add that if we cannot get Maciej's 8259 ack patch
> > back into the distro then we need an if statement in the check_timer()
> > to turn off timer_ack for nforce2 or Christian might get his hi-load back
> > and certainly nmi_debug=1 won't work.
> >
> > e.g. for 2.4.26-rc2 io_apic.c line 1613 or 2.6.5 line 2180
> >       if (pin1 != -1) {
> >               /*
> >                * Ok, does IRQ0 through the IOAPIC work?
> >                */
> > +             if(acpi_skip_timer_override)
> > +                     timer_ack=0;
> >               unmask_IO_APIC_irq(0);
> >
> 
> Also on mainline 2.6.5 this if-statement doesn't seem to be necessary. Len's 
> patch worked on this kernel as well, setting the timer interrupt to 
> IO-APIC-edge and there is no strange hi-load anymore too.
> 

Good that your hi-load is fixed just by routing the timer through io-apic.

Could you try the "nmi_watchdog=1" kernel arg please.

You should get a message in your boot log as to whether it works
also cat /proc/interrupts to see if it stops. 
Wouldn't hurt to try "nmi_watchdog=2" either.
I had a situation where "nmi_watchdog=2" tested ok in boot log
but halted after 23 interrupts.


> thanks, christian.
> 
> 
> 

Re: IO-APIC on nforce2 [PATCH]

[Ross Dickson]

On Thursday 15 April 2004 10:17, Len Brown wrote:
> On Wed, 2004-04-14 at 15:57, Christian Kröner wrote:
> 
> > This is simply great, any uncommon hi-load disappeared.
> > Will something like this get into mainline soon, maybe with automatic chipset 
> > detection?
> 
> I'm okay putting the bootparam and the workaround into the kernel,
> for it is generic and we may find other platforms need it.

Great, it sure is simpler and cleaner than my workaround. Thanks.

> 
> But I don't have a clean way to make it automatic.
> This is a BIOS bug, so chipset ID will not always work.

True it is a bios thing but I have yet to see an nforce2 MOBO that is not 
routed in this way. I am thinking it is internal to the chipset. I have seen
none route it into io-apic pin2.

> Maciej wrote
>  Well, the question is whether the timer->INTIN0 routing is hardwired
> inside the nforce2 chipset or is it external and thus board-dependent.  
> Any way to get this clarified by the chipset's manufacturer?

Nvidia is the first Company in my 20+ years of working life to totally not 
respond to my attempts to communicate and I have had dealings with
numerous semiconductor firms and agents. I doubt that my email source 
would be blocked and I have also tried their form mail. Do real people
work there? Maybe I have to phone or fax them from here in Australia?
-or place an order for 10,000 chips? Maybe we need a worldwide union of
Linux support staff to exhibit collective sales pressure. Enough ranting....

I am also cautioned by Maciej's comments indicating that maybe the 
override appears in the nforce2 bios because there is no other way of 
saying this is a feature that nvidia could not get to work properly?...

On the flip side in favour of this routing the clock skew may be restricted
to only to 2.6.1 kerns, I do not have it on my patched 2.4 kerns, it may
be fine on 2.6.5.

Here is a link to the old thread with the skew issues.
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-01/3129.html
Christian - would you please check if you get clock skew as described in
that thread?

> 
> We could list the BIOS in dmi_scan(), but I hate doing
> that b/c then the vendor releases a new version of their
> broken BIOS and the automatic workaround no longer works...
> 
> -Len
> 

Unfortunately the hard lockups in the BUG report won't be fixed by this io-apic
work. I think Shuttle is the only manufacturer to ship a bios update which has
taken a board with existing lockup problems and fixed it. So far nobody has
posted how this magic was done?
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-01/5003.html

In the mean time I and others with lockups have had success with my C1 idle 
patch but I have left it manual with kern arg for the same reason - no clean
way to automate it. Some nforce2 need it, others don't. Want me to finish 
cleaning it up for possible inclusion?
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-04/1707.html

-Ross.

Re: IO-APIC on nforce2 [PATCH]

[Zwane Mwaikambo]

On Tue, 13 Apr 2004, Len Brown wrote:

> Re: IRQ0 XT-PIC timer issue
>
> Since the hardware is connected to APIC pin0, it is a BIOS bug
> that an ACPI interrupt source override from pin2 to IRQ0 exists.
>
> With this simple 2.6.5 patch you can specify "acpi_skip_timer_override"
> to ignore that bogus BIOS directive.  The result is with your
> ACPI-enabled APIC-enabled kernel, you'll get IRQ0 IO-APIC-edge timer.
>
> Probably there is a more clever way to trigger this workaround
> automatcially instead of via boot parameter.

Nice, this is the problem which broke Andrew's and the systems i tested
my adaptation of Natalie's mp_override_legacy_irq() change. Whacking out
previous mp_irq entries would have worked if the BIOS had not forced the
pin2 override.

Re: IO-APIC on nforce2 [PATCH]

[Christian Kröner]

On Thursday 15 April 2004 10:17, Len Brown wrote:
>  I'm okay putting the bootparam and the workaround into the kernel,
>  for it is generic and we may find other platforms need it.

Thats more than what I could have expected, thanks.


Ross, I tested my kernel with nmi_watchdog=1 and nmi_watchdog=2 getting only 2 
to work.

output: nmi_watchdog=1

activating NMI Watchdog ... done.
testing NMI watchdog ... CPU#0: NMI appears to be stuck!


output: nmi_watchdog=2

testing NMI watchdog ... OK.


This is on 2.6.5-mm5-1.

Concerning the timer, well I tested it against my radio-controlled clock, 
setting it with ntpdate first and letting the system run (with ntpd off) and 
my system is kinda faster than my radio-clock. After about one hour my system 
was off by +14s compared to the radio-clock. I don't know if that is pretty 
shitty or simply normal for these bad pc-clocks...

I'm now compiling 2.6.6-rc1 with the nmi_watchdog=1 workaround. One question 
about the C1idle-patch, does this add a new feature or is it just a 
workaround for locked up nforce2-systems (since I never experienced lockups 
on my system, I wouldn't need it then)?

thanks for now, christian.

RE: IO-APIC on nforce2 [PATCH]

[Allen Martin]

> True it is a bios thing but I have yet to see an nforce2 MOBO 
> that is not 
> routed in this way. I am thinking it is internal to the 
> chipset. I have seen
> none route it into io-apic pin2.

It was a bug in our original nForce reference BIOS that we gave out to vendors.  Since then we fixed the reference BIOS, but since it was after products shipped, most of the motherboard vendors won't pick up the change unless they get complaints from customers.

We've fixed it for our reference BIOS for future products though.


-Allen

RE: IO-APIC on nforce2 [PATCH]

[Craig Bradney]

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

On Thu, 2004-04-15 at 20:33, Allen Martin wrote:
> > True it is a bios thing but I have yet to see an nforce2 MOBO 
> > that is not 
> > routed in this way. I am thinking it is internal to the 
> > chipset. I have seen
> > none route it into io-apic pin2.
> 
> It was a bug in our original nForce reference BIOS that we gave out to vendors.  Since then we fixed the reference BIOS, but since it was after products shipped, most of the motherboard vendors won't pick up the change unless they get complaints from customers.
> 
> We've fixed it for our reference BIOS for future products though.

Would it not be worth Nvidia advising the vendors (possibly already
done) that there are nForce BIOS issues causing reproducable hard
crashes with their existing BIOS versions with relation to the issue
here? I realise that these manufacturers (in my case ASUS) may have no
obligation and have their own product schedules of course.

There would seem to be many people puchasing nForce based systems and
many will not find out how or why there is the problem.

I for one, will not be buying another nForce based motherboard until I'm
sure this issue is sorted properly. Yes, I will probably find issues on
other boards, but I have no such hard crashes on an old P3 Sis chipset
board, a VIA KT Abit Duron board, nor on this P4 board with the very
same kernel source.

While my single purchases make no difference in the scheme of things,
the lack of support from the various manufacturers given to the kernel
developers  (I refer in this case to Ross Dickson trying to get help
from Nvidia and another, I think AMD) is turning me away (back to Intel
CPUs).

Of course, I am very happy to finally see a response from someone from
Nvidia now.

With best regards
Craig Bradney



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IO-APIC on nforce2 [PATCH]

[Len Brown]

On Wed, 2004-04-14 at 06:37, Maciej W. Rozycki wrote:
> On Wed, 14 Apr 2004, Ross Dickson wrote:

> > The clock skew is an interesting one, I think the clock uses tsc if available
> > to interpolate between timer ints and if so should it not also be used to 
> > validate the timer ints in case of noise? Apparently the clock speeds up not
> > slows down in those cases?
> 
>  With real hardware perhaps it can be debugged.  The interaction between
> the 8254, the 8259As and the APICs seems interesting in the chipset.

> Perhaps the override to INTIN2 is to tell the timer is really unavailable
> directly?

That would be way too subtle for a BIOS writer;-)

> I can't see a way to have an ACPI override that specifies an
> ISA interrupt is not connected to the I/O APIC (unlike with the MPS).

I agree.  And I think the existence of this /proc/interrupts
entry on an ACPI-enabled system should probably go away.

           CPU0       CPU1
  2:          0          0          XT-PIC  cascade

ACPI also doesn't support sharing more than 1 pin on an IRQ.
So if you see a construct like this below, it is also a bug:

IRQ to pin mappings:
IRQ23 -> 0:23-> 0:7

cheers,
-Len

RE: IO-APIC on nforce2 [PATCH]

[Len Brown]

On Thu, 2004-04-15 at 14:33, Allen Martin wrote:

> It was a bug in our original nForce reference BIOS that we gave out to vendors.  Since then we fixed the reference BIOS, but since it was after products shipped, most of the motherboard vendors won't pick up the change unless they get complaints from customers.
> 
> We've fixed it for our reference BIOS for future products though.

Great!

Knowing this makes the path clear.
As we expected, an automatic workaround based on chip-set would
fail because some BIOS's are fixed and some are not.
So we either leave the workaround as manual bootparam
or try to enumerate all BIOS versions with the bug
in dmi_scan.  I'm content to do the former.  If distros
have trouble supporting nforce2 systems, they may want to add
to the later.

thanks,
-Len

ps.
I'm also excited to see a linux-nforce-bugs@exchange.nvidia.com alias
on your note.  Perhaps you can explain how we should use it.  Should
this alias be included on discussions of the more important issue --
the system hang that seems to be related to HALT in idle/C1?

Re: IO-APIC on nforce2 [PATCH]

[Jamie Lokier]

Len Brown wrote:
> As we expected, an automatic workaround based on chip-set would
> fail because some BIOS's are fixed and some are not.

Does the workaround actually fail with the fixed BIOSes?

-- Jamie

RE: IO-APIC on nforce2 [PATCH]

[Allen Martin]

> I'm also excited to see a linux-nforce-bugs@exchange.nvidia.com alias
> on your note.  Perhaps you can explain how we should use it.  Should
> this alias be included on discussions of the more important issue --
> the system hang that seems to be related to HALT in idle/C1?

Yes, any issues that are relevant to linux operation on nForce boards can go there.  That list gets a lot of volume though, so any pressing issue that needs a response you can cc me directly.

-Allen

Re: IO-APIC on nforce2 [PATCH]

[Len Brown]

On Fri, 2004-04-16 at 04:27, Jamie Lokier wrote:
> Len Brown wrote:
> > As we expected, an automatic workaround based on chip-set would
> > fail because some BIOS's are fixed and some are not.
> 
> Does the workaround actually fail with the fixed BIOSes?

A fixed BIOS will not have a bogus IRQ2->pin-2 mapping,
so the acpi_skip_timer_override workaround would not
find an entry to ignore, and would become a NOP.

So if
1. all nforce2 chipsets have timer connected to pin0
2. we can safely discover we're on nforce2 early enough,
   like andi did on x86_64

then we could apply the workaround automatically always
w/o any harm.

-Len

Re: IO-APIC on nforce2 [PATCH]

[Maciej W. Rozycki]

On Thu, 22 Apr 2004, Len Brown wrote:

> So if
> 1. all nforce2 chipsets have timer connected to pin0

 Allen, is there a possibility to get a clarification from Nvidia on that?  
Specifically, assuming both an 8254 and an I/O APIC core are integrated
into the chip, whether OUT0 of the 8254 is unconditionally routed to
INTIN0 of the I/O APIC or is it configurable somehow.

> 2. we can safely discover we're on nforce2 early enough,
>    like andi did on x86_64
> 
> then we could apply the workaround automatically always
> w/o any harm.

 Indeed.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: IO-APIC on nforce2 [PATCH]

[Christian Kröner]

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

since its becoming fancy to post dmidecode output, here is mine. my bios 
vendor is MSI (K7N2-Delta) and it has released many BIOS updates for this 
board, but none of them fixes the timer-issue. i only got the timer issue, 
(related with it the already discussed obscure hi-load) no hang with c1 
disconnect enabled. another thing i recently noticed (running 2.6.6-rc2-mm1 
now) is that the last XT-PIC interrupt is gone now. i had cascade on irq2 
routed as XT-PIC before, now cascade (whatever it is) doesnt exist 
anymore ;).

/proc/interrupts now:

  0:   32184529    IO-APIC-edge  timer
  1:       1741    IO-APIC-edge  i8042
  7:          0    IO-APIC-edge  parport0
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:       9229    IO-APIC-edge  i8042
 14:     107111    IO-APIC-edge  ide0
 15:         92    IO-APIC-edge  ide1
 16:       3138   IO-APIC-level  ide2, saa7134[0]
 17:        153   IO-APIC-level  CMI8738
 19:    2732391   IO-APIC-level  nvidia
 20:    4315754   IO-APIC-level  ohci_hcd, eth0
 21: 1167427697   IO-APIC-level  ehci_hcd
 22:         79   IO-APIC-level  ohci_hcd

another thing that bugs me a little (a little offtopic here maybe), is the 
irq21 of ehci_hcd seems to get hit about twice as often as the timer irq 
although im not at all using USB...   any suggestions? maybe i start a second 
thread on this one...

attached: dmidecode output.

greets, christian.

pls CC on replies.

[-- Attachment #2: dmidecode.txt --]
[-- Type: text/plain, Size: 11463 bytes --]

# dmidecode 2.4
SMBIOS 2.3 present.
37 structures occupying 1049 bytes.
Table at 0x000F0000.
Handle 0x0000
	DMI type 0, 20 bytes.
	BIOS Information
		Vendor: Phoenix Technologies, LTD
		Version: 6.00 PG
		Release Date: 03/29/2004
		Address: 0xE0000
		Runtime Size: 128 kB
		ROM Size: 256 kB
		Characteristics:
			ISA is supported
			PCI is supported
			PNP is supported
			APM is supported
			BIOS is upgradeable
			BIOS shadowing is allowed
			Boot from CD is supported
			Selectable boot is supported
			BIOS ROM is socketed
			EDD is supported
			5.25"/360 KB floppy services are supported (int 13h)
			5.25"/1.2 MB floppy services are supported (int 13h)
			3.5"/720 KB floppy services are supported (int 13h)
			3.5"/2.88 MB floppy services are supported (int 13h)
			Print screen service is supported (int 5h)
			8042 keyboard services are supported (int 9h)
			Serial services are supported (int 14h)
			Printer services are supported (int 17h)
			CGA/mono video services are supported (int 10h)
			ACPI is supported
			USB legacy is supported
			AGP is supported
			LS-120 boot is supported
			ATAPI Zip drive boot is supported
			Function key-initiated network boot is supported
Handle 0x0001
	DMI type 1, 25 bytes.
	System Information
		Manufacturer:  
		Product Name:  
		Version:  
		Serial Number:  
		UUID: Not Present
		Wake-up Type: Power Switch
Handle 0x0002
	DMI type 2, 8 bytes.
	Base Board Information
		Manufacturer: MICRO-STAR INTERNATIONAL CO., LTD
		Product Name: MS-6570
		Version:  
		Serial Number:  
Handle 0x0003
	DMI type 3, 17 bytes.
	Chassis Information
		Manufacturer:  
		Type: Desktop
		Lock: Not Present
		Version:  
		Serial Number:  
		Asset Tag:  
		Boot-up State: Unknown
		Power Supply State: Unknown
		Thermal State: Unknown
		Security Status: Unknown
		OEM Information: 0x00000000
Handle 0x0004
	DMI type 4, 35 bytes.
	Processor Information
		Socket Designation: Socket A
		Type: Central Processor
		Family: Duron
		Manufacturer: AMD
		ID: 42 06 00 00 FF FB 83 01
		Signature: Family 6, Model 4, Stepping 2
		Flags:
			FPU (Floating-point unit on-chip)
			VME (Virtual mode extension)
			DE (Debugging extension)
			PSE (Page size extension)
			TSC (Time stamp counter)
			MSR (Model specific registers)
			PAE (Physical address extension)
			MCE (Machine check exception)
			CX8 (CMPXCHG8 instruction supported)
			APIC (On-chip APIC hardware supported)
			SEP (Fast system call)
			MTRR (Memory type range registers)
			PGE (Page global enable)
			MCA (Machine check architecture)
			CMOV (Conditional move instruction supported)
			PAT (Page attribute table)
			PSE-36 (36-bit page size extension)
			MMX (MMX technology supported)
			FXSR (Fast floating-point save and restore)
		Version: AMD Athlon(tm)
		Voltage: 1.7 V
		External Clock: 133 MHz
		Max Speed: 2200 MHz
		Current Speed: 1200 MHz
		Status: Populated, Enabled
		Upgrade: ZIF Socket
		L1 Cache Handle: 0x0009
		L2 Cache Handle: 0x000A
		L3 Cache Handle: Not Provided
		Serial Number:  
		Asset Tag:  
		Part Number:  
Handle 0x0005
	DMI type 5, 22 bytes.
	Memory Controller Information
		Error Detecting Method: 8-bit Parity
		Error Correcting Capabilities:
			None
		Supported Interleave: One-way Interleave
		Current Interleave: One-way Interleave
		Maximum Memory Module Size: 32 MB
		Maximum Total Memory Size: 96 MB
		Supported Speeds:
			70 ns
			60 ns
		Supported Memory Types:
			Standard
			EDO
		Memory Module Voltage: 5.0 V
		Associated Memory Slots: 3
			0x0006
			0x0007
			0x0008
		Enabled Error Correcting Capabilities: None
Handle 0x0006
	DMI type 6, 12 bytes.
	Memory Module Information
		Socket Designation: A0
		Bank Connections: None
		Current Speed: 10 ns
		Type: Other
		Installed Size: Not Installed (Single-bank Connection)
		Enabled Size: Not Installed (Single-bank Connection)
		Error Status: OK
Handle 0x0007
	DMI type 6, 12 bytes.
	Memory Module Information
		Socket Designation: A1
		Bank Connections: 2
		Current Speed: 10 ns
		Type: Other
		Installed Size: 512 MB (Single-bank Connection)
		Enabled Size: 512 MB (Single-bank Connection)
		Error Status: OK
Handle 0x0008
	DMI type 6, 12 bytes.
	Memory Module Information
		Socket Designation: A2
		Bank Connections: None
		Current Speed: 10 ns
		Type: Other
		Installed Size: Not Installed (Single-bank Connection)
		Enabled Size: Not Installed (Single-bank Connection)
		Error Status: OK
Handle 0x0009
	DMI type 7, 19 bytes.
	Cache Information
		Socket Designation: Internal Cache
		Configuration: Enabled, Not Socketed, Level 1
		Operational Mode: Write Back
		Location: Internal
		Installed Size: 128 KB
		Maximum Size: 128 KB
		Supported SRAM Types:
			Synchronous
		Installed SRAM Type: Synchronous
		Speed: Unknown
		Error Correction Type: Unknown
		System Type: Unknown
		Associativity: Unknown
Handle 0x000A
	DMI type 7, 19 bytes.
	Cache Information
		Socket Designation: External Cache
		Configuration: Enabled, Not Socketed, Level 2
		Operational Mode: Write Back
		Location: External
		Installed Size: 256 KB
		Maximum Size: 256 KB
		Supported SRAM Types:
			Synchronous
		Installed SRAM Type: Synchronous
		Speed: Unknown
		Error Correction Type: Unknown
		System Type: Unknown
		Associativity: Unknown
Handle 0x000B
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: PRIMARY IDE
		Internal Connector Type: On Board IDE
		External Reference Designator: Not Specified
		External Connector Type: None
		Port Type: Other
Handle 0x000C
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: SECONDARY IDE
		Internal Connector Type: On Board IDE
		External Reference Designator: Not Specified
		External Connector Type: None
		Port Type: Other
Handle 0x000D
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: FDD
		Internal Connector Type: On Board Floppy
		External Reference Designator: Not Specified
		External Connector Type: None
		Port Type: 8251 FIFO Compatible
Handle 0x000E
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: COM1
		Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
		External Reference Designator:  
		External Connector Type: DB-9 male
		Port Type: Serial Port 16450 Compatible
Handle 0x000F
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: COM2
		Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
		External Reference Designator:  
		External Connector Type: DB-9 male
		Port Type: Serial Port 16450 Compatible
Handle 0x0010
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: LPT1
		Internal Connector Type: DB-25 female
		External Reference Designator:  
		External Connector Type: DB-25 female
		Port Type: Parallel Port ECP/EPP
Handle 0x0011
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: Keyboard
		Internal Connector Type: PS/2
		External Reference Designator:  
		External Connector Type: PS/2
		Port Type: Keyboard Port
Handle 0x0012
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: PS/2 Mouse
		Internal Connector Type: PS/2
		External Reference Designator:  
		External Connector Type: PS/2
		Port Type: Mouse Port
Handle 0x0013
	DMI type 8, 9 bytes.
	Port Connector Information
		Internal Reference Designator: Not Specified
		Internal Connector Type: None
		External Reference Designator: USB
		External Connector Type: Other
		Port Type: USB
Handle 0x0014
	DMI type 9, 13 bytes.
	System Slot Information
		Designation: PCI0
		Type: 32-bit PCI
		Current Usage: Available
		Length: Long
		ID: 1
		Characteristics:
			5.0 V is provided
			PME signal is supported
Handle 0x0015
	DMI type 9, 13 bytes.
	System Slot Information
		Designation: PCI1
		Type: 32-bit PCI
		Current Usage: Available
		Length: Long
		ID: 2
		Characteristics:
			5.0 V is provided
			PME signal is supported
Handle 0x0016
	DMI type 9, 13 bytes.
	System Slot Information
		Designation: PCI2
		Type: 32-bit PCI
		Current Usage: In Use
		Length: Long
		ID: 3
		Characteristics:
			5.0 V is provided
			PME signal is supported
Handle 0x0017
	DMI type 9, 13 bytes.
	System Slot Information
		Designation: PCI3
		Type: 32-bit PCI
		Current Usage: In Use
		Length: Long
		ID: 4
		Characteristics:
			5.0 V is provided
			PME signal is supported
Handle 0x0018
	DMI type 9, 13 bytes.
	System Slot Information
		Designation: PCI4
		Type: 32-bit PCI
		Current Usage: Available
		Length: Long
		ID: 5
		Characteristics:
			5.0 V is provided
			PME signal is supported
Handle 0x0019
	DMI type 9, 13 bytes.
	System Slot Information
		Designation: AGP
		Type: 32-bit AGP
		Current Usage: Available
		Length: Long
		ID: 240
		Characteristics:
			5.0 V is provided
Handle 0x001A
	DMI type 13, 22 bytes.
	BIOS Language Information
		Installable Languages: 3
			n|US|iso8859-1
			n|US|iso8859-1
			r|CA|iso8859-1
		Currently Installed Language: n|US|iso8859-1
Handle 0x001B
	DMI type 16, 15 bytes.
	Physical Memory Array
		Location: System Board Or Motherboard
		Use: System Memory
		Error Correction Type: None
		Maximum Capacity: 1536 MB
		Error Information Handle: Not Provided
		Number Of Devices: 3
Handle 0x001C
	DMI type 17, 27 bytes.
	Memory Device
		Array Handle: 0x001B
		Error Information Handle: Not Provided
		Total Width: Unknown
		Data Width: Unknown
		Size: No Module Installed
		Form Factor: DIMM
		Set: None
		Locator: A0
		Bank Locator: Bank0/1
		Type: Unknown
		Type Detail: None
		Speed: Unknown
		Manufacturer: None
		Serial Number: None
		Asset Tag: None
		Part Number: None
Handle 0x001D
	DMI type 17, 27 bytes.
	Memory Device
		Array Handle: 0x001B
		Error Information Handle: Not Provided
		Total Width: Unknown
		Data Width: Unknown
		Size: 512 MB
		Form Factor: DIMM
		Set: None
		Locator: A1
		Bank Locator: Bank2/3
		Type: Unknown
		Type Detail: None
		Speed: Unknown
		Manufacturer: None
		Serial Number: None
		Asset Tag: None
		Part Number: None
Handle 0x001E
	DMI type 17, 27 bytes.
	Memory Device
		Array Handle: 0x001B
		Error Information Handle: Not Provided
		Total Width: Unknown
		Data Width: Unknown
		Size: No Module Installed
		Form Factor: DIMM
		Set: None
		Locator: A2
		Bank Locator: Bank4/5
		Type: Unknown
		Type Detail: None
		Speed: Unknown
		Manufacturer: None
		Serial Number: None
		Asset Tag: None
		Part Number: None
Handle 0x001F
	DMI type 19, 15 bytes.
	Memory Array Mapped Address
		Starting Address: 0x00000000000
		Ending Address: 0x0001FFFFFFF
		Range Size: 512 MB
		Physical Array Handle: 0x001B
		Partition Width: 0
Handle 0x0020
	DMI type 20, 19 bytes.
	Memory Device Mapped Address
		Starting Address: 0x00000000000
		Ending Address: 0x000000003FF
		Range Size: 1 kB
		Physical Device Handle: 0x001C
		Memory Array Mapped Address Handle: 0x001F
		Partition Row Position: 1
Handle 0x0021
	DMI type 20, 19 bytes.
	Memory Device Mapped Address
		Starting Address: 0x00000000000
		Ending Address: 0x0001FFFFFFF
		Range Size: 512 MB
		Physical Device Handle: 0x001D
		Memory Array Mapped Address Handle: 0x001F
		Partition Row Position: 1
Handle 0x0022
	DMI type 20, 19 bytes.
	Memory Device Mapped Address
		Starting Address: 0x00000000000
		Ending Address: 0x000000003FF
		Range Size: 1 kB
		Physical Device Handle: 0x001E
		Memory Array Mapped Address Handle: 0x001F
		Partition Row Position: 1
Handle 0x0023
	DMI type 32, 11 bytes.
	System Boot Information
		Status: No errors detected
Handle 0x0024
	DMI type 127, 4 bytes.
	End Of Table

Re: IO-APIC on nforce2 [PATCH]

[Len Brown]

On Thu, 2004-04-22 at 09:53, Christian Kröner wrote:
> since its becoming fancy to post dmidecode output

Thanks.  BTW. sending the dmidecode directly to me should be sufficient
should you have need to do so again.

> another thing i recently noticed (running 2.6.6-rc2-mm1 
> now) is that the last XT-PIC interrupt is gone now. i had cascade on
> irq2 
> routed as XT-PIC before, now cascade (whatever it is) doesnt exist 
> anymore ;).

Yes, this is normal on ACPI+IOAPIC configs going forward
details here:  http://bugzilla.kernel.org/show_bug.cgi?id=2564

> /proc/interrupts now:
> 
>   0:   32184529    IO-APIC-edge  timer
>   1:       1741    IO-APIC-edge  i8042
>   7:          0    IO-APIC-edge  parport0
>   8:          4    IO-APIC-edge  rtc
>   9:          0   IO-APIC-level  acpi
>  12:       9229    IO-APIC-edge  i8042
>  14:     107111    IO-APIC-edge  ide0
>  15:         92    IO-APIC-edge  ide1
>  16:       3138   IO-APIC-level  ide2, saa7134[0]
>  17:        153   IO-APIC-level  CMI8738
>  19:    2732391   IO-APIC-level  nvidia
>  20:    4315754   IO-APIC-level  ohci_hcd, eth0
>  21: 1167427697   IO-APIC-level  ehci_hcd
>  22:         79   IO-APIC-level  ohci_hcd


> another thing that bugs me a little (a little offtopic here maybe), is
> the 
> irq21 of ehci_hcd seems to get hit about twice as often as the timer
> irq 
> although im not at all using USB...   any suggestions? maybe i start a
> second 
> thread on this one...

Better yet, file a bug and we'll look at your ehci interrupt issue in
detail.

thanks,
-Len

How to file a bug against ACPI:

http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI

For failure and success case, please attach
1. dmesg -s64000, or serial console using "debug" on cmdline.
  (increase CONFIG_LOG_BUF_SHIFT if it doesn't get back to beginning)
2. /proc/interrupts
3. lspci -v

Please attach the output from acpidmp, available in /usr/sbin/, or in
pmtools:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

Re: IO-APIC on nforce2 [PATCH]

[Maciej W. Rozycki]

On Thu, 22 Apr 2004, Len Brown wrote:

> Yes, this is normal on ACPI+IOAPIC configs going forward
> details here:  http://bugzilla.kernel.org/show_bug.cgi?id=2564

 Except that the IRQ was reserved for plain 8259A setups, where it is
really used for a cascade for a slave 8259A, long before any APIC support
was there in Linux.  JFTR.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: IO-APIC on nforce2 [PATCH]

[Christian Kröner]

On Thursday 22 April 2004 17:27, you wrote:
> On Thu, 2004-04-22 at 09:53, Christian Kröner wrote:
> > since its becoming fancy to post dmidecode output
>
> Thanks.  BTW. sending the dmidecode directly to me should be sufficient
> should you have need to do so again.
>
> > another thing i recently noticed (running 2.6.6-rc2-mm1
> > now) is that the last XT-PIC interrupt is gone now. i had cascade on
> > irq2
> > routed as XT-PIC before, now cascade (whatever it is) doesnt exist
> > anymore ;).
>
> Yes, this is normal on ACPI+IOAPIC configs going forward
> details here:  http://bugzilla.kernel.org/show_bug.cgi?id=2564
>
> > /proc/interrupts now:
> >
> >   0:   32184529    IO-APIC-edge  timer
> >   1:       1741    IO-APIC-edge  i8042
> >   7:          0    IO-APIC-edge  parport0
> >   8:          4    IO-APIC-edge  rtc
> >   9:          0   IO-APIC-level  acpi
> >  12:       9229    IO-APIC-edge  i8042
> >  14:     107111    IO-APIC-edge  ide0
> >  15:         92    IO-APIC-edge  ide1
> >  16:       3138   IO-APIC-level  ide2, saa7134[0]
> >  17:        153   IO-APIC-level  CMI8738
> >  19:    2732391   IO-APIC-level  nvidia
> >  20:    4315754   IO-APIC-level  ohci_hcd, eth0
> >  21: 1167427697   IO-APIC-level  ehci_hcd
> >  22:         79   IO-APIC-level  ohci_hcd
> >
> >
> > another thing that bugs me a little (a little offtopic here maybe), is
> > the
> > irq21 of ehci_hcd seems to get hit about twice as often as the timer
> > irq
> > although im not at all using USB...   any suggestions? maybe i start a
> > second
> > thread on this one...
>
> Better yet, file a bug and we'll look at your ehci interrupt issue in
> detail.
>
> thanks,
> -Len
>
> How to file a bug against ACPI:
>
> http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
>
> For failure and success case, please attach
> 1. dmesg -s64000, or serial console using "debug" on cmdline.
>   (increase CONFIG_LOG_BUF_SHIFT if it doesn't get back to beginning)
> 2. /proc/interrupts
> 3. lspci -v
>
> Please attach the output from acpidmp, available in /usr/sbin/, or in
> pmtools:
> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

Since I don't know which category of ACPI bugtracking my "bug" fits into I 
send the symptom here:

cat /proc/interrupts

  0:   41075417    IO-APIC-edge  timer
  1:      27326    IO-APIC-edge  i8042
  7:          0    IO-APIC-edge  parport0
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:     226123    IO-APIC-edge  i8042
 14:     152298    IO-APIC-edge  ide0
 15:         92    IO-APIC-edge  ide1
 16:      28174   IO-APIC-level  ide2, saa7134[0]
 17:      86370   IO-APIC-level  CMI8738
 19:    3500294   IO-APIC-level  nvidia
 20:    5858400   IO-APIC-level  ohci_hcd, eth0
 21: 2678002320   IO-APIC-level  ehci_hcd
 22:         79   IO-APIC-level  ohci_hcd
NMI:      13435 
LOC:   40935121 
ERR:          0
MIS:          0

and the same only 5 seconds later:

  0:   41082729    IO-APIC-edge  timer
  1:      27350    IO-APIC-edge  i8042
  7:          0    IO-APIC-edge  parport0
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 12:     226123    IO-APIC-edge  i8042
 14:     152313    IO-APIC-edge  ide0
 15:         92    IO-APIC-edge  ide1
 16:      28243   IO-APIC-level  ide2, saa7134[0]
 17:      86515   IO-APIC-level  CMI8738
 19:    3500917   IO-APIC-level  nvidia
 20:    5859792   IO-APIC-level  ohci_hcd, eth0
 21: 2679242125   IO-APIC-level  ehci_hcd
 22:         79   IO-APIC-level  ohci_hcd
NMI:      13438 
LOC:   40942396 
ERR:          0
MIS:          0

It seems as if irq21 (ehci_hcd) got hit 1 239 805 times in only 5 seconds 
without me even using USB in that period.


Please tell me into which category I should file this issue and I will happily 
file a bug report right after...

thanks, christian.

RE: IO-APIC on nforce2 [PATCH]

[Allen Martin]

>  Allen, is there a possibility to get a clarification from 
> Nvidia on that?  
> Specifically, assuming both an 8254 and an I/O APIC core are 
> integrated
> into the chip, whether OUT0 of the 8254 is unconditionally routed to
> INTIN0 of the I/O APIC or is it configurable somehow.

The 8254 PIT is hardwared to IRQ0 on all nForce chipsets, it can't be routed.

-Allen

RE: IO-APIC on nforce2 [PATCH]

[Maciej W. Rozycki]

On Thu, 22 Apr 2004, Allen Martin wrote:

> The 8254 PIT is hardwared to IRQ0 on all nForce chipsets, it can't be routed.

 Thanks for this info.  Thus the workaround can be unconditional.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +