Re: pl2303_read_int_callback - usb_submit_urb failed with result -19

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 31, 2016 at 02:30:15PM +0530, Malith Yapa wrote:
> On Mon, Aug 29, 2016 at 11:29 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 29 Aug 2016, Greg KH wrote:
> >
> >> > >> 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?
> >
> > Yes, it should.
> >
> >> > >> >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).
> >
> > The command is:
> >
> >         echo module usbserial =p >/sys/kernel/debug/dynamic_debug/control
> >
> > (note that you need to mount a debugfs filesystem on /sys/kernel/debug
> > first).
> >
> >> > 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 :(
> >
> > But even in this case, the kernel would re-use the old minor numbers
> > once the ttyUSB files had been closed.
> >
> > Alan Stern
> >
> 
> Turns out it was in fact a problem with libmodbus. Someone might even
> say it was a problem with how i used libmodbus :/

Yeah, glad you figured it out!

> Thanks a bunch for all the support. Never expected kernel threads to
> be this supportive :)

Hey now, we don't bite :)

> I would very much like to contribute, if there is something trivial
> that i can work on while learning.

Take a look at:
	http://www.labbott.name/blog/2016/08/15/ideas-for-getting-started-in-the-linux-kernel/

for some suggestions.

good luck!

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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux