Thanks a ton Greg ... that really helped !!
Ultimately, it turned out that I was missing the O_NDELAY flag in the
"open" call.
ORing that flag solved the issue !!
Thanks and Regards,
Ajay
On Thu, Sep 1, 2016 at 8:18 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> 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
--
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
