From: Andreas Hartmann <andihartmann@freenet.de>
To: Alex Williamson <alex.williamson@redhat.com>,
Andreas Hartmann <andihartmann@freenet.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
linux-pci <linux-pci@vger.kernel.org>
Subject: Re: Hard and silent lock up since linux 3.14 with PCIe pass through (vfio)
Date: Wed, 22 Oct 2014 18:22:49 +0200 [thread overview]
Message-ID: <5447D9D9.9030909@maya.org> (raw)
In-Reply-To: <1413927152.4202.195.camel@ul30vt.home>
Alex Williamson wrote:
> On Tue, 2014-10-21 at 15:06 -0600, Alex Williamson wrote:
>> Hi Andreas,
>>
>> On Fri, 2014-10-17 at 03:04 +0200, Andreas Hartmann wrote:
>>> Hello Alex,
>>>
>>> Alex Williamson wrote:
>>>> Hi Andreas,
>>> [...]
>>>> Sorry for the breakage. Is it possible to run lspci on the device in a
>>>> loop from the host and capture whether we're failing to restore some of
>>>> the VC bits to their previous state?
>>>
>>>> Does the problem also occur if you
>>>> unbind from host driver,
>>>
>>> The machine is booted w/ blacklisted ath9k. Then, the device is bound to
>>> vfio:
>>>
>>> echo "168c 0030" > /sys/bus/pci/drivers/vfio-pci/new_id
>>> echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind
>>> echo 0000:03:00.0 > /sys/bus/pci/drivers/vfio-pci/bind
>>>
>>> afterwards the VM is started -> hang.
>>>
>>> W/o starting th VM, I can bind it to vfio and unbind it from vfio w/o
>>> any problem.
>>>
>>>> echo 1 > reset in pci-sysfs,
>>>
>>> echo 1 > /sys/bus/pci/devices/0000:03:00.0 works w/o any problem while
>>> bound to vfio. Even after unbinding from vfio and rebinding to vfio
>>> again ... .
>>>
>>>> and re-bind to the
>>>
>>> Do you mean loading ath9k in host system after unbinding from vfio? If
>>> yes: Works w/o any problem. It's even possible to reset it or do a
>>> ifconfig wlan0 up, ifconfig wlan0 down, rmmod ath9k, bind it to vfio
>>> again and reset it, ....
>>>
>>> Looks like the hang only is triggered by qemu-system_x86_64 on startup
>>> the VM.
>
> Also, this might be because QEMU since 1.7 will favor doing a bus reset
> for a device over PM reset while the sysfs reset interface will only do
> a bus reset if there are no other methods available and there are no
> other devices on the bus. Can you reproduce the hang using the sysfs
> reset interface without QEMU if you modify the kernel like this:
>
> --- 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.
Regards,
Andreas
next prev parent reply other threads:[~2014-10-22 16:29 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-23 19:03 Hard and silent lock up since linux 3.14 with PCIe pass through (vfio) Andreas Hartmann
2014-09-23 20:07 ` Alex Williamson
2014-09-24 14:54 ` Andreas Hartmann
2014-09-24 17:16 ` Andreas Hartmann
2014-10-10 9:39 ` Andreas Hartmann
2014-10-10 14:37 ` Bjorn Helgaas
2014-10-10 14:49 ` Andreas Hartmann
2014-10-10 15:55 ` Bjorn Helgaas
2014-10-10 16:09 ` Andreas Hartmann
2014-10-10 16:41 ` Bjorn Helgaas
2014-10-10 22:32 ` Andreas Hartmann
2014-10-10 22:54 ` Bjorn Helgaas
2014-10-11 6:20 ` Andreas Hartmann
2014-10-15 8:04 ` Alex Williamson
2014-10-17 1:04 ` Andreas Hartmann
2014-10-21 21:06 ` Alex Williamson
2014-10-21 21:32 ` Alex Williamson
2014-10-22 16:22 ` Andreas Hartmann [this message]
2014-10-22 20:36 ` Alex Williamson
2014-10-23 16:00 ` Andreas Hartmann
2014-10-23 16:33 ` Alex Williamson
2014-10-23 17:12 ` Andreas Hartmann
2014-10-23 17:33 ` Andreas Hartmann
2014-10-23 19:37 ` Alex Williamson
2014-10-24 14:21 ` Andreas Hartmann
2014-10-25 6:03 ` Andreas Hartmann
2014-10-28 21:51 ` Alex Williamson
2014-10-29 16:47 ` Andreas Hartmann
2014-10-29 17:44 ` Alex Williamson
2014-10-29 17:57 ` Andreas Hartmann
2014-10-29 18:16 ` Alex Williamson
2014-10-29 19:43 ` Andreas Hartmann
2014-10-29 20:50 ` Alex Williamson
2014-10-29 21:35 ` Andreas Hartmann
2014-10-30 16:35 ` Andreas Hartmann
2014-10-30 16:58 ` Alex Williamson
2014-10-30 19:09 ` Andreas Hartmann
2014-10-30 19:45 ` Alex Williamson
2014-10-30 20:21 ` Andreas Hartmann
2014-10-22 15:34 ` Andreas Hartmann
2014-10-22 16:02 ` Alex Williamson
2014-10-22 16:20 ` Andreas Hartmann
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=5447D9D9.9030909@maya.org \
--to=andihartmann@freenet.de \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).