Created attachment 92831 [details] dmesg 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: ~120MB/sec USB write performance: ~18MB/sec After sleep: HDD write performance: ~7MB/sec (i.e 17 times slower) USB write performance: ~0.5MB/sec (i.e. 36 times slower) This is totally unacceptable, the computer becomes unusable. I 'm open to suggestions how to debug this extremely serious problem. P.S. Since I 'm still using x86 kernel, on boot it switches x86-64 UEFI off: [ 0.000000] efi: EFI v2.31 by American Megatrends [ 0.000000] efi: ACPI=0xdf385000 ACPI 2.0=0xdf385000 SMBIOS=0xdec28e98 MPS=0xfc9a0 [ 0.000000] efi: No EFI runtime due to 32/64-bit mismatch with kernel ... [ 0.000000] efi: Setup done, disabling due to 32/64-bit mismatch
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