All of lore.kernel.org
 help / color / mirror / Atom feed
From: "P. Christeas" <p_christ-U04EIuiosng@public.gmane.org>
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Cc: lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: [PATCH] 2.6.0-test4: Trivial /sys/power/state patch, sleep status report
Date: Tue, 26 Aug 2003 01:25:30 +0300	[thread overview]
Message-ID: <200308260125.30194.p_christ@hol.gr> (raw)

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

Just found out that by 'echo sth_wrong > /sys/power/state' the kernel would 
oops in a fatal way (no clean exit from there).
The oops suggested that the code would enter an invalid fn.

You may apply the included patch to solve the bug. IMHO doing a clean exit is 
much preferrable than having BUG() there.

In the patch I also added some double checking of the fn. You may disable that  
(although sleeping is a one time fn which won't be slowed dow by that). 

Status report:  (HP Omnibook XE3GC)
S1 ('standby') works
S3, S4bios will suspend, but NOT resume.
that's the same as previous kernels I've tested so far.

I still have the ALSA-artsd deadlock I reported w. -test1 (in short, artsd 
resumes from S1 in a 'disk I/O' process state, which deadlocks maestro3)
see: http://marc.theaimsgroup.com/?l=linux-kernel&m=105836807605512&w=2



[-- Attachment #2: sys-power-state.diff --]
[-- Type: text/x-diff, Size: 922 bytes --]

diff -Bbur /diskb/users/panos/linux-off/kernel/power/main.c /usr/src/linux/kernel/power/main.c
--- /diskb/users/panos/linux-off/kernel/power/main.c	2003-08-23 12:13:17.000000000 +0300
+++ /usr/src/linux/kernel/power/main.c	2003-08-26 00:59:34.000000000 +0300
@@ -304,6 +304,20 @@
 		goto Unlock;
 	}
 
+# if 1 		/* disable once we're sure we got it right */
+	/* double - check  code */
+	if (!s ) {
+		printk (KERN_ERR "Invalid suspend state %d\n",state);
+		error = -EINVAL;
+		goto Unlock ;
+	}
+	if (! s->fn) {
+		printk(KERN_ERR "Invalid fn for suspend state %d\n", state );
+		error = -EINVAL ;
+		goto Unlock;
+	}
+# endif
+
 	pr_debug("PM: Preparing system for suspend.\n");
 	if ((error = suspend_prepare(state)))
 		goto Unlock;
@@ -500,7 +514,7 @@
 		if (s->name && !strcmp(buf,s->name))
 			break;
 	}
-	if (s)
+	if ( (s) && (state < PM_SUSPEND_MAX) )
 		error = enter_state(state);
 	else
 		error = -EINVAL;

WARNING: multiple messages have this Message-ID (diff)
From: "P. Christeas" <p_christ@hol.gr>
To: acpi-devel@lists.sourceforge.net
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH] 2.6.0-test4: Trivial /sys/power/state patch, sleep status report
Date: Tue, 26 Aug 2003 01:25:30 +0300	[thread overview]
Message-ID: <200308260125.30194.p_christ@hol.gr> (raw)

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

Just found out that by 'echo sth_wrong > /sys/power/state' the kernel would 
oops in a fatal way (no clean exit from there).
The oops suggested that the code would enter an invalid fn.

You may apply the included patch to solve the bug. IMHO doing a clean exit is 
much preferrable than having BUG() there.

In the patch I also added some double checking of the fn. You may disable that  
(although sleeping is a one time fn which won't be slowed dow by that). 

Status report:  (HP Omnibook XE3GC)
S1 ('standby') works
S3, S4bios will suspend, but NOT resume.
that's the same as previous kernels I've tested so far.

I still have the ALSA-artsd deadlock I reported w. -test1 (in short, artsd 
resumes from S1 in a 'disk I/O' process state, which deadlocks maestro3)
see: http://marc.theaimsgroup.com/?l=linux-kernel&m=105836807605512&w=2



[-- Attachment #2: sys-power-state.diff --]
[-- Type: text/x-diff, Size: 922 bytes --]

diff -Bbur /diskb/users/panos/linux-off/kernel/power/main.c /usr/src/linux/kernel/power/main.c
--- /diskb/users/panos/linux-off/kernel/power/main.c	2003-08-23 12:13:17.000000000 +0300
+++ /usr/src/linux/kernel/power/main.c	2003-08-26 00:59:34.000000000 +0300
@@ -304,6 +304,20 @@
 		goto Unlock;
 	}
 
+# if 1 		/* disable once we're sure we got it right */
+	/* double - check  code */
+	if (!s ) {
+		printk (KERN_ERR "Invalid suspend state %d\n",state);
+		error = -EINVAL;
+		goto Unlock ;
+	}
+	if (! s->fn) {
+		printk(KERN_ERR "Invalid fn for suspend state %d\n", state );
+		error = -EINVAL ;
+		goto Unlock;
+	}
+# endif
+
 	pr_debug("PM: Preparing system for suspend.\n");
 	if ((error = suspend_prepare(state)))
 		goto Unlock;
@@ -500,7 +514,7 @@
 		if (s->name && !strcmp(buf,s->name))
 			break;
 	}
-	if (s)
+	if ( (s) && (state < PM_SUSPEND_MAX) )
 		error = enter_state(state);
 	else
 		error = -EINVAL;

             reply	other threads:[~2003-08-25 22:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-25 22:25 P. Christeas [this message]
2003-08-25 22:25 ` [PATCH] 2.6.0-test4: Trivial /sys/power/state patch, sleep status report P. Christeas
     [not found] ` <200308260125.30194.p_christ-U04EIuiosng@public.gmane.org>
2003-08-25 22:40   ` Bernd Petrovitsch
2003-08-25 22:40     ` Bernd Petrovitsch
     [not found]     ` <1061851218.12331.23.camel-j7ksBhXOGzoJmsy6czSMtA@public.gmane.org>
2003-08-25 22:47       ` P. Christeas
2003-08-25 22:47         ` P. Christeas
     [not found]         ` <200308260147.50968.p_christ-U04EIuiosng@public.gmane.org>
2003-08-25 22:57           ` Bernd Petrovitsch
2003-08-25 22:57             ` Bernd Petrovitsch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200308260125.30194.p_christ@hol.gr \
    --to=p_christ-u04eiuiosng@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.