Date: Tue, 2 Dec 2014 11:43:01 +0100 From: Ulrich Grey <usenet@ulrich-grey.de> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@freebsd.org Subject: Re: Another Test Run with Alternative pmap Implementation Message-ID: <20141202114301.040b9f05048bbf395e3f1096@ulrich-grey.de> In-Reply-To: <1417458072.1064.26.camel@revolution.hippie.lan> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <CAFHCsPXnSFY_X-O73M%2Bh0xO_XJ0cTmkRwtu-o4omPndnfbEhmg@mail.gmail.com> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <CAFHCsPWTnU7j0MC7YSHFFDE97%2B%2BBrnkJKGnK9zkxVGemaa6nAw@mail.gmail.com> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <CAFHCsPXPEN3U%2B0=AtAJ4dL5g7jGuyW6=u%2B-tbHf3xH1QdJYyhQ@mail.gmail.com> <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> <20141128001235.6591396b2f6298b861a96b57@ulrich-grey.de> <CAFHCsPUcB%2Bhirfd1k-199Syug0--rHLD1qKQcJSo2gvUoTRSPA@mail.gmail.com> <1417185069.1047.4.camel@revolution.hippie.lan> <CAFHCsPW12LMuuKeuQrW_GpLwSma1JohDqVXNW-N7DqSzd-HdPg@mail.gmail.com> <1417458072.1064.26.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141202114301.040b9f05048bbf395e3f1096>