Re: [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps
One alternative would be: KVM_SWITCH_DIRTY_LOG passing the address of a bitmap. If the active bitmap was clean, it returns 0, no switch performed. If the active bitmap was dirty, the kernel switches to the new bitmap and returns 1. And the responsability of cleaning the new bitmap could also be left for userspace. That is a beautiful approach but we can do that only when we give up using GET api. I follow you and Avi's advice about that kind of maintenance policy! What do you think? If you introduce a switch ioctl that frees the bitmap vmalloc'ed by the current set_memory_region (if its not freed already), after pointing the memslot to the user supplied one, it should be fine? You mean switching from vmalloc'ed(not do_mmap'ed) one to user supplied one? It may be possible but makes things really complicated in my view: until some point we use set_bit, and then use set_bit_user, etc. IMO: - # of slots is limited and the size of dirty_bitmap_old pointer is not problematic. - Both user side and kernel side need not allocate buffers every time and once paired buffers are registered, we will reuse the buffers until user side orders to stop logging. - We have a tiny advantage if we need not copy_from_user to get a bitmap address for switch ioctl. = So I think having two __user bitmaps is not a bad thing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH RFC 10/12] KVM: move dirty bitmaps to user space
r = 0;
@@ -1195,11 +1232,16 @@ void mark_page_dirty(struct kvm *kvm, gfn_t gfn)
gfn = unalias_gfn(kvm, gfn);
memslot = gfn_to_memslot_unaliased(kvm, gfn);
if (memslot memslot-dirty_bitmap) {
- unsigned long rel_gfn = gfn - memslot-base_gfn;
+ int nr = generic_le_bit_offset(gfn - memslot-base_gfn);
- generic___set_le_bit(rel_gfn, memslot-dirty_bitmap);
+ if (kvm_set_bit_user(nr, memslot-dirty_bitmap))
+ goto out_fault;
mark_page_dirty is called with the mmu_lock spinlock held in set_spte.
Must find a way to move it outside of the spinlock section.
Oh, it's a serious problem. I have to consider it.
Thanks,
Takuya
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Wed, May 05, 2010 at 02:03:03AM +0530, K.Prasad wrote: It is true that the breakpoint exceptions will go amiss following the alignment exception, and be restored when the thread single-steps due to other requests causing undesirable effects. (Borrowing from some of the discussions I had with BenH, earlier) There can be two ways of changing the implementation to counter it: - To sense that the impending exception (alignment, page-fault, single-step) is a successor to a hw-breakpoint exception (and that restoration of debug register values is necessary), somewhere early in exceptions-64s.S and jump to a common handler, say do_single_step_dabr() which does a majority of single_step_dabr_instruction(). - To modify emulate_single_step() to also do a notify_die(DIE_SSTEP,...) in addition to its existing code. This would invoke single_step_dabr_instruction() where the breakpoints can be restored. I thought you would change the explicit regs-msr modification in single_step_exception() to clear_single_step(), then just make emulate_single_step() call single_step_exception(). I must admit that it is not clear to me when you say doesn't return to the instruction and instruction has been changed underneath. Are you Suppose the address at which the data breakpoint has been unmapped, and the process has a handler for the SIGSEGV signal. When we try to single-step the load or store, we will get a DSI (0x300) interrupt, call into do_page_fault, and end up sending the process a SIGSEGV. That will invoke the signal handler, which can then do anything it likes. It can do a blocking system call, it can longjmp() back into its main event, or it can return from the signal handler. Only in the last case will it retry the load or store, and then only if the signal handler hasn't modified the NIP value in the signal frame. That's what I mean by doesn't return to the instruction. The instruction could be changed underneath us if the program is multi-threaded and another thread writes another instruction to the instruction word where the load or store is. Or it could use mmap() to map some other page at the address of the load or store. Either way we could end up with a different instruction there. referring to the fact that the thread which generated breakpoints hits could have moved out of the CPU due to a scheduler induced context switch (which is an apparent cause for current-thread.last_hit_ubp to turn stale) or is there a different source for such a change that I don't realise? Given that 'last_hit_ubp' is safely ensconced inside 'thread_struct', the ill-effects of a possible pre-emption during a page-fault will be suitably handled i.e. the pending single-step exception will be generated on the processor to which 'current' is migrated to, and the breakpoint will be set on the new processor. If we do get a context switch, e.g. as a result of a page fault, and then switch back to the task, it looks to me like we will end up with MSR_SE and DABR both set. I don't suppose that will actually cause any real problem besides double-counting the hit. However, the possibility that current-thread.last_hit_ubp points to a perf_event structure that is unregistered and freed does exist, and I did not foresee the risk. An arch-specific function that hooks onto release_bp_slot() would be required to perform the cleanup. I will submit modify the patch to that effect. Thanks for pointing it out. Yes, I think we need that. In conjunction with what you've stated below, do you suggest that emulate_step() be replaced with fix_alignment() which appears to be more powerful at emulation (or carve out a helper function for fix_alignment() that does only emulation and which can be invoked here)? Something like that eventually, but not for a first pass. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
8640D Erratum fixup
Hi kumar, I just want to know whether the erratum of MPC8640D has fixed on u-boot or linux ? -Thirumalai CAUTION - Disclaimer *This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. *** End of Disclaimer ***DataPatterns ITS Group** ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Fix kexec on powerpc32
2010/5/12 Christian Kujau li...@nerdbynature.de
Maxim Uvarov wrote on 2010-05-11 10:47 :
This patch is required in case if you are using new toolchains.
I'm on Debian/stable (binutils 2.18, gcc 4.3.2), so I applied your patches
to the latest -git checkout:
First, compilation fails with:
cc1: warnings being treated as errors
kexec/arch/ppc/kexec-ppc.c: In function ‘get_base_ranges’:
kexec/arch/ppc/kexec-ppc.c:258: error: value computed is not used
make: *** [kexec/arch/ppc/kexec-ppc.o] Error 1
Somehow a - hyphen made it into one of the functions:
--- a/kexec/arch/ppc/kexec-ppc.c
+++ b/kexec/arch/ppc/kexec-ppc.c
[...]
if (local_memory_ranges = max_memory_ranges) {
- fclose(file);
- break;
+ if (realloc_memory_ranges() 0){
+ - fclose(file);
Oh, I sent this patch twice with stg -a by mistake. And second version has
-. I will fix and resend patches.
Removing this, gets me further, until:
purgatory/arch/ppc/crt.o: In function `__lshrdi3':
(.text+0xf0): multiple definition of `__lshrdi3'
purgatory/arch/ppc/misc.o:(.text+0x50): first defined here
collect2: ld returned 1 exit status
make: *** [purgatory/purgatory.ro] Error 1
And has been defined in purgatory/arch/ppc/crt.S and
./purgatory/arch/ppc/misc.S. Removing it from e.g. crt.S
makes it compile, I have not tested it yet, though :-)
Yes, that is expected result for old tool chains. New tool chains (from code
sourcery ) need this crt.S.
I think we can have --with-oldtoolchain option to configure to point to old
tool chains. (or even rename it to --with-crts,
I don't know what is better.)
Thanks,
Christian.
PS: Where is -Werror defined? I could not find it anywhere in the kexec
source (execpt in arch/mips)...
--
This -Werror came from mips. kexec/arch/mips/Makefile. It is already removed
in the git. We already saw this problem.
make bzImage, not war
--
Best regards,
Maxim Uvarov
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Fix kexec on powerpc32
On Wed, 12 May 2010 at 10:31, Maxim Uvarov wrote: Yes, that is expected result for old tool chains. New tool chains (from code sourcery ) need this crt.S. I think we can have --with-oldtoolchain option to configure to point to old tool chains. (or even rename it to --with-crts, I don't know what is better.) Yes, I've seen this --with-oldtoolchain flag in ./configure, but: when exactly is my toolchain old enough so that this flag has to be used? Is my binutils 2.18 too old? So, I'm all in favour of --with-crts (which I would use when compilation breaks with some descriptive error message) or, even better: can't we set this flag during ./configure automatically, based on the actual toolchain installed on the system? ./configure should be able to determine this, no? This -Werror came from mips. kexec/arch/mips/Makefile. It is already removed in the git. We already saw this problem. Powerpc including a mops Makefile, whooha :-) Thanks, Christian. -- BOFH excuse #91: Mouse chewed through power cable ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] Fix kexec on powerpc32
Hello everybody,
Changes from previous version:
- removed bogus hyphen from the patch;
- move ifdefs to crt.S instead of Makefile
Please find here patch for user land kexec-tools application. Following
patch makes kexec-tools work for both kexec and kdump. I tested it with
git kernel (linus-tree) and Freescale/Logic MPC8360ERDK board with
mpc83xx_defconfig kernel config.
kexec:
kexec -l vmlinux --command-line=console= ... etc
kexec -e
kdump:
kexec -p vmlinux_dump --command-line=console=... etc
echo c /proc/sysrq-trigger
I also think that is is reasonable:
- put GAME_CUBE specific code to separate files;
- combine ppc and ppc64 to powerpc directory (I'm planning to do it.
And that why in some places my patch have ifdefs for PPC64);
Best regards,
Maxim Uvarov.
From: Maxim Uvarov muva...@gmail.com
Signed-off-by: Maxim Uvarov muva...@gmail.com
Signed-off-by: Maxim Uvarov muva...@gmail.com
---
kexec/arch/ppc/Makefile|2
kexec/arch/ppc/crashdump-powerpc.c | 439 ++
kexec/arch/ppc/crashdump-powerpc.h | 38 +++
kexec/arch/ppc/fs2dt.c | 460
kexec/arch/ppc/kexec-elf-ppc.c | 186 +--
kexec/arch/ppc/kexec-ppc.c | 275 --
kexec/arch/ppc/kexec-ppc.h | 32 +++
purgatory/arch/ppc/Makefile|2
purgatory/arch/ppc/purgatory-ppc.c | 38 ++-
purgatory/arch/ppc/purgatory-ppc.h |4
purgatory/arch/ppc/v2wrap.S| 66 -
purgatory/arch/ppc/v2wrap_32.S | 91 +++
12 files changed, 1524 insertions(+), 109 deletions(-)
create mode 100644 kexec/arch/ppc/crashdump-powerpc.c
create mode 100644 kexec/arch/ppc/crashdump-powerpc.h
create mode 100644 kexec/arch/ppc/fs2dt.c
delete mode 100644 purgatory/arch/ppc/v2wrap.S
create mode 100644 purgatory/arch/ppc/v2wrap_32.S
diff --git a/kexec/arch/ppc/Makefile b/kexec/arch/ppc/Makefile
index 1c7441c..5988213 100644
--- a/kexec/arch/ppc/Makefile
+++ b/kexec/arch/ppc/Makefile
@@ -11,6 +11,8 @@ ppc_KEXEC_SRCS += kexec/arch/ppc/kexec-uImage-ppc.c
ppc_KEXEC_SRCS += kexec/arch/ppc/ppc-setup-simple.S
ppc_KEXEC_SRCS += kexec/arch/ppc/ppc-setup-dol.S
ppc_KEXEC_SRCS += kexec/arch/ppc/fixup_dtb.c
+ppc_KEXEC_SRCS += kexec/arch/ppc/fs2dt.c
+ppc_KEXEC_SRCS += kexec/arch/ppc/crashdump-powerpc.c
ppc_KEXEC_SRCS += kexec/kexec-uImage.c
libfdt_SRCS = kexec/arch/ppc/libfdt-wrapper.c
diff --git a/kexec/arch/ppc/crashdump-powerpc.c
b/kexec/arch/ppc/crashdump-powerpc.c
new file mode 100644
index 000..7bfad20
--- /dev/null
+++ b/kexec/arch/ppc/crashdump-powerpc.c
@@ -0,0 +1,439 @@
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include unistd.h
+#include errno.h
+#include limits.h
+#include elf.h
+#include dirent.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include ../../kexec.h
+#include ../../kexec-elf.h
+#include ../../kexec-syscall.h
+#include ../../crashdump.h
+#include kexec-ppc.h
+#include crashdump-powerpc.h
+
+#ifdef CONFIG_PPC64
+static struct crash_elf_info elf_info64 = {
+class: ELFCLASS64,
+data: ELFDATA2MSB,
+machine: EM_PPC64,
+backup_src_start: BACKUP_SRC_START,
+backup_src_end: BACKUP_SRC_END,
+page_offset: PAGE_OFFSET,
+lowmem_limit: MAXMEM,
+};
+#endif
+static struct crash_elf_info elf_info32 = {
+class: ELFCLASS32,
+data: ELFDATA2MSB,
+#ifdef CONFIG_PPC64
+machine: EM_PPC64,
+#else
+machine: EM_PPC,
+#endif
+backup_src_start: BACKUP_SRC_START,
+backup_src_end: BACKUP_SRC_END,
+page_offset: PAGE_OFFSET,
+lowmem_limit: MAXMEM,
+};
+
+/* Stores a sorted list of RAM memory ranges for which to create elf headers.
+ * A separate program header is created for backup region
+ */
+static struct memory_range *crash_memory_range;
+
+/* Define a variable to replace the CRASH_MAX_MEMORY_RANGES macro */
+static int crash_max_memory_ranges;
+
+/*
+ * Used to save various memory ranges/regions needed for the captured
+ * kernel to boot. (lime memmap= option in other archs)
+ */
+mem_rgns_t usablemem_rgns = {0, NULL};
+
+/*
+ * To store the memory size of the first kernel and this value will be
+ * passed to the second kernel as command line (savemaxmem=xM).
+ * The second kernel will be calculated saved_max_pfn based on this
+ * variable.
+ * Since we are creating/using usable-memory property, there is no way
+ * we can determine the RAM size unless parsing the device-tree/memoy@/reg
+ * property in the kernel.
+ */
+unsigned long long saved_max_mem;
+
+/* Reads the appropriate file and retrieves the SYSTEM RAM regions for whom to
+ * create Elf headers. Keeping it separate from get_memory_ranges() as
+ * requirements are different in the case of normal kexec and crashdumps.
+ *
+ * Normal kexec needs to look at all of available physical memory irrespective
+ * of the fact how much of it is being used by currently running kernel.
+ * Crashdumps need to
[PATCH v2 2/2] powerpc new toolchains fix (crt.S)
Hello everybody, Changes from previous version: - removed bogus hyphen from the patch; - move ifdefs to crt.S instead of Makefile Please find here patch for user land kexec-tools application. Following patch makes kexec-tools work for both kexec and kdump. I tested it with git kernel (linus-tree) and Freescale/Logic MPC8360ERDK board with mpc83xx_defconfig kernel config. kexec: kexec -l vmlinux --command-line=console= ... etc kexec -e kdump: kexec -p vmlinux_dump --command-line=console=... etc echo c /proc/sysrq-trigger I also think that is is reasonable: - put GAME_CUBE specific code to separate files; - combine ppc and ppc64 to powerpc directory (I'm planning to do it. And that why in some places my patch have ifdefs for PPC64); Best regards, Maxim Uvarov. From: Maxim Uvarov muva...@gmail.com Linker does not provide some vital functions when building freestanding applications with a new toolchain, so we have to provide our own CRT. p.s. Without the CRT we won't see any build errors (since the purgatory is linked with --no-undefined), but the purgatory code won't work, 'kexec -e' will just hang the board. I added option to configure to keep code buildable for old toolchais. But there should be way to do this automatically. Author: Anton Vorontsov avoront...@ru.mvista.com Signed-off-by: Maxim Uvarov muva...@gmail.com Signed-off-by: Maxim Uvarov muva...@gmail.com --- configure.ac|9 + purgatory/arch/ppc/Makefile |1 purgatory/arch/ppc/crt.S| 263 +++ 3 files changed, 273 insertions(+), 0 deletions(-) create mode 100644 purgatory/arch/ppc/crt.S diff --git a/configure.ac b/configure.ac index fcf50e4..63606bc 100644 --- a/configure.ac +++ b/configure.ac @@ -159,6 +159,15 @@ if test $with_xen = yes ; then AC_MSG_NOTICE([Xen support disabled]))) fi +dnl new toolchains +if test $ARCH = ppc; then +AC_ARG_WITH([oldtoolchain], + AC_HELP_STRING([--with-oldtoolchain],[compile without crt.S + required for new toolchains]), + AC_DEFINE(PPC_OLDTOOLCHAIN, 1, + [Define to compile with old toolchains])) +fi + dnl ---Sanity checks if test $CC = no; then AC_MSG_ERROR([cc not found]); fi if test $CPP = no; then AC_MSG_ERROR([cpp not found]); fi diff --git a/purgatory/arch/ppc/Makefile b/purgatory/arch/ppc/Makefile index 72289a0..4020778 100644 --- a/purgatory/arch/ppc/Makefile +++ b/purgatory/arch/ppc/Makefile @@ -6,6 +6,7 @@ ppc_PURGATORY_SRCS += purgatory/arch/ppc/v2wrap_32.S ppc_PURGATORY_SRCS += purgatory/arch/ppc/misc.S ppc_PURGATORY_SRCS += purgatory/arch/ppc/purgatory-ppc.c ppc_PURGATORY_SRCS += purgatory/arch/ppc/console-ppc.c +ppc_PURGATORY_SRCS += purgatory/arch/ppc/crt.S dist += purgatory/arch/ppc/Makefile $(ppc_PURGATORY_SRCS) \ purgatory/arch/ppc/purgatory-ppc.h purgatory/arch/ppc/ppc_asm.h diff --git a/purgatory/arch/ppc/crt.S b/purgatory/arch/ppc/crt.S new file mode 100644 index 000..70f4d61 --- /dev/null +++ b/purgatory/arch/ppc/crt.S @@ -0,0 +1,263 @@ +/* This is from linux-2.6/arch/powerpc/lib/crtsavres.S: + * + * Special support for eabi and SVR4 + * + * Copyright (C) 1995, 1996, 1998, 2000, 2001 Free Software Foundation, Inc. + * Copyright 2008 Freescale Semiconductor, Inc. + * Written By Michael Meissner + * + * Based on gcc/config/rs6000/crtsavres.asm from gcc + * + * This file is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * In addition to the permissions in the GNU General Public License, the + * Free Software Foundation gives you unlimited permission to link the + * compiled version of this file with other programs, and to distribute + * those programs without any restriction coming from the use of this + * file. (The General Public License restrictions do apply in other + * respects; for example, they cover modification of the file, and + * distribution when not linked into another program.) + * + * This file is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; see the file COPYING. If not, write to + * the Free Software Foundation, 51 Franklin Street, Fifth Floor, + * Boston, MA 02110-1301, USA. + * + *As a special exception, if you link this library with files + *compiled with GCC to produce an executable, this does not cause + *the resulting executable to be covered by the GNU General Public
Re: [PATCH 1/2] Fix kexec on powerpc32
On Tue, 11 May 2010 at 21:47, Maxim Uvarov wrote: This patch is required in case if you are using new toolchains. After kexec-tools compiled, I actually tried it: # kexec -l /boot/2.6/zImage --command-line=root=/dev/hda6 ro # echo $? 0 # kexec -e Starting new kernel Bye! but then the system just hung there, no more messages, I had to powercycle it. The --debug options is listed for dol-ppc systems (I have a PowerBook G4, not sure if this falls into this category), when I use it the help screen of kexec is displayed again and at the bottom: Cannot load /boot/2.6/zImage This is with 2.6.34-rc7 (today's git): # file /boot/2.6/zImage /boot/2.6/zImage: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, with unknown capability 0x4100 = 0x11676e75, with unknown capability 0x1 = 0x90402, not stripped .config and dmesg: http://nerdbynature.de/bits/2.6.34-rc7/kexec/ Christian. -- make bzImage, not war ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] hwmon: (tmp421) Add nfactor support.
Hi Jeff, On Tue, 11 May 2010 15:34:29 -0400, Jeff Angielski wrote: On 05/11/2010 03:03 PM, Andre Prendel wrote: I'de prefer implementing the sysfs access methods in a consistent way (see other functions). That means adding the nfactor register to the tmp421_data structure and using tmp421_update_device() to update the structure. I did this on purpose since the nfactor typically only changes once at runtime when you program it for your sensor. It seemed like a waste of processing power and i2c bandwidth to read a pseudo static register over and over again. It can easily be changed if that's what will help the community the best. I get your point and it makes sense. However, we also have to ensure that no regular user can saturate the I2C link by repeatedly polling for the same register value. So, any sysfs attribute which triggers an immediate I2C transaction shouldn't be accessible by regular users (i.e. change the mode from 0644 to 0640). An alternative is to slit the cache into short-lived (~ 1 or 2 seconds) and long-lived (1 to 5 minutes.) A number of drivers do this. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Please pull this perf event fix from Paulus. Without it, using perf event can potentially oops the machine at any time. Thanks ! Cheers, Ben. The following changes since commit cea0d767c29669bf89f86e4aee46ef462d2ebae8: Linus Torvalds (1): Merge branch 'hwmon-for-linus' of git://git.kernel.org/.../jdelvare/staging are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Paul Mackerras (1): powerpc/perf_event: Fix oops due to perf_event_do_pending call arch/powerpc/include/asm/hw_irq.h | 38 --- arch/powerpc/kernel/asm-offsets.c |1 - arch/powerpc/kernel/entry_64.S|9 - arch/powerpc/kernel/irq.c |6 arch/powerpc/kernel/time.c| 60 +--- 5 files changed, 48 insertions(+), 66 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix UART clocks on 440SPe
On Wednesday 12 May 2010 04:22:50 Benjamin Herrenschmidt wrote: The code to fixup the serial ports on 440SPe uses the incorrect addresses for these. This fixes it. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Acked-by: Stefan Roese s...@denx.de Cheers, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space
[To ppc people] Hi, Benjamin, Paul, Alex, Please see the patches 6,7/12. I first say sorry for that I've not tested these yet. In that sense, these may not be in the quality for precise reviews. But I will be happy if you would give me any comments. Alex, could you help me? Though I have a plan to get PPC box in the future, currently I cannot test these. Could you please point me to a git tree where everything's readily applied? That would make testing a lot easier. OK, I'll prepare one. Probably on sourceforge or somewhere like Kemari. Thanks, Takuya Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like function for bitmaps in user space
+static inline int set_bit_user_non_atomic(int nr, void __user *addr)
+{
+ u8 __user *p;
+ u8 val;
+
+ p = (u8 __user *)((unsigned long)addr + nr / BITS_PER_BYTE);
Does C do the + or the / first? Either way, I'd like to see brackets here :)
OK, I'll change like that! I like brackets style too :)
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On May 12, 2010, at 2:46 AM, Benjamin Herrenschmidt wrote: Hi Linus ! Please pull this perf event fix from Paulus. Without it, using perf event can potentially oops the machine at any time. Thanks ! Cheers, Ben. The following changes since commit cea0d767c29669bf89f86e4aee46ef462d2ebae8: Linus Torvalds (1): Merge branch 'hwmon-for-linus' of git://git.kernel.org/.../jdelvare/staging are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Paul Mackerras (1): powerpc/perf_event: Fix oops due to perf_event_do_pending call arch/powerpc/include/asm/hw_irq.h | 38 --- arch/powerpc/kernel/asm-offsets.c |1 - arch/powerpc/kernel/entry_64.S|9 - arch/powerpc/kernel/irq.c |6 arch/powerpc/kernel/time.c| 60 +--- 5 files changed, 48 insertions(+), 66 deletions(-) Ben, Did where you going to also send linus: http://patchwork.ozlabs.org/patch/51496/ - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix UART clocks on 440SPe
On Wed, May 12, 2010 at 12:22:50PM +1000, Benjamin Herrenschmidt wrote: The code to fixup the serial ports on 440SPe uses the incorrect addresses for these. This fixes it. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- I'm surprised nobody noticed, serial is pretty busted for me without that patch :-) Odd. I don't have a 440SPe, so no surprise there but I would have thought someone would notice. Though this is only needed if you are using an older U-Boot that needs cuImage, and I'm guessing Stefan runs u-boot.git on his boards ;) diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c index 27db893..627de25 100644 --- a/arch/powerpc/boot/4xx.c +++ b/arch/powerpc/boot/4xx.c @@ -544,9 +544,9 @@ void ibm440spe_fixup_clocks(unsigned int sys_clk, unsigned int plb_clk = __ibm440eplike_fixup_clocks(sys_clk, tmr_clk, 1); /* serial clocks beed fixup based on int/ext */ You couldn't be bothered to fixup the typo? s/beed/need ;) I'll fix it when I bring this in. - eplike_fixup_uart_clk(0, /plb/opb/ser...@1200, ser_clk, plb_clk); - eplike_fixup_uart_clk(1, /plb/opb/ser...@1300, ser_clk, plb_clk); - eplike_fixup_uart_clk(2, /plb/opb/ser...@1600, ser_clk, plb_clk); + eplike_fixup_uart_clk(0, /plb/opb/ser...@f200, ser_clk, plb_clk); + eplike_fixup_uart_clk(1, /plb/opb/ser...@f300, ser_clk, plb_clk); + eplike_fixup_uart_clk(2, /plb/opb/ser...@f600, ser_clk, plb_clk); } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Wed, 2010-05-12 at 05:24 -0500, Kumar Gala wrote: Did where you going to also send linus: http://patchwork.ozlabs.org/patch/51496/ Forgot about that one... I'll add it to the pile tomorrow. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Please pull 'next' branch of 4xx (again)
On Fri, May 07, 2010 at 03:54:53PM -0400, Josh Boyer wrote: Hi Ben, Two more quick patches from me for -next. Stefrano's is the Katmai usage of the reset type change that just went in. The 460SX PCI-e patch has been sitting for a while and seems to have been skipped over. I've updated my next branch with two more patches. Yours for the 440SPe UART clock fix, and the new platform addition of Icon 440SPe from Stefan. Updated diffstat below. Thanks, josh The following changes since commit 1ed31d6db90d51010545921e59d369d2f92b7ac2: Benjamin Herrenschmidt (1): Merge commit 'origin/master' into next are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Benjamin Herrenschmidt (1): powerpc/44x: Fix UART clocks on 440SPe Stefan Roese (2): powerpc/44x: Add reset-type to katmai.dts powerpc/44x: Add basic ICON PPC440SPe board support Tirumala Marri (1): powerpc/44x: Adding PCI-E support for PowerPC 460SX based SOC. arch/powerpc/boot/4xx.c| 12 +- arch/powerpc/boot/dts/icon.dts | 447 ++ arch/powerpc/boot/dts/katmai.dts |1 + arch/powerpc/boot/dts/redwood.dts | 122 +++ arch/powerpc/configs/44x/icon_defconfig| 1316 arch/powerpc/platforms/44x/Kconfig | 11 + arch/powerpc/platforms/44x/ppc44x_simple.c |3 +- arch/powerpc/sysdev/ppc4xx_pci.c | 119 +++ arch/powerpc/sysdev/ppc4xx_pci.h | 58 ++ 9 files changed, 2082 insertions(+), 7 deletions(-) create mode 100644 arch/powerpc/boot/dts/icon.dts create mode 100644 arch/powerpc/configs/44x/icon_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Fix kexec on powerpc32
2010/5/12 Christian Kujau li...@nerdbynature.de On Tue, 11 May 2010 at 21:47, Maxim Uvarov wrote: This patch is required in case if you are using new toolchains. After kexec-tools compiled, I actually tried it: # kexec -l /boot/2.6/zImage --command-line=root=/dev/hda6 ro # echo $? 0 # kexec -e Starting new kernel Bye! but then the system just hung there, no more messages, I had to powercycle it. The --debug options is listed for dol-ppc systems (I have a PowerBook G4, not sure if this falls into this category), when I use it the help screen of kexec is displayed again and at the bottom: Cannot load /boot/2.6/zImage This is with 2.6.34-rc7 (today's git): # file /boot/2.6/zImage /boot/2.6/zImage: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, with unknown capability 0x4100 = 0x11676e75, with unknown capability 0x1 = 0x90402, not stripped .config and dmesg: http://nerdbynature.de/bits/2.6.34-rc7/kexec/ Christian. -- make bzImage, not war Can you try vmlinux? I tested only with vmlinux. -- Best regards, Maxim Uvarov ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Fix kexec on powerpc32
On Wed, May 12, 2010 at 10:31:26AM +0400, Maxim Uvarov wrote:
2010/5/12 Christian Kujau li...@nerdbynature.de
Maxim Uvarov wrote on 2010-05-11 10:47 :
This patch is required in case if you are using new toolchains.
I'm on Debian/stable (binutils 2.18, gcc 4.3.2), so I applied your patches
to the latest -git checkout:
First, compilation fails with:
cc1: warnings being treated as errors
kexec/arch/ppc/kexec-ppc.c: In function ‘get_base_ranges’:
kexec/arch/ppc/kexec-ppc.c:258: error: value computed is not used
make: *** [kexec/arch/ppc/kexec-ppc.o] Error 1
Somehow a - hyphen made it into one of the functions:
--- a/kexec/arch/ppc/kexec-ppc.c
+++ b/kexec/arch/ppc/kexec-ppc.c
[...]
if (local_memory_ranges = max_memory_ranges) {
- fclose(file);
- break;
+ if (realloc_memory_ranges() 0){
+ - fclose(file);
Oh, I sent this patch twice with stg -a by mistake. And second version has
-. I will fix and resend patches.
Removing this, gets me further, until:
purgatory/arch/ppc/crt.o: In function `__lshrdi3':
(.text+0xf0): multiple definition of `__lshrdi3'
purgatory/arch/ppc/misc.o:(.text+0x50): first defined here
collect2: ld returned 1 exit status
make: *** [purgatory/purgatory.ro] Error 1
And has been defined in purgatory/arch/ppc/crt.S and
./purgatory/arch/ppc/misc.S. Removing it from e.g. crt.S
makes it compile, I have not tested it yet, though :-)
Yes, that is expected result for old tool chains. New tool chains (from code
sourcery ) need this crt.S.
I think we can have --with-oldtoolchain option to configure to point to old
tool chains. (or even rename it to --with-crts,
I don't know what is better.)
I think --with-crts would be better as --with-oldtoolchain could
mean many things.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Update smt_enabled=X handling for cores with more than two threads
This patch updates the handling of the smt-enabled=X boot option to handle
settings on systems with more than two threads per core. This change involves
moving all of the handling of the boot option to the check_smt_enabled()
routine and the calling of this routine in setup_system() until after the
smp_setup_cpu_maps() call. This is done so that we can use the
threads_per_core variable when validating the smt boot option specified.
Signed-off-by: Nathan Fontenotnf...@austin.ibm.com
---
arch/powerpc/kernel/setup_64.c | 61 ---
arch/powerpc/platforms/pseries/smp.c | 11 --
2 files changed, 42 insertions(+), 30 deletions(-)
Index: powerpc/arch/powerpc/kernel/setup_64.c
===
--- powerpc.orig/arch/powerpc/kernel/setup_64.c 2010-05-12 08:33:38.0
-0500
+++ powerpc/arch/powerpc/kernel/setup_64.c 2010-05-12 08:48:10.0
-0500
@@ -95,7 +95,7 @@
#ifdef CONFIG_SMP
-static int smt_enabled_cmdline;
+static char *smt_enabled_cmdline;
/* Look for ibm,smt-enabled OF option */
static void check_smt_enabled(void)
@@ -103,37 +103,46 @@
struct device_node *dn;
const char *smt_option;
- /* Allow the command line to overrule the OF option */
- if (smt_enabled_cmdline)
- return;
-
- dn = of_find_node_by_path(/options);
+ /* Default to enabling all threads */
+ smt_enabled_at_boot = threads_per_core;
- if (dn) {
- smt_option = of_get_property(dn, ibm,smt-enabled, NULL);
+ /* Allow the command line to overrule the OF option */
+ if (smt_enabled_cmdline) {
+ if (!strcmp(smt_enabled_cmdline, on))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_enabled_cmdline, off))
+ smt_enabled_at_boot = 0;
+ else {
+ long smt;
+ int rc;
+
+ rc = strict_strtol(smt_enabled_cmdline, 10,smt);
+ if (!rc)
+ smt_enabled_at_boot =
+ min(threads_per_core, (int)smt);
+ }
+ } else {
+ dn = of_find_node_by_path(/options);
+ if (dn) {
+ smt_option = of_get_property(dn, ibm,smt-enabled,
+NULL);
+
+ if (smt_option) {
+ if (!strcmp(smt_option, on))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_option, off))
+ smt_enabled_at_boot = 0;
+ }
-if (smt_option) {
- if (!strcmp(smt_option, on))
- smt_enabled_at_boot = 1;
- else if (!strcmp(smt_option, off))
- smt_enabled_at_boot = 0;
-}
-}
+ of_node_put(dn);
+ }
+ }
}
/* Look for smt-enabled= cmdline option */
static int __init early_smt_enabled(char *p)
{
- smt_enabled_cmdline = 1;
-
- if (!p)
- return 0;
-
- if (!strcmp(p, on) || !strcmp(p, 1))
- smt_enabled_at_boot = 1;
- else if (!strcmp(p, off) || !strcmp(p, 0))
- smt_enabled_at_boot = 0;
-
+ smt_enabled_cmdline = p;
return 0;
}
early_param(smt-enabled, early_smt_enabled);
@@ -390,8 +399,8 @@
*/
xmon_setup();
- check_smt_enabled();
smp_setup_cpu_maps();
+ check_smt_enabled();
#ifdef CONFIG_SMP
/* Release secondary cpus out of their spinloops at 0x60 now that
Index: powerpc/arch/powerpc/platforms/pseries/smp.c
===
--- powerpc.orig/arch/powerpc/platforms/pseries/smp.c 2010-05-12
08:33:38.0 -0500
+++ powerpc/arch/powerpc/platforms/pseries/smp.c2010-05-12
08:36:09.0 -0500
@@ -154,10 +154,13 @@
/* Special case - we inhibit secondary thread startup
* during boot if the user requests it.
*/
- if (system_state SYSTEM_RUNNING
- cpu_has_feature(CPU_FTR_SMT)
- !smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
- return 0;
+ if (system_state SYSTEM_RUNNING cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+ cpu_thread_in_core(nr)= smt_enabled_at_boot)
+ return 0;
+ }
return 1;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Re: Config Items appearing twice in same Kconfig file?
Just noticed it might have been worth adding the output so everyone out there doesn't ned to grep through his tree for reference: % grep ^config **/Kconfig* | sort | uniq -dc 2 arch/alpha/Kconfig.debug:config ALPHA_LEGACY_START_ADDRESS 2 arch/alpha/Kconfig:config ALPHA_EV4 3 arch/alpha/Kconfig:config ALPHA_EV56 2 arch/alpha/Kconfig:config ALPHA_GAMMA 2 arch/blackfin/Kconfig:config MEM_MT48LC32M8A2_75 2 arch/cris/arch-v32/drivers/Kconfig:config ETRAX_RS485 2 arch/cris/arch-v32/drivers/Kconfig:config ETRAX_RS485_DISABLE_RECEIVER 2 arch/cris/arch-v32/drivers/Kconfig:config ETRAX_SER3_CD_BIT 2 arch/h8300/Kconfig.ide:config H8300_IDE_ALT 2 arch/h8300/Kconfig.ide:config H8300_IDE_BASE 2 arch/h8300/Kconfig.ide:config H8300_IDE_IRQ 2 arch/ia64/Kconfig:config IOMMU_HELPER 2 arch/powerpc/Kconfig:config KERNEL_START 2 arch/powerpc/Kconfig:config PAGE_OFFSET 2 arch/powerpc/Kconfig:config PHYSICAL_START 2 arch/powerpc/Kconfig:config RELOCATABLE 2 arch/score/Kconfig:config RWSEM_GENERIC_SPINLOCK 4 arch/x86/Kconfig.debug:config DEFAULT_IO_DELAY_TYPE 2 arch/x86/Kconfig:config PCI_MMCONFIG 2 arch/x86/Kconfig:config X86_EXTENDED_PLATFORM 2 drivers/isdn/hisax/Kconfig:config HISAX_AVM_A1_PCMCIA 2 net/ipv4/Kconfig:config TCP_CONG_CUBIC ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Config Items appearing twice in same Kconfig file?
Hi all! First of all sorry for the huge CC, I couldn't come up with a way to create a smaller list while reaching all the relevant people. We, the vamos project[1] at the Friedrich Alexander University are analything the linux configuration model trying to detect errors. During a run with our tools we noticed the fact that the option ALPHA_LEGACY_START_ADDRESS in arch/alpha/Kconfig.debug is listed twice with contradictory dependencies on ALPHA_GENERIC. Taking a closer look[2] we noticed 22 occurences where the same config option is defined more than once in the same Kconfig file, not all of them are, of course, contradictory as the ALPHA sample. Wed be interested in reasons to keep this configuration split up in the same file or if this is just a error introduced someeewhere in linux' development that should be fixed. Regards Chritoph Egger [ Please keep vamos@ Cc-ed -- we're not following all the lkml traffic ;) no need to keep me though ] [1] http://vamos1.informatik.uni-erlangen.de [2] grep ^config **/Kconfig* | sort | uniq -d -c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix register_power_pmu() section mismatch warning
Add missing __cpuinit annotations to fix a bunch of warnings like the one
shown below when building a kernel for the PowerPC architecture with
CONFIG_DEBUG_SECTION_MISMATCH=y.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x11c72): Section mismatch in
reference from the function register_power_pmu() to the variable
.cpuinit.data:power_pmu_notifier_nb.23552
The function register_power_pmu() references
the variable __cpuinitdata power_pmu_notifier_nb.23552.
This is often because register_power_pmu lacks a __cpuinitdata
annotation or the annotation of power_pmu_notifier_nb.23552 is wrong.
Signed-off-by: Albert Herranz albert_herr...@yahoo.es
---
arch/powerpc/kernel/mpc7450-pmu.c |2 +-
arch/powerpc/kernel/perf_event.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c
b/arch/powerpc/kernel/mpc7450-pmu.c
index 09d7202..3982bfa 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -405,7 +405,7 @@ struct power_pmu mpc7450_pmu = {
.cache_events = mpc7450_cache_events,
};
-static int init_mpc7450_pmu(void)
+static int __cpuinit init_mpc7450_pmu(void)
{
if (!cur_cpu_spec-oprofile_cpu_type ||
strcmp(cur_cpu_spec-oprofile_cpu_type, ppc/7450))
diff --git a/arch/powerpc/kernel/perf_event.c b/arch/powerpc/kernel/perf_event.c
index 08460a2..6b70834 100644
--- a/arch/powerpc/kernel/perf_event.c
+++ b/arch/powerpc/kernel/perf_event.c
@@ -1314,7 +1314,7 @@ power_pmu_notifier(struct notifier_block *self, unsigned
long action, void *hcpu
return NOTIFY_OK;
}
-int register_power_pmu(struct power_pmu *pmu)
+int __cpuinit register_power_pmu(struct power_pmu *pmu)
{
if (ppmu)
return -EBUSY; /* something's already registered */
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix register_power_pmu() section mismatch warning
On Wed, May 12, 2010 at 08:04:46PM +0200, Albert Herranz wrote: Add missing __cpuinit annotations to fix a bunch of warnings like the one shown below when building a kernel for the PowerPC architecture with CONFIG_DEBUG_SECTION_MISMATCH=y. WARNING: arch/powerpc/kernel/built-in.o(.text+0x11c72): Section mismatch in reference from the function register_power_pmu() to the variable .cpuinit.data:power_pmu_notifier_nb.23552 The function register_power_pmu() references the variable __cpuinitdata power_pmu_notifier_nb.23552. This is often because register_power_pmu lacks a __cpuinitdata annotation or the annotation of power_pmu_notifier_nb.23552 is wrong. Hmmm, I would think these things could be just plain __init, not __cpuinit. They're not called on cpu hotplug events. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Config Items appearing twice in same Kconfig file?
On Wed, 2010-05-12 at 16:40 +0200, Christoph Egger wrote: Just noticed it might have been worth adding the output so everyone out there doesn't ned to grep through his tree for reference: % grep ^config **/Kconfig* | sort | uniq -dc That didn't actually work for me? 2 arch/powerpc/Kconfig:config KERNEL_START 2 arch/powerpc/Kconfig:config PAGE_OFFSET 2 arch/powerpc/Kconfig:config PHYSICAL_START 2 arch/powerpc/Kconfig:config RELOCATABLE The duplication of these is caused by the second definitions being inside an if PPC64 block. For PAGE_OFFSET and KERNEL_START we want the 2nd definitions, the default value is different between 32 64 bit. For RELOCATABLE it's a little weird, but we want the 2nd definition because the depends condition is different between 32 64bit - though they could probably be merged. I don't really see why we need two versions of PHYSICAL_START. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [POWEPC] crashdump: do not fail on null pointer dereferencing
On Tue, 2010-05-11 at 18:02 +0200, Vitaly Wool wrote:
Hi,
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 6f4613d..341d8af 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -375,6 +375,9 @@ void default_machine_crash_shutdown(struct pt_regs
*regs)
for_each_irq(i) {
struct irq_desc *desc = irq_to_desc(i);
+ if (!desc || !desc-chip || !desc-chip-eoi)
+ continue;
+
Actually almost certain that desc will be NULL. When CONFIG_SPARSE_IRQ=y
(the default), irq_desc's are allocated lazily.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! I've added to my merge branch Kumar's swiotlb fix. Here's the updated pull request. Thanks ! Cheers, Ben. The following changes since commit cea0d767c29669bf89f86e4aee46ef462d2ebae8: Linus Torvalds (1): Merge branch 'hwmon-for-linus' of git://git.kernel.org/.../jdelvare/staging are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Benjamin Herrenschmidt (1): Merge commit 'kumar/merge' into merge Kumar Gala (1): powerpc/swiotlb: Fix off by one in determining boundary of which ops to use Paul Mackerras (1): powerpc/perf_event: Fix oops due to perf_event_do_pending call arch/powerpc/include/asm/hw_irq.h | 38 --- arch/powerpc/kernel/asm-offsets.c |1 - arch/powerpc/kernel/dma-swiotlb.c |5 ++- arch/powerpc/kernel/entry_64.S|9 - arch/powerpc/kernel/irq.c |6 arch/powerpc/kernel/time.c| 60 +--- 6 files changed, 51 insertions(+), 68 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
event-scan failed logflood
I upgraded the kernel on my Pegasos from 2.6.32 to 2.6.33 and now it sends the message event-scan failed to the kernel log about 60 times per second as long as it's running. The message comes from arch/powerpc/kernel/rtasd.c but I don't know what's going on in there so I can't say much more about it. How may I help find the cause of this problem? (Or alternatively: what is the correct way to disable this event-scan? I suspect it's not really necessary since it didn't exist in the previous kernel version, and the system is running perfectly aside from the error message flood.) -- Alan Curry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
