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. That bug report has nothing to do with my problem - my PC suspends and resumes more or less correctly - everything works (albeit some parts don't work as they should). That person also has a very outdated BIOS - 1904 from 08/15/2011. I wouldn't be surprised if BIOS update solved his problem. Best regards, Artem -- 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
