On Wed, Dec 16, 2009 at 3:18 PM, Peter Zijlstra wrote:
> On Wed, 2009-12-16 at 12:24 +0530, Sachin Sant wrote:
>> Xiaotian Feng wrote:
>> > On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant wrote:
>> >
>> >> Xiaotian Feng wrote:
>> >>
>> >>> Does this testcase hotplug cpu 0 off?
>> >>>
>> >>>
>> >> No
On Wed, 2009-12-16 at 12:24 +0530, Sachin Sant wrote:
> Xiaotian Feng wrote:
> > On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant wrote:
> >
> >> Xiaotian Feng wrote:
> >>
> >>> Does this testcase hotplug cpu 0 off?
> >>>
> >>>
> >> No, i don't think so. It skips cpu0 during online/offl
On Wed, 2009-12-16 at 11:08 +0530, Sachin Sant wrote:
> Peter Zijlstra wrote:
> > Could you try the below?
> >
> No luck. Still the same issue. The mask values don't change.
Bugger, that patch did solve a similar problem for a patch I'm working
on.
Can you maybe add a print of the cpu_active_m
On Tue, Dec 15, 2009 at 9:47 PM, Sachin Sant wrote:
> Peter Zijlstra wrote:
>>>
>>> I added some debug statements within the above code. This is a 2 cpu
>>> machine.
>>>
>>> XMON dest_cpu = 1024 . dead_cpu = 1 . nr_cpu_ids = 2
>>> XMON dest_cpu = 1024 XMON dest_cpu = 1024 . dead_cpu = 1
>>> XMON d
Xiaotian Feng wrote:
On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant wrote:
Xiaotian Feng wrote:
Does this testcase hotplug cpu 0 off?
No, i don't think so. It skips cpu0 during online/offline
process.
Then how could this happen ? Looks like cpu 0 is offline
0:mon> <4
> -Original Message-
> From:
> linuxppc-dev-bounces+vivek.mahajan=freescale@lists.ozlabs.
> org
> [mailto:linuxppc-dev-bounces+vivek.mahajan=freescale@lists
.ozlabs.org] On Behalf Of Felix Radensky
> Sent: Wednesday, December 16, 2009 2:56 AM
> To: linuxppc-...@ozlabs.org; Aggrwal
On Wed, Dec 16, 2009 at 2:41 PM, Sachin Sant wrote:
> Xiaotian Feng wrote:
>>
>> Does this testcase hotplug cpu 0 off?
>>
>
> No, i don't think so. It skips cpu0 during online/offline
> process.
Then how could this happen ? Looks like cpu 0 is offline
0:mon> <4>IRQ 17 affinity broken off cpu
On Fri, Dec 11, 2009 at 6:53 PM, Sachin Sant wrote:
> While executing cpu_hotplug(from autotest) tests against latest
> next on a power6 box, the machine locks up. A soft reset shows
> the following trace
>
> cpu 0x0: Vector: 100 (System Reset) at [cc9333d0]
> pc: c03433d8: .find
Xiaotian Feng wrote:
Does this testcase hotplug cpu 0 off?
No, i don't think so. It skips cpu0 during online/offline
process.
thanks
-Sachin
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
Peter Zijlstra wrote:
Could you try the below?
No luck. Still the same issue. The mask values don't change.
Thanks
-Sachin
---
init/main.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/init/main.c b/init/main.c
index 4051d75..4be7de2 100644
--- a/init/main
This patch ports the kprobe-based event tracer to powerpc. This patch
is based in x86 port. This brings powerpc on par with x86.
Port the following API's to ppc for accessing registers and stack entries
from pt_regs.
- regs_query_register_offset(const char *name)
Query the offset of "name" reg
On Wed, Dec 16, 2009 at 02:47:30AM +0300, Vitaly Bordug wrote:
>
> From: Heiko Schocher
>
> This driver provides (read/write) access to the
> U-Boot bootcounter via PROC FS or sysFS.
>
> in u-boot, it uses a 8 byte mem area (it must hold the value over a
> soft reset of course), for storing a b
From: Heiko Schocher
This driver provides (read/write) access to the
U-Boot bootcounter via PROC FS or sysFS.
in u-boot, it uses a 8 byte mem area (it must hold the value over a
soft reset of course), for storing a bootcounter (it counts many soft
resets are done, on hard reset it starts with 0
MPC85xx chips report the wrong value in feature reporting register,
and that causes the following oops:
Unable to handle kernel paging request for data at address 0x0c00
Faulting instruction address: 0xc0019294
Oops: Kernel access of bad area, sig: 11 [#1]
MPC8569 MDS
Modules linked in:
Hi,
I'm trying to use mini-PCI-E WLAN card on P2020RDB running 2.6.32, but
so far without success.
ath9k driver identifies the device, I can run ifconfig, iwconfig and
hostapd on wlan0, but device is not
getting any interrupts, so I suspect the interrupt configuration is
wrong. Atheros ath9k
The following changes since
commit e090aa80321b64c3b793f3b047e31ecf1af9538d:
Benjamin Herrenschmidt (1):
powerpc: Fix usage of 64-bit instruction in 32-bit altivec code
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next
Anton
On Tue, Dec 15, 2009 at 3:59 AM, Roman Fietze
wrote:
> Hallo Grant,
>
> On Friday 11 December 2009 07:13:45 Grant Likely wrote:
>
>> BTW, if you're interested, there is a driver for the SCLPC FIFO about
>> to be merged into 2.6.33. It's in Ben's tree waiting to be pulled
>> into mainline.
>
> I'v
Suresh Vishnu-B05022 wrote:
> On Mon, Dec 14, 2009 at 6:33 AM, Vishnu Suresh
wrote:
> > The async_tx descriptors contains dangling pointers.
> > Hence, re-initialize them to NULL before use.
> >
> > Signed-off-by: Vishnu Suresh
> > ---
> > o. Rebased to linux-next as of 20091214
> >
>
Could you try the below?
---
init/main.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/init/main.c b/init/main.c
index 4051d75..4be7de2 100644
--- a/init/main.c
+++ b/init/main.c
@@ -369,12 +369,6 @@ static void __init smp_init(void)
{
unsigned int cpu;
Peter Zijlstra wrote:
I added some debug statements within the above code.
This is a 2 cpu machine.
XMON dest_cpu = 1024 . dead_cpu = 1 . nr_cpu_ids = 2
XMON dest_cpu = 1024
XMON dest_cpu = 1024 . dead_cpu = 1
XMON dest_cpu = 1024 . dead_cpu = 1 . nr_cpu_ids = 2
XMON dest_cpu = 1024
XMON des
* Benjamin Herrenschmidt [2009-12-04 21:00:52]:
> On Fri, 2009-12-04 at 13:45 +0530, Arun R Bharadwaj wrote:
>
> >
> > Hi Ben,
> >
> > I forgot to attach the patch which enables cpuidle for the rest of the
> > POWER platforms. Attaching it below.
> >
> > So for these platforms, ppc_md.power_s
> On Mon, Dec 14, 2009 at 6:33 AM, Vishnu Suresh wrote:
> > The async_tx descriptors contains dangling pointers.
> > Hence, re-initialize them to NULL before use.
> >
> > Signed-off-by: Vishnu Suresh
> > ---
> > o. Rebased to linux-next as of 20091214
> >
> > drivers/crypto/talitos.c |3 +++
Hallo Grant,
On Friday 11 December 2009 07:13:45 Grant Likely wrote:
> BTW, if you're interested, there is a driver for the SCLPC FIFO about
> to be merged into 2.6.33. It's in Ben's tree waiting to be pulled
> into mainline.
I've had a "look" into it. This means I rewrote it in some parts to
g
On Tue, 2009-12-15 at 15:14 +0530, Sachin Sant wrote:
> Benjamin Herrenschmidt wrote:
> >> static void move_task_off_dead_cpu(int dead_cpu, struct task_struct *p)
> >> {
> >> int dest_cpu;
> >> const struct cpumask *nodemask =
> >> cpumask_of_node(cpu_to_node(dead_cpu));
> >>
> >>
Benjamin Herrenschmidt wrote:
static void move_task_off_dead_cpu(int dead_cpu, struct task_struct *p)
{
int dest_cpu;
const struct cpumask *nodemask = cpumask_of_node(cpu_to_node(dead_cpu));
again:
/* Look for allowed, online CPU in same node. */
for_each_cpu_and(
25 matches
Mail list logo
