driver ring buffer overrun and printf usage
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 ) ? do the actual implementation of printf involves any kind of sleeps ? kindly share necessary insight wrt above printf usage and driver ring buffer overrun . regards Amit Nagal
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 ) ?
do the actual implementation of printf involves any kind of sleeps ?
kindly share necessary insight wrt above printf usage and driver ring buffer overrun .
I had encountered a similar problem, I think the problem is in 'printing to serial console' which is a slow process (transfer rate is very less compared to other i/o), serial I/O may not be able to keep up to the pace at which kernel logging happens. In my case, there was no such custom application writing to the console, instead the logging daemon itself was the culprit, some other drivers were not able to meet some timing requirements because of the heavy serial logging and my solution was to reduce the console logging using 'dmesg -n' option -- Thanks Sudheer
Hi Amit, On Thu, Jul 14, 2011 at 5:20 AM, Amit Nagal <helloin.amit@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
participants (3)
-
Amit Nagal -
Dave Hylands -
Sudheer Divakaran