* Re: [PATCH 08/15] powerpc/cell: Extract duplicated IOPTE_* to <asm/iommu.h>
From: Geert Uytterhoeven @ 2009-05-11 7:24 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-fbdev-devel, Arnd Bergmann, linux-kernel, linuxppc-dev,
cbe-oss-dev
In-Reply-To: <20090510190825.GB23659@lst.de>
On Sun, 10 May 2009, Christoph Hellwig wrote:
> On Fri, May 08, 2009 at 04:01:17PM +0200, Geert Uytterhoeven wrote:
> > +/* Cell page table entries */
> > +#define IOPTE_PP_W 0x8000000000000000ul /* protection: write */
> > +#define IOPTE_PP_R 0x4000000000000000ul /* protection: read */
> > +#define IOPTE_M 0x2000000000000000ul /* coherency required */
> > +#define IOPTE_SO_R 0x1000000000000000ul /* ordering: writes */
> > +#define IOPTE_SO_RW 0x1800000000000000ul /* ordering: r & w */
> > +#define IOPTE_RPN_Mask 0x07fffffffffff000ul /* RPN */
> > +#define IOPTE_H 0x0000000000000800ul /* cache hint */
> > +#define IOPTE_IOID_Mask 0x00000000000007fful /* ioid */
>
> If this is in a global header it should probably have a CELL_ prefix.
Fair enough; I'll use CBE_, as that's shorter and used for the other
definitions in arch/powerpc/include/asm/cell-*.h, too.
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: David Jander @ 2009-05-11 6:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Miller, wd
In-Reply-To: <20090508.005251.14244652.davem@davemloft.net>
On Friday 08 May 2009 09:52:51 David Miller wrote:
> From: John Rigby <jcrigby@gmail.com>
> Date: Thu, 7 May 2009 20:02:53 -0600
>
> > Also don't forget that the register map is the same on 512x, mx and
> > coldfire platforms but not on the other ppc platforms so if you want
> > to one binary to rule them all you will need to have an offest table
> > or some such.
>
> I would suggest using ->read_reg() ->write_reg() methods for abstracting
> this. That's how we handle all of the different way ESP scsi chips
> have their registers wired up.
>
> I/O register reads take hundreds, if not thousands of CPU cycles so,
> relatively speaking, the indirection costs absolutely nothing.
I fear the memory-mapped I/O of the PowerPC SoC is *slightly* faster, so in
terms of cycle count, this WILL matter, although depending on how much
register-I/O the driver does, overall performance impact _may_ still be
negligible. I suggest testing this (benchmarks) before and after the change.
Best regsards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [PATCH v3] powerpc: Keep track of emulated instructions if debugfs is enabled
From: Geert Uytterhoeven @ 2009-05-11 6:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Linux/PPC Development
In-Reply-To: <1242009161.7767.38.camel@concordia>
On Mon, 11 May 2009, Michael Ellerman wrote:
> On Fri, 2009-05-08 at 16:15 +0200, Geert Uytterhoeven wrote:
> > Counters for the various classes of emulated instructions are available under
> > /sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs is mounted on
> > /sys/kernel/debug). Optionally (controlled by
> > /sys/kernel/debug/powerpc/emulated_instructions/do_warn), rate-limited warnings
> > can be printed to the console when instructions are emulated.
> >
> > Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> > ---
> > Tested on ppc64 (ps3) and ppc32 (sequoia) using mfpvr.
> >
> > v3:
> > - add generic unaligned
> > - switch from sysfs + sysctl to debugfs. All virtual files now show up under
> > /sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs mounted on
> > /sys/kernel/debug)
> > - enable the printing of rate-limited warnings by writing a non-zero value to
> > /sys/kernel/debug/powerpc/emulated_instructions/do_warn
> > - switch from per-CPU to system-wide counters
> > - always use 32-bit counters (was 64-bit on ppc64)
> > - counters are writable, i.e. can be reset (by root)
>
> Nice :)
>
> My only query is whether it needs its own CONFIG option. Some folks
> might want other DEBUG_FS things but not this?
That's possible. Let's see what the other folks say...
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: device trees.
From: David H. Lynch Jr. @ 2009-05-11 6:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40905102108l5c964893y2dfb84763e13511@mail.gmail.com>
I will have to look at the code referenced below,
But my objective is not to address partial reconfiguration at this time.
At Pico we have come to the conclusion that as it is currently done
partial reconfiguration has extremely limited use.
We are actively looking at other techniques as well as different
FPGA technology to impliment usable equivalents.
But partial reconfiguration is not the only way to encounter a
dynamic environment.
A typical pico system has multiple bit files and multiple
executables stored in its flash file system.
Power up and soft resets might each run through a different sequence
of bit files and executables.
My issue is that post 2.6.26 unless I can dynamically create the
device tree inside our monitor/bootloader
we must at minimum have a different device tree for each bitfile, or
worse if we wrap the device tree into the executable,
a different linux executable for each bit file.
We are very actively headed in the opposite direction. It is my/our
intention to have a single linux executable that works accross
everyone of our cards and everyone of our bitfiles.
Grant Likely wrote:
> On Sun, May 10, 2009 at 8:00 PM, Michael Ellerman
> <michael@ellerman.id.au> wrote:
>
>> On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote:
>>
>>> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>>>
>>>> Is there an example somewhere that shows building a device tree on
>>>> the fly ?
>>>>
>>>> As our products move forward it becomes increasingly clear that
>>>> static configurations are not going to work.
>>>>
>>> To use device tree with partial reconfiguration would require rework
>>> to the device tree infrastructure to prune and graft portions of the
>>> device tree. I think it is possible, but it is non-trivial to get
>>> working.
>>>
>> arch/powerpc/platforms/pseries/reconfig.c
>>
>> Not pretty, but it does more or less what you're talking about. Would
>> need some work to get it going on !pseries obviously.
>>
>
> Heh, I didn't even know this existed. :-)
>
> Thinking about this more, it seems to me that the tricky bit would be
> figuring out how to drop all references to a node before it is pruned
> from the tree. of_platform_devices would probably be the easiest
> because the bus could walked before pruning the node, but there are
> also references on the i2c, spi and mdio busses that must be dealt
> with appropriately.
>
> g.
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: [PATCH] i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
From: Mark Ware @ 2009-05-11 4:28 UTC (permalink / raw)
To: Ben Dooks; +Cc: Linuxppc-dev Development, linux-i2c
In-Reply-To: <20090503222352.GB5750@fluff.org.uk>
Ben Dooks wrote:
> On Wed, Apr 29, 2009 at 08:43:14AM -0500, Kumar Gala wrote:
>> On Apr 22, 2009, at 4:56 PM, Ben Dooks wrote:
>>
>>> On Tue, Apr 21, 2009 at 10:11:51AM -0500, Kumar Gala wrote:
>>>> On Apr 21, 2009, at 7:49 AM, Mark Ware wrote:
>>>>
>>>>> Recent DMA changes result in a BUG() when NULL is passed to
>>>>> dma_alloc_coherent in place of a device.
>>>>>
>>>>> Signed-off-by: Mark Ware <mware@elphinstone.net>
>>>>> ---
>>>>>
>>>>> This patch fixes the BUG() during boot that has appeared during the
>>>>> 2.6.30 window. It has been tested and appears correct on my 8280
>>>>> based
>>>>> board.
>>>>> Sent to both linuxppc-dev and linux-i2c, since I'm not sure where it
>>>>> belongs.
>>>>>
>>>>>
>>>>> drivers/i2c/busses/i2c-cpm.c | 14 ++++++++------
>>>>> 1 files changed, 8 insertions(+), 6 deletions(-)
>>>> Acked-by: Kumar Gala <galak@kernel.crashing.org>
>>>>
>>>> Ben, I'm expecting you to pick this up unless you tell me otherwise.
>>> Yes.
>> This go in yet?
>
> I've had to do a manual apply due to some changes in the
> driver, so can someone please do a build of my git tree
> at:
>
> git://aeryn.fluff.org.uk/bjdooks/linux.git i2c-for-2630-rc5
>
> or tell me which arch and defconfig to build.
>
Ping. Is there anything still blocking this?
Mark Ware
^ permalink raw reply
* Re: device trees.
From: Grant Likely @ 2009-05-11 4:08 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, dhlii
In-Reply-To: <1242007203.7767.28.camel@concordia>
On Sun, May 10, 2009 at 8:00 PM, Michael Ellerman
<michael@ellerman.id.au> wrote:
> On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote:
>> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. <dhlii@dlasys.net> w=
rote:
>> > =A0 =A0Is there an example somewhere that shows building a device tree=
on
>> > the fly ?
>> >
>> > =A0 =A0As our products move forward it becomes increasingly clear that
>> > static configurations are not going to work.
>
>> To use device tree with partial reconfiguration would require rework
>> to the device tree infrastructure to prune and graft portions of the
>> device tree. =A0I think it is possible, but it is non-trivial to get
>> working.
>
> arch/powerpc/platforms/pseries/reconfig.c
>
> Not pretty, but it does more or less what you're talking about. Would
> need some work to get it going on !pseries obviously.
Heh, I didn't even know this existed. :-)
Thinking about this more, it seems to me that the tricky bit would be
figuring out how to drop all references to a node before it is pruned
from the tree. of_platform_devices would probably be the easiest
because the bus could walked before pruning the node, but there are
also references on the i2c, spi and mdio busses that must be dealt
with appropriately.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] mmc: Add fsl,esdhc as a valid compatible to bind against
From: Michael Ellerman @ 2009-05-11 2:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, pierre, linux-kernel
In-Reply-To: <1241790769-3843-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 303 bytes --]
On Fri, 2009-05-08 at 08:52 -0500, Kumar Gala wrote:
> We plan to use fsl,esdhc going forward as the base compatible so update
> the driver to bind against it.
I was going to NAK this based on its non-sensical changelog, but going
backward you're not the first to be going forward :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v3] powerpc: Keep track of emulated instructions if debugfs is enabled
From: Michael Ellerman @ 2009-05-11 2:32 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Linux/PPC Development
In-Reply-To: <alpine.LRH.2.00.0905081611130.7964@vixen.sonytel.be>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Fri, 2009-05-08 at 16:15 +0200, Geert Uytterhoeven wrote:
> Counters for the various classes of emulated instructions are available under
> /sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs is mounted on
> /sys/kernel/debug). Optionally (controlled by
> /sys/kernel/debug/powerpc/emulated_instructions/do_warn), rate-limited warnings
> can be printed to the console when instructions are emulated.
>
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> ---
> Tested on ppc64 (ps3) and ppc32 (sequoia) using mfpvr.
>
> v3:
> - add generic unaligned
> - switch from sysfs + sysctl to debugfs. All virtual files now show up under
> /sys/kernel/debug/powerpc/emulated_instructions (assumed debugfs mounted on
> /sys/kernel/debug)
> - enable the printing of rate-limited warnings by writing a non-zero value to
> /sys/kernel/debug/powerpc/emulated_instructions/do_warn
> - switch from per-CPU to system-wide counters
> - always use 32-bit counters (was 64-bit on ppc64)
> - counters are writable, i.e. can be reset (by root)
Nice :)
My only query is whether it needs its own CONFIG option. Some folks
might want other DEBUG_FS things but not this?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpic: improve interrupt handling performance
From: Michael Ellerman @ 2009-05-11 2:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1241820500-12545-1-git-send-email-galak@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]
On Fri, 2009-05-08 at 17:08 -0500, Kumar Gala wrote:
> Before when we were setting up the irq host map for mpic we passed in
> just isu_size for the size of the linear map. However, for a number of
> mpic implementations we have no isu (thus pass in 0) and will end up
> with a no linear map (size = 0). This causes us to always call
> irq_find_mapping() from mpic_get_irq().
>
> By moving the allocation of the host map to after we've determined the
> number of sources we can actually benefit from having a linear map for
> the non-isu users that covers all the interrupt sources.
That's a nasty bug, so I think we should do:
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 7d46e5d..2b958d6 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -537,6 +537,7 @@ struct irq_host *irq_alloc_host(struct device_node *of_node,
}
break;
case IRQ_HOST_MAP_LINEAR:
+ WARN_ON(revmap_arg == 0);
rmap = (unsigned int *)(host + 1);
for (i = 0; i < revmap_arg; i++)
rmap[i] = NO_IRQ;
To save anyone else the embarrassment :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCH] powerpc: Allow mem=x cmdline to work with 4G+
From: Michael Ellerman @ 2009-05-11 2:09 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1241821167-13069-1-git-send-email-beckyb@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 270 bytes --]
On Fri, 2009-05-08 at 17:19 -0500, Becky Bruce wrote:
> We're currently choking on mem=4g (and above) due to memory_limit
> being specified as an unsigned long. Make memory_limit
> phys_addr_t to fix this.
Can we not just make it u64 to save the casts?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: device trees.
From: Michael Ellerman @ 2009-05-11 2:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, dhlii
In-Reply-To: <fa686aa40905091351k140c64a0w27eb44908218814@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote:
> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > Is there an example somewhere that shows building a device tree on
> > the fly ?
> >
> > As our products move forward it becomes increasingly clear that
> > static configurations are not going to work.
> To use device tree with partial reconfiguration would require rework
> to the device tree infrastructure to prune and graft portions of the
> device tree. I think it is possible, but it is non-trivial to get
> working.
arch/powerpc/platforms/pseries/reconfig.c
Not pretty, but it does more or less what you're talking about. Would
need some work to get it going on !pseries obviously.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Improve decrementer accuracy
From: Anton Blanchard @ 2009-05-10 23:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, davem
I have been looking at sources of OS jitter and notice that after a long
NO_HZ idle period we wakeup too early:
relative time (us) event
timer irq exit
999946.405 timer irq entry
4.835 timer irq exit
21.685 timer irq entry
3.540 timer (tick_sched_timer) entry
Here we slept for just under a second then took a timer interrupt that did
nothing. 21.685 us later we wake up again and do the work.
We set a rather low shift value of 16 for the decrementer clockevent, which I
think is causing this issue. On this box we have a 207MHz decrementer and see:
clockevent: decrementer mult[3501] shift[16] cpu[0]
For calculations of large intervals this mult/shift combination could be
off by a significant amount. I notice the sparc code has a loop that iterates
to find a mult/shift combination that maximises the shift value while
keeping mult under 32bit. With the patch below we get:
clockevent: decrementer mult[35015c20] shift[32] cpu[15]
And we no longer see the spurious wakeups.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
- I haven't tested if it does the right thing on 32bit yet
- Should we do something similar to the timebase? We use a 22 bit shift
there but time might drift if that isnt accurate enough.
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c 2009-05-10 19:48:39.000000000 +1000
+++ linux-2.6/arch/powerpc/kernel/time.c 2009-05-11 09:36:25.000000000 +1000
@@ -110,7 +110,7 @@
static struct clock_event_device decrementer_clockevent = {
.name = "decrementer",
.rating = 200,
- .shift = 16,
+ .shift = 0, /* To be filled in */
.mult = 0, /* To be filled in */
.irq = 0,
.set_next_event = decrementer_set_next_event,
@@ -852,6 +852,22 @@
decrementer_set_next_event(DECREMENTER_MAX, dev);
}
+static void __init setup_clockevent_multiplier(unsigned long hz)
+{
+ u64 mult, shift = 32;
+
+ while (1) {
+ mult = div_sc(hz, NSEC_PER_SEC, shift);
+ if (mult && (mult >> 32UL) == 0UL)
+ break;
+
+ shift--;
+ }
+
+ decrementer_clockevent.shift = shift;
+ decrementer_clockevent.mult = mult;
+}
+
static void register_decrementer_clockevent(int cpu)
{
struct clock_event_device *dec = &per_cpu(decrementers, cpu).event;
@@ -869,8 +885,7 @@
{
int cpu = smp_processor_id();
- decrementer_clockevent.mult = div_sc(ppc_tb_freq, NSEC_PER_SEC,
- decrementer_clockevent.shift);
+ setup_clockevent_multiplier(ppc_tb_freq);
decrementer_clockevent.max_delta_ns =
clockevent_delta2ns(DECREMENTER_MAX, &decrementer_clockevent);
decrementer_clockevent.min_delta_ns =
^ permalink raw reply
* Re: [PATCH 08/15] powerpc/cell: Extract duplicated IOPTE_* to <asm/iommu.h>
From: Christoph Hellwig @ 2009-05-10 19:08 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-fbdev-devel, Arnd Bergmann, linux-kernel, linuxppc-dev,
cbe-oss-dev
In-Reply-To: <1241791284-11490-9-git-send-email-Geert.Uytterhoeven@sonycom.com>
On Fri, May 08, 2009 at 04:01:17PM +0200, Geert Uytterhoeven wrote:
> +/* Cell page table entries */
> +#define IOPTE_PP_W 0x8000000000000000ul /* protection: write */
> +#define IOPTE_PP_R 0x4000000000000000ul /* protection: read */
> +#define IOPTE_M 0x2000000000000000ul /* coherency required */
> +#define IOPTE_SO_R 0x1000000000000000ul /* ordering: writes */
> +#define IOPTE_SO_RW 0x1800000000000000ul /* ordering: r & w */
> +#define IOPTE_RPN_Mask 0x07fffffffffff000ul /* RPN */
> +#define IOPTE_H 0x0000000000000800ul /* cache hint */
> +#define IOPTE_IOID_Mask 0x00000000000007fful /* ioid */
If this is in a global header it should probably have a CELL_ prefix.
^ permalink raw reply
* Re: device trees.
From: Grant Likely @ 2009-05-09 20:51 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-dev
In-Reply-To: <4A0457BC.3040408@dlasys.net>
On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrot=
e:
> =A0 =A0Is there an example somewhere that shows building a device tree on
> the fly ?
>
> =A0 =A0As our products move forward it becomes increasingly clear that
> static configurations are not going to work.
Knowing your history, I assume you're talking about FPGA device trees
here. Are you doing partial reconfiguration at runtime? Or are you
talking about generating a device tree to match the FPGA design?
For the later, there is a tool which works with EDK to generate a
device tree based on an EDK design. You can find it on the xilinx git
server:
http://git.xilinx.com/cgi-bin/gitweb.cgi?p=3Ddevice-tree.git;a=3Dsummary
To use device tree with partial reconfiguration would require rework
to the device tree infrastructure to prune and graft portions of the
device tree. I think it is possible, but it is non-trivial to get
working.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: question about softirqs
From: David Miller @ 2009-05-09 6:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <18948.63755.279732.294842@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Sat, 9 May 2009 13:31:23 +1000
> David Miller writes:
>
>> Grumble, when did that happen :-(
>
> Ages ago (i.e. before the switch to git :). Talk to Ingo, it's his
> doing IIRC.
I'll first do some data mining before coming to any (further)
conclusions :-)
>> That's horrible for latency compared to handling it directly
>> in the trap return path.
>
> Actually, I don't know why we ever let there be softirqs pending when
> we're in process context. I would think that we should just call
> do_softirq immediately if we raise a softirq when !in_interrupt().
> But I might be missing some subtlety.
I bet it was a non-starter before IRQ stacks.
It does seem like a good idea to me.
You know, for networking over loopback (one of the only real cases
that even matters, if we get a hard interrupt then the return from
that would process any softints), we probably make out just fine
anyways. As long as we hit a local_bh_enable() (and in the return
path from device transmit that's exceedingly likely as all of the
networking locking is BH safe) we'll run the softints from that and
thus long before we get to syscall return.
^ permalink raw reply
* Re: question about softirqs
From: Paul Mackerras @ 2009-05-09 3:31 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20090508.165358.97542490.davem@davemloft.net>
David Miller writes:
> Grumble, when did that happen :-(
Ages ago (i.e. before the switch to git :). Talk to Ingo, it's his
doing IIRC.
> That's horrible for latency compared to handling it directly
> in the trap return path.
Actually, I don't know why we ever let there be softirqs pending when
we're in process context. I would think that we should just call
do_softirq immediately if we raise a softirq when !in_interrupt().
But I might be missing some subtlety.
Paul.
^ permalink raw reply
* Re: question about softirqs
From: Benjamin Herrenschmidt @ 2009-05-09 2:52 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, paulus
In-Reply-To: <20090508.165358.97542490.davem@davemloft.net>
> > The soft irq stuff is pretty much all generic code these days, except
> > for the code to switch to the softirq stack.
>
> Grumble, when did that happen :-(
>
> That's horrible for latency compared to handling it directly
> in the trap return path.
If it is indeed such a problem, it would be reasonably easy to
handle it in the return-to-userspace path around the same place
where we test for pending signals (isn't what we used to do
anyway ?)
Cheers,
Ben.
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-09 0:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18948.49541.735156.176919@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> If a soft irq is raised in process context, raise_softirq() in
> kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
> runs soon to process the soft irq. So what would happen is that we
> would see the TIF_RESCHED_PENDING flag on the current task in the
> syscall exit path and call schedule() which would switch to ksoftirqd
> to process the soft irq (if it hasn't already been processed by that
> stage).
I think I see a problem with this. Suppose I have a SCHED_FIFO task
spinning on recvmsg() with MSG_DONTWAIT set (and maybe doing other stuff
if there are no messages). Under the scenario you described, schedule()
would re-run the spinning task, no? This could prevent any incoming
packets from actually being sent up the stack until we get a real
hardware interrupt--which could be a whole jiffy if interrupt mitigation
is enabled in the net device.
Chris
^ permalink raw reply
* Re: question about softirqs
From: David Miller @ 2009-05-08 23:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <18948.49541.735156.176919@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Sat, 9 May 2009 09:34:29 +1000
> If a soft irq is raised in process context, raise_softirq() in
> kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
> runs soon to process the soft irq. So what would happen is that we
> would see the TIF_RESCHED_PENDING flag on the current task in the
> syscall exit path and call schedule() which would switch to ksoftirqd
> to process the soft irq (if it hasn't already been processed by that
> stage).
>
> If the soft irq is raised in interrupt context, then the soft irq gets
> run via the do_softirq() call in irq_exit(), as you saw.
>
> The soft irq stuff is pretty much all generic code these days, except
> for the code to switch to the softirq stack.
Grumble, when did that happen :-(
That's horrible for latency compared to handling it directly
in the trap return path.
^ permalink raw reply
* Re: question about softirqs
From: Paul Mackerras @ 2009-05-08 23:34 UTC (permalink / raw)
To: Chris Friesen; +Cc: linuxppc-dev
In-Reply-To: <4A04B76D.20106@nortel.com>
Chris Friesen writes:
> I'm trying to figure out where exactly softirqs are called on return
> from a syscall in 64-bit powerpc. I can see where they get called for a
> normal interrupt via the irq_exit() path, but not for syscalls.
If a soft irq is raised in process context, raise_softirq() in
kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
runs soon to process the soft irq. So what would happen is that we
would see the TIF_RESCHED_PENDING flag on the current task in the
syscall exit path and call schedule() which would switch to ksoftirqd
to process the soft irq (if it hasn't already been processed by that
stage).
If the soft irq is raised in interrupt context, then the soft irq gets
run via the do_softirq() call in irq_exit(), as you saw.
The soft irq stuff is pretty much all generic code these days, except
for the code to switch to the softirq stack.
Paul.
^ permalink raw reply
* Re: question about softirqs
From: David Miller @ 2009-05-08 23:05 UTC (permalink / raw)
To: cfriesen; +Cc: linuxppc-dev
In-Reply-To: <4A04B76D.20106@nortel.com>
From: "Chris Friesen" <cfriesen@nortel.com>
Date: Fri, 08 May 2009 16:51:25 -0600
> I'm trying to figure out where exactly softirqs are called on return
> from a syscall in 64-bit powerpc. I can see where they get called for
> a normal interrupt via the irq_exit() path, but not for syscalls.
>
> I'm sure I'm missing something obvious...can anyone help?
I can't see where it does this either, strange.
That would be a very terrible bug if it's not invoking
pending softirqs before return from system calls.
Although, it might be happening via some clever side effect
of how the software managed hardware interrupt stuff works
on powerpc.
^ permalink raw reply
* question about softirqs
From: Chris Friesen @ 2009-05-08 22:51 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm trying to figure out where exactly softirqs are called on return
from a syscall in 64-bit powerpc. I can see where they get called for a
normal interrupt via the irq_exit() path, but not for syscalls.
I'm sure I'm missing something obvious...can anyone help?
Thanks,
Chris
^ permalink raw reply
* Re: [PowerPC] Next May 8 boot failure: OOPS during ibmveth module init
From: Jiri Pirko @ 2009-05-08 22:33 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, linux-next, netdev, sfr
In-Reply-To: <20090508.125722.54378771.davem@davemloft.net>
Fri, May 08, 2009 at 09:57:22PM CEST, davem@davemloft.net wrote:
>From: Sachin Sant <sachinp@in.ibm.com>
>Date: Fri, 08 May 2009 18:22:48 +0530
>
>> Todays Next failed to boot on a Power6 JS22 blade with following oops.
>
>Jiri, I suspect this might be your address list changes.
>
>Although that's just a guess. But please take a look.
Hmm, only thing I see might cause the problem would be if calling __hw_addr_add
in dev_addr_init fails, then dev->dev_addr would contain zeroes (which looks
this is not the case). But in this case the oops would appear earlier (in
ibmveth_probe dev_addr memcpy).
Will do the patch which checks the result to behave correctly in case of oom
but this imho this wouldn't help. Strange, I will dig into this more tomorrow.
>
>> Unable to handle kernel paging request for data at address
>> 0x654af306c04b990
>> Faulting instruction address: 0xc00000000003a740
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=1024 NUMA pSeries
>> Modules linked in: ibmveth(+) sg sd_mod crc_t10dif ibmvscsic
>> scsi_transport_srp scsi_tgt scsi_mod
>> NIP: c00000000003a740 LR: c000000000361e20 CTR: 0000000000000000
>> REGS: c000000042af6e80 TRAP: 0300 Not tainted
>> (2.6.30-rc4-next-20090508)
>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 28222286 XER: 20000001
>> DAR: 0654af306c04b990, DSISR: 0000000040000000
>> TASK = c0000000428084d0[590] 'modprobe' THREAD: c000000042af4000 CPU:
>> 0
>> GPR00: c000000000361e10 c000000042af7100 c000000000eb8190
>> c00000004427cc80
>> GPR04: 0654af306c04b990 0000000000000006 0000000000000000
>> 0000000000000002
>> GPR08: c00000004427cc00 0000000000000088 0000000000000280
>> 000000000000007c
>> GPR12: 0000000084222284 c000000000f92400 0000000000000000
>> 0000000000000000
>> GPR16: 0000000000000000 0000000000000000 d000000000ed4346
>> d000000000ed3aa0
>> GPR20: d000000000ed6358 c00000004427cc00 00000000ffffffff
>> 0000000000000000
>> GPR24: 0000000000000000 c0000000402d0000 0000000000000010
>> c00000004194b400
>> GPR28: 0000000000000006 0654af306c04b990 c000000000e44f18
>> 0000000000000000
>> NIP [c00000000003a740] .memcpy+0x240/0x278
>> LR [c000000000361e20] .__nla_put+0x30/0x4c
>> Call Trace:
>> [c000000042af7100] [c000000000361e10] .__nla_put+0x20/0x4c
>> (unreliable)
>> [c000000042af7190] [c000000000361e88] .nla_put+0x4c/0x60
>> [c000000042af7200] [c00000000053993c] .rtnl_fill_ifinfo+0x308/0x614
>> [c000000042af7300] [c00000000053a118] .rtmsg_ifinfo+0x104/0x198
>> [c000000042af73b0] [c00000000053a244] .rtnetlink_event+0x98/0xb0
>> [c000000042af7430] [c0000000005c8330] .notifier_call_chain+0x68/0xdc
>> [c000000042af74d0] [c000000000530488] .register_netdevice+0x390/0x418
>> [c000000042af75a0] [c000000000530568] .register_netdev+0x58/0x80
>> [c000000042af7630] [d000000000ed2da4] .ibmveth_probe+0x2c8/0x3a4
>> [ibmveth]
>> [c000000042af7730] [c000000000023208] .vio_bus_probe+0x2f0/0x358
>> [c000000042af77f0] [c000000000462be0] .driver_probe_device+0xd4/0x1bc
>> [c000000042af7890] [c000000000462d5c] .__driver_attach+0x94/0xd8
>> [c000000042af7920] [c000000000462164] .bus_for_each_dev+0x80/0xe8
>> [c000000042af79d0] [c0000000004629b0] .driver_attach+0x28/0x40
>> [c000000042af7a50] [c000000000461808] .bus_add_driver+0xdc/0x27c
>> [c000000042af7af0] [c0000000004631d0] .driver_register+0xf0/0x1b0
>> [c000000042af7b90] [c000000000025178] .vio_register_driver+0x44/0x60
>> [c000000042af7c20] [d000000000ed2ed4] .ibmveth_module_init+0x54/0xa60
>> [ibmveth]
>> [c000000042af7ca0] [c0000000000092c0] .do_one_initcall+0x80/0x19c
>> [c000000042af7d90] [c0000000000bf884] .SyS_init_module+0xe0/0x248
>> [c000000042af7e30] [c000000000008534] syscall_exit+0x0/0x40
>> Instruction dump:
>> 7cb01120 7c862214 7c661a14 4bfffe04 409c001c 80040000 81240004
>> 38840008
>> 90030000 91230004 38630008 409d0014 <80040000> 38840004 90030000
>> 38630004
>> ---[ end trace 695e9dc0c5a9da2f ]---
>>
>> udevd-event[587]: '/sbin/modprobe' abnormal exit
>>
>> Unable to handle kernel paging request for data at address
>> 0x654af306c04b990
>> Faulting instruction address: 0xc000000000543ce0
>> Oops: Kernel access of bad area, sig: 11 [#2]
>> SMP NR_CPUS=1024 NUMA pSeries
>> Modules linked in: ibmveth(+) sg sd_mod crc_t10dif ibmvscsic
>> scsi_transport_srp scsi_tgt scsi_mod
>> NIP: c000000000543ce0 LR: c000000000543dcc CTR: c00000000053dd98
>> REGS: c0000000408b3740 TRAP: 0300 Tainted: G D
>> (2.6.30-rc4-next-20090508)
>> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 24042428 XER: 00000001
>> DAR: 0654af306c04b990, DSISR: 0000000040000000
>> TASK = c00000004053d880[752] 'udevd' THREAD: c0000000408b0000 CPU: 3
>> GPR00: c000000000543dcc c0000000408b39c0 c000000000eb8190
>> c0000000448e0000
>> GPR04: 0000000000010000 c000000000796dec 0000000000000006
>> 0000000000000000
>> GPR08: c00000004265cf34 c000000000ea7250 c00000004265cf34
>> 0000000000000000
>> GPR12: 0000000044042488 c000000000f92a00 0000000000000001
>> 0000000000000001
>> GPR16: 00000000100372dc 00000000100374e0 00000000100376f8
>> 0000000000000000
>> GPR20: 0000000010036ec8 0000000000000000 00000fffdb3a6618
>> 0000000000000200
>> GPR24: 0000000000000006 0000000000000005 c0000000448f0000
>> c0000000448e0000
>> GPR28: 0654af306c04b990 0000000000000000 c000000000e45318
>> c0000000448e0000
>> NIP [c000000000543ce0] ._format_mac_addr+0x54/0xd4
>> LR [c000000000543dcc] .sysfs_format_mac+0x30/0x6c
>> Call Trace:
>> [c0000000408b39c0] [c00000000010c9a4]
>> .__alloc_pages_internal+0x1b8/0x590 (unreliable)
>> [c0000000408b3a70] [c000000000543dcc] .sysfs_format_mac+0x30/0x6c
>> [c0000000408b3b00] [c00000000053dde8] .show_address+0x50/0x88
>> [c0000000408b3b90] [c00000000045ead4] .dev_attr_show+0x4c/0x94
>> [c0000000408b3c20] [c0000000001bce48] .sysfs_read_file+0x10c/0x1d0
>> [c0000000408b3ce0] [c00000000014c9a0] .vfs_read+0xd0/0x1bc
>> [c0000000408b3d80] [c00000000014cb94] .SyS_read+0x58/0xa0
>> [c0000000408b3e30] [c000000000008534] syscall_exit+0x0/0x40
>> Instruction dump:
>> f8010010 ebc2cc58 f821ff51 7c7b1b78 7cd83378 7cbc2b78 7f432214
>> 7c7f1b78
>> 3ba00000 3b26ffff 48000044 e8be8000 <88dc0000> 3b9c0001 4be0ff89
>> 60000000
>> ---[ end trace 695e9dc0c5a9da30 ]---
>>
>> attempt to access beyond end of device
>>
>> Next May 7 with same config boots fine.
>>
>> Thanks
>> -Sachin
>>
>> --
>>
>> ---------------------------------
>> Sachin Sant
>> IBM Linux Technology Center
>> India Systems and Technology Labs
>> Bangalore, India
>> ---------------------------------
>>
^ permalink raw reply
* [PATCH] powerpc: Allow mem=x cmdline to work with 4G+
From: Becky Bruce @ 2009-05-08 22:19 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
We're currently choking on mem=4g (and above) due to memory_limit
being specified as an unsigned long. Make memory_limit
phys_addr_t to fix this.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
Ben,
This is a fix for something I missed in the earlier large physical patches.
I've tested it on MPC8641 both with and without PHYS_64BIT; I've build
tested on ppc64_defconfig as well.
Cheers,
B
arch/powerpc/include/asm/system.h | 2 +-
arch/powerpc/kernel/machine_kexec.c | 4 ++--
arch/powerpc/kernel/prom.c | 8 ++++----
arch/powerpc/mm/mem.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/system.h
index f612798..2b2420a 100644
--- a/arch/powerpc/include/asm/system.h
+++ b/arch/powerpc/include/asm/system.h
@@ -212,7 +212,7 @@ extern struct task_struct *_switch(struct thread_struct *prev,
extern unsigned int rtas_data;
extern int mem_init_done; /* set on boot once kmalloc can be called */
extern int init_bootmem_done; /* set on !NUMA once bootmem is available */
-extern unsigned long memory_limit;
+extern phys_addr_t memory_limit;
extern unsigned long klimit;
extern void *alloc_maybe_bootmem(size_t size, gfp_t mask);
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index d59e2b1..bb3d893 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -125,8 +125,8 @@ void __init reserve_crashkernel(void)
/* Crash kernel trumps memory limit */
if (memory_limit && memory_limit <= crashk_res.end) {
memory_limit = crashk_res.end + 1;
- printk("Adjusted memory limit for crashkernel, now 0x%lx\n",
- memory_limit);
+ printk("Adjusted memory limit for crashkernel, now 0x%llx\n",
+ (unsigned long long)memory_limit);
}
printk(KERN_INFO "Reserving %ldMB of memory at %ldMB "
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 5ec6a9e..ce01ff2 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -426,7 +426,7 @@ static int __init early_parse_mem(char *p)
return 1;
memory_limit = PAGE_ALIGN(memparse(p, &p));
- DBG("memory limit = 0x%lx\n", memory_limit);
+ DBG("memory limit = 0x%llx\n", (unsigned long long)memory_limit);
return 0;
}
@@ -1160,7 +1160,7 @@ static inline void __init phyp_dump_reserve_mem(void) {}
void __init early_init_devtree(void *params)
{
- unsigned long limit;
+ phys_addr_t limit;
DBG(" -> early_init_devtree(%p)\n", params);
@@ -1204,7 +1204,7 @@ void __init early_init_devtree(void *params)
limit = memory_limit;
if (! limit) {
- unsigned long memsize;
+ phys_addr_t memsize;
/* Ensure that total memory size is page-aligned, because
* otherwise mark_bootmem() gets upset. */
@@ -1218,7 +1218,7 @@ void __init early_init_devtree(void *params)
lmb_analyze();
lmb_dump_all();
- DBG("Phys. mem: %lx\n", lmb_phys_mem_size());
+ DBG("Phys. mem: %llx\n", lmb_phys_mem_size());
/* We may need to relocate the flat tree, do it now.
* FIXME .. and the initrd too? */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index f668fa9..d0602a7 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -57,7 +57,7 @@
int init_bootmem_done;
int mem_init_done;
-unsigned long memory_limit;
+phys_addr_t memory_limit;
#ifdef CONFIG_HIGHMEM
pte_t *kmap_pte;
--
1.6.0.6
^ permalink raw reply related
* [PATCH] powerpc/mpic: improve interrupt handling performance
From: Kumar Gala @ 2009-05-08 22:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Before when we were setting up the irq host map for mpic we passed in
just isu_size for the size of the linear map. However, for a number of
mpic implementations we have no isu (thus pass in 0) and will end up
with a no linear map (size = 0). This causes us to always call
irq_find_mapping() from mpic_get_irq().
By moving the allocation of the host map to after we've determined the
number of sources we can actually benefit from having a linear map for
the non-isu users that covers all the interrupt sources.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Ben,
I leave it up to you if you want to put this in for 2.6.30. We see about a 1us
reduction in time spent in mpic_get_irq() based on ftrace.
- k
arch/powerpc/sysdev/mpic.c | 16 +++++++++-------
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 21b9567..0efc12d 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1057,13 +1057,6 @@ struct mpic * __init mpic_alloc(struct device_node *node,
memset(mpic, 0, sizeof(struct mpic));
mpic->name = name;
- mpic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
- isu_size, &mpic_host_ops,
- flags & MPIC_LARGE_VECTORS ? 2048 : 256);
- if (mpic->irqhost == NULL)
- return NULL;
-
- mpic->irqhost->host_data = mpic;
mpic->hc_irq = mpic_irq_chip;
mpic->hc_irq.typename = name;
if (flags & MPIC_PRIMARY)
@@ -1213,6 +1206,15 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic->isu_shift = 1 + __ilog2(mpic->isu_size - 1);
mpic->isu_mask = (1 << mpic->isu_shift) - 1;
+ mpic->irqhost = irq_alloc_host(node, IRQ_HOST_MAP_LINEAR,
+ isu_size ? isu_size : mpic->num_sources,
+ &mpic_host_ops,
+ flags & MPIC_LARGE_VECTORS ? 2048 : 256);
+ if (mpic->irqhost == NULL)
+ return NULL;
+
+ mpic->irqhost->host_data = mpic;
+
/* Display version */
switch (greg_feature & MPIC_GREG_FEATURE_VERSION_MASK) {
case 1:
--
1.6.0.6
^ 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