Bug 6259

I'd have thought that this was a failure in the
serial drivers.

Which serial driver are you using? 8250?

Tested some more things out. This doesn't exclusively happen with just the
console=ttyS0,9600 argument. The same thing also happens if you just have a
plain serial login going, but thru init and not the kernel.

I am on a standard 16550A based serial port. Dell 600m laptop, x86. So, I guess
the 16550A driver.

Just checked again - 2.6.15 kernel does not have this problem. I resume the
system from S3 (ram), and a whole bunch of debug info shows up on the console.
In 2.6.16, resuming the system results in some garbage on the console. So this
must have been caused by some very recent change.

On Mon, Mar 20, 2006 at 11:27:57PM -0800, bugme-daemon@bugzilla.kernel.org wrote:
> I'd have thought that this was a failure in the
> serial drivers.
> 
> Which serial driver are you using? 8250?

It can only be restored if either:

1. the console uart has never been opened by userspace.
2. the console uart has been opened by userspace and _remains_ open at
   the time of suspend.

The problem is that the console code has to give up the cflag setting on
the first open, which means this information is no longer available to
the serial layer when the uart is closed.

If we didn't have this behaviour then we'd be restoring a random cflag
setting - if userspace had changed the baud rate prior to suspend, we'd
be restoring the boot time setting which is also unacceptable.

So essentially, we need more work on the tty layer to provide some way
to retrieve the current settings for a closed port.  Or something.

OIC, thanks.

We can't just save the most recent cflag setting in the driver?

Hello again

I am afriad there is something else going on here. I just did some more testing
and came up with the following.

In 2.6.15: Console works OK before and after suspend with NO userspace program
even opening the port. Console also works fine before and after suspend WITH a
userspace program (gtkterm) using the port.

In 2.6.16: Console does NOT work after resume with no userspace program ever
touching the port. Console also does not work after resume WITH a program using
the port during suspend.

So as you can see, in the new kernel, even when no userspace program opens the
port, or when a program keeps it open, the port is still malfunctioning after
resume.


Another interesting point I think is important:
I set dmesg -n 8 on both kernels prior to suspend. When 2.6.15 suspends, it
first outputs to console something like "Stopping tasks..." followed by some
messages starting with "ACPI:" followed by a message like "hwsleep: entering
state S3" or something. Similar messages appear during resume.

When 2.6.16 suspends, all it says is "Stopping tasks..." and that is the last
intelligent thing the console says. No "ACPI:" messages, no "hswleep" message.
Could this mean the serial port is being screwed up somewhere in the suspend
process, if not the resume process ?

> We can't just save the most recent cflag setting in the driver?

As I've said, the problem is that we don't know what the correct cflag
setting is - the tty layer is the only thing which authoritively knows
and the creaky tty layer is not setup for power management.

The additional issue is that the only driver which knows how to do this
is serial_core, and that can't save it in a static location because
there may be multiple serial ports (of differing types) configured as
console.

All round, I don't see an easy solution to this.  (If there were I'd
have already fixed it - I've known about this issue since I wrote the
PM serial support.)

How has this been working in the previous kernel? Did it simply not suspend the
serial ports?

We've been doing serial-based suspend for quite a number of kernel releases now.

this appears to be serial/tty layer issue, not an ACPI issue.
moving to Drivers/serial.

Is it still present with 2.6.18?

Please reopen this bug if it's still present in kernel 2.6.19.