Expose Talitos's XOR functionality to be used for
RAID Parity calculation via the Async_tx layer.
Thanks to Surender Kumar and Lee Nipper for their help in
realising this driver
Signed-off-by: Kim Phillips
Signed-off-by: Dipen Dudhat
Signed-off-by: Maneesh Gupta
Signed-off-by: Vishnu Suresh
-
This patch disables the use of DMA_INTERRUPT capability with Async_tx
The fsldma produces a null transfer with DMA_INTERRUPT
capability when used with Async_tx. When RAID devices queue
a transaction via Async_tx, this results in a hang.
Signed-off-by: Vishnu Suresh
---
drivers/dma/fsldma.c |
Hi Linus !
A tad late due mostly to me being on vacation :-) Here's some powerpc
fixes for 2.6.32, not that much and nothing really big.
The following changes since commit 80f506918fdaaca6b574ba931536a58ce015c7be:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.dk/linux
On Thu, 2009-10-15 at 07:42 +0200, Joakim Tjernlund wrote:
> I didn't say that, did I? More like:
> if I don't do tlbil_va at all I get a lot of extra/duplicate TLB
> errors
> for the same address. Adding the patch makes these go away.
> I guess one could do tlbil_va unconditionally but I didn't
>
From: Akinobu Mita
Subject: Fix
bitmap-introduce-bitmap_set-bitmap_clear-bitmap_find_next_zero_area.patch
- Rewrite bitmap_set and bitmap_clear
Instead of setting or clearing for each bit.
- Fix off-by-one errors in bitmap_find_next_zero_area
This bug was derived from find_next_zero_area
* Andi Kleen [2009-10-14 09:18:38]:
> > How about something like this..
> > If the arch does not enable CONFIG_CPU_IDLE, the cpuidle_idle_call
> > which is called from cpu_idle() should call default_idle without
> > involving the registering cpuidle steps. This should prevent bloating
> > up of t
Hi,
In arch/powerpc/kernel/head_44x.S file, it says it clears all the TLBs
except the current working one. In our case we have mainly 3 TLBs for
FLASH, SRAM and the UART. We have the TLB of 16MB of SRAM *which is
our total memory*. So the TLBs that we create from our bootloader will
be used for th
Benjamin Herrenschmidt wrote on 15/10/2009 03:12:50:
>
> On Wed, 2009-10-14 at 18:08 -0700, Rex Feany wrote:
> > Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
> >
> > > On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> > > > The biggest problem for me turned out to be the MMU
Rex Feany wrote on 15/10/2009 03:08:55:
>
> Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
>
> > On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> > > The biggest problem for me turned out to be the MMU context IDs being
> > > clamped to 32 when the 8xx only has 16. With this, t
Hi folks !
So I have a problem ... :-)
For some weird reason, our gcc until 4.3 (fixed in 4.3) had the weird
idea that the alignment attribute should not be allowed to force an
alignment greater than 32k. If attempted, it would warn -and- crop the
alignment to 32k.
As you can imagine, this doesn
The architecture defines that if MSR PR is set we are in problem state
irrespective of the HV bit. This fixes perf events to reflect this.
Also, on bare metal systems, samples taken in Linux will now be reported
as kernel rather than hypervisor.
Signed-off-by: Michael Neuling
CC: pau...@samba
The architecture defines that if MSR PR is set we are in problem state
irrespective of the HV bit. This fixes perf events to reflect this.
Signed-off-by: Michael Neuling
CC: pau...@samba.org
---
Tested on PHYP and BML.
This could go back into 31 too with s/event/counters/g. It only
effects bar
Hi
I have a powerbook G4 which has drives connected via a cardbus sata_sil. It is
running fedora 11. It boots fine with 2.6.27.35-170.2.94.fc10.ppc, but with
2.6.30.8-64.fc11.ppc because of an error in the probe function of sata_sil.
I have traced the problem to be the line in sata_sil.c funct
On Wed, 2009-10-14 at 18:08 -0700, Rex Feany wrote:
> Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
>
> > On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> > > The biggest problem for me turned out to be the MMU context IDs being
> > > clamped to 32 when the 8xx only has 16. Wi
Thus spake Benjamin Herrenschmidt (b...@kernel.crashing.org):
> On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> > The biggest problem for me turned out to be the MMU context IDs being
> > clamped to 32 when the 8xx only has 16. With this, things are a bit more
> > stable :)
>
> This is with
On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> The biggest problem for me turned out to be the MMU context IDs being
> clamped to 32 when the 8xx only has 16. With this, things are a bit more
> stable :)
This is with Joakim patches or without ?
Ben.
> diff --git a/arch/powerpc/mm/mmu_cont
Also find all users of struct property and make sure that they include
linux/of.h.
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/of.h|7 +++
arch/powerpc/include/asm/prom.h |7 +--
arch/powerpc/kernel/machine_kexec_64.c |1 +
This creates asm/of.h for powerpc and sparc and includes it
from linux/of.h, it also moves the first trivial stuff there from
asm/prom.h
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/of.h | 23 +++
arch/powerpc/include/asm/prom.h |7 ---
arch/sparc/
Hi Grant,
On Tue, 06 Oct 2009 22:29:57 -0600 Grant Likely
wrote:
>
> Well, I've got to start somewhere...
>
> So here goes. I've begun the work to merge and clean up the OF device
> tree handling code and this is my first set of patches. Not fully
> tested yet, but I'm getting them out to the
On Wed, 2009-10-14 at 17:41 -0700, Rex Feany wrote:
> The biggest problem for me turned out to be the MMU context IDs being
> clamped to 32 when the 8xx only has 16. With this, things are a bit more
> stable :)
Ugh ? The clamp went upstream ? That sucks... let me fix that asap
Cheers,
Ben.
> dif
The biggest problem for me turned out to be the MMU context IDs being
clamped to 32 when the 8xx only has 16. With this, things are a bit more
stable :)
diff --git a/arch/powerpc/mm/mmu_context_nohash.c
b/arch/powerpc/mm/mmu_context_nohash.c
index c2f93dc..15e00c5 100644
--- a/arch/powerpc/mm/mmu
On Wed, Oct 14, 2009 at 5:51 PM, Michael Ellerman
wrote:
> On Wed, 2009-10-14 at 12:44 -0600, Grant Likely wrote:
>> Why not make sparse IRQs manditory for all platforms? Is there a
>> performance concern with doing so? From a maintenance perspective,
>> I'd rather see IRQ descs manged in one wa
On Wed, 2009-10-14 at 12:44 -0600, Grant Likely wrote:
> On Tue, Oct 13, 2009 at 11:45 PM, Michael Ellerman
> wrote:
> > Defining CONFIG_SPARSE_IRQ enables generic code that gets rid of the
> > static irq_desc array, and replaces it with an array of pointers to
> > irq_descs.
> >
> > It also allow
On Wed, 2009-10-14 at 12:59 -0600, Grant Likely wrote:
> On Tue, Oct 13, 2009 at 11:44 PM, Michael Ellerman
> wrote:
> > The irq_desc array consumes quite a lot of space, and for systems
> > that don't need or can't have 512 irqs it's just wasted space.
> >
> > The first 16 are reserved for ISA, s
On Fri, 2009-10-09 at 12:14 -0700, Hollis Blanchard wrote:
> Rusty's version of BUILD_BUG_ON() does indeed fix the build break, and
> also exposes the bug in kvmppc_account_exit_stat(). So to recap:
>
> original: built but didn't work
> Jan's: doesn't build
> Rusty's: builds and works
>
> Where d
Benjamin Herrenschmidt wrote on 14/10/2009 23:52:10:
>
> On Wed, 2009-10-14 at 23:41 +0200, Joakim Tjernlund wrote:
> > Benjamin Herrenschmidt wrote on 14/10/2009
> > 23:17:09:
> > >
> > > On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
> > > >
> > > > I think the last working version was a
From: Grant Likely
Date: Wed, 14 Oct 2009 11:43:43 -0600
> From: John Bonesio
>
> The MDIO bus cannot be accessed at interrupt context, but on an FEC
> error, the fec_mpc52xx driver reset function also tries to reset the
> PHY. Since the error is detected at IRQ context, and the PHY functions
From: Anton Vorontsov
Date: Thu, 8 Oct 2009 16:15:12 +0400
> Some OF platform drivers are missing module device tables, so they won't
> load automatically on boot. This patch fixes the issue by adding proper
> MODULE_DEVICE_TABLE() macros to the drivers.
>
> Signed-off-by: Anton Vorontsov
Appl
hvc_console_print() calls the HVC client driver's put_chars() callback
to write some characters to the console. If the callback returns 0, that
indicates that no characters were written (perhaps the output buffer is
full), but hvc_console_print() treats that as an error and discards the
rest of th
On Wed, 2009-10-14 at 23:41 +0200, Joakim Tjernlund wrote:
> Benjamin Herrenschmidt wrote on 14/10/2009
> 23:17:09:
> >
> > On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
> > >
> > > I think the last working version was a little older than that -- and it's
> > > quite
> > > possible that t
Benjamin Herrenschmidt wrote on 14/10/2009 23:17:09:
>
> On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
> >
> > I think the last working version was a little older than that -- and it's
> > quite
> > possible that there was underlying badness even earlier that just recently
> > got
> > exp
Roberto Guerra wrote:
I've been learning how to modify the dts from
http://www.mjmwired.net/kernel/Documentation/powerpc/dts-bindings/mtd-physmap.txt#49
The original mpc8272ads.dts represents four 8-bit JEDEC Sharp flash
chips in 1 SIMM module:
[snip]local...@f0010100 {
co
On Fri, Oct 9, 2009 at 2:16 PM, Scott Wood wrote:
> On Fri, Oct 09, 2009 at 01:59:58PM -0400, Roberto Guerra wrote:
>> No. I did not. My FDT was simplified from the stock MPC8272ADS:
>> => fdt list
>> / {
>> model = "pq2fads";
>> compatible = "fsl,pq2fads";
>> #address-cell
Roel Kluin writes:
> Check to prevent unsigned wrap of size before subtraction.
>
> Signed-off-by: Roel Kluin
> ---
> Is this maybe better or are we certain that size can't wrap?
Patch looks good, though while you're at it, you could add a space
after the "while".
Acked-by: Paul Mackerras
___
On Wed, 2009-10-14 at 16:14 -0500, Scott Wood wrote:
>
> I think the last working version was a little older than that -- and it's
> quite
> possible that there was underlying badness even earlier that just recently
> got
> exposed. I think I want to just debug it and find out what's really g
On Wed, 2009-10-14 at 23:02 +0200, Jean Delvare wrote:
> Hi all,
>
> On Tue, 13 Oct 2009 11:49:48 +0200, Jean Delvare wrote:
> > I2C bus being setup too fast sounds more likely. It might be worth
> > adding an arbitrary delay after initialization, just to see if it
> > helps. Not sure where though
Joakim Tjernlund wrote:
With that, I don't see the hard lockup, but things get stuck during
You needed both to loose the hard lockup? I would think
it should be enough to revert the "various copy routines" stuff?
No, but when I just reverted the patch and didn't change the TLB error handler,
Scott Wood wrote on 14/10/2009 22:22:25:
>
> Joakim Tjernlund wrote:
> > Scott Wood wrote on 14/10/2009 21:23:02:
> >> Joakim Tjernlund wrote:
> >>> BTW, you could add a test and printk in do_page_fault on address
> >>> 0x00f0.
> >>> if that ever hits there is a problem with dcbX fixup.
> >
Jean,
I tried one reboot with your patch, failed as usual.
(Patch sounds like a good idea though.)
-Tim Shepard
s...@alum.mit.edu
tree<11>$ git describe
v2.6.31.1-6-g0b193bc
tree<12>$ git diff HEAD^ HEAD
diff --git a/drivers/macintosh/therm_adt
Hi all,
On Tue, 13 Oct 2009 11:49:48 +0200, Jean Delvare wrote:
> I2C bus being setup too fast sounds more likely. It might be worth
> adding an arbitrary delay after initialization, just to see if it
> helps. Not sure where though, as I'm not familiar with the Powermac
> initialization steps. May
Joakim Tjernlund wrote:
Scott Wood wrote on 14/10/2009 21:23:02:
Joakim Tjernlund wrote:
BTW, you could add a test and printk in do_page_fault on address 0x00f0.
if that ever hits there is a problem with dcbX fixup.
It doesn't get any 0xf0 faults.
FWIW, I'm not seeing the segfault any mo
Hi, Scott
Scott Wood wrote:
Felix Radensky wrote:
Yes, NAND and NOR are on the same local bus controller.
Maybe powerpc folks can provide some insight here.
Is it possible that simultaneous access to NOR and NAND
on MPC8536 can result in NAND timeouts ?
I've heard other reports of such probl
Scott Wood wrote on 14/10/2009 21:23:02:
> Joakim Tjernlund wrote:
> > BTW, you could add a test and printk in do_page_fault on address 0x00f0.
> > if that ever hits there is a problem with dcbX fixup.
>
> It doesn't get any 0xf0 faults.
>
> FWIW, I'm not seeing the segfault any more, but I st
On Wed, Oct 14, 2009 at 1:11 PM, Wolfgang Grandegger
wrote:
> Grant Likely wrote:
>> From: John Bonesio
>>
>> The MDIO bus cannot be accessed at interrupt context, but on an FEC
>> error, the fec_mpc52xx driver reset function also tries to reset the
>> PHY. Since the error is detected at IRQ co
Joakim Tjernlund wrote:
BTW, you could add a test and printk in do_page_fault on address 0x00f0.
if that ever hits there is a problem with dcbX fixup.
It doesn't get any 0xf0 faults.
FWIW, I'm not seeing the segfault any more, but I still get the lockup.
-Scott
___
Grant Likely wrote:
> From: John Bonesio
>
> The MDIO bus cannot be accessed at interrupt context, but on an FEC
> error, the fec_mpc52xx driver reset function also tries to reset the
> PHY. Since the error is detected at IRQ context, and the PHY functions
> try to sleep, the kernel ends up pani
Scott Wood wrote on 14/10/2009 19:20:03:
>
> On Sun, Oct 11, 2009 at 06:35:08PM +0200, Joakim Tjernlund wrote:
> > This is an assembler version to fixup DAR not being set
> > by dcbX, icbi instructions. There are two versions, one
> > uses selfmodifing code, the other uses a
> > jump table but is
On Tue, Oct 13, 2009 at 11:44 PM, Michael Ellerman
wrote:
> get_irq_desc() is a powerpc-specific version of irq_to_desc(). That
> is reason enough to remove it, but it also doesn't know about sparse
> irq_desc support which irq_to_desc() does (when we enable it).
>
> Signed-off-by: Michael Ellerma
On Tue, Oct 13, 2009 at 11:44 PM, Michael Ellerman
wrote:
> The irq_desc array consumes quite a lot of space, and for systems
> that don't need or can't have 512 irqs it's just wasted space.
>
> The first 16 are reserved for ISA, so the minimum of 32 is really
> 16 - and no one has asked for more
Scott Wood wrote on 14/10/2009 19:23:51:
>
> On Sun, Oct 11, 2009 at 06:35:04PM +0200, Joakim Tjernlund wrote:
> > This is the latest batch of mu 8xx MMU/TLB rework.
> > I think this is complete now and will relax with
> > other work the next few days. I hope I can get some
> > testing from Scott
On Tue, Oct 13, 2009 at 11:45 PM, Michael Ellerman
wrote:
> Defining CONFIG_SPARSE_IRQ enables generic code that gets rid of the
> static irq_desc array, and replaces it with an array of pointers to
> irq_descs.
>
> It also allows node local allocation of irq_descs, however we
> currently don't ha
On Tue, Oct 13, 2009 at 11:45 PM, Michael Ellerman
wrote:
> Move the default case out of the if, ie. when we're just displaying
> an irq. And consolidate all the odd cases at the top, ie. printing
> the header and footer.
>
> And in the process cope with sparse irq_descs.
>
> Signed-off-by: Michae
On Tue, Oct 13, 2009 at 11:44 PM, Michael Ellerman
wrote:
> Signed-off-by: Michael Ellerman
Acked-by: Grant Likely
> ---
> arch/powerpc/kernel/irq.c | 5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index
On Tue, Oct 13, 2009 at 11:44 PM, Michael Ellerman
wrote:
> Rather than open-coding our own check, use irq_has_action()
> to check if an irq has an action - ie. is "in use".
>
> irq_has_action() doesn't take the descriptor lock, but it
> shouldn't matter - we're just using it as an indicator
> tha
On Wed, Oct 14, 2009 at 6:57 AM, FIXED-TERM Seeh Thomas (BEG/EMS1)
wrote:
> Hello everyone,
>
> I'm working on a project to get USB ready on a MPC5200B based board.
> On this board I'm not using Linux (but MQX), but my question is not related
> to Linux.
> It's more specific to USB and OHCI.
> I w
Felix Radensky wrote:
Yes, NAND and NOR are on the same local bus controller.
Maybe powerpc folks can provide some insight here.
Is it possible that simultaneous access to NOR and NAND
on MPC8536 can result in NAND timeouts ?
I've heard other reports of such problems with eLBC, but was unable
Hi,
I've found a very simple way to create a kernel panic, that's happening
to our MPC5200B based boards. The issue was that when our boards
received a burst of ethernet packets had a kernel panic.
It does also happen to a lite5200b evaluation board, and it is really
simple to reproduce:
Step 1:
Adrian Hunter wrote:
Felix Radensky wrote:
Adrian Hunter wrote:
Felix Radensky wrote:
Hi,
I have a strange problem in linux-2.6.31 running on MPC8536DS board.
It is 100% reproducible, by opening a 350MB tar file into ubifs volume
on NAND flash, and starting erase of NOR flash partition righ
From: John Bonesio
The MDIO bus cannot be accessed at interrupt context, but on an FEC
error, the fec_mpc52xx driver reset function also tries to reset the
PHY. Since the error is detected at IRQ context, and the PHY functions
try to sleep, the kernel ends up panicking.
Resetting the PHY on an
From: John Bonesio
The MDIO bus cannot be accessed at interrupt context, but on an FEC
error, the fec_mpc52xx driver reset function also tries to reset the
PHY. Since the error is detected at IRQ context, and the PHY functions
try to sleep, the kernel ends up panicking.
Resetting the PHY on an
On Sun, Oct 11, 2009 at 06:35:04PM +0200, Joakim Tjernlund wrote:
> This is the latest batch of mu 8xx MMU/TLB rework.
> I think this is complete now and will relax with
> other work the next few days. I hope I can get some
> testing from Scott and Rex during this time.
I applied this stack plus "
On Sun, Oct 11, 2009 at 06:35:08PM +0200, Joakim Tjernlund wrote:
> This is an assembler version to fixup DAR not being set
> by dcbX, icbi instructions. There are two versions, one
> uses selfmodifing code, the other uses a
> jump table but is much bigger(default).
> ---
> arch/powerpc/kernel/hea
On Wed, Oct 14, 2009 at 10:35 AM, Asier Llano Palacios wrote:
> Hi,
>
> I've found a very simple way to create a kernel panic, that's happening
> to our MPC5200B based boards. The issue was that when our boards
> received a burst of ethernet packets had a kernel panic.
This looks familiar. Look
On Sun, Oct 11, 2009 at 06:35:09PM +0200, Joakim Tjernlund wrote:
> DARFix: /* Return from dcbx instruction bug workaround, r10 holds value
> of DAR */
[snip]
> + b DARfix /* Nope, go back to normal TLB processing */
arch/powerpc/kernel/head_8xx.S:577: undefined reference
On Sun, Oct 11, 2009 at 06:35:06PM +0200, Joakim Tjernlund wrote:
> + mfspr r11, SRR1
> + /* clear all error bits as TLB Miss
> + * sets a few unconditionally
> + */
> + rlwinm r11, r11, 0, 0x
> + mtspr SRR1, r11
arch/powerpc/kernel/head_8xx.S:369: Error: unsuppor
On Sun, Oct 11, 2009 at 06:35:05PM +0200, Joakim Tjernlund wrote:
> 8xx sometimes need to load a invalid/non-present TLBs in
> it DTLB asm handler.
> These must be invalidated separaly as linux mm don't.
> ---
> arch/powerpc/mm/fault.c |8 +++-
> 1 files changed, 7 insertions(+), 1 deletio
Felix Radensky wrote:
Adrian Hunter wrote:
Felix Radensky wrote:
Hi,
I have a strange problem in linux-2.6.31 running on MPC8536DS board.
It is 100% reproducible, by opening a 350MB tar file into ubifs volume
on NAND flash, and starting erase of NOR flash partition right after
that.
If I do
Hello everyone,
I'm working on a project to get USB ready on a MPC5200B based board.
On this board I'm not using Linux (but MQX), but my question is not related to
Linux.
It's more specific to USB and OHCI.
I will communicate with a Mass Storage Device and therefor the control transfer
works fin
Felix Radensky wrote:
Hi,
I have a strange problem in linux-2.6.31 running on MPC8536DS board.
It is 100% reproducible, by opening a 350MB tar file into ubifs volume
on NAND flash, and starting erase of NOR flash partition right after that.
If I don't start NOR erase, everything works fine. Al
The ADT746x don't have any register at sub-address 0, so better use an
existing register for the initial test read.
Signed-off-by: Jean Delvare
Cc: Colin Leroy
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
Tim, I don't really expect this to solve your problem, but who knows...
Care to give
On Wed, Oct 14, 2009 at 09:41:33AM +0200, Richard Cochran wrote:
> >-Original Message-
> >From: linuxppc-dev-bounces On Behalf Of Scott Wood
> >Sent: Wednesday, September 09, 2009 8:22 PM
> >To: Roland Lezuo
> >Cc: linuxppc-dev@lists.ozlabs.org
> >Subject: Re: [PATCH] * mpc8313erdb.dts: Fix
size_t len cannot be less than 0.
Signed-off-by: Roel Kluin
---
>>> Or can this test be removed?
>>
>> I'd prefer just to remove the test.
>
> Yes, sounds good.
If you meant only the left-hand part, here you go:
diff --git a/arch/powerpc/platforms/cell/spufs/file.c
b/arch/powerpc/platforms/ce
Adrian Hunter wrote:
Felix Radensky wrote:
Hi,
I have a strange problem in linux-2.6.31 running on MPC8536DS board.
It is 100% reproducible, by opening a 350MB tar file into ubifs volume
on NAND flash, and starting erase of NOR flash partition right after
that.
If I don't start NOR erase, e
Hi, Adrian
Adrian Hunter wrote:
Felix Radensky wrote:
Hi,
I have a strange problem in linux-2.6.31 running on MPC8536DS board.
It is 100% reproducible, by opening a 350MB tar file into ubifs volume
on NAND flash, and starting erase of NOR flash partition right after
that.
If I don't start
On Wed, 2009-10-14 at 17:15 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-10-14 at 11:43 +0530, Sachin Sant wrote:
>
> > Tested both the patches. Works fine.
>
> Thanks !
>
> Stephen, you merge these yourself or you need me to pick them up in
> -powerpc ?
>
Ben,
You can either pull from
Check to prevent unsigned wrap of size before subtraction.
Signed-off-by: Roel Kluin
---
Is this maybe better or are we certain that size can't wrap?
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 1ade7eb..dd2d263 100644
--- a/arch/powerpc/mm/hash_utils_64.c
Hi,
I have a strange problem in linux-2.6.31 running on MPC8536DS board.
It is 100% reproducible, by opening a 350MB tar file into ubifs volume
on NAND flash, and starting erase of NOR flash partition right after that.
If I don't start NOR erase, everything works fine. Also, If I run sync
afte
>-Original Message-
>From: linuxppc-dev-bounces On Behalf Of Scott Wood
>Sent: Wednesday, September 09, 2009 8:22 PM
>To: Roland Lezuo
>Cc: linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
>
>On Fri, Sep 04, 2009 at 12:31:25PM +0200, R
> How about something like this..
> If the arch does not enable CONFIG_CPU_IDLE, the cpuidle_idle_call
> which is called from cpu_idle() should call default_idle without
> involving the registering cpuidle steps. This should prevent bloating
> up of the kernel for archs which dont want to use cpuid
79 matches
Mail list logo
