From owner-freebsd-arch@FreeBSD.ORG Sun Dec 22 21:50:41 2013 Return-Path: Delivered-To: freebsd-arch@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 AC0D1F56 for ; Sun, 22 Dec 2013 21:50:41 +0000 (UTC) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73CA71B4D for ; Sun, 22 Dec 2013 21:50:41 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id qd12so5288590ieb.15 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=F2Xy77/i3nKU4wTIY0ZECfZPcNlrLKVQ0WeVljO2TgqJgBCONvfuCNs99nUr44wWP4 3OAZ9Brtm2iTyhcCB2rJDFs2L5laZXSCvLE7LaDeHoC6Zit2ijdwvT8rI8hj+pFZIJZT iVmdc5K3NOxXeYnQTuoWimW7Do+W02N3Emk5VOJISBuCmWdJuHjeimLKv9RwKisQ7/fD SSlxA9PjQi0E8hplTVDXN45YZqam2nixzjHg+fuOhyY2XgId+h/x0/8e9mFHY71Zgj0f ioMLr3LA0wyIcXq8f6KtMhDvh/KJKdLJwf8F2fqjIItCL1qzrOSU0AY1Bb+hjHaDIao9 dbTQ== X-Gm-Message-State: ALoCoQlJic4+8zSd5fymgO3n1oaoDX3ae6i4eGjFmWBT+iNlNdPTpQ3BZEQN4B/CTOXFmrlctEhU 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-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 21:50:41 -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