On Thu, Sep 01, 2016 at 02:37:46PM +0530, Ajay Garg wrote:
> Hi All.
>
> Any, pointers, please?
>
> Is this a probable known issue?
> Asking because I saw one of the other emails on this list, stating
> that a lot of tty/serial patches are pending.
You can try out the linux-next tree if you wish to see all of those
patches applied.
But I doubt they will affect what you are seeing here.
>
> If so, kindly let know so that I can wait with peace of mind :)
>
>
> Thanks and Regards,
> Ajay
>
> On Tue, Aug 30, 2016 at 8:27 PM, Ajay Garg <ajaygargnsit@xxxxxxxxx> wrote:
> > Hi All.
> >
> > Following is our setup ::
> >
> > *
> > A pc-in-a-box embedded system, with 2 COM-ports, 2 USB-2.0 ports and 1
> > USB-3.0 port
> >
> > *
> > Ubuntu 14.0.4.3 installed as the OS.
> >
> > *
> > Vanilla C-application, reading/writing from 2 COM-ports and 1 USB-2.0 port.
> >
> >
> > First discussing about the USB-2.0 port, we have added a udev-rule, so
> > that the USB is always identified as "/dev/ttyUSB0".
> > In case the USB is not present, an appropriate error is returned via
> > the "open" call, and our binary exits (and restarts).
> >
> > For the COM-ports, they are hard-linked to "/dev/ttyS0" and
> > "/dev/ttyS1" respectively.
> >
> >
> > Now, in an ideal scenario, all the 3 ports have the devices connected to them.
> > So, the
> >
> > binary-start => open-ports => read/write => close-ports-before-binary-exit
> >
> > cycle works fine.
> >
> >
> > However, if let's say no device is physically connected to
> > "/dev/ttyS0", then the above cycle works ONLY THE FIRST TIME of
> > device-start.
> > Thereafter, the app-binary simply hangs trying to open "/dev/ttyS0"
> > (with no error being returned from the "open" call).
> >
> > I am using
> >
> > open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_SYNC)
> >
> > call for opening the port in question.
> >
> >
> > So is the code incorrect? Or this is expected behaviour? Or something
> > is wrong at kernel-level? Or something is wrong at the hardware-level?
Try running a "real" serial program, like minicom, on your hardware to
see if it acts the same way or not. That will help rule out either your
software, or the kernel/hardware.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
