| Message ID | 20170115091925.GA26656@gmail.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote: > So there's a new mpt3sas SCSI driver boot regression, introduced in > this merge window, which made one of my servers unbootable. We're not reverting a fix that would cause regressions for others. However, The fix was manifestly wrong, so does this fix of the fix work for you: http://marc.info/?l=linux-scsi&m=148329237807604 It's been languishing a bit because no-one seemed to care enough to test or review it. IOf you can add a tested by, that will give the two we need to push it. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jan 15, 2017 at 8:11 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > We're not reverting a fix that would cause regressions for others. Oh HELL YES we are. The rule is that we never break old stuff. Some new fix that fixes something that never used to work, but breaks something else, gets reverted very aggressively. So if a new bugfix or workaround causes problems for existing users, it gets reverted. The fact that it fixed something else is COMPLETELY IRRELEVANT. We do not do the "one step forward, two steps back" dance. If you can't fix a bug without breaking old systems, the "fix" gets reverted. Apparently there is already a possible real fix in flight, so I won't actually do the revert, but I very much want to object to your statement. Reverts happen. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2017-01-15 at 10:54 -0800, Linus Torvalds wrote: > On Sun, Jan 15, 2017 at 8:11 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > > > We're not reverting a fix that would cause regressions for others. > > Oh HELL YES we are. > > The rule is that we never break old stuff. Some new fix that fixes > something that never used to work, but breaks something else, gets > reverted very aggressively. > > So if a new bugfix or workaround causes problems for existing users, > it gets reverted. The fact that it fixed something else is COMPLETELY > IRRELEVANT. > > We do not do the "one step forward, two steps back" dance. If you > can't fix a bug without breaking old systems, the "fix" gets > reverted. > > Apparently there is already a possible real fix in flight, so I won't > actually do the revert, but I very much want to object to your > statement. > > Reverts happen. Can we compromise on "try not to revert a fix ...". The problem with bugs in regression fixes is that we now have two constituencies: the people who get the regression back if we revert the fix and the people who are bitten by the bug in the original regression fix. In this particular case, I think we should always try to fix the fix because reversion also violates "never break old stuff". There are corner cases, of course, like if the latter constituency is much bigger and the fix is hard to fix, then we might revert and try again. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > Can we compromise on "try not to revert a fix ...". No. It's about timing, and about how serious the regression is. For example, if this happened in rc7, I would have reverted immediately. No questions asked. In this case, the "fix" was was also much less important then the problem it caused. Some specialized pass-through command not working right, vs a machine not even booting? There's just no question what-so-ever. So the "fix" you claim just wasn't nearly important enough. It was also pretty recent and clearly things had worked for _years_ without it. In fact, I'm still somewhat inclined to revert it, just to have a working rc4 release later today. But I'm hoping maybe Ingo has time to test things (although I suspect he's already asleep). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2017-01-15 at 11:41 -0800, Linus Torvalds wrote: > On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley > <James.Bottomley@hansenpartnership.com> wrote: > > > > Can we compromise on "try not to revert a fix ...". > > No. > > It's about timing, and about how serious the regression is. > > For example, if this happened in rc7, I would have reverted > immediately. No questions asked. > > In this case, the "fix" was was also much less important then the > problem it caused. Some specialized pass-through command not working > right, vs a machine not even booting? There's just no question > what-so-ever. > > So the "fix" you claim just wasn't nearly important enough. It was > also pretty recent and clearly things had worked for _years_ without > it. > > In fact, I'm still somewhat inclined to revert it, just to have a > working rc4 release later today. But I'm hoping maybe Ingo has time > to test things (although I suspect he's already asleep). OK, so the patch to revert would actually be commit 669f044170d8933c3d66d231b69ea97cb8447338 Author: Bart Van Assche <bart.vanassche@sandisk.com> Date: Tue Nov 22 16:17:13 2016 -0800 scsi: srp_transport: Move queuecommand() wait code to SCSI core Because that change in the wait code broke the "fix" in mpt3sas. Before that was applied, it actually worked even though I think it's a wrong fix. James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2017-01-15 at 11:49 -0800, James Bottomley wrote: > On Sun, 2017-01-15 at 11:41 -0800, Linus Torvalds wrote: > > On Sun, Jan 15, 2017 at 11:13 AM, James Bottomley > > <James.Bottomley@hansenpartnership.com> wrote: > > > > > > Can we compromise on "try not to revert a fix ...". > > > > No. > > > > It's about timing, and about how serious the regression is. > > > > For example, if this happened in rc7, I would have reverted > > immediately. No questions asked. > > > > In this case, the "fix" was was also much less important then the > > problem it caused. Some specialized pass-through command not > > working > > right, vs a machine not even booting? There's just no question > > what-so-ever. > > > > So the "fix" you claim just wasn't nearly important enough. It was > > also pretty recent and clearly things had worked for _years_ > > without > > it. > > > > In fact, I'm still somewhat inclined to revert it, just to have a > > working rc4 release later today. But I'm hoping maybe Ingo has > > time > > to test things (although I suspect he's already asleep). > > OK, so the patch to revert would actually be > > commit 669f044170d8933c3d66d231b69ea97cb8447338 > Author: Bart Van Assche <bart.vanassche@sandisk.com> > Date: Tue Nov 22 16:17:13 2016 -0800 > > scsi: srp_transport: Move queuecommand() wait code to SCSI core > > Because that change in the wait code broke the "fix" in mpt3sas. > Before that was applied, it actually worked even though I think it's > a wrong fix. Hello James, I disagree. Even if my patch would be reverted that still wouldn't fix the severe race condition that was introduced in the mpt3sas driver by the patch that triggers the lockup during boot. As I explained two weeks ago (see also https://www.spinics.net/lists/kernel/msg2411413.htm l), commit 18f6084a989b ("scsi: mpt3sas: Fix secure erase premature termination") is the one that should be reverted instead of my patch. I agree with Linus that the offending mpt3sas patch already should have been reverted. Bart.
* James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote: > > So there's a new mpt3sas SCSI driver boot regression, introduced in > > this merge window, which made one of my servers unbootable. > > We're not reverting a fix that would cause regressions for others. You really need to reconsider that stance ... > However, The fix was manifestly wrong, so does this fix of the fix work for you: > > http://marc.info/?l=linux-scsi&m=148329237807604 > > It's been languishing a bit because no-one seemed to care enough to > test or review it. IOf you can add a tested by, that will give the two > we need to push it. I have tested your other patch that you pointed to: http://marc.info/?l=linux-scsi&m=148449968522828 Which patch fixes the bug too (I removed my revert first) - so you can add my: Reported-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> BTW., is it wise to work around the out of spec firmware in the mpt3sas code and leave the overly optimistic assumptions in the SCSI code intact? The problem is that other SCSI hardware could be affected as well - and especially enterprise class server hardware has long testing and thus regression latencies (as my example proves). Wouldn't it be more robust to only submit one pass-through command at a time from the SCSI layer, and maybe opt-in hardware that is known to implement the SAT standard fully? (But I'm just kibitzing here really.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2017-01-16 at 10:22 +0100, Ingo Molnar wrote: > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote: > > > So there's a new mpt3sas SCSI driver boot regression, introduced > > > in > > > this merge window, which made one of my servers unbootable. > > > > We're not reverting a fix that would cause regressions for others. > > You really need to reconsider that stance ... > > > However, The fix was manifestly wrong, so does this fix of the fix > > work for you: > > > > http://marc.info/?l=linux-scsi&m=148329237807604 > > > > It's been languishing a bit because no-one seemed to care enough to > > test or review it. IOf you can add a tested by, that will give the > > two > > we need to push it. > > I have tested your other patch that you pointed to: > > http://marc.info/?l=linux-scsi&m=148449968522828 > > Which patch fixes the bug too (I removed my revert first) - so you > can add my: > > Reported-by: Ingo Molnar <mingo@kernel.org> > Tested-by: Ingo Molnar <mingo@kernel.org> Thanks ... just checking you tested the second version with the concurrency part? > BTW., is it wise to work around the out of spec firmware in the > mpt3sas code and leave the overly optimistic assumptions in the SCSI > code intact? The problem is that other SCSI hardware could be > affected as well - and especially enterprise class server hardware > has long testing and thus regression latencies (as my example > proves). Realistically, there is no other card. Every other SAS implementation uses the in-kernel SAT, which does the right thing. We've suggested on a few occasions that the mpt SAS might like to use it as well, given we keep tripping on SAT problems in their firmware. > Wouldn't it be more robust to only submit one pass-through command at > a time from the SCSI layer, and maybe opt-in hardware that is known > to implement the SAT standard fully? Unfortunately it's a lot more complex: the standard gives a queueing mechanism for SAT pass through, so mostly you *can* have multiple commands outstanding, so it looks like we shouldn't globally restrict that. However, it seems the mpt3 firmware is using a queue single command model *and* not doing the right thing with return codes hence the failure. Since the failure mode is mpt3 specific, I think the best place for the fix is in their code. We can revisit this decision if something else comes along that also has this problem (UAS springs to mind). James > (But I'm just kibitzing here really.) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jan 15, 2017 at 10:02:51PM +0000, Bart Van Assche wrote: > I disagree. Even if my patch would be reverted that still wouldn't fix > the severe race condition that was introduced in the mpt3sas driver by > the patch that triggers the lockup during boot. As I explained two > weeks ago (see also https://www.spinics.net/lists/kernel/msg2411413.htm > l), commit 18f6084a989b ("scsi: mpt3sas: Fix secure erase premature > termination") is the one that should be reverted instead of my patch. I > agree with Linus that the offending mpt3sas patch already should have > been reverted. In addition to that ATA passthrough through scsi CDBs is a fringe feature compared to normal operation of the HBA. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2017-01-16 at 07:27 -0800, Christoph Hellwig wrote: > On Sun, Jan 15, 2017 at 10:02:51PM +0000, Bart Van Assche wrote: > > I disagree. Even if my patch would be reverted that still wouldn't > > fix the severe race condition that was introduced in the mpt3sas > > driver by the patch that triggers the lockup during boot. As I > > explained two weeks ago (see also > > https://www.spinics.net/lists/kernel/msg2411413.htm > > l), commit 18f6084a989b ("scsi: mpt3sas: Fix secure erase premature > > termination") is the one that should be reverted instead of my > > patch. I agree with Linus that the offending mpt3sas patch already > > should have been reverted. > > In addition to that ATA passthrough through scsi CDBs is a fringe > feature compared to normal operation of the HBA. So how about, instead of arguing about reversion, one or other of you reviews the proposed fix of the fix which would avoid having to revert anything? James -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Mon, 2017-01-16 at 10:22 +0100, Ingo Molnar wrote: > > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote: > > > > So there's a new mpt3sas SCSI driver boot regression, introduced > > > > in > > > > this merge window, which made one of my servers unbootable. > > > > > > We're not reverting a fix that would cause regressions for others. > > > > You really need to reconsider that stance ... > > > > > However, The fix was manifestly wrong, so does this fix of the fix > > > work for you: > > > > > > http://marc.info/?l=linux-scsi&m=148329237807604 > > > > > > It's been languishing a bit because no-one seemed to care enough to > > > test or review it. IOf you can add a tested by, that will give the > > > two > > > we need to push it. > > > > I have tested your other patch that you pointed to: > > > > http://marc.info/?l=linux-scsi&m=148449968522828 > > > > Which patch fixes the bug too (I removed my revert first) - so you > > can add my: > > > > Reported-by: Ingo Molnar <mingo@kernel.org> > > Tested-by: Ingo Molnar <mingo@kernel.org> > > Thanks ... just checking you tested the second version with the > concurrency part? I tested the one I linked to: http://marc.info/?l=linux-scsi&m=148449968522828 I don't know which version that is exactly, I just tested what you asked me to test. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 16, 2017 at 08:14:39AM -0800, James Bottomley wrote: > So how about, instead of arguing about reversion, one or other of you > reviews the proposed fix of the fix which would avoid having to revert > anything? As far as I can tell everyone is waiting for you to resend it with the review comment from the Broadcom maintainers adddressed. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
====================> From 0734e6d2a7f757172d6b7750d8fcf602909300e6 Mon Sep 17 00:00:00 2001 From: Ingo Molnar <mingo@kernel.org> Date: Sun, 15 Jan 2017 09:59:39 +0100 Subject: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination" This reverts commit 18f6084a989ba1b38702f9af37a2e4049a924be6. Conflicts: drivers/scsi/mpt3sas/mpt3sas_scsih.c Signed-off-by: Ingo Molnar <mingo@kernel.org> --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index b5c966e319d3..3573daa2cce8 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -4063,13 +4063,6 @@ scsih_qcmd(struct Scsi_Host *shost, struct scsi_cmnd *scmd) if (ioc->logging_level & MPT_DEBUG_SCSI) scsi_print_command(scmd); - /* - * Lock the device for any subsequent command until command is - * done. - */ - if (ata_12_16_cmd(scmd)) - scsi_internal_device_block(scmd->device); - sas_device_priv_data = scmd->device->hostdata; if (!sas_device_priv_data || !sas_device_priv_data->sas_target) { scmd->result = DID_NO_CONNECT << 16; @@ -4650,9 +4643,6 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply) if (scmd == NULL) return 1; - if (ata_12_16_cmd(scmd)) - scsi_internal_device_unblock(scmd->device, SDEV_RUNNING); - mpi_request = mpt3sas_base_get_msg_frame(ioc, smid); if (mpi_reply == NULL) {
So there's a new mpt3sas SCSI driver boot regression, introduced in this merge window, which made one of my servers unbootable. The kernel, starting at upstream commit a829a8445f09, would hang thusly: [ 6.230363] Linux agpgart interface v0.103 [ 6.245029] brd: module loaded [ 6.253233] loop: module loaded [ 6.256695] mpt3sas version 14.101.00.00 loaded [ 6.261890] mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (65950628 kB) [ 6.326222] mpt2sas_cm0: MSI-X vectors supported: 1, no of cores: 32, max_msix_vectors: -1 [ 6.334953] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 24 [ 6.340237] mpt2sas_cm0: iomem(0x00000000dff3c000), mapped(0xffffc90007414000), size(16384) [ 6.349002] mpt2sas_cm0: ioport(0x000000000000e000), size(256) [ 6.410830] mpt2sas_cm0: sending message unit reset !! [ 6.417739] mpt2sas_cm0: message unit reset: SUCCESS [ 6.463486] mpt2sas_cm0: Allocated physical memory: size(8199 kB) [ 6.469820] mpt2sas_cm0: Current Controller Queue Depth(3640),Max Controller Queue Depth(3712) [ 6.478840] mpt2sas_cm0: Scatter Gather Elements per IO(128) [ 6.530653] mpt2sas_cm0: LSISAS2008: FWVersion(12.00.00.00), ChipRevision(0x03), BiosVersion(07.23.01.00) [ 6.540621] mpt2sas_cm0: Protocol=( [ 6.540622] Initiator [ 6.544346] ,Target [ 6.546844] ), [ 6.549168] Capabilities=( [ 6.551165] TLR [ 6.554098] ,EEDP [ 6.556095] ,Snapshot Buffer [ 6.558249] ,Diag Trace Buffer [ 6.561359] ,Task Set Full [ 6.564666] ,NCQ [ 6.567594] ) [ 6.571517] scsi host0: Fusion MPT SAS Host [ 6.576539] mpt2sas_cm0: sending port enable !! [ 6.576699] ahci 0000:00:11.0: version 3.0 [ 6.577285] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode [ 6.577290] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc [ 6.579218] scsi host1: ahci [ 6.579685] scsi host2: ahci [ 6.5800[ 39.972084] sd 0:0:0:0: attempting task abort! scmd(ffff881014cb9500) [ 39.978809] sd 0:0:0:0: [sda] tag#0 CDB: ATA command pass through(12)/Blank a1 08 2e 00 01 00 00 00 00 ec 00 00 [ 39.989346] scsi target0:0:0: handle(0x0009), sas_address(0x4433221100000000), phy(0) [ 39.997584] scsi target0:0:0: enclosure_logical_id(0x5003048003e10c00), slot(31) [ 40.005425] sd 0:0:0:0: task abort: SUCCESS scmd(ffff881014cb9500) udevd[472]: timeout 'ata_id --export /dev/sda' udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] udevd[472]: timeout: killing 'ata_id --export /dev/sda' [503] [ this would continue ad infinitum. ] The correct bootup sequence would be: [ 6.252918] loop: module loaded [ 6.256390] mpt3sas version 14.101.00.00 loaded [ 6.261554] mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (65950628 kB) [ 6.325894] mpt2sas_cm0: MSI-X vectors supported: 1, no of cores: 32, max_msix_vectors: -1 [ 6.334640] mpt2sas0-msix0: PCI-MSI-X enabled: IRQ 24 [ 6.339925] mpt2sas_cm0: iomem(0x00000000dff3c000), mapped(0xffffc900073f4000), size(16384) [ 6.348672] mpt2sas_cm0: ioport(0x000000000000e000), size(256) [ 6.410508] mpt2sas_cm0: sending message unit reset !! [ 6.417437] mpt2sas_cm0: message unit reset: SUCCESS [ 6.463275] mpt2sas_cm0: Allocated physical memory: size(8199 kB) [ 6.469627] mpt2sas_cm0: Current Controller Queue Depth(3640),Max Controller Queue Depth(3712) [ 6.478635] mpt2sas_cm0: Scatter Gather Elements per IO(128) [ 6.530433] mpt2sas_cm0: LSISAS2008: FWVersion(12.00.00.00), ChipRevision(0x03), BiosVersion(07.23.01.00) [ 6.540424] mpt2sas_cm0: Protocol=( [ 6.540425] Initiator [ 6.544150] ,Target [ 6.546644] ), [ 6.548968] Capabilities=( [ 6.550943] TLR [ 6.553901] ,EEDP [ 6.555898] ,Snapshot Buffer [ 6.558050] ,Diag Trace Buffer [ 6.561159] ,Task Set Full [ 6.564462] ,NCQ [ 6.567395] ) [ 6.571316] scsi host0: Fusion MPT SAS Host [ 6.576344] mpt2sas_cm0: sending port enable !! [ 6.576495] ahci 0000:00:11.0: version 3.0 [ 6.577100] ahci 0000:00:11.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode [ 6.577105] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc [ 6.579016] scsi host1: ahci [ 6.579387] scsi host2: ahci [ 6.[ [32m OK [0m] Started Journal Service. ... (BTW., note the various broken printk lines - which is an unrelated bug.) I bisected the regression back to this upstream merge commit done by Linus: commit a829a8445f09036404060f4d6489cb13433f4304 Merge: 84b607913442 f5b893c94715 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Wed Dec 14 10:49:33 2016 -0800 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi ... which is a head-scratcher, so I double checked the key bisection points, but the bisection result is robust. I also re-created Linus's merge and double checked the conflict resolution - which looks fine as well. After (much) more testing it turns out that the bug is some sort of combination bug, in that scsi-next didn't have all the SCSI fixes that upstream already had, in particular it didn't have these commits: 7ff723ad0f87 scsi: mpt3sas: Unblock device after controller reset 18f6084a989b scsi: mpt3sas: Fix secure erase premature termination 6d3a56ed0985 scsi: mpt3sas: Fix for block device of raid exists even after deleting raid disk When Linus pulled in scsi-next-minus-fixes these two sets of commits combined and produced the regression - and made the bisection lead to the merge commit. So I manually rebased those 3 fixes on top of the scsi-next tree (f5b893c94715) and indeed one of them broke my box: 18f6084a989b scsi: mpt3sas: Fix secure erase premature termination I reverted it from latest upstream (with a minor conflict resolution), and that makes my box boot fine again. I have no idea which scsi-next commit this change interacted with, and it's not easy to find out so I'm not volunteering! It must be one of these 256 commits: e3a00f68e426..f5b893c94715 Note that reverting the first commit alone does not help: 7ff723ad0f87 scsi: mpt3sas: Unblock device after controller reset So it's reverting 18f6084a989b (while keeping ata_12_16_cmd() around to enable the 7ff723ad0f87 fix) that does the trick. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html