linux-kernel - Re: Abysmal HDD/USB write speed after sleep on a UEFI system

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-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFyscOeZUPaYj_-QYgjADPD59+=c5aMvtpPEnd1tmpUGiA@mail.gmail.com>
Date:	Tue, 12 Feb 2013 09:29:59 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Artem S. Tashkinov" <t.artem@...os.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Abysmal HDD/USB write speed after sleep on a UEFI system

On Mon, Feb 11, 2013 at 10:25 PM, Artem S. Tashkinov <t.artem@...os.com> wrote:
> Hello Linus,
>
> I've already posted a bug report (https://bugzilla.kernel.org/show_bug.cgi?id=53551),
> a message to LKML (http://lkml.indiana.edu/hypermail/linux/kernel/1302.1/00837.html)
> and so far I've received zero response even though the bug is quite critical as it prevents
> me from using suspend altogether.
>
> I wonder if you could tell me who is responsible for this problem and who I need to CC in
> bugzilla.

According to your bugzilla it doesn't really seem to be strictly
UEFI-specific, and it's hard to tell what subsystem is to blame.

A few things to try to pinpoint:

 (a) Is it *only* write performance that suffers, or is it other
performance too? Networking (DMA? Perhaps only writing *to* the
network?)? CPU?

 (b) the fact that it apparently happens with both SATA and USB
implies that it's neither, and is more likely something core like
memory speed (mtrr, caching) or PCI (DMA, burst sizes, whatever).

 (c) can you find anything that changes over the suspend/resume? IOW,
look at things like "lspci -vvxxx" before-and-after, and see what
changed on the bridges leading to both things etc.

The performance drop sounds extreme enough that it sounds like caches
got disabled or something, but that should show up as CPU performance
in general being slow, not just writes to disk. But basically, I think
we need more clues about which sub-area is actually the culprit. My
*guess* would be some core PCI thing not being initialized, but I
don't see how you could even make PCI go that slow. Interrupt
problems? DMA failures? I have no idea.

Has it ever worked? Suspend on desktop motherboards used to be quite
spotty (nobody ever used it, manufacturers didn't care), but it
generally has gotten better since people use it more these days..

Added lkml and Bjorn to the participants, in case anybody has any ideas..

                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/