Re: omap3isp cache error when unloading

Hiroshi DOYU
2011-03-04T10:07:36Z

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.