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]

Date:	Mon, 20 Aug 2007 22:51:28 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Brownell <david-b@...bell.net>,
	Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
	linux-usb-devel@...ts.sourceforge.net, Greg KH <gregkh@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Stuart_Hayes@...l.com" <Stuart_Hayes@...l.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Exner <dex@...gonslave.de>
Subject: Re: [linux-usb-devel] [4/4] 2.6.23-rc3: known regressions


> Have we done that? Yes. We actually had a "no-hlt" kernel command line 
> flag that literally disabled halting the CPU, because it apparently caused 
> problems for some floppy disk setups (and yes, the main reasonable 
> explanation was some bad DMA interaction, we never figured it out).
> 
> So it might be much better if we instead re-introduced that kind of "DMA 
> latency requirement", and letting different subsystems react to that as 
> they may.


wait.... we HAVE that infrastructure .. see kernel/latency.c ...


> It really can affect more than just cpufreq - I would not be in the 
> *least* surprised if C3 latencies and other things can cause these things 
> too! But even within cpufreq, it's quite likely to hit certain situations 
> more than others.

and kernel/latency.c was designed EXACTLY for that reason. All the USB
layer has to do is to announce it's latency requirement like this:

/* 
 * 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);


and the C-state code will honor it. CPUFREQ doesn't honor it yet but
that's easy to add.. (this assumes the ACPI BIOS informs us correctly
about the cpu behavior, but that's the best we can do obviously unless
you want a table inside the kernel keyed off vendor/model/stepping)




-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

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