On Tue, 29 Oct 2013, Prasad Koya wrote:
> Thanks for looking into the patch. Am fairly new to the USB subsystem.
> You are right. There is a possibility of going into infinite loop with
> hub_port_init -> usb_reset_device -> usb_reset_and_verify_device ->
> hub_port_init.
>
> We are trying to achieve two things inside crash_kexec'ed kerrnel:
>
> 1. avoid the 5s timeout during get_device_descriptor
> 2. and get USB device working
>
> When I tried this in hub_port_init() (in 2.6.38)
>
> default:
> if (r == 0)
> r = -EPROTO;
> break;
> }
>
> + if (r == -ETIMEDOUT) {
> + if(udev->speed == USB_SPEED_HIGH) {
> + dev_info(&udev->dev,
> "%s: force maxpktsize\n",
> +
> __FUNCTION__);
> + buf->bMaxPacketSize0 = 64;
> + r = 0;
> + break;
> + }
> + }
I prefer not to do it this way. First, because it avoids the retry
loop, and second, because the same technique can apply to other speeds,
not only high speed.
> the function completed fine i.e., even hub_port_reset below went fine
> with wPortStatus reflecting that reset is complete. However, 20s after
> that the USB block driver had called usb_reset_device() and the device
> is accessible since then.
I can't understand this last sentence. 20 seconds after what -- the
reset? Do you mean usb-storage rather than USB block driver?
usb-storage called usb_reset_device 20 seconds after the reset was
complete? The device is accessible since when (the first reset or the
second)?
> When usb_reset_device was called by higher
> layer, the state of the USB is CONFIGURED. Below is the backtrace to
> usb_reset_device.
The backtrace only tells you that usb-storage called
usb_reset_device. If you want to know _why_ it called
usb_reset_device, you need to collect a usbmon trace.
> As you suggested earlier, I'm thinking of if there is a way to
> unbind/rebind the driver. From above backtrace and after looking at
> usb_reset_device(), I thought usb_reset_device() is doing the
> unbind/rebind.
Why do you want to unbind and rebind usb-storage?
> Since I'm seeing 'r' as -110 (ETIMEDOUT) or -71 (EPROTO) (EPROTO on
> later 2 retries), the code you gave in first part of your patch would
> never get executed.
>
> Thanks for your help.
Maybe it would be best to switch devices instead of trying to change
the driver. Find a device that complies with the USB spec.
Alternatively, you could create a new quirk flag for this device. When
that flag is set, you could skip the 64-byte Get-Descriptor entirely.
Or you could try setting the "usbcore.old_scheme_first=1" option in the
kernel command line. That might be the easiest answer.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
