Hi Greg, Thanks for the reply. I verified that only the expected respective application processes are associated with the devices through lsof. Physically disconnecting the device resolves the problem... but I'm developing an application where this isn't a viable option. Could the application where the device is held busy after it closes be due to the ioctl(fd,TIOCEXCL) call? It's hard to get a description of the params in ioctl_list, but this seems to say that the given device should only be allowed access by the calling application. The device is not restored to global access (ioctl(fd,TIOCNXCL)). I forgot to mention, I can access the device through root no problem. Still, it's strange that this only occurs with my FTDI device. Regards, Pris On Thu, Dec 22, 2011 at 12:41 PM, Greg KH <greg@xxxxxxxxx> wrote: > On Thu, Dec 22, 2011 at 09:17:06AM -0500, Pris Matic wrote: >> Hiya, >> >> I'm having a really strange issue with a particular device that uses >> the FTDI serial chipset. After connection, I'm able to initially open >> and communicate with the device no problem. Issues occur when trying >> to close the device connection. Some applications are able to close >> the device without any issue. In other cases the device seems to >> remain open, and attempting to open the device again will result in a >> "Device or resource busy" error message. The only way to resolve this >> is to physically reconnect the device. From a development standpoint, >> issuing a close() on the device fd returns successfully and there >> doesn't seem to be any indication that the device should remain in a >> 'busy' state. This problem does not occur with another device that >> uses a serial chipset by Prolific... in that case, all applications >> are able to successfully close the device and re-open it. >> >> I ran an strace on one application which did close the device >> successfully, and one application which did not. I tried to isolate >> the relevant information from each trace: >> [http://pastebin.com/riJKvCS4]. I'm not too sure what else I can do to >> help figure out what's going on and would appreciate any advice. I'm >> running Arch Linux, kernel v 3.1.5-1. > > Those strace outputs look fine, but are you sure that no other program > also has opened the port at the same time? If so, all applications need > to let it go. > > If you disconnect the device, all programs that have the port open will > get a HANGUP signal, and then they should close the device properly. > Have you tried that? > > And for the "failure" version, does using lsof show any other program > that is connected to the device? > > thanks, > > 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
