Re: [PATCH] string.h: work around for increased stack usage

[Andrew Morton]

On Tue,  5 Dec 2017 22:51:19 +0100 Arnd Bergmann  wrote:

> The hardened strlen() function causes rather large stack usage in at
> least one file in the kernel, in particular when CONFIG_KASAN is enabled:
> 
> drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init':
> drivers/media/usb/em28xx/em28xx-dvb.c:2062:1: error: the frame size of 3256 
> bytes is larger than 204 bytes [-Werror=frame-larger-than=]
> 
> Analyzing this problem led to the discovery that gcc fails to merge the
> stack slots for the i2c_board_info[] structures after we strlcpy() into
> them, due to the 'noreturn' attribute on the source string length check.
> 
> I reported this as a gcc bug, but it is unlikely to get fixed for gcc-8,
> since it is relatively easy to work around, and it gets triggered rarely.
> An earlier workaround I did added an empty inline assembly statement
> before the call to fortify_panic(), which works surprisingly well,
> but is really ugly and unintuitive.
> 
> This is a new approach to the same problem, this time addressing it by
> not calling the 'extern __real_strnlen()' function for string constants
> where __builtin_strlen() is a compile-time constant and therefore known
> to be safe. We do this by checking if the last character in the string
> is a compile-time constant '\0'. If it is, we can assume that
> strlen() of the string is also constant. As a side-effect, this should
> also improve the object code output for any other call of strlen()
> on a string constant.
> 
> Cc: sta...@vger.kernel.org

I'll add

Fixes: 6974f0c4555 ("include/linux/string.h: add the option of fortified 
string.h functions")

to simplify stable@'s life.

> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
> Link: https://patchwork.kernel.org/patch/9980413/
> Link: https://patchwork.kernel.org/patch/9974047/
> Signed-off-by: Arnd Bergmann 
>
> ...
>
> --- a/include/linux/string.h
> +++ b/include/linux/string.h
> @@ -259,7 +259,8 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
>  {
>   __kernel_size_t ret;
>   size_t p_size = __builtin_object_size(p, 0);
> - if (p_size == (size_t)-1)
> + if (p_size == (size_t)-1 ||
> + (__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
>   return __builtin_strlen(p);
>   ret = strnlen(p, p_size);
>   if (p_size <= ret)

Let's have some sympathy for our poor readers?

--- a/include/linux/string.h~stringh-work-around-for-increased-stack-usage-fix
+++ a/include/linux/string.h
@@ -259,6 +259,8 @@ __FORTIFY_INLINE __kernel_size_t strlen(
 {
__kernel_size_t ret;
size_t p_size = __builtin_object_size(p, 0);
+
+   /* Work around gcc excess stack consumption issue */
if (p_size == (size_t)-1 ||
(__builtin_constant_p(p[p_size - 1]) && p[p_size - 1] == '\0'))
return __builtin_strlen(p);
_

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

[Andrew Morton]

On Fri, 27 May 2016 23:23:25 +0200 Arnd Bergmann  wrote:

> Most users of IS_ERR_VALUE() in the kernel are wrong, as they
> pass an 'int' into a function that takes an 'unsigned long'
> argument. This happens to work because the type is sign-extended
> on 64-bit architectures before it gets converted into an
> unsigned type.
> 
> However, anything that passes an 'unsigned short' or 'unsigned int'
> argument into IS_ERR_VALUE() is guaranteed to be broken, as are
> 8-bit integers and types that are wider than 'unsigned long'.
> 
> Andrzej Hajda has already fixed a lot of the worst abusers that
> were causing actual bugs, but it would be nice to prevent any
> users that are not passing 'unsigned long' arguments.
> 
> This patch changes all users of IS_ERR_VALUE() that I could find
> on 32-bit ARM randconfig builds and x86 allmodconfig. For the
> moment, this doesn't change the definition of IS_ERR_VALUE()
> because there are probably still architecture specific users
> elsewhere.

So you do plan to add some sort of typechecking into IS_ERR_VALUE()?

> Almost all the warnings I got are for files that are better off
> using 'if (err)' or 'if (err < 0)'.
> The only legitimate user I could find that we get a warning for
> is the (32-bit only) freescale fman driver, so I did not remove
> the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
> For 9pfs, I just worked around one user whose calling conventions
> are so obscure that I did not dare change the behavior.
> 
> I was using this definition for testing:
> 
>  #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
>unlikely((unsigned long long)(x) >= (unsigned long 
> long)(typeof(x))-MAX_ERRNO))
> 
> which ends up making all 16-bit or wider types work correctly with
> the most plausible interpretation of what IS_ERR_VALUE() was supposed
> to return according to its users, but also causes a compile-time
> warning for any users that do not pass an 'unsigned long' argument.
> 
> I suggested this approach earlier this year, but back then we ended
> up deciding to just fix the users that are obviously broken. After
> the initial warning that caused me to get involved in the discussion
> (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
> asked me to send the whole thing again.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] lib: scatterlist: add sg splitting function

[Andrew Morton]

On Mon, 24 Aug 2015 14:15:08 -0600 Jens Axboe ax...@kernel.dk wrote:

 On 08/08/2015 02:44 AM, Robert Jarzmik wrote:
  Sometimes a scatter-gather has to be split into several chunks, or sub
  scatter lists. This happens for example if a scatter list will be
  handled by multiple DMA channels, each one filling a part of it.
 
  A concrete example comes with the media V4L2 API, where the scatter list
  is allocated from userspace to hold an image, regardless of the
  knowledge of how many DMAs will fill it :
- in a simple RGB565 case, one DMA will pump data from the camera ISP
  to memory
- in the trickier YUV422 case, 3 DMAs will pump data from the camera
  ISP pipes, one for pipe Y, one for pipe U and one for pipe V
 
  For these cases, it is necessary to split the original scatter list into
  multiple scatter lists, which is the purpose of this patch.
 
  The guarantees that are required for this patch are :
- the intersection of spans of any couple of resulting scatter lists is
  empty.
- the union of spans of all resulting scatter lists is a subrange of
  the span of the original scatter list.
- streaming DMA API operations (mapping, unmapping) should not happen
  both on both the resulting and the original scatter list. It's either
  the first or the later ones.
- the caller is reponsible to call kfree() on the resulting
  scatterlists.
 
  Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
 
 I think this looks fine. But do we really need the Kconfig option? It's 
 not a lot of code, and it seems silly to put the onus on the driver for 
 having to enable something that is a subset of the SG api.

Blame me for that.  It's so that all kernels don't need to carry a lump
of code which only a small number of media drivers actually use.

The tradeoff is a bit of once-off build-time effort versus a permanent
runtime gain for many systems.  That's a good tradeoff.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2] lib: scatterlist: add sg splitting function

[Andrew Morton]

On Tue, 04 Aug 2015 19:04:36 +0200 Robert Jarzmik robert.jarz...@free.fr 
wrote:

 Andrew Morton a...@linux-foundation.org writes:
 
   include/linux/scatterlist.h |   5 ++
   lib/scatterlist.c   | 189 
  
   2 files changed, 194 insertions(+)
 
  It's quite a bit of code for a fairly specialised thing.  How ugly
  would it be to put this in a new .c file and have subsystems select it
  in Kconfig?
 I have no idea about the ugliness, but why not ...
 
 If nobody objects, and in order to submit a proper patch, there are decisions 
 to
 make :
  - what will be the scope of this new .c file ?
- only sg_plit() ?
- all sg specialized functions, ie. sg_lib.c ?

Just sg_split I'd say.  It's a logical unit.  Other things can be moved
elsewhere later as cleanups/optimisations, but that's all off-topic.

  - will include/linux/scatterlist.h have an ifdefed portion for what X.c
offers ?

I prefer to avoid the ifdefs.  This means that the error is reported at
link-time rather than compile-time but that's a pretty small cost and
it's a once-off inconvenience, whereas messy/complex header files are
permanent.

  - what naming for X.c and the config entry ?

um, CONFIG_SG_SPLIT and sg_split.c?

 What about adding this to lib/Makefile, and one ifdef to scatterlist.h ? :
  obj-$(CONFIG_SG_LIB) += sg_lib.o

It would be obj-$(CONFIG_SG_SPLIT) += sg_split.o
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2] lib: scatterlist: add sg splitting function

[Andrew Morton]

On Sat,  1 Aug 2015 15:17:13 +0200 Robert Jarzmik robert.jarz...@free.fr 
wrote:

 Sometimes a scatter-gather has to be split into several chunks, or sub scatter
 lists. This happens for example if a scatter list will be handled by multiple
 DMA channels, each one filling a part of it.
 
 A concrete example comes with the media V4L2 API, where the scatter list is
 allocated from userspace to hold an image, regardless of the knowledge of how
 many DMAs will fill it :
  - in a simple RGB565 case, one DMA will pump data from the camera ISP to 
 memory
  - in the trickier YUV422 case, 3 DMAs will pump data from the camera ISP 
 pipes,
one for pipe Y, one for pipe U and one for pipe V
 
 For these cases, it is necessary to split the original scatter list into
 multiple scatter lists, which is the purpose of this patch.
 
 ...

  include/linux/scatterlist.h |   5 ++
  lib/scatterlist.c   | 189 
 
  2 files changed, 194 insertions(+)

It's quite a bit of code for a fairly specialised thing.  How ugly
would it be to put this in a new .c file and have subsystems select it
in Kconfig?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mm: Provide new get_vaddr_frames() helper

[Andrew Morton]

On Fri, 17 Jul 2015 12:23:40 +0200 Hans Verkuil hverk...@xs4all.nl wrote:

 On 07/13/2015 04:55 PM, Jan Kara wrote:
  From: Jan Kara j...@suse.cz
  
  Provide new function get_vaddr_frames().  This function maps virtual
  addresses from given start and fills given array with page frame numbers of
  the corresponding pages. If given start belongs to a normal vma, the 
  function
  grabs reference to each of the pages to pin them in memory. If start
  belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
  must make sure pfns aren't reused for anything else while he is using
  them.
  
  This function is created for various drivers to simplify handling of
  their buffers.
  
  Acked-by: Mel Gorman mgor...@suse.de
  Acked-by: Vlastimil Babka vba...@suse.cz
  Signed-off-by: Jan Kara j...@suse.cz
 
 I'd like to see an Acked-by from Andrew or mm-maintainers before I merge this.

I think I already acked this but it got lost.

Acked-by: Andrew Morton a...@linux-foundation.org
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] Helper to abstract vma handling in media layer

[Andrew Morton]

On Wed, 10 Jun 2015 06:20:43 -0300 Mauro Carvalho Chehab 
mche...@osg.samsung.com wrote:

 I received this patch series with a new set of helper functions for
 mm, together with changes for media and DRM drivers.
 
 As this stuff is actually mm code, I prefer if this got merged via
 your tree.
 
 Could you please handle it? Please notice that patch 8 actually changes
 the exynos DRM driver, but it misses ack from DRM people.

I'm now getting large rejects from many of these patches.  It seems
that someone has recently removed a patch from linux-next, and that
patch added down_read(mmap_sem) and up_read(mmap_sem) to the same
functions which this patch series is altering.

I started fixing them all up but I got bored, and I'm not very
confident in the end result.

It was a particularly bad time to be making these sorts of changes. 
Does anyone know what's happening?
--
To unsubscribe from this list: send the line unsubscribe linux-media in

Re: [PATCH 0/9] Helper to abstract vma handling in media layer

[Andrew Morton]

On Thu, 11 Jun 2015 11:08:47 +0200 Hans Verkuil hverk...@xs4all.nl wrote:

 I discovered a regression on a prerequisite patch merged in the media
 tree that until solved prevents parts of this patch series from going in.
 
 See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg89538.html
 
 Jan is on vacation, and I don't know if I have time this weekend to dig
 into this, so the patch that caused the regression may have to be reverted
 for 4.2 and the vb2 patches in this series postponed until the regression
 problem is fixed.
 
 Note that this is all v4l/vb2 related, the get_vaddr_frames helper is actually
 fine and could be merged, it's just the vb2 patches in this patch series that
 cannot be merged for now due to deadlocks.

OK, thanks.  I'll just keep these patches on hold (in -next) until
advised otherwise?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mm: Provide new get_vaddr_frames() helper

[Andrew Morton]

On Tue, 2 Jun 2015 17:23:00 +0200 Jan Kara j...@suse.cz wrote:

  That's a lump of new code which many kernels won't be needing.  Can we
  put all this in a new .c file and select it within drivers/media
  Kconfig?
   So the attached patch should do what you had in mind. OK?

lgtm.

  drivers/gpu/drm/exynos/Kconfig  |   1 +
  drivers/media/platform/omap/Kconfig |   1 +
  drivers/media/v4l2-core/Kconfig |   1 +
  mm/Kconfig  |   3 +
  mm/Makefile |   1 +
  mm/frame-vec.c  | 233 
 

But frame_vector.c would be a more pleasing name.  For `struct frame_vector'.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mm: Provide new get_vaddr_frames() helper

[Andrew Morton]

On Wed, 13 May 2015 15:08:08 +0200 Jan Kara j...@suse.cz wrote:

 Provide new function get_vaddr_frames().  This function maps virtual
 addresses from given start and fills given array with page frame numbers of
 the corresponding pages. If given start belongs to a normal vma, the function
 grabs reference to each of the pages to pin them in memory. If start
 belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
 must make sure pfns aren't reused for anything else while he is using
 them.
 
 This function is created for various drivers to simplify handling of
 their buffers.
 
 Acked-by: Mel Gorman mgor...@suse.de
 Acked-by: Vlastimil Babka vba...@suse.cz
 Signed-off-by: Jan Kara j...@suse.cz
 ---
  include/linux/mm.h |  44 +++
  mm/gup.c   | 226 
 +

That's a lump of new code which many kernels won't be needing.  Can we
put all this in a new .c file and select it within drivers/media
Kconfig?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fix _IOC_TYPECHECK sparse error

[Andrew Morton]

On Fri, 09 May 2014 09:43:58 +0200 Hans Verkuil hverk...@xs4all.nl wrote:

 Andrew, can you merge this for 3.15 or 3.16 (you decide)? While it fixes a 
 sparse error
 for the media subsystem, it is not really appropriate to go through our media 
 tree.
 
 Thanks,
 
   Hans
 
 
 When running sparse over drivers/media/v4l2-core/v4l2-ioctl.c I get these
 errors:
 
 drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant 
 expression
 drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error: bad integer constant 
 expression
 drivers/media/v4l2-core/v4l2-ioctl.c:2045:9: error: bad integer constant 
 expression
 drivers/media/v4l2-core/v4l2-ioctl.c:2046:9: error: bad integer constant 
 expression
 
 etc.
 
 The root cause of that turns out to be in include/asm-generic/ioctl.h:
 
 #include uapi/asm-generic/ioctl.h
 
 /* provoke compile error for invalid uses of size argument */
 extern unsigned int __invalid_size_argument_for_IOC;
 #define _IOC_TYPECHECK(t) \
 ((sizeof(t) == sizeof(t[1])  \
   sizeof(t)  (1  _IOC_SIZEBITS)) ? \
   sizeof(t) : __invalid_size_argument_for_IOC)
 
 If it is defined as this (as is already done if __KERNEL__ is not defined):
 
 #define _IOC_TYPECHECK(t) (sizeof(t))
 
 then all is well with the world.
 
 This patch allows sparse to work correctly.
 
 --- a/include/asm-generic/ioctl.h
 +++ b/include/asm-generic/ioctl.h
 @@ -3,10 +3,15 @@
  
  #include uapi/asm-generic/ioctl.h
  
 +#ifdef __CHECKER__
 +#define _IOC_TYPECHECK(t) (sizeof(t))
 +#else
  /* provoke compile error for invalid uses of size argument */
  extern unsigned int __invalid_size_argument_for_IOC;
  #define _IOC_TYPECHECK(t) \
   ((sizeof(t) == sizeof(t[1])  \
 sizeof(t)  (1  _IOC_SIZEBITS)) ? \
 sizeof(t) : __invalid_size_argument_for_IOC)
 +#endif
 +
  #endif /* _ASM_GENERIC_IOCTL_H */

Can't we use BUILD_BUG_ON() here?  That's neater, more standard and
BUILD_BUG_ON() already has sparse handling.  
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] nommu: remap_pfn_range: fix addr parameter check

[Andrew Morton]

On Thu, 13 Sep 2012 10:40:57 +0800
Bob Liu lliu...@gmail.com wrote:

 The addr parameter may not page aligned eg. when it's come from
 vfb_mmap():vma-vm_start in video driver.
 
 This patch fix the check in remap_pfn_range() else some driver like v4l2 will
 fail in this function while calling mmap() on nommu arch like blackfin and st.
 
 Reported-by: Bhupesh SHARMA bhupesh.sha...@st.com
 Reported-by: Scott Jiang scott.jiang.li...@gmail.com
 Signed-off-by: Bob Liu lliu...@gmail.com
 ---
  mm/nommu.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/mm/nommu.c b/mm/nommu.c
 index d4b0c10..5d6068b 100644
 --- a/mm/nommu.c
 +++ b/mm/nommu.c
 @@ -1819,7 +1819,7 @@ struct page *follow_page(struct vm_area_struct *vma, 
 unsigned long address,
  int remap_pfn_range(struct vm_area_struct *vma, unsigned long addr,
   unsigned long pfn, unsigned long size, pgprot_t prot)
  {
 - if (addr != (pfn  PAGE_SHIFT))
 + if ((addr  PAGE_MASK) != (pfn  PAGE_SHIFT))
   return -EINVAL;
  
   vma-vm_flags |= VM_IO | VM_RESERVED | VM_PFNMAP;

hm, what is the right thing to do here?

Yes, the MMU version of remap_pfn_range() does permit non-page-aligned
`addr' (at least, if the userspace maaping is a non-COW one).  But I
suspect that was an implementation accident - it is a nonsensical thing
to do, isn't it?  The MMU cannot map a bunch of kernel pages onto a
non-page-aligned userspace address.

So I'm thinking that we should declare ((addr  ~PAGE_MASK) != 0) to be
a caller bug, and fix up this regrettably unidentified v4l driver?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/9] string: introduce memweight

[Andrew Morton]

On Sat,  9 Jun 2012 09:50:30 +0900
Akinobu Mita akinobu.m...@gmail.com wrote:

 memweight() is the function that counts the total number of bits set
 in memory area.  Unlike bitmap_weight(), memweight() takes pointer
 and size in bytes to specify a memory area which does not need to be
 aligned to long-word boundary.
 
 ...

 +/**
 + * memweight - count the total number of bits set in memory area
 + * @ptr: pointer to the start of the area
 + * @bytes: the size of the area
 + */
 +size_t memweight(const void *ptr, size_t bytes)
 +{
 + size_t w = 0;

Calling the return value ret is a useful convention and fits well here.

 + size_t longs;
 + const unsigned char *bitmap = ptr;
 +
 + for (; bytes  0  ((unsigned long)bitmap) % sizeof(long);
 + bytes--, bitmap++)
 + w += hweight8(*bitmap);
 +
 + longs = bytes / sizeof(long);
 + if (longs) {
 + BUG_ON(longs = INT_MAX / BITS_PER_LONG);
 + w += bitmap_weight((unsigned long *)bitmap,
 + longs * BITS_PER_LONG);
 + bytes -= longs * sizeof(long);
 + bitmap += longs * sizeof(long);
 + }
 + /*
 +  * The reason that this last loop is distinct from the preceding
 +  * bitmap_weight() call is to compute 1-bits in the last region smaller
 +  * than sizeof(long) properly on big-endian systems.
 +  */
 + for (; bytes  0; bytes--, bitmap++)
 + w += hweight8(*bitmap);
 +
 + return w;
 +}
 +EXPORT_SYMBOL(memweight);

diff -puN lib/string.c~string-introduce-memweight-fix lib/string.c
--- a/lib/string.c~string-introduce-memweight-fix
+++ a/lib/string.c
@@ -833,18 +833,18 @@ EXPORT_SYMBOL(memchr_inv);
  */
 size_t memweight(const void *ptr, size_t bytes)
 {
-   size_t w = 0;
+   size_t ret = 0;
size_t longs;
const unsigned char *bitmap = ptr;
 
for (; bytes  0  ((unsigned long)bitmap) % sizeof(long);
bytes--, bitmap++)
-   w += hweight8(*bitmap);
+   ret += hweight8(*bitmap);
 
longs = bytes / sizeof(long);
if (longs) {
BUG_ON(longs = INT_MAX / BITS_PER_LONG);
-   w += bitmap_weight((unsigned long *)bitmap,
+   ret += bitmap_weight((unsigned long *)bitmap,
longs * BITS_PER_LONG);
bytes -= longs * sizeof(long);
bitmap += longs * sizeof(long);
@@ -855,8 +855,8 @@ size_t memweight(const void *ptr, size_t
 * than sizeof(long) properly on big-endian systems.
 */
for (; bytes  0; bytes--, bitmap++)
-   w += hweight8(*bitmap);
+   ret += hweight8(*bitmap);
 
-   return w;
+   return ret;
 }
 EXPORT_SYMBOL(memweight);
_

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] scatterlist: add sg_alloc_table_from_pages function

[Andrew Morton]

On Mon, 21 May 2012 16:01:50 +0200
Tomasz Stanislawski t.stanisl...@samsung.com wrote:

  +int sg_alloc_table_from_pages(struct sg_table *sgt,
  +  struct page **pages, unsigned int n_pages,
  +  unsigned long offset, unsigned long size,
  +  gfp_t gfp_mask)
  
  I guess a 32-bit n_pages is OK.  A 16TB IO seems enough ;)
  
 
 Do you think that 'unsigned long' for offset is too big?
 
 Ad n_pages. Assuming that Moore's law holds it will take
 circa 25 years before the limit of 16 TB is reached :) for
 high-end scatterlist operations.
 Or I can change the type of n_pages to 'unsigned long' now at
 no cost :).

By then it will be Someone Else's Problem ;)

  +{
  +  unsigned int chunks;
  +  unsigned int i;
  
  erk, please choose a different name for this.  When a C programmer sees
  i, he very much assumes it has type int.  Making it unsigned causes
  surprise.
  
  And don't rename it to u!  Let's give it a nice meaningful name.  pageno?
  
 
 The problem is that 'i' is  a natural name for a loop counter.

It's also the natural name for an integer.  If a C programmer sees i,
he thinks int.  It's a Fortran thing ;)

 AFAIK, in the kernel code developers try to avoid Hungarian notation.
 A name of a variable should reflect its purpose, not its type.
 I can change the name of 'i' to 'pageno' and 'j' to 'pageno2' (?)
 but I think it will make the code less reliable.

Well, one could do something radical such as using p.


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv24 00/16] Contiguous Memory Allocator

[Andrew Morton]

On Tue, 03 Apr 2012 16:10:05 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:

 This is (yet another) update of CMA patches.

Looks OK to me.  It's a lot of code.

Please move it into linux-next, and if all is well, ask Linus to pull
the tree into 3.5-rc1.  Please be sure to cc me on that email.

I suggest that you include additional patches which enable CMA as much
as possible on as many architectures as possible so that it gets
maximum coverage testing in linux-next.  Remove those Kconfig patches
when merging upstream.

All this code will probably mess up my tree, but I'll work that out. 
It would be more awkward if the CMA code were to later disappear from
linux-next or were not merged into 3.5-rc1.  Let's avoid that.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv22 14/16] X86: integrate CMA with DMA-mapping subsystem

[Andrew Morton]

On Fri, 17 Feb 2012 20:30:34 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:

 This patch adds support for CMA to dma-mapping subsystem for x86
 architecture that uses common pci-dma/pci-nommu implementation. This
 allows to test CMA on KVM/QEMU and a lot of common x86 boxes.
 
 ...

 --- a/arch/x86/Kconfig
 +++ b/arch/x86/Kconfig
 @@ -31,6 +31,7 @@ config X86
   select ARCH_WANT_OPTIONAL_GPIOLIB
   select ARCH_WANT_FRAME_POINTERS
   select HAVE_DMA_ATTRS
 + select HAVE_DMA_CONTIGUOUS if !SWIOTLB
   select HAVE_KRETPROBES
   select HAVE_OPTPROBES
   select HAVE_FTRACE_MCOUNT_RECORD

I don't think it's compilable at all for x86_64, because that platform
selects SWIOTLB.

After a while I got it to compile for i386.  arm didn't go so well,
partly because arm allmodconfig is presently horked (something to do
with Kconfig not setting PHYS_OFFSET) and partly because arm defconfig
doesn't permit CMA to be set.  Got bored, gave up.

The patchset collides pretty seriously with pending dma api changes and
pending arm changes in linux-next, so I didn't apply anything.  This
will all need to be looked at, please.

I'll make do with reading the patches for now ;)

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv7 PATCH 0/4] Add poll_requested_events() function.

[Andrew Morton]

On Thu,  2 Feb 2012 11:26:53 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 The first version of this patch was posted July 1st, 2011. I really hope that
 it won't take another six months to get a review from a fs developer. As this
 LWN article (http://lwn.net/Articles/450658/) said: 'There has been little
 discussion of the patch; it doesn't seem like there is any real reason for it
 not to go in for 3.1.'
 
 The earliest this can go in now is 3.4. The only reason it takes so long is
 that it has been almost impossible to get a Ack or comments or even just a
 simple reply from the fs developers. That is really frustrating, I'm sorry
 to say.

Yup.  Nobody really maintains the poll/select code.  It happens to sit
under fs/ so nominally belongs to the fs maintainers.  The logs for
fs/select.c seem to show me as the usual committer, but I wouldn't
claim particular expertise in this area - I'm more a tube-unclogger
here.  Probably Al knows the code as well or better than anyone else. 
It's good that he looked at an earlier version of the patches.

fs/eventpoll.c has an identified maintainer, but he has been vigorously
hiding from us for a year or so.  I'm the commit monkey for eventpoll,
in a similar state to fs/select.c.

So ho hum, all we can do is our best.  You're an experienced kernel
developer who has put a lot of work into the code.  I suggest that you
get your preferred version into linux-next ASAP then send Linus a pull
request for 3.4-rc1, explaining the situation.  If the code wasn't
already in linux-next I would put it in -mm today, for 3.4-rc1.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv7 PATCH 2/4] poll: add poll_requested_events() and poll_does_not_wait() functions

[Andrew Morton]

On Thu,  2 Feb 2012 11:26:55 +0100
Hans Verkuil hverk...@xs4all.nl wrote:

 From: Hans Verkuil hans.verk...@cisco.com
 
 In some cases the poll() implementation in a driver has to do different
 things depending on the events the caller wants to poll for. An example is
 when a driver needs to start a DMA engine if the caller polls for POLLIN,
 but doesn't want to do that if POLLIN is not requested but instead only
 POLLOUT or POLLPRI is requested. This is something that can happen in the
 video4linux subsystem.
 
 Unfortunately, the current epoll/poll/select implementation doesn't provide
 that information reliably. The poll_table_struct does have it: it has a key
 field with the event mask. But once a poll() call matches one or more bits
 of that mask any following poll() calls are passed a NULL poll_table_struct
 pointer.
 
 The solution is to set the qproc field to NULL in poll_table_struct once
 poll() matches the events, not the poll_table_struct pointer itself. That
 way drivers can obtain the mask through a new poll_requested_events inline.
 
 The poll_table_struct can still be NULL since some kernel code calls it
 internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
 that case poll_requested_events() returns ~0 (i.e. all events).
 
 Very rarely drivers might want to know whether poll_wait will actually wait.
 If another earlier file descriptor in the set already matched the events the
 caller wanted to wait for, then the kernel will return from the select() call
 without waiting.
 
 A new helper function poll_does_not_wait() is added that drivers can use to
 detect this situation.
 
 Drivers should no longer access any of the poll_table internals, but use the
 poll_requested_events() and poll_does_not_wait() access functions instead.

A way to communicate and enforce this is to rename the relevant fields.  Prepend
a _ to them and add a stern comment.


 Since the behavior of the qproc field changes with this patch (since this
 function pointer can now be NULL when that wasn't possible in the past) I
 have renamed that field from qproc to pq_proc. Any out-of-tree driver that
 uses it will now fail to compile.
 
 Some notes regarding the correctness of this patch: the driver's poll()
 function is called with a 'struct poll_table_struct *wait' argument. This
 pointer may or may not be NULL, drivers can never rely on it being one or
 the other as that depends on whether or not an earlier file descriptor in
 the select()'s fdset matched the requested events.
 
 ...
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv19 00/15] Contiguous Memory Allocator

[Andrew Morton]

On Thu, 26 Jan 2012 15:31:40 +
Arnd Bergmann a...@arndb.de wrote:

 On Thursday 26 January 2012, Marek Szyprowski wrote:
  Welcome everyone!
  
  Yes, that's true. This is yet another release of the Contiguous Memory
  Allocator patches. This version mainly includes code cleanups requested
  by Mel Gorman and a few minor bug fixes.
 
 Hi Marek,
 
 Thanks for keeping up this work! I really hope it works out for the
 next merge window.

Someone please tell me when it's time to start paying attention
again ;)

These patches don't seem to have as many acked-bys and reviewed-bys as
I'd expect.  Given the scope and duration of this, it would be useful
to gather these up.  But please ensure they are real ones - people
sometimes like to ack things without showing much sign of having
actually read them.

Also there is the supreme tag: Tested-by:..  Ohad (at least) has been
testing the code.  Let's mention that.


The patches do seem to have been going round in ever-decreasing circles
lately and I think we have decided to merge them (yes?) so we may as well
get on and do that and sort out remaining issues in-tree.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added

[Andrew Morton]

On Mon, 17 Oct 2011 14:21:07 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:

   +
   +void free_contig_pages(unsigned long pfn, unsigned nr_pages)
   +{
   + struct page *page = pfn_to_page(pfn);
   +
   + while (nr_pages--) {
   + __free_page(page);
   + ++pfn;
   + if (likely(zone_pfn_same_memmap(pfn - 1, pfn)))
   + ++page;
   + else
   + page = pfn_to_page(pfn);
   + }
   +}
  
  You're sure these functions don't need EXPORT_SYMBOL()?  Maybe the
  design is that only DMA core calls into here (if so, that's good).
 
 Drivers should not call it, it is intended to be used by low-level DMA
 code.

OK, thanks for checking.

 Do you think that a comment about missing EXPORT_SYMBOL is 
 required?

No.  If someone later wants to use these from a module then we can look
at their reasons and make a decision at that time.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added

[Andrew Morton]

On Sun, 16 Oct 2011 10:01:36 +0200 Michal Nazarewicz min...@mina86.com 
wrote:

 Still, as I think of it now, maybe alloc_contig_free_range() would be
 better?

Nope.  Of *course* the pages were free.  Otherwise we couldn't
(re)allocate them.  I still think the free part is redundant.

What could be improved is the alloc part.  This really isn't an
allocation operation.  The pages are being removed from buddy then
moved into the free arena of a different memory manager from where they
will _later_ be allocated.

So we should move away from the alloc/free naming altogether for this
operation and think up new terms.  How about claim and release? 
claim_contig_pages, claim_contig_range, release_contig_pages, etc?
Or we could use take/return.

Also, if we have no expectation that anything apart from CMA will use
these interfaces (?), the names could/should be prefixed with cma_.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv16 0/9] Contiguous Memory Allocator

[Andrew Morton]

On Tue, 11 Oct 2011 15:52:04 +0200
Arnd Bergmann a...@arndb.de wrote:

 On Tuesday 11 October 2011, Andrew Morton wrote:
  Russell's going to hate me, but...
  
  I do know that he had substantial objections to at least earlier
  versions of this, and he is a guy who knows of what he speaks.
  
  So I would want to get a nod from rmk on this work before proceeding. 
  If that nod isn't available then let's please identify the issues and
  see what we can do about them.
 
 I'm pretty sure that Russell's concerns were almost entirely about the
 ARM specific parts, which were extremely hard to figure out. The
 most important technical concern back in July was that the patch
 series at the time did not address the problem of conflicting pte
 flags when we remap memory as uncached on ARMv6. He had a patch
 to address this problem that was supposed to get merged in 3.1
 and would have conflicted with the CMA patch set.
 
 Things have changed a lot since then. Russell had to revert his
 own patch because he found regressions using it on older machines.
 However, the current CMA on ARM patch AFAICT reliably fixes this
 problem now and does not cause the same regression on older machines.
 The solution used now is the one we agreed on after sitting together
 for a few hours with Russell, Marek, Paul McKenney and myself.
 
 If there are still concerns over the ARM specific portion of
 the patch series, I'm very confident that we can resolve these
 now (I was much less so before that meeting).
 
 What I would really want to hear from you is your opinion on
 the architecture independent stuff. Obviously, ARM is the
 most important consumer of the patch set, but I think the
 code has its merit on other architectures as well and most of
 them (maybe not parisc) should be about as simple as the x86
 one that Marek posted now with v16.

Having an x86 implementation is good.  It would also be good to get
some x86 drivers using CMA asap, so the thing gets some runtime testing
from the masses.  Can we think of anything we can do here?

Regarding the core MM changes: Mel's the man for migration and
compaction.  I wouldn't want to proceed until he (and perferably
Johannes) have spent some quality time with the code.  I'm not seeing
their reviewed-by's of acked-by's and I don't have a good recollection
of their involvement?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/9] mm: move some functions from memory_hotplug.c to page_isolation.c

[Andrew Morton]

On Thu, 06 Oct 2011 15:54:41 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:

 From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
 
 Memory hotplug is a logic for making pages unused in the specified
 range of pfn. So, some of core logics can be used for other purpose
 as allocating a very large contigous memory block.
 
 This patch moves some functions from mm/memory_hotplug.c to
 mm/page_isolation.c. This helps adding a function for large-alloc in
 page_isolation.c with memory-unplug technique.
 
 Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
 [m.nazarewicz: reworded commit message]
 Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 [m.szyprowski: rebased and updated to Linux v3.0-rc1]
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 CC: Michal Nazarewicz min...@mina86.com
 Acked-by: Arnd Bergmann a...@arndb.de

 ...

 +/*
 + * For migration.
 + */
 +
 +int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn);

This is a rather poor function name.  Given that we're now making it a
global identifier, perhaps we should give it a better name. 
pages_in_single_zone()?

 +unsigned long scan_lru_pages(unsigned long start, unsigned long end);
 +int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
  

 ...

 --- a/mm/page_isolation.c
 +++ b/mm/page_isolation.c
 @@ -5,6 +5,9 @@
  #include linux/mm.h
  #include linux/page-isolation.h
  #include linux/pageblock-flags.h
 +#include linux/memcontrol.h
 +#include linux/migrate.h
 +#include linux/mm_inline.h
  #include internal.h
  
  static inline struct page *
 @@ -139,3 +142,114 @@ int test_pages_isolated(unsigned long start_pfn, 
 unsigned long end_pfn)
   spin_unlock_irqrestore(zone-lock, flags);
   return ret ? 0 : -EBUSY;
  }
 +
 +
 +/*
 + * Confirm all pages in a range [start, end) is belongs to the same zone.

It would be good to fix up that sentence while we're touching it. 
Confirm that all pages ...  belong to the same zone.


 ...

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/9] mm: alloc_contig_freed_pages() added

[Andrew Morton]

On Thu, 06 Oct 2011 15:54:42 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:

 From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
 
 This commit introduces alloc_contig_freed_pages() function

The freed seems redundant to me.  Wouldn't alloc_contig_pages be a
better name?

 which allocates (ie. removes from buddy system) free pages
 in range.  Caller has to guarantee that all pages in range
 are in buddy system.
 
 Along with this function, a free_contig_pages() function is
 provided which frees all (or a subset of) pages allocated
 with alloc_contig_free_pages().
 
 Michal Nazarewicz has modified the function to make it easier
 to allocate not MAX_ORDER_NR_PAGES aligned pages by making it
 return pfn of one-past-the-last allocated page.
 

 ...

 +#if defined(CONFIG_SPARSEMEM)  !defined(CONFIG_SPARSEMEM_VMEMMAP)
 +/*
 + * Both PFNs must be from the same zone!  If this function returns
 + * true, pfn_to_page(pfn1) + (pfn2 - pfn1) == pfn_to_page(pfn2).
 + */
 +static inline bool zone_pfn_same_memmap(unsigned long pfn1, unsigned long 
 pfn2)
 +{
 + return pfn_to_section_nr(pfn1) == pfn_to_section_nr(pfn2);
 +}
 +
 +#else
 +
 +#define zone_pfn_same_memmap(pfn1, pfn2) (true)

Do this in C, please.  It's nicer and can prevent unused-var warnings.

 +#endif
 +

 ...

 +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long 
 end,
 +gfp_t flag)
 +{
 + unsigned long pfn = start, count;
 + struct page *page;
 + struct zone *zone;
 + int order;
 +
 + VM_BUG_ON(!pfn_valid(start));
 + page = pfn_to_page(start);
 + zone = page_zone(page);
 +
 + spin_lock_irq(zone-lock);
 +
 + for (;;) {
 + VM_BUG_ON(page_count(page) || !PageBuddy(page) ||
 +   page_zone(page) != zone);
 +
 + list_del(page-lru);
 + order = page_order(page);
 + count = 1UL  order;
 + zone-free_area[order].nr_free--;
 + rmv_page_order(page);
 + __mod_zone_page_state(zone, NR_FREE_PAGES, -(long)count);

__mod_zone_page_state() generally shouldn't be used - it bypasses the
per-cpu magazines and can introduce high lock contentions.

That's hopefully not an issue on this callpath but it is still a red
flag.  I'd suggest at least the addition of a suitably apologetic code
comment here - we don't want people to naively copy this code.

Plus such a comment would let me know why this was done ;)

 + pfn += count;
 + if (pfn = end)
 + break;
 + VM_BUG_ON(!pfn_valid(pfn));
 +
 + if (zone_pfn_same_memmap(pfn - count, pfn))
 + page += count;
 + else
 + page = pfn_to_page(pfn);
 + }
 +
 + spin_unlock_irq(zone-lock);
 +
 + /* After this, pages in the range can be freed one be one */
 + count = pfn - start;
 + pfn = start;
 + for (page = pfn_to_page(pfn); count; --count) {
 + prep_new_page(page, 0, flag);
 + ++pfn;
 + if (likely(zone_pfn_same_memmap(pfn - 1, pfn)))
 + ++page;
 + else
 + page = pfn_to_page(pfn);
 + }
 +
 + return pfn;
 +}
 +
 +void free_contig_pages(unsigned long pfn, unsigned nr_pages)
 +{
 + struct page *page = pfn_to_page(pfn);
 +
 + while (nr_pages--) {
 + __free_page(page);
 + ++pfn;
 + if (likely(zone_pfn_same_memmap(pfn - 1, pfn)))
 + ++page;
 + else
 + page = pfn_to_page(pfn);
 + }
 +}

You're sure these functions don't need EXPORT_SYMBOL()?  Maybe the
design is that only DMA core calls into here (if so, that's good).


  #ifdef CONFIG_MEMORY_HOTREMOVE
  /*
   * All pages in the range must be isolated before calling this.
 -- 
 1.7.1.569.g6f426
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/9] mm: alloc_contig_range() added

[Andrew Morton]

On Thu, 06 Oct 2011 15:54:43 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:

 From: Michal Nazarewicz m.nazarew...@samsung.com
 
 This commit adds the alloc_contig_range() function which tries
 to allocate given range of pages.  It tries to migrate all
 already allocated pages that fall in the range thus freeing them.
 Once all pages in the range are freed they are removed from the
 buddy system thus allocated for the caller to use.
 
 Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 [m.szyprowski: renamed some variables for easier code reading]
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 CC: Michal Nazarewicz min...@mina86.com
 Acked-by: Arnd Bergmann a...@arndb.de

Where-is: Mel Gorman m...@csn.ul.ie

 +#define MIGRATION_RETRY  5
 +static int __alloc_contig_migrate_range(unsigned long start, unsigned long 
 end)
 +{
 + int migration_failed = 0, ret;
 + unsigned long pfn = start;
 +
 + /*
 +  * Some code borrowed from KAMEZAWA Hiroyuki's
 +  * __alloc_contig_pages().
 +  */
 +
 + /* drop all pages in pagevec and pcp list */
 + lru_add_drain_all();
 + drain_all_pages();

These operations are sometimes wrong ;) Have you confirmed that we
really need to perform them here?  If so, a little comment explaining
why we're using them here would be good.

 + for (;;) {
 + pfn = scan_lru_pages(pfn, end);
 + if (!pfn || pfn = end)
 + break;
 +
 + ret = do_migrate_range(pfn, end);
 + if (!ret) {
 + migration_failed = 0;
 + } else if (ret != -EBUSY
 + || ++migration_failed = MIGRATION_RETRY) {

Sigh, magic numbers.

Have you ever seen this retry loop actually expire in testing?

migrate_pages() tries ten times.  This code tries five times.  Is there
any science to all of this?

 + return ret;
 + } else {
 + /* There are unstable pages.on pagevec. */
 + lru_add_drain_all();
 + /*
 +  * there may be pages on pcplist before
 +  * we mark the range as ISOLATED.
 +  */
 + drain_all_pages();
 + }
 + cond_resched();
 + }
 +
 + if (!migration_failed) {
 + /* drop all pages in pagevec and pcp list */
 + lru_add_drain_all();
 + drain_all_pages();

hm.

 + }
 +
 + /* Make sure all pages are isolated */
 + if (WARN_ON(test_pages_isolated(start, end)))
 + return -EBUSY;
 +
 + return 0;
 +}
 +
 +/**
 + * alloc_contig_range() -- tries to allocate given range of pages
 + * @start:   start PFN to allocate
 + * @end: one-past-the-last PFN to allocate
 + * @flags:   flags passed to alloc_contig_freed_pages().
 + *
 + * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
 + * aligned, hovewer it's callers responsibility to guarantee that we

however

however it is the caller's responsibility..

 + * are the only thread that changes migrate type of pageblocks the
 + * pages fall in.
 + *
 + * Returns zero on success or negative error code.  On success all
 + * pages which PFN is in (start, end) are allocated for the caller and
 + * need to be freed with free_contig_pages().
 + */

 ...


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/9] mm: MIGRATE_CMA migration type added

[Andrew Morton]

On Thu, 06 Oct 2011 15:54:44 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:

 From: Michal Nazarewicz m.nazarew...@samsung.com
 
 The MIGRATE_CMA migration type has two main characteristics:
 (i) only movable pages can be allocated from MIGRATE_CMA
 pageblocks and (ii) page allocator will never change migration
 type of MIGRATE_CMA pageblocks.
 
 This guarantees that page in a MIGRATE_CMA page block can
 always be migrated somewhere else (unless there's no memory left
 in the system).
 
 It is designed to be used with Contiguous Memory Allocator
 (CMA) for allocating big chunks (eg. 10MiB) of physically
 contiguous memory.  Once driver requests contiguous memory,
 CMA will migrate pages from MIGRATE_CMA pageblocks.
 
 To minimise number of migrations, MIGRATE_CMA migration type
 is the last type tried when page allocator falls back to other
 migration types then requested.
 

 ...

 +#ifdef CONFIG_CMA_MIGRATE_TYPE
 +#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
 +#else
 +#  define is_migrate_cma(migratetype) false
 +#endif

Implement in C, please.


 ...

 --- a/mm/compaction.c
 +++ b/mm/compaction.c
 @@ -115,6 +115,16 @@ static bool suitable_migration_target(struct page *page)
   if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
   return false;
  
 + /* Keep MIGRATE_CMA alone as well. */
 + /*
 +  * XXX Revisit.  We currently cannot let compaction touch CMA
 +  * pages since compaction insists on changing their migration
 +  * type to MIGRATE_MOVABLE (see split_free_page() called from
 +  * isolate_freepages_block() above).
 +  */

Talk to us about this.

How serious is this shortcoming in practice?  What would a fix look
like?  Is anyone working on an implementation, or planning to do so?


 + if (is_migrate_cma(migratetype))
 + return false;
 +
   /* If the page is a large free page, then allow migration */
   if (PageBuddy(page)  page_order(page) = pageblock_order)
   return true;

 ...

 +void __init init_cma_reserved_pageblock(struct page *page)
 +{
 + struct page *p = page;
 + unsigned i = pageblock_nr_pages;
 +
 + prefetchw(p);
 + do {
 + if (--i)
 + prefetchw(p + 1);
 + __ClearPageReserved(p);
 + set_page_count(p, 0);
 + } while (++p, i);
 +
 + set_page_refcounted(page);
 + set_pageblock_migratetype(page, MIGRATE_CMA);
 + __free_pages(page, pageblock_order);
 + totalram_pages += pageblock_nr_pages;
 +}

I wonder if the prefetches do any good.  it doesn't seem very important
in an __init function.

 +#endif
  

 ...


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/9] drivers: add Contiguous Memory Allocator

[Andrew Morton]

On Thu, 06 Oct 2011 15:54:46 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:

 The Contiguous Memory Allocator is a set of helper functions for DMA
 mapping framework that improves allocations of contiguous memory chunks.
 
 CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and
 gives back to the system. Kernel is allowed to allocate movable pages
 within CMA's managed memory so that it can be used for example for page
 cache when DMA mapping do not use it. On dma_alloc_from_contiguous()
 request such pages are migrated out of CMA area to free required
 contiguous block and fulfill the request. This allows to allocate large
 contiguous chunks of memory at any time assuming that there is enough
 free memory available in the system.
 
 This code is heavily based on earlier works by Michal Nazarewicz.
 

 ...

 +#ifdef phys_to_pfn
 +/* nothing to do */
 +#elif defined __phys_to_pfn
 +#  define phys_to_pfn __phys_to_pfn
 +#elif defined __va
 +#  define phys_to_pfn(x) page_to_pfn(virt_to_page(__va(x)))
 +#else
 +#  error phys_to_pfn implementation needed
 +#endif

Yikes!

This hackery should not be here, please.  If we need a phys_to_pfn()
then let's write a proper one which lives in core MM and arch, then get
it suitably reviewed and integrated and then maintained.

 +struct cma {
 + unsigned long   base_pfn;
 + unsigned long   count;
 + unsigned long   *bitmap;
 +};
 +
 +struct cma *dma_contiguous_default_area;
 +
 +#ifndef CONFIG_CMA_SIZE_ABSOLUTE
 +#define CONFIG_CMA_SIZE_ABSOLUTE 0
 +#endif
 +
 +#ifndef CONFIG_CMA_SIZE_PERCENTAGE
 +#define CONFIG_CMA_SIZE_PERCENTAGE 0
 +#endif

No, .c files should not #define CONFIG_ variables like this.

One approach is

#ifdef CONFIG_FOO
#define BAR CONFIG_FOO
#else
#define BAR 0
#endif

but that's merely cosmetic fluff.  A superior fix is to get the Kconfig
correct, so CONFIG_FOO cannot ever be undefined if we're compiling this
.c file.

 +static unsigned long size_abs = CONFIG_CMA_SIZE_ABSOLUTE * SZ_1M;
 +static unsigned long size_percent = CONFIG_CMA_SIZE_PERCENTAGE;
 +static long size_cmdline = -1;

Maybe a little documentation for these, explaining their role in
everything?

 +static int __init early_cma(char *p)
 +{
 + pr_debug(%s(%s)\n, __func__, p);
 + size_cmdline = memparse(p, p);
 + return 0;
 +}
 +early_param(cma, early_cma);

Did this get added to Documentation/kernel-parameters.txt?

 +static unsigned long __init __cma_early_get_total_pages(void)

The leading __ seems unnecessay for a static function.

 +{
 + struct memblock_region *reg;
 + unsigned long total_pages = 0;
 +
 + /*
 +  * We cannot use memblock_phys_mem_size() here, because
 +  * memblock_analyze() has not been called yet.
 +  */
 + for_each_memblock(memory, reg)
 + total_pages += memblock_region_memory_end_pfn(reg) -
 +memblock_region_memory_base_pfn(reg);
 + return total_pages;
 +}
 +
 +/**
 + * dma_contiguous_reserve() - reserve area for contiguous memory handling
 + *
 + * This funtion reserves memory from early allocator. It should be
 + * called by arch specific code once the early allocator (memblock or 
 bootmem)
 + * has been activated and all other subsystems have already 
 allocated/reserved
 + * memory.
 + */

Forgot to document the argument.

 +void __init dma_contiguous_reserve(phys_addr_t limit)
 +{
 + unsigned long selected_size = 0;
 + unsigned long total_pages;
 +
 + pr_debug(%s(limit %08lx)\n, __func__, (unsigned long)limit);
 +
 + total_pages = __cma_early_get_total_pages();
 + size_percent *= (total_pages  PAGE_SHIFT) / 100;
 +
 + pr_debug(%s: total available: %ld MiB, size absolute: %ld MiB, size 
 percentage: %ld MiB\n,
 +  __func__, (total_pages  PAGE_SHIFT) / SZ_1M,
 + size_abs / SZ_1M, size_percent / SZ_1M);
 +
 +#ifdef CONFIG_CMA_SIZE_SEL_ABSOLUTE
 + selected_size = size_abs;
 +#elif defined(CONFIG_CMA_SIZE_SEL_PERCENTAGE)
 + selected_size = size_percent;
 +#elif defined(CONFIG_CMA_SIZE_SEL_MIN)
 + selected_size = min(size_abs, size_percent);
 +#elif defined(CONFIG_CMA_SIZE_SEL_MAX)
 + selected_size = max(size_abs, size_percent);
 +#endif

geeze, what's all that stuff?

Whatever it's doing, it seems a bad idea to relegate these decisions to
Kconfig-time.  The vast majority of users don't have control of their
kernel configuration!  The code would be more flexible and generic if
this was done at runtime somehow.

 + if (size_cmdline != -1)
 + selected_size = size_cmdline;
 +
 + if (!selected_size)
 + return;
 +
 + pr_debug(%s: reserving %ld MiB for global area\n, __func__,
 +  selected_size / SZ_1M);
 +
 + dma_declare_contiguous(NULL, selected_size, 0, limit);
 +};
 +

 ...

 +static struct cma *__cma_create_area(unsigned long base_pfn,

s/__//?

 +  unsigned long count)
 +{
 + int bitmap_size = 

Re: [PATCHv16 0/9] Contiguous Memory Allocator

[Andrew Morton]

On Fri, 7 Oct 2011 18:27:06 +0200
Arnd Bergmann a...@arndb.de wrote:

 On Thursday 06 October 2011, Marek Szyprowski wrote:
  Once again I decided to post an updated version of the Contiguous Memory
  Allocator patches.
  
  This version provides mainly a bugfix for a very rare issue that might
  have changed migration type of the CMA page blocks resulting in dropping
  CMA features from the affected page block and causing memory allocation
  to fail. Also the issue reported by Dave Hansen has been fixed.
  
  This version also introduces basic support for x86 architecture, what
  allows wide testing on KVM/QEMU emulators and all common x86 boxes. I
  hope this will result in wider testing, comments and easier merging to
  mainline.
 
 Hi Marek,
 
 I think we need to finally get this into linux-next now, to get some
 broader testing. Having the x86 patch definitely helps here becauses
 it potentially exposes the code to many more testers.
 
 IMHO it would be good to merge the entire series into 3.2, since
 the ARM portion fixes an important bug (double mapping of memory
 ranges with conflicting attributes) that we've lived with for far
 too long, but it really depends on how everyone sees the risk
 for regressions here. If something breaks in unfixable ways before
 the 3.2 release, we can always revert the patches and have another
 try later.
 
 It's also not clear how we should merge it. Ideally the first bunch
 would go through linux-mm, and the architecture specific patches
 through the respective architecture trees, but there is an obvious
 inderdependency between these sets.
 
 Russell, Andrew, are you both comfortable with putting the entire
 set into linux-mm to solve this? Do you see this as 3.2 or rather
 as 3.3 material?
 

Russell's going to hate me, but...

I do know that he had substantial objections to at least earlier
versions of this, and he is a guy who knows of what he speaks.

So I would want to get a nod from rmk on this work before proceeding. 
If that nod isn't available then let's please identify the issues and
see what we can do about them.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFCv4 PATCH 0/6]: add poll_requested_events() function

[Andrew Morton]

On Wed, 5 Oct 2011 09:47:09 +0200
Hans Verkuil hverk...@xs4all.nl wrote:

 On Thursday 29 September 2011 09:44:06 Hans Verkuil wrote:
  This is the fourth version of this patch series, incorporating the comments
  from Andrew Morton: I've split up the multiple-assignment line and added a
  comment explaining the purpose of the new function in poll.h.
  
  It's also rebased to the current staging/for_v3.2 branch of the linux-media
  tree.
  
  There are no other changes compared to the RFCv3 patches.
  
  I'd very much like to get an Acked-by (or additional comments) from Al or
  Andrew! This patch series really should go into v3.2 which is getting
  close.
  
  Normally I would have posted this v4 3 weeks ago, but due to Real Life
  interference in the past few weeks I was unable to. But I'm back, and this
  is currently the highest priority for me.
 
 This is becoming annoying. Andrew, Al, can one of you please Ack this patch 
 or 
 review it? We *really* need this enhancement for our v4l drivers. I've been 
 asking for an ack (or review) for ages and for the most part I got radio 
 silence. Jon Corbet has already reviewed the code in early July (!), so I 
 don't see why this is taking so long.
 
 Mauro needs an ack from one of you before he can merge it.
 

It looks OK to me, but obviously it would be better if Al were to go
through it also.  If he doesn't then there isn't a lot we can do about
it - I suggest that you proceed with the plan to merge it into -rc1.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 3.0.1. imon locking issues?

[Andrew Morton]

(cc's added)

On Sun, 04 Sep 2011 21:02:41 +0200
Anders aerikss...@gmail.com wrote:

 Found this oops produced by kdump here. It seems imon related.
 

 ...

 4[  278.893189] Restarting tasks ... done.
 6[  278.994452] usb 5-1: USB disconnect, device number 2
 3[  278.995191] imon:send_packet: error submitting urb(-19)
 3[  279.16] imon:vfd_write: send packet failed for packet #3
 3[  279.28] imon:vfd_write: no iMON device present
 3[  279.32] imon:vfd_write: no iMON device present
 3[  279.36] imon:vfd_write: no iMON device present
 3[  279.40] imon:vfd_write: no iMON device present
 3[  279.44] imon:vfd_write: no iMON device present
 3[  279.48] imon:vfd_write: no iMON device present
 3[  279.53] imon:vfd_write: no iMON device present
 3[  279.57] imon:vfd_write: no iMON device present
 3[  279.61] imon:vfd_write: no iMON device present
 3[  279.65] imon:vfd_write: no iMON device present
 3[  279.69] imon:vfd_write: no iMON device present
 3[  279.73] imon:vfd_write: no iMON device present
 3[  279.77] imon:vfd_write: no iMON device present
 3[  279.81] imon:vfd_write: no iMON device present
 3[  279.85] imon:vfd_write: no iMON device present
 0[  279.042361] stack segment:  [#1] PREEMPT SMP
 4[  279.042450] CPU 1
 4[  279.042482] Modules linked in: saa7134_alsa tda1004x saa7134_dvb
 videobuf_dvb dvb_core ir_kbd_i2c tda827x ir_lirc_codec lirc_dev tda8290
 ir_sony_decoder tuner ir_jvc_decoder snd_hda_codec_realtek
 ir_rc6_decoder saa7134 videobuf_dma_sg videobuf_core v4l2_common
 rc_imon_mce imon ir_rc5_decoder ir_nec_decoder rc_core videodev
 snd_hda_intel parport_pc snd_hda_codec v4l2_compat_ioctl32 parport
 tveeprom snd_hwdep i2c_piix4 sg pcspkr rtc_cmos atiixp asus_atk0110
 4[  279.043219]
 4[  279.043242] Pid: 1922, comm: LCDd Not tainted 3.0.1-dirty #24
 System manufacturer System Product Name/M2A-VM HDMI
 4[  279.043318] RIP: 0010:[810231bb]  [810231bb]
 mutex_spin_on_owner+0x3e/0x63
 4[  279.043318] RSP: 0018:88004a1c3e00  EFLAGS: 00010246
 4[  279.043318] RAX: 880074118cf0 RBX: 8800725d0020 RCX:
 
 4[  279.043318] RDX: 8800725d0038 RSI: 65766f6d65723d4e RDI:
 8800725d0020
 4[  279.043318] RBP: 65766f6d65723d4e R08:  R09:
 88007308fe40
 4[  279.043318] R10: 0001 R11: 0246 R12:
 
 4[  279.043318] R13: 88004a1c2010 R14: 88004a1c2010 R15:
 0001
 4[  279.043318] FS:  7f9c84ed5700() GS:880077c8()
 knlGS:
 4[  279.043318] CS:  0010 DS:  ES:  CR0: 80050033
 4[  279.043318] CR2: 7eff71e392a0 CR3: 730f9000 CR4:
 06e0
 4[  279.043318] DR0:  DR1:  DR2:
 
 4[  279.043318] DR3:  DR6: 0ff0 DR7:
 0400
 4[  279.043318] Process LCDd (pid: 1922, threadinfo 88004a1c2000,
 task 880074118cf0)
 0[  279.043318] Stack:
 4[  279.043318]  0286 8800725d0020 880074118cf0
 65766f6d65723d4e
 4[  279.043318]   814c14dc 
 8800725d0038
 4[  279.043318]  81048211 88004a1c3ed8 0286
 880074118cf0
 0[  279.043318] Call Trace:
 4[  279.043318]  [814c14dc] ? __mutex_lock_slowpath+0x57/0x17f
 4[  279.043318]  [81048211] ? lock_hrtimer_base+0x1b/0x3c
 4[  279.043318]  [810482d1] ? hrtimer_try_to_cancel+0x63/0x6c
 4[  279.043318]  [814c1404] ? mutex_lock+0x12/0x22
 4[  279.043318]  [814c1a8a] ? do_nanosleep+0x77/0xb0
 4[  279.043318]  [a0100805] ? vfd_write+0x63/0x1bd [imon]
 4[  279.043318]  [8104877d] ? hrtimer_nanosleep+0x9c/0x108
 4[  279.043318]  [810b22cb] ? vfs_write+0xad/0x12e
 4[  279.043318]  [810b2402] ? sys_write+0x45/0x6e
 4[  279.043318]  [814c317b] ? system_call_fastpath+0x16/0x1b
 0[  279.043318] Code: 00 55 48 89 f5 53 48 89 fb 48 83 ec 08 eb 0e 49
 8b 45 00 a8 08 74 04 31 c0 eb 2c f3 90 e8 02 38 05 00 45 31 e4 48 39 6b
 18 75 08
 83[  279.043318]  7d 28 00 41 0f 95 c4 e8 60 48 05 00 45 84 e4 75 d2
 31 c0 48
 1[  279.043318] RIP  [810231bb] mutex_spin_on_owner+0x3e/0x63
 4[  279.043318]  RSP 88004a1c3e00

Yes, vfd_write() appears to have got all confused and passed a garbage
pointer into mutex_lock().

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can you review or ack this patch?

[Andrew Morton]

On Tue, 23 Aug 2011 08:33:25 +0200
Hans Verkuil hverk...@xs4all.nl wrote:

 (and resent again, this time with the correct linux-fsdevel mail address)
 (Resent as requested by Andrew Morton since this is still stuck)
 
 Hi Al, Andrew,
 
 Can you take a look at this patch and send an Ack or review comments?
 
 It's already been reviewed by Jon Corbet and we really need this functionality
 for v3.1. You were in the CC list in earlier postings:
 
 Here: http://www.spinics.net/lists/linux-fsdevel/msg46753.html
 and here: 
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg34546.html
 
 The patch also featured on LWN: http://lwn.net/Articles/450658/
 
 Without your ack Mauro can't upstream this and we have a number of other
 patches that depend on this and are currently blocked.
 
 We would prefer to upstream this patch through the linux-media git tree
 due to these dependencies.
 
 My git branch containing this and the dependent patches is here:
 
 http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/poll
 
 Your help would be greatly appreciated (and your ack even more :-) )!

I'll grab the patch to get it a bit of testing while Al cogitates.

 
 
 [PATCH] poll: add poll_requested_events() function
 
 In some cases the poll() implementation in a driver has to do different
 things depending on the events the caller wants to poll for. An example is
 when a driver needs to start a DMA engine if the caller polls for POLLIN,
 but doesn't want to do that if POLLIN is not requested but instead only
 POLLOUT or POLLPRI is requested. This is something that can happen in the
 video4linux subsystem.
 
 Unfortunately, the current epoll/poll/select implementation doesn't provide
 that information reliably. The poll_table_struct does have it: it has a key
 field with the event mask. But once a poll() call matches one or more bits
 of that mask any following poll() calls are passed a NULL poll_table_struct
 pointer.
 
 The solution is to set the qproc field to NULL in poll_table_struct once
 poll() matches the events, not the poll_table_struct pointer itself. That
 way drivers can obtain the mask through a new poll_requested_events inline.
 
 The poll_table_struct can still be NULL since some kernel code calls it
 internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
 that case poll_requested_events() returns ~0 (i.e. all events).
 
 Since eventpoll always leaves the key field at ~0 instead of using the
 requested events mask, that source was changed as well to properly fill in
 the key field.

It would be nice to find some suitable place in the code where we can
explain all this to other potential users of the capability.  Perhaps
the implementation site for the currently undocumented
poll_requested_events() would be a suitable place.


 ...

 - epi-event.events = event-events;
 + epi-event.events = pt.key = event-events;

coding style nit: we generally try to avoid multiple assignemnts like this.


 ...


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv11 0/8] Contiguous Memory Allocator

[Andrew Morton]

On Tue, 5 Jul 2011 14:07:17 +0200
Arnd Bergmann a...@arndb.de wrote:

 On Tuesday 05 July 2011, Marek Szyprowski wrote:
  This is yet another round of Contiguous Memory Allocator patches. I hope
  that I've managed to resolve all the items discussed during the Memory
  Management summit at Linaro Meeting in Budapest and pointed later on
  mailing lists. The goal is to integrate it as tight as possible with
  other kernel subsystems (like memory management and dma-mapping) and
  finally merge to mainline.
 
 You have certainly addressed all of my concerns, this looks really good now!
 
 Andrew, can you add this to your -mm tree? What's your opinion on the
 current state, do you think this is ready for merging in 3.1 or would
 you want to have more reviews from core memory management people?
 
 My reviews were mostly on the driver and platform API side, and I think
 we're fine there now, but I don't really understand the impacts this has
 in mm.

I could review it and put it in there on a preliminary basis for some
runtime testing.  But the question in my mind is how different will the
code be after the problems which rmk has identified have been fixed?

If not very different then that effort and testing will have been
worthwhile.

If very different or unworkable then it was all for naught.

So.  Do we have a feeling for the magnitude of the changes which will
be needed to fix these things up?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Security] [PATCH 00/20] world-writable files in sysfs and debugfs

[Andrew Morton]

On Sat, 12 Mar 2011 23:23:06 +0300
Vasiliy Kulikov seg...@openwall.com wrote:

  Vasiliy Kulikov (20):
   mach-ux500: mbox-db5500: world-writable sysfs fifo file
   leds: lp5521: world-writable sysfs engine* files
   leds: lp5523: world-writable engine* sysfs files
   misc: ep93xx_pwm: world-writable sysfs files
   rtc: rtc-ds1511: world-writable sysfs nvram file
   scsi: aic94xx: world-writable sysfs update_bios file
   scsi: iscsi: world-writable sysfs priv_sess file
 
 These are still not merged :(

I grabbed them and shall merge some and send others at relevant
maintainers, thanks.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mmotm 2010-10-13 - GSPCA SPCA561 webcam driver broken

[Andrew Morton]

On Fri, 15 Oct 2010 10:45:45 +0200 Hans Verkuil hverk...@xs4all.nl wrote:

 On Thursday, October 14, 2010 22:06:29 valdis.kletni...@vt.edu wrote:
  On Wed, 13 Oct 2010 17:13:25 PDT, a...@linux-foundation.org said:
   The mm-of-the-moment snapshot 2010-10-13-17-13 has been uploaded to
   
  http://userweb.kernel.org/~akpm/mmotm/
  
  This broke my webcam.  I bisected it down to this commit, and things
  work again after reverting the 2 code lines of change.
  
  commit 9e4d79a98ebd857ec729f5fa8f432f35def4d0da
  Author: Hans Verkuil hverk...@xs4all.nl
  Date:   Sun Sep 26 08:16:56 2010 -0300
  
  V4L/DVB: v4l2-dev: after a disconnect any ioctl call will be blocked
  
  Until now all fops except release and (unlocked_)ioctl returned an error
  after the device node was unregistered. Extend this as well to the ioctl
  fops. There is nothing useful that an application can do here and it
  complicates the driver code unnecessarily.
  
  Signed-off-by: Hans Verkuil hverk...@xs4all.nl
  Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
  
  
  diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
  index d4a3532..f069c61 100644
  --- a/drivers/media/video/v4l2-dev.c
  +++ b/drivers/media/video/v4l2-dev.c
  @@ -221,8 +221,8 @@ static long v4l2_ioctl(struct file *filp, unsigned int 
  cmd, 
  struct video_device *vdev = video_devdata(filp);
  int ret;
   
  -   /* Allow ioctl to continue even if the device was unregistered.
  -  Things like dequeueing buffers might still be useful. */
  +   if (!vdev-fops-ioctl)
  +   return -ENOTTY;
  if (vdev-fops-unlocked_ioctl) {
  ret = vdev-fops-unlocked_ioctl(filp, cmd, arg);
  } else if (vdev-fops-ioctl) {
  
  I suspect this doesn't do what's intended if a driver is using 
  -unlocked_ioctl
  rather than -ioctl, and it should be reverted - it only saves at most one
  if statement.
  
  
 
 I'm not sure what is going on here. It looks like this patch is mangled in 
 your
 tree since the same patch in the v4l-dvb repository looks like this:
 
 diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c  

 index 32575a6..26d39c4 100644 

 --- a/drivers/media/video/v4l2-dev.c  

 +++ b/drivers/media/video/v4l2-dev.c  

 @@ -222,8 +222,8 @@ static int v4l2_ioctl(struct inode *inode, struct file 
 *filp,
   

 if (!vdev-fops-ioctl)   

 return -ENOTTY;   

 -   /* Allow ioctl to continue even if the device was unregistered.   

 -  Things like dequeueing buffers might still be useful. */
 +   if (!video_is_registered(vdev))
 +   return -ENODEV;
 return vdev-fops-ioctl(filp, cmd, arg);
  }
  
 @@ -234,8 +234,8 @@ static long v4l2_unlocked_ioctl(struct file *filp,
  
 if (!vdev-fops-unlocked_ioctl)
 return -ENOTTY;
 -   /* Allow ioctl to continue even if the device was unregistered.
 -  Things like dequeueing buffers might still be useful. */
 +   if (!video_is_registered(vdev))
 +   return -ENODEV;
 return vdev-fops-unlocked_ioctl(filp, cmd, arg);
  }
 
 In your diff there is a mismatch between ioctl and unlocked_ioctl which no 
 doubt
 is causing all the problems for you.

The patch which Valdis quoted is what is in linux-next.  I'm not
at which stage the mangling happened?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFCv4 0/6] The Contiguous Memory Allocator framework

[Andrew Morton]

On Fri, 20 Aug 2010 15:15:10 +0200
Peter Zijlstra pet...@infradead.org wrote:

 On Fri, 2010-08-20 at 11:50 +0200, Michal Nazarewicz wrote:
  Hello everyone,
  
  The following patchset implements a Contiguous Memory Allocator.  For
  those who have not yet stumbled across CMA an excerpt from
  documentation:
  
 The Contiguous Memory Allocator (CMA) is a framework, which allows
 setting up a machine-specific configuration for physically-contiguous
 memory management. Memory for devices is then allocated according
 to that configuration.
  
 The main role of the framework is not to allocate memory, but to
 parse and manage memory configurations, as well as to act as an
 in-between between device drivers and pluggable allocators. It is
 thus not tied to any memory allocation method or strategy.
  
  For more information please refer to the second patch from the
  patchset which contains the documentation.
 
 So the idea is to grab a large chunk of memory at boot time and then
 later allow some device to use it?
 
 I'd much rather we'd improve the regular page allocator to be smarter
 about this. We recently added a lot of smarts to it like memory
 compaction, which allows large gobs of contiguous memory to be freed for
 things like huge pages.
 
 If you want guarantees you can free stuff, why not add constraints to
 the page allocation type and only allow MIGRATE_MOVABLE pages inside a
 certain region, those pages are easily freed/moved aside to satisfy
 large contiguous allocations.

That would be good.  Although I expect that the allocation would need
to be 100% rock-solid reliable, otherwise the end user has a
non-functioning device.  Could generic core VM provide the required level
of service?

Anyway, these patches are going to be hard to merge but not impossible.
Keep going.  Part of the problem is cultural, really: the consumers of
this interface are weird dinky little devices which the core MM guys
tend not to work with a lot, and it adds code which they wouldn't use.

I agree that having two contiguous memory allocators floating about
on the list is distressing.  Are we really all 100% diligently certain
that there is no commonality here with Zach's work?

I agree that Peter's above suggestion would be the best thing to do. 
Please let's take a look at that without getting into sunk cost
fallacies with existing code!

It would help (a lot) if we could get more attention and buyin and
fedback from the potential clients of this code.  rmk's feedback is
valuable.  Have we heard from the linux-media people?  What other
subsystems might use it?  ieee1394 perhaps?  Please help identify
specific subsystems and I can perhaps help to wake people up.

And I agree that this code (or one of its alternatives!) would benefit
from having a core MM person take a close interest.  Any volunteers?

Please cc me on future emails on this topic?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

[Andrew Morton]

On Sun, 30 May 2010 14:29:55 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

 https://bugzilla.kernel.org/show_bug.cgi?id=16077

2.6.33 - 2.6.34 performance regression in dvb webcam frame rates.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 16050] New: The ibmcam driver is not working

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Tue, 25 May 2010 23:02:23 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

 https://bugzilla.kernel.org/show_bug.cgi?id=16050
 
URL: https://bugzilla.redhat.com/show_bug.cgi?id=588900
Summary: The ibmcam driver is not working
Product: Drivers
Version: 2.5
 Kernel Version: 2.6.34
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: USB
 AssignedTo: g...@kroah.com
 ReportedBy: david...@tmr.com
 Regression: Yes
 
 
 This driver has been working, and around the 1st of May I updated my Fedora
 kernel (FC13-RC) to current. The camera stopped working, so I built the latest
 2.6.34-rc version and verified the problem. When 2.6.34 final released I
 repeated the test and the driver is still not working.
 
 Originally reported against Fedora (not going to be fixed in FC13) the
 information in the Fedora report may be enough to identify the problem. I can
 do a bit of test almost any day, but the cams are on a video monitoring 
 system,
 so I'm not able to do long bisects and such.
 

It's a 2.6.33 - 2.6.34 regression, I think.  I don't know whether it's
a v4l problem or a USB one..

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 15826] New: WARNING: at fs/proc/generic.c:317 __xlate_proc_name+0xbd/0xe0()

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed, 21 Apr 2010 12:21:18 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

 https://bugzilla.kernel.org/show_bug.cgi?id=15826
 
Summary: WARNING: at fs/proc/generic.c:317
 __xlate_proc_name+0xbd/0xe0()
Product: v4l-dvb
Version: unspecified
 Kernel Version: 2.6.34-rc5
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: dvb-core
 AssignedTo: v4l-dvb_dvb-c...@kernel-bugs.osdl.org
 ReportedBy: bugzilla.kernel@boris64.net
 Regression: No
 
 
 Created an attachment (id=26077)
  -- (https://bugzilla.kernel.org/attachment.cgi?id=26077)
 full dmesg
 
 I keep getting this warning on boot. It seems to
 happen when the dvb driver for my technisat skystar2
 card is loaded (correct me if i'm wrong).
 
 If you need more infos or debug stuff inside 
 my kernel config, please tell me what i need to include.
 
 Thank you in advance.
 
 
 ...
 [0.739420] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip
 loaded successfully
 [0.739435] flexcop-pci: will use the HW PID filter.
 [0.739438] flexcop-pci: card revision 2
 [0.739442] b2c2_flexcop_pci :04:01.0: PCI INT A - GSI 17 (level, low)
 - IRQ 17
 [0.739459] [ cut here ]
 [0.739463] WARNING: at fs/proc/generic.c:317 __xlate_proc_name+0xbd/0xe0()

Alexey, this sucks.  A developer goes to the warning site:

static int __xlate_proc_name(const char *name, struct proc_dir_entry **ret,
 const char **residual)
{
const char  *cp = name, *next;
struct proc_dir_entry   *de;
int len;

de = *ret;
if (!de)
de = proc_root;

while (1) {
next = strchr(cp, '/');
if (!next)
break;

len = next - cp;
for (de = de-subdir; de ; de = de-next) {
if (proc_match(len, cp, de))
break;
}
if (!de) {
WARN(1, name '%s'\n, name);
return -ENOENT;
}
cp += len + 1;
}
*residual = cp;
*ret = de;
return 0;
}

and there's no hint whatsoever to tell him what the warning means, nor
how to fix it.

Please send a patch adding a nice comment to __xlate_proc_name().  Then
perhaps the DVB guys have a chance of fixing this bug.

Thanks.


 [0.739465] Hardware name: P5K
 [0.739466] name 'Technisat/B2C2 FlexCop II/IIb/III Digital TV PCI Driver'
 [0.739467] Modules linked in:
 [0.739470] Pid: 1, comm: swapper Not tainted 2.6.34-rc5-v2k11+-dbg-dirty
 #118
 [0.739471] Call Trace:
 [0.739476]  [8103e386] warn_slowpath_common+0x76/0xb0
 [0.739478]  [8103e41c] warn_slowpath_fmt+0x3c/0x40
 [0.739481]  [8110b4ad] __xlate_proc_name+0xbd/0xe0
 [0.739483]  [8110b540] __proc_create+0x70/0x140
 [0.739486]  [8110bf49] proc_mkdir_mode+0x29/0x60
 [0.739488]  [8110bf91] proc_mkdir+0x11/0x20
 [0.739491]  [8107b39b] register_handler_proc+0x11b/0x140
 [0.739494]  [810791f9] __setup_irq+0x1f9/0x390
 [0.739497]  [813ca790] ? flexcop_pci_isr+0x0/0x3e0
 [0.739500]  [810794bc] request_threaded_irq+0x12c/0x210
 [0.739502]  [813cad20] flexcop_pci_probe+0x1b0/0x350
 [0.739505]  [811e4ee5] pci_device_probe+0x75/0xa0
 [0.739509]  [8130522a] ? driver_sysfs_add+0x5a/0x90
 [0.739511]  [813054f3] driver_probe_device+0x93/0x1a0
 [0.739514]  [8130569b] __driver_attach+0x9b/0xa0
 [0.739517]  [81305600] ? __driver_attach+0x0/0xa0
 [0.739519]  [8130460e] bus_for_each_dev+0x5e/0x90
 [0.739522]  [813051c9] driver_attach+0x19/0x20
 [0.739524]  [81304d62] bus_add_driver+0xb2/0x260
 [0.739527]  [8130590f] driver_register+0x6f/0x130
 [0.739529]  [811e5171] __pci_register_driver+0x51/0xd0
 [0.739533]  [818f49a9] ? flexcop_pci_module_init+0x0/0x1b
 [0.739535]  [818f49c2] flexcop_pci_module_init+0x19/0x1b
 [0.739538]  [810002d9] do_one_initcall+0x39/0x1a0
 [0.739540]  [818d1cc4] kernel_init+0x14d/0x1d7
 [0.739543]  [81003194] kernel_thread_helper+0x4/0x10
 [0.739546]  [818d1b77] ? kernel_init+0x0/0x1d7
 [0.739548]  [81003190] ? kernel_thread_helper+0x0/0x10
 [0.739553] ---[ end trace 4e6b2faee55cb1bf ]---
 [0.744389] DVB: registering new adapter (FlexCop Digital TV device)
 [0.746102] 

Fw: PROBLEM: linux server halts while restarting VLC

[Andrew Morton]

Begin forwarded message:

Date: Wed, 14 Apr 2010 12:36:18 +0400
From: Alexander Kolesnik linux-ker...@abisoft.biz
To: linux-ker...@vger.kernel.org
Subject: PROBLEM: linux server halts while restarting VLC


Hello,

We have a video camera which is connected to a capture card in a linux
server  (CentOS  5.4).  VLC  takes  video  data from the capture card,
streams  it  and writes to a file. A cron job checking the file's size
and  rotates  it  when  it comes to a configured limit. After file was
rotated, VLC process is restarted.
Rotating and restarting are done by means of logrotate script:
# cat /etc/logrotate.d/vlc
/opt3/cam-fx4/*.asf {
size 300M
rotate 16
notifempty
missingok
prerotate
killall vlc  sleep 1
endscript
postrotate
sudo -u vlc /usr/local/bin/vlc_cam-fx4.shx
endscript
}

# cat /usr/local/bin/vlc_cam-fx4.shx
nice -n 19 vlc --intf dummy v4l2:// :v4l2-dev=/dev/video0 :v4l2-standard=255 
:v4l2-input=1 :v4l2-width=720 :v4l2-height=480 \
--no-sout-audio \
--marq-marquee=%d-%m-%Y %H:%M:%S --marq-position=10 --marq-opacity=200 
--marq-size=20 \
--sout 
'#transcode{vcodec=mp4v,vb=2048,scale=1,sfilter=marq}:duplicate{dst=std{access=http,mux=ts,dst=.},dst=std{access=file,mux=ps,dst=/opt3/cam-fx4/cam-fx4.asf}}'
  /dev/null 21 

Once or twice a day, the server halts with the following in the system
log:
Apr 14 07:01:02 alto sudo: root : TTY=unknown ; PWD=/ ; USER=vlc ; 
COMMAND=/usr/local/bin/vlc_cam-fx4.shx
Apr 14 07:01:06 alto kernel: vlc: page allocation failure. order:2, mode:0x8020
Apr 14 07:01:06 alto kernel: Pid: 3492, comm: vlc Not tainted 2.6.33.2 #1
Apr 14 07:01:06 alto kernel: Call Trace:
Apr 14 07:01:06 alto kernel:  [c106b047] ? __alloc_pages_nodemask+0x465/0x4dd
Apr 14 07:01:06 alto kernel:  [c1004d69] ? 
dma_generic_alloc_coherent+0x4d/0xa4
Apr 14 07:01:06 alto kernel:  [c1004d1c] ? dma_generic_alloc_coherent+0x0/0xa4
Apr 14 07:01:06 alto kernel:  [e0fbf4de] ? btcx_riscmem_alloc+0x9d/0xf3 
[btcx_risc]
Apr 14 07:01:06 alto kernel:  [e14fe4ae] ? bttv_risc_planar+0x4f/0x2a3 [bttv]
Apr 14 07:01:06 alto kernel:  [c10801b1] ? map_vm_area+0x20/0x30
Apr 14 07:01:06 alto kernel:  [e14feefa] ? bttv_buffer_risc+0x31f/0x4b4 [bttv]
Apr 14 07:01:06 alto kernel:  [e14fb503] ? buffer_prepare+0x296/0x2c5 [bttv]
Apr 14 07:01:06 alto kernel:  [e101f2fd] ? videobuf_qbuf+0x235/0x2ed 
[videobuf_core]
Apr 14 07:01:06 alto kernel:  [e14fd072] ? bttv_qbuf+0x0/0x63 [bttv]
Apr 14 07:01:06 alto kernel:  [e14fd072] ? bttv_qbuf+0x0/0x63 [bttv]
Apr 14 07:01:06 alto kernel:  [e134bb9b] ? __video_do_ioctl+0x115b/0x3554 
[videodev]
Apr 14 07:01:06 alto kernel:  [c10e989a] ? avc_has_perm_noaudit+0x1b6/0x2be
Apr 14 07:01:06 alto kernel:  [c123f1ef] ? schedule+0x29e/0x2c3
Apr 14 07:01:06 alto kernel:  [c10e9b1b] ? avc_has_perm+0x3c/0x46
Apr 14 07:01:06 alto kernel:  [e134e221] ? video_ioctl2+0x28d/0x34f [videodev]
Apr 14 07:01:06 alto kernel:  [c1077083] ? __do_fault+0x373/0x3ac
Apr 14 07:01:06 alto kernel:  [c10ea80f] ? file_has_perm+0x84/0x8d
Apr 14 07:01:06 alto kernel:  [e134df94] ? video_ioctl2+0x0/0x34f [videodev]
Apr 14 07:01:06 alto kernel:  [e134a6c1] ? v4l2_ioctl+0x31/0x34 [videodev]
Apr 14 07:01:06 alto kernel:  [e134a690] ? v4l2_ioctl+0x0/0x34 [videodev]
Apr 14 07:01:06 alto kernel:  [c1096821] ? vfs_ioctl+0x39/0x48
Apr 14 07:01:06 alto kernel:  [c1096d98] ? do_vfs_ioctl+0x4d8/0x525
Apr 14 07:01:06 alto kernel:  [c1096e26] ? sys_ioctl+0x41/0x58
Apr 14 07:01:06 alto kernel:  [c100254c] ? sysenter_do_call+0x12/0x22
Apr 14 07:01:06 alto kernel: Mem-Info:
Apr 14 07:01:06 alto kernel: DMA per-cpu:
Apr 14 07:01:06 alto kernel: CPU0: hi:0, btch:   1 usd:   0
Apr 14 07:01:06 alto kernel: Normal per-cpu:
Apr 14 07:01:06 alto kernel: CPU0: hi:  186, btch:  31 usd: 198
Apr 14 07:01:06 alto kernel: active_anon:2701 inactive_anon:2754 isolated_anon:0
Apr 14 07:01:06 alto kernel:  active_file:37313 inactive_file:75024 
isolated_file:0
Apr 14 07:01:06 alto kernel:  unevictable:0 dirty:951 writeback:0 unstable:0
Apr 14 07:01:06 alto kernel:  free:3474 slab_reclaimable:3837 
slab_unreclaimable:1016
Apr 14 07:01:06 alto kernel:  mapped:4169 shmem:41 pagetables:156 bounce:0
Apr 14 07:01:06 alto kernel: DMA free:2008kB min:88kB low:108kB high:132kB 
active_anon:12kB inactive_anon:16kB active_file:177
2kB inactive_file:11988kB unevictable:0kB isolated(anon):0kB isolated(file):0kB 
present:15868kB mlocked:0kB dirty:0kB writebac
k:0kB mapped:0kB shmem:0kB slab_reclaimable:92kB slab_unreclaimable:4kB 
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0k
B writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Apr 14 07:01:06 alto kernel: lowmem_reserve[]: 0 491 491 491
Apr 14 07:01:06 alto kernel: Normal free:11888kB min:2788kB low:3484kB 
high:4180kB active_anon:10792kB inactive_anon:11000kB a
ctive_file:147480kB inactive_file:288108kB unevictable:0kB isolated(anon):0kB 
isolated(file):0kB present:502856kB mlocked:0kB
dirty:3804kB writeback:0kB 

Re: [PATCH] drivers/media/video: avoid NULL dereference

[Andrew Morton]

On Sun, 21 Mar 2010 22:31:06 +0100 (CET) Julia Lawall ju...@diku.dk wrote:

 From: Julia Lawall ju...@diku.dk
 
 If ov is NULL, it will not be possible to take the lock in the first place,
 so move the test up earlier.
 
 ...

 --- a/drivers/media/video/ov511.c
 +++ b/drivers/media/video/ov511.c
 @@ -5913,14 +5913,12 @@ ov51x_disconnect(struct usb_interface *intf)
  
   PDEBUG(3, );
  
 + if (!ov)
 + return;
 +
   mutex_lock(ov-lock);
   usb_set_intfdata (intf, NULL);
  
 - if (!ov) {
 - mutex_unlock(ov-lock);
 - return;
 - }
 -
   /* Free device number */
   ov511_devused = ~(1  ov-nr);

I think we can pretty safely assume that we never get here with ov==NULL.

Oh well, I'll leave the test there for others to ponder.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2/5] drivers/media/video: move dereference after NULL test

[Andrew Morton]

On Thu, 11 Mar 2010 16:38:21 -0600
Karicheri, Muralidharan m-kariche...@ti.com wrote:

 diff -puN drivers/media/video/davinci/vpif_display.c~drivers-media-video-
 move-dereference-after-null-test drivers/media/video/davinci/vpif_display.c
 --- a/drivers/media/video/davinci/vpif_display.c~drivers-media-video-move-
 dereference-after-null-test
 +++ a/drivers/media/video/davinci/vpif_display.c
 @@ -383,8 +383,6 @@ static int vpif_get_std_info(struct chan
  int index;
 
  std_info-stdid = vid_ch-stdid;
 -if (!std_info)
 -return -1;
 
 Please change it as 
 
 if (!std_info-stdid)
   return -1;

Could you please do this, and send the patch?  It's better that way as
you're more familar with the code and maybe can even test it.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] radio: Add support for SAA7706H Car Radio DSP

[Andrew Morton]

On Fri, 22 Jan 2010 10:08:43 +0100
Richard R__jfors richard.rojf...@pelagicore.com wrote:

 These sets of patches added support for the SAA7706H Car Radio DSP.
 
 Patch 2 is updated after feedback from Hans Verkuil. Thanks Hans!
 
 Patch 1:
 Add The saa7706h to the v4l2-chip-ident.h
 Patch 2:
 Add the actual source code
 Patch 3:
 Add the saa7706h to the Kconfig and Makefile

There doesn't seem much point in splitting the patch up along these
lines, so I joined them all into a single patch in my tree.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 15087] New: hauppauge nova-t 500 remote controller cause usb halt with Via usb controller

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Mon, 18 Jan 2010 21:06:57 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=15087
 
Summary: hauppauge nova-t 500 remote controller cause usb halt
 with Via usb controller
Product: Drivers
Version: 2.5
 Kernel Version: 2.6.32
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: blocking
   Priority: P1
  Component: USB
 AssignedTo: g...@kroah.com
 ReportedBy: fuffi.il.fu...@gmail.com
 Regression: Yes
 
 
 This is a know problem with this dvb-t card.
 If the ir receiver is disabled via modprobe option (adding this parameter in
 modprobe.conf: #options dvb_usb disable_rc_polling=1) I cannot use it but 
 the
 card works perfectly, but if I try to activate it (removing that option) and i
 launch the lircd daemon, I obtain a usb halt as described below in this old
 message in the linux-media ml.
 
 klogd: ehci_hcd :04:00.2: force halt; handhake f8018014 4000
  - -110
 
 Here, the writer find the commit that cause this regression:
 http://osdir.com/ml/linux-media/2009-08/msg00185.html
 Here is explained when it was introduced:
 http://osdir.com/ml/linux-media/2009-08/msg00182.html
 
 It seems that this problem is present only with a via usb controller,
 unfortunately i have this one:
 
  lspci | grep -i via
 01:08.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
 Controller (rev 62)
 01:08.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
 Controller (rev 62)
 01:08.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65)
 
 Tell me if you need additional info.
 I'm using a 2.6.32 kernel on arch linux.
 Other relevant modprobe options:
 options dib3000mc buggy_sfn_workaround=1
 options dib7000p buggy_sfn_workaround=1
 alias net-pf-10 off
 

This is a regression.  You have to chase links a bit, but it was
bisected down to a particular commit in
http://linuxtv.org/hg/v4l-dvb/rev/561b447ade77.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Fwd: [patch] media video cx23888 driver: ported to new kfifo API]

[Andrew Morton]

On Fri, 18 Dec 2009 22:57:22 +0100
Stefani Seibold stef...@seibold.net wrote:

 But kfifo_len() did not
 requiere a lock in my opinion. It is save to use without a look. 

What do you mean by this?  Safe in general, or safe in this particular driver?

In either case: why?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

drivers/media/video/gspca/ov534.c warning

[Andrew Morton]

drivers/media/video/gspca/ov534.c: In function 'setsharpness_96':
drivers/media/video/gspca/ov534.c:1539: warning: comparison is always false due 
to limited range of data type

this code can't ever have worked.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux-next i386 allmodconfig

[Andrew Morton]

ERROR: __divdf3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __adddf3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __udivdi3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __floatsidf [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __muldf3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __floatsidf [drivers/media/common/tuners/max2165.ko] undefined!

would be nice to get that fixed up before merging.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 14174] New: floppy drive not usable more than one time after reboot - kernel panic with active DVB

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Sun, 13 Sep 2009 15:08:21 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=14174
 
Summary: floppy drive not usable more than one time after
 reboot - kernel panic with active DVB
Product: IO/Storage
Version: 2.5
 Kernel Version: 2.6.27.29-0.1-vanilla x86_64 SMP
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: Other
 AssignedTo: io_ot...@kernel-bugs.osdl.org
 ReportedBy: alexander.koe...@koenig-a.de
 Regression: No
 
 
 This bug report is afollow-up of my report already posted in the OPENSuse
 bugzilla at https://bugzilla.novell.com/show_bug.cgi?id=421732
 You can find detailed information of my hardware and software configuration
 there.
 
 Short System description:
 - CPU: AMD Phenom X4 9550 4x2.2GHz (95W) 65nm Quad Core
 - Memory:  4GB - 2x2048MB DDR2-800 CL5, Dual Channel 2x1024MB
 - Motherboard: GIGABYTE GA-MA770-DS3
 - Graphics NVidia GeForce 7300 GS, 256MB, TV-Out, DVI, PCIe
 - Floppy:  1.44MB
 - 1. hard disk:500GB Seagate 7200 RPM SATA II
 - 2. hard disk:500GB Seagate 7200 RPM SATA II
 - DVD-ROM: Optiarc DDU 1615 16x/48x, IDE
 - DVD-RW:  NEC AD-7200, IDE
 - SCSI-Controller: Adaptec 2940 SCSI adapter,SCSI ID: 7
 - DVB controller:  Technotrend/Hauppauge DVB card rev2.1
 
 Symptoms:
 The first command to the floppy drive after re-boot seems to work, all
 subsequent access to the floppy drive - with the same disk or with any other -
 fail (floppy LED is on, floppy drive moves, but no positive result). See log 
 of
 a terminal session below:
 
 alexa...@asterix:~ mdir
  Volume in drive A has no label
  Volume Serial Number is 2828-50E1
 Directory for A:/
 
 autoexec bat  1142 1998-05-15  20:01  autoexec.bat
 setramd  bat   881 1998-05-15  20:01  setramd.bat
 findramd exe  6855 1998-05-15  20:01  findramd.exe
 aspi4dos sys 14386 1998-05-15  20:01  aspi4dos.sys
 aspicd   sys 29620 1998-05-15  20:01  aspicd.sys
 aspi2dos sys 35330 1998-05-15  20:01  aspi2dos.sys
 aspi8u2  sys 40792 1998-05-15  20:01  aspi8u2.sys
 extract  exe 93242 1998-05-15  20:01  extract.exe
 drvspace bin 69079 1998-05-15  20:01  drvspace.bin
 himemsys 33447 1998-05-15  20:01  himem.sys
 ebd  cab276324 1998-05-15  20:01  ebd.cab
 country  sys 30742 1998-05-15  20:01  country.sys
 mode com 29815 1998-05-15  20:01  mode.com
 keyb com 20023 1998-05-15  20:01  keyb.com
 ebd  sys 0 2000-01-08  10:09  ebd.sys
 io   sys222390 1998-05-15  20:01  io.sys
 config   sys   860 2003-11-16   0:26  config.sys
 readme   txt 16216 1998-05-15  20:01  readme.txt
 ramdrive sys 12823 1998-05-15  20:01  ramdrive.sys
 btcdrom  sys 21971 1998-05-15  20:01  btcdrom.sys
 btdosm   sys 30955 1998-05-15  20:01  btdosm.sys
 aspi8dos sys 37564 1998-05-15  20:01  aspi8dos.sys
 flashpt  sys 64425 1998-05-15  20:01  flashpt.sys
 fdiskexe 64956 1998-05-15  20:01  fdisk.exe
 command  com 96360 1998-05-15  20:01  command.com
 oakcdrom sys 41302 1998-05-15  20:01  oakcdrom.sys
 display  sys 17191 1998-05-15  20:01  display.sys
 ega  cpi 58870 1998-05-15  20:01  ega.cpi
 keyboard sys 34566 1998-05-15  20:01  keyboard.sys
 msdossys 9 2000-01-08  10:09  msdos.sys
 toshv224 sys 13720 2003-11-16   0:24  toshv224.sys
31 files   1 415 856 bytes
  33 792 bytes free
 
 alexa...@asterix:~ mdir
 init A: non DOS media
 Cannot initialize 'A:'
 alexa...@asterix:~ mdir
 init A: non DOS media
 Cannot initialize 'A:'
 alexa...@asterix:~ mount /media/floppy
 mount: blockorientiertes Ger__t /dev/fd0 ist schreibgesch__tzt, wird 
 eingeh__ngt
 im Nur-Lese-Modus
 mount: konnte Dateisystemtyp nicht feststellen, und es wurde keiner angegeben
 --- floppy removed from drive ---
 alexa...@asterix:~ mount /media/floppy  
 mount: /dev/fd0 ist kein g__ltiges blockorientiertes Ger__t
  --- inserted another floppy into the drive ---
 alexa...@asterix:~ mount /media/floppy
 mount: blockorientiertes Ger__t /dev/fd0 ist schreibgesch__tzt, wird 
 eingeh__ngt
 im Nur-Lese-Modus
 mount: konnte Dateisystemtyp nicht feststellen, und es wurde keiner angegeben
  --- removed floppy from drive ---
 alexa...@asterix:~ mdir
 Can't open /dev/fd0: No such device or address
 Cannot initialize 'A:'
  --- inserted floppy into drive ---
 alexa...@asterix:~ mdir
 init A: non DOS media
 Cannot initialize 'A:'
 alexa...@asterix:~ mdir
 init A: non DOS media
 Cannot initialize 'A:'
 alexa...@asterix:~ 
 
 All disks used for these experiments (Windows 98 installation boot disk, SuSE
 Linux 

Re: [Bugme-new] [Bug 13951] New: in function device_authorization mutex is not released on error path.

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Mon, 10 Aug 2009 08:16:08 GMT bugzilla-dae...@bugzilla.kernel.org wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=13951
 
Summary: in function device_authorization mutex is not released
 on  error  path.
Product: Drivers
Version: 2.5
 Kernel Version: 2.6.30
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: Video(Other)
 AssignedTo: drivers_video-ot...@kernel-bugs.osdl.org
 ReportedBy: str...@ispras.ru
 Regression: No
 
 
 In ./drivers/media/video/hdpvr/hdpvr-core.c in function 
 device authorization: 
 If after mutex lock (line 4) usb control msg returns ret!=46 
 we go to 
 label 
 error. In this case before exit from function mutex must be unlocked.
 
 01) static int device authorization(struct hdpvr device *dev)
 02) {
 03) 
 04) mutex lock(dev-usbc mutex); 
  
 05)ret = usb control msg(dev-udev,
 06)  usb rcvctrlpipe(dev-udev, 
 0),
 07) rcv request, 0x80 | request 
 type,
 08) 0x0400, 0x0003,
 09) dev-usbc buf, 46,1);
 10)  if (ret != 46) {
 11) v4l2 err(dev-v4l2 dev,
 12) unexpected answer of status request, 
 len %d\n, 
 ret);
 13)goto error;
 14)}
 15) .
 16) error:
 17)
 18)return retval;
 19) }
 

Alexander, it would make life simpler if you were to just email patches
which fix things like this!

Thanks.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bug 13708] Aiptek DV-T300 support is incomplete

[Andrew Morton]

On Mon, 20 Jul 2009 22:37:08 +0200
Bal__zs H__morszky bal...@gmail.com wrote:

 I don't have my kernel tree with me (I'm at vacation atm.). The patch
 is made with only the -uN options, but I can make a new one on Friday
 (if needed).
 

The patch doesn't apply to current kernels and fixing it looks non-trivial.

There's no hurry - please email us a complete (tested, changelogged,
signed-off) patch when you have time to get onto it, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13709] New: b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter w/ kernel-2.6.31-rc2

[Andrew Morton]

On Wed, 22 Jul 2009 00:19:00 -0700 (PDT) Trent Piepho xy...@speakeasy.org 
wrote:

 On Mon, 20 Jul 2009, Andrew Morton wrote:
  On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
  Trent Piepho xy...@speakeasy.org wrote:
   On Mon, 20 Jul 2009, Andrew Morton wrote:
   I produced a patch that fixed this problem over a month ago,
   http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
 
  Where is that patch now?  It isn't present in linux-next.
 
 Mauro has how pulled it from me and so it will probably show up in his tree
 soon.
 
  Also, is there any way of avoiding this?
 
  +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
  + (defined(CONFIG_DVB_##fe##_MODULE)  defined(MODULE)))
 
  That's just way too tricky.  It expects all versions of the
  preprocessor to be correctly implemented (unlikely) and there are other
  tools like unifdef which want to parse kernel #defines.
 
 What's so tricky about it?  A quick grep shows hundreds of uses of
 ## for concatenation.

Not the concatenation, of course.

The worrisomie thing is the macro which expands to preprocessor
statements.  It requires that the preprocessor run itself multiple
times across the same line.  Or something.  I don't recall seeing that
trick used elsewhere in the kernel and I have vague memories of it
causing problems in the past.


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] drivers/media/video/zoran_card.c: en/decoder loading

[Andrew Morton]

(cc linux-media)

On Sun, 27 Jan 2008 19:01:29 +0100
Martin Samuelsson sam.linux.ker...@gmail.com wrote:

 This enables the avs6eyes to load the bt866 and ks0127 drivers automatically.
 
 Signed-off-by: Martin Samuelsson sam.linux.ker...@gmail.com
 ---
  zoran_card.c |6 ++
  1 file changed, 6 insertions(+)
 --- linux-2.6.24-ori/drivers/media/video/zoran_card.c 2008-01-24 
 23:58:37.0 +0100
 +++ linux-2.6.24-sam/drivers/media/video/zoran_card.c 2008-01-27 
 17:16:51.0 +0100
 @@ -366,6 +366,12 @@ i2cid_to_modulename (u16 i2c_id)
   case I2C_DRIVERID_MSE3000:
   name = mse3000;
   break;*/
 + case I2C_DRIVERID_BT866:
 + name = bt866;
 + break;
 + case I2C_DRIVERID_KS0127:
 + name = ks0127;
 + break;
   default:
   break;
   }

The Zoran driver has changed a lot since 2.6.24 and I can't find
anywhere where a patch like this might be applied.

Please check a current kernel and update the patch if it is still needed?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] drivers/media/video/zoran_card.c: en/decoder loading

[Andrew Morton]

On Wed, 22 Jul 2009 13:57:57 -0700
Andrew Morton a...@linux-foundation.org wrote:

 (cc linux-media)
 
 On Sun, 27 Jan 2008 19:01:29 +0100

oops

 Martin Samuelsson sam.linux.ker...@gmail.com wrote:
 
  This enables the avs6eyes to load the bt866 and ks0127 drivers 
  automatically.
  
  Signed-off-by: Martin Samuelsson sam.linux.ker...@gmail.com
  ---
   zoran_card.c |6 ++
   1 file changed, 6 insertions(+)
  --- linux-2.6.24-ori/drivers/media/video/zoran_card.c   2008-01-24 
  23:58:37.0 +0100
  +++ linux-2.6.24-sam/drivers/media/video/zoran_card.c   2008-01-27 
  17:16:51.0 +0100
  @@ -366,6 +366,12 @@ i2cid_to_modulename (u16 i2c_id)
  case I2C_DRIVERID_MSE3000:
  name = mse3000;
  break;*/
  +   case I2C_DRIVERID_BT866:
  +   name = bt866;
  +   break;
  +   case I2C_DRIVERID_KS0127:
  +   name = ks0127;
  +   break;
  default:
  break;
  }
 
 The Zoran driver has changed a lot since 2.6.24 and I can't find
 anywhere where a patch like this might be applied.
 
 Please check a current kernel and update the patch if it is still needed?

sorry, operator error.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13709] New: b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter w/ kernel-2.6.31-rc2

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).


Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to
add it to the regression tracking list.

btw, does the flexcop driver have a regular maintainer?  Or someone who
wants to volunteer?  MAINTAINERS is silent about it..

Thanks.

On Sun, 5 Jul 2009 01:36:31 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=13709
 
Summary: b2c2-flexcop: no frontend driver found for this
 B2C2/FlexCop adapter w/ kernel-2.6.31-rc2
Product: v4l-dvb
Version: unspecified
 Kernel Version: 2.6.31-rc1
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: dvb-frontend
 AssignedTo: v4l-dvb_dvb-front...@kernel-bugs.osdl.org
 ReportedBy: bugzilla.kernel@boris64.net
 Regression: Yes
 
 
 Hi kernel people!
 
 Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't
 working anymore, because no frontend driver is found.
 The frontend 'ST STV0299 DVB-S' is compiled into the kernel
 and _did_ work fine in pre-2.6.31 kernels.
 
 
 [lspci]
 ...
 05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip
 / Technisat SkyStar2 DVB card (rev 02)
 [/lspci]
 
 [dmesg]
 Working kernel-2.6.30.1:
 
 ...
 b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
 successfully
 b2c2_flexcop_pci :05:02.0: PCI INT A - GSI 18 (level, low) - IRQ 18
 b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
 b2c2-flexcop: found 'ST STV0299 DVB-S' .
 b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation 
 (HD5000)'
 at the 'PCI' bus controlled by a 'FlexCopIIb' complete
 ...
 
 Non-working kernel-2.6.31-rc:
 
 ...
 b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
 successfully
 b2c2_flexcop_pci :05:02.0: PCI INT A - GSI 18 (level, low) - IRQ 18
 b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
 b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter
 b2c2_flexcop_pci :05:02.0: PCI INT A disabled
 ...
 [/dmesg]
 
 
 I'll attach full dmesg+lspci.
 Please feel free to contact me if you need more infos.
 Thank you in advance ;)
 
 -- 
 Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13709] New: b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter w/ kernel-2.6.31-rc2

[Andrew Morton]

On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Trent Piepho xy...@speakeasy.org wrote:

 On Mon, 20 Jul 2009, Andrew Morton wrote:
 
  (switched to email.  Please respond via emailed reply-to-all, not via the
  bugzilla web interface).
 
 
  Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to
  add it to the regression tracking list.
 
  btw, does the flexcop driver have a regular maintainer?  Or someone who
  wants to volunteer?  MAINTAINERS is silent about it..
 
 I produced a patch that fixed this problem over a month ago,
 http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e

Where is that patch now?  It isn't present in linux-next.

If it needs to be resent, please cc me on it?


Also, is there any way of avoiding this?

+#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
+ (defined(CONFIG_DVB_##fe##_MODULE)  defined(MODULE)))

That's just way too tricky.  It expects all versions of the
preprocessor to be correctly implemented (unlikely) and there are other
tools like unifdef which want to parse kernel #defines.

otoh the trick does produce a nice result and doing it any other way
(which I can think of) would make a mess.

 Maybe it should go into 2.6.31?

It depends on the seriousness of the regression (number of people
affected, whether there's a workaround, etc) and upon the riskiness of
the patch.

But sure, we don't want regressions and letting one be released when we
already know about it and have a fix would be bad!

If the patch is judged too risky at this time, there might be a simpler
one, perhaps.

Or just revert whichever patch broke things.  Your changelog describes
this as simply A recent patch (bad changelog!) so I am unable to judge this.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/6] radio-mr800.c: missing mutex include

[Andrew Morton]

On Thu, 11 Jun 2009 03:21:36 +0400 Alexey Klimov klimov.li...@gmail.com wrote:

 On Wed, Jun 10, 2009 at 11:44 PM, a...@linux-foundation.org wrote:
  From: Alessio Igor Bogani abog...@texware.it
 
  radio-mr800.c uses struct mutex, so while linux/mutex.h seems to be
  pulled in indirectly by one of the headers it already includes, the right
  thing is to include it directly.
 
 It was already applied to v4l-dvb tree (and probably to v4l git tree).

It isn't in today's linux-next.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bugme-new] [Bug 13316] New: task khubd:281 blocked for more than 120 seconds

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Fri, 15 May 2009 17:46:49 GMT bugzilla-dae...@bugzilla.kernel.org wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=13316
 
Summary: task khubd:281 blocked for more than 120 seconds
Product: Drivers
Version: 2.5
 Kernel Version: 2.6.30-rc5
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: USB
 AssignedTo: g...@kroah.com
 ReportedBy: mr...@gmx.at
 Regression: No
 
 
 When unplugging the dvb-t device while using it (running me-tv) I got the
 following syslog output:
 
 May 15 19:35:42 jupiter kernel: [ 6601.222871] INFO: task khubd:281 blocked 
 for
 more than 120 seconds.
 May 15 19:35:42 jupiter kernel: [ 6601.222890] echo 0 
 /proc/sys/kernel/hung_task_timeout_secs disables this message.
 May 15 19:35:42 jupiter kernel: [ 6601.222906] khubd D 05e3 0 
  
 281  2
 May 15 19:35:42 jupiter kernel: [ 6601.222932]  f71b3e30 0046 bc40db98
 05e3 f0ce8000 f71b3dd0 c08e0510 c08a8dc0
 May 15 19:35:42 jupiter kernel: [ 6601.222982]  c08a8dc0  f256fab8
 f71994e0 f7199774 c2225dc0  c014046b
 May 15 19:35:42 jupiter kernel: [ 6601.223030]  bc414f32 05e3 f256fab8
   0046 f71b3e14 f256faa8
 May 15 19:35:42 jupiter kernel: [ 6601.223077] Call Trace:
 May 15 19:35:42 jupiter kernel: [ 6601.223112]  [c014046b] ?
 prepare_to_wait+0x14/0x48
 May 15 19:35:42 jupiter kernel: [ 6601.223136]  [c014d665] ?
 trace_hardirqs_on+0xb/0xd
 May 15 19:35:42 jupiter kernel: [ 6601.223160]  [c04c9459] ?
 _spin_unlock_irqrestore+0x5f/0x6c
 May 15 19:35:42 jupiter kernel: [ 6601.223181]  [c04c7833] 
 schedule+0x12/0x33
 May 15 19:35:42 jupiter kernel: [ 6601.223235]  [f8a989b2]
 dvb_unregister_frontend+0x99/0xd3 [dvb_core]
 May 15 19:35:42 jupiter kernel: [ 6601.223258]  [c01402db] ?
 autoremove_wake_function+0x0/0x33
 May 15 19:35:42 jupiter kernel: [ 6601.223290]  [f83f8b81]
 dvb_usb_adapter_frontend_exit+0x15/0x25 [dvb_usb]
 May 15 19:35:42 jupiter kernel: [ 6601.223318]  [f83f82f8]
 dvb_usb_exit+0x2c/0x93 [dvb_usb]
 May 15 19:35:42 jupiter kernel: [ 6601.223345]  [f83f8394]
 dvb_usb_device_exit+0x35/0x47 [dvb_usb]
 May 15 19:35:42 jupiter kernel: [ 6601.223369]  [c03a2cdc]
 usb_unbind_interface+0x4d/0xc4
 May 15 19:35:42 jupiter kernel: [ 6601.223393]  [c0348252]
 __device_release_driver+0x5a/0x77
 May 15 19:35:42 jupiter kernel: [ 6601.223413]  [c034830c]
 device_release_driver+0x18/0x23
 May 15 19:35:42 jupiter kernel: [ 6601.223433]  [c0347adc]
 bus_remove_device+0x71/0x88
 May 15 19:35:42 jupiter kernel: [ 6601.223453]  [c034679a]
 device_del+0xf9/0x152
 May 15 19:35:42 jupiter kernel: [ 6601.223473]  [c03a092f]
 usb_disable_device+0x5c/0xba
 May 15 19:35:42 jupiter kernel: [ 6601.223493]  [c039c9e9]
 usb_disconnect+0x73/0xdc
 May 15 19:35:42 jupiter kernel: [ 6601.223564]  [c039d7a8]
 hub_thread+0x548/0xdf8
 May 15 19:35:42 jupiter kernel: [ 6601.223601]  [c014d639] ?
 trace_hardirqs_on_caller+0x103/0x124
 May 15 19:35:42 jupiter kernel: [ 6601.223632]  [c01402db] ?
 autoremove_wake_function+0x0/0x33
 May 15 19:35:42 jupiter kernel: [ 6601.223660]  [c039d260] ?
 hub_thread+0x0/0xdf8
 May 15 19:35:42 jupiter kernel: [ 6601.223685]  [c039d260] ?
 hub_thread+0x0/0xdf8
 May 15 19:35:42 jupiter kernel: [ 6601.223714]  [c013ffb6] kthread+0x45/0x6b
 May 15 19:35:42 jupiter kernel: [ 6601.223744]  [c013ff71] ? 
 kthread+0x0/0x6b
 May 15 19:35:42 jupiter kernel: [ 6601.223777]  [c01037e7]
 kernel_thread_helper+0x7/0x10
 May 15 19:35:42 jupiter kernel: [ 6601.223796] INFO: lockdep is turned off.
 

Oh my, that wordwrapping is painful :( You're better off using
attachments with bugzilla.

Could be a USB bug, could be a DVB bug.  I'd guess DVB.  Both lists
cc'ed for disposition, please.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fw: tua6100_sleep: i2c error when trying to tune saa7146 based DVB card

[Andrew Morton]

Begin forwarded message:

Date: Tue, 12 May 2009 09:42:35 +0200
From: Marc Haber mh+linux-ker...@zugschlus.de
To: linux-ker...@vger.kernel.org
Subject: tua6100_sleep: i2c error when trying to tune saa7146 based  DVB card


Recently, my entertainment PC has begun to refuse tuning to my
favorite stations, logging tua6100_sleep: i2c error when I try to do
so. Kaffeine says can't tune DVB.

Other stations work just fine.

The box has a saa7146 equipped budget DVB-S card which used to work
fine previously. I have first seen this behavior in kernel 2.6.29, and
still see it in 2.6.29.3.

If you need any more data, please ask and I'll try to deliver it.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] videobuf-dma-contig: zero copy USERPTR support V3

[Andrew Morton]

On Fri, 08 May 2009 17:53:10 +0900
Magnus Damm magnus.d...@gmail.com wrote:

 From: Magnus Damm d...@igel.co.jp
 
 This is V3 of the V4L2 videobuf-dma-contig USERPTR zero copy patch.
 
 Since videobuf-dma-contig is designed to handle physically contiguous
 memory, this patch modifies the videobuf-dma-contig code to only accept
 a user space pointer to physically contiguous memory. For now only
 VM_PFNMAP vmas are supported, so forget hotplug.
 
 On SuperH Mobile we use this with our sh_mobile_ceu_camera driver
 together with various multimedia accelerator blocks that are exported to
 user space using UIO. The UIO kernel code exports physically contiguous
 memory to user space and lets the user space application mmap() this memory
 and pass a pointer using the USERPTR interface for V4L2 zero copy operation.
 
 With this approach we support zero copy capture, hardware scaling and
 various forms of hardware encoding and decoding.
 
 Signed-off-by: Magnus Damm d...@igel.co.jp
 ---
 
  Needs the following patches (Thanks to Johannes Weiner and akpm):
  - mm-introduce-follow_pte.patch
  - mm-use-generic-follow_pte-in-follow_phys.patch
  - mm-introduce-follow_pfn.patch

I'l plan to merge this and the above three into 2.6.31-rc1 unless it
all gets shot down.

 +static int videobuf_dma_contig_user_get(struct videobuf_dma_contig_memory 
 *mem,
 + struct videobuf_buffer *vb)
 +{
 + struct mm_struct *mm = current-mm;
 + struct vm_area_struct *vma;
 + unsigned long prev_pfn, this_pfn;
 + unsigned long pages_done, user_address;
 + int ret;
 +
 + mem-size = PAGE_ALIGN(vb-size);
 + mem-is_userptr = 0;
 + ret = -EINVAL;
 +
 + down_read(mm-mmap_sem);
 +
 + vma = find_vma(mm, vb-baddr);
 + if (!vma)
 + goto out_up;
 +
 + if ((vb-baddr + mem-size)  vma-vm_end)
 + goto out_up;
 +
 + pages_done = 0;
 + prev_pfn = 0; /* kill warning */
 + user_address = vb-baddr;
 +
 + while (pages_done  (mem-size  PAGE_SHIFT)) {
 + ret = follow_pfn(vma, user_address, this_pfn);
 + if (ret)
 + break;
 +
 + if (pages_done == 0)
 + mem-dma_handle = this_pfn  PAGE_SHIFT;
 + else if (this_pfn != (prev_pfn + 1))
 + ret = -EFAULT;
 +
 + if (ret)
 + break;
 +
 + prev_pfn = this_pfn;
 + user_address += PAGE_SIZE;
 + pages_done++;
 + }
 +
 + if (!ret)
 + mem-is_userptr = 1;
 +
 + out_up:
 + up_read(current-mm-mmap_sem);
 +
 + return ret;
 +}

If this function really so obvious and trivial that it is best to merge
it without any documentation at all?  Has it been made as easy for
others to maintain as we can possibly make it?

What does it do, how does it do it and why does it do it?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/3] mm: introduce follow_pte()

[Andrew Morton]

On Mon,  4 May 2009 11:54:32 +0200
Johannes Weiner han...@cmpxchg.org wrote:

 A generic readonly page table lookup helper to map an address space
 and an address from it to a pte.

umm, OK.

Is there actually some point to these three patches?  If so, what is it?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/3] mm: introduce follow_pte()

[Andrew Morton]

On Tue, 5 May 2009 22:38:07 +0200
Johannes Weiner han...@cmpxchg.org wrote:

 On Tue, May 05, 2009 at 12:24:42PM -0700, Andrew Morton wrote:
  On Mon,  4 May 2009 11:54:32 +0200
  Johannes Weiner han...@cmpxchg.org wrote:
  
   A generic readonly page table lookup helper to map an address space
   and an address from it to a pte.
  
  umm, OK.
  
  Is there actually some point to these three patches?  If so, what is it?
 
 Magnus needs to check for physical contiguity of a VMAs backing pages
 to support zero-copy exportation of video data to userspace.
 
 This series implements follow_pfn() so he can walk the VMA backing
 pages and ensure their PFNs are in linear order.
 
 [ This patch can be collapsed with 2/3, I just thought it would be
   easier to read the diffs when having them separate. ]
 
 1/3 and 2/3: factor out the page table walk from follow_phys() into
 follow_pte().
 
 3/3: implement follow_pfn() on top of follow_pte().

So we could bundle these patches with Magnus's patchset, or we could
consider these three patches as a cleanup or something.

Given that 3/3 introduces an unused function, I'm inclined to sit tight
and await Magnus's work.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] dvb-core: Fix potential mutex_unlock without mutex_lock in dvb_dvr_read

[Andrew Morton]

On Thu, 30 Apr 2009 22:42:06 +0100
Simon Arlott si...@fire.lp0.eu wrote:

  diff --git a/drivers/media/dvb/dvb-core/dmxdev.c 
  b/drivers/media/dvb/dvb-core/dmxdev.c
  index c35fbb8..d6d098a 100644
  --- a/drivers/media/dvb/dvb-core/dmxdev.c
  +++ b/drivers/media/dvb/dvb-core/dmxdev.c
  @@ -247,7 +247,7 @@ static ssize_t dvb_dvr_read(struct file *file, char 
  __user *buf, size_t count,
 int ret;
   
 if (dmxdev-exit) {
  -  mutex_unlock(dmxdev-mutex);
  +  //mutex_unlock(dmxdev-mutex);
 return -ENODEV;
 }
  
  Is there any value in retaining all the commented-out lock operations,
  or can we zap 'em?
 
 I'm assuming they should really be there - it's just not practical
 because the call to dvb_dmxdev_buffer_read is likely to block waiting
 for data.

well..  such infomation is much better communicated via a nice comment,
rather than mystery-dead-code?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: + drivers-media-video-saa7134-add-tuner-support-for-avermedia-studio-505.patch added to -mm tree

[Andrew Morton]

On Wed, 22 Apr 2009 01:21:18 +0200 hermann pitton hermann-pit...@arcor.de 
wrote:

 Hmm, do we try to fix/improve it on Andrew's tree or take it over to
 mercurial v4l-dvb and send back from there?

I'll drop the patch which I have.  Please don't lose it!
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fw: PROBLEM: crashes or unstability while watching tv with MPlayer from pci bttv card

[Andrew Morton]

Begin forwarded message:

Date: Wed, 15 Apr 2009 06:31:46 -0500
From: Alejandro Vélez null...@gmail.com
To: linux-ker...@vger.kernel.org
Subject: PROBLEM: crashes or unstability while watching tv with MPlayer from  
pci bttv card


[1.] One line summary of the problem:

General system unstability occurs while previewing any video input
from the pci bttv-card with MPlayer SVN.

[2.] Full description of the problem/report:

after a time of watching or previewing the tv card input with MPlayer
the system becomes irreversibly unstable, for example the kernel can
crash in a different number of ways all the times that that I have
reproduced such behavior or the system just lockups with the caps lock
and scroll lock leds blinking.

[3.] Keywords (i.e., modules, networking, kernel):

kernel, crashes, lockups, unstability, MPlayer, Hauppauge WinTV-Go,
bttv, X11, bttv.

[4.] Kernel version (from /proc/version):

Linux version 2.6.29.1-smp (r...@midas) (gcc version 4.3.3 (GCC) ) #1
SMP Fri Apr 10 18:42:54 CDT 2009

[5.] Output of Oops.. message (if applicable) with symbolic
information resolved (see Documentation/oops-tracing.txt)

Not Applicable. There's a different type of kernel crash if there's it
at all everytime that I reproduce the bug.

[6.] A small shell script or example program which triggers the
problem (if possible)

I just preview the tv input with the command: mplayer tv:// -tv input=1:normid=0

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux slacktoo 2.6.29.1-smp #1 SMP Fri Apr 10 18:42:54 CDT 2009 i686
Unknown CPU Type AuthenticAMD GNU/Linux

Gnu C  4.2.3
Gnu make   3.81
binutils   2.17.50.0.17.20070615
util-linux 2.13.1
mount  2.13.1
module-init-tools  found
quota-tools3.13.
Linux C Library2.7
Dynamic linker (ldd)   2.7
Linux C++ Library  6.0.9
Procps 3.2.7
Kbd1.12
oprofile   0.9.2
Sh-utils   6.9
udev   118
Modules Loaded savage drm bsd_comp ppp_synctty ppp_async
crc_ccitt ppp_generic slhc it87 hwmon_vid snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss ipt_MASQUERADE
xt_limit xt_pkttype ipt_REJECT xt_tcpudp xt_state ipt_LOG
iptable_mangle iptable_nat iptable_filter nf_conntrack_irc nf_nat_ftp
nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4
ip_tables x_tables nls_utf8 ntfs xfs exportfs quota_v2 quota_tree lp
fuse tuner_simple tuner_types tuner tvaudio fan snd_cs4232
snd_wavefront snd_wss_lib ns558 snd_opl3_lib snd_hwdep bttv snd_mpu401
ir_common i2c_algo_bit v4l2_common thermal parport_pc videodev parport
v4l1_compat serio_raw processor thermal_sys hwmon videobuf_dma_sg
videobuf_core evdev psmouse button rtc_cmos rtc_core rtc_lib
snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer
snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd
soundcore btcx_risc uhci_hcd via_agp tveeprom i2c_viapro shpchp
agpgart sundance i2c_core 8139too mii sg ext3 jbd mbcache

[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 8
model name  : Unknown CPU Type
stepping: 1
cpu MHz : 1673.954
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up
bogomips: 3347.90
clflush size: 32
power management: ts

[7.3.] Module information (from /proc/modules):

savage 30940 2 - Live 0xe6ccb000
drm 137824 3 savage, Live 0xe6ae7000
bsd_comp 5244 0 - Live 0xe6f2e000
ppp_synctty 6940 0 - Live 0xe6eca000
ppp_async 8668 1 - Live 0xe6de5000
crc_ccitt 1628 1 ppp_async, Live 0xe6ddd000
ppp_generic 22472 7 bsd_comp,ppp_synctty,ppp_async, Live 0xe6d88000
slhc 5404 1 ppp_generic, Live 0xe6d6d000
it87 19820 0 - Live 0xe6d51000
hwmon_vid 2684 1 it87, Live 0xe6d4e000
snd_seq_dummy 2464 0 - Live 0xe6cc6000
snd_seq_oss 29792 0 - Live 0xe6ca3000
snd_seq_midi_event 5980 1 snd_seq_oss, Live 0xe6c8e000
snd_seq 47984 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event, Live 0xe6a67000
snd_pcm_oss 37728 0 - Live 0xe683e000
snd_mixer_oss 14300 1 snd_pcm_oss, Live 0xe6812000
ipt_MASQUERADE 2460 1 - Live 0xe897a000
xt_limit 1824 3 - Live 0xe8885000
xt_pkttype 1372 1 - Live 0xe886d000
ipt_REJECT 2780 8 - Live 0xe8659000
xt_tcpudp 2620 40 - Live 0xe852f000
xt_state 1756 7 - Live 0xe84f4000
ipt_LOG 5344 13 - Live 0xe84d8000
iptable_mangle 2332 0 - Live 0xe843b000
iptable_nat 4796 1 - Live 0xe8415000
iptable_filter 2268 1 - Live 0xe83f
nf_conntrack_irc 

Re: USB DVB unplug: kernel BUG at kernel/module.c:912!

[Andrew Morton]

On Tue, 31 Mar 2009 14:28:45 +0200 (CEST) Geert Uytterhoeven 
geert.uytterhoe...@sonycom.com wrote:

 When unplugging a Sony PlayTV USB DVB adaptor from a PS3, I get
 
 | kernel BUG at kernel/module.c:912!
 
 on 2.6.29-06608-g15f7176.
 
 Insert Sony PlayTV USB:
 
 Mar 31 13:41:57 ps3 kernel: [  266.556878] usb 1-2.1: new high speed USB 
 device using ps3-ehci-driver and address 6
 Mar 31 13:41:57 ps3 kernel: [  266.649435] usb 1-2.1: New USB device found, 
 idVendor=1415, idProduct=0003
 Mar 31 13:41:57 ps3 kernel: [  266.649448] usb 1-2.1: New USB device strings: 
 Mfr=1, Product=2, SerialNumber=3
 Mar 31 13:41:57 ps3 kernel: [  266.649457] usb 1-2.1: Product: SCEH-0036
 Mar 31 13:41:57 ps3 kernel: [  266.649464] usb 1-2.1: Manufacturer: SONY
 Mar 31 13:41:57 ps3 kernel: [  266.649475] usb 1-2.1: SerialNumber: ALR001GLZS
 Mar 31 13:41:57 ps3 kernel: [  266.649819] usb 1-2.1: configuration #1 chosen 
 from 1 choice
 Mar 31 13:41:58 ps3 kernel: [  267.496197] dib0700: loaded with support for 9 
 different device-types
 Mar 31 13:41:58 ps3 kernel: [  267.497162] dvb-usb: found a 'Sony PlayTV' in 
 cold state, will try to load a firmware
 Mar 31 13:41:58 ps3 kernel: [  267.497182] usb 1-2.1: firmware: requesting 
 dvb-usb-dib0700-1.20.fw
 Mar 31 13:41:58 ps3 kernel: [  267.547717] dvb-usb: downloading firmware from 
 file 'dvb-usb-dib0700-1.20.fw'
 Mar 31 13:41:58 ps3 kernel: [  267.760597] dib0700: firmware started 
 successfully.
 Mar 31 13:41:59 ps3 kernel: [  268.264509] dvb-usb: found a 'Sony PlayTV' in 
 warm state.
 Mar 31 13:41:59 ps3 kernel: [  268.264696] dvb-usb: will pass the complete 
 MPEG2 transport stream to the software demuxer.
 Mar 31 13:41:59 ps3 kernel: [  268.265293] DVB: registering new adapter (Sony 
 PlayTV)
 Mar 31 13:41:59 ps3 kernel: [  268.502455] DVB: registering adapter 0 
 frontend 0 (DiBcom 7000PC)...
 Mar 31 13:41:59 ps3 kernel: [  268.685103] DiB0070: successfully identified
 Mar 31 13:41:59 ps3 kernel: [  268.685117] dvb-usb: will pass the complete 
 MPEG2 transport stream to the software demuxer.
 Mar 31 13:41:59 ps3 kernel: [  268.685539] DVB: registering new adapter (Sony 
 PlayTV)
 Mar 31 13:41:59 ps3 kernel: [  268.842648] DVB: registering adapter 1 
 frontend 0 (DiBcom 7000PC)...
 Mar 31 13:42:00 ps3 kernel: [  269.029071] DiB0070: successfully identified
 Mar 31 13:42:00 ps3 kernel: [  269.029331] input: IR-receiver inside an USB 
 DVB receiver as /class/input/input3
 Mar 31 13:42:00 ps3 kernel: [  269.052670] dvb-usb: schedule remote query 
 interval to 50 msecs.
 Mar 31 13:42:00 ps3 kernel: [  269.052685] dvb-usb: Sony PlayTV successfully 
 initialized and connected.
 Mar 31 13:42:00 ps3 kernel: [  269.052917] usbcore: registered new interface 
 driver dvb_usb_dib0700
 
 Unplug Sony PlayTV USB:
 
 Mar 31 14:01:28 ps3 kernel: [ 1437.101593] usb 1-2.1: USB disconnect, address 
 6
 Mar 31 14:01:28 ps3 kernel: [ 1437.133461] [ cut here 
 ]
 Mar 31 14:01:28 ps3 kernel: [ 1437.137955] kernel BUG at kernel/module.c:912!
 Mar 31 14:01:28 ps3 kernel: [ 1437.142408] Oops: Exception in kernel mode, 
 sig: 5 [#1]
 Mar 31 14:01:28 ps3 kernel: [ 1437.146533] SMP NR_CPUS=2 PS3
 Mar 31 14:01:28 ps3 kernel: [ 1437.150560] Modules linked in: dvb_usb_dib0700 
 dib7000p dib3000mc dvb_usb dvb_core dib7000m dibx000_common dib0070 i2c_core 
 nfsd exportfs dm_crypt dm_mod sg ps3disk ps3rom ps3flash ps3stor_lib ps3vram 
 joydev evdev
 Mar 31 14:01:28 ps3 kernel: [ 1437.155317] NIP: c008ae54 LR: 
 c008ae4c CTR: c008ae20
 Mar 31 14:01:28 ps3 kernel: [ 1437.159706] REGS: c6987410 TRAP: 0700  
  Tainted: GW   (2.6.29-06608-g15f7176)
 Mar 31 14:01:28 ps3 kernel: [ 1437.164144] MSR: 80028032 
 EE,CE,IR,DR  CR: 44004042  XER: 2000
 Mar 31 14:01:28 ps3 kernel: [ 1437.168636] TASK = c69811c0[111] 
 'khubd' THREAD: c6984000 CPU: 0
 Mar 31 14:01:28 ps3 kernel: [ 1437.168853] GPR00: c05777f8 
 c6987690 c0639b20  
 Mar 31 14:01:28 ps3 kernel: [ 1437.173362] GPR04: c00d1504 
 d29ced10  c065dc68 
 Mar 31 14:01:28 ps3 kernel: [ 1437.177894] GPR08:  
 c05777f8 d28092f8 c05777f8 
 Mar 31 14:01:28 ps3 kernel: [ 1437.182439] GPR12: d29d53f0 
 c0664200 00e9 c6d71830 
 Mar 31 14:01:28 ps3 kernel: [ 1437.186985] GPR16: 03e8 
  c6de9400 c6d71830 
 Mar 31 14:01:28 ps3 kernel: [ 1437.191559] GPR20:  
  c6cc6000 c6cc6000 
 Mar 31 14:01:28 ps3 kernel: [ 1437.196120] GPR24: 0001 
 c6cc63a0 c6bf90e8 c122c800 
 Mar 31 14:01:28 ps3 kernel: [ 1437.200676] GPR28: 0001 
 c312a000 d2b5c080 d28092f8 
 Mar 31 14:01:28 ps3 kernel: [ 1437.209542] NIP [c008ae54] 
 .symbol_put_addr+0x34/0x64
 Mar 31 14:01:28 ps3 

Re: [PATCH -next] dvb/frontends: fix duplicate 'debug' symbol

[Andrew Morton]

On Fri, 06 Mar 2009 13:24:46 -0800
Randy Dunlap randy.dun...@oracle.com wrote:

 It would also be Good if arch/x86/kernel/entry_32.S didn't have a
 non-static 'debug' symbol.  OTOH, it helps catch things like this one.

heh, yes, it's a feature.  We should put it in init/main.c, along with
100-odd other dont-do-that-dopey symbols.



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Fw: oops in pwc_reset_buffers

[Andrew Morton]

Begin forwarded message:

Date: Thu, 05 Mar 2009 14:53:17 +0100
From: strawks stra...@yahoo.fr
To: linux-ker...@vger.kernel.org
Subject: oops in pwc_reset_buffers


Hi all,

On 2.6.29-rc6, when resuming from suspend to RAM I got the following 
oops when motion tried to open /dev/video0. Just ask me if you need some 
additionnal info (full log attached).

regards,
strawks

Mar  5 08:26:38 evangeline kernel: [109985.797284] BUG: unable to handle 
kernel NULL pointer dereference at 0008
Mar  5 08:26:38 evangeline kernel: [109985.797290] IP: 
[a01d1439] pwc_reset_buffers+0x4a/0xdd [pwc]
Mar  5 08:26:38 evangeline kernel: [109985.797299] PGD 51dad067 PUD 
18485067 PMD 0
Mar  5 08:26:38 evangeline kernel: [109985.797302] Oops: 0002 [#1] SMP
Mar  5 08:26:38 evangeline kernel: [109985.797305] last sysfs file: 
/sys/class/video4linux/video0/index
Mar  5 08:26:38 evangeline kernel: [109985.797307] CPU 0
Mar  5 08:26:38 evangeline kernel: [109985.797308] Modules linked in: 
i915 drm i2c_algo_bit acpi_cpufreq cpufreq_conservative 
cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_ondemand 
freq_table ipv6 fuse coretemp it87 hwmon_vid sbp2 loop 
snd_hda_codec_intelhdmi snd_hda_codec_realtek snd_usb_audio 
snd_hda_intel snd_usb_lib snd_hda_codec snd_seq_midi snd_seq_midi_event 
snd_rawmidi snd_pcm snd_hwdep snd_seq snd_timer snd_seq_device pwc 
i2c_i801 psmouse snd videodev v4l1_compat i2c_core serio_raw iTCO_wdt 
snd_page_alloc soundcore pcspkr v4l2_compat_ioctl32 joydev intel_agp 
button evdev ext3 jbd mbcache ide_gd_mod ata_piix ata_generic libata 
scsi_mod hid_logitech ff_memless usbhid hid ohci1394 ieee1394 
ide_pci_generic it8213 ide_core ehci_hcd r8169 mii uhci_hcd thermal 
processor fan thermal_sys
Mar  5 08:26:38 evangeline kernel: [109985.797356] Pid: 26749, comm: 
motion Not tainted 2.6.29-rc6 #1 EG45M-DS2H
Mar  5 08:26:38 evangeline kernel: [109985.797359] RIP: 
0010:[a01d1439]  [a01d1439] 
pwc_reset_buffers+0x4a/0xdd [pwc]
Mar  5 08:26:38 evangeline kernel: [109985.797366] RSP: 
0018:880018519cb8  EFLAGS: 00010046
Mar  5 08:26:38 evangeline kernel: [109985.797368] RAX:  
RBX: 880037968c00 RCX: 
Mar  5 08:26:38 evangeline kernel: [109985.797370] RDX: 805852b8 
RSI: 0296 RDI: 
Mar  5 08:26:38 evangeline kernel: [109985.797372] RBP: 880037968e70 
R08: 0003 R09: 
Mar  5 08:26:38 evangeline kernel: [109985.797375] R10:  
R11: 804697f2 R12: 0001
Mar  5 08:26:38 evangeline kernel: [109985.797377] R13: 000a 
R14: 00f0 R15: 0140
Mar  5 08:26:38 evangeline kernel: [109985.797379] FS: 
7faba7078950() GS:80671000() knlGS:
Mar  5 08:26:38 evangeline kernel: [109985.797382] CS:  0010 DS:  
ES:  CR0: 8005003b
Mar  5 08:26:38 evangeline kernel: [109985.797384] CR2: 0008 
CR3: 533a7000 CR4: 000406e0
Mar  5 08:26:38 evangeline kernel: [109985.797386] DR0:  
DR1:  DR2: 
Mar  5 08:26:38 evangeline kernel: [109985.797388] DR3:  
DR6: 0ff0 DR7: 0400
Mar  5 08:26:38 evangeline kernel: [109985.797391] Process motion (pid: 
26749, threadinfo 880018518000, task 88007b3b0050)
Mar  5 08:26:38 evangeline kernel: [109985.797393] Stack:
Mar  5 08:26:38 evangeline kernel: [109985.797394]  0001 
 880037968c00 a01d270d
Mar  5 08:26:38 evangeline kernel: [109985.797397]   
c0d05605 88007b8ac080 880037968c00
Mar  5 08:26:38 evangeline kernel: [109985.797401]  88007a8c5400 
  a01d616c
Mar  5 08:26:38 evangeline kernel: [109985.797405] Call Trace:
Mar  5 08:26:38 evangeline kernel: [109985.797408]  [a01d270d] 
? pwc_try_video_mode+0x2d/0xa5 [pwc]
Mar  5 08:26:38 evangeline kernel: [109985.797414]  [a01d616c] 
? pwc_video_do_ioctl+0xe8b/0x127b [pwc]
Mar  5 08:26:38 evangeline kernel: [109985.797421]  [802379d7] 
? default_wake_function+0x0/0x9
Mar  5 08:26:38 evangeline kernel: [109985.797426]  [a01a1a46] 
? video_usercopy+0x17a/0x217 [videodev]
Mar  5 08:26:38 evangeline kernel: [109985.797433]  [a01d52e1] 
? pwc_video_do_ioctl+0x0/0x127b [pwc]
Mar  5 08:26:38 evangeline kernel: [109985.797439]  [a01d164c] 
? pwc_video_ioctl+0x65/0x7f [pwc]
Mar  5 08:26:38 evangeline kernel: [109985.797446]  [a01a110b] 
? v4l2_ioctl+0x38/0x3a [videodev]
Mar  5 08:26:38 evangeline kernel: [109985.797451]  [802c2aa3] 
? vfs_ioctl+0x56/0x6c
Mar  5 08:26:38 evangeline kernel: [109985.797455]  [802c2ef2] 
? do_vfs_ioctl+0x439/0x472
Mar  5 08:26:38 evangeline kernel: [109985.797458]  [802b74c3] 
? vfs_write+0x121/0x156
Mar  5 08:26:38 evangeline kernel: [109985.797462]  

Re: [Bugme-new] [Bug 12768] New: usb_alloc_urb() leaks memory together with uvcvideo driver

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Mon, 23 Feb 2009 22:08:37 -0800 (PST)
bugme-dae...@bugzilla.kernel.org wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=12768

There's additional info at the link.

Summary: usb_alloc_urb() leaks memory together with uvcvideo
 driver
Product: Drivers
Version: 2.5
  KernelVersion: 2.6.28
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: USB
 AssignedTo: g...@kroah.com
 ReportedBy: nm...@freemail.hu
 
 
 Latest working kernel version:
 Earliest failing kernel version:
 Distribution:
 Hardware Environment: EeePC 901
 Software Environment: Debian 5.0
 Problem Description:
 
 Steps to reproduce:
 1. Boot the system
 2. start an xterm window and execute the following command:
 
 $ while true; do clear; cat /proc/slab_allocators |grep usb_alloc; sleep 1;
 done
 
 This will print out similar lines each second:
 
 size-2048: 18 usb_alloc_dev+0x1d/0x212 [usbcore]
 size-2048: 2280 usb_alloc_urb+0xc/0x2b [usbcore]
 size-1024: 85 usb_alloc_urb+0xc/0x2b [usbcore]
 size-128: 10 usb_alloc_urb+0xc/0x2b [usbcore]
 
 3. Start xawtv, this will show the picture of the webcam
 4. Exit xawtv
 
 Current result:
 In the output of /proc/slab_allocators the number of blocks allocated by
 usb_alloc_urb() increases, however, the xawtv is no longer running:
 
 size-2048: 18 usb_alloc_dev+0x1d/0x212 [usbcore]
 size-2048: 2280 usb_alloc_urb+0xc/0x2b [usbcore]
 size-1024: 100 usb_alloc_urb+0xc/0x2b [usbcore]
 size-128: 10 usb_alloc_urb+0xc/0x2b [usbcore]
 
 Each time xawtv is started and stopped the value increases at the
 usb_alloc_urb().
 
 Expected result: the same memory usage is reached again after xawtv exited.
 

I assume this is a v4l bug and not a USB core bug?

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html