Hi Alan, thanks for working on this problem.
snip
By the way, looks like much of the list-handling in uhci-hcd could be
done more cleanly using the macros from list.h.
Agreed. But that's just a cleanup, not a fix. It can be done some other
time.
Sure. In fact I already did it, but I
Johannes:
With Duncan away, you're the only other person I know still interested in
working on this...
Duncan's suggestions gave me some ideas for even more improvements.
Consider this:
Merge the code that frees QHs, TDs, and urbps. That eliminates
the need for the qh_remove_list
On Sat, Jul 26, 2003, Alan Stern [EMAIL PROTECTED] wrote:
With Duncan away, you're the only other person I know still interested in
working on this...
Duncan's suggestions gave me some ideas for even more improvements.
Consider this:
Merge the code that frees QHs, TDs, and urbps.
On Sat, 26 Jul 2003, Johannes Erdfelt wrote:
On Sat, Jul 26, 2003, Alan Stern [EMAIL PROTECTED] wrote:
Eliminate the complete_list as well. When an URB completes, just
call uhci_finish_urb() instead of uhci_add_complete(). Unlinked URBs can
be passed to uhci_finish_urb() as they
Hi Alan, thanks for the patch. Yes, it works. Comments below.
On Thursday 24 July 2003 20:58, Alan Stern wrote:
On Fri, 18 Jul 2003, Duncan Sands wrote:
Hi Alan, Johannes, how about this? I tried to make as few changes to the
existing code as possible. In my opinion it would make more
On Fri, 25 Jul 2003, Duncan Sands wrote:
My patch also doesn't need to add a list header to each TD: you can just
reuse the list entry. I added the new list head to keep things symmetric
with QHs.
In the end, I find it distasteful to separate the freeing of the TDs and
the QHs. They should
On Fri, 18 Jul 2003, Duncan Sands wrote:
Hi Alan, Johannes, how about this? I tried to make as few changes to the
existing code as possible. In my opinion it would make more sense to have
the list of TDs belong to the QH and not the urb_priv, and free them when the
QH is freed, but that
OK - I implemented this is in a quick and nasty way, and it works.
(Though maybe I just changed the timing enough to not hit the race
anymore...) It looks like Alan's analysis was right on target :)
I'll try to send a clean fix next weekend.
Hi Alan, Johannes, how about this? I tried to
On Friday 04 July 2003 10:30, Duncan Sands wrote:
One other option may be to add a list to the QH structure and use that
if the URB needs a QH. If there are any TDs linked to the URB priv list
head, we free them when we destroy the URB priv. If they are linked to
the QH list head, we free
One other option may be to add a list to the QH structure and use that
if the URB needs a QH. If there are any TDs linked to the URB priv list
head, we free them when we destroy the URB priv. If they are linked to
the QH list head, we free them when we destroy the QH.
That would be really
Very interesting. The UHCI Design Guide document is _not_ very specific
about what happens with short packets. It does say that if the SPD bit is
set then the TD is marked inactive, the QH element ptr is not updated, and
an interrupt is requested. It doesn't say what happens if the SPD bit
On Fri, 27 Jun 2003, Duncan Sands wrote:
Hi Alan, if this scenario is correct then the same problem could occur
even if urbs are not being queued, right? So the fact I only see this
with queued urbs would be a coincidence: getting the timing just right
so as to hit the race...
To be honest,
On Wed, 25 Jun 2003, Johannes Erdfelt wrote:
One other option may be to add a list to the QH structure and use that
if the URB needs a QH. If there are any TDs linked to the URB priv list
head, we free them when we destroy the URB priv. If they are linked to
the QH list head, we free them
On Mon, 23 Jun 2003, Duncan Sands wrote:
On Sunday 22 June 2003 02:00, Johannes Erdfelt wrote:
On Sun, Jun 22, 2003, Duncan Sands [EMAIL PROTECTED] wrote:
I have tracked the problem down further. What happens is that the
host controller is still reading a TD when uhci_free_td is
On Wed, Jun 25, 2003, Alan Stern [EMAIL PROTECTED] wrote:
On Mon, 23 Jun 2003, Duncan Sands wrote:
On Sunday 22 June 2003 02:00, Johannes Erdfelt wrote:
On Sun, Jun 22, 2003, Duncan Sands [EMAIL PROTECTED] wrote:
I have tracked the problem down further. What happens is that the
On Wed, 25 Jun 2003, Johannes Erdfelt wrote:
I think your analysis is right on target.
I think your proposed fix is correct, but the implementation will be
tricky. We store TDs in the URB because the TDs for Interrupt and
Isochronous URBs don't have a QH. There's no reason we can't use a QH
On Wed, Jun 25, 2003, Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 25 Jun 2003, Johannes Erdfelt wrote:
I think your analysis is right on target.
I think your proposed fix is correct, but the implementation will be
tricky. We store TDs in the URB because the TDs for Interrupt and
On Sunday 22 June 2003 02:00, Johannes Erdfelt wrote:
On Sun, Jun 22, 2003, Duncan Sands [EMAIL PROTECTED] wrote:
On Tuesday 10 June 2003 19:18, Alan Stern wrote:
On Tue, 10 Jun 2003, Duncan Sands wrote:
I've tracked it down to the following: the first of two queued urbs
completes,
On Tuesday 10 June 2003 19:18, Alan Stern wrote:
On Tue, 10 Jun 2003, Duncan Sands wrote:
I've tracked it down to the following: the first of two queued urbs
completes, and the HC detects a problem in the following stretch of code
in uhci_irq:
I have tracked the problem down further. What
On Sun, Jun 22, 2003, Duncan Sands [EMAIL PROTECTED] wrote:
On Tuesday 10 June 2003 19:18, Alan Stern wrote:
On Tue, 10 Jun 2003, Duncan Sands wrote:
I've tracked it down to the following: the first of two queued urbs
completes, and the HC detects a problem in the following stretch of
Hi Alan, thanks for thinking about this.
You must have had debug set to 1, because your listing did not include the
skeleton QH's. That's what's confusing you; the QH at dee6e210 is the
Terminating QH.
Yup.
It might be worthwhile examining a dump made immediately after you queue
the
On Tue, 10 Jun 2003, Duncan Sands wrote:
I've tracked it down to the following: the first of two queued urbs completes,
and the HC detects a problem in the following stretch of code in uhci_irq:
What do you mean? The HC detects a problem only after
uhci_transfer_result() runs? Or does the
On Tuesday 10 June 2003 19:18, Alan Stern wrote:
On Tue, 10 Jun 2003, Duncan Sands wrote:
I've tracked it down to the following: the first of two queued urbs
completes, and the HC detects a problem in the following stretch of code
in uhci_irq:
What do you mean? The HC detects a problem
On Fri, 6 Jun 2003, Duncan Sands wrote:
Here's the schedule. It finishes like this:
[dee6e2d0] link (1ee6e212) element (18f33a50)
0: [d8f33a50] link (1ee6e302) e3 SPD IOC Active Length=0 MaxLen=34 DT1 EndPt=7
Dev=2, PID=e1(OUT) (buf=193cd000)
-- Queued QH's:
[dee6e300]
On Thu, 5 Jun 2003, Duncan Sands wrote:
If I try to queue bulk urbs to an endpoint (2.5, uhci-hcd),
I rapidly get
host controller process error. something bad happened
followed by
host controller halted. very bad.
In order to track down what went wrong, I would like to
know which TD caused
Here's the schedule. It finishes like this:
[dee6e2d0] link (1ee6e212) element (18f33a50)
0: [d8f33a50] link (1ee6e302) e3 SPD IOC Active Length=0 MaxLen=34 DT1 EndPt=7
Dev=2, PID=e1(OUT) (buf=193cd000)
-- Queued QH's:
[dee6e300] link (1ee6e212) element (18f33a80)
0:
If I try to queue bulk urbs to an endpoint (2.5, uhci-hcd),
I rapidly get
host controller process error. something bad happened
followed by
host controller halted. very bad.
In order to track down what went wrong, I would like to
know which TD caused the host controller to barf, which
QH it is in,
27 matches
Mail list logo
