S3 suspend and serial console

S3 suspend and serial console

[Carl-Daniel Hailfinger]

Hi,

on resume from S3, my serial console prints garbage and stops working.
I assume the BIOS resets the serial port on resume, but I have
abolutely no idea how to find out what speed and parity the serial
port has after resume. A quick try of 9600,57600,115200 didn't
succeed and I now wonder if
- the kernel could reset the serial ports on resume
- the kernel could read the current parameters from the UART and print
them out so I can adjust my serial console.

Oh well... after some investigation, it seems the serial console
goes back to normal after issuing the command
echo foo >/dev/ttyS0

Could it be that the UART state is out-of-sync or something like that
after resume and the serial console code doesn't notice?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: S3 suspend and serial console

[Carl-Daniel Hailfinger]

Carl-Daniel Hailfinger schrieb:
> Hi,
> 
> on resume from S3, my serial console prints garbage and stops working.
> I assume the BIOS resets the serial port on resume, but I have
> abolutely no idea how to find out what speed and parity the serial
> port has after resume. A quick try of 9600,57600,115200 didn't
> succeed and I now wonder if
> - the kernel could reset the serial ports on resume
> - the kernel could read the current parameters from the UART and print
> them out so I can adjust my serial console.
> 
> Oh well... after some investigation, it seems the serial console
> goes back to normal after issuing the command
> echo foo >/dev/ttyS0

>/dev/ttyS0
fixes it, too. So you're right, Pavel.


> Could it be that the UART state is out-of-sync or something like that
> after resume and the serial console code doesn't notice?

If you add an open()/close() to the S3 wakeup code, how can you
find out which device you're supposed to open, that is which device
the serial console is attached to? And how early can you open() the
serial port? Before the "Back to C!" printk?

Once you have a patch, please mail it to me. I'll surely test it ;-)

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: S3 suspend and serial console

[Karol Kozimor]

Thus wrote Carl-Daniel Hailfinger:
> > goes back to normal after issuing the command
> > echo foo >/dev/ttyS0
> 
> >/dev/ttyS0
> fixes it, too. So you're right, Pavel.

echo > /dev/ttyS0 will echo a single '\n'. I guess echo -n would be more
appropriate.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: S3 suspend and serial console

[Stefan Seyfried]

On Sat, Feb 05, 2005 at 04:58:45PM +0100, Karol Kozimor wrote:
 
> echo > /dev/ttyS0 will echo a single '\n'. I guess echo -n would be more

only "> /dev/ttyS0", no echo. This basically does...

open("/dev/tty", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fcntl64(1, F_GETFD)                     = 0
fcntl64(1, F_DUPFD, 10)                 = 10
fcntl64(1, F_GETFD)                     = 0
fcntl64(10, F_SETFD, FD_CLOEXEC)        = 0
dup2(3, 1)                              = 1
close(3)                                = 0

so it is pretty equivalent to "echo -n > /dev/ttyS0"
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: S3 suspend and serial console

[Carl-Daniel Hailfinger]

Stefan Seyfried schrieb:
> 
> only "> /dev/ttyS0", no echo. This basically does...
> 
> open("/dev/tty", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
> fcntl64(1, F_GETFD)                     = 0
> fcntl64(1, F_DUPFD, 10)                 = 10
> fcntl64(1, F_GETFD)                     = 0
> fcntl64(10, F_SETFD, FD_CLOEXEC)        = 0
> dup2(3, 1)                              = 1
> close(3)                                = 0
> 
> so it is pretty equivalent to "echo -n > /dev/ttyS0"

Erm... is it intentional that serial powermanagement code is never
called on entering/leaving S3? When I added debugging statements
to the serial code, this seemed very strange.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: S3 suspend and serial console

[Pavel Machek]

Hi!


> > only "> /dev/ttyS0", no echo. This basically does...
> > 
> > open("/dev/tty", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
> > fcntl64(1, F_GETFD)                     = 0
> > fcntl64(1, F_DUPFD, 10)                 = 10
> > fcntl64(1, F_GETFD)                     = 0
> > fcntl64(10, F_SETFD, FD_CLOEXEC)        = 0
> > dup2(3, 1)                              = 1
> > close(3)                                = 0
> > 
> > so it is pretty equivalent to "echo -n > /dev/ttyS0"
> 
> Erm... is it intentional that serial powermanagement code is never
> called on entering/leaving S3? When I added debugging statements

Probably noone was yet trying to use serial during suspend....

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: S3 suspend and serial console

[Carl-Daniel Hailfinger]

Hi!

>>Erm... is it intentional that serial powermanagement code is never
>>called on entering/leaving S3? When I added debugging statements

Pavel Machek schrieb:
> 
> Probably noone was yet trying to use serial during suspend....

You mean noone uses the serial console while testing suspend?
What is the new way to debug suspend problems not requiring a
serial console?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: S3 suspend and serial console

[Pavel Machek]

Hi!

> >>Erm... is it intentional that serial powermanagement code is never
> >>called on entering/leaving S3? When I added debugging statements
> 
> > Probably noone was yet trying to use serial during suspend....
> 
> You mean noone uses the serial console while testing suspend?
> What is the new way to debug suspend problems not requiring a
> serial console?

Well, when video works, you debug using video. I used hardware
debugger, too...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: S3 suspend and serial console

[Carl-Daniel Hailfinger]

Pavel Machek schrieb:
> Hi!
> 
> 
>>>>Erm... is it intentional that serial powermanagement code is never
>>>>called on entering/leaving S3? When I added debugging statements
>>
>>>Probably noone was yet trying to use serial during suspend....
>>
>>You mean noone uses the serial console while testing suspend?
>>What is the new way to debug suspend problems not requiring a
>>serial console?
> 
> Well, when video works, you debug using video. I used hardware
> debugger, too...

Will there be any patch to actually use the powermanagement code
in the serial core?


Regarding the original problem:
It seems the following call is sufficient to make the console work
again. However, I haven't found a function which would give me
the parameters needed to call ->set_termios.

serial/8250.c: serial8250_set_termios

Do you have any idea how to obtain the termios and tty structures
for a given port, e.g. ttyS0?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Re: Re: S3 suspend and serial console

[Nigel Cunningham]

Hi.

On Tue, 2005-02-08 at 04:14, Carl-Daniel Hailfinger wrote:
> Pavel Machek schrieb:
> > Hi!
> > 
> > 
> >>>>Erm... is it intentional that serial powermanagement code is never
> >>>>called on entering/leaving S3? When I added debugging statements
> >>
> >>>Probably noone was yet trying to use serial during suspend....
> >>
> >>You mean noone uses the serial console while testing suspend?
> >>What is the new way to debug suspend problems not requiring a
> >>serial console?
> > 
> > Well, when video works, you debug using video. I used hardware
> > debugger, too...
> 
> Will there be any patch to actually use the powermanagement code
> in the serial core?
> 
> 
> Regarding the original problem:
> It seems the following call is sufficient to make the console work
> again. However, I haven't found a function which would give me
> the parameters needed to call ->set_termios.
> 
> serial/8250.c: serial8250_set_termios
> 
> Do you have any idea how to obtain the termios and tty structures
> for a given port, e.g. ttyS0?

We have code for 2.4 in Suspend2. I haven't seen any need for it in 2.6;
it just works (except that you can't send keystrokes early in the boot
process). Haven't tried S3, so I don't know the issues there.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: S3 suspend and serial console

[Pavel Machek]

Hi!

> Regarding the original problem:
> It seems the following call is sufficient to make the console work
> again. However, I haven't found a function which would give me
> the parameters needed to call ->set_termios.
> 
> serial/8250.c: serial8250_set_termios
> 
> Do you have any idea how to obtain the termios and tty structures
> for a given port, e.g. ttyS0?

Save some termios passed to it in static variable and than use that
one as a quick hack...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: S3 suspend and serial console

[Carl-Daniel Hailfinger]

Hi,

Pavel Machek schrieb:
> 
>>Regarding the original problem:
>>It seems the following call is sufficient to make the console work
>>again. However, I haven't found a function which would give me
>>the parameters needed to call ->set_termios.
>>
>>serial/8250.c: serial8250_set_termios
>>
>>Do you have any idea how to obtain the termios and tty structures
>>for a given port, e.g. ttyS0?
> 
> Save some termios passed to it in static variable and than use that
> one as a quick hack...

Yes, that will hopefully work. The hack I'm using right now causes
random oopses, but at least the serial console can display them :-|

--- 1.44/drivers/acpi/sleep/main.c      2005-01-15 23:01:53 +01:00
+++ edited/drivers/acpi/sleep/main.c    2005-02-08 13:16:13 +01:00
@@ -18,6 +18,7 @@
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
 #include "sleep.h"
+#include <linux/syscalls.h>

 u8 sleep_states[ACPI_S_STATE_COUNT];

@@ -82,6 +83,7 @@
        acpi_status status = AE_OK;
        unsigned long flags = 0;
        u32 acpi_state = acpi_suspend_states[pm_state];
+       struct file* filp;

        ACPI_FLUSH_CPU_CACHE();

@@ -126,6 +128,8 @@
        if (pm_state > PM_SUSPEND_STANDBY)
                acpi_restore_state_mem();

+       filp = filp_open("/dev/ttyS0", O_WRONLY, 0);
+       filp_close(filp, NULL);

        return ACPI_SUCCESS(status) ? 0 : -EFAULT;
 }

Any idea why that darn thing oopses on me at random locations?

First Oops on suspend:

divide error: 0000 [#1]
Modules linked in: nvram parport_pc lp parport edd cpufreq_userspace speedstep_s
CPU:    0
EIP:    0060:[<c011a8ed>]    Not tainted VLI
EFLAGS: 00000286   (2.6.11-rc3-latest-s3test14)
EIP is at release_console_sem+0x1d/0x90
eax: c0303fc0   ebx: 00000286   ecx: ffffffff   edx: 00005536
esi: fffffe89   edi: 0000003e   ebp: dfd8c200   esp: d97b5db4
ds: 0068   es: 007b   ss: 0068
Process s3script (pid: 8845, threadinfo=d97b4000 task=dd45fa20)
Stack: c01b2744 00000001 00000246 c011a86d d97b5de8 c03abe60 dfb71900 d97b5e08
       c011a757 c02d77a4 d97b5de8 c021b6a5 c02d77a4 c013678f c03abe60 db35c9c0
       00000000 dd45fa20 c0117590 00000000 00000000 c03abe60 00000296 00000296
Call Trace:
 [<c01b2744>] vscnprintf+0x14/0x20
 [<c011a86d>] vprintk+0x10d/0x120
 [<c011a757>] printk+0x17/0x20
 [<c021b6a5>] uart_block_til_ready+0x1a5/0x1b0
 [<c013678f>] request_irq+0x7f/0xb0
 [<c0117590>] default_wake_function+0x0/0x10
 [<c0117590>] default_wake_function+0x0/0x10
 [<c0219c2c>] uart_startup+0x8c/0x120
 [<c021b8d8>] uart_open+0x118/0x140
 [<c0204cc6>] tty_open+0x166/0x2a0
 [<c015b609>] chrdev_open+0xa9/0x140
 [<c0154229>] get_empty_filp+0x59/0xe0
 [<c01529c6>] dentry_open+0x176/0x1e0
 [<c0152840>] filp_open+0x40/0x50
 [<c011a86d>] vprintk+0x10d/0x120
 [<c01f3795>] acpi_pm_enter+0x96/0xac
 [<c013153e>] suspend_enter+0x2e/0x50
 [<c01315ef>] enter_state+0x4f/0x90
 [<c01f380f>] acpi_suspend+0x25/0x32
 [<c01b369a>] copy_from_user+0x3a/0x80
 [<c01f3917>] acpi_system_write_sleep+0x69/0x7a
 [<c0153684>] vfs_write+0xd4/0x130
 [<c0153791>] sys_write+0x41/0x70
 [<c0102e0d>] sysenter_past_esp+0x52/0x75
Code: b5 37 c0 c3 8d 76 00 8d bc 27 00 00 00 00 56 31 f6 53 83 ec 04 eb 14 8d b

Reboot, next try to suspend:

Unable to handle kernel paging request at virtual address fffffe20
 printing eip:
c0152c03
*pde = 00002067
*pte = 00000000
Oops: 0000 [#1]
Modules linked in: nvram parport_pc lp parport cpufreq_userspace speedstep_cents
CPU:    0
EIP:    0060:[<c0152c03>]    Not tainted VLI
EFLAGS: 00010282   (2.6.11-rc3-latest-s3test14)
EIP is at filp_close+0x13/0x90
eax: fffffe00   ebx: fffffe00   ecx: dd1d00c0   edx: 00000000
esi: 00000002   edi: 00000000   ebp: 00000000   esp: d800def8
ds: 0068   es: 007b   ss: 0068
Process s3script (pid: 8754, threadinfo=d800c000 task=df0d2520)
Stack: 00000002 00000003 00000002 00000046 c01f379c 00000000 00000282 00000003
       00000002 c013153e 00000000 00000003 d800df54 c01315ef c02bdaed 00000002
       c02b3088 c01f380f 00000000 00000001 00000000 00000003 00000004 40204000
Call Trace:
 [<c01f379c>] acpi_pm_enter+0x9d/0xac
 [<c013153e>] suspend_enter+0x2e/0x50
 [<c01315ef>] enter_state+0x4f/0x90
 [<c01f380f>] acpi_suspend+0x25/0x32
 [<c01b369a>] copy_from_user+0x3a/0x80
 [<c01f3917>] acpi_system_write_sleep+0x69/0x7a
 [<c0153684>] vfs_write+0xd4/0x130
 [<c0153791>] sys_write+0x41/0x70
 [<c0102e0d>] sysenter_past_esp+0x52/0x75
Code: 89 04 24 e8 40 ff ff ff 83 c4 0c c3 8d b6 00 00 00 00 8d bf 00 00 00 00 8

Is it generally unsafe to call anything during resume?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Re: S3 suspend and serial console

[Pavel Machek]

Hi!

> >>Regarding the original problem:
> >>It seems the following call is sufficient to make the console work
> >>again. However, I haven't found a function which would give me
> >>the parameters needed to call ->set_termios.
> >>
> >>serial/8250.c: serial8250_set_termios
> >>
> >>Do you have any idea how to obtain the termios and tty structures
> >>for a given port, e.g. ttyS0?
> > 
> > Save some termios passed to it in static variable and than use that
> > one as a quick hack...
> 
> Yes, that will hopefully work. The hack I'm using right now causes
> random oopses, but at least the serial console can display them :-|

Are you using 8250.c? It seems to have some suspend/resume
support. Perhaps you should talk to Russell King?

> --- 1.44/drivers/acpi/sleep/main.c      2005-01-15 23:01:53 +01:00
> +++ edited/drivers/acpi/sleep/main.c    2005-02-08 13:16:13 +01:00
> @@ -18,6 +18,7 @@
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
>  #include "sleep.h"
> +#include <linux/syscalls.h>
> 
>  u8 sleep_states[ACPI_S_STATE_COUNT];
> 
> @@ -82,6 +83,7 @@
>         acpi_status status = AE_OK;
>         unsigned long flags = 0;
>         u32 acpi_state = acpi_suspend_states[pm_state];
> +       struct file* filp;
> 
>         ACPI_FLUSH_CPU_CACHE();
> 
> @@ -126,6 +128,8 @@
>         if (pm_state > PM_SUSPEND_STANDBY)
>                 acpi_restore_state_mem();
> 
> +       filp = filp_open("/dev/ttyS0", O_WRONLY, 0);
> +       filp_close(filp, NULL);


> Any idea why that darn thing oopses on me at random locations?

Yes, you can only do such stuff from process context etc... not from
some random place like this.

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click