I've pulled v2 with the ia64 into dma-mapping for-next. This should
give us a little more than a week in linux-next to sort out any
issues.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tue, Dec 11, 2018 at 05:13:30PM +, Luck, Tony wrote:
> > But that might not be your fault. My ancient system is getting flaky. A
> > v4.19 build that
> > has booted before is also resetting :-(
>
> After a power-cycle (and some time to let the machine cool off). System now
> boots
> with
> But that might not be your fault. My ancient system is getting flaky. A v4.19
> build that
> has booted before is also resetting :-(
After a power-cycle (and some time to let the machine cool off). System now
boots
with your patch series plus the __phys_to_pfn() #define
So if you can figure
> This should fix it:
...
> +#include
Not quite. Still have an issue with __phys_to_pfn(paddr)
Trying ti #include gave we a raft of redefined
macros. So I just added
#define __phys_to_pfn(paddr)PHYS_PFN(paddr)
to arch/ia64/mm/init.c
That made the build work. But boot spontaneously
On Mon, Dec 10, 2018 at 01:51:13PM -0800, Luck, Tony wrote:
> But the ia64 build fails with:
Yes, I just got the same complaint form the buildbot, unfortunately
I don't have a good ia64 cross compiler locally given that Debian
is lacking one, and the one provided by the buildbot doesn't build on
On Fri, Dec 07, 2018 at 11:07:05AM -0800, Christoph Hellwig wrote:
> This works is based on the dma-mapping tree, so you probably want to
> want this git tree for testing:
>
> git://git.infradead.org/users/hch/misc.git dma-direct-calls.2
Pulled this tree. Got HEAD
33b9fc015171
On Fri, 7 Dec 2018 11:07:05 -0800
Christoph Hellwig wrote:
> Hi all,
>
> a while ago Jesper reported major performance regressions due to the
> spectre v2 mitigations in his XDP forwarding workloads. A large part
> of that is due to the DMA mapping API indirect calls.
>
> It turns out that
