On May 19, 2009, at 7:11 PM, Alan Stern wrote:
On Tue, 19 May 2009, Greg KH wrote:
On Tue, May 19, 2009 at 04:08:00PM -0700, Rob Duncan wrote:
I have a composite device (multiple serial ports) where each serial
port is controlled by a separate instance of my driver. The driver
instances all use the default control pipe to make configuration
changes on the device via usb_control_msg(). Are there any special
locking requirements that I need to take into account so that the
driver instances do not interfere with each other when they use this
routine? I have been assuming that the answer to that question is
"No!", but I'm running into some surprising (to me) behavior.
The answer _is_ "No!", as far as the host side is concerned. The
device may have its own requirements.
It seems that if several drivers concurrently make several
configuration parameter changes via usb_control_msg() I occasionally
see some control transfers duplicated on the bus, and some missing
(each duplicate appears to have taken the place of a transfer from
another driver instance). I have added logging to my driver and see
the interleaved requests from the different driver instances, but
the
trace I obtain with the CATC bus analyzer doesn't match with my
logs.
That sounds pretty strange. Any logs we can look at?
In addition to the driver and CATC logs, a usbmon log would be
helpful.
That sort of behavior should never happen; if it does then it's a bug.
I'm happy to report that this is a false alarm. Or rather it appears
to be a bug in VMware 1.1: running on real hardware or a more recent
version of VMware doesn't exhibit this badness.
I thought I had reproduced the problem on real hardware before sending
my initial question, but I had mistakenly conflated two unrelated
problems and confused myself.
Thank you both very much for your help,
Rob.
--
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
