- 24 10月, 2013 2 次提交
-
-
由 Chen, Gong 提交于
This patch adds a new interface to decode memory device (type 17) to help error reporting on DIMMs. Original-author: Tony Luck <tony.luck@intel.com> Signed-off-by: NChen, Gong <gong.chen@linux.intel.com> Acked-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Acked-by: NBorislav Petkov <bp@suse.de> Reviewed-by: NMauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
由 Chen, Gong 提交于
This H/W error log driver (a.k.a eMCA driver) is implemented based on http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.html After errors are captured, more detailed platform specific information can be got via this new enhanced H/W error log driver. Most notably we can track memory errors back to the DIMM slot silk screen label. Signed-off-by: NChen, Gong <gong.chen@linux.intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com>
-
- 15 10月, 2013 3 次提交
-
-
由 Raghavendra K T 提交于
We use jump label to enable pv-spinlock. With the changes in (442e0973 Merge branch 'x86/jumplabel'), the jump label behaviour has changed that would result in eventual hang of the VM since we would end up in a situation where slow path locks would halt the vcpus but we will not be able to wakeup the vcpu by lock releaser using unlock kick. Similar problem in Xen and more detailed description is available in a945928e (xen: Do not enable spinlocks before jump_label_init() has executed) This patch splits kvm_spinlock_init to separate jump label changes with pvops patching and also make jump label enabling after jump_label_init(). Signed-off-by: NRaghavendra K T <raghavendra.kt@linux.vnet.ibm.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Reviewed-by: NSteven Rostedt <rostedt@goodmis.org> Signed-off-by: NGleb Natapov <gleb@redhat.com>
-
由 Marek Szyprowski 提交于
This reverts commit 10bcdfb8. There is no consensus on the bindings for the reserved memory, so the code for handing it will be reverted. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-
由 Russ Anderson 提交于
The UV3 hub revision ID is different than expected. The first revision was supposed to start at 1 but instead will start at 0. Signed-off-by: NRuss Anderson <rja@sgi.com> Cc: <stable@kernel.org> # v3.9, v3.10, v3.11 Link: http://lkml.kernel.org/r/20131014161733.GA6274@sgi.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 14 10月, 2013 3 次提交
-
-
由 Borislav Petkov 提交于
I have a randconfig here which has enabled only CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y with both # CONFIG_MICROCODE_INTEL is not set # CONFIG_MICROCODE_AMD is not set off. Which makes building the microcode functionality a little pointless. Don't do that in such cases then. Signed-off-by: NBorislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/1381682189-14470-1-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 AKASHI Takahiro 提交于
In ftrace_syscall_enter(), syscall_get_arguments(..., 0, n, ...) if (i == 0) { <handle ORIG_r0> ...; n--;} memcpy(..., n * sizeof(args[0])); If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in syscall_get_arguments(), none of arguments should be copied by memcpy(). Otherwise 'n--' can be a big positive number and unexpected amount of data will be copied. Tracing system calls which take no argument, say sync(void), may hit this case and eventually make the system corrupted. This patch fixes the issue both in syscall_get_arguments() and syscall_set_arguments(). Cc: <stable@vger.kernel.org> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Yuvaraj Kumar C D 提交于
Without the "clock-frequency" property in arch timer node, could able to see the below crash dump. [<c0014e28>] (unwind_backtrace+0x0/0xf4) from [<c0011808>] (show_stack+0x10/0x14) [<c0011808>] (show_stack+0x10/0x14) from [<c036ac1c>] (dump_stack+0x7c/0xb0) [<c036ac1c>] (dump_stack+0x7c/0xb0) from [<c01ab760>] (Ldiv0_64+0x8/0x18) [<c01ab760>] (Ldiv0_64+0x8/0x18) from [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) [<c0062f60>] (clockevents_config.part.2+0x1c/0x74) from [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) [<c0062fd8>] (clockevents_config_and_register+0x20/0x2c) from [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) [<c02b8e8c>] (arch_timer_setup+0xa8/0x134) from [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) [<c04b47b4>] (arch_timer_init+0x1f4/0x24c) from [<c04b40d8>] (clocksource_of_init+0x34/0x58) [<c04b40d8>] (clocksource_of_init+0x34/0x58) from [<c049ed8c>] (time_init+0x20/0x2c) [<c049ed8c>] (time_init+0x20/0x2c) from [<c049b95c>] (start_kernel+0x1e0/0x39c) THis is because the Exynos u-boot, for example on the Chromebooks, doesn't set up the CNTFRQ register as expected by arch_timer. Instead, we have to specify the frequency in the device tree like this. Signed-off-by: NYuvaraj Kumar C D <yuvaraj.cd@samsung.com> [olof: Changed subject, added comment, elaborated on commit message] Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 13 10月, 2013 7 次提交
-
-
由 Helge Deller 提交于
Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 John David Anglin 提交于
The attached change defers the initialization of the variables tsk, mm and flags until they are needed. As a result, the code won't crash if a kernel probe is done with a corrupt context and the code will be better optimized. Signed-off-by: NJohn David Anglin <dave.anglin@bell.net> Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Helge Deller 提交于
Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel. The problem is, that in print_worker_info() we try to read the workqueue info via the probe_kernel_read() functions which use pagefault_disable() to avoid crashes like this: probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq)); probe_kernel_read(&wq, &pwq->wq, sizeof(wq)); probe_kernel_read(name, wq->name, sizeof(name) - 1); The problem here is, that the first probe_kernel_read(&pwq) might return zero in pwq and as such the following probe_kernel_reads() try to access contents of the page zero which is read protected and generate a kernel segfault. With this patch we fix the interruption handler to call parisc_terminate() directly only if pagefault_disable() was not called (in which case preempt_count()==0). Otherwise we hand over to the pagefault handler which will try to look up the faulting address in the fixup tables. Signed-off-by: NHelge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v3.0+ Signed-off-by: NJohn David Anglin <dave.anglin@bell.net> Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Helge Deller 提交于
Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Helge Deller 提交于
Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Jiang Liu 提交于
Commit 9a46ad6d "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Signed-off-by: NJiang Liu <jiang.liu@huawei.com> Cc: Jiang Liu <liuj97@gmail.com> Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Geert Uytterhoeven 提交于
ERROR: "flush_cache_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined! Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: NHelge Deller <deller@gmx.de>
-
- 12 10月, 2013 1 次提交
-
-
由 Vineet Gupta 提交于
ARCompact TRAP_S insn used for breakpoints, commits before exception is taken (updating architectural PC). So ptregs->ret contains next-PC and not the breakpoint PC itself. This is different from other restartable exceptions such as TLB Miss where ptregs->ret has exact faulting PC. gdb needs to know exact-PC hence ARC ptrace GETREGSET provides for @stop_pc which returns ptregs->ret vs. EFA depending on the situation. However, writing stop_pc (SETREGSET request), which updates ptregs->ret doesn't makes sense stop_pc doesn't always correspond to that reg as described above. This was not an issue so far since user_regs->ret / user_regs->stop_pc had same value and both writing to ptregs->ret was OK, needless, but NOT broken, hence not observed. With gdb "jump", they diverge, and user_regs->ret updating ptregs is overwritten immediately with stop_pc, which this patch fixes. Reported-by: NAnton Kolesov <akolesov@synopsys.com> Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
-
- 11 10月, 2013 1 次提交
-
-
由 Ingo Molnar 提交于
Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto' constructs, as outlined here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 Implement a workaround suggested by Jakub Jelinek. Reported-and-tested-by: NFengguang Wu <fengguang.wu@intel.com> Reported-by: NOleg Nesterov <oleg@redhat.com> Reported-by: NPeter Zijlstra <a.p.zijlstra@chello.nl> Suggested-by: NJakub Jelinek <jakub@redhat.com> Reviewed-by: NRichard Henderson <rth@twiddle.net> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <stable@kernel.org> Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 10 10月, 2013 4 次提交
-
-
由 Frediano Ziglio 提交于
Due to the way kernel is initialized under Xen is possible that the ring1 selector used by the kernel for the boot cpu end up to be copied to userspace leading to segmentation fault in the userspace. Xen code in the kernel initialize no-boot cpus with correct selectors (ds and es set to __USER_DS) but the boot one keep the ring1 (passed by Xen). On task context switch (switch_to) we assume that ds, es and cs already point to __USER_DS and __KERNEL_CSso these selector are not changed. If processor is an Intel that support sysenter instruction sysenter/sysexit is used so ds and es are not restored switching back from kernel to userspace. In the case the selectors point to a ring1 instead of __USER_DS the userspace code will crash on first memory access attempt (to be precise Xen on the emulated iret used to do sysexit will detect and set ds and es to zero which lead to GPF anyway). Now if an userspace process call kernel using sysenter and get rescheduled (for me it happen on a specific init calling wait4) could happen that the ring1 selector is set to ds and es. This is quite hard to detect cause after a while these selectors are fixed (__USER_DS seems sticky). Bisecting the code commit 7076aada appears to be the first one that have this issue. Signed-off-by: NFrediano Ziglio <frediano.ziglio@citrix.com> Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by: NAndrew Cooper <andrew.cooper3@citrix.com>
-
由 Bharat Bhushan 提交于
When the MM code is invalidating a range of pages, it calls the KVM kvm_mmu_notifier_invalidate_range_start() notifier function, which calls kvm_unmap_hva_range(), which arranges to flush all the TLBs for guest pages. However, the Linux PTEs for the range being flushed are still valid at that point. We are not supposed to establish any new references to pages in the range until the ...range_end() notifier gets called. The PPC-specific KVM code doesn't get any explicit notification of that; instead, we are supposed to use mmu_notifier_retry() to test whether we are or have been inside a range flush notifier pair while we have been referencing a page. This patch calls the mmu_notifier_retry() while mapping the guest page to ensure we are not referencing a page when in range invalidation. This call is inside a region locked with kvm->mmu_lock, which is the same lock that is called by the KVM MMU notifier functions, thus ensuring that no new notification can proceed while we are in the locked region. Signed-off-by: NBharat Bhushan <bharat.bhushan@freescale.com> Acked-by: NAlexander Graf <agraf@suse.de> [Backported to 3.12 - Paolo] Reviewed-by: NBharat Bhushan <bharat.bhushan@freescale.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paul Mackerras 提交于
This fixes a typo in the code that saves the guest DSCR (Data Stream Control Register) into the kvm_vcpu_arch struct on guest exit. The effect of the typo was that the DSCR value was saved in the wrong place, so changes to the DSCR by the guest didn't persist across guest exit and entry, and some host kernel memory got corrupted. Cc: stable@vger.kernel.org [v3.1+] Signed-off-by: NPaul Mackerras <paulus@samba.org> Acked-by: NAlexander Graf <agraf@suse.de> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Gleb Natapov 提交于
72f85795 broke shadow on EPT. This patch reverts it and fixes PAE on nEPT (which reverted commit fixed) in other way. Shadow on EPT is now broken because while L1 builds shadow page table for L2 (which is PAE while L2 is in real mode) it never loads L2's GUEST_PDPTR[0-3]. They do not need to be loaded because without nested virtualization HW does this during guest entry if EPT is disabled, but in our case L0 emulates L2's vmentry while EPT is enables, so we cannot rely on vmcs12->guest_pdptr[0-3] to contain up-to-date values and need to re-read PDPTEs from L2 memory. This is what kvm_set_cr3() is doing, but by clearing cache bits during L2 vmentry we drop values that kvm_set_cr3() read from memory. So why the same code does not work for PAE on nEPT? kvm_set_cr3() reads pdptes into vcpu->arch.walk_mmu->pdptrs[]. walk_mmu points to vcpu->arch.nested_mmu while nested guest is running, but ept_load_pdptrs() uses vcpu->arch.mmu which contain incorrect values. Fix that by using walk_mmu in ept_(load|save)_pdptrs. Signed-off-by: NGleb Natapov <gleb@redhat.com> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Tested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 09 10月, 2013 4 次提交
-
-
由 Pali Rohár 提交于
File drivers/leds/leds-lp55xx-common.c refuse to change led_current sysfs attribute if value is higher than max_current specified in board file. By default global C variables are zero, so changing always failed. This patch adding missing max_current and setting it to max safe value 100 (10 mA). It is unclear which commit exactly caused this regression as the lp5523 driver was broken and was hiding the platform data breakage. Now the driver is fixed so this should be fixed as well. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NJoerg Reisenweber <joerg@openmoko.org> [tony@atomide.com: updated comments to describe regression] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Simon Barth 提交于
Since dra7 reuses the function 'omap5_realtime_timer_init' in arch/arm/mach-omap2/board-generic.c as timer init function, it has to be built for this SoC as well. Signed-off-by: NSimon Barth <Simon.Pe.Barth@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
The wake-up interrupt bit is available on omap3/4/5 processors unlike what we claim. Without fixing it we cannot use it on omap3 and the system configured for wake-up events will just hang on wake-up. Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Benoît Cousson <bcousson@baylibre.com> Cc: devicetree@vger.kernel.org Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Nishanth Menon 提交于
SoC family definitions at the moment are reactive to board needs as a result, beagle-xm would matchup with ti,omap3 which invokes omap3430_init_early instead of omap3630_init_early. Obviously, this is the wrong behavior. With clock node dts conversion, we get the following warnings before system hangs as a result and 3630 based platforms fails to boot (uart4 clocks are only present in OMAP3630 and not present in OMAP3430): ... omap_hwmod: uart4: cannot clk_get main_clk uart4_fck omap_hwmod: uart4: cannot _init_clocks WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434 _init+0x6c/0x80() omap_hwmod: uart4: couldn't init clocks ... WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126 _enable+0x254/0x280() omap_hwmod: timer12: enabled state can only be entered from initialized, idle, or disabled state ... WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224 _idle+0xd4/0xf8() omap_hwmod: timer12: idle state can only be entered from enabled state WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126 _enable+0x254/0x280() omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or disabled state So, add specific compatiblity for 3630 to allow match for Beagle-XM platform. Signed-off-by: NNishanth Menon <nm@ti.com> [tony@atomide.com: left out ti,omap343x, updated comments] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 08 10月, 2013 1 次提交
-
-
由 Benjamin Herrenschmidt 提交于
irq_exit() is now called on the irq stack, which can trigger a switch to the softirq stack from the irq stack. If an interrupt happens at that point, we will not properly detect the re-entrancy and clobber the original return context on the irq stack. This fixes it. The side effect is to prevent all nesting from softirq stack to irq stack even in the "safe" case but it's simpler that way and matches what x86_64 does. Reported-by: NCédric Le Goater <clg@fr.ibm.com> Tested-by: NCédric Le Goater <clg@fr.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 07 10月, 2013 1 次提交
-
-
由 James Hogan 提交于
Commit 1400eb65 (MIPS: r4k,octeon,r2300: stack protector: change canary per task) was merged in v3.11 and introduced assembly in the MIPS resume functions to update the value of the current canary in __stack_chk_guard. However it used PTR_L resulting in a load of the canary value, instead of PTR_LA to construct its address. The value is intended to be random but is then treated as an address in the subsequent LONG_S (store). This was observed to cause a fault and panic: CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4 Oops[#1]: ... $24 : 139fea20 1e1f7cb6 ... Call Trace: [<8000cc0c>] resume+0xac/0x118 [<8034f2a4>] __schedule+0x5f8/0x78c [<8034f4e0>] schedule_preempt_disabled+0x20/0x2c [<80348eec>] rest_init+0x74/0x84 [<804dc990>] start_kernel+0x43c/0x454 Code: 3c18804b 8f184030 8cb901f8 <af190000> 00c0e021 8cb002f0 8cb102f4 8cb202f8 8cb302fc This can also be forced by modifying arch/mips/include/asm/stackprotector.h so that the default __stack_chk_guard value is more likely to be a bad (or unaligned) pointer. Fix it to use PTR_LA instead, to load the address of the canary value, which the LONG_S can then use to write into it. Reported-by: bobjones (via #mipslinux on IRC) Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Gregory Fong <gregory.0xf0@gmail.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/6026/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 06 10月, 2013 1 次提交
-
-
由 Ville Syrjälä 提交于
Dell Latitude E5410 needs reboot=pci to actually reboot. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://lkml.kernel.org/r/1380888964-14517-1-git-send-email-ville.syrjala@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 05 10月, 2013 2 次提交
-
-
由 Bjorn Helgaas 提交于
This reverts commit 07f9b61c. 07f9b61c was intended to be a cleanup that didn't change anything, but in fact, for systems without _CBA (which is almost everything), it broke extended config space for domain 0 and all config space for other domains. Reference: http://lkml.kernel.org/r/20131004011806.GE20450@dangermouse.emea.sgi.comReported-by: NHedi Berriche <hedi@sgi.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Thomas Petazzoni 提交于
Commit ebd97be6 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option') removed the ARCH_SUPPORTS_MSI option which architectures could select to indicate that they support MSI. Now, all architectures are supposed to build fine when MSI support is enabled: instead of having the architecture tell *when* MSI support can be used, it's up to the architecture code to ensure that MSI support can be enabled. On x86, commit ebd97be6 removed the following line: select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC) Which meant that MSI support was only available when the local APIC and I/O APIC were enabled. While this is always true on SMP or x86-64, it is not necessarily the case on i386 !SMP. The below patch makes sure that the local APIC and I/O APIC support is always enabled when MSI support is enabled. To do so, it: * Ensures the X86_UP_APIC option is not visible when PCI_MSI is enabled. This is the option that allows, on UP machines, to enable or not the APIC support. It is already not visible on SMP systems, or x86-64 systems, for example. We're simply also making it invisible on i386 MSI systems. * Ensures that the X86_LOCAL_APIC and X86_IO_APIC options are 'y' when PCI_MSI is enabled. Notice that this change requires a change in drivers/iommu/Kconfig to avoid a recursive Kconfig dependencey. The AMD_IOMMU option selects PCI_MSI, but was depending on X86_IO_APIC. This dependency is no longer needed: as soon as PCI_MSI is selected, the presence of X86_IO_APIC is guaranteed. Moreover, the AMD_IOMMU already depended on X86_64, which already guaranteed that X86_IO_APIC was enabled, so this dependency was anyway redundant. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: http://lkml.kernel.org/r/1380794354-9079-1-git-send-email-thomas.petazzoni@free-electrons.comReported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 04 10月, 2013 2 次提交
-
-
由 Peter Zijlstra 提交于
Currently the cap_user_time_zero capability has different tests than cap_user_time; even though they expose the exact same data. Switch from CONSTANT && NONSTOP to sched_clock_stable to also deal with multi cabinet machines and drop the tsc_disabled() check.. non of this will work sanely without tsc anyway. Signed-off-by: NPeter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/n/tip-nmgn0j0muo1r4c94vlfh23xy@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Aaro Koskinen 提交于
With DT-based boot, the GPMC OneNAND sync mode setup does not work correctly. During the async mode setup, sync flags gets incorrectly set in the onenand_async data and the system crashes during the async setup. Also, the sync mode never gets set in gpmc_onenand_data->flags, so even without the crash, the actual sync mode setup would never be called. The patch fixes this by adjusting the gpmc_onenand_data->flags when the data is read from the DT. Also while doing this we force the onenand_async to be always async. The patch enables to use the following DTS chunk (that should correspond the arch/arm/mach-omap2/board-rm680.c board file setup) with Nokia N950, which currently crashes with 3.12-rc1. The crash output can be also found below. &gpmc { ranges = <0 0 0x04000000 0x20000000>; onenand@0,0 { #address-cells = <1>; #size-cells = <1>; reg = <0 0 0x20000000>; gpmc,sync-read; gpmc,sync-write; gpmc,burst-length = <16>; gpmc,burst-read; gpmc,burst-wrap; gpmc,burst-write; gpmc,device-width = <2>; gpmc,mux-add-data = <2>; gpmc,cs-on-ns = <0>; gpmc,cs-rd-off-ns = <87>; gpmc,cs-wr-off-ns = <87>; gpmc,adv-on-ns = <0>; gpmc,adv-rd-off-ns = <10>; gpmc,adv-wr-off-ns = <10>; gpmc,oe-on-ns = <15>; gpmc,oe-off-ns = <87>; gpmc,we-on-ns = <0>; gpmc,we-off-ns = <87>; gpmc,rd-cycle-ns = <112>; gpmc,wr-cycle-ns = <112>; gpmc,access-ns = <81>; gpmc,page-burst-access-ns = <15>; gpmc,bus-turnaround-ns = <0>; gpmc,cycle2cycle-delay-ns = <0>; gpmc,wait-monitoring-ns = <0>; gpmc,clk-activation-ns = <5>; gpmc,wr-data-mux-bus-ns = <30>; gpmc,wr-access-ns = <81>; gpmc,sync-clk-ps = <15000>; }; }; [ 1.467559] GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns [ 1.474822] GPMC CS0: cs_rd_off : 1 ticks, 5 ns (was 24 ticks) 5 ns [ 1.482116] GPMC CS0: cs_wr_off : 14 ticks, 71 ns (was 24 ticks) 71 ns [ 1.489349] GPMC CS0: adv_on : 0 ticks, 0 ns (was 0 ticks) 0 ns [ 1.496582] GPMC CS0: adv_rd_off: 3 ticks, 15 ns (was 3 ticks) 15 ns [ 1.503845] GPMC CS0: adv_wr_off: 3 ticks, 15 ns (was 3 ticks) 15 ns [ 1.511077] GPMC CS0: oe_on : 3 ticks, 15 ns (was 4 ticks) 15 ns [ 1.518310] GPMC CS0: oe_off : 1 ticks, 5 ns (was 24 ticks) 5 ns [ 1.525543] GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns [ 1.532806] GPMC CS0: we_off : 8 ticks, 40 ns (was 24 ticks) 40 ns [ 1.540039] GPMC CS0: rd_cycle : 4 ticks, 20 ns (was 29 ticks) 20 ns [ 1.547302] GPMC CS0: wr_cycle : 4 ticks, 20 ns (was 29 ticks) 20 ns [ 1.554504] GPMC CS0: access : 0 ticks, 0 ns (was 23 ticks) 0 ns [ 1.561767] GPMC CS0: page_burst_access: 0 ticks, 0 ns (was 3 ticks) 0 ns [ 1.569641] GPMC CS0: bus_turnaround: 0 ticks, 0 ns (was 0 ticks) 0 ns [ 1.577270] GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks) 0 ns [ 1.585144] GPMC CS0: wait_monitoring: 0 ticks, 0 ns (was 0 ticks) 0 ns [ 1.592834] GPMC CS0: clk_activation: 0 ticks, 0 ns (was 0 ticks) 0 ns [ 1.600463] GPMC CS0: wr_data_mux_bus: 5 ticks, 25 ns (was 8 ticks) 25 ns [ 1.608154] GPMC CS0: wr_access : 0 ticks, 0 ns (was 23 ticks) 0 ns [ 1.615386] GPMC CS0 CLK period is 5 ns (div 1) [ 1.625122] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf009e442 [ 1.633178] Internal error: : 1008 [#1] ARM [ 1.637573] Modules linked in: [ 1.640777] CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0-rc1-n9xx-los.git-5318619-00006-g4baa700-dirty #26 [ 1.651123] task: ef04c000 ti: ef050000 task.ti: ef050000 [ 1.656799] PC is at gpmc_onenand_setup+0x98/0x1e0 [ 1.661865] LR is at gpmc_cs_set_timings+0x494/0x5a4 [ 1.667083] pc : [<c002e040>] lr : [<c001f384>] psr: 60000113 [ 1.667083] sp : ef051d10 ip : ef051ce0 fp : ef051d94 [ 1.679138] r10: c0caaf60 r9 : ef050000 r8 : ef18b32c [ 1.684631] r7 : f0080000 r6 : c0caaf60 r5 : 00000000 r4 : f009e400 [ 1.691497] r3 : f009e442 r2 : 80050000 r1 : 00000014 r0 : 00000000 [ 1.698333] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 1.706024] Control: 10c5387d Table: af290019 DAC: 00000015 [ 1.712066] Process swapper (pid: 1, stack limit = 0xef050240) [ 1.718200] Stack: (0xef051d10 to 0xef052000) [ 1.722778] 1d00: 00004000 00001402 00000000 00000005 [ 1.731384] 1d20: 00000047 00000000 0000000f 0000000f 00000000 00000028 0000000f 00000005 [ 1.739990] 1d40: 00000000 00000000 00000014 00000014 00000000 00000000 00000000 00000000 [ 1.748596] 1d60: 00000000 00000019 00000000 00000000 ef18b000 ef099c50 c0c8cb30 00000000 [ 1.757171] 1d80: c0488074 c048f868 ef051dcc ef051d98 c024447c c002dfb4 00000000 c048f868 [ 1.765777] 1da0: 00000000 00000000 c010e4a4 c0dbbb7c c0c8cb40 00000000 c0ca2500 c0488074 [ 1.774383] 1dc0: ef051ddc ef051dd0 c01fd508 c0244370 ef051dfc ef051de0 c01fc204 c01fd4f4 [ 1.782989] 1de0: c0c8cb40 c0ca2500 c0c8cb74 00000000 ef051e1c ef051e00 c01fc3b0 c01fc104 [ 1.791595] 1e00: ef0983bc 00000000 c0ca2500 c01fc31c ef051e44 ef051e20 c01fa794 c01fc328 [ 1.800201] 1e20: ef03634c ef0983b0 ef27d534 c0ca2500 ef27d500 c0c9a2f8 ef051e54 ef051e48 [ 1.808807] 1e40: c01fbcfc c01fa744 ef051e84 ef051e58 c01fb838 c01fbce4 c0411df8 c0caa040 [ 1.817413] 1e60: ef051e84 c0ca2500 00000006 c0caa040 00000066 c0488074 ef051e9c ef051e88 [ 1.825988] 1e80: c01fca30 c01fb768 c04975b8 00000006 ef051eac ef051ea0 c01fd728 c01fc9bc [ 1.834594] 1ea0: ef051ebc ef051eb0 c048808c c01fd6e4 ef051f4c ef051ec0 c0008888 c0488080 [ 1.843200] 1ec0: 0000006f c046bae8 00000000 00000000 ef051efc ef051ee0 ef051f04 ef051ee8 [ 1.851806] 1ee0: c046d400 c0181218 c046d410 c18da8d5 c036a8e4 00000066 ef051f4c ef051f08 [ 1.860412] 1f00: c004b9a8 c046d41c c048f840 00000006 00000006 c046b488 00000000 c043ec08 [ 1.869018] 1f20: ef051f4c c04975b8 00000006 c0caa040 00000066 c046d410 c048f85c c048f868 [ 1.877593] 1f40: ef051f94 ef051f50 c046db8c c00087a0 00000006 00000006 c046d410 ffffffff [ 1.886199] 1f60: ffffffff ffffffff ffffffff 00000000 c0348fd0 00000000 00000000 00000000 [ 1.894805] 1f80: 00000000 00000000 ef051fac ef051f98 c0348fe0 c046daa8 00000000 00000000 [ 1.903411] 1fa0: 00000000 ef051fb0 c000e7f8 c0348fdc 00000000 00000000 00000000 00000000 [ 1.912017] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.920623] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [ 1.929199] Backtrace: [ 1.931793] [<c002dfa8>] (gpmc_onenand_setup+0x0/0x1e0) from [<c024447c>] (omap2_onenand_probe+0x118/0x49c) [ 1.942047] [<c0244364>] (omap2_onenand_probe+0x0/0x49c) from [<c01fd508>] (platform_drv_probe+0x20/0x24) [ 1.952117] r8:c0488074 r7:c0ca2500 r6:00000000 r5:c0c8cb40 r4:c0dbbb7c [ 1.959197] [<c01fd4e8>] (platform_drv_probe+0x0/0x24) from [<c01fc204>] (driver_probe_device+0x10c/0x224) [ 1.969360] [<c01fc0f8>] (driver_probe_device+0x0/0x224) from [<c01fc3b0>] (__driver_attach+0x94/0x98) [ 1.979125] r7:00000000 r6:c0c8cb74 r5:c0ca2500 r4:c0c8cb40 [ 1.985107] [<c01fc31c>] (__driver_attach+0x0/0x98) from [<c01fa794>] (bus_for_each_dev+0x5c/0x90) [ 1.994506] r6:c01fc31c r5:c0ca2500 r4:00000000 r3:ef0983bc [ 2.000488] [<c01fa738>] (bus_for_each_dev+0x0/0x90) from [<c01fbcfc>] (driver_attach+0x24/0x28) [ 2.009735] r6:c0c9a2f8 r5:ef27d500 r4:c0ca2500 [ 2.014587] [<c01fbcd8>] (driver_attach+0x0/0x28) from [<c01fb838>] (bus_add_driver+0xdc/0x260) [ 2.023742] [<c01fb75c>] (bus_add_driver+0x0/0x260) from [<c01fca30>] (driver_register+0x80/0xfc) [ 2.033081] r8:c0488074 r7:00000066 r6:c0caa040 r5:00000006 r4:c0ca2500 [ 2.040161] [<c01fc9b0>] (driver_register+0x0/0xfc) from [<c01fd728>] (__platform_driver_register+0x50/0x64) [ 2.050476] r5:00000006 r4:c04975b8 [ 2.054260] [<c01fd6d8>] (__platform_driver_register+0x0/0x64) from [<c048808c>] (omap2_onenand_driver_init+0x18/0x20) [ 2.065490] [<c0488074>] (omap2_onenand_driver_init+0x0/0x20) from [<c0008888>] (do_one_initcall+0xf4/0x150) [ 2.075836] [<c0008794>] (do_one_initcall+0x0/0x150) from [<c046db8c>] (kernel_init_freeable+0xf0/0x1b4) [ 2.085815] [<c046da9c>] (kernel_init_freeable+0x0/0x1b4) from [<c0348fe0>] (kernel_init+0x10/0xec) [ 2.095336] [<c0348fd0>] (kernel_init+0x0/0xec) from [<c000e7f8>] (ret_from_fork+0x14/0x3c) [ 2.104125] r4:00000000 r3:00000000 [ 2.107879] Code: ebffc3ae e2505000 ba00002e e2843042 (e1d320b0) [ 2.114318] ---[ end trace b8ee3e3e5e002451 ]--- Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 03 10月, 2013 8 次提交
-
-
由 Santosh Shilimkar 提交于
The generic code is well equipped to differentiate between SMP and UP configurations.However, there are some devices which use Cortex-A9 MP core IP with 1 CPU as configuration. To let these SOCs to co-exist in a CONFIG_SMP=y build by leveraging the SMP_ON_UP support, we need to additionally check the number the cores in Cortex-A9 MPCore configuration. Without such a check in place, the startup code tries to execute ALT_SMP() set of instructions which lead to CPU faults. The issue was spotted on TI's Aegis device and this patch makes now the device work with omap2plus_defconfig which enables SMP by default. The change is kept limited to only Cortex-A9 MPCore detection code. Note that if any future SoC *does* use 0x0 as the PERIPH_BASE, then the SCU address check code needs to be #ifdef'd for for the Aegis platform. Acked-by: NSricharan R <r.sricharan@ti.com> Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Andrea Adami 提交于
This fixes a regression for kernels after v3.2 After commit 72662e01 ARM: head.S: only include __turn_mmu_on in the initial identity mapping Zaurus PXA devices call sharpsl_save_param() during fixup and hang on boot because memcpy refers to physical addresses no longer valid if the MMU is setup. Zaurus collie (SA1100) is unaffected (function is called in init_machine). The code was making assumptions and for PXA the virtual address should have been used before. Signed-off-by: NMarko Katic <dromede@gmail.com> Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Ard Biesheuvel 提交于
Commit 09096f6a (ARM: 7822/1: add workaround for ambiguous C99 stdint.h types) introduced an ARM specific 'asm/types.h' to work around some ambiguities in the definitions of 32 bit types. Hence, we will not be needing the generic version anymore. Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
Currently mcpm_cpu_power_down() and mcpm_cpu_suspend() trigger BUG() if mcpm_platform_register() is not called beforehand. This may occur for many reasons such as some incomplete device tree passed to the kernel or the like. Let's be nicer to users and avoid killing the kernel if that happens by logging a warning and returning to the caller. The mcpm_cpu_suspend() user is already set to deal with this situation, and so is cpu_die() invoking mcpm_cpu_die(). The problematic case would have been the B.L switcher's usage of mcpm_cpu_power_down(), however it has to call mcpm_cpu_power_up() first which is already set to catch an error resulting from a missing mcpm_platform_register() call. Signed-off-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Michael Neuling 提交于
When we do a treclaim or trecheckpoint we end up running with userspace PPR and DSCR values. Currently we don't do anything special to avoid running with user values which could cause a severe performance degradation. This patch moves the PPR and DSCR save and restore around treclaim and trecheckpoint so that we run with user values for a much shorter period. More care is taken with the PPR as it's impact is greater than the DSCR. This is similar to user exceptions, where we run HTM_MEDIUM early to ensure that we don't run with a userspace PPR values in the kernel. Signed-off-by: NMichael Neuling <mikey@neuling.org> Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Neuling 提交于
We can't take IRQs in tm_reclaim as we might have a bogus r13 and r1. This turns IRQs hard off in this function. Signed-off-by: NMichael Neuling <mikey@neuling.org> Cc: <stable@vger.kernel.org> # 3.9+ Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
Commit 4df48999 "Add power8 EBB support" included a bug in the handling of the FAB_CRESP_MATCH and FAB_TYPE_MATCH fields. These values are pulled out of the event code using EVENT_THR_CTL_SHIFT, however we were then or'ing that value directly into MMCR1. This meant we were failing to set the FAB fields correctly, and also potentially corrupting the value for PMC4SEL. Leading to no counts for the FAB events and incorrect counts for PMC4. The fix is simply to shift left the FAB value correctly before or'ing it with MMCR1. Reported-by: NSooraj Ravindran Nair <soonair3@in.ibm.com> Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Prarit Bhargava 提交于
modalias_show() should return an empty string on error, not -ENODEV. This causes the following false and annoying error: > find /sys/devices -name modalias -print0 | xargs -0 cat >/dev/null cat: /sys/devices/vio/4000/modalias: No such device cat: /sys/devices/vio/4001/modalias: No such device cat: /sys/devices/vio/4002/modalias: No such device cat: /sys/devices/vio/4004/modalias: No such device cat: /sys/devices/vio/modalias: No such device Signed-off-by: NPrarit Bhargava <prarit@redhat.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> CC: <stable@vger.kernel.org>
-