Bug 13356 - Serial port misbehaves after undocking/docking
Summary: Serial port misbehaves after undocking/docking
Status: CLOSED WILL_NOT_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Serial (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Russell King
URL:
Keywords:
Depends on:
Blocks: 56331
  Show dependency tree
 
Reported: 2009-05-21 17:44 UTC by Mikhail Gusarov
Modified: 2013-04-09 06:23 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.31
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg with "LSR safety check engaged!" (75.65 KB, text/plain)
2009-05-22 06:18 UTC, Mikhail Gusarov
Details
acpidump output (thinkpad t400) (310.77 KB, text/plain)
2009-06-02 08:10 UTC, Mikhail Gusarov
Details

Description Mikhail Gusarov 2009-05-21 17:44:23 UTC
HW: Thinkpad T400, Lenovo Advanced mini-dock.

Serial port works fine if laptop is boot in dock, but after undocking/docking it starts to misbehave, from eating symbols (with "ttyS0: 1 input overrun(s)" in dmesg), to denying it exists at all (with "ttyS0: LSR safety check engaged!" in dmesg).
Comment 1 Márton Németh 2009-05-21 19:36:58 UTC
Is it possible for you to attach a full dmesg about the problem?
What distribution do you use?
Is your serial port driver compiled as module or is it linked to the kernel?
If it is a module does it help to unload the serial port module with rmmod and load it again with modprobe or insmod?
Comment 2 Mikhail Gusarov 2009-05-22 06:18:02 UTC
> Is it possible for you to attach a full dmesg about the problem?

See the attach (please, ignore the usb errors - it's misbehaving device I was debugging).

> What distribution do you use?

Debian (testing+unstable)

> Is your serial port driver compiled as module or is it linked to the kernel?

CONFIG_SERIAL_8250=y

8250 is the PC serial driver, is it?

> If it is a module does it help to unload the serial port module with rmmod
> and
load it again with modprobe or insmod?

I'll need to compile another kernel to check it. Sorry, don't have time to do it right now, will test day or two later.
Comment 3 Mikhail Gusarov 2009-05-22 06:18:41 UTC
Created attachment 21481 [details]
dmesg with "LSR safety check engaged!"
Comment 4 Mikhail Gusarov 2009-05-22 06:19:20 UTC
Last messages in dmesg correspond to attempt to run cu(1) on /dev/ttyS0
Comment 5 Alan 2009-05-24 14:02:40 UTC
Looks like an ACPI related funny. We get "[43274.788775] ACPI: \_SB_.GDCK - docking" but the ACPI firmware doesn't appear to sort out the hardware config for attaching the port. I'm not sure who is actually supposed to be handling this or how so I've cc'd Len the ACPI guru
Comment 6 Alan 2009-05-24 14:03:21 UTC
Len- what should happen on an ACPI docking event when it involves an onboard (non PCI hot plugged) serial port ?
Comment 7 Andrew Morton 2009-05-27 02:13:37 UTC
I'll reassign this to acpi/bios so it doesn't get lost.
Comment 8 Zhang Rui 2009-06-02 07:13:10 UTC
please attach the acpidump output
Comment 9 Mikhail Gusarov 2009-06-02 08:10:32 UTC
Created attachment 21704 [details]
acpidump output (thinkpad t400)

Sure. Here it is.
Comment 10 Mikhail Gusarov 2009-06-02 08:11:11 UTC
Uhm. I can't reopen the bug, so it's left in NEEDINFO state.
Comment 11 Alan 2009-06-02 09:04:57 UTC
(needinfo is an open state - its ok)
Comment 12 Mikhail Gusarov 2009-06-07 14:15:41 UTC
Just tested with 8250/8250_pnp built as modules, and it worked: reloading 8250/8250_pnp makes serial port to function properly.
Comment 13 Zhang Rui 2009-06-17 02:49:07 UTC
this looks like a serial driver problem to me.
re-assign to the driver/serial category.
Comment 14 Alan 2009-06-17 08:52:03 UTC
Still waiting for Len Brown to answer comment #6
Comment 15 Mikhail Gusarov 2009-09-12 11:16:37 UTC
*ping*

Any other information is needed?
Comment 16 Márton Németh 2009-09-12 18:30:17 UTC
(In reply to comment #15)
> Any other information is needed?

Is this problem still reproducible with the reacently released Linux kernel 2.6.31?
If yes, does the workaround mentioned in comment #12 still working?
Comment 17 Mikhail Gusarov 2009-09-12 18:33:12 UTC
Yes and yes.

Just has been hit by it in 2.6.31-rc8, and confirmed again in 2.6.31.
Comment 18 Márton Németh 2009-09-12 20:34:38 UTC
(In reply to comment #17)
> Just has been hit by it in 2.6.31-rc8, and confirmed again in 2.6.31.

If you have a previous version which was working properly and this is a regression then you might want to try "git bisecting" the problem (see http://kerneltrap.org/node/11753 ).
Comment 19 Mikhail Gusarov 2009-09-12 20:38:22 UTC
Did not work with 2.6.16. Should I start with 1.0 and bisect? :)
Comment 20 Márton Németh 2009-09-13 06:21:22 UTC
The fist Linux version in git is 2.6.11, see http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tags . If that one is also bad then this method will not work, you are right.

Unfortunately I don't have the necessary ACPI (Advanced Configuration & Power Interface) knowledge to find out what the problem could be. I only can give you a pointer where you can find the ACPI specification: http://www.acpi.info/ and you can try to find out the answer for comment #5 and comment #6.
Comment 21 Henrique de Moraes Holschuh 2009-09-20 21:04:09 UTC
ThinkPads usually have their serial ports in a LPC superIO chip.  The superIO chip is not in the dock, the dock just has the physical connectors.  So, the device is always available, and docking/undocking shouldn't be much of a factor, at least as far as the chip itself goes.

The DSDT seems to reflect this (PCI0.LPC.UART), including the dependency on the dock device, and empty _PS0/_PS3 methods (because it is always enabled as long as the PCI0.LPC.SIO device (super-IO chip) is).

What exactly are we doing to devices in the _EJD list when undocking? The answer for the problem is probably there.
Comment 22 Henrique de Moraes Holschuh 2010-01-24 13:16:49 UTC
Any updates?  If this is a BIOS bug, we need to know it soon in order to still have time to request a fix from Lenovo.
Comment 23 Alan 2010-01-25 15:31:52 UTC
Hard to tell, you would need to ask someone with ACPI expertise.
Comment 24 Zhang Rui 2010-01-27 07:44:14 UTC
Mikhail, does the problem still exist if you boot with boot option acpi_osi="!Windows 2001"?
Comment 25 Mikhail Gusarov 2010-01-27 10:35:21 UTC
Yes. Unfortunately adding acpi_osi="!Windows 2001" did not change anything.

Note You need to log in before you can comment on or make changes to this bug.