On Mon, Aug 29, 2016 at 10:22:43PM +0530, Malith Yapa wrote:
> On Mon, Aug 29, 2016 at 4:46 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, Aug 29, 2016 at 02:49:23PM +0530, Malith Yapa wrote:
> >> On Thu, Jul 14, 2016 at 9:14 AM, Malith Yapa <malithyapa@xxxxxxxxx> wrote:
> >> > On Thu, Jul 14, 2016 at 2:14 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >> >> On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote:
> >> >>> I think i am.
> >> >>>
> >> >>> int readDword(int addr) {
> >> >>>
> >> >>> uint16_t reg[1];// will store read registers values
> >> >>>
> >> >>> int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2
> >> >>>
> >> >>> usleep(5);
> >> >>>
> >> >>> if (num != 1) {
> >> >>> fprintf(stderr, "Failed(%i) to read: %s\n", num,
> >> >>> modbus_strerror(errno));
> >> >>> modbus_close(ctx);
> >> >>> modbus_free(ctx);
> >> >>> sleep(5);
> >> >>> int wait = 1;
> >> >>> while(initModbus()) {
> >> >>> cerr << "Waiting for PLC.. SLEEP[" << wait*20 << "]" << endl;
> >> >>> sleep(wait*20);
> >> >>> wait++;
> >> >>> }
> >> >>> }
> >> >>>
> >> >>> return reg[0];
> >> >>> }
> >> >>>
> >> >>> according to modbus documentation, "The modbus_close() function shall
> >> >>> close the connection established with the backend set in the context."
> >> >>>
> >> >>> Even if not. Shouldn't the minor number's go upto 512 (as Johan
> >> >>> pointed out) before giving up?
> >> >>
> >> >> Yes it should.
> >> >>
> >> >>> The system is an Olimex A20-micro,
> >> >>> Linux version 3.4.90+ (gcc version 4.7.1 (Debian 4.7.1-7) )
> >> >>
> >> >> Ugh, 3.4 is a very old, and obsolete kernel version. Please get support
> >> >> for it from the vendor that is forcing you to use such a thing, as you
> >> >> are already paying for it from them.
> >> >>
> >> >> We can help you out if you can reproduce this on 4.6, have you tried
> >> >> that?
> >> >>
> >> >> thanks,
> >> >>
> >> >> greg k-h
> >> >
> >> > Looks like sunxi only provides a 3.4 kernel. I lack the expertise to
> >> > try to build 4.6 for this board so I'll try reporting it to them.
> >> >
> >> > Thanks,
> >> > Malith
> >>
> >> Hope it's ok to reply on the old thread.
> >>
> >> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
> >> of problem is solved. The minor number now definitely goes up to 512
> >> before giving no more free serial devices. But it still doesn't reuse
> >> the minors after disconnecting.
> >>
> >> In my code I'm calling modbus_close and modbus_free which in turn call
> >> close() and free() on the file descriptor. Shouldn't this make the
> >> minor reusable?
> >>
> >> >From what i understand minor numbers are allocated and freed by the
> >> driver. So how does the driver know to release the minor number after
> >> the file descriptor is closed?
> >
> > The USB serial driver core code handles this for you automatically after
> > the last reference goes away. Are you sure that userspace is properly
> > releasing the device properly?
> >
> > thanks,
> >
> > greg k-h
>
> >From my understanding it is, but let me double check. If i compile the
> kernel with some print statements in usb-serial.c, will i get the
> output in stdout?
You can use dynamic debugging on the usb_serial.ko kernel module to see
the open/close messages in the kernel log, along with when minors are
allocated. Read about how to turn that on in the Documentation/
directory (search for dynamic debugging).
> In the userspace is it sufficient to just call close() on the file
> descriptor in /dev ?
Yes.
> Is it possible that udev has already replaced /dev/ttyUSBx with
> /dev/ttyUSBx+1 by the time the program calls close() on it?
Yes, if it is open. And udev does not create the device node, the
kernel is doing so.
If your program/device does the following:
- userspace open ttyUSB0
- device disconnect
- device connect (ttyUSB1)
- userspace close ttyUSB0
- kernel removes ttyUSB0
that could be what is happening here, you are racing and loosing :(
Hope that helps,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
