Alex Williamson wrote: > 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 machine is booted w/ vfio bound to 3:00.0 as usual (now for testing linux 3.14) lspci -xxxx -s 3:00.0 setpci -s 00:05.0 3e.w=40:40 usleep 10 setpci -s 00:05.0 3e.w=00:40 sleep 1 lspci -xxxx -s 3:00.0 I didn't get the second lspci because the machine already was hanging. The first output is attached completely. Hope this helps, thanks, regards, Andreas
Attachment:
atheros-pci1.gz
Description: GNU Zip compressed data
