Hi all,
I got a weird page fault oops on vmalloc'ed area. Digging into the powerpc
do_page_fault(), I found there is no handling of address in kernel space unlike
the x86 counter part. Does any one know how we deal with the vmalloc'ed area
on powerpc? Thanks a lot.
- Leo
___
On Wed, May 05, 2010 at 01:35:21PM +1000, Michael Neuling wrote:
>
>
> In message <20100505023316.gf13...@verge.net.au> you wrote:
> > On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote:
> > > 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 "some kexec MIPS
> > > improvements" broke pp64 as
In message <20100505023316.gf13...@verge.net.au> you wrote:
> On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote:
> > 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 "some kexec MIPS
> > improvements" broke pp64 as it turned on -Werror for all archs.
> >
> > This fixes the warning and henc
On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote:
> 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 "some kexec MIPS
> improvements" broke pp64 as it turned on -Werror for all archs.
>
> This fixes the warning and hence ppc64 building.
Thanks.
While I'm very much in favour of using -Werr
On Tue, 04 May 2010 19:08:23 +0300
Avi Kivity wrote:
> On 05/04/2010 06:03 PM, Arnd Bergmann wrote:
> > On Tuesday 04 May 2010, Takuya Yoshikawa wrote:
...
> >> So let us use the le bit offset calculation part by defining it as a new
> >> macro: generic_le_bit_offset() .
> >>
> > Does this
In article <15110.1273024...@neuling.org> Michael Neuling wrote:
> 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 "some kexec MIPS
> improvements" broke pp64 as it turned on -Werror for all archs.
>
> This fixes the warning and hence ppc64 building.
>
> Signed-off-by: Michael Neuling
> ---
> I've post
6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 "some kexec MIPS
improvements" broke pp64 as it turned on -Werror for all archs.
This fixes the warning and hence ppc64 building.
Signed-off-by: Michael Neuling
---
I've posted a second patch to fix the issue of changing one archs
Makefile, effecting all
Commit 6acc6833510db8f72b5ef343296d97480555fda9
introduced NULL pointer dereference and kernel crash
on ppc32 machines while booting. Fix this bug now.
Reported-by: Leonardo Chiquitto
Signed-off-by: Anatolij Gustschin
---
drivers/serial/mpc52xx_uart.c |2 +-
1 files changed, 1 insertions(+)
On Tue, 4 May 2010 17:39:25 -0300
Leonardo Chiquitto wrote:
> Kernel 2.6.34-rc5 crashes on boot in a ppc32 machine (Mac Mini G4).
>
> Reverting the following commit makes the kernel boot normally again:
>
> commit 6acc6833510db8f72b5ef343296d97480555fda9
> Author: Anatolij Gustschin
> Date:
On Mon, May 03, 2010 at 04:23:30PM +1000, Paul Mackerras wrote:
> On Wed, Apr 14, 2010 at 09:18:27AM +0530, K.Prasad wrote:
>
> > Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
> > These interfaces help arbitrate requests from various users and schedules
> > them as app
On Tue, May 04, 2010 at 10:11:34AM -0500, Timur Tabi wrote:
> Also remove the "gianfar" compatible from mpc8610_ids[], since there is no
> gianfar (or any other networking device) on the 8610.
Meh, sorry. Though this is a very good example of why you shouldn't
randomly mix unrelated changes into
On Sun, May 02, 2010 at 09:30:25PM +0400, Anton Vorontsov wrote:
> Since commit 7acd72eb85f1c7a15e8b5eb554994949241737f1 ("kfifo: rename
> kfifo_put... into kfifo_in... and kfifo_get... into kfifo_out..."),
> kfifo_out() is marked __must_check, and that causes gcc to produce
> lots of warnings like
On May 3, 2010, at 4:54 PM, Timur Tabi wrote:
> A future version of the MPC8610 HPCD's ASoC DMA driver will probe on
> individual
> DMA channel nodes, so the DMA controller nodes' compatible string must be
> listed
> in mpc8610_ids[] for the probe to work.
>
> Also remove the "gianfar" compati
Short version:
Can anyone confirm 10Mb Ethernet works with fs_enet/mac-fcc? with
RMII? with a KS8721 PHY?
Long version:
I have an MPC8247 connected via an externally clocked RMII to a Micrel
KS8721 PHY using the Generic PHY driver, running either MontaVista
2.6.18+ or mainline 2.6.30 (I don't se
On 05/04/2010 06:03 PM, Arnd Bergmann wrote:
On Tuesday 04 May 2010, Takuya Yoshikawa wrote:
Although we can use *_le_bit() helpers to treat bitmaps le arranged,
having le bit offset calculation as a seperate macro gives us more freedom.
For example, KVM has le arranged dirty bitmaps for VG
We use new API for light dirty log access if KVM supports it.
This conflicts with Marcelo's patches. So please take this as a sample patch.
Signed-off-by: Takuya Yoshikawa
---
kvm/include/linux/kvm.h | 11 ++
qemu-kvm.c | 81 ++-
Now that dirty bitmaps are accessible from user space, we export the
addresses of these to achieve zero-copy dirty log check:
KVM_GET_USER_DIRTY_LOG_ADDR
We also need an API for triggering dirty bitmap switch to take the full
advantage of double buffered bitmaps.
KVM_SWITCH_DIRTY_LOG
See th
We move dirty bitmaps to user space.
- Allocation and destruction: we use do_mmap() and do_munmap().
The new bitmap space is twice longer than the original one and we
use the additional space for double buffering: this makes it
possible to update the active bitmap while letting the user
This is not to break the build for other architectures than x86 and ppc.
Signed-off-by: Takuya Yoshikawa
Signed-off-by: Fernando Luis Vazquez Cao
---
arch/ia64/include/asm/kvm_host.h|5 +
arch/powerpc/include/asm/kvm_host.h |6 ++
arch/s390/include/asm/kvm_host.h|6 +
Although we can use *_le_bit() helpers to treat bitmaps le arranged,
having le bit offset calculation as a seperate macro gives us more freedom.
For example, KVM has le arranged dirty bitmaps for VGA, live-migration
and they are used in user space too. To avoid bitmap copies between kernel
and use
During the work of KVM's dirty page logging optimization, we encountered
the need of manipulating bitmaps in user space efficiantly. To achive this,
we introduce a uaccess function for setting a bit in user space following
Avi's suggestion.
KVM is now using dirty bitmaps for live-migration and V
During the work of KVM's dirty page logging optimization, we encountered
the need of copy_in_user() for 32-bit ppc and x86: these will be used for
manipulating dirty bitmaps in user space.
So we implement copy_in_user() for 32-bit with __copy_tofrom_user().
Signed-off-by: Takuya Yoshikawa
Signed
During the work of KVM's dirty page logging optimization, we encountered
the need of manipulating bitmaps in user space efficiantly. To achive this,
we introduce a uaccess function for setting a bit in user space following
Avi's suggestion.
KVM is now using dirty bitmaps for live-migration and V
During the work of KVM's dirty page logging optimization, we encountered
the need of copy_in_user() for 32-bit x86 and ppc: these will be used for
manipulating dirty bitmaps in user space.
So we implement copy_in_user() for 32-bit with existing generic copy user
helpers.
Signed-off-by: Takuya Yos
We will change the vmalloc() and vfree() to do_mmap() and do_munmap() later.
This patch makes it easy and cleanup the code.
Signed-off-by: Takuya Yoshikawa
Signed-off-by: Fernando Luis Vazquez Cao
---
virt/kvm/kvm_main.c | 27 ---
1 files changed, 20 insertions(+), 7 d
This patch introduces is_dirty member for each memory slot.
Using this member, we remove the dirty bitmap scans which are done in
get_dirty_log().
This is important for moving dirty bitmaps to user space because we don't
have any good ways to check bitmaps in user space with low cost and scanning
Although we always allocate a new dirty bitmap in x86's get_dirty_log(),
it is only used as a zero-source of copy_to_user() and freed right after
that when memslot is clean. This patch uses clear_user() instead of doing
this unnecessary zero-source allocation.
Performance improvement: as we can ex
Hi, sorry for sending from my personal account.
The following series are all from me:
From: Takuya Yoshikawa
The 3rd version of "moving dirty bitmaps to user space".
>From this version, we add x86 and ppc and asm-generic people to CC lists.
[To KVM people]
Sorry for being late to reply y
Mark Brown wrote:
> On Mon, May 03, 2010 at 04:54:15PM -0500, Timur Tabi wrote:
>
>> { .compatible = "simple-bus", },
>> -{ .compatible = "gianfar", },
>> +/* So that the DMA channel nodes can be probed individually: */
>> +{ .compatible = "fsl,eloplus-dma", },
>> {}
>
> The
On Tuesday 04 May 2010, Takuya Yoshikawa wrote:
>
> Although we can use *_le_bit() helpers to treat bitmaps le arranged,
> having le bit offset calculation as a seperate macro gives us more freedom.
>
> For example, KVM has le arranged dirty bitmaps for VGA, live-migration
> and they are used in
On Mon, May 03, 2010 at 04:54:15PM -0500, Timur Tabi wrote:
> { .compatible = "simple-bus", },
> - { .compatible = "gianfar", },
> + /* So that the DMA channel nodes can be probed individually: */
> + { .compatible = "fsl,eloplus-dma", },
> {}
The removal of gianfar looks
With a huge patch series like this, can you post a cover note at the front
(usually patch 0) saying what the point of the whole series is?
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, 2010-04-28 at 17:33 -0500, Steve Deiters wrote:
> The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121
> revision 2.
>
> ---
> drivers/mtd/nand/mpc5121_nfc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
Please, add your Signed-off-by and re-send.
-
33 matches
Mail list logo
