Messages in this thread | | | Date | Wed, 22 Aug 2007 11:41:46 -0700 (PDT) | From | Linus Torvalds <> | Subject | RE: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions |
| |
On Wed, 22 Aug 2007, Stuart_Hayes@Dell.com wrote: > > If you were running 2.6.26-rc3, that's quite possibly because you didn't > have the follow-up patch that fixed my original patch... it wasn't in > 2.6.26-rc3
Well, I was running "current git", and it's never been there. So not just a -rc3 issue.
> 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..
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |