Description of problem: I'm trying to use a USB-serial adapter for my system console and it does not seem to be working properly. Using a standard serial port (ttyS1) as the console does work properly though. Consequently, I cannot get initscripts output when using ttyUSB0 as my console. i.e. Using ttyS1 as my console works fine, here's my grub.conf boot kernel entry: kernel /boot/vmlinuz-2.6.19-1.2895.uplogix.14 ro root=/dev/hda1 panic=5 console=tty0 console=ttyS1,115200 I get initscripts output and can for example 'echo test >/dev/console' and get the output via ttyS1. However, when I try to use a usb-serial console: kernel /boot/vmlinuz-2.6.19-1.2895.uplogix.14 ro root=/dev/hda1 panic=5 console=tty0 console=ttyUSB0,115200 I get no initscripts output. And when I 'echo test >/dev/console', I get absolutely nothing out of ttyUSB0. When I add 'CONSOLE=/dev/ttyUSB0' to my kernel command line, init seems to read CONSOLE from the environment and will use that instead of /dev/console. But the output comes out at 9600 instead of the 115200 baud rate I wanted. This seems to be an issue regardless of the USB-serial driver. I've used the io_ti driver with my IO Edgeport adapter and mos7840 driver for my Moschip USB-serial device. I've tried it with the default kernel build and I've done my on compile with my kernel config that built in: # # USB Serial Converter support # CONFIG_USB_SERIAL=y CONFIG_USB_SERIAL_CONSOLE=y CONFIG_USB_SERIAL_EDGEPORT_TI=y CONFIG_USB_SERIAL_MOS7840=y FYI, partial kernel boot messages will come out of ttyUSB0. But /dev/console never seems to work properly. Version-Release number of selected component (if applicable): kernel-2.6.19-1.2895 SysVinit-2.86-14 initscripts-8.45.3-1 How reproducible: Plug in a USB-serial adapter and add console=ttyUSB0 to the kernel command line. Use minicom or whatnot to try to get the output and see that no initscripts output comes. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
AFAIK, the console= argument cannot be provided by something that is modular (as usb is.)
As noted above, I did compile in the modules proper.. And it still didn't work. At any rate, to get around the problem, I've patched my init: --- sysvinit-2.86.orig/src/init.c 2007-11-01 13:16:02.000000000 -0500 +++ sysvinit-2.86/src/init.c 2007-11-01 14:06:49.000000000 -0500 @@ -694,7 +694,7 @@ (void) tcgetattr(fd, &tty); tty.c_cflag &= CBAUD|CBAUDEX|CSIZE|CSTOPB|PARENB|PARODD; - tty.c_cflag |= HUPCL|CLOCAL|CREAD; + tty.c_cflag |= HUPCL|CLOCAL|CREAD|B115200; tty.c_cc[VINTR] = 3; /* ctrl('c') */ tty.c_cc[VQUIT] = 28; /* ctrl('\\') */ So now init is using /dev/ttyUSB0 as I've set 'CONSOLE=/dev/ttyUSB0' on my kernel command line and it's getting passed to the environment. The patch simply has init setting the baud rate to 115200 every time. It would be nice if init could read another environment variable, say CONSOLE_BAUD or something similar and set that if it exists. Or maybe make init smart enough to parse CONSOLE like 'console' is parsed from the kernel command line. i.e. CONSOLE=/dev/ttyUSB0,115200 would tell init to use ttyUSB0 and set it's baud rate to 115200..
Did you compile in the usb host adapter, etc. as well? If the usb driver isn't honoring the baud rate, that's probably a kernel bug. I really don't think it belongs in init to set it.
Yup. Compiled in everything USB. I'm not sure I'd say the driver isn't honoring the baud rate. I get the kernel boot messages at 115200 which has nothing to do with my little hack. Somewhere along the way, something is changing the baud rate to 9600.
Right, but if it's not needed for 'normal' serial, it shouldn't be needed for USB. What's your inittab line look like for it, if there is one?
Agreed, that's why I opened the bug.. :) I have an entry to run agetty, but that's it: a0:2345:once:/sbin/agetty /dev/ttyUSB0 -t 60 115200 That part has always worked okay though..
I'm too swamped to look at this promptly. The USB console is just not a good idea. Consider that it must have interrupts open to function, which is not true for any normal console. It's entirely useless in case of any crash. But if you do not have a crash, why have it at all? Just use a netconsole instead. That said, please attach /proc/bus/usb/devices. The usb-serial has a legion of subdrivers, each of which may fail to set termios right. BTW, please try F8. It has massive cleanups to termios handling by Alan Cox. It's VERY likely that Alan cleared any improper and/or erroneous termios handling scattered across usb-serial subdrivers. Even if you cannot deploy F8 on that box now, we need to know if this bug is a dead-end.
(This is a mass-update to all current FC6 kernel bugs in NEW state) Hello, I'm reviewing this bug list as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora!
Per the previous comment in this bug, I am closing it as INSUFFICIENT_DATA, since no information has been lodged for over 30 days. Please re-open this bug or file a new one if you can provide the requested data, and thanks for filing the original report!