On Wed, 1 Mar 2006, Pete Zaitcev wrote:
> On Wed, 22 Feb 2006 15:28:02 -0500 (EST), Alan Stern <[EMAIL PROTECTED]>
> wrote:
> > On Wed, 22 Feb 2006, Pete Zaitcev wrote:
>
> > > Frankly, I cannot fathom Alan's resistance to it when he actually
> > > suggested
> > > the main idea for the patch.
>
On Wed, 22 Feb 2006 15:28:02 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Feb 2006, Pete Zaitcev wrote:
> > Frankly, I cannot fathom Alan's resistance to it when he actually suggested
> > the main idea for the patch.
>
> I'm not at all resistant to the idea. It's just that the
On Fri, 20 Jan 2006, Pete Zaitcev wrote:
> If the above theory is correct, the only way NO_FSBR flag can help is
> because it prevents us from switching TDs into UHCI_PTR_DEPTH mode
> in uhci_fsbr_timeout. This is something I do not understand completely
> yet.
The newest drivers don't use depth-
On Fri, 20 Jan 2006, Frantz, Chris wrote:
> Alan,
>
> On my controller, PEC turns on as soon as the controller begins the
> reset condition. CSC turns on as soon as the controller ends the reset
> condition (e.g. in response to PORT_RESET getting cleared).
>
> So, the loop exit condition should
On Fri, 20 Jan 2006 11:16:04 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote:
> I've been meaning to get back to you about this. The latest kernels
> (those that use check_fsbr() instead of stall_callback) don't seem to
> suffer from the same problem.
>[...]
> I'm not exactly sure what should be
Alan,
On my controller, PEC turns on as soon as the controller begins the
reset condition. CSC turns on as soon as the controller ends the reset
condition (e.g. in response to PORT_RESET getting cleared).
So, the loop exit condition should be (inw(port_addr) & CSC).
I'll prototype this change o
On Fri, 20 Jan 2006, Frantz, Chris wrote:
> The hardware is already shipping, so we can't switch controllers. I
> haven't examined the code thouroughly enough to fully understand it yet.
> Was there something wrong with the way the code worked in earlier
> kernels?
There was no spinlock protecti
Alan,
> I'm not sure about that. The delay occurs with a spinlock held and
interrupts
> disabled, and 250 us is a pretty long time to wait with interrupts
turned off.
> Some people might get annoyed.
> There are other ways of accomplishing the same thing, but they are
more
> difficult. Do you
On Fri, 20 Jan 2006, Frantz, Chris wrote:
> Pete,
>
> I do, unforunately, have a different problem that I may need your and
> Alan's help on. It seems the uhci hub implementation has changed
> slighly. In older kernels (2.6.9/2.6.10/2.6.11 timeframe), the uhci hub
> portion of the driver had a
Pete,
I do, unforunately, have a different problem that I may need your and
Alan's help on. It seems the uhci hub implementation has changed
slighly. In older kernels (2.6.9/2.6.10/2.6.11 timeframe), the uhci hub
portion of the driver had a rather long delay (10 ms) between clearning
root-hub po
On Fri, 20 Jan 2006 11:16:04 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote:
> I've been meaning to get back to you about this. The latest kernels
> (those that use check_fsbr() instead of stall_callback) don't seem to
> suffer from the same problem. It seems that those kernels don't keep
> tr
Pete,
I've been meaning to get back to you about this. The latest kernels
(those that use check_fsbr() instead of stall_callback) don't seem to
suffer from the same problem. It seems that those kernels don't keep
track of individual transfers and mess with whether or not FSBR is on or
off.
On e
On Wed, 16 Nov 2005 17:21:46 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote:
> I've been looking into adjusting IDLE_TIMEOUT. Unfortunately, I've been
> dealing with some other issues first. Preliminary testing seems to
> indicate that adjusting the idle timeout will work, but I need to do
> s
Pete,
I've been looking into adjusting IDLE_TIMEOUT. Unfortunately, I've been
dealing with some other issues first. Preliminary testing seems to
indicate that adjusting the idle timeout will work, but I need to do
some more testing.
Best Regards,
--Chris
-Original Message-
From: Pete
On Thu, 10 Nov 2005 17:54:25 -0600, "Frantz, Chris" <[EMAIL PROTECTED]> wrote:
> I would agree that the patch is questionable. It appears the only
> reason that it helps is that it takes advantage of some unintended
> behavior of the FSBR implementation in the current UHCI driver.
Chris, did you
On Thu, 10 Nov 2005, Frantz, Chris wrote:
> On Thu, 10 Nov 2005, Alan Stern wrote:
>
> > > It appears that the stall callback is the thing that turns off FSBR
> if
> > > there has been an fsbr timeout. If an URB requests NO_FSBR, then
> the
> > > stall_callback can't turn off FSBR, so the host
On Thu, 10 Nov 2005, Alan Stern wrote:
> > It appears that the stall callback is the thing that turns off FSBR
if
> > there has been an fsbr timeout. If an URB requests NO_FSBR, then
the
> > stall_callback can't turn off FSBR, so the host controller queues
> > remain linked in a cycle, and the
On Thu, 10 Nov 2005, Pete Zaitcev wrote:
> Hi, guys:
>
> My collegues from HP asked me to incorporate the following patch, which
> adds a quirk bit to the unusual_devs.h and sets NO_FSBR.
> Here's the explanation (from Chris):
>
> ---
> I think under normal condition
Off the cuff, this looks like a possible HCD problem. FSBR affects how the
HCD executes the command on the wire usb-storage (or ub for that
matter) shouldn't really have to worry about a flag like that.
Matt
On Thu, Nov 10, 2005 at 12:16:31PM -0800, Pete Zaitcev wrote:
> Hi, guys:
>
> My co
19 matches
Mail list logo
