[OLPC Engineering] [Techteam] New F14-arm build os21

[Paul Fox]

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 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

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 at lists.laptop.org
 > http://lists.laptop.org/listinfo/techteam
 > _______________________________________________
 > Engineering mailing list
 > Engineering at laptop.org
 > http://lists.laptop.org/listinfo/engineering

=---------------------
 paul fox, pgf at laptop.org