"irq 11: nobody cared" after S3

"irq 11: nobody cared" after S3

[Stefan Dösinger]

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

Hello,
I have a really odd problem with acpi interrupts and ipw2100.

I use 2.6.8-rc2 + acpi-20040715 and the system works fine after S3 as long no 
driver uses IRQ11. But if I have ipw2100 loaded before I suspend or load it 
afterwards, irq11 and irq10 are disabled.

The odd thing is that it worked for 2 days with the (hopefully) same 
configuration. Then I tried to make a clear patch which calls 
acpi_leave_sleep_state before resuming the devices which is needed on my 
notebook(see pci device resume too early?). I recombiled the kernel and my 
nice setup stopped working. Returning to the original code didn't help.

The problem occurs when ipw2100(or ndiswrapper) is loaded before I suspend(see 
dmesg.loadbefore) or if I load it after resume(see dmesg.loadlater. In both 
cases IRQ11 and IRQ10 are disabled. IRQ10 works nicely as long IRQ11 is not 
used. The IRQ crash occues eighter when PIT is resumed or when ipw2100 
registers the irq line.

This is my /proc/interrupts with a normally booted system(no S3):
           CPU0
  0:    1508252          XT-PIC  timer
  1:       2953          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:      19552          XT-PIC  uhci_hcd, eth0
  8:          2          XT-PIC  rtc
  9:        168          XT-PIC  acpi
 10:      94435          XT-PIC  ehci_hcd, uhci_hcd, uhci_hcd, 
radeon@PCI:1:0:0, Intel ICH4
 11:       1166          XT-PIC  wlan0
 12:       5382          XT-PIC  i8042
 14:      14433          XT-PIC  ide0
NMI:          0
LOC:    1508373
ERR:          0
MIS:          0

After this crash, 11 hase a count of exactly 100000.
I tried with  and without APIC, IOAPIC, hpet, power management timer.
If I reverse the patch from http://bugme.osdl.org/show_bug.cgi?id=2643, the 
messages disappear, but the interrupts still do not work.

Any ideas?
Best regards,
Stefan

[-- Attachment #2: dmesg.loadbefore.bz2 --]
[-- Type: application/x-bzip2, Size: 4670 bytes --]

[-- Attachment #3: dmesg.loadlater.bz2 --]
[-- Type: application/x-bzip2, Size: 4635 bytes --]

[-- Attachment #4: acpidump.out.bz2 --]
[-- Type: application/x-bzip2, Size: 12275 bytes --]

[-- Attachment #5: config.bz2 --]
[-- Type: application/x-bzip2, Size: 8267 bytes --]

Re: "irq 11: nobody cared" after S3

[Nathan Bryant]

Stefan Dösinger wrote:
> Hello,
> I have a really odd problem with acpi interrupts and ipw2100.
> 
> I use 2.6.8-rc2 + acpi-20040715 and the system works fine after S3 as long no 
> driver uses IRQ11. But if I have ipw2100 loaded before I suspend or load it 
> afterwards, irq11 and irq10 are disabled.
> 
> The odd thing is that it worked for 2 days with the (hopefully) same 
> configuration. Then I tried to make a clear patch which calls 
> acpi_leave_sleep_state before resuming the devices which is needed on my 
> notebook(see pci device resume too early?). I recombiled the kernel and my 
> nice setup stopped working. Returning to the original code didn't help.
> 
> The problem occurs when ipw2100(or ndiswrapper) is loaded before I suspend(see 
> dmesg.loadbefore) or if I load it after resume(see dmesg.loadlater. In both 
> cases IRQ11 and IRQ10 are disabled. IRQ10 works nicely as long IRQ11 is not 
> used. The IRQ crash occues eighter when PIT is resumed or when ipw2100 
> registers the irq line.

Does kernel command line "acpi=noirq" help?

> 
> This is my /proc/interrupts with a normally booted system(no S3):
>            CPU0
>   0:    1508252          XT-PIC  timer
>   1:       2953          XT-PIC  i8042
>   2:          0          XT-PIC  cascade
>   5:      19552          XT-PIC  uhci_hcd, eth0
>   8:          2          XT-PIC  rtc
>   9:        168          XT-PIC  acpi
>  10:      94435          XT-PIC  ehci_hcd, uhci_hcd, uhci_hcd, 
> radeon@PCI:1:0:0, Intel ICH4
>  11:       1166          XT-PIC  wlan0
>  12:       5382          XT-PIC  i8042
>  14:      14433          XT-PIC  ide0
> NMI:          0
> LOC:    1508373
> ERR:          0
> MIS:          0
> 
> After this crash, 11 hase a count of exactly 100000.
> I tried with  and without APIC, IOAPIC, hpet, power management timer.
> If I reverse the patch from http://bugme.osdl.org/show_bug.cgi?id=2643, the 
> messages disappear, but the interrupts still do not work.
> 
> Any ideas?
> Best regards,
> Stefan



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

RE: "irq 11: nobody cared" after S3

[Li, Shaohua]

I guess the bug is: ACPI sets LNKE's IRQ from 10 to 11 in boot time.
LNKE's register is at LPC bridge offset 0x68, but current PCI config
space save/restore code only handles first 0x40 bytes. After resume,
LNKE's register doesn't recover. So LNKE will actually route to 10, but
ACPI still thinks it routes to 11. Then you will get such error. I guess
such error is unavoidable unless LPC bridge driver exists (it can
save/restore all affected config space instead of first 0x40 bytes). 

Thanks,
Shaohua

>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-
>admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of stefandoesinger-RbZlAiThDcE@public.gmane.org
>Sent: Monday, August 02, 2004 12:50 AM
>To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: [ACPI] "irq 11: nobody cared" after S3
>
>Hello,
>I have a really odd problem with acpi interrupts and ipw2100.
>
>I use 2.6.8-rc2 + acpi-20040715 and the system works fine after S3 as
long
>no
>driver uses IRQ11. But if I have ipw2100 loaded before I suspend or
load it
>afterwards, irq11 and irq10 are disabled.
>
>The odd thing is that it worked for 2 days with the (hopefully) same
>configuration. Then I tried to make a clear patch which calls
>acpi_leave_sleep_state before resuming the devices which is needed on
my
>notebook(see pci device resume too early?). I recombiled the kernel and
my
>nice setup stopped working. Returning to the original code didn't help.
>
>The problem occurs when ipw2100(or ndiswrapper) is loaded before I
>suspend(see
>dmesg.loadbefore) or if I load it after resume(see dmesg.loadlater. In
both
>cases IRQ11 and IRQ10 are disabled. IRQ10 works nicely as long IRQ11 is
not
>used. The IRQ crash occues eighter when PIT is resumed or when ipw2100
>registers the irq line.
>
>This is my /proc/interrupts with a normally booted system(no S3):
>           CPU0
>  0:    1508252          XT-PIC  timer
>  1:       2953          XT-PIC  i8042
>  2:          0          XT-PIC  cascade
>  5:      19552          XT-PIC  uhci_hcd, eth0
>  8:          2          XT-PIC  rtc
>  9:        168          XT-PIC  acpi
> 10:      94435          XT-PIC  ehci_hcd, uhci_hcd, uhci_hcd,
>radeon@PCI:1:0:0, Intel ICH4
> 11:       1166          XT-PIC  wlan0
> 12:       5382          XT-PIC  i8042
> 14:      14433          XT-PIC  ide0
>NMI:          0
>LOC:    1508373
>ERR:          0
>MIS:          0
>
>After this crash, 11 hase a count of exactly 100000.
>I tried with  and without APIC, IOAPIC, hpet, power management timer.
>If I reverse the patch from http://bugme.osdl.org/show_bug.cgi?id=2643,
the
>messages disappear, but the interrupts still do not work.
>
>Any ideas?
>Best regards,
>Stefan


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: "irq 11: nobody cared" after S3

[Nathan Bryant]

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

Li, Shaohua wrote:
> I guess the bug is: ACPI sets LNKE's IRQ from 10 to 11 in boot time.
> LNKE's register is at LPC bridge offset 0x68, but current PCI config
> space save/restore code only handles first 0x40 bytes. After resume,
> LNKE's register doesn't recover. So LNKE will actually route to 10, but
> ACPI still thinks it routes to 11. Then you will get such error. I guess
> such error is unavoidable unless LPC bridge driver exists (it can
> save/restore all affected config space instead of first 0x40 bytes). 

Hi,

I agree with you, but I suspect a better fix is something like the 
attached diff, from my local tree. (My machine has similar problems, but 
this is not tested yet. Will test tonight and then send a patch to Len 
if it works out.)

[-- Attachment #2: acpi-fixes.patch --]
[-- Type: text/plain, Size: 2121 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/08/02 10:11:58-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org 
#   drivers/acpi/pci_link.c: remove setonboot from struct
#   acpi_pci_link_irq. Make acpi_pci_link_allocate() call the BIOS to
#   program the IRQ router every time it is called instead of only after
#   boot. This should hopefully fix problems with IRQ routing after
#   resume from S3 suspend. We can't rely on the bridge state being
#   saved/restored, because we don't have proper drivers for every
#   chipset, so instead we rely on the BIOS. Even pci_save_state only
#   saves the first 0x40 bytes of PCI config space; this is not enough
#   for PIIX.
# 
# drivers/acpi/pci_link.c
#   2004/08/02 10:11:50-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +0 -6
#   remove setonboot from struct
#   acpi_pci_link_irq. Make acpi_pci_link_allocate() call the BIOS to
#   program the IRQ router every time it is called instead of only after
#   boot. This should hopefully fix problems with IRQ routing after
#   resume from S3 suspend. We can't rely on the bridge state being
#   saved/restored, because we don't have proper drivers for every
#   chipset, so instead we rely on the BIOS. Even pci_save_state only
#   saves the first 0x40 bytes of PCI config space; this is not enough
#   for PIIX.
# 
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c	2004-08-02 10:14:23 -04:00
+++ b/drivers/acpi/pci_link.c	2004-08-02 10:14:23 -04:00
@@ -71,7 +71,6 @@
 	u8			active;			/* Current IRQ */
 	u8			edge_level;		/* All IRQs */
 	u8			active_high_low;	/* All IRQs */
-	u8			setonboot;
 	u8			resource_type;
 	u8			possible_count;
 	u8			possible[ACPI_PCI_LINK_MAX_POSSIBLE];
@@ -517,9 +516,6 @@
 
 	ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
 
-	if (link->irq.setonboot)
-		return_VALUE(0);
-
 	/*
 	 * search for active IRQ in list of possible IRQs.
 	 */
@@ -570,8 +566,6 @@
 			acpi_device_name(link->device),
 			acpi_device_bid(link->device), link->irq.active);
 	}
-
-	link->irq.setonboot = 1;
 
 	return_VALUE(0);
 }

RE: "irq 11: nobody cared" after S3

[Li, Shaohua]

I don't think your patch works, and even it works for your system, it
will break other systems. The goal of 'setonboot' is to prevent setting
LINK device's IRQ every time, which we added last year. Without it, many
systems will break. IIRC, its goal is to resolve a bug in bugzilla. But
currently I don't remember the exact bug number.

Thanks,
Shaohua
>-----Original Message-----
>From: Nathan Bryant [mailto:nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org]
>Sent: Monday, August 02, 2004 10:18 PM
>To: Li, Shaohua
>Cc: stefandoesinger-RbZlAiThDcE@public.gmane.org; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] "irq 11: nobody cared" after S3
>
>Li, Shaohua wrote:
>> I guess the bug is: ACPI sets LNKE's IRQ from 10 to 11 in boot time.
>> LNKE's register is at LPC bridge offset 0x68, but current PCI config
>> space save/restore code only handles first 0x40 bytes. After resume,
>> LNKE's register doesn't recover. So LNKE will actually route to 10,
but
>> ACPI still thinks it routes to 11. Then you will get such error. I
guess
>> such error is unavoidable unless LPC bridge driver exists (it can
>> save/restore all affected config space instead of first 0x40 bytes).
>
>Hi,
>
>I agree with you, but I suspect a better fix is something like the
>attached diff, from my local tree. (My machine has similar problems,
but
>this is not tested yet. Will test tonight and then send a patch to Len
>if it works out.)


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: "irq 11: nobody cared" after S3

[Nathan Bryant]

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

Li, Shaohua wrote:

>I don't think your patch works, and even it works for your system, it
>will break other systems. The goal of 'setonboot' is to prevent setting
>LINK device's IRQ every time, which we added last year. Without it, many
>systems will break. IIRC, its goal is to resolve a bug in bugzilla. But
>currently I don't remember the exact bug number.
>  
>
Thanks for the feedback. It works for my system--but only for devices 
that call pci_device_enable(). Therefore I am currently reinstating the 
"setonboot" flag and reworking the patch along the lines of the attached:

[-- Attachment #2: acpi-fixes.patch --]
[-- Type: text/x-patch, Size: 2202 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2004/08/02 20:41:54-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org 
#   [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
#   called when resuming from a suspend state that needs IRQ routing to be
#   restored. This fixes issues reported on the mailing lists, e.g.:
#   
#   http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
# 
# drivers/acpi/pci_link.c
#   2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +23 -0
#   [ACPI] drivers/acpi/pci_link.c: add acpi_pci_link_resume(), which will be
#   called when resuming from a suspend state that needs IRQ routing to be
#   restored. This fixes issues reported on the mailing lists, e.g.:
#   
#   http://marc.theaimsgroup.com/?l=acpi4linux&m=109142999328643&w=2
# 
# BitKeeper/etc/ignore
#   2004/08/02 20:41:45-04:00 nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org +2 -0
#   Added Module.symvers drivers/acpi/pci_link.c~ to the ignore list
# 
diff -Nru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c	2004-08-02 21:23:19 -04:00
+++ b/drivers/acpi/pci_link.c	2004-08-02 21:23:19 -04:00
@@ -55,6 +55,7 @@
 #define ACPI_PCI_LINK_MAX_POSSIBLE 16
 
 static int acpi_pci_link_add (struct acpi_device *device);
+static int acpi_pci_link_resume (struct acpi_device *device, int state);
 static int acpi_pci_link_remove (struct acpi_device *device, int type);
 
 static struct acpi_driver acpi_pci_link_driver = {
@@ -64,6 +65,7 @@
 	.ops =		{
 				.add =    acpi_pci_link_add,
 				.remove = acpi_pci_link_remove,
+				.resume = acpi_pci_link_resume,
 			},
 };
 
@@ -691,6 +693,27 @@
 		kfree(link);
 
 	return_VALUE(result);
+}
+
+
+static int
+acpi_pci_link_resume (
+	struct acpi_device	*device,
+	int state)
+{
+	struct acpi_pci_link *link = NULL;
+	
+	ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
+	
+	if (!device || !acpi_driver_data(device))
+		return_VALUE(-EINVAL);
+		
+	link = (struct acpi_pci_link *) acpi_driver_data(device);
+
+	if (link->irq.active && link->irq.setonboot)
+		return_VALUE(acpi_pci_link_set(link, link->irq.active));
+	else
+		return_VALUE(0);
 }
 
 

RE: "irq 11: nobody cared" after S3

[Li, Shaohua]

Actually current ACPI drivers don't support resume/suspend. :(. I also
consider adding a workaround to support Link device suspend/resume, but
you know it's just a workaround. Some guys may not agree to add a
workaround for the special case. For long term, LPC bridge driver should
do this.

Thanks,
Shaohua

>-----Original Message-----
>From: Nathan Bryant [mailto:nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org]
>Sent: Tuesday, August 03, 2004 9:28 AM
>To: Li, Shaohua
>Cc: stefandoesinger-RbZlAiThDcE@public.gmane.org; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: Re: [ACPI] "irq 11: nobody cared" after S3
>
>Li, Shaohua wrote:
>
>>I don't think your patch works, and even it works for your system, it
>>will break other systems. The goal of 'setonboot' is to prevent
setting
>>LINK device's IRQ every time, which we added last year. Without it,
many
>>systems will break. IIRC, its goal is to resolve a bug in bugzilla.
But
>>currently I don't remember the exact bug number.
>>
>>
>Thanks for the feedback. It works for my system--but only for devices
>that call pci_device_enable(). Therefore I am currently reinstating the
>"setonboot" flag and reworking the patch along the lines of the
attached:


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: "irq 11: nobody cared" after S3

[Nathan Bryant]

Li, Shaohua wrote:

>I don't think your patch works, and even it works for your system, it
>will break other systems. The goal of 'setonboot' is to prevent setting
>LINK device's IRQ every time, which we added last year. Without it, many
>systems will break. IIRC, its goal is to resolve a bug in bugzilla. But
>currently I don't remember the exact bug number.
>  
>
Hi, Shaohua,

I did some research on this, and came up with the original ChangeSet 
that introduced setonboot:

ChangeSet 1.1046.1.424 2003/07/29 13:28:32 agrover-qb8aLOKklSjp4P8CbLYnNQ@public.gmane.org
  ACPI: Allow irqs > 15 to use interrupt semantics other than PCI's standard
  active-low, level trigger. Make other changes as required for this.  
(Andrew de Quincey)

It looks like the setonboot flag was only introduced because calling the 
BIOS again might reset the edge/level and low/high flags. Judging by the 
ChangeSet message, the extra BIOS calls were not originally a problem, 
but getting rid of them was required for the additional edge/level feature.

If I can write my patch in such away that the link reconfiguration only 
gets called ONCE upon S3 resume, with interrupts disabled, and then 
resets the edge/level flags before re-enabling interrupts, will this be 
OK with you? This would save lots of work on several different low-level 
drivers. It might also fix the regressions that people are reporting 
with the ELCR save/restore patch.

This should be less of a "workaround" -- not at all of one, I hope ;)

Nathan


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: "irq 11: nobody cared" after S3

[Stefan Dösinger]

Hi,
> > I use 2.6.8-rc2 + acpi-20040715 and the system works fine after S3 as
> > long no driver uses IRQ11. But if I have ipw2100 loaded before I suspend
> > or load it afterwards, irq11 and irq10 are disabled.

> > The problem occurs when ipw2100(or ndiswrapper) is loaded before I
> > suspend(see dmesg.loadbefore) or if I load it after resume(see
> > dmesg.loadlater. In both cases IRQ11 and IRQ10 are disabled. IRQ10 works
> > nicely as long IRQ11 is not used. The IRQ crash occues eighter when PIT
> > is resumed or when ipw2100 registers the irq line.
>
> Does kernel command line "acpi=noirq" help?

Yes it does. Sorry for not mentioning this. I used pci=noacpi the last few 
weeks. This makes the wireless card use IRQ 10
It doesn't work very well thought, the IRQ10 and IRQ5 are unstable and the 
wireless and the sound block each other(Both IRQ 10), as well as USB and 
ethernet(IRQ 5). Additionally, DRI is unstable after resume.

I modified my DSDT to use IRQ 10 for LNKE, and that makes my system work 
perfectly. Is this a workaround or can I consider this a solution. The 
problem is, that half my hardware uses irq10 while the irqs 4,6,7,11,14 and 
15 are unused.
Shall I upload my modified dsdt? I think so.

Stefan


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

Re: "irq 11: nobody cared" after S3

[Nathan Bryant]

Stefan Dösinger wrote:
[snip]
>>Does kernel command line "acpi=noirq" help?
> 
> 
> Yes it does. Sorry for not mentioning this. I used pci=noacpi the last few 
> weeks. This makes the wireless card use IRQ 10
> It doesn't work very well thought, the IRQ10 and IRQ5 are unstable and the 
> wireless and the sound block each other(Both IRQ 10), as well as USB and 
> ethernet(IRQ 5). Additionally, DRI is unstable after resume.
> 
> I modified my DSDT to use IRQ 10 for LNKE, and that makes my system work 
> perfectly. Is this a workaround or can I consider this a solution. The 

This is a workaround. The ultimate solution is to have Linux restore the 
IRQ routing upon resume from S3. There is not yet a clear consensus 
about whether this needs to be done through the chipset drivers or the 
ACPI BIOS routines...

IMO, we need to make the ACPI BIOS IRQ routing code compatible with the 
non-ACPI IRQ routing code. This means that either they both should run 
only at boot/resume, or they both should NOT. Right now they are 
inconsistent...

> problem is, that half my hardware uses irq10 while the irqs 4,6,7,11,14 and 
> 15 are unused.
> Shall I upload my modified dsdt? I think so.

the ultimate solution is IRQ restore on resume. Your modified DSDT isn't 
really guaranteed to do the right thing for everyone forever, it just 
hardwires certain interrupts that Linux might want to dynamically assign 
in some circumstances...



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com