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&kid=103432&bid=230486&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
