APM realy sucks on 2.6.x

After all this bashing...

Is there anyone out there who has the same experiences ?

Quoted 5 lines · Sebastian Kloska

After all this bashing...

Is there anyone out there who has the same experiences ?

I had the same problem at one time. Does disabling i2c help at all??

If so, the problem is probably in the w83781d or w83627hf driver; I could send you a copy of the patch, or you could just get the latest i2c release from http://www2.lm-sensors.nu/~lm78/index.html

I'm really having a hard time with APM on 2.6.x. I have a DELL Latitude L400 with the newest BIOS release. The most important functionality of APM for me is the 'suspend to RAM' function which worked like it should on all 2.4.x kernels I've tested. Under 2.6.x it simply does not resume the second time.

Quoted 6 lines · Sebastian Kloska

I'm really having a hard time with APM on 2.6.x. I have a DELL Latitude
L400 with the newest BIOS release. The most important functionality
of APM for me is the 'suspend to RAM' function which worked like
it should on all 2.4.x kernels I've tested. Under 2.6.x it simply does not resume the second time.

Here's a patch I've been using to resume on Dell Latitude C610 for the last eight months or so. I've never sent it in because I guess it's just papering over some deeper issue (with the BIOS? originally some earlier revision, I updated to latest A16 back then, but no change).

The funny thing is, that the code which resumes is relying on an APM event to tell it that it's resuming, and that event sometimes doesn't arrive. This patch lets the resuming code jump to the wild conclusion that it's resuming, without relying on that event. I hope this helps you, but fear your issue may be something else.

Hugh

arch/i386/kernel/apm.c +11 -5

@@ -389,7 +389,9 @@ static int			suspends_pending;
 static int			standbys_pending;
 static int			ignore_sys_suspend;
 static int			ignore_normal_resume;
+static int			ignore_bounce;
 static int			bounce_interval = DEFAULT_BOUNCE_INTERVAL;
+static unsigned long		last_resume;
 
 #ifdef CONFIG_APM_RTC_IS_GMT
 #	define	clock_cmos_diff	0

@@ -1225,11 +1227,14 @@ static int suspend(int vetoable)
 	spin_lock(&i8253_lock);
 	reinit_timer();
 	set_time();
-	ignore_normal_resume = 1;
-
 	spin_unlock(&i8253_lock);
 	write_sequnlock_irq(&xtime_lock);
 
+	ignore_normal_resume = 1;
+	ignore_sys_suspend = -1;
+	last_resume = jiffies;
+	ignore_bounce = 1;
+
 	if (err == APM_NO_ERROR)
 		err = APM_SUCCESS;
 	if (err != APM_SUCCESS)

@@ -1239,6 +1244,7 @@ static int suspend(int vetoable)
 	device_resume();
 	pm_send_all(PM_RESUME, (void *)0);
 	queue_event(APM_NORMAL_RESUME, NULL);
+	ignore_normal_resume = 0;
 out:
 	spin_lock(&user_list_lock);
 	for (as = user_list; as != NULL; as = as->next) {

@@ -1289,8 +1295,6 @@ static apm_event_t get_event(void)
 static void check_events(void)
 {
 	apm_event_t		event;
-	static unsigned long	last_resume;
-	static int		ignore_bounce;
 
 	while ((event = get_event()) != 0) {
 		if (debug) {

@@ -1333,8 +1337,10 @@ static void check_events(void)
 			 * sending a SUSPEND event until something else
 			 * happens!
 			 */
-			if (ignore_sys_suspend)
+			if (ignore_sys_suspend > 0)
 				return;
+			if (ignore_sys_suspend < 0)
+				printk("suspend: missed resume event\n");
 			ignore_sys_suspend = 1;
 			queue_event(event, NULL);
 			if (suspends_pending <= 0)

Thanks for the patch

Unfortunately that didn't do the trick. It does not even suspend sometimes when hitting the suspend button. This is very strange. It reproducible does not resume the second time. Seems like the system has been left in an unstable state after the first suspend/resume cycle. I'm definitely not the born hardware/BIOS programmer although I have been involved in graphic device programming (a pain) but in this this case which is a real pain I would be willing to at least help by further debugging the issue. Kernel 2.4.x proved that the BIOS can be talked into properly interacting with linux. So it's at least not totally brain dead.

One might argue that the hardware is already a little bit out dated but I really do not have the resources to buy a new laptop every year and it also represents some kind of masochistic challenge to get this thing going. But I really do not know how to debug the stuff or where to look.

Any hints how to proceed would be highly appreciated

Sebastian

Quoted 81 lines · Hugh Dickins

Quoted 5 lines · Sebastian Kloska

I'm really having a hard time with APM on 2.6.x. I have a DELL Latitude
L400 with the newest BIOS release. The most important functionality
of APM for me is the 'suspend to RAM' function which worked like
it should on all 2.4.x kernels I've tested. Under 2.6.x it simply does not resume the second time.

Here's a patch I've been using to resume on Dell Latitude C610 for the last eight months or so. I've never sent it in because I guess it's just papering over some deeper issue (with the BIOS? originally some earlier revision, I updated to latest A16 back then, but no change).

The funny thing is, that the code which resumes is relying on an APM event to tell it that it's resuming, and that event sometimes doesn't arrive. This patch lets the resuming code jump to the wild conclusion that it's resuming, without relying on that event. I hope this helps you, but fear your issue may be something else.

Hugh

arch/i386/kernel/apm.c 2004-05-10 07:29:55.021595384 +0100 renamed from arch/i386/kernel/apm.c 2004-05-10 03:33:36.000000000 +0100 +11 -5

@@ -389,7 +389,9 @@ static int            suspends_pending;
 static int            standbys_pending;
 static int            ignore_sys_suspend;
 static int            ignore_normal_resume;
+static int            ignore_bounce;
 static int            bounce_interval = DEFAULT_BOUNCE_INTERVAL;
+static unsigned long        last_resume;
 
 #ifdef CONFIG_APM_RTC_IS_GMT
 #    define    clock_cmos_diff    0

@@ -1225,11 +1227,14 @@ static int suspend(int vetoable)
    spin_lock(&i8253_lock);
    reinit_timer();
    set_time();
-    ignore_normal_resume = 1;
-
    spin_unlock(&i8253_lock);
    write_sequnlock_irq(&xtime_lock);
 
+    ignore_normal_resume = 1;
+    ignore_sys_suspend = -1;
+    last_resume = jiffies;
+    ignore_bounce = 1;
+
    if (err == APM_NO_ERROR)
        err = APM_SUCCESS;
    if (err != APM_SUCCESS)

@@ -1239,6 +1244,7 @@ static int suspend(int vetoable)
    device_resume();
    pm_send_all(PM_RESUME, (void *)0);
    queue_event(APM_NORMAL_RESUME, NULL);
+    ignore_normal_resume = 0;
 out:
    spin_lock(&user_list_lock);
    for (as = user_list; as != NULL; as = as->next) {

@@ -1289,8 +1295,6 @@ static apm_event_t get_event(void)
 static void check_events(void)
 {
    apm_event_t        event;
-    static unsigned long    last_resume;
-    static int        ignore_bounce;
 
    while ((event = get_event()) != 0) {
        if (debug) {

@@ -1333,8 +1337,10 @@ static void check_events(void)
             * sending a SUSPEND event until something else
             * happens!
             */
-            if (ignore_sys_suspend)
+            if (ignore_sys_suspend > 0)
                return;
+            if (ignore_sys_suspend < 0)
+                printk("suspend: missed resume event\n");
            ignore_sys_suspend = 1;
            queue_event(event, NULL);
            if (suspends_pending <= 0)

One possibility is code sections incorrectly marked as discardable.

Quoted 3 lines · Michael Clark

One possibility is code sections incorrectly marked as discardable.

`make buildcheck' will locate these.

My impression is that APM is slowly degenerating while ACPI is not (yet ?) able to fill the gap. The suspend feature of ACPI is stated to be dangerous and experimental and does not work for me at all.

After all this bashing...

Is there anyone out there who has the same experiences ?

Is there a workaround ?

Is it possible to somehow downgrade APM in the 2.6 kernel to the 2.4.x state ?

How could one debug this kind of missbehaviour ? Where do I have to look for potential miss configurations of the system ?

I'm really willing to help the APM developers to track down this bug but don't have a clue how to debug this kind stuff.

Hi!

Quoted 3 lines

My impression is that APM is slowly degenerating while ACPI is not (yet ?) able to fill the gap. The suspend feature of ACPI is stated to be dangerous and experimental and does not work for me at all.

That sounds about right.

Quoted 9 lines

After all this bashing...

Is there anyone out there who has the same experiences ?

Is there a workaround ?

Is it possible to somehow downgrade APM in the 2.6 kernel to the 2.4.x state ?

Quoted 5 lines

How could one debug this kind of missbehaviour ? Where do I have to look for potential miss configurations of the system ?

I'm really willing to help the APM developers to track down this bug but don't have a clue how to debug this kind stuff.

What APM developers? There are none as far as I know.

Try removing calls to device_* in apm.c. Better yet become APM developer.

Pavel

Quoted 5 lines

Quoted 2 lines

I'm really willing to help the APM developers to track down this bug but don't have a clue how to debug this kind stuff.

What APM developers? There are none as far as I know.

Hmmm ... So once again the Tooth Fairy and Santa Claus :-) ?

At least a

grep '<.*@' /usr/src/linux-2.6.6/arch/i386/kernel/apm.c | sed 's/.*<//' | sed 's/>.*//'

gives me:

<snip>
[email protected]

[email protected]
</snip>

This is pretty much for no one. And I guess you knew since you're on the list yourself. But I think you're right when meaning that there is not much of active maintenance anymore. Which at least I find a little bit discouraging when looking of the state of the ACPI support.

Quoted 2 lines

Try removing calls to device_* in apm.c. Better yet become APM developer.

It seems like I'm on my way to do so (still reluctantly). As I stated
in my previous mails I'm not born as a hardware/BIOS hacker (more the application C++/Java stuff) but I'm willing to learn. When I'm grown up I definitely want to be linux kernel hacker :-) ...

Currently I ripped down the 2.6.6 kernel to almost nothing
and add one module after the other checking for proper suspend/resume behavior....

The most suspicious candidates on my list are currently the
USB-UHCI driver and the ALSA sound system, which is my #1 candidate since it has not been an integral part of the 2.4.x (x<=20) kernels.

So if anybody out there could give me guidance on how the apm code might interact with the ALSA sound system it would be highly appreciated....

Hi!

Quoted 18 lines

Quoted 5 lines

Quoted 2 lines

I'm really willing to help the APM developers to track down this bug but don't have a clue how to debug this kind stuff.

What APM developers? There are none as far as I know.

Hmmm ... So once again the Tooth Fairy and Santa Claus :-) ?

At least a

grep '<.*@' /usr/src/linux-2.6.6/arch/i386/kernel/apm.c | sed 's/.*<//' | sed 's/>.*//'

gives me:

<snip>
[email protected]

...

Quoted 8 lines

[email protected]
</snip>

This is pretty much for no one. And I guess you knew since you're on the list yourself. But I think you're right when meaning that there is not much of active maintenance anymore. Which at least I find a little bit discouraging when looking of the state of the ACPI support.

Yes, that's pretty much what I meant. ACPI has ~5 people actively working on it, some of them probably full-time. That's a lot of manpower, compared to APM.

And ACPI is in pretty good state, btw, unless you want suspend-to-RAM. Unfortunately you want suspend-to-RAM.

Quoted 12 lines

Quoted 2 lines

Try removing calls to device_* in apm.c. Better yet become APM developer.

It seems like I'm on my way to do so (still reluctantly). As I stated
in my previous mails I'm not born as a hardware/BIOS hacker (more the application C++/Java stuff) but I'm willing to learn. When I'm grown up I definitely want to be linux kernel hacker :-) ...

Currently I ripped down the 2.6.6 kernel to almost nothing
and add one module after the other checking for proper suspend/resume behavior....

Quoted 8 lines

The most suspicious candidates on my list are currently the
USB-UHCI driver and the ALSA sound system, which is my #1 candidate since it has not been an integral part of the 2.4.x (x<=20) kernels.

So if anybody out there could give me guidance on how the apm code might interact with the ALSA sound system it would be highly appreciated....

device_suspend() will propagate all the way to alsa.
Pavel

Quoted 3 lines

Yes, that's pretty much what I meant. ACPI has ~5 people actively working on it, some of them probably full-time. That's a lot of manpower, compared to APM.

This becomes a little bit scary. Someone else on this list already
mentioned that there is a strong movement towards everything which is at least a desktop/server machine. And on the other hand there are these embedded systems which seem to be attractive for linux to.

ACPI seems to be nifty for such things like hardware monitoring and stuff. That makes it interesting for servers etc...

Everything in the middle (aka laptops) seems to slowly drop out of the loop. PCMCIA seems to be another ugly example. Anyway ... I'm not frightened

HP sells compaq nx5000 notebooks with Linux preloaded. Unfortunately suspend-to-RAM is not there (IIRC). That's because suspend-to-RAM is hard to do with ACPI.

Quoted 3 lines · Pavel Machek

HP sells compaq nx5000 notebooks with Linux preloaded. Unfortunately suspend-to-RAM is not there (IIRC). That's because suspend-to-RAM is hard to do with ACPI.

It took some time for me to work, but now ACPI S3 (suspend to RAM) is finally working for me (I have been trying it since 2.4.22 with no luck). Only one thing is required before suspending:

# modprobe ds
# cardctl eject

This ejects my CardBus NIC before going to sleep. Not doing so, causes the system to freeze when resuming.

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

Pavel Machek wrote:

| PCMCIA... well, that's another obsolete technology. Too bad.

PCMCIA is obsolete? Did I miss something, or was this a joke?

- --
Clemens Schwaighofer - IT Engineer & System Administration
==========================================================
TEQUILA\Japan, 6-17-2 Ginza Chuo-ku, Tokyo 104-8167, JAPAN
Tel: +81-(0)3-3545-7703 Fax: +81-(0)3-3545-7343
http://www.tequila.co.jp
==========================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAxT2AjBz/yQjBxz8RAlP7AJwPKwcRGUXXPUmecVAPQIYqX6LHuACgspJF VnS33PaDIFjNS29dPPOrakg=
=GIid
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

| PCMCIA... well, that's another obsolete technology. Too bad.

PCMCIA is obsolete? Did I miss something, or was this a joke?

|>| PCMCIA... well, that's another obsolete technology. Too bad.
|>
|>PCMCIA is obsolete? Did I miss something, or was this a joke?
|
|
| Obsoleted by cardbus, I believe. (cardbus cards look like PCMCIA
| cards, but electrical protocol is different) Plus, as someone else
| noted, stuff moves into mainboard. USB also replacs part of what
| PCMCIA was for.

hmm, I didn't know that there is a change from PCMCIA to cardbus. Thought still there are lot of pcmcia stuff around. wlan cards, eg my dial up card (CF card into a PCMCIA adapter). Well I wouldn't abandon PCMCIA so fast. At least the linux kernel is know for beeing able to use very old hardware in a very good way ...

| I agree that supporting PCMCIA is usefull, and that linux should run
| on old hardware; but you can see that PCMCIA and APM is in "old
| hardware" category, along with ISA, Pentium I CPUs and serial ports.

Well I wouldn't put PCMCIA into the same part as ISA and Pentium I, because my 2 year old Sonylaptop with a Pentium-M 4 1.5Ghz has PCMCIA slots ... So its not like it is found only on stone old Laptops.

Hi!

Quoted 2 lines

| PCMCIA... well, that's another obsolete technology. Too bad.

Quoted 1 line

PCMCIA is obsolete? Did I miss something, or was this a joke?

Obsoleted by cardbus, I believe. (cardbus cards look like PCMCIA cards, but electrical protocol is different) Plus, as someone else noted, stuff moves into mainboard. USB also replacs part of what PCMCIA was for.

Cardbus maybe, USB not. USB is very nice, but it's not typically SMALL. A PCMCIA NIC card is a credit card size, a USB NIC is a box plus a cable. Before you tell me I don't need it please name the affordable laptop which has 2 NICs.

Quoted 6 lines · Pavel Machek

Hi!

Quoted 3 lines

| PCMCIA... well, that's another obsolete technology. Too bad.

PCMCIA is obsolete? Did I miss something, or was this a joke?

Cardbus maybe, USB not. USB is very nice, but it's not typically SMALL. A PCMCIA NIC card is a credit card size, a USB NIC is a box plus a cable. Before you tell me I don't need it please name the affordable laptop which has 2 NICs.

So if anybody out there could give me guidance on how the apm code might interact with the ALSA sound system it would be highly appreciated....

Quoted 3 lines

So if anybody out there could give me guidance on how the apm code might interact with the ALSA sound system it would be highly appreciated....

In a word, badly. For at least one chipset, suspending while outputting to the pcm device causes the program outputting to the pcm device to enter the uninterruptible sleep state. A reboot is then required for the pcm device to be usable again...

(I attempted to report this back in February, but my bug report and workaround patch apparently didn't get through the alsa-devel spam filters.)

Quoted 3 lines · Sebastian Kloska

So if anybody out there could give me guidance on how the apm code might interact with the ALSA sound system it would be highly appreciated....

In a word, badly. For at least one chipset, suspending while outputting to the pcm device causes the program outputting to the pcm device to enter the uninterruptible sleep state. A reboot is then required for the pcm device to be usable again...

(I attempted to report this back in February, but my bug report and workaround patch apparently didn't get through the alsa-devel spam filters.)

The pure ALSA system with PCI Cirrus Logic CS4281 (my configuration) just dropped of my list of the 'bad' one ....

Does this bug freeze the machine ? Or just block
the outputting program ?

PCM will be the next to look at...

 +-compile->reboot->check->-+
 ^                          |
 |                          |
 +---<----------------------+

Kind of feel like in the old days where
a decend 'printf(stderr,....)' was THE
state of the art debugging tool ....

Hi!

Quoted 4 lines

The pure ALSA system with PCI Cirrus Logic CS4281 (my configuration) just dropped of my list of the 'bad' one ....

Quoted 4 lines

Does this bug freeze the machine ? Or just block the outputting program ?

PCM will be the next to look at...

Drop all non-important hw. That's everything but keyboard, VGA and harddrive...

Quoted 6 lines

+-compile->reboot->check->-+
^                          |
|                          |
+---<----------------------+

Quoted 3 lines

Kind of feel like in the old days where
a decend 'printf(stderr,....)' was THE state of the art debugging tool ....

Its *still* state of the art debugging tool for kernel.

Pavel

Quoted 9 lines

Quoted 4 lines

Does this bug freeze the machine ? Or just block
the outputting program ?

PCM will be the next to look at...

Drop all non-important hw. That's everything but keyboard, VGA and harddrive...

Already did that and APM suspends/resumes fine. That gives
me hope to at least pinpoint the bad behaving module/driver....

Does this bug freeze the machine ? Or just block the outputting program ?