Distribution: FC3 Hardware Environment: IBM T42p Software Environment: PM via ACPI Problem Description: After suspend/resume cycle, serial interfaces do not work. I checked real serial port, with 'minicom'; and infrared. I saw this problem with all 2.6.11 test releases. It was in 2.6.9 also, unless I forget something. Can't verify right now. Steps to reproduce: - reboot For serial: - connect laptop to other computer with null modem cable - establish connection with 'minicom' on both sides. Verify it works. - do suspend/resume cycle - connection is not working any more. For infrared: - start IRDA (/etc/init.d/irda start) - switch on some IR enabled appliance, for example, cell phone - verify, with 'irdadump', that it is recognized - do suspend/resume cycle - now you are unable to see your device in 'irdadump'
If this is still a problem with latest kernels, please grab the contents of: /proc/interrupts /proc/tty/driver/serial both before and after trying to send/receive on the affected machine. Also a dmesg log after this attempt would be handy.
Please note that IrDA support isn't covered by the serial driver, so I can't comment on that aspect. However, if you can re-test whether the problem still remains (as previously requested) with a later kernel, that would be good. If not, I will have to reject this bug due to insufficient information.
I verified with 2.6.12. Bug remains. Setup: host under inversigation (T42p) connected via serial cable with another host. Serial is ttyS0. Both sides running minicom. Also, IDRA activated on ttyS1. After frech reboot: - communication over minicom's work as expected. - IRDA work (irdadump see my cell phone). - In separate experiment, if I run kernel with serial console, kernel messages displayed on 2-nd side. After suspend/resume: - chars on one minicom are not displayed on other one (both directions). After restart of minicom on test host, chars displayed on other side as number of dots (both sides) - IRDA do not work any more. - (separate run, with serial console) kernel messages seen as dots. requested data follows. I see: 'ehci_hcd:usb1' and 'yenta' changed in order at IRQ11 list ttyS1 signals changed (no more CTS and DSR) I'd be happy to assist gathering any information that may help. [~]$ cat /tmp/interrupts.before CPU0 0: 482644 XT-PIC timer 1: 485 XT-PIC i8042 2: 0 XT-PIC cascade 3: 2709 XT-PIC serial 4: 89 XT-PIC serial 5: 1484 XT-PIC Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, yenta 7: 3 XT-PIC parport0 9: 299 XT-PIC acpi 11: 25231 XT-PIC ipw2200, ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, yenta, eth0 12: 3101 XT-PIC i8042 14: 23635 XT-PIC ide0 15: 30799 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 [~]$ cat /tmp/interrupts.after CPU0 0: 515264 XT-PIC timer 1: 551 XT-PIC i8042 2: 0 XT-PIC cascade 3: 2874 XT-PIC serial 4: 89 XT-PIC serial 5: 1484 XT-PIC Intel 82801DB-ICH4, Intel 82801DB-ICH4 Modem, yenta 7: 3 XT-PIC parport0 9: 323 XT-PIC acpi 11: 26487 XT-PIC ipw2200, yenta, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, ehci_hcd:usb1, eth0 12: 5582 XT-PIC i8042 14: 23889 XT-PIC ide0 15: 32616 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 [~]# cat /tmp/serial.before serinfo:1.0 driver revision: 0: uart:NS16550A port:000003F8 irq:4 tx:112 rx:33 RTS|CTS|DTR|DSR 1: uart:NS16550A port:000002F8 irq:3 tx:23189 rx:4479 RTS|CTS|DTR|DSR 2: uart:unknown port:000003E8 irq:4 3: uart:unknown port:000002E8 irq:3 4: uart:unknown port:00000000 irq:0 5: uart:unknown port:00000000 irq:0 6: uart:unknown port:00000000 irq:0 7: uart:unknown port:00000000 irq:0 [~]# cat /tmp/serial.after serinfo:1.0 driver revision: 0: uart:NS16550A port:000003F8 irq:4 tx:112 rx:33 RTS|CTS|DTR|DSR 1: uart:NS16550A port:000002F8 irq:3 tx:24821 rx:4489 RTS|DTR 2: uart:unknown port:000003E8 irq:4 3: uart:unknown port:000002E8 irq:3 4: uart:unknown port:00000000 irq:0 5: uart:unknown port:00000000 irq:0 6: uart:unknown port:00000000 irq:0 7: uart:unknown port:00000000 irq:0
Created attachment 5252 [details] Test fix Please test whether this patch improves the situation. If you can do the same test as before, that'd be great. I note with disappointment that ttyS0 character counts/errors remained constant across the suspend/resume - please confirm whether you tried sending characters before capturing the ".after" results.
Your patch helpt somewhat. Still, after suspend/resume, already established serial link do not work. tx/rx counters in /proc/tty/driver/serial do not change regardless of keys pressed. However, after I close minicom and open it again, link works excellent! Missing (if running without patch) CTS and DSR are now on: 0: uart:NS16550A port:000003F8 irq:4 tx:74 rx:7 RTS|CTS|DTR|DSR This solves problem with ordinary serial link; but not with serial console. This case is more interesting for me. I wanted to use serial console to aid debugging power management of driver I develop. I hoped to get usefull info in case my driver oops on resume.
P.S. IRDA do not work after suspend/resume. I tried: - stop/start - stop, unload all modules including 8250, then start back - start IRDA only after suspend/resume In all cases - not work after resume.
It should work without having to close and re-open minicom. > Missing (if running without patch) CTS and DSR are now on: > 0: uart:NS16550A port:000003F8 irq:4 tx:74 rx:7 RTS|CTS|DTR|DSR I'm confused about this. Comment #3 indicates that ttyS0 did have CTS and DSR on. Is this line from the PC which was suspended/resumed or from the other PC? > This solves problem with ordinary serial link; but not with serial console. What part of serial console doesn't work? Note that any kernel messages between the point where the port becomes suspended and the port being resumed will not be sent via the port, but will only exist in the kernel message buffer (accessible via dmesg.) PS: I'm not expecting IrDA to change (see previous comments.)
All /proc snapshots was taken from PC that was suspended/resumed. For serial console, it becomes completely useless after suspend/resume since I can't restart serial link from its side.
I'm sorry, I'm out of ideas on this problem, especially as I find that I'm completely confused by what seems to be going on here. Sorry, but I don't see how I can progress this any further.
Ok, I think I have an idea what's going on here. When a port is opened by userspace, we zero out the consoles termios control flags so that when the port is subsequently re-opened, we don't reset the termios flags to the console setting, which may have been changed. The result is that if the port is resumed without it being open by userspace, we no longer have any record of the correct control flag settings. Hence, we are unable to restore the baud rate. Please verify by suspending/resuming with some userspace application keeping the serial port open.
*** Bug 5053 has been marked as a duplicate of this bug. ***
Ping?
I did test with minicom running. After resume, link is non-functional. However, if I quit minicom and start it again, link is OK.
That throws my only theory out the window. I'm afraid I don't have any boxes with 8250-compatible UARTs which support suspend/resume so I'm stumped on this one. Sorry.
On my TP 600X, the serial port works again after doing setserial -a /dev/ttyS0 upon resume (so it's not even necessary to restart minicom). > I'm afraid I don't have any boxes with 8250-compatible UARTs which > support suspend/resume This serial port is a 16550A. From dmesg: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A -Sanjoy
Yes, this is exactly the same behaviour that Vladimir is seeing, and therefore doesn't provide any additional clues. I think you're going to have to put up with a setserial -a /dev/ttyS0 or similar after resume for the time being. Sorry.
I noticed some strange things. I run now 2.6.13. /dev/ttyS0 is indeed serial port, /dev/ttyS1 is IRDA. 1-st, at boot time, there is output in /var/log/messages: Sep 1 23:55:28 vkondra-mobl kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled Sep 1 23:55:28 vkondra-mobl kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A Sep 1 23:55:28 vkondra-mobl kernel: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A Sep 1 23:55:28 vkondra-mobl kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A Sep 1 23:55:28 vkondra-mobl kernel: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A I don't understand last 2 lines. 2-nd, (after suspend/resume): [root@vkondra-mobl RPMS]# setserial -a /dev/ttyS0 /dev/ttyS0, Line 0, UART: undefined, Port: 0x03f8, IRQ: 4 Baud_base: 921600, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test [root@vkondra-mobl RPMS]# setserial -a /dev/ttyS1 /dev/ttyS1, Line 1, UART: undefined, Port: 0x02f8, IRQ: 3 Baud_base: 921600, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal skip_test auto_irq Note "UART: undefined" and "Baud_base: 921600"
Created attachment 5877 [details] serial printk patch The first two lines are a result of the legacy table. The second two lines are a result of the other probe drivers (8250_acpi / 8250_pnp) initialising. If you apply the serial printk patch, this will confirm this. As far as ttyS1 becoming undefined, compare like with like: check immediately before suspend what setserial reports for ttyS1 and recheck after resume. Don't rely on two different sources of information.
Does this bug relate to the problem described here? http://lkml.org/lkml/2006/4/26/123 Just a possible relation pointed out by Sanjoy. Regards Uli
No. The problem described in that email will result in the RTS and DTR modem control lines being inappropriately set to active state just before suspend, which may result in loss of characters (depending on the application.) Vladimir's bug is rather different.
Can anyone please tell me what the current status of this bug is?
Vladimir, can you confirm the problem is still there or it's gone in current kernel? Thanks.
Vladimir, Please test the 2.6.23 kernel and see if the problem is still there.
Closing. Please reopen if necessary, thanks.