Distribution: Debian testing Hardware Environment: TP 600X (has a serial port, which is ttyS0, and a lame Winmodem, which is ttyS1), connected via a null-modem cable to a Thinkpad 560X # egrep -i 'serial|tty' /var/log/dmesg Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A # setserial -a /dev/ttyS0 /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4 Baud_base: 115200, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test Software Environment: hacked DSDT (see acpidmp in Bug #4989) Problem Description: After waking, the computer at the other end of the serial port (it's a TP560X running minicom with params 115200 8N1) no longer gets dmesgs. As soon as I run 'setserial -a /dev/ttyS0', they start again. Steps to reproduce:
Did this ever work, or is it a regression with a recent kernel?
> Did this ever work, or is it a regression with a recent kernel? I don't know. It's the first time I've ever used the serial port on this laptop (using it for serial-console debugging of Bug #5037, S3 sleep hangs often). Once I've stressed the current kernel, as part of debugging Bug #5037, I'll test the serial-port wakeup using earlier kernels on which S3 sleep/wake worked (2.6.11.4 and 2.6.12.3).
> Did this ever work, or is it a regression with a recent kernel? I just tried 2.6.11.4 and 2.6.12.3, and in both the serial port needs resetting upon wake (and 'setserial -a /dev/ttyS0' does the trick). With still earlier kernels, S3 didn't work at all.
*** This bug has been marked as a duplicate of 4270 ***