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. Best regards -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
