On 7/2/06, David Brownell [EMAIL PROTECTED] wrote:
On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
Disconnecting a hub/device causes two things to happen at the same time:
1) usb_disconnect is called on the root device.
2) each active transfer descriptor throws an
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
On 7/2/06, David Brownell [EMAIL PROTECTED] wrote:
On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
Disconnecting a hub/device causes two things to happen at the same time:
1) usb_disconnect is called on the root device.
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
Actually it is. Look in drivers/usb/core/hub.c at the
usb_set_device_state() routine.
will do.
Potentially tight doesn't have to mean tight. Higher-level drivers should
strive to avoid immediate resubmissions of URBs that fail because of
On Wed, 5 Jul 2006, Christopher Montgomery wrote:
The resubmission is in ehci-q.c:qh_completions(); it is not checking
to see if the device is disconnected (is this possible?
No.
) before
deciding the endpoint EPROTO fault calls for tearing it down and
setting it back up. Active/submitted
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
) before
deciding the endpoint EPROTO fault calls for tearing it down and
setting it back up. Active/submitted URBs potentially have nothing to
do with it; it is happening even when my devices are idle.
I'm not terribly familiar with
On 7/5/06, Christopher Montgomery [EMAIL PROTECTED] wrote:
/ the two lines below
*/
intr_deschedule (ehci, qh);
(void) periodic_qh_schedule (ehci, qh);
Oops,
On Wednesday 05 July 2006 7:16 am, Christopher Montgomery wrote:
On 7/2/06, David Brownell [EMAIL PROTECTED] wrote:
On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
Disconnecting a hub/device causes two things to happen at the same time:
1) usb_disconnect is called on
On Wednesday 05 July 2006 7:56 am, Christopher Montgomery wrote:
The resubmission is in ehci-q.c:qh_completions(); it is not checking
to see if the device is disconnected (is this possible?) before
deciding the endpoint EPROTO fault calls for tearing it down and
setting it back up.
To
On Wednesday 05 July 2006 8:30 am, Christopher Montgomery wrote:
/ the two lines below
*/
intr_deschedule (ehci, qh);
(void) periodic_qh_schedule (ehci, qh);
...
It is
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 7:16 am, Christopher Montgomery wrote:
Odd ... interwoven certainly allows gaps, and all of your
additional details agree completely with the facts as I had
pointed out.
I think we both actually agree on all but the
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 8:30 am, Christopher Montgomery wrote:
/ the two lines below
*/
intr_deschedule (ehci, qh);
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
To repeat myself: the instant the physical disconnect happens,
then pending transfers to that device's endpoints may trigger
USB transfer errors. And that can happen a LONG time before any
component of the USB stack (e.g. qh_completions)
On Wednesday 05 July 2006 11:40 am, Christopher Montgomery wrote:
I plug in a hub. I unplug a hub. Nothing else happens in between and
I see the resubmission loop happen until the disconnect code catches
up and removes the hub's intr endpoint. Exactly what driver are you
talking about?
On Wed, 5 Jul 2006 14:40:54 -0400, Christopher Montgomery [EMAIL PROTECTED]
wrote:
And in any case, the only way qh_completions would reactivate
a halted endpoint is if its queue were non-empty after a fault
got reported. And that's solidly in the hands of the driver
which filled that
In particular, that transfer errors will start
long before usbcore has any clue that the root cause is that
the device has been disconnected. You need to be re-thinking
a bunch of things if you believe otherwise.
I see that's exactly what's happening. It merely seems
I see that's exactly what's happening. It merely seems unfortunate.
That sort of behavior is inevitable in hardware-parallel systems.
But it's also a rather minor failure mode, and the only folk who
seem to run into it are people tweaking host controller drivers
and adding lots of
On Wednesday 05 July 2006 6:14 pm, Christopher Montgomery wrote:
And as a simplification: to date there's been only one data
structure, which encodes both the schedule and all allocations.
This is a Good Thing (tm) because it's less error prone ... and
it's also a useful simplification.
On Sun, 2 Jul 2006, Christopher Montgomery wrote:
I'm putting the finishing touches on the new EHCI scheduler and
noticed an interesting 'problem' in shutdown. In practice it usually
doesn't work out to being a bug, but it appears to be unintentional
and potentially problematic on slow CPUs
On 7/2/06, Alan Stern [EMAIL PROTECTED] wrote:
I don't understand the problem you are describing. The kernel doesn't
kill off an IRQ unless it gets a lot of unhandled interrupts (99900 out of
the last 10). But none of the interrupts you mention will be
unhandled -- ehci-hcd will handle
On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
Disconnecting a hub/device causes two things to happen at the same time:
1) usb_disconnect is called on the root device.
2) each active transfer descriptor throws an interrupt/error each time
it comes up in the periodic
20 matches
Mail list logo
