mpt fusion error handler patches
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest4 patches 9 repliesIn review
- v15 patches 3 repliesSuperseded
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | mpt fusion SoftReset handlerdrivers/ drivers/ drivers/ +2 more | +218 | 3 replies | |
| 1/4 | mpt fusion disable hard resets for 53C1030 based devicesdrivers/ drivers/ | +72 | 3 replies | |
| 3/4 | mpt fusion prevent DV deadlockdrivers/ | +12 | 2 replies | |
| 4/4 | Increase scsi timeoutsdrivers/ | +1 | 1 reply |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH 0/4 V2] mpt fusion error handler patches
Hello,
here is version 2 of the patches, version 1 may be found here:
http://kerneltrap.org/mailarchive/linux-scsi/2008/9/12/3279954
In difference to the previous series I skipped the removal of mptscsih_TMHandler(), since it actually does the right thing, it only cause the HardReset function to be activated, which caused the real trouble.
I also made the soft/hard reset calls into one main call. From this main call it is then also generally possible to avoid calling the hard reset handler.
There is still one issue left, while in the 4.x series of the driver the mptscsih_IssueTaskMgmt() succeeds for task aborts, this still fails in the in kernel version. My guess is the this is related to the completion calls. While the in-kernel driver uses mptscsih_tm_wait_for_completion(), the 4.x series uses just like the in kernel mptsas the generic wait_for_completion_timeout() handler.
But switching to that actually means a lot of work. Without to be sure this is really the cause of the trouble, I won't spend my time on it.
Cheers,
Bernd
Signature · 2 lines
Bernd Schubert Q-Leap Networks GmbH