From owner-freebsd-arm@FreeBSD.ORG Mon Apr 21 01:06:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B172C998; Mon, 21 Apr 2014 01:06:21 +0000 (UTC) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (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 8ADBA17A2; Mon, 21 Apr 2014 01:06:20 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id s3L16Jhm092206; Mon, 21 Apr 2014 01:06:19 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.101] (192.168.1.66 [192.168.1.66]) by kientzle.com with SMTP id 82pxb6idnwdnrffzq6aihxnebw; Mon, 21 Apr 2014 01:06:19 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Curious BeagleBone console hang... From: Tim Kientzle In-Reply-To: <1398040513.1124.369.camel@revolution.hippie.lan> Date: Sun, 20 Apr 2014 18:06:19 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <723E6F77-A274-4115-8D37-C12353494EA1@freebsd.org> <1398040513.1124.369.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: FreeBSD ARM X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 01:06:21 -0000 On Apr 20, 2014, at 5:35 PM, Ian Lepore wrote: > On Sun, 2014-04-20 at 16:37 -0700, Tim Kientzle wrote: >> Here's an odd one: >> >> $ stty 72 >> >> consistently hangs the serial console on a BeagleBone >> running FreeBSD-CURRENT r264208. (I found this out >> by accidentally omitting 'rows' when I typed the command.) >> >> Doesn't seem to affect an SSH session, only the serial console. >> >> After doing this, nothing seems to be running; the console >> is just completely non responsive: even echo is dead. >> >> I can recover by logging in through SSH and killing the >> console login. >> >> Trying to puzzle it out: >> >> $ truss stty 72 >> ... >> ioctl(0,TIOCGETA,0xbffffcb0) = 0 (0x0) >> ioctl(0,TIOCGETD,0xbffffc9c) = 0 (0x0) >> ioctl(0,TIOCGWINSZ,0xbffffcdc) = 0 (0x0) >> ioctl(1,TIOCGETA,0xbffffb60) = 0 (0x0) >> ioctl(2,TIOCGETA,0xbffffb60) = 0 (0x0) >> fstat(1,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0) >> fstat(2,{ mode=crw------- ,inode=32,size=0,blksize=4096 }) = 0 (0x0 >> >> >> Does this make sense to anyone? >> >> Tim > > You're setting the line speed to 72 baud, and due to recent kernel > changes the console baud rate is allowed to be changed now, so you lose > console comms as soon as the change takes effect. Thank you! I went through the stty man page several times and consistently overlooked the description for a bare number. That makes perfect sense. I guess getty must reset the line when the login session exits, which would explain why killing the login session recovers it. Tim