Hi Amit,
On Thu, Jul 14, 2011 at 5:20 AM, Amit Nagal <helloin.amit@xxxxxxxxx> wrote:
> Hi ,
>
> In my embedded linux-arm target , in a userspace thread , i am reading
> hid events over usb-hiddev interface (/dev/hiddev) .
>
> basically what i do is this :
>
> read_thread(){
> while(1){
> ret = read( "/dev/hiddev" , user_buffer , bytes_to_read);
> printf("bytes received =%d" , ret ) ; // (printf prints debug message
> to serial console );
> }
> }
>
> now whenever i use the printf statement in read thread , kernel space
> ring buffer in usb-hid driver is overrun frequently , which results
> in loss of data send by usb device .
> if i remove printf in read thread , no overruns are reported in
> usb-hid driver . that means if printf is used , application
> read_thread is not able to
> read data in time which leads to driver ring buffer overrun .
>
> does this behaviour of printf points to some problem in embedded
> linux's scheduler ( printf prints data to debug serial port , and
> consecutive read() calls in read_thread() are scheduled lately due
> to that ) ?
No - It points to the fact that you're trying to generate more
bandwidth than the serial port can process.
> do the actual implementation of printf involves any kind of sleeps ?
Absolutely. Let's say that your serial port is running at 115K baud.
That means that you can send approximately 11,500 characters/second.
If you try to generate higher bandwidth than this then you will
eventually fill whatever buffers exist, and then you'll sleep waiting
for space to become available in the buffer.
> kindly share necessary insight wrt above printf usage and driver ring
> buffer overrun .
For situations like this, you typically need to log to a memory buffer
(I normally use a circular buffer of some type and have new entries
overwrite old entries).
Then when you're finished, you can dump information from the memory buffer.
--
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
