On Wed, 2013-02-06 at 21:17 +0100, Oliver Neukum wrote: > On Wednesday 06 February 2013 12:42:56 Dan Williams wrote: > > As part of the initialization sequence, the driver sends a SYNC message > > via the control pipe to the firmware, which appears to request a > > firmware restart. The firmware responds with an indication via the > > interrupt pipe set up by usbnet. If the driver does not receive a > > RESTART indication within a certain amount of time, it will periodically > > send additional SYNC messages until it receives the RESTART indication. > > > > Unfortunately, the interrupt URB is only submitted while the netdev > > is open, which is usually not the case during initialization, and thus > > the firmware's RESTART indication is lost. So the driver continues > > sending SYNC messages, and eventually the firmware crashes when it > > receives too many. This leads to a wedged netdev. > > If I understand this correctly we should stop the interrupt pipe once > RESTART has been recieved. I am afraid this patch is a bit inefficient. The firmware may send other indications to the host over the interrupt pipe at any time, apparently. However, I have not seen firmware send these indications in practice, so maybe we can ignore this and do as you suggest. So how would you suggest to handle this given the constraints? Basically, we need to allow sierra_net to submit dev->interrupt at probe/bind and then after a period of time kill it when it's no longer needed. The problem is that if the interface is set IFF_UP right after bind but before sierra_net has finished its SYNC/Restart dance, we need to ensure that sierra_net doesn't kill the URB unconditionally. One way to do this would be a new usbnet function to subdrivers could call to submit the URB which would be a NOP if the URB was already submitted. It would be paired with a function to kill the URB which would be a NOP if (URB already killed || (IFF_UP and subdriver has status() hook)). Kinda like refcounting the interrupt URB submission but not. Does that sound like a worthwhile approach? Dan -- 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
