From owner-freebsd-current@FreeBSD.ORG Tue Dec 9 17:42:02 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 772771065670 for ; Tue, 9 Dec 2008 17:42:02 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE648FC13 for ; Tue, 9 Dec 2008 17:42:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id mB9HfwCt019827; Tue, 9 Dec 2008 10:41:58 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <493EADE6.60508@samsco.org> Date: Tue, 09 Dec 2008 10:41:58 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Mike Tancsa References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <200812081906.mB8J6oha042222@lava.sentex.ca> <200812082049.mB8KnHSN042710@lava.sentex.ca> <84A7F176-5A74-48AC-859A-C0D4C7CBCB48@mac.com> <7.1.0.9.0.20081208173515.13f62e88@sentex.net> <200812091457.mB9EvLSD047534@lava.sentex.ca> <493EA759.4000504@samsco.org> In-Reply-To: <493EA759.4000504@samsco.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Marcel Moolenaar , freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 17:42:02 -0000 Scott Long wrote: > Mike Tancsa wrote: >> At 05:39 PM 12/8/2008, Mike Tancsa wrote: >> >>> What it appears to be is that as long as data is coming in, even at >>> 1200bps, the ioctl FIONREAD returns zero and an actual read does not >>> return any data until there is either a pause in the data coming in >>> or possibly when we do a xmit/write at which point the accumulated >>> data is available for us to read. >>> >>> We dont know if this is due to the hardware fifo or something in the >>> driver itself. >> >> OK, I think we found the issue! >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=121421 >> >> Not sure if the semantics are exactly right, but adding >> >> hint.uart.0.flags="0x100" >> hint.uart.1.flags="0x100" >> hint.uart.2.flags="0x100" >> hint.uart.3.flags="0x100" >> >> to device.hints fixed the issue! >> >> The next question-- is there a way to do this with the ucom driver as >> well ? We are seeing the same issue with it. >> >> ---Mike > > It's pretty sad that the uart driver can't keep up with the 16550 at > full FIFO depth, though I can see exactly why. Even though the driver > will normally use a fast interrupt handler, that handler does nothing > but schedule the sio swi thread. Well, I shouldn't say that that's the > only thing it does; it also does a spinwait on a home-rolled semaphore > with the swi thread, something that I'm not sure I understand. Maybe > the author thought that there was a risk of missed wakeups of the swi? > > That aside, I think what needs to happen is for the driver to use the > interrupt handler to pull the bytes out of the hardware and into an > internal lockless ring buffer, then schedule the swi to process the ring > buffer. I'll see if I can come up with some code for this today. Not > sure if the same can be done for ucom since the USB stack below it > presents a lot more complications and overhead. > > Scott > Bah, that's what I get for reading code before I'm awake. The uart driver does do exactly what I suggest it should. It has a 384 byte ring buffer, which should be more than enough. So I wonder if the spin-wait on the swi semaphore is what is killing it, though. Scott