* Re: question about softirqs
From: Andi Kleen @ 2009-05-13 19:13 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
Andi Kleen, paulus, Thomas Gleixner, David Miller
In-Reply-To: <4A0B19A9.1090206@nortel.com>
On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
>
> > network packets are normally processed by the network packet interrupt's
> > softirq or alternatively in the NAPI poll loop.
>
> If we have a high priority task, ksoftirqd may not get a chance to run.
In this case the next interrupt will also process them. It will just
go more slowly because interrupts limit the work compared to ksoftirqd.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: question about softirqs
From: Chris Friesen @ 2009-05-13 19:04 UTC (permalink / raw)
To: Andi Kleen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
paulus, Thomas Gleixner, David Miller
In-Reply-To: <20090513170122.GZ19296@one.firstfloor.org>
Andi Kleen wrote:
> network packets are normally processed by the network packet interrupt's
> softirq or alternatively in the NAPI poll loop.
If we have a high priority task, ksoftirqd may not get a chance to run.
My point is simply that the documentation says that softirqs are
processed on return from a syscall, and this is not necessarily the case.
Chris
^ permalink raw reply
* Re: [PATCH] leds: Add options to have GPIO LEDs start on or keep their state
From: Trent Piepho @ 2009-05-13 18:54 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Richard Purdie, Sean MacLennan
In-Reply-To: <20090513091330.GA3078@pengutronix.de>
On Wed, 13 May 2009, Wolfram Sang wrote:
> > 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 :)
I should have mentioned that in the description. It didn't make sense to
me to declare a bit field with u8. An eight bit type that is one bit
wide? The field width overrides the type width, but I think it's better to
just use "unsigned" and only specify a width once.
>
> Other than that:
>
> Acked-by: Wolfram Sang <w.sang@pengutronix.de>
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
^ permalink raw reply
* Re: Delay on intialization ide subsystem(most likely)
From: Bartlomiej Zolnierkiewicz @ 2009-05-13 18:46 UTC (permalink / raw)
To: Andrey Gusev; +Cc: linux-ide, petkovbb, linuxppc-dev
In-Reply-To: <20090513211123.24825895@power-debian>
On Wednesday 13 May 2009 19:11:23 Andrey Gusev wrote:
> On Wed, 13 May 2009 15:28:26 +0200
> Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> > On Tuesday 12 May 2009 21:50:24 Andrey Gusev wrote:
> > > On Mon, 27 Apr 2009 23:21:48 +0200
> > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > >
> > > > On Monday 27 April 2009 22:36:45 Andrey Gusev wrote:
> > > > > On Sat, 25 Apr 2009 16:48:38 +0200
> > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Saturday 25 April 2009 15:02:03 Andrey Gusev wrote:
> > > > > > > Hello!
> > > > > > >
> > > > > > > I have tested linux-2.6.30-rc3 on my system and find some
> > > > > > > problems. One of them is delaying on initialization IDE
> > > > > > > subsystem. I don't have this problem on 2.6.29.1. The
> > > > > > > difference is looked on log of dmesg.
> > > > > >
> > > > > > Unfortunately this doesn't give us any hint about the root
> > > > > > cause of the bug so please try narrowing the problem down to
> > > > > > the specific change using git-bisect (sorry, there were 212
> > > > > > drivers/ide/ commits during v2.6.29..v2.6.30-rc3 and much much
> > > > > > more non-drivers/ide/ ones).
> > > > > >
> > > > > > Thanks,
> > > > > > Bart
> > > > > >
> > > > >
> > > > > Hello!
> > > > >
> > > > >
> > > > > The full result of bisect is:
> > > > >
> > > > >
> > > > > git bisect start
> > > > > # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
> > > > > git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
> > > > > # bad: [091069740304c979f957ceacec39c461d0192158] Linux
> > > > > 2.6.30-rc3 git bisect bad
> > > > > 091069740304c979f957ceacec39c461d0192158 # good:
> > > > > [40f07111be99b71c1e8d40c13cdc38445add787f] V4L/DVB (11166):
> > > > > pvrusb2: Implement status fetching from sub-devices git bisect
> > > > > good 40f07111be99b71c1e8d40c13cdc38445add787f # good:
> > > > > [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg:
> > > > > slicoss: Specify the license for Sahara SXG and Slicoss drivers
> > > > > git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8
> > > > >
> > > > >
> > > > > git bisect start 'drivers/ide/'
> > > >
> > > > Please note that limiting search space to drivers/ide/ may not
> > > > give reliable results in case problem was introduced by some
> > > > other kernel area.
> > > >
> > > > > # good: [ba0e1ebb7ea0616eebc29d2077355bacea62a9d8] Staging: sxg:
> > > > > slicoss: Specify the license for Sahara SXG and Slicoss drivers
> > > > > git bisect good ba0e1ebb7ea0616eebc29d2077355bacea62a9d8 # bad:
> > > > > [091069740304c979f957ceacec39c461d0192158] Linux 2.6.30-rc3 git
> > > > > bisect bad 091069740304c979f957ceacec39c461d0192158 # good:
> > > > > [e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d] ide-cd: convert
> > > > > cdrom_decode_status() to use switch statements git bisect good
> > > > > e01f251fd09fa7cb3d352eac7de17bb5d5bd1f9d # good:
> > > > > [3153c26b54230d025c6d536e8d3015def4524906] ide: refactor
> > > > > tf_read() method git bisect good
> > > > > 3153c26b54230d025c6d536e8d3015def4524906 # good:
> > > > > [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix HPT370
> > > > > DMA timeouts git bisect good
> > > > > c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac # bad:
> > > > > [d5f840bf74c09ca5a31e518c9d984999926b5f44] ide: Remove void
> > > > > casts git bisect bad d5f840bf74c09ca5a31e518c9d984999926b5f44 #
> > > > > bad: [59c8d04f5ee97ea46da854e9adbbaa45d988c39d] hpt366: use
> > > > > ATA_DMA_* constants git bisect bad
> > > > > 59c8d04f5ee97ea46da854e9adbbaa45d988c39d
> > > >
> > > > Uhh.. something went wrong during bisect.
> > > >
> > > > "hpt366: use ATA_DMA_* constants" cannot be a first bad commit
> > > > because hpt366 is not even used on this system.
> > > >
> > > > Could it be that the delay doesn't happen on every boot for "bad"
> > > > kernels?
> > > >
> > > > Also, is 2.6.30-rc1 okay?
> > > >
> > > > Thanks,
> > > > Bart
> > > >
> > >
> > > Hello all!
> > >
> > > I continue to find reason of bug. I made more testing with bisect
> > > and got result:
> > >
> > > git bisect start
> > > # bad: [c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac] hpt366: fix
> > > HPT370 DMA timeouts git bisect bad
> > > # good:
> > > [fb4252e59452c18b88af014a2c4ee697bbf8cbc6] at91_ide: turn on PIO 6
> > > support git bisect good fb4252e59452c18b88af014a2c4ee697bbf8cbc6 #
> > > good: [2e1c63b7ed36532b68f0eddd6a184d7ba1013b89] Merge branch
> > > 'for-rc1/xen/core' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen git bisect
> > > good 2e1c63b7ed36532b68f0eddd6a184d7ba1013b89 # bad:
> > > [cd97824994042b809493807ea644ba26c0c23290] Merge
> > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 git
> > > bisect bad cd97824994042b809493807ea644ba26c0c23290 # bad:
> > > [a2c252ebdeaab28c9b400570594d576dae295958] Merge
> > > git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes
> > > git bisect bad a2c252ebdeaab28c9b400570594d576dae295958 # good:
> > > [b897e6fbc49dd84b2634bca664344d503b907ce9] Merge branch
> > > 'drm-intel-next' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel git
> > > bisect good b897e6fbc49dd84b2634bca664344d503b907ce9 # good:
> > > [dfbc4752eab33e66f113f9daa2effbe241cd661d] brd: support barriers
> > > git bisect good dfbc4752eab33e66f113f9daa2effbe241cd661d # good:
> > > [a23c218bd36e11120daf18e00a91d5dc20e288e6] Merge branch 'merge' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc git
> > > bisect good a23c218bd36e11120daf18e00a91d5dc20e288e6 # good:
> > > [23da64b4714812b66ecf010e7dfb3ed1bf2eda69] Merge branch 'for-linus'
> > > of git://git.kernel.dk/linux-2.6-block git bisect good
> > > 23da64b4714812b66ecf010e7dfb3ed1bf2eda69 # good:
> > > [a228df6339e0d385b8149c860d81b6007f5e9c81] GFS2: Move umount flush
> > > rwsem git bisect good a228df6339e0d385b8149c860d81b6007f5e9c81 #
> > > skip: [1328df725239804ae30fc7257c1a3185e679b517] GFS2: Use
> > > DEFINE_SPINLOCK git bisect skip
> > > 1328df725239804ae30fc7257c1a3185e679b517 # good:
> > > [10d2198805d7faa2b193485446ff6b1de42c9b78] GFS2: cleanup
> > > file_operations mess git bisect good
> > > 10d2198805d7faa2b193485446ff6b1de42c9b78
> > >
> > > As I understand, I found bad commit, but it includes 5 commits. I
> > > checked them and they are good. So, I did git checkout
> > > a2c252ebdeaab28c9b400570594d576dae295958 and test one more time
> > > this commit. I found that bag is unstable. The boot can be bad or
> > > good on this commit. I compared dmesg of 'bad' and 'good' booting,
> > > but it is equal till delay.
> >
> > Thanks for doing it.
> >
> > > Any suggestions?
> >
> > Hard to tell...
> >
> > I went through all commits in-between
> >
> > fb4252e59452c18b88af014a2c4ee697bbf8cbc6
> >
> > and
> >
> > a2c252ebdeaab28c9b400570594d576dae295958
> >
> > and there are no obvious candidates..
> >
> > Could you please refresh my memory and tell me whether 2.6.30-rc2 was
> > OK?
> >
>
> It was ok, but I don't sure now. I tested only one boot, but this problem is not
> stable. I am rechecking it.
Ok.
Please also recheck first 'good' commit if 2.6.30-rc2 turns out to be 'bad'.
[ BTW the above bisection points that the problem was introduced outside of
drivers/ide or that it was introduced earlier that we'd initially thought ]
> I have added second hard drive and got new issue. May be this log (dmesg) can
> tell you something. It is on first known 'bad commit'. 2.6.29.2 can't properly
It tells us that there is some IRQ routing problem... seems like a platform
or ide-pmac specific problem. Does some earlier kernel work OK with this
configuration?
> initialize it too (got lost interrupt and disable dma).
>
> [ 1.113901] Uniform Multi-Platform E-IDE driver
> [ 1.120304] ide-pmac 0002:20:0d.0: enabling device (0000 -> 0002)
> [ 1.123139] adb: starting probe task...
> [ 1.125609] adb: finished probe task...
> [ 2.147653] ide-pmac: Found Apple UniNorth ATA-6 controller (PCI), bus ID 3, irq 39
> [ 2.152331] Probing IDE interface ide0...
> [ 2.457825] hda: IBM-IC35L060AVVA07-0, ATA DISK drive
> [ 2.817641] hdb: QUANTUM FIREBALLP LM20.5, ATA DISK drive
> [ 66.660447] hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 66.660624] hda: UDMA/100 mode selected
> [ 66.663170] hdb: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 66.663415] hdb: UDMA/66 mode selected
> [ 66.666108] ide0 at 0xf1012000-0xf1012070,0xf1012160 on irq 39
> [ 67.697640] ide-pmac: Found Apple KeyLargo ATA-4 controller (macio), bus ID 2, irq 19
> [ 67.702368] Probing IDE interface ide1...
> [ 131.867685] ide1 at 0xf100e000-0xf100e070,0xf100e160 on irq 19
> [ 132.897559] ide-pmac: Found Apple KeyLargo ATA-3 controller (macio), bus ID 0, irq 20
> [ 132.902273] Probing IDE interface ide2...
> [ 196.898053] hde: PHILIPS CDD5101, ATAPI CD/DVD-ROM drive
> [ 260.980668] hde: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> [ 260.981049] hde: MWDMA2 mode selected
> [ 260.984269] ide2 at 0xf1016000-0xf1016070,0xf1016160 on irq 20
> [ 260.989418] ide-gd driver 1.18
> [ 260.991880] hda: max request size: 128KiB
> [ 261.039649] hda: 120103200 sectors (61492 MB) w/1863KiB Cache, CHS=65535/16/63
> [ 261.044690] hda: cache flushes supported
> [ 261.047292] hda: [mac] hda1 hda2 hda3 hda4
> [ 261.060150] hdb: max request size: 128KiB
> [ 261.089788] hdb: 40132503 sectors (20547 MB) w/1900KiB Cache, CHS=39813/16/63
> [ 261.092287] hdb: cache flushes not supported
> [ 261.094754] hdb:<3>ide-pmac lost interrupt, dma status: 8480
> [ 281.089717] hdb: lost interrupt
> [ 281.092085] hdb: dma_intr: status=0x58 { DriveReady SeekComplete DataRequest }
> [ 281.097038] ide: failed opcode was: unknown
> [ 281.101900] hda: DMA disabled
> [ 281.104247] hdb: DMA disabled
> [ 281.187260] ide0: reset: success
> [ 281.230368] hdb1 hdb2 < hdb5 hdb6 hdb7 hdb8 >
> [ 281.285486] ide-cd driver 5.00
> [ 281.297481] ide-cd: hde: ATAPI 32X DVD-ROM CD-R/RW drive, 8192kB Cache
> [ 281.299687] Uniform CD-ROM driver Revision: 3.20
^ permalink raw reply
* Re: device trees.
From: David H. Lynch Jr. @ 2009-05-13 18:11 UTC (permalink / raw)
To: David H. Lynch Jr., Stephen Neuendorffer, Grant Likely,
linuxppc-dev
In-Reply-To: <20090513062127.GU24338@yookeroo.seuss>
David Gibson wrote:
>
>
> Ok. If you have NOR flash, why couldn't you just put the dtb in a
> separate partition of the NOR?
>
>
It is not THE dtb, it is A dtb. Our systems support and typically use
multiple FPGA bit streams.
Clients are
That means each bitstream must have its own dtb, clients are
allowed/expected to create their own firmware,
but the norm is to leave the "PrimaryBoot.bit" startup bit file intact.
Clients may swap between several bit files for development purposes in
the course of a day.
It is even possible that a clients application may require swapping bit
files as part of normal operations.
I want one linux binary - because I know damn well that given two my
clients will use the wrong one alteast 30% of the time.
Somewhere arround 4 binaries that becomes almost 100% of the time.
Using dtb's to make the linux binary does NOT solve the problem it just
changes the file they have to get right.
Worse still the wrong dtb will probably mostly work. If it just failed
they would be more likely to grasp what they got wrong.
I need/want the device tree welded to the bitstream. That means creating
it dynamically or welding it to the bitstream.
Anything else wil be a support nightmare.
Though this does not impact Linux, we have clusters of FPGA's that are
used for High Performance computing,
One typical application is decryption where they work much like turing's
Bomb's at bletchley park only much faster.
Anyway in that application we load bitstreams into FPGA's exactly the
way someone would load programs into a processor.
The FPGA programming can be changed on a whim. In a cluster some
FPGA's/Processors might be executing one set of code while
others might be running different programming.
As the tools get better this is going to become even more common.
Right now this is not a linux application (linux manages the cluster),
but there is no reason you can not think of the cluster as a massive SMP
machine,
with massively parallel soft CPU's, and who knows the whole mess could
be running Linux itself.
The point I am trying to make is whatever I am doing now, things may be
totally different soon enough.
Every significant performance gain that occurs with Xilinx tools results
in a significant increase in our markets.
Hard and fast constraints guarantee problems down the line. Wasteful
choices that are easy now come back to haunt us down the line.
Standalone embedded systems are my bread and butter, but they are only
about 1/3 of our market.
Even within them 95% of our clients do not need Linux. Most do not
really need an OS at all.
Some of the time they do not even need a CPU.
We provide Linux because it makes them happy, because they are not up to
developing their own standalone programs to perform the tasks.
Still that means that Linux needs to make the task easier - not harder.
--
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: question about softirqs
From: Andi Kleen @ 2009-05-13 17:01 UTC (permalink / raw)
To: Chris Friesen
Cc: Peter Zijlstra, netdev, Ingo Molnar, Steven Rostedt, linuxppc-dev,
Andi Kleen, paulus, Thomas Gleixner, David Miller
In-Reply-To: <4A0AE19D.9040509@nortel.com>
On Wed, May 13, 2009 at 09:05:01AM -0600, 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,
network packets are normally processed by the network packet interrupt's
softirq or alternatively in the NAPI poll loop.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* 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
* [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
* 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 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
* [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
* 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
* 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
* 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: 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
* 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: 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 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: 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: 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: 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: [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: [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 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: 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
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