Bug 2009
Summary: | Serial Console setup (16550 based) is destroyed by porbing and resuming | ||
---|---|---|---|
Product: | Drivers | Reporter: | Christoph Plattner (christoph.plattner) |
Component: | Serial | Assignee: | Russell King (rmk) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | ||
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.1, 2.6.2-rc2 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | Quickfix for the problem |
Description
Christoph Plattner
2004-02-03 15:30:19 UTC
Created attachment 3405 [details]
Quickfix for the problem
I've encountered the same problem and really had to get it resolved. I've
tracked down the problem to 8250.c. When the console-port have already been
initialized, there were used to be no check to avoid re-initialization of the
port, causing the serial driver to do some custom-chip probing, resulting in
garbled output. My patch simply disables that probing, and seems to have no bad
side-effects. Please review and come back with feedback.
I think something else other than the serial driver is accessing the port while the port is being probed, which _WILL_ be bad news. The full message is: Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled and it seems that we're messing the port up after "IRQ". However, I can not see _any_ way for this to happen with the code as I know it, since the console is synchronous to printk returning, and as such we will not have reached the probe code until after this message has been completed. So, unless you're using some other serial console code than the code in 8250.c, I'm at a loss to explain the behaviour you're seeing. Especially since I'm unable to reproduce the problem here. |