[PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
Just whitelist these extra compiler generated symbols.
Fixes these errors:
Error: External symbol '_restgpr0_14' referenced from prom_init.c
Error: External symbol '_restgpr0_20' referenced from prom_init.c
Error: External symbol '_restgpr0_22' referenced from prom_init.c
Error: External symbol '_restgpr0_24' referenced from prom_init.c
Error: External symbol '_restgpr0_25' referenced from prom_init.c
Error: External symbol '_restgpr0_26' referenced from prom_init.c
Error: External symbol '_restgpr0_27' referenced from prom_init.c
Error: External symbol '_restgpr0_28' referenced from prom_init.c
Error: External symbol '_restgpr0_29' referenced from prom_init.c
Error: External symbol '_restgpr0_31' referenced from prom_init.c
Error: External symbol '_savegpr0_14' referenced from prom_init.c
Error: External symbol '_savegpr0_20' referenced from prom_init.c
Error: External symbol '_savegpr0_22' referenced from prom_init.c
Error: External symbol '_savegpr0_24' referenced from prom_init.c
Error: External symbol '_savegpr0_25' referenced from prom_init.c
Error: External symbol '_savegpr0_26' referenced from prom_init.c
Error: External symbol '_savegpr0_27' referenced from prom_init.c
Error: External symbol '_savegpr0_28' referenced from prom_init.c
Error: External symbol '_savegpr0_29' referenced from prom_init.c
Error: External symbol '_savegpr0_31' referenced from prom_init.c
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
---
arch/powerpc/kernel/prom_init_check.sh |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init_check.sh
b/arch/powerpc/kernel/prom_init_check.sh
index 1ac136b..9f82f49 100644
--- a/arch/powerpc/kernel/prom_init_check.sh
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -52,12 +52,18 @@ do
if [ ${UNDEF:0:9} = _restgpr_ ]; then
OK=1
fi
+ if [ ${UNDEF:0:10} = _restgpr0_ ]; then
+ OK=1
+ fi
if [ ${UNDEF:0:11} = _rest32gpr_ ]; then
OK=1
fi
if [ ${UNDEF:0:9} = _savegpr_ ]; then
OK=1
fi
+ if [ ${UNDEF:0:10} = _savegpr0_ ]; then
+ OK=1
+ fi
if [ ${UNDEF:0:11} = _save32gpr_ ]; then
OK=1
fi
--
1.7.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: fix module building for gcc 4.5 and 64 bit
Gcc 4.5 is now generating out of line register save and restore in the function prefix and postfix when we use -Os. Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/Makefile|4 +- arch/powerpc/lib/Makefile|4 +- arch/powerpc/lib/crtsavres.S | 129 ++ scripts/mod/modpost.c|5 ++ 4 files changed, 138 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 42dcd3f..77cfe7a 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -92,10 +92,10 @@ endif else KBUILD_CFLAGS += $(call cc-option,-mtune=power4) endif -else -LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o endif +LDFLAGS_MODULE += arch/powerpc/lib/crtsavres.o + ifeq ($(CONFIG_TUNE_CELL),y) KBUILD_CFLAGS += $(call cc-option,-mtune=cell) endif diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index 3040dac..111da1c 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -12,8 +12,8 @@ CFLAGS_REMOVE_code-patching.o = -pg CFLAGS_REMOVE_feature-fixups.o = -pg obj-y := string.o alloc.o \ - checksum_$(CONFIG_WORD_SIZE).o -obj-$(CONFIG_PPC32)+= div64.o copy_32.o crtsavres.o + checksum_$(CONFIG_WORD_SIZE).o crtsavres.o +obj-$(CONFIG_PPC32)+= div64.o copy_32.o obj-$(CONFIG_HAS_IOMEM)+= devres.o obj-$(CONFIG_PPC64)+= copypage_64.o copyuser_64.o \ diff --git a/arch/powerpc/lib/crtsavres.S b/arch/powerpc/lib/crtsavres.S index 70a9cd8..1c893f0 100644 --- a/arch/powerpc/lib/crtsavres.S +++ b/arch/powerpc/lib/crtsavres.S @@ -6,6 +6,7 @@ * Written By Michael Meissner * * Based on gcc/config/rs6000/crtsavres.asm from gcc + * 64 bit additions from reading the PPC elf64abi document. * * 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 @@ -44,6 +45,8 @@ #ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE +#ifndef CONFIG_PPC64 + /* Routines for saving integer registers, called by the compiler. */ /* Called with r11 pointing to the stack header word of the caller of the */ /* function, just beyond the end of the integer save area. */ @@ -226,4 +229,130 @@ _GLOBAL(_rest32gpr_31_x) mtlr0 mr 1,11 blr + +#else /* CONFIG_PPC64 */ + +.globl _savegpr0_14 +_savegpr0_14: + std r14,-144(r1) +.globl _savegpr0_15 +_savegpr0_15: + std r15,-136(r1) +.globl _savegpr0_16 +_savegpr0_16: + std r16,-128(r1) +.globl _savegpr0_17 +_savegpr0_17: + std r17,-120(r1) +.globl _savegpr0_18 +_savegpr0_18: + std r18,-112(r1) +.globl _savegpr0_19 +_savegpr0_19: + std r19,-104(r1) +.globl _savegpr0_20 +_savegpr0_20: + std r20,-96(r1) +.globl _savegpr0_21 +_savegpr0_21: + std r21,-88(r1) +.globl _savegpr0_22 +_savegpr0_22: + std r22,-80(r1) +.globl _savegpr0_23 +_savegpr0_23: + std r23,-72(r1) +.globl _savegpr0_24 +_savegpr0_24: + std r24,-64(r1) +.globl _savegpr0_25 +_savegpr0_25: + std r25,-56(r1) +.globl _savegpr0_26 +_savegpr0_26: + std r26,-48(r1) +.globl _savegpr0_27 +_savegpr0_27: + std r27,-40(r1) +.globl _savegpr0_28 +_savegpr0_28: + std r28,-32(r1) +.globl _savegpr0_29 +_savegpr0_29: + std r29,-24(r1) +.globl _savegpr0_30 +_savegpr0_30: + std r30,-16(r1) +.globl _savegpr0_31 +_savegpr0_31: + std r31,-8(r1) + std r0,16(r1) + blr + +.globl _restgpr0_14 +_restgpr0_14: + ld r14,-144(r1) +.globl _restgpr0_15 +_restgpr0_15: + ld r15,-136(r1) +.globl _restgpr0_16 +_restgpr0_16: + ld r16,-128(r1) +.globl _restgpr0_17 +_restgpr0_17: + ld r17,-120(r1) +.globl _restgpr0_18 +_restgpr0_18: + ld r18,-112(r1) +.globl _restgpr0_19 +_restgpr0_19: + ld r19,-104(r1) +.globl _restgpr0_20 +_restgpr0_20: + ld r20,-96(r1) +.globl _restgpr0_21 +_restgpr0_21: + ld r21,-88(r1) +.globl _restgpr0_22 +_restgpr0_22: + ld r22,-80(r1) +.globl _restgpr0_23 +_restgpr0_23: + ld r23,-72(r1) +.globl _restgpr0_24 +_restgpr0_24: + ld r24,-64(r1) +.globl _restgpr0_25 +_restgpr0_25: + ld r25,-56(r1) +.globl _restgpr0_26 +_restgpr0_26: + ld r26,-48(r1) +.globl _restgpr0_27 +_restgpr0_27: + ld r27,-40(r1) +.globl _restgpr0_28 +_restgpr0_28: + ld r28,-32(r1) +.globl _restgpr0_29 +_restgpr0_29: + ld r0,16(r1) + ld r29,-24(r1) + mtlrr0 + ld r30,-16(r1) + ld r31,-8(r1) + blr + +.globl _restgpr0_30 +_restgpr0_30: + ld r30,-16(r1) +.globl _restgpr0_31 +_restgpr0_31: + ld r0,16(r1) + ld r31,-8(r1) + mtlrr0 + blr + +#endif /* CONFIG_PPC64 */ + #endif diff --git
Re: machine check in kernel for a mpc870 board
Hi Scott, Bus Fault @ 0x00404c40, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 07d1cb80 Unknown values in msr NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 0001 MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 Can you look up the source line/instruction corresponding to 0x404c40, in the wrapper ELF file? I'm not sure how to look up it. But I used the BDI to dump the instructions in which you may find some clue? These should be kernel code, right? Maybe the gdb can help to de-assemble them? BDImd 0x404c00 0x20 00404c00 : 0x4800317d 1207972221 H.1} 00404c04 : 0x80010014 -2147418092 00404c08 : 0xbbc10008 -1144979448 00404c0c : 0x7c0803a6 208096 |... 00404c10 : 0x38210010941686800 8!.. 00404c14 : 0x4e800020 1317011488 N.. 00404c18 : 0x9421fff0 -1809711120 .!.. 00404c1c : 0x7c0802a6 2080899750 |... 00404c20 : 0x429f0005 1117716485 B... 00404c24 : 0xbfc10008 -1077870584 00404c28 : 0x7fc802a6 2143814310 00404c2c : 0x90010014 -1878982636 00404c30 : 0x3fde0001 1071513601 ?... 00404c34 : 0x3bdedd98 1004461464 ;... 00404c38 : 0x813e8000 -2126610432 ... 00404c3c : 0x8149 -2125922304 .I.. 00404c40 : 0xa00a -1609957376 00404c44 : 0x0c00201326592 00404c48 : 0x4c00012c 1275068716 L.., 00404c4c : 0x70090001 1879638017 p... 00404c50 : 0x4082fff0 1082327024 @... 00404c54 : 0x817e8000 -2122416128 .~.. 00404c58 : 0x5469402e 1416183854 t...@. Thanks a lot, -Shawn. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull my perf.git tree support
Ben, When you set up your next branch for commits to go in 2.6.36-rc1, please do a pull from: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git master to get a series of commits that add support for hw_breakpoint events on 64-bit POWER server processors in the perf_event subsystem. This consists of a commit from me that adds support for most integer instructions to the emulate_step() function, a series from K. Prasad that add the ppc64-specific hw_breakpoint code, and some small commits from me that fix a few bugs that I found in testing. There is one commit in there from K. Prasad that modifies the generic hw_breakpoint code to add the ability to have an arch-specific unregister hook for hw_breakpoints. It has been acked by Frederic Weisbecker. Thanks, Paul. The following changes since commit 7e27d6e778cd87b6f2415515d7127eba53fe5d02: Linux 2.6.35-rc3 (2010-06-11 19:14:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulus/perf.git master K.Prasad (5): hw_breakpoints: Allow arch-specific cleanup before breakpoint unregistration powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server processors powerpc, hw_breakpoint: Handle concurrent alignment interrupts powerpc, hw_breakpoint: Enable hw-breakpoints while handling intervening signals powerpc, hw_breakpoint: Discard extraneous interrupt due to accesses outside symbol length Paul Mackerras (4): powerpc: Emulate most Book I instructions in emulate_step() powerpc, hw_breakpoint: Fix off-by-one in checking access address powerpc, hw_breakpoint: Cooperate better with other single-steppers powerpc, hw_breakpoint: Tell generic code we have no instruction breakpoints arch/powerpc/Kconfig |1 + arch/powerpc/include/asm/asm-compat.h|2 + arch/powerpc/include/asm/cputable.h |4 + arch/powerpc/include/asm/hw_breakpoint.h | 74 ++ arch/powerpc/include/asm/ppc-opcode.h|7 + arch/powerpc/include/asm/processor.h |8 + arch/powerpc/kernel/Makefile |1 + arch/powerpc/kernel/exceptions-64s.S |1 + arch/powerpc/kernel/hw_breakpoint.c | 364 +++ arch/powerpc/kernel/machine_kexec_64.c |3 + arch/powerpc/kernel/process.c| 14 + arch/powerpc/kernel/ptrace.c | 64 ++ arch/powerpc/kernel/signal.c |3 + arch/powerpc/kernel/traps.c |8 +- arch/powerpc/lib/Makefile|5 +- arch/powerpc/lib/ldstfp.S| 375 arch/powerpc/lib/sstep.c | 1514 +- kernel/hw_breakpoint.c | 12 + 18 files changed, 2408 insertions(+), 52 deletions(-) create mode 100644 arch/powerpc/include/asm/hw_breakpoint.h create mode 100644 arch/powerpc/kernel/hw_breakpoint.c create mode 100644 arch/powerpc/lib/ldstfp.S ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
On Tue, Jun 29, 2010 at 04:13:24PM -0700, David Daney wrote: On 06/29/2010 03:41 PM, David Brownell wrote: Good -- MUSB won't be the only one. ;) Could you mention a few Linux-enabled chips which include this controller? I can. Some members of the Octeon family: arch/mips/cavium-octeon Plus ECONA CNS3xxx (arch/arm/mach-cns3xxx). -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Hi Fushen, Hi Mark, On Tuesday 29 June 2010 23:26:54 Fushen Chen wrote: The DWC OTG driver module provides the initialization and cleanup entry points for the DWC OTG USB driver. Signed-off-by: Fushen Chen fc...@apm.com Signed-off-by: Mark Miesfeld mmiesf...@apm.com I tried to compare this driver with the version that's currently available in the linux-2.6-denx repository. But the differences are quite big. Could you please list the history of this DWC driver? Things like: - Which Synopsis version is it based upon? - What changes/enhancements/fixups where made from APM? - How was this driver tested (USB host and device mode)? As Wolfgang already pointed out, the driver in our git repository has undergone multiple changes/fixes. Did you take a look at them and try to integrate them? Thanks. Cheers, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Hello.
Fushen Chen wrote:
The DWC OTG driver module provides the initialization and cleanup
entry points for the DWC OTG USB driver.
Signed-off-by: Fushen Chen fc...@apm.com
Signed-off-by: Mark Miesfeld mmiesf...@apm.com
[...]
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index 083e68e..1a141b8 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -394,5 +394,20 @@
0x0 0x0 0x0 0x3 UIC2 0xd 0x4 /* swizzled int C
*/
0x0 0x0 0x0 0x4 UIC2 0xe 0x4 /* swizzled int D
*/;
};
+
+ USBOTG0: usb...@ef6c {
+ compatible = amcc,dwc-otg;
+ reg = 0xef6c 0x1;
+ interrupt-parent = USBOTG0;
+ interrupts = 0x0 0x1 0x2;
+ #interrupt-cells = 0x1;
+ #address-cells = 0x0;
+ #size-cells = 0x0;
+ interrupt-map =
+ 0x0 UIC2 0x1e 0x4 /* USB-OTG */
+ 0x1 UIC1 0x1a 0x8 /* HIGH-POWER */
+ 0x2 UIC0 0xc 0x4 /* DMA */ ;
+ interrupt-map-mask = 0x;
+ };
};
};
Please put this file in a separate patch and push thru the PowerPC tree.
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
On 06/30/2010 12:41 AM, David Brownell wrote: Could you mention a few Linux-enabled chips which include this controller? Ralink APSoC chips (rt2880, rt305x) do: http://svn.dd-wrt.com:8000/dd-wrt/browser/src/linux/rt2880/linux-2.6.23/drivers/usb/dwc_otg/Kconfig Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055 emlix - your embedded linux partner ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Oops while running fs_racer test on a POWER6 box against latest git
While running fs_racer test from LTP on a POWER6 box against latest git(2.6.35-rc3-git4 - commitid 984bc9601f64fd) came across the following warning followed by multiple oops. [ cut here ] Badness at kernel/mutex-debug.c:64 NIP: c00be9e8 LR: c00be9cc CTR: REGS: c0010be8f6f0 TRAP: 0700 Not tainted (2.6.35-rc3-git4-autotest) MSR: 80029032EE,ME,CE,IR,DRCR: 24224422 XER: 0012 TASK = c0010727cf00[8211] 'fs_racer_file_c' THREAD: c0010be8bb50 CPU: 2 GPR00: c0010be8f970 c0d3d798 0001 GPR04: c0010be8fa70 c0010be8c000 c0010727d9f8 GPR08: c43042f0 c16534e8 017a c0c29a1c GPR12: 28228424 cf600500 c0010be8fc40 2000 GPR16: f000 c00109c73000 c0010be8fc30 00010442 GPR20: 01b6 c0010dd12250 GPR24: c017c08c c0010727cf00 c0010dd12278 c0010dd12210 GPR28: 0001 c0010be8c000 c0ca2008 c0010be8fa70 NIP [c00be9e8] .mutex_remove_waiter+0xa4/0x130 LR [c00be9cc] .mutex_remove_waiter+0x88/0x130 Call Trace: [c0010be8f970] [c0010be8fa00] 0xc0010be8fa00 (unreliable) [c0010be8fa00] [c064a9f0] .mutex_lock_nested+0x384/0x430 Instruction dump: e81f0010 e93d 7fa04800 41fe0028 482e96e5 6000 2fa3 419e0018 e93e8008 8009 2f80 409e00080fe0 e93e8000 8009 2f80 Unable to handle kernel paging request for unknown fault Faulting instruction address: 0xc008d0f4 Oops: Kernel access of bad area, sig: 7 [#1] SMP NR_CPUS=1024 NUMA Unrecoverable FP Unavailable Exception 800 at c0648ed4 pSeries last sysfs file: /sys/devices/system/cpu/cpu19/cache/index1/shared_cpu_map Modules linked in: ipv6 fuse loop dm_mod sr_mod cdrom ibmveth sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod NIP: c008d0f4 LR: c008d0d0 CTR: REGS: c0010978f900 TRAP: 0600 Tainted: GW (2.6.35-rc3-git4-autotest) MSR: 80009032 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 EE,ME,IR,DRCR: 24022442 XER: 0012 DAR: c0648f54, DSISR: 4001 TASK = c001096e4900[7353] 'fs_racer_file_s' THREAD: c0010978c000 CPU: 10 GPR00: 4000 c0010978fb80 c0d3d798 0001 GPR04: c083539e c1610228 c54c6880 GPR08: 06a5 c0648f54 0007 049b GPR12: cf601900 GPR16: 4b7dc520 c0010978fea0 GPR20: 0fffcca7e7a0 0fffcca7e7a0 0fffabf7dfd0 0fffabf7dfd0 GPR24: 01200011 c0e1c0a8 c0648ed4 GPR28: c001096e4900 c0ca0458 c0010725d400 NIP [c008d0f4] .copy_process+0x310/0xf40 LR [c008d0d0] .copy_process+0x2ec/0xf40 Call Trace: [c0010978fb80] [c008d0d0] .copy_process+0x2ec/0xf40 (unreliable) [c0010978fc80] [c008deb4] .do_fork+0x190/0x3cc [c0010978fdc0] [c0011ef4] .sys_clone+0x58/0x70 [c0010978fe30] [c00087f0] .ppc_clone+0x8/0xc Instruction dump: 419e0010 7fe3fb78 480774cd 6000 801f0014 e93f0008 7800b842 39290080 78004800 6042 901f0014 380040007d6048a8 7d6b0078 7d6049ad 40c2fff4 Kernel version 2.6.34-rc3-git3 works fine. Thanks Divya Using 007dfade bytes for initrd buffer Please wait, loading kernel... Allocated 0180 bytes for kernel @ 01e0 Elf64 kernel loaded... Loading ramdisk... ramdisk loaded 007dfade @ 0360 OF stdout device is: /vdevice/v...@3000 Preparing to boot Linux version 2.6.35-rc3-git4-autotest (r...@p55alp2) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Wed Jun 30 08:47:11 IST 2010 Max number of cores passed to firmware: 0x0200 Calling ibm,client-architecture-support... not implemented command line: root=/dev/sda5 IDENT=1277868480 memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 03de alloc_top: 1000 alloc_top_hi : 0001f000 rmo_top : 1000 ram_top : 0001f000 instantiating rtas at 0x0f6a... done boot cpu hw idx starting cpu hw idx 0002... done starting cpu hw idx 0004... done starting cpu hw idx 0006... done starting cpu hw idx 0008... done starting cpu hw idx 000a... done starting cpu
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
Dear Rupjyoti Sarmah, In message 201006241327.o5odry6m032...@amcc.com you wrote: This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. Signed-off-by: Rupjyoti Sarmah rsar...@appliedmicro.com Signed-off-by: Mark Miesfeld mmiesf...@appliedmicro.com Signed-off-by: Prodyut Hazarika phazar...@appliedmicro.com --- This patch incorporates the changes advised in the mailing list. The device tree changes were submitted as a seperate patch. Which kernel is this patch supposed to be applied to? Using current mainline (v2.6.35-rc3-262-g984bc96) the patch applies without problems, but when I enable it in the kernel configuration I get this: drivers/ata/sata_dwc_460ex.c:43:1: warning: DRV_NAME redefined In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: DRV_VERSION redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read': drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write': drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr': drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_isr': drivers/ata/sata_dwc_460ex.c:953: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c:957: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c:991: error: implicit declaration of function 'ata_sff_hsm_move' drivers/ata/sata_dwc_460ex.c:1030: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1213: warning: 'struct ata_ioports' declared inside parameter list drivers/ata/sata_dwc_460ex.c:1213: warning: its scope is only this definition or declaration, which is probably not what you want drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_setup_port': drivers/ata/sata_dwc_460ex.c:1215: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1216: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1218: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1219: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1221: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1223: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1224: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1225: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1227: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1228: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1229: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1231: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1232: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_port_start': drivers/ata/sata_dwc_460ex.c:1273: error: 'struct ata_port' has no member named 'bmdma_prd' drivers/ata/sata_dwc_460ex.c:1274: error: 'struct ata_port' has no member named 'bmdma_prd_dma' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag': drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast drivers/ata/sata_dwc_460ex.c:1369: error: implicit declaration of function 'ata_sff_exec_command' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue': drivers/ata/sata_dwc_460ex.c:1512: error: 'struct ata_port_operations' has no member named 'sff_tf_load' drivers/ata/sata_dwc_460ex.c:1516: error: implicit declaration of function 'ata_sff_qc_issue' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_handler': drivers/ata/sata_dwc_460ex.c:1545: error: implicit declaration of function 'ata_sff_error_handler' drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1564: error: 'ata_sff_port_ops' undeclared here (not in a function) drivers/ata/sata_dwc_460ex.c:1577: error: unknown field 'bmdma_setup' specified in initializer drivers/ata/sata_dwc_460ex.c:1577: warning: initialization from incompatible pointer type drivers/ata/sata_dwc_460ex.c:1578: error: unknown field 'bmdma_start' specified in initializer drivers/ata/sata_dwc_460ex.c:1578: warning: initialization from incompatible pointer type drivers/ata/sata_dwc_460ex.c: In function
RE: [PATCH v1]460EX on-chip SATA driverresubmisison
Hi Wolfgang, I took the mainline kernel v2.6.35-rc3 and downloaded using the git download link. I created the patch on 6/24/2010 after doing a git pull. With the kernel tree on 6/24/2010 the driver compiled. I also tested the functionality on the SATA drive it worked. Regards, Rup -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, June 30, 2010 5:28 PM To: Rupjyoti Sarmah Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; jgar...@pobox.com; s...@denx.de; rsar...@apm.com; linuxppc-...@ozlabs.org Subject: Re: [PATCH v1]460EX on-chip SATA driverresubmisison Dear Rupjyoti Sarmah, In message 201006241327.o5odry6m032...@amcc.com you wrote: This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. Signed-off-by: Rupjyoti Sarmah rsar...@appliedmicro.com Signed-off-by: Mark Miesfeld mmiesf...@appliedmicro.com Signed-off-by: Prodyut Hazarika phazar...@appliedmicro.com --- This patch incorporates the changes advised in the mailing list. The device tree changes were submitted as a seperate patch. Which kernel is this patch supposed to be applied to? Using current mainline (v2.6.35-rc3-262-g984bc96) the patch applies without problems, but when I enable it in the kernel configuration I get this: drivers/ata/sata_dwc_460ex.c:43:1: warning: DRV_NAME redefined In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: DRV_VERSION redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read': drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write': drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr': drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_isr': drivers/ata/sata_dwc_460ex.c:953: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c:957: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c:991: error: implicit declaration of function 'ata_sff_hsm_move' drivers/ata/sata_dwc_460ex.c:1030: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1213: warning: 'struct ata_ioports' declared inside parameter list drivers/ata/sata_dwc_460ex.c:1213: warning: its scope is only this definition or declaration, which is probably not what you want drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_setup_port': drivers/ata/sata_dwc_460ex.c:1215: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1216: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1218: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1219: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1221: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1223: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1224: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1225: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1227: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1228: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1229: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1231: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1232: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_port_start': drivers/ata/sata_dwc_460ex.c:1273: error: 'struct ata_port' has no member named 'bmdma_prd' drivers/ata/sata_dwc_460ex.c:1274: error: 'struct ata_port' has no member named 'bmdma_prd_dma' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag': drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast drivers/ata/sata_dwc_460ex.c:1369: error: implicit declaration of function 'ata_sff_exec_command' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue': drivers/ata/sata_dwc_460ex.c:1512: error: 'struct ata_port_operations' has no member named 'sff_tf_load' drivers/ata/sata_dwc_460ex.c:1516: error: implicit declaration of function 'ata_sff_qc_issue' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_handler': drivers/ata/sata_dwc_460ex.c:1545: error: implicit declaration of function
[PATCH 2/2] KVM: PPC: Make use of hash based Shadow MMU
We just introduced generic functions to handle shadow pages on PPC.
This patch makes the respective backends make use of them, getting
rid of a lot of duplicate code along the way.
Signed-off-by: Alexander Graf ag...@suse.de
---
v2 - v3:
- use hlist
- use global kmem cache
---
arch/powerpc/include/asm/kvm_book3s.h |9 +++
arch/powerpc/include/asm/kvm_host.h | 17 +-
arch/powerpc/kvm/Makefile |2 +
arch/powerpc/kvm/book3s.c | 14 -
arch/powerpc/kvm/book3s_32_mmu_host.c | 104 +++-
arch/powerpc/kvm/book3s_64_mmu_host.c | 98 ++
6 files changed, 54 insertions(+), 190 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s.h
b/arch/powerpc/include/asm/kvm_book3s.h
index 4e99559..8274a2d 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -115,6 +115,15 @@ extern void kvmppc_mmu_book3s_32_init(struct kvm_vcpu
*vcpu);
extern int kvmppc_mmu_map_page(struct kvm_vcpu *vcpu, struct kvmppc_pte *pte);
extern int kvmppc_mmu_map_segment(struct kvm_vcpu *vcpu, ulong eaddr);
extern void kvmppc_mmu_flush_segments(struct kvm_vcpu *vcpu);
+
+extern void kvmppc_mmu_hpte_cache_map(struct kvm_vcpu *vcpu, struct hpte_cache
*pte);
+extern struct hpte_cache *kvmppc_mmu_hpte_cache_next(struct kvm_vcpu *vcpu);
+extern void kvmppc_mmu_hpte_destroy(struct kvm_vcpu *vcpu);
+extern int kvmppc_mmu_hpte_init(struct kvm_vcpu *vcpu);
+extern void kvmppc_mmu_invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache
*pte);
+extern int kvmppc_mmu_hpte_sysinit(void);
+extern void kvmppc_mmu_hpte_sysexit(void);
+
extern int kvmppc_ld(struct kvm_vcpu *vcpu, ulong *eaddr, int size, void *ptr,
bool data);
extern int kvmppc_st(struct kvm_vcpu *vcpu, ulong *eaddr, int size, void *ptr,
bool data);
extern void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, unsigned int
vec);
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 0c9ad86..e004eaf 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -38,7 +38,13 @@
#define KVM_NR_PAGE_SIZES 1
#define KVM_PAGES_PER_HPAGE(x) (1UL31)
-#define HPTEG_CACHE_NUM 1024
+#define HPTEG_CACHE_NUM(1 15)
+#define HPTEG_HASH_BITS_PTE13
+#define HPTEG_HASH_BITS_VPTE 13
+#define HPTEG_HASH_BITS_VPTE_LONG 5
+#define HPTEG_HASH_NUM_PTE (1 HPTEG_HASH_BITS_PTE)
+#define HPTEG_HASH_NUM_VPTE(1 HPTEG_HASH_BITS_VPTE)
+#define HPTEG_HASH_NUM_VPTE_LONG (1 HPTEG_HASH_BITS_VPTE_LONG)
struct kvm;
struct kvm_run;
@@ -151,6 +157,9 @@ struct kvmppc_mmu {
};
struct hpte_cache {
+ struct hlist_node list_pte;
+ struct hlist_node list_vpte;
+ struct hlist_node list_vpte_long;
u64 host_va;
u64 pfn;
ulong slot;
@@ -282,8 +291,10 @@ struct kvm_vcpu_arch {
unsigned long pending_exceptions;
#ifdef CONFIG_PPC_BOOK3S
- struct hpte_cache hpte_cache[HPTEG_CACHE_NUM];
- int hpte_cache_offset;
+ struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
+ struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
+ struct hlist_head hpte_hash_vpte_long[HPTEG_HASH_NUM_VPTE_LONG];
+ int hpte_cache_count;
#endif
};
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index ff43606..d45c818 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -45,6 +45,7 @@ kvm-book3s_64-objs := \
book3s.o \
book3s_emulate.o \
book3s_interrupts.o \
+ book3s_mmu_hpte.o \
book3s_64_mmu_host.o \
book3s_64_mmu.o \
book3s_32_mmu.o
@@ -57,6 +58,7 @@ kvm-book3s_32-objs := \
book3s.o \
book3s_emulate.o \
book3s_interrupts.o \
+ book3s_mmu_hpte.o \
book3s_32_mmu_host.o \
book3s_32_mmu.o
kvm-objs-$(CONFIG_KVM_BOOK3S_32) := $(kvm-book3s_32-objs)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 884d4a5..30c0bd5 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -1389,12 +1389,22 @@ int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
static int kvmppc_book3s_init(void)
{
- return kvm_init(NULL, sizeof(struct kvmppc_vcpu_book3s), 0,
- THIS_MODULE);
+ int r;
+
+ r = kvm_init(NULL, sizeof(struct kvmppc_vcpu_book3s), 0,
+THIS_MODULE);
+
+ if (r)
+ return r;
+
+ r = kvmppc_mmu_hpte_sysinit();
+
+ return r;
}
static void kvmppc_book3s_exit(void)
{
+ kvmppc_mmu_hpte_sysexit();
kvm_exit();
}
diff --git a/arch/powerpc/kvm/book3s_32_mmu_host.c
b/arch/powerpc/kvm/book3s_32_mmu_host.c
index 904f5ac..0b51ef8 100644
--- a/arch/powerpc/kvm/book3s_32_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_32_mmu_host.c
@@ -58,105 +58,19 @@
static ulong htab;
[PATCH 0/2] Faster MMU lookups for Book3s v3
Book3s suffered from my really bad shadow MMU implementation so far. So
I finally got around to implement a combined hash and list mechanism that
allows for much faster lookup of mapped pages.
To show that it really is faster, I tried to run simple process spawning
code inside the guest with and without these patches:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null; done
real0m20.235s
user0m10.418s
sys 0m9.766s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null; done
real0m14.659s
user0m8.967s
sys 0m5.688s
So as you can see, performance improved significantly.
v2 - v3:
- use hlist
- use global slab cache
Alexander Graf (2):
KVM: PPC: Add generic hpte management functions
KVM: PPC: Make use of hash based Shadow MMU
arch/powerpc/include/asm/kvm_book3s.h |9 +
arch/powerpc/include/asm/kvm_host.h | 17 ++-
arch/powerpc/kvm/Makefile |2 +
arch/powerpc/kvm/book3s.c | 14 ++-
arch/powerpc/kvm/book3s_32_mmu_host.c | 104 ++---
arch/powerpc/kvm/book3s_64_mmu_host.c | 98 +---
arch/powerpc/kvm/book3s_mmu_hpte.c| 277 +
7 files changed, 331 insertions(+), 190 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s_mmu_hpte.c
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] KVM: PPC: Add generic hpte management functions
Currently the shadow paging code keeps an array of entries it knows about.
Whenever the guest invalidates an entry, we loop through that entry,
trying to invalidate matching parts.
While this is a really simple implementation, it is probably the most
ineffective one possible. So instead, let's keep an array of lists around
that are indexed by a hash. This way each PTE can be added by 4 list_add,
removed by 4 list_del invocations and the search only needs to loop through
entries that share the same hash.
This patch implements said lookup and exports generic functions that both
the 32-bit and 64-bit backend can use.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- remove hpte_all list
- lookup all using vpte_long lists
- decrease size of vpte_long hash
- fix missing brackets
v2 - v3:
- use hlist
- use global kmem cache
---
arch/powerpc/kvm/book3s_mmu_hpte.c | 277
1 files changed, 277 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/kvm/book3s_mmu_hpte.c
diff --git a/arch/powerpc/kvm/book3s_mmu_hpte.c
b/arch/powerpc/kvm/book3s_mmu_hpte.c
new file mode 100644
index 000..4868d4a
--- /dev/null
+++ b/arch/powerpc/kvm/book3s_mmu_hpte.c
@@ -0,0 +1,277 @@
+/*
+ * Copyright (C) 2010 SUSE Linux Products GmbH. All rights reserved.
+ *
+ * Authors:
+ * Alexander Graf ag...@suse.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program 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; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ */
+
+#include linux/kvm_host.h
+#include linux/hash.h
+#include linux/slab.h
+
+#include asm/kvm_ppc.h
+#include asm/kvm_book3s.h
+#include asm/machdep.h
+#include asm/mmu_context.h
+#include asm/hw_irq.h
+
+#define PTE_SIZE 12
+
+/* #define DEBUG_MMU */
+
+#ifdef DEBUG_MMU
+#define dprintk_mmu(a, ...) printk(KERN_INFO a, __VA_ARGS__)
+#else
+#define dprintk_mmu(a, ...) do { } while(0)
+#endif
+
+static struct kmem_cache *hpte_cache;
+
+static inline u64 kvmppc_mmu_hash_pte(u64 eaddr)
+{
+ return hash_64(eaddr PTE_SIZE, HPTEG_HASH_BITS_PTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte(u64 vpage)
+{
+ return hash_64(vpage 0xfULL, HPTEG_HASH_BITS_VPTE);
+}
+
+static inline u64 kvmppc_mmu_hash_vpte_long(u64 vpage)
+{
+ return hash_64((vpage 0xff000ULL) 12,
+ HPTEG_HASH_BITS_VPTE_LONG);
+}
+
+void kvmppc_mmu_hpte_cache_map(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
+{
+ u64 index;
+
+ /* Add to ePTE list */
+ index = kvmppc_mmu_hash_pte(pte-pte.eaddr);
+ hlist_add_head(pte-list_pte, vcpu-arch.hpte_hash_pte[index]);
+
+ /* Add to vPTE list */
+ index = kvmppc_mmu_hash_vpte(pte-pte.vpage);
+ hlist_add_head(pte-list_vpte, vcpu-arch.hpte_hash_vpte[index]);
+
+ /* Add to vPTE_long list */
+ index = kvmppc_mmu_hash_vpte_long(pte-pte.vpage);
+ hlist_add_head(pte-list_vpte_long,
+ vcpu-arch.hpte_hash_vpte_long[index]);
+}
+
+static void invalidate_pte(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
+{
+ dprintk_mmu(KVM: Flushing SPT: 0x%lx (0x%llx) - 0x%llx\n,
+ pte-pte.eaddr, pte-pte.vpage, pte-host_va);
+
+ /* Different for 32 and 64 bit */
+ kvmppc_mmu_invalidate_pte(vcpu, pte);
+
+ if (pte-pte.may_write)
+ kvm_release_pfn_dirty(pte-pfn);
+ else
+ kvm_release_pfn_clean(pte-pfn);
+
+ hlist_del(pte-list_pte);
+ hlist_del(pte-list_vpte);
+ hlist_del(pte-list_vpte_long);
+
+ vcpu-arch.hpte_cache_count--;
+ kmem_cache_free(hpte_cache, pte);
+}
+
+static void kvmppc_mmu_pte_flush_all(struct kvm_vcpu *vcpu)
+{
+ struct hpte_cache *pte;
+ struct hlist_node *node, *tmp;
+ int i;
+
+ for (i = 0; i HPTEG_HASH_NUM_VPTE_LONG; i++) {
+ struct hlist_head *list = vcpu-arch.hpte_hash_vpte_long[i];
+
+ hlist_for_each_entry_safe(pte, node, tmp, list, list_vpte_long)
+ invalidate_pte(vcpu, pte);
+ }
+}
+
+static void kvmppc_mmu_pte_flush_page(struct kvm_vcpu *vcpu, ulong guest_ea)
+{
+ struct hlist_head *list;
+ struct hlist_node *node, *tmp;
+ struct hpte_cache *pte;
+
+ /* Find the list of entries in the map */
+ list = vcpu-arch.hpte_hash_pte[kvmppc_mmu_hash_pte(guest_ea)];
+
+ /* Check the list for matching entries and invalidate */
+
Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
On Fri, 2010-06-25 at 13:18 +0200, Jakub Jelinek wrote: On Fri, Jun 25, 2010 at 01:08:23PM +0200, Segher Boessenkool wrote: - stw%U0%X0 %L2,%1 - : =m (*ptep), =m (*((unsigned char *)ptep+4)) + stw%U1%X1 %L2,%1 + : =m (*ptep), =m (*((unsigned char *)ptep+4)) : r (pte) : memory); This still isn't correct -- the constraint says that a byte is written, but the insn changes a word. Probably should just be ptep[1] ? Oops, almost forgot about this. Are you guys shooting a new patch or do you want me to do it ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel init exception
Hi, David, Segher, Maybe it was caused by floating exception.I found that,system received a program check exception,the reason for it was REASON_ILLEGAL. I also use show_regs to print the NIP in exception,it seemed that ,this exception was caused by 'vmhaddshs' instruction in user mode of init process . Is vmhaddshs avaliable on e500mc? My cross compile tool is gcc-4.1.2-glibc-2.5.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
On 06/30/2010 01:14 AM, Shawn Jin wrote: Hi Scott, Bus Fault @ 0x00404c40, fixup 0x Machine check in kernel mode. Caused by (from msr): regs 07d1cb80 Unknown values in msr NIP: 00404C40 XER: LR: 00404C24 REGS: 07d1cb80 TRAP: 0200 DAR: 0001 MSR: 1002 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 Can you look up the source line/instruction corresponding to 0x404c40, in the wrapper ELF file? I'm not sure how to look up it. Use a powerpc gdb on the wrapper ELF file, and do li *0x404c40 and/or i li *0x404c40. Or use a powerpc addr2line. But I used the BDI to dump the instructions in which you may find some clue? These should be kernel code, right? Maybe the gdb can help to de-assemble them? Not easily (Format letter i is meaningless in print command, it says...) and there'd be no context about what part of the source code it corresponds to... 00404c40 : 0xa00a -1609957376 But this is a 16-bit load from r10, which is from your previous register dump is FF0009C0. Does u-boot on your board put IMMR somewhere other than 0xff00? If so, you'll need to update the device tree to reflect this. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote:
I really don't see any value at all to this config option,
the errata fixup code should be there all the time.
Well, at least for eTSEC76 erratum (patch 2/3) we have to touch
fast path (i.e. start_xmit), so I just wanted to make zero
overhead for controllers that don't need any fixups.
Not that there's much of the overhead in a single additional
'if' condition, no. ;-)
It really does no harm to be there in the cases where it isn't
used, and forcing users to turn this on is just another
obscure way to end up with an incorrect configuration.
OK, resending the new patches, without Kconfig stuff...
If we'll have too many or too big errata so that it would cause
major performance or code size penalty for non-affected SOCs, we
can always do:
enum gfar_errata {
#ifdef CONFIG_PPC_FOO
GFAR_ERRATA_FOO = 0x01,
#else
GFAR_ERRATA_FOO = 0,
#endif
}
And then, priv-errata GFAR_ERRATA_FOO will be optimized
away by the compiler.
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
MPC8313ECE says:
If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
which are larger than MAXFRM, the controller truncates the frames to
length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
or MAXFRM-1, even though those frames are not truncated.
No truncation or truncation error occurs if MACCFG2[Huge Frame]=1.
There are two options to workaround the issue:
1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
frames. Software can determine if a frame is larger than MAXFRM by
reading RxBD[LG] or RxBD[Data Length].
2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
normal-length frames are not marked as truncated. Software can examine
RxBD[Data Length] to determine if the frame was larger than MAXFRM-2.
This patch implements the first workaround option by setting HUGEFRAME
bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
drivers/net/gianfar.c | 29 +++--
drivers/net/gianfar.h | 11 +++
2 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 28b53d1..9abcb39 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -85,6 +85,7 @@
#include linux/net_tstamp.h
#include asm/io.h
+#include asm/reg.h
#include asm/irq.h
#include asm/uaccess.h
#include linux/module.h
@@ -928,6 +929,24 @@ static void gfar_init_filer_table(struct gfar_private
*priv)
}
}
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = priv-ofdev-dev;
+ unsigned int pvr = mfspr(SPRN_PVR);
+ unsigned int svr = mfspr(SPRN_SVR);
+ unsigned int mod = (svr 16) 0xfff6; /* w/o E suffix */
+ unsigned int rev = svr 0x;
+
+ /* MPC8313 Rev 2.0 and higher; All MPC837x */
+ if ((pvr == 0x80850010 mod == 0x80b0 rev = 0x0020) ||
+ (pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
+ priv-errata |= GFAR_ERRATA_74;
+
+ if (priv-errata)
+ dev_info(dev, enabled errata workarounds, flags: 0x%x\n,
+priv-errata);
+}
+
/* Set up the ethernet device structure, private data,
* and anything else we need before we start */
static int gfar_probe(struct of_device *ofdev,
@@ -960,6 +979,8 @@ static int gfar_probe(struct of_device *ofdev,
dev_set_drvdata(ofdev-dev, priv);
regs = priv-gfargrp[0].regs;
+ gfar_detect_errata(priv);
+
/* Stop the DMA engine now, in case it was running before */
/* (The firmware could have used it, and left it running). */
gfar_halt(dev);
@@ -974,7 +995,10 @@ static int gfar_probe(struct of_device *ofdev,
gfar_write(regs-maccfg1, tempval);
/* Initialize MACCFG2. */
- gfar_write(regs-maccfg2, MACCFG2_INIT_SETTINGS);
+ tempval = MACCFG2_INIT_SETTINGS;
+ if (gfar_has_errata(priv, GFAR_ERRATA_74))
+ tempval |= MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK;
+ gfar_write(regs-maccfg2, tempval);
/* Initialize ECNTRL */
gfar_write(regs-ecntrl, ECNTRL_INIT_SETTINGS);
@@ -2300,7 +2324,8 @@ static int gfar_change_mtu(struct net_device *dev, int
new_mtu)
* to allow huge frames, and to check the length */
tempval = gfar_read(regs-maccfg2);
- if (priv-rx_buffer_size DEFAULT_RX_BUFFER_SIZE)
+ if (priv-rx_buffer_size DEFAULT_RX_BUFFER_SIZE ||
+ gfar_has_errata(priv, GFAR_ERRATA_74))
tempval |= (MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
else
tempval = ~(MACCFG2_HUGEFRAME | MACCFG2_LENGTHCHECK);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index ac4a92e..0a0483c 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1025,6 +1025,10 @@ struct gfar_priv_grp {
char int_name_er[GFAR_INT_NAME_MAX];
};
+enum gfar_errata {
+ GFAR_ERRATA_74 = 0x01,
+};
+
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
* (Ok, that's not so true anymore, but there is a family resemblence)
* The GFAR buffer descriptors track the ring buffers. The rx_bd_base
@@ -1049,6 +1053,7 @@ struct gfar_private {
struct device_node *node;
struct net_device *ndev;
struct of_device *ofdev;
+ enum gfar_errata errata;
struct gfar_priv_grp gfargrp[MAXGROUPS];
struct gfar_priv_tx_q *tx_queue[MAX_TX_QS];
@@ -,6 +1116,12 @@ struct gfar_private {
extern unsigned int ftp_rqfpr[MAX_FILER_IDX + 1];
extern unsigned int ftp_rqfcr[MAX_FILER_IDX + 1];
+static inline int gfar_has_errata(struct gfar_private *priv,
+ enum gfar_errata err)
+{
+ return priv-errata err;
+}
+
static inline u32 gfar_read(volatile unsigned
[PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
MPC8313ECE says:
For TOE=1 huge or jumbo frames, the data required to generate the
checksum may exceed the 2500-byte threshold beyond which the controller
constrains itself to one memory fetch every 256 eTSEC system clocks.
This throttling threshold is supposed to trigger only when the
controller has sufficient data to keep transmit active for the duration
of the memory fetches. The state machine handling this threshold,
however, fails to take large TOE frames into account. As a result,
TOE=1 frames larger than 2500 bytes often see excess delays before start
of transmission.
This patch implements the workaround as suggested by the errata
document, i.e.:
Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
memory throttling.
When using packets larger than 2700 bytes, it is recommended to turn TOE
off.
To be sure, we limit the TOE frames to 2500 bytes, and do software
checksumming instead.
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
drivers/net/gianfar.c | 19 +++
drivers/net/gianfar.h |1 +
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 9abcb39..8ba2973 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -942,6 +942,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
priv-errata |= GFAR_ERRATA_74;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 mod == 0x80b0) ||
+ (pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
+ priv-errata |= GFAR_ERRATA_76;
+
if (priv-errata)
dev_info(dev, enabled errata workarounds, flags: 0x%x\n,
priv-errata);
@@ -2011,6 +2016,20 @@ static int gfar_start_xmit(struct sk_buff *skb, struct
net_device *dev)
unsigned int nr_frags, nr_txbds, length;
union skb_shared_tx *shtx;
+ /*
+* TOE=1 frames larger than 2500 bytes may see excess delays
+* before start of transmission.
+*/
+ if (unlikely(gfar_has_errata(priv, GFAR_ERRATA_76)
+ skb-ip_summed == CHECKSUM_PARTIAL
+ skb-len 2500)) {
+ int ret;
+
+ ret = skb_checksum_help(skb);
+ if (ret)
+ return ret;
+ }
+
rq = skb-queue_mapping;
tx_queue = priv-tx_queue[rq];
txq = netdev_get_tx_queue(dev, rq);
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index 0a0483c..c414374 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1027,6 +1027,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
+ GFAR_ERRATA_76 = 0x02,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
MPC8313ECE says:
If the controller receives a 1- or 2-byte frame (such as an illegal
runt packet or a packet with RX_ER asserted) before GRS is asserted
and does not receive any other frames, the controller may fail to set
GRSC even when the receive logic is completely idle. Any subsequent
receive frame that is larger than two bytes will reset the state so
the graceful stop can complete. A MAC receiver (Rx) reset will also
reset the state.
This patch implements the proposed workaround:
If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
If the register fields are not equal, wait for another timeout
period and check again.
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
drivers/net/gianfar.c | 40 +---
drivers/net/gianfar.h |1 +
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8ba2973..35626eb 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -947,6 +947,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
priv-errata |= GFAR_ERRATA_76;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 mod == 0x80b0) ||
+ (pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
+ priv-errata |= GFAR_ERRATA_A002;
+
if (priv-errata)
dev_info(dev, enabled errata workarounds, flags: 0x%x\n,
priv-errata);
@@ -1570,6 +1575,29 @@ static void init_registers(struct net_device *dev)
gfar_write(regs-minflr, MINFLR_INIT_SETTINGS);
}
+static int __gfar_is_rx_idle(struct gfar_private *priv)
+{
+ u32 res;
+
+ /*
+* Normaly TSEC should not hang on GRS commands, so we should
+* actually wait for IEVENT_GRSC flag.
+*/
+ if (likely(!gfar_has_errata(priv, GFAR_ERRATA_A002)))
+ return 0;
+
+ /*
+* Read the eTSEC register at offset 0xD1C. If bits 7-14 are
+* the same as bits 23-30, the eTSEC Rx is assumed to be idle
+* and the Rx can be safely reset.
+*/
+ res = gfar_read((void __iomem *)priv-gfargrp[0].regs + 0xd1c);
+ res = 0x7f807f80;
+ if ((res 0x) == (res 16))
+ return 1;
+
+ return 0;
+}
/* Halt the receive and transmit queues */
static void gfar_halt_nodisable(struct net_device *dev)
@@ -1593,12 +1621,18 @@ static void gfar_halt_nodisable(struct net_device *dev)
tempval = gfar_read(regs-dmactrl);
if ((tempval (DMACTRL_GRS | DMACTRL_GTS))
!= (DMACTRL_GRS | DMACTRL_GTS)) {
+ int ret;
+
tempval |= (DMACTRL_GRS | DMACTRL_GTS);
gfar_write(regs-dmactrl, tempval);
- spin_event_timeout(((gfar_read(regs-ievent)
-(IEVENT_GRSC | IEVENT_GTSC)) ==
-(IEVENT_GRSC | IEVENT_GTSC)), -1, 0);
+ do {
+ ret = spin_event_timeout(((gfar_read(regs-ievent)
+(IEVENT_GRSC | IEVENT_GTSC)) ==
+(IEVENT_GRSC | IEVENT_GTSC)), 100, 0);
+ if (!ret !(gfar_read(regs-ievent) IEVENT_GRSC))
+ ret = __gfar_is_rx_idle(priv);
+ } while (!ret);
}
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index c414374..710810e 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1028,6 +1028,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
+ GFAR_ERRATA_A002= 0x04,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
Dear Rupjyoti Sarmah, In message 3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com you wrote: I took the mainline kernel v2.6.35-rc3 and downloaded using the git download link. I created the patch on 6/24/2010 after doing a git pull. With the kernel tree on 6/24/2010 the driver compiled. I also tested the functionality on the SATA drive it worked. v2.6.35-rc3 was released on June 11, 13 days before 6/24/2010. Can you please give the exact git commit ID so I can try reproducing this? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There comes to all races an ultimate crisis which you have yet to face One day our minds became so powerful we dared think of ourselves as gods. -- Sargon, Return to Tomorrow, stardate 4768.3 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: Anton Vorontsov avoront...@mvista.com Date: Wed, 30 Jun 2010 20:38:04 +0400 On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote: I really don't see any value at all to this config option, the errata fixup code should be there all the time. Well, at least for eTSEC76 erratum (patch 2/3) we have to touch fast path (i.e. start_xmit), so I just wanted to make zero overhead for controllers that don't need any fixups. Not that there's much of the overhead in a single additional 'if' condition, no. ;-) The register accesses will dominate the costs with this chip. The only case where a if() test is going to potentially create some practical performance impact is if the TX is performed purely using changes to a shared memory data structure and absolutely no MMIO register reads or writes. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: Anton Vorontsov avoront...@mvista.com Date: Wed, 30 Jun 2010 20:39:12 +0400 MPC8313ECE says: If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames which are larger than MAXFRM, the controller truncates the frames to length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM or MAXFRM-1, even though those frames are not truncated. No truncation or truncation error occurs if MACCFG2[Huge Frame]=1. There are two options to workaround the issue: 1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large frames. Software can determine if a frame is larger than MAXFRM by reading RxBD[LG] or RxBD[Data Length]. 2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so normal-length frames are not marked as truncated. Software can examine RxBD[Data Length] to determine if the frame was larger than MAXFRM-2. This patch implements the first workaround option by setting HUGEFRAME bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length]. Signed-off-by: Anton Vorontsov avoront...@mvista.com Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: Anton Vorontsov avoront...@mvista.com Date: Wed, 30 Jun 2010 20:39:13 +0400 MPC8313ECE says: For TOE=1 huge or jumbo frames, the data required to generate the checksum may exceed the 2500-byte threshold beyond which the controller constrains itself to one memory fetch every 256 eTSEC system clocks. This throttling threshold is supposed to trigger only when the controller has sufficient data to keep transmit active for the duration of the memory fetches. The state machine handling this threshold, however, fails to take large TOE frames into account. As a result, TOE=1 frames larger than 2500 bytes often see excess delays before start of transmission. This patch implements the workaround as suggested by the errata document, i.e.: Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to memory throttling. When using packets larger than 2700 bytes, it is recommended to turn TOE off. To be sure, we limit the TOE frames to 2500 bytes, and do software checksumming instead. Signed-off-by: Anton Vorontsov avoront...@mvista.com Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: Anton Vorontsov avoront...@mvista.com Date: Wed, 30 Jun 2010 20:39:15 +0400 MPC8313ECE says: If the controller receives a 1- or 2-byte frame (such as an illegal runt packet or a packet with RX_ER asserted) before GRS is asserted and does not receive any other frames, the controller may fail to set GRSC even when the receive logic is completely idle. Any subsequent receive frame that is larger than two bytes will reset the state so the graceful stop can complete. A MAC receiver (Rx) reset will also reset the state. This patch implements the proposed workaround: If IEVENT[GRSC] is still not set after the timeout, read the eTSEC register at offset 0xD1C. If bits 7-14 are the same as bits 23-30, the eTSEC Rx is assumed to be idle and the Rx can be safely reset. If the register fields are not equal, wait for another timeout period and check again. Signed-off-by: Anton Vorontsov avoront...@mvista.com Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
Dear Rupjyoti Sarmah, In message 3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com you wrote: I took the mainline kernel v2.6.35-rc3 and downloaded using the git download link. I created the patch on 6/24/2010 after doing a git pull. I don;t think that you used v2.6.35-rc3; using this version, I still get this: drivers/ata/sata_dwc_460ex.c:43:1: warning: DRV_NAME redefined In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: DRV_VERSION redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read': drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write': drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr': drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_isr': drivers/ata/sata_dwc_460ex.c:953: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c:957: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c:991: error: implicit declaration of function 'ata_sff_hsm_move' drivers/ata/sata_dwc_460ex.c:1030: error: 'struct ata_port_operations' has no member named 'sff_check_status' drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1213: warning: 'struct ata_ioports' declared inside parameter list drivers/ata/sata_dwc_460ex.c:1213: warning: its scope is only this definition or declaration, which is probably not what you want drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_setup_port': drivers/ata/sata_dwc_460ex.c:1215: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1216: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1218: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1219: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1221: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1223: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1224: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1225: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1227: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1228: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1229: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1231: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c:1232: error: dereferencing pointer to incomplete type drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_port_start': drivers/ata/sata_dwc_460ex.c:1273: error: 'struct ata_port' has no member named 'bmdma_prd' drivers/ata/sata_dwc_460ex.c:1274: error: 'struct ata_port' has no member named 'bmdma_prd_dma' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag': drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast drivers/ata/sata_dwc_460ex.c:1369: error: implicit declaration of function 'ata_sff_exec_command' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue': drivers/ata/sata_dwc_460ex.c:1512: error: 'struct ata_port_operations' has no member named 'sff_tf_load' drivers/ata/sata_dwc_460ex.c:1516: error: implicit declaration of function 'ata_sff_qc_issue' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_handler': drivers/ata/sata_dwc_460ex.c:1545: error: implicit declaration of function 'ata_sff_error_handler' drivers/ata/sata_dwc_460ex.c: At top level: drivers/ata/sata_dwc_460ex.c:1564: error: 'ata_sff_port_ops' undeclared here (not in a function) drivers/ata/sata_dwc_460ex.c:1577: error: unknown field 'bmdma_setup' specified in initializer drivers/ata/sata_dwc_460ex.c:1577: warning: initialization from incompatible pointer type drivers/ata/sata_dwc_460ex.c:1578: error: unknown field 'bmdma_start' specified in initializer drivers/ata/sata_dwc_460ex.c:1578: warning: initialization from incompatible pointer type drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_probe': drivers/ata/sata_dwc_460ex.c:1638: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c:1639: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c:1641: error: 'struct ata_port' has no member named 'ioaddr' make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1 make[1]: *** [drivers/ata] Error 2 make:
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
On 06/30/2010 02:47 PM, Wolfgang Denk wrote: Dear Rupjyoti Sarmah, In message3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com you wrote: I took the mainline kernel v2.6.35-rc3 and downloaded using the git download link. I created the patch on 6/24/2010 after doing a git pull. I don;t think that you used v2.6.35-rc3; using this version, I still get this: drivers/ata/sata_dwc_460ex.c:43:1: warning: DRV_NAME redefined In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: DRV_VERSION redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read': drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write': drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr': drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status' It looks like -your- build config is missing CONFIG_ATA_SFF or similar. If you actually look at include/linux/libata.h, you see that struct ata_port_operations most definitely has a member named sff_check_status, for example. Ditto ata_port and member ioaddr, etc. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-booke: Fix comments that refer to BAT registers
There are no BATS on BookE - we have the TLBCAM instead. Also correct the page size information to included extended (1G and 4G) sizes. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- Lame, I know, but this drives me batty every time I see it, and I've had customers get confused because of it. I've finally gotten irritated enough to send a patch. -Becky arch/powerpc/mm/fsl_booke_mmu.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c index cdc7526..681429d 100644 --- a/arch/powerpc/mm/fsl_booke_mmu.c +++ b/arch/powerpc/mm/fsl_booke_mmu.c @@ -104,9 +104,9 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa) } /* - * Set up one of the I/D BAT (block address translation) register pairs. - * The parameters are not checked; in particular size must be a power - * of 4 between 4k and 256M. + * Set up a variable-size TLB entry (tlbcam). The parameters are not checked; + * in particular size must be a power of 4 between 4k and 256M (or 4G, for cpus + * that support extended page sizes). */ static void settlbcam(int index, unsigned long virt, phys_addr_t phys, unsigned long size, unsigned long flags, unsigned int pid) -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
On Wed, Jun 30, 2010 at 03:17:05PM -0400, Jeff Garzik wrote: On 06/30/2010 02:47 PM, Wolfgang Denk wrote: Dear Rupjyoti Sarmah, In message3b928476b2fffdcf0694e5436e8a4...@mail.gmail.com you wrote: I took the mainline kernel v2.6.35-rc3 and downloaded using the git download link. I created the patch on 6/24/2010 after doing a git pull. I don;t think that you used v2.6.35-rc3; using this version, I still get this: drivers/ata/sata_dwc_460ex.c:43:1: warning: DRV_NAME redefined In file included from drivers/ata/sata_dwc_460ex.c:38: drivers/ata/libata.h:31:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c:44:1: warning: DRV_VERSION redefined drivers/ata/libata.h:32:1: warning: this is the location of the previous definition drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read': drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write': drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr' drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr': drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status' It looks like -your- build config is missing CONFIG_ATA_SFF or similar. If you actually look at include/linux/libata.h, you see that struct ata_port_operations most definitely has a member named sff_check_status, for example. Ditto ata_port and member ioaddr, etc. The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to require it at build time. Isn't that something that needs fixing in the driver? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
Stefan, The driver is based on Synopsys driver 2.60a. We started to prepare open source submission based on our internal version. We sync this version to linux-2.6-denx repository from time to time. I'll sync the driver to the latest linux-2.6-denx as Wolfgang pointed out, and re-submit patch to open source. We modified the driver mostly to follow Linux kernel coding style. Both USB host and device modes are tested. Thanks, Fushen 1. On Wed, 2010-06-30 at 11:27 +0200, Stefan Roese wrote: Hi Fushen, Hi Mark, On Tuesday 29 June 2010 23:26:54 Fushen Chen wrote: The DWC OTG driver module provides the initialization and cleanup entry points for the DWC OTG USB driver. Signed-off-by: Fushen Chen fc...@apm.com Signed-off-by: Mark Miesfeld mmiesf...@apm.com I tried to compare this driver with the version that's currently available in the linux-2.6-denx repository. But the differences are quite big. Could you please list the history of this DWC driver? Things like: - Which Synopsis version is it based upon? - What changes/enhancements/fixups where made from APM? - How was this driver tested (USB host and device mode)? As Wolfgang already pointed out, the driver in our git repository has undergone multiple changes/fixes. Did you take a look at them and try to integrate them? Thanks. Cheers, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2] powerpc: Fix comments in fsl_booke_mmu code that mention BATS
There are no BATS on BookE - we have the TLBCAM instead. Also correct the page size information to included extended sizes. We don't actually allow a 4G page size to be used, so comment on that as well. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- Even lamer, I forgot that we don't actually allow use of a 4G page. Update the comment to reflect this. -Becky arch/powerpc/mm/fsl_booke_mmu.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c index cdc7526..4b66a1e 100644 --- a/arch/powerpc/mm/fsl_booke_mmu.c +++ b/arch/powerpc/mm/fsl_booke_mmu.c @@ -104,9 +104,10 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa) } /* - * Set up one of the I/D BAT (block address translation) register pairs. - * The parameters are not checked; in particular size must be a power - * of 4 between 4k and 256M. + * Set up a variable-size TLB entry (tlbcam). The parameters are not checked; + * in particular size must be a power of 4 between 4k and 256M (or 1G, for cpus + * that support extended page sizes). Note that while some cpus support a + * page size of 4G, we don't allow its use here. */ static void settlbcam(int index, unsigned long virt, phys_addr_t phys, unsigned long size, unsigned long flags, unsigned int pid) -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
On Mon, Mar 8, 2010 at 2:10 PM, Alexandre Bounine aboun...@tundra.com wrote:
From: Alexandre Bounine alexandre.boun...@idt.com
Add Machine Check exception handling into RapidIO port driver
for Freescale SoCs (MPC85xx).
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Tested-by: Thomas Moll thomas.m...@sysgo.com
...
+static int fsl_rio_mcheck_exception(struct pt_regs *regs)
+{
+ const struct exception_table_entry *entry = NULL;
+ unsigned long reason = (mfspr(SPRN_MCSR) MCSR_MASK);
MCSR_MASK is not defined anywhere, so when I compile this code, I get this:
CC arch/powerpc/sysdev/fsl_rio.o
arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared
(first use in this function)
arch/powerpc/sysdev/fsl_rio.c:248: error: (Each undeclared identifier
is reported only once
arch/powerpc/sysdev/fsl_rio.c:248: error: for each function it appears in.)
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
On Wed, Jun 30, 2010 at 3:55 PM, Timur Tabi timur.t...@gmail.com wrote: MCSR_MASK is not defined anywhere, so when I compile this code, I get this: Never mind. I see that it's been fixed already, and that the patch that removed MCSR_MASK was posted around the same time that this patch was posted. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
David, AppliedMicro has PPC-405EX and PPC-460EX SOC using this controller. There will be another arch/powerpc/boot/dts/canyonlands.dts for PPC-460EX board. Thanks, Fushen On Tue, 2010-06-29 at 15:41 -0700, David Brownell wrote: Good -- MUSB won't be the only one. ;) Could you mention a few Linux-enabled chips which include this controller? arch/powerpc/boot/dts/kilauea.dts | 15 + Also, please provide a clean patch that only includes the driver, and split PPC hooks into a separate patch. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
Just whitelist these extra compiler generated symbols.
Fixes these errors:
[...]
I've used an identical patch for almost a year now, so...
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
Acked-by: Segher Boessenkool seg...@kernel.crashing.org
You probably also need something similar to http://git.infradead.org/
users/segher/linux.git/commitdiff/
98194f54cc8e19ecd752bc10e2d19ef94074f502
(note: only build-tested, not run-tested).
Segher
---
arch/powerpc/kernel/prom_init_check.sh |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/
kernel/prom_init_check.sh
index 1ac136b..9f82f49 100644
--- a/arch/powerpc/kernel/prom_init_check.sh
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -52,12 +52,18 @@ do
if [ ${UNDEF:0:9} = _restgpr_ ]; then
OK=1
fi
+ if [ ${UNDEF:0:10} = _restgpr0_ ]; then
+ OK=1
+ fi
if [ ${UNDEF:0:11} = _rest32gpr_ ]; then
OK=1
fi
if [ ${UNDEF:0:9} = _savegpr_ ]; then
OK=1
fi
+ if [ ${UNDEF:0:10} = _savegpr0_ ]; then
+ OK=1
+ fi
if [ ${UNDEF:0:11} = _save32gpr_ ]; then
OK=1
fi
--
1.7.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: machine check in kernel for a mpc870 board
Hi Scott,
Does u-boot on your board put IMMR somewhere other than 0xff00? If so,
you'll need to update the device tree to reflect this.
Thanks a lot. I think you got something here. Please bear with me.
This is the first dts file I'm creating. I have some question
regarding to dts first. BTW, My IMMR is at 0xfa20.
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc
relate to IMMR? So my localbus and soc should be as follows?
local...@fa200100 {
compatible = fsl,mpc885-localbus, fsl,pq1-localbus,
simple-bus;
#address-cells = 2;
#size-cells = 1;
reg = 0xfa200100 0x40;
ranges =
0 0 0xfe00 0x0100// I'm not sure about this?
;
};
s...@fa20 {
compatible = fsl,mpc875-immr, fsl,pq1-soc, simple-bus;
#address-cells = 1;
#size-cells = 1;
ranges = 0 0xfa20 0x4000;
// Temporary until code stops depending on it.
device_type = soc;
// Temporary until get_immrbase() is fixed.
reg = 0xfa20 0x4000;
};
Thanks again,
-Shawn.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
- stw%U0%X0 %L2,%1 - : =m (*ptep), =m (*((unsigned char *)ptep+4)) + stw%U1%X1 %L2,%1 + : =m (*ptep), =m (*((unsigned char *)ptep+4)) : r (pte) : memory); This still isn't correct -- the constraint says that a byte is written, but the insn changes a word. Probably should just be ptep[1] ? Oops, almost forgot about this. Are you guys shooting a new patch or do you want me to do it ? It's really an independent fix. Just take Jakub's patch, I'll do one on top of it? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
Hi Segher, On Thu, 1 Jul 2010 00:16:40 +0200 Segher Boessenkool seg...@kernel.crashing.org wrote: I've used an identical patch for almost a year now, so... Signed-off-by: Stephen Rothwell s...@canb.auug.org.au Acked-by: Segher Boessenkool seg...@kernel.crashing.org Thanks. You probably also need something similar to http://git.infradead.org/ users/segher/linux.git/commitdiff/ 98194f54cc8e19ecd752bc10e2d19ef94074f502 (note: only build-tested, not run-tested). See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp2WepkTQBLn.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel init exception
Maybe it was caused by floating exception.I found that,system received a program check exception,the reason for it was REASON_ILLEGAL. I also use show_regs to print the NIP in exception,it seemed that ,this exception was caused by 'vmhaddshs' instruction in user mode of init process . Is vmhaddshs avaliable on e500mc? My cross compile tool is gcc-4.1.2-glibc-2.5.0 This isn't vmhaddshs (which is an AltiVec instruction), but something else that also uses primary opcode 4. It sounds like your toolchain isn't set up correctly for e500mc. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
You probably also need something similar to http://git.infradead.org/ users/segher/linux.git/commitdiff/ 98194f54cc8e19ecd752bc10e2d19ef94074f502 (note: only build-tested, not run-tested). See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday. Yeah saw that right after I hit send :-) Either it's way more complete than what I did, or way more complex because we still don't link with libgcc :-P Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1]460EX on-chip SATA driverresubmisison
Dear Josh Boyer, In message 20100630200325.gd7...@zod.rchland.ibm.com you wrote: The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to require it at build time. Isn't that something that needs fixing in the driver? Right. Next question is if this is really needed for this driver. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Copy from one, it's plagiarism; copy from two, it's research. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
On Thu, 1 Jul 2010 00:50:36 +0200 Segher Boessenkool seg...@kernel.crashing.org wrote: You probably also need something similar to http://git.infradead.org/ users/segher/linux.git/commitdiff/ 98194f54cc8e19ecd752bc10e2d19ef94074f502 (note: only build-tested, not run-tested). See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday. Yeah saw that right after I hit send :-) Either it's way more complete than what I did, or way more complex because we still don't link with libgcc :-P Actually, the 64bit versions of the routines are supplied by the linker, so the vmlinux links fine. But for modules, the final link is actually done by the kernel module loader, thus we need to provide those routines in this case. linking against libgcc would not have helped. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpMRjUn9Xd8e.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: kernel init exception
2010/7/1 Segher Boessenkool seg...@kernel.crashing.org: Maybe it was caused by floating exception.I found that,system received a program check exception,the reason for it was REASON_ILLEGAL. I also use show_regs to print the NIP in exception,it seemed that ,this exception was caused by 'vmhaddshs' instruction in user mode of init process . Is vmhaddshs avaliable on e500mc? My cross compile tool is gcc-4.1.2-glibc-2.5.0 This isn't vmhaddshs (which is an AltiVec instruction), but something else that also uses primary opcode 4. It sounds like your toolchain isn't set up correctly for e500mc. Segher I 've used cross_tool (powerpc_mc) that freescale provided, to compile the kernel image, and use an ordinary powerpc cross tool to compile busybox into cpio ramdisk. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday. Yeah saw that right after I hit send :-) Either it's way more complete than what I did, or way more complex because we still don't link with libgcc :-P Actually, the 64bit versions of the routines are supplied by the linker, so the vmlinux links fine. But for modules, the final link is actually done by the kernel module loader, thus we need to provide those routines in this case. linking against libgcc would not have helped. Right, so more complete it is :-) I now checked that patch in detail, and it looks good to me. Thank you for tackling this! Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops while running fs_racer test on a POWER6 box against latest git
While running fs_racer test from LTP on a POWER6 box against latest git(2.6.3 5-rc3-git4 - commitid 984bc9601f64fd) came across the following warning followed by multiple oops. [ cut here ] Badness at kernel/mutex-debug.c:64 NIP: c00be9e8 LR: c00be9cc CTR: REGS: c0010be8f6f0 TRAP: 0700 Not tainted (2.6.35-rc3-git4-autotest) MSR: 80029032EE,ME,CE,IR,DRCR: 24224422 XER: 0012 TASK = c0010727cf00[8211] 'fs_racer_file_c' THREAD: c0010be8bb50 CPU: 2 GPR00: c0010be8f970 c0d3d798 0001 GPR04: c0010be8fa70 c0010be8c000 c0010727d9f8 GPR08: c43042f0 c16534e8 017a c0c29a1c GPR12: 28228424 cf600500 c0010be8fc40 2000 GPR16: f000 c00109c73000 c0010be8fc30 00010442 GPR20: 01b6 c0010dd12250 GPR24: c017c08c c0010727cf00 c0010dd12278 c0010dd12210 GPR28: 0001 c0010be8c000 c0ca2008 c0010be8fa70 NIP [c00be9e8] .mutex_remove_waiter+0xa4/0x130 LR [c00be9cc] .mutex_remove_waiter+0x88/0x130 Call Trace: [c0010be8f970] [c0010be8fa00] 0xc0010be8fa00 (unreliable) [c0010be8fa00] [c064a9f0] .mutex_lock_nested+0x384/0x430 Instruction dump: e81f0010 e93d 7fa04800 41fe0028 482e96e5 6000 2fa3 419e0018 e93e8008 8009 2f80 409e00080fe0 e93e8000 8009 2f80 Unable to handle kernel paging request for unknown fault Faulting instruction address: 0xc008d0f4 Oops: Kernel access of bad area, sig: 7 [#1] SMP NR_CPUS=1024 NUMA Unrecoverable FP Unavailable Exception 800 at c0648ed4 pSeries last sysfs file: /sys/devices/system/cpu/cpu19/cache/index1/shared_cpu_map Modules linked in: ipv6 fuse loop dm_mod sr_mod cdrom ibmveth sg sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod NIP: c008d0f4 LR: c008d0d0 CTR: REGS: c0010978f900 TRAP: 0600 Tainted: GW(2.6.35-rc3-git4-a utotest) MSR: 80009032 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 Unrecoverable FP Unavailable Exception 800 at c0648ed4 EE,ME,IR,DRCR: 24022442 XER: 0012 DAR: c0648f54, DSISR: 4001 TASK = c001096e4900[7353] 'fs_racer_file_s' THREAD: c0010978c000 CPU: 10 GPR00: 4000 c0010978fb80 c0d3d798 0001 GPR04: c083539e c1610228 c54c6880 GPR08: 06a5 c0648f54 0007 049b GPR12: cf601900 GPR16: 4b7dc520 c0010978fea0 GPR20: 0fffcca7e7a0 0fffcca7e7a0 0fffabf7dfd0 0fffabf7dfd0 GPR24: 01200011 c0e1c0a8 c0648ed4 GPR28: c001096e4900 c0ca0458 c0010725d400 NIP [c008d0f4] .copy_process+0x310/0xf40 LR [c008d0d0] .copy_process+0x2ec/0xf40 Call Trace: [c0010978fb80] [c008d0d0] .copy_process+0x2ec/0xf40 (unreliable) [c0010978fc80] [c008deb4] .do_fork+0x190/0x3cc [c0010978fdc0] [c0011ef4] .sys_clone+0x58/0x70 [c0010978fe30] [c00087f0] .ppc_clone+0x8/0xc Instruction dump: 419e0010 7fe3fb78 480774cd 6000 801f0014 e93f0008 7800b842 39290080 78004800 6042 901f0014 380040007d6048a8 7d6b0078 7d6049ad 40c2fff4 Kernel version 2.6.34-rc3-git3 works fine. Should this read 2.6.35-rc3-git3? If so, there's only about 20 commits in: 5904b3b81d2516..984bc9601f64fd The likely fs related candidates are from Christoph and Nick Piggin (added to CC) No commits relating to POWER6 or PPC. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
