>> That could definitely cause mouse lock-ups. Sorry, that should have
>> occurred to me yesterday when you mentioned the problem your kids
>> were seeing, but it didn't for some reason.
>
> Btw, could it have caused the USB stack to be *really* confused? Some
> of those mouse lockups ended up also locking the machine hard (ie no
> ping, no nothing), and I'm a bit worried that there was something
> else going on too..
>
Unfortunately, yes, that sounds exactly like what happened with the
nVidia controller. The problem was with my patch, but was fixed with
the later patch. I doubt there was anything else going on.
> That said, if you can actually re-create the MMF problems, could you
> please try the patch that Arjan suggested? Ie add a
>
> /*
> * Some broadcom chips are buggy and can't take more than 5 usec
as
> DMA
> * latency; inform the rest of kernel of this.
> */
> if (weird_broadcom_chip())
> set_acceptable_latency("ehci", 5);
>
> to the USB driver, and then add something like
>
> static inline int cpufreq_acceptable_latency(struct
cpufreq_policy
> *policy) {
> unsigned long latency;
>
> /* Policy latency in usec */
> latency = policy->cpuinfo.transition_latency / 1000;
>
> if (latency > system_latency_constraint())
> return -EINVAL;
>
> return 0;
> }
>
> adn then add calls to this from both the "__cpufreq_set_policy()"
> function and the "__cpufreq_driver_target()" one too..
>
> That should disable cpufreq with that broken chip, which is perhaps a
> big draconian, but it's certainly better than having the USB layer
> know about cpufreq internals directly.
>
> In the longer run, I think we can move the
> "system_latency_constraint()"
> checking from the policy registration into each CPU frequency driver,
> so that it could be more dynamically decide about "can we do it right
> _now_"
> rather than globally saying "we can't do it with this hardware".
>
> Linus
I will work on that, thank you for the help.
Stuart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
