Distribution: self compiled kernel (on debian 3.0) Hardware Environment: Fujitsu&Siemens Notebook Amilo 8820 Software Environment: Kernel (+ debian system) Problem Description: When booting via serial console (on standard PC UART 16550 based), the output starts correctly. But on ttyS0/1 probing the output is destroyed (baud rate not meassured yet with oscilloscope) - wrong characters are displayed. On the `open("/dev/console", ...)' in the kernel before starting `/sbin/init', the UART setting is repaired (so normal device setup on open is working correctly) and the system boots up normally. No console parameter is used, so I use default with 9600 baud (only 'console=ttyS0' is given). On my notebook I have problems with resume (system hagns). I want to use the serial console to debug that problem (as I to with embedded systems all the days), but on resume the serial console is also destroyed as after UART probing ! Steps to reproduce: Boot kernel with serial console and see the output .... Here a part of a log: : : ACPI: Battery Slot [BAT0] (battery present) ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLP2] ACPI: Lid Switch [LID] ACPI: Processor [CPU0] (supports C1 C2) ACPI: Thermal Zone [THRS] (42 C) ACPI: Thermal Zone [THRC] (52 C) pty: 256 Unix98 ptys configured Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected SiS 646 chipset agpgart: Maximum main memory to use for agp memory: 438M agpgart: AGP aperture is 64M @ 0xe8000000 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ
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.