* Re: [PATCH/RFC v3 0/7] Videobuf2 framework
From: Kyungmin Park @ 2010-10-20 7:18 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Marek Szyprowski, linux-media, pawel
In-Reply-To: <201010200914.32868.hverkuil@xs4all.nl>
On Wed, Oct 20, 2010 at 4:14 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On Wednesday, October 20, 2010 08:41:06 Marek Szyprowski wrote:
>> Hello,
>>
>> As I promissed I continue the development of the VideoBuf2 at Samsung
>> until Pawel finds some spare time to help us. This is a third version of
>> the framework. Besides the minor bugfixes here and there I've added a
>> complete read() callback emulator. This emulator provides 2 types of
>> read() operation - 'streaming' and 'one shot'. It is suitable to replace
>> both videobuf_read_stream() and videobuf_read_one() methods from the old
>> videobuf.
>
> One thing I never understood: what is the point of supporting 'one shot' read
> mode? Why not support just streaming? Does anyone know?
>
> Another question: how hard is it to support write mode as well? I think
> vb2 should support both. I suspect that once we have a read emulator it isn't
> difficult to make a write emulator too.
One thing consideration is that with this implementation we can't meet
merge window for 2.6.37.
How do you think?
Thank you,
Kyungmin Park
>
> A last remark: the locking has changed recently in videobuf due to the work
> done on eliminating the BKL. It's probably a good idea to incorporate those
> changes as well in vb2.
>
> Regards,
>
> Hans
>
>>
>> Taking into account the size of the patches and the number of lines I've
>> changed, I've decided to keep the Pawel signed-off attribute and
>> authorship to correctly credit him. If this is against kernel rules,
>> feel free to let me know.
>>
>> Best regards
>> --
>> Marek Szyprowski
>> Samsung Poland R&D Center
>>
>>
>> Changes since V2:
>> =================
>> - added read() emulator (see patch #5/7)
>> - fixed lack of parentheses in macro definitions (caused side effects
>> in some places)
>> - added a separate check for VM_READ or VM_WRITE in vb2_mmap()
>> - added vb2_is_streaming(), vb2_lock and vb2_unlock inlines
>> - updated vivi driver with the new read() emulator
>>
>> Changes since V1:
>> =================
>> - removed drv_lock, added start_streaming and stop_streaming callbacks
>>
>>
>> Here is the original Videobuf2 introduction prepared by Pawel:
>> =======================================================================
>>
>> These patches add a new driver framework for Video for Linux 2 driver
>> - Videobuf2.
>>
>> Videobuf2 is intended as a replacement for videobuf, the current driver
>> framework, which will be referred to as "videobuf1" for the remainder
>> of this document.
>>
>> ================================
>> What is videobuf2?
>> ================================
>> Videobuf2 is a Video for Linux 2 API-compatible driver framework for
>> multimedia devices. It acts as an intermediate layer between userspace
>> applications and device drivers. It also provides low-level, modular
>> memory management functions for drivers.
>>
>> Videobuf2 eases driver development, reduces drivers' code size and aids in
>> proper and consistent implementation of V4L2 API in drivers.
>>
>> Videobuf2 memory management backend is fully modular. This allows custom
>> memory management routines for devices and platforms with non-standard
>> memory management requirements to be plugged in, without changing the
>> high-level buffer management functions and API.
>>
>> The framework provides:
>> - implementations of streaming I/O V4L2 ioctls and file operations
>> - high-level video buffer, video queue and state management functions
>> - video buffer memory allocation and management
>>
>> ================================
>> Why a new framework?
>> ================================
>> There have been many discussions in the V4L2 community about the feasibility
>> of writing a new framework, as opposed to fixing the existing one. It has been
>> agreed though that:
>> - videobuf1 has major flaws and an attempt to fix it would end up in rewriting
>> most of the code
>> - many drivers depend on videobuf1 and since the changes would be major,
>> an effort to adapt and test them all would not be realistically possible
>>
>> Due to the problems with videobuf most new drivers cannot use it. This leads
>> to code replication and overcomplicated drivers.
>>
>> ================================
>> What is wrong with videobuf1?
>> ================================
>> There are many problems with the current videobuf implementation. During a V4L2
>> mini-summit in Helsinki in June 2010, two presentations were delivered
>> on this topic:
>> - Laurent Pinchart "videobuf - the good, the bad and the ugly"
>> http://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-v4l2_summit-videobuf.pdf
>> - Pawel Osciak "Future of the videobuf framework"
>> http://linuxtv.org/downloads/presentations/summit_jun_2010/Videobuf_Helsinki_June2010.pdf
>>
>> These presentations highlighted many problems with videobuf. The most prominent
>> include:
>>
>> - V4L2 API violations and wrong memory management design
>> - it is impossible to pause streaming (buffers are freed on streamoff)
>> - VIDIOC_REQBUFS(0) does not free memory
>> - it is impossible to reallocate memory with VIDIOC_REQBUFS
>> - video memory is allocated on mmap, qbuf or even on page fault,
>> freed on unmap, streamoff or explicitly by drivers
>> - per-buffer waitqueues
>> - not extensible enough and thus not ready for new platforms and uses,
>> especially considering embedded multimedia devices
>> - very hard to add new memory handling routines and custom memory allocators
>> - no or poor support for handling cache coherency, IOMMUs,
>> - poor flexibility - only one do-it-all function for handling memory pinning,
>> cache, sg-list creation, etc...
>> - unused fields, code duplication, vague/inconsistent naming, obscure usage in
>> some places...
>>
>> Many driver authors expressed their frustration with videobuf. Developers
>> acknowledge its merits and would like to use it, but due mostly to its
>> inflexible memory allocation schemes they are unable to do so.
>>
>> ================================
>> Main goals of the redesign
>> ================================
>> - correct V4L2 API implementation, fixing videobuf1 problems and shortcomings
>> - full separation between queue management and memory management
>> - fully flexible, pluggable memory allocators and memory handling routines
>> - more specialized driver callbacks, called at different points
>> - support for new V4L2 API extensions, such as multi-planar video buffers
>>
>> ================================
>> Driver callbacks
>> ================================
>> Driver callbacks have been redesigned for symmetry:
>> - buf_init - called once, after memory is allocated or after a new USERPTR
>> buffer is queued; can be used e.g. to pin pages, verify contiguity, set up
>> IOMMU mappings, etc.
>> - buf_prepare - called on each QBUF; can be used e.g. for cache sync, copying
>> to bounce buffers, etc.
>> - buf_finish - called on each DQBUF; can be used e.g. for cache sync, copying
>> back from bounce buffers, etc.
>> - buf_cleanup - called before freeing/releasing memory; can be used e.g. for
>> unmapping memory, etc.
>>
>> The remaining driver callbacks have been slightly redesigned:
>> - queue_negotiate - now incorporates multi-planar extensions; drivers return
>> required number of buffers and planes per buffer
>> - plane_setup - drivers return plane sizes
>> Those two callbacks replace the old buf_setup.
>>
>> - buf_queue - basically stays the same
>>
>> ================================
>> Memory allocators and handling
>> ================================
>> Memory handling has been designed to allow more customization than in the
>> original videobuf. For this memory allocation ops have been slightly redesigned,
>> and have become fully replaceable and an allocator context struct have been
>> introduced.
>>
>> Allocator context is intended to provide memory operations to videobuf and also
>> for storing allocator private data, if required, although simpler allocators
>> do not have to use this feature. Private data can be added by embedding the
>> context struct inside their own structures:
>>
>> struct vb2_alloc_ctx {
>> const struct vb2_mem_ops *mem_ops;
>> };
>>
>> struct vb2_foo_alloc_conf {
>> struct vb2_alloc_ctx alloc_ctx;
>> /* Allocator private data here */
>> };
>>
>> Moreover, a buffer context structure concept has been introduced. Allocators
>> return their own, custom, per-buffer structures on every allocation. This
>> structure is then used as a "cookie" and passed to other memory handling
>> methods called for its corresponding buffer.
>>
>> Memory operations, stored in the allocator context, can be replaced if
>> needed by drivers on a per-function basis and functions from other allocators
>> or drivers can be reused as well. A full list with documentation can be found
>> in the videobuf2-core.h file.
>>
>> It is also possible, although not required, to assign different contexts per
>> plane. This may be useful for drivers that need to use different memory types
>> for different planes. An example may be a driver that stores video data in the
>> first plane, which has to be allocated from a device-accessible memory area,
>> and metadata in the second plane, which does not have to be stored in
>> a device-accessible memory.
>>
>> An good example of integrating a more advanced allocator, the recently discussed
>> on this list CMA (contiguous memory allocator), can be found in videobuf2-cma.*.
>>
>> ================================
>> Other changes
>> ================================
>> The changes described above are the main changes in videobuf2. Most of the core
>> API has remained the same or very similar, although its implementation has been
>> fully rewritten. Some more visible changes include:
>>
>> - Memory is now properly allocated on REQBUFS and can be freed and reallocated
>> there as well.
>> - It is now possible to pause and resume streaming with streamon/streamoff,
>> without freeing the buffers.
>> - V4L2 API-related, userspace-visible metadata, such as inputs, timestamps, etc.
>> are no longer stored in videobuf buffer structure, but in an actual
>> v4l2_buffer struct (idea borrowed from Laurent Pinchart). I felt that driver
>> authors would prefer to use V4L2 API-based structures of videobuf custom
>> structures where possible. It also eases copying v4l2_buffer-related data
>> from/to userspace.
>> - Buffers do not include waitqueues anymore. One, global, per-queue waitqueue
>> for done buffers has been introduced instead. Per-buffer waitqueues were not
>> very useful and introduced additional complications in code.
>> With this, drivers have gained the ability of dequeuing buffers out-of-order
>> as well.
>> - Buffer states are not handled jointly by both videobuf and driver anymore,
>> I felt it was not required and confusing for driver authors
>> - Some fields that were less useful have been removed and naming of others
>> have been changed to better reflect their function.
>> - Other then reqbufs, ioctl implementations have remained almost the same
>> and behave in the same way,
>>
>>
>> Please see documentation in videobuf2-core.c and videobuf2-core.h for more
>> details and the patch porting vivi to videobuf2 for how to port existing
>> drivers to videobuf2.
>>
>> This is a preliminary version intended for review, but has already been tested
>> for multiple drivers and different memory handling implementations. DMA-SG
>> implementation is not included yet.
>>
>> The CMA allocator patches are attached for reference, to show how a more
>> complicated allocator can be integrated into the framework.
>>
>> Any comments will be very much appreciated!
>>
>> Best regards,
>> Pawel Osciak
>> Linux Platform Group
>> Samsung Poland R&D Center
>>
>> =======================================================================
>>
>> Patch summary:
>>
>> Pawel Osciak (6):
>> v4l: add videobuf2 Video for Linux 2 driver framework
>> v4l: videobuf2: add generic memory handling routines
>> v4l: videobuf2: add vmalloc allocator
>> v4l: videobuf2: add DMA coherent allocator
>> v4l: vivi: port to videobuf2
>> v4l: videobuf2: add CMA allocator
>>
>> Marek Szyprowski (1):
>> v4l: videobuf2: add read() emulator
>>
>> drivers/media/video/Kconfig | 23 +-
>> drivers/media/video/Makefile | 6 +
>> drivers/media/video/videobuf2-cma.c | 250 ++++
>> drivers/media/video/videobuf2-core.c | 1726 ++++++++++++++++++++++++++
>> drivers/media/video/videobuf2-dma-coherent.c | 208 ++++
>> drivers/media/video/videobuf2-memops.c | 199 +++
>> drivers/media/video/videobuf2-vmalloc.c | 177 +++
>> drivers/media/video/vivi.c | 348 +++---
>> include/media/videobuf2-cma.h | 25 +
>> include/media/videobuf2-core.h | 392 ++++++
>> include/media/videobuf2-dma-coherent.h | 21 +
>> include/media/videobuf2-memops.h | 31 +
>> include/media/videobuf2-vmalloc.h | 16 +
>> 13 files changed, 3258 insertions(+), 164 deletions(-)
>> create mode 100644 drivers/media/video/videobuf2-cma.c
>> create mode 100644 drivers/media/video/videobuf2-core.c
>> create mode 100644 drivers/media/video/videobuf2-dma-coherent.c
>> create mode 100644 drivers/media/video/videobuf2-memops.c
>> create mode 100644 drivers/media/video/videobuf2-vmalloc.c
>> create mode 100644 include/media/videobuf2-cma.h
>> create mode 100644 include/media/videobuf2-core.h
>> create mode 100644 include/media/videobuf2-dma-coherent.h
>> create mode 100644 include/media/videobuf2-memops.h
>> create mode 100644 include/media/videobuf2-vmalloc.h
>>
>>
>
> --
> Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Call for help for demo UPNP media renderer
From: Joshua Lock @ 2010-10-20 7:18 UTC (permalink / raw)
To: Xu, Dongxiao; +Cc: yocto@yoctoproject.org
In-Reply-To: <D5AB6E638E5A3E4B8F4406B113A5A19A2FF0D378@shsmsx501.ccr.corp.intel.com>
On Wed, 2010-10-20 at 14:07 +0800, Xu, Dongxiao wrote:
> Hi Josh,
>
> Today I took a glance at the rygel crash issue in poky. Though I didn't
> get the root cause, I found when configure Tracker plugin into rygel,
> the segmentation fault will happen. Since we have already configured
> the media-export plugin, and tracker plugin plays the same role, I
> think we can simply disable tracker plugin (by configure time or change
> by rygel-preferences) for demo usage.
Yes, I thought I mentioned disabling the tracker plugin in an earlier
mail? I'll prepare a patch to the recipe to disable that so we don't
have to remember to do that by hand.
Cheers,
Joshua
>
> Thanks,
> Dongxiao
>
> Xu, Dongxiao wrote:
> > I just built out the poky-image-rygel image with your meta-demo
> > layer, and run
> >
> > rygel --gst-debug-level=5
> >
> > I still saw it "segmentation fault" in the last...
> >
> > I am looking into it.
> >
> > Thanks,
> > Dongxiao
> >
> > Xu, Dongxiao wrote:
> >> Zanussi, Tom wrote:
> >>> On Tue, 2010-10-19 at 17:40 -0700, Xu, Dongxiao wrote:
> >>>> Joshua Lock wrote:
> >>>>> On Wed, 2010-10-20 at 01:04 +0100, Joshua Lock wrote:
> >>>>>> On Tue, 2010-10-19 at 14:31 -0700, Saul Wold wrote:
> >>>>>>>
> >>>>>>> Dongxiao,
> >>>>>>>
> >>>>>>> Can you take a look at this since you have worked with the
> >>>>>>> gstreamer?
> >>>>>>
> >>>>>> I did a sloppy job pushing my changes when leaving the office but
> >>>>>> think I have replicated most/all of the in the josh/demo branch.
> >>>>>>
> >>>>>> I also took a look through the rygel code to see what gstreamer
> >>>>>> elements are explicitly being used, I've created a list and tried
> >>>>>> to ensure as many as possible of them are in the IMAGE_INSTALL
> >>>>>> list for poky-image-rygel, adding them to the RDEPENDS for rygel
> >>>>>> doesn't appear to have included them in the image I just
> >>>>>> created...
> >>>>>>
> >>>>>> Full list of names of pipeline elements I found in the rygel
> >>>>>> code follows:
> >>>>>>
> >>>>>> decodebin2, videorate, videoscale, ffmpegcolorspace, ffenc_wmv1,
> >>>>>> twolame, lame, mp3parse, ffenc_wmav2, convert-sink-pad,
> >>>>>> ffenc_mpeg2video, audio-src-pad, audio-sink-pad,
> >>>>>> audio-enc-sink-pad, sink, mpegtsmux, audioconvert, audioresample,
> >>>>>> audiorate, capsfilter, audiotestsrc, videotestsrc, ffmux_asf
> >>>>>>
> >>>>>
> >>>>> The image I just built with my latest changes in josh/demo
> >>>>> worked!?! Rygel did not segfault :-)
> >>>>>
> >>>>> If you have time Dongxiao (or anyone else) I'd appreciate if you
> >>>>> could double-check my changes (my install_append in rygel to
> >>>>> create a .config isn't working, so you'll need to do that
> >>>>> manually and run rygel-preferences to disable the tracker
> >>>>> plugin). If you could test using Rygel as a renderer for some
> >>>>> content served by the mediatomb image, that would be much
> >>>>> appreciated. You'll want gupnp-av-cp as provided by gupnp-tools
> >>>>> to control the renderer and content server.
> >>>>>
> >>>>> Thanks,
> >>>>> Joshua
> >>>>
> >>>> I will try your branch, however I didn't find josh/demo in
> >>>> poky-contrib. Is it reside in other place?
> >>>>
> >>>
> >>> It should be here:
> >>>
> >>> ssh://git@git.pokylinux.org/meta-demo.git
> >>>
> >>> Tom
> >>
> >> Got it, thanks!
> >>
> >> Dongxiao
> >> _______________________________________________
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.pokylinux.org/listinfo/yocto
>
--
Joshua Lock
Intel Open Source Technology Centre
^ permalink raw reply
* [U-Boot] [RFC/PATCH] Makefile: allow boards to check file size limits
From: Wolfgang Denk @ 2010-10-20 7:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTinvwZsVZosDgLtGV2LiJhU0QWQoQdfD765z=1SH@mail.gmail.com>
Dear Vaibhav Bedia,
In message <AANLkTinvwZsVZosDgLtGV2LiJhU0QWQoQdfD765z=1SH@mail.gmail.com> you wrote:
>
> Just displaying the binary size can be misleading IMHO. If the info printed
> contains the complete memory requirement (stack+heap+bss) then it can
> potentially save a lot of time during debugging
Just run "MAKEALL" for your board and you get exactly what you are
asking for,
> either way, none of this is related to my patch.
> > -mike
> >
You really need to get your quoting right.
Please read http://www.netmeister.org/news/learn2quote.html
> --0016e649837c8d6440049306e906
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
And STOP posting HTML!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I used to think that the brain was the most wonderful organ in my
body. Then I realized who was telling me this." - Emo Phillips
^ permalink raw reply
* Re: [PATCH 1/9] MIPS: Decouple BMIPS CPU support from bcm47xx/bcm63xx SoC code
From: Ralf Baechle @ 2010-10-20 7:19 UTC (permalink / raw)
To: Kevin Cernekee; +Cc: ffainelli, mbizon, linux-mips, linux-kernel
In-Reply-To: <17ebecce124618ddf83ec6fe8e526f93@localhost>
Thanks, queued for 2.6.37.
Ralf
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 1/2] pci: Automatically patch PCI vendor id and device id in PCI ROM
From: Gerd Hoffmann @ 2010-10-20 7:19 UTC (permalink / raw)
To: Stefan Weil; +Cc: Michael S. Tsirkin, QEMU Developers, Markus Armbruster
In-Reply-To: <1287522501-8091-1-git-send-email-weil@mail.berlios.de>
Hi,
> The i825xx ethernet controller family is a typical example
> which is implemented in hw/eepro100.c. It uses at least
> 3 different device ids, so normally 3 boot roms would be needed.
Does this actually work now with the etherboot roms?
cheers,
Gerd
^ permalink raw reply
* [PATCH] sched_fair.c:find_busiest_group(), kernel 2.6.35.7
From: Andrew Dickinson @ 2010-10-20 7:20 UTC (permalink / raw)
To: linux-kernel
This is a patch to fix the corner case where we're crashing with
divide_error in find_busiest_group (see
https://bugzilla.kernel.org/show_bug.cgi?id=16991).
I don't fully understand what the case is that causes sds.total_pwr to
be zero in find_busiest_group, but this patch guards against the
divide-by-zero bug.
I also added safe-guarding around other routines in the scheduler code
where we're dividing by power; that's more of a just-in-case and I'm
definitely open for debate on that.
diff -ruwp a/kernel/sched_fair.c b/kernel/sched_fair.c
--- a/kernel/sched_fair.c 2010-10-19 23:47:51.000000000 -0700
+++ b/kernel/sched_fair.c 2010-10-20 00:08:17.000000000 -0700
@@ -1344,7 +1344,9 @@ find_idlest_group(struct sched_domain *s
}
/* Adjust by relative CPU power of the group */
- avg_load = (avg_load * SCHED_LOAD_SCALE) / group->cpu_power;
+ avg_load = (avg_load * SCHED_LOAD_SCALE);
+ if (group->cpu_power)
+ avg_load /= group->cpu_power;
if (local_group) {
this_load = avg_load;
@@ -2409,7 +2411,9 @@ static inline void update_sg_lb_stats(st
update_group_power(sd, this_cpu);
/* Adjust by relative CPU power of the group */
- sgs->avg_load = (sgs->group_load * SCHED_LOAD_SCALE) / group->cpu_power;
+ sgs->avg_load = (sgs->group_load * SCHED_LOAD_SCALE);
+ if (group->cpu_power)
+ sgs->avg_load /= group->cpu_power;
/*
* Consider the group unbalanced when the imbalance is larger
@@ -2692,7 +2696,7 @@ find_busiest_group(struct sched_domain *
if (!(*balance))
goto ret;
- if (!sds.busiest || sds.busiest_nr_running == 0)
+ if (!sds.busiest || sds.busiest_nr_running == 0 || sds.total_pwr == 0)
goto out_balanced;
if (sds.this_load >= sds.max_load)
@@ -2757,7 +2761,9 @@ find_busiest_queue(struct sched_group *g
* the load can be moved away from the cpu that is potentially
* running at a lower capacity.
*/
- wl = (wl * SCHED_LOAD_SCALE) / power;
+ wl = (wl * SCHED_LOAD_SCALE);
+ if (power)
+ wl /= power;
if (wl > max_load) {
max_load = wl;
^ permalink raw reply
* [U-Boot] [PATCH] Fix compile warning in uli526x driver
From: Kumar Gala @ 2010-10-20 7:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287557795-15496-1-git-send-email-galak@kernel.crashing.org>
On Oct 20, 2010, at 1:56 AM, Kumar Gala wrote:
> uli526x.c: In function 'uli526x_init_one':
> uli526x.c:314:2: warning: dereferencing type-punned pointer will break strict-aliasing rules
> uli526x.c:314:2: warning: dereferencing type-punned pointer will break strict-aliasing rules
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/net/uli526x.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
applied to 85xx
- k
^ permalink raw reply
* [U-Boot] [PATCH 05/17] ppc: Don't initialize write protected NOR flashes
From: Stefan Roese @ 2010-10-20 7:21 UTC (permalink / raw)
To: u-boot
In-Reply-To: <439257F7-1F67-4524-AFD2-6A5F582A1916@kernel.crashing.org>
On Wednesday 20 October 2010 08:46:03 Kumar Gala wrote:
> On Sep 29, 2010, at 2:05 PM, Peter Tyser wrote:
> > From: John Schmoller <jschmoller@xes-inc.com>
> >
> > If a NOR flash is write protected it can not be initialized/detected so
> > add the ability for boards to skip NOR initialization on bootup. A
> > board can skip NOR initialization by implementing the
> > board_flash_wp_on() function.
> >
> > Signed-off-by: John Schmoller <jschmoller@xes-inc.com>
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > CC: sr at denx.de
> > ---
> > arch/powerpc/lib/board.c | 16 +++++++++++++++-
> > 1 files changed, 15 insertions(+), 1 deletions(-)
>
> Needs a Wolfgang or Stefan ack.
Fine with me:
Acked-by: Stefan Roese <sr@denx.de>
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* Re: [PATCH v2 2/9] MIPS: Add BMIPS processor types to Kconfig
From: Ralf Baechle @ 2010-10-20 7:21 UTC (permalink / raw)
To: Kevin Cernekee; +Cc: ffainelli, linux-mips, linux-kernel
In-Reply-To: <584a8c475b66c7ccdd112fb6afda8491@localhost>
Thanks, queued for 2.6.37.
Ralf
^ permalink raw reply
* [U-Boot] ARM: Warning with current master
From: Matthias Weißer @ 2010-10-20 7:22 UTC (permalink / raw)
To: u-boot
Hi
after pulling the latest changes I get the following warning during
linking of arm boards (I tested jadecpu and tx25).
arm-unknown-eabi-ld: warning: creating a DT_TEXTREL in object.
Must have something to do with the latest ELF based relocation changes
but I am not an expert in these tool chain related issues to dig a bit
deeper into this issue.
I didn't test if the image runs on the target.
gcc version is 4.3.4
Matthias
^ permalink raw reply
* Re: [PATCH 3/9] MIPS: Add BMIPS CP0 register definitions
From: Ralf Baechle @ 2010-10-20 7:23 UTC (permalink / raw)
To: Kevin Cernekee; +Cc: linux-mips, linux-kernel
In-Reply-To: <c6dd81d43765a1646f0d0d607df3bd20@localhost>
Thanks, queued for 2.6.37.
Ralf
^ permalink raw reply
* [U-Boot] [PATCH] FAT: buffer overflow with FAT12/16
From: Mikhail Zolotaryov @ 2010-10-20 7:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1287557505-3955-1-git-send-email-sbabic@denx.de>
Stefano,
you're right, sorry for that. Isn't it better to define LINEAR_PREFETCH_SIZE as
2 (blocks) and change get_vfatname() to something like that in such case:
__u8 *buflimit = cluster + ((curclust == 0) ?
LINEAR_PREFETCH_SIZE :
mydata->clust_size
) * SECTOR_SIZE;
Regards,
Mikhail
On 20.10.10 09:51, Stefano Babic wrote:
> Last commit 3831530dcb7b71329c272ccd6181f8038b6a6dd0a was intended
> "explicitly specify FAT12/16 root directory parsing buffer size, instead
> of relying on cluster size". Howver, the underlying function requires
> the size of the buffer in blocks, not in bytes, and instead of passing
> a double sector size a request for 1024 blocks is sent. This generates
> a buffer overflow with overwriting of other structure (in the case seen,
> USB structures were overwritten).
>
> Signed-off-by: Stefano Babic <sbabic@denx.de>
> CC: Mikhail Zolotaryov <lebon@lebon.org.ua>
>
> ---
> fs/fat/fat.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 744e961..a75e4f2 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -858,7 +858,7 @@ do_fat_read (const char *filename, void *buffer, unsigned long maxsize,
> if (disk_read(cursect,
> (mydata->fatsize == 32) ?
> (mydata->clust_size) :
> - LINEAR_PREFETCH_SIZE,
> + LINEAR_PREFETCH_SIZE / SECTOR_SIZE,
> do_fat_read_block) < 0) {
> debug("Error: reading rootdir block\n");
> return -1;
^ permalink raw reply
* Re: Call for help for demo UPNP media renderer
From: Xu, Dongxiao @ 2010-10-20 7:23 UTC (permalink / raw)
To: Joshua Lock; +Cc: yocto@yoctoproject.org
In-Reply-To: <1287559110.2268.1.camel@scimitar>
Joshua Lock wrote:
> On Wed, 2010-10-20 at 14:07 +0800, Xu, Dongxiao wrote:
>> Hi Josh,
>>
>> Today I took a glance at the rygel crash issue in poky. Though I
>> didn't get the root cause, I found when configure Tracker plugin into
>> rygel, the segmentation fault will happen. Since we have already
>> configured the media-export plugin, and tracker plugin plays the same
>> role, I think we can simply disable tracker plugin (by configure time
>> or change by rygel-preferences) for demo usage.
>
> Yes, I thought I mentioned disabling the tracker plugin in an earlier
> mail? I'll prepare a patch to the recipe to disable that so we don't
> have to remember to do that by hand.
Ah, oops. I didn't read your previous mail carefully...
But luckily it didn't cost too much time. :-)
Thanks,
Dongxiao
>
> Cheers,
> Joshua
>
>>
>> Thanks,
>> Dongxiao
>>
>> Xu, Dongxiao wrote:
>>> I just built out the poky-image-rygel image with your meta-demo
>>> layer, and run
>>>
>>> rygel --gst-debug-level=5
>>>
>>> I still saw it "segmentation fault" in the last...
>>>
>>> I am looking into it.
>>>
>>> Thanks,
>>> Dongxiao
>>>
>>> Xu, Dongxiao wrote:
>>>> Zanussi, Tom wrote:
>>>>> On Tue, 2010-10-19 at 17:40 -0700, Xu, Dongxiao wrote:
>>>>>> Joshua Lock wrote:
>>>>>>> On Wed, 2010-10-20 at 01:04 +0100, Joshua Lock wrote:
>>>>>>>> On Tue, 2010-10-19 at 14:31 -0700, Saul Wold wrote:
>>>>>>>>>
>>>>>>>>> Dongxiao,
>>>>>>>>>
>>>>>>>>> Can you take a look at this since you have worked with the
>>>>>>>>> gstreamer?
>>>>>>>>
>>>>>>>> I did a sloppy job pushing my changes when leaving the office
>>>>>>>> but think I have replicated most/all of the in the josh/demo
>>>>>>>> branch.
>>>>>>>>
>>>>>>>> I also took a look through the rygel code to see what gstreamer
>>>>>>>> elements are explicitly being used, I've created a list and
>>>>>>>> tried to ensure as many as possible of them are in the
>>>>>>>> IMAGE_INSTALL list for poky-image-rygel, adding them to the
>>>>>>>> RDEPENDS for rygel doesn't appear to have included them in the
>>>>>>>> image I just created...
>>>>>>>>
>>>>>>>> Full list of names of pipeline elements I found in the rygel
>>>>>>>> code follows:
>>>>>>>>
>>>>>>>> decodebin2, videorate, videoscale, ffmpegcolorspace,
>>>>>>>> ffenc_wmv1, twolame, lame, mp3parse, ffenc_wmav2,
>>>>>>>> convert-sink-pad, ffenc_mpeg2video, audio-src-pad,
>>>>>>>> audio-sink-pad, audio-enc-sink-pad, sink, mpegtsmux,
>>>>>>>> audioconvert, audioresample, audiorate, capsfilter,
>>>>>>>> audiotestsrc, videotestsrc, ffmux_asf
>>>>>>>>
>>>>>>>
>>>>>>> The image I just built with my latest changes in josh/demo
>>>>>>> worked!?! Rygel did not segfault :-)
>>>>>>>
>>>>>>> If you have time Dongxiao (or anyone else) I'd appreciate if you
>>>>>>> could double-check my changes (my install_append in rygel to
>>>>>>> create a .config isn't working, so you'll need to do that
>>>>>>> manually and run rygel-preferences to disable the tracker
>>>>>>> plugin). If you could test using Rygel as a renderer for some
>>>>>>> content served by the mediatomb image, that would be much
>>>>>>> appreciated. You'll want gupnp-av-cp as provided by gupnp-tools
>>>>>>> to control the renderer and content server.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joshua
>>>>>>
>>>>>> I will try your branch, however I didn't find josh/demo in
>>>>>> poky-contrib. Is it reside in other place?
>>>>>>
>>>>>
>>>>> It should be here:
>>>>>
>>>>> ssh://git@git.pokylinux.org/meta-demo.git
>>>>>
>>>>> Tom
>>>>
>>>> Got it, thanks!
>>>>
>>>> Dongxiao
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@yoctoproject.org
>>>> https://lists.pokylinux.org/listinfo/yocto
^ permalink raw reply
* Re: Deadlock possibly caused by too_many_isolated.
From: Torsten Kaiser @ 2010-10-20 7:25 UTC (permalink / raw)
To: Wu Fengguang
Cc: Neil Brown, Rik van Riel, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Li, Shaohua
In-Reply-To: <20101020055717.GA12752@localhost>
On Wed, Oct 20, 2010 at 7:57 AM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> On Tue, Oct 19, 2010 at 06:06:21PM +0800, Torsten Kaiser wrote:
>> swap_writepage() uses get_swap_bio() which uses bio_alloc() to get one
>> bio. That bio is the submitted, but the submit path seems to get into
>> make_request from raid1.c and that allocates a second bio from
>> bio_alloc() via bio_clone().
>>
>> I am seeing this pattern (swap_writepage calling
>> md_make_request/make_request and then getting stuck in mempool_alloc)
>> more than 5 times in the SysRq+T output...
>
> I bet the root cause is the failure of pool->alloc(__GFP_NORETRY)
> inside mempool_alloc(), which can be fixed by this patch.
No. I tested the patch (ontop of Neils fix and your patch regarding
too_many_isolated()), but the system got stuck the same way on the
first try to fill the tmpfs.
I think the basic problem is, that the mempool that should guarantee
progress is exhausted because the raid1 device is stacked between the
pageout code and the disks and so the "use only 1 bio"-rule gets
violated.
> Thanks,
> Fengguang
> ---
>
> concurrent direct page reclaim problem
>
> __GFP_NORETRY page allocations may fail when there are many concurrent page
> allocating tasks, but not necessary in real short of memory. The root cause
> is, tasks will first run direct page reclaim to free some pages from the LRU
> lists and put them to the per-cpu page lists and the buddy system, and then
> try to get a free page from there. However the free pages reclaimed by this
> task may be consumed by other tasks when the direct reclaim task is able to
> get the free page for itself.
I believe the facts disagree with that assumtion. My bad for not
posting this before, but I also used SysRq+M to see whats going on,
but each time there still was some free memory.
Here is the SysRq+M output from the run with only Neils patch applied,
but on each other run the same ~14Mb stayed free
[ 437.481365] SysRq : Show Memory
[ 437.490003] Mem-Info:
[ 437.491357] Node 0 DMA per-cpu:
[ 437.500032] CPU 0: hi: 0, btch: 1 usd: 0
[ 437.500032] CPU 1: hi: 0, btch: 1 usd: 0
[ 437.500032] CPU 2: hi: 0, btch: 1 usd: 0
[ 437.500032] CPU 3: hi: 0, btch: 1 usd: 0
[ 437.500032] Node 0 DMA32 per-cpu:
[ 437.500032] CPU 0: hi: 186, btch: 31 usd: 138
[ 437.500032] CPU 1: hi: 186, btch: 31 usd: 30
[ 437.500032] CPU 2: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 3: hi: 186, btch: 31 usd: 0
[ 437.500032] Node 1 DMA32 per-cpu:
[ 437.500032] CPU 0: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 1: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 2: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 3: hi: 186, btch: 31 usd: 0
[ 437.500032] Node 1 Normal per-cpu:
[ 437.500032] CPU 0: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 1: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 2: hi: 186, btch: 31 usd: 25
[ 437.500032] CPU 3: hi: 186, btch: 31 usd: 30
[ 437.500032] active_anon:2039 inactive_anon:985233 isolated_anon:682
[ 437.500032] active_file:1667 inactive_file:1723 isolated_file:0
[ 437.500032] unevictable:0 dirty:0 writeback:25387 unstable:0
[ 437.500032] free:3471 slab_reclaimable:2840 slab_unreclaimable:6337
[ 437.500032] mapped:1284 shmem:960501 pagetables:523 bounce:0
[ 437.500032] Node 0 DMA free:8008kB min:28kB low:32kB high:40kB
active_anon:0kB inact
ive_anon:7596kB active_file:12kB inactive_file:0kB unevictable:0kB
isolated(anon):0kB i
solated(file):0kB present:15768kB mlocked:0kB dirty:0kB
writeback:404kB mapped:0kB shme
m:7192kB slab_reclaimable:32kB slab_unreclaimable:304kB
kernel_stack:0kB pagetables:0kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:118
all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 2004 2004 2004
[ 437.500032] Node 0 DMA32 free:2980kB min:4036kB low:5044kB
high:6052kB active_anon:2
844kB inactive_anon:1918424kB active_file:3428kB inactive_file:3780kB
unevictable:0kB isolated(anon):1232kB isolated(file):0kB
present:2052320kB mlocked:0kB dirty:0kB writeback:72016kB
mapped:2232kB shmem:1847640kB slab_reclaimable:5444kB
slab_unreclaimable:13508kB kernel_stack:744kB pagetables:864kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 0 0 0
[ 437.500032] Node 1 DMA32 free:2188kB min:3036kB low:3792kB
high:4552kB active_anon:0kB inactive_anon:1555368kB active_file:0kB
inactive_file:28kB unevictable:0kB isolated(anon):768kB
isolated(file):0kB present:1544000kB mlocked:0kB dirty:0kB
writeback:21160kB mapped:0kB shmem:1534960kB slab_reclaimable:3728kB
slab_unreclaimable:7076kB kernel_stack:8kB pagetables:0kB unstable:0kB
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 0 505 505
[ 437.500032] Node 1 Normal free:708kB min:1016kB low:1268kB
high:1524kB active_anon:5312kB inactive_anon:459544kB
active_file:3228kB inactive_file:3084kB unevictable:0kB
isolated(anon):728kB isolated(file):0kB present:517120kB mlocked:0kB
dirty:0kB writeback:7968kB mapped:2904kB shmem:452212kB
slab_reclaimable:2156kB slab_unreclaimable:4460kB kernel_stack:200kB
pagetables:1228kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:9678 all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 0 0 0
[ 437.500032] Node 0 DMA: 2*4kB 2*8kB 1*16kB 3*32kB 3*64kB 4*128kB
4*256kB 2*512kB 1*1024kB 2*2048kB 0*4096kB = 8008kB
[ 437.500032] Node 0 DMA32: 27*4kB 15*8kB 8*16kB 8*32kB 7*64kB
1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2980kB
[ 437.500032] Node 1 DMA32: 1*4kB 6*8kB 3*16kB 1*32kB 0*64kB 1*128kB
0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2308kB
[ 437.500032] Node 1 Normal: 39*4kB 13*8kB 10*16kB 3*32kB 1*64kB
1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 708kB
[ 437.500032] 989289 total pagecache pages
[ 437.500032] 25398 pages in swap cache
[ 437.500032] Swap cache stats: add 859204, delete 833806, find 28/39
[ 437.500032] Free swap = 9865628kB
[ 437.500032] Total swap = 10000316kB
[ 437.500032] 1048575 pages RAM
[ 437.500032] 33809 pages reserved
[ 437.500032] 7996 pages shared
[ 437.500032] 1008521 pages non-shared
> Let's retry it a bit harder.
>
> --- linux-next.orig/mm/page_alloc.c 2010-10-20 13:44:50.000000000 +0800
> +++ linux-next/mm/page_alloc.c 2010-10-20 13:50:54.000000000 +0800
> @@ -1700,7 +1700,7 @@ should_alloc_retry(gfp_t gfp_mask, unsig
> unsigned long pages_reclaimed)
> {
> /* Do not loop if specifically requested */
> - if (gfp_mask & __GFP_NORETRY)
> + if (gfp_mask & __GFP_NORETRY && pages_reclaimed > (1 << (order + 12)))
> return 0;
>
> /*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: Deadlock possibly caused by too_many_isolated.
From: Torsten Kaiser @ 2010-10-20 7:25 UTC (permalink / raw)
To: Wu Fengguang
Cc: Neil Brown, Rik van Riel, Andrew Morton, KOSAKI Motohiro,
KAMEZAWA Hiroyuki, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Li, Shaohua
In-Reply-To: <20101020055717.GA12752@localhost>
On Wed, Oct 20, 2010 at 7:57 AM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> On Tue, Oct 19, 2010 at 06:06:21PM +0800, Torsten Kaiser wrote:
>> swap_writepage() uses get_swap_bio() which uses bio_alloc() to get one
>> bio. That bio is the submitted, but the submit path seems to get into
>> make_request from raid1.c and that allocates a second bio from
>> bio_alloc() via bio_clone().
>>
>> I am seeing this pattern (swap_writepage calling
>> md_make_request/make_request and then getting stuck in mempool_alloc)
>> more than 5 times in the SysRq+T output...
>
> I bet the root cause is the failure of pool->alloc(__GFP_NORETRY)
> inside mempool_alloc(), which can be fixed by this patch.
No. I tested the patch (ontop of Neils fix and your patch regarding
too_many_isolated()), but the system got stuck the same way on the
first try to fill the tmpfs.
I think the basic problem is, that the mempool that should guarantee
progress is exhausted because the raid1 device is stacked between the
pageout code and the disks and so the "use only 1 bio"-rule gets
violated.
> Thanks,
> Fengguang
> ---
>
> concurrent direct page reclaim problem
>
> __GFP_NORETRY page allocations may fail when there are many concurrent page
> allocating tasks, but not necessary in real short of memory. The root cause
> is, tasks will first run direct page reclaim to free some pages from the LRU
> lists and put them to the per-cpu page lists and the buddy system, and then
> try to get a free page from there. However the free pages reclaimed by this
> task may be consumed by other tasks when the direct reclaim task is able to
> get the free page for itself.
I believe the facts disagree with that assumtion. My bad for not
posting this before, but I also used SysRq+M to see whats going on,
but each time there still was some free memory.
Here is the SysRq+M output from the run with only Neils patch applied,
but on each other run the same ~14Mb stayed free
[ 437.481365] SysRq : Show Memory
[ 437.490003] Mem-Info:
[ 437.491357] Node 0 DMA per-cpu:
[ 437.500032] CPU 0: hi: 0, btch: 1 usd: 0
[ 437.500032] CPU 1: hi: 0, btch: 1 usd: 0
[ 437.500032] CPU 2: hi: 0, btch: 1 usd: 0
[ 437.500032] CPU 3: hi: 0, btch: 1 usd: 0
[ 437.500032] Node 0 DMA32 per-cpu:
[ 437.500032] CPU 0: hi: 186, btch: 31 usd: 138
[ 437.500032] CPU 1: hi: 186, btch: 31 usd: 30
[ 437.500032] CPU 2: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 3: hi: 186, btch: 31 usd: 0
[ 437.500032] Node 1 DMA32 per-cpu:
[ 437.500032] CPU 0: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 1: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 2: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 3: hi: 186, btch: 31 usd: 0
[ 437.500032] Node 1 Normal per-cpu:
[ 437.500032] CPU 0: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 1: hi: 186, btch: 31 usd: 0
[ 437.500032] CPU 2: hi: 186, btch: 31 usd: 25
[ 437.500032] CPU 3: hi: 186, btch: 31 usd: 30
[ 437.500032] active_anon:2039 inactive_anon:985233 isolated_anon:682
[ 437.500032] active_file:1667 inactive_file:1723 isolated_file:0
[ 437.500032] unevictable:0 dirty:0 writeback:25387 unstable:0
[ 437.500032] free:3471 slab_reclaimable:2840 slab_unreclaimable:6337
[ 437.500032] mapped:1284 shmem:960501 pagetables:523 bounce:0
[ 437.500032] Node 0 DMA free:8008kB min:28kB low:32kB high:40kB
active_anon:0kB inact
ive_anon:7596kB active_file:12kB inactive_file:0kB unevictable:0kB
isolated(anon):0kB i
solated(file):0kB present:15768kB mlocked:0kB dirty:0kB
writeback:404kB mapped:0kB shme
m:7192kB slab_reclaimable:32kB slab_unreclaimable:304kB
kernel_stack:0kB pagetables:0kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:118
all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 2004 2004 2004
[ 437.500032] Node 0 DMA32 free:2980kB min:4036kB low:5044kB
high:6052kB active_anon:2
844kB inactive_anon:1918424kB active_file:3428kB inactive_file:3780kB
unevictable:0kB isolated(anon):1232kB isolated(file):0kB
present:2052320kB mlocked:0kB dirty:0kB writeback:72016kB
mapped:2232kB shmem:1847640kB slab_reclaimable:5444kB
slab_unreclaimable:13508kB kernel_stack:744kB pagetables:864kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 0 0 0
[ 437.500032] Node 1 DMA32 free:2188kB min:3036kB low:3792kB
high:4552kB active_anon:0kB inactive_anon:1555368kB active_file:0kB
inactive_file:28kB unevictable:0kB isolated(anon):768kB
isolated(file):0kB present:1544000kB mlocked:0kB dirty:0kB
writeback:21160kB mapped:0kB shmem:1534960kB slab_reclaimable:3728kB
slab_unreclaimable:7076kB kernel_stack:8kB pagetables:0kB unstable:0kB
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 0 505 505
[ 437.500032] Node 1 Normal free:708kB min:1016kB low:1268kB
high:1524kB active_anon:5312kB inactive_anon:459544kB
active_file:3228kB inactive_file:3084kB unevictable:0kB
isolated(anon):728kB isolated(file):0kB present:517120kB mlocked:0kB
dirty:0kB writeback:7968kB mapped:2904kB shmem:452212kB
slab_reclaimable:2156kB slab_unreclaimable:4460kB kernel_stack:200kB
pagetables:1228kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:9678 all_unreclaimable? no
[ 437.500032] lowmem_reserve[]: 0 0 0 0
[ 437.500032] Node 0 DMA: 2*4kB 2*8kB 1*16kB 3*32kB 3*64kB 4*128kB
4*256kB 2*512kB 1*1024kB 2*2048kB 0*4096kB = 8008kB
[ 437.500032] Node 0 DMA32: 27*4kB 15*8kB 8*16kB 8*32kB 7*64kB
1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2980kB
[ 437.500032] Node 1 DMA32: 1*4kB 6*8kB 3*16kB 1*32kB 0*64kB 1*128kB
0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2308kB
[ 437.500032] Node 1 Normal: 39*4kB 13*8kB 10*16kB 3*32kB 1*64kB
1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 708kB
[ 437.500032] 989289 total pagecache pages
[ 437.500032] 25398 pages in swap cache
[ 437.500032] Swap cache stats: add 859204, delete 833806, find 28/39
[ 437.500032] Free swap = 9865628kB
[ 437.500032] Total swap = 10000316kB
[ 437.500032] 1048575 pages RAM
[ 437.500032] 33809 pages reserved
[ 437.500032] 7996 pages shared
[ 437.500032] 1008521 pages non-shared
> Let's retry it a bit harder.
>
> --- linux-next.orig/mm/page_alloc.c 2010-10-20 13:44:50.000000000 +0800
> +++ linux-next/mm/page_alloc.c 2010-10-20 13:50:54.000000000 +0800
> @@ -1700,7 +1700,7 @@ should_alloc_retry(gfp_t gfp_mask, unsig
> unsigned long pages_reclaimed)
> {
> /* Do not loop if specifically requested */
> - if (gfp_mask & __GFP_NORETRY)
> + if (gfp_mask & __GFP_NORETRY && pages_reclaimed > (1 << (order + 12)))
> return 0;
>
> /*
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: including sparse headers in C++ code
From: Al Viro @ 2010-10-20 7:29 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Christopher Li, Kamil Dudka, Tomas Klacko, linux-sparse,
Josh Triplett
In-Reply-To: <1286981110.14103.86.camel@thorin>
On Wed, Oct 13, 2010 at 04:45:10PM +0200, Bernd Petrovitsch wrote:
> rename the local variables "true" and "false" to "if_true" and "if_false",
> respectively to not clash with the well-known "keywords" defined by C99.
> This is similar to commit 0be55c9.
These are not keywords... Said that, things like
if (!cond->value)
true = false;
if (!true)
true = cond;
certainly reek of IOCCC. I'd rather avoid "if_true" as replacement, though.
If anything, true_expr and false_expr would make more sense.
^ permalink raw reply
* [U-Boot] Observation: rebasing against current master increases code size by 1.8k
From: Reinhard Meyer @ 2010-10-20 7:30 UTC (permalink / raw)
To: u-boot
Just an observation on my AT91SAM9XE based board:
based on yesterday's master + arm elf relocations +
my (then not mainstreamed) patches: 256288 bytes
based on current master: 258020 bytes
Otherwise it compiles without warnings and runs fine.
Just some non-reloc-related patches have increased
code size by that amount - finding out which are to
"blame" is probably not worth the effort.
Best Regards,
Reinhard
^ permalink raw reply
* Re: [PATCH 2/2]x86: spread tlb flush vector between nodes
From: Andi Kleen @ 2010-10-20 7:30 UTC (permalink / raw)
To: Shaohua Li; +Cc: lkml, Ingo Molnar, hpa@zytor.com, Andi Kleen, Chen, Tim C
In-Reply-To: <1287544023.4571.8.camel@sli10-conroe.sh.intel.com>
Hi Shaohua,
> + if (nr_online_nodes > NUM_INVALIDATE_TLB_VECTORS)
> + nr_node_vecs = 1;
> + else
> + nr_node_vecs = NUM_INVALIDATE_TLB_VECTORS/nr_online_nodes;
Does this build without CONFIG_NUMA? AFAIK nr_online_nodes is only
defined for a numa kernel.
> +
> +static int tlb_cpuhp_notify(struct notifier_block *n,
> + unsigned long action, void *hcpu)
> +{
> + switch (action & 0xf) {
> + case CPU_ONLINE:
> + case CPU_DEAD:
> + calculate_tlb_offset();
I still think the notifier is overkill and a static mapping at boot time
would be fine.
The rest looks ok to me.
-andi
^ permalink raw reply
* [Qemu-devel] [Bug 663713] [NEW] Mouse frozen under an emulated ubuntu
From: FredBezies @ 2010-10-20 7:24 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20101020072423.24878.5349.malonedeb@wampee.canonical.com>
Public bug reported:
Qemu 0.13.0
Command line used :
qemu-system-x86_64 --enable-kvm -localtime -soundhw all -k fr -m 1500
-net user -net nic,model=rtl8139 -hda disk.img -cdrom ubuntu-10.10
-desktop-amd64.iso -boot d
When I try to move mouse cursor in qemu, pointer is frozen. Nothing is
moving. Was working perfectly with Qemu 0.12.5.
** Affects: qemu
Importance: Undecided
Status: New
--
Mouse frozen under an emulated ubuntu
https://bugs.launchpad.net/bugs/663713
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
Qemu 0.13.0
Command line used :
qemu-system-x86_64 --enable-kvm -localtime -soundhw all -k fr -m 1500 -net user -net nic,model=rtl8139 -hda disk.img -cdrom ubuntu-10.10-desktop-amd64.iso -boot d
When I try to move mouse cursor in qemu, pointer is frozen. Nothing is moving. Was working perfectly with Qemu 0.12.5.
^ permalink raw reply
* Re: [PATCH 2/2]x86: spread tlb flush vector between nodes
From: Andi Kleen @ 2010-10-20 7:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Shaohua Li, lkml, Ingo Molnar, hpa@zytor.com, Andi Kleen,
Chen, Tim C
In-Reply-To: <1287551797.2700.76.camel@edumazet-laptop>
> Maybe we should have a per_node memory infrastructure, so that we can
> lower memory needs of currently per_cpu objects.
I have been looking at that :- for a lot of things per core
data makes sense too.
Really a lot of the per CPU scaling we have today should be per core
or per node to avoid explosion.
But for this particular case it doesn't help because you still
need a mapping for each CPU.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [U-Boot] [PATCH] sparc: add asm/unaligned.h
From: Mike Frysinger @ 2010-10-20 7:32 UTC (permalink / raw)
To: u-boot
It isn't possible to build any sparc boards without this ...
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
arch/sparc/include/asm/unaligned.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 arch/sparc/include/asm/unaligned.h
diff --git a/arch/sparc/include/asm/unaligned.h b/arch/sparc/include/asm/unaligned.h
new file mode 100644
index 0000000..6cecbbb
--- /dev/null
+++ b/arch/sparc/include/asm/unaligned.h
@@ -0,0 +1 @@
+#include <asm-generic/unaligned.h>
--
1.7.3.1
^ permalink raw reply related
* A music recommendation from Mike Jones and eil.com
From: Sales @ 2010-10-20 7:34 UTC (permalink / raw)
To: xfs
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]
Hi Friend,
Chances are you will never find something this rare and incredible again.
==> http://shrunk.net/4d27aea7
This is a chance to copy exactly what a 25 year old unemployed "dude" did
to make $27,408 in under 30 days... but only for a limited time.
The information revealed is downright alarming.
Here it is:
http://shrunk.net/4d27aea7
Thanks,
Mike Jones
P.S. There actually very few spots left... he is pulling the site down
once they are filled!
http://shrunk.net/4d27aea7
Discover 6 decades of music history at eil.com the world's premier on-line
store for new, rare and collectable vinyl, compact discs and music
memorabilia.
This message was sent to you on behalf of Mike Jones using the 'tell a
friend' service at http://eil.com
____________ discover more @ eil.com ____________
all the latest arrivals - http://eil.com/click_here_4/shopping
£9.99 album chart - http://eil.com/click_here_4/album_chart
future releases - http://eil.com/click_here_4/future_releases
latest music news - http://eil.com/click_here_4/music_news
exclusive games - http://eil.com/click_here_4/games_zone
music discussion board - http://eil.com/click_here_4/chat
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [U-Boot] [PATCH] cmd_net: drop spurious comma in U_BOOT_CMD
From: Mike Frysinger @ 2010-10-20 7:33 UTC (permalink / raw)
To: u-boot
Building for boards that have CONFIG_CMD_CDP enabled fail with:
cmd_net.c:301: error: expected expression before ',' token
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
common/cmd_net.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_net.c b/common/cmd_net.c
index 44d17db..b131006 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -297,7 +297,7 @@ int do_cdp (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
U_BOOT_CMD(
cdp, 1, 1, do_cdp,
- "Perform CDP network configuration",
+ "Perform CDP network configuration"
);
#endif
--
1.7.3.1
^ permalink raw reply related
* [U-Boot] [PATCH] MAKEALL: drop non-existent i386 config
From: Mike Frysinger @ 2010-10-20 7:34 UTC (permalink / raw)
To: u-boot
---
MAKEALL | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/MAKEALL b/MAKEALL
index c1f3842..febf89c 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -559,9 +559,7 @@ LIST_mips_el=" \
## i386 Systems
#########################################################################
-LIST_x86="$(boards_by_arch i386)
- sc520_eNET \
-"
+LIST_x86="$(boards_by_arch i386)"
#########################################################################
## Nios-II Systems
--
1.7.3.1
^ permalink raw reply related
* Re: [lm-sensors] [PATCH] drivers/hwmon: Use pr_fmt and pr_<level>
From: Jean Delvare @ 2010-10-20 7:34 UTC (permalink / raw)
To: Joe Perches
Cc: Guenter Roeck, Hans de Goede, Alistair John Strachan,
Henrik Rydberg, Mark M. Hoffman, Luca Tettamanti, Fenghua Yu,
Juerg Haefliger, Eric Piel, Jim Cromie, Roger Lucas,
lm-sensors@lm-sensors.org, LKML
In-Reply-To: <1287547662.10409.618.camel@Joe-Laptop>
On Tue, 19 Oct 2010 21:07:42 -0700, Joe Perches wrote:
> On Tue, 2010-10-19 at 20:53 -0700, Guenter Roeck wrote:
> > On Tue, Oct 19, 2010 at 11:34:18PM -0400, Joe Perches wrote:
> > > On Tue, 2010-10-19 at 20:29 -0700, Guenter Roeck wrote:
> > > > There are several lines longer than 80 characters.
> > > > Does this rule no longer apply ?
> > > 80 columns isn't checked for printk format strings.
> > Interesting.
> > > A kernel general preference may be to keep formats as
> > > a single string without line breaks so that grep works
> > > better.
> > > > Oddly enough, there are only four checkpatch warnings about long lines,
> > > > even though there are many more.
> > > The version I use doesn't show any warnings.
> > checkpatch.pl from both v2.6.36-rc7 and v2.6.36-rc6 do report warnings.
> > Looks like those versions flag long lines for pr_warn. Is your version
> > older or newer ?
>
> Newer. It adds pr_warn to the exempted list, not just pr_warning.
I hope there's a plan to get rid of one of these? Having two macros
doing exactly the same thing will confuse everybody.
> > Anyway, would it be possible to split the patch into one patch per file ?
>
> Oh sure. It's trivial to do that.
>
> > I don't know how Jean thinks about it, but in my opinion it would be cleaner,
> > permit revert on a single patch/file instead of having to revert the entire series,
> > it would simplify review, and it would make it much easier to cherry-pick
> > pieces into other releases if needed.
>
> Jean, do you have a preference?
> I'll resubmit if you want it separated.
Jean has no preference when sleeping.
Now Jean is awake and can express himself on the matter:
* This isn't the kind of fixes we want to cherry-pick from. We're not
fixing any bug here, are we? I certainly hope that a real bug fix
wouldn't be hidden within a larger patch, but would have the separate
patch it deserves. At which point we no longer care if the rest is
one large patch or one patch per driver.
* I don't see us reverting that kind of patch either. If we don't like
the changes for whatever reason, we don't take them in the first
place. Once in, we're not going to change our minds.
* 32 patches for a simple cleanup is actually a lot more work for me
than a single large patch. It's cheaper for me to do minor
adjustments to a large patch than to apply 32 patches individually.
* That being said, now that the hwmon subsystem maintainer is a shared
duty between Guenter and myself, there's no single place where we can
keep a patch touching many drivers and ensure it doesn't conflict
with the changes in the other tree. But I would think this is
something for Gunter and myself to sort out, not patch contributors.
I currently have pending patches to the following hwmon drivers in my
tree: adt7475, ams, asc7621, hdaps, it87, k8temp, lm75, lm85, lm90,
pcf8591, s3c-hwmon, w83795. Two of these are affected by Joe's
patch(es). Guenter, what about you?
Joe, would you mind providing a similar patch for the driver at:
http://khali.linux-fr.org/devel/misc/w83795/w83795.c
This driver will be added to kernel 2.6.37.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.