Bug 13356
| Summary: | Serial port misbehaves after undocking/docking | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Mikhail Gusarov (dottedmag) |
| Component: | Serial | Assignee: | Russell King (rmk) |
| Status: | CLOSED WILL_NOT_FIX | ||
| Severity: | normal | CC: | akpm, alan, hmh, lenb, nm127, rui.zhang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.31 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 56331 | ||
| Attachments: |
dmesg with "LSR safety check engaged!"
acpidump output (thinkpad t400) |
||
|
Description
Mikhail Gusarov
2009-05-21 17:44:23 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? > 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. Created attachment 21481 [details]
dmesg with "LSR safety check engaged!"
Last messages in dmesg correspond to attempt to run cu(1) on /dev/ttyS0 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 Len- what should happen on an ACPI docking event when it involves an onboard (non PCI hot plugged) serial port ? I'll reassign this to acpi/bios so it doesn't get lost. please attach the acpidump output Created attachment 21704 [details]
acpidump output (thinkpad t400)
Sure. Here it is.
Uhm. I can't reopen the bug, so it's left in NEEDINFO state. (needinfo is an open state - its ok) Just tested with 8250/8250_pnp built as modules, and it worked: reloading 8250/8250_pnp makes serial port to function properly. this looks like a serial driver problem to me. re-assign to the driver/serial category. Still waiting for Len Brown to answer comment #6 *ping* Any other information is needed? (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? Yes and yes. Just has been hit by it in 2.6.31-rc8, and confirmed again in 2.6.31. (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 ). Did not work with 2.6.16. Should I start with 1.0 and bisect? :) 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. 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. 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. Hard to tell, you would need to ask someone with ACPI expertise. Mikhail, does the problem still exist if you boot with boot option acpi_osi="!Windows 2001"? Yes. Unfortunately adding acpi_osi="!Windows 2001" did not change anything. |