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.
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?
>
> Sorry for me being all over the place, but I am a serious newbie, with
> loads of willingness to learn :)
> So will be grateful for any pointers on how to identify the root-cause
> and fixing it.
>
>
> Thanks and Regards,
> Ajay
--
Regards,
Ajay
--
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
