Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #63552 > unrolled thread

Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen Juergen Gross <jgross@suse.com> - 2019-03-11 08:00 +0100
    Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen Juergen Gross <jgross@suse.com> - 2019-03-12 17:10 +0100
      Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen Juergen Gross <jgross@suse.com> - 2019-03-12 20:30 +0100

#63552 — Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen

On 10/03/2019 23:03, Andrew Cooper wrote:
> On 10/03/2019 21:35, Hans van Kranenburg wrote:
>> found -1 4.19.20-1
>> thanks
>>
>> Hi,
>>
>> Reviving a thing from Jan 2017 here. I don't have this thread in my
>> mailbox, so no inline quotes.
>>
>> I just installed some HP z820 workstation and rebooted it into Xen
>> 4.11.1+26-g87f51bf366-3 with linux 4.19.20-1 as dom0 kernel.
>>
>> During boot I'm greeted by a long list of...
>>
>> [   14.518793] mpt3sas 0000:02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.518899] mpt3sas 0000:02:00.0: swiotlb buffer is full
>> [   14.518956] mpt3sas 0000:02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.518988] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
>> [   14.519081] mpt3sas 0000:02:00.0: swiotlb buffer is full
>> [   14.519309] sd 6:0:1:0: pci_map_sg failed: request for 1310720 bytes!
>> [   14.524611] mpt3sas 0000:02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [   14.527309] mpt3sas 0000:02:00.0: swiotlb buffer is full
>> [   14.527405] sd 6:0:3:0: pci_map_sg failed: request for 786432 bytes!
>> [...]
>>
>> ...and some hangs here and there. This indeed did not happen when
>> booting just Linux, without Xen.
>>
>> Some searching brought me to this Debian bug. So, thanks for writing
>> down all kinds of research here already. Even if it's not fixed upstream
>> yet, this helps a lot. :-)
>>
>> Using dom0_mem=2GiB,max:4GiB instead of dom0_mem=2GiB,max:2GiB (which I
>> started with) makes the errors go away, so workaround confirmed.
>>
>> I can try any of the linked patches, but I see that in message 54,
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425#54
>> Andrew says: "IIRC, they were essentially rejected,". Next message, Ian
>> asks "Do you have a reference ?", but I don't see any fup on that.
>>
>> I think I'm fine with this workaround.
>>
>> If someone will ever work on the upstream patches, then this is just to
>> let know that I might be able to help testing. However, I only have one
>> of this type of box and it's gonna be installed as server at some
>> non-profit organization without OOB access, replacing even older donated
>> hardware, so, it will be kinda limited... :)
> 
> I think
> https://lists.xen.org/archives/html/xen-devel/2014-12/msg00699.html is
> the last attempt David made to upstream the fixes.
> 
> Linux is still broken, and these fixes are still necessary.
> 
> Boris/Juergen: Any chance you could look into these patches?  I have no
> idea what they they're in against master, but its also liable its now
> more complicated with the host max mfn calculations which have gone in
> more recently.

I'm not sure. Patch 3 of this series is basically already there (see
commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
is patch 4, which should really be easy to do?

Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
I can do the official patch posting in case you confirm it working.

Adding Konrad as the swiotlb-xen maintainer.


Juergen

[toc] | [next] | [standalone]

#63566

On 11/03/2019 20:50, Hans van Kranenburg wrote:
> On 3/11/19 7:34 AM, Juergen Gross wrote:
>>
>> I'm not sure. Patch 3 of this series is basically already there (see
>> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
>> is patch 4, which should really be easy to do?
>>
>> Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
>> I can do the official patch posting in case you confirm it working.
> 
> Ehm ok, well... This is interesting.
> 
> I just built a 4.20.13 (without the patch), and I did it from the Debian
> kernel team repo, because then I just get all latest config options like
> I would get them in Debian.
> 
> I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
> errors similar to the ones I pasted earlier.
> 
> I haven't been running any domU on it yet (just installed it), but this
> is not what I expected.

Well, commit c6d4381220a0087ce19dbf6984d92c451bd6b364 is part of a
rather large series making the dma interface cleaner and using it more
correctly where appropriate. Maybe your use case is covered by this
series already.


Juergen

[toc] | [prev] | [next] | [standalone]

#63568

On 12/03/2019 17:41, Hans van Kranenburg wrote:
> On 3/12/19 5:04 PM, Juergen Gross wrote:
>> On 11/03/2019 20:50, Hans van Kranenburg wrote:
>>> On 3/11/19 7:34 AM, Juergen Gross wrote:
>>>>
>>>> I'm not sure. Patch 3 of this series is basically already there (see
>>>> commit c6d4381220a0087ce19dbf6984d92c451bd6b364). So maybe all we need
>>>> is patch 4, which should really be easy to do?
>>>>
>>>> Hans, could you give it a try? You'd need to use a 4.20 kernel at least.
>>>> I can do the official patch posting in case you confirm it working.
>>>
>>> Ehm ok, well... This is interesting.
>>>
>>> I just built a 4.20.13 (without the patch), and I did it from the Debian
>>> kernel team repo, because then I just get all latest config options like
>>> I would get them in Debian.
>>>
>>> I rebooted the HP Z820 with it (with Xen 4.11) and I don't see any
>>> errors similar to the ones I pasted earlier.
>>>
>>> I haven't been running any domU on it yet (just installed it), but this
>>> is not what I expected.
>>
>> Well, commit c6d4381220a0087ce19dbf6984d92c451bd6b364 is part of a
>> rather large series making the dma interface cleaner and using it more
>> correctly where appropriate. Maybe your use case is covered by this
>> series already.
> 
> It seems so. That's good, of course, but it also means that I cannot be
> of any use here any more to test the additional proposed change. ;]

I don't think the change is needed any longer.

Christoph's series was meant to fix stuff like that and it did that very
well.


Juergen

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web