From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C2CC0267B92 for ; Fri, 23 Jan 2026 12:19:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769170780; cv=none; b=LJmiSyXkSJbQI7N7DqCWaghii+SRnMUNSsAhDQuKa4LAte98AFBQVnVkSRjDurT3wspw03wvXI3pTalIML61dEnKkw1D3KXfDMdr1Wpx5y7p/dMc9EmzNTGv/P0QAZ1CJhCWVETRQ+KwqBpFD/AuVlqal6FRQZ4mLzVFsFEAgzM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769170780; c=relaxed/simple; bh=oZxgIhb/AoBJR9bO4SZ92HOthvqA3QHEBkVQBKLDBdM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=btofiPD6JcOyA5LRiX/s2KljxjFZ5A5CucnZi7AvZNapQ1scOEfMVRQtdv7ubn0dYZptl6v1mjyoXhdElAglV3m7zu5SugHVYRiSgtTMiHlkdPVTv/RU0+KAngTpdt1GSOmQZp6kE0/BUZIOibWTuMZQaDJKzk2RGQysu3ORF1U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=AAB29+Y8; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="AAB29+Y8" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-47ee937ecf2so18440605e9.0 for ; Fri, 23 Jan 2026 04:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769170777; x=1769775577; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZNvR/HokefFGCi702j1R9Nq3MLeLBb8qzhRaEu72y3U=; b=AAB29+Y8muB07gtBjXIGL6OFmcNVTN7xeq0L/NKXrBTCfdekblkw5/k7LGanTC0shh T85iAVm2PCxk6mbhRwngvyjwYWm+ncoP1n/ecpMLq6i3m0C18G78qRAeud4+wHzJ3KR9 7Q5RKaleNLhT29eyLvRwM2He/r9jUWSXoLJyu3CazLiq3q9UrwVlG+lvSbF1yj4e9ezV B5VyxtX8HgmrXzscOVTFDpKRMPFNN1u1nyjq5eeltXyM5ZVW7c+Q2+BJaRHAuxrgZ0zg d3fh+QxX6rC0Kxb9/mWfToFGRFMZ2Wc90/vNj5DBanNBCia1rtugzKTAoX81wnAX2f8D eQeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769170777; x=1769775577; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZNvR/HokefFGCi702j1R9Nq3MLeLBb8qzhRaEu72y3U=; b=hizmpqy6sEGlPqdfyTc8ul8Xa5sBdSI6qhKXD6RMGYOjL3plBS0kFbiAt4iPhn/TYh jEYH+Dw0f6Gl71b0TNBkanf8jTBXnsf8U9tOn9jBaWERZEWTx9UJ2Xv9fDU1XMdxl4ST XHpn5F9WkKuq2/tE5pSyAEa8rl15PGZsCy13MnJRIugNDNdHt4U/UySP/UERpHIBSQvV I8dy/c5yWOOGxUucQvYCPoimItQiR5LLTeQ2N2kq3jqDg6OLEeWK0JI7offKx92zpZ9w FjKUPMmXRHp25aQNlCi1o4GKkRPNBv/XCAlfsHXt6ynrKlm39AAOjMvnsQMerghPEff2 pHew== X-Forwarded-Encrypted: i=1; AJvYcCWcRaZhg7qOKArpo+CVc3HmjLJ93TNhH01d2EeVQHbtjVoGtuDaVDqqK35XJ4Jm14LDQwziZg1LnnX0TpQ=@vger.kernel.org X-Gm-Message-State: AOJu0Yz2mQ041Zl8DAxskUF2CQAOcZU+2tWTrXlo3JjRaWcbNZtQfyVi EvLtiZzW7/1mAr+fokAD4Cjg6629Kvd0S0+JajSigzwxRh9Lwb0ofIQlFBDCxhBGxco= X-Gm-Gg: AZuq6aIvrIJ8jPbWrt7wrUnbkJR7UpHAQQXi7moIxfhvgeXgrMYR/qzGXqEiFwqFXME 4uUXls8fln69voRhFjQVs3a+DtrOzcMbnfh0NJLW+VaHOI3OAX9YpS7nSw3x8c3aNqVExYcoNtS tkUA/Fefc5QX1Z3uNBQCaAW7rh+uhy5VDB9cTwHRddwkJHvFje0/HBudzJlsUOirgoMd20Seryk dbiuhvW11bLkimJk8UOw4cFdumIDS4VVyEh1B0FttzsHuzCh+KHbaAlSoSXc/UYusqBHGxw/ag5 uNwTWn1p0ybCEKeIlvDEMrymzQsmAAnHqLgBgvo+h5VwInA0u8au92GgObOrTCi7HihwmJY+6yS p7IH8/8B01BfJNDWHKqFkG5m3dL/xUxEGjUj16vOa16ddNuUNAHZ8A6pr2gkc11+DPzxmRXAVO8 Kz1V29BUOhqMClig== X-Received: by 2002:a05:600c:524c:b0:479:1348:c63e with SMTP id 5b1f17b1804b1-4804d2ebb31mr45346785e9.9.1769170776973; Fri, 23 Jan 2026 04:19:36 -0800 (PST) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4804d84588fsm54653275e9.2.2026.01.23.04.19.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Jan 2026 04:19:36 -0800 (PST) Date: Fri, 23 Jan 2026 13:19:34 +0100 From: Petr Mladek To: ysard Cc: John Ogness , linux-kernel@vger.kernel.org, senozhatsky@chromium.org Subject: Re: Regression: system freeze on resume from suspend introduced by printk per-console suspended state Message-ID: References: <87tsxhbtxo.fsf@jogness.linutronix.de> <877bts1ltv.fsf@jogness.linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri 2026-01-23 08:44:39, ysard wrote: > Good evening, thank you for your reply and the patch. > > > Summary > ====== > > The patch does not seem to have any effect on the problem, *but* I have found a > way to temporarily fix the freeze by disabling the `nvidia-suspend` service. Great catch! > Additional info for diagnostics > =============================== > > $ cat /proc/driver/nvidia/version > NVRM version: NVIDIA UNIX x86_64 Kernel Module 470.256.02 Thu May 2 14:37:44 UTC 2024 > GCC version: gcc version 12.5.0 (Debian 12.5.0-6) > > $ nvcc --version > nvcc: NVIDIA (R) Cuda compiler driver > Copyright (c) 2005-2019 NVIDIA Corporation > Built on Wed_Oct_23_19:24:38_PDT_2019 > Cuda compilation tools, release 10.2, V10.2.89 > > > Procedure requested > =================== > > > I have attached a patch (based on 6.19-rc4). It should restore the old > > console_lock behavior during suspend/resume. Assuming this works for > > you, it also adds some debugging information so that we can figure out > > who is locking the console. > > I applied the patch. The behavior is the same as before (no resume). > > $ uname -r > 6.19.0-rc4-dirty > > $ dmesg | grep printk > [ 0.030102] [ T0] printk: log buffer data + meta data: 131072 + 458752 = 589824 bytes > [ 0.077779] [ T0] printk: legacy console [tty0] enabled > [ 152.678589] [ T1349] printk: Suspending console(s) (use no_console_suspend to debug) > ... > no resume > > > Temporary solution > ================== > > I had the idea of restarting in recovery mode (rescue.target) to run the test. > The `systemctl suspend` command is not available in this mode, which forced me > to use the `pm-suspend` command, which allows for proper sleep and resume across > all kernel versions that I have been able to test previously. > > Systemd triggers a number of services before actually going into sleep mode, > including a call to nvidia-suspend.service, which I disabled > ("because it's always nvidia"). > > The following command restores normal operation of `systemctl suspend`, > including on the first non-functional commit found by the bisect > (9e70a5e109a4a23367810de09be826c52d27ee2f). > > $ systemctl disable nvidia-suspend.service > > This service calls a script `/usr/bin/nvidia-sleep.sh` that seems to play with > vt consoles and expects that they are still usable (`chvt 63` ?): I did run chvt with strace and it does something like: openat(AT_FDCWD, "/dev/tty0", O_RDWR) = 3 ioctl(3, TCGETS2, {c_iflag=IGNBRK|IGNPAR, c_oflag=NL0|CR0|TAB0|BS0|VT0|FF0|, c_cflag=B38400|CS8|CREAD, c_lflag=, ...}) = 0 ioctl(3, KDGKBTYPE, [KB_101]) = 0 rt_sigaction(SIGALRM, {sa_handler=0x556bcf0418e0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f3e60a42910}, NULL, 8) = 0 timer_create(CLOCK_REALTIME, {sigev_value={sival_int=1668762552, sival_ptr=0x7ffc63774bb8}, sigev_signo=SIGALRM, sigev_notify=SIGEV_SIGNAL}, [0]) = 0 timer_settime(0, 0, {it_interval={tv_sec=1, tv_nsec=0}, it_value={tv_sec=1, tv_nsec=0}}, NULL) = 0 ioctl(3, VT_ACTIVATE, 0x3f) = 0 ioctl(3, VT_WAITACTIVE, 0x3f) = 0 And vt_ioctl(,,VT_ACTIVATE) calls vc_allocate(arg) under console_lock()... The commit 9e70a5e109a4a233 ("printk: Add per-console suspended state") does some changes in console_lock(). It newly sets: console_locked = 1; console_may_schedule = 1; I can't see how this might cause the freeze. Well, for example, it would allow console_conditional_schedule() to get asleep. And it might be harder to obtain the lock when the current owner is sleeping. But it would have an effect only in CONFIG_PREEMPT_VOLUNTARY kernel. The process might get scheduled even without cond_resched() with other CONFIG_PREEMPT modes. Also I would expect that the userspace waits until the services finish the job before suspending the kernel. > #!/bin/bash > > if [ ! -f /proc/driver/nvidia/suspend ]; then > exit 0 > fi > > RUN_DIR="/var/run/nvidia-sleep" > XORG_VT_FILE="${RUN_DIR}"/Xorg.vt_number > > PATH="/bin:/usr/bin" > > case "$1" in > suspend|hibernate) > mkdir -p "${RUN_DIR}" > fgconsole > "${XORG_VT_FILE}" > chvt 63 > if [[ $? -ne 0 ]]; then > exit $? > fi > echo "$1" > /proc/driver/nvidia/suspend > exit $? > ;; > resume) > echo "$1" > /proc/driver/nvidia/suspend > # > # Check if Xorg was determined to be running at the time > # of suspend, and whether its VT was recorded. If so, > # attempt to switch back to this VT. > # > if [[ -f "${XORG_VT_FILE}" ]]; then > XORG_PID=$(cat "${XORG_VT_FILE}") > rm "${XORG_VT_FILE}" > chvt "${XORG_PID}" > fi > exit 0 I just wonder. Could you please try to comment out the various commands here and bisect whether the problem is with "fgconsole", "chvt", or "echo XXX >/proc/driver/nvidia/suspend" commands. I mean to try to disable the counter parts in the suspend/resume code paths and try whether the freeze is still reproducible? > ;; > *) > exit 1 > esac > > > Conclusion > ========== > > kernel nvidia-suspend (systemd 259~rc1-1) result > < 9e70a5e109a4 enabled ok > < 9e70a5e109a4 disabled ok > >= 9e70a5e109a4 enabled freeze > >= 9e70a5e109a4 disabled ok > > - Reactivating this service causes the freeze to reappear in a reproducible pattern. > - The `pm-suspend` command has never stopped working. > > It seems that this is a two-sided problem? > If the kernel is not the issue, I apologize and am sorry for wasting your time; > I should have thought about the layers added by systemd sooner. There is no need to apologize. It seems to be somehow affected by the kernel commit. And it would be great to understand what is going on. > Extra > ===== > > During my tests with 6.19.0-rc1 and 6.19.0-rc4, I noticed that resuming a sleep > test that used to work now fails (it worked in 6.18.2), but I think this is > unrelated and is due to another issue. I am noting this for historical purposes. > > $ echo core > /sys/power/pm_test > $ echo deep > /sys/power/mem_sleep > > Both commands `pm-suspend` or `systemctl suspend` have the same effect: > > - Trigger suspend (`kernel: PM: suspend entry (deep)` in dmesg); > - No response when pressing the power button to wake up; > - Force shutdown by holding down the power button; > - The computer shuts down but the motherboard indicates a state similar to > sleep mode (LED flashing); > - Pressing the power button starts the computer (fans + HDD spin up) for a > fraction of a second (<1s) then the machine shuts down; > - Pressing the power button starts the machine normally > (not a resume from sleep mode). This would deserve a separate thread. It would be great if you could bisect it to the problematic commit. Best Regards, Petr