From owner-freebsd-arm@FreeBSD.ORG Mon Dec 1 18:21:17 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45A69BC5 for ; Mon, 1 Dec 2014 18:21:17 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B952218 for ; Mon, 1 Dec 2014 18:21:16 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XvVb0-00088A-Iv; Mon, 01 Dec 2014 18:21:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sB1ILD4C005502; Mon, 1 Dec 2014 11:21:13 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19xL5omsYQYH5Z57jcl+vOC X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Another Test Run with Alternative pmap Implementation From: Ian Lepore To: Svatopluk Kraus In-Reply-To: References: <20141113125236.b16cd4e5f0e339eac0494cd4@ulrich-grey.de> <20141115143444.5ad037548e06f289d2532fb7@ulrich-grey.de> <20141119225903.81fbbc7809093a0e6e0de9d5@ulrich-grey.de> <20141120151900.a68c6d8316b96a62cb65d17a@ulrich-grey.de> <20141121115941.54d4e36b103341c3adf7eb36@ulrich-grey.de> <20141124132733.4e96b906f0d1ab69969dddd9@ulrich-grey.de> <1416840814.1147.380.camel@revolution.hippie.lan> <20141125225451.924a5df4bdb4753db273b8c5@ulrich-grey.de> <20141127234239.e2c40a8fb99ba41f9ec3a7e7@ulrich-grey.de> <20141128001235.6591396b2f6298b861a96b57@ulrich-grey.de> <1417185069.1047.4.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Mon, 01 Dec 2014 11:21:12 -0700 Message-ID: <1417458072.1064.26.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:21:17 -0000 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