Pretty sure that's it. -12 is -ENOMEM, and there are two sites in that commit that return -ENOMEM, right when we have an error message from the failure to spawn the SCSI error handler thread.
Note that the oops/backtrace is a red herring. There is a secondary, unrelated bug in the mptsas code that is triggered by this untested codepath: when scsi_host_alloc fails to allocate (and hence eventually set ioc->sh), "Unable to register controller with SCSI subsystem" is printed (which we see), then it jumps to out_mptsas_probe where mptscsih_remove() is called; however, mptscsih_remove() tries to scsi_remove_host(host), but host = ioc->sh & ioc->sh == NULL, as it was the reason we ended up here. The solution for this -again, unrelated- bug would be to have a different label for early failures that won't call mptscsih_remove(). I'll prepare a patch for this and submit it to linux-scsi shortly.
The real issue of this bug is why the kthread spawning fails; I haven't figured that out yet.
Pretty sure that's it. -12 is -ENOMEM, and there are two sites in that commit that return -ENOMEM, right when we have an error message from the failure to spawn the SCSI error handler thread.
Note that the oops/backtrace is a red herring. There is a secondary, unrelated bug in the mptsas code that is triggered by this untested codepath: when scsi_host_alloc fails to allocate (and hence eventually set ioc->sh), "Unable to register controller with SCSI subsystem" is printed (which we see), then it jumps to out_mptsas_probe where mptscsih_remove() is called; however, mptscsih_remove() tries to scsi_remove_ host(host) , but host = ioc->sh & ioc->sh == NULL, as it was the reason we ended up here. The solution for this -again, unrelated- bug would be to have a different label for early failures that won't call mptscsih_remove(). I'll prepare a patch for this and submit it to linux-scsi shortly.
The real issue of this bug is why the kthread spawning fails; I haven't figured that out yet.