Skip site navigation (1)Skip section navigation (2)
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>