* Re: device trees.
From: David H. Lynch Jr. @ 2009-05-13 6:11 UTC (permalink / raw)
To: Stephen Neuendorffer, Grant Likely, linuxppc-dev,
David H. Lynch Jr.
In-Reply-To: <20090513023614.GJ24338@yookeroo.seuss>
David Gibson wrote:
> On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
>
>> Another possibility is to pad the DTB with a DESYNC command and the
>> correct pad frame, just in case it cannot be prevented.
>>
>
> Um.. one thing I'm missing in this discussion of attaching the dtb to
> the bitstream: I don't see how the bitstream becomes accessible to
> the kernel at runtime. Unless you were exposing the dtb as part of
> the fpga programming, but I thought you explicitly weren't doing that
> because of limited bram space.
>
> I imagine this is simply due to my ignorance about FPGA techniques,
> but if someone could enlighten me...?
>
While I am not sure I grasp all of the nuances why, this is NOT the
scheme Stephen recomends.
But it looks to be the most promising for me at Pico.
In my instance, the FPGA code is typically in NOR Flash - actually
several different FPGA bitstreams might be in Flash.
The mechanism that we use to load the FPGA ensures that I can know
the Flash File that was used to program the FPGA.
That means that my monitor an read that file and extract the device
tree.
The remainder is a discussion of how to concatenate the dtb and the
bit stream together, the pros/cons of prepending vs. appending,
and work arrounds for issues.
The critical factor is that the nature of the FPGA load process
makes it possible to put data at the front or rear and assure that it
gets ignored.
--
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: device trees.
From: David Gibson @ 2009-05-13 6:21 UTC (permalink / raw)
To: David H. Lynch Jr.; +Cc: linuxppc-dev
In-Reply-To: <4A0A6495.2050605@dlasys.net>
On Wed, May 13, 2009 at 02:11:33AM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> > On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
> >
> >> Another possibility is to pad the DTB with a DESYNC command and the
> >> correct pad frame, just in case it cannot be prevented.
> >>
> >
> > Um.. one thing I'm missing in this discussion of attaching the dtb to
> > the bitstream: I don't see how the bitstream becomes accessible to
> > the kernel at runtime. Unless you were exposing the dtb as part of
> > the fpga programming, but I thought you explicitly weren't doing that
> > because of limited bram space.
> >
> > I imagine this is simply due to my ignorance about FPGA techniques,
> > but if someone could enlighten me...?
> >
> While I am not sure I grasp all of the nuances why, this is NOT the
> scheme Stephen recomends.
> But it looks to be the most promising for me at Pico.
>
> In my instance, the FPGA code is typically in NOR Flash - actually
> several different FPGA bitstreams might be in Flash.
> The mechanism that we use to load the FPGA ensures that I can know
> the Flash File that was used to program the FPGA.
> That means that my monitor an read that file and extract the device
> tree.
> The remainder is a discussion of how to concatenate the dtb and the
> bit stream together, the pros/cons of prepending vs. appending,
> and work arrounds for issues.
> The critical factor is that the nature of the FPGA load process
> makes it possible to put data at the front or rear and assure that it
> gets ignored.
Ok. If you have NOR flash, why couldn't you just put the dtb in a
separate partition of the NOR?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PowerPC] Next May 8 boot failure: OOPS during ibmveth moduleinit
From: Stephen Rothwell @ 2009-05-13 6:39 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev, linux-next, netdev, Jiri Pirko
In-Reply-To: <20090512174451.eeed4126.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
Hi Dave,
On Tue, 12 May 2009 17:44:51 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 12 May 2009 17:24:02 +1000
> Subject: [PATCH] net/ibmveth: fix panic in probe
>
> netdev->dev_addr changed from being an array to being a pointer, so we
> should not take its address for memcpy().
I have applied this to linux-next until you decide what to do with it.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash, size
From: Heiko Schocher @ 2009-05-13 6:27 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <mailman.7754.1242158509.26545.linuxppc-dev@ozlabs.org>
Hello Wolfgang,
> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
Wouldn;t it be better, if u-boot fixes the device tree entries?
I think, u-boot should know, where the flash begins and ends, and
because this is maybe a dynamic variable for this board, it should
be better, if u-boot fixes this, so no need for adding a device tree
for every board variant.
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* RE: device trees.
From: Stephen Neuendorffer @ 2009-05-13 6:58 UTC (permalink / raw)
To: David H. Lynch Jr., grant.likely, linuxppc-dev
In-Reply-To: <4A0A6495.2050605@dlasys.net>
[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]
>> Um.. one thing I'm missing in this discussion of attaching the dtb to
>> the bitstream: I don't see how the bitstream becomes accessible to
>> the kernel at runtime. Unless you were exposing the dtb as part of
>> the fpga programming, but I thought you explicitly weren't doing that
>> because of limited bram space.
> While I am not sure I grasp all of the nuances why, this is NOT the
>scheme Stephen recomends.
> But it looks to be the most promising for me at Pico.
There is not a general way to pass additional information which does not program configuration bits of the FPGA through
the configuration interface. There is a mechanism to do this in Virtex 4 and Virtex 5, but there is no
such mechanism for Spartan 3. The best option that works for all Xilinx FPGAs is to use the initial state of a
BRAM memory block to contain the .dtb, which can then be scavenged and reused in the system, if necessary, although this
can impact overall system design.
David specifically asked for a mechanism which:
1) works on Spartan 3, in addition to V4 and V5.
2) does not require reserving an initialized BRAM, since BRAM information is very expensive in his system.
The solution is highly specific to the configuration mechanism that David's company uses in their systems, and is not generally applicable
to all board designs.
The main point of all of this is to avoid separating the bitstream from the corresponding .dtb, in order to
avoid consistency issues. Essentially, the bitstream describes itself using a .dtb.
Steve
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 2530 bytes --]
^ permalink raw reply
* [PATCH][POWERPC] mpc83xx : allow SPI without cs.
From: Rini van Zetten @ 2009-05-13 7:50 UTC (permalink / raw)
To: galak, spi-devel-general, Linuxppc-dev
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = <&pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
&pio2 2 0>; /* cs2 */
Signed-off-by: Rini van Zetten <rini@arvoo.nl>
---
drivers/spi/spi_mpc83xx.c | 44 +++++++++++++++++++++++---------------------
1 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index f4573a9..d06027e 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -687,9 +687,10 @@ static void mpc83xx_spi_cs_control(struct spi_device *spi, bool on)
struct mpc83xx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
u16 cs = spi->chip_select;
int gpio = pinfo->gpios[cs];
- bool alow = pinfo->alow_flags[cs];
-
- gpio_set_value(gpio, on ^ alow);
+ if ( gpio != -EEXIST ) {
+ bool alow = pinfo->alow_flags[cs];
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc83xx_spi_get_chipselects(struct device *dev)
@@ -728,27 +729,28 @@ static int of_mpc83xx_spi_get_chipselects(struct device *dev)
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, &flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
+ goto err_loop;
+ }
+ pinfo->gpios[i] = gpio;
+ pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo->gpios[i],
+ pinfo->alow_flags[i]);
+ if (ret) {
+ dev_err(dev, "can't set output direction for gpio "
+ "#%d: %d\n", i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo->gpios[i] = -EEXIST;
+ } else {
dev_err(dev, "invalid gpio #%d: %d\n", i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
- goto err_loop;
- }
-
- pinfo->gpios[i] = gpio;
- pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
- if (ret) {
- dev_err(dev, "can't set output direction for gpio "
- "#%d: %d\n", i, ret);
- goto err_loop;
- }
}
pdata->max_chipselect = ngpios;
--
^ permalink raw reply related
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 8:34 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Steven Rostedt, David Miller,
linuxppc-dev, paulus, Ingo Molnar, Thomas Gleixner
In-Reply-To: <4A09933B.8010606@nortel.com>
"Chris Friesen" <cfriesen@nortel.com> writes:
>
> One of the reasons I brought up this issue is that there is a lot of
> documentation out there that says "softirqs will be processed on return
> from a syscall". The fact that it actually depends on the scheduler
> parameters of the task issuing the syscall isn't ever mentioned.
It's not mentioned because it is not currently.
However some network TCP RX processing can happen in process context,
which gives you most of the benefit anyways.
> In fact, "Documentation/DocBook/kernel-hacking.tmpl" in the kernel
> source still has the following:
>
> Whenever a system call is about to return to userspace, or a
> hardware interrupt handler exits, any 'software interrupts'
> which are marked pending (usually by hardware interrupts) are
> run (<filename>kernel/softirq.c</filename>).
>
> If anyone is looking at changing this code, it might be good to ensure
> that at least the kernel docs are updated.
So far the code is not changed in mainline. There have been some
proposals only.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH 06/12] mpc5121: Added NAND Flash Controller driver.
From: Piotr Zięcik @ 2009-05-13 8:41 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev, linux-mtd, Wolfgang Denk
In-Reply-To: <4b73d43f0905072030n1b014dafmea840387ab0f3a6d@mail.gmail.com>
=46riday 08 May 2009 05:30:15 John Rigby napisa=B3(a):
> Did you choose to not support hardware ECC so you could use the spare are=
a?
> The original driver only supported hardware ECC but unfortuneatly the
> hardware ECC includes the spare area so the spare area cannot be written
> separately.
In short yes. There are fundamental problems which you described. Flash=20
filesystems expect that ECC is calculated from main area only and writes to=
=20
spare area not change it. MPC5121 NAND flash controller calculates ECC from=
=20
both areas except few bytes holding ECC. This makes flash filesystems=20
unusable when we turn on hardware ECC.
This could be fixed by disabling spare area usage in flash filesystems but
this probably requires changes in the MTD/filesystem infrastructure.
=2D-=20
Best Regards.
Piotr Zi=EAcik
^ permalink raw reply
* Re: [PATCH] leds: Add options to have GPIO LEDs start on or keep their state
From: Wolfram Sang @ 2009-05-13 9:13 UTC (permalink / raw)
To: Trent Piepho; +Cc: linuxppc-dev, Richard Purdie, Sean MacLennan
In-Reply-To: <1242167592-14649-1-git-send-email-xyzzy@speakeasy.org>
[-- Attachment #1: Type: text/plain, Size: 899 bytes --]
Hello Trent,
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 376fe07..66e7d75 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -141,9 +141,14 @@ struct gpio_led {
> const char *name;
> const char *default_trigger;
> unsigned gpio;
> - u8 active_low : 1;
> - u8 retain_state_suspended : 1;
> + unsigned active_low : 1;
> + unsigned retain_state_suspended : 1;
> + unsigned default_state : 2;
> + /* default_state should be one of LEDS_GPIO_DEFSTATE_(ON|OFF|KEEP) */
Any specific reason for the change from u8 to unsigned? Could be
mentioned in the patch description maybe. And what Sean mentioned :)
Other than that:
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] [PowerPC] MPC8272ADS: fix device tree for 8 MB flash size
From: Li Yang @ 2009-05-13 10:28 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <1242155174-2513-1-git-send-email-wd@denx.de>
On Wed, May 13, 2009 at 3:06 AM, Wolfgang Denk <wd@denx.de> wrote:
> The current device tree for the MPC8272ADS assumes a mapping of 32 MB
> of NOR flash at 0xFE00.0000, while there are actually only 8 MB on
> the boards, mapped at 0xFF80.0000. When booting an uImage with such a
> device tree, the kernel crashes because 0xFE00.0000 is not mapped.
>
> Also introduce aliases for serial[01] and ethernet[01].
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Scott Wood <scottwood@freescale.com>
> cc: Kumar Gala <galak@kernel.crashing.org>
> ---
> I am not really sure what the typical flash size on MPC8272ADS boards
> is. The board I used for testing is marked as "Prototype", so it may
> not be the release configuration. On the other hand, the manual also
> says 8 MB, Vitaly Borduk confirms 8 MB on his board, too, and Scott
> Wood eventually tested only with cuImage which fixes up the localbus
> mappings, thus eventually concealing the issue.
The latest reference board I got also has an 8MB SIMM flash module
shipped in the box.
>
> I'm posting this as reference in case the 8 MB should turn out to be
> correct. -- wd
Although 8MB seems to be the common size used. It can be very easy
changed as a pluggable module. It might be better to make the code
working for any reasonable flash sizes.
- Leo
^ permalink raw reply
* Re: RapidIO - general questions
From: Li Yang @ 2009-05-13 10:57 UTC (permalink / raw)
To: Jan Neskudla; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1242119872.16400.113.camel@demuxf9c>
cc'ed LKML
On Tue, May 12, 2009 at 5:17 PM, Jan Neskudla <jan.neskudla.ext@nsn.com> wr=
ote:
> Hallo
>
> we'd likes to use a RapidIO as a general communication bus on our new
> product, and so I have some questions about general design of Linux RIO
> subsystem. I did not find any better mailing list for RapidIO
> discussion.
>
> [1] - we'd like to implement following features
> =C2=A0 =C2=A0* Hot-plug (hot-insert/hot-remove) of devices
> =C2=A0 =C2=A0* Error handling (port-write packets - configuration, handli=
ng of
> them)
> =C2=A0 =C2=A0* Static ID configuration based on port numbers
> =C2=A0 =C2=A0* Aux driver - basic driver, for sending messages over diffe=
rent
> mboxes, handling ranges of doorbells
>
> =C2=A0 =C2=A0Is it here anyone who is working on any improvement, or anyo=
ne who
> knows the development plans for RapidIO subsystem?
>
AFAIK, there is no one currently working on these features for Linux.
It will be good if you can add these useful features.
> [2] - I have a following problem with a current implementation of
> loading drivers. The driver probe-function call is based on comparison
> of VendorID (VID) and DeviceID (DID) only. Thus if I have 3 devices with
> same DID and VID connected to the same network (bus), the driver is
> loaded 3times, instead only once for the actual device Master port.
This should be the correct way as you actually have 3 instances of the devi=
ce.
>
> Rionet driver solved this by enabling to call initialization function
> just once, and it expect that this is the Master port.
Rionet is kind of special. It's not working like a simple device
driver, but more like a customized protocol stack to support multiple
ethernet over rio links.
>
> Is it this correct behavior =C2=A0? It looks to me that RapidIO is handle=
d
> like a local bus (like PCI)
This is correct behavior. All of them are using Linux device/driver
infrastructure, but rionet is a special device.
- Leo
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 13:23 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Steven Rostedt, David Miller,
linuxppc-dev, paulus, Ingo Molnar, Thomas Gleixner
In-Reply-To: <874ovpmmdq.fsf@basil.nowhere.org>
Andi Kleen wrote:
> "Chris Friesen" <cfriesen@nortel.com> writes:
>
>>One of the reasons I brought up this issue is that there is a lot of
>>documentation out there that says "softirqs will be processed on return
>>from a syscall". The fact that it actually depends on the scheduler
>>parameters of the task issuing the syscall isn't ever mentioned.
> It's not mentioned because it is not currently.
Paul Mackerras explained the current behaviour earlier in the thread
(when it was still on the ppc list). His explanation agrees with my
exporation of the code.
"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 current task is of higher priority, ksoftirqd doesn't get a
chance to run and we don't process softirqs on return from a syscall.
Chris
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 14:15 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Steven Rostedt, David Miller,
linuxppc-dev, Andi Kleen, paulus, Ingo Molnar, Thomas Gleixner
In-Reply-To: <4A0AC9EC.6070908@nortel.com>
> "If a soft irq is raised in process context, raise_softirq() in
> kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
softirqd is only used when the softirq runs for too long or when
there are no suitable irq exits for a long time.
In normal situations (not excessive time in softirq) they don't
do anything.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 14:24 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter Zijlstra, netdev, Steven Rostedt, linuxppc-dev, paulus,
Ingo Molnar, David Miller
In-Reply-To: <alpine.LFD.2.00.0905131612180.3561@localhost.localdomain>
Thomas Gleixner <tglx@linutronix.de> writes:
> Err, no. Chris is completely correct:
>
> if (!in_interrupt())
> wakeup_softirqd();
Yes you have to wake it up just in case, but it doesn't normally
process the data because a normal softirq comes in faster. It's
just a safety policy.
You can check this by checking the accumulated CPU time on your
ksoftirqs. Mine are all 0 even on long running systems.
The reason Andrea originally added the softirqds was just that
if you have very softirq intensive workloads they would tie
up too much CPU time or not make enough process with the default
"don't loop too often" heuristics.
> We can not rely on irqs coming in when the softirq is raised from
You can't rely on it, but it happens in near all cases.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Thomas Gleixner @ 2009-05-13 14:17 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Steven Rostedt, linuxppc-dev, paulus,
Ingo Molnar, David Miller
In-Reply-To: <20090513141532.GT19296@one.firstfloor.org>
On Wed, 13 May 2009, Andi Kleen wrote:
> > "If a soft irq is raised in process context, raise_softirq() in
> > kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
>
> softirqd is only used when the softirq runs for too long or when
> there are no suitable irq exits for a long time.
>
> In normal situations (not excessive time in softirq) they don't
> do anything.
Err, no. Chris is completely correct:
if (!in_interrupt())
wakeup_softirqd();
We can not rely on irqs coming in when the softirq is raised from
thread context. An irq_exit might be faster to process it than the
scheduler can schedule ksoftirqd in, but ksoftirqd is woken and runs
nevertheless. If it finds a softirq pending then it processes them in
it's context and irq_exit calls to softirq are returning right away.
Thanks,
tglx
^ permalink raw reply
* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 15:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: Peter Zijlstra, linuxppc-dev, netdev, Steven Rostedt,
David Miller, Andi Kleen, paulus, Thomas Gleixner, Ingo Molnar
In-Reply-To: <4A0ADF34.2040001@cosmosbay.com>
> I have one machine SMP flooded by network frames, CPU0 handling all
Yes that's the case softirqd is supposed to handle. When you
spend a significant part of your CPU time in softirq context it kicks
in to provide somewhat fair additional CPU time.
But most systems (like mine) don't do that.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Eric Dumazet @ 2009-05-13 14:54 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, linuxppc-dev, netdev, Ingo Molnar, Steven Rostedt,
paulus, Thomas Gleixner, David Miller
In-Reply-To: <87my9hkrmw.fsf@basil.nowhere.org>
Andi Kleen a =E9crit :
> Thomas Gleixner <tglx@linutronix.de> writes:
>=20
>=20
>> Err, no. Chris is completely correct:
>>
>> if (!in_interrupt())
>> wakeup_softirqd();
>=20
> Yes you have to wake it up just in case, but it doesn't normally
> process the data because a normal softirq comes in faster. It's
> just a safety policy.=20
>=20
> You can check this by checking the accumulated CPU time on your
> ksoftirqs. Mine are all 0 even on long running systems.
>=20
Then its a bug Andi. Its quite easy to trigger ksoftirqd with a Gb ethern=
et link.
commit f5f293a4e3d0a0c52cec31de6762c95050156516 corrected something
(making mpstat and top correctly display softirq on cpu stats),
but apparently we still have a problem to report correct time on processe=
s,
particularly on ksoftirq/x
I have one machine SMP flooded by network frames, CPU0 handling all
the work, inside ksoftirq/0 (napi processing : almost no more hard interr=
upts delivered)
Still, top or ps reports no more than 30% of cpu time used by
ksoftirqd, while this cpu only runs ksoftirqd/0 (100% in sirq), and has n=
o idle time.
$ps -fp 4 ; mpstat -P 0 1 10 ; ps -fp 4
UID PID PPID C STIME TTY TIME CMD
root 4 2 1 15:35 ? 00:00:46 [ksoftirqd/0]
Linux 2.6.30-rc5-tip-01595-g6f75dad-dirty (svivoipvnx001) 05/13/200=
9 _i686_
04:45:01 PM CPU %usr %nice %sys %iowait %irq %soft %steal =
%guest %idle
04:45:02 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:03 PM 0 0.00 0.00 0.00 0.00 0.00 99.01 0.00 =
0.00 0.99
04:45:04 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:05 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:06 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:07 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:08 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:09 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:10 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
04:45:11 PM 0 0.00 0.00 0.00 0.00 0.00 100.00 0.00 =
0.00 0.00
Average: 0 0.00 0.00 0.00 0.00 0.00 99.90 0.00 =
0.00 0.10
UID PID PPID C STIME TTY TIME CMD
root 4 2 1 15:35 ? 00:00:49 [ksoftirqd/0]
You can see here time consumed by ksoftirqd/0 suring this 10 seconds time=
frame is *only* 3 seconds.
Therefore, we cannot trust ps, not with current kernel.
# cat /proc/4/stat ; sleep 10 ; cat /proc/4/stat
4 (ksoftirqd/0) R 2 0 0 0 -1 2216730688 0 0 0 0 0 15347 0 0 15 -5 1 0 6 0=
0 4294967295 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0
4 (ksoftirqd/0) R 2 0 0 0 -1 2216730688 0 0 0 0 0 15670 0 0 15 -5 1 0 6 0=
0 4294967295 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 0 0 0 0 0 0
> The reason Andrea originally added the softirqds was just that
> if you have very softirq intensive workloads they would tie
> up too much CPU time or not make enough process with the default
> "don't loop too often" heuristics.=20
>=20
>> We can not rely on irqs coming in when the softirq is raised from
>=20
> You can't rely on it, but it happens in near all cases.
>=20
> -Andi
^ permalink raw reply
* removing pcibios_fixup_bus
From: Kumar Gala @ 2009-05-13 15:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linuxppc-dev Development
Ben,
We have:
/* Platform specific bus fixups. This is currently only used
* by fsl_pci and I'm hoping to get rid of it at some point
*/
if (ppc_md.pcibios_fixup_bus)
ppc_md.pcibios_fixup_bus(bus);
I can remove this but would need to replace it with:
if (bus->self != NULL) {
pci_read_bridge_bases(bus);
if (ppc_md.pcibios_fixup_bridge_resources)
ppc_md.pcibios_fixup_bridge_resources(bus);
}
This is only moving the issue, but its a bit cleaner as the fixup I'm
doing is because when we read the BARs on the virtual P2P bridge on
our PCIe PHBs we get bogus values back.
Thoughts?
- k
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 15:05 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
paulus, Thomas Gleixner, David Miller
In-Reply-To: <87my9hkrmw.fsf@basil.nowhere.org>
Andi Kleen wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
>>Err, no. Chris is completely correct:
>>
>> if (!in_interrupt())
>> wakeup_softirqd();
>
> Yes you have to wake it up just in case, but it doesn't normally
> process the data because a normal softirq comes in faster. It's
> just a safety policy.
What about the scenario I raised earlier, where we have incoming network
packets, no hardware interrupts coming in other than the timer tick, and
a high-priority userspace app is spinning on recvmsg() with MSG_DONTWAIT
set?
As far as I can tell, in this scenario softirqs may not get processed on
return from a syscall (contradicting the documentation). In the worst
case, they may not get processed until the next timer tick.
Chris
^ permalink raw reply
* Re: question about softirqs
From: Thomas Gleixner @ 2009-05-13 15:54 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Steven Rostedt, linuxppc-dev, Andi Kleen,
paulus, Ingo Molnar, David Miller
In-Reply-To: <4A0AE19D.9040509@nortel.com>
On Wed, 13 May 2009, Chris Friesen wrote:
> Andi Kleen wrote:
> > Thomas Gleixner <tglx@linutronix.de> writes:
>
> >>Err, no. Chris is completely correct:
> >>
> >> if (!in_interrupt())
> >> wakeup_softirqd();
> >
> > Yes you have to wake it up just in case, but it doesn't normally
> > process the data because a normal softirq comes in faster. It's
> > just a safety policy.
>
> What about the scenario I raised earlier, where we have incoming network
> packets, no hardware interrupts coming in other than the timer tick, and
> a high-priority userspace app is spinning on recvmsg() with MSG_DONTWAIT
> set?
>
> As far as I can tell, in this scenario softirqs may not get processed on
> return from a syscall (contradicting the documentation). In the worst
> case, they may not get processed until the next timer tick.
Right because your high prio tasks prevents that ksoftirqd runs,
because it can not preempt the high priority task.
Thanks,
tglx
^ permalink raw reply
* [PATCH 3/3] powerpc/spufs: remove double check for non-negative dentry
From: Arnd Bergmann @ 2009-05-13 15:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Jan Blunck, Jeremy Kerr
From: Jan Blunck <jblunck@suse.de>
This patch removes an unnecessary double check if the dentry returned by
lookup_create() is actually non-negative. Since lookup_create() itself returns
an error in this case just remove the check.
Signed-off-by: Jan Blunck <jblunck@suse.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/spufs/inode.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index 706eb5c..36b6700 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -631,10 +631,6 @@ long spufs_create(struct nameidata *nd, unsigned int flags, mode_t mode,
if (IS_ERR(dentry))
goto out_dir;
- ret = -EEXIST;
- if (dentry->d_inode)
- goto out_dput;
-
mode &= ~current_umask();
if (flags & SPU_CREATE_GANG)
--
1.5.6.3
^ permalink raw reply related
* [PATCH 1/3] powerpc/cell: make ptcal more reliable
From: Arnd Bergmann @ 2009-05-13 15:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Gerhard Stenzel, linuxppc-dev, Jeremy Kerr
From: Gerhard Stenzel <stenzel@de.ibm.com>
There have been a series of checkstops on QS21 related to
ptcal being set up incorrectly. On systems that only
have memory on a single node, ptcal fails when it gets
a pointer to memory on the remote node.
Moreover, agressive prefetching in memcpy and other
functions may accidentally touch the first cache line
of the page that we reserve for ptcal, which causes
an ECC checkstop.
We now allocate pages only from the specified node, moves the
ptcal area into the middle of the allocated page to avoid
potential prefetch problems and prints the address of the
ptcal area to facilitate diagnostics.
Signed-off-by: Gerhard Stenzel <gerhard.stenzel@de.ibm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/powerpc/platforms/cell/ras.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/ras.c b/arch/powerpc/platforms/cell/ras.c
index 5f961c4..296b526 100644
--- a/arch/powerpc/platforms/cell/ras.c
+++ b/arch/powerpc/platforms/cell/ras.c
@@ -122,12 +122,23 @@ static int __init cbe_ptcal_enable_on_node(int nid, int order)
area->nid = nid;
area->order = order;
- area->pages = alloc_pages_node(area->nid, GFP_KERNEL, area->order);
+ area->pages = alloc_pages_node(area->nid, GFP_KERNEL | GFP_THISNODE,
+ area->order);
- if (!area->pages)
+ if (!area->pages) {
+ printk(KERN_WARNING "%s: no page on node %d\n",
+ __func__, area->nid);
goto out_free_area;
+ }
- addr = __pa(page_address(area->pages));
+ /*
+ * We move the ptcal area to the middle of the allocated
+ * page, in order to avoid prefetches in memcpy and similar
+ * functions stepping on it.
+ */
+ addr = __pa(page_address(area->pages)) + (PAGE_SIZE >> 1);
+ printk(KERN_DEBUG "%s: enabling PTCAL on node %d address=0x%016lx\n",
+ __func__, area->nid, addr);
ret = -EIO;
if (rtas_call(ptcal_start_tok, 3, 1, NULL, area->nid,
--
1.5.6.3
^ permalink raw reply related
* Please pull next branch of cell.git
From: Arnd Bergmann @ 2009-05-13 16:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben,
I have three small fixes for Cell that I'd like you to
add to your powerpc tree.
git pull git.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git next
The first two patches might still be good to have in 2.6.30,
the patch from Jan is just a cleanup for 2.6.31.
Thanks,
Arnd <><
---
commit 2de7d2f19196445eecc89e161a6ae0a3e3f272b9
Author: Jan Blunck <jblunck@suse.de>
powerpc/spufs: remove double check for non-negative dentry
arch/powerpc/platforms/cell/spufs/inode.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
commit f1eaf5e7b1b0c5140e4b730d81b966cd37ff2245
Author: Benjamin Krill <ben@codiert.org>
serial/nwpserial: fix wrong register read address and add interrupt acknowledge.
drivers/serial/nwpserial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
commit f0cbc66cf73524e0c97957bc909d263810c4f339
Author: Gerhard Stenzel <stenzel@de.ibm.com>
powerpc/cell: make ptcal more reliable
arch/powerpc/platforms/cell/ras.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 2/3] serial/nwpserial: fix wrong register read address and add interrupt acknowledge.
From: Arnd Bergmann @ 2009-05-13 15:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
From: Benjamin Krill <ben@codiert.org>
The receive interrupt routine checks the wrong register if the
receive fifo is empty. Further an explicit interrupt acknowledge
write is introduced. In some circumstances another interrupt was
issued.
Signed-off-by: Benjamin Krill <ben@codiert.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/serial/nwpserial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/nwpserial.c b/drivers/serial/nwpserial.c
index 32f3eaf..9e150b1 100644
--- a/drivers/serial/nwpserial.c
+++ b/drivers/serial/nwpserial.c
@@ -145,11 +145,13 @@ static irqreturn_t nwpserial_interrupt(int irq, void *dev_id)
ch = dcr_read(up->dcr_host, UART_RX);
if (up->port.ignore_status_mask != NWPSERIAL_STATUS_RXVALID)
tty_insert_flip_char(tty, ch, TTY_NORMAL);
- } while (dcr_read(up->dcr_host, UART_RX) & UART_LSR_DR);
+ } while (dcr_read(up->dcr_host, UART_LSR) & UART_LSR_DR);
tty_flip_buffer_push(tty);
ret = IRQ_HANDLED;
+ /* clear interrupt */
+ dcr_write(up->dcr_host, UART_IIR, 1);
out:
spin_unlock(&up->port.lock);
return ret;
--
1.5.6.3
^ permalink raw reply related
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 16:10 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter Zijlstra, netdev, Steven Rostedt, linuxppc-dev, Andi Kleen,
paulus, Ingo Molnar, David Miller
In-Reply-To: <alpine.LFD.2.00.0905131751150.3561@localhost.localdomain>
Thomas Gleixner wrote:
> On Wed, 13 May 2009, Chris Friesen wrote:
>> As far as I can tell, in this scenario softirqs may not get processed on
>> return from a syscall (contradicting the documentation). In the worst
>> case, they may not get processed until the next timer tick.
>
> Right because your high prio tasks prevents that ksoftirqd runs,
> because it can not preempt the high priority task.
Exactly.
I'm suggesting that this point (the idea that softirqs may or may not
get processed on return from syscall depending on relative task
priority) should probably be documented somewhere, because the current
documentation (in the kernel and on the web) doesn't mention it at all.
Maybe I should just submit a patch to
Documentation/DocBook/kernel-hacking.tmpl.
Chris
^ 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