From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932945AbbD0N6Q (ORCPT ); Mon, 27 Apr 2015 09:58:16 -0400 Received: from nef2.ens.fr ([129.199.96.40]:3599 "EHLO nef2.ens.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932762AbbD0N6P (ORCPT ); Mon, 27 Apr 2015 09:58:15 -0400 X-Greylist: delayed 3252 seconds by postgrey-1.27 at vger.kernel.org; Mon, 27 Apr 2015 09:58:14 EDT Date: Mon, 27 Apr 2015 15:03:58 +0200 From: Nicolas George To: debian-user@lists.debian.org, linux-kernel@vger.kernel.org Subject: ATA resets with Intel 8/C220 and HGST drive Message-ID: <20150427130358.GA522233@phare.normalesup.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (nef2.ens.fr [129.199.96.32]); Mon, 27 Apr 2015 15:03:58 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Summary: I had annoying resets of the SATA bus with a 8 Series/C220 Series Chipset controller and a HGST Travelstar 7K1000 drive. I recently managed to stop them and as far as I currently know I am satisfied; I write this mail in the hope that it may be useful for anyone having similar issues. If you do not have that issue and you are not a developer interested in fixing the issue more permanently, you can stop reading right now. Here are the details. The computer is a Zotac ZBox ID91 nettop with a proprietary motherboard, and, as stated above, a Travelstar 7K1000 hard drive (a 7200 RPM 2.5", an unusual beast). It was installed around June 2014, and I noticed the problems some time later, they probably started right away. The distribution was a Debian Jessie (testing) with the packaged kernel, probably linux-image-3.14-1-amd64:amd64 at the time; the issue was not fixed by upgrades. The possibly relevant hardware information are these: CPU: Intel(R) Core(TM) i3-4130T CPU @ 2.90GHz CPU: product: Intel(R) Core(TM) i3-4130T CPU @ 2.90GHz description: SATA controller product: 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI= mode] vendor: Intel Corporation physical id: 1f.2 bus info: pci@0000:00:1f.2 version: 05 width: 32 bits clock: 66MHz capabilities: storage msi pm ahci_1.0 bus_master cap_list configuration: driver=3Dahci latency=3D0 resources: irq:42 ioport:f0b0(size=3D8) ioport:f0a0(size=3D4) ioport:f090(s= ize=3D8) ioport:f080(size=3D4) ioport:f060(size=3D32) memory:f7d1a000-f7d1a= 7ff description: ATA Disk product: HGST HTS721010A9 physical id: 0.0.0 bus info: scsi@1:0.0.0 logical name: /dev/sda version: A3J0 serial: [REMOVED] size: 931GiB (1TB) capabilities: partitioned partitioned:dos configuration: ansiversion=3D5 logicalsectorsize=3D512 sectorsize=3D4096 si= gnature=3Dd3079a6d The resets happened a few times a day (this computer was is kept on for more than a day and suspend is not used), mostly when the disk was in heavy use, sometimes as early as during the boot; there was a few good days when they did not happen. They were annoying because they caused a few seconds freeze of anything reading from disk; AFAIK they never resulted in data corruption. The corresponding kernel messages look like this: [ 337.466498] ata2: EH complete [ 367.251032] ata2.00: exception Emask 0x10 SAct 0x80000 SErr 0x400100 act= ion 0x6 frozen [ 367.251041] ata2.00: irq_stat 0x08000000, interface fatal error [ 367.251046] ata2: SError: { UnrecovData Handshk } [ 367.251053] ata2.00: failed command: WRITE FPDMA QUEUED [ 367.251063] ata2.00: cmd 61/08:98:68:3b:40/00:00:6b:00:00/40 tag 19 ncq = 4096 out [ 367.251063] res 50/00:08:68:3b:40/00:00:6b:00:00/40 Emask 0x10 = (ATA bus error) [ 367.251068] ata2.00: status: { DRDY } [ 367.251075] ata2: hard resetting link [ 367.571128] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 367.577660] ata2.00: configured for UDMA/133 [ 367.577676] ata2: EH complete [ 409.772730] ata2: limiting SATA link speed to 3.0 Gbps [ 409.772735] ata2.00: exception Emask 0x10 SAct 0x3fe00 SErr 0x400100 act= ion 0x6 frozen [ 409.772736] ata2.00: irq_stat 0x08000000, interface fatal error [ 409.772737] ata2: SError: { UnrecovData Handshk } [ 409.772739] ata2.00: failed command: READ FPDMA QUEUED [ 409.772742] ata2.00: cmd 60/08:48:78:09:41/00:00:01:00:00/40 tag 9 ncq 4= 096 in [ 409.772742] res 50/00:28:e0:a3:04/00:00:02:00:00/40 Emask 0x10 = (ATA bus error) [ 409.772743] ata2.00: status: { DRDY } [ 409.772773] ata2.00: failed command: WRITE FPDMA QUEUED [ 409.772776] ata2.00: cmd 61/28:88:e0:a3:04/00:00:02:00:00/40 tag 17 ncq = 20480 out [ 409.772776] res 50/00:28:e0:a3:04/00:00:02:00:00/40 Emask 0x10 = (ATA bus error) [ 409.772777] ata2.00: status: { DRDY } [ 409.772779] ata2: hard resetting link [ 410.092732] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320) [ 410.097670] ata2.00: configured for UDMA/133 Last week, hinted by the penultimate line, I tried to lower the speed of the SATA link permanently, and it worked. I did this by adding "libata.force=3D2:3.0Gbps" to the kernel command line (configured using /etc/default/grub). Since then, no reset happened; I am confident that seven days without them are not a coincidence. As I said, I consider the issue closed from my point of view. If someone wants to investigate further (for example a kernel hacker to actually fix this, or a distro developer to make an automatic work-around), I can give some more details, and possibly run a few tests if they do not take much time and are not too risky. Hope this helps. Regards, --=20 Nicolas George --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVPjO+AAoJEHGVSyPKTcYMlS4P/1VjmwRVcdPh8WT7rt1GnbWO bkQcPF7nInG8y2PMuKFDqdBYsEMNOPrT3fgly+h99pIMVXy7Ef1GUz9L/S4POiL9 FPrWaZrUi/bT6mJQCTns8/OtfbFk9TVW7zmk+ilj5Tz3tzCyYx+DWmHGR+9nR2+d Gv/vO6IoB4Ruey8PEJMbCbnfmWppV7LmmC/9fBRRNoYpRLMPqEH7Q3NnpnfZTpYM RLYmzFKL9Tpn5ygqoSz5btUIHP21pDjoHp0lQYx5LZrDzi+62rwJJQ5p8Y26rvoE QcC5mqgr3fBZ17D6p5WLlydCZJJVCml1bynJOpCC031S4pn6/g1oja14x2ucRZML S/Zv5Hxvl/P6JTbiPvqpfZsNxjv0SWqQpxuaYf0v5s7nt5jQCLUm/ZIR6rsRv1EJ iCHY93I1Ms1XT+UC/eA9FccxjZ2sB5HepYth7qrp6R9hQC8Oftp8qj8a1eGe4W/G MV9tTdLn9HNPOpsWHQJYNkxqSWa5NXd3MWPNzpTol81feEQ3+GNYzEFffKu4JgoX xiNKSAnAUh8Yd8WQ0SPbJXPsUs3rYpnYkjVbSSvgt0/rQxUQ95W6flqV3IqneaEo ntG4Om9Q8pEFIkY0nZWjllzUt4qq1dBuWj4JHEYqUdPAarq2kB1UItJhHeHQgTWh JHn9PfBVzsuryfs7PLsv =TyBC -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--