Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Zwane Mwaikambo]

On Sun, 1 Jun 2003, Con Kolivas wrote:

> I get the same problem here with acpi-20030522 applied to rc6
> P4 2.53 on an i845 mobo (P4PE).

I think it could be the Bus Mastering event monitoring thing, can you 
shoehorn this (HACK HACK) patch into 2.4?

Index: linux-2.5.70-mm1/drivers/acpi/processor.c
===================================================================
RCS file: /build/cvsroot/linux-2.5.70/drivers/acpi/processor.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 processor.c
--- linux-2.5.70-mm1/drivers/acpi/processor.c	27 May 2003 02:19:28 -0000	1.1.1.1
+++ linux-2.5.70-mm1/drivers/acpi/processor.c	29 May 2003 11:32:00 -0000
@@ -711,11 +711,13 @@ acpi_processor_get_power_info (
 		 * use this in our C3 policy.
 		 */
 		else {
+			goto done;
 			pr->power.states[ACPI_STATE_C3].valid = 1;
 			pr->power.states[ACPI_STATE_C3].latency_ticks = 
 				US_TO_PM_TIMER_TICKS(acpi_fadt.plvl3_lat);
 			pr->flags.bm_check = 1;
 		}
+		done:
 	}
 
 	/*
-- 
function.linuxpower.ca

ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Paul P Komkoff Jr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Replying to Andreas Haumer:
> 2.) ACPI itself doesn't work right anymore and makes the system
>     unusable... :-(
>     It did work with the last AC kernel I tried (2.4.21-rc2-ac2)
> 
>     Symptoms are:
>     No ethernet, NIC (Intel eepro100) doesn't get interrupts,
>     ACPI interrupt "storm" (millions of IRQ in a few minutes)
> 
>     Booting with "acpi=off" makes the system work again, but without
>     ACPI, of course.
> 
>     Here are a few more infos from the running system:
> 
>     Asus P4B motherboard, P4 1.6GHz processor, 1.2GB RAM

I am here experiencing almost same behavior, but I didnt collected enough
data to isolate the problem
few points:
1. It is new acpi code, backported by alan in latest -ac. Previous (2.4)
acpi "works" (err, it's outdated and more but at least no interrupt storm).
I didnt tried running 2.5 on the target machine yet.

2. all other devices working fine. The only visible things are slow mouse
responsiveness and >60k interrupts per second at vmstat output

The box is p4-based fujitsu scenic. More information is available on request.
And I will try 2.5 on it soon.

- -- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
 This message represents the official view of the voices in my head
-----BEGIN PGP SIGNATURE-----

iD8DBQE+2anlyMW8naS07KQRAgMpAJ9ZEMyG8EuRyAM/mis0lLK8/8Xw7QCgw0it
CZpTv8PL4In4Tn8iDn8oH1s=
=SvQM
-----END PGP SIGNATURE-----

Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Con Kolivas]

On Sun, 1 Jun 2003 17:23, Paul P Komkoff Jr wrote:
> Replying to Andreas Haumer:
> > 2.) ACPI itself doesn't work right anymore and makes the system
> >     unusable... :-(
> >     It did work with the last AC kernel I tried (2.4.21-rc2-ac2)
> >
> >     Symptoms are:
> >     No ethernet, NIC (Intel eepro100) doesn't get interrupts,
> >     ACPI interrupt "storm" (millions of IRQ in a few minutes)
> >
> >     Booting with "acpi=off" makes the system work again, but without
> >     ACPI, of course.
> >
> >     Here are a few more infos from the running system:
> >
> >     Asus P4B motherboard, P4 1.6GHz processor, 1.2GB RAM
>
> I am here experiencing almost same behavior, but I didnt collected enough
> data to isolate the problem
> few points:
> 1. It is new acpi code, backported by alan in latest -ac. Previous (2.4)
> acpi "works" (err, it's outdated and more but at least no interrupt storm).
> I didnt tried running 2.5 on the target machine yet.
>
> 2. all other devices working fine. The only visible things are slow mouse
> responsiveness and >60k interrupts per second at vmstat output
>
> The box is p4-based fujitsu scenic. More information is available on
> request. And I will try 2.5 on it soon.

I get the same problem here with acpi-20030522 applied to rc6
P4 2.53 on an i845 mobo (P4PE).

Con

RE: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Grover, Andrew]

I suspect this machine should be falling into one of the cases before
this last one, thus making ACPI not use C3, or check for bus-mastering.
I especially think this is the case because this appears to be a desktop
system. It should not have a C3 address or a plvl3_lat less than 1000,
yet it appears to, yes?

Regards -- Andy

> -----Original Message-----
> From: Zwane Mwaikambo [mailto:zwane@linuxpower.ca] 
> Sent: Sunday, June 01, 2003 12:23 AM
> To: Con Kolivas
> Cc: Paul P Komkoff Jr; linux-kernel@vger.kernel.org
> Subject: Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)
> Importance: High
> 
> 
> On Sun, 1 Jun 2003, Con Kolivas wrote:
> 
> > I get the same problem here with acpi-20030522 applied to rc6
> > P4 2.53 on an i845 mobo (P4PE).
> 
> I think it could be the Bus Mastering event monitoring thing, can you 
> shoehorn this (HACK HACK) patch into 2.4?
> 
> Index: linux-2.5.70-mm1/drivers/acpi/processor.c
> ===================================================================
> RCS file: /build/cvsroot/linux-2.5.70/drivers/acpi/processor.c,v
> retrieving revision 1.1.1.1
> diff -u -p -B -r1.1.1.1 processor.c
> --- linux-2.5.70-mm1/drivers/acpi/processor.c	27 May 2003 
> 02:19:28 -0000	1.1.1.1
> +++ linux-2.5.70-mm1/drivers/acpi/processor.c	29 May 2003 
> 11:32:00 -0000
> @@ -711,11 +711,13 @@ acpi_processor_get_power_info (
>  		 * use this in our C3 policy.
>  		 */
>  		else {
> +			goto done;
>  			pr->power.states[ACPI_STATE_C3].valid = 1;
>  			pr->power.states[ACPI_STATE_C3].latency_ticks = 
>  				
> US_TO_PM_TIMER_TICKS(acpi_fadt.plvl3_lat);
>  			pr->flags.bm_check = 1;
>  		}
> +		done:
>  	}
>  
>  	/*
> -- 
> function.linuxpower.ca
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Con Kolivas]

On Tue, 3 Jun 2003 07:01, Grover, Andrew wrote:
> I suspect this machine should be falling into one of the cases before
> this last one, thus making ACPI not use C3, or check for bus-mastering.
> I especially think this is the case because this appears to be a desktop
> system. It should not have a C3 address or a plvl3_lat less than 1000,
> yet it appears to, yes?

Sorry Andy I have no idea what you're talking about. Are there some details 
specifically about this machine you want me to provide?

Con
> > -----Original Message-----
> > From: Zwane Mwaikambo [mailto:zwane@linuxpower.ca]
> > On Sun, 1 Jun 2003, Con Kolivas wrote:
> > > I get the same problem here with acpi-20030522 applied to rc6
> > > P4 2.53 on an i845 mobo (P4PE).
> >
> > I think it could be the Bus Mastering event monitoring thing, can you
> > shoehorn this (HACK HACK) patch into 2.4?
> >
> > Index: linux-2.5.70-mm1/drivers/acpi/processor.c
> > ===================================================================
> > RCS file: /build/cvsroot/linux-2.5.70/drivers/acpi/processor.c,v
> > retrieving revision 1.1.1.1
> > diff -u -p -B -r1.1.1.1 processor.c
> > --- linux-2.5.70-mm1/drivers/acpi/processor.c	27 May 2003
> > 02:19:28 -0000	1.1.1.1
> > +++ linux-2.5.70-mm1/drivers/acpi/processor.c	29 May 2003
> > 11:32:00 -0000
> > @@ -711,11 +711,13 @@ acpi_processor_get_power_info (
> >  		 * use this in our C3 policy.
> >  		 */
> >  		else {
> > +			goto done;
> >  			pr->power.states[ACPI_STATE_C3].valid = 1;
> >  			pr->power.states[ACPI_STATE_C3].latency_ticks =
> >
> > US_TO_PM_TIMER_TICKS(acpi_fadt.plvl3_lat);
> >  			pr->flags.bm_check = 1;
> >  		}
> > +		done:
> >  	}
> >
> >  	/*

Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Con Kolivas]

On Tue, 3 Jun 2003 10:12, Con Kolivas wrote:
> On Tue, 3 Jun 2003 07:01, Grover, Andrew wrote:
> > I suspect this machine should be falling into one of the cases before
> > this last one, thus making ACPI not use C3, or check for bus-mastering.
> > I especially think this is the case because this appears to be a desktop
> > system. It should not have a C3 address or a plvl3_lat less than 1000,
> > yet it appears to, yes?
>
> Sorry Andy I have no idea what you're talking about. Are there some details
> specifically about this machine you want me to provide?

At least I can provide you with the acpi info from dmesg when it booted, and 
I'll try Zwane's hack in the near future to see if it helps.

Jun  1 16:32:45 localhost kernel: ACPI: Interpreter enabled
Jun  1 16:32:45 localhost kernel: ACPI: Using IOAPIC for interrupt routing
Jun  1 16:32:45 localhost kernel: ACPI: System [ACPI] (supports S0 S1 S4 S5)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 
6 7 9 10 11 12 14 15)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 
6 7 *9 10 11 12 14 15)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 
6 7 *9 10 11 12 14 15)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 
6 7 *9 10 11 12 14 15)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 
6 7 9 *10 11 12 14 15)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 
6 7 *9 10 11 12 14 15)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 
6 7 9 10 11 12 14 15, disabled)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 
6 7 9 10 *11 12 14 15)
Jun  1 16:32:45 localhost kernel: ACPI: PCI Root Bridge [PCI0] (00:00)
Jun  1 16:32:45 localhost kernel: PCI: Probing PCI hardware (bus 00)
Jun  1 16:32:45 localhost kernel: PCI: Ignoring BAR0-3 of IDE controller 
00:1f.1
Jun  1 16:32:45 localhost kernel: Transparent bridge - Intel Corp. 
82801BA/CA/DB PCI Bridge
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0._PRT]
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI1._PRT]
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Routing Table 
[\_SB_.PCI0.PCI2._PRT]
Jun  1 16:32:45 localhost kernel: PCI: Probing PCI hardware
Jun  1 16:32:45 localhost kernel: ACPI: PCI Interrupt Link [LNKG] enabled at 
IRQ 11
Jun  1 16:32:45 localhost kernel: IOAPIC[0]: Set PCI routing entry (2-16 -> 
0xb1 -> IRQ 16)
Jun  1 16:32:45 localhost kernel: 00:00:1d[A] -> 2-16 -> IRQ 16
Jun  1 16:32:45 localhost kernel: IOAPIC[0]: Set PCI routing entry (2-19 -> 
0xb9 -> IRQ 19)
Jun  1 16:32:45 localhost kernel: 00:00:1d[B] -> 2-19 -> IRQ 19
Jun  1 16:32:45 localhost kernel: IOAPIC[0]: Set PCI routing entry (2-18 -> 
0xc1 -> IRQ 18)
Jun  1 16:32:45 localhost kernel: 00:00:1d[C] -> 2-18 -> IRQ 18
Jun  1 16:32:45 localhost kernel: IOAPIC[0]: Set PCI routing entry (2-23 -> 
0xc9 -> IRQ 23)
Jun  1 16:32:45 localhost kernel: 00:00:1d[D] -> 2-23 -> IRQ 23
Jun  1 16:32:45 localhost kernel: Pin 2-18 already programmed
Jun  1 16:32:45 localhost kernel: IOAPIC[0]: Set PCI routing entry (2-17 -> 
0xd1 -> IRQ 17)
Jun  1 16:32:45 localhost kernel: 00:00:1f[B] -> 2-17 -> IRQ 17
Jun  1 16:32:45 localhost kernel: Pin 2-16 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-17 already programmed
Jun  1 16:32:45 localhost kernel: IOAPIC[0]: Set PCI routing entry (2-21 -> 
0xd9 -> IRQ 21)
Jun  1 16:32:45 localhost kernel: 00:02:09[A] -> 2-21 -> IRQ 21
Jun  1 16:32:45 localhost kernel: Pin 2-23 already programmed
Jun  1 16:32:45 localhost kernel: IOAPIC[0]: Set PCI routing entry (2-20 -> 
0xe1 -> IRQ 20)
Jun  1 16:32:45 localhost kernel: 00:02:09[D] -> 2-20 -> IRQ 20
Jun  1 16:32:45 localhost kernel: Pin 2-23 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-20 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-21 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-23 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-20 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-21 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-20 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-21 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-23 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-21 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-23 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-20 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-18 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-19 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-16 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-17 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-20 already programmed
Jun  1 16:32:45 localhost kernel: Pin 2-23 already programmed
Jun  1 16:32:45 localhost kernel: PCI: Using ACPI for IRQ routing
Jun  1 16:32:45 localhost kernel: PCI: if you experience problems, try using 
option 'pci=noacpi' or even 'acpi
=off'
Jun  1 16:32:45 localhost kernel: Linux NET4.0 for Linux 2.4
Jun  1 16:32:45 localhost kernel: Based upon Swansea University Computer 
Society NET3.039
Jun  1 16:32:45 localhost kernel: Initializing RT netlink socket
Jun  1 16:32:45 localhost kernel: Starting kswapd
Jun  1 16:32:45 localhost kernel: devfs: v1.12c (20020818) Richard Gooch 
(rgooch@atnf.csiro.au)
Jun  1 16:32:45 localhost kernel: devfs: boot_options: 0x1
Jun  1 16:32:45 localhost kernel: ACPI: Power Button (FF) [PWRF]
Jun  1 16:32:45 localhost kernel: ACPI: Processor [CPU0] (supports C1)
Jun  1 16:32:45 localhost kernel: ACPI: Processor [CPU1] (supports C1)


Con

Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Zwane Mwaikambo]

On Tue, 3 Jun 2003, Con Kolivas wrote:

> At least I can provide you with the acpi info from dmesg when it booted, and 
> I'll try Zwane's hack in the near future to see if it helps.

Andrew, i picked this up on the tailend of another bug report, there 
should be a new one opened but i haven't checked. I presume the tree you 
have in 2.5.70 and 2.4.21rc6-ac1 are relatively the same.

http://bugzilla.kernel.org/show_bug.cgi?id=370

-- 
function.linuxpower.ca

Re: ACPI interrupt storm (was Re: Linux 2.4.21rc6-ac1)

[Con Kolivas]

On Sun, 1 Jun 2003 17:23, Zwane Mwaikambo wrote:
> On Sun, 1 Jun 2003, Con Kolivas wrote:
> > I get the same problem here with acpi-20030522 applied to rc6
> > P4 2.53 on an i845 mobo (P4PE).
>
> I think it could be the Bus Mastering event monitoring thing, can you
> shoehorn this (HACK HACK) patch into 2.4?
>
> Index: linux-2.5.70-mm1/drivers/acpi/processor.c
> ===================================================================
> RCS file: /build/cvsroot/linux-2.5.70/drivers/acpi/processor.c,v
> retrieving revision 1.1.1.1
> diff -u -p -B -r1.1.1.1 processor.c
> --- linux-2.5.70-mm1/drivers/acpi/processor.c	27 May 2003 02:19:28
> -0000	1.1.1.1 +++ linux-2.5.70-mm1/drivers/acpi/processor.c	29 May 2003
> 11:32:00 -0000 @@ -711,11 +711,13 @@ acpi_processor_get_power_info (
>  		 * use this in our C3 policy.
>  		 */
>  		else {
> +			goto done;
>  			pr->power.states[ACPI_STATE_C3].valid = 1;
>  			pr->power.states[ACPI_STATE_C3].latency_ticks =
>  				US_TO_PM_TIMER_TICKS(acpi_fadt.plvl3_lat);
>  			pr->flags.bm_check = 1;
>  		}
> +		done:
>  	}
>
>  	/*

Ok I tried this hack. 

Here is vmstat before:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0      0 494640   4088   6628    0    0     0   240 82011    34  0  1 99  
and after:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0      0 494700   4052   6608    0    0     0   136 82182    32  0  1 99  

so it managed to give me another 100 or so interrupts on top of the 80k I was 
already getting; ie not much help
at about the same time I got a minor file system corruption but too many 
things happened together so I'm really not sure what that was.

Con