From: Jon Hunter <jonathanh@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>,
John Ogness <john.ogness@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>, Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Esben Haabendal <esben@geanix.com>,
linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Arnd Bergmann <arnd@arndb.de>, Tony Lindgren <tony@atomide.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Serge Semin <fancer.lancer@gmail.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH tty-next v5 5/6] serial: 8250: Switch to nbcon console
Date: Mon, 27 Jan 2025 14:54:25 +0000 [thread overview]
Message-ID: <3e93c665-7603-4b64-a64c-a29079d8d11f@nvidia.com> (raw)
In-Reply-To: <lrpcbufgu7jnvepqkd3sz2qap2th45ndzv4c4vxh7v4zyhep6k@t635s7vbhkgz>
Hi John,
On 20/01/2025 16:34, Thierry Reding wrote:
> On Mon, Jan 20, 2025 at 05:23:26PM +0100, Thierry Reding wrote:
>> On Thu, Jan 16, 2025 at 10:41:08AM +0000, Jon Hunter wrote:
>>>
>>> On 16/01/2025 10:38, John Ogness wrote:
>>>> On 2025-01-16, Jon Hunter <jonathanh@nvidia.com> wrote:
>>>>>> Do you at least know if it is failing to suspend or failing to resume
>>>>>> (based on power consumption)?
>>>>>
>>>>>
>>>>> Unfortunately, I don't. These are farm boards and so nothing local I can
>>>>> get my hands on. For some reason all the serial console logs are not
>>>>> available and so I am going to talk to the farm team about fixing that
>>>>> because we should at least have serial logs.
>>>>
>>>> Can you confirm that the board is actually booting? The suspend code for
>>>> 8250_tegra.c is quite simple. I am wondering if the farm tests are
>>>> failing somewhere else, such as the atomic printing during early boot.
>>>
>>>
>>> Yes they are all booting fine. I have an independent boot test and that is
>>> passing. It is just the suspend test that is failing.
>>
>> I was able to capture logs, but unfortunately they don't provide much
>> insight either. On the first try it doesn't suspend and goes back to
>> userspace after a second or so:
>>
>> --- >8 ---
>> -sh-5.1# rtcwake --device /dev/rtc1 --mode mem --seconds 5
>> rtcwake: assuming RTC uses UTC ...
>> rtcwake: wakeup from "mem" using /dev/rtc1 at Thu Jan 1 00:01:00 1970
>> [ 36.332486] PM: suspend entry (deep)
>> [ 36.332832] Filesystems sync: 0.000 seconds
>> [ 36.369331] +1.8V_RUN_CAM: disabling
>> [ 36.373884] +2.8V_RUN_CAM: disabling
>> [ 36.375571] +1.2V_RUN_CAM_FRONT: disabling
>> [ 36.380359] +1.05V_RUN_CAM_REAR: disabling
>> [ 36.387399] +3.3V_RUN_TOUCH: disabling
>> [ 36.390808] +2.8V_RUN_CAM_AF: disabling
>> [ 36.393621] +1.8V_RUN_VPP_FUSE: disabling
>> [ 36.408218] Freezing user space processes
>> [ 36.413660] Freezing user space processes completed (elapsed 0.005 seconds)
>> [ 36.413680] OOM killer disabled.
>> [ 36.413693] Freezing remaining freezable tasks
>> [ 36.415033] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
>> [ 36.428474] drm drm: [drm:drm_client_dev_suspend] fbdev: ret=0
>> [ 36.428527] drm drm: [drm:drm_atomic_state_init] Allocated atomic state 2e5cd010
>> [ 36.428547] drm drm: [drm:drm_atomic_get_crtc_state] Added [CRTC:47:crtc-0] 6a6be0ef state to 2e5cd010
>> [ 36.428561] drm drm: [drm:drm_atomic_get_crtc_state] Added [CRTC:63:crtc-1] 00d818c2 state to 2e5cd010
>> [ 36.428574] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:32:plane-0] 4e145b7d state to 2e5cd010
>> [ 36.428587] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:36:plane-1] dbf67d12 state to 2e5cd010
>> [ 36.428597] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:40:plane-2] 763d8809 state to 2e5cd010
>> [ 36.428608] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:44:plane-3] b6eabcf1 state to 2e5cd010
>> [ 36.428617] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:48:plane-4] 7863878c state to 2e5cd010
>> [ 36.428628] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:52:plane-5] 54b8029c state to 2e5cd010
>> [ 36.428638] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:56:plane-6] 364063af state to 2e5cd010
>> [ 36.428648] drm drm: [drm:drm_atomic_get_plane_state] Added [PLANE:60:plane-7] e1c11dfb state to 2e5cd010
>> [ 36.428662] drm drm: [drm:drm_atomic_get_connector_state] Added [CONNECTOR:65:HDMI-A-1] 5cb32770 state to 2e5cd010
>> [ 36.428674] drm drm: [drm:drm_atomic_state_init] Allocated atomic state 832943c7
>> [ 36.428682] drm drm: [drm:drm_atomic_get_crtc_state] Added [CRTC:47:crtc-0] f09cf73d state to 832943c7
>> [ 36.428691] drm drm: [drm:drm_atomic_add_affected_planes] Adding all current planes for [CRTC:47:crtc-0] to 832943c7
>> [ 36.428700] drm drm: [drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:47:crtc-0] to 832943c7
>> [ 36.428711] drm drm: [drm:drm_atomic_get_crtc_state] Added [CRTC:63:crtc-1] 2700922c state to 832943c7
>> [ 36.428720] drm drm: [drm:drm_atomic_add_affected_planes] Adding all current planes for [CRTC:63:crtc-1] to 832943c7
>> [ 36.428727] drm drm: [drm:drm_atomic_add_affected_connectors] Adding all current connectors for [CRTC:63:crtc-1] to 832943c7
>> [ 36.428737] drm drm: [drm:drm_atomic_check_only] checking 832943c7
>> [ 36.428759] drm drm: [drm:drm_atomic_commit] committing 832943c7
>> [ 36.428881] drm drm: [drm:drm_atomic_state_default_clear] Clearing atomic state 832943c7
>> [ 36.428897] drm drm: [drm:__drm_atomic_state_free] Freeing atomic state 832943c7
>> [ 36.429085] r8169 0000:01:00.0 eth0: Link is Down
>> [ 36.713236] Disabling non-boot CPUs ...
>> -sh-5.1#
>> --- >8 ---
>>
>> A second attempt soft-hangs:
>>
>> --- >8 ---
>> -sh-5.1# rtcwake --device /dev/rtc1 --mode mem --seconds 5
>> rtcwake: assuming RTC uses UTC ...
>> rtcwake: wakeup from "mem" using /dev/rtc1 at Thu Jan 1 00:01:10 1970
>> --- >8 ---
>>
>> Where "soft-hang" means it doesn't do anything after this and I can't
>> SIGINT out of it or anything. However, the serial seems to still be
>> responsive.
>
> To clarify, this was on top of next-20250120 and reverting the patches
> that Jon mentioned suspend/resume is fixed for me as well.
>
> I do have a local device that I can test on, so if there's any patches
> you want me to try, or any options to enable to get more information,
> please let me know.
Any feedback on this? Our boards are still broken with this change.
Thanks!
Jon
--
nvpublic
next prev parent reply other threads:[~2025-01-27 14:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-07 21:26 [PATCH tty-next v5 0/6] convert 8250 to nbcon John Ogness
2025-01-07 21:26 ` [PATCH tty-next v5 1/6] serial: 8250: Adjust the timeout for FIFO mode John Ogness
2025-01-07 21:26 ` [PATCH tty-next v5 2/6] serial: 8250: Use frame time to determine timeout John Ogness
2025-01-13 9:54 ` Andy Shevchenko
2025-01-07 21:26 ` [PATCH tty-next v5 3/6] serial: 8250: Use high-level writing function for FIFO John Ogness
2025-01-07 21:27 ` [PATCH tty-next v5 4/6] serial: 8250: Provide flag for IER toggling for RS485 John Ogness
2025-01-07 21:27 ` [PATCH tty-next v5 5/6] serial: 8250: Switch to nbcon console John Ogness
2025-01-09 16:13 ` Petr Mladek
2025-01-15 16:21 ` Jon Hunter
2025-01-15 16:54 ` John Ogness
2025-01-16 10:27 ` Jon Hunter
2025-01-16 10:38 ` John Ogness
2025-01-16 10:41 ` Jon Hunter
2025-01-20 16:23 ` Thierry Reding
2025-01-20 16:34 ` Thierry Reding
2025-01-27 14:54 ` Jon Hunter [this message]
2025-01-27 15:20 ` Petr Mladek
2025-01-27 15:21 ` John Ogness
2025-01-27 16:13 ` Jon Hunter
2025-10-08 15:56 ` John Ogness
2025-10-08 19:21 ` Jon Hunter
2025-10-09 10:04 ` Thierry Reding
2025-10-09 11:49 ` John Ogness
2025-10-09 12:54 ` Petr Mladek
2025-01-07 21:27 ` [PATCH tty-next v5 6/6] serial: 8250: Revert "drop lockdep annotation from serial8250_clear_IER()" John Ogness
2025-01-09 16:13 ` Petr Mladek
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=3e93c665-7603-4b64-a64c-a29079d8d11f@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=esben@geanix.com \
--cc=fancer.lancer@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=schnelle@linux.ibm.com \
--cc=senozhatsky@chromium.org \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.com \
--cc=tony@atomide.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).