Date: Tue, 09 Dec 2008 10:41:58 -0700 From: Scott Long <scottl@samsco.org> To: Mike Tancsa <mike@sentex.net> Cc: Marcel Moolenaar <xcllnt@mac.com>, freebsd-current@freebsd.org Subject: Re: uart vs sio differences ? Message-ID: <493EADE6.60508@samsco.org> In-Reply-To: <493EA759.4000504@samsco.org> References: <200812081621.mB8GLMxB041498@lava.sentex.ca> <ED8BC24F-EAC3-4266-AF54-4C6262DDC156@mac.com> <200812081906.mB8J6oha042222@lava.sentex.ca> <CF6E0ACA-CCFA-4A35-A88F-C95484309A78@mac.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?493EADE6.60508>