hello
i have same problem. low write speed after system sleep
kernel 3.9.9
i can see it HDD SATA & USB disks to
i try to make another test
before sleep i make file /tmp/test ( /tmp mounted as tmpfs size=8G, i have
16G memory in my system )
dd if=/dev/zero bs=1M count=1000 of=/tmp/test
~ 3,2 GB/s
cryptsetup luksFormat /tmp/test
cryptsetup luksOpen /tmp/test test
dd if=/dev/zero bs=1M count=1000 of=/dev/mapper/test
~ 465 GB/s good speed
after sleep
dd if=/dev/zero bs=1M count=1000 of=/dev/mapper/test
~ 5MB/s ooops (((( very slow
but if write directly in /tmp i can see
dd if=/dev/zero bs=1M count=1000 of=/tmp/test2
~ 3,2 GB/s
I can see this is not hardware problem (NOT SATA OR USB) i think is kernel
BUG, i i dont have this problem on previous kernel 3.4
Best regards,
Tema
--
View this message in context: http://linux-kernel.2935.n7.nabble.com/Abysmal-HDD-USB-write-speed-after-sleep-on-a-UEFI-system-tp598586p681610.html
Sent from the Linux Kernel mailing list archive at Nabble.com.
[+cc previous cc list from lkml]
On Wed, Jul 10, 2013 at 11:25 AM, hyphop <[email protected]> wrote:
> hello
> i have same problem. low write speed after system sleep
>
> kernel 3.9.9
>
> i can see it HDD SATA & USB disks to
>
> i try to make another test
>
> before sleep i make file /tmp/test ( /tmp mounted as tmpfs size=8G, i have
> 16G memory in my system )
>
> dd if=/dev/zero bs=1M count=1000 of=/tmp/test
> ~ 3,2 GB/s
> cryptsetup luksFormat /tmp/test
> cryptsetup luksOpen /tmp/test test
>
> dd if=/dev/zero bs=1M count=1000 of=/dev/mapper/test
> ~ 465 GB/s good speed
>
> after sleep
>
> dd if=/dev/zero bs=1M count=1000 of=/dev/mapper/test
> ~ 5MB/s ooops (((( very slow
>
> but if write directly in /tmp i can see
>
> dd if=/dev/zero bs=1M count=1000 of=/tmp/test2
> ~ 3,2 GB/s
>
> I can see this is not hardware problem (NOT SATA OR USB) i think is kernel
> BUG, i i dont have this problem on previous kernel 3.4
Thanks for this report. Artem collected some of his info here:
https://bugzilla.kernel.org/show_bug.cgi?id=53551 . Hendrik Haddorp
also reported seeing this issue there.
Artem reported that Windows complains "The system firmware has changed
the processor's memory type range registers (MTRRs) across a sleep
state transition (S4). This can result in reduced resume performance."
If you have Windows on your system, does it complain the same way?
Can you collect and attach complete dmesg and "lspci -vvv" logs, from
both working and broken kernels, to the bugzilla? Collect lspci logs
both before and after the sleep; I think Artem saw some differences
between those, and I'm not sure we completely ruled those out.
If anybody can reproduce this reliably enough to bisect it, that would
be a huge help.
Bjorn