#
05500a48 |
| 26-Aug-2024 |
Keith Busch <kbusch@kernel.org> |
nvme-pci: allocate tagset on reset if necessary
[ Upstream commit 6f01bdbfef3b62955cf6503a8425d527b3a5cf94 ]
If a drive is unable to create IO queues on the initial probe, a subsequent reset will n
nvme-pci: allocate tagset on reset if necessary
[ Upstream commit 6f01bdbfef3b62955cf6503a8425d527b3a5cf94 ]
If a drive is unable to create IO queues on the initial probe, a subsequent reset will need to allocate the tagset if IO queue creation is successful. Without this, blk_mq_update_nr_hw_queues will crash on a bad pointer due to the invalid tagset.
Fixes: eac3ef262941f62 ("nvme-pci: split the initial probe from the rest path") Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
77ee2eae |
| 27-Aug-2024 |
Georg Gottleuber <ggo@tuxedocomputers.com> |
nvme-pci: Add sleep quirk for Samsung 990 Evo
commit 61aa894e7a2fda4ee026523b01d07e83ce2abb72 upstream.
On some TUXEDO platforms, a Samsung 990 Evo NVMe leads to a high power consumption in s2idle
nvme-pci: Add sleep quirk for Samsung 990 Evo
commit 61aa894e7a2fda4ee026523b01d07e83ce2abb72 upstream.
On some TUXEDO platforms, a Samsung 990 Evo NVMe leads to a high power consumption in s2idle sleep (2-3 watts).
This patch applies 'Force No Simple Suspend' quirk to achieve a sleep with a lower power consumption, typically around 0.5 watts.
Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Cc: <stable@vger.kernel.org> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
a47b5484 |
| 15-Jul-2024 |
WangYuli <wangyuli@uniontech.com> |
nvme/pci: Add APST quirk for Lenovo N60z laptop
commit ab091ec536cb7b271983c0c063b17f62f3591583 upstream.
There is a hardware power-saving problem with the Lenovo N60z board. When turn it on and le
nvme/pci: Add APST quirk for Lenovo N60z laptop
commit ab091ec536cb7b271983c0c063b17f62f3591583 upstream.
There is a hardware power-saving problem with the Lenovo N60z board. When turn it on and leave it for 10 hours, there is a 20% chance that a nvme disk will not wake up until reboot.
Link: https://lore.kernel.org/all/2B5581C46AC6E335+9c7a81f1-05fb-4fd0-9fbb-108757c21628@uniontech.com Signed-off-by: hmy <huanglin@uniontech.com> Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Signed-off-by: WangYuli <wangyuli@uniontech.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
c63b44fb |
| 27-May-2024 |
Mikulas Patocka <mpatocka@redhat.com> |
block: change rq_integrity_vec to respect the iterator
[ Upstream commit cf546dd289e0f6d2594c25e2fb4e19ee67c6d988 ]
If we allocate a bio that is larger than NVMe maximum request size, attach integr
block: change rq_integrity_vec to respect the iterator
[ Upstream commit cf546dd289e0f6d2594c25e2fb4e19ee67c6d988 ]
If we allocate a bio that is larger than NVMe maximum request size, attach integrity metadata to it and send it to the NVMe subsystem, the integrity metadata will be corrupted.
Splitting the bio works correctly. The function bio_split will clone the bio, trim the iterator of the first bio and advance the iterator of the second bio.
However, the function rq_integrity_vec has a bug - it returns the first vector of the bio's metadata and completely disregards the metadata iterator that was advanced when the bio was split. Thus, the second bio uses the same metadata as the first bio and this leads to metadata corruption.
This commit changes rq_integrity_vec, so that it calls mp_bvec_iter_bvec instead of returning the first vector. mp_bvec_iter_bvec reads the iterator and uses it to build a bvec for the current position in the iterator.
The "queue_max_integrity_segments(rq->q) > 1" check was removed, because the updated rq_integrity_vec function works correctly with multiple segments.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reviewed-by: Anuj Gupta <anuj20.g@samsung.com> Reviewed-by: Kanchan Joshi <joshi.k@samsung.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/49d1afaa-f934-6ed2-a678-e0d428c63a65@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
77848b37 |
| 24-Jul-2024 |
Leon Romanovsky <leonro@nvidia.com> |
nvme-pci: add missing condition check for existence of mapped data
[ Upstream commit c31fad1470389666ac7169fe43aa65bf5b7e2cfd ]
nvme_map_data() is called when request has physical segments, hence t
nvme-pci: add missing condition check for existence of mapped data
[ Upstream commit c31fad1470389666ac7169fe43aa65bf5b7e2cfd ]
nvme_map_data() is called when request has physical segments, hence the nvme_unmap_data() should have same condition to avoid dereference.
Fixes: 4aedb705437f ("nvme-pci: split metadata handling from nvme_map_data / nvme_unmap_data") Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Nitesh Shetty <nj.shetty@samsung.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
8772be96 |
| 11-Jul-2024 |
Bart Van Assche <bvanassche@acm.org> |
nvme-pci: Fix the instructions for disabling power management
[ Upstream commit 92fc2c469eb26060384e9b2cd4cb0cc228aba582 ]
pcie_aspm=off tells the kernel not to modify the ASPM configuration. This
nvme-pci: Fix the instructions for disabling power management
[ Upstream commit 92fc2c469eb26060384e9b2cd4cb0cc228aba582 ]
pcie_aspm=off tells the kernel not to modify the ASPM configuration. This setting does not guarantee that ASPM (Active State Power Management) is disabled. Hence add pcie_port_pm=off. This disables power management for all PCIe ports.
This patch has been tested on a workstation with a Samsung SSD 970 EVO Plus NVMe SSD.
Fixes: 4641a8e6e145 ("nvme-pci: add trouble shooting steps for timeouts") Cc: Keith Busch <kbusch@kernel.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
b955b479 |
| 23-May-2024 |
Kundan Kumar <kundan.kumar@samsung.com> |
nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset
[ Upstream commit 1bd293fcf3af84674e82ed022c049491f3768840 ]
bio_vec start offset may be relatively large particularly when large folio gets
nvme: adjust multiples of NVME_CTRL_PAGE_SIZE in offset
[ Upstream commit 1bd293fcf3af84674e82ed022c049491f3768840 ]
bio_vec start offset may be relatively large particularly when large folio gets added to the bio. A bigger offset will result in avoiding the single-segment mapping optimization and end up using expensive mempool_alloc further.
Rather than using absolute value, adjust bv_offset by NVME_CTRL_PAGE_SIZE while checking if segment can be fitted into one/two PRP entries.
Suggested-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Kundan Kumar <kundan.kumar@samsung.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
b6eaa53f |
| 25-Apr-2024 |
Nilay Shroff <nilay@linux.ibm.com> |
nvme: cancel pending I/O if nvme controller is in terminal state
[ Upstream commit 25bb3534ee21e39eb9301c4edd7182eb83cb0d07 ]
While I/O is running, if the pci bus error occurs then in-flight I/O ca
nvme: cancel pending I/O if nvme controller is in terminal state
[ Upstream commit 25bb3534ee21e39eb9301c4edd7182eb83cb0d07 ]
While I/O is running, if the pci bus error occurs then in-flight I/O can not complete. Worst, if at this time, user (logically) hot-unplug the nvme disk then the nvme_remove() code path can't forward progress until in-flight I/O is cancelled. So these sequence of events may potentially hang hot-unplug code path indefinitely. This patch helps cancel the pending/in-flight I/O from the nvme request timeout handler in case the nvme controller is in the terminal (DEAD/DELETING/DELETING_NOIO) state and that helps nvme_remove() code path forward progress and finish successfully.
Link: https://lore.kernel.org/all/199be893-5dfa-41e5-b6f2-40ac90ebccc4@linux.ibm.com/ Signed-off-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
a2da0e5c |
| 22-Apr-2024 |
Sean Anderson <sean.anderson@linux.dev> |
nvme-pci: Add quirk for broken MSIs
commit d5887dc6b6c054d0da3cd053afc15b7be1f45ff6 upstream.
Sandisk SN530 NVMe drives have broken MSIs. On systems without MSI-X support, all commands time out res
nvme-pci: Add quirk for broken MSIs
commit d5887dc6b6c054d0da3cd053afc15b7be1f45ff6 upstream.
Sandisk SN530 NVMe drives have broken MSIs. On systems without MSI-X support, all commands time out resulting in the following message:
nvme nvme0: I/O tag 12 (100c) QID 0 timeout, completion polled
These timeouts cause the boot to take an excessively-long time (over 20 minutes) while the initial command queue is flushed.
Address this by adding a quirk for drives with buggy MSIs. The lspci output for this device (recorded on a system with MSI-X support) is:
02:00.0 Non-Volatile memory controller: Sandisk Corp Device 5008 (rev 01) (prog-if 02 [NVM Express]) Subsystem: Sandisk Corp Device 5008 Flags: bus master, fast devsel, latency 0, IRQ 16, NUMA node 0 Memory at f7e00000 (64-bit, non-prefetchable) [size=16K] Memory at f7e04000 (64-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable- Count=1/32 Maskable- 64bit+ Capabilities: [b0] MSI-X: Enable+ Count=17 Masked- Capabilities: [c0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [150] Device Serial Number 00-00-00-00-00-00-00-00 Capabilities: [1b8] Latency Tolerance Reporting Capabilities: [300] Secondary PCI Express Capabilities: [900] L1 PM Substates Kernel driver in use: nvme Kernel modules: nvme
Cc: <stable@vger.kernel.org> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
5e11bacf |
| 15-Mar-2024 |
Jiawei Fu (iBug) <i@ibugone.com> |
drivers/nvme: Add quirks for device 126f:2262
[ Upstream commit e89086c43f0500bc7c4ce225495b73b8ce234c1f ]
This commit adds NVME_QUIRK_NO_DEEPEST_PS and NVME_QUIRK_BOGUS_NID for device [126f:2262],
drivers/nvme: Add quirks for device 126f:2262
[ Upstream commit e89086c43f0500bc7c4ce225495b73b8ce234c1f ]
This commit adds NVME_QUIRK_NO_DEEPEST_PS and NVME_QUIRK_BOGUS_NID for device [126f:2262], which appears to be a generic VID:PID pair used for many SSDs based on the Silicon Motion SM2262/SM2262EN controller.
Two of my SSDs with this VID:PID pair exhibit the same behavior:
* They frequently have trouble exiting the deepest power state (5), resulting in the entire disk unresponsive. Verified by setting nvme_core.default_ps_max_latency_us=10000 and observing them behaving normally. * They produce all-zero nguid and eui64 with `nvme id-ns` command.
The offending products are:
* HP SSD EX950 1TB * HIKVISION C2000Pro 2TB
Signed-off-by: Jiawei Fu <i@ibugone.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
8884a56d |
| 27-Oct-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: ensure reset state check ordering
[ Upstream commit e6e7f7ac03e40795346f1b2994a05f507ad8d345 ]
A different CPU may be setting the ctrl->state value, so ensure proper barriers to prevent optim
nvme: ensure reset state check ordering
[ Upstream commit e6e7f7ac03e40795346f1b2994a05f507ad8d345 ]
A different CPU may be setting the ctrl->state value, so ensure proper barriers to prevent optimizing to a stale state. Normally it isn't a problem to observe the wrong state as it is merely advisory to take a quicker path during initialization and error recovery, but seeing an old state can report unexpected ENETRESET errors when a reset request was in fact successful.
Reported-by: Minh Hoang <mh2022@meta.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
dd864f6e |
| 20-Sep-2023 |
Georg Gottleuber <ggo@tuxedocomputers.com> |
nvme-pci: Add sleep quirk for Kingston drives
commit 107b4e063d78c300b21e2d5291b1aa94c514ea5b upstream.
Some Kingston NV1 and A2000 are wasting a lot of power on specific TUXEDO platforms in s2idle
nvme-pci: Add sleep quirk for Kingston drives
commit 107b4e063d78c300b21e2d5291b1aa94c514ea5b upstream.
Some Kingston NV1 and A2000 are wasting a lot of power on specific TUXEDO platforms in s2idle sleep if 'Simple Suspend' is used.
This patch applies a new quirk 'Force No Simple Suspend' to achieve a low power sleep without 'Simple Suspend'.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com> Cc: <stable@vger.kernel.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
5c3f4066 |
| 12-Oct-2023 |
Keith Busch <kbusch@kernel.org> |
nvme-pci: add BOGUS_NID for Intel 0a54 device
These ones claim cmic and nmic capable, so need special consideration to ignore their duplicate identifiers.
Link: https://bugzilla.kernel.org/show_bug
nvme-pci: add BOGUS_NID for Intel 0a54 device
These ones claim cmic and nmic capable, so need special consideration to ignore their duplicate identifiers.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217981 Reported-by: welsh@cassens.com Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
dad651b2 |
| 12-Sep-2023 |
Pratyush Yadav <ptyadav@amazon.de> |
nvme-pci: do not set the NUMA node of device if it has none
If a device has no NUMA node information associated with it, the driver puts the device in node first_memory_node (say node 0). Not having
nvme-pci: do not set the NUMA node of device if it has none
If a device has no NUMA node information associated with it, the driver puts the device in node first_memory_node (say node 0). Not having a NUMA node and being associated with node 0 are completely different things and it makes little sense to mix the two.
Signed-off-by: Pratyush Yadav <ptyadav@amazon.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
688b419c |
| 16-Nov-2022 |
August Wikerfors <git@augustwikerfors.se> |
nvme-pci: add NVME_QUIRK_BOGUS_NID for Samsung PM9B1 256G and 512G
The Samsung PM9B1 512G SSD found in some Lenovo Yoga 7 14ARB7 laptop units reports eui as 0001000200030004 when resuming from s2idl
nvme-pci: add NVME_QUIRK_BOGUS_NID for Samsung PM9B1 256G and 512G
The Samsung PM9B1 512G SSD found in some Lenovo Yoga 7 14ARB7 laptop units reports eui as 0001000200030004 when resuming from s2idle, causing the device to be removed with this error in dmesg:
nvme nvme0: identifiers changed for nsid 1
To fix this, add a quirk to ignore namespace identifiers for this device.
Signed-off-by: August Wikerfors <git@augustwikerfors.se> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
b8f6446b |
| 13-Jul-2023 |
Ming Lei <ming.lei@redhat.com> |
nvme-pci: fix DMA direction of unmapping integrity data
DMA direction should be taken in dma_unmap_page() for unmapping integrity data.
Fix this DMA direction, and reported in Guangwu's test.
Repo
nvme-pci: fix DMA direction of unmapping integrity data
DMA direction should be taken in dma_unmap_page() for unmapping integrity data.
Fix this DMA direction, and reported in Guangwu's test.
Reported-by: Guangwu Zhang <guazhang@redhat.com> Fixes: 4aedb705437f ("nvme-pci: split metadata handling from nvme_map_data / nvme_unmap_data") Signed-off-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
71a5bb15 |
| 12-Jul-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: ensure disabling pairs with unquiesce
If any error handling that disables the controller fails to queue the reset work, like if the state changed to disconnected inbetween, then the failed tea
nvme: ensure disabling pairs with unquiesce
If any error handling that disables the controller fails to queue the reset work, like if the state changed to disconnected inbetween, then the failed teardown needs to unquiesce the queues since it's no longer paired with reset_work. Just make sure that the controller can be put into a resetting state prior to starting the disable so that no other handling can change the queue states while recovery is happening.
Reported-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
e5bb0988 |
| 04-Jul-2023 |
Pankaj Raghav <p.raghav@samsung.com> |
nvme: add BOGUS_NID quirk for Samsung SM953
Add the quirk as SM953 is reporting bogus namespace ID.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217593 Reported-by: Clemens Springsguth <csprin
nvme: add BOGUS_NID quirk for Samsung SM953
Add the quirk as SM953 is reporting bogus namespace ID.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217593 Reported-by: Clemens Springsguth <cspringsguth@gmail.com> Tested-by: Clemens Springsguth <cspringsguth@gmail.com> Signed-off-by: Pankaj Raghav <p.raghav@samsung.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
4e69d4da |
| 28-Jun-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: disable controller on reset state failure
If the controller is not in a RESETTING state at the point of reset work, we have to conclude the controller is being deleted. Go to the cleanup on th
nvme: disable controller on reset state failure
If the controller is not in a RESETTING state at the point of reset work, we have to conclude the controller is being deleted. Go to the cleanup on this condition to ensure proper pairing of request_queue quiesce state.
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
a2b5d544 |
| 28-Jun-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: sync timeout work on failed reset
Timeouts during reset will set the controller for failure, preventing the state change to LIVE. Ensure all timeout work is synced after the controller disabli
nvme: sync timeout work on failed reset
Timeouts during reset will set the controller for failure, preventing the state change to LIVE. Ensure all timeout work is synced after the controller disabling completes to ensure we don't have any other tasks messing with any namespace request_queue's.
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
2ab4e5f4 |
| 28-Jun-2023 |
Keith Busch <kbusch@kernel.org> |
nvme: ensure unquiesce on teardown
The reset work is called on quiesced IO queues, so ensure these are unquiesced after a failed reset to flush out any pending requests.
Reviewed-by: Christoph Hell
nvme: ensure unquiesce on teardown
The reset work is called on quiesced IO queues, so ensure these are unquiesced after a failed reset to flush out any pending requests.
Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
4a4d9bc0 |
| 12-May-2023 |
Irvin Cote <irvincoteg@gmail.com> |
nvme-pci: cleaning up nvme_pci_init_request
Erase the superfluous line that retrieves the nvme_dev.
Signed-off-by: Irvin Cote <irvincoteg@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Sign
nvme-pci: cleaning up nvme_pci_init_request
Erase the superfluous line that retrieves the nvme_dev.
Signed-off-by: Irvin Cote <irvincoteg@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
a3a9d63d |
| 20-May-2023 |
Tatsuki Sugiura <sugi@nemui.org> |
NVMe: Add MAXIO 1602 to bogus nid list.
HIKSEMI FUTURE M.2 SSD uses the same dummy nguid and eui64. I confirmed it with my two devices.
This patch marks the controller as NVME_QUIRK_BOGUS_NID.
---
NVMe: Add MAXIO 1602 to bogus nid list.
HIKSEMI FUTURE M.2 SSD uses the same dummy nguid and eui64. I confirmed it with my two devices.
This patch marks the controller as NVME_QUIRK_BOGUS_NID.
--------------------------------------------------------- sugi@tempest:~% sudo nvme id-ctrl /dev/nvme0 NVME Identify Controller: vid : 0x1e4b ssvid : 0x1e4b sn : 30096022612 mn : HS-SSD-FUTURE 2048G fr : SN10542 rab : 0 ieee : 000000 cmic : 0 mdts : 7 cntlid : 0 ver : 0x10400 rtd3r : 0x7a120 rtd3e : 0x1e8480 oaes : 0x200 ctratt : 0x2 rrls : 0 cntrltype : 1 fguid : 00000000-0000-0000-0000-000000000000 <snip...> ---------------------------------------------------------
--------------------------------------------------------- sugi@tempest:~% sudo nvme id-ns /dev/nvme0n1 NVME Identify Namespace 1: <snip...> nguid : 00000000000000000000000000000000 eui64 : 0000000000000002 lbaf 0 : ms:0 lbads:9 rp:0 (in use) ---------------------------------------------------------
Signed-off-by: Tatsuki Sugiura <sugi@nemui.org> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
06497281 |
| 17-May-2023 |
Daniel Smith <dansmith@ds.gy> |
nvme-pci: Add quirk for Teamgroup MP33 SSD
Add a quirk for Teamgroup MP33 that reports duplicate ids for disk.
Signed-off-by: Daniel Smith <dansmith@ds.gy> [kch: patch formatting] Signed-off-by: Ch
nvme-pci: Add quirk for Teamgroup MP33 SSD
Add a quirk for Teamgroup MP33 that reports duplicate ids for disk.
Signed-off-by: Daniel Smith <dansmith@ds.gy> [kch: patch formatting] Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com> Tested-by: Daniel Smith <dansmith@ds.gy> Signed-off-by: Keith Busch <kbusch@kernel.org>
show more ...
|
#
3710e2b0 |
| 21-Apr-2023 |
Adrian Huang <ahuang12@lenovo.com> |
nvme-pci: clamp max_hw_sectors based on DMA optimized limitation
When running the fio test on a 448-core AMD server + a NVME disk, a soft lockup or a hard lockup call trace is shown:
[soft lockup]
nvme-pci: clamp max_hw_sectors based on DMA optimized limitation
When running the fio test on a 448-core AMD server + a NVME disk, a soft lockup or a hard lockup call trace is shown:
[soft lockup] watchdog: BUG: soft lockup - CPU#126 stuck for 23s! [swapper/126:0] RIP: 0010:_raw_spin_unlock_irqrestore+0x21/0x50 ... Call Trace: <IRQ> fq_flush_timeout+0x7d/0xd0 ? __pfx_fq_flush_timeout+0x10/0x10 call_timer_fn+0x2e/0x150 run_timer_softirq+0x48a/0x560 ? __pfx_fq_flush_timeout+0x10/0x10 ? clockevents_program_event+0xaf/0x130 __do_softirq+0xf1/0x335 irq_exit_rcu+0x9f/0xd0 sysvec_apic_timer_interrupt+0xb4/0xd0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1f/0x30 ...
Obvisouly, fq_flush_timeout spends over 20 seconds. Here is ftrace log:
| fq_flush_timeout() { | fq_ring_free() { | put_pages_list() { 0.170 us | free_unref_page_list(); 0.810 us | } | free_iova_fast() { | free_iova() { * 85622.66 us | _raw_spin_lock_irqsave(); 2.860 us | remove_iova(); 0.600 us | _raw_spin_unlock_irqrestore(); 0.470 us | lock_info_report(); 2.420 us | free_iova_mem.part.0(); * 85638.27 us | } * 85638.84 us | } | put_pages_list() { 0.230 us | free_unref_page_list(); 0.470 us | } ... ... $ 31017069 us | }
Most of cores are under lock contention for acquiring iova_rbtree_lock due to the iova flush queue mechanism.
[hard lockup] NMI watchdog: Watchdog detected hard LOCKUP on cpu 351 RIP: 0010:native_queued_spin_lock_slowpath+0x2d8/0x330
Call Trace: <IRQ> _raw_spin_lock_irqsave+0x4f/0x60 free_iova+0x27/0xd0 free_iova_fast+0x4d/0x1d0 fq_ring_free+0x9b/0x150 iommu_dma_free_iova+0xb4/0x2e0 __iommu_dma_unmap+0x10b/0x140 iommu_dma_unmap_sg+0x90/0x110 dma_unmap_sg_attrs+0x4a/0x50 nvme_unmap_data+0x5d/0x120 [nvme] nvme_pci_complete_batch+0x77/0xc0 [nvme] nvme_irq+0x2ee/0x350 [nvme] ? __pfx_nvme_pci_complete_batch+0x10/0x10 [nvme] __handle_irq_event_percpu+0x53/0x1a0 handle_irq_event_percpu+0x19/0x60 handle_irq_event+0x3d/0x60 handle_edge_irq+0xb3/0x210 __common_interrupt+0x7f/0x150 common_interrupt+0xc5/0xf0 </IRQ> <TASK> asm_common_interrupt+0x2b/0x40 ...
ftrace shows fq_ring_free spends over 10 seconds [1]. Again, most of cores are under lock contention for acquiring iova_rbtree_lock due to the iova flush queue mechanism.
[Root Cause] The root cause is that the max_hw_sectors_kb of nvme disk (mdts=10) is 4096kb, which streaming DMA mappings cannot benefit from the scalable IOVA mechanism introduced by the commit 9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova allocation") if the length is greater than 128kb.
To fix the lock contention issue, clamp max_hw_sectors based on DMA optimized limitation in order to leverage scalable IOVA mechanism.
Note: The issue does not happen with another NVME disk (mdts = 5 and max_hw_sectors_kb = 128)
[1] https://gist.github.com/AdrianHuang/bf8ec7338204837631fbdaed25d19cc4
Suggested-by: Keith Busch <kbusch@kernel.org> Reported-and-tested-by: Jiwei Sun <sunjw10@lenovo.com> Signed-off-by: Adrian Huang <ahuang12@lenovo.com> Reviewed-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
show more ...
|