On Fri, 19 Mar 2004, Matthias Andree wrote:
> > On Thu, 18 Mar 2004, David Brownell wrote:
> >
> > > Software that tries to change the device configuration would
> > > certainly cause lots of hotplugging. Basically that's a bad
> > > idea. There's a call to just _reset_ the configuration, that
> > > verges on reasonable ... for devices that only have a single
> > > driver on the device interfaces.
The problem is that usb_reset_configuration is so new that it's not
exported to user programs via usbfs or libusb. There's one possible
solution in the patch below: Make the set_configuration call in usbfs do
reset_configuration instead if the new config is the same as the existing
one.
> I believe I've identified the trigger of the problem. Log attached
> (Linux 2.6), with usb.agent running with "set -x".
>
> I don't understand why this hotplug version executes several processes
> of usb.agent for the same device at the same time, but that's probably
> off-topic for this list.
They are started at different times (all within a very short period), but
usb.agent includes a 3-second delay so they end up overlapping. Each time
usb_set_configuration is called, it generates a pair of hotplug events.
And something is calling it several times within a single second.
> Hotplug's usb.agent runs usbmodules, and just sampling one of the
> usbmodules invocations from the log and feeding them through strace
> yields:
>
> ...
> close(3) = 0
> munmap(0x40016000, 4096) = 0
> open("/proc/bus/usb/003/002", O_RDWR) = 3
> ioctl(3, USBDEVFS_CONTROL, 0xbfffefb0) = 18
> ioctl(3, USBDEVFS_CONTROL, 0xbfffeb70) = 9
> ioctl(3, USBDEVFS_CONTROL, 0xbfffeb70) = 32
> close(3) = 0
> exit_group(0) = ?
>
> So we do know that usbmodules run on behalf of hotplug issues
> USBDEVFS_CONTROL.
It sure looks as though usbmodules could stand a little rewriting. The
18-byte call is Get_Device_Descriptor, and the 9- and 32-byte calls are
Get_Configuration_Descriptor. All that information is already available
through usbfs and sysfs; there's no reason at all to do I/O with the
device. Furthermore the timeouts are ridiculously low, but maybe that's
been changed in a more recent version of the hotplug package.
Matthias, try using the patch below in place of the ones I sent earlier.
It replaces the set_configuration call that's starting all the hotplug
activity with reset_configuration, and it logs the pid and name of the
process issuing the call so we can tell what program is the guilty party.
Alan Stern
===== devio.c 1.88 vs edited =====
--- 1.88/drivers/usb/core/devio.c Wed Mar 17 14:16:46 2004
+++ edited/drivers/usb/core/devio.c Fri Mar 19 10:41:57 2004
@@ -751,9 +751,15 @@
{
unsigned int u;
+ printk(KERN_DEBUG "usbfs: proc_setconfig: pid %d, %s\n",
+ current->pid, current->comm);
if (get_user(u, (unsigned int __user *)arg))
return -EFAULT;
- return usb_set_configuration(ps->dev, u);
+ if (ps->dev->actconfig &&
+ ps->dev->actconfig->desc.bConfigurationValue == u)
+ return usb_reset_configuration(ps->dev);
+ else
+ return usb_set_configuration(ps->dev, u);
}
static int proc_submiturb(struct dev_state *ps, void __user *arg)
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
