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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <DFEF91B22ED07447AB6AA4B237F913F9B18F45@ausx3mpc125.aus.amer.dell.com>
Date:	Wed, 22 Aug 2007 15:41:38 -0500
From:	<Stuart_Hayes@...l.com>
To:	<torvalds@...ux-foundation.org>
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


>> 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 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/