Did you try with 2.6.18-rc3? There's a Kconfig option for an
improved interrupt scheduler, which might help especially with
all those low speed devices.
- Dave
David Brownell wrote:
> Did you try with 2.6.18-rc3? There's a Kconfig option for an
> improved interrupt scheduler, which might help especially with
> all those low speed devices.
I hadn't but i just did.
(I guess you meant CONFIG_USB_EHCI_TT_NEWSCHED=y)
The behaviour was different, every light went on and the syslog went
silent. I could switch on one of the HDDs and i could see it in
/proc/partitions. But then everything completly broke down and syslog
was flooded after some time all lights went out.
Do you want/need the syslog?
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
On 8/4/06, David Brownell <[email protected]> wrote:
> Did you try with 2.6.18-rc3? There's a Kconfig option for an
> improved interrupt scheduler, which might help especially with
> all those low speed devices.
Actually, assuming I'm reading the spec right, I've come to realize
Dan's improved scheduler patch allows illegal QH schedules that the
old scheduler prevented (as the old scheduler would not allow any set
of complete splits to overlap). Dan's patch allows complete splits to
be serviced in a different order than the original start splits, which
will cause the out of order responses to be dropped on the floor.
QHs splits must be scheduled in the order the QHs appear in a given
frame; if QH B is scheduled after QH A and uses a later microframe for
its SS, but appears in a higher period level of the tree such that it
actually occurs earlier in the frame, QH A may see all of its complete
splits lost; this is subject to uncertainties due to bti stuffing and
bandwidth recovery/error recovery. It is possible in our current
scheduler with Dan's improvement patch.
Monty