Hi On 2015-07-29, gregkh@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx> know about it. > > > From 5d3abf8ff67f49271a42c0f7fa4f20f9e046bf0e Mon Sep 17 00:00:00 2001 > From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx> > 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@xxxxxxxxxx> > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html