Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
On 3/12/19 8:19 PM, Juergen Gross wrote: > 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. Clear. Then for 4.19 in Debian the workaround is documented in here. And if someone from the kernel team is reading along... Please mark as solved when >= 4.20 is uploaded to Debian unstable? Hans
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
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
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
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. ;] Except, for trying it to see if it won't introduce more regressions and explosions, if you want me to. Hans
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
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
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
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. xen_extra : .2-pre xen_version: 4.11.2-pre xen_commandline: placeholder dom0_mem=2G,max:2G dom0_max_vcpus=1-4 com2=115200,8n1 console=com2,vga noreboot=true xpti=dom0=false,domu=true smt=off clocksource=tsc tsc=stable:socket Hans
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
On 3/11/19 2: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? FWIW to me this also seems to be the only missing part. -boris
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 :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [ 14.518899] mpt3sas :02:00.0: swiotlb buffer is full
>> [ 14.518956] mpt3sas :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 :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 :02:00.0: swiotlb buffer is full (sz: 65536
>> bytes)
>> [ 14.527309] mpt3sas :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.
Attached is a rebase of the last part missing.
Should apply on top of 5.0 kernel, 4.20 should be okay, too. Earlier
kernels will miss some prerequisites.
Juergen
From: David Vrabel
Date: Mon, 11 Mar 2019 14:40:00 +0100
Subject: [PATCH] x86/xen: assume a 64-bit DMA mask is required
On a Xen PV guest the DMA addresses and physical addresses are not 1:1
(such as Xen PV guests) and the generic dma_get_required_mask() does
not return the correct mask (since it uses max_pfn).
Some device drivers (such as mptsas, mpt2sas) use
dma_get_required_mask() to set the device's DMA mask to allow them to
use only 32-bit DMA addresses in hardware structures. This results in
unnecessary use of the SWIOTLB if DMA addresses are more than 32-bits,
impacting performance significantly.
We could base the DMA mask on the maximum MFN but:
a) The hypercall op to get the maximum MFN (XENMEM_maximum_ram_page)
will truncate the result to an int in 32-bit guests.
b) Future uses of the IOMMU in Xen may map frames at bus addresses
above the end of RAM.
So, just assume a 64-bit DMA mask is always required.
Signed-off-by: David Vrabel
Reviewed-by: Juergen Gross
---
drivers/xen/swiotlb-xen.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index bb7888429be6..75e6e440d982 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -680,6 +680,11 @@ xen_swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt,
return dma_common_get_sgtable(dev, sgt, cpu_addr, handle, size, attrs);
}
+static u64 xen_swiotlb_get_required_mask(struct device *dev)
+{
+ return DMA_BIT_MASK(64);
+}
+
const struct dma_map_ops xen_swiotlb_dma_ops = {
.alloc = xen_swiotlb_alloc_coherent,
.free = xen_swiotlb_free_coherent,
@@ -694,4 +699,5 @@ const struct dma_map_ops xen_swiotlb_dma_ops = {
.dma_supported = xen_swiotlb_dma_supported,
.mmap = xen_swiotlb_dma_mmap,
.get_sgtable = xen_swiotlb_get_sgtable,
+ .get_required_mask = xen_swiotlb_get_required_mask,
};
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
On 10/03/2019 23:12, Hans van Kranenburg wrote: > On 3/10/19 11:03 PM, Andrew Cooper wrote: >> On 10/03/2019 21:35, Hans van Kranenburg wrote: >>> [...] >>> >>> 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. > It's actually dom0_mem=2G,max:4G, I typed something before which was not > identical to what I started that machine with. > >>> [...] >>> I think I'm fine with this workaround. >> 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. > FMI, is this max:4G DTRT for me now in the meantime, or am I still > facing more hidden problems while using this workaround? I believe that is good enough to work around the problem. The issue is that the these drivers are using dom0's max ram (well - max pfn to be specific) to decide whether it reports itself as 32bit or 64bit DMA capable, which is nonsense. Therefore, if dom0 thinks it has less that 4G of potential RAM, the driver reports the device as only 32-bit capable, and bounce-buffers all of its DMA (as dom0 is generally allocated above the 4G boundary in physical address space). ~Andrew
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 :02:00.0: swiotlb buffer is full (sz: 65536 >> bytes) >> [ 14.518899] mpt3sas :02:00.0: swiotlb buffer is full >> [ 14.518956] mpt3sas :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 :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 :02:00.0: swiotlb buffer is full (sz: 65536 >> bytes) >> [ 14.527309] mpt3sas :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
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
On 3/10/19 11:03 PM, Andrew Cooper wrote: > On 10/03/2019 21:35, Hans van Kranenburg wrote: >> >> [...] >> >> 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. It's actually dom0_mem=2G,max:4G, I typed something before which was not identical to what I started that machine with. >> [...] >> I think I'm fine with this workaround. > > 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. FMI, is this max:4G DTRT for me now in the meantime, or am I still facing more hidden problems while using this workaround? > 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. Thanks, Hans
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
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 :02:00.0: swiotlb buffer is full (sz: 65536 > bytes) > [ 14.518899] mpt3sas :02:00.0: swiotlb buffer is full > [ 14.518956] mpt3sas :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 :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 :02:00.0: swiotlb buffer is full (sz: 65536 > bytes) > [ 14.527309] mpt3sas :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. ~Andrew
Bug#850425: mpt3sas "swiotlb buffer is full" problem only under Xen
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 :02:00.0: swiotlb buffer is full (sz: 65536 bytes) [ 14.518899] mpt3sas :02:00.0: swiotlb buffer is full [ 14.518956] mpt3sas :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 :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 :02:00.0: swiotlb buffer is full (sz: 65536 bytes) [ 14.527309] mpt3sas :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... :) Hans
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
On Mon, 2017-01-16 at 11:47 +, Ian Jackson wrote:
> Andy Smith writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
> buffer is full" problem only under Xen"):
> > On Mon, Jan 09, 2017 at 06:01:14PM +, Ian Jackson wrote:
> > > Patches only make it into Linux upstream stable releases if someone
> > > pushes to get them in.
> >
> > Do you have any advice how I could push to get this to happen?
> >
> > Obviously I need this in order for Xen to be usable on my hardware
> > but we're talking mpt3sas driver here which is pretty common, so I
> > think it is quite desirable.
>
> Right. Well, you need to post to linux-kernel saying "this patch
> fixes such-and-such". You should:
>
> 1. git clone or git fetch the current master, which is
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#master
> and check that it doesn't have the patch.
It is better to use the subsystem's master branch. For many subsystems
this is listed in MAINTAINERS; otherwise 'git log --merges directory/'
should provide a clue.
[...]
> Backports to Debian are requested via the Debian BTS but you ideally
> the patch would be in upstream stable trees.
We're happy to take fixes once they've been accepted by the subsystem
maintainer.
> To get the patch into upstream stable trees, you need to send a
> > similar kind of email, but to <sta...@vger.kernel.org> (and the
> maintainers for the subsystems, I think).
[...]
It is easier to do this by putting a 'Cc: sta...@vger.kernel.org'
pseudo-header in the patch (along with Signed-off-by etc).
Ben.
--
Ben Hutchings
Every program is either trivial or else contains at least one bug
signature.asc
Description: This is a digitally signed message part
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
Andrew Cooper writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
buffer is full" problem only under Xen"):
> On 16/01/17 13:00, Ian Jackson wrote:
> > FYI David Vrabel doesn't work for Citrix any more but I'm hoping if
> > there are questions Andrew Cooper will be able to help.
>
> I am not sure how best to proceed. IIRC, they were essentially
> rejected, without any suitable alternative proposed by the maintainers.
Do you have a reference ?
Ian.
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
On 16/01/17 13:00, Ian Jackson wrote:
> Andy Smith writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
> buffer is full" problem only under Xen"):
>> On Mon, Jan 16, 2017 at 11:47:54AM +, Ian Jackson wrote:
>>> Right. Well, you need to post to linux-kernel saying "this patch
>>> fixes such-and-such". You should:
> ...
>> I see. This is not something I've done before, but I'd be willing to
>> give it a go.
>>
>> But, I am not the author of these two patches. That's David Vrabel,
>> and they're from something Andrew Cooper referred to as "the
>> XenServer Patch queue", here:
> Indeed.
>
>> At the present time I don't actually know in detail what these
>> patches do, nor how they have been tested, etc.; I only know that
>> they fix the problem I was seeing.
>>
>> Is it appropriate for me to be the one presenting them to
>> linux-kernel and the maintainers and so on?
> Yes, it is normal to be passing on other people's patches. Although
> of course if there are questions about them then you may not be able
> to answer.
>
> You should CC the patch authors (generally, everyone named with a
> Signed-off-by or a CC) on your emails.
>
> FYI David Vrabel doesn't work for Citrix any more but I'm hoping if
> there are questions Andrew Cooper will be able to help.
I am not sure how best to proceed. IIRC, they were essentially
rejected, without any suitable alternative proposed by the maintainers.
~Andrew
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
Andy Smith writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
buffer is full" problem only under Xen"):
> On Mon, Jan 16, 2017 at 11:47:54AM +, Ian Jackson wrote:
> > Right. Well, you need to post to linux-kernel saying "this patch
> > fixes such-and-such". You should:
...
> I see. This is not something I've done before, but I'd be willing to
> give it a go.
>
> But, I am not the author of these two patches. That's David Vrabel,
> and they're from something Andrew Cooper referred to as "the
> XenServer Patch queue", here:
Indeed.
> At the present time I don't actually know in detail what these
> patches do, nor how they have been tested, etc.; I only know that
> they fix the problem I was seeing.
>
> Is it appropriate for me to be the one presenting them to
> linux-kernel and the maintainers and so on?
Yes, it is normal to be passing on other people's patches. Although
of course if there are questions about them then you may not be able
to answer.
You should CC the patch authors (generally, everyone named with a
Signed-off-by or a CC) on your emails.
FYI David Vrabel doesn't work for Citrix any more but I'm hoping if
there are questions Andrew Cooper will be able to help.
Regards,
Ian.
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
Hi Ian, On Mon, Jan 16, 2017 at 11:47:54AM +, Ian Jackson wrote: > Right. Well, you need to post to linux-kernel saying "this patch > fixes such-and-such". You should: […] I see. This is not something I've done before, but I'd be willing to give it a go. But, I am not the author of these two patches. That's David Vrabel, and they're from something Andrew Cooper referred to as "the XenServer Patch queue", here: https://github.com/xenserver/linux-3.x.pg/blob/master/master/series#L613-L614 At the present time I don't actually know in detail what these patches do, nor how they have been tested, etc.; I only know that they fix the problem I was seeing. Is it appropriate for me to be the one presenting them to linux-kernel and the maintainers and so on? Thanks, Andy
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
Andy Smith writes ("Re: Bug#850425: Debian bug #850425 - mpt3sas "swiotlb
buffer is full" problem only under Xen"):
> On Mon, Jan 09, 2017 at 06:01:14PM +, Ian Jackson wrote:
> > Patches only make it into Linux upstream stable releases if someone
> > pushes to get them in.
>
> Do you have any advice how I could push to get this to happen?
>
> Obviously I need this in order for Xen to be usable on my hardware
> but we're talking mpt3sas driver here which is pretty common, so I
> think it is quite desirable.
Right. Well, you need to post to linux-kernel saying "this patch
fixes such-and-such". You should:
1. git clone or git fetch the current master, which is
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#master
and check that it doesn't have the patch.
2. Post the patch to linux-kernel. You need to CC all the relevant
maintainers and mailing lists. The kernel source tree has a script
get_maintainer.pl which will produce a list. Your message should
include all the relevant information, including:
* A copy of the patch (eg as produced by git-format-patch)
* A description of why it is needed, how it has been tested,
or whatever
If you don't get a sensible response you may need to repeat yourself.
There is no bug tracker or upstream work queue tracker; the retry
token is with you at all times.
When the patch is in the upstream tree (or perhaps, when it has been
queued by one of the driver maintainers for the next merge window, or
whatever), you should consider asking for backports.
Backports to Debian are requested via the Debian BTS but you ideally
the patch would be in upstream stable trees.
To get the patch into upstream stable trees, you need to send a
similar kind of email, but to <sta...@vger.kernel.org> (and the
maintainers for the subsystems, I think). You will again need to
chase this until you get a response. The corresponding trees are
something like
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#linux-3.19.y
Getting a respone may take some time. When you get a response saying
`queued' that does not mean it's actually in the public branch; only
that it is in the maintainers' private tree for the next push. I'm
told that that may again take several weeks. If it takes much longer
you should probably chase it.
Now that I have written all of this down, I hope you can see why we're
not volunteering to do all this donkey work :-/. But, I would be
happy to review drafts of your mails if you like, and to be CC'd.
Good luck.
Ian.
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
Hi Ian, On Mon, Jan 09, 2017 at 06:01:14PM +, Ian Jackson wrote: > Patches only make it into Linux upstream stable releases if someone > pushes to get them in. Do you have any advice how I could push to get this to happen? Obviously I need this in order for Xen to be usable on my hardware but we're talking mpt3sas driver here which is pretty common, so I think it is quite desirable. Cheers, Andy
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
On Mon, 2017-01-09 at 18:01 +, Ian Jackson wrote:
> Andy Smith writes ("Debian bug #850425 - mpt3sas "swiotlb buffer is
> full" problem only under Xen"):
> > I'm trying to get two Xen patches applied in Debian as I need it
> > for
> > Xen to work on my hardware. The bug report is here:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425
>
> Hi. (Bounced this to my work account where I do Xen stuff.)
>
> > Ben Hutchings is asking why the two patches are not yet applied
> > upstream and doesn't seem to have got an answer. I was wondering if
> > you could take a look.
>
> I'm afraid I don't know.
>
> Patches only make it into Linux upstream stable releases if someone
> pushes to get them in. I don't know whether this specific patch is
> even in the current Linux tip, which would normally be the route to
> getting them into stable.
It's not (unless that's changed since my previous mail).
Ben.
--
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.
signature.asc
Description: This is a digitally signed message part
Bug#850425: Debian bug #850425 - mpt3sas "swiotlb buffer is full" problem only under Xen
Andy Smith writes ("Debian bug #850425 - mpt3sas "swiotlb buffer is full"
problem only under Xen"):
> I'm trying to get two Xen patches applied in Debian as I need it for
> Xen to work on my hardware. The bug report is here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850425
Hi. (Bounced this to my work account where I do Xen stuff.)
> Ben Hutchings is asking why the two patches are not yet applied
> upstream and doesn't seem to have got an answer. I was wondering if
> you could take a look.
I'm afraid I don't know.
Patches only make it into Linux upstream stable releases if someone
pushes to get them in. I don't know whether this specific patch is
even in the current Linux tip, which would normally be the route to
getting them into stable.
Ian.
