james wrote:
On Thu, Jul 21, 2011 at 12:14:14AM -0400, Martin Langhoff wrote:
On Wed, Jul 20, 2011 at 6:04 AM, Martin Langhoff martin@laptop.org wrote:
On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff martin@laptop.org wrote:
?- Updates olpc-utils to disable X zapping and fix serial port terminal
Initial testing seems to indicate serial port needs a bit more attention. I've also tested it with a newer kernel containing Paul's tty config fix, and it doesn't make a difference.
Looking at it again -- there is no apparent problem with using the serial port, only an early msg in var/log/messages
Jul 21 04:07:36 localhost init: ttySx main process (33) terminated with status 1
I looked into this.
/etc/init/ttyS.conf says "start on startup", but if it is changed to "start on runlevel [12345]" this strange message goes away. Perhaps it
that would probably be okay. when i changed our conf file to "start on startup" a year or more ago, it was to get the serial port up as soon as possible, because i was tired of not having it while the system booted. (it was being treated as a normal user getty before that, i think.)
paul
is caused by some interaction with upstart's init, or perhaps we are not following best practices in ttyS.conf.
(We have our own ttyS.conf, but curiously /etc/init/serial.conf might have been starting a process, but it says it requires ttyS2 to be the last or primary console in the kernel command line, and for it to be listed in /etc/securetty. Doing those things doesn't cause serial.conf to start a process though.)
But nothing seems to be broken
- shutdown/reboot works correctly (and the plymouth workaround has
been removed)
- switch to gnome / sugar works correctly
- bash is respawned correctly if you exit
My gut feel is that we still have something lurking here, but nothing we ship at the moment tries modem control on /dev/ttyS2. Not even ModemManager, according to strace. (Pity it doesn't ignore USB serial adapters as well.)
I looked briefly at the serial/pxa driver. When a user process configures for modem control on /dev/ttyS2 via termios, the upshot is the setting of bit AFE (Auto-flow Control Enable) in the UART MCR (modem control register). Good.
During serial_pxa_startup, /dev/ttyS3 is configured for AFE automatically. But I didn't see any obvious way at mmp2_add_uart time to tell the driver not to bother setting UART_MCR_AFE for /dev/ttyS2.
The control lines themselves aren't exposed, which is presumably why threads that do I/O hang.
But hey, the same thing happens on XO-1.5, just tested ... so we're good to go. ;-)
-- James Cameron http://quozl.linux.org.au/ _______________________________________________ Techteam mailing list Techteam@lists.laptop.org http://lists.laptop.org/listinfo/techteam _______________________________________________ Engineering mailing list Engineering@laptop.org http://lists.laptop.org/listinfo/engineering
=--------------------- paul fox, pgf@laptop.org