On 12/11/2019 12:05, Jan Beulich wrote:
> On 11.11.2019 22:38, Sander Eikelenboom wrote:
>> When supplying "pci=nomsi" to the guest kernel, the device works fine,
>> and I don't get the "INVALID_DEV_REQUEST".
>>
>> After reverting 1b00c16bdf, the device works fine
>> and I don't get the
On 11.11.2019 22:38, Sander Eikelenboom wrote:
> When supplying "pci=nomsi" to the guest kernel, the device works fine,
> and I don't get the "INVALID_DEV_REQUEST".
>
> After reverting 1b00c16bdf, the device works fine
> and I don't get the INVALID_DEV_REQUEST,
Could you give the patch below a
On 11/11/2019 16:35, Jan Beulich wrote:
> On 31.10.2019 21:48, Sander Eikelenboom wrote:
>> - The usb3 controller malfunctioning seems indeed to be a separate issue
>> (which seems unfortunate,
>> because a bisect seems to become even nastier with all the intertwined
>>
On 31.10.2019 21:48, Sander Eikelenboom wrote:
> While in the guest it is endlessly repeating:
> [ 231.385566] xhci_hcd :00:05.0: Max number of devices this
> xHCI host supports is 32.
> [ 231.407351] usb usb1-port2: couldn't allocate usb_device
For this one,
On 31.10.2019 21:48, Sander Eikelenboom wrote:
> - The usb3 controller malfunctioning seems indeed to be a separate issue
> (which seems unfortunate,
> because a bisect seems to become even nastier with all the intertwined
> pci-passthrough issues).
>
> Perhaps this one
On 31/10/2019 11:15, Jan Beulich wrote:
> On 30.10.2019 23:21, Sander Eikelenboom wrote:
>> Call trace seems to be the same in all cases.
>>
>> --
>> Sander
>>
>>
>> (XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access
>> pdev_list without aquiring pcidevs_lock.
>> (XEN)
On 30.10.2019 23:21, Sander Eikelenboom wrote:
> Call trace seems to be the same in all cases.
>
> --
> Sander
>
>
> (XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access
> pdev_list without aquiring pcidevs_lock.
> (XEN) [2019-10-30 22:07:05.748] [ Xen-4.13.0-rc x86_64
On 31/10/2019 10:18, Jan Beulich wrote:
> On 31.10.2019 09:35, Sander Eikelenboom wrote:
>> Platform is perhaps what specific (older AMD 890FX chipset) and I need the
>> bios workaround:
>> ivrs_ioapic[6]=00:14.0 iommu=on.
>
> Shouldn't matter here.
>
>> On the other hand, this has ran like
On 31.10.2019 09:35, Sander Eikelenboom wrote:
> Platform is perhaps what specific (older AMD 890FX chipset) and I need the
> bios workaround:
> ivrs_ioapic[6]=00:14.0 iommu=on.
Shouldn't matter here.
> On the other hand, this has ran like this for quite some time.
>
> I have 3 guests (HVM)
On 30.10.2019 23:21, Sander Eikelenboom wrote:
> Call trace seems to be the same in all cases.
Thanks much.
> (XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access
> pdev_list without aquiring pcidevs_lock.
> (XEN) [2019-10-30 22:07:05.748] [ Xen-4.13.0-rc x86_64
On 30/10/2019 16:48, Jan Beulich wrote:
> On 28.10.2019 11:32, Sander Eikelenboom wrote:
>> While testing the latest xen-unstable and starting an HVM guest with
>> pci-passtrough on my AMD machine,
>> my eye catched the following messages in xl dmesg I haven't seen before:
>>
>> (XEN) [2019-10-28
On 28.10.2019 11:32, Sander Eikelenboom wrote:
> While testing the latest xen-unstable and starting an HVM guest with
> pci-passtrough on my AMD machine,
> my eye catched the following messages in xl dmesg I haven't seen before:
>
> (XEN) [2019-10-28 10:23:16.372] AMD-Vi: update_paging_mode Try
On 28.10.2019 11:32, Sander Eikelenboom wrote:
> Hi Jan / Andrew,
>
> While testing the latest xen-unstable and starting an HVM guest with
> pci-passtrough on my AMD machine,
> my eye catched the following messages in xl dmesg I haven't seen before:
>
> (XEN) [2019-10-28 10:23:16.372] AMD-Vi:
Hi Jan / Andrew,
While testing the latest xen-unstable and starting an HVM guest with
pci-passtrough on my AMD machine,
my eye catched the following messages in xl dmesg I haven't seen before:
(XEN) [2019-10-28 10:23:16.372] AMD-Vi: update_paging_mode Try to access
pdev_list without aquiring
14 matches
Mail list logo
