Date: Mon, 01 Dec 2014 11:21:12 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Svatopluk Kraus <onwahe@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: Another Test Run with Alternative pmap Implementation Message-ID: <1417458072.1064.26.camel@revolution.hippie.lan> In-Reply-To: <CAFHCsPW12LMuuKeuQrW_GpLwSma1JohDqVXNW-N7DqSzd-HdPg@mail.gmail.com> References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <C6FED1A5-490C-47BE-B071-484271ED370E@me.com> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <CAFHCsPUJ1HhLqAjitPg6mPzhMYSui64Xmu4omO7Pkp%2B0kPZnAA@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1417458072.1064.26.camel>