Bug 4270

Summary: serial interfaces do not work after suspend/resume
Product: Drivers Reporter: Vladimir Kondratiev (vladimir.kondratiev)
Component: SerialAssignee: Russell King (rmk)
Status: REJECTED INSUFFICIENT_DATA    
Severity: normal CC: bunk, protasnb, sanjoy
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.11-rc5-bk3 Subsystem:
Regression: --- Bisected commit-id:
Bug Depends on:    
Bug Blocks: 7216    
Attachments: Test fix
serial printk patch

Description Vladimir Kondratiev 2005-03-01 11:11:08 UTC
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'
Comment 1 Russell King 2005-06-26 15:29:05 UTC
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.
Comment 2 Russell King 2005-07-01 15:18:28 UTC
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.
Comment 3 Vladimir Kondratiev 2005-07-02 12:54:59 UTC
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
Comment 4 Russell King 2005-07-02 14:17:19 UTC
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.
Comment 5 Vladimir Kondratiev 2005-07-03 11:34:06 UTC
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.
Comment 6 Vladimir Kondratiev 2005-07-03 11:39:11 UTC
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.
Comment 7 Russell King 2005-07-03 12:38:54 UTC
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.)
Comment 8 Vladimir Kondratiev 2005-07-03 23:44:21 UTC
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.
Comment 9 Russell King 2005-08-10 10:21:29 UTC
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.
Comment 10 Russell King 2005-08-28 10:05:54 UTC
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.
Comment 11 Russell King 2005-08-28 10:06:31 UTC
*** Bug 5053 has been marked as a duplicate of this bug. ***
Comment 12 Russell King 2005-09-01 07:39:18 UTC
Ping?
Comment 13 Vladimir Kondratiev 2005-09-01 08:31:31 UTC
I did test with minicom running. After resume, link is non-functional.
However, if I quit minicom and start it again, link is OK.
Comment 14 Russell King 2005-09-01 08:36:32 UTC
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.
Comment 15 Sanjoy Mahajan 2005-09-01 08:45:15 UTC
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

Comment 16 Russell King 2005-09-01 08:58:23 UTC
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.
Comment 17 Vladimir Kondratiev 2005-09-03 07:55:09 UTC
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"
Comment 18 Russell King 2005-09-03 08:03:25 UTC
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.
Comment 19 Uli Luckas 2006-04-27 00:36:04 UTC
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
Comment 20 Russell King 2006-04-27 00:58:51 UTC
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.

Comment 21 Rafael J. Wysocki 2007-08-09 09:31:55 UTC
Can anyone please tell me what the current status of this bug is?
Comment 22 Natalie Protasevich 2007-09-22 22:55:25 UTC
Vladimir, can you confirm the problem is still there or it's gone in current kernel?
Thanks.
Comment 23 Rafael J. Wysocki 2007-10-12 13:13:02 UTC
Vladimir,
Please test the 2.6.23 kernel and see if the problem is still there.
Comment 24 Rafael J. Wysocki 2007-12-12 17:04:00 UTC
Closing.  Please reopen if necessary, thanks.