linux-kernel - RE: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.0.999.0708221122180.30176@woody.linux-foundation.org>
Date:	Wed, 22 Aug 2007 11:41:46 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stuart_Hayes@...l.com
cc:	david-b@...bell.net, michal.k.k.piotrowski@...il.com,
	linux-usb-devel@...ts.sourceforge.net, gregkh@...e.de,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	dex@...gonslave.de
Subject: RE: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions

On Wed, 22 Aug 2007, Stuart_Hayes@...l.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/