Hello. 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 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.