Another Test Run with Alternative pmap Implementation

[Ulrich Grey]

Hello,

I use a Serial to USB cable to connect the wandboard to a Raspberry.

Now, on the wandboard, I have changed in file /etc/ttys this line

ttyu0   "/usr/libexec/getty std.115200" vt100   on secure

to

ttyu0   "/usr/libexec/getty 3wire.115200"       vt100   on secure

On the Raspberry I issue

script outfile.txt
cu -l/dev/cuaU0 -s115200

So I get the output from the wandbord recorded in the file outfile.txt.
This file can not be corrupted if the wandboard crashes.
(The Raspberry runs  FreeBSD 10.1-PRERELEASE #8 r273483M without problems.)

The test

cd /usr/src
make -j20 buildworld

now finished successfully.

Start: Mo 20:01:55, completed: Tue 02:39:50

Thank you to you all for advice 

Regards

Ulrich
----------------------------------
On Mon, 01 Dec 2014 11:21:12 -0700
Ian Lepore <ian at FreeBSD.org> wrote:

> On Mon, 2014-12-01 at 15:32 +0100, Svatopluk Kraus wrote:
> > Hi Ian,
> > 
> > after some more tests, it looks now that there is a probem with tty. Ulrich
> > sent me more infos requested by me from several tests which hanged, and it
> > always hangs on same place. Last (youngest) process childs related to test
> > is always this:
> > 
> > ex - /usr/local/DEVEL/STREJDA/freebsd/share/termcap/termcap.src
> > 
> > and it's waiting for "ttydcd" (mwchan) -> tty data carry detect? Ulrich
> > tried to change his hardware (teminal setup) and it helped. Do you have any
> > idea what could be wrong considering wandboard? I looked at kernel tty
> > module and there was some work around recently too. Ulrich told me that
> > before our last update of git repository (Freebsd-current merge), it does
> > not hang sometimes.
> > Svata
> 
> 'ex -' is actually a batch-mode of vi and the input for that command is
> a redirect from a source file.  I used 'truss' to run that command by
> hand and it appears that vi (actually ncurses I suppose) tries to get
> terminfo from stdin, and that fails because it's a file, so then it
> opens /dev/tty to get the terminfo from there.  The command is also run
> with TERM=dumb TERMCAP=dumb: in the environment.
> 
> That open of /dev/tty is the only thing I can think of that could get
> into a dcdwait state while running make.  But that makes it all pretty
> murky to me about what it's actually doing in a dcdwait state.  
> 
> If you're connected via ssh your terminal is xterm.  What does modem
> carrier state mean in that case?  If you're on the serial console and
> are using the standard /etc/ttys file your terminal type should be
> "3wire" and that forces the "clocal" flag on, which disables dcdwait and
> other modem-control stuff.  If you're on the serial console and the
> entry in /etc/ttys is std<.speed> then that is probably the problem, and
> changing that entry to 3wire will probably fix it.
> 
> The other thing that can get you into a dcdwait state is if two threads
> or processes are trying to open or close the same tty at the same time.
> The dcdwait state is used to force single-threading through the open and
> close routines.  I don't see how that applies here either.
> 
> -- Ian
> 
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"