Printf hangs when internal buffer of driver is temporarily full

Printf hangs when internal buffer of driver is temporarily full

[Philip Oberstaller]

Hi,

I'm writing a driver for the Exar's XR20M1280 SPI-based serial port
using kernel version 3.4.17.

If a string, which is considerably longer than the driver's internal buffer
(512 bytes), is written with printf/fprintf to the dedicated port, then the
function call hangs after the driver's write_room function returns zero,
which happens when the driver's internal buffer is temporarily full.
I would have expected that the TTY layer or the libc implementation of
printf would requery write_room automatically and thus would notice
after a while that there is space again, but this doesn't seem to happen.
Eventually the printf function returns after a very long timeout but without
that the remaining characters have been printed.

I based my code mainly on the ifx6x60-driver and I looked at other similar
drivers as well, but I can't see that they are using a different strategy.

In a dated driver book it was suggested that write_room and write should
always return at least one. I could use busy waiting in the write function
until there is space for at least one character, but I hope that there is
a better solution around?!

Thanks,
Philip

[Please CC me, I'm not on the list]

________________________________

This e-mail communication contains information that is confidential and may also be privileged. It is intended for the exclusive use of the addressees. If you are not the person or organization to whom it is addressed, you must not copy, distribute or take any action in reliance upon it. If you received this communication in error, please notify Septentrio nv immediately [ telephone +32 [0] 16 300800 ]. Septentrio nv will not accept liability for contractual commitments made by individuals employed by this company outside the scope of our business.

Re: Printf hangs when internal buffer of driver is temporarily full

[Greg KH]

On Mon, Jan 14, 2013 at 02:11:31PM +0100, Philip Oberstaller wrote:
> Hi,
> 
> I'm writing a driver for the Exar's XR20M1280 SPI-based serial port
> using kernel version 3.4.17.

We can't take drivers for older kernel versions, why not write it for
3.8 and then backport it when finished?

> If a string, which is considerably longer than the driver's internal buffer
> (512 bytes), is written with printf/fprintf to the dedicated port, then the
> function call hangs after the driver's write_room function returns zero,
> which happens when the driver's internal buffer is temporarily full.
> I would have expected that the TTY layer or the libc implementation of
> printf would requery write_room automatically and thus would notice
> after a while that there is space again, but this doesn't seem to happen.

That's right, the printf call should return a "short" write, but really,
you should use write() and friends for tty ports, not fprintf, if at all
possible to handle this type of error better.

> Eventually the printf function returns after a very long timeout but without
> that the remaining characters have been printed.
> 
> I based my code mainly on the ifx6x60-driver and I looked at other similar
> drivers as well, but I can't see that they are using a different strategy.
> 
> In a dated driver book it was suggested that write_room and write should
> always return at least one. I could use busy waiting in the write function
> until there is space for at least one character, but I hope that there is
> a better solution around?!

I don't think so, sorry.

> This e-mail communication contains information that is confidential
> and may also be privileged.

<snip>

This type of footer really isn't good to have for public mailing list
posts, it directly goes against the fact that you sent this to thousands
of people in a public manner :)

thanks,

greg k-h

Re: Printf hangs when internal buffer of driver is temporarily full

[Alan Cox]

> which happens when the driver's internal buffer is temporarily full.
> I would have expected that the TTY layer or the libc implementation of
> printf would requery write_room automatically and thus would notice

How is it going to magically notice ?

> after a while that there is space again, but this doesn't seem to happen.
> Eventually the printf function returns after a very long timeout but without
> that the remaining characters have been printed.

You need to wake it up and tell it there is room in your completion
interrupts. It will then think about retrying.

> I based my code mainly on the ifx6x60-driver and I looked at other similar
> drivers as well, but I can't see that they are using a different strategy.
> 
> In a dated driver book it was suggested that write_room and write should
> always return at least one.

I would suggest recycling that book 8)

Alan

Re: Printf hangs when internal buffer of driver is temporarily full

[Philip Oberstaller]

On 01/14/2013 08:36 PM, Alan Cox wrote:
>> which happens when the driver's internal buffer is temporarily full.
>> I would have expected that the TTY layer or the libc implementation of
>> printf would requery write_room automatically and thus would notice
>
> How is it going to magically notice ?
>
>> after a while that there is space again, but this doesn't seem to happen.
>> Eventually the printf function returns after a very long timeout but without
>> that the remaining characters have been printed.
>
> You need to wake it up and tell it there is room in your completion
> interrupts. It will then think about retrying.

Yeah, behind the magic there is most of the time some manual work. Thanks
for the hint of the wakeup! That definitely makes it working. Don't ask
me why I didn't see it before...

> I would suggest recycling that book 8)

Agreed, but as it's pretty cold these days, it might well be used for
some other purpose...

(Sorry for the disclaimer, but it cannot be circumvented when sending
from this domain - at least I would not know how)

________________________________

This e-mail communication contains information that is confidential and may also be privileged. It is intended for the exclusive use of the addressees. If you are not the person or organization to whom it is addressed, you must not copy, distribute or take any action in reliance upon it. If you received this communication in error, please notify Septentrio nv immediately [ telephone +32 [0] 16 300800 ]. Septentrio nv will not accept liability for contractual commitments made by individuals employed by this company outside the scope of our business.