All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: David Shah <dave@ds0.me>
Cc: Discussions about the Letux Kernel <letux-kernel@openphoenux.org>,
	kernel@pyra-handheld.com, Linux-OMAP <linux-omap@vger.kernel.org>
Subject: Re: [Letux-kernel] Lockup inside omap4_prminst_read_inst_reg on OMAP5 uEVM
Date: Mon, 17 Aug 2020 09:38:35 +0300	[thread overview]
Message-ID: <20200817063835.GA2994@atomide.com> (raw)
In-Reply-To: <30eba639cefaa30718fad38a1dbc53c7475e40dd.camel@ds0.me>

Hi,

* David Shah <dave@ds0.me> [200816 20:13]:
> It seems like 'CSWR' idle may never have actually worked properly on
> the OMAP5...
> 
> As an experiment, I took the old TI 3.8.y GLSDK kernel,
> commit 2c871a879dbb4234232126f7075468d5bf0a50e3 and made the following
> changes:
> 
>  - Enabling CONFIG_CPU_IDLE as this was not in omap2plus_defconfig back
> then
>  - Disabling all the kernel debugging related config, as these seem to
> significantly reduce the frequency of lockups
>  - OSWR idle disabled, as this is known broken
>  - Some small patches to get it working with gcc9, none of which
> touched any power management or idle code.
> 
> And I saw lockups with an almost identical frequency to 5.6 and 5.7
> with a similar config; and the same pipeline stalled error reported by
> CCS when connecting over JTAG. The only difference is the reported PC
> was a read instruction inside sched_clock rather
> than omap4_prminst_read_inst_reg.
> 
> Would be interested to know if there is a backstory here? Could it be
> related to the bugs that stopped OSWR from working? Is there a glsdk
> kernel version that I missed where CSWR on the OMAP5 actually works
> reliably.
> 
> If anyone wants to try reproducing this; the most important settings
> are:
> 
>  - CONFIG_CPU_IDLE=y
>  - All kernel debugging settings disabled
>  - CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
> 
> This will usually result in a lockup while idle at a login prompt
> within a few hours with no other hardware connected. A lockup usually
> occurs sooner (within 30 minutes) repeatedly wget'ing a 100MB test file
> in a loop.

Care to check if this happens with current mainline kernel and sgx
disabled?

The reason I'm asking is I used a pi-top with a omap5-igep0050 board as
a test laptop with the mainline kernel for about two years until I managed
to break the UART connector on it a few years ago :) I sure had things
working reliably with no hangs with cpuidle enabled with LPAE. This was
with the pi-top HDMI panel without sgx.

Also please see if this happens with omap5-uevm too. There pyra related
DDR self-refresh related hangs should be out of the AFAIK, but still
worth testing.

Regards,

Tony

  reply	other threads:[~2020-08-17  6:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-26 17:59 Lockup inside omap4_prminst_read_inst_reg on OMAP5 uEVM David Shah
2020-07-27  6:47 ` Tony Lindgren
2020-08-01 20:57 ` David Shah
2020-08-16 17:13   ` [Letux-kernel] " David Shah
2020-08-17  6:38     ` Tony Lindgren [this message]
2020-08-17  8:18       ` David Shah

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=20200817063835.GA2994@atomide.com \
    --to=tony@atomide.com \
    --cc=dave@ds0.me \
    --cc=kernel@pyra-handheld.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-omap@vger.kernel.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 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.