RE: 82xx performance
From: Arnd Bergmann [mailto:[EMAIL PROTECTED] On Thursday 17 July 2008, Rune Torgersen wrote: Arnd Bergmann wrote: So again, nothing conclusive. I'm running out of ideas. Is the syscall path different or the same on ppc and powerpc? Any differences in the task switching, irq handling or page fault handling? It's all different in suble ways, but those changes should only show up in the system time accounting, not user time accounting. I've been running the workload this board will see. On a 2.6.18 kernel %idle is ~50% and %wa (waiting for IO) is less than 1% most of the time. On 2.6.25, the idle% is lower (by about 10-15%) and the %wa is consistently hovering around 20-30% sometimes spiking to 100%. The workload involves quite a bit of socket IO (TCP, UDP, Unix Sockets and TIPC) and disk IO. Any easy way of finding what is causing the wait for IO? (Ive been trying to get lttng to work, but not any good results so far). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [HOW] binutils-2.17 breaks the 2.6.26 kernel
From: Segher Boessenkool Previous threads have mentioned that binutil-2.17 is broken for building powerpc kernels. It is fixed in binutils-2.18. I have a working (tested! thanks Milton) workaround for the current problem, will send it later today. This problem funnily is hidden by the presence of build-id :-) Did you ever send this patch? I'd like to try it as I cannot compile a arch/powerpc 2.6.265 kernel right now. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
Arnd Bergmann wrote: If you can't get it to work, readprofile(1) is a much simpler tool, both in what it can do and what it requires you to do. One thing that pops out is that handle_mm_fault uses twice as many ticks in arch/powerpc. Top 20 calls from readprofile 2.6.25 arch/ppc 305993 total 0.1295 53301 __flush_dcache_icache832.8281 25746 clear_pages 919.5000 19086 __copy_tofrom_user33.3671 17198 get_page_from_freelist13.3525 12741 _tlbia 353.9167 12317 handle_mm_fault8.9774 9669 handle_page_fault 75.5391 8037 do_page_fault 9.5225 6450 cpu_idle 25.1953 5430 update_mmu_cache 21.8952 4663 copy_page 32.3819 3712 __link_path_walk 0.8452 3302 find_vma 19.6548 3241 __do_fault 2.6741 3235 unmap_vmas 2.1741 3184 lru_cache_add_active 16.5833 3076 __alloc_pages 3.8450 3062 find_lock_page 9.8141 2826 zone_watermark_ok 16.0568 2593 put_page 6.8237 2.6.25 arch/powerpc 60982 cpu_idle 262.8534 54601 __flush_dcache_icache_phys 650.0119 25676 clear_pages 917. 24892 handle_mm_fault8.7772 19478 __copy_tofrom_user34.0524 18112 get_page_from_freelist12.3716 13245 _tlbia 367.9167 11976 do_page_fault 10.3241 10028 handle_page_fault 78.3438 6025 update_mmu_cache 23.5352 4650 page_address 15.7095 4097 copy_page 28.4514 4031 __do_fault 1.9838 3952 find_vma 27. 3861 __link_path_walk 0.9237 3533 unmap_vmas 2.2590 3400 lru_cache_add_active 19.3182 3317 find_lock_page11.0567 3238 __alloc_pages 4.5223 2825 zone_watermark_ok 16.8155 2740 __d_lookup 5.8547 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
Arnd Bergmann wrote: Seeing more hits in handle_mm_fault suggests that you have a higher page fault rate. A trivial reason for this might be that the amount of memory was misdetected in the new code (maybe broken device tree). What is the content of /proc/meminfo after a fresh boot? I also just realized that the /aprch/ppc was set up without high-mem support (using all 1G as lowmem), while the arch/powerpc was set up with hightmem. I'm retrying a compile without highmem support and 1 G lowmem on arch/powerpc now to see if it makes a difference. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
Arnd Bergmann wrote: Seeing more hits in handle_mm_fault suggests that you have a higher page fault rate. A trivial reason for this might be that the amount of memory was misdetected in the new code (maybe broken device tree). What is the content of /proc/meminfo after a fresh boot? Powerpc MemTotal: 1011296 kB MemFree:953884 kB Buffers: 20316 kB Cached: 25896 kB SwapCached: 0 kB Active: 26228 kB Inactive:25652 kB SwapTotal: 0 kB SwapFree:0 kB Dirty: 132 kB Writeback: 0 kB AnonPages:5684 kB Mapped: 2436 kB Slab: 2460 kB SReclaimable: 732 kB SUnreclaim: 1728 kB PageTables:208 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:505648 kB Committed_AS:11472 kB VmallocTotal: 474756 kB VmallocUsed: 8776 kB VmallocChunk: 465664 kB Ppc: MemTotal: 1011500 kB MemFree:954868 kB Buffers: 20696 kB Cached: 25044 kB SwapCached: 0 kB Active: 26816 kB Inactive:24588 kB SwapTotal: 0 kB SwapFree:0 kB Dirty: 124 kB Writeback: 0 kB AnonPages:5680 kB Mapped: 2456 kB Slab: 2056 kB SReclaimable: 736 kB SUnreclaim: 1320 kB PageTables:180 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:505748 kB Committed_AS:11468 kB VmallocTotal: 245696 kB VmallocUsed: 360 kB VmallocChunk: 245276 kB If it's the same, try running a kernel build with 'time --verbose', using GNU time instead of the bash builtin time to see how the page fault rate changed. Arch/powerpc Command being timed: make vmlinux User time (seconds): 4339.11 System time (seconds): 319.41 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 1:17:42 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 4213347 Voluntary context switches: 53543 Involuntary context switches: 90165 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 Arch/ppc Command being timed: make vmlinux User time (seconds): 4177.11 System time (seconds): 295.00 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 1:14:35 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 0 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 4203103 Voluntary context switches: 53812 Involuntary context switches: 85856 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
Arnd Bergmann wrote: So again, nothing conclusive. I'm running out of ideas. Is the syscall path different or the same on ppc and powerpc? Any differences in the task switching, irq handling or page fault handling? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Comiler error compiling 2.6.26
Segher Boessenkool wrote: Trying to cross-compile arch/powerpc for an freescale 8280: Gcc 4.1.2 Binutils 2.17 BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps previous sections [etc] Could you try with binutils 2.18? Not easilly, I would have to rebuild the cross compiler. I did try an older compiler (3.4.3 with binutils 2.15.94). That compiles but doesn't boot. If not, or if that doesn't help, we'll need to see your .config . # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26 # Tue Jul 15 17:52:27 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_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_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_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=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= # CONFIG_LOCALVERSION_AUTO is not set # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # 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 is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y 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 is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_PROC_PAGE_MONITOR=y 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 is not set 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 # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory CONFIG_CLASSIC_RCU=y # # Platform support # # CONFIG_PPC_MULTIPLATFORM is not set CONFIG_PPC_82xx=y # CONFIG_PPC_83xx is not set # CONFIG_PPC_86xx is not set # CONFIG_PPC_MPC512x is not set # CONFIG_PPC_MPC5121 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_MPC8272_ADS is not set # CONFIG_PQ2FADS is not set # CONFIG_EP8248E is not set CONFIG_INNSYS_APMAX=y # CONFIG_PQ2ADS is not set CONFIG_8260=y CONFIG_APMAX_PCI_INT=y CONFIG_INNSYS_CPU1=y # CONFIG_INNSYS_CPU2 is not set CONFIG_INNSYS_REV=0x20 CONFIG_INNSYS_DEVCOM_PTR=y CONFIG_INNSYS_DEVCOM_SIZE=24 CONFIG_INNSYS_BYPASS_TTY=y # CONFIG_IPIC is not set # CONFIG_MPIC is not set # CONFIG_MPIC_WEIRD is not set # CONFIG_PPC_I8259 is not set # CONFIG_PPC_RTAS is not set # CONFIG_MMIO_NVRAM is not set # CONFIG_PPC_MPC106 is not set # CONFIG_PPC_970_NAP is not set # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set CONFIG_CPM2=y
RE: 82xx performance
Arnd Bergmann wrote: On Tuesday 15 July 2008, Rune Torgersen wrote: Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile test I did is almost identical (within 1%) of what the arch/powerpc 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25 (I'll see if I can find an exact version, as I think my ppc port can be compiled for all versions from 2.6.18 to 25) You probably already know git-bisect, but if you don't, you should definitely give it a try. It's the best tool to find which patch exactly broke your performance. Turns out the story is no so simple. I redid the test wih all versions of arch/ppc from 2.6.18 to 2.6.26, and also arch/powerpc (2.6.24 and 25, 26 doesn't compile because of binutil issues) This time I made very sure that the tests were performed the same way, and I made a tabel showing relative performance: kernelcompile time rel context switch rel v2.6.18 01:13:33.70 1.00 7.21.00 v2.6.19 01:13:29.21 1.00 7.10.99 v2.6.20 01:13:29.58 1.00 2.80.39 v2.6.21 01:13:24.91 1.00 8.11.13 v2.6.22 01:13:42.72 1.00 4.50.63 v2.6.23 01:15:16.43 1.02 17 2.36 v2.6.24 01:15:30.90 1.03 20 2.78 v2.6.25 01:14:51.21 1.02 21 2.92 v2.6.26 01:14:34.76 1.01 23.8 3.31 v2.6.24-powerpc 01:17:41.99 1.06 25.8 3.58 v2.6.25-powerpc 01:18:10.10 1.06 35.7 4.96 This shows that arch/ppc no matter versin is fairly consistent in speed. Arch/powerpc is roughtly 6% worse. The contect swith column is found running lat_ctx 2 from lmbench3, and should be in microsecs. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
Arnd Bergmann wrote: Ok, I think this could be related mostly to two changes: * In 2.6.23, the process scheduler was replaced, the new one is the CFS, the 'completely fair scheduler'. This has changed a lot of data. To verify this, you could check out a git version just before and just after CFS went in. I'll check. Checking the context switch is fairly fast, so this is a goot time to learn bisect... * Obviously, the 6 percent change between ppc and powerpc should not be there. You can still try to use 'readprofile', or oprofile in timer based mode (i.e. without HW performance counters) to get some more data about where the time is spent on an identical kernel version. I did run oprofile, but I could not figure out how to get it to show me where in the kernel it was spending time. It showed that a lot of time was spent in vmlinux, but not anything specific. I probably just don't know how to set up or run oprofile correctly. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
9919_unit Linux 2.6.25 powerpc-linux-gnu 4343232 1. 1 9919_unit Linux 2.6.18 powerpc-linux-gnu 4453232 1.0100 1 Hmm, processor MHz is off by 11/445 I noticed that. And memory latency is off 13/500. That sounds like it will be 16/666. Are you using the same board and the same firmware? Yes. Same board, same firmware, same filesystem, just booted with different kernels. If so, look at /proc/cpuinfo and/or the boot log to see what frequency linux thinks the processor is running at. It sounds like someone introduced or fixed a rounding error error calculating the timebase frequency for your board. 2.6.18 /proc/cpuinfo processor : 0 cpu : G2_LE revision: 1.4 (pvr 8082 2014) bogomips: 296.96 chipset : 8250 vendor : Innovative Systems LLC machine : AP Gold mem size: 0x4000 console baud: 115200 core clock : 447 MHz CPM clock : 298 MHz bus clock : 99 MHz 2.6.25 /proc/cpuinfo processor : 0 cpu : G2_LE clock : 447.897600MHz revision: 1.4 (pvr 8082 2014) bogomips: 49.53 timebase: 24883200 platform: Innovative Systems ApMax Please try the sleep test: sleep for 100 seconds, and time with either a stopwatch or another system. I think you will find they take different amounts of time, and all the results need to be scaled. You might be able to see it reading the hardware clock. Sleep 100 takes excactly 100 seconds on both kernels (verified with stopwatch and external ntp server) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 82xx performance
* Maybe there is a kernel version that supports your hardware in both arch/ppc/ and arch/powerpc. In that case, you could see if the platform change had an impact. Using arch/ppc I got a 2.6.25 kernel to boot, and the kernel compile test I did is almost identical (within 1%) of what the arch/powerpc 2.6.25 did, so it seems to be a difference between 2.6.18 and 2.6.25 (I'll see if I can find an exact version, as I think my ppc port can be compiled for all versions from 2.6.18 to 25) And running oprofile didn't help much, as it seems not to have been able to figure out what in the kernel got called. (the Freescale 82xx dcoes not have hw performance registers) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Comiler error compiling 2.6.26
Trying to cross-compile arch/powerpc for an freescale 8280: Gcc 4.1.2 Binutils 2.17 BFD: ./vmlinux.strip.7812: section .text lma 0xc000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .ref.text lma 0xc024f000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .rodata lma 0xc0251000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .pci_fixup lma 0xc02dd2f0 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ksymtab lma 0xc02dd930 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ksymtab_gpl lma 0xc02e2088 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ksymtab_strings lma 0xc02e3a20 overlaps previous sections BFD: ./vmlinux.strip.7812: section __param lma 0xc02f08cc overlaps previous sections BFD: ./vmlinux.strip.7812: section __ex_table lma 0xc02f1000 overlaps previous sections BFD: ./vmlinux.strip.7812: section __bug_table lma 0xc02f22b8 overlaps previous sections BFD: ./vmlinux.strip.7812: section .init.text lma 0xc02f8000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .exit.text lma 0xc030f908 overlaps previous sections BFD: ./vmlinux.strip.7812: section .init.data lma 0xc0310468 overlaps previous sections BFD: ./vmlinux.strip.7812: section .init.setup lma 0xc0315b70 overlaps previous sections BFD: ./vmlinux.strip.7812: section .initcall.init lma 0xc0315e28 overlaps previous sections BFD: ./vmlinux.strip.7812: section .con_initcall.init lma 0xc0316050 overlaps previous sections BFD: ./vmlinux.strip.7812: section __ftr_fixup lma 0xc0316058 overlaps previous sections BFD: ./vmlinux.strip.7812: section .machine.desc lma 0xc0317000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data lma 0xc0318000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.init_task lma 0xc033 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.page_aligned lma 0xc0332000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.cacheline_aligned lma 0xc0335000 overlaps previous sections BFD: ./vmlinux.strip.7812: section .data.read_mostly lma 0xc0335820 overlaps previous sections ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH]: Check that TASK_SIZE does not overlap KERNEL_START
Make sure CONFIG_TASK_SIZE does not overlap CONFIG_KERNEL_START This could happen when overriding settings to get 1GB lowmem, and would lead to userland mysteriousely hanging. This setting is only used by PPC32. Signed-off-by Rune Torgersen [EMAIL PROTECTED] diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h index fd98ca9..72e0e3f 100644 --- a/include/asm-powerpc/processor.h +++ b/include/asm-powerpc/processor.h @@ -81,6 +81,10 @@ extern struct task_struct *last_task_used_altivec; extern struct task_struct *last_task_used_spe; #ifdef CONFIG_PPC32 + +#if CONFIG_TASK_SIZE CONFIG_KERNEL_START +#error User TASK_SIZE overlaps with KERNEL_START address +#endif #define TASK_SIZE (CONFIG_TASK_SIZE) /* This decides where the kernel will search for a free chunk of vm ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
Kumar Gala wrote: On May 21, 2008, at 4:24 PM, Rune Torgersen wrote: Kumar Gala wrote: On May 21, 2008, at 3:55 PM, Rune Torgersen wrote: Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. We should really add some sanity check on CONFIG_TASK_SIZE vs KERNEL_START. Something like this? Wording sould probablyy be a bit different/cleare. diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h index fd98ca9..72e0e3f 100644 --- a/include/asm-powerpc/processor.h +++ b/include/asm-powerpc/processor.h @@ -81,6 +81,10 @@ extern struct task_struct *last_task_used_altivec; extern struct task_struct *last_task_used_spe; #ifdef CONFIG_PPC32 + +#if CONFIG_TASK_SIZE CONFIG_KERNEL_START +#error User TASK_SIZE overlaps with KERNEL_START address +#endif #define TASK_SIZE (CONFIG_TASK_SIZE) /* This decides where the kernel will search for a free chunk of vm something like that would be good. is there really anything PPC32 specific about it? Probably not. Could this be done in the Kconfig file instead?. Don't know if Kconfig supports doing a comparison. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
FW: 1 GB lowmem
Kumar Gala wrote: On May 21, 2008, at 4:24 PM, Rune Torgersen wrote: Kumar Gala wrote: On May 21, 2008, at 3:55 PM, Rune Torgersen wrote: Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. We should really add some sanity check on CONFIG_TASK_SIZE vs KERNEL_START. Something like this? Wording sould probablyy be a bit different/cleare. diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h index fd98ca9..72e0e3f 100644 --- a/include/asm-powerpc/processor.h +++ b/include/asm-powerpc/processor.h @@ -81,6 +81,10 @@ extern struct task_struct *last_task_used_altivec; extern struct task_struct *last_task_used_spe; #ifdef CONFIG_PPC32 + +#if CONFIG_TASK_SIZE CONFIG_KERNEL_START +#error User TASK_SIZE overlaps with KERNEL_START address +#endif #define TASK_SIZE (CONFIG_TASK_SIZE) /* This decides where the kernel will search for a free chunk of vm something like that would be good. is there really anything PPC32 specific about it? Probably not. Could this be done in the Kconfig file instead?. Don't know if Kconfig supports doing a comparison. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
Kumar Gala wrote: something like that would be good. is there really anything PPC32 specific about it? Apparently. The Kconfig option is only available for arch/powerpc and arch/ppc, and the only place in the whole codetree where CONFIG_TASK_SIZE is used is that particular spot in asm-powerpc/processor.h, and that again is within CONFIG_PPC32 define, so it seems only PPC32 is using TASK_SIZE. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
1 GB lowmem
Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
[EMAIL PROTECTED] wrote: Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) Scratch that. 1 GB lowmem works with vanilla 2.6.25.4, but not at all with 2.6.25.4-rt[13] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
Rune Torgersen wrote: [EMAIL PROTECTED] wrote: Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) Scratch that. 1 GB lowmem works with vanilla 2.6.25.4, but not at all with 2.6.25.4-rt[13] Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. Highmem still doesn't work. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
Kumar Gala wrote: On May 21, 2008, at 3:55 PM, Rune Torgersen wrote: Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. We should really add some sanity check on CONFIG_TASK_SIZE vs KERNEL_START. Something like this? Wording sould probablyy be a bit different/cleare. diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h index fd98ca9..72e0e3f 100644 --- a/include/asm-powerpc/processor.h +++ b/include/asm-powerpc/processor.h @@ -81,6 +81,10 @@ extern struct task_struct *last_task_used_altivec; extern struct task_struct *last_task_used_spe; #ifdef CONFIG_PPC32 + +#if CONFIG_TASK_SIZE CONFIG_KERNEL_START +#error User TASK_SIZE overlaps with KERNEL_START address +#endif #define TASK_SIZE (CONFIG_TASK_SIZE) /* This decides where the kernel will search for a free chunk of vm ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Oops in fs_enet driver with preempt-rt
Hi
I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
8280 CPU (arch/powerpc)
I get the follwing oops when trying to enable ethernet:
(looks like a null pointer dereference in
drivers/net/fs_enet/fs_enet-main.c:106)
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0197efc
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c0197efc LR: c0197c48 CTR: c01986c4
REGS: df84de90 TRAP: 0300 Not tainted (2.6.25.4-rt1)
MSR: 9032 EE,ME,IR,DR CR: 42004022 XER:
DAR: , DSISR: 2000
TASK = df82ea70[7] 'sirq-net-rx/0' THREAD: df84c000
GPR00: e105a350 df84df40 df82ea70 df37f000 0011 c034ed90 c034ed70
GPR08: e105a340 0009 df80 0fffd000
0028
GPR16: 00400558 0080 df3e71e0 0011
GPR24: df37f000 fffb9e82 012c 0011
df37f5a0
NIP [c0197efc] fs_enet_rx_napi+0x2f0/0x3ac
LR [c0197c48] fs_enet_rx_napi+0x3c/0x3ac
Call Trace:
[df84df40] [c024a1b4] __spin_unlock+0x18/0x3c (unreliable)
[df84df80] [c01d9d28] net_rx_action+0x84/0x1ac
[df84dfa0] [c0022f18] ksoftirqd+0x158/0x25c
[df84dfd0] [c0033fa0] kthread+0x4c/0x88
[df84dff0] [c000fb34] kernel_thread+0x44/0x60
Instruction dump:
73202000 3b7b0008 41820008 837f00bc 813f00a0 7f03c378 81290034 7d2903a6
4e800421 7f96a000 409c00a8 7c0004ac a01b 0c00 4c00012c
5419043e
---[ end trace c548f7dabfe5b3de ]---
0xc0197efc is in fs_enet_rx_napi (include/asm/io.h:124).
119 DEF_MMIO_OUT(name, u##size, __stringify(insn)%U0%X0
%1,%0)
120 #define DEF_MMIO_OUT_LE(name, size, insn) \
121 DEF_MMIO_OUT(name, u##size, __stringify(insn) %1,0,%2)
122
123 DEF_MMIO_IN_BE(in_8, 8, lbz);
124 DEF_MMIO_IN_BE(in_be16, 16, lhz);
125 DEF_MMIO_IN_BE(in_be32, 32, lwz);
126 DEF_MMIO_IN_LE(in_le16, 16, lhbrx);
127 DEF_MMIO_IN_LE(in_le32, 32, lwbrx);
128
0xc0197c48 is in fs_enet_rx_napi
(drivers/net/fs_enet/fs_enet-main.c:106).
101 * These get messed up if we get called due to a busy
condition.
102 */
103 bdp = fep-cur_rx;
104
105 /* clear RX status bits for napi*/
106 (*fep-ops-napi_clear_rx_event)(dev);
107
108 while (((sc = CBDR_SC(bdp)) BD_ENET_RX_EMPTY) == 0) {
109 curidx = bdp - fep-rx_bd_base;
110
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Broken highmem support with preempt-rt
Hi When booting v2.6.25.4-rt1 (PREEMPT-RT) on my 8280 CPU with 1 GB RAM, I get the following oopses. They both are caused by a BUG_ON in kmap_atomic (include/asm-powerpc/highmem.h). If I boot with mem=512M or mem=768M they do not appear. Any help is greatly appreciated. Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c005e780 LR: c005e758 CTR: REGS: ef2c1d20 TRAP: 0700 Not tainted (2.6.25.4-rt1) MSR: 00029032 EE,ME,IR,DR CR: 48222482 XER: 2000 TASK = ef2a1a90[98] 'S21initenv' THREAD: ef2c GPR00: 3ffcf581 ef2c1dd0 ef2a1a90 c02cae8c 0002 0001 3ffcf580 GPR08: c037 c037000c 28222484 1009ecc0 100a5838 GPR16: 1009 1009 1009 ef2a7100 3ee38385 100955ac GPR24: ef2a4ef0 c27dc700 c27dcb80 0003 ef359040 c0334f88 NIP [c005e780] do_wp_page+0x650/0xc2c LR [c005e758] do_wp_page+0x628/0xc2c Call Trace: [ef2c1dd0] [c005e758] do_wp_page+0x628/0xc2c (unreliable) [ef2c1e10] [c0012420] do_page_fault+0x338/0x4b4 [ef2c1f40] [c0010120] handle_page_fault+0xc/0x80 --- Exception: 301 at 0x100322e0 LR = 0x100322dc Instruction dump: 409e0594 4810f2e1 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e 7d6b4a14 540007fa 30e0 7cc70110 0f06 3d20c035 3d40c035 8129b480 Oops: Exception in kernel mode, sig: 5 [#2] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c005db0c LR: c005dae4 CTR: REGS: ef29fd00 TRAP: 0700 Tainted: G D (2.6.25.4-rt1) MSR: 00029032 EE,ME,IR,DR CR: 48002482 XER: 2000 TASK = ef26e070[102] 'sed' THREAD: ef29e000 GPR00: 3ee2d581 ef29fdb0 ef26e070 c02cae8c 0001 3ee2d580 GPR08: c037 c037000c 0722 1009ecc0 4802dfa4 4802d878 GPR16: 0014f73c 0003 4802cce0 0001 0200 GPR24: ef3592e0 0ffece1c ef3592e0 ef2a50fc ef2a4df4 0003 c27dcfe0 c27ff4c0 NIP [c005db0c] __do_fault+0x1e0/0x804 LR [c005dae4] __do_fault+0x1b8/0x804 Call Trace: [ef29fdb0] [c005dae4] __do_fault+0x1b8/0x804 (unreliable) [ef29fe10] [c0012420] do_page_fault+0x338/0x4b4 [ef29ff40] [c0010120] handle_page_fault+0xc/0x80 --- Exception: 301 at 0x48017b10 LR = 0x48007ac8 Instruction dump: 409e060c 4810ff55 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e 7d6b4a14 540007fa 30e0 7cc70110 0f06 3d20c035 3d40c035 8129b480 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops in fs_enet driver with preempt-rt
Rune Torgersen wrote:
Hi
I am trying to get preempt-rt (v2.6.25.4-rt1) to work on a Freescale
8280 CPU (arch/powerpc)
I get the follwing oops when trying to enable ethernet:
(looks like a null pointer dereference in
drivers/net/fs_enet/fs_enet-main.c:106)
And if I disable NAPI I get this one instead:
Bringing up the eth1 interface...Unable to handle kernel paging request
for data at address 0x
Faulting instruction address: 0xc019706c
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c019706c LR: c0196d84 CTR: c0198790
REGS: ef2c3cb0 TRAP: 0300 Not tainted (2.6.25.4-rt1)
MSR: 9032 EE,ME,IR,DR CR: 42004222 XER:
DAR: , DSISR: 2000
TASK = ef2ac590[114] 'ifconfig' THREAD: ef2c2000
GPR00: ef2c3d60 ef2ac590 ef37f000 0008 ef2c3d5c
008c
GPR08: ef2c3d38 0008 ef2c3d40 0001 22000222 10021454
100a37b0
GPR16: 1009 ef3e71e0 ef3e71e0 1007 0008 100192c0
8914
GPR24: ef37f000 ef37f5a0 c0196d34 ef37f5a0 fff4
ef2973a0
NIP [c019706c] fs_enet_interrupt+0x338/0x5f4
LR [c0196d84] fs_enet_interrupt+0x50/0x5f4
Call Trace:
[ef2c3d60] [c024a270] __spin_unlock_irqrestore+0x20/0x4c (unreliable)
[ef2c3db0] [c0049a04] request_irq+0xb8/0xfc
[ef2c3de0] [c0198044] fs_enet_open+0x8c/0x210
[ef2c3e00] [c01d9b4c] dev_open+0x80/0xe8
[ef2c3e10] [c01d89ac] dev_change_flags+0xc8/0x19c
[ef2c3e30] [c021bfb0] devinet_ioctl+0x284/0x6f0
[ef2c3e90] [c021c8fc] inet_ioctl+0xc0/0xf4
[ef2c3ea0] [c01cbec4] sock_ioctl+0x200/0x23c
[ef2c3ec0] [c00810c0] vfs_ioctl+0x44/0xa8
[ef2c3ee0] [c0081520] do_vfs_ioctl+0x3fc/0x440
[ef2c3f10] [c00815a4] sys_ioctl+0x40/0x70
[ef2c3f40] [c000fcf0] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff6a37c
LR = 0xffecd58
Instruction dump:
7c0004ac b01c 72e02000 3b9c0008 41820008 839d00bc 813d00a0 7f03c378
81290034 7d2903a6 4e800421 7c0004ac a01c 0c00 4c00012c
5417043e
---[ end trace 61ff5e5c97ddf707 ]---
Seems to be caused by line 471 in fs_enet_main:
0xc0196d84 is in fs_enet_interrupt
(drivers/net/fs_enet/fs_enet-main.c:473).
468 if (fpi-use_napi)
469 int_clr_events = ~fep-ev_napi_rx;
470
471 (*fep-ops-clear_int_events)(dev,
int_clr_events);
472
473 if (int_events fep-ev_err)
474 (*fep-ops-ev_error)(dev, int_events);
475
476 if (int_events fep-ev_rx) {
477 if (!fpi-use_napi)
(gdb)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops in fs_enet driver with preempt-rt
Scott Wood wrote:
Rune Torgersen wrote:
0xc0196d84 is in fs_enet_interrupt
(drivers/net/fs_enet/fs_enet-main.c:473).
468 if (fpi-use_napi)
469 int_clr_events = ~fep-ev_napi_rx;
470 471 (*fep-ops-clear_int_events)(dev,
int_clr_events); 472
473 if (int_events fep-ev_err)
474 (*fep-ops-ev_error)(dev,
int_events); 475 476 if (int_events
fep-ev_rx) { 477 if (!fpi-use_napi)
(gdb)
Do you have shared interrupt debugging turned on? That breaks this
driver, and a patch to remove the shared flag was nacked in favor of
actually fixing the driver, which I haven't gotten around to.
-Scott
Thanks!!
That worked. Now I just have to get highmem support...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops in fs_enet driver with preempt-rt
Scott Wood wrote: Rune Torgersen wrote: Hmm ttyCPM1 output seems to be kinda garbled... Any ideas? Incomplete locking between printk and userland use of ttyCPM1 as console? s/incomplete/nonexistent/ :-P Try acquiring port-lock in cpm_uart_console_write. -Scott That worked. Console output is sane again. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops in fs_enet driver with preempt-rt
Kumar Gala wrote: Rune Torgersen wrote: That worked. Console output is sane again. I'm hoping to see some patches related to these fixes :) Working on it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix cpm uart corruption with PREEMPT_RT
Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT. Userland usage of console, and kernel printf's were stepping on each others toes. Signed-off-by: Rune Torgersen [EMAIL PROTECTED] diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c index fb93403..79c109d 100755 --- a/drivers/serial/cpm_uart/cpm_uart_core.c +++ b/drivers/serial/cpm_uart/cpm_uart_core.c @@ -1214,7 +1214,9 @@ static void cpm_uart_console_write(struct console *co, const char *s, unsigned int i; cbd_t __iomem *bdp, *bdbase; unsigned char *cp; + unsigned long flags; + spin_lock_irqsave(pinfo-port.lock, flags); /* Get the address of the host memory buffer. */ bdp = pinfo-tx_cur; @@ -1282,6 +1284,8 @@ static void cpm_uart_console_write(struct console *co, const char *s, ; pinfo-tx_cur = bdp; + + spin_unlock_irqrestore(pinfo-port.lock, flags); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix pq2fads irq handling with PREEMPT_RT
Fix interrupt threading issue on pq2fads when running with CONFIG_PREEMPT_RT
Signed-off-by: Rune Torgersen [EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
index a801381..9876d7e 100644
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -109,7 +109,7 @@ static int pci_pic_host_map(struct irq_host *h, unsigned
int virq,
{
get_irq_desc(virq)-status |= IRQ_LEVEL;
set_irq_chip_data(virq, h-host_data);
- set_irq_chip(virq, pq2ads_pci_ic);
+ set_irq_chip_and_handler(virq, pq2ads_pci_ic, handle_level_irq);
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] Fix cpm uart corruption with PREEMPT_RT
Scott Wood wrote: On Tue, May 20, 2008 at 02:28:16PM -0500, Rune Torgersen wrote: Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT. Userland usage of console, and kernel printf's were stepping on each others toes. We should bypass the lock when oops_in_progress is set, something like: Ok, will respin. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix cpm uart corruption with PREEMPT_RT
Fix CPM serial port corruption when running with CONFIG_PREEMPT_RT.
Userland usage of console, and kernel printf's were stepping on each others
toes.
Also only take lock if not in an oops.
Signed-off-by: Rune Torgersen [EMAIL PROTECTED]
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index fb93403..11bee62 100755
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1214,6 +1214,14 @@ static void cpm_uart_console_write(struct console *co,
const char *s,
unsigned int i;
cbd_t __iomem *bdp, *bdbase;
unsigned char *cp;
+ unsigned long flags;
+ int nolock = oops_in_progress;
+
+ if (unlikely(nolock)) {
+ local_irq_save(flags);
+ } else {
+ spin_lock_irqsave(pinfo-port.lock, flags);
+ }
/* Get the address of the host memory buffer.
*/
@@ -1282,6 +1290,12 @@ static void cpm_uart_console_write(struct console *co,
const char *s,
;
pinfo-tx_cur = bdp;
+
+ if (unlikely(nolock)) {
+ local_irq_restore(flags);
+ } else {
+ spin_unlock_irqrestore(pinfo-port.lock, flags);
+ }
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Oops with PREEMPT-RT on 2.6.25.4
Hi I get the following oops when trying to boot a arch/powerpc kernel with preempt-rt installed (v2.6.25.4-rt1) The board is using a Freescale 8280 as the main CPU and a Silicon Image SII3124 SATA controller. The oops seems to happen on fileaccess right after init starts. I need ideas what to look for. Freeing unused kernel memory: 128k init INIT: version 2.85 booting Activating all swap files/partitions... [ OK ] Mounting proc file system...[ OK ] path=/bin:/usr/bin:/sbin:/usr/sbin Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c0249618 LR: c02495ec CTR: REGS: ef29d550 TRAP: 0700 Not tainted (2.6.25.4-rt1) MSR: 00021032 ME,IR,DR CR: 24044482 XER: TASK = ef26d070[50] 'ldconfig' THREAD: ef29c000 GPR00: 0001 ef29d600 ef26d070 ef29d64c 008c GPR08: ef29d628 ef29d630 ef29c000 100b5eec 100b GPR16: c00c3304 ef29dc48 000c 0014 0001 ef3818c0 GPR24: ef8a4000 0011 c01bc3c4 ef29d698 ef381904 9032 c0354700 NIP [c0249618] rt_spin_lock_slowlock+0x9c/0x200 LR [c02495ec] rt_spin_lock_slowlock+0x70/0x200 Call Trace: [ef29d600] [c02495ec] rt_spin_lock_slowlock+0x70/0x200 (unreliable) [ef29d670] [c00277d0] lock_timer_base+0x2c/0x64 [ef29d690] [c00285e8] del_timer+0x2c/0x78 [ef29d6b0] [c019d108] scsi_delete_timer+0x1c/0x3c [ef29d6d0] [c01992d0] scsi_done+0x18/0x4c [ef29d6f0] [c01b19dc] ata_scsi_qc_complete+0x364/0x380 [ef29d720] [c01a8708] __ata_qc_complete+0xd8/0xec [ef29d740] [c01b011c] ata_qc_complete_multiple+0xc4/0xec [ef29d760] [c01bcaf4] sil24_interrupt+0x46c/0x52c [ef29d7a0] [c0048954] handle_IRQ_event+0x64/0x100 [ef29d7d0] [c0048b30] __do_IRQ+0x140/0x1bc [ef29d7f0] [c00166c4] apmax_int_irq_demux+0x8c/0xb0 [ef29d810] [c0006448] do_IRQ+0x68/0xa8 [ef29d820] [c0010388] ret_from_except+0x0/0x14 --- Exception: 501 at __spin_unlock_irqrestore+0x28/0x4c LR = __spin_unlock_irqrestore+0x20/0x4c [ef29d8f0] [c0249600] rt_spin_lock_slowlock+0x84/0x200 [ef29d960] [c00277d0] lock_timer_base+0x2c/0x64 [ef29d980] [c002790c] __mod_timer+0x34/0xdc [ef29d9b0] [c0154650] blk_plug_device+0x58/0x68 [ef29d9c0] [c0154db0] __make_request+0x2dc/0x34c [ef29da00] [c0153aa4] generic_make_request+0x20c/0x238 [ef29da40] [c01550a8] submit_bio+0x124/0x138 [ef29da80] [c009a490] submit_bh+0x13c/0x174 [ef29daa0] [c009df9c] __bread+0xa4/0x100 [ef29dab0] [c00c2478] ext3_get_branch+0x78/0xfc [ef29dae0] [c00c27dc] ext3_get_blocks_handle+0x94/0x9cc [ef29dba0] [c00c3398] ext3_get_block+0x94/0xdc [ef29dbd0] [c00a458c] do_mpage_readpage+0x1a4/0x63c [ef29dc40] [c00a4b58] mpage_readpages+0xc4/0x11c [ef29dd20] [c00c269c] ext3_readpages+0x24/0x34 [ef29dd30] [c00572e4] __do_page_cache_readahead+0x1a0/0x258 [ef29dd70] [c00512bc] filemap_fault+0x198/0x41c [ef29ddb0] [c005d934] __do_fault+0x6c/0x804 [ef29de10] [c0012420] do_page_fault+0x338/0x4b4 [ef29df40] [c0010120] handle_page_fault+0xc/0x80 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops with PREEMPT-RT on 2.6.25.4
Scott Wood wrote: Rune Torgersen wrote: Hi I get the following oops when trying to boot a arch/powerpc kernel with preempt-rt installed (v2.6.25.4-rt1) The board is using a Freescale 8280 as the main CPU and a Silicon Image SII3124 SATA controller. The oops seems to happen on fileaccess right after init starts. [snip] NIP [c0249618] rt_spin_lock_slowlock+0x9c/0x200 LR [c02495ec] rt_spin_lock_slowlock+0x70/0x200 Call Trace: [ef29d600] [c02495ec] rt_spin_lock_slowlock+0x70/0x200 (unreliable) [ef29d670] [c00277d0] lock_timer_base+0x2c/0x64 [ef29d690] [c00285e8] del_timer+0x2c/0x78 [ef29d6b0] [c019d108] scsi_delete_timer+0x1c/0x3c [ef29d6d0] [c01992d0] scsi_done+0x18/0x4c [ef29d6f0] [c01b19dc] ata_scsi_qc_complete+0x364/0x380 [ef29d720] [c01a8708] __ata_qc_complete+0xd8/0xec [ef29d740] [c01b011c] ata_qc_complete_multiple+0xc4/0xec [ef29d760] [c01bcaf4] sil24_interrupt+0x46c/0x52c [ef29d7a0] [c0048954] handle_IRQ_event+0x64/0x100 [ef29d7d0] [c0048b30] __do_IRQ+0x140/0x1bc [ef29d7f0] [c00166c4] apmax_int_irq_demux+0x8c/0xb0 [ef29d810] [c0006448] do_IRQ+0x68/0xa8 [ef29d820] [c0010388] ret_from_except+0x0/0x14 --- Exception: 501 at __spin_unlock_irqrestore+0x28/0x4c LR = __spin_unlock_irqrestore+0x20/0x4c [ef29d8f0] [c0249600] rt_spin_lock_slowlock+0x84/0x200 [ef29d960] [c00277d0] lock_timer_base+0x2c/0x64 You're recursively entering lock_timer_base, which does a spin_lock_irqsave(). Either interrupts are enabled when they should not be, or an interrupt was supposed to be threaded that isn't. Sort of figured. How do I figure out which one, and how to fix it? I've never gotten any -rt patchsets to work on this CPU, and it always seems to be related to the disk driver. I've tried since 2.6.16 ppc (2.6.16, 2.6.18 on ppc, 2.6.24 and 25 on powerpc) Even though this is a custom board, I'm pretty sure I can get it to fail on a pq2fads board with the same disk controller. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops with PREEMPT-RT on 2.6.25.4
Scott Wood wrote: Almost certainly the latter. Is the disk interrupt shared with any other interrupts, that are marked IRQF_NODELAY? The -rt patch doesn't seem to handle mixing the two well. Disk is on a muxed PCI interrupt. None of the other interrupts on the mux is fireing at the time. Is is possible that the demuxer is not set up right? It is based loosely on pq2-pci-pic.c Oh, and just to be sure: you do have CONFIG_PREEMPT_RT turned on, and not just CONFIG_PREEMPT, right? The non-preempt-rt versions in the -rt patch don't look like they disable interrupts, though I may just be getting lost in a sea of underscores and ifdefs. Full CONFIG_PREEMPT_RT. I was actually going to try CONFIG_PREEMPT to see if anything helped. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops with PREEMPT-RT on 2.6.25.4
Scott Wood wrote: Try calling irq_set_chip_and_handler() with handle_level_irq, rather than irq_set_chip(). The -rt patch doesn't seem to have threadified the __do_IRQ() path. The demuxer is setting itself up with set_irq_chained handler(), any pointers on how to change to irq_set_chip_and_handler()? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops with PREEMPT-RT on 2.6.25.4
Scott Wood wrote: Rune Torgersen wrote: Scott Wood wrote: Try calling irq_set_chip_and_handler() with handle_level_irq, rather than irq_set_chip(). The -rt patch doesn't seem to have threadified the __do_IRQ() path. The demuxer is setting itself up with set_irq_chained handler(), any pointers on how to change to irq_set_chip_and_handler()? No, I mean the call to set_irq_chip() in pci_pic_host_map() where it sets up the IRQs it manages, not the cascade IRQ itself. Thanks!!! That fixed that particular problem. Of course I then ran headfirst into another one This one seems to happen when I attempt to read flash through an mtd driver. Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c005e780 LR: c005e758 CTR: REGS: ef2c1d20 TRAP: 0700 Not tainted (2.6.25.4-rt1) MSR: 00029032 EE,ME,IR,DR CR: 48222482 XER: 2000 TASK = ef2a1a90[98] 'S21initenv' THREAD: ef2c GPR00: 3ffcf581 ef2c1dd0 ef2a1a90 c02cae8c 0002 0001 3ffcf580 GPR08: c037 c037000c 28222484 1009ecc0 100a5838 GPR16: 1009 1009 1009 ef2a7100 3ee38385 100955ac GPR24: ef2a4ef0 c27dc700 c27dcb80 0003 ef359040 c0334f88 NIP [c005e780] do_wp_page+0x650/0xc2c LR [c005e758] do_wp_page+0x628/0xc2c Call Trace: [ef2c1dd0] [c005e758] do_wp_page+0x628/0xc2c (unreliable) [ef2c1e10] [c0012420] do_page_fault+0x338/0x4b4 [ef2c1f40] [c0010120] handle_page_fault+0xc/0x80 --- Exception: 301 at 0x100322e0 LR = 0x100322dc Instruction dump: 409e0594 4810f2e1 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e 7d6b4a14 540007fa 30e0 7cc70110 0f06 3d20c035 3d40c035 8129b480 Oops: Exception in kernel mode, sig: 5 [#2] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c005db0c LR: c005dae4 CTR: REGS: ef29fd00 TRAP: 0700 Tainted: G D (2.6.25.4-rt1) MSR: 00029032 EE,ME,IR,DR CR: 48002482 XER: 2000 TASK = ef26e070[102] 'sed' THREAD: ef29e000 GPR00: 3ee2d581 ef29fdb0 ef26e070 c02cae8c 0001 3ee2d580 GPR08: c037 c037000c 0722 1009ecc0 4802dfa4 4802d878 GPR16: 0014f73c 0003 4802cce0 0001 0200 GPR24: ef3592e0 0ffece1c ef3592e0 ef2a50fc ef2a4df4 0003 c27dcfe0 c27ff4c0 NIP [c005db0c] __do_fault+0x1e0/0x804 LR [c005dae4] __do_fault+0x1b8/0x804 Call Trace: [ef29fdb0] [c005dae4] __do_fault+0x1b8/0x804 (unreliable) [ef29fe10] [c0012420] do_page_fault+0x338/0x4b4 [ef29ff40] [c0010120] handle_page_fault+0xc/0x80 --- Exception: 301 at 0x48017b10 LR = 0x48007ac8 Instruction dump: 409e060c 4810ff55 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e 7d6b4a14 540007fa 30e0 7cc70110 0f06 3d20c035 3d40c035 8129b480 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Oops with PREEMPT-RT on 2.6.25.4
Rune Torgersen wrote: Scott Wood wrote: Of course I then ran headfirst into another one This one seems to happen when I attempt to read flash through an mtd driver. Both if these is hitting a BUG_ON in kmap_atomic (include/asm-powerpc/highmem.h) Oops: Exception in kernel mode, sig: 5 [#1] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c005e780 LR: c005e758 CTR: REGS: ef2c1d20 TRAP: 0700 Not tainted (2.6.25.4-rt1) MSR: 00029032 EE,ME,IR,DR CR: 48222482 XER: 2000 TASK = ef2a1a90[98] 'S21initenv' THREAD: ef2c GPR00: 3ffcf581 ef2c1dd0 ef2a1a90 c02cae8c 0002 0001 3ffcf580 GPR08: c037 c037000c 28222484 1009ecc0 100a5838 GPR16: 1009 1009 1009 ef2a7100 3ee38385 100955ac GPR24: ef2a4ef0 c27dc700 c27dcb80 0003 ef359040 c0334f88 NIP [c005e780] do_wp_page+0x650/0xc2c LR [c005e758] do_wp_page+0x628/0xc2c Call Trace: [ef2c1dd0] [c005e758] do_wp_page+0x628/0xc2c (unreliable) [ef2c1e10] [c0012420] do_page_fault+0x338/0x4b4 [ef2c1f40] [c0010120] handle_page_fault+0xc/0x80 --- Exception: 301 at 0x100322e0 LR = 0x100322dc Instruction dump: 409e0594 4810f2e1 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e 7d6b4a14 540007fa 30e0 7cc70110 0f06 3d20c035 3d40c035 8129b480 Oops: Exception in kernel mode, sig: 5 [#2] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c005db0c LR: c005dae4 CTR: REGS: ef29fd00 TRAP: 0700 Tainted: G D (2.6.25.4-rt1) MSR: 00029032 EE,ME,IR,DR CR: 48002482 XER: 2000 TASK = ef26e070[102] 'sed' THREAD: ef29e000 GPR00: 3ee2d581 ef29fdb0 ef26e070 c02cae8c 0001 3ee2d580 GPR08: c037 c037000c 0722 1009ecc0 4802dfa4 4802d878 GPR16: 0014f73c 0003 4802cce0 0001 0200 GPR24: ef3592e0 0ffece1c ef3592e0 ef2a50fc ef2a4df4 0003 c27dcfe0 c27ff4c0 NIP [c005db0c] __do_fault+0x1e0/0x804 LR [c005dae4] __do_fault+0x1b8/0x804 Call Trace: [ef29fdb0] [c005dae4] __do_fault+0x1b8/0x804 (unreliable) [ef29fe10] [c0012420] do_page_fault+0x338/0x4b4 [ef29ff40] [c0010120] handle_page_fault+0xc/0x80 --- Exception: 301 at 0x48017b10 LR = 0x48007ac8 Instruction dump: 409e060c 4810ff55 3d20c035 1fa3000f 8129b140 3bbd0003 57ab103a 7c0b482e 7d6b4a14 540007fa 30e0 7cc70110 0f06 3d20c035 3d40c035 8129b480 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/2] [MTD] Add support for RAM ROMmappings in the physmap_of MTD driver.
Laurent Pinchart wrote: Last thing I heard was that the device tree should not encode a device's expected usage, so memory nodes should not have any compatible property that would automatically associated them to an MTD driver. I've been adviced to add platform-specific code to instantiate a platform device manually (possibly checking if the required memory node is present in the device tree). This arguably makes sense, but adds more platform-specific code. So... What good it the device tree at all then, if intended usage should not be encoded in there. Most other devices has an intended usage encoded. Examples would be the FCC's on a Freescale PQ2 chip, where they are encoded as ethernet controllers. (Thsy could be used as high-speed HDLC controllers, ATM controllers and other usages), the SCC ports (as serial, they can be used for syncronous serial and HDLC) That would also mean if usage would change, the kernel image (and possiby u-boot) whould have to change, instead of just fixing the device tree. Argh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in thedevice tree.
Scott Wood wrote: 0x2000 minus sizeof(...) would be a good default for CPM1 and CPM2 (8280 has its first chunk go up to 0x4000, but for some reason that didn't get reflected in the dts for the one 8280 board in-tree). Except that last time I tested it, it is not from 0 - 0x4000, but the extra 0x2000 is added from offset 0x9000. So 8280 has available muram from 0 - 0x2000 and 0x9000 - 0xb000 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCHv2 2/3] ep8248e: Reference SMC parameter RAM base in thedevice tree.
Scott Wood wrote: Rune Torgersen wrote: Scott Wood wrote: 0x2000 minus sizeof(...) would be a good default for CPM1 and CPM2 (8280 has its first chunk go up to 0x4000, but for some reason that didn't get reflected in the dts for the one 8280 board in-tree). Except that last time I tested it, it is not from 0 - 0x4000, but the extra 0x2000 is added from offset 0x9000. So 8280 has available muram from 0 - 0x2000 and 0x9000 - 0xb000 According to the docs, it has 0 - 0x4000 and 0x9000 - 0xc000. I tried it on out 8280 board inhouse, and any addresses from 0x2000 to 0x3fff does not work with at least the MCC's. (running ss7 with the extended ss7 microcode) If I only used 0-0x2000 and 0x9000 to 0xB000 then it is happy. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 0/2] Add support for RAM ROM mappings to the physmap_of driver
Laurent Pinchart wrote: Hi everybody, these two patches add support for memory-mapped RAM ROM chips to the physmap_of MTD driver. Whole series acked-by: Rune Torgersen [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
Laurent Pinchart wrote: On Tuesday 25 March 2008 17:27, Rune Torgersen wrote: Laurent Pinchart wrote: On Tuesday 25 March 2008 17:03, Scott Wood wrote: Yes, I've answered questions on the lists from at least one person using a custom board with cpm2 smc. Are you sure it wasn't me ? ;-) Probably me, actually. We have a 8280 with SMC's in use (SMC1 and 2) Do you have any opinion about the proposed patch ? That is about time... :) I've never really liked that the smc driver in the kernel relies on parts of the SMC port to be set up by the boot-loader. It really bit us when we were porting to 2.6.24, and was trying to enable SMC2, since it was not used by u-boot as a console port, the pram was uninitialized, and the linux driver then completely borked both smc's. This should take care of that, it looks like. No driver should rely on the boot loader to initialize the device... (With the exception of pin mappinmgs, PCI and memory...) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: OF compatible MTD platform RAM driver ?
Laurent Pinchart wrote: On Tuesday 25 March 2008 18:02, Sergei Shtylyov wrote: Laurent Pinchart wrote: Regarding non-volatility nothing prevents a user from using a volatile RAM as an MTD device, but there's little point in doing so. Would it be acceptable for the linear-nvram specification not to include volatile RAM ? ROM chips would be excluded too. Is that an issue ? We actually use a volatile ram (SRAM) as an MTD device. We use it to store info from bootloader and system specific values between resets. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: OF compatible MTD platform RAM driver ?
David Gibson wrote: On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote: We ran ito the same issue. We did option 3, as it was efinetly the easiest, I think this is the best option in principle. here is the sram entry in our dts: Except that your implementation of it is not good. You're relying on the old obsolete flash binding with the probe-type field. The solution should be adapted to the new approach which uses values in the compatible field to indicate various sorts of flash device. Yea, I know. But it was the easiest way of doing it at the time we did our port In a timecrunch, easier is sometimes better than correct. :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: OF compatible MTD platform RAM driver ?
[EMAIL PROTECTED] wrote:
Hi everybody,
as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
looking for an
OpenFirmware compatible way to handle a RAM-based MTD device.
On the platform_device based ppc architecture, the
drivers/mtd/maps/plat-ram.c
driver handled mtd-ram platform devices. There is no such
driver for the
OF-based powerpc architecture.
As a temporary workaround I hacked the physmap_of driver to
handle direct-mapped OF devices oh type ram by adding a
corresponding entry in the of_flash_match[] array. This seems to work
fine.
What would be the preferred way to handle OF-compatible RAM-based MTD
devices ? The 3 ways I can think of are
1. porting the plat-ram driver to OF (the driver isn't used
in the kernel tree
but I suspect it is used by out-of-tree boards)
2. creating a new plat-ram-of driver, much like the
physmap_of driver comes
from the physmap driver
3. extending the physmap_of driver to handle RAM devices (in
which case
references to flash in the function names should probably
be replaced
by mtd)
I live option 3 better so far.
Has anyone already worked on this ? Is there any defined
device tree mapping
for MTD RAM devices ?
Best regards,
We ran ito the same issue.
We did option 3, as it was efinetly the easiest,
here is the sram entry in our dts:
[EMAIL PROTECTED],0 {
device_type = rom;
compatible = direct-mapped;
probe-type = RAM;
reg = 9 0 2;
bank-width = 2;
device-width = 2;
#address-cells = 1;
#size-cells = 1;
[EMAIL PROTECTED] {
label = SRAM;
reg = 0 2;
};
here is the change to physmap_of.c:
diff --git a/drivers/mtd/maps/physmap_of.c
b/drivers/mtd/maps/physmap_of.c
old mode 100644
new mode 100755
index aeed9ea..687ef54
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -201,6 +201,8 @@ static struct mtd_info * __devinit
obsolete_probe(struct of_device *dev,
return do_map_probe(cfi_probe, map);
} else if (strcmp(of_probe, JEDEC) == 0) {
return do_map_probe(jedec_probe, map);
+ } else if (strcmp(of_probe, RAM) == 0) {
+ return do_map_probe(map_ram, map);
} else {
if (strcmp(of_probe, ROM) != 0)
dev_warn(dev-dev, obsolete_probe: don't know
probe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
pdflush weirdness
Hi While trying to find what is causing some hickups on our Freescale 8280 based system (ppc 603e core), i've found that pdflush is causing us some grief. The system is runnign at 450MHz, have 1GB of memory, and we see the same issue on 2.6.18 (arch/ppc) and 2.6.24.3 (arch/powerpc) Filesystem is ext3, but we also see it using ext2. (have not tried any other fs, but suspect the same result) Disk is a SATAII Hitachi drive connected to a SiliconImage 3124 controller. Basically we have a testprogram that (re)writes a 80k file to a random directory. There are 5 target directories. Directory tree has 5000 top level directories, and 10 direcories under each one. Average opens take around 100ms Average writes take 2ms Average close/fflush takes mostly 2ms but also a significant number around 100ms. Once in a while (sometimes 30seconds sometimes longer) a open or a close takes 2-3 seconds. if I disable pdflush (echo 0 /proc/sys/vm/dirty_writeback_centisecs) I see no accesses larger than 400 ms, and most writes/closes are 10ms. Opens stay at 100ms (expected as seek time of hd comes into play) When the pdflush delays occur, the whole system seems to be unresponsive. If we have the same number of direcories, but only access a subset of 2-300 of the directories, we never see this happening. (Max time is then comparable to pdflush off) The system is basically a voicemail storage system, and this causes us problems, as it causes several second long timeouts in processing. 1) Is there any reason that we cannot run with pdflush permanetly disabled (probably a bad idea...) 2) Are there any thing we can tune to make the system NOT have these hickups? I've also been trying to get PREEMPT_RT patches to work on our 2.6.24 kernel, but it blows up when doing the first diskaccess. (getting a BUG_ON in rtmutex.c, line 691) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: locking problem in sata_sil24?
[EMAIL PROTECTED] wrote:
Now I get an inconsistent locking state, but I need help in
trying to
fiure out what I should look for.
I did figure out htat lockdep only complains about inonsistent locking
state when PREEMPT_RT paches are applied.
Now I just need some help interpreting this output so I can find what
lock and why it is inconsitent.
I _really_ want to run the rt patches...
=
[ INFO: inconsistent lock state ]
[ 2.6.24-rt1 #12
-
inconsistent {hardirq-on-W} - {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(host-lock){+-..}, at: [c01c8e14] sil24_interrupt+0x68/0x53c
{hardirq-on-W} state was registered at:
[c0047724] __lock_acquire+0x494/0xc04
[c0047ee8] lock_acquire+0x54/0x78
[c025c8f0] rt_spin_lock+0x34/0x54
[c01b45ac] ata_dev_init+0x38/0x88
[c01b467c] ata_link_init+0x80/0xa4
[c01b4840] ata_port_alloc+0x1a0/0x1bc
[c01b48f4] ata_host_alloc+0x98/0xf8
[c01b4974] ata_host_alloc_pinfo+0x20/0x104
[c01c83b4] sil24_init_one+0x128/0x390
[c01802f0] pci_device_probe+0x70/0xa8
[c0197d10] driver_probe_device+0x104/0x1ac
[c0197e0c] __driver_attach+0x54/0x8c
[c0197030] bus_for_each_dev+0x58/0xa0
[c0197adc] driver_attach+0x2c/0x44
[c0197778] bus_add_driver+0xb4/0x1b8
[c01980b8] driver_register+0x7c/0x114
[c01803bc] __pci_register_driver+0x60/0x78
[c031e620] sil24_init+0x2c/0x44
[c030a2c8] kernel_init+0xdc/0x334
[c0010408] kernel_thread+0x44/0x60
irq event stamp: 16174
hardirqs last enabled at (16173): [c0046d18]
trace_hardirqs_on+0x1c/0x34
hardirqs last disabled at (16174): [c0045554]
trace_hardirqs_off+0x1c/0x34
softirqs last enabled at (0): [] 0x0
softirqs last disabled at (0): [] 0x0
other info that might help us debug this:
no locks held by swapper/0.
stack backtrace:
Call Trace:
[c0357ca0] [c0008474] show_stack+0x54/0x18c (unreliable)
[c0357cd0] [c00085cc] dump_stack+0x20/0x38
[c0357ce0] [c00460a0] print_usage_bug+0x130/0x14c
[c0357d10] [c0046674] mark_lock+0xf0/0x4ec
[c0357d30] [c004769c] __lock_acquire+0x40c/0xc04
[c0357d80] [c0047ee8] lock_acquire+0x54/0x78
[c0357da0] [c025c8f0] rt_spin_lock+0x34/0x54
[c0357dc0] [c01c8e14] sil24_interrupt+0x68/0x53c
[c0357e00] [c00529e0] handle_IRQ_event+0x6c/0x114
[c0357e30] [c0052bcc] __do_IRQ+0x144/0x1c4
[c0357e50] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[c0357e70] [c00063f0] do_IRQ+0x6c/0xb0
[c0357e80] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at check_critical_timing+0x184/0x190
LR = check_critical_timing+0x15c/0x190
[c0357f80] [c00519a4] touch_critical_timing+0x5c/0xb0
[c0357fa0] [c00096c4] cpu_idle+0xe4/0x124
[c0357fb0] [c0003bcc] rest_init+0x78/0xac
[c0357fc0] [c030ab9c] start_kernel+0x2c4/0x2dc
[c0357ff0] [3438] 0x3438
[ cut here ]
kernel BUG at kernel/rtmutex.c:692!
Oops: Exception in kernel mode, sig: 5 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in:
NIP: c025c340 LR: c025c318 CTR: c01c8dac
REGS: ef859ad0 TRAP: 0700 Not tainted (2.6.24-rt1)
MSR: 00021032 ME,IR,DR CR: 28004042 XER: 2000
TASK = ef852090[8] 'softirq-block/0' THREAD: ef858000
GPR00: 0001 ef859b80 ef852090
0002 GPR08: 0001 ef852090 ef852090 ef859b80
0fffd000 0028 GPR16: 00800564 0080 007fff00
0001 ef8bc000 ef3ac2f0 GPR24: 0011 ef3f77e0
ef858000 1032 ef3ac2f0 ef859b80 NIP [c025c340]
rt_spin_lock_slowlock+0x7c/0x1c0
LR [c025c318] rt_spin_lock_slowlock+0x54/0x1c0
Call Trace:
[ef859b80] [c025c318] rt_spin_lock_slowlock+0x54/0x1c0 (unreliable)
[ef859be0] [c025c78c] __rt_spin_lock+0x80/0x98
[ef859bf0] [c025c8f8] rt_spin_lock+0x3c/0x54
[ef859c10] [c01c8e14] sil24_interrupt+0x68/0x53c
[ef859c50] [c00529e0] handle_IRQ_event+0x6c/0x114
[ef859c80] [c0052bcc] __do_IRQ+0x144/0x1c4
[ef859ca0] [c0017d88] apmax_int_irq_demux+0x90/0xb8
[ef859cc0] [c00063f0] do_IRQ+0x6c/0xb0
[ef859cd0] [c0010cfc] ret_from_except+0x0/0x28
--- Exception: 501 at ata_qc_issue+0x140/0x684
LR = ata_scsi_translate+0x138/0x184
[ef859d90] [ef385960] 0xef385960 (unreliable)
[ef859dd0] [c01bd7a0] ata_scsi_translate+0x138/0x184
[ef859e00] [c01c0d0c] ata_scsi_queuecmd+0x210/0x240
[ef859e20] [c01a46d4] scsi_dispatch_cmd+0x1d0/0x240
[ef859e40] [c01aaecc] scsi_request_fn+0x274/0x340
[ef859e60] [c0160b9c] blk_run_queue+0x68/0xac
[ef859e80] [c01a8ee0] scsi_run_queue+0x1cc/0x1e4
[ef859eb0] [c01a9678] scsi_next_command+0x3c/0x5c
[ef859ed0] [c01a987c] scsi_end_request+0xd4/0xf4
[ef859ef0] [c01a9c30] scsi_io_completion+0xf4/0x320
[ef859f30] [c01a3f78] scsi_finish_command+0x94/0xac
[ef859f50] [c01aa5d4] scsi_softirq_done+0xd4/0xec
[ef859f70] [c015c83c] blk_done_softirq+0x8c/0xbc
[ef859f90] [c0026008] ksoftirqd+0x168/0x27c
[ef859fd0] [c00386d0] kthread+0x50/0x90
[ef859ff0] [c0010408] kernel_thread+0x44/0x60
Instruction
locking problem in sata_sil24?
Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, but
kept gettign a BUG() (kernel BUG at kernel/rtmutex.c:692).
While tryiong to figure out what it was, I saw some mention of trying
LOCKDEP to see what is going on, so I patched my -rt1 kernel with some
lockdep patches from BenH.
Now I get an inconsistent locking state, but I need help in trying to
fiure out what I should look for.
kernel is fo an Freescale 8280 and the locking seems to occur in the
driver for a Silicon Image SII3124 SATA disk driver
Linux version 2.6.24-rt1 ([EMAIL PROTECTED]) (gcc version 4.1.2) #12 PREEMPT
RT Mon Mar 3 15:47:03 CST 2008
Trying to allocate DevcomPtr
DevcomHugeMemPtr = c180
Zone PFN ranges:
DMA 0 - 196608
Normal 196608 - 196608
HighMem196608 - 262144
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0:0 - 262144
Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
260096
Kernel command line: root=/dev/sda3 rw console=ttyCPM0,115200
WARNING: experimental RCU implementation.
PID hash table entries: 4096 (order: 12, 16384 bytes)
clocksource: timebase mult[a0c0437] shift[22] registered
console [ttyCPM0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 16384
... MAX_LOCKDEP_CHAINS: 32768
... CHAINHASH_SIZE: 16384
memory used by lock dependency info: 1568 kB
per task-struct memory footprint: 1200 bytes
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1007824k/1048576k available (3240k kernel code, 302324k
reserved, 176k data, 2803k bss, 128k init)
Mount-cache hash table entries: 512
net_namespace: 88 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
SCSI subsystem initialized
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 32768 (order: 9, 2228224 bytes)
TCP: Hash tables configured (established 131072 bind 32768)
TCP reno registered
krcupreemptd setsched 0
prio = 98
highmem bounce pool size: 64 pages
JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ttyCPM0 at MMIO 0xf1050a80 (irq = 16) is a CPM UART
Fixed MDIO Bus: probed
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky [EMAIL PROTECTED]
eth0: fs_enet: 00:30:d7:00:14:52
eth1: fs_enet: 00:30:d7:00:14:53
eth2: fs_enet: 00:30:d7:00:00:01
Driver 'sd' needs updating - please use bus_type methods
scsi0 : sata_sil24
scsi1 : sata_sil24
scsi2 : sata_sil24
scsi3 : sata_sil24
ata1: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x90008000 irq 17
ata2: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9000a000 irq 17
ata3: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9000c000 irq 17
ata4: SATA max UDMA/100 host [EMAIL PROTECTED] port 0x9000e000 irq 17
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0)
stopped custom tracer.
=
[ INFO: inconsistent lock state ]
[ 2.6.24-rt1 #12
-
inconsistent {hardirq-on-W} - {in-hardirq-W} usage.
swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(host-lock){+-..}, at: [c01c8e14] sil24_interrupt+0x68/0x53c
{hardirq-on-W} state was registered at:
[c0047724] __lock_acquire+0x494/0xc04
[c0047ee8] lock_acquire+0x54/0x78
[c025c8f0] rt_spin_lock+0x34/0x54
[c01b45ac] ata_dev_init+0x38/0x88
[c01b467c] ata_link_init+0x80/0xa4
[c01b4840] ata_port_alloc+0x1a0/0x1bc
[c01b48f4] ata_host_alloc+0x98/0xf8
[c01b4974] ata_host_alloc_pinfo+0x20/0x104
[c01c83b4] sil24_init_one+0x128/0x390
[c01802f0] pci_device_probe+0x70/0xa8
[c0197d10] driver_probe_device+0x104/0x1ac
[c0197e0c] __driver_attach+0x54/0x8c
[c0197030] bus_for_each_dev+0x58/0xa0
[c0197adc] driver_attach+0x2c/0x44
[c0197778] bus_add_driver+0xb4/0x1b8
[c01980b8] driver_register+0x7c/0x114
[c01803bc] __pci_register_driver+0x60/0x78
[c031e620] sil24_init+0x2c/0x44
[c030a2c8] kernel_init+0xdc/0x334
[c0010408] kernel_thread+0x44/0x60
irq event stamp: 16174
hardirqs last enabled at (16173): [c0046d18]
trace_hardirqs_on+0x1c/0x34
hardirqs last disabled at (16174): [c0045554]
trace_hardirqs_off+0x1c/0x34
softirqs last enabled at (0): [] 0x0
softirqs last disabled at (0): [] 0x0
other info that might help us debug this:
no locks held by swapper/0.
stack backtrace:
Call Trace:
[c0357ca0] [c0008474] show_stack+0x54/0x18c (unreliable)
[c0357cd0] [c00085cc] dump_stack+0x20/0x38
[c0357ce0] [c00460a0]
RE: locking problem in sata_sil24?
Benjamin Herrenschmidt wrote: On Mon, 2008-03-03 at 16:10 -0600, Rune Torgersen wrote: Hi I am trying to get PREEMPT_RT pach to wokr on my 2.6.24 kernel, What core is in the 8280 ? At this stage, I wouldn't rule out a bug in the lockdep patches, I need to do more work on them. Should be an 603e adn revision (from u-boot) CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz I am currently compiling a LOCKDEP kernel for my x86 desktop, as it has the exact same SiliconImage controller on a card, so I'll see if it gets a similar detection. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: locking problem in sata_sil24?
From: Benjamin Herrenschmidt In fact, I remember working on 64 bits lockdep, based on patches from Johannes, but I didn't do 32 bits. I think somebody worked on it, but now I can't find the patches... http://patchwork.ozlabs.org/linuxppc/patch?id=16652 Whoever did it can bounce them back to me ? I intend to do some more work on this soon. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] fs_enet: Don't call phy_mii_ioctl() in atomic context.
Scott Wood wrote:
The lock acquisition in fs_ioctl() does not appear to actually be
necessary, and thus is simply removed.
Signed-off-by: Scott Wood [EMAIL PROTECTED] ---
This fixes the following bug:
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051564.html
drivers/net/fs_enet/fs_enet-main.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index 42d94ed..af869cf 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -946,16 +946,11 @@ static int fs_ioctl(struct net_device
*dev, struct ifreq *rq, int cmd)
{
struct fs_enet_private *fep = netdev_priv(dev);
struct mii_ioctl_data *mii = (struct mii_ioctl_data
*)rq-ifr_data;
- unsigned long flags;
- int rc;
if (!netif_running(dev))
return -EINVAL;
- spin_lock_irqsave(fep-lock, flags);
- rc = phy_mii_ioctl(fep-phydev, mii, cmd);
- spin_unlock_irqrestore(fep-lock, flags);
- return rc;
+ return phy_mii_ioctl(fep-phydev, mii, cmd);
}
extern int fs_mii_connect(struct net_device *dev);
Acked-by: Rune Torgersen [EMAIL PROTECTED]
Tested it and it does indeed take care of the bug.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
WARN_ON() hit in fsl bitbanged phy driver
I hit the following WARN_ON when using mii-tools agains a ethernet
interface using a bit-banged mii interface
It is only diplayed once, and does not seem to impact usage at all
Does somebody know what is wrong, and how to fix it?
The PHY is an Intel LXT973
Badness at kernel/softirq.c:139
NIP: c001f8bc LR: c0121170 CTR: c01269d8
REGS: dfaa5ce0 TRAP: 0700 Tainted: P (2.6.24-cpu2)
MSR: 00021032 ME,IR,DR CR: 2000 XER: 2000
TASK = de0c2b40[825] 'mii-tool' THREAD: dfaa4000
GPR00: 0001 dfaa5d90 de0c2b40 782d 0005 0001
0ff6a37c
GPR08: c025 df86bb60 0800 8242 1001aa20
100aa258
GPR16: 1009 1009 1007 100aa170 1001
bff3bd94
GPR24: 0003 0001 c0123234 782d dfaa4000
df003a00
NIP [c001f8bc] local_bh_enable+0x28/0x9c
LR [c0121170] phy_read+0x5c/0x74
Call Trace:
[dfaa5d90] [dfaa4000] 0xdfaa4000 (unreliable)
[dfaa5da0] [c0121170] phy_read+0x5c/0x74
drivers/net/phy/phy.c:80
[dfaa5dc0] [c012140c] phy_mii_ioctl+0x64/0x170
drivers/net/phy/phy.c:368
[dfaa5de0] [c0125394] fs_ioctl+0x4c/0x8c
[dfaa5e00] [c0143744] dev_ifsioc+0x2e8/0x314
[dfaa5e20] [c0144eb8] dev_ioctl+0x6f4/0x8a8
[dfaa5ea0] [c0136aa8] sock_ioctl+0x1fc/0x21c
[dfaa5ec0] [c00742e0] do_ioctl+0x44/0xa8
[dfaa5ee0] [c00746e8] vfs_ioctl+0x3a4/0x3e8
[dfaa5f10] [c007476c] sys_ioctl+0x40/0x70
[dfaa5f40] [c000edc8] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff6a37c
LR = 0xffecd58
Instruction dump:
7c0803a6 4e800020 9421fff0 7c0802a6 90010014 7ca6 70098000 40a2002c
3d20c025 8009d2a8 7c34 5400d97e 0f00 2f80 41be0010
3801
(gdb) list *0xc0121170
0xc0121170 is in phy_read (drivers/net/phy/phy.c:80).
75 spin_lock_bh(bus-mdio_lock);
76 retval = bus-read(bus, phydev-addr, regnum);
77 spin_unlock_bh(bus-mdio_lock);
78
79 return retval;
80 }
81 EXPORT_SYMBOL(phy_read);
82
83 /**
84 * phy_write - Convenience function for writing a given PHY
register
(gdb) list *0xc012140c
0xc012140c is in phy_mii_ioctl (drivers/net/phy/phy.c:368).
363 switch (cmd) {
364 case SIOCGMIIPHY:
365 mii_data-phy_id = phydev-addr;
366 break;
367 case SIOCGMIIREG:
368 mii_data-val_out = phy_read(phydev,
mii_data-reg_num);
369 break;
370
371 case SIOCSMIIREG:
372 if (!capable(CAP_NET_ADMIN))
(gdb) list *0xc001f8bc
0xc001f8bc is in local_bh_enable (kernel/softirq.c:139).
134 #ifdef CONFIG_TRACE_IRQFLAGS
135 unsigned long flags;
136
137 WARN_ON_ONCE(in_irq());
138 #endif
139 WARN_ON_ONCE(irqs_disabled());
140
141 #ifdef CONFIG_TRACE_IRQFLAGS
142 local_irq_save(flags);
143 #endif
the relevant part of my device tree is:
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,mpc8280-fcc-enet,
fsl,cpm2-fcc-enet;
reg = 11340 20 8600 100 113d0 1;
interrupts = 22 8;
interrupt-parent = PIC;
phy-handle = PHY1;
linux,network-index = 1;
fsl,cpm-command = 1a400300;
local-mac-address = [00 00 00 00 00 00];
};
[EMAIL PROTECTED] {
device_type = mdio;
compatible = fsl,pq2fads-mdio-bitbang,
fsl,mpc8280-mdio-bitbang,
fsl,cpm2-mdio-bitbang;
#address-cells = 1;
#size-cells = 0;
reg = 10d40 14;
fsl,mdio-pin = 5;
fsl,mdc-pin = 4;
PHY1: [EMAIL PROTECTED] {
//interrupt-parent = PIC;
//interrupts = 19 2;
reg = 1;
device_type = ethernet-phy;
};
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: WARN_ON() hit in fsl bitbanged phy driver
Scott Wood wrote: Rune Torgersen wrote: I hit the following WARN_ON when using mii-tools agains a ethernet interface using a bit-banged mii interface It looks like the kernel thinks it's in an interrupt, even though it clearly isn't from the backtrace. Presumably, something slept from an interrupt handler; try turning on sleep-in-spinlock debugging. I turned on sleep-in-spinlock and it did not reveal anything. I'm trying some other debug options. The root cause was probably something other than the phy code. I'm not so sure, because it only happens when I run mii-tool agains the interface useing the bit-banged driver, and then only the first time. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kernel oops while duming user core.
Hi I get the following kernel core while a user program I have is dumping core. Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on a 8280) When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11 and dumps core. On 2.6.24, I ghet the kernel oops, and then the program hangs sround forever and is unkillable. Unable to handle kernel paging request for data at address 0x48024000 Faulting instruction address: 0xc000ef88 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT Innovative Systems ApMax Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) NIP: c000ef88 LR: c0012180 CTR: 0080 REGS: eebc9b70 TRAP: 0300 Tainted: P (2.6.24) MSR: 9032 EE,ME,IR,DR CR: 24004442 XER: DAR: 48024000, DSISR: 2000 TASK = eebac3c0[3131] 'armd' THREAD: eebc8000 GPR00: ee9b7d00 eebc9c20 eebac3c0 48024000 0080 399a4181 48024000 GPR08: 399a4181 ee9b7d00 c200 44004422 10100f38 ee82fc00 bfff GPR16: ef377060 0030 ee9b7d00 eebc9cdc 0011 eebc9cd8 eeb96480 GPR24: ee9b7d00 399a4181 48024000 eeb9a370 eeb9a370 399a4181 48024000 c2733480 NIP [c000ef88] __flush_dcache_icache+0x14/0x40 LR [c0012180] update_mmu_cache+0x74/0x114 Call Trace: [eebc9c20] [eebc8000] 0xeebc8000 (unreliable) [eebc9c40] [c005d060] handle_mm_fault+0x630/0xbc0 [eebc9c80] [c005d9e4] get_user_pages+0x3f4/0x4fc [eebc9cd0] [c00aa7c4] elf_core_dump+0x9a4/0xc5c [eebc9d60] [c00779e4] do_coredump+0x6e0/0x748 [eebc9e50] [c002a5b0] get_signal_to_deliver+0x40c/0x45c [eebc9e80] [c0008ce8] do_signal+0x50/0x294 [eebc9f40] [c000fb98] do_user_signal+0x74/0xc4 --- Exception: 300 at 0x10044efc LR = 0x10044ec0 Instruction dump: 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 6000 54630026 38800080 7c8903a6 7c661b78 7c00186c 38630020 4200fff8 7c0004ac ---[ end trace 97db37eaf213da3c ]--- note: armd[3131] exited with preempt_count 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Nathan Lynch wrote: Hmm, this is the second report of 2.6.24 crashing in __flush_dcache_icache during a core dump; see: http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html Is this easily recreatable? Yes. I have a binary that will do this every time it is started (on this particular system), only takes about 10 seconds before it dumps. I was going to test HEAD of powerpc.git to see if it is still there. I cannot test any earlier versions as our board port was done on 2.6.24. Our older kernel port is 2.6.18 on arch/ppc, and it works just fine. One potential clue: Unable to handle kernel paging request for data at address 0x48024000 this adddress is beyond our physical memory. We have 1GB of mem (CONFIG_HIGH_MEM enabled) so 0x3fff_ is the last valid address. 0x4000_ to 0x7fff_ are unused, 0x8000_ to 0x9fff_ is used by PCI. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Rune Torgersen wrote:
I was going to test HEAD of powerpc.git to see if it is still there.
Still there. Also used GDB on the vmlinux image to get source and
dissasembly of the ooops:
Unable to handle kernel paging request for data at address 0x48024000
Faulting instruction address: 0xc000f0a0
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT Innovative Systems ApMax
Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7
drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P)
NIP: c000f0a0 LR: c0011fec CTR: 0080
REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test)
MSR: 9032 EE,ME,IR,DR CR: 24004442 XER:
DAR: 48024000, DSISR: 2000
TASK = eeba9780[2554] 'armd_crash' THREAD: eebe8000
GPR00: eea44d00 eebe9c20 eeba9780 48024000 0080 37a56181 48024000
GPR08: 37a56181 eea44d00 c200 44004422 10100f38 ef336600
bfff
GPR16: eeff0300 0030 eea44d00 eebe9cdc 0011 eebe9cd8
eebca480
GPR24: eea44d00 37a56181 48024000 eebad580 eebad580 37a56181 48024000
c26f4ac0
NIP [c000f0a0] __flush_dcache_icache+0x14/0x40
LR [c0011fec] update_mmu_cache+0x74/0x114
Call Trace:
[eebe9c20] [eebe8000] 0xeebe8000 (unreliable)
[eebe9c40] [c005cfd0] handle_mm_fault+0x630/0xbc0
[eebe9c80] [c005d954] get_user_pages+0x3f4/0x4fc
[eebe9cd0] [c00aa730] elf_core_dump+0x9a4/0xc5c
[eebe9d60] [c0077954] do_coredump+0x6e0/0x748
[eebe9e50] [c002a520] get_signal_to_deliver+0x40c/0x45c
[eebe9e80] [c0008cec] do_signal+0x50/0x294
[eebe9f40] [c000fc9c] do_user_signal+0x74/0xc4
--- Exception: 300 at 0x10044efc
LR = 0x10044ec0
Instruction dump:
4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 6000
54630026 38800080 7c8903a6 7c661b78 7c00186c 38630020 4200fff8
7c0004ac
---[ end trace 37755b0fb9e79677 ]---
note: armd_crash[2554] exited with preempt_count 2
backtrace using gdb on vmlinux image:
0xc00aa730 is in elf_core_dump (fs/binfmt_elf.c:1762).
1757
1758for (addr = vma-vm_start; addr end; addr +=
PAGE_SIZE) {
1759struct page *page;
1760struct vm_area_struct *vma;
1761
1762if (get_user_pages(current, current-mm,
addr, 1, 0, 1,
1763page, vma) =
0) {
1764DUMP_SEEK(PAGE_SIZE);
1765} else {
1766if (page == ZERO_PAGE(0)) {
(gdb) list *0xc005d954
0xc005d954 is in get_user_pages (mm/memory.c:1072).
1067cond_resched();
1068while (!(page = follow_page(vma, start,
foll_flags))) {
1069int ret;
1070ret = handle_mm_fault(mm, vma,
start,
1071foll_flags
FOLL_WRITE);
1072if (ret VM_FAULT_ERROR) {
1073if (ret VM_FAULT_OOM)
1074return i ? i :
-ENOMEM;
1075else if (ret
VM_FAULT_SIGBUS)
1076return i ? i :
-EFAULT;
(gdb) list *0xc005cfd0
0xc005cfd0 is in handle_mm_fault (include/asm/thread_info.h:99).
94 {
95 register unsigned long sp asm(r1);
96
97 /* gcc4, at least, is smart enough to turn this into a
single
98 * rlwinm for ppc32 and clrrdi for ppc64 */
99 return (struct thread_info *)(sp ~(THREAD_SIZE-1));
100 }
101
102 #endif /* __ASSEMBLY__ */
103
(gdb)
(gdb) list *0xc0011fec
0xc0011fec is in update_mmu_cache (arch/powerpc/mm/mem.c:489).
484 _tlbie(address, 0 /* 8xx doesn't care about PID
*/);
485 #endif
486 if (!PageReserved(page)
487 !test_bit(PG_arch_1, page-flags)) {
488 if (vma-vm_mm == current-active_mm) {
489 __flush_dcache_icache((void *)
address);
490 } else
491 flush_dcache_icache_page(page);
492 set_bit(PG_arch_1, page-flags);
493 }
(gdb) list *0xc000f0a0
No source file for address 0xc000f0a0.
(gdb) disassemble 0xc000f0a0
Dump of assembler code for function __flush_dcache_icache:
0xc000f08c __flush_dcache_icache+0: dec%esi
0xc000f08d __flush_dcache_icache+1: addb $0x20,(%eax)
0xc000f090 __flush_dcache_icache+4: push %esp
0xc000f091 __flush_dcache_icache+5: arpl %ax,(%eax)
0xc000f093 __flush_dcache_icache+7: cmp%al,%es:0x897c8000(%eax)
0xc000f09a __flush_dcache_icache+14: add0x781b667c(%esi),%esp
0xc000f0a0 __flush_dcache_icache+20: jl 0xc000f0a2
__flush_dcache_icache+22
0xc000f0a2 __flush_dcache_icache+22: sbb%ch,0x63(%eax,%edi
RE: Kernel oops while duming user core.
Kumar Gala wrote: Can you git-bisect to narrow this down further. Not easilly, as the board port to arch/powerpc was done on 2.6.24-rc7 and up. Is there an somewhat esy way in git to apply the differences from master branch to our board branch to a branch created by bisect? And I don't even know where this started to happen. Would trying arch/ppc help any? I have our arch/ppc port in a semiworking state for kernels up to 2.6.23 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Scott Wood wrote: Does it happen without preempt? Will try shortly, just updated my git to HEAD of Linus's tree Modules linked in: drv_wd(P) drv_scc devcom drv_pcir tipc drv_ss7 drv_auxcpu drv_leds(P) drv_ethsw proc_sysinfo(P) i2c_8266(P) NIP: c000f0a0 LR: c0011fec CTR: 0080 REGS: eebe9b70 TRAP: 0300 Tainted: P (2.6.24-test) Does it happen without the modules? Cannot test without most of them. Do you have a simple test case that we could try to reproduce? I tried a simple core dump on an 8280, and it worked. I do not have a testcase, except a app for our board that does this reliably after about 10 seconds. Failing that, I'd add code to the page fault handler to dump what is (or isn't) supposed to be mapped at the faulting address, and something to track which (if any) TLB miss exception it came through. I can test code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Scott Wood wrote: Does it happen without preempt? Yes ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Nathan Lynch wrote: Scott Wood wrote: Do you have a simple test case that we could try to reproduce? I tried a simple core dump on an 8280, and it worked. Is the crashing program multithreaded? The first report had firefox triggering the oops. The crashing program has 10 threads. (NPTL pthreads, glibc-2.5, gcc 4.1.2) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kernel oops while duming user core.
Scott Wood wrote: Scott Wood wrote: Nathan Lynch wrote: Is the crashing program multithreaded? The first report had firefox triggering the oops. OK, I've got a test program that triggers it now. I'll see if I can figure out what's going on. The problem seems to be that update_mmu_cache() is called on a guard page with no access rights. Changing update_mmu_cache() to always call flush_dcache_icache_page() fixes it, though a better performing fix would probably be to add an exception table entry for the dcbst. I can confirm that this seems to fix it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problems with PCI on 8280
Hi.
We have e 8280 bioard with PCI. We have three memory ranges set up;
0x8000_ to 0x8fff_ is prefetchable memory
0x9000_ to 0x97ff_ is non-prefetchable memory
0x9800_ to 0x9800_ is IO.
our device tree has
ranges = 4200 0 8000 8000 0 1000// Pre-fetch memory
0200 0 9000 9000 0 0800// Normal Memory
0100 0 9800 9800 0 0001; // I/O
for the memory ranges in the PCI node (full node at the end)
Our problem is that we can only access the first 128MB of the prefetchable area.
an access to 0x87ff_ works (after ioremap), while an access to 0x8800_
causes an bus error.
trying to access 0x87FC - 0x
trying to access 0x8800 -Machine check in kernel mode.
Caused by (from SRR1=49030): Transfer error ack signal
It is like the prefetch area is not set up correctly for ioremap.
The PCI registers are set up correctly in u-boot, and we can access the whole
prefetch area in u-boot without any problems.
pci node in device tree:
[EMAIL PROTECTED] {
device_type = pci;
reg = f0010800 10c f00101ac 8 f00101c4 8;
compatible = fsl,mpc8280-pci, apmax-pci, fsl,pq2-pci;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
clock-frequency = d#49766400; // For our board.
interrupt-map-mask = f800 0 0 7;// Anded with the
interrupt-map values
interrupt-map =
/* IDSEL 0x11 */
8800 0 0 1 PCI_INT 5; // 3 first
numbers pci device specifier are: (buss 16 | id_sel 11) 0 0
//buss = 0,
id_sel = 11
// Next number is
interrupt 1-4 mapped A-D (interrupt A for us)
// Last two
numbers are host interrupt specifier (external interrupt 5)
//interrupt-parent = PIC;
interrupt-parent = PCI_INT;
// interrupts = 12 8;
// Mem type 0 Bus Add Loc. Add 0 Length --- Remember the
mem type is little endian
ranges = 4200 0 8000 8000 0 1000//
Pre-fetch memory
0200 0 9000 9000 0 0800// Normal
Memory
0100 0 9800 9800 0 0001; // I/O
bus-range = 0 ff;
[EMAIL PROTECTED] {
device_type = pci;
reg = 9000 0 0 0 0;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
interrupt-parent = PCI_INT;
interrupt-map-mask = 0f800 0 0 7;
interrupt-map =
/* IDSEL 0x10 */
0 0 1 PCI_INT 1
/* IDSEL 0x11 */
0800 0 0 1 PCI_INT 2
/* IDSEL 0x12 */
1000 0 0 1 PCI_INT 3
/* IDSEL 0x13 */
1800 0 0 1 PCI_INT 4 ;
};
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Problems with PCI on 8280
From: Scott Wood Hmm... that suggests that something in u-boot's setup is either incorrect, or (more likely in this case) doesn't match the device tree. Turns out u-boot was not setting u the inbound window size correctly. It was hardcoded to 512MB and we have a gig of ram. Set it correctly, and CPI now works fully even without fixup_pci() Ah. Yes, I was assuming both windows would be the same size. The code should be changed to check that, and if any conditions for setting PCIBRx/PCIMSKx fail, check to see if the firmware-provided values work (and if not, bail without touching anything). yup. In our case we only need one window. BTW. there is a bug in the inbound window size calculation. The mem_log2 variable sould be the shift value, not 1 shift. and on the next line the window size mask sould be anded with 0x000f_ before or'ed with 0xa000_ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Problems with PCI on 8280
From: Scott Wood Are you using cuImage, or a regular uImage with a device-tree-aware u-boot cuImage for now. If the former, try commenting out the call to fixup_pci() in arch/powerpc/boot/cuboot-pq2.c and let me know if that changes anything. Did that, That made our PCI bus fail completely Looking in fixup_pci, I see it sets up one outbound window to the size of prefechable and non-prefetcabe memory and anoter one to the size of the IO. We have our PCI set up to ONE 512MB outbound range doing all three. (I can see where you'd save on mem usage by doing two) I do see a bug tho. In our case prefetch is 256MB, memio is 128MB. the calculation for outbound wiondow 1 sets the size to ~(pref+mmio-1). That only works if the resulting size is a power of 2. If we comment out the rewrite of the outbound windows, we get PCI to work. But since our u-boot sets everything up correctly (Including prefecable memory) we should not need this? or is it rewriting the device tree in some way? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Rune Torgersen Finally got it (sort-of) working. Turned out that for some reason the console init is setting the baudrate to 9600 the options string passed in to the console init fuunction is NULL. Any idea oon how this should be passed in from u-boot? Ok, needed a valid console= line on the command line. WHen we tried that, we had a typo, so it was not recognized. Our old 2.6.18 arch/ppc kernel didn't need a console parameter, it got the baudrate from u-boot somehow. Anyway of doing that here too? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood You could add something to the cuboot code to fill in current-speed based on the value in the bd_t. Ahh.. That was what I'm missing. Where in the devicetree is that supposed to be at? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Device Tree PCI
Hi.
We're trying to port 2.6.24-rc7 to a board.
Right now wr're battling with the device tree and PCI.
Our board is somewhat loosely based on a 8266ADS/pq2fads board
We have a PCI interrupt mux in a fpga.
We have a disk controller and a pci bridge on the primary side, and four
TI dsp's on the secondary side.
All the interrupts are hardwired to the int mux in our FPGA.
THe PCI code does not seem happy:
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
PCI: Probing PCI hardware
irq_create_mapping called for NULL host, hwirq=0
[ cut here ]
Badness at arch/powerpc/kernel/irq.c:661
NIP: c0006048 LR: c0006048 CTR:
REGS: ef821d40 TRAP: 0700 Not tainted (2.6.24-rc7-gdcbd768b-dirty)
MSR: 00029032 EE,ME,IR,DR CR: 24022022 XER:
TASK = ef812000[1] 'swapper' THREAD: ef82
GPR00: c0006048 ef821df0 ef812000 0034 0001 0001
c0306c30
GPR08: c02f 24022082 10019684 0ffce000
0040092c
GPR16: 0001 ef821f60 c02d c02d c02d 0071f3a0
0001
GPR24: c030e000 ef818100 0001 ef818114
NIP [c0006048] irq_create_mapping+0xa8/0x100
LR [c0006048] irq_create_mapping+0xa8/0x100
Call Trace:
[ef821df0] [c0006048] irq_create_mapping+0xa8/0x100 (unreliable)
[ef821e10] [c001225c] pci_read_irq_line+0x84/0xfc
[ef821e60] [c00117c8] pcibios_fixup_bus+0xe8/0x24c
[ef821e90] [c013b784] pci_scan_child_bus+0x78/0x118
[ef821eb0] [c013bb24] pci_scan_bridge+0x300/0x42c
[ef821ef0] [c013b7d4] pci_scan_child_bus+0xc8/0x118
[ef821f10] [c013beb4] pci_scan_bus_parented+0x20/0x3c
[ef821f20] [c02ba754] pcibios_init+0x68/0x250
[ef821f50] [c02b68ac] kernel_init+0x108/0x2e0
[ef821ff0] [c00100d8] kernel_thread+0x44/0x60
here is our device tree:
/*
* Device Tree for the ApMax board with an MPC8280 chip.
*
* Copyright 2007 Freescale Semiconductor Inc.
* Copyright 2008 Innovative Systems, LLC
*
* This program is free software; you can redistribute it and/or modify
it
* under the terms of the GNU General Public License as published by
the
* Free Software Foundation; either version 2 of the License, or (at
your
* option) any later version.
*/
/ {
model = pq2fads;
compatible = fsl,pq2fads;
#address-cells = 1;
#size-cells = 1;
cpus {
#address-cells = 1;
#size-cells = 0;
[EMAIL PROTECTED] {
device_type = cpu;
reg = 0;
d-cache-line-size = d#32;
i-cache-line-size = d#32;
d-cache-size = d#16384;
i-cache-size = d#16384;
timebase-frequency = 0;
clock-frequency = 0;
};
};
memory {
device_type = memory;
reg = 0 0;
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8280-localbus,
fsl,pq2-localbus;//
Change to our own apmax-localbus
#address-cells = 2;
#size-cells = 1;
reg = f0010100 60;
// CS 0 BaseAddress length
look
ranges = 0 0 ff80 0080 // CPU1
8MB Flash
5 0 f810 8000 // FPGA
registers
6 0 f880 0020
// ARM FIFO in FPGA
8 0 f900 0080
// CPU2 8MB Flash
9 0 f840 0002;
// CPU1 128K SRAM
[EMAIL PROTECTED],0 {
compatible = jedec-flash;
reg = 0 0 80;
bank-width = 2;
device-width = 2;
};
PCI_INT: [EMAIL PROTECTED],10 {
#interrupt-cells = 1;
interrupt-controller;
reg = 5 10 4; //
Chip select, offset, length
compatible = apmax-pciintmux;
interrupt-parent = PIC;
interrupts = 19 8;//
IRQ7, interrupt#25
};
};
[EMAIL PROTECTED] {
device_type = pci;
reg = f0010800 10c f00101ac 8 f00101c4 8;
compatible = fsl,mpc8280-pci, fsl,pq2-pci;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
clock-frequency = d#49766400; // For our
board.
interrupt-map-mask = f800 0 0 7;// Anded
with the interrupt-map values
interrupt-map =
/* IDSEL 0x11 */
8800 0 0 1 PCI_INT 5;
RE: Device Tree PCI
From: Scott Wood
Sent: Fri 1/11/2008 1:02 PM
To: Rune Torgersen
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Device Tree PCI
On Fri, Jan 11, 2008 at 12:17:41PM -0600, Rune Torgersen wrote:
PCI_INT: [EMAIL PROTECTED],10 {
#interrupt-cells = 1;
interrupt-controller;
reg = 5 10 4; //
Chip select, offset, length
compatible = apmax-pciintmux;
interrupt-parent = PIC;
interrupts = 19 8;//
IRQ7, interrupt#25
};
Is this interrupt controller getting registered before the PCI bus gets
probed?
Yes, and we got the disk controller on the primary side to work fully.
The kernel is still spitting those messages out, and we have determined it does
so when scanning the secondary side of the bridge, so we're suspecting our
bridge node in the device tree is not correct.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood The tree looks OK. The checkstop may be from erratum SIU18; I had this issue on the ep8248e board. Try clearing BCR[PLDP]. Not sure what was wrong. We took a step back, and redid some stuff, and now we have serial output from the boot-wrapper. THe checkstop came from the wrapper grying to access the bcsr and doing the chip select fixup. We don';t have a bcsr on our board, and the cs layout is different. Now our problem is that the kernel doesn't want to output anything to hte serial port. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Help with device tree binding for SMC serial
Hi
We're trying to get a SMC serial port on a8280 to work.
I cannot find any ecxamples on the binding, so we've tried to make one.
is this anywhere close to workable?
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 87fc 2;
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0100;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood
Sent: Wednesday, January 09, 2008 1:46 PM
We're trying to get a SMC serial port on a8280 to work.
I cannot find any ecxamples on the binding, so we've tried
to make one.
is this anywhere close to workable?
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 87fc 2;
The current binding has the actual parameter ram block as the
second reg
property, not the two-byte pointer. If your firmware doesn't
initialize
the pointer, you'll have to do it in platform code.
interrupts = 4 8;
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 0100;
};
cpm-command should be 1d00 for SMC1.
Otherwise, it looks OK.
Ok we're now using
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 0 40;// base_address length
parameter_ram_address length
interrupts = 4 8; // Interrupt from table 4.3
of mpc8280rm, interrupt is level or edge
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 1d00; // Page and Sub-block code
of the CPCR
};
Right now we're trying to just get a kernel to give us some serial
output, so we can continue the porting job.
We're unsig a cuImage (using the pq2fads code right now).
Now our problem is that the serial port is spitting out 0x0a's as fast
as it can.
Seems to be repeadtin the linefeed at the end of Uncompressing Kernel
Image ... OK
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood Don't forget to exclude the SMC parameter RAM from the muram data area in /soc/cpm/muram/data/reg. If you have an older device tree binding that has no /soc/cpm/muram node, but instead has two resources in /soc/cpm/reg, you need to move to head-of-tree to get this to work. Did that, now we get e checkstop resert. Time to hook up the BDI-2000 Is there a way to have the bootwrapper use the u-boot serial for a while (like a early srial port) for debugging? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
From: Scott Wood [mailto:[EMAIL PROTECTED]
Rune Torgersen wrote:
From: Scott Wood
Don't forget to exclude the SMC parameter RAM from the muram
data area
in /soc/cpm/muram/data/reg. If you have an older device
tree binding
that has no /soc/cpm/muram node, but instead has two resources in
/soc/cpm/reg, you need to move to head-of-tree to get this to work.
Did that, now we get e checkstop resert. Time to hook up the
BDI-2000
Is there a way to have the bootwrapper use the u-boot
serial for a while
(like a early srial port) for debugging?
If you mean calling into u-boot for a console, no, there's no
code for that.
What do your cpm and muram nodes look like?
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
#interrupt-cells = 2;
compatible = fsl,mpc8280-cpm, fsl,cpm2;
reg = 119c0 30;
ranges;
[EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
ranges = 0 0 1;
[EMAIL PROTECTED] {
compatible = fsl,cpm-muram-data;
reg = 100 1f00 9800 800;
};
};
[EMAIL PROTECTED] {
compatible = fsl,mpc8280-brg,
fsl,cpm2-brg,
fsl,cpm-brg;
reg = 119f0 10 115f0 10;
};
[EMAIL PROTECTED] {
device_type = serial;
compatible = fsl,mpc8280-smc-uart,
fsl,cpm2-smc-uart;
reg = 11a80 10 0 40;// base_address
length parameter_ram_address length
interrupts = 4 8; // Interrupt from
table 4.3 of mpc8280rm, interrupt is level or edge
interrupt-parent = PIC;
fsl,cpm-brg = 7;
fsl,cpm-command = 1d00; // Page and
Sub-block code of the CPCR
};
};
and chosen node (not sure if needed)
chosen {
linux,stdout-path = /soc/cpm/[EMAIL PROTECTED];
bootargs = console=ttyS0,115200;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
settimeofday not working
Hi I upgraded my board-port from 2.6.18 (8280 in arch/ppc) to 2.6.23 (Yes, I know, arch/powerpc. I am planning on doing that, I just wanted the old stuff working first). On any kernel newer than 2.6.20, settimeofday does not work. I try to set the current date, but when I read back the time, it is still the old date (in our case, Jan 1 1970) Any idea of where I should start looking? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: settimeofday not working
From: Rune Torgersen Sent: Thursday, October 25, 2007 2:40 PM On any kernel newer than 2.6.20, settimeofday does not work. I try to set the current date, but when I read back the time, it is still the old date (in our case, Jan 1 1970) Eventually the date actually got updated. Before then it returned 00:00 Jan 1 1970 every time it was queried. Anyways. Updated to 2.6.24-rc1, and it seems to work correctly. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Override timer interrupt
From: Benjamin Herrenschmidt In fact, I'm not sure what is your problem with the DEC proper as the TB will be used ultimately and thus it shouldn't drift more than the TB does. Can your part use an externally clocked TB ? If not, and you still have a drift despite calibration, you can always use NTP services to adjust timekeeping. We use NTP, which is why I didn't see it until recently. (Happened to have a board without NTP configured The main couse is that our main bus frequency cannort be divided into 1kHz evently by the decrementer. Main bus freq = 99532800 Hz. Decrementer then becomes 24883, which gives us 91.9624485600nsec per jiffy. That is not a number easilly converted into time without drift. Changing HZ to 100 fixes it, but is for varous reasons not an option right now. What I did do is change the timer interrupt to be called by an ecxternal 1kHz interrupt source instead of the decrementer. The TB register is only ued for offsets from the last jiffie, not as a continous offset, so then it works out pretty good. There is a discontinuity in the sub ms resolution of the clock that I can live with. msec and up are dead accurate. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Override timer interrupt
From: Benjamin Herrenschmidt The TB register is only ued for offsets from the last jiffie, not as a continous offset, so then it works out pretty good. The date is derived from the absolute TB value though... Huh? Not in 2.6.18/arch/ppc at least, unless I'm completely misundrstanding the code. ppc/powerpc seems to be using clocksource_jiffies as the clock source, and teh gettimeofday gets xtime + a offset from last jiffie, and xtime is updated with a fixed amount per tick. Things have changed a lot since I last delved deep into this to try to ge an accurate freerunning clock (2.6.12). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
FW: Override timer interrupt
From: Benjamin Herrenschmidt
Things have changed a lot since I last delved deep into
this to try to
ge an accurate freerunning clock (2.6.12).
Hrm... 2.6.18 doesn't have clock sources in the first place,
what kernel
are you using ?
2.6.18
And I'm starting at the clocksource code right now...
From jiffies.c:
static int __init init_jiffies_clocksource(void)
{
return clocksource_register(clocksource_jiffies);
}
module_init(init_jiffies_clocksource);
from: kernel/timer.c
/*
* update_wall_time - Uses the current clocksource to increment the wall
time
*
* Called from the timer interrupt, must hold a write on xtime_lock.
*/
static void update_wall_time(void)
{
cycle_t offset;
/* Make sure we're fully resumed: */
if (unlikely(timekeeping_suspended))
return;
#ifdef CONFIG_GENERIC_TIME
offset = (clocksource_read(clock) - clock-cycle_last)
clock-mask;
#else
offset = clock-cycle_interval;
#endif
clock-xtime_nsec += (s64)xtime.tv_nsec clock-shift;
/* normally this loop will run just once, however in the
* case of lost or late ticks, it will accumulate correctly.
*/
while (offset = clock-cycle_interval) {
/* accumulate one interval */
clock-xtime_nsec += clock-xtime_interval;
clock-cycle_last += clock-cycle_interval;
offset -= clock-cycle_interval;
if (clock-xtime_nsec = (u64)NSEC_PER_SEC
clock-shift) {
clock-xtime_nsec -= (u64)NSEC_PER_SEC
clock-shift;
xtime.tv_sec++;
second_overflow();
}
/* interpolator bits */
time_interpolator_update(clock-xtime_interval
clock-shift);
/* increment the NTP state machine */
update_ntp_one_tick();
/* accumulate error between NTP and clock interval */
clock-error += current_tick_length();
clock-error -= clock-xtime_interval
(TICK_LENGTH_SHIFT - clock-shift);
}
/* correct the clock when NTP error is too big */
clocksource_adjust(clock, offset);
/* store full nanoseconds into xtime */
xtime.tv_nsec = (s64)clock-xtime_nsec clock-shift;
clock-xtime_nsec -= (s64)xtime.tv_nsec clock-shift;
/* check to see if there is a new clocksource to use */
if (change_clocksource()) {
clock-error = 0;
clock-xtime_nsec = 0;
clocksource_calculate_interval(clock, tick_nsec);
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 23/28] mpc82xx: Define CPU_FTR_NEED_COHERENT
-Original Message- From: Scott Wood Sent: Monday, September 17, 2007 11:58 AM The 8272 (and presumably other PCI PQ2 chips) appear to have the same issue as the 83xx regarding PCI streaming DMA. Can you explain what this isssue is? We're using a 8280 and have had some PCI busmaster DMA problems, and wonder if it is related. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
