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 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 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
-
James Cameron -
Paul Fox