[+cc previous cc list from lkml]
On Wed, Jul 10, 2013 at 11:25 AM, hyphop wrote:
> hello
> i have same problem. low write speed after system sleep
>
> kernel 3.9.9
>
> i can see it HDD SATA & USB disks to
>
> i try to make another test
>
> before sleep i make file /tmp/test ( /tmp mounted as tmp
-HDD-USB-write-speed-after-sleep-on-a-UEFI-system-tp598586p681610.html
Sent from the Linux Kernel mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/8/2013 4:37 AM, Artem S. Tashkinov wrote:
> Have you tried suspending more than three times? In the absence of
> UEFI boot this bug emerges only on a third or even fourth resume
> attempt. UEFI boot triggers it immediately on a first resume
> thou
On Wed, May 8, 2013 at 10:37 AM, Artem S. Tashkinov wrote:
>>I think this is the official statement from Intel on the SATA issue:
>>http://newsroom.intel.com/community/intel_newsroom/blog/2011/01/31/intel-identifies-chipset-design-error-implementing-solution
>
> My motherboard has a new fixed B3 r
May 8, 2013 04:25:43 AM, Patrik Jakobsson wrote:
On Wed, May 8, 2013 at 12:02 AM, Bjorn Helgaas wrote:
>> On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson wrote:
>>> On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas wrote:
> I'm not sure if reading /proc/mtrr actually reads the registers out of
>
May 8, 2013 04:03:18 AM, Bjorn Helgaas wrote:
On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson
> wrote:
>> On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas
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
On Wed, May 8, 2013 at 12:02 AM, Bjorn Helgaas wrote:
> On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson
> wrote:
>> On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas wrote:
I'm not sure if reading /proc/mtrr actually reads the registers out of
the CPU each time, or whether we just return
On Tue, May 7, 2013 at 2:48 PM, Patrik Jakobsson
wrote:
> On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas 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
On Tue, May 7, 2013 at 10:20 PM, Bjorn Helgaas 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
On Tue, May 7, 2013 at 12:05 PM, Robert Hancock wrote:
> On Tue, May 7, 2013 at 9: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 bes
On Tue, May 7, 2013 at 9: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
>>>
On Tue, May 7, 2013 at 11:50 AM, Artem S. Tashkinov 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 ab
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. Like
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
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/7/2013 11:25 AM, Bjorn Helgaas wrote:
> 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
> perf
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 perf
[+cc Phillip]
On Tue, Apr 30, 2013 at 9:19 PM, Robert Hancock wrote:
> On 04/29/2013 10:47 PM, Bjorn Helgaas wrote:
>>
>> On Sat, Apr 27, 2013 at 4:10 AM, Artem S. Tashkinov
>> wrote:
Did this problem ever get resolved?
>>>
>>> Hello,
>>>
>>> Unfortunately, no. Out of curiosi
On 04/29/2013 10:47 PM, Bjorn Helgaas wrote:
On Sat, Apr 27, 2013 at 4:10 AM, Artem S. Tashkinov wrote:
Did this problem ever get resolved?
Hello,
Unfortunately, no. Out of curiosity I've tried booting kernel
3.9-rc8 in EUFI mode but it exhibits the same problem.
Right after the boot:
[r
On Sat, Apr 27, 2013 at 4:10 AM, Artem S. Tashkinov wrote:
>>
>>Did this problem ever get resolved?
>>
>
> Hello,
>
> Unfortunately, no. Out of curiosity I've tried booting kernel
> 3.9-rc8 in EUFI mode but it exhibits the same problem.
>
> Right after the boot:
>
> [root@localhost ~]# dd if=/dev/
>
>Did this problem ever get resolved?
>
Hello,
Unfortunately, no. Out of curiosity I've tried booting kernel
3.9-rc8 in EUFI mode but it exhibits the same problem.
Right after the boot:
[root@localhost ~]# dd if=/dev/zero of=test bs=64M count=3
3+0 records in
3+0 records out
201326592 bytes (
On Wed, Mar 6, 2013 at 5:17 PM, Bjorn Helgaas wrote:
> On Tue, Feb 26, 2013 at 12:14 PM, Artem S. Tashkinov
> wrote:
>> Feb 27, 2013 12:47:01 AM, Bjorn Helgaas wrote:
>> On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote:
Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
>
>Whe
On Tue, Feb 26, 2013 at 12:14 PM, Artem S. Tashkinov wrote:
> Feb 27, 2013 12:47:01 AM, Bjorn Helgaas wrote:
> On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote:
>>> Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
Where are we at with this, Artem? I assume it's still a problem.
>
Feb 27, 2013 12:47:01 AM, Bjorn Helgaas wrote:
On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote:
>> Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
>>>
>>>Where are we at with this, Artem? I assume it's still a problem.
>>>
>>
>> Yes, it is, Bjorn.
>>
>> In order to eliminate this problem
On Mon, Feb 25, 2013 at 11:35 PM, Artem S. Tashkinov wrote:
> Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
>>
>>Where are we at with this, Artem? I assume it's still a problem.
>>
>
> Yes, it is, Bjorn.
>
> In order to eliminate this problem I switched back to MBR yesterday, because
> so far I
Feb 26, 2013 03:57:52 AM, Bjorn Helgaas wrote:
>
>Where are we at with this, Artem? I assume it's still a problem.
>
Yes, it is, Bjorn.
In order to eliminate this problem I switched back to MBR yesterday, because
so far I haven't received any instructions or guidance as to how I can debug
it fur
On Tue, Feb 19, 2013 at 9:22 AM, Alan Stern wrote:
> On Tue, 12 Feb 2013, Bjorn Helgaas wrote:
>
>> [+cc linux-pci, Rafael, Alan]
>>
>> [https://bugzilla.kernel.org/show_bug.cgi?id=53551]
>>
>> On Tue, Feb 12, 2013 at 1:13 PM, Artem S. Tashkinov
>> wrote:
>> > Feb 13, 2013 01:32:53 AM, Linus Tor
On Tue, 12 Feb 2013, Bjorn Helgaas wrote:
> [+cc linux-pci, Rafael, Alan]
>
> [https://bugzilla.kernel.org/show_bug.cgi?id=53551]
>
> On Tue, Feb 12, 2013 at 1:13 PM, Artem S. Tashkinov wrote:
> > Feb 13, 2013 01:32:53 AM, Linus Torvalds wrote:
> > On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tas
[+cc linux-pci, Rafael, Alan]
[https://bugzilla.kernel.org/show_bug.cgi?id=53551]
On Tue, Feb 12, 2013 at 1:13 PM, Artem S. Tashkinov wrote:
> Feb 13, 2013 01:32:53 AM, Linus Torvalds wrote:
> On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov wrote:
>>> Feb 12, 2013 11:30:20 PM, Linus Torvald
Feb 13, 2013 01:32:53 AM, Linus Torvalds wrote:
On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov wrote:
>> Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote:
>>>
>>>A few things to try to pinpoint:
>>>
>>> (a) Is it *only* write performance that suffers, or is it other
>>>performance too? Networki
On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov wrote:
> Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote:
>>
>>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?)? C
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/130
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
Hello,
I have a P8P67 Pro motherboard made by ASUS and recently I decided to switch to
EUFI boot.
Maybe it's a coincidence or maybe Linux kernel 3.7.6 (vanilla) has some serious
bug but after
waking up from sleep write performance becomes intolerable.
On boot I have:
HDD write performance: ~12
33 matches
Mail list logo
