On Wed, 2014-10-22 at 18:22 +0200, Andreas Hartmann wrote: > Alex Williamson wrote: > > --- a/drivers/pci/pci.c > > +++ b/drivers/pci/pci.c > > @@ -3308,15 +3308,15 @@ static int __pci_dev_reset(struct pci_dev *dev, int prob > > if (rc != -ENOTTY) > > goto done; > > > > - rc = pci_pm_reset(dev, probe); > > + rc = pci_dev_reset_slot_function(dev, probe); > > if (rc != -ENOTTY) > > goto done; > > > > - rc = pci_dev_reset_slot_function(dev, probe); > > + rc = pci_parent_bus_reset(dev, probe); > > if (rc != -ENOTTY) > > goto done; > > > > - rc = pci_parent_bus_reset(dev, probe); > > + rc = pci_pm_reset(dev, probe); > > done: > > return rc; > > } > > This way it's crashing with echo 1 > reset, too. Ok, so it's somehow related to doing a bus reset with virtual channel save/restore while PM reset with VC save/restore works ok as apparently does bus reset without VC save/restore. Let's try to do a manual bus reset so we can look at the post reset state of the device before the kernel tries to restore it. First bind the target device 03:00.0 to pci-stub or vfio-pci so that we know it's not being used. Next capture lspci -xxxx -s 3:00.0 so we have the starting state. Then we'll do a bus reset using setpci: # setpci -s 00:05.0 3e.w=40:40 <if you script this, wait at least 2ms here> # setpci -s 00:05.0 3e.w=00:40 <wait 1 second here> Now re-capture lspci -xxxx -s 3:00.0 The interesting lines for your device are 140: and 150:, so if you want to avoid sending massive emails you can just send those for the before and after. You'll need to reboot the system before you do anything else with this device since it's now in an uninitialized state. Based on what the lspci output reports (or whether you experience a hang simply from this), we may want to try writing additional bits with setpci to mimic the VC restore behavior. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
