Re: [POWERPC] XilinxFB: removed unused #include version.h
On Fri, Aug 22, 2008 at 11:56 PM, Huang Weiyi [EMAIL PROTECTED] wrote: The driver(s) below do not use LINUX_VERSION_CODE nor KERNEL_VERSION. drivers/video/xilinxfb.c This patch removes the said #include version.h. Signed-off-by: Huang Weiyi [EMAIL PROTECTED] Thanks, I'll pick this one up for .28 g. diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c index 7b3a842..5da3d24 100644 --- a/drivers/video/xilinxfb.c +++ b/drivers/video/xilinxfb.c @@ -24,7 +24,6 @@ #include linux/device.h #include linux/module.h #include linux/kernel.h -#include linux/version.h #include linux/errno.h #include linux/string.h #include linux/mm.h -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/mpc5200: remove unused #include version.h
On Fri, Aug 22, 2008 at 11:56 PM, Huang Weiyi [EMAIL PROTECTED] wrote: The file(s) below do not use LINUX_VERSION_CODE nor KERNEL_VERSION. arch/powerpc/sysdev/bestcomm/gen_bd.c This patch removes the said #include version.h. Signed-off-by: Huang Weiyi [EMAIL PROTECTED] Thanks, I'll queue this for .28 g. diff --git a/arch/powerpc/sysdev/bestcomm/gen_bd.c b/arch/powerpc/sysdev/bestcomm/gen_bd.c index a3a134c..e0a53e3 100644 --- a/arch/powerpc/sysdev/bestcomm/gen_bd.c +++ b/arch/powerpc/sysdev/bestcomm/gen_bd.c @@ -11,7 +11,6 @@ * */ -#include linux/version.h #include linux/module.h #include linux/kernel.h #include linux/string.h -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Why does one stw fail with address translation disabled in PPC405EP?
在 2008-08-22五的 14:42 -0400，Josh Boyer写道： On Fri, Aug 22, 2008 at 08:27:15PM +0200, Zhou Rui wrote: Hi, all: I think I meet an odd problem with PPC405EP (PPChameleonEVB Board). What kernel version are you using? linux-2.6.19.2 from ELDK4.1 I am running a kernel module which will execute a user space application. The entry point of the application is 0x10a0. At the That should be the first clue that you are doing it wrong. Don't do stuff like that in modules... Oh, but our project needs a function like that ... moment when the processor tries to execute the application, 0x10a0 is not in TLB (this can be seen from BDI by printing out TLB entries), so DTLBMiss is called automatically and then finish_tlb_load. However, InstructionAccess is followed and the problem arises here. InstructionAccess starts from 0x400, and after instruction 0xc434 InstructionAccess+52: stw r12,64(r11), machine check occurs. This instruction will store the value of r12, which is 0x0 at this moment, to address 0x03072de0. I am puzzled why this action leads to machine check. Is it illegal to store 0x0 in a memory address? Or is there some other cause of the machine check here? I have no idea if you're using physical or virtual addresses here, so there isn't much we can do to help you. It is physical address at this moment. Address translation is disabled automatically (MSR[IR, DR] = [0, 0]) because of TLB Miss Exception and Instrunction Storage Exception. Do you have enough DRAM to cover that? Some of those boards only come with 32MiB of DRAM. My board only has 32MB DRAM. Do you mean 32MB is not enough for that? The same codes can run well in a PPC440EP (Yosemite Board) which owns 256MB DRAM. At the beginning of my work, I thought memory size may be the cause of failure. But I did not know how to demonstrate it. So if the limitation of 32MB DRAM leads to the failure, are there any methods for the codes to solve it? Thank you very much for your reply! Best Wishes Zhou Rui 2008-08-23 josh __ �Ͽ�ע���Ż�? http://cn.mail.yahoo.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: checkpatch nits ...
On Saturday 23 August 2008, Kevin Diggs wrote: WARNING: externs should be avoided in .c files #1137: FILE: powerpc/kernel/cpu/pll_if.c:369: + __asm__ __volatile__ ( ??? I don't know what this is? The entire block is: __asm__ __volatile__ ( addi %0,%3,-1\n andc %1,%3,%0\n cntlzw %1,%1\n subfic %1,%1,31\n cntlzw %0,%2\n: =r(cntlz), =r(cnttz): r(tmp), b(cnttz) ); It's a bug in checkpatch, your code is correct (although I would write asm volatile, not __asm__ __volatile__, and add \t after each \n). Can you explain why you need that inline assembly? All you do in there are arithmetic operations, so you should be able to express that using C, or at least using the helpers we already have. Checkpatch thinks that what you wrote is a declaration for a function named __volatile__ returning a variable of type __asm__, and complains that this declaration belongs into a header file. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Random crashes with 2.6.27-rc3 on PPC
I am seeing random kernel and userland application crashes on a Powerbook running a 2.6.27-rc3 based kernel (wireless-testing.git). The crashes did recently appear. It might be the case that they were introduced with the merge of 2.6.27-rc1 into wireless-testing. I'm not sure on that one, however. Just a guess. I still need to do more testing (also on vanilla upstream kernels). The crashes are completely random and they look like bad hardware. However I cannot reproduce on 2.6.25.9 (That's a kernel I still had installed, so I tried that one). So it most likely is _not_ caused by faulty hardware. The crashes are hard to reproduce, and happen about every 20 minutes when compiling a kernel tree. (gcc segfaults). Sometimes the kernel oopses in random places with pointer dereference faults. Is this a known issue? I'm going to bisect this one, but it will take a lot of time, as reproducing takes about 20 minutes. So that's about an hour for one test round. The kernel configuration is the following: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27-rc3 # Fri Aug 22 18:57:55 2008 # # 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_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 is not set CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_PPC_MERGE=y 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_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y # CONFIG_PPC_UDBG_16550 is not set # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_32=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-wltest # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=19 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y 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_HAVE_DMA_ATTRS is not set # CONFIG_USE_GENERIC_SMP_HELPERS is not set CONFIG_HAVE_CLK=y CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF 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 #
Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
On Aug 22, 2008, at 12:11 PM, Scott Wood wrote: On Fri, Aug 22, 2008 at 12:26:01PM +0100, Martyn Welch wrote: drop device_type. Ah - _all_ device_type! Um, not all - just the ones where the name of the block matches the device type(?) All except cpu and memory. I think network is ok. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc: Board support for GE Fanuc SBC610
On Aug 22, 2008, at 6:11 AM, Martyn Welch wrote:
+static void __init
+gef_sbc610_init_irq(void)
+{
+ struct mpic *mpic1;
+ struct device_node *np;
+ struct resource res;
+
+ /* Determine PIC address. */
+ np = of_find_node_by_type(NULL, open-pic);
+ if (np == NULL)
+ return;
+ of_address_to_resource(np, 0, res);
+
+ mpic1 = mpic_alloc(np, res.start,
+ MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN,
+ 0, 256, mpic);
+ of_node_put(np);
+ BUG_ON(mpic1 == NULL);
+
+ mpic_init(mpic1);
+}
any reason not to use mpc86xx_init_irq() in pic.c?
Yes, the afore-mentioned chained interrupt controller that is rather
specific to our boards that I will/have added to this function in a
patch that I shall post soon.
Hmm, does that chained interrupt-controller really effect this bit of
code any? I'd expect you'd be able to still call mpc86xx_init_irq()
and than in your board file hook up the cascade (like how we hookup
the i8259 in pic.c).
If not here are a few comments:
* Use *mpic instead mpic1
* Add MPIC_BROKEN_FRR_NIRQS to the flags
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Random crashes with 2.6.27-rc3 on PPC
Hi, Michael Buesch [EMAIL PROTECTED] writes: I am seeing random kernel and userland application crashes on a Powerbook running a 2.6.27-rc3 based kernel (wireless-testing.git). The crashes did recently appear. It might be the case that they were introduced with the merge of 2.6.27-rc1 into wireless-testing. I'm not sure on that one, however. Just a guess. I still need to do more testing (also on vanilla upstream kernels). The crashes are completely random and they look like bad hardware. However I cannot reproduce on 2.6.25.9 (That's a kernel I still had installed, so I tried that one). So it most likely is _not_ caused by faulty hardware. The crashes are hard to reproduce, and happen about every 20 minutes when compiling a kernel tree. (gcc segfaults). Sometimes the kernel oopses in random places with pointer dereference faults. Exact same thing here on a PB 12 (not a ppc64, but ppc32). It was not on a wireless-testing.git but on a recent net-2.6 or 2.6.27-rc3 (I do not remember precisely). I thought it was a thermal issue and did not spend time on it because of another regression I bisected (sysctl+IPv6) that version useless for me. Is this a known issue? Now it is ;-) I'm going to bisect this one, but it will take a lot of time, as reproducing takes about 20 minutes. So that's about an hour for one test round. Thanks for doing that. Cheers, a+ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
compile testing: cpufreq stats driver?
Hi, When I tried building my cpufreq driver into the kernel, the cpufreq stats driver quit working? Anyone know if I screwed something up? Or is this normal (2.6.26)? Also, I thought, apparently incorrectly, That module parameters became boot parameters when the module was built in to the kernel? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Why does one stw fail with address translation disabled in PPC405EP?
在 2008-08-22五的 14:42 -0400，Josh Boyer写道： On Fri, Aug 22, 2008 at 08:27:15PM +0200, Zhou Rui wrote: Hi, all: I think I meet an odd problem with PPC405EP (PPChameleonEVB Board). What kernel version are you using? I am running a kernel module which will execute a user space application. The entry point of the application is 0x10a0. At the That should be the first clue that you are doing it wrong. Don't do stuff like that in modules... moment when the processor tries to execute the application, 0x10a0 is not in TLB (this can be seen from BDI by printing out TLB entries), so DTLBMiss is called automatically and then finish_tlb_load. However, InstructionAccess is followed and the problem arises here. InstructionAccess starts from 0x400, and after instruction 0xc434 InstructionAccess+52: stw r12,64(r11), machine check occurs. This instruction will store the value of r12, which is 0x0 at this moment, to address 0x03072de0. I am puzzled why this action leads to machine check. Is it illegal to store 0x0 in a memory address? Or is there some other cause of the machine check here? I have no idea if you're using physical or virtual addresses here, so there isn't much we can do to help you. Do you have enough DRAM to cover that? Some of those boards only come with 32MiB of DRAM. Oh, I think I just now realized that for 32MB DRAM, the physical address should be between 0x0 and 0x1FF, but the address 0x03072da0 was out of this range ... To enlarge the memory size is one solution but I do not think it is feasible for my board. Is there any solution from software side? I hope there is. Thank you very much!!! Best Wishes Zhou Rui 2008-08-23 josh __ �Ͽ�ע���Ż�? http://cn.mail.yahoo.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Why does one stw fail with address translation disabled in PPC405EP?
On Sat, 2008-08-23 at 10:26 +0200, Zhou Rui wrote: My board only has 32MB DRAM. Do you mean 32MB is not enough for that? The same codes can run well in a PPC440EP (Yosemite Board) which owns 256MB DRAM. At the beginning of my work, I thought memory size may be the cause of failure. But I did not know how to demonstrate it. So if the limitation of 32MB DRAM leads to the failure, are there any methods for the codes to solve it? Well, it looks like the kernel is trying to access memory beyond 32M, which would mean that the problem is that your kernel port or your bootloader somewhat thinks there is more memory than there really is. You need to look there... whatever passes the amount of memory to the kernel at boot needs to be fixed. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Random crashes with 2.6.27-rc3 on PPC
On Sat, 2008-08-23 at 16:10 +0200, Michael Buesch wrote: I am seeing random kernel and userland application crashes on a Powerbook running a 2.6.27-rc3 based kernel (wireless-testing.git). The crashes did recently appear. It might be the case that they were introduced with the merge of 2.6.27-rc1 into wireless-testing. I'm not sure on that one, however. Just a guess. I still need to do more testing (also on vanilla upstream kernels). The crashes are completely random and they look like bad hardware. However I cannot reproduce on 2.6.25.9 (That's a kernel I still had installed, so I tried that one). So it most likely is _not_ caused by faulty hardware. The crashes are hard to reproduce, and happen about every 20 minutes when compiling a kernel tree. (gcc segfaults). Sometimes the kernel oopses in random places with pointer dereference faults. Is this a known issue? I'm going to bisect this one, but it will take a lot of time, as reproducing takes about 20 minutes. So that's about an hour for one test round. The kernel configuration is the following: Random guess: CONFIG_FRAME_POINTER=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y Note sure what those together do, check if you have any file compiled with -fno-omit-frame-pointer and if you do, try to change things so that you don't ... we found some miscompiles when that is set, exposed by FTRACE typically (which you don't have enabled) but possibly by other things. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
