g_serial hangs on write when the cable is disconnected

g_serial hangs on write when the cable is disconnected

[Laszlo Papp]

Hi,

The code below reproduces the issue. The code is intentionally kept
small, so it deliberately does not have error checking, et al.

Now, my concern is that it blocks for the write operation if the cable
is disconnected. This is not inline with the /dev/ttyS* operation, for
instance. They would not block if I disconnected the serial cable.

Is this a bug or feature? :-) If it turns out to be a feature, is it
better to use O_NONBLOCK if one does not want to use pthreads, etc?

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main()
{
    const char buf[] = "Hello World!\n";
    int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
    int sent = write(fd, buf, sizeof(buf)-1);
    close(fd);
    return 0;
}

Cheers, L.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Greg KH]

On Wed, Aug 05, 2015 at 11:05:56AM +0100, Laszlo Papp wrote:
> Hi,
> 
> The code below reproduces the issue. The code is intentionally kept
> small, so it deliberately does not have error checking, et al.
> 
> Now, my concern is that it blocks for the write operation if the cable
> is disconnected. This is not inline with the /dev/ttyS* operation, for
> instance. They would not block if I disconnected the serial cable.
> 
> Is this a bug or feature? :-) If it turns out to be a feature, is it
> better to use O_NONBLOCK if one does not want to use pthreads, etc?
> 
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> 
> int main()
> {
>     const char buf[] = "Hello World!\n";
>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);

This line discipline is very different from the "traditional" tty line
discipline, so it might not know anything about cable removals.

good luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Laszlo Papp]

On Wed, Aug 5, 2015 at 3:56 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Aug 05, 2015 at 11:05:56AM +0100, Laszlo Papp wrote:
>> Hi,
>>
>> The code below reproduces the issue. The code is intentionally kept
>> small, so it deliberately does not have error checking, et al.
>>
>> Now, my concern is that it blocks for the write operation if the cable
>> is disconnected. This is not inline with the /dev/ttyS* operation, for
>> instance. They would not block if I disconnected the serial cable.
>>
>> Is this a bug or feature? :-) If it turns out to be a feature, is it
>> better to use O_NONBLOCK if one does not want to use pthreads, etc?
>>
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <fcntl.h>
>>
>> int main()
>> {
>>     const char buf[] = "Hello World!\n";
>>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
>
> This line discipline is very different from the "traditional" tty line
> discipline, so it might not know anything about cable removals.
>
> good luck,
>
> greg k-h
> --

Thank you for your prompt reply.

Wow, I managed to mess it up in my original email! So, this code above
made it working, but without O_NONBLOCK, it was not working. Using
O_NONBLOCK is my current nasty workaround. As you are indicating it,
this does not quite feel right, does it! I am not sure what the right
thing would be to do in order to get write non-blocking for g_serial.
I hope that someone with more knowledge about it than me could help
out!

Thank you in advance.


> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Greg KH]

On Wed, Aug 05, 2015 at 04:40:21PM +0100, Laszlo Papp wrote:
> On Wed, Aug 5, 2015 at 3:56 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> > On Wed, Aug 05, 2015 at 11:05:56AM +0100, Laszlo Papp wrote:
> >> Hi,
> >>
> >> The code below reproduces the issue. The code is intentionally kept
> >> small, so it deliberately does not have error checking, et al.
> >>
> >> Now, my concern is that it blocks for the write operation if the cable
> >> is disconnected. This is not inline with the /dev/ttyS* operation, for
> >> instance. They would not block if I disconnected the serial cable.
> >>
> >> Is this a bug or feature? :-) If it turns out to be a feature, is it
> >> better to use O_NONBLOCK if one does not want to use pthreads, etc?
> >>
> >> #include <sys/types.h>
> >> #include <sys/stat.h>
> >> #include <fcntl.h>
> >>
> >> int main()
> >> {
> >>     const char buf[] = "Hello World!\n";
> >>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
> >
> > This line discipline is very different from the "traditional" tty line
> > discipline, so it might not know anything about cable removals.
> >
> > good luck,
> >
> > greg k-h
> > --
> 
> Thank you for your prompt reply.
> 
> Wow, I managed to mess it up in my original email! So, this code above
> made it working, but without O_NONBLOCK, it was not working. Using
> O_NONBLOCK is my current nasty workaround. As you are indicating it,
> this does not quite feel right, does it! I am not sure what the right
> thing would be to do in order to get write non-blocking for g_serial.
> I hope that someone with more knowledge about it than me could help
> out!

I doubt the O_NONBLOCK setting does anything, this is a character
device, with a very specific line discipline that works in a very
specific way and assumes you know exactly how to talk to it and
communicate with it properly.

Why not look at some examples of userspace code that uses this
connection properly to see how they do it?

good luck,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Peter Stuge]

Greg KH wrote:
> > >>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
> > >
> > > This line discipline is very different from the "traditional" tty
> > > line discipline
..
> this is a character device, with a very specific line discipline
> that works in a very specific way and assumes you know exactly how
> to talk to it and communicate with it properly.

If the character device is called tty* then I think it is appropriate
to expect that it (by default) behaves like a "traditional" tty device.

How the kernel implements this device internally (ldisc or no)
shouldn't matter to the user, and if it does I'd consider that a bug.
(Sadly unfixable, because public API.)

=> Rather than defending unexpected behavior, why not admit that the
name was poorly chosen and point to the device-specific requirements?


Thanks

//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Greg KH]

On Wed, Aug 05, 2015 at 07:09:27PM +0200, Peter Stuge wrote:
> Greg KH wrote:
> > > >>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
> > > >
> > > > This line discipline is very different from the "traditional" tty
> > > > line discipline
> ..
> > this is a character device, with a very specific line discipline
> > that works in a very specific way and assumes you know exactly how
> > to talk to it and communicate with it properly.
> 
> If the character device is called tty* then I think it is appropriate
> to expect that it (by default) behaves like a "traditional" tty device.
> 
> How the kernel implements this device internally (ldisc or no)
> shouldn't matter to the user, and if it does I'd consider that a bug.
> (Sadly unfixable, because public API.)
> 
> => Rather than defending unexpected behavior, why not admit that the
> name was poorly chosen and point to the device-specific requirements?

hm, wait, is this really the n_gsm line discipline?  Or is it something
else?

g_serial is the device side of a serial connection, there is no "cable
removed" notification that it even knows about, that has to come from
the gadget driver somehow, which you should listen for and then kick
your userspace program.

Yeah, gadget devices are odd...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Alan Stern]

On Wed, 5 Aug 2015, Greg KH wrote:

> hm, wait, is this really the n_gsm line discipline?  Or is it something
> else?
> 
> g_serial is the device side of a serial connection, there is no "cable
> removed" notification that it even knows about, that has to come from
> the gadget driver somehow, which you should listen for and then kick
> your userspace program.

There is the gserial_disconnect() callback, which gets invoked when the 
Vbus power (provided by the host) is removed.  It's a pretty good 
indicator that the USB cable has been unplugged.

I don't understand all the stuff that gserial_disconnect() does, but it 
ought to be more or less equivalent to a "hangup" -- as the kerneldoc 
says.  If it doesn't do what users expect, there's probably a bug 
somewhere.

Of course, it's possible that the callback does not get invoked in 
Laszlo's case.  Then the question would be: Why not?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Laszlo Papp]

On Wed, Aug 5, 2015 at 5:29 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Aug 05, 2015 at 04:40:21PM +0100, Laszlo Papp wrote:
>> On Wed, Aug 5, 2015 at 3:56 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
>> > On Wed, Aug 05, 2015 at 11:05:56AM +0100, Laszlo Papp wrote:
>> >> Hi,
>> >>
>> >> The code below reproduces the issue. The code is intentionally kept
>> >> small, so it deliberately does not have error checking, et al.
>> >>
>> >> Now, my concern is that it blocks for the write operation if the cable
>> >> is disconnected. This is not inline with the /dev/ttyS* operation, for
>> >> instance. They would not block if I disconnected the serial cable.
>> >>
>> >> Is this a bug or feature? :-) If it turns out to be a feature, is it
>> >> better to use O_NONBLOCK if one does not want to use pthreads, etc?
>> >>
>> >> #include <sys/types.h>
>> >> #include <sys/stat.h>
>> >> #include <fcntl.h>
>> >>
>> >> int main()
>> >> {
>> >>     const char buf[] = "Hello World!\n";
>> >>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
>> >
>> > This line discipline is very different from the "traditional" tty line
>> > discipline, so it might not know anything about cable removals.
>> >
>> > good luck,
>> >
>> > greg k-h
>> > --
>>
>> Thank you for your prompt reply.
>>
>> Wow, I managed to mess it up in my original email! So, this code above
>> made it working, but without O_NONBLOCK, it was not working. Using
>> O_NONBLOCK is my current nasty workaround. As you are indicating it,
>> this does not quite feel right, does it! I am not sure what the right
>> thing would be to do in order to get write non-blocking for g_serial.
>> I hope that someone with more knowledge about it than me could help
>> out!
>
> I doubt the O_NONBLOCK setting does anything, this is a character
> device, with a very specific line discipline that works in a very
> specific way and assumes you know exactly how to talk to it and
> communicate with it properly.

At least, it puts me in the illusin then that it seems to unblock the
port when disconnected. That is why I decided to go for this for now.
I will follow your advice to look for a good example if I can find
one. Thanks.

> Why not look at some examples of userspace code that uses this
> connection properly to see how they do it?
>
> good luck,
>
> greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Laszlo Papp]

On Wed, Aug 5, 2015 at 6:09 PM, Peter Stuge <peter-Y+HMSxxDrH8@public.gmane.org> wrote:
> Greg KH wrote:
>> > >>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
>> > >
>> > > This line discipline is very different from the "traditional" tty
>> > > line discipline
> ..
>> this is a character device, with a very specific line discipline
>> that works in a very specific way and assumes you know exactly how
>> to talk to it and communicate with it properly.
>
> If the character device is called tty* then I think it is appropriate
> to expect that it (by default) behaves like a "traditional" tty device.
>
> How the kernel implements this device internally (ldisc or no)
> shouldn't matter to the user, and if it does I'd consider that a bug.
> (Sadly unfixable, because public API.)
>
> => Rather than defending unexpected behavior, why not admit that the
> name was poorly chosen and point to the device-specific requirements?

I see. Yes, if it is not supposed to behave like a traditional "tty"
device, then the name was indeed poorly chosen. Unfortunately, there
is not much that can be done about that now for compatibility reasons
as you are writing. So I just need to find how not to block then while
doing it properly. Apparently, O_NONBLOCK is not the right thing for
that as I am being told.

Thank you for your answer.

>
>
> Thanks
>
> //Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Laszlo Papp]

Hi Alan,

On Wed, Aug 5, 2015 at 7:15 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> On Wed, 5 Aug 2015, Greg KH wrote:
>
>> hm, wait, is this really the n_gsm line discipline?  Or is it something
>> else?
>>
>> g_serial is the device side of a serial connection, there is no "cable
>> removed" notification that it even knows about, that has to come from
>> the gadget driver somehow, which you should listen for and then kick
>> your userspace program.
>
> There is the gserial_disconnect() callback, which gets invoked when the
> Vbus power (provided by the host) is removed.  It's a pretty good
> indicator that the USB cable has been unplugged.
>
> I don't understand all the stuff that gserial_disconnect() does, but it
> ought to be more or less equivalent to a "hangup" -- as the kerneldoc
> says.  If it doesn't do what users expect, there's probably a bug
> somewhere.
>
> Of course, it's possible that the callback does not get invoked in
> Laszlo's case.  Then the question would be: Why not?

Hmm, that is a good question. I wonder if there had been any recent
fixes for that lately... I suppose that I will need to skim through
the git log. Thank you for the hints!

> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Alan Stern]

On Thu, 6 Aug 2015, Laszlo Papp wrote:

> Hi Alan,
> 
> On Wed, Aug 5, 2015 at 7:15 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> > On Wed, 5 Aug 2015, Greg KH wrote:
> >
> >> hm, wait, is this really the n_gsm line discipline?  Or is it something
> >> else?
> >>
> >> g_serial is the device side of a serial connection, there is no "cable
> >> removed" notification that it even knows about, that has to come from
> >> the gadget driver somehow, which you should listen for and then kick
> >> your userspace program.
> >
> > There is the gserial_disconnect() callback, which gets invoked when the
> > Vbus power (provided by the host) is removed.  It's a pretty good
> > indicator that the USB cable has been unplugged.
> >
> > I don't understand all the stuff that gserial_disconnect() does, but it
> > ought to be more or less equivalent to a "hangup" -- as the kerneldoc
> > says.  If it doesn't do what users expect, there's probably a bug
> > somewhere.
> >
> > Of course, it's possible that the callback does not get invoked in
> > Laszlo's case.  Then the question would be: Why not?
> 
> Hmm, that is a good question. I wonder if there had been any recent
> fixes for that lately... I suppose that I will need to skim through
> the git log. Thank you for the hints!

You should also add a printk statement to the disconnect callback so 
that you can verify whether it really is getting called.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Laszlo Papp]

On Thu, Aug 6, 2015 at 2:52 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> On Thu, 6 Aug 2015, Laszlo Papp wrote:
>
>> Hi Alan,
>>
>> On Wed, Aug 5, 2015 at 7:15 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>> > On Wed, 5 Aug 2015, Greg KH wrote:
>> >
>> >> hm, wait, is this really the n_gsm line discipline?  Or is it something
>> >> else?
>> >>
>> >> g_serial is the device side of a serial connection, there is no "cable
>> >> removed" notification that it even knows about, that has to come from
>> >> the gadget driver somehow, which you should listen for and then kick
>> >> your userspace program.
>> >
>> > There is the gserial_disconnect() callback, which gets invoked when the
>> > Vbus power (provided by the host) is removed.  It's a pretty good
>> > indicator that the USB cable has been unplugged.
>> >
>> > I don't understand all the stuff that gserial_disconnect() does, but it
>> > ought to be more or less equivalent to a "hangup" -- as the kerneldoc
>> > says.  If it doesn't do what users expect, there's probably a bug
>> > somewhere.
>> >
>> > Of course, it's possible that the callback does not get invoked in
>> > Laszlo's case.  Then the question would be: Why not?
>>
>> Hmm, that is a good question. I wonder if there had been any recent
>> fixes for that lately... I suppose that I will need to skim through
>> the git log. Thank you for the hints!
>
> You should also add a printk statement to the disconnect callback so
> that you can verify whether it really is getting called.

Thanks. Should that also be called if I just boot up the board with
Linux on it while the cable is not attached. In other words, the
problem that I am also experiencing is that it blocks even when no
cable is attached to the board and there has been no cable ever
attached for the last boot.

>
> Alan Stern
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Alan Stern]

On Thu, 6 Aug 2015, Laszlo Papp wrote:

> > You should also add a printk statement to the disconnect callback so
> > that you can verify whether it really is getting called.
> 
> Thanks. Should that also be called if I just boot up the board with
> Linux on it while the cable is not attached.

No.  It gets called only at the time you unplug the cable.

> In other words, the
> problem that I am also experiencing is that it blocks even when no
> cable is attached to the board and there has been no cable ever
> attached for the last boot.

You didn't mention this before.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Peter Hurley]

[ +cc Felipe ]

Hi Laszlo,

On 08/06/2015 10:03 AM, Laszlo Papp wrote:
> On Thu, Aug 6, 2015 at 2:52 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>> On Thu, 6 Aug 2015, Laszlo Papp wrote:
>>> On Wed, Aug 5, 2015 at 7:15 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>>>> On Wed, 5 Aug 2015, Greg KH wrote:
>>>>
>>>>> hm, wait, is this really the n_gsm line discipline?  Or is it something
>>>>> else?
>>>>>
>>>>> g_serial is the device side of a serial connection, there is no "cable
>>>>> removed" notification that it even knows about, that has to come from
>>>>> the gadget driver somehow, which you should listen for and then kick
>>>>> your userspace program.
>>>>
>>>> There is the gserial_disconnect() callback, which gets invoked when the
>>>> Vbus power (provided by the host) is removed.  It's a pretty good
>>>> indicator that the USB cable has been unplugged.
>>>>
>>>> I don't understand all the stuff that gserial_disconnect() does, but it
>>>> ought to be more or less equivalent to a "hangup" -- as the kerneldoc
>>>> says.  If it doesn't do what users expect, there's probably a bug
>>>> somewhere.
>>>>
>>>> Of course, it's possible that the callback does not get invoked in
>>>> Laszlo's case.  Then the question would be: Why not?
>>>
>>> Hmm, that is a good question. I wonder if there had been any recent
>>> fixes for that lately... I suppose that I will need to skim through
>>> the git log. Thank you for the hints!
>>
>> You should also add a printk statement to the disconnect callback so
>> that you can verify whether it really is getting called.
> 
> Thanks. Should that also be called if I just boot up the board with
> Linux on it while the cable is not attached. In other words, the
> problem that I am also experiencing is that it blocks even when no
> cable is attached to the board and there has been no cable ever
> attached for the last boot.

You have everyone hopelessly confused about what your problem actually is.

Your $subject says that "g_serial hangs on write" and for a reproducer
you provide:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main()
{
    const char buf[] = "Hello World!\n";
    int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
    int sent = write(fd, buf, sizeof(buf)-1);
    close(fd);
    return 0;
}

Only a careful reader would have caught this in your subsequent reply:

On Wed, Aug 05, 2015 at 04:40:21PM +0100, Laszlo Papp wrote:
> Wow, I managed to mess it up in my original email! So, this code above
> made it working, but without O_NONBLOCK, it was not working. Using
> O_NONBLOCK is my current nasty workaround.

To answer your original question, yes, the write() is behaving as expected.
If you open a tty without O_NONBLOCK, then both read() and write() to that
tty will _block_ until the operation is successful or the tty is hung up.

Your comparison with how ttyS* ports behave when a cable is not connected
is based on incorrect assumptions. When a ttyS port is in CLOCAL mode
(the default), the cable state is ignored when _opening_. On write(),
without hardware flow control (CRTSCTS), the serial port is successfully
writing the data out without knowing that nothing is listening.

I don't see a bug here.

Regards,
Peter Hurley




--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: g_serial hangs on write when the cable is disconnected

[Laszlo Papp]

On Thu, Aug 6, 2015 at 4:16 PM, Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org> wrote:
> [ +cc Felipe ]
>
> Hi Laszlo,
>
> On 08/06/2015 10:03 AM, Laszlo Papp wrote:
>> On Thu, Aug 6, 2015 at 2:52 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>>> On Thu, 6 Aug 2015, Laszlo Papp wrote:
>>>> On Wed, Aug 5, 2015 at 7:15 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
>>>>> On Wed, 5 Aug 2015, Greg KH wrote:
>>>>>
>>>>>> hm, wait, is this really the n_gsm line discipline?  Or is it something
>>>>>> else?
>>>>>>
>>>>>> g_serial is the device side of a serial connection, there is no "cable
>>>>>> removed" notification that it even knows about, that has to come from
>>>>>> the gadget driver somehow, which you should listen for and then kick
>>>>>> your userspace program.
>>>>>
>>>>> There is the gserial_disconnect() callback, which gets invoked when the
>>>>> Vbus power (provided by the host) is removed.  It's a pretty good
>>>>> indicator that the USB cable has been unplugged.
>>>>>
>>>>> I don't understand all the stuff that gserial_disconnect() does, but it
>>>>> ought to be more or less equivalent to a "hangup" -- as the kerneldoc
>>>>> says.  If it doesn't do what users expect, there's probably a bug
>>>>> somewhere.
>>>>>
>>>>> Of course, it's possible that the callback does not get invoked in
>>>>> Laszlo's case.  Then the question would be: Why not?
>>>>
>>>> Hmm, that is a good question. I wonder if there had been any recent
>>>> fixes for that lately... I suppose that I will need to skim through
>>>> the git log. Thank you for the hints!
>>>
>>> You should also add a printk statement to the disconnect callback so
>>> that you can verify whether it really is getting called.
>>
>> Thanks. Should that also be called if I just boot up the board with
>> Linux on it while the cable is not attached. In other words, the
>> problem that I am also experiencing is that it blocks even when no
>> cable is attached to the board and there has been no cable ever
>> attached for the last boot.
>
> You have everyone hopelessly confused about what your problem actually is.
>
> Your $subject says that "g_serial hangs on write" and for a reproducer
> you provide:
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
>
> int main()
> {
>     const char buf[] = "Hello World!\n";
>     int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
>     int sent = write(fd, buf, sizeof(buf)-1);
>     close(fd);
>     return 0;
> }
>
> Only a careful reader would have caught this in your subsequent reply:
>
> On Wed, Aug 05, 2015 at 04:40:21PM +0100, Laszlo Papp wrote:
>> Wow, I managed to mess it up in my original email! So, this code above
>> made it working, but without O_NONBLOCK, it was not working. Using
>> O_NONBLOCK is my current nasty workaround.

Yes, of course. I made a mistake with that and I apologise.

> To answer your original question, yes, the write() is behaving as expected.
> If you open a tty without O_NONBLOCK, then both read() and write() to that
> tty will _block_ until the operation is successful or the tty is hung up.
>
> Your comparison with how ttyS* ports behave when a cable is not connected
> is based on incorrect assumptions. When a ttyS port is in CLOCAL mode
> (the default), the cable state is ignored when _opening_. On write(),
> without hardware flow control (CRTSCTS), the serial port is successfully
> writing the data out without knowing that nothing is listening.

Yes, you are right with that. There is no way to detect errors without
some handshaking on the serial port.

For now, O_NONBLOCK, it is, until I find a better example to work with.

> I don't see a bug here.

It is very likely just a missing example in the documentation. I do
not think that there is a bug in here.

> Regards,
> Peter Hurley
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html