[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D70E8CC4-9FA3-4DC9-B623-02F32EFBFE0F@kernel.crashing.org>
Date: Thu, 1 Dec 2011 08:03:42 -0600
From: Kumar Gala <galak@...nel.crashing.org>
To: Jean-Michel Hautbois <jhautbois@...il.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...abs.org>
Subject: Re: Different behaviour when using "nosmp" parameter on SMP and UP
On Dec 1, 2011, at 3:57 AM, Jean-Michel Hautbois wrote:
> Hi,
>
> I have a P2020 CPU (powerpc) and I compiled it with two different defconfigs.
> The first one is a SMP, 2 cores, launched with the "nosmp" kernel
> parameter, the other one is an UP kernel.
>
> My driver behaviour is not the same whether launching one or the
> other. It is hard to explain more precisely, as it deals only with
> ioctl which only does ioread32/iowrite32 on a PCIe device.
> But I can tell that it never works the same way when UP (not working
> correctly), or SMP "nosmp" (working) or even SMP (not working).
>
> AFAIK, the "nosmp" parameter should tell the kernel to act the same is
> if it is an UP kernel, and it disables IO APIC, which is not an issue
> in my case.
>
> Can you think about anything that would explain it, or would help me
> debugging it ?
This is a bit odd, hard to say w/o more details on what exactly your code is trying to do and wait the failure is.
The larger differences between SMP & UP build would be setting of memory attribute for cache coherency. In UP case we don't set it.
Between SMP 'nosmp' and SMP 'on' cases you seem like you're hitting some locking condition.
Guessing your running into a timing & locking issue that you're getting lucky on the SMP 'nosmp' case such that it just happens to work.
- k--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists