Bug 1248152
| Summary: | systemd detects backlight (and fails to manipulate it) when no backlight exists | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jason Tibbitts <j> | ||||
| Component: | systemd | Assignee: | systemd-maint | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 22 | CC: | hdegoede, johannbg, jsynacek, lnykryn, msekleta, s, systemd-maint, zbyszek | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-07-19 17:15:25 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Hi All, So what I believe is happening here is that the involved Asus mainboards suffer from a known Asus issue where Asus exports an acpi-video backlight interface on desktop/server mainboards. The kernel has special Asus specific code to deal with this in drivers/platform/x86/asus_wmi.c, which unregisters the acpi-video backlight if it has already registered and sets a flag telling the acpi-video code to not register it later on. So depending on module load ordering the acpi-video0 backlight sysfs interface may briefly appear during module loading. Note that this is not unique to Asus. many of the vendor specific drivers/platform/x86/vendor-foo.c drivers do the same. It was decided long ago to have vendor specific handling in vendor specific drivers even if it involves removing the acpi-backlight interface because it is know to be broken for certain boards of that vendor. I realize that this far from ideal from a systemd pov, but there is very little we can do about this in the kernel (if only firmware did not suck ...), so it would be good if a workaround could be added to systemd to not consider it a failure when an acpi_video# backlight interface disappears underneath it. Regards, Hans We should be able to deal with hardware going away at any time (for example being unplugged). So we should ignore missing devices in general. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 1057376 [details] dmesg I'm having an issue with a large number of desktops where systemctl status will show the state as "degraded" because systemd-backlight@backlight:acpi_video0.service fails at boot time. systemctl status shows: Jul 28 12:53:00 ld61.e.math.uh.edu systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0... Jul 28 12:53:00 ld61.e.math.uh.edu systemd[1]: systemd-backlight@backlight:acpi_video0.service: main process exited, code=exited, status=1/FAILURE Jul 28 12:53:00 ld61.e.math.uh.edu systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video0. Jul 28 12:53:00 ld61.e.math.uh.edu systemd[1]: Unit systemd-backlight@backlight:acpi_video0.service entered failed state. Jul 28 12:53:00 ld61.e.math.uh.edu systemd[1]: systemd-backlight@backlight:acpi_video0.service failed. Now, /sys/class/backlight is empty, so I'm not sure what method systemd is using to detect a backlight. I've attached dmesg output. Hans suggested that there might be a race where a backlight exists momentarily only to be removed after systemd has already failed to manipulate it, and from looking at the kernel log it does appear to be a possibility. He asked me to file this ticket and CC him.