Date: Sun, 22 Dec 2013 14:50:33 -0700 From: Warner Losh <imp@bsdimp.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: mountroot issues (was Re: 10.0-release proposed patch for Atmel) Message-ID: <774852B0-2B02-46BD-8054-FAF3CB3DDAA7@bsdimp.com> In-Reply-To: <20131222192842.GI99167@funkthat.com> References: <B5B10EE3-955D-4A8C-A233-9DADF6898A54@bsdimp.com> <20131222192842.GI99167@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?774852B0-2B02-46BD-8054-FAF3CB3DDAA7>