From: Don Brace <don.brace@microchip.com>
To: <don.brace@microchip.com>, <scott.teel@microchip.com>,
<Justin.Lindley@microchip.com>, <scott.benesh@microchip.com>,
<gerry.morong@microchip.com>, <mahesh.rajashekhara@microchip.com>,
<mike.mcgowen@microchip.com>, <murthy.bhat@microchip.com>,
<kumar.meiyappan@microchip.com>, <jeremy.reeves@microchip.com>,
<david.strahan@microchip.com>, <hch@infradead.org>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Martin Petersen <martin.petersen@oracle.com>,
<joseph.szczypek@hpe.com>, <POSWALD@suse.com>
Cc: <linux-scsi@vger.kernel.org>
Subject: [PATCH 0/7] smartpqi updates
Date: Tue, 27 Aug 2024 13:54:54 -0500 [thread overview]
Message-ID: <20240827185501.692804-1-don.brace@microchip.com> (raw)
These patches are based on Martin Petersen's 6.12/scsi-queue tree
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
6.12/scsi-queue
There are two functional changes:
smartpqi-add-fw-log-to-kdump
smartpqi-add-counter-for-parity-write-stream-requests
There are three minor bug fixes:
smartpqi-fix-stream-detection
smartpqi-fix-rare-system-hang-during-LUN-reset
smartpqi-fix-volume-size-updates
The other two patches add PCI-IDs for new controllers and change the
driver version.
This set of changes consists of:
* smartpqi-add-fw-log-to-kdump
During a kdump, the driver tells the controller to copy its logging information to some
pre-allocated buffers that can be analyzed later.
This is a "feature" driven capability and is backward compatible with existing controller FW.
This patch renames some prefixes for OFA (Online-Firmware Activation ofa_*) buffers
to host_memory_*. So, not a lot of actual functional changes to smartpqi_init.c,
mainly determining the memory size allocation.
We added a function to notify the controller to copy debug data into host memory before
continuing kdump.
Most of the functional changes are in smartpqi_sis.c where the actual handshaking is done.
* smartpqi-fix-stream-detection
Correct some false write-stream detections. The data structure used to check for write-streams
was not initialized to all 0's causing some false write stream detections. The driver sends
down streamed requests to the raid engine instead of using AIO bypass for some extra performance.
(Potential full-stripe write verses Read Modify Write).
False detections have not caused any data corruption.
Found by internal testing. No known externally reported bugs.
* smartpqi-add-counter-for-parity-write-stream-requests
Adding some counters for raid_bypass and write streams. These two counters are related
because write stream detection is only checked if an I/O request is eligible for bypass (AIO).
The bypass counter (raid_bypass_cnt) was moved into a common structure (pqi_raid_io_stats) and
changed to type __percpu. The write stream counter is (write_stream_cnt) has been added to
this same structure.
These counters are __percpu counters for performance. We added a sysfs entry to show the
write stream count. The raid bypass counter sysfs entry already exists.
Useful for checking streaming writes. The change in the sysfs entry write_stream_cnt can be
checked during AIO eligible write operations.
* smartpqi-add-new-controller-PCI-IDs
Adding support for new controller HW.
No functional changes.
* smartpqi-fix-rare-system-hang-during-LUN-reset
We found a rare race condition that can occur during a LUN reset. We were not emptying
our internal queue completely.
There have been some rare conditions where our internal request queue has requests for
multiple LUNs and a reset comes in for one of the LUNs. The driver waits for this internal
queue to empty. We were only clearing out the requests for the LUN being reset so the
request queue was never empty causing a hang.
The Fix:
For all requests in our internal request queue:
Complete requests with DID_RESET for queued requests for the device undergoing a reset.
Complete requests with DID_REQUEUE for all other queued requests.
Found by internal testing. No known externally reported bugs.
* smartpqi-fix-volume-size-updates
The current code only checks for a size change if there is also a queue depth change.
We are separating the check for queue depth and the size changes.
Found by internal testing. No known bugs were filed.
* smartpqi-update-version-to-2.1.30-031
No functional changes.
---
David Strahan (1):
smartpqi: add new controller PCI IDs
Don Brace (2):
smartpqi: fix volume size updates
smartpqi: update driver version to 2.1.30-031
Mahesh Rajashekhara (2):
smartpqi: correct stream detection
smartpqi: add counter for parity write stream requests
Murthy Bhat (2):
smartpqi: Add fw log to kdump
smartpqi: fix rare system hang during LUN reset
drivers/scsi/smartpqi/smartpqi.h | 39 ++-
drivers/scsi/smartpqi/smartpqi_init.c | 352 +++++++++++++++++---------
drivers/scsi/smartpqi/smartpqi_sis.c | 60 +++++
drivers/scsi/smartpqi/smartpqi_sis.h | 3 +
4 files changed, 322 insertions(+), 132 deletions(-)
--
2.46.0.421.g159f2d50e7
next reply other threads:[~2024-08-27 18:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 18:54 Don Brace [this message]
2024-08-27 18:54 ` [PATCH 1/7] smartpqi: Add fw log to kdump Don Brace
2024-08-27 18:54 ` [PATCH 2/7] smartpqi: correct stream detection Don Brace
2024-08-27 18:54 ` [PATCH 3/7] smartpqi: add counter for parity write stream requests Don Brace
2024-08-27 18:54 ` [PATCH 4/7] smartpqi: add new controller PCI IDs Don Brace
2024-08-27 18:54 ` [PATCH 5/7] smartpqi: fix rare system hang during LUN reset Don Brace
2024-08-27 18:55 ` [PATCH 6/7] smartpqi: fix volume size updates Don Brace
2024-08-27 18:55 ` [PATCH 7/7] smartpqi: update driver version to 2.1.30-031 Don Brace
2024-08-29 2:18 ` [PATCH 0/7] smartpqi updates Martin K. Petersen
-- strict thread matches above, loose matches on Subject: below --
2020-07-31 21:01 Don Brace
2020-08-12 20:03 ` Martin Wilck
2020-08-13 2:50 ` Martin K. Petersen
2020-08-18 3:11 ` Martin K. Petersen
2017-08-10 18:46 Don Brace
2017-08-11 0:00 ` Martin K. Petersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240827185501.692804-1-don.brace@microchip.com \
--to=don.brace@microchip.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Justin.Lindley@microchip.com \
--cc=POSWALD@suse.com \
--cc=david.strahan@microchip.com \
--cc=gerry.morong@microchip.com \
--cc=hch@infradead.org \
--cc=jeremy.reeves@microchip.com \
--cc=joseph.szczypek@hpe.com \
--cc=kumar.meiyappan@microchip.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mahesh.rajashekhara@microchip.com \
--cc=martin.petersen@oracle.com \
--cc=mike.mcgowen@microchip.com \
--cc=murthy.bhat@microchip.com \
--cc=scott.benesh@microchip.com \
--cc=scott.teel@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox