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

[Bjorn Helgaas]

On Tue, May 7, 2013 at 11:50 AM, Artem S. Tashkinov <t.artem@xxxxxxxxx> wrote:
> May 7, 2013 10:27:30 PM, Bjorn Helgaas wrote:
> On Tue, May 7, 2013 at 8:59 AM, Artem S. Tashkinov  wrote:
>>> May 7, 2013 09:25:40 PM,        Bjorn Helgaas  wrote:
>>>> [+cc Phillip]
>>>>
>>>>> I would suspect that Windows' complaint about the BIOS mucking up the MTRRs
>>>>> is likely the best hint. Likely Windows is detecting the problem and fixing
>>>>> it up on resume, thus it only complains about "reduced resume performance".
>>>>> If the MTRRs are messed up, then quite likely parts of RAM have become
>>>>> uncacheable, causing performance to get randomly slaughtered in various
>>>>> ways.
>>>>>
>>>>> From looking at the code it's not clear if we are checking/restoring the
>>>>> MTRR contents after resume. If not, maybe we should be.
>>>>
>>>>I agree; the MTRR warning is a good hint.  Artem?
>>>>
>>>>Phillip, I cc'd you because you have similar hardware and your
>>>>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1131468 report is
>>>>slightly similar.  Have you seen anything like this "reduced
>>>>performance after resume" issue?  If so, can you collect /proc/mtrr
>>>>contents before and after suspending?
>>>>
>>>
>>> Like Robert Hancock correctly noted the Linux kernel lacks the code to check
>>> for MTTR changes after resume - I'm not a kernel hacker to write such a code ;-)
>>>
>>> Likewise there's no code to see if RAM pages have become uncacheable - i.e
>>> I've no idea how to check it either.
>>>
>>> According to /proc/mttr nothing changes on resume - only Windows detects
>>> the discrepancy between MTTR regions on resume. dmesg contains no warnings
>>> or errors (aside from usual ACPI SATA warnings - but they happen right on
>>> boot - so I highly doubt the ACPI or SATA layers can be the culprit, since USB
>>> exhibits a similar performance degradation).
>>>
>>> In short, there's little to nothing that I can check.
>>
>>I'm not trying to be ungrateful, but maybe you could actually collect
>>the info we've asked for and attach it to the bugzilla.  It's hard for
>>me to get excited about digging into this when all I see is "nothing
>>changes in MTRR" and "it's probably not X."  I really need some
>>concrete data to help rule things out and suggest other things to
>>investigate.
>>
>>Maybe we won't be able to make progress on this until other people
>>start hitting similar issues and we can find patterns.
>
> The pattern is very easy to spot - Linus once told that desktop PCs are
> not meant to work properly with suspend. That's kinda strange for me
> as I have yet to encounter a PC where Windows fails to work properly
> after resume - maybe I'm lucky - who knows.
>
> Taking into consideration that only few people use Linux, most Linux
> users avoid UEFI, very few of them actually use suspend/resume then
> it gets very easy to understand why such bug reports are vanishingly
> rare.
>
> Asus themselves could have easily debugged this issue if they were
> slightly interested in fixing it, yet their policy is that they only support
> Windows, and Linux is not their concern.

I can't intuit what the problem is.  If you or others can collect
data, we can try to fix this.  Otherwise, we can't.

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