driver ring buffer overrun and printf usage

[Dave Hylands]

Hi Amit,

On Thu, Jul 14, 2011 at 5:20 AM, Amit Nagal <helloin.amit at gmail.com> 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