From owner-freebsd-arm@FreeBSD.ORG Sun Dec 22 21:50:36 2013 Return-Path: Delivered-To: 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 B1F80F55 for ; Sun, 22 Dec 2013 21:50:36 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A62F1B4C for ; Sun, 22 Dec 2013 21:50:36 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hk11so19651367igb.0 for ; Sun, 22 Dec 2013 13:50:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6uDmgAL98JDk42NCR3xur7VDhTja6d1/Lr9QzvTAWeE=; b=eBBlpHkI0EZIH3pms62my1SRMA6jWWz2sA1uH0wS3gvqR6xoqgmUe+Jt4z656UlCZg xNFTCX2rnbh+Wwpt5mc63m6LHBRi2m4/jPm8/euF5pEuUiJFgzp9k5RfSNWPx7VSvJU1 Sh1Ib9xSWKc2hJqmLvnW7+J+kLIExTqAQKWixrV5dk5HhWo2K6Zw91x5YAJOpKapPrtw I/LLzuMSwulVFxqJktj0IbhlQ3ulb7a8riENTQAd7y4Lwh7Ck09sCmoDudOxjB3xiVRP JA+N13+cuzqS9owQXrCCZXbJk0AJ4r6RkQ25Yvq3hUUbThlPdukkXD12GFt8zr3ENyvi z32A== X-Gm-Message-State: ALoCoQkim0h+MtMTaaDq+kqIxngcMDrAE8ZoldmFcV5pkJqlCV7gVcCbiDQOuac2I5VhYefGJlFp X-Received: by 10.50.73.136 with SMTP id l8mr18450781igv.7.1387749035552; Sun, 22 Dec 2013 13:50:35 -0800 (PST) Received: from [10.0.0.23] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ml2sm17347417igb.10.2013.12.22.13.50.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Dec 2013 13:50:35 -0800 (PST) Sender: Warner Losh Subject: Re: mountroot issues (was Re: 10.0-release proposed patch for Atmel) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20131222192842.GI99167@funkthat.com> Date: Sun, 22 Dec 2013 14:50:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <774852B0-2B02-46BD-8054-FAF3CB3DDAA7@bsdimp.com> References: <20131222192842.GI99167@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1085) Cc: "freebsd-arm@freebsd.org" , freebsd-arch@freebsd.org 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: Sun, 22 Dec 2013 21:50:36 -0000 On Dec 22, 2013, at 12:28 PM, John-Mark Gurney wrote: > Warner Losh wrote this message on Sat, Dec 21, 2013 at 23:44 -0700: >> Right now, the mountroot prompt doesn't work on Atmel CPUs. Almost = all the characters are eaten. I recently committed an elegant fix for = this into head to mask the interrupt for new characters and only do = polling. >=20 > So, a similar issue plages i386/amd64 too. There the console mostly > works, but it will drop characters on occasion... The problem is that > mount root spins calling into the console code instead of asking the > console code for a single character and having the console code wait > for this character... and if you type a character while it's outside > the console routines, that character will be dropped... I don't think that's the problem... Why is the character dropping? > The problem is, not many of us spend time at the mountroot prompt, and > so even if we notice the issue, it's so minor that we just deal w/ > it... If characters are being dropped, it is because interrupts are enabled, = the interrupt fires and the ISR eats them. This will happen because we = don't properly implement cngrab/cnungrab in the serial driver at the = moment... I guess I've just gotten lucky and not been bit by this, or if I have it = has been so infrequently that it hasn't registered. With Atmel, it = happens all the time and I've seen it for perhaps a decade... > The method I came up with years ago was to add a routine/flag that = would > have the console wait for a character instead of simply returning when > there was no character... Though if we implement cngrab properly = where > we don't flush buffers, turn off interupts, etc, then that would work > too... That's the more robust way to cope. cngrab works really well... > I've cc'd -arch since it's not just an -arm issue. >=20 Agreed.=20 Warner