/dev entry of USB device not disappearing after detach

[Valentina Manea]

Hello,

I am working on a driver for a virtual USB host controller. When I attach a USB
device, everything is fine - sysfs files are created, /dev entry is
created, device is usable.
However, when I detach it, the /dev entry still remains. The sysfs
files are removed, as expected. Obviously, the /dev entry is no longer
usable, e.g. it can't be used for mounting.

The output from udevmon is here [1]. vhci_hcd is the device representing the
USB hub and 2-1 is the bus ID of the attached device.

As far as I can tell, udevd receives the remove event but, for some
reason, the /dev entry still remains.

Any help is greatly appreciated.

Thanks,
Valentina

[1] http://pastebin.com/0M2pSGw1
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Greg KH]

Post by Valentina Manea
Hello,
I am working on a driver for a virtual USB host controller. When I attach a USB
device, everything is fine - sysfs files are created, /dev entry is
created, device is usable.
However, when I detach it, the /dev entry still remains. The sysfs
files are removed, as expected. Obviously, the /dev entry is no longer
usable, e.g. it can't be used for mounting.

What /dev entry are you referring to?

Did something have it held open while the device was still connected and
hasn't closed it yet?

Post by Valentina Manea
The output from udevmon is here [1]. vhci_hcd is the device representing the
USB hub and 2-1 is the bus ID of the attached device.
As far as I can tell, udevd receives the remove event but, for some
reason, the /dev entry still remains.

How about enabling debugging in the USB core to see what is going on
with the device removal path?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Greg KH]

Post by Greg KH

Post by Valentina Manea
Hello,
I am working on a driver for a virtual USB host controller. When I attach a USB
device, everything is fine - sysfs files are created, /dev entry is
created, device is usable.
However, when I detach it, the /dev entry still remains. The sysfs
files are removed, as expected. Obviously, the /dev entry is no longer
usable, e.g. it can't be used for mounting.

What /dev entry are you referring to?
Did something have it held open while the device was still connected and
hasn't closed it yet?

Also, the kernel is the one now responsible for managing the /dev node
creation/removal, through devtmpfs, there shouldn't be any "hotplug"
scripts involved in this process, so I doubt it's a userspace issue.

you do have CONFIG_DEVTMPFS enabled in your kernel, right?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Valentina Manea]

Post by Greg KH
Also, the kernel is the one now responsible for managing the /dev node
creation/removal, through devtmpfs, there shouldn't be any "hotplug"
scripts involved in this process, so I doubt it's a userspace issue.
you do have CONFIG_DEVTMPFS enabled in your kernel, right?

Hi Greg,

It seems I did not have CONFIG_DEVTMPFS and, with this option, the bug
is no longer reproducible. Since, as I've read, devtmpfs has replaced
tmpfs, there's no point in further debugging.

Thanks,
Valentina
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Greg KH]

Post by Valentina Manea

Post by Greg KH
Also, the kernel is the one now responsible for managing the /dev node
creation/removal, through devtmpfs, there shouldn't be any "hotplug"
scripts involved in this process, so I doubt it's a userspace issue.
you do have CONFIG_DEVTMPFS enabled in your kernel, right?

Hi Greg,
It seems I did not have CONFIG_DEVTMPFS and, with this option, the bug
is no longer reproducible. Since, as I've read, devtmpfs has replaced
tmpfs, there's no point in further debugging.

Ok, that makes sense, it wasn't a "bug", it was just that nothing was
around to delete the device node at all (udev no longer does this, it
relies on devtmpfs to be present). So all was working just fine.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html