[Bug 1095700] New: setterm reports "cannot (un)set powersave mode: Inappropriate ioctl for device"
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 Bug ID: 1095700 Summary: setterm reports "cannot (un)set powersave mode: Inappropriate ioctl for device" Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: per@computer.org QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Trying to re-establish screen blanking and power saving for virtual consoles on machines without X, I am trying to use "setterm -powersave on". This works on some machines, but not on others. I have added the following drop-in: /etc/systemd/system/getty\@.service.d/powersave.conf [Service] Environment=TERM=linux ExecStartPost=-/usr/bin/setterm -powersave on >/dev/%I ExecStartPost=/usr/bin/setterm -blank 2 -powerdown 5 >/dev/%I I have split the setterm into two, because the 'powersave on' keeps fasiling and reporting "cannot (un)set powersave mode: Inappropriate ioctl for device". If I run it when logged into a console, it does not complain, but it also doesn't work. On older openSUSE, e.g. 12.3, it works, but I'm wondering if it might be a graphics driver issue? Maybe also refer to bug#1094452 which prompted me to look for a solution. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c2 Per Jessen <per@computer.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |per@computer.org Flags| |needinfo?(per@computer.org) --- Comment #2 from Per Jessen <per@computer.org> --- (In reply to Takashi Iwai from comment #1)
Possibly a race condition, you're trying to issue an ioctl while switching the fbcon from VESA to the KMS one?
Uh, I don't know - I'm just amending the tty service with those setterms.
Does it happen if you boot with nomodeset to prevent the native graphics switching?
I'll try that. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c3 Per Jessen <per@computer.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(per@computer.org) | --- Comment #3 from Per Jessen <per@computer.org> --- (In reply to Per Jessen from comment #2)
(In reply to Takashi Iwai from comment #1)
Possibly a race condition, you're trying to issue an ioctl while switching the fbcon from VESA to the KMS one?
Uh, I don't know - I'm just amending the tty service with those setterms.
Does it happen if you boot with nomodeset to prevent the native graphics switching?
I'll try that.
using nomodeset does not seem to have any impact. Same error message from setterm. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c4 --- Comment #4 from Per Jessen <per@computer.org> --- Have just tried the same setup on a new install, Leap15. Different graphics, ATI Rage XL. Same result. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c5 --- Comment #5 from Per Jessen <per@computer.org> --- On different hardware again - with Leap15.1, the power saving mode still does not work. This afternoon, this system (office33) was upgraded from 13.1 (32bit) to Leap151. prior to which the correct powersaving mode could be observed. Regression .... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c6 --- Comment #6 from Takashi Iwai <tiwai@suse.com> --- This looks rather like the invocation problem. The redirection to the stdio isn't enough for setting the option for setterm. For example, try to change -powersave option for /dev/tty1 from an X terminal. The command line you gave would give the very same error. I guess it looked as if working in the past although it had no real effect... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c7 --- Comment #7 from Per Jessen <per@computer.org> --- Is there any other way of re-establishing the screen blanking and power-save on virtual consoles? It works fine on older systems, e.g. with 13.x. I just thought the 'setterm' utility would help. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c8 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrabec@suse.com Assignee|kernel-maintainers@forge.pr |bnc-team-screening@forge.pr |ovo.novell.com |ovo.novell.com --- Comment #8 from Takashi Iwai <tiwai@suse.com> --- setterm should work if it's invoked properly, I guess. Since you could run setterm properly on the actual VT, it must be the problem of the command invocation from the unit file at the boot time. That is, it's not really a kernel problem. I guess you could get a better answer by asking other parties like systemd guys. Or maybe util-linux maintainer has a better clue. Stanislav? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c9 Stanislav Brabec <sbrabec@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED --- Comment #9 from Stanislav Brabec <sbrabec@suse.com> --- I can confirm that "setterm --blank force" does nothing. I just debugged it. It really sends ioctl(STDIN_FILENO, TIOCLINUX, &ioctlarg) According to the code, ioctlarg = 14. It seems to be correct. This setterm code did not change since 2014. => Virtual console blanking seems to be broken in the kernel. Are vesa_blank_mode and vesa_off_interval effective in the recent virtual console? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c10 --- Comment #10 from Takashi Iwai <tiwai@suse.com> --- (In reply to Stanislav Brabec from comment #9)
I can confirm that "setterm --blank force" does nothing.
Which graphics driver did you test? The behavior seems depending on the driver. For example, it works for VT with nouveau. Meanwhile it's been broken for most of QEMU graphics, AFAIK. And now testing with an i915 machine, it doesn't seem working, either. Hmm. I remember that I've tried to address some screen blank issues, but the upstream didn't take it because there were quite rewrites of the code and the whole DPMS handling was being changed at that time: https://marc.info/?l=dri-devel&m=150110261705295&w=2 Maybe we need to revisit the issues again. In anyway, the broken behavior of setterm --blank, especially if it's really a regression, should be handled in the upstream bugzilla. It's clearly an upstream issue. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c11 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tzimmermann@suse.com --- Comment #11 from Takashi Iwai <tiwai@suse.com> --- Adding Thomas to Cc, as he's been working on drm fb stuff recently. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c12 --- Comment #12 from Stanislav Brabec <sbrabec@suse.com> --- I have "radeon" kernel module loaded. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c13 --- Comment #13 from Per Jessen <per@computer.org> --- When I reported the original issue in bug#1094452, it was module 'xgifb', but same behavior with 'i915'. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c14 --- Comment #14 from Takashi Iwai <tiwai@suse.com> --- Note that there are a few issues here. The original problem, the error from setterm invocation, is likely rather a user-space problem, i.e. possibly some incorrect invocation. OTOH, another problem, the non-working blank despite of setterm command, is a kernel problem, and this strongly depends on the framebuffer driver (and KMS driver, too). This needs to be addressed in the kernel upstream. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c15 --- Comment #15 from Per Jessen <per@computer.org> --- (In reply to Takashi Iwai from comment #14)
Note that there are a few issues here.
The original problem, the error from setterm invocation, is likely rather a user-space problem, i.e. possibly some incorrect invocation.
OTOH, another problem, the non-working blank despite of setterm command, is a kernel problem, and this strongly depends on the framebuffer driver (and KMS driver, too). This needs to be addressed in the kernel upstream.
Agree - and the former is only an attempt to work around the latter. So as soon as the kernel problem is fixed, the user-space issue also goes away :-) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c17 --- Comment #17 from Per Jessen <per@computer.org> --- Have just tried the same on Leap 15.3, kernel 5.3.18-52-default. Same result: setterm[1735]: setterm: cannot (un)set powersave mode: Inappropriate ioctl for device -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c18 --- Comment #18 from Takashi Iwai <tiwai@suse.com> --- The powersave option isn't supported on modern drivers, I suppose. But "setterm --blank force" works, right? I noticed that the blanking doesn't work on QEMU graphics except for virtio. I'm going to resubmit a fix patch to the upstream. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c19 --- Comment #19 from Takashi Iwai <tiwai@suse.com> --- (In reply to Takashi Iwai from comment #18)
The powersave option isn't supported on modern drivers, I suppose.
Or do you mean invocation of the unit file as you tested in the past? This won't work, per design. It's racy with the dynamic VT allocation by systemd. Here, the question is whether setterm manual invocation works and is effective on the newer kernels. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1095700 http://bugzilla.opensuse.org/show_bug.cgi?id=1095700#c20 --- Comment #20 from Per Jessen <per@computer.org> --- (In reply to Takashi Iwai from comment #19)
(In reply to Takashi Iwai from comment #18)
The powersave option isn't supported on modern drivers, I suppose.
Or do you mean invocation of the unit file as you tested in the past? This won't work, per design. It's racy with the dynamic VT allocation by systemd.
Aha, okay - yes, I was trying to use that.
Here, the question is whether setterm manual invocation works and is effective on the newer kernels.
Directly on the console: setterm --blank force - works. setterm --blank=1 - works. setterm --powersave on - no complaints setterm --powerdown=1 - no complaints, but does not work. -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply＠novell.com -
bugzilla_noreply＠suse.com