<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/ata, branch v3.12.20</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>libata: Update queued trim blacklist for M5x0 drives</title>
<updated>2014-05-15T07:56:01+00:00</updated>
<author>
<name>Martin K. Petersen</name>
<email>martin.petersen@oracle.com</email>
</author>
<published>2014-04-02T00:42:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1b18c1cf7f64cfa8a7c5cdfc3f364b4280b15660'/>
<id>1b18c1cf7f64cfa8a7c5cdfc3f364b4280b15660</id>
<content type='text'>
commit d121f7d0cbb875abce249dbf7eb191f9bafe80b7 upstream.

Crucial/Micron M500 drives properly support queued DSM TRIM starting
with firmware MU05. Update the blacklist so we only disable queued trim
for older firmware releases.

Early M550 series drives suffer from the same issue as M500. A bugfix
firmware is in the pipeline but not ready yet. Until then, blacklist
queued trim for M550.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Chris Samuel &lt;chris@csamuel.org&gt;
Cc: Marc MERLIN &lt;marc@merlins.org&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d121f7d0cbb875abce249dbf7eb191f9bafe80b7 upstream.

Crucial/Micron M500 drives properly support queued DSM TRIM starting
with firmware MU05. Update the blacklist so we only disable queued trim
for older firmware releases.

Early M550 series drives suffer from the same issue as M500. A bugfix
firmware is in the pipeline but not ready yet. Until then, blacklist
queued trim for M550.

Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Chris Samuel &lt;chris@csamuel.org&gt;
Cc: Marc MERLIN &lt;marc@merlins.org&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ahci: Do not receive interrupts sent by dummy ports</title>
<updated>2014-05-15T07:56:01+00:00</updated>
<author>
<name>Alexander Gordeev</name>
<email>agordeev@redhat.com</email>
</author>
<published>2014-04-17T16:06:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7adc63f52f7d6ab93e7c53c2a34bcb690cc560e5'/>
<id>7adc63f52f7d6ab93e7c53c2a34bcb690cc560e5</id>
<content type='text'>
commit 2cf532f5e67c0cfe38c8c100e49280cdadacd2be upstream.

In multiple MSI mode all AHCI ports (including dummy) get assigned
separate MSI vectors and (as result of execution
pci_enable_msi_exact() function) separate IRQ numbers, (mapped to the
MSI vectors).

Therefore, although interrupts from dummy ports are not desired they
are still enabled. We do not request IRQs for dummy ports, but that
only means we do not assign AHCI-specific ISRs to corresponding IRQ
numbers.

As result, dummy port interrupts still could come and traverse all the
way from the PCI device to the kernel, causing unnecessary overhead.

This update disables IRQs for dummy ports and prevents the described
issue.

Signed-off-by: Alexander Gordeev &lt;agordeev@redhat.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Tested-by: David Milburn &lt;dmilburn@redhat.com&gt;
Cc: linux-ide@vger.kernel.org
Fixes: 5ca72c4f7c41 ("AHCI: Support multiple MSIs")
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2cf532f5e67c0cfe38c8c100e49280cdadacd2be upstream.

In multiple MSI mode all AHCI ports (including dummy) get assigned
separate MSI vectors and (as result of execution
pci_enable_msi_exact() function) separate IRQ numbers, (mapped to the
MSI vectors).

Therefore, although interrupts from dummy ports are not desired they
are still enabled. We do not request IRQs for dummy ports, but that
only means we do not assign AHCI-specific ISRs to corresponding IRQ
numbers.

As result, dummy port interrupts still could come and traverse all the
way from the PCI device to the kernel, causing unnecessary overhead.

This update disables IRQs for dummy ports and prevents the described
issue.

Signed-off-by: Alexander Gordeev &lt;agordeev@redhat.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Tested-by: David Milburn &lt;dmilburn@redhat.com&gt;
Cc: linux-ide@vger.kernel.org
Fixes: 5ca72c4f7c41 ("AHCI: Support multiple MSIs")
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>libata/ahci: accommodate tag ordered controllers</title>
<updated>2014-05-15T07:56:00+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2014-04-17T18:48:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d168685b0bb01219443ceeb47d786a30693553a1'/>
<id>d168685b0bb01219443ceeb47d786a30693553a1</id>
<content type='text'>
commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.

The AHCI spec allows implementations to issue commands in tag order
rather than FIFO order:

	5.3.2.12 P:SelectCmd
	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
	or HBA selects the command to issue that has had the
	PxCI bit set to '1' longer than any other command
	pending to be issued.

The result is that commands posted sequentially (time-wise) may play out
of sequence when issued by hardware.

This behavior has likely been hidden by drives that arrange for commands
to complete in issue order.  However, it appears recent drives (two from
different vendors that we have found so far) inflict out-of-order
completions as a matter of course.  So, we need to take care to maintain
ordered submission, otherwise we risk triggering a drive to fall out of
sequential-io automation and back to random-io processing, which incurs
large latency and degrades throughput.

This issue was found in simple benchmarks where QD=2 seq-write
performance was 30-50% *greater* than QD=32 seq-write performance.

Tagging for -stable and making the change globally since it has a low
risk-to-reward ratio.  Also, word is that recent versions of an unnamed
OS also does it this way now.  So, drives in the field are already
experienced with this tag ordering scheme.

Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Ed Ciechanowski &lt;ed.ciechanowski@intel.com&gt;
Reviewed-by: Matthew Wilcox &lt;matthew.r.wilcox@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream.

The AHCI spec allows implementations to issue commands in tag order
rather than FIFO order:

	5.3.2.12 P:SelectCmd
	HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
	or HBA selects the command to issue that has had the
	PxCI bit set to '1' longer than any other command
	pending to be issued.

The result is that commands posted sequentially (time-wise) may play out
of sequence when issued by hardware.

This behavior has likely been hidden by drives that arrange for commands
to complete in issue order.  However, it appears recent drives (two from
different vendors that we have found so far) inflict out-of-order
completions as a matter of course.  So, we need to take care to maintain
ordered submission, otherwise we risk triggering a drive to fall out of
sequential-io automation and back to random-io processing, which incurs
large latency and degrades throughput.

This issue was found in simple benchmarks where QD=2 seq-write
performance was 30-50% *greater* than QD=32 seq-write performance.

Tagging for -stable and making the change globally since it has a low
risk-to-reward ratio.  Also, word is that recent versions of an unnamed
OS also does it this way now.  So, drives in the field are already
experienced with this tag ordering scheme.

Cc: Dave Jiang &lt;dave.jiang@intel.com&gt;
Cc: Ed Ciechanowski &lt;ed.ciechanowski@intel.com&gt;
Reviewed-by: Matthew Wilcox &lt;matthew.r.wilcox@intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ahci: do not request irq for dummy port</title>
<updated>2014-05-15T07:56:00+00:00</updated>
<author>
<name>David Milburn</name>
<email>dmilburn@redhat.com</email>
</author>
<published>2014-04-16T16:43:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f7f31e5ef6d277ed917369f4e246088699b60470'/>
<id>f7f31e5ef6d277ed917369f4e246088699b60470</id>
<content type='text'>
commit 9ae794ac5e407d3bc3fec785db481d5a2c0fa275 upstream.

System may crash in ahci_hw_interrupt() or ahci_thread_fn() when
accessing the interrupt status in a port's private_data if the port is
actually a DUMMY port.

00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller

&lt;snip console output for linux-3.15-rc1&gt;
[    9.352080] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x1 impl SATA mode
[    9.352084] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc
[    9.368155] Console: switching to colour frame buffer device 128x48
[    9.439759] mgag200 0000:11:00.0: fb0: mgadrmfb frame buffer device
[    9.446765] mgag200 0000:11:00.0: registered panic notifier
[    9.470166] scsi1 : ahci
[    9.479166] scsi2 : ahci
[    9.488172] scsi3 : ahci
[    9.497174] scsi4 : ahci
[    9.506175] scsi5 : ahci
[    9.515174] scsi6 : ahci
[    9.518181] ata1: SATA max UDMA/133 abar m2048@0x95c00000 port 0x95c00100 irq 91
[    9.526448] ata2: DUMMY
[    9.529182] ata3: DUMMY
[    9.531916] ata4: DUMMY
[    9.534650] ata5: DUMMY
[    9.537382] ata6: DUMMY
[    9.576196] [drm] Initialized mgag200 1.0.0 20110418 for 0000:11:00.0 on minor 0
[    9.845257] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    9.865161] ata1.00: ATAPI: Optiarc DVD RW AD-7580S, FX04, max UDMA/100
[    9.891407] ata1.00: configured for UDMA/100
[    9.900525] scsi 1:0:0:0: CD-ROM            Optiarc  DVD RW AD-7580S  FX04 PQ: 0 ANSI: 5
[   10.247399] iTCO_vendor_support: vendor-support=0
[   10.261572] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   10.269764] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
[   10.301932] sd 0:2:0:0: [sda] 570310656 512-byte logical blocks: (291 GB/271 GiB)
[   10.317085] sd 0:2:0:0: [sda] Write Protect is off
[   10.328326] sd 0:2:0:0: [sda] Write cache: disabled, read cache: disabled, supports DPO and FUA
[   10.375452] BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
[   10.384217] IP: [&lt;ffffffffa0133df0&gt;] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.392101] PGD 0
[   10.394353] Oops: 0000 [#1] SMP
[   10.397978] Modules linked in: sr_mod(+) cdrom sd_mod iTCO_wdt crc_t10dif iTCO_vendor_support crct10dif_common ahci libahci libata lpc_ich mfd_core mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm i2c_core megaraid_sas dm_mirror dm_region_hash
dm_log dm_mod
[   10.426499] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1 #1
[   10.433495] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
[   10.443886] task: ffffffff81906460 ti: ffffffff818f0000 task.ti: ffffffff818f0000
[   10.452239] RIP: 0010:[&lt;ffffffffa0133df0&gt;]  [&lt;ffffffffa0133df0&gt;] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.462838] RSP: 0018:ffff880033c03d98  EFLAGS: 00010046
[   10.468767] RAX: 0000000000a400a4 RBX: ffff880029a6bc18 RCX: 00000000fffffffa
[   10.476731] RDX: 00000000000000a4 RSI: ffff880029bb0000 RDI: ffff880029a6bc18
[   10.484696] RBP: ffff880033c03dc8 R08: 0000000000000000 R09: ffff88002f800490
[   10.492661] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000000
[   10.500625] R13: ffff880029a6bd98 R14: 0000000000000000 R15: ffffc90000194000
[   10.508590] FS:  0000000000000000(0000) GS:ffff880033c00000(0000) knlGS:0000000000000000
[   10.517623] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   10.524035] CR2: 000000000000003c CR3: 00000000328ff000 CR4: 00000000000007b0
[   10.531999] Stack:
[   10.534241]  0000000000000017 ffff880031ba7d00 000000000000005c ffff880031ba7d00
[   10.542535]  0000000000000000 000000000000005c ffff880033c03e10 ffffffff810c2a1e
[   10.550827]  ffff880031ae2900 000000008108fb4f ffff880031ae2900 ffff880031ae2984
[   10.559121] Call Trace:
[   10.561849]  &lt;IRQ&gt;
[   10.563994]  [&lt;ffffffff810c2a1e&gt;] handle_irq_event_percpu+0x3e/0x1a0
[   10.571309]  [&lt;ffffffff810c2bbd&gt;] handle_irq_event+0x3d/0x60
[   10.577631]  [&lt;ffffffff810c4fdd&gt;] try_one_irq.isra.6+0x8d/0xf0
[   10.584142]  [&lt;ffffffff810c5313&gt;] note_interrupt+0x173/0x1f0
[   10.590460]  [&lt;ffffffff810c2a8e&gt;] handle_irq_event_percpu+0xae/0x1a0
[   10.597554]  [&lt;ffffffff810c2bbd&gt;] handle_irq_event+0x3d/0x60
[   10.603872]  [&lt;ffffffff810c5727&gt;] handle_edge_irq+0x77/0x130
[   10.610199]  [&lt;ffffffff81014b8f&gt;] handle_irq+0xbf/0x150
[   10.616040]  [&lt;ffffffff8109ff4e&gt;] ? vtime_account_idle+0xe/0x50
[   10.622654]  [&lt;ffffffff815fca1a&gt;] ? atomic_notifier_call_chain+0x1a/0x20
[   10.630140]  [&lt;ffffffff816038cf&gt;] do_IRQ+0x4f/0xf0
[   10.635490]  [&lt;ffffffff815f8aed&gt;] common_interrupt+0x6d/0x6d
[   10.641805]  &lt;EOI&gt;
[   10.643950]  [&lt;ffffffff8149ca9f&gt;] ? cpuidle_enter_state+0x4f/0xc0
[   10.650972]  [&lt;ffffffff8149ca98&gt;] ? cpuidle_enter_state+0x48/0xc0
[   10.657775]  [&lt;ffffffff8149cb47&gt;] cpuidle_enter+0x17/0x20
[   10.663807]  [&lt;ffffffff810b0070&gt;] cpu_startup_entry+0x2c0/0x3d0
[   10.670423]  [&lt;ffffffff815dfcc7&gt;] rest_init+0x77/0x80
[   10.676065]  [&lt;ffffffff81a60f47&gt;] start_kernel+0x40f/0x41a
[   10.682190]  [&lt;ffffffff81a60941&gt;] ? repair_env_string+0x5c/0x5c
[   10.688799]  [&lt;ffffffff81a60120&gt;] ? early_idt_handlers+0x120/0x120
[   10.695699]  [&lt;ffffffff81a605ee&gt;] x86_64_start_reservations+0x2a/0x2c
[   10.702889]  [&lt;ffffffff81a60733&gt;] x86_64_start_kernel+0x143/0x152
[   10.709689] Code: a0 fc ff 85 c0 8b 4d d4 74 c3 48 8b 7b 08 89 ca 48 c7 c6 60 66 13 a0 31 c0 e8 9d 70 28 e1 8b 4d d4 eb aa 0f 1f 84 00 00 00 00 00 &lt;45&gt; 8b 64 24 3c 48 89 df e8 23 47 4c e1 41 83 fc 01 19 c0 48 83
[   10.731470] RIP  [&lt;ffffffffa0133df0&gt;] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.739441]  RSP &lt;ffff880033c03d98&gt;
[   10.743333] CR2: 000000000000003c
[   10.747032] ---[ end trace b6e82636970e2690 ]---
[   10.760190] Kernel panic - not syncing: Fatal exception in interrupt
[   10.767291] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

Cc: Alexander Gordeev &lt;agordeev@redhat.com&gt;
Cc: Tejun Heo &lt;tj@kernel.org&gt;
Signed-of-by: David Milburn &lt;dmilburn@redhat.com&gt;
Fixes: 5ca72c4f7c41 ("AHCI: Support multiple MSIs")
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9ae794ac5e407d3bc3fec785db481d5a2c0fa275 upstream.

System may crash in ahci_hw_interrupt() or ahci_thread_fn() when
accessing the interrupt status in a port's private_data if the port is
actually a DUMMY port.

00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller

&lt;snip console output for linux-3.15-rc1&gt;
[    9.352080] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x1 impl SATA mode
[    9.352084] ahci 0000:00:1f.2: flags: 64bit ncq sntf pm led clo pio slum part ccc
[    9.368155] Console: switching to colour frame buffer device 128x48
[    9.439759] mgag200 0000:11:00.0: fb0: mgadrmfb frame buffer device
[    9.446765] mgag200 0000:11:00.0: registered panic notifier
[    9.470166] scsi1 : ahci
[    9.479166] scsi2 : ahci
[    9.488172] scsi3 : ahci
[    9.497174] scsi4 : ahci
[    9.506175] scsi5 : ahci
[    9.515174] scsi6 : ahci
[    9.518181] ata1: SATA max UDMA/133 abar m2048@0x95c00000 port 0x95c00100 irq 91
[    9.526448] ata2: DUMMY
[    9.529182] ata3: DUMMY
[    9.531916] ata4: DUMMY
[    9.534650] ata5: DUMMY
[    9.537382] ata6: DUMMY
[    9.576196] [drm] Initialized mgag200 1.0.0 20110418 for 0000:11:00.0 on minor 0
[    9.845257] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    9.865161] ata1.00: ATAPI: Optiarc DVD RW AD-7580S, FX04, max UDMA/100
[    9.891407] ata1.00: configured for UDMA/100
[    9.900525] scsi 1:0:0:0: CD-ROM            Optiarc  DVD RW AD-7580S  FX04 PQ: 0 ANSI: 5
[   10.247399] iTCO_vendor_support: vendor-support=0
[   10.261572] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   10.269764] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by hardware/BIOS
[   10.301932] sd 0:2:0:0: [sda] 570310656 512-byte logical blocks: (291 GB/271 GiB)
[   10.317085] sd 0:2:0:0: [sda] Write Protect is off
[   10.328326] sd 0:2:0:0: [sda] Write cache: disabled, read cache: disabled, supports DPO and FUA
[   10.375452] BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
[   10.384217] IP: [&lt;ffffffffa0133df0&gt;] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.392101] PGD 0
[   10.394353] Oops: 0000 [#1] SMP
[   10.397978] Modules linked in: sr_mod(+) cdrom sd_mod iTCO_wdt crc_t10dif iTCO_vendor_support crct10dif_common ahci libahci libata lpc_ich mfd_core mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm i2c_core megaraid_sas dm_mirror dm_region_hash
dm_log dm_mod
[   10.426499] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1 #1
[   10.433495] Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.S013.032920111005 03/29/2011
[   10.443886] task: ffffffff81906460 ti: ffffffff818f0000 task.ti: ffffffff818f0000
[   10.452239] RIP: 0010:[&lt;ffffffffa0133df0&gt;]  [&lt;ffffffffa0133df0&gt;] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.462838] RSP: 0018:ffff880033c03d98  EFLAGS: 00010046
[   10.468767] RAX: 0000000000a400a4 RBX: ffff880029a6bc18 RCX: 00000000fffffffa
[   10.476731] RDX: 00000000000000a4 RSI: ffff880029bb0000 RDI: ffff880029a6bc18
[   10.484696] RBP: ffff880033c03dc8 R08: 0000000000000000 R09: ffff88002f800490
[   10.492661] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000000
[   10.500625] R13: ffff880029a6bd98 R14: 0000000000000000 R15: ffffc90000194000
[   10.508590] FS:  0000000000000000(0000) GS:ffff880033c00000(0000) knlGS:0000000000000000
[   10.517623] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   10.524035] CR2: 000000000000003c CR3: 00000000328ff000 CR4: 00000000000007b0
[   10.531999] Stack:
[   10.534241]  0000000000000017 ffff880031ba7d00 000000000000005c ffff880031ba7d00
[   10.542535]  0000000000000000 000000000000005c ffff880033c03e10 ffffffff810c2a1e
[   10.550827]  ffff880031ae2900 000000008108fb4f ffff880031ae2900 ffff880031ae2984
[   10.559121] Call Trace:
[   10.561849]  &lt;IRQ&gt;
[   10.563994]  [&lt;ffffffff810c2a1e&gt;] handle_irq_event_percpu+0x3e/0x1a0
[   10.571309]  [&lt;ffffffff810c2bbd&gt;] handle_irq_event+0x3d/0x60
[   10.577631]  [&lt;ffffffff810c4fdd&gt;] try_one_irq.isra.6+0x8d/0xf0
[   10.584142]  [&lt;ffffffff810c5313&gt;] note_interrupt+0x173/0x1f0
[   10.590460]  [&lt;ffffffff810c2a8e&gt;] handle_irq_event_percpu+0xae/0x1a0
[   10.597554]  [&lt;ffffffff810c2bbd&gt;] handle_irq_event+0x3d/0x60
[   10.603872]  [&lt;ffffffff810c5727&gt;] handle_edge_irq+0x77/0x130
[   10.610199]  [&lt;ffffffff81014b8f&gt;] handle_irq+0xbf/0x150
[   10.616040]  [&lt;ffffffff8109ff4e&gt;] ? vtime_account_idle+0xe/0x50
[   10.622654]  [&lt;ffffffff815fca1a&gt;] ? atomic_notifier_call_chain+0x1a/0x20
[   10.630140]  [&lt;ffffffff816038cf&gt;] do_IRQ+0x4f/0xf0
[   10.635490]  [&lt;ffffffff815f8aed&gt;] common_interrupt+0x6d/0x6d
[   10.641805]  &lt;EOI&gt;
[   10.643950]  [&lt;ffffffff8149ca9f&gt;] ? cpuidle_enter_state+0x4f/0xc0
[   10.650972]  [&lt;ffffffff8149ca98&gt;] ? cpuidle_enter_state+0x48/0xc0
[   10.657775]  [&lt;ffffffff8149cb47&gt;] cpuidle_enter+0x17/0x20
[   10.663807]  [&lt;ffffffff810b0070&gt;] cpu_startup_entry+0x2c0/0x3d0
[   10.670423]  [&lt;ffffffff815dfcc7&gt;] rest_init+0x77/0x80
[   10.676065]  [&lt;ffffffff81a60f47&gt;] start_kernel+0x40f/0x41a
[   10.682190]  [&lt;ffffffff81a60941&gt;] ? repair_env_string+0x5c/0x5c
[   10.688799]  [&lt;ffffffff81a60120&gt;] ? early_idt_handlers+0x120/0x120
[   10.695699]  [&lt;ffffffff81a605ee&gt;] x86_64_start_reservations+0x2a/0x2c
[   10.702889]  [&lt;ffffffff81a60733&gt;] x86_64_start_kernel+0x143/0x152
[   10.709689] Code: a0 fc ff 85 c0 8b 4d d4 74 c3 48 8b 7b 08 89 ca 48 c7 c6 60 66 13 a0 31 c0 e8 9d 70 28 e1 8b 4d d4 eb aa 0f 1f 84 00 00 00 00 00 &lt;45&gt; 8b 64 24 3c 48 89 df e8 23 47 4c e1 41 83 fc 01 19 c0 48 83
[   10.731470] RIP  [&lt;ffffffffa0133df0&gt;] ahci_hw_interrupt+0x100/0x130 [libahci]
[   10.739441]  RSP &lt;ffff880033c03d98&gt;
[   10.743333] CR2: 000000000000003c
[   10.747032] ---[ end trace b6e82636970e2690 ]---
[   10.760190] Kernel panic - not syncing: Fatal exception in interrupt
[   10.767291] Kernel Offset: 0x0 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffff9fffffff)

Cc: Alexander Gordeev &lt;agordeev@redhat.com&gt;
Cc: Tejun Heo &lt;tj@kernel.org&gt;
Signed-of-by: David Milburn &lt;dmilburn@redhat.com&gt;
Fixes: 5ca72c4f7c41 ("AHCI: Support multiple MSIs")
</pre>
</div>
</content>
</entry>
<entry>
<title>libata: use wider match for blacklisting Crucial M500</title>
<updated>2014-03-22T21:01:57+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-03-10T15:13:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=04da573274f14d9167901f6b8b38d7cc521f08ac'/>
<id>04da573274f14d9167901f6b8b38d7cc521f08ac</id>
<content type='text'>
commit 83493d7e782d2630f1a55def14a79f0e7c4faac3 upstream.

We're now blacklisting "Crucial_CT???M500SSD1" and
"Crucial_CT???M500SSD3".  Also, "Micron_M500*" is blacklisted which is
about the same devices as the crucial branded ones.  Let's merge the
two Crucial M500 entries and widen the match to
"Crucial_CT???M500SSD*" so that we don't have to fiddle with new
entries for similar devices.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 83493d7e782d2630f1a55def14a79f0e7c4faac3 upstream.

We're now blacklisting "Crucial_CT???M500SSD1" and
"Crucial_CT???M500SSD3".  Also, "Micron_M500*" is blacklisted which is
about the same devices as the crucial branded ones.  Let's merge the
two Crucial M500 entries and widen the match to
"Crucial_CT???M500SSD*" so that we don't have to fiddle with new
entries for similar devices.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 (2BA30001)</title>
<updated>2014-03-22T21:01:57+00:00</updated>
<author>
<name>Michele Baldessari</name>
<email>michele@acksyn.org</email>
</author>
<published>2014-03-07T16:34:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2d5a0832a2a8258291d97fcd0cee4425de1dc0a3'/>
<id>2d5a0832a2a8258291d97fcd0cee4425de1dc0a3</id>
<content type='text'>
commit b28a613e9138e4b3a64649bd60b13436f4b4b49b upstream.

Via commit 87809942d3fa "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk
for Seagate Momentus SpinPoint M8" we added a quirk for disks named
"ST1000LM024 HN-M101MBB" with firmware revision "2AR10001".

As reported on https://bugzilla.redhat.com/show_bug.cgi?id=1073901,
we need to also add firmware revision 2BA30001 as it is broken as well.

Reported-by: Nicholas &lt;arealityfarbetween@googlemail.com&gt;
Signed-off-by: Michele Baldessari &lt;michele@acksyn.org&gt;
Tested-by: Guilherme Amadio &lt;guilherme.amadio@gmail.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b28a613e9138e4b3a64649bd60b13436f4b4b49b upstream.

Via commit 87809942d3fa "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk
for Seagate Momentus SpinPoint M8" we added a quirk for disks named
"ST1000LM024 HN-M101MBB" with firmware revision "2AR10001".

As reported on https://bugzilla.redhat.com/show_bug.cgi?id=1073901,
we need to also add firmware revision 2BA30001 as it is broken as well.

Reported-by: Nicholas &lt;arealityfarbetween@googlemail.com&gt;
Signed-off-by: Michele Baldessari &lt;michele@acksyn.org&gt;
Tested-by: Guilherme Amadio &lt;guilherme.amadio@gmail.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>libata: disable queued TRIM for Crucial M500 mSATA SSDs</title>
<updated>2014-03-22T21:01:57+00:00</updated>
<author>
<name>Marios Andreopoulos</name>
<email>opensource@andmarios.com</email>
</author>
<published>2014-03-03T16:19:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e98da7baab3bbb4cfcc60ab24a91b64c650c39d1'/>
<id>e98da7baab3bbb4cfcc60ab24a91b64c650c39d1</id>
<content type='text'>
commit 2564338b13e6e132ee224edb63e1e872adf431f4 upstream.

Queued TRIM commands cause problems and silent file system corruption
on Crucial M500 SSDs. This patch disables them for the mSATA model of
the drive.

Signed-off-by: Marios Andreopoulos &lt;opensource@andmarios.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=71371
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2564338b13e6e132ee224edb63e1e872adf431f4 upstream.

Queued TRIM commands cause problems and silent file system corruption
on Crucial M500 SSDs. This patch disables them for the mSATA model of
the drive.

Signed-off-by: Marios Andreopoulos &lt;opensource@andmarios.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=71371
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN</title>
<updated>2014-03-05T16:13:46+00:00</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2014-02-03T15:42:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bbff349264e736651e87bc6937882529b5441d47'/>
<id>bbff349264e736651e87bc6937882529b5441d47</id>
<content type='text'>
commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.

It's a bit odd to see a newer device showing mod15write; however, the
reported behavior is highly consistent and other factors which could
contribute seem to have been verified well enough.  Also, both
sata_sil itself and the drive are fairly outdated at this point making
the risk of this change fairly low.  It is possible, probably likely,
that other drive models in the same family have the same problem;
however, for now, let's just add the specific model which was tested.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: matson &lt;lists-matsonpa@luxsci.me&gt;
References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.

It's a bit odd to see a newer device showing mod15write; however, the
reported behavior is highly consistent and other factors which could
contribute seem to have been verified well enough.  Also, both
sata_sil itself and the drive are fairly outdated at this point making
the risk of this change fairly low.  It is possible, probably likely,
that other drive models in the same family have the same problem;
however, for now, let's just add the specific model which was tested.

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: matson &lt;lists-matsonpa@luxsci.me&gt;
References: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ata: enable quirk from jmicron JMB350 for JMB394</title>
<updated>2014-03-05T16:13:46+00:00</updated>
<author>
<name>Denis V. Lunev</name>
<email>den@openvz.org</email>
</author>
<published>2014-01-30T11:20:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d5772bfe2ddd46c0a59bae0f776be249f48a9db0'/>
<id>d5772bfe2ddd46c0a59bae0f776be249f48a9db0</id>
<content type='text'>
commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.

Without the patch the kernel generates the following error.

 ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
 ata11.15: PMP revalidation failed (errno=-19)
 ata11.15: failed to recover PMP after 5 tries, giving up

This patch helps to bypass this error and the device becomes
functional.

Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: &lt;linux-ide@vger.kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.

Without the patch the kernel generates the following error.

 ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
 ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'
 ata11.15: PMP revalidation failed (errno=-19)
 ata11.15: failed to recover PMP after 5 tries, giving up

This patch helps to bypass this error and the device becomes
functional.

Signed-off-by: Denis V. Lunev &lt;den@openvz.org&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Cc: &lt;linux-ide@vger.kernel.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ahci: disable NCQ on Samsung pci-e SSDs on macbooks</title>
<updated>2014-03-05T16:13:45+00:00</updated>
<author>
<name>Levente Kurusa</name>
<email>levex@linux.com</email>
</author>
<published>2014-02-18T15:22:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7addaee35a868cd036c0d5a64388380ce47c1bc5'/>
<id>7addaee35a868cd036c0d5a64388380ce47c1bc5</id>
<content type='text'>
commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream.

Samsung's pci-e SSDs with device ID 0x1600 which are found on some
macbooks time out on NCQ commands.  Blacklist NCQ on the device so
that the affected machines can at least boot.

Original-patch-by: Levente Kurusa &lt;levex@linux.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 67809f85d31eac600f6b28defa5386c9d2a13b1d upstream.

Samsung's pci-e SSDs with device ID 0x1600 which are found on some
macbooks time out on NCQ commands.  Blacklist NCQ on the device so
that the affected machines can at least boot.

Original-patch-by: Levente Kurusa &lt;levex@linux.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60731
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
</feed>
