| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <771cded00911020122o3bb5cc96q957c8be1ce7cae46@mail.gmail.com>
Date: Mon, 2 Nov 2009 05:22:30 -0400
From: Haojian Zhuang <haojian.zhuang@...il.com>
To: Pavel Machek <pavel@....cz>, dsaxena@...top.org,
alan@...ux.intel.com, gregkh@...e.de
Cc: Daniel Mack <daniel@...aq.de>,
linux-arm-kernel@...ts.infradead.org, Eric <eric.y.miao@...il.com>,
Haojian Zhuang <haojian.zhuang@...vell.com>, rpurdie@...ys.net,
lenz@...wisc.edu, kernel list <linux-kernel@...r.kernel.org>,
Dirk@...er-online.de, arminlitzel@....de,
Cyril Hrubis <metan@....cz>, thommycheck@...il.com,
dbaryshkov@...il.com, omegamoon@...il.com, utx@...guin.cz,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: Possible suspend/resume regression in .32-rc?
On Sun, Nov 1, 2009 at 6:03 PM, Pavel Machek <pavel@....cz> wrote:
>> Hi!
>>
>> > > Is anyone using suspend/resume with a recent git mainline kernel on PXA
>> > > or other ARM embedded boards? My platform used to suspend and resume
>> > > just fine on 2.6.31 but now as I rebased it, it fails the resume part.
>> > >
>> > > Unfortunately, I can't bisect it as the platform is not mainline yet and
>> > > so I always have mandatory patches (without my platform won't do
>> > > anything) on top of the git repository. Which breaks the bisect logic.
>> > >
>> > > What puzzles me is that I see the current raising at wakeup time, so at
>> > > least the processor seems to resume, but I can't see any serial console
>> > > output, just like if the kernel crashed very early after wakeup.
>> > > 'no_console_suspend' didn't help either.
>> >
>> > Ok, got it. The culprit is commit d2c37068 ("[ARM] pxa: initialize
>> > default interrupt priority and use ICHP for IRQ handling"). Reverting it
>> > make suspend/resume work again on my board.
>> >
>> > Haojian, Eric, could you have a look at this?
>>
>> Okay, patch is this one: I'll test reverting it shortly.
>>
>> commit d2c37068429b29d6549cf3486fc84b836689e122
>> Author: Haojian Zhuang <haojian.zhuang@...vell.com>
>> Date: Wed Aug 19 19:49:31 2009 +0800
>>
>> [ARM] pxa: initialize default interrupt priority and use ICHP for IRQ handling
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang@...vell.com>
>> Signed-off-by: Eric Miao <eric.y.miao@...il.com>
>
> And yes, reverting it _does_ fix suspend on spitz.
>
> Pavel
Em, it's not caused by the IRQ patch.
The kernel is blocked in resume path. When console is resumed, IRQ is
already disabled and system is blocked. Actually, IRQ shouldn't be
disabled at here. Up to now, I only find which patch will cause this
issue. But I can't find the best solution on it. The patch with issue
is pasted in below.
So this issue is only occused when console suspend is enabled. If you
enable no_console_suspend in command, you won't meet this issue. It
seems that it's caused by removing termios setting in
uart_resume_port() in the below patch. If I add these code back, the
issue doesn't occur any more.
Deepak,
Could you help to investigate this issue also?
By the way, the suggested quick test command is in below. If we tried
these commands for 20 times, the issue would occur. I only test it in
PXA silicon. I don't know the symptom on other silicons.
$ echo devices > /sys/power/pm_test
$ echo mem > /sys/power/state
Thanks
Haojian
>From ba15ab0e8de0d4439a91342ad52d55ca9e313f3d Mon Sep 17 00:00:00 2001
From: Deepak Saxena <dsaxena@...top.org>
Date: Sat, 19 Sep 2009 13:13:33 -0700
Subject: [PATCH] Set proper console speed on resume if console suspend
is disabled
Commit b5b82df6, from May 2007, breaks no_console_suspend on the OLPC
XO laptop. Basically what happens is that upon returning from resume,
serial8250_resume_port() will reconfigure the port for high speed
mode and all console output will be garbled, making debug of the
resume path painful. This patch modifies uart_resume_port() to
reset the port to the state it was in before we suspended.
Original patch by Marcelo Tosatti
Second patch by Deepak then reworked by Alan to fit with the tty changes
before it got submitted. Also fixed the console path to set c_i/ospeed as
some drivers require the termios fields are valid
Signed-off-by: Deepak Saxena <dsaxena@...top.org>
Signed-off-by: Alan Cox <alan@...ux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
---
drivers/serial/serial_core.c | 32 ++++++++++++++++++--------------
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index 3fd0134..2514d00 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -2068,11 +2068,29 @@ int uart_resume_port(struct uart_driver *drv,
struct uart_port *uport)
struct tty_port *port = &state->port;
struct device *tty_dev;
struct uart_match match = {uport, drv};
+ struct ktermios termios;
mutex_lock(&port->mutex);
if (!console_suspend_enabled && uart_console(uport)) {
/* no need to resume serial console, it wasn't suspended */
+ /*
+ * First try to use the console cflag setting.
+ */
+ memset(&termios, 0, sizeof(struct ktermios));
+ termios.c_cflag = uport->cons->cflag;
+ /*
+ * If that's unset, use the tty termios setting.
+ */
+ if (termios.c_cflag == 0)
+ termios = *state->port.tty->termios;
+ else {
+ termios.c_ispeed = termios.c_ospeed =
+ tty_termios_input_baud_rate(&termios);
+ termios.c_ispeed = termios.c_ospeed =
+ tty_termios_baud_rate(&termios);
+ }
+ uport->ops->set_termios(uport, &termios, NULL);
mutex_unlock(&port->mutex);
return 0;
}
@@ -2089,20 +2107,6 @@ int uart_resume_port(struct uart_driver *drv,
struct uart_port *uport)
* Re-enable the console device after suspending.
*/
if (uart_console(uport)) {
- struct ktermios termios;
-
- /*
- * First try to use the console cflag setting.
- */
- memset(&termios, 0, sizeof(struct ktermios));
- termios.c_cflag = uport->cons->cflag;
-
- /*
- * If that's unset, use the tty termios setting.
- */
- if (port->tty && termios.c_cflag == 0)
- termios = *port->tty->termios;
-
uart_change_pm(state, 0);
uport->ops->set_termios(uport, &termios, NULL);
console_start(uport->cons);
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists