|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] patch "[PATCH] xen/swiotlb: Use page alignment for early buffer allocation." failed to apply to 3.1-stable tree
On Fri, Dec 16, 2011 at 12:58:55AM +0000, Taylor, Neal E wrote:
> Konrad,
>
> This patch applies and compiles on 3.1.5 and 3.0.4. I'll test tomorrow.
OK. I've tested it on 3.1.5 and 3.0.6 as well. If I recall you mentioned
that you had tested the 3.0.4 + this patch yesterday (thought you
probably had tons of debugging patches too). Is that you are testing a clean
version of 3.0.4 with this patch? Or are you testing both trees on your box?
Thanks!
>
> Neal
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..5c8e445 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,8 @@ retry:
> /*
> * Get IO TLB memory from any location.
> */
> - xen_io_tlb_start = alloc_bootmem(bytes);
> + xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> +
> if (!xen_io_tlb_start)
> panic("Cannot allocate SWIOTLB buffer");
>
> -----Original Message-----
> From: gregkh@xxxxxxx [mailto:gregkh@xxxxxxx]
> Sent: Thursday, December 15, 2011 3:14 PM
> To: konrad.wilk@xxxxxxxxxx; Kalev, Leonid; Taylor, Neal E
> Cc: stable@xxxxxxxxxxxxxxx
> Subject: patch "[PATCH] xen/swiotlb: Use page alignment for early buffer
> allocation." failed to apply to 3.1-stable tree
>
>
> The patch below does not apply to the 3.1-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to <stable@xxxxxxxxxxxxxxx>.
>
> thanks,
>
> greg k-h
>
> ------------------ original commit in Linus's tree ------------------
>
> >From 63a741757d15320a25ebf5778f8651cce2ed0611 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> Date: Thu, 15 Dec 2011 11:28:46 -0500
> Subject: [PATCH] xen/swiotlb: Use page alignment for early buffer allocation.
>
> This fixes an odd bug found on a Dell PowerEdge 1850/0RC130
> (BIOS A05 01/09/2006) where all of the modules doing pci_set_dma_mask
> would fail with:
>
> ata_piix 0000:00:1f.1: enabling device (0005 -> 0007)
> ata_piix 0000:00:1f.1: can't derive routing for PCI INT A
> ata_piix 0000:00:1f.1: BMDMA: failed to set dma mask, falling back to PIO
>
> The issue was the Xen-SWIOTLB was allocated such as that the end of
> buffer was stradling a page (and also above 4GB). The fix was
> spotted by Kalev Leonid which was to piggyback on git commit
> e79f86b2ef9c0a8c47225217c1018b7d3d90101c "swiotlb: Use page alignment
> for early buffer allocation" which:
>
> We could call free_bootmem_late() if swiotlb is not used, and
> it will shrink to page alignment.
>
> So alloc them with page alignment at first, to avoid lose two pages
>
> And doing that fixes the outstanding issue.
>
> CC: stable@xxxxxxxxxx
> Suggested-by: "Kalev, Leonid" <Leonid.Kalev@xxxxxx>
> Reported-and-Tested-by: "Taylor, Neal E" <Neal.Taylor@xxxxxx>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 8e964b9..284798a 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -166,7 +166,7 @@ retry:
> /*
> * Get IO TLB memory from any location.
> */
> - xen_io_tlb_start = alloc_bootmem(bytes);
> + xen_io_tlb_start = alloc_bootmem_pages(PAGE_ALIGN(bytes));
> if (!xen_io_tlb_start) {
> m = "Cannot allocate Xen-SWIOTLB buffer!\n";
> goto error;
> @@ -179,7 +179,7 @@ retry:
> bytes,
> xen_io_tlb_nslabs);
> if (rc) {
> - free_bootmem(__pa(xen_io_tlb_start), bytes);
> + free_bootmem(__pa(xen_io_tlb_start), PAGE_ALIGN(bytes));
> m = "Failed to get contiguous memory for DMA from Xen!\n"\
> "You either: don't have the permissions, do not have"\
> " enough free memory under 4GB, or the hypervisor memory"\
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |