From: Kumar Gala <galak@kernel.crashing.org>
To: Jean-Michel Hautbois <jhautbois@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: Different behaviour when using "nosmp" parameter on SMP and UP
Date: Thu, 1 Dec 2011 08:03:42 -0600 [thread overview]
Message-ID: <D70E8CC4-9FA3-4DC9-B623-02F32EFBFE0F@kernel.crashing.org> (raw)
In-Reply-To: <CAL8zT=juU_PC92R4za31R8Lmur0PrFwog1m1fk+PEarW_0C6ng@mail.gmail.com>
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
next prev parent reply other threads:[~2011-12-01 14:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-01 9:57 Jean-Michel Hautbois
2011-12-01 14:03 ` Kumar Gala [this message]
2011-12-01 15:04 ` Jean-Michel Hautbois
2011-12-01 15:56 ` Tabi Timur-B04825
2011-12-01 16:14 ` Jean-Michel Hautbois
2011-12-01 17:52 ` Jean-Michel Hautbois
2011-12-01 19:35 ` Kumar Gala
2011-12-01 20:09 ` Jean-Michel Hautbois
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D70E8CC4-9FA3-4DC9-B623-02F32EFBFE0F@kernel.crashing.org \
--to=galak@kernel.crashing.org \
--cc=jhautbois@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®