New F14-arm build os21

[James Cameron]

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 at laptop.org> wrote:
> > On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff <martin at 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 Cameron
http://quozl.linux.org.au/