Message ID | 4D6FBC7F.1080500@matrix-vision.de (mailing list archive) |
---|---|
State | Superseded, archived |
Headers |
Return-path: <mchehab@pedra> Envelope-to: mchehab@pedra Delivery-date: Thu, 03 Mar 2011 13:07:30 -0300 Received: from mchehab by pedra with local (Exim 4.72) (envelope-from <mchehab@pedra>) id 1PvB3q-0002kP-H5 for mchehab@pedra; Thu, 03 Mar 2011 13:07:30 -0300 Received: from casper.infradead.org [85.118.1.10] by pedra with IMAP (fetchmail-6.3.17) for <mchehab@localhost> (single-drop); Thu, 03 Mar 2011 13:07:30 -0300 (BRT) Received: from vger.kernel.org ([209.132.180.67]) by casper.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PvB3C-00014s-Q0; Thu, 03 Mar 2011 16:06:51 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932171Ab1CCQG1 (ORCPT <rfc822;kmpark@infradead.org> + 1 other); Thu, 3 Mar 2011 11:06:27 -0500 Received: from mail1.matrix-vision.com ([78.47.19.71]:46085 "EHLO mail1.matrix-vision.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754035Ab1CCQG0 (ORCPT <rfc822; linux-media@vger.kernel.org>); Thu, 3 Mar 2011 11:06:26 -0500 Received: from mail1.matrix-vision.com (localhost [127.0.0.1]) by mail1.matrix-vision.com (Postfix) with ESMTP id 5DB93723A4; Thu, 3 Mar 2011 17:06:25 +0100 (CET) Received: from erinome (g2.matrix-vision.com [80.152.136.245]) by mail1.matrix-vision.com (Postfix) with ESMTPA id 13D8372167; Thu, 3 Mar 2011 17:06:25 +0100 (CET) Received: from erinome (localhost [127.0.0.1]) by erinome (Postfix) with ESMTP id 7B7186F8A; Thu, 3 Mar 2011 17:06:24 +0100 (CET) Received: by erinome (Postfix, from userid 108) id 6CBD86F9C; Thu, 3 Mar 2011 17:06:24 +0100 (CET) Received: from [192.168.65.46] (host65-46.intern.matrix-vision.de [192.168.65.46]) by erinome (Postfix) with ESMTPA id 592A06F8A; Thu, 3 Mar 2011 17:06:24 +0100 (CET) Message-ID: <4D6FBC7F.1080500@matrix-vision.de> Date: Thu, 03 Mar 2011 17:06:23 +0100 From: Michael Jones <michael.jones@matrix-vision.de> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>, fernando.lugo@ti.com CC: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>, Linux Media Mailing List <linux-media@vger.kernel.org>, linux-omap@vger.kernel.org, Hiroshi.DOYU@nokia.com Subject: Re: omap3isp cache error when unloading References: <4D6D219D.7020605@matrix-vision.de> <201103022018.23446.laurent.pinchart@ideasonboard.com> In-Reply-To: <201103022018.23446.laurent.pinchart@ideasonboard.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MV-Disclaimer: true (erinome) X-AV-Checked: ClamAV using ClamSMTP (erinome) X-AV-Checked: ClamAV using ClamSMTP (mail1) Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org Sender: <mchehab@pedra> |
Commit Message
Michael Jones
March 3, 2011, 4:06 p.m. UTC
On 03/02/2011 08:18 PM, Laurent Pinchart wrote: > Hi Michael, > > On Tuesday 01 March 2011 17:41:01 Michael Jones wrote: >> Hi all, >> >> I get a warning about a cache error with the following steps: >> >> 0. load omap3-isp >> 1. set up media broken media pipeline. (e.g. set different formats on >> opposite ends of a link, as will be the case for using the lane shifter) >> 2. try to capture images. isp_video_streamon() returns -EPIPE from the >> failed isp_video_validate_pipeline() call. >> 3. unload omap3-isp module >> >> then I get the following from kmem_cache_destroy(): >> >> slab error in kmem_cache_destroy(): cache `iovm_area_cache': Can't free all >> objects [<c0040318>] (unwind_backtrace+0x0/0xec) from [<c00bfe14>] >> (kmem_cache_destroy+0x88/0xf4) [<c00bfe14>] (kmem_cache_destroy+0x88/0xf4) >> from [<c00861f8>] (sys_delete_module+0x1c4/0x230) [<c00861f8>] >> (sys_delete_module+0x1c4/0x230) from [<c003b680>] >> (ret_fast_syscall+0x0/0x30) >> >> Then, when reloading the module: >> SLAB: cache with size 32 has lost its name >> >> Can somebody else confirm that they also observe this behavior? > > I can't reproduce that (tried both 2.6.32 and 2.6.37). Could you give me some > more details about your exact test procedure (such as how you configure the > pipeline) ? > Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either. It's actually not related to mis-configuring the ISP pipeline like I thought at first- it also happens after I have successfully captured images. I've since tracked down the problem, although I don't understand the cache management well enough to be sure it's a proper fix, so hopefully some new recipients on this can make suggestions/comments. The patch below solves the problem, which modifies a commit by Fernando Guzman Lugo from December. -Michael From db35fb8edca2a4f8fd37197d77fd58676cb1dcac Mon Sep 17 00:00:00 2001 From: Michael Jones <michael.jones@matrix-vision.de> Date: Thu, 3 Mar 2011 16:50:39 +0100 Subject: [PATCH] fix iovmm slab cache error on module unload modify "OMAP: iommu: create new api to set valid da range" This modifies commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb. --- arch/arm/plat-omap/iovmm.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
Comments
Hi Michael, Michael Jones wrote: > On 03/02/2011 08:18 PM, Laurent Pinchart wrote: >> Hi Michael, >> >> On Tuesday 01 March 2011 17:41:01 Michael Jones wrote: >>> Hi all, >>> >>> I get a warning about a cache error with the following steps: >>> >>> 0. load omap3-isp >>> 1. set up media broken media pipeline. (e.g. set different formats on >>> opposite ends of a link, as will be the case for using the lane shifter) >>> 2. try to capture images. isp_video_streamon() returns -EPIPE from the >>> failed isp_video_validate_pipeline() call. >>> 3. unload omap3-isp module >>> >>> then I get the following from kmem_cache_destroy(): >>> >>> slab error in kmem_cache_destroy(): cache `iovm_area_cache': Can't free all >>> objects [<c0040318>] (unwind_backtrace+0x0/0xec) from [<c00bfe14>] >>> (kmem_cache_destroy+0x88/0xf4) [<c00bfe14>] (kmem_cache_destroy+0x88/0xf4) >>> from [<c00861f8>] (sys_delete_module+0x1c4/0x230) [<c00861f8>] >>> (sys_delete_module+0x1c4/0x230) from [<c003b680>] >>> (ret_fast_syscall+0x0/0x30) >>> >>> Then, when reloading the module: >>> SLAB: cache with size 32 has lost its name >>> >>> Can somebody else confirm that they also observe this behavior? >> >> I can't reproduce that (tried both 2.6.32 and 2.6.37). Could you give me some >> more details about your exact test procedure (such as how you configure the >> pipeline) ? >> > > Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch > based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either. > It's actually not related to mis-configuring the ISP pipeline like I > thought at first- it also happens after I have successfully captured images. > > I've since tracked down the problem, although I don't understand the > cache management well enough to be sure it's a proper fix, so hopefully > some new recipients on this can make suggestions/comments. > > The patch below solves the problem, which modifies a commit by Fernando > Guzman Lugo from December. Thanks for the patch. It looks like this patch from Fernando, perhaps unintentionally, also makes the first page mappable so the NULL address is also valid. The NULL address isn't considered valid by the ISP driver which thus does not iommu_vunmap() the NULL address. Hiroshi, David, what do you think? I think the patch is correct so it could be applied with description changed to mention it disallows mapping the first page again. Or is there a reason to allow mapping the first page automatically? I personally don't see any. Cheers, > From db35fb8edca2a4f8fd37197d77fd58676cb1dcac Mon Sep 17 00:00:00 2001 > From: Michael Jones <michael.jones@matrix-vision.de> > Date: Thu, 3 Mar 2011 16:50:39 +0100 > Subject: [PATCH] fix iovmm slab cache error on module unload > > modify "OMAP: iommu: create new api to set valid da range" > > This modifies commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb. > --- > arch/arm/plat-omap/iovmm.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c > index 6dc1296..2fba6f1 100644 > --- a/arch/arm/plat-omap/iovmm.c > +++ b/arch/arm/plat-omap/iovmm.c > @@ -280,7 +280,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da, > alignement = PAGE_SIZE; > > if (flags & IOVMF_DA_ANON) { > - start = obj->da_start; > + /* > + * Reserve the first page for NULL > + */ > + start = obj->da_start + PAGE_SIZE; > > if (flags & IOVMF_LINEAR) > alignement = iopgsz_max(bytes);
From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com> Subject: Re: omap3isp cache error when unloading Date: Fri, 4 Mar 2011 09:38:22 +0200 > Hi Michael, > > Michael Jones wrote: >> On 03/02/2011 08:18 PM, Laurent Pinchart wrote: >>> Hi Michael, >>> >>> On Tuesday 01 March 2011 17:41:01 Michael Jones wrote: >>>> Hi all, >>>> >>>> I get a warning about a cache error with the following steps: >>>> >>>> 0. load omap3-isp >>>> 1. set up media broken media pipeline. (e.g. set different formats on >>>> opposite ends of a link, as will be the case for using the lane shifter) >>>> 2. try to capture images. isp_video_streamon() returns -EPIPE from the >>>> failed isp_video_validate_pipeline() call. >>>> 3. unload omap3-isp module >>>> >>>> then I get the following from kmem_cache_destroy(): >>>> >>>> slab error in kmem_cache_destroy(): cache `iovm_area_cache': Can't free all >>>> objects [<c0040318>] (unwind_backtrace+0x0/0xec) from [<c00bfe14>] >>>> (kmem_cache_destroy+0x88/0xf4) [<c00bfe14>] (kmem_cache_destroy+0x88/0xf4) >>>> from [<c00861f8>] (sys_delete_module+0x1c4/0x230) [<c00861f8>] >>>> (sys_delete_module+0x1c4/0x230) from [<c003b680>] >>>> (ret_fast_syscall+0x0/0x30) >>>> >>>> Then, when reloading the module: >>>> SLAB: cache with size 32 has lost its name >>>> >>>> Can somebody else confirm that they also observe this behavior? >>> >>> I can't reproduce that (tried both 2.6.32 and 2.6.37). Could you give me some >>> more details about your exact test procedure (such as how you configure the >>> pipeline) ? >>> >> >> Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch >> based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either. >> It's actually not related to mis-configuring the ISP pipeline like I >> thought at first- it also happens after I have successfully captured images. >> >> I've since tracked down the problem, although I don't understand the >> cache management well enough to be sure it's a proper fix, so hopefully >> some new recipients on this can make suggestions/comments. >> >> The patch below solves the problem, which modifies a commit by Fernando >> Guzman Lugo from December. > > Thanks for the patch. > > It looks like this patch from Fernando, perhaps unintentionally, also > makes the first page mappable so the NULL address is also valid. The > NULL address isn't considered valid by the ISP driver which thus does > not iommu_vunmap() the NULL address. > > Hiroshi, David, what do you think? I think the patch is correct so it > could be applied with description changed to mention it disallows > mapping the first page again. > > Or is there a reason to allow mapping the first page automatically? I > personally don't see any. I think that was done "unintentionally". The invalid first page may be quite reasonable generally. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, [snip] > Sorry, I should've mentioned: I'm using your media-0005-omap3isp branch > based on 2.6.38-rc5. I didn't have the problem with 2.6.37, either. > It's actually not related to mis-configuring the ISP pipeline like I > thought at first- it also happens after I have successfully captured images. > > I've since tracked down the problem, although I don't understand the > cache management well enough to be sure it's a proper fix, so hopefully > some new recipients on this can make suggestions/comments. > > The patch below solves the problem, which modifies a commit by Fernando > Guzman Lugo from December. > > -Michael > > From db35fb8edca2a4f8fd37197d77fd58676cb1dcac Mon Sep 17 00:00:00 2001 > From: Michael Jones <michael.jones@matrix-vision.de> > Date: Thu, 3 Mar 2011 16:50:39 +0100 > Subject: [PATCH] fix iovmm slab cache error on module unload > > modify "OMAP: iommu: create new api to set valid da range" > > This modifies commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb. > --- > arch/arm/plat-omap/iovmm.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c > index 6dc1296..2fba6f1 100644 > --- a/arch/arm/plat-omap/iovmm.c > +++ b/arch/arm/plat-omap/iovmm.c > @@ -280,7 +280,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da, > alignement = PAGE_SIZE; > > if (flags & IOVMF_DA_ANON) { > - start = obj->da_start; > + /* > + * Reserve the first page for NULL > + */ > + start = obj->da_start + PAGE_SIZE; IMO if obj->da_start != 0, no need to add PAGE_SIZE. Otherwise, it does make sense to correct wrong obj->da_start == 0. Another thing is this piece of code is using alignement (alignment) variable instead of PAGE_SIZE (which is the same value). Br, David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 6dc1296..2fba6f1 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -280,7 +280,10 @@ static struct iovm_struct *alloc_iovm_area(struct iommu *obj, u32 da, alignement = PAGE_SIZE; if (flags & IOVMF_DA_ANON) { - start = obj->da_start; + /* + * Reserve the first page for NULL + */ + start = obj->da_start + PAGE_SIZE; if (flags & IOVMF_LINEAR) alignement = iopgsz_max(bytes);