* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Darren Hart @ 2010-09-01 15:10 UTC (permalink / raw)
To: michael
Cc: Stephen Rothwell, Gautham R Shenoy, Josh Triplett, Steven Rostedt,
linuxppc-dev, Will Schmidt, Paul Mackerras, Ankita Garg,
Thomas Gleixner
In-Reply-To: <1283320481.32679.32.camel@concordia>
On 08/31/2010 10:54 PM, Michael Ellerman wrote:
> On Tue, 2010-08-31 at 00:12 -0700, Darren Hart wrote:
> ..
>>
>> When running with the function plugin I had to stop the trace
>> immediately before entering start_secondary after an online or my traces
>> would not include the pseries_mach_cpu_die function, nor the tracing I
>> added there (possibly buffer size, I am using 2048). The following trace
>> was collected using "trace-cmd record -p function -e irq -e sched" and
>> has been filtered to only show CPU [001] (the CPU undergoing the
>> offline/online test, and the one seeing preempt_count (pcnt) go to
>> ffffffff after cede. The function tracer does not indicate anything
>> running on the CPU other than the HCALL - unless the __trace_hcall*
>> commands might be to blame.
>
> It's not impossible. Though normally they're disabled right, so the only
> reason they're running is because you're tracing. So if they are causing
> the bug then that doesn't explain why you see it normally.
>
> Still, might be worth disabling just the hcall tracepoints just to be
> 100% sure.
A couple of updates. I was working from tip/rt/head, which has been
stale for some months now. I switched to tip/rt/2.6.33 and the
preempt_count() change over cede went away. I now see the live hang that
Will has reported.
Before I dive into the live hang, I want to understand what fixed the
preempt_count() change. That might start pointing us in the right
direction for the live hang.
I did an inverted git bisect between tip/rt/head and tip/rt/2.6.33 to
try and locate the fix. I've narrowed it down to the 2.6.33.6 merge:
# git show 7e1af1172bbd4109d09ac515c5d376f633da7cff
commit 7e1af1172bbd4109d09ac515c5d376f633da7cff
Merge: d8e94db 9666790
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Jul 13 16:01:16 2010 +0200
Merge
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.33.y
Conflicts:
Makefile
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Visual inspection yields two patches of interest:
f8b67691828321f5c85bb853283aa101ae673130
powerpc/pseries: Make query-cpu-stopped callable outside hotplug cpu
aef40e87d866355ffd279ab21021de733242d0d5
powerpc/pseries: Only call start-cpu when a CPU is stopped
I'm going to try reverting these today and see if they addressed the
issue indirectly.
--
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team
^ permalink raw reply
* PCI: device not available (can't reserve [mem 0x00000000-0x0003ffff])
From: Ravi Gupta @ 2010-09-01 15:07 UTC (permalink / raw)
To: linuxppc-dev, MJ embd, Ira W. Snyder, Anton Vorontsov
[-- Attachment #1: Type: text/plain, Size: 1159 bytes --]
Hi,
I am facing a strange problem with a PCI express device. I have written a
simple PCI driver(pci_skel sample driver for LDD book) just to detect a PCI
device and read its vender and device id from its configuration space. When
I connect the device on a standard i386 based PC, it works fine, as
expected. But when I run the same driver on the MPC837xERDB board(powerpc
arch based processor from freescale), it gives me error. Below is the O/P on
both the architectures. Could anyone suggest what can be the cause of this
problem? I am new to linux device driver development.
i386 output.
[ 921.097050] PCI driver: Init function
[ 921.097415] PCI driver: Probe function
[ 921.097442] pci_skel 0000:04:00.0: PCI INT A -> GSI 18 (level, low) ->
IRQ 18
[ 921.097453] PCI driver Vendor ID = 1204
[ 921.097462] PCI driver Device ID = e250
[ 921.097471] PCI driver Revision = 0
Powerpc output
PCI driver: Init function
PCI driver: Probe function
pci_skel 0001:02:00.0: device not available (can't reserve [mem
0x00000000-0x0003ffff])
Unable to Enable PCI device:-22
pci_skel: probe of 0001:02:00.0 failed with error -22
Thanks in advance
Ravi Gupta
[-- Attachment #2: Type: text/html, Size: 1276 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] drivers/macintosh/via-pmu-led.c: Add of_node_put to avoid memory leak
From: walter harms @ 2010-09-01 15:03 UTC (permalink / raw)
To: Grant Likely
Cc: Vasiliy Kulikov, devicetree-discuss, kernel-janitors,
linux-kernel, Julia Lawall, linuxppc-dev
In-Reply-To: <AANLkTi=3b0NY5pFepv-TmjFDmPUBK9Ew16HyTn-+YguX@mail.gmail.com>
Grant Likely schrieb:
> On Tue, Aug 31, 2010 at 10:16 AM, Vasiliy Kulikov <segooon@gmail.com> wrote:
>> On Tue, Aug 31, 2010 at 18:08 +0200, Julia Lawall wrote:
>>> On Tue, 31 Aug 2010, walter harms wrote:
>>>>> if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
>>>>> strncmp(model, "iBook", strlen("iBook")) != 0 &&
>>>>> strcmp(model, "PowerMac7,2") != 0 &&
>>>>>
>>>> is there any rule that says when to use strncmp ? it seems perfecly valid to use strcpy here
>>>> (what is done in the last cmp).
>>> Perhaps there are some characters after eg PowerBook that one doesn't want
>>> to compare with?
>> It seems to me that model has no '\0' in the end. If model is got from
>> the hardware then we should double check it - maybe harware is buggy.
>> Otherwise we'll overflow model.
>
> Model does have \0 at the end. This code is using strncmp to
> purposefully ignore the model suffix.
>
>> But why strcmp(model, "PowerMac7,2")? IMO it should be replaced
>> with strncmp().
>
> We use strcmp when parsing the device tree because the the length of
> the model property string is unknown and in most cases we *must* match
> the exact entire string, such as with this PowerMac7,2 example. Using
> strncmp would also happen to match with something like
> "PowerMac7,2345" which is not the desired behaviour.
>
hi Grant,
whould you mind to use you explanation as comment in the code ?
Tthat the strncpy/strcpy difference is important should be noted. that would be clearly a
bonos with further audits.
re,
wh
^ permalink raw reply
* ERR_PTR pattern in phylib
From: Grant Likely @ 2010-09-01 14:42 UTC (permalink / raw)
To: Andy Fleming, netdev, linuxppc-dev
Hi Andy,
I've been looking at the phylib code, and specifically at the use of
the ERR_PTR() pattern. I'm personally not a big fan of ERR_PTR()
because the compiler cannot type check the result and it runs
completely counter to the pattern "if (!ptr)" than is common for
testing a pointer return value.
(That being said, I do understand the need for it in certain parts of
the kernel (like the filesystem code) where it is important to be both
efficient because it is a hot path and still able to accurately return
an error code that is used by userspace.)
It seems to me that phylib is one of the cases where the users (the
network drivers) don't actually care about the specific error code
when calling phylib functions. The drivers only seem to care whether
or not the function failed, and if it did then bail out. I've also
noticed that using the "if (!ptr)" test on phylib return values is a
common error for driver writers.
In the interest of making driver code easier to write and review,
would you be opposed to a set of patches to remove the ERR_PTR()
pattern from phylib and its users?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [v1 PATCH] ucc_geth: fix ethtool set ring param bug
From: Ben Hutchings @ 2010-09-01 13:42 UTC (permalink / raw)
To: Liang Li; +Cc: netdev, avorontsov, davem, linuxppc-dev
In-Reply-To: <1283305429-8426-1-git-send-email-liang.li@windriver.com>
On Wed, 2010-09-01 at 09:43 +0800, Liang Li wrote:
> It's common sense that when we should do change to driver ring
> desc/buffer etc only after 'stop/shutdown' the device. When we
> do change while devices/driver is running, kernel oops occur:
[...]
> - ug_info->bdRingLenRx[queue] = ring->rx_pending;
> - ug_info->bdRingLenTx[queue] = ring->tx_pending;
> -
> if (netif_running(netdev)) {
> - /* FIXME: restart automatically */
> - printk(KERN_INFO
> - "Please re-open the interface.\n");
> + u16 rx_t;
> + u16 tx_t;
> + printk(KERN_INFO "Stopping interface %s.\n", netdev->name);
> + ucc_geth_close(netdev);
> +
> + rx_t = ug_info->bdRingLenRx[queue];
> + tx_t = ug_info->bdRingLenTx[queue];
> +
> + ug_info->bdRingLenRx[queue] = ring->rx_pending;
> + ug_info->bdRingLenTx[queue] = ring->tx_pending;
> +
> + printk(KERN_INFO "Reactivating interface %s.\n", netdev->name);
> + ret = ucc_geth_open(netdev);
> + if (ret) {
> + printk(KERN_WARNING "uec_set_ringparam: set ring param for running"
> + " interface %s failed. Please try to make the interface "
> + " down, then try again.\n", netdev->name);
> + ug_info->bdRingLenRx[queue] = rx_t;
> + ug_info->bdRingLenTx[queue] = tx_t;
> + }
[...]
Bringing the interface down will call ucc_geth_close(), which will try
to free resources that have not been allocated!
If you cannot roll back a failed change then at least use dev_close()
and dev_open() rather than calling ucc_geth_{close,open}() directly, so
that the interface state is updated correctly. Or just refuse to make
the change if the interface is up.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [linuxppc-release] [PATCH 1/2] powerpc/mm: Assume first cpu is boot_cpuid not 0
From: Kumar Gala @ 2010-09-01 13:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: Matthew McClintock, linuxppc-dev
In-Reply-To: <4C7E4FA4.60909@freescale.com>
On Sep 1, 2010, at 8:05 AM, Timur Tabi wrote:
> Matthew McClintock wrote:
>> +#ifndef CONFIG_SMP
>> stale_map[0] =3D alloc_bootmem(CTX_MAP_SIZE);
>> +#else
>> + stale_map[boot_cpuid] =3D alloc_bootmem(CTX_MAP_SIZE);
>=20
> So you're saying that even on a non-SMP kernel, boot_cpuid might not =
be zero?
That is correct, we have that situation on AMP kernel boots on 8572, =
p2020, etc.
- k=
^ permalink raw reply
* Re: [linuxppc-release] [PATCH 1/2] powerpc/mm: Assume first cpu is boot_cpuid not 0
From: Timur Tabi @ 2010-09-01 13:05 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1283297085-3455-1-git-send-email-msm@freescale.com>
Matthew McClintock wrote:
> +#ifndef CONFIG_SMP
> stale_map[0] = alloc_bootmem(CTX_MAP_SIZE);
> +#else
> + stale_map[boot_cpuid] = alloc_bootmem(CTX_MAP_SIZE);
So you're saying that even on a non-SMP kernel, boot_cpuid might not be zero?
^ permalink raw reply
* Re: [PATCH] powerpc: mtmsrd not defined
From: Kumar Gala @ 2010-09-01 13:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <20100901080214.GA4722@brick.ozlabs.ibm.com>
On Sep 1, 2010, at 3:02 AM, Paul Mackerras wrote:
> On Tue, Aug 31, 2010 at 10:55:25PM -0400, Sean MacLennan wrote:
>=20
>> I had to give up. Without the CONFIG_PPC_FPU it compiles fine for an
>> FPU less 44x. But with the CONFIG_PPC_FPU, I get the following =
errors:
>=20
> Ah, those references would be from arch/powerpc/lib/sstep.c. =
Evidently
> we need #ifdef CONFIG_PPC_FPU around the emulation of the =
floating-point
> loads and stores.
>=20
> Do we do any in-kernel emulation of floating-point operations with
> CONFIG_PPC_FPU turned off?
I'm not aware of any. I haven't looked at the Program Check exception =
path to know if we'd handle emulation gracefully or not for =
!CONFIG_PPC_FPU.
- k=
^ permalink raw reply
* P1021MDS QE Ethernet Ports
From: Ioannis Kokkoris @ 2010-09-01 12:11 UTC (permalink / raw)
To: linuxppc-dev
Hello=2C
we are seeing a strange behavior when trying to use the QE Ethernet interfa=
ces.
ENET5 (UCC5 - RMII) interface on P1021MDS boards does not come up if there =
is no physical link on the ENET1 (UCC1 - MII) Port.
It seems that interrupts from ENET5 are normally received but the link come=
s up and works properly only if we have physical connection on ENET1.=20
Can anyone think of a possible reason for this behavior=2C is there a way t=
o trace this problem?
I can provide any further information needed.
Any help would be appreciated=2C
Regards=2C
John
=
^ permalink raw reply
* Re: [PATCH] powerpc: mtmsrd not defined
From: Paul Mackerras @ 2010-09-01 8:02 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20100831225525.1c9bd5a8@lappy.seanm.ca>
On Tue, Aug 31, 2010 at 10:55:25PM -0400, Sean MacLennan wrote:
> I had to give up. Without the CONFIG_PPC_FPU it compiles fine for an
> FPU less 44x. But with the CONFIG_PPC_FPU, I get the following errors:
Ah, those references would be from arch/powerpc/lib/sstep.c. Evidently
we need #ifdef CONFIG_PPC_FPU around the emulation of the floating-point
loads and stores.
Do we do any in-kernel emulation of floating-point operations with
CONFIG_PPC_FPU turned off?
Paul.
^ permalink raw reply
* RE: [PATCH v2 1/4] fsl_rio: fix compile errors
From: Li Yang-R58472 @ 2010-09-01 7:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <F508DEEC-D2A3-406E-AC8C-45DCC466C769@kernel.crashing.org>
>Subject: Re: [PATCH v2 1/4] fsl_rio: fix compile errors
>
>
>On Aug 31, 2010, at 10:40 PM, Li Yang wrote:
>
>> On Wed, Sep 1, 2010 at 5:39 AM, Kumar Gala =
<galak@kernel.crashing.org>
>wrote:
>>>
>>> On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
>>>
>>>> Fixes the following compile problem on E500 platforms:
>>>> arch/powerpc/sysdev/fsl_rio.c: In function =
'fsl_rio_mcheck_exception':
>>>> arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared
>(first use in this function)
>>>>
>>>> Also fixes the compile problem on non-E500 platforms.
>>>>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>> ---
>>>> arch/powerpc/sysdev/fsl_rio.c | 6 +++++-
>>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>>
>>> applied to merge
>>
>> Thanks, Kumar.
>>
>> How about the other ones in the series?
>
>I want to rework how the whole RIO mcheck works and will do so for =
2.6.37.
>Part of the problem I have is that we are ignoring the fact that this =
code
>isn't right for 8641 support of SRIO.
Right. So I protected the code with #ifdef CONFIG_E500. The following =
patches in series enable it to be used by e500mc. Having it to support =
all platforms is surely the best, but before that we can make it better. =
And I believe they wouldn't get in the way of further MPC8641 support.
- Leo
^ permalink raw reply
* Re: [PULL 00/35] KVM: PPC: End-August patch queue
From: Avi Kivity @ 2010-09-01 7:50 UTC (permalink / raw)
To: Alexander Graf; +Cc: Linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1283221937-21006-1-git-send-email-agraf@suse.de>
On 08/31/2010 05:31 AM, Alexander Graf wrote:
> Howdy,
>
> This is my local patch queue with stuff that has accumulated over the last
> weeks on KVM for PPC with some last minute fixes, speedups and debugging help
> that I needed for the KVM Forum ;-).
>
> The highlights of this set are:
>
> - Converted most important debug points to tracepoints
> - Flush less PTEs (speedup)
> - Go back to our own hash (less duplicates)
> - Make SRs guest settable (speedup for 32 bit guests)
> - Remove r30/r31 restrictions from PV hooks (speedup!)
> - Fix random breakages
> - Fix random guest stalls
> - 440GP host support (Thanks Hollis!)
> - Reliable interrupt injection
>
> Keep in mind that this is the first version that is stable on PPC32 hosts.
> All versions prior to this could occupy otherwise used segment entries and
> thus crash your machine :-).
>
> It is also the first version that is stable with PPC64 guests, because they
> require more sophisticated interrupt injection logic for which qemu patches
> are also required.
>
> Please pull this tree from:
>
> git://github.com/agraf/linux-2.6.git kvm-ppc-next
>
> Have fun with more accurate, faster and less buggy KVM on PowerPC!
Pulled, thanks.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH] powerpc: mtmsrd not defined
From: Sean MacLennan @ 2010-09-01 6:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <9B0CD60E-F3E4-47FD-AE4D-3065E742E3A2@kernel.crashing.org>
On Wed, 1 Sep 2010 01:45:46 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> For what defconfig setup do you get the errors above?
44x/ebony_defconfig
Then enable KPROBES (or XMON).
Then put an #ifdef CONFIG_PPC_FPU in ldstfp.S.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] powerpc: mtmsrd not defined
From: Kumar Gala @ 2010-09-01 6:45 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20100831225525.1c9bd5a8@lappy.seanm.ca>
On Aug 31, 2010, at 9:55 PM, Sean MacLennan wrote:
> On Tue, 31 Aug 2010 13:46:05 -0400
> Sean MacLennan <smaclennan@pikatech.com> wrote:
>=20
>> On Tue, 31 Aug 2010 11:17:17 -0500
>> Kumar Gala <galak@kernel.crashing.org> wrote:
>>=20
>>> Can we add proper CONFIG_PPC_FPU into this file. =20
>>=20
>> If nobody beats me to it.... I can try this evening.
>=20
> I had to give up. Without the CONFIG_PPC_FPU it compiles fine for an
> FPU less 44x. But with the CONFIG_PPC_FPU, I get the following errors:
>=20
> arch/powerpc/lib/built-in.o: In function `__copy_tofrom_user':
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0xf8e): undefined reference =
to `do_lfs'
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0xf96): undefined reference =
to `do_lfs'
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0xfc2): undefined reference =
to `do_lfd'
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0xfca): undefined reference =
to `do_lfd'
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0xff6): undefined reference =
to `do_stfs'
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0xffe): undefined reference =
to `do_stfs'
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0x102a): undefined reference =
to `do_stfd'
> arch/powerpc/lib/copy_32.S:(.kprobes.text+0x1032): undefined reference =
to `do_stfd'
> make: *** [.tmp_vmlinux1] Error 1
>=20
>=20
> Oops, sorry, it will say arch/powerpc/lib/copy32.S... I corrected =
that.
> But I cannot find how copy_32.S is including those functions.
>=20
> Cheers,
> Sean
For what defconfig setup do you get the errors above?
- k=
^ permalink raw reply
* Re: [PATCH v2 1/4] fsl_rio: fix compile errors
From: Kumar Gala @ 2010-09-01 6:44 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikcfOQOEK=-oV2DBN7et9jkHM5s-v08EWHBjKno@mail.gmail.com>
On Aug 31, 2010, at 10:40 PM, Li Yang wrote:
> On Wed, Sep 1, 2010 at 5:39 AM, Kumar Gala <galak@kernel.crashing.org> =
wrote:
>>=20
>> On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
>>=20
>>> Fixes the following compile problem on E500 platforms:
>>> arch/powerpc/sysdev/fsl_rio.c: In function =
'fsl_rio_mcheck_exception':
>>> arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared =
(first use in this function)
>>>=20
>>> Also fixes the compile problem on non-E500 platforms.
>>>=20
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> arch/powerpc/sysdev/fsl_rio.c | 6 +++++-
>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>=20
>> applied to merge
>=20
> Thanks, Kumar.
>=20
> How about the other ones in the series?
I want to rework how the whole RIO mcheck works and will do so for =
2.6.37. Part of the problem I have is that we are ignoring the fact =
that this code isn't right for 8641 support of SRIO.
- k
^ permalink raw reply
* Re: [PATCH][RFC] preempt_count corruption across H_CEDE call with CONFIG_PREEMPT on pseries
From: Michael Ellerman @ 2010-09-01 5:54 UTC (permalink / raw)
To: Darren Hart
Cc: Stephen Rothwell, Gautham R Shenoy, Josh Triplett, Steven Rostedt,
linuxppc-dev, Will Schmidt, Paul Mackerras, Ankita Garg,
Thomas Gleixner
In-Reply-To: <4C7CAB72.2050305@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
On Tue, 2010-08-31 at 00:12 -0700, Darren Hart wrote:
..
>
> When running with the function plugin I had to stop the trace
> immediately before entering start_secondary after an online or my traces
> would not include the pseries_mach_cpu_die function, nor the tracing I
> added there (possibly buffer size, I am using 2048). The following trace
> was collected using "trace-cmd record -p function -e irq -e sched" and
> has been filtered to only show CPU [001] (the CPU undergoing the
> offline/online test, and the one seeing preempt_count (pcnt) go to
> ffffffff after cede. The function tracer does not indicate anything
> running on the CPU other than the HCALL - unless the __trace_hcall*
> commands might be to blame.
It's not impossible. Though normally they're disabled right, so the only
reason they're running is because you're tracing. So if they are causing
the bug then that doesn't explain why you see it normally.
Still, might be worth disabling just the hcall tracepoints just to be
100% sure.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] fsl_rio: fix compile errors
From: Li Yang @ 2010-09-01 3:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <C038AA46-E821-49EF-8958-747953FF56A0@kernel.crashing.org>
On Wed, Sep 1, 2010 at 5:39 AM, Kumar Gala <galak@kernel.crashing.org> wrot=
e:
>
> On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
>
>> Fixes the following compile problem on E500 platforms:
>> arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
>> arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared (first =
use in this function)
>>
>> Also fixes the compile problem on non-E500 platforms.
>>
>> Signed-off-by: Li Yang <leoli@freescale.com>
>> ---
>> arch/powerpc/sysdev/fsl_rio.c | =C2=A0 =C2=A06 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> applied to merge
Thanks, Kumar.
How about the other ones in the series?
- Leo
^ permalink raw reply
* Re: [PATCH] powerpc: mtmsrd not defined
From: Sean MacLennan @ 2010-09-01 2:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20100831134605.1fca5fdf@lappy.seanm.ca>
On Tue, 31 Aug 2010 13:46:05 -0400
Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Tue, 31 Aug 2010 11:17:17 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
> > Can we add proper CONFIG_PPC_FPU into this file.
>
> If nobody beats me to it.... I can try this evening.
I had to give up. Without the CONFIG_PPC_FPU it compiles fine for an
FPU less 44x. But with the CONFIG_PPC_FPU, I get the following errors:
arch/powerpc/lib/built-in.o: In function `__copy_tofrom_user':
arch/powerpc/lib/copy_32.S:(.kprobes.text+0xf8e): undefined reference to `do_lfs'
arch/powerpc/lib/copy_32.S:(.kprobes.text+0xf96): undefined reference to `do_lfs'
arch/powerpc/lib/copy_32.S:(.kprobes.text+0xfc2): undefined reference to `do_lfd'
arch/powerpc/lib/copy_32.S:(.kprobes.text+0xfca): undefined reference to `do_lfd'
arch/powerpc/lib/copy_32.S:(.kprobes.text+0xff6): undefined reference to `do_stfs'
arch/powerpc/lib/copy_32.S:(.kprobes.text+0xffe): undefined reference to `do_stfs'
arch/powerpc/lib/copy_32.S:(.kprobes.text+0x102a): undefined reference to `do_stfd'
arch/powerpc/lib/copy_32.S:(.kprobes.text+0x1032): undefined reference to `do_stfd'
make: *** [.tmp_vmlinux1] Error 1
Oops, sorry, it will say arch/powerpc/lib/copy32.S... I corrected that.
But I cannot find how copy_32.S is including those functions.
Cheers,
Sean
^ permalink raw reply
* [v1 PATCH] ucc_geth: fix ethtool set ring param bug
From: Liang Li @ 2010-09-01 1:43 UTC (permalink / raw)
To: leoli, davem, avorontsov, netdev, linuxppc-dev
In-Reply-To: <1283179677-21262-1-git-send-email-liang.li@windriver.com>
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[
root@fsl_8569mds:/root> ethtool -G eth0 tx 256
root@fsl_8569mds:/root> Oops: Kernel access of bad area, sig: 11 [#1]
MPC8569 MDS
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in:
NIP: 00000000 LR: c0072fbc CTR: 00000000
REGS: effefef0 TRAP: 0400 Not tainted (2.6.36-rc3-00002-g6c3b118-dirty)
MSR: 00021000 <ME,CE> CR: 24442048 XER: 00000000
TASK = c0518350[0] 'swapper' THREAD: c0544000
GPR00: 00000000 effeffa0 c0518350 00000020 ef0be000 ef005000 80000000 00000200
GPR08: c03b5d00 00000000 f1010080 ef08d458 000dda96 00000000 3ffb2900 00000000
GPR16: 00000000 3ffa8948 3fff1314 3ffac3f8 00000000 00000000 00000000 00000000
GPR24: 00000000 00000000 00000000 c0530000 00000000 00000000 00000020 ef3709c0
NIP [00000000] (null)
LR [c0072fbc] handle_IRQ_event+0x4c/0x12c
Call Trace:
[effeffa0] [c0019414] qe_ic_mask_irq+0x1c/0x90 (unreliable)
[effeffc0] [c0075b74] handle_level_irq+0x88/0x128
[effeffd0] [c001ca44] qe_ic_cascade_muxed_mpic+0x50/0x88
[effefff0] [c000d5fc] call_handle_irq+0x18/0x28
[c0545ea0] [c0004f3c] do_IRQ+0xa8/0x140
[c0545ed0] [c000e2bc] ret_from_except+0x0/0x18
-- Exception: 501 at cpu_idle+0x9c/0xdc
LR = cpu_idle+0x9c/0xdc
[c0545f90] [c0008318] cpu_idle+0x54/0xdc (unreliable)
[c0545fb0] [c000231c] rest_init+0x68/0x7c
[c0545fc0] [c04e686c] start_kernel+0x230/0x2b0
[c0545ff0] [c000039c] skpinv+0x2b4/0x2f0
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..
]
Then the natural solution would be 'stop driver/device then adjust
ring buffer parameter then reactivate driver/device'.
v1: add roll back branch for 'auto reopen fail' statement
Signed-off-by: Liang Li <liang.li@windriver.com>
---
drivers/net/ucc_geth.c | 4 ++--
drivers/net/ucc_geth.h | 2 ++
drivers/net/ucc_geth_ethtool.c | 29 +++++++++++++++++++++++------
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 7d2e33a..5eadfa3 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3485,7 +3485,7 @@ err:
/* Called when something needs to use the ethernet device */
/* Returns 0 for success. */
-static int ucc_geth_open(struct net_device *dev)
+int ucc_geth_open(struct net_device *dev)
{
struct ucc_geth_private *ugeth = netdev_priv(dev);
int err;
@@ -3542,7 +3542,7 @@ err:
}
/* Stops the kernel queue, and halts the controller */
-static int ucc_geth_close(struct net_device *dev)
+int ucc_geth_close(struct net_device *dev)
{
struct ucc_geth_private *ugeth = netdev_priv(dev);
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 05a9558..1cfb400 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -1235,5 +1235,7 @@ int init_flow_control_params(u32 automatic_flow_control_mode,
u32 __iomem *upsmr_register, u32 __iomem *uempr_register,
u32 __iomem *maccfg1_register);
+extern int ucc_geth_open(struct net_device *);
+extern int ucc_geth_close(struct net_device *);
#endif /* __UCC_GETH_H__ */
diff --git a/drivers/net/ucc_geth_ethtool.c b/drivers/net/ucc_geth_ethtool.c
index 6f92e48..644a6db 100644
--- a/drivers/net/ucc_geth_ethtool.c
+++ b/drivers/net/ucc_geth_ethtool.c
@@ -255,13 +255,30 @@ uec_set_ringparam(struct net_device *netdev,
return -EINVAL;
}
- ug_info->bdRingLenRx[queue] = ring->rx_pending;
- ug_info->bdRingLenTx[queue] = ring->tx_pending;
-
if (netif_running(netdev)) {
- /* FIXME: restart automatically */
- printk(KERN_INFO
- "Please re-open the interface.\n");
+ u16 rx_t;
+ u16 tx_t;
+ printk(KERN_INFO "Stopping interface %s.\n", netdev->name);
+ ucc_geth_close(netdev);
+
+ rx_t = ug_info->bdRingLenRx[queue];
+ tx_t = ug_info->bdRingLenTx[queue];
+
+ ug_info->bdRingLenRx[queue] = ring->rx_pending;
+ ug_info->bdRingLenTx[queue] = ring->tx_pending;
+
+ printk(KERN_INFO "Reactivating interface %s.\n", netdev->name);
+ ret = ucc_geth_open(netdev);
+ if (ret) {
+ printk(KERN_WARNING "uec_set_ringparam: set ring param for running"
+ " interface %s failed. Please try to make the interface "
+ " down, then try again.\n", netdev->name);
+ ug_info->bdRingLenRx[queue] = rx_t;
+ ug_info->bdRingLenTx[queue] = tx_t;
+ }
+ } else {
+ ug_info->bdRingLenRx[queue] = ring->rx_pending;
+ ug_info->bdRingLenTx[queue] = ring->tx_pending;
}
return ret;
--
1.7.2
^ permalink raw reply related
* [PATCH 1/2] powerpc/mm: Assume first cpu is boot_cpuid not 0
From: Matthew McClintock @ 2010-08-31 23:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, kumar.gala
arch/powerpc/mm/mmu_context_nohash.c assumes the boot cpu
will always have smp_processor_id() == 0. This patch fixes
that assumption
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/mm/mmu_context_nohash.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
index 1f2d9ff..cf98c1e 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -334,7 +334,7 @@ static int __cpuinit mmu_context_cpu_notify(struct notifier_block *self,
/* We don't touch CPU 0 map, it's allocated at aboot and kept
* around forever
*/
- if (cpu == 0)
+ if (cpu == boot_cpuid)
return NOTIFY_OK;
switch (action) {
@@ -412,9 +412,11 @@ void __init mmu_context_init(void)
*/
context_map = alloc_bootmem(CTX_MAP_SIZE);
context_mm = alloc_bootmem(sizeof(void *) * (last_context + 1));
+#ifndef CONFIG_SMP
stale_map[0] = alloc_bootmem(CTX_MAP_SIZE);
+#else
+ stale_map[boot_cpuid] = alloc_bootmem(CTX_MAP_SIZE);
-#ifdef CONFIG_SMP
register_cpu_notifier(&mmu_context_cpu_nb);
#endif
--
1.6.6.1
^ permalink raw reply related
* [PATCH 2/2] powerpc/fsl_booke: Add support to boot from core other than 0
From: Matthew McClintock @ 2010-08-31 23:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, kumar.gala
In-Reply-To: <1283297085-3455-1-git-send-email-msm@freescale.com>
First we check to see if we are the first core booting up. This
is accomplished by comparing the boot_cpuid with -1, if it is we
assume this is the first core coming up.
Secondly, we need to update the initial thread info structure
to reflect the actual cpu we are running on otherwise
smp_processor_id() and related functions will return the default
initialization value of the struct or 0.
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
arch/powerpc/kernel/setup_32.c | 2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 258315a..5bbf593 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -152,8 +152,11 @@ _ENTRY(__early_start)
/* Check to see if we're the second processor, and jump
* to the secondary_start code if so
*/
- mfspr r24,SPRN_PIR
- cmpwi r24,0
+ lis r24, boot_cpuid@h
+ ori r24, r24, boot_cpuid@l
+ lwz r24, 0(r24)
+ cmpwi r24, -1
+ mfspr r24,SPRN_PIR
bne __secondary_start
#endif
@@ -175,6 +178,9 @@ _ENTRY(__early_start)
li r0,0
stwu r0,THREAD_SIZE-STACK_FRAME_OVERHEAD(r1)
+ rlwinm r22,r1,0,0,31-THREAD_SHIFT /* current thread_info */
+ stw r24, TI_CPU(r22)
+
bl early_init
#ifdef CONFIG_RELOCATABLE
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 8f58986..4be3ef4 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -46,7 +46,7 @@
extern void bootx_init(unsigned long r4, unsigned long phys);
-int boot_cpuid;
+int boot_cpuid = -1;
EXPORT_SYMBOL_GPL(boot_cpuid);
int boot_cpuid_phys;
--
1.6.6.1
^ permalink raw reply related
* [PATCH v2] powerpc/fsl_soc: Search all global-utilities nodes for rstccr
From: Matthew McClintock @ 2010-08-31 22:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Matthew McClintock, kumar.gala, timur
In-Reply-To: <AANLkTikdm6f6dRDoOXuBx0-viwNqHuez4P+xTum+M+9O@mail.gmail.com>
The first global-utilities node might not contain the rstcr
property, so we should search all the nodes
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
-Changed KERN_EMERG to KERN_ERR
-Break if we do not find rstcr mapped
-Restore of_put_node that was dropped
arch/powerpc/sysdev/fsl_soc.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index b91f7ac..6c67d9e 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -378,17 +378,23 @@ static __be32 __iomem *rstcr;
static int __init setup_rstcr(void)
{
struct device_node *np;
- np = of_find_node_by_name(NULL, "global-utilities");
- if ((np && of_get_property(np, "fsl,has-rstcr", NULL))) {
- rstcr = of_iomap(np, 0) + 0xb0;
- if (!rstcr)
- printk (KERN_EMERG "Error: reset control register "
- "not mapped!\n");
- } else if (ppc_md.restart == fsl_rstcr_restart)
+
+ for_each_node_by_name(np, "global-utilities") {
+ if ((of_get_property(np, "fsl,has-rstcr", NULL))) {
+ rstcr = of_iomap(np, 0) + 0xb0;
+ if (!rstcr)
+ printk (KERN_ERR "Error: reset control "
+ "register not mapped!\n");
+ break;
+ }
+ }
+
+ if (!rstcr && ppc_md.restart == fsl_rstcr_restart)
printk(KERN_ERR "No RSTCR register, warm reboot won't work\n");
if (np)
of_node_put(np);
+
return 0;
}
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH 0/8] v5 De-couple sysfs memory directories from memory sections
From: Anton Blanchard @ 2010-08-31 21:57 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linuxppc-dev, Greg KH, linux-kernel, Dave Hansen, linux-mm, akpm,
KAMEZAWA Hiroyuki
In-Reply-To: <4C60407C.2080608@austin.ibm.com>
Hi Nathan,
> This set of patches de-couples the idea that there is a single
> directory in sysfs for each memory section. The intent of the
> patches is to reduce the number of sysfs directories created to
> resolve a boot-time performance issue. On very large systems
> boot time are getting very long (as seen on powerpc hardware)
> due to the enormous number of sysfs directories being created.
> On a system with 1 TB of memory we create ~63,000 directories.
> For even larger systems boot times are being measured in hours.
>
> This set of patches allows for each directory created in sysfs
> to cover more than one memory section. The default behavior for
> sysfs directory creation is the same, in that each directory
> represents a single memory section. A new file 'end_phys_index'
> in each directory contains the physical_id of the last memory
> section covered by the directory so that users can easily
> determine the memory section range of a directory.
I tested this on a POWER7 with 2TB memory and the boot time improved from
greater than 6 hours (I gave up), to under 5 minutes. Nice!
Tested-by: Anton Blanchard <anton@samba.org>
Anton
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Kumar Gala @ 2010-08-31 21:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
The following changes since commit 54a834043314c257210db2a9d59f8cc605571639:
Michael Neuling (1):
powerpc: Don't use kernel stack with translation off
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git ..BRANCH.NOT.VERIFIED..
Alexander Graf (1):
powerpc/85xx: Fix compilation of mpc85xx_mds.c
Anton Vorontsov (1):
powerpc/85xx: Add P1021 PCI IDs and quirks
Julia Lawall (2):
arch/powerpc/platforms/83xx/mpc837x_mds.c: Add missing iounmap
arch/powerpc/sysdev/qe_lib/qe.c: Add of_node_put to avoid memory leak
Kumar Gala (1):
powerpc/85xx: Fix compile issue with p1022_ds due to lmb rename to memblock
Li Yang (1):
fsl_rio: fix compile errors
arch/powerpc/platforms/83xx/mpc837x_mds.c | 9 ++++++---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1 +
arch/powerpc/platforms/85xx/p1022_ds.c | 4 ++--
arch/powerpc/sysdev/fsl_pci.c | 2 ++
arch/powerpc/sysdev/fsl_rio.c | 6 +++++-
arch/powerpc/sysdev/qe_lib/qe.c | 1 +
include/linux/pci_ids.h | 2 ++
7 files changed, 19 insertions(+), 6 deletions(-)
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add P1021 PCI IDs and quirks
From: Kumar Gala @ 2010-08-31 21:44 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20100808140333.GA4706@oksana.dev.rtsoft.ru>
On Aug 8, 2010, at 9:03 AM, Anton Vorontsov wrote:
> This is needed for proper PCI-E support on P1021 SoCs.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 2 ++
> include/linux/pci_ids.h | 2 ++
> 2 files changed, 4 insertions(+), 0 deletions(-)
applied
- k
^ permalink raw reply
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