Hi Ingo,
On Fri, 12 Jun 2009 16:11:18 +0200 Ingo Molnar wrote:
>
> But that's axiomatic, isnt it? linux-next build-tests PowerPC as the
> first in the row of tests - so no change that was in linux-next can
> ever cause a build failure on PowerPC, right?
Not really. I build a powerpc ppc64_def
Hi Ingo,
On Fri, 12 Jun 2009 15:44:28 +0200 Ingo Molnar wrote:
>
> In terms of test coverage, at least for our trees, less than 1% of
> the bugs we handle get reported in a linux-next context - and most
> of the bugs that get reported (against say the scheduler tree) are
> related to rare arch
OK, one major issue with this patch and a few minor nits.
First, the major issue is that I don't see anything in the patch that
changes the code in ehca_mem_notifier() in ehca_main.c:
case MEM_GOING_ONLINE:
case MEM_GOING_OFFLINE:
/* only ok if no hca is attached t
Allow use_rmii in fs_platform_info to be set in the OF device tree
using phy-mode="rmii".
Signed-off-by: Ken MacLeod
---
drivers/net/fs_enet/fs_enet-main.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_en
The new driver for AC97 on the mpc5200 has landed in front of Timur's
patch implementing spin_event_timeout(). Timur's patch is in
powerpc-next which hasn't been merged yet. mpc5200_psc_ac97 will build
ok after this merge happens.
--
Jon Smirl
jonsm...@gmail.com
_
On Jun 12, 2009, at 12:38 PM, Dan Williams wrote:
Kumar Gala wrote:
On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
On Thu, Jun 11, 2009 at 11:17 PM, Ira
Snyder wrote:
On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
On Mon, Apr 27
From: Grant Likely
The xilinxfb driver is improperly casting a physical address to a
u32, and the probe routine isn't as straight forward as it could be.
(discovered by gcc spitting out warnings on most recent change to
xilinxfb driver).
This patch fixes the cast and simplifies the probe path.
On Fri, Jun 12, 2009 at 09:04:52AM -0500, Kumar Gala wrote:
>> On UP, all the spinlock manipulation goes away and we simply disable
>> interrupts around each operation. In fact gcc eliminates the whole
>> atomic64_lock variable as well.
>>
>> Signed-off-by: Paul Mackerras
>> ---
>> Compile-tested
Kumar Gala wrote:
On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder
wrote:
On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi
wrote:
Adding Kumar t
On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder
wrote:
On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi
wrote:
Adding Kumar to the CC: list, s
On Fri, 2009-06-12 at 16:11 +0200, Ingo Molnar wrote:
> > Maybe. But maybe it's representative... so far in this merge
> > window, 100% of the powerpc build and runtime breakage upstream
> > comes from stuff that didn't get into -next before.
>
> But that's axiomatic, isnt it? linux-next build-t
> Uhm, the bug you are making a big deal of would have been found and
> fixed by Paulus a few hours after any such mail - and probably by me
> too as i do daily cross builds to Power.
>
> So yes, we had a bug, but any extra linux-next hoops would not have
> prevented it: i could still have mes
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt wrote:
> >
> > > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> > >
> > > > To some extent, he
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
>
> > This is certainly doable for agreeable features - which is the bulk
> > - and it is being done.
> >
> > But this is a catch-22 for _controversial_ new features - which
> > perfcounters clearly was,
On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
>
> > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> >
> > > To some extent, here, the issue is on Linus side and it's up to him
On Jun 12, 2009, at 7:02 AM, Paul Mackerras wrote:
32-bit powerpc processors have no 64-bit atomic instructions, but we
will
need atomic64_t in order to support the perf_counter subsystem on 32-
bit
processors.
This adds an implementation of 64-bit atomic operations using hashed
spinlocks t
On Fri, 2009-06-12 at 08:54 -0500, Timur Tabi wrote:
> On Fri, Jun 12, 2009 at 2:29 AM, Benjamin
> Herrenschmidt wrote:
> > I pushed the following commits, along with merging Linus tree in today.
>
> Is there a reason you keep ignoring my patch?
Other than I hate you ? just kidding :-)
> [PATCH
On Jun 12, 2009, at 8:27 AM, Li Yang wrote:
On Thu, Jun 11, 2009 at 9:32 PM, Kumar
Gala wrote:
On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
On May 12, 2009, at 3:35 AM, Li Yang wrote:
Add the mapping functions used to support direct IO memory
access of
rapidIO.
Signed-off-by: Zh
On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
> This is certainly doable for agreeable features - which is the bulk
> - and it is being done.
>
> But this is a catch-22 for _controversial_ new features - which
> perfcounters clearly was, in case you turned off your lkml
> subscription
On Fri, Jun 12, 2009 at 2:29 AM, Benjamin
Herrenschmidt wrote:
> I pushed the following commits, along with merging Linus tree in today.
Is there a reason you keep ignoring my patch?
[PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()
There is PowerPC code in the ALSA tree that depends
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
>
> > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > Linus ! still listening ?) to maybe be more proactive a
* Benjamin Herrenschmidt wrote:
> > linux-next should not be second-guessing maintainers and should
> > not act as an "approval forum" for controversial features,
> > increasing the (already quite substantial) pressure on
> > maintainers to apply more crap.
>
> I agree here. That's not the p
On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> To some extent, here, the issue is on Linus side and it's up to him (Hey
> Linus ! still listening ?) to maybe be more proactive at giving an ack
> or nack so that we can get
On Thu, Jun 11, 2009 at 9:32 PM, Kumar Gala wrote:
>
> On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
>
>>> On May 12, 2009, at 3:35 AM, Li Yang wrote:
>>>
Add the mapping functions used to support direct IO memory access of
rapidIO.
Signed-off-by: Zhang Wei
Signed-off
On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt wrote:
> linux-next has integration testing so that interactions between
> maintainer trees are mapped and that architectures that otherwise
> few people use get build-tested too (well beyond their practical
> rel
* Benjamin Herrenschmidt wrote:
> > Ah - thanks. The bug was caused by me being a bit too optimistic
> > in applying the shiny-new Power7 support patches on the last
> > day. (nice CPU btw.)
>
> In that case paulus tells me it's actually Peter screwing up
> moving something from the powerpc
32-bit powerpc processors have no 64-bit atomic instructions, but we will
need atomic64_t in order to support the perf_counter subsystem on 32-bit
processors.
This adds an implementation of 64-bit atomic operations using hashed
spinlocks to provide atomicity. For each atomic operation, the addres
On 32-bit non-Book E, local_irq_restore() turns into just mtmsr(),
which doesn't currently have a compiler memory barrier. This means
that accesses to memory inside a local_irq_save/restore section,
or a spin_lock_irqsave/spin_unlock_irqrestore section on UP, can
be reordered by the compiler to oc
* Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:
>
> > From: Stephen Rothwell
> > Date: Fri, 12 Jun 2009 10:14:22 +1000
> > Subject: [PATCH] perfcounters: remove powerpc definitions of
> > perf_counter_do_pending
> >
> > Commit 925d519ab82b6dd7aca9
On Fri, 2009-06-12 at 11:43 +0200, Peter Zijlstra wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even though
> its not c
* Peter Zijlstra wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even
> though its not clear they will be merged?
>
>
On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> We should at least -try- to follow the
> process we've defined, don't you think ?
So you're saying -next should include whole new subsystems even though
its not clear they will be merged?
That'll invariably create the opposite cas
On Tue, 2009-06-09 at 17:38 -0700, David Brownell wrote:
> On Friday 05 June 2009, Subrata Modak wrote:
> > Correct, it fixes the issue. However, since few changes might have gone
> > to the Kconfig, the patch does not apply cleanly. Below is the patch, just
> > a retake of the earlier one, but on
> Ah - thanks. The bug was caused by me being a bit too optimistic in
> applying the shiny-new Power7 support patches on the last day. (nice
> CPU btw.)
In that case paulus tells me it's actually Peter screwing up moving
something from the powerpc code to generic :-)
.../...
> Such bugs happ
On Fri, 2009-06-12 at 14:32 +0530, Sachin Sant wrote:
> 2.6.30-git3 fails to boot on Power6 box with following messages
.../...
> git2 boots fine with the same config.
>
> I came across the following mail from Ben so this could be a know issue.
>
> http://lists.ozlabs.org/pipermail/linuxppc-d
On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder wrote:
> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>
>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>
>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi
>>> wrote:
Adding Kumar to the CC: list, since he might pick up the patch
2.6.30-git3 fails to boot on Power6 box with following messages
[boot]0020 XICS Init
Unable to handle kernel paging request for data at address 0x0020
Faulting instruction address: 0xc00cb7d8
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in
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: Rin
090611) the slab tree for linux-next had only one
> commit in it ("SLUB: Out-of-memory diagnostics"). Today (next-20090612)
> it has quite a lot in it again - including SLQB.
Ah, ok. I did mess it up for few hours and I guess you picked up then.
Thanks, Stephen!
uot;). Today (next-20090612)
it has quite a lot in it again - including SLQB.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
pgpxd35sjbvZY.pgp
Description: PGP signature
___
Linuxppc-dev mailin
Hi Jaswinder,
On Fri, 12 Jun 2009 12:04:54 +0530 Jaswinder Singh Rajput
wrote:
>
> Please check this patch :
>
> [PATCH] powerpc: perf_counter fix performance counter event types
>
> Fix compilation warnings :
> CC arch/powerpc/kernel/power7-pmu.o
> arch/powerpc/kernel/power7-pmu.c:297:
On Fri, 2009-06-12 at 10:21 +0200, Nick Piggin wrote:
> On Fri, Jun 12, 2009 at 01:38:50PM +0530, Sachin Sant wrote:
> > Nick Piggin wrote:
> > >>I was able to boot yesterday's next (20090611) on this machine. Not sure
> > >>
> > >
> > >Still with SLQB? With debug options turned on?
> > >
> >
On Fri, Jun 12, 2009 at 01:38:50PM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >>I was able to boot yesterday's next (20090611) on this machine. Not sure
> >>
> >
> >Still with SLQB? With debug options turned on?
> >
> Ah .. spoke too soon. The kernel was not compiled with SLQB. Sorry
>
Jaswinder Singh Rajput wrote:
Please check this patch :
[PATCH] powerpc: perf_counter fix performance counter event types
Fix compilation warnings :
CC arch/powerpc/kernel/power7-pmu.o
arch/powerpc/kernel/power7-pmu.c:297: error: PERF_COUNT_CPU_CYCLES undeclared
here (not in a function)
Nick Piggin wrote:
I was able to boot yesterday's next (20090611) on this machine. Not sure
Still with SLQB? With debug options turned on?
Ah .. spoke too soon. The kernel was not compiled with SLQB. Sorry
about the confusion. I can't seem to select SLQB as the slab
allocator.
Thanks
On Fri, Jun 12, 2009 at 11:14:10AM +0530, Sachin Sant wrote:
> Nick Piggin wrote:
> >I can't really work it out. It seems to be the kmem_cache_cache which has
> >a problem, but there have already been lots of caches created and even
> >this samw cache_node already used right beforehand with no prob
I pushed the following commits, along with merging Linus tree in today.
Note that it will not boot on various machines unless the allocator
init ordering problem I mentioned earlier is fixed.
Benjamin Herrenschmidt (1):
powerpc: Fix bug in move of altivec code to vector.S
Josh Boyer (3):
--- Begin Message ---
On Fri, 2009-06-12 at 14:25 +1000, Benjamin Herrenschmidt wrote:
> I'll cook up a patch that defines a global bitmask of "forbidden" GFP
> bits and see how things go.
>From ad87215e01b257ccc1af64aa9d5776ace580dea3 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt
Date:
48 matches
Mail list logo
