I have been trying to debug the S3 resume hang from Kernel Bug 5555. I got a
serial console set up, by kernel command line console=ttyS0,9600.
In 2.6.15, several ACPI-related messages appear on the console, as well as some
PCI stuff, and Stopping / Restarting Tasks.... etc. The console worked fine
before and after resume.
Now switched to 2.6.16. Some messages are not printed to the console (like the
ACPI: stuff) even on dmesg -n 8. "Stopping Tasks" is printed to the console, and
that is all. The machine enters S3 suspend.
After machine resumes, utter garbage (baud barf) is printed to the console. stty
-F /dev/ttyS0 shows the console is still operating at 9600 baud.
stty -F /dev/ttyS0 ispeed 9600 ospeed 9600
is required to restore the console to normal operation. Unfortunately this does
not HELP at all since I am trying to debug a periodic crash that happens DURING
the S3 resume process, so any output that would be interesting would occur
before I get a chance to fix the console with stty, assuming the machine wakes
up at all.
Again, this behavior only started in 2.6.16. In 2.6.15 the serial console
operates totally fine across many suspend/resume cycles.
I'd have thought that this was a failure in the
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, firstname.lastname@example.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.
We can't just save the most recent cflag setting in the driver?
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
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
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
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.