Bug 53551

Created attachment 92841 [details]
dmesg (UEFI disabled)

OK, I've just rebooted with UEFI disabled, and everything (after suspend/resume) works as expected.

Strangely, on the second or third suspend during a single start up sequence (i.e. without reboots/shutdowns), speed became as awful as with a UEFI boot.

I.e. UEFI is not strictly necessary to trigger this problem, with UEFI it just happens immediately after a first suspend attempt.

In that case, I suspect that it's related to the memory map layout in some way and the UEFI memory map just makes your problem occur more reliably.

Do you know of a kernel version that doesn't exhibit this bug, e.g. is this a regression? If so, doing a git bisect would be the simplest way to find out what commit introduced this slowdown.

Created attachment 93161 [details]
lspci -vvvv, dd, hdparm, /proc info on boot and after suspend

This time it's taken four suspend attempts for this problem to appear _without_ EUFI.

I will now try to run this test in Windows - let's see if it affects Windows as well - if I can reproduce this problem in this OS then almost certainly it's a BIOS bug.

OK, Windows doesn't suffer from this bug, but it's not entirely happy either:

"The system firmware has changed the processor's memory type range registers (MTRRs) across a sleep state transition (S4). This can result in reduced resume performance."

That's kinda weird, as Linux doesn't detect this change in MTTR registers. Can it be the source of slowdown?

I'm have an issue that looks identical using Ubuntu 12.04 on a Lenovo ThinkPad W520. I believe it started once I upgrade to the 3.5 kernel series.

After a resume the disk write speed is super slow. Today I saw the same issue after taking my laptop out of the port replicator or once I placed it back in.

BIOS bug.

You can probably mostly work around it by setting the mtrr values back sensibly using the /proc/mtrr interface and a bit of scripting.

Gotta reopen since it doesn't happen in Windows ever.

If it means Linux has to be more "Windows" like - so it must be it. Hardware vendors often don't give a damn about Linux and we have to play by their rules unfortunately.

Otherwise there's no point in developing Linux.

Its a firmware bug. I've noted how to work around it.

If you wanted to automate that its a distribution problem and shell script in the suspend/resume scripts not a kernel action. We can't put every workaround for every obscure firmware bug in the kernel nor should we.

Alan

I've verified that MTTR values rarely change - so most likely it's not related to MTTR. So far, I haven't received any advice as to how I can even debug this issue.

> We can't put every workaround for every obscure firmware bug in the kernel
> nor should we.

Then why are there so many quirks and workarounds in the Linux kernel? I guess no less than several hundreds.

How many motherboards owners based on the Intel P8P67 chipset use Linux? Less than 0.5%?  So how do you know and why do you think you have the right to say it's an obscure firmware bug? So far we haven't even found out the root cause of this problem.

If you have any ideas how I can "see" what parts of the Linux kernel break in a process of UEFI reboot, I'm here to follow and debug.

I happen to run i686 in PAE mode - the problem might be related to this fact.

I will reopen this bug report, when I switch to x86-64 (I still haven't found a single serious reason for that).

i'm using amd64 3.16 and 3.19 and have the same problem, after suspend disk io is very slow. io to tmpfs and network is fine.

$ cat /proc/mtrr 
reg00: base=0x0ff800000 ( 4088MB), size=    8MB, count=1: write-protect
reg01: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x0bc000000 ( 3008MB), size=   64MB, count=1: uncachable
reg04: base=0x0bb000000 ( 2992MB), size=   16MB, count=1: uncachable
reg05: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg06: base=0x200000000 ( 8192MB), size= 8192MB, count=1: write-back
reg07: base=0x400000000 (16384MB), size= 1024MB, count=1: write-back
reg08: base=0x43f000000 (17392MB), size=   16MB, count=1: uncachable

/proc/mtrr does not change after suspend.

$ uname -a
Linux io 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux

please reopen

(In reply to gfa from comment #12)

Please post your hardware configuration:

1) Motherboard and its BIOS version
2) CPU
3) RAM configuration
4) Type of storage and how your disk is connected to the motherboard (which SATA ports)
5) Please attach dmesg, lspci -vvv, /proc/iomem

1) 
hp elitebook 8470p
BIOS Information
        Vendor: Hewlett-Packard
        Version: 68ICF Ver. F.31
        Release Date: 09/24/2012
2)
Intel(R) Core(TM) i5-3340M CPU @ 2.70GHz

3)
2x8G kingston ddr3 1600mhz

4) 
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
INTEL SSDSC2BW180A3H

ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
WDC WD3200BEKT-60PVMT0

Created attachment 171091 [details]
dmesg ok hp elitebook

dmesg after boot the laptop, suspend and resume *without* the problem

Created attachment 171101 [details]
/proc/iomem

/proc/iomem after suspend and resume without the problem

Created attachment 171111 [details]
lspci -vvvvx

lspci -vvvx after suspend and resume, without the problem

Created attachment 171121 [details]
/proc/mtrr

after suspend and resume without the problem

/proc/mtrr looks the same after and before suspend, with or without the problem

laptop now is working ok, sometimes if works for long time suspending and resuming for almost a month. 
most of the time i have to reboot after every suspend or hibernate

now is slow again, uploading files

Created attachment 172731 [details]
/proc/iomem when machine is slow

Created attachment 172741 [details]
dmesg when the machine is slow

Created attachment 172751 [details]
lspci -vvvvx when the machine is slow

i found this looking at the differences of lspci between slow and ok


00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI])
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+

OK:
	Interrupt: pin A routed to IRQ 46
        Address: 00000000fee00398  Data: 0000
SLOW:
        Interrupt: pin A routed to IRQ 45
        Address: 00000000fee00378  Data: 0000


00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-

OK:
     Interrupt: pin B routed to IRQ 45
     Address: fee00378  Data: 0000

SLOW:
     Interrupt: pin B routed to IRQ 46
     Address: fee00398  Data: 0000


02:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller (rev 30)

OK:
    DevSta:	CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
SLOW:
    DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

i was able to get a bios update from my vendor. let's hope that fix the issue

i'm sorry but the bug is not on the kernel, acpi-support scripts fool me. you can close this bug