NVME Subsystem Reset Question

[Jeffrey Lien]

Keith,
After reading over the LTSSM detect state description in the PCI spec, it certainly appears like the link recovery should be automatic.  

Are you thinking the surprise removal checking by the driver is causing the link to be disabled - until a bus scan is done?  If so, maybe it would be worth putting in a retry of the call to nvme_dev_resume (after a short delay) in nvme_remove_dead_ctrl before making the call to pci_stop_and_remove_bus_device_locked.  I'll do some experimenting with this to see if it works and let you know what I find.


Jeff Lien

-----Original Message-----
From: Linux-nvme [mailto:linux-nvme-bounces at lists.infradead.org] On Behalf Of Keith Busch
Sent: Monday, October 17, 2016 11:21 AM
To: Jeffrey Lien
Cc: axboe at fb.com; Nathan Rabe; David Darrington; linux-nvme at lists.infradead.org
Subject: Re: NVME Subsystem Reset Question

On Mon, Oct 17, 2016 at 02:42:56PM +0000, Jeffrey Lien wrote:
> We're using the 3.10.0-493 kernel from a Red hat 7.3 Beta install.  I believe the nvme inbox driver here was back ported from the 4.5 kernel release.   I've attached the dmesg output from both the intel and western digital device.  Both are very similar if not identical.  

It does appear the link is disabled when the driver's health check runs. It may be possible it observes all 1's on a transient link state change in the health check. I'm not sure right now of a safe way to distinguish a permanently disabled device vs a transient condition with the information available.

How are you sending a subsystem reset? On the Intel device, I assumed you were using a D3600, but this looks like a P3600 based on the model and firmware revision. That controller doesn't support subsystem reset, so the ioctl method should have returned -ENOTTY.

_______________________________________________
Linux-nvme mailing list
Linux-nvme at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme