* [PATCH 1/4] powerpc: Require gcc 4.0 on 64-bit
From: Anton Blanchard @ 2012-04-18 4:42 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
Older versions of gcc had issues with using -maltivec together with
-mcpu of a non altivec capable CPU. We work around it by specifying
-mcpu=970, but the logic is complicated.
In preparation for adding more -mcpu targets, remove the workaround
and just require gcc 4.0 for 64-bit builds.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
4.0 came out in 2005 and the gcc on RHEL5 and SLES10 looks to be 4.1.
I highly doubt a ppc64 kernel will build these days on either RHEL4 or
SLES9.
Anything else we have to worry about?
Index: linux-build/arch/powerpc/Makefile
===================================================================
--- linux-build.orig/arch/powerpc/Makefile 2012-04-18 11:59:31.444220933 +1000
+++ linux-build/arch/powerpc/Makefile 2012-04-18 11:59:58.860721391 +1000
@@ -234,10 +234,11 @@ archprepare: checkbin
# Use the file '.tmp_gas_check' for binutils tests, as gas won't output
# to stdout and these checks are run even on install targets.
TOUT := .tmp_gas_check
-# Ensure this is binutils 2.12.1 (or 2.12.90.0.7) or later for altivec
-# instructions.
-# gcc-3.4 and binutils-2.14 are a fatal combination.
+# Check gcc and binutils versions:
+# - gcc-3.4 and binutils-2.14 are a fatal combination
+# - Require gcc 4.0 or above on 64-bit
+# - gcc-4.2.0 has issues compiling modules on 64-bit
checkbin:
@if test "$(call cc-version)" = "0304" ; then \
if ! /bin/echo mftb 5 | $(AS) -v -mppc -many -o $(TOUT) >/dev/null 2>&1 ; then \
@@ -247,6 +248,12 @@ checkbin:
false; \
fi ; \
fi
+ @if test "$(call cc-version)" -lt "0400" \
+ && test "x${CONFIG_PPC64}" = "xy" ; then \
+ echo -n "Sorry, GCC v4.0 or above is required to build " ; \
+ echo "the 64-bit powerpc kernel." ; \
+ false ; \
+ fi
@if test "$(call cc-fullversion)" = "040200" \
&& test "x${CONFIG_MODULES}${CONFIG_PPC64}" = "xyy" ; then \
echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ; \
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: crash caused by null eeh_dev
From: Anton Blanchard @ 2012-04-18 1:16 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <1334642139-25447-1-git-send-email-shangw@linux.vnet.ibm.com>
Hi Gavin,
> The problem was reported by Anton Blanchard. While EEH error
> happened to the PCI device without the corresponding device
> driver, kernel crash was seen. Eventually, I successfully
> reproduced the problem on Firebird-L machine with utility
> "errinjct". Initially, the device driver for Emulex ethernet
> MAC has been disabled from .config and force data parity on
> the Emulex ethernet MAC with help of "errinjct". Eventually,
> I saw the kernel crash after issueing couple of "lspci -v"
> command.
>
> The root cause behind is that the PCI device, including the
> reference to the corresponding eeh device, will be removed
> from the system while EEH does recovery. Afterwards, the
> PCI device will be probed again and added into the system
> accordingly. So it's not safe to retrieve the eeh device from
> the corresponding PCI device after the PCI device has been removed
> and not added again.
>
> The patch fixes the issue and retrieve the eeh device from OF node
> instead of PCI device after the PCI device has been removed.
Thanks, this does fix the oops I see.
Tested-by: Anton Blanchard <anton@samba.org>
Anton
> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/pseries/eeh.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/eeh.c
> b/arch/powerpc/platforms/pseries/eeh.c index 309d38e..a75e37d 100644
> --- a/arch/powerpc/platforms/pseries/eeh.c
> +++ b/arch/powerpc/platforms/pseries/eeh.c
> @@ -1076,7 +1076,7 @@ static void eeh_add_device_late(struct pci_dev
> *dev) pr_debug("EEH: Adding device %s\n", pci_name(dev));
>
> dn = pci_device_to_OF_node(dev);
> - edev = pci_dev_to_eeh_dev(dev);
> + edev = of_node_to_eeh_dev(dn);
> if (edev->pdev == dev) {
> pr_debug("EEH: Already referenced !\n");
> return;
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add back condition for smp
From: Scott Wood @ 2012-04-17 22:17 UTC (permalink / raw)
To: York Sun; +Cc: PPC list
In-Reply-To: <1334698746-11529-1-git-send-email-yorksun@freescale.com>
On 04/17/2012 04:39 PM, York Sun wrote:
> The timebase synchronization is only necessary if we need to reset a
> separate core. Currently only KEXEC and CPU hotplug require resetting
> a single core. The following code should be in the condition of
> CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
>
> .give_timebase = smp_generic_give_timebase,
> .take_timebase = smp_generic_take_timebase,
>
> Signed-off-by: York Sun <yorksun@freescale.com>
> Acked-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
> index 56942af..868c6d7 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops = {
> .cpu_disable = generic_cpu_disable,
> .cpu_die = generic_cpu_die,
> #endif
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
> .give_timebase = smp_generic_give_timebase,
> .take_timebase = smp_generic_take_timebase,
> +#endif
> };
>
> #ifdef CONFIG_KEXEC
Note that this is only a temporary fix, that assumes the environments
where tbsync is problematic[1] (virtualization and simulation) do not
enable CONFIG_KEXEC or CONFIG_HOTPLUG_CPU. Eventually the sync should
be done via CCSR like in U-Boot, and the decision on whether to do it
should be runtime.
-Scott
[1] More so than usual.
^ permalink raw reply
* Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
From: Borislav Petkov @ 2012-04-17 21:40 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Shaohui Xie, Jason Uhlenkott, Hitoshi Mitake, Mark Gross,
Dmitry Eremin-Solenikov, Ranganathan Desikan, Borislav Petkov,
Egor Martovetsky, Niklas Söderlund, Tim Small, Arvind R.,
Chris Metcalf, Olof Johansson, Doug Thompson,
Linux Edac Mailing List, Michal Marek, Jiri Kosina,
Linux Kernel Mailing List, Joe Perches, Andrew Morton,
linuxppc-dev
In-Reply-To: <4F8DC471.3050809@redhat.com>
On Tue, Apr 17, 2012 at 04:28:49PM -0300, Mauro Carvalho Chehab wrote:
> Ok. well, we can either multiply nr_pages by channel_count or to let it
> clear that this is per channel. I prefer the last option (see the enclosed
> patch).
>
> >> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> >> int i, j, empty = 1;
> >> enum mem_type mtype;
> >> enum edac_type edac_mode;
> >> + int nr_pages;
> >>
> >> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
> >>
> >> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
> >> i, pvt->mc_node_id);
> >>
> >> empty = 0;
> >> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> >> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> >> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
> >> /* 8 bytes of resolution */
> >>
> >> mtype = amd64_determine_memory_type(pvt, i);
> >>
> >> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
> >> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
> >> + debugf1(" nr_pages: %u\n", nr_pages);
> >>
> >> /*
> >> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
> >> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> >> for (j = 0; j < pvt->channel_count; j++) {
> >> csrow->channels[j].dimm->mtype = mtype;
> >> csrow->channels[j].dimm->edac_mode = edac_mode;
> >> + csrow->channels[j].dimm->nr_pages = nr_pages;
> >
> > I'm guessing you want to accumulate the nr_pages for all channels here
> > and dump it properly?
> >
>
> As you've requested to not move the debugf0() to be after the loop, it is
> easier to just multiply it at the printk. As an advantage, when the kernel
> is compiled without debug, no code will be produced.
>
> IMO, the best way to solve it is with this small patch. If you're ok, I'll
> fold it with this one and add your ack.
>
> Regards,
> Mauro
>
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 8804ac8..6d6ec68 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -2127,7 +2127,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>
> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
> - debugf0(" nr_pages= %u channel-count = %d\n",
> + debugf0(" nr_pages/channel= %u channel-count = %d\n",
> nr_pages, pvt->channel_count);
>
> return nr_pages;
> @@ -2176,7 +2176,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> mtype = amd64_determine_memory_type(pvt, i);
>
> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
> - debugf1(" nr_pages: %u\n", nr_pages);
> + debugf1(" nr_pages: %u\n", nr_pages * pvt->channel_count);
>
> /*
> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
Yeah, this is basically what the code did anyway, so yes, please fold it
in and you can add my ACK. I'll continue reviewing the rest tomorrow.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* [PATCH] powerpc/85xx: Add back condition for smp
From: York Sun @ 2012-04-17 21:39 UTC (permalink / raw)
To: linuxppc-dev
The timebase synchronization is only necessary if we need to reset a
separate core. Currently only KEXEC and CPU hotplug require resetting
a single core. The following code should be in the condition of
CONFIG_KEXEC or CONFIG_HOTPLUG_CPU
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
Signed-off-by: York Sun <yorksun@freescale.com>
Acked-by: Li Yang <leoli@freescale.com>
---
arch/powerpc/platforms/85xx/smp.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index 56942af..868c6d7 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -192,8 +192,10 @@ struct smp_ops_t smp_85xx_ops = {
.cpu_disable = generic_cpu_disable,
.cpu_die = generic_cpu_die,
#endif
+#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
.give_timebase = smp_generic_give_timebase,
.take_timebase = smp_generic_take_timebase,
+#endif
};
#ifdef CONFIG_KEXEC
--
1.7.0.4
^ permalink raw reply related
* PowerPC radeon KMS - is it possible?
From: o jordan @ 2012-04-17 19:49 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]
Hi list,
Firstly let me say thanks for the great work you do!!!
I've been trying to get Kernel Mode Setting working on my iBook with Ubuntu 12.04. I can only get it working by forcing PCI mode (agpmode=-1). Setting agpmode=1 or a higher number just results in freezing and a flashing screen. Does anybody know how to get it working fully with agp?
I've tried the Debian experimental kernel with the same results. I notice with Fedora 16 they also recommend setting agpmode=-1 with a radeon card. So I'm guessing there is no easy fix??
I've been trying to sort out the kernel configuration for ati/radeon cards with Ubuntu. I raised a bug to build back in the framebuffers https://bugs.launchpad.net/ubuntu/+source/linux/+bug/949288 . I'd appreciate any help with that bug report.
With Userspace Mode Setting there is nolonger any 3D hardware acceleration (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 ) so this is why I'm interested in getting KMS working properly. However, some people seem to really want suspend which currently requires radeonfb. So I'm trying to find a kernel configuration that works well for UMS and KMS!!!
This is what I proposed:
CONFIG_DRM_RADEON_KMS=y
CONFIG_FB_RADEON=y
CONFIG_FB_ATY128=y
CONFIG_FB_ATY=y
So people can disable radeonfb from the yaboot prompt/conf if they want fully working KMS. I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or built in. We are now in kernel freeze for 12.04 so to get any changes is going to take some serious begging!!!
Cheers
Adam
[-- Attachment #2: Type: text/html, Size: 2180 bytes --]
^ permalink raw reply
* [PATCH 1/2] seccomp: ignore secure_computing return values
From: Will Drewry @ 2012-04-17 19:48 UTC (permalink / raw)
To: jmorris
Cc: linux-mips, linux-sh, Heiko Carstens, David Howells,
Paul Mackerras, Eric Paris, H. Peter Anvin, sparclinux, Kees Cook,
sfr, Richard Weinberger, Avi Kivity, Frederic Weisbecker,
Ingo Molnar, Serge Hallyn, Peter Zijlstra, linux-s390,
microblaze-uclinux, James Morris, Michal Simek, Tony Luck,
Will Drewry, linux-kernel, Ralf Baechle, linux-security-module,
Paul Mundt, Martin Schwidefsky, linux390, linuxppc-dev,
David S. Miller
This change is inspired by
https://lkml.org/lkml/2012/4/16/14
which fixes the build warnings for arches that don't support
CONFIG_HAVE_ARCH_SECCOMP_FILTER.
In particular, there is no requirement for the return value of
secure_computing() to be checked unless the architecture supports
seccomp filter. Instead of silencing the warnings with (void)
a new static inline is added to encode the expected behavior
in a compiler and human friendly way.
v2: - cleans things up with a static inline
- removes sfr's signed-off-by since it is a different approach
v1: - matches sfr's original change
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Will Drewry <wad@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
---
arch/microblaze/kernel/ptrace.c | 2 +-
arch/mips/kernel/ptrace.c | 2 +-
arch/powerpc/kernel/ptrace.c | 2 +-
arch/s390/kernel/ptrace.c | 2 +-
arch/sh/kernel/ptrace_32.c | 2 +-
arch/sh/kernel/ptrace_64.c | 2 +-
arch/sparc/kernel/ptrace_64.c | 2 +-
include/linux/seccomp.h | 7 +++++++
8 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/microblaze/kernel/ptrace.c b/arch/microblaze/kernel/ptrace.c
index 6eb2aa9..ab1b9db 100644
--- a/arch/microblaze/kernel/ptrace.c
+++ b/arch/microblaze/kernel/ptrace.c
@@ -136,7 +136,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
{
long ret = 0;
- secure_computing(regs->r12);
+ secure_computing_strict(regs->r12);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c
index 7c24c29..4812c6d 100644
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@ -535,7 +535,7 @@ static inline int audit_arch(void)
asmlinkage void syscall_trace_enter(struct pt_regs *regs)
{
/* do the secure computing check first */
- secure_computing(regs->regs[2]);
+ secure_computing_strict(regs->regs[2]);
if (!(current->ptrace & PT_PTRACED))
goto out;
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 8d8e028..dd5e214 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -1710,7 +1710,7 @@ long do_syscall_trace_enter(struct pt_regs *regs)
{
long ret = 0;
- secure_computing(regs->gpr[0]);
+ secure_computing_strict(regs->gpr[0]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
index 02f300f..4993e68 100644
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -719,7 +719,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
long ret = 0;
/* Do the secure computing check first. */
- secure_computing(regs->gprs[2]);
+ secure_computing_strict(regs->gprs[2]);
/*
* The sysc_tracesys code in entry.S stored the system
diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c
index 9698671..81f999a 100644
--- a/arch/sh/kernel/ptrace_32.c
+++ b/arch/sh/kernel/ptrace_32.c
@@ -503,7 +503,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs *regs)
{
long ret = 0;
- secure_computing(regs->regs[0]);
+ secure_computing_strict(regs->regs[0]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/sh/kernel/ptrace_64.c b/arch/sh/kernel/ptrace_64.c
index bc81e07..af90339 100644
--- a/arch/sh/kernel/ptrace_64.c
+++ b/arch/sh/kernel/ptrace_64.c
@@ -522,7 +522,7 @@ asmlinkage long long do_syscall_trace_enter(struct pt_regs *regs)
{
long long ret = 0;
- secure_computing(regs->regs[9]);
+ secure_computing_strict(regs->regs[9]);
if (test_thread_flag(TIF_SYSCALL_TRACE) &&
tracehook_report_syscall_entry(regs))
diff --git a/arch/sparc/kernel/ptrace_64.c b/arch/sparc/kernel/ptrace_64.c
index 6f97c07..484daba 100644
--- a/arch/sparc/kernel/ptrace_64.c
+++ b/arch/sparc/kernel/ptrace_64.c
@@ -1062,7 +1062,7 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
int ret = 0;
/* do the secure computing check first */
- secure_computing(regs->u_regs[UREG_G1]);
+ secure_computing_strict(regs->u_regs[UREG_G1]);
if (test_thread_flag(TIF_SYSCALL_TRACE))
ret = tracehook_report_syscall_entry(regs);
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 60f2b35..84f6320d 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -75,6 +75,12 @@ static inline int secure_computing(int this_syscall)
return 0;
}
+/* A wrapper for architectures supporting only SECCOMP_MODE_STRICT. */
+static inline void secure_computing_strict(int this_syscall)
+{
+ BUG_ON(secure_computing(this_syscall) != 0);
+}
+
extern long prctl_get_seccomp(void);
extern long prctl_set_seccomp(unsigned long, char __user *);
@@ -91,6 +97,7 @@ struct seccomp { };
struct seccomp_filter { };
static inline int secure_computing(int this_syscall) { return 0; }
+static inline void secure_computing_strict(int this_syscall) { return; }
static inline long prctl_get_seccomp(void)
{
--
1.7.5.4
^ permalink raw reply related
* Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
From: Mauro Carvalho Chehab @ 2012-04-17 19:28 UTC (permalink / raw)
To: Borislav Petkov
Cc: Shaohui Xie, Jason Uhlenkott, Hitoshi Mitake, Mark Gross,
Dmitry Eremin-Solenikov, Ranganathan Desikan, Egor Martovetsky,
Niklas Söderlund, Tim Small, Arvind R., Chris Metcalf,
Olof Johansson, Doug Thompson, Linux Edac Mailing List,
Michal Marek, Jiri Kosina, Linux Kernel Mailing List, Joe Perches,
Andrew Morton, linuxppc-dev
In-Reply-To: <20120417184808.GD13989@aftab>
Em 17-04-2012 15:48, Borislav Petkov escreveu:
> On Mon, Apr 16, 2012 at 05:12:10PM -0300, Mauro Carvalho Chehab wrote:
>> The number of pages is a dimm property. Move it to the dimm struct.
>>
>> After this change, it is possible to add sysfs nodes for the DIMM's that
>
> Minor nitpick:
>
> DIMMs
>
> Please go over the rest of the commit messages because they have similar
> typos.
>
>> will properly represent the DIMM stick properties, including its size.
>>
>> A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
>> the memory controller represents the memory via chip select rows.
>>
>> Reviewed-by: Aristeu Rozanski <arozansk@redhat.com>
>> Cc: Doug Thompson <norsk5@yahoo.com>
>> Cc: Borislav Petkov <borislav.petkov@amd.com>
>> Cc: Mark Gross <mark.gross@intel.com>
>> Cc: Jason Uhlenkott <juhlenko@akamai.com>
>> Cc: Tim Small <tim@buttersideup.com>
>> Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
>> Cc: "Arvind R." <arvino55@gmail.com>
>> Cc: Olof Johansson <olof@lixom.net>
>> Cc: Egor Martovetsky <egor@pasemi.com>
>> Cc: Chris Metcalf <cmetcalf@tilera.com>
>> Cc: Michal Marek <mmarek@suse.cz>
>> Cc: Jiri Kosina <jkosina@suse.cz>
>> Cc: Joe Perches <joe@perches.com>
>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Hitoshi Mitake <h.mitake@gmail.com>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
>> Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
>> Cc: Josh Boyer <jwboyer@gmail.com>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>> ---
>> drivers/edac/amd64_edac.c | 12 +++------
>> drivers/edac/amd76x_edac.c | 6 ++--
>> drivers/edac/cell_edac.c | 8 ++++--
>> drivers/edac/cpc925_edac.c | 8 ++++--
>> drivers/edac/e752x_edac.c | 6 +++-
>> drivers/edac/e7xxx_edac.c | 5 ++-
>> drivers/edac/edac_mc.c | 16 ++++++++-----
>> drivers/edac/edac_mc_sysfs.c | 47 ++++++++++++++++++++++++++++------------
>> drivers/edac/i3000_edac.c | 6 +++-
>> drivers/edac/i3200_edac.c | 3 +-
>> drivers/edac/i5000_edac.c | 14 ++++++-----
>> drivers/edac/i5100_edac.c | 22 +++++++++++-------
>> drivers/edac/i5400_edac.c | 9 ++-----
>> drivers/edac/i7300_edac.c | 22 +++++-------------
>> drivers/edac/i7core_edac.c | 10 ++------
>> drivers/edac/i82443bxgx_edac.c | 2 +-
>> drivers/edac/i82860_edac.c | 2 +-
>> drivers/edac/i82875p_edac.c | 5 ++-
>> drivers/edac/i82975x_edac.c | 11 ++++++--
>> drivers/edac/mpc85xx_edac.c | 3 +-
>> drivers/edac/mv64x60_edac.c | 3 +-
>> drivers/edac/pasemi_edac.c | 14 ++++++------
>> drivers/edac/ppc4xx_edac.c | 5 ++-
>> drivers/edac/r82600_edac.c | 3 +-
>> drivers/edac/sb_edac.c | 8 +-----
>> drivers/edac/tile_edac.c | 2 +-
>> drivers/edac/x38_edac.c | 4 +-
>> include/linux/edac.h | 8 ++++--
>> 28 files changed, 144 insertions(+), 120 deletions(-)
>>
>> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
>> index 0be3f29..8804ac8 100644
>> --- a/drivers/edac/amd64_edac.c
>> +++ b/drivers/edac/amd64_edac.c
>> @@ -2126,12 +2126,6 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
>>
>> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>>
>> - /*
>> - * If dual channel then double the memory size of single channel.
>> - * Channel count is 1 or 2
>> - */
>> - nr_pages <<= (pvt->channel_count - 1);
>
> This changes DEBUG output from:
>
> EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
> EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
> EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 1048576 channel-count = 2
> EDAC amd64: CS0: Registered DDR3 RAM
> EDAC DEBUG: init_csrows: for MC node 0 csrow 0:
> EDAC DEBUG: init_csrows: nr_pages: 1048576
>
> to
>
> EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
> EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
> EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
>
> which is only half the pages.
>
>> -
>> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
>> debugf0(" nr_pages= %u channel-count = %d\n",
>> nr_pages, pvt->channel_count);
Ok. well, we can either multiply nr_pages by channel_count or to let it
clear that this is per channel. I prefer the last option (see the enclosed
patch).
>> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>> int i, j, empty = 1;
>> enum mem_type mtype;
>> enum edac_type edac_mode;
>> + int nr_pages;
>>
>> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
>>
>> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
>> i, pvt->mc_node_id);
>>
>> empty = 0;
>> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
>> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
>> /* 8 bytes of resolution */
>>
>> mtype = amd64_determine_memory_type(pvt, i);
>>
>> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
>> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
>> + debugf1(" nr_pages: %u\n", nr_pages);
>>
>> /*
>> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
>> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
>> for (j = 0; j < pvt->channel_count; j++) {
>> csrow->channels[j].dimm->mtype = mtype;
>> csrow->channels[j].dimm->edac_mode = edac_mode;
>> + csrow->channels[j].dimm->nr_pages = nr_pages;
>
> I'm guessing you want to accumulate the nr_pages for all channels here
> and dump it properly?
>
As you've requested to not move the debugf0() to be after the loop, it is
easier to just multiply it at the printk. As an advantage, when the kernel
is compiled without debug, no code will be produced.
IMO, the best way to solve it is with this small patch. If you're ok, I'll
fold it with this one and add your ack.
Regards,
Mauro
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 8804ac8..6d6ec68 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2127,7 +2127,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
- debugf0(" nr_pages= %u channel-count = %d\n",
+ debugf0(" nr_pages/channel= %u channel-count = %d\n",
nr_pages, pvt->channel_count);
return nr_pages;
@@ -2176,7 +2176,7 @@ static int init_csrows(struct mem_ctl_info *mci)
mtype = amd64_determine_memory_type(pvt, i);
debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
- debugf1(" nr_pages: %u\n", nr_pages);
+ debugf1(" nr_pages: %u\n", nr_pages * pvt->channel_count);
/*
* determine whether CHIPKILL or JUST ECC or NO ECC is operating
^ permalink raw reply related
* Re: [EDAC PATCH v13 4/7] edac: move nr_pages to dimm struct
From: Borislav Petkov @ 2012-04-17 18:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Shaohui Xie, Jason Uhlenkott, Hitoshi Mitake, Mark Gross,
Dmitry Eremin-Solenikov, Ranganathan Desikan, Egor Martovetsky,
Niklas Söderlund, Tim Small, Arvind R., Chris Metcalf,
Olof Johansson, Doug Thompson, Linux Edac Mailing List,
Michal Marek, Jiri Kosina, Linux Kernel Mailing List, Joe Perches,
Andrew Morton, linuxppc-dev
In-Reply-To: <1334607133-30039-5-git-send-email-mchehab@redhat.com>
On Mon, Apr 16, 2012 at 05:12:10PM -0300, Mauro Carvalho Chehab wrote:
> The number of pages is a dimm property. Move it to the dimm struct.
>
> After this change, it is possible to add sysfs nodes for the DIMM's that
Minor nitpick:
DIMMs
Please go over the rest of the commit messages because they have similar
typos.
> will properly represent the DIMM stick properties, including its size.
>
> A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
> the memory controller represents the memory via chip select rows.
>
> Reviewed-by: Aristeu Rozanski <arozansk@redhat.com>
> Cc: Doug Thompson <norsk5@yahoo.com>
> Cc: Borislav Petkov <borislav.petkov@amd.com>
> Cc: Mark Gross <mark.gross@intel.com>
> Cc: Jason Uhlenkott <juhlenko@akamai.com>
> Cc: Tim Small <tim@buttersideup.com>
> Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
> Cc: "Arvind R." <arvino55@gmail.com>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: Egor Martovetsky <egor@pasemi.com>
> Cc: Chris Metcalf <cmetcalf@tilera.com>
> Cc: Michal Marek <mmarek@suse.cz>
> Cc: Jiri Kosina <jkosina@suse.cz>
> Cc: Joe Perches <joe@perches.com>
> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Hitoshi Mitake <h.mitake@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
> Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
> Cc: Josh Boyer <jwboyer@gmail.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> ---
> drivers/edac/amd64_edac.c | 12 +++------
> drivers/edac/amd76x_edac.c | 6 ++--
> drivers/edac/cell_edac.c | 8 ++++--
> drivers/edac/cpc925_edac.c | 8 ++++--
> drivers/edac/e752x_edac.c | 6 +++-
> drivers/edac/e7xxx_edac.c | 5 ++-
> drivers/edac/edac_mc.c | 16 ++++++++-----
> drivers/edac/edac_mc_sysfs.c | 47 ++++++++++++++++++++++++++++------------
> drivers/edac/i3000_edac.c | 6 +++-
> drivers/edac/i3200_edac.c | 3 +-
> drivers/edac/i5000_edac.c | 14 ++++++-----
> drivers/edac/i5100_edac.c | 22 +++++++++++-------
> drivers/edac/i5400_edac.c | 9 ++-----
> drivers/edac/i7300_edac.c | 22 +++++-------------
> drivers/edac/i7core_edac.c | 10 ++------
> drivers/edac/i82443bxgx_edac.c | 2 +-
> drivers/edac/i82860_edac.c | 2 +-
> drivers/edac/i82875p_edac.c | 5 ++-
> drivers/edac/i82975x_edac.c | 11 ++++++--
> drivers/edac/mpc85xx_edac.c | 3 +-
> drivers/edac/mv64x60_edac.c | 3 +-
> drivers/edac/pasemi_edac.c | 14 ++++++------
> drivers/edac/ppc4xx_edac.c | 5 ++-
> drivers/edac/r82600_edac.c | 3 +-
> drivers/edac/sb_edac.c | 8 +-----
> drivers/edac/tile_edac.c | 2 +-
> drivers/edac/x38_edac.c | 4 +-
> include/linux/edac.h | 8 ++++--
> 28 files changed, 144 insertions(+), 120 deletions(-)
>
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index 0be3f29..8804ac8 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -2126,12 +2126,6 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 dct, int csrow_nr)
>
> nr_pages = pvt->ops->dbam_to_cs(pvt, dct, cs_mode) << (20 - PAGE_SHIFT);
>
> - /*
> - * If dual channel then double the memory size of single channel.
> - * Channel count is 1 or 2
> - */
> - nr_pages <<= (pvt->channel_count - 1);
This changes DEBUG output from:
EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 1048576 channel-count = 2
EDAC amd64: CS0: Registered DDR3 RAM
EDAC DEBUG: init_csrows: for MC node 0 csrow 0:
EDAC DEBUG: init_csrows: nr_pages: 1048576
to
EDAC DEBUG: init_csrows: ----CSROW 0 VALID for MC node 0
EDAC DEBUG: amd64_csrow_nr_pages: (csrow=0) DBAM map index= 8
EDAC DEBUG: amd64_csrow_nr_pages: nr_pages= 524288 channel-count = 2
which is only half the pages.
> -
> debugf0(" (csrow=%d) DBAM map index= %d\n", csrow_nr, cs_mode);
> debugf0(" nr_pages= %u channel-count = %d\n",
> nr_pages, pvt->channel_count);
> @@ -2152,6 +2146,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> int i, j, empty = 1;
> enum mem_type mtype;
> enum edac_type edac_mode;
> + int nr_pages;
>
> amd64_read_pci_cfg(pvt->F3, NBCFG, &val);
>
> @@ -2174,14 +2169,14 @@ static int init_csrows(struct mem_ctl_info *mci)
> i, pvt->mc_node_id);
>
> empty = 0;
> - csrow->nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> + nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
> get_cs_base_and_mask(pvt, i, 0, &base, &mask);
> /* 8 bytes of resolution */
>
> mtype = amd64_determine_memory_type(pvt, i);
>
> debugf1(" for MC node %d csrow %d:\n", pvt->mc_node_id, i);
> - debugf1(" nr_pages: %u\n", csrow->nr_pages);
> + debugf1(" nr_pages: %u\n", nr_pages);
>
> /*
> * determine whether CHIPKILL or JUST ECC or NO ECC is operating
> @@ -2195,6 +2190,7 @@ static int init_csrows(struct mem_ctl_info *mci)
> for (j = 0; j < pvt->channel_count; j++) {
> csrow->channels[j].dimm->mtype = mtype;
> csrow->channels[j].dimm->edac_mode = edac_mode;
> + csrow->channels[j].dimm->nr_pages = nr_pages;
I'm guessing you want to accumulate the nr_pages for all channels here
and dump it properly?
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
From: Tabi Timur-B04825 @ 2012-04-17 18:09 UTC (permalink / raw)
To: Huang Changming-R66093; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1334654129-1044-1-git-send-email-Chang-Ming.Huang@freescale.com>
On Tue, Apr 17, 2012 at 4:15 AM, <Chang-Ming.Huang@freescale.com> wrote:
> diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platfo=
rms/85xx/p1022_ds.c
> index e74b7cd..0db3a7e 100644
> --- a/arch/powerpc/platforms/85xx/p1022_ds.c
> +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> @@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
> =A0static struct of_device_id __initdata p1022_ds_ids[] =3D {
> =A0 =A0 =A0 =A0/* So that the DMA channel nodes can be probed individuall=
y: */
> =A0 =A0 =A0 =A0{ .compatible =3D "fsl,eloplus-dma", },
> + =A0 =A0 =A0 { .compatible =3D "fsl,p1022-elbc", },
> =A0 =A0 =A0 =A0{},
> =A0};
Have you actually tested this with an upstream kernel? p1022_ds_ids[]
is broken upstream, so adding a new line won't work.
Take a look at http://patchwork.ozlabs.org/patch/128533/
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH v4 1/4] powerpc/85xx: add HOTPLUG_CPU support
From: Scott Wood @ 2012-04-17 16:25 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Zhao Chenhui-B35336
In-Reply-To: <94F013E7935FF44C83EBE7784D62AD3F092D1098@039-SN2MPN1-022.039d.mgd.msft.net>
On 04/17/2012 04:51 AM, Li Yang-R58472 wrote:
>>> struct smp_ops_t smp_85xx_ops = {
>>> .kick_cpu = smp_85xx_kick_cpu,
>>> -#ifdef CONFIG_KEXEC
>>> +#ifdef CONFIG_HOTPLUG_CPU
>>> + .cpu_disable = generic_cpu_disable,
>>> + .cpu_die = generic_cpu_die,
>>> +#endif
>>> .give_timebase = smp_generic_give_timebase,
>>> .take_timebase = smp_generic_take_timebase,
>>> -#endif
>>> };
>>
>> We need to stop using smp_generic_give/take_timebase, not expand its use.
>> This stuff breaks under hypervisors where timebase can't be written. It
>> wasn't too bad before since we generally didn't enable CONFIG_KEXEC, but
>> we're more likely to want CONFIG_HOTPLUG_CPU.
>
> I understand that the guest OS shouldn't change the real timebase.
Cannot change it, and we've seen the tbsync code loop forever when it
tries (since the changes aren't taking effect).
> But no matter what timebase syncing method we are using, the timebase need to be changed anyway for certain features.
That's why I said to do it the way U-Boot does it.
> I think the better way should be trapping timebase modification in the hypervisor.
It does trap. Currently we treat it as a no-op. The only reasonable
alternative is to give the guest an exception. It is simply not allowed
for a guest to modify the timebase -- we are not going to break the
host's timebase sync. See the virtualized implementation note in
section 9.2.1 of book III-E of Power ISA 2.06B: "In virtualized
implementations, TBU and TBL are read-only."
>> Do the timebase sync the way U-Boot does -- if you find the appropriate
>> guts node in the device tree.
>
> That involves stopping timebase for a short time on all cores including the cores that are still online. Won't this be a potential issue?
I don't think it's a big deal in the contexts where you'd be doing
this -- at least not worse than the current situation. Just make sure
that you don't reset the timebase to zero or otherwise make a core see
the timebase go backward.
-Scott
^ permalink raw reply
* Re: [PATCH] Drivers: ps3: ps3av.c: fixed checkpatch warnings
From: Geert Uytterhoeven @ 2012-04-17 12:53 UTC (permalink / raw)
To: Valentin Ilie; +Cc: geoff, cbe-oss-dev, linuxppc-dev, linux-kernel
In-Reply-To: <1334661361-3699-1-git-send-email-valentin.ilie@gmail.com>
On Tue, Apr 17, 2012 at 13:16, Valentin Ilie <valentin.ilie@gmail.com> wrot=
e:
> diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
> index a409fa0..46136b0 100644
> --- a/drivers/ps3/ps3av.c
> +++ b/drivers/ps3/ps3av.c
> @@ -25,8 +25,8 @@
> =C2=A0#include <linux/ioctl.h>
> =C2=A0#include <linux/fb.h>
> =C2=A0#include <linux/slab.h>
> +#include <linux/firmware.h>
>
> -#include <asm/firmware.h>
NAK. It really needs <asm/firmware.h> (have you compiled the result?).
Gr{oetje,eeting}s,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0 -- Linus Torvalds
^ permalink raw reply
* [PATCH] Drivers: ps3: ps3av.c: fixed checkpatch warnings
From: Valentin Ilie @ 2012-04-17 11:16 UTC (permalink / raw)
To: geoff; +Cc: cbe-oss-dev, Valentin Ilie, linuxppc-dev, linux-kernel
Fixed some indenting problems.
Signed-off-by: Valentin Ilie <valentin.ilie@gmail.com>
---
drivers/ps3/ps3av.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/ps3/ps3av.c b/drivers/ps3/ps3av.c
index a409fa0..46136b0 100644
--- a/drivers/ps3/ps3av.c
+++ b/drivers/ps3/ps3av.c
@@ -25,8 +25,8 @@
#include <linux/ioctl.h>
#include <linux/fb.h>
#include <linux/slab.h>
+#include <linux/firmware.h>
-#include <asm/firmware.h>
#include <asm/ps3av.h>
#include <asm/ps3.h>
@@ -338,7 +338,7 @@ int ps3av_do_pkt(u32 cid, u16 send_len, size_t usr_buf_size,
mutex_unlock(&ps3av->mutex);
return 0;
- err:
+err:
mutex_unlock(&ps3av->mutex);
printk(KERN_ERR "%s: failed cid:%x res:%d\n", __func__, cid, res);
return res;
@@ -477,7 +477,6 @@ int ps3av_set_audio_mode(u32 ch, u32 fs, u32 word_bits, u32 format, u32 source)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_audio_mode);
static int ps3av_set_videomode(void)
@@ -870,21 +869,18 @@ int ps3av_set_video_mode(int id)
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_set_video_mode);
int ps3av_get_auto_mode(void)
{
return ps3av_auto_videomode(&ps3av->av_hw_conf);
}
-
EXPORT_SYMBOL_GPL(ps3av_get_auto_mode);
int ps3av_get_mode(void)
{
return ps3av ? ps3av->ps3av_mode : 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_get_mode);
/* get resolution by video_mode */
@@ -902,7 +898,6 @@ int ps3av_video_mode2res(u32 id, u32 *xres, u32 *yres)
*yres = video_mode_table[id].y;
return 0;
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mode2res);
/* mute */
@@ -911,7 +906,6 @@ int ps3av_video_mute(int mute)
return ps3av_set_av_video_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_video_mute);
/* mute analog output only */
@@ -935,7 +929,6 @@ int ps3av_audio_mute(int mute)
return ps3av_set_audio_mute(mute ? PS3AV_CMD_MUTE_ON
: PS3AV_CMD_MUTE_OFF);
}
-
EXPORT_SYMBOL_GPL(ps3av_audio_mute);
static int __devinit ps3av_probe(struct ps3_system_bus_device *dev)
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/7] Add support hardreset
From: Sergei Shtylyov @ 2012-04-17 11:06 UTC (permalink / raw)
To: Thang Q. Nguyen
Cc: Phong Vo, devicetree-discuss, linuxppc-dev, Rob Herring,
linux-kernel, linux-ide, Paul Mackerras, Jeff Garzik
In-Reply-To: <1334652193-10487-1-git-send-email-tqnguyen@apm.com>
Hello.
On 17-04-2012 12:43, Thang Q. Nguyen wrote:
> The hardreset operation is currently not supported. This causes sometime the SATA driver does cause kernel crash because of none-determined state.a This patch will fix the issue.
> Signed-off-by: Thang Q. Nguyen<tqnguyen@apm.com>
> ---
> drivers/ata/sata_dwc_460ex.c | 24 +++++++++++++++++++++++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
> index 69f7cde..ae13ef1 100644
> --- a/drivers/ata/sata_dwc_460ex.c
> +++ b/drivers/ata/sata_dwc_460ex.c
> @@ -1581,10 +1581,31 @@ static void sata_dwc_qc_prep(struct ata_queued_cmd *qc)
>
> static void sata_dwc_error_handler(struct ata_port *ap)
> {
> - ap->link.flags |= ATA_LFLAG_NO_HRST;
> ata_sff_error_handler(ap);
> }
Could eliminate this, switching to the default implementation...
MBR, Sergei
^ permalink raw reply
* RE: [PATCH v4 1/4] powerpc/85xx: add HOTPLUG_CPU support
From: Li Yang-R58472 @ 2012-04-17 9:51 UTC (permalink / raw)
To: Wood Scott-B07421, Zhao Chenhui-B35336
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <4F8C78B3.1070002@freescale.com>
> > struct smp_ops_t smp_85xx_ops =3D {
> > .kick_cpu =3D smp_85xx_kick_cpu,
> > -#ifdef CONFIG_KEXEC
> > +#ifdef CONFIG_HOTPLUG_CPU
> > + .cpu_disable =3D generic_cpu_disable,
> > + .cpu_die =3D generic_cpu_die,
> > +#endif
> > .give_timebase =3D smp_generic_give_timebase,
> > .take_timebase =3D smp_generic_take_timebase,
> > -#endif
> > };
>=20
> We need to stop using smp_generic_give/take_timebase, not expand its use.
> This stuff breaks under hypervisors where timebase can't be written. It
> wasn't too bad before since we generally didn't enable CONFIG_KEXEC, but
> we're more likely to want CONFIG_HOTPLUG_CPU.
I understand that the guest OS shouldn't change the real timebase. But no =
matter what timebase syncing method we are using, the timebase need to be c=
hanged anyway for certain features. I think the better way should be trapp=
ing timebase modification in the hypervisor.
>=20
> Do the timebase sync the way U-Boot does -- if you find the appropriate
> guts node in the device tree.
That involves stopping timebase for a short time on all cores including the=
cores that are still online. Won't this be a potential issue?
- Leo=20
^ permalink raw reply
* [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
From: Chang-Ming.Huang @ 2012-04-17 9:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jerry Huang
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
The compatilbe 'simple-bus' is removed from the latest DTS for NAND and
NOR flash partition, so we must add the new compatilbe support for p1022ds,
otherwise, the kernel can't parse the partition of NOR and NAND flash.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
changes for v2:
correct the style
arch/powerpc/platforms/85xx/p1022_ds.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index e74b7cd..0db3a7e 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
static struct of_device_id __initdata p1022_ds_ids[] = {
/* So that the DMA channel nodes can be probed individually: */
{ .compatible = "fsl,eloplus-dma", },
+ { .compatible = "fsl,p1022-elbc", },
{},
};
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v3]KVM: PPC: Use clockevent multiplier and shifter for decrementer
From: Alexander Graf @ 2012-04-17 9:22 UTC (permalink / raw)
To: Bharat Bhushan; +Cc: Bharat Bhushan, linuxppc-dev, kvm, kvm-ppc, bharatb.yadav
In-Reply-To: <1334634909-9066-1-git-send-email-bharat.bhushan@freescale.com>
On 04/17/2012 05:55 AM, Bharat Bhushan wrote:
> Time for which the hrtimer is started for decrementer emulation is calculated using tb_ticks_per_usec. While hrtimer uses the clockevent for DEC reprogramming (if needed) and which calculate timebase ticks using the multiplier and shifter mechanism implemented within clockevent layer. It was observed that this conversion (timebase->time->timebase) are not correct because the mechanism are not consistent. In our setup it adds 2% jitter.
>
> With this patch clockevent multiplier and shifter mechanism are used when starting hrtimer for decrementer emulation. Now the jitter is< 0.5%.
>
> Signed-off-by: Bharat Bhushan<bharat.bhushan@freescale.com>
> ---
> v3:
> - decrementer_clockevent symbol exported.
>
> arch/powerpc/include/asm/time.h | 1 +
> arch/powerpc/kernel/time.c | 3 ++-
> arch/powerpc/kvm/emulate.c | 5 +++--
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
> index 7eb10fb..b3c7959 100644
> --- a/arch/powerpc/include/asm/time.h
> +++ b/arch/powerpc/include/asm/time.h
> @@ -28,6 +28,7 @@
> extern unsigned long tb_ticks_per_jiffy;
> extern unsigned long tb_ticks_per_usec;
> extern unsigned long tb_ticks_per_sec;
> +extern struct clock_event_device decrementer_clockevent;
>
> struct rtc_time;
> extern void to_tm(int tim, struct rtc_time * tm);
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 567dd7c..4f7a285 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -105,7 +105,7 @@ static int decrementer_set_next_event(unsigned long evt,
> static void decrementer_set_mode(enum clock_event_mode mode,
> struct clock_event_device *dev);
>
> -static struct clock_event_device decrementer_clockevent = {
> +struct clock_event_device decrementer_clockevent = {
> .name = "decrementer",
> .rating = 200,
> .irq = 0,
> @@ -113,6 +113,7 @@ static struct clock_event_device decrementer_clockevent = {
> .set_mode = decrementer_set_mode,
> .features = CLOCK_EVT_FEAT_ONESHOT,
> };
> +EXPORT_SYMBOL(decrementer_clockevent);
>
> DEFINE_PER_CPU(u64, decrementers_next_tb);
> static DEFINE_PER_CPU(struct clock_event_device, decrementers);
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index afc9154..c8b5206 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -23,6 +23,7 @@
> #include<linux/types.h>
> #include<linux/string.h>
> #include<linux/kvm_host.h>
> +#include<linux/clockchips.h>
>
> #include<asm/reg.h>
> #include<asm/time.h>
> @@ -104,8 +105,8 @@ void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
> */
>
> dec_time = vcpu->arch.dec;
> - dec_time *= 1000;
> - do_div(dec_time, tb_ticks_per_usec);
Sorry for the late nitpicking, but could you please add a comment here
that states that we can use the host's decrementer calculations because
the guest's timebase ticks at the same speed?
Alex
> + dec_time = dec_time<< decrementer_clockevent.shift;
> + do_div(dec_time, decrementer_clockevent.mult);
> dec_nsec = do_div(dec_time, NSEC_PER_SEC);
> hrtimer_start(&vcpu->arch.dec_timer,
> ktime_set(dec_time, dec_nsec), HRTIMER_MODE_REL);
^ permalink raw reply
* [PATCH 1/7] Add support hardreset
From: Thang Q. Nguyen @ 2012-04-17 8:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Jeff Garzik, Grant Likely,
Rob Herring
Cc: Phong Vo, devicetree-discuss, linux-kernel, linux-ide,
Thang Q. Nguyen, linuxppc-dev
The hardreset operation is currently not supported. This causes sometime the SATA driver does cause kernel crash because of none-determined state.a This patch will fix the issue.
Signed-off-by: Thang Q. Nguyen <tqnguyen@apm.com>
---
drivers/ata/sata_dwc_460ex.c | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index 69f7cde..ae13ef1 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -1581,10 +1581,31 @@ static void sata_dwc_qc_prep(struct ata_queued_cmd *qc)
static void sata_dwc_error_handler(struct ata_port *ap)
{
- ap->link.flags |= ATA_LFLAG_NO_HRST;
ata_sff_error_handler(ap);
}
+int sata_dwc_hardreset(struct ata_link *link, unsigned int *class,
+ unsigned long deadline)
+{
+ struct sata_dwc_device *hsdev = HSDEV_FROM_AP(link->ap);
+ int ret;
+
+ ret = sata_sff_hardreset(link, class, deadline);
+
+ sata_dwc_enable_interrupts(hsdev);
+
+ /* Reconfigure the DMA control register */
+ out_le32(&hsdev->sata_dwc_regs->dmacr,
+ SATA_DWC_DMACR_TXRXCH_CLEAR);
+
+ /* Reconfigure the DMA Burst Transaction Size register */
+ out_le32(&hsdev->sata_dwc_regs->dbtsr,
+ SATA_DWC_DBTSR_MWR(AHB_DMA_BRST_DFLT) |
+ SATA_DWC_DBTSR_MRD(AHB_DMA_BRST_DFLT));
+
+ return ret;
+}
+
/*
* scsi mid-layer and libata interface structures
*/
@@ -1604,6 +1625,7 @@ static struct ata_port_operations sata_dwc_ops = {
.inherits = &ata_sff_port_ops,
.error_handler = sata_dwc_error_handler,
+ .hardreset = sata_dwc_hardreset,
.qc_prep = sata_dwc_qc_prep,
.qc_issue = sata_dwc_qc_issue,
--
1.7.3.4
^ permalink raw reply related
* [PATCH] powerpc/eeh: crash caused by null eeh_dev
From: Gavin Shan @ 2012-04-17 5:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: anton, Gavin Shan
The problem was reported by Anton Blanchard. While EEH error
happened to the PCI device without the corresponding device
driver, kernel crash was seen. Eventually, I successfully
reproduced the problem on Firebird-L machine with utility
"errinjct". Initially, the device driver for Emulex ethernet
MAC has been disabled from .config and force data parity on
the Emulex ethernet MAC with help of "errinjct". Eventually,
I saw the kernel crash after issueing couple of "lspci -v"
command.
The root cause behind is that the PCI device, including the
reference to the corresponding eeh device, will be removed
from the system while EEH does recovery. Afterwards, the
PCI device will be probed again and added into the system
accordingly. So it's not safe to retrieve the eeh device from
the corresponding PCI device after the PCI device has been removed
and not added again.
The patch fixes the issue and retrieve the eeh device from OF node
instead of PCI device after the PCI device has been removed.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/eeh.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 309d38e..a75e37d 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -1076,7 +1076,7 @@ static void eeh_add_device_late(struct pci_dev *dev)
pr_debug("EEH: Adding device %s\n", pci_name(dev));
dn = pci_device_to_OF_node(dev);
- edev = pci_dev_to_eeh_dev(dev);
+ edev = of_node_to_eeh_dev(dn);
if (edev->pdev == dev) {
pr_debug("EEH: Already referenced !\n");
return;
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/2] powerpc/8xx: Fix NR_IRQ bugs and refactor 8xx interrupt controller
From: Joakim Tjernlund @ 2012-04-17 5:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1334624440.25353.18.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2012/04/17 03:00:40:
>
> On Tue, 2012-04-17 at 02:03 +0200, Joakim Tjernlund wrote:
> >
> > If you are going to test 8xx, could you revert
> > e0908085fc2391c85b85fb814ae1df377c8e0dcb,
> > powerpc/8xx: Fix regression introduced by cache coherency rewrite ?
> >
> > It should not be needed after I fixed up the 8xx TLB code and added a
> > workaround
> > for buggy dcbX instructions.
>
> Have you actually verified that things still work after reverting it ?
Nope, I haven't moved our 8xx to 3.x. We are still on
2.4 and it works there.
Jocke
^ permalink raw reply
* Re: [PATCH v5 00/21] EEH reorganization
From: Gavin Shan @ 2012-04-17 5:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1334627871.25353.26.camel@pasglop>
Ben, thanks a lot for the backtrace to help narrowing down the root
cause. Also thanks a lot for how to parse the backtrace and register
staff printed by oops ;-)
Finally, I successfully reproduced the issue on Firebird-L machine
without loading the corresponding device driver for Emulex ethernet
by disable the corresponding config options in .config. With injected
config space data parity error destined to the Emulex ethernet MAC,
I saw following backtrace. The problem came from following piece of
code. Actually, the EEH device should be retrieve from OF node instead
of PCI device since the PCI device didn't trace the corresponding
EEH device yet at that time. I'll send one patch against it soon even
it only need 1 line of code change ;-)
(gdb) p &(((struct eeh_dev *)0)->pdev)
$1 = (struct pci_dev **) 0x70
static void eeh_add_device_late(struct pci_dev *dev)
{
struct device_node *dn;
struct eeh_dev *edev;
if (!dev || !eeh_subsystem_enabled)
return;
dn = pci_device_to_OF_node(dev);
edev = pci_dev_to_eeh_dev(dev); <<< edev should be NULL
if (edev->pdev == dev) { <<< data access fault here.
pr_debug("EEH: Already referenced !\n");
return;
}
WARN_ON(edev->pdev);
:
:
}
[ 176.972046] Unable to handle kernel paging request for data at address 0x00000070
[ 176.972054] Faulting instruction address: 0xc000000000055ecc
[ 176.972064] Oops: Kernel access of bad area, sig: 11 [#1]
[ 176.972070] SMP NR_CPUS=1024 NUMA pSeries
[ 176.972078] Modules linked in:
[ 176.972086] NIP: c000000000055ecc LR: c000000000055ec8 CTR: c00000000005babc
[ 176.972102] REGS: c000000f4d913970 TRAP: 0300 Not tainted (3.4.0-rc2+)
[ 176.972109] MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28000084 XER: 00000009
[ 176.972129] SOFTE: 1
[ 176.972133] CFAR: c000000000005080
[ 176.972138] DAR: 0000000000000070, DSISR: 40000000
[ 176.972146] TASK = c000000f4d8c3600[1038] 'eehd' THREAD: c000000f4d910000 CPU: 24
[ 176.972155] GPR00: c000000000055ec8 c000000f4d913bf0 c00000000147ed90 000000000000001e
[ 176.972170] GPR04: 0000000000000000 ffffffffffffffff 0000000000000000 0000000000000000
[ 176.972183] GPR08: 000000004f4e450d c000000000c44208 0000000000036710 0000000000ec0000
[ 176.972197] GPR12: 0000000028000082 c00000000ff25400 0000000000000000 000000000106c9c8
[ 176.972212] GPR16: 0000000002280000 0000000002e5acf0 0000000001aff9a4 0000000000000060
[ 176.972227] GPR20: 0000000000000000 ffffffffffffffff ffffffffffffffff c000000001345c78
[ 176.972241] GPR24: c000000001345c70 0000000000000000 0000000000000000 c000000000851ac0
[ 176.972256] GPR28: c000000000a95ad3 c000000f529f2c28 c000000f529f2c00 c000000f4d880000
[ 176.972276] NIP [c000000000055ecc] .eeh_add_device_tree_late+0x17c/0x2c4
[ 176.972286] LR [c000000000055ec8] .eeh_add_device_tree_late+0x178/0x2c4
[ 176.972294] Call Trace:
[ 176.972300] [c000000f4d913bf0] [c000000000055ec8] .eeh_add_device_tree_late+0x178/0x2c4 (unreliable)
[ 176.972316] [c000000f4d913ca0] [c000000000036bc8] .pcibios_finish_adding_to_bus+0x74/0x90
[ 176.972328] [c000000f4d913d20] [c000000000059b50] .pcibios_add_pci_devices+0x12c/0x150
[ 176.972339] [c000000f4d913db0] [c000000000057c60] .eeh_reset_device+0x10c/0x140
[ 176.972350] [c000000f4d913e50] [c000000000057ee4] .handle_eeh_events+0x250/0x42c
[ 176.972361] [c000000f4d913f10] [c000000000058560] .eeh_event_handler+0xe4/0x178
[ 176.972372] [c000000f4d913f90] [c000000000021550] .kernel_thread+0x54/0x70
[ 176.972380] Instruction dump:
[ 176.972384] eb82a1f0 7f83e378 487dd2e9 60000000 e862a1f8 7f64db78 487dd2d9 60000000
[ 176.972400] eb5f02c0 7f83e378 487dd2c9 60000000 <e81a0070> 7fa0f800 40de0028 e862a188
Thanks,
Gavin
>
>More precisely, the original oops reported by Anton decodes as such:
>
>>Oops: Kernel access of bad area, sig: 11 [#1]
>
>This is typically a bad memory access..
>
>>SMP NR_CPUS=1024 NUMA pSeries
>>Modules linked in:
>>NIP: c000000000055af8 LR: c000000000033204 CTR: 0000000000000000
>>REGS: c000001f42fb7990 TRAP: 0300 Tainted: G W (3.4.0-rc2-00065-gf549e08-dirty)
>
>TRAP: 300 means that it's the result of a data access interrupts, ie,
>load or store to a bad address
>
>>MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24008084 XER: 00000000
>>SOFTE: 1
>>CFAR: 00000000000049b8
>>DAR: 0000000000000070, DSISR: 40000000
>
>Here the DAR tells us what address was accessed. 0x70 is a strong indication
>that this was an access to a NULL pointer (at offset 0x70 from that pointer).
>
>It -might- be something else (such as a NULL passed to a list head or such)
>but the idea that there's a NULL floating around is a good hint.
>
>>TASK = c000001f6c7dfc40[19010] 'eehd' THREAD: c000001f42fb4000 CPU: 6
>>GPR00: 0000000000000001 c000001f42fb7c10 c000000000bd3a28 c000001f80ab0800
>>GPR04: c000001f7c57d418 0000000000000380 c000001f7c57e070 c000000000ed5360
>>GPR08: 0000000000000000 c000000000c77088 0000000000000000 0000000000000001
>>GPR12: 0000000044008088 c00000000eda1500 00000000019ffa78 0000000000a70000
>>GPR16: 00000000000000bb c000000000a9f754 c000000000963230 000000000000005e
>>GPR20: 0000000001b37e80 00000000000000bb 0000000000000000 c000000000b0ad90
>>GPR24: 0000000000000000 c000000000b10588 0000000000000001 c000001f80ab0800
>>GPR28: 0000000000000000 c000001f80ab0828 0000000000000000 c000001f7ee10000
>>NIP [c000000000055af8] .eeh_add_device_tree_late+0x58/0xf0
>
>This is the function where it happened (eeh_add_device_tree_late)
>
>>LR [c000000000033204] .pcibios_finish_adding_to_bus+0x34/0x50
>>Call Trace:
>>[c000001f42fb7c10] [00000000fdffffff] 0xfdffffff (unreliable)
>>[c000001f42fb7ca0] [c000000000033204] .pcibios_finish_adding_to_bus+0x34/0x50
>>[c000001f42fb7d20] [c000000000059a5c] .pcibios_add_pci_devices+0x7c/0x190
>>[c000001f42fb7db0] [c000000000057a6c] .eeh_reset_device+0xfc/0x1a0
>>[c000001f42fb7e50] [c000000000057e18] .handle_eeh_events+0x308/0x480
>>[c000001f42fb7f00] [c0000000000584dc] .eeh_event_handler+0x13c/0x1d0
>>[c000001f42fb7f90] [c00000000002099c] .kernel_thread+0x54/0x70
>
>And your backtrace. You can see that you got an eeh event, which triggered an
>eeh reset, which triggered a pcibios_add_pci_devices() etc...
>
>>Instruction dump:
>>480000a8 60000000 ebff0000 7fbfe800 419e0098 2fbf0000 419e005c e9229eb0
>>80090008 2f800000 419e004c ebdf01d0 <e81e0070> 7fbf0000 3160ffff
>>7d2b0110
>
>Cheers,
>Ben.
>
>
^ permalink raw reply
* [PATCH v3]KVM: PPC: Use clockevent multiplier and shifter for decrementer
From: Bharat Bhushan @ 2012-04-17 3:55 UTC (permalink / raw)
To: linuxppc-dev, kvm-ppc, kvm, bharatb.yadav; +Cc: Bharat Bhushan
Time for which the hrtimer is started for decrementer emulation is calculated using tb_ticks_per_usec. While hrtimer uses the clockevent for DEC reprogramming (if needed) and which calculate timebase ticks using the multiplier and shifter mechanism implemented within clockevent layer. It was observed that this conversion (timebase->time->timebase) are not correct because the mechanism are not consistent. In our setup it adds 2% jitter.
With this patch clockevent multiplier and shifter mechanism are used when starting hrtimer for decrementer emulation. Now the jitter is < 0.5%.
Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
---
v3:
- decrementer_clockevent symbol exported.
arch/powerpc/include/asm/time.h | 1 +
arch/powerpc/kernel/time.c | 3 ++-
arch/powerpc/kvm/emulate.c | 5 +++--
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index 7eb10fb..b3c7959 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -28,6 +28,7 @@
extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
+extern struct clock_event_device decrementer_clockevent;
struct rtc_time;
extern void to_tm(int tim, struct rtc_time * tm);
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 567dd7c..4f7a285 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -105,7 +105,7 @@ static int decrementer_set_next_event(unsigned long evt,
static void decrementer_set_mode(enum clock_event_mode mode,
struct clock_event_device *dev);
-static struct clock_event_device decrementer_clockevent = {
+struct clock_event_device decrementer_clockevent = {
.name = "decrementer",
.rating = 200,
.irq = 0,
@@ -113,6 +113,7 @@ static struct clock_event_device decrementer_clockevent = {
.set_mode = decrementer_set_mode,
.features = CLOCK_EVT_FEAT_ONESHOT,
};
+EXPORT_SYMBOL(decrementer_clockevent);
DEFINE_PER_CPU(u64, decrementers_next_tb);
static DEFINE_PER_CPU(struct clock_event_device, decrementers);
diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
index afc9154..c8b5206 100644
--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -23,6 +23,7 @@
#include <linux/types.h>
#include <linux/string.h>
#include <linux/kvm_host.h>
+#include <linux/clockchips.h>
#include <asm/reg.h>
#include <asm/time.h>
@@ -104,8 +105,8 @@ void kvmppc_emulate_dec(struct kvm_vcpu *vcpu)
*/
dec_time = vcpu->arch.dec;
- dec_time *= 1000;
- do_div(dec_time, tb_ticks_per_usec);
+ dec_time = dec_time << decrementer_clockevent.shift;
+ do_div(dec_time, decrementer_clockevent.mult);
dec_nsec = do_div(dec_time, NSEC_PER_SEC);
hrtimer_start(&vcpu->arch.dec_timer,
ktime_set(dec_time, dec_nsec), HRTIMER_MODE_REL);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v5 00/21] EEH reorganization
From: Benjamin Herrenschmidt @ 2012-04-17 1:57 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <20120417113738.0f091da4@kryten>
On Tue, 2012-04-17 at 11:37 +1000, Anton Blanchard wrote:
>
> No. I replaced that backtrace in eeh_dn_check_failure with a WARN_ON()
> because the backtrace doesn't give us enough info. I'm submitting a
> patch for that today.
>
> Bottom line is mstmread has been causing an EEH error since at least
> 3.0, but in 3.4 we now oops instead of recovering. The signs all point
> to the EEH rework in 3.4.
More precisely, the original oops reported by Anton decodes as such:
>Oops: Kernel access of bad area, sig: 11 [#1]
This is typically a bad memory access..
>SMP NR_CPUS=1024 NUMA pSeries
>Modules linked in:
>NIP: c000000000055af8 LR: c000000000033204 CTR: 0000000000000000
>REGS: c000001f42fb7990 TRAP: 0300 Tainted: G W (3.4.0-rc2-00065-gf549e08-dirty)
TRAP: 300 means that it's the result of a data access interrupts, ie,
load or store to a bad address
>MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24008084 XER: 00000000
>SOFTE: 1
>CFAR: 00000000000049b8
>DAR: 0000000000000070, DSISR: 40000000
Here the DAR tells us what address was accessed. 0x70 is a strong indication
that this was an access to a NULL pointer (at offset 0x70 from that pointer).
It -might- be something else (such as a NULL passed to a list head or such)
but the idea that there's a NULL floating around is a good hint.
>TASK = c000001f6c7dfc40[19010] 'eehd' THREAD: c000001f42fb4000 CPU: 6
>GPR00: 0000000000000001 c000001f42fb7c10 c000000000bd3a28 c000001f80ab0800
>GPR04: c000001f7c57d418 0000000000000380 c000001f7c57e070 c000000000ed5360
>GPR08: 0000000000000000 c000000000c77088 0000000000000000 0000000000000001
>GPR12: 0000000044008088 c00000000eda1500 00000000019ffa78 0000000000a70000
>GPR16: 00000000000000bb c000000000a9f754 c000000000963230 000000000000005e
>GPR20: 0000000001b37e80 00000000000000bb 0000000000000000 c000000000b0ad90
>GPR24: 0000000000000000 c000000000b10588 0000000000000001 c000001f80ab0800
>GPR28: 0000000000000000 c000001f80ab0828 0000000000000000 c000001f7ee10000
>NIP [c000000000055af8] .eeh_add_device_tree_late+0x58/0xf0
This is the function where it happened (eeh_add_device_tree_late)
>LR [c000000000033204] .pcibios_finish_adding_to_bus+0x34/0x50
>Call Trace:
>[c000001f42fb7c10] [00000000fdffffff] 0xfdffffff (unreliable)
>[c000001f42fb7ca0] [c000000000033204] .pcibios_finish_adding_to_bus+0x34/0x50
>[c000001f42fb7d20] [c000000000059a5c] .pcibios_add_pci_devices+0x7c/0x190
>[c000001f42fb7db0] [c000000000057a6c] .eeh_reset_device+0xfc/0x1a0
>[c000001f42fb7e50] [c000000000057e18] .handle_eeh_events+0x308/0x480
>[c000001f42fb7f00] [c0000000000584dc] .eeh_event_handler+0x13c/0x1d0
>[c000001f42fb7f90] [c00000000002099c] .kernel_thread+0x54/0x70
And your backtrace. You can see that you got an eeh event, which triggered an
eeh reset, which triggered a pcibios_add_pci_devices() etc...
>Instruction dump:
>480000a8 60000000 ebff0000 7fbfe800 419e0098 2fbf0000 419e005c e9229eb0
>80090008 2f800000 419e004c ebdf01d0 <e81e0070> 7fbf0000 3160ffff
>7d2b0110
Cheers,
Ben.
^ permalink raw reply
* [PATCH 2/2] powerpc/p1022ds/DTS: Add RTC support
From: Chang-Ming.Huang @ 2012-04-17 1:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jerry Huang
In-Reply-To: <1334626955-8069-1-git-send-email-Chang-Ming.Huang@freescale.com>
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
Add the RTC support for p1022ds
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
arch/powerpc/boot/dts/p1022ds.dtsi | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1022ds.dtsi b/arch/powerpc/boot/dts/p1022ds.dtsi
index 2b0d9e9..904b653 100644
--- a/arch/powerpc/boot/dts/p1022ds.dtsi
+++ b/arch/powerpc/boot/dts/p1022ds.dtsi
@@ -42,6 +42,10 @@
* the clock is enabled.
*/
};
+ rtc@68 {
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ };
};
spi@7000 {
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/mpc85xx: p1022ds support the MTD for NOR and NAND flash
From: Chang-Ming.Huang @ 2012-04-17 1:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jerry Huang
From: Jerry Huang <Chang-Ming.Huang@freescale.com>
The compatilbe 'simple-bus' is removed from the latest DTS for NAND and
NOR flash partition, so we must add the new compatilbe support for p1022ds,
otherwise, the kernel can't parse the partition of NOR and NAND flash.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
arch/powerpc/platforms/85xx/p1022_ds.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c
index 6c8ff8b..8948293 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -379,6 +379,7 @@ static struct of_device_id __initdata p1022_ds_ids[] = {
{ .compatible = "gianfar", },
/* So that the DMA channel nodes can be probed individually: */
{ .compatible = "fsl,eloplus-dma", },
+ { .compatible = "fsl,p1022-elbc", },
{},
};
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox