From: Michal Sojka <sojkam1@fel.cvut.cz>
To: christophe leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <scottwood@freescale.com>, linuxppc-dev@lists.ozlabs.org
Subject: Re: memcpy regression
Date: Sat, 05 Sep 2015 02:08:33 +0200 [thread overview]
Message-ID: <55EA3281.3000806@fel.cvut.cz> (raw)
In-Reply-To: <55E9F5CE.6050904@fel.cvut.cz>
On 4.9.2015 21:49, Michal Sojka wrote:
> On 4.9.2015 20:10, christophe leroy wrote:
>>
>>
>> Le 04/09/2015 16:35, Michal Sojka a écrit :
>>> On Fri, Sep 04 2015, Christophe LEROY wrote:
>>>> Le 04/09/2015 15:33, Michal Sojka a écrit :
>>>>> Dear Christophe,
>>>>>
>>>>> my MPC5200-based system stopped booting recently. I bisected the
>>>>> problem
>>>>> to your commit below. If I revert that commit (on top of
>>>>> 807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my
>>>>> system boots again.
>>>>>
>>>>>
>>>> Do you use mainline code only, or do you have home-made code ?
>>> I use mainline only sources with non-mainline device-tree.
>>>
>>>> memcpy() is not supposed to be used on non-cacheable memory.
>>>> memcpy_toio() is the function to use when copying to non-cacheble
>>>> area.
>>>>
>>>> When I submitted the patch, I looked for erroneous use of memcpy() and
>>>> memset().
>>>> I found one wrong use of memset() that I changed to memset_io() but I
>>>> didn't find any misuse of memcpy().
>>>> But I may have missed one.
>>> I attach my .config, if it helps. I have there
>>>
>>> CONFIG_PPC_MPC52xx=y
>>> CONFIG_PPC_MPC5200_SIMPLE=y
>>>
>>> so arch/powerpc/platforms/52xx is probably the directory to look. Do
>>> you
>>> see any mempcy misuse there?
>> I only found one suspect use of memcpy() in arch/powerpc/platforms/52xx/
>> It is in mpc52xx_pm.c but it's linked to CONFIG_PM which is not
>> selected by your .config
>> I'll check in the drivers selected by your .config
>>
>> In parallele, are you able to try with CONFIG_PPC_EARLY_DEBUG in
>> order to try and locate the blocking point ?
> I don't get any output from the system even with CONFIG_PPC_EARLY_DEBUG.
Hmm, there is no udbg console for MPC5200. I hacked something up and the
earliest place I was able to initialize it is after early_init_devtree()
in setup_32.c. Even with this console, I got no output when the
problematic patch was applied. So the problem is somewhere earlier.
-Michal
next prev parent reply other threads:[~2015-09-05 0:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 13:33 memcpy regression Michal Sojka
2015-09-04 13:57 ` Christophe LEROY
2015-09-04 14:35 ` Michal Sojka
2015-09-04 18:10 ` christophe leroy
2015-09-04 19:49 ` Michal Sojka
2015-09-05 0:08 ` Michal Sojka [this message]
2015-09-06 8:18 ` christophe leroy
2015-09-06 19:05 ` Michal Sojka
2015-09-06 21:01 ` Michal Sojka
2015-09-07 1:14 ` Michael Ellerman
2015-09-07 7:08 ` Christophe LEROY
2015-09-07 8:40 ` Michael Ellerman
2015-09-07 9:45 ` Michal Sojka
2015-09-07 10:59 ` David Laight
2015-09-08 3:54 ` Michael Ellerman
2015-09-08 8:59 ` David Laight
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=55EA3281.3000806@fel.cvut.cz \
--to=sojkam1@fel.cvut.cz \
--cc=christophe.leroy@c-s.fr \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=scottwood@freescale.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.