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

[Artem S. Tashkinov]

Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote:
>On Mon, Feb 11, 2013 at 10:25 PM, Artem S. Tashkinov 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?

I've tested hdpard -tT --direct and the output on boot and after suspend
is quite similar.

I've also checked my network read/write speed, and it's the same
~ 100MBit/sec (I have no 1Gbit computers on my network
unfortunately).

>
> (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).

I've no idea, please, check my bug report where I've just added lots of
information including a diff between on boot and after suspend.

lspci outputs differ quite substantially, but the things that have change
say nothing to me - you'll want to see it for yourself. I see changes like:

-                       Changed: MRL- PresDet- LinkState-
+                       Changed: MRL- PresDet+ LinkState-

i.e. PresDet minus to PresDet plus.

-               Address: 00000000fee0f00c  Data: 41e1
+               Address: 0000000000000000  Data: 0000

-       Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- TAbort- 
> (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..

I remember it used to work before, but I've never suspended more than once
during one boot session before (this time I did it out of pure curiosity) and
I've never run Linux from UEFI.

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

I'll gladly provide any information you need.

Thanks a lot,

Artem
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/