Hi
On 2015-07-29, [email protected] 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 <[email protected]> know about it.
>
>
> From 5d3abf8ff67f49271a42c0f7fa4f20f9e046bf0e Mon Sep 17 00:00:00 2001
> From: "Martin K. Petersen" <[email protected]>
> 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" <[email protected]>
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
