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 earlier kernels (such as 2.6.9), the IDLE_TIMEOUT value does cause FSBR to get shut off after a transfer taking a long time. I'm not exactly sure what should be done about this. On earlier kernels (before check_fsbr()), 250ms seems to be a good value for IDLE_TIMEOUT. On later kernels, it doesn't seem that IDLE_TIMEOUT matters (e.g. there isn't a problem). Best Regards, --Chris -----Original Message----- From: Pete Zaitcev [mailto:[EMAIL PROTECTED] Sent: Thursday, January 19, 2006 11:13 PM To: Frantz, Chris Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-usb-devel@lists.sourceforge.net; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: HP iLO needs FSBR 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 some more testing. Chris, did you do anything about this? I tried to approach this problem this week, and only now I started to understand the details. It looks to me that blaming stall_callback (or its replacement code in check_fsbr() in modern kernels) cannot be the answer, because when FSBR is finally disabled, it only makes things the same as they would have been if the URB didn't have FSBR to begin with. Could it be that FSBR itself is actually a problem? For example, it can overwhelm the firmware in iLO with polling, and so prevent it from doing something more useful. In such a case, lengthening timeouts should make things worse, not better. I haven't secured a suitable system. I identified one in Boston. But at the last moment I understood that iLO uses a storage image placed at the client, and not elsewhere, and so it's going to read from my laptop in California, which is not good for performance evaluations. I am afraid that I'll have to ride testing by e-mail at HP premises... -- Pete ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
