>
>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 (201 MB) copied, 1.08544 s, 185 MB/s
After suspend/resume:
# dd if=/dev/zero of=test bs=64M count=3
3+0 records in
3+0 records out
201326592 bytes (201 MB) copied, 66.5392 s, 3.0 MB/s
That's for my primary SATA-3 HDD.
Forgive me my impudence but I believe debugging the USB stack is
tangential to this problem. Something far deeper than USB support
breaks, but so far no one has come even with the slightest clue of
what that might be.
And like I mentioned before this problem doesn't affect Windows - once
I suspended it seven times in a row and it kept on chugging happily.
According to hdparm nothing changes after suspend/resume:
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: disabled
Recommended acoustic management value: 208, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
3MB/sec matches PIO mode 0 which is ridiculous and implausible given
than this HDD is attached via SATA.
Besides hdparm says that:
# hdparm -tT --direct /dev/sda
/dev/sda:
Timing O_DIRECT cached reads: 862 MB in 2.00 seconds = 430.77 MB/sec
Timing O_DIRECT disk reads: 520 MB in 3.01 seconds = 173.03 MB/sec
So, only writes are affected.
My dmesg is here: http://ompldr.org/vaThpcA/dmesg
On Sat, Apr 27, 2013 at 4:10 AM, Artem S. Tashkinov <[email protected]> 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/zero of=test bs=64M count=3
> 3+0 records in
> 3+0 records out
> 201326592 bytes (201 MB) copied, 1.08544 s, 185 MB/s
>
> After suspend/resume:
>
> # dd if=/dev/zero of=test bs=64M count=3
> 3+0 records in
> 3+0 records out
> 201326592 bytes (201 MB) copied, 66.5392 s, 3.0 MB/s
>
> That's for my primary SATA-3 HDD.
>
> Forgive me my impudence but I believe debugging the USB stack is
> tangential to this problem. Something far deeper than USB support
> breaks, but so far no one has come even with the slightest clue of
> what that might be.
I tend to agree that it sounds like something deeper than USB is
broken. I admit I'm just grasping at straws because I don't have any
good ideas yet.
Here are three easy things you can try:
1) Collect "lspci -vvv -xxxx" output before and after the
suspend/resume to investigate the XHCI Unsupported Request errors.
2) Collect the contents of /proc/mtrr before and after the suspend/resume.
3) After the suspend/resume, try the "setpci" to set the MSI address
back to the original value to see if it makes a difference (see my Feb
12 message).
Bjorn
On 04/29/2013 10:47 PM, Bjorn Helgaas wrote:
> On Sat, Apr 27, 2013 at 4:10 AM, Artem S. Tashkinov <[email protected]> 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/zero of=test bs=64M count=3
>> 3+0 records in
>> 3+0 records out
>> 201326592 bytes (201 MB) copied, 1.08544 s, 185 MB/s
>>
>> After suspend/resume:
>>
>> # dd if=/dev/zero of=test bs=64M count=3
>> 3+0 records in
>> 3+0 records out
>> 201326592 bytes (201 MB) copied, 66.5392 s, 3.0 MB/s
>>
>> That's for my primary SATA-3 HDD.
>>
>> Forgive me my impudence but I believe debugging the USB stack is
>> tangential to this problem. Something far deeper than USB support
>> breaks, but so far no one has come even with the slightest clue of
>> what that might be.
>
> I tend to agree that it sounds like something deeper than USB is
> broken. I admit I'm just grasping at straws because I don't have any
> good ideas yet.
>
> Here are three easy things you can try:
>
> 1) Collect "lspci -vvv -xxxx" output before and after the
> suspend/resume to investigate the XHCI Unsupported Request errors.
>
> 2) Collect the contents of /proc/mtrr before and after the suspend/resume.
>
> 3) After the suspend/resume, try the "setpci" to set the MSI address
> back to the original value to see if it makes a difference (see my Feb
> 12 message).
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.
[+cc Phillip]
On Tue, Apr 30, 2013 at 9:19 PM, Robert Hancock <[email protected]> wrote:
> On 04/29/2013 10:47 PM, Bjorn Helgaas wrote:
>>
>> On Sat, Apr 27, 2013 at 4:10 AM, Artem S. Tashkinov <[email protected]>
>> 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/zero of=test bs=64M count=3
>>> 3+0 records in
>>> 3+0 records out
>>> 201326592 bytes (201 MB) copied, 1.08544 s, 185 MB/s
>>>
>>> After suspend/resume:
>>>
>>> # dd if=/dev/zero of=test bs=64M count=3
>>> 3+0 records in
>>> 3+0 records out
>>> 201326592 bytes (201 MB) copied, 66.5392 s, 3.0 MB/s
>>>
>>> That's for my primary SATA-3 HDD.
>>>
>>> Forgive me my impudence but I believe debugging the USB stack is
>>> tangential to this problem. Something far deeper than USB support
>>> breaks, but so far no one has come even with the slightest clue of
>>> what that might be.
>>
>>
>> I tend to agree that it sounds like something deeper than USB is
>> broken. I admit I'm just grasping at straws because I don't have any
>> good ideas yet.
>>
>> Here are three easy things you can try:
>>
>> 1) Collect "lspci -vvv -xxxx" output before and after the
>> suspend/resume to investigate the XHCI Unsupported Request errors.
>>
>> 2) Collect the contents of /proc/mtrr before and after the suspend/resume.
>>
>> 3) After the suspend/resume, try the "setpci" to set the MSI address
>> back to the original value to see if it makes a difference (see my Feb
>> 12 message).
>
>
> 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?
Bjorn
-----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
> performance after resume" issue? If so, can you collect
> /proc/mtrr contents before and after suspending?
Nope, not seen that issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRiSgCAAoJEJrBOlT6nu75e0IH/1tqoTRyAMfVgcWTfhdcSAVi
kBnvTpfGqlwD1ThxF3AZ+kHFPykI7TNUEvPR+syBFIi6BLHDoCZJMyCnKWwrY3jW
62lpgBZPZNejK+Yms3wjt6bZs81g38FKhWqm/IGruo7u79j/CS6puUypQMZ7WkC4
8y3SjBfiVy3ncQAOr7akCJzCv4fgqY+vtpIOHOXknfUxwgHqVOo3Pa0rMeat2TrN
8KHLkzYjML7Z+vN9DvPnqnRYFwFmkRZl01wRITo3OaFFJFhH70uqnwZ3ES+H0oh5
OpAJqEZ1PqiSAn+P7nI8RJ8lt7c5bta6Mvv0ev4+aDOQxnL3AmipOMNGfI37Ubk=
=fiiM
-----END PGP SIGNATURE-----