Re: Patch "libata: Fall back to unqueued READ LOG EXT if the DMA variant fails" has been added to the 4.1-stable tree

[Stefan Lippers-Hollmann <s.l-h@gmx.de>]

Hi

On 2015-07-29, gregkh@linuxfoundation.org wrote:
> This is a note to let you know that I've just added the patch titled
> 
>     libata: Fall back to unqueued READ LOG EXT if the DMA variant fails
> 
> to the 4.1-stable tree which can be found at:
>     http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> 
> The filename of the patch is:
>      libata-fall-back-to-unqueued-read-log-ext-if-the-dma-variant-fails.patch
> and it can be found in the queue-4.1 subdirectory.
> 
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
> 
> 
> From 5d3abf8ff67f49271a42c0f7fa4f20f9e046bf0e Mon Sep 17 00:00:00 2001
> From: "Martin K. Petersen" <martin.petersen@oracle.com>
> Date: Mon, 4 May 2015 21:54:21 -0400
> Subject: libata: Fall back to unqueued READ LOG EXT if the DMA variant fails
> 
> From: "Martin K. Petersen" <martin.petersen@oracle.com>
> 
> commit 5d3abf8ff67f49271a42c0f7fa4f20f9e046bf0e upstream.
> 
> Some devices advertise support for the READ/WRITE LOG DMA EXT commands
> but fail when we try to issue them. This can lead to queued TRIM being
> unintentionally disabled since the relevant feature flag is located in a
> general purpose log page.
> 
> Fall back to unqueued READ LOG EXT if the DMA variant fails while
> reading a log page.

This patch, as part of the current -stable queue-4.1 introduces a 
regression for me on an ivy-bridge Asus P8H77-M PRO[1] mainboard using 
a Toshiba DT01ACA3 attached. When trying to boot, the system stops 
with a high spinning loop (and many supressed printks) of

	ata1.00: READ LOG DMA EXT failed, trying unqueued

while still being in the initramfs code.

00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04) (prog-if 01 [AHCI 1.0])
        Subsystem: ASUSTeK Computer Inc. P8 series motherboard [1043:84ca]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin B routed to IRQ 30
        Region 0: I/O ports at f0b0 [size=8]
        Region 1: I/O ports at f0a0 [size=4]
        Region 2: I/O ports at f090 [size=8]
        Region 3: I/O ports at f080 [size=4]
        Region 4: I/O ports at f060 [size=32]
        Region 5: Memory at f7f16000 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
                Address: fee00398  Data: 0000
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
        Capabilities: [b0] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel driver in use: ahci

$ lsscsi 
[0:0:0:0]    disk    ATA      Samsung SSD 840  6B0Q  /dev/sda 
[1:0:0:0]    disk    ATA      TOSHIBA DT01ACA3 ABB0  /dev/sdb 
[2:0:0:0]    disk    ATA      SAMSUNG HD204UI  0001  /dev/sdc 
[3:0:0:0]    disk    ATA      SAMSUNG HD204UI  0001  /dev/sdd 
[4:0:0:0]    disk    ATA      ST3000DM001-1CH1 CC24  /dev/sde 
[5:0:0:0]    disk    ATA      TOSHIBA DT01ACA3 ABB0  /dev/sdf

Reverting only this patch from the current queue-4.1, and fixing up 
the trivial merge conflicts this introduces for the subsequent patches

	libata-add-ata_horkage_max_sec_1024-to-revert-back-to-previous-max_sectors-limit.patch
	libata-add-ata_horkage_notrim.patch

fixes the problem for me.

Regards
	Stefan Lippers-Hollmann

[1]	http://www.asus.com/Motherboards/P8H77M_PRO