> An odd sort of bug. You'd think that not getting a response back would
> be one of the first types of error the hardware designers would check
> for.
You'd think that, right? But apparently they didn't. I've now also
tried just hacking a pointless SET_INTERFACE message into the
On Tue, Jul 30, 2013 at 07:33:46PM -0700, Julius Werner wrote:
> > Wait a moment. Why does each of these attempts lead to a 5-second
> > timeout? Why don't they fail immediately?
>
> Now that you mention it, that's a very good question. The kernel
> enqueues a control transfer to the now
On Tue, 30 Jul 2013, Julius Werner wrote:
> > Wait a moment. Why does each of these attempts lead to a 5-second
> > timeout? Why don't they fail immediately?
>
> Now that you mention it, that's a very good question.
I have brought this up with Sarah on more than one occasion, but we
never
On Tue, 30 Jul 2013, Julius Werner wrote:
Wait a moment. Why does each of these attempts lead to a 5-second
timeout? Why don't they fail immediately?
Now that you mention it, that's a very good question.
I have brought this up with Sarah on more than one occasion, but we
never found a
On Tue, Jul 30, 2013 at 07:33:46PM -0700, Julius Werner wrote:
Wait a moment. Why does each of these attempts lead to a 5-second
timeout? Why don't they fail immediately?
Now that you mention it, that's a very good question. The kernel
enqueues a control transfer to the now disconnected
An odd sort of bug. You'd think that not getting a response back would
be one of the first types of error the hardware designers would check
for.
You'd think that, right? But apparently they didn't. I've now also
tried just hacking a pointless SET_INTERFACE message into the
> Wait a moment. Why does each of these attempts lead to a 5-second
> timeout? Why don't they fail immediately?
Now that you mention it, that's a very good question. The kernel
enqueues a control transfer to the now disconnected address because
it's internal bookkeeping is not yet updated, but
On Tue, 30 Jul 2013, Julius Werner wrote:
> The USB hub driver's event handler contains a check to catch SuperSpeed
> devices that transitioned into the SS.Inactive state and tries to fix
> them with a reset. It decides whether to do a plain hub port reset or
> call the usb_reset_device() method
-andiry.xu... he wrote that section originally but it seems that his
address is no longer available.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The USB hub driver's event handler contains a check to catch SuperSpeed
devices that transitioned into the SS.Inactive state and tries to fix
them with a reset. It decides whether to do a plain hub port reset or
call the usb_reset_device() method based on whether there was a device
attached to the
The USB hub driver's event handler contains a check to catch SuperSpeed
devices that transitioned into the SS.Inactive state and tries to fix
them with a reset. It decides whether to do a plain hub port reset or
call the usb_reset_device() method based on whether there was a device
attached to the
-andiry.xu... he wrote that section originally but it seems that his
address is no longer available.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 30 Jul 2013, Julius Werner wrote:
The USB hub driver's event handler contains a check to catch SuperSpeed
devices that transitioned into the SS.Inactive state and tries to fix
them with a reset. It decides whether to do a plain hub port reset or
call the usb_reset_device() method
Wait a moment. Why does each of these attempts lead to a 5-second
timeout? Why don't they fail immediately?
Now that you mention it, that's a very good question. The kernel
enqueues a control transfer to the now disconnected address because
it's internal bookkeeping is not yet updated, but I
14 matches
Mail list logo