Re: [PowerPC] 2.6.30-git14 boot failure with SLAB
Benjamin Herrenschmidt wrote: That is strange. If I revert that commit, I get breakages on machines here. It would be interesting to understand what the problem is here, as we -do- use that kmem cache for allocating page tables, so we do need it initialized that early. (IE, we can't allow vmalloc for example to be called before the page table caches are initialized). This will need more debugging and understanding as to why it hangs. Hi Ben, Looks like the control enters pgtable_cache_init but rever returns. The machine just hangs. I triggered a system reset via HMC to see what's happening on the cpu. Here is the xmon o/p after a system reset. The code that was executed was __mutex_lock_slowpath.. cpu 0x0: Vector: 100 (System Reset) at [c0b138e0] pc: c060a4b8: .__mutex_lock_slowpath+0x9c/0x1f4 lr: c060abc8: .mutex_lock+0x50/0x70 sp: c0b13b60 msr: 80081032 current = 0xc0a3ab70 paca= 0xc0be2400 pid = 0, comm = swapper enter ? for help [c0b13c30] c060abc8 .mutex_lock+0x50/0x70 [c0b13cb0] c008c7f0 .get_online_cpus+0x4c/0x84 [c0b13d40] c014a120 .kmem_cache_create+0xcc/0x5f4 [c0b13e50] c0033f38 .pgtable_cache_init+0x28/0x78 [c0b13ee0] c08809a4 .start_kernel+0x1f8/0x568 [c0b13f90] c00083d8 .start_here_common+0x1c/0x44 0:mon 0:mon di $.__mutex_lock_slowpath c060a41c fba1ffe8 std r29,-24(r1) c060a420 7c0802a6 mflrr0 SNIP . c060a46c 7fe4fb78 mr r4,r31 c060a470 419e0014 beq cr7,c060a484# .__mutex_lock_slowpath+0x68/0x1f4 c060a474 4ba6859d bl c0072a10# .mutex_spin_on_owner+0x0/0xbc c060a478 6000 nop c060a47c 2fa3 cmpdi cr7,r3,0 c060a480 419e0078 beq cr7,c060a4f8# .__mutex_lock_slowpath+0xdc/0x1f4 c060a484 93010070 stw r24,112(r1) c060a488 93210074 stw r25,116(r1) c060a48c 81210070 lwz r9,112(r1) c060a490 80010074 lwz r0,116(r1) c060a494 7d2907b4 extsw r9,r9 c060a498 7c0007b4 extsw r0,r0 0:mon c060a49c 7c2004ac lwsync c060a4a0 7d60e828 lwarx r11,0,r29 c060a4a4 7c0b4800 cmpwr11,r9 c060a4a8 40c20010 bne-c060a4b8# .__mutex_lock_slowpath+0x9c/0x1f4 c060a4ac 7c00e92d stwcx. r0,0,r29 c060a4b0 40c2fff0 bne-c060a4a0# .__mutex_lock_slowpath+0x84/0x1f4 c060a4b4 4c00012c isync c060a4b8 2f8b0001 cmpwi cr7,r11,1 ^ PC points to this instruction c060a4bc 2f3f cmpdi cr6,r31,0 c060a4c0 409e0010 bne cr7,c060a4d0# .__mutex_lock_slowpath+0xb4/0x1f4 c060a4c4 78200464 rldicr r0,r1,0,49 c060a4c8 f81d0030 std r0,48(r29) c060a4cc 48000118 b c060a5e4# .__mutex_lock_slowpath+0x1c8/0x1f4 c060a4d0 409a001c bne cr6,c060a4ec# .__mutex_lock_slowpath+0xd0/0x1f4 c060a4d4 e81b ld r0,0(r27) c060a4d8 7809f7e3 rldicl. r9,r0,62,63 0:mon r R00 = R16 = 02bc4b68 R01 = c0b13b60 R17 = R02 = c0b0bca0 R18 = c08c4b68 R03 = c0d07fd0 R19 = 01b1fc90 R04 = R20 = 00b8 R05 = 005e R21 = c07ec008 R06 = 0004 R22 = 007c28bb R07 = c0a95288 R23 = c07cbdd5 R08 = R24 = 0001 R09 = 0001 R25 = R10 = R26 = c0d08000 R11 = R27 = c0b10080 R12 = 2482 R28 = c0a3ab70 R13 = c0be2400 R29 = c0d07fd0 R14 = c08c4c30 R30 = c0a75be8 R15 = c0a95288 R31 = pc = c060a4b8 .__mutex_lock_slowpath+0x9c/0x1f4 lr = c060abc8 .mutex_lock+0x50/0x70 msr = 80081032 cr = 8422 ctr = 00136f8c xer = 0001 trap = 100 0:mon Let me know if i can provide more information. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
* Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2009-06-17 at 16:27 +0200, Ingo Molnar wrote: I think it would be nice to have more platform support in .31. Perfcounters is a brand-new feature so there's no risk of regression. In the end it will depend on Linus to pull of course, and BenH can veto it too if he'd like no more PowerPC changes in this cycle. Worst-case it's all .32 material. There have been little PowerPC changes in this cycle and I agree with you on that it's a nice feature to have with little risk of regression. Ok - thanks - i'll push it to Linus probably later today. In fact, I also have an up-to-date (and hopefully working) irqtrace/lockdep patch for 32-bit powerpc (we only do 64-bit right now) that I'm considering merging this time around, the benefit it brings is worth the risk I believe. Nice :-) Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] powerpc/85xx: remove duplicated #include
Remove duplicated #include in arch/powerpc/platforms/85xx/xes_mpc85xx.c. Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com --- arch/powerpc/platforms/85xx/xes_mpc85xx.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/85xx/xes_mpc85xx.c b/arch/powerpc/platforms/85xx/xes_mpc85xx.c index ee01532..1b42605 100644 --- a/arch/powerpc/platforms/85xx/xes_mpc85xx.c +++ b/arch/powerpc/platforms/85xx/xes_mpc85xx.c @@ -32,7 +32,6 @@ #include sysdev/fsl_soc.h #include sysdev/fsl_pci.h -#include linux/of_platform.h /* A few bit definitions needed for fixups on some boards */ #define MPC85xx_L2CTL_L2E 0x8000 /* L2 enable */ -- 1.6.1.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] Fix stuck on cpm-i2c driver
Hi Michael, This happen because though the wait_event_interruptible_timeout takes the signals into account, the driver does not handle them. We propose to change the wait_event_interruptible_timeout with wait_event_timeout, leaving the signals to be handled in other points on the upper layers. Makes sense. I2C transactions better shouldn't be interrupted or data loss might happen. Signed-off-by: Bruno Morelli br...@evidence.eu.com Signed-off-by: Michael Trimarchi mich...@evidence.eu.com Acked-by: Jochen Friedrich joc...@scram.de Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
howto redirect serial console
I have a ppc405 based board with one serial interface which I use as a console. I would like to redirect or suppress, at run time, the console in order to use the serial port to control external serial devices. I have tried (busybox) setconsole program to redirect the console to /dev/null but it did not work. What would be the elegant way to redirect or suppress the serial console. M. -- View this message in context: http://www.nabble.com/howto-redirect-serial-console-tp24127643p24127643.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Delay on intialization ide subsystem(most likely)
On Thu, 11 Jun 2009 10:44:01 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Thu, 2009-06-11 at 01:57 +0400, Andrey Gusev wrote: I found configuration, where there isn't delay, but I need more time for testing. I switched to 2.6.30 and found that CONFIG_CC_OPTIMIZE_FOR_SIZE option takes influence on delay. If it is enabled, there is delay. I tried to shrink configuration, but I can't find a real module which responsible for this. There is a configuration file: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30 # Sat Jun 20 21:30:05 2009 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_TRACE=y CONFIG_RCU_FANOUT=32 # CONFIG_RCU_FANOUT_EXACT is not set CONFIG_TREE_RCU_TRACE=y # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_STRIP_ASM_SYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # CONFIG_FREEZER is not set # # Platform support # CONFIG_PPC_CHRP=y # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set # CONFIG_PQ2ADS is not set # CONFIG_PPC_83xx is
Badness on the Warp
[0.00] [ cut here ] [0.00] Badness at c033ebc4 [verbose debug info unavailable] [0.00] NIP: c033ebc4 LR: c033eb94 CTR: [0.00] REGS: c037fe70 TRAP: 0700 Not tainted (2.6.30-pika) [0.00] MSR: 00021000 ME,CE CR: 22022024 XER: [0.00] TASK = c035b440[0] 'swapper' THREAD: c037e000 [0.00] 6GPR00: 0001 c037ff20 c035b440 000c 0020 3fff [0.00] 6GPR08: c036faa4 c038 c07b7586 22002022 0ffa7f00 007fff99 [0.00] 6GPR16: 00400450 0080 007fff00 0ffa7a90 c0351d40 [0.00] 6GPR24: 1229 c0386b1c 000c 0020 3fff 000c [0.00] NIP [c033ebc4] alloc_arch_preferred_bootmem+0x48/0x74 [0.00] LR [c033eb94] alloc_arch_preferred_bootmem+0x18/0x74 [0.00] Call Trace: [0.00] [c037ff20] [c0350fa8] 0xc0350fa8 (unreliable) [0.00] [c037ff30] [c033ec40] ___alloc_bootmem_nopanic+0x50/0x108 [0.00] [c037ff60] [c033ed10] ___alloc_bootmem+0x18/0x50 [0.00] [c037ff70] [c033b3bc] uic_init_one+0x40/0x22c [0.00] [c037ff90] [c033b630] uic_init_tree+0x88/0x168 [0.00] [c037ffb0] [c0337378] init_IRQ+0x28/0x40 [0.00] [c037ffc0] [c0334664] start_kernel+0x15c/0x2a0 [0.00] [c037fff0] [c200] skpinv+0x190/0x1cc [0.00] Instruction dump: [0.00] 2f83 3860 409e0018 80010014 83e1000c 7c0803a6 38210010 4e800020 [0.00] 3d20c038 80095408 2160 7c0b0114 0f00 2f80 409e0018 3880 I wouldn't trust the backtrace too much since it seems to keep changing. It used to show __start_notes as the backtrace. This one is with the head of Linus' tree as of a few minutes ago. So I did a git bisect, and the problem goes back to June 11. The Warp boots and seems to run fine. So I didn't notice until looking at the logs for a different problem. I have since added a test to my regression tests to look for badness or oops in the logs. The git bisect returned: 871fa90791a6f83dd8e2e489feb9534a8c02088d is first bad commit That is it, no more info strange. git show 8714...088d gives: Merge: 7702667... 79f52b7... Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Jun 11 11:27:09 2009 -0700 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/shaggy/jfs-2.6: jfs: Add missing mutex_unlock call to error path missing unlock in jfs_quota_write() The Warp has jfs disabled, so I don't know why it would affect us, especially this realy in the boot! Anyway, I tried to revert the patch: $ git revert 871fa90791a6f83dd8e2e489feb9534a8c02088d fatal: Commit 871fa90791a6f83dd8e2e489feb9534a8c02088d is a merge but no -m option was given. So, anybody got an idea what is going on here? Or how I can revert the patch. I am not a git expert, so if I am doing this wrong, let me know. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness on the Warp
On Sat, 20 Jun 2009 22:56:45 +0200 Frans Pop elen...@planet.nl wrote: The fact that your bisect ended at a merge essentially means that it is invalid. As a merge does not introduce any actual change (unless it includes changes to resolve conflicts), it normally cannot be the cause of a regression. Makes sense I messed up somewhere. This is the commit that causes problems: Merge branch 'topic/slab/earlyboot' of git://git./linux/kernel/git/penberg/slab-2.6 * 'topic/slab/earlyboot' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6: vgacon: use slab allocator instead of the bootmem allocator irq: use kcalloc() instead of the bootmem allocator sched: use slab in cpupri_init() sched: use alloc_cpumask_var() instead of alloc_bootmem_cpumask_var() memcg: don't use bootmem allocator in setup code irq/cpumask: make memoryless node zero happy x86: remove some alloc_bootmem_cpumask_var calling vt: use kzalloc() instead of the bootmem allocator sched: use kzalloc() instead of the bootmem allocator init: introduce mm_init() vmalloc: use kzalloc() instead of alloc_bootmem() slab: setup allocators earlier in the boot sequence bootmem: fix slab fallback on numa bootmem: use slab if bootmem is no longer available Makes sense since it is very early in the boot I get the badness. Also, there is no mention of JFS in the above logs. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] perf_counter: powerpc: remove duplicated #include
Remove duplicated #include('s) in
arch/powerpc/kernel/mpc7450-pmu.c
arch/powerpc/kernel/ppc970-pmu.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
arch/powerpc/kernel/mpc7450-pmu.c |1 -
arch/powerpc/kernel/ppc970-pmu.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c
b/arch/powerpc/kernel/mpc7450-pmu.c
index 75ff47f..c244133 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -10,7 +10,6 @@
*/
#include linux/string.h
#include linux/perf_counter.h
-#include linux/string.h
#include asm/reg.h
#include asm/cputable.h
diff --git a/arch/powerpc/kernel/ppc970-pmu.c b/arch/powerpc/kernel/ppc970-pmu.c
index 6637c87..833097a 100644
--- a/arch/powerpc/kernel/ppc970-pmu.c
+++ b/arch/powerpc/kernel/ppc970-pmu.c
@@ -10,7 +10,6 @@
*/
#include linux/string.h
#include linux/perf_counter.h
-#include linux/string.h
#include asm/reg.h
#include asm/cputable.h
--
1.6.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness on the Warp
I found the source of the badness. The backtrace is correct: uic_init_one ___alloc_bootmem ___alloc_bootmem_nopanic alloc_arch_preferred_bootmem In alloc_arch_preferred_bootmem we have: if (WARN_ON_ONCE(slab_is_available())) return kzalloc(size, GFP_NOWAIT); Since the slab is available (it had better be or the call will return NULL), we get the badness message, then a successful return from kzalloc. I believe the author wants something like: if (slab_is_available()) return kzalloc(size, GFP_NOWAIT); else WARN_ON_ONCE(1); Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness on the Warp
The git bisect returned: 871fa90791a6f83dd8e2e489feb9534a8c02088d is first bad commit That is it, no more info strange. git show 8714...088d gives: Merge: 7702667... 79f52b7... Author: Linus Torvalds torva...@linux-foundation.org Date: Thu Jun 11 11:27:09 2009 -0700 The Warp has jfs disabled, so I don't know why it would affect us, especially this realy in the boot! The fact that your bisect ended at a merge essentially means that it is invalid. As a merge does not introduce any actual change (unless it includes changes to resolve conflicts), it normally cannot be the cause of a regression. So either you made a mistake when marking a commit as good or bad during the bisect, or the badness does not trigger reliably, resulting in you incorrectly marking a bad commit as good. My suggestion would be to run the bisection again from the start. Cheers, FJP ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness on the Warp
On Sunday 21 June 2009, Sean MacLennan wrote: On Sat, 20 Jun 2009 22:56:45 +0200 Frans Pop elen...@planet.nl wrote: The fact that your bisect ended at a merge essentially means that it is invalid. As a merge does not introduce any actual change (unless it includes changes to resolve conflicts), it normally cannot be the cause of a regression. Makes sense I messed up somewhere. This is the commit that causes problems: Merge branch 'topic/slab/earlyboot' of git://git./linux/kernel/git/penberg/slab-2.6 * 'topic/slab/earlyboot' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6: Hmmm. That's b640f042faa2, which is another merge... So you're still not there. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Badness on the Warp
On Sunday 21 June 2009, Sean MacLennan wrote: I found the source of the badness. The backtrace is correct: uic_init_one So that's in arch/powerpc/sysdev/uic.c. ___alloc_bootmem ___alloc_bootmem_nopanic alloc_arch_preferred_bootmem In alloc_arch_preferred_bootmem we have: if (WARN_ON_ONCE(slab_is_available())) return kzalloc(size, GFP_NOWAIT); Since the slab is available (it had better be or the call will return NULL), we get the badness message, then a successful return from kzalloc. I believe the author wants something like: if (slab_is_available()) return kzalloc(size, GFP_NOWAIT); else WARN_ON_ONCE(1); Well, I myself have no idea. It could also indicate a bug in the uic code. But let's CC some people responsible for this code. Pekka recently added this WARN that triggers in your case; David and Paul look to be the people most involved in the uic code. Start of the thread is at http://lkml.org/lkml/2009/6/20/165. Cheers, FJP ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Make bridge bug in linux 2.6.25b using Powerpc 405ep
hello all: I encountered a very strange question, I am using the AMCC Powerpc 405ep its Emac0 received a single phy intel 971, Emac1 received RTL8305SB, they shared Mdio, Mdc. 2.6.25.10 I use the kernel. The problem is to use the following command will be eth0, eth1 configured bridge .my borad will down often. Hope that helps! 2009:06:21 leowang Flowing command ifconfig eth0 down ifconfig eth1 down ifconfig eth0 0.0.0.0 up ifconfig eth1 0.0.0.0 up brctl addbr br0 brctl addif br0 eth0 brctl addif br0 eth1 ifconfig br0 192.168.80.250 up router ad default gw 192.168.80.1 brctl stp off brctl setfd br0 off kernel log [r...@kinggate ~]# dmesg Linux version 2.6.25.16 (r...@localhost.localdomain) (gcc version 4.3.3 (GCC) ) #283 Wed Jun 17 12:06:25 CST 2009 IBM Bubinga port (MontaVista Software, Inc. sou...@mvista.com) Entering add_active_range(0, 0, 32768) 0 entries of 256 used Zone PFN ranges: DMA 0 - 32768 Normal 32768 - 32768 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 - 32768 On node 0 totalpages: 32768 DMA zone: 256 pages used for memmap DMA zone: 0 pages reserved DMA zone: 32512 pages, LIFO batch:7 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/ram0 rw console=/dev/null PID hash table entries: 512 (order: 9, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 123932k available (2800k kernel code, 708k data, 164k init, 0k highmem) SLUB: Genslabs=12, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay loop... 332.59 BogoMIPS (lpj=1662976) Security Framework initialized Capability LSM initialized Mount-cache hash table entries: 512 net_namespace: 444 bytes NET: Registered protocol family 16 PCI: Probing PCI hardware NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered checking if image is initramfs...it isn't (no cpio magic); looks like an initrd Freeing initrd memory: 2178k freed JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler deadline registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled serial8250: ttyS0 at MMIO 0x0 (irq = 1) is a 16550A serial8250: ttyS1 at MMIO 0x0 (irq = 0) is a 16550A brd: module loaded loop: module loaded PPC 4xx OCP EMAC driver, version 3.54 mal0: initialized, 4 TX channels, 2 RX channels lipeng 10 eth0: emac0, MAC 00:10:5c:f0:90:d4 eth0: found Generic MII PHY (0x0a) lipeng 5 eth1: emac1, MAC 00:10:5c:f0:90:d5 eth1: found Generic MII PHY (0x05) Ethernet Channel Bonding Driver: v3.2.5 (March 21, 2008) bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details. PPP generic driver version 2.4.2 PPP Deflate Compression module registered PPP BSD Compression module registered PPP MPPE Compression module registered NET: Registered protocol family 24 IMQ driver loaded successfully. Hooking IMQ after NAT on PREROUTING. Hooking IMQ before NAT on POSTROUTING. 8139too Fast Ethernet driver 0.9.28 eth2: RealTek RTL8139 at 0xfe00, 00:e0:4c:42:0a:55, IRQ 28 eth2: Identified 8139 chip type 'RTL-8100B/8139D' physmap platform flash device: 0200 at fd00 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank physmap-flash.0: Found 1 x16 devices at 0x100 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled erase region 0: offset=0x0,size=0x2,blocks=128 erase region 1: offset=0x100,size=0x2,blocks=128 Using physmap partition information Creating 4 MTD partitions on physmap-flash.0: 0x-0x0040 : zImage 0x0040-0x0042 : hidden 0x0042-0x01d0 : application 0x01d0-0x0200 : config i2c /dev entries driver IBM IIC driver v2.1 ibm-iic0: using standard (100 kHz) mode GACT probability on u32 classifier Performance counters on Actions configured Netfilter messages via NETLINK v0.30.
Re: Badness on the Warp
On Sun, 21 Jun 2009, Frans Pop wrote: On Sunday 21 June 2009, Sean MacLennan wrote: On Sat, 20 Jun 2009 22:56:45 +0200 Frans Pop elen...@planet.nl wrote: The fact that your bisect ended at a merge essentially means that it is invalid. As a merge does not introduce any actual change (unless it includes changes to resolve conflicts), it normally cannot be the cause of a regression. Makes sense I messed up somewhere. This is the commit that causes problems: Merge branch 'topic/slab/earlyboot' of git://git./linux/kernel/git/penberg/slab-2.6 * 'topic/slab/earlyboot' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6: Hmmm. That's b640f042faa2, which is another merge... So you're still not there. It's not implausible that this is, in fact, the first bad commit. The early slab topic could easily have been correct for everything in the tree when it was written, but cause problems with some other patch developed simultaneously. It's worth rechecking that both 871fa90 and b8ec757 are good and b640f042faa2 is bad, since it's also pretty likely that the test isn't reproducing perfectly. -Daniel *This .sig left intentionally blank* ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
