Bug 12920
Summary: | savage: mmap2 of /dev/dri/card0 fails with EAGAIN since 2.6.29-rc6 | ||
---|---|---|---|
Product: | Platform Specific/Hardware | Reporter: | Alex Villacis Lasso (avillaci) |
Component: | i386 | Assignee: | platform_i386 |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | rjw, suresh.b.siddha, the.masch, venki |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.29-rc6 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 12398 | ||
Attachments: |
Kernel configuration which succeeds in 2.6.29-rc5 and fails in 2.6.29-rc6 and up.
dmesg output for 2.6.29-rc8 which also shows the bug. Full xorg log when bug happens. strace output that shows EAGAIN as error from mmap2 strace output that shows EAGAIN as error from mmap2 |
Description
Alex Villacis Lasso
2009-03-23 08:58:05 UTC
Created attachment 20642 [details]
Kernel configuration which succeeds in 2.6.29-rc5 and fails in 2.6.29-rc6 and up.
Created attachment 20643 [details]
dmesg output for 2.6.29-rc8 which also shows the bug.
I do not see any message that could point to some particular problem, because similar messages appear in rc5, but I could be wrong.
Created attachment 20644 [details]
Full xorg log when bug happens.
Created attachment 20645 [details]
strace output that shows EAGAIN as error from mmap2
Created attachment 20646 [details]
strace output that shows EAGAIN as error from mmap2
Sorry for double-posting the attachment. I attempted to bisect this bug over the weekend. This is what I got so far: git bisect start # bad: [fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc] Linux 2.6.29-rc7 git bisect bad fec6c6fec3e20637bee5d276fb61dd8b49a3f9cc # good: [d2f8d7ee1a9b4650b4e43325b321801264f7c37a] Linux 2.6.29-rc5 git bisect good d2f8d7ee1a9b4650b4e43325b321801264f7c37a # bad: [ddf9499b3d1e655f212f22b0a703506fcac90b25] x86, Voyager: fix compile by lifting the degeneracy of phys_cpu_present_map git bisect bad ddf9499b3d1e655f212f22b0a703506fcac90b25 # bad: [ba95fd47d177d46743ad94055908d22840370e06] Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block git bisect bad ba95fd47d177d46743ad94055908d22840370e06 # good: [48c0d9ece360ff6001e2ae36aa9b34446d0388a8] Merge git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable git bisect good 48c0d9ece360ff6001e2ae36aa9b34446d0388a8 # bad: [82eb03cfd862a65363fa2826de0dbd5474cfe5e2] cciss: PCI power management reset for kexec git bisect bad 82eb03cfd862a65363fa2826de0dbd5474cfe5e2 # good: [8ce9a75a307e142a8871c649627555e0e4a1eefb] Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip git bisect good 8ce9a75a307e142a8871c649627555e0e4a1eefb I'd take a bet on this being the PAT/mmap breakage again testing latest -tip would be useful: http://people.redhat.com/mingo/tip.git/README in particular the fix below has a chance of resolving it. Ingo ----------------> From 9cdec049389ce2c324fd1ec508a71528a27d4a07 Mon Sep 17 00:00:00 2001 From: Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> Date: Mon, 23 Mar 2009 12:07:20 -0700 Subject: [PATCH] x86, PAT, PCI: Change vma prot in pci_mmap to reflect inherited prot While looking at the issue in the thread: http://marc.info/?l=dri-devel&m=123606627824556&w=2 noticed a bug in pci PAT code and memory type setting. PCI mmap code did not set the proper protection in vma, when it inherited protection in reserve_memtype. This bug only affects the case where there exists a WC mapping before X does an mmap with /proc or /sys pci interface. This will cause X userlevel mmap from /proc or /sysfs to fail on fork. Reported-by: Kevin Winchester <kjwinchester@gmail.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Dave Airlie <airlied@redhat.com> Cc: <stable@kernel.org> LKML-Reference: <20090323190720.GA16831@linux-os.sc.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- arch/x86/pci/i386.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c index 5ead808..f234a37 100644 --- a/arch/x86/pci/i386.c +++ b/arch/x86/pci/i386.c @@ -319,6 +319,9 @@ int pci_mmap_page_range(struct pci_dev *dev, struct vm_area_struct *vma, return -EINVAL; } flags = new_flags; + vma->vm_page_prot = __pgprot( + (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK) | + flags); } if (((vma->vm_pgoff < max_low_pfn_mapped) || (pwc has a similar problem btw) >
> diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
> index 5ead808..f234a37 100644
> --- a/arch/x86/pci/i386.c
> +++ b/arch/x86/pci/i386.c
> @@ -319,6 +319,9 @@ int pci_mmap_page_range(struct pci_dev *dev, struct
> vm_area_struct *vma,
> return -EINVAL;
> }
> flags = new_flags;
> + vma->vm_page_prot = __pgprot(
> + (pgprot_val(vma->vm_page_prot) & ~_PAGE_CACHE_MASK) |
> + flags);
> }
>
> if (((vma->vm_pgoff < max_low_pfn_mapped) ||
Compiling a full kernel takes too long in my machine (over 6 hours), so I tried manually applying this patch on an already compiled 2.6.29-rc8 checkout. However, it did not fix the problem - the symptoms remain exactly the same.
I have the same problem using archlinux and the latest 2.26.9 kernel of the the distro, I will waiting that the distribution apply the patch. It's work the patch? Bisection points me to the following: be03d9e8022030c16abf534e33e185bfc3d40eef is first bad commit commit be03d9e8022030c16abf534e33e185bfc3d40eef Author: Suresh Siddha <suresh.b.siddha@intel.com> Date: Wed Feb 11 11:20:23 2009 -0800 x86, pat: fix warn_on_once() while mapping 0-1MB range with /dev/mem Jeff Mahoney reported: > With Suse's hwinfo tool, on -tip: > WARNING: at arch/x86/mm/pat.c:637 reserve_pfn_range+0x5b/0x26d() reserve_pfn_range() is not tracking the memory range below 1MB as non-RAM and as such is inconsistent with similar checks in reserve_memtype() and free_memtype() Rename the pagerange_is_ram() to pat_pagerange_is_ram() and add the "track legacy 1MB region as non RAM" condition. And also, fix reserve_pfn_range() to return -EINVAL, when the pfn range is RAM. This is to be consistent with this API design. Reported-and-tested-by: Jeff Mahoney <jeffm@suse.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> :040000 040000 feb3bf21d762e885284cb1bedb5d2c6c0d16811b b4c2143775386ce15dd49b6749c1f7913d8beb00 M arch I have confirmed that reverting this one patch fixes the issue in both 2.6.29-rc8 and 2.6.29 final. Is there anything else I could do to help fix this problem? Going to try re-applying failing commit, then applying http://marc.info/?l=linux-kernel&m=123691716419111&w=2 to see whether this fixes the issue too. Fix for this issue (http://marc.info/?l=linux-kernel&m=123854290308079&w=2) went into linux-2.6.29.1. Can we please check 2.6.29.1 and close this bug if the issue is resolved? The 2.6.29.1 patch indeed fixes this bug for me. Marking as FIXED. The 2.6.29.1 patch indeed fixes this bug for me. Marking as FIXED. |