[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMeQTsZEpRE_bv6o9mBpqNrbf36SZVscxy+JS72=BOzA1ey-XQ@mail.gmail.com>
Date: Tue, 7 May 2013 23:48:26 +0200
From: Patrik Jakobsson <patrik.r.jakobsson@...il.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
Cc: Robert Hancock <hancockrwd@...il.com>,
"Artem S. Tashkinov" <t.artem@...os.com>,
Alan Stern <stern@...land.harvard.edu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, Phillip Susi <psusi@...ntu.com>
Subject: Re: Abysmal HDD/USB write speed after sleep on a UEFI system
On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> I'm not sure if reading /proc/mtrr actually reads the registers out of
>> the CPU each time, or whether we just return the cached values we read
>> out during initial boot-up. If the latter, then this output isn't
>> really useful as there's no guarantee the values are still intact.
>
> Good point. From what I can tell, on Artem's system with "CPU0:
> Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz," we would be using
> generic_mtrr_ops, and generic_get_mtrr() appears to read from the
> MSRs, so I think it should be useful.
FWIW, that motherboard suffers from a PCI to PCIE bridge problem. It might
have been fixed by bios upgrades by now but not sure.
It might also suffer (depending on the revision) from the Sandy bridge SATA
issue. So if affected, SATA controller is a ticking bomb.
I have a P8H67-V motherboard but I haven't seen any suspend related issues.
If this is totally unrelated I'm sorry for wasting your time. Just thought it
might be good to know.
Thanks
Patrik Jakobsson
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists