acpi-20040715: functional regression on ASUS M2N

acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

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

Hi all,

I just tried a kernel 2.6.8-rc2 with swsusp2-2.0.0.100 and some other
minor patches -- overall with great success. But when I updated from
the ACPI included in the kernel to the acpi-20040715 patch for 2.6.8,
suspend to ram does not work anymore: the machine hangs on resume.

Except for the network cards, which are broken after resume from S3,
it otherwise works fine for the previous ACPI versions with kernel
2.6.7 and kernel 2.6.8 -- which are the first kernels for which this
is true.

This is on an ASUS M2N with intel 855GM Centrino chipset, running the
Debian GNU/Linux distribution.

If you need more info, let me know.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve-BSDwwRMYa8fNLxjTenLetw@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
GNU Business Network                        (http://mailman.gnubiz.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Matthew Garrett]

On Tue, 2004-07-20 at 00:31, Georg C. F. Greve wrote:

> I just tried a kernel 2.6.8-rc2 with swsusp2-2.0.0.100 and some other
> minor patches -- overall with great success. But when I updated from
> the ACPI included in the kernel to the acpi-20040715 patch for 2.6.8,
> suspend to ram does not work anymore: the machine hangs on resume.

Do you get any output on the screen at all during resume?

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

Re: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

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

 || On Tue, 20 Jul 2004 20:03:17 +0100
 || Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> wrote: 

 >> I just tried a kernel 2.6.8-rc2 with swsusp2-2.0.0.100 and some
 >> other minor patches -- overall with great success. But when I
 >> updated from the ACPI included in the kernel to the acpi-20040715
 >> patch for 2.6.8, suspend to ram does not work anymore: the machine
 >> hangs on resume.

 mg> Do you get any output on the screen at all during resume?

Not with acpi-20040715. The screen remains entirely dead.

In fact my suspicion is that the whole machine has a problem, shutdown
does not work and even after a forced poweroff (keeping the power
button pressed for a while until machine shuts off) the screen is dead
when starting the machine again. I cannot say much more since it does
not even appear to boot.

Only after I took out the battery and took it off power for a while
did the machine come back to life, really.


With older versions, I see a yellow "inu" in the uppermost row for a
second, then the X server comes back up. I should mention at this time
that both DRI and AGP are compiled in and working fine.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 1432 bytes --]

Hi all,

okay, I did some more checks on the problems I experienced with
acpi-20040715 on Intel Centrino 855GM notebook ASUS M2N.

Background: As of kernel 2.6.7 suspend to RAM (s3_bios) actually
worked and even with DRI/DRM and AGP compiled in and the X server
running, things are working nicely. 

When restarting from suspend to RAM, I briefly see a yellow "inu" in
the uppermost row for a second, then the screen flickers once and X11
is back.

Only disadvantage: network cards (both wired & ipw2100 wireless) are
dead after suspend to ram, I need a suspend to disk (swsusp2 version
2.0.0.100) to bring them back to life. (referred to as "fine" below)

When upgrading to acpi-20040715 I discovered that resume from suspend
to RAM was broken. Contrary to what I wrote in my previous mail, it
seems that there is the yellow "inu" in the uppermost row and then the
machine is dead. (referred to as "dead" below)

I need a forced poweroff plus "needle-pushed reset button" to bring it
back to life.


Having had some time to let the machine compile in the background, I
narrowed down the code that broke the resume from suspend to RAM on my
machine. Apparently it was the patch that is supposed to fix the
network card problems.

When starting from a patched 2.6.7 with suspend to ram and resume
working fine as described above (=base), I have applied two patches

 (a) acpi-20040715

 (b) Fix ACPI after S3 patch of David Shaohua:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: http://bugme.osdl.org/attachment.cgi?id=3292&action=view --]
[-- Type: text/x-patch, Size: 2410 bytes --]

===== arch/i386/kernel/i8259.c 1.30 vs edited =====
--- 1.30/arch/i386/kernel/i8259.c	Thu Apr 22 19:15:40 2004
+++ edited/arch/i386/kernel/i8259.c	Tue Jun 29 15:35:28 2004
@@ -238,14 +238,39 @@
 	}
 }
 
+static char irq_trigger[2];
+/**
+ * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ
+ */
+static void restore_ELCR(char *trigger)
+{
+	outb(trigger[0], 0x4d0);
+	outb(trigger[1], 0x4d1);
+}
+
+static void save_ELCR(char *trigger)
+{
+	/* IRQ 0,1,2,8,13 are marked as reserved */
+	trigger[0] = inb(0x4d0) & 0xF8;
+	trigger[1] = inb(0x4d1) & 0xDE;
+}
+
 static int i8259A_resume(struct sys_device *dev)
 {
 	init_8259A(0);
+	restore_ELCR(irq_trigger);
+	return 0;
+}
+
+static int i8259A_suspend(struct sys_device *dev, u32 state)
+{
+	save_ELCR(irq_trigger);
 	return 0;
 }
 
 static struct sysdev_class i8259_sysdev_class = {
 	set_kset_name("i8259"),
+	.suspend = i8259A_suspend,
 	.resume = i8259A_resume,
 };
 
===== arch/x86_64/kernel/i8259.c 1.12 vs edited =====
--- 1.12/arch/x86_64/kernel/i8259.c	Wed Apr 21 08:55:12 2004
+++ edited/arch/x86_64/kernel/i8259.c	Tue Jun 29 15:36:08 2004
@@ -318,7 +318,7 @@
 	}
 }
 
-void __init init_8259A(int auto_eoi)
+void init_8259A(int auto_eoi)
 {
 	unsigned long flags;
 
@@ -360,6 +360,57 @@
 
 	spin_unlock_irqrestore(&i8259A_lock, flags);
 }
+
+static char irq_trigger[2];
+/**
+ * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ
+ */
+static void restore_ELCR(char *trigger)
+{
+	outb(trigger[0], 0x4d0);
+	outb(trigger[1], 0x4d1);
+}
+
+static void save_ELCR(char *trigger)
+{
+	/* IRQ 0,1,2,8,13 are marked as reserved */
+	trigger[0] = inb(0x4d0) & 0xF8;
+	trigger[1] = inb(0x4d1) & 0xDE;
+}
+
+static int i8259A_resume(struct sys_device *dev)
+{
+	init_8259A(0);
+	restore_ELCR(irq_trigger);
+	return 0;
+}
+
+static int i8259A_suspend(struct sys_device *dev, u32 state)
+{
+	save_ELCR(irq_trigger);
+	return 0;
+}
+
+static struct sysdev_class i8259_sysdev_class = {
+	set_kset_name("i8259"),
+	.suspend = i8259A_suspend,
+	.resume = i8259A_resume,
+};
+
+static struct sys_device device_i8259A = {
+	.id	= 0,
+	.cls	= &i8259_sysdev_class,
+};
+
+static int __init i8259A_init_sysfs(void)
+{
+	int error = sysdev_class_register(&i8259_sysdev_class);
+	if (!error)
+		error = sysdev_register(&device_i8259A);
+	return error;
+}
+
+device_initcall(i8259A_init_sysfs);
 
 /*
  * IRQ2 is cascade interrupt to second interrupt controller

[-- Attachment #1.3: Type: text/plain, Size: 714 bytes --]

     (from http://bugme.osdl.org/show_bug.cgi?id=2643 )

in the following combinations with the following results:

 base + (a) = dead

 base + (b) = dead

 base + (a) - (b) = fine


So applying the ACPI patch and reverse-applying the (b) patch to it
actually fixes the problem, although the network cards still remain
dead.

Which narrows the problem down to patch (b) as the one breaking
suspend to ram on ASUS M2N. Hope this helps tracking things down.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Matthew Garrett]

On Tue, 2004-07-27 at 12:14, Georg C. F. Greve wrote:

> Which narrows the problem down to patch (b) as the one breaking
> suspend to ram on ASUS M2N. Hope this helps tracking things down.

Can you try doing the following:

1) Open arch/i386/kernel/time.c
2) Find sysdev_class pit_sysclass
3) Change 

.resume = time_resume,

to

// .resume = time_resume,

4) Rebuild the kernel

You'll need to change your resume script to do a hwclock --hwtosys once
the system comes back up. If this works then it's the same problem that
I have - I have no idea what's causing it.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click

RE: acpi-20040715: functional regression on ASUS M2N

[Li, Shaohua]

Hi,
does a patch like below help your system? Please manually add it and
try. 

Thanks,
Shaohua

static int i8259A_resume(struct sys_device *dev)
 {
+	unsigned long flags;
 	init_8259A(0);
+ 
+	spin_lock_irqsave(&i8259A_lock, flags);
	restore_ELCR(irq_trigger);
+	spin_unlock_irqrestore(&i8259A_lock, flags);
	return 0;
}

>-----Original Message-----
>From: Georg C. F. Greve [mailto:greve-1r/uNngapc3YtjvyW6yDsg@public.gmane.org] On Behalf Of Georg C.
F.
>Greve
>Sent: Tuesday, July 27, 2004 7:14 PM
>To: Matthew Garrett
>Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Li, Shaohua
>Subject: Re: [ACPI] acpi-20040715: functional regression on ASUS M2N
>
>Hi all,
>
>okay, I did some more checks on the problems I experienced with
>acpi-20040715 on Intel Centrino 855GM notebook ASUS M2N.
>
>Background: As of kernel 2.6.7 suspend to RAM (s3_bios) actually
>worked and even with DRI/DRM and AGP compiled in and the X server
>running, things are working nicely.
>
>When restarting from suspend to RAM, I briefly see a yellow "inu" in
>the uppermost row for a second, then the screen flickers once and X11
>is back.
>
>Only disadvantage: network cards (both wired & ipw2100 wireless) are
>dead after suspend to ram, I need a suspend to disk (swsusp2 version
>2.0.0.100) to bring them back to life. (referred to as "fine" below)
>
>When upgrading to acpi-20040715 I discovered that resume from suspend
>to RAM was broken. Contrary to what I wrote in my previous mail, it
>seems that there is the yellow "inu" in the uppermost row and then the
>machine is dead. (referred to as "dead" below)
>
>I need a forced poweroff plus "needle-pushed reset button" to bring it
>back to life.
>
>
>Having had some time to let the machine compile in the background, I
>narrowed down the code that broke the resume from suspend to RAM on my
>machine. Apparently it was the patch that is supposed to fix the
>network card problems.
>
>When starting from a patched 2.6.7 with suspend to ram and resume
>working fine as described above (=base), I have applied two patches
>
> (a) acpi-20040715
>
> (b) Fix ACPI after S3 patch of David Shaohua:


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id\x10040&op=click

Re: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

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

 || On Tue, 27 Jul 2004 12:24:22 +0100
 || Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> wrote: 

 >> Which narrows the problem down to patch (b) as the one breaking
 >> suspend to ram on ASUS M2N. Hope this helps tracking things down.

 mg> Can you try doing the following:

 mg> 1) Open arch/i386/kernel/time.c
 mg> 2) Find sysdev_class pit_sysclass
 mg> 3) Change 

 mg> .resume = time_resume,
 mg> to
 mg> // .resume = time_resume,
 mg> 4) Rebuild the kernel

Tried it. No effect.

Did not change anything as far as I could tell. Problem persists.


 mg> You'll need to change your resume script to do a hwclock
 mg> --hwtosys once the system comes back up.

I've actually always had that. :)


 mg> If this works then it's the same problem that
 mg> I have - I have no idea what's causing it.

It seems to be a different problem, then.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

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

 || On Tue, 27 Jul 2004 20:24:29 +0800
 || "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: 

 ls> does a patch like below help your system? Please manually add it
 ls> and try.

I added your suggested patch to

  arch/i386/kernel/i8259.c

and recompiled. 

Problem persists, no difference I could tell.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Nathan Bryant]

> I added your suggested patch to
> 
>   arch/i386/kernel/i8259.c
> 
> and recompiled. 
> 
> Problem persists, no difference I could tell.

I don't know why the patch masks out the reserved interrupts. None of 
the other code that sets ELCR is masking out those bits, and it all 
works fine. Possibly some chipsets use different edge/level behavior for 
these, and the save code is forcing them back to edge. Does the problem 
persist if you go into arch/i386/kernel/i8259.c and change:

static void save_ELCR(char *trigger)
{
         /* IRQ 0,1,2,8,13 are marked as reserved */
         trigger[0] = inb(0x4d0) & 0xF8;
         trigger[1] = inb(0x4d1) & 0xDE;
}

to:

static void save_ELCR(char *trigger)
{
         /* IRQ 0,1,2,8,13 are marked as reserved */
         trigger[0] = inb(0x4d0);
         trigger[1] = inb(0x4d1);
}



-------------------------------------------------------
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: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 697 bytes --]

 || On Mon, 02 Aug 2004 12:45:16 -0400
 || Nathan Bryant <nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org> wrote: 

 >> I added your suggested patch to arch/i386/kernel/i8259.c and
 >> recompiled. Problem persists, no difference I could tell.

 nb> I don't know why the patch masks out the reserved
 nb> interrupts. None of the other code that sets ELCR is masking out
 nb> those bits, and it all works fine. Possibly some chipsets use
 nb> different edge/level behavior for these, and the save code is
 nb> forcing them back to edge.  Does the problem persist if you go
 nb> into arch/i386/kernel/i8259.c and change: [...]

Yup. Problem persists.

Just took a working, patched 2.6.7 and applied


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: fix-acpi-after-s3.patch --]
[-- Type: text/x-patch, Size: 2410 bytes --]

===== arch/i386/kernel/i8259.c 1.30 vs edited =====
--- 1.30/arch/i386/kernel/i8259.c	Thu Apr 22 19:15:40 2004
+++ edited/arch/i386/kernel/i8259.c	Tue Jun 29 15:35:28 2004
@@ -238,14 +238,39 @@
 	}
 }
 
+static char irq_trigger[2];
+/**
+ * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ
+ */
+static void restore_ELCR(char *trigger)
+{
+	outb(trigger[0], 0x4d0);
+	outb(trigger[1], 0x4d1);
+}
+
+static void save_ELCR(char *trigger)
+{
+	/* IRQ 0,1,2,8,13 are marked as reserved */
+	trigger[0] = inb(0x4d0) & 0xF8;
+	trigger[1] = inb(0x4d1) & 0xDE;
+}
+
 static int i8259A_resume(struct sys_device *dev)
 {
 	init_8259A(0);
+	restore_ELCR(irq_trigger);
+	return 0;
+}
+
+static int i8259A_suspend(struct sys_device *dev, u32 state)
+{
+	save_ELCR(irq_trigger);
 	return 0;
 }
 
 static struct sysdev_class i8259_sysdev_class = {
 	set_kset_name("i8259"),
+	.suspend = i8259A_suspend,
 	.resume = i8259A_resume,
 };
 
===== arch/x86_64/kernel/i8259.c 1.12 vs edited =====
--- 1.12/arch/x86_64/kernel/i8259.c	Wed Apr 21 08:55:12 2004
+++ edited/arch/x86_64/kernel/i8259.c	Tue Jun 29 15:36:08 2004
@@ -318,7 +318,7 @@
 	}
 }
 
-void __init init_8259A(int auto_eoi)
+void init_8259A(int auto_eoi)
 {
 	unsigned long flags;
 
@@ -360,6 +360,57 @@
 
 	spin_unlock_irqrestore(&i8259A_lock, flags);
 }
+
+static char irq_trigger[2];
+/**
+ * ELCR registers (0x4d0, 0x4d1) control edge/level of IRQ
+ */
+static void restore_ELCR(char *trigger)
+{
+	outb(trigger[0], 0x4d0);
+	outb(trigger[1], 0x4d1);
+}
+
+static void save_ELCR(char *trigger)
+{
+	/* IRQ 0,1,2,8,13 are marked as reserved */
+	trigger[0] = inb(0x4d0) & 0xF8;
+	trigger[1] = inb(0x4d1) & 0xDE;
+}
+
+static int i8259A_resume(struct sys_device *dev)
+{
+	init_8259A(0);
+	restore_ELCR(irq_trigger);
+	return 0;
+}
+
+static int i8259A_suspend(struct sys_device *dev, u32 state)
+{
+	save_ELCR(irq_trigger);
+	return 0;
+}
+
+static struct sysdev_class i8259_sysdev_class = {
+	set_kset_name("i8259"),
+	.suspend = i8259A_suspend,
+	.resume = i8259A_resume,
+};
+
+static struct sys_device device_i8259A = {
+	.id	= 0,
+	.cls	= &i8259_sysdev_class,
+};
+
+static int __init i8259A_init_sysfs(void)
+{
+	int error = sysdev_class_register(&i8259_sysdev_class);
+	if (!error)
+		error = sysdev_register(&device_i8259A);
+	return error;
+}
+
+device_initcall(i8259A_init_sysfs);
 
 /*
  * IRQ2 is cascade interrupt to second interrupt controller

[-- Attachment #1.3: Type: text/plain, Size: 40 bytes --]


which is causing the problem and also


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.4: S3-fix.patch --]
[-- Type: text/x-patch, Size: 660 bytes --]

--- arch/i386/kernel/i8259.c.orig	2004-08-04 01:44:05.000000000 +0200
+++ arch/i386/kernel/i8259.c	2004-08-04 01:45:43.000000000 +0200
@@ -251,14 +251,18 @@ static void restore_ELCR(char *trigger)
 static void save_ELCR(char *trigger)
 {
 	/* IRQ 0,1,2,8,13 are marked as reserved */
-	trigger[0] = inb(0x4d0) & 0xF8;
-	trigger[1] = inb(0x4d1) & 0xDE;
+	trigger[0] = inb(0x4d0);
+	trigger[1] = inb(0x4d1);
 }
 
 static int i8259A_resume(struct sys_device *dev)
 {
-	init_8259A(0);
+	unsigned long flags;
+ 	init_8259A(0);
+ 
+	spin_lock_irqsave(&i8259A_lock, flags);
 	restore_ELCR(irq_trigger);
+	spin_unlock_irqrestore(&i8259A_lock, flags);
 	return 0;
 }
 

[-- Attachment #1.5: Type: text/plain, Size: 659 bytes --]


which we hoped to be fixing the problem.

The machine goes into S3 and upon wake up shows same behaviour as
without "hopefully fixing patch": Crashes with "inu" in yellow on the
left in upper row visible. After poweroff, only "needle-pushed reset"
will bring it back to life.

So current ACPI is still showing functional regression on ASUS M2N.

Anyone other ideas? Anyone ready to solve the puzzle?

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Nathan Bryant]

Hi all. Some thoughts on this:

The ELCR save/restore patch is causing regressions for some people. What 
if the problem is that we're saving/restoring registers at the wrong time?

For example, on the Intel PIIX, the PIC is a child of PCI device 
31:function 0. What if this PCI device is disabled at the time we decide 
to save ELCR? If the I/O space is not mapped, we would probably read 
0xff in this case, I think, and I think that would set everything to 
level. What could be disabling it?

Georg, can you add some printk's to save_ELCR and log the values that we 
are actually saving?

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: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

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

 || On Thu, 05 Aug 2004 14:49:48 -0400
 || Nathan Bryant <nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org> wrote: 

 nb> Georg, can you add some printk's to save_ELCR and log the values
 nb> that we are actually saving?

I'll be glad to do that, but will have to see how to do it in a way
that I actually see what is printed. Haven't done much kernel hacking
really, is there "the right way" to do it?

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Nathan Bryant]

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

Georg C. F. Greve wrote:

> nb> Georg, can you add some printk's to save_ELCR and log the values
> nb> that we are actually saving?
>
>I'll be glad to do that, but will have to see how to do it in a way
>that I actually see what is printed. Haven't done much kernel hacking
>really, is there "the right way" to do it?
>  
>
The attached patch is good enough. Since the call to restore_ELCR is 
crashing you, we comment it out, and log the raw values from save_ELCR:

By the way, can you send the output of lspci?

[-- Attachment #2: elcrlog.patch --]
[-- Type: text/x-patch, Size: 870 bytes --]

===== arch/i386/kernel/i8259.c 1.35 vs edited =====
--- 1.35/arch/i386/kernel/i8259.c	2004-07-14 16:00:16 -04:00
+++ edited/arch/i386/kernel/i8259.c	2004-08-06 09:33:02 -04:00
@@ -244,21 +244,23 @@
  */
 static void restore_ELCR(char *trigger)
 {
-	outb(trigger[0], 0x4d0);
-	outb(trigger[1], 0x4d1);
+	/* IRQ 0,1,2,8,13 are marked as reserved */
+	outb(trigger[0] & 0xF8, 0x4d0);
+	outb(trigger[1] & 0xDE, 0x4d1);
 }
 
 static void save_ELCR(char *trigger)
 {
-	/* IRQ 0,1,2,8,13 are marked as reserved */
-	trigger[0] = inb(0x4d0) & 0xF8;
-	trigger[1] = inb(0x4d1) & 0xDE;
+	trigger[0] = inb(0x4d0);
+	trigger[1] = inb(0x4d1);
+	printk(KERN_DEBUG "i8259: saving ELCR: 0x%02x 0x%02x\n",
+		trigger[0], trigger[1]);
 }
 
 static int i8259A_resume(struct sys_device *dev)
 {
 	init_8259A(0);
-	restore_ELCR(irq_trigger);
+	/*restore_ELCR(irq_trigger);*/
 	return 0;
 }
 

Re: acpi-20040715: functional regression on ASUS M2N

[Matthew Garrett]

On Thu, 2004-08-05 at 14:49 -0400, Nathan Bryant wrote:

> The ELCR save/restore patch is causing regressions for some people. What 
> if the problem is that we're saving/restoring registers at the wrong time?

On closer investigation, I found that the system was restoring my ioapic
state /after/ it had started the programmable interrupt timer back up.
Changing line 310 of drivers/base/sys.c to list_for_each_entry_reverse
seems to have greatly improved my ability to suspend and resume (which
worked fine before the interrupt controller suspend/resume patches,
except that I didn't get many interrupts...) 

There doesn't seem to be any fine-grained way to control the order of
suspend/resume for individual drivers. It seems to be assumed that
everything that devices depend on will be higher than them in the tree,
and so everything will "just work" - I'm not sure this is true. As
another example, I just had my wireless card fail to resume correctly.
It tried to do a hotplug firmware load on resume. Which was difficult,
because it was resumed before the IDE interface was. How can this sort
of thing be avoided?

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
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: acpi-20040715: functional regression on ASUS M2N

[Nathan Bryant]

Matthew Garrett wrote:
> On Thu, 2004-08-05 at 14:49 -0400, Nathan Bryant wrote:
> 
> 
>>The ELCR save/restore patch is causing regressions for some people. What 
>>if the problem is that we're saving/restoring registers at the wrong time?
> 
> 
> On closer investigation, I found that the system was restoring my ioapic
> state /after/ it had started the programmable interrupt timer back up.
> Changing line 310 of drivers/base/sys.c to list_for_each_entry_reverse
> seems to have greatly improved my ability to suspend and resume (which
> worked fine before the interrupt controller suspend/resume patches,
> except that I didn't get many interrupts...) 
> 
> There doesn't seem to be any fine-grained way to control the order of
> suspend/resume for individual drivers. It seems to be assumed that
> everything that devices depend on will be higher than them in the tree,
> and so everything will "just work" - I'm not sure this is true. As

Oh, of course it isn't true. Everyone's just keeping their fingers 
crossed and hoping to avoid moving resume logic into complex special 
cases. But we might have to go there regardless...

In this case, it may make sense to consolidate all 
interrupt-controller-related suspend/resume into a single logical sys 
device so that we'll be sure to get the order right within that module.

Been thinking about this lately. There is some evidence that we may 
eventually need resume drivers for southbridge components. For example, 
my ACPI BIOS doesn't restore the ICH2 LPC bridge's SW_IRQ_GEN register 
on resume, which leads to some benign debug messages that might be 
concerning to some people who didn't know what the real problem is... 
this register is responsible for masking out IRQ1 and/or IRQ12 in 
legacy-free systems.

But if these southbridge components get their callbacks as a pci_driver, 
they might run AFTER various sys devices that are more accurately 
considered children of the south bridge: for example the PIC and the irq 
router.

> another example, I just had my wireless card fail to resume correctly.
> It tried to do a hotplug firmware load on resume. Which was difficult,
> because it was resumed before the IDE interface was. How can this sort
> of thing be avoided?
> 

That's a little more "interesting"...two possibilities
1) find a more generic mechanism to handle these special-case 
dependencies ;) Maybe let drivers register themselves as depending on 
other component classes, and then do a topological sort...
2) move everything that this driver needs to hotplug itself into kernel 
space



-------------------------------------------------------
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: acpi-20040715: functional regression on ASUS M2N

[Nate Lawson]

Matthew Garrett wrote:
> On Thu, 2004-08-05 at 14:49 -0400, Nathan Bryant wrote:
>>The ELCR save/restore patch is causing regressions for some people. What 
>>if the problem is that we're saving/restoring registers at the wrong time?
> 
> 
> On closer investigation, I found that the system was restoring my ioapic
> state /after/ it had started the programmable interrupt timer back up.
> Changing line 310 of drivers/base/sys.c to list_for_each_entry_reverse
> seems to have greatly improved my ability to suspend and resume (which
> worked fine before the interrupt controller suspend/resume patches,
> except that I didn't get many interrupts...) 
> 
> There doesn't seem to be any fine-grained way to control the order of
> suspend/resume for individual drivers. It seems to be assumed that
> everything that devices depend on will be higher than them in the tree,
> and so everything will "just work" - I'm not sure this is true. As
> another example, I just had my wireless card fail to resume correctly.
> It tried to do a hotplug firmware load on resume. Which was difficult,
> because it was resumed before the IDE interface was. How can this sort
> of thing be avoided?

With a real device framework.  We (FreeBSD) propagate suspend requests 
throough our generic device structure.  Each parent and child has a 
method which can be overridden.  This starts at the root and is 
propagated downward.

For instance, the PCI driver has methods that save/restore BARs:
         DEVMETHOD(device_suspend,       pci_suspend),
         DEVMETHOD(device_resume,        pci_resume),

The suspend function does its work and then calls bus_generic_suspend() 
which propagates the request down to the children.  Or if it knows that 
it needs to run after all children have suspended, it calls 
bus_generic_suspend() first, then does its work.

/**
  * @brief Helper function for implementing DEVICE_SUSPEND()
  *
  * This function can be used to help implement the DEVICE_SUSPEND()
  * for a bus. It calls DEVICE_SUSPEND() for each of the device's
  * children. If any call to DEVICE_SUSPEND() fails, the suspend
  * operation is aborted and any devices which were suspended are
  * resumed immediately by calling their DEVICE_RESUME() methods.
  */
int
bus_generic_suspend(device_t dev)
{
         int             error;
         device_t        child, child2;

         TAILQ_FOREACH(child, &dev->children, link) {
                 error = DEVICE_SUSPEND(child);
                 if (error) {
                         for (child2 = TAILQ_FIRST(&dev->children);
                              child2 && child2 != child;
                              child2 = TAILQ_NEXT(child2, link))
                                 DEVICE_RESUME(child2);
                         return (error);
                 }
         }
         return (0);
}

The key helpful thing is that each driver can specify its own methods 
through its device object but they can be called in a generic way.  For 
instance, if the root bus does "device_suspend(pci_dev)", then the 
actual function call expanded at run time is "pci_suspend(pci_dev)"

-Nate


-------------------------------------------------------
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: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 505 bytes --]

 || On Fri, 06 Aug 2004 09:36:04 -0400
 || Nathan Bryant <nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org> wrote: 

 nb> The attached patch is good enough. Since the call to restore_ELCR
 nb> is crashing you, we comment it out, and log the raw values from
 nb> save_ELCR:

Thanks.

Okay, took same 2.6.7, applied patches.

Here is what it said for my machine during resume from suspend to ram:

  i8259: saving ELCR: 0xfffffff0 0x0a


 nb> By the way, can you send the output of lspci?

Sure, here it is:

[-- Attachment #1.2: lspci-vvv --]
[-- Type: application/octet-stream, Size: 10482 bytes --]

0000:00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
	Subsystem: Asustek Computer, Inc.: Unknown device 1751
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Region 0: Memory at <unassigned> (32-bit, prefetchable)
	Capabilities: [40] #09 [a105]

0000:00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control Registers (rev 02)
	Subsystem: Asustek Computer, Inc.: Unknown device 175a
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

0000:00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process Registers (rev 02)
	Subsystem: Asustek Computer, Inc.: Unknown device 175b
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA])
	Subsystem: Asustek Computer, Inc.: Unknown device 1712
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K]
	Region 2: I/O ports at dc00 [size=8]
	Capabilities: [d0] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02)
	Subsystem: Asustek Computer, Inc.: Unknown device 1712
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at ff980000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [d0] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 1758
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 11
	Region 4: I/O ports at d480 [size=32]

0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 1758
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 5
	Region 4: I/O ports at d800 [size=32]

0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 1758
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin C routed to IRQ 7
	Region 4: I/O ports at d880 [size=32]

0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 03) (prog-if 20 [EHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 1759
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin D routed to IRQ 4
	Region 0: Memory at ffa7fc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] #0a [2080]

0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 83) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR+
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: ff700000-ff7fffff
	Prefetchable memory behind bridge: dea00000-deafffff
	BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-

0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03) (prog-if 8a [Master SecP PriP])
	Subsystem: Asustek Computer, Inc.: Unknown device 1758
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 7
	Region 0: I/O ports at <unassigned>
	Region 1: I/O ports at <unassigned>
	Region 2: I/O ports at <unassigned>
	Region 3: I/O ports at <unassigned>
	Region 4: I/O ports at ffa0 [size=16]
	Region 5: Memory at 1f800000 (32-bit, non-prefetchable) [size=1K]

0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
	Subsystem: Asustek Computer, Inc.: Unknown device 1713
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 6
	Region 0: I/O ports at e000 [size=256]
	Region 1: I/O ports at e100 [size=64]
	Region 2: Memory at 1f800400 (32-bit, non-prefetchable) [size=512]
	Region 3: Memory at 1f800600 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:03.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a9)
	Subsystem: Asustek Computer, Inc.: Unknown device 1754
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168
	Interrupt: pin A routed to IRQ 6
	Region 0: Memory at 1f801000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=01, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 1fc00000-1ffff000 (prefetchable)
	Memory window 1: 20000000-203ff000
	I/O window 0: 00004000-000040ff
	I/O window 1: 00004400-000044ff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

0000:01:03.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a9)
	Subsystem: Asustek Computer, Inc.: Unknown device 1754
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168
	Interrupt: pin B routed to IRQ 7
	Region 0: Memory at 1f802000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=01, secondary=06, subordinate=09, sec-latency=176
	Memory window 0: 20400000-207ff000 (prefetchable)
	Memory window 1: 20800000-20bff000
	I/O window 0: 00004800-000048ff
	I/O window 1: 00004c00-00004cff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

0000:01:03.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 01) (prog-if 10 [OHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 1757
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (500ns min, 1000ns max)
	Interrupt: pin C routed to IRQ 11
	Region 0: Memory at ff7ef000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME+

0000:01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
	Subsystem: Asustek Computer, Inc.: Unknown device 1045
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at c800 [size=256]
	Region 1: Memory at ff7efc00 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:01:05.0 Network controller: Intel Corp. PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)
	Subsystem: Intel Corp. MIM2000/Centrino
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (500ns min, 8500ns max), Cache Line Size: 0x10 (64 bytes)
	Interrupt: pin A routed to IRQ 7
	Region 0: Memory at ff7ff000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=1 PME-


[-- Attachment #1.3: Type: text/plain, Size: 478 bytes --]


If you want to know more about my machine, you can also check out

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

which is where I also gave some more info.

If I can help you with anything else, please let me know.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Nathan Bryant]

Georg C. F. Greve wrote:

> Here is what it said for my machine during resume from suspend to ram:
> 
>   i8259: saving ELCR: 0xfffffff0 0x0a

Interesting. That translates into the following IRQ's set to level trigger:

4
5
6 (!) floppy controller?
7
9
11

But I don't think there's anything wrong with that. It does seem that 
Matthew Garrett's message holds the key:

He wrote:
> On Thu, 2004-08-05 at 14:49 -0400, Nathan Bryant wrote:
> 
> 
>>> The ELCR save/restore patch is causing regressions for some people. What 
>>> if the problem is that we're saving/restoring registers at the wrong time?
> 
> 
> On closer investigation, I found that the system was restoring my ioapic
> state /after/ it had started the programmable interrupt timer back up.
> Changing line 310 of drivers/base/sys.c to list_for_each_entry_reverse
> seems to have greatly improved my ability to suspend and resume (which
> worked fine before the interrupt controller suspend/resume patches,
> except that I didn't get many interrupts...) 
> 
> There doesn't seem to be any fine-grained way to control the order of
> suspend/resume for individual drivers. It seems to be assumed that
> everything that devices depend on will be higher than them in the tree,
> and so everything will "just work" - I'm not sure this is true. As
> another example, I just had my wireless card fail to resume correctly.
> It tried to do a hotplug firmware load on resume. Which was difficult,
> because it was resumed before the IDE interface was. How can this sort
> of thing be avoided?
> 
> -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org 




-------------------------------------------------------
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: acpi-20040715: functional regression on ASUS M2N

[Nathan Bryant]

Matthew Garrett wrote:
> As
> another example, I just had my wireless card fail to resume correctly.
> It tried to do a hotplug firmware load on resume. Which was difficult,
> because it was resumed before the IDE interface was. How can this sort
> of thing be avoided?
> 

Notwithstanding all the overly grandiose crap I posted earlier 
(Honestly, I wasn't smoking anything) even on APM systems this sort of 
thing was typically handled by downing the network interfaces from 
userspace scripts before suspending.


-------------------------------------------------------
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: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 437 bytes --]

 || On Fri, 06 Aug 2004 13:07:33 -0400
 || Nathan Bryant <nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org> wrote: 

 >> Here is what it said for my machine during resume from suspend to
 >> ram: i8259: saving ELCR: 0xfffffff0 0x0a

 nb> Interesting. That translates into the following IRQ's set to level trigger:

 nb> 4
 nb> 5
 nb> 6 (!) floppy controller?
 nb> 7
 nb> 9
 nb> 11

Actually, this laptop has no floppy. In case it helps: 

[-- Attachment #1.2: cat /proc/interrupts --]
[-- Type: text/plain, Size: 645 bytes --]

           CPU0
  0:   13849154          XT-PIC  timer
  1:        595          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  4:          0          XT-PIC  ehci_hcd
  5:          0          XT-PIC  uhci_hcd
  6:          0          XT-PIC  Intel 82801DB-ICH4, yenta
  7:     146446          XT-PIC  uhci_hcd, yenta, eth1
  8:          4          XT-PIC  rtc
  9:     155025          XT-PIC  acpi
 11:       1019          XT-PIC  uhci_hcd, ohci1394, eth0
 12:       8438          XT-PIC  i8042
 14:      44918          XT-PIC  ide0
 15:        219          XT-PIC  ide1
NMI:          0
LOC:    2095462
ERR:          0
MIS:          0

[-- Attachment #1.3: Type: text/plain, Size: 547 bytes --]



 nb> But I don't think there's anything wrong with that. It does seem
 nb> that Matthew Garrett's message holds the key:
 nb> [...]

So should I try to change line 310 of drivers/base/sys.c to
list_for_each_entry_reverse and try again? 

Will this be useful to anyone to resolve things?

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

RE: acpi-20040715: functional regression on ASUS M2N

[Li, Shaohua]

I guess sysdev suffers from the problem much. Device core doesn't
maintain a tree for all sysdev. It's just a list, so PIC, LAPIC, PIT,
and so on may suspend/resume in random order. Don't know if it's indeed
an issue, but it looks crazy. 

Thanks,
Shaohua

>-----Original Message-----
>From: Matthew Garrett [mailto:mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org]
>Sent: Friday, August 06, 2004 11:24 PM
>To: Nathan Bryant
>Cc: ACPI Developers; Li, Shaohua; Georg C. F. Greve
>Subject: Re: [ACPI] acpi-20040715: functional regression on ASUS M2N
>
>On Thu, 2004-08-05 at 14:49 -0400, Nathan Bryant wrote:
>
>> The ELCR save/restore patch is causing regressions for some people.
What
>> if the problem is that we're saving/restoring registers at the wrong
time?
>
>On closer investigation, I found that the system was restoring my
ioapic
>state /after/ it had started the programmable interrupt timer back up.
>Changing line 310 of drivers/base/sys.c to list_for_each_entry_reverse
>seems to have greatly improved my ability to suspend and resume (which
>worked fine before the interrupt controller suspend/resume patches,
>except that I didn't get many interrupts...)
>
>There doesn't seem to be any fine-grained way to control the order of
>suspend/resume for individual drivers. It seems to be assumed that
>everything that devices depend on will be higher than them in the tree,
>and so everything will "just work" - I'm not sure this is true. As
>another example, I just had my wireless card fail to resume correctly.
>It tried to do a hotplug firmware load on resume. Which was difficult,
>because it was resumed before the IDE interface was. How can this sort
>of thing be avoided?
>
>--
>Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
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: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

Hi all,

I thought you might like to know that I've just managed to build a
kernel that allows me to suspend to ram again -- and in fact better
than before in so far as the network cards work correctly after
resume. Unfortunately this only works once. So there is progress on
the problem, even though it is not fully solved yet.

The kernel is a 2.6.9-rc1 with the following patches applied in this
order: 

 acpi-20040816-26-latest-release.diff.bz2
 alsa-bk-2004-08-26.patch.gz
 software-suspend-2.0.0.105-for-2.6.8.1.tar.bz2

(Note: the software suspend 2 has one reject that is apparently
 relatively easy to fix, however software suspend 2 does not work
 anymore on this kernel. On suspend it does not switch to the suspend
 screen, although the machine appears to be suspending successfully,
 but on resume the machine hangs when "Copying original kernel back")

Please note that the ALSA patch is absolutely necessary for this to
work, when I left it out, the resume from suspend to ram hung. Only
with the patch applied it resumes properly and I see the messages for
irq 6 and irq 11 having been disabled during the suspend phase.

In the syslog it shows that something still appears to be fishy,
however:

 kernel: Back to C!
 kernel: irq 6: nobody cared!
 kernel:  [__report_bad_irq+42/139] __report_bad_irq+0x2a/0x8b
 kernel:  [note_interrupt+111/159] note_interrupt+0x6f/0x9f
 kernel:  [do_IRQ+295/310] do_IRQ+0x127/0x136
 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
 kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
 kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
 kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
 kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
 kernel:  [__do_softirq+47/135] __do_softirq+0x2f/0x87
 kernel:  [do_softirq+38/40] do_softirq+0x26/0x28
 kernel:  [do_IRQ+259/310] do_IRQ+0x103/0x136
 kernel:  [time_resume+0/74] time_resume+0x0/0x4a
 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
 kernel:  [time_resume+0/74] time_resume+0x0/0x4a
 kernel:  [time_resume+66/74] time_resume+0x42/0x4a
 kernel:  [sysdev_resume+225/230] sysdev_resume+0xe1/0xe6
 kernel:  [device_power_up+5/10] device_power_up+0x5/0xa
 kernel:  [suspend_enter+54/74] suspend_enter+0x36/0x4a
 kernel:  [enter_state+105/161] enter_state+0x69/0xa1
 kernel:  [acpi_suspend+62/77] acpi_suspend+0x3e/0x4d
 kernel:  [acpi_system_write_sleep+96/139] acpi_system_write_sleep+0x60/0x8b
 kernel:  [acpi_system_write_sleep+117/139] acpi_system_write_sleep+0x75/0x8b
 kernel:  [acpi_system_write_sleep+0/139] acpi_system_write_sleep+0x0/0x8b
 kernel:  [vfs_write+176/281] vfs_write+0xb0/0x119
 kernel:  [sys_write+81/128] sys_write+0x51/0x80
 kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
 kernel: handlers:
 kernel: [snd_intel8x0_interrupt+0/542] (snd_intel8x0_interrupt+0x0/0x21e)
 kernel: Disabling IRQ #6
 kernel: irq 11: nobody cared!
 kernel:  [__report_bad_irq+42/139] __report_bad_irq+0x2a/0x8b
 kernel:  [note_interrupt+111/159] note_interrupt+0x6f/0x9f
 kernel:  [do_IRQ+295/310] do_IRQ+0x127/0x136
 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
 kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
 kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
 kernel:  [__do_softirq+47/135] __do_softirq+0x2f/0x87
 kernel:  [do_softirq+38/40] do_softirq+0x26/0x28
 kernel:  [do_IRQ+259/310] do_IRQ+0x103/0x136
 kernel:  [time_resume+0/74] time_resume+0x0/0x4a
 kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
 kernel:  [time_resume+0/74] time_resume+0x0/0x4a 
 kernel:  [time_resume+66/74] time_resume+0x42/0x4a
 kernel:  [sysdev_resume+225/230] sysdev_resume+0xe1/0xe6
 kernel:  [device_power_up+5/10] device_power_up+0x5/0xa
 kernel:  [suspend_enter+54/74] suspend_enter+0x36/0x4a
 kernel:  [enter_state+105/161] enter_state+0x69/0xa1
 kernel:  [acpi_suspend+62/77] acpi_suspend+0x3e/0x4d
 kernel:  [acpi_system_write_sleep+96/139] acpi_system_write_sleep+0x60/0x8b
 kernel:  [acpi_system_write_sleep+117/139] acpi_system_write_sleep+0x75/0x8b
 kernel:  [acpi_system_write_sleep+0/139] acpi_system_write_sleep+0x0/0x8b
 kernel:  [vfs_write+176/281] vfs_write+0xb0/0x119
 kernel:  [sys_write+81/128] sys_write+0x51/0x80
 kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
 kernel: handlers:
 kernel: [pg0+536303635/1068441600] (ohci_irq_handler+0x0/0x80e [ohci1394])
 kernel: Disabling IRQ #11
 kernel: PM: Finishing up.
 [...]
 kernel: ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11
 kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
 kernel: ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) -> IRQ 5
 kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64
 kernel: ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 7 (level, low) -> IRQ 7
 kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64
 kernel: ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 4 (level, low) -> IRQ 4
 kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
 kernel: ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 7 (level, low) -> IRQ 7
 kernel: ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 6 (level, low) -> IRQ 6
 kernel: PCI: Setting latency timer of device 0000:00:1f.5 to 64
 kernel: ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 6 (level, low) -> IRQ 6
 kernel: ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 7 (level, low) -> IRQ 7
 kernel: ACPI: PCI interrupt 0000:01:03.2[C] -> GSI 11 (level, low) -> IRQ 11
 [...]
 kernel: ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 6 (level, low) -> IRQ 6
 kernel: Yenta: CardBus bridge found at 0000:01:03.0 [1043:1754]
 kernel: yenta 0000:01:03.0: Preassigned resource 1 busy, reconfiguring...
 kernel: yenta 0000:01:03.0: Preassigned resource 2 busy, reconfiguring...
 kernel: yenta 0000:01:03.0: Preassigned resource 3 busy, reconfiguring...
 kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 6
 kernel: Socket status: 30000006
 kernel: ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 7 (level, low) -> IRQ 7
 kernel: Yenta: CardBus bridge found at 0000:01:03.1 [1043:1754]
 kernel: yenta 0000:01:03.1: Preassigned resource 0 busy, reconfiguring...
 kernel: yenta 0000:01:03.1: Preassigned resource 1 busy, reconfiguring...
 kernel: yenta 0000:01:03.1: Preassigned resource 2 busy, reconfiguring...
 kernel: yenta 0000:01:03.1: Preassigned resource 3 busy, reconfiguring...
 kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 7
 [...]
 kernel: ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller
 kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
 kernel: ehci_hcd 0000:00:1d.7: irq 4, pci mem e0434c00
 kernel: ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
 kernel: PCI: cache line size of 32 is not supported by device 0000:00:1d.7
 kernel: ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10
 kernel: hub 4-0:1.0: USB hub found
 kernel: hub 4-0:1.0: 6 ports detected
 pci.agent[4271]:      ehci-hcd: loaded successfully
 [...]
 kernel: usb 1-1: control timeout on ep0out
 kernel: uhci_hcd 0000:00:1d.0: Unlink after no-IRQ?  Different ACPI or APIC settings may help.

The second attempt at suspending gives

 kernel: ehci_hcd 0000:00:1d.7: remove, state 1

upon stopping the hotplug services. The system does not resume but
keeps running, apparently remaining functional.

If more info is helpful, let me know.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

RE: acpi-20040715: functional regression on ASUS M2N

[Li, Shaohua]

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

Hi,
I guess it's the problem I encountered (the dmesg is the same as mine).
Attached email includes two workarounds for this issue, but no final
solution yet.

Thanks,
Shaohua

>-----Original Message-----
>From: Georg C. F. Greve [mailto:greve-1r/uNngapc3YtjvyW6yDsg@public.gmane.org] On Behalf Of Georg C.
F.
>Greve
>Sent: Tuesday, August 31, 2004 4:16 PM
>To: ACPI Developers; Li, Shaohua
>Subject: Re: [ACPI] acpi-20040715: functional regression on ASUS M2N
>
>Hi all,
>
>I thought you might like to know that I've just managed to build a
>kernel that allows me to suspend to ram again -- and in fact better
>than before in so far as the network cards work correctly after
>resume. Unfortunately this only works once. So there is progress on
>the problem, even though it is not fully solved yet.
>
>The kernel is a 2.6.9-rc1 with the following patches applied in this
>order:
>
> acpi-20040816-26-latest-release.diff.bz2
> alsa-bk-2004-08-26.patch.gz
> software-suspend-2.0.0.105-for-2.6.8.1.tar.bz2
>
>(Note: the software suspend 2 has one reject that is apparently
> relatively easy to fix, however software suspend 2 does not work
> anymore on this kernel. On suspend it does not switch to the suspend
> screen, although the machine appears to be suspending successfully,
> but on resume the machine hangs when "Copying original kernel back")
>
>Please note that the ALSA patch is absolutely necessary for this to
>work, when I left it out, the resume from suspend to ram hung. Only
>with the patch applied it resumes properly and I see the messages for
>irq 6 and irq 11 having been disabled during the suspend phase.
>
>In the syslog it shows that something still appears to be fishy,
>however:
>
> kernel: Back to C!
> kernel: irq 6: nobody cared!
> kernel:  [__report_bad_irq+42/139] __report_bad_irq+0x2a/0x8b
> kernel:  [note_interrupt+111/159] note_interrupt+0x6f/0x9f
> kernel:  [do_IRQ+295/310] do_IRQ+0x127/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
> kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
> kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [__do_softirq+47/135] __do_softirq+0x2f/0x87
> kernel:  [do_softirq+38/40] do_softirq+0x26/0x28
> kernel:  [do_IRQ+259/310] do_IRQ+0x103/0x136
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [time_resume+66/74] time_resume+0x42/0x4a
> kernel:  [sysdev_resume+225/230] sysdev_resume+0xe1/0xe6
> kernel:  [device_power_up+5/10] device_power_up+0x5/0xa
> kernel:  [suspend_enter+54/74] suspend_enter+0x36/0x4a
> kernel:  [enter_state+105/161] enter_state+0x69/0xa1
> kernel:  [acpi_suspend+62/77] acpi_suspend+0x3e/0x4d
> kernel:  [acpi_system_write_sleep+96/139]
>acpi_system_write_sleep+0x60/0x8b
> kernel:  [acpi_system_write_sleep+117/139]
>acpi_system_write_sleep+0x75/0x8b
> kernel:  [acpi_system_write_sleep+0/139]
acpi_system_write_sleep+0x0/0x8b
> kernel:  [vfs_write+176/281] vfs_write+0xb0/0x119
> kernel:  [sys_write+81/128] sys_write+0x51/0x80
> kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
> kernel: handlers:
> kernel: [snd_intel8x0_interrupt+0/542]
(snd_intel8x0_interrupt+0x0/0x21e)
> kernel: Disabling IRQ #6
> kernel: irq 11: nobody cared!
> kernel:  [__report_bad_irq+42/139] __report_bad_irq+0x2a/0x8b
> kernel:  [note_interrupt+111/159] note_interrupt+0x6f/0x9f
> kernel:  [do_IRQ+295/310] do_IRQ+0x127/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [handle_IRQ_event+36/100] handle_IRQ_event+0x24/0x64
> kernel:  [do_IRQ+148/310] do_IRQ+0x94/0x136
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [__do_softirq+47/135] __do_softirq+0x2f/0x87
> kernel:  [do_softirq+38/40] do_softirq+0x26/0x28
> kernel:  [do_IRQ+259/310] do_IRQ+0x103/0x136
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [common_interrupt+24/32] common_interrupt+0x18/0x20
> kernel:  [time_resume+0/74] time_resume+0x0/0x4a
> kernel:  [time_resume+66/74] time_resume+0x42/0x4a
> kernel:  [sysdev_resume+225/230] sysdev_resume+0xe1/0xe6
> kernel:  [device_power_up+5/10] device_power_up+0x5/0xa
> kernel:  [suspend_enter+54/74] suspend_enter+0x36/0x4a
> kernel:  [enter_state+105/161] enter_state+0x69/0xa1
> kernel:  [acpi_suspend+62/77] acpi_suspend+0x3e/0x4d
> kernel:  [acpi_system_write_sleep+96/139]
>acpi_system_write_sleep+0x60/0x8b
> kernel:  [acpi_system_write_sleep+117/139]
>acpi_system_write_sleep+0x75/0x8b
> kernel:  [acpi_system_write_sleep+0/139]
acpi_system_write_sleep+0x0/0x8b
> kernel:  [vfs_write+176/281] vfs_write+0xb0/0x119
> kernel:  [sys_write+81/128] sys_write+0x51/0x80
> kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
> kernel: handlers:
> kernel: [pg0+536303635/1068441600] (ohci_irq_handler+0x0/0x80e
[ohci1394])
> kernel: Disabling IRQ #11
> kernel: PM: Finishing up.
> [...]
> kernel: ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) ->
IRQ
>11
> kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
> kernel: ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 5 (level, low) ->
IRQ 5
> kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64
> kernel: ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 7 (level, low) ->
IRQ 7
> kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64
> kernel: ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 4 (level, low) ->
IRQ 4
> kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
> kernel: ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 7 (level, low) ->
IRQ 7
> kernel: ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 6 (level, low) ->
IRQ 6
> kernel: PCI: Setting latency timer of device 0000:00:1f.5 to 64
> kernel: ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 6 (level, low) ->
IRQ 6
> kernel: ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 7 (level, low) ->
IRQ 7
> kernel: ACPI: PCI interrupt 0000:01:03.2[C] -> GSI 11 (level, low) ->
IRQ
>11
> [...]
> kernel: ACPI: PCI interrupt 0000:01:03.0[A] -> GSI 6 (level, low) ->
IRQ 6
> kernel: Yenta: CardBus bridge found at 0000:01:03.0 [1043:1754]
> kernel: yenta 0000:01:03.0: Preassigned resource 1 busy,
reconfiguring...
> kernel: yenta 0000:01:03.0: Preassigned resource 2 busy,
reconfiguring...
> kernel: yenta 0000:01:03.0: Preassigned resource 3 busy,
reconfiguring...
> kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 6
> kernel: Socket status: 30000006
> kernel: ACPI: PCI interrupt 0000:01:03.1[B] -> GSI 7 (level, low) ->
IRQ 7
> kernel: Yenta: CardBus bridge found at 0000:01:03.1 [1043:1754]
> kernel: yenta 0000:01:03.1: Preassigned resource 0 busy,
reconfiguring...
> kernel: yenta 0000:01:03.1: Preassigned resource 1 busy,
reconfiguring...
> kernel: yenta 0000:01:03.1: Preassigned resource 2 busy,
reconfiguring...
> kernel: yenta 0000:01:03.1: Preassigned resource 3 busy,
reconfiguring...
> kernel: Yenta: ISA IRQ mask 0x0000, PCI irq 7
> [...]
> kernel: ehci_hcd 0000:00:1d.7: Intel Corp. 82801DB/DBM (ICH4/ICH4-M)
USB
>2.0 EHCI Controller
> kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
> kernel: ehci_hcd 0000:00:1d.7: irq 4, pci mem e0434c00
> kernel: ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus
number
>4
> kernel: PCI: cache line size of 32 is not supported by device
0000:00:1d.7
> kernel: ehci_hcd 0000:00:1d.7: USB 2.0 enabled, EHCI 1.00, driver
2004-
>May-10
> kernel: hub 4-0:1.0: USB hub found
> kernel: hub 4-0:1.0: 6 ports detected
> pci.agent[4271]:      ehci-hcd: loaded successfully
> [...]
> kernel: usb 1-1: control timeout on ep0out
> kernel: uhci_hcd 0000:00:1d.0: Unlink after no-IRQ?  Different ACPI or
>APIC settings may help.
>
>The second attempt at suspending gives
>
> kernel: ehci_hcd 0000:00:1d.7: remove, state 1
>
>upon stopping the hotplug services. The system does not resume but
>keeps running, apparently remaining functional.
>
>If more info is helpful, let me know.
>
>Regards,
>Georg
>
>--
>Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
>Free Software Foundation Europe
(http://fsfeurope.org)
>Brave GNU World
(http://brave-gnu-world.org)

[-- Attachment #2: Type: message/rfc822, Size: 8609 bytes --]

From: "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Pallipadi, Venkatesh" <venkatesh.pallipadi-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, <stefandoesinger-RbZlAiThDcE@public.gmane.org>, "Nathan Bryant" <nbryant-p32f3XyCuykqcZcGjlUOXw@public.gmane.org>
Cc: "Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, <acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>, "Linux Kernel Mailing List" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
Date: Mon, 23 Aug 2004 13:58:52 +0800
Message-ID: <B44D37711ED29844BEA67908EAF36F039EA6C2-4yWAQGcml65pB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>

Right, this looks like the problem I encounter. My current test shows that the problem only occurs if ACPI changed LINK devices' IRQ. If ACPI use default LINK device IRQ, the problem went off.
Currently there are two workarounds:
1. comment one line in pci_link.c:acpi_pci_link_allocate, like below
	/*
	 * forget active IRQ that is not in possible list
	 */
	if (i == link->irq.possible_count) {
		if (acpi_strict)
			printk(KERN_WARNING PREFIX "_CRS %d not found"
				" in _PRS\n", link->irq.active);
+//		link->irq.active = 0;
	}
This disables rebalance IRQ, which fixes my problem.

2. change 'device_initcall(i8259A_init_sysfs);' to 'late_initcall(i8259A_init_sysfs);'
It seems that if OS changed BIOS IRQ router setting (like ACPI change Link device setting), IRQ router should resume before PIC. This possibly proves what Venki said.

PS. For the resume order, isn't it strange Local APIC resumes after PIT? I guess it should be the first device to resume.

Thanks,
Shaohua
>-----Original Message-----
>From: Pallipadi, Venkatesh
>Sent: Saturday, August 21, 2004 3:00 AM
>To: stefandoesinger-RbZlAiThDcE@public.gmane.org; Nathan Bryant
>Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Brown, Len; Linux Kernel list; Li,
>Shaohua
>Subject: RE: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>
>
>
>
>>-----Original Message-----
>>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
>>Stefan Dösinger
>>Sent: Friday, August 20, 2004 9:36 AM
>>To: Nathan Bryant
>>Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org; Brown, Len; Linux Kernel
>>list; Li, Shaohua
>>Subject: Re: [ACPI] [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
>>
>>Am Freitag, 20. August 2004 14:18 schrieb Nathan Bryant:
>>> Stefan -
>>>
>>> Also - did suspend/resume for the ipw2100 ever work under any kernel
>>> version?
>>Yes, it works with acpi=noirq at least up to 2.6.7(not tested
>>with later
>>versions, but I'm sure it does)
>>It works with 2.6.8-rc2 and 2.6.8-rc4 and 2.6.8.1 with acpi IRQs and a
>>modified dsdt which forces LNKE to IRQ 10. I attached a dmesg
>>output of a
>>successful resume.
>>
>>Cheers,
>>Stefan
>
>This seems to be the same resume order issue, that Shaohua is hitting.
>
>On my system the resume order looks like this:
>Resuming System Devices
>Resuming type 'cpu':
> cpu0
>aux driver resume 0xc010e410 (mtrr_restore)
>aux driver resume 0xc03365f0 (cpufreq_resume)
>Resuming type 'i8259':
> i82590
>Resuming type 'timer':
> timer0
>Resuming type 'pit':
> pit0
>Resuming type 'lapic':
> lapic0
>Resuming type 'irqrouter':
> irqrouter0
>Resuming type 'i8042':
> i80420
>
>The current theory I have for this issue is we resume pci_link driver
>A bit too late, which is causing this problem.
>
>Say a particular device doesn't do anything for suspend and resume.
>So, as soon as we resume this particular device can start
>generating interrupts. Once we have PIC enabled, it starts sending
>interrupts and no one handles that original IRQ. As pci_link that
>resumes later is reprogramming the device to different IRQ, where the
>driver is handling the device.
>
>That's probably the reason why it works with acpi=noirq or
>modified DSDT. Does it make sense?
>
>I think we have to resume pci_link device before PIC.
>We should be able to achieve this my changing the makefile orders.
>
>Thanks,
>Venki
>


-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel

Re: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

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

 || On Tue, 31 Aug 2004 16:45:04 +0800
 || "Li, Shaohua" <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote: 

 ls> I guess it's the problem I encountered (the dmesg is the same as
 ls> mine).  Attached email includes two workarounds for this issue,
 ls> but no final solution yet.

Thanks a lot for the pointer, it indeed appears to be the same
problem.


 ls> Currently there are two workarounds:

 ls> 1. comment one line in pci_link.c:acpi_pci_link_allocate, like
 ls> [...]
 ls> This disables rebalance IRQ, which fixes my problem.

This makes the problematic behaviour disappear, but not the messages
about the problem. I still see the syslog messages, although things
seem to work fine.


 ls> 2. change 'device_initcall(i8259A_init_sysfs);' to
 ls> 'late_initcall(i8259A_init_sysfs);'

This makes both the problematic behaviour and the messages disappear.

Also, it saves me the weird graphical behaviour upon resume, blocky
primitive graphics patterns, changing in one or two steps. 

Now I only have the "inu" close to the upper left corner for a second
or two as I had before the functional regression occured to me. 

All in all, #1 looks like a pretty brutal workaround to me, #2 looks
more like a fix.


 ls> It seems that if OS changed BIOS IRQ router setting (like ACPI
 ls> change Link device setting), IRQ router should resume before
 ls> PIC. This possibly proves what Venki said.

Well, it seems that my experience supports that.

If swsusp2 would also work now, things would be pretty nice.

Regards,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: acpi-20040715: functional regression on ASUS M2N

[Georg C. F. Greve]

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

 || On Tue, 31 Aug 2004 15:38:30 +0200
 || "Georg C. F. Greve" <greve-mXXj517/zsQ@public.gmane.org> wrote: 

 gg> If swsusp2 would also work now, things would be pretty nice.

Okay, it seems I got software suspend 2 working for this kernel, as
well -- the problem was that somewhere between version 2.0.0.100 and
2.0.0.105 behaviour changed in a way that the userland script is
expected to switch consoles.

I can now suspend to & resume from disk successfully as often as I
want with this kernel, it seems. Also, it appears I can suspend to &
resume from ram successfully as often as I want with this kernel.

Unfortunately, after having done a successful suspend to ram cycle,
the suspend from disk will hang while "Cleaning Up".


So it seems that the state the machine is in after resume from ram is
not identical to the one after resume from disk. Whether this is due
to a problem in the suspend to ram or swsusp2 code, I cannot say.


Given that the suspend to ram has seemed more shaky than the swsusp2
code and only got to work after making the change by hand that Li,
Shaohua suggested, I am (maybe unfairly) suspecting that something is
still not quite right in suspend to ram.

If I can help by providing some more information, please let me know.

Thanks,
Georg

-- 
Georg C. F. Greve                                       <greve-mXXj517/zsQ@public.gmane.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Brave GNU World	                           (http://brave-gnu-world.org)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]