You are not logged in.
Hello,
I just updated to 210 and rebooted as soon as possible as advised. The first thing I noticed is the red [Failed] message during startup. After looking at systemctl I noticed that systemd-backlight@backlight:eeepc-wmi.service fails. There are 3 things wrong with this 1) I don't have a backlight this is on a desktop 2) It's not an eeePC 3) I never had any failed services before the update. I tried to disable this service, but the service still tries to start and fails on every boot. I read about systemd-backlight here: http://www.freedesktop.org/software/sys … rvice.html but it doesn't really help much to explain why it tries to load this service in the firstplace. I have not tried masking it, but this would not fix the underlying problem anyway.
The systemctl status doesn't provide any usful information.
systemd-backlight@backlight:eeepc-wmi.service - Load/Save Screen Backlight Brightness of backlight:eeepc/wmi
Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static)
Active: failed (Result: exit-code) since Di 2014-03-04 18:51:41 CET; 20min ago
Docs: man:systemd-backlight@.service(8)
Process: 185 ExecStart=/usr/lib/systemd/systemd-backlight load %I (code=exited, status=1/FAILURE)
Main PID: 185 (code=exited, status=1/FAILURE)
Mär 04 18:51:41 archbox systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:eeepc/wmi...
Mär 04 18:51:41 archbox systemd[1]: systemd-backlight@backlight:eeepc-wmi.service: main process exited, code=exited, status=1/FAILURE
Mär 04 18:51:41 archbox systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:eeepc/wmi.
Mär 04 18:51:41 archbox systemd[1]: Unit systemd-backlight@backlight:eeepc-wmi.service entered failed state.
Regards,
blackout23
Last edited by blackout23 (2014-03-07 01:24:29)
Offline
You're not alone. I have the same problem, though Google really doesn't show anyone else who does. What's your hardware situation look like?
Here's my lcpci:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4)
00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 6 (rev c4)
00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
01:00.0 PCI bridge: PLX Technology, Inc. Device 8747 (rev ba)
02:08.0 PCI bridge: PLX Technology, Inc. Device 8747 (rev ba)
02:10.0 PCI bridge: PLX Technology, Inc. Device 8747 (rev ba)
03:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 680] (rev a1)
03:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)
05:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
06:04.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio]
07:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6315 Series Firewire Controller (rev 01)
08:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
09:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
0a:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
Last edited by dhaines (2014-03-05 01:37:50)
Offline
I assume the backlight service is triggered if the eeepc-wmi kernel module is loaded.
Blacklisting it and some of its friends stops the service loading. I've never understood why these modules were loaded on a desktop machine and blacklisting has caused no problems so far (but it might).
cat /etc/modprobe.d/blacklist.conf
blacklist asus-wmi
install asus-wmi /bin/false
blacklist button
install button /bin/false
blacklist eeepc-wmi
install eeepc-wmi /bin/false
blacklist mxm-wmi
install mxm-wmi /bin/false
blacklist rfkill
install rfkill /bin/false
blacklist sparse-keymap
install sparse-keymap /bin/false
blacklist video
install video /bin/false
blacklist wmi
install wmi /bin/false
Have a look at hwdetect --show-modules and mkinitcpio -M for some clues.
Offline
I'm also experiencing the same problem (I did a system update yesterday).
I'm also on a desktop machine.
Offline
I have the same problem.
I'm on a desktop computer that's been running the same installation of Arch since November 2012 and no problem so far with systemd services until this eeepc-wmi.service popped up with an error today.
Offline
Thanks for the answers guys!
Here's my lspci:
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
00:1c.6 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation Z68 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 580] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF110 High Definition Audio Controller (rev a1)
03:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller
05:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)
Motherboard is ASUS P8Z68-V Pro. The eeepc_wmi kernel module gets loaded for whatever reason, but that didn't cause any issues with the older systemd versions obviously.
Last edited by blackout23 (2014-03-05 22:38:28)
Offline
Motherboard is ASUS P8Z86-V Pro. The eeepc_wmi kernel module gets loaded for whatever reason, but that didn't cause any issues with the older systemd versions obviously.
And mine is an ASUS P8Z77 WS. A trend perhaps? Anyone else?
Offline
z87 deluxe, same problem since last update
Offline
I'm seeing this error too after the last update. Prior to the update, there where some informational entries about my ASUS EEE PC in my desktop's logs. I have the EEE PC plugged into the same KVM as my desktop and just attributed my desktop seeing the EEE PC because of this.
I solved the boot failures by blacklisting eeepc-wmi. I did this by creating /etc/modprobe.d/disable-eeepc.conf containing
blacklist eeepc-wmi
and then running
$ sudo mkinitcpio -p linux
I'm new to Arch, so take this with a grain of salt, but I think the issue is because udev detects the device and the new version of systemd is trying to start relevant services for it. Blacklisting it from udev will stop systemd from trying to start the backlight service. Blacklisting it stopped the failure messages on my system. It also stopped the informational log messages that I was getting. Hope this helps someone.
EDIT: I guess this is a coincidence. My motherboard is also an ASUS. Just so happens that I also own a EEE PC. Sorry for any confusion.
Last edited by 0strodamus (2014-03-06 15:35:19)
archlinux | OpenRC | TOMOYO Linux | Xfce
"In his house at R'lyeh dead Cthulhu waits dreaming."
Offline
And mine is an ASUS P8Z77 WS. A trend perhaps? Anyone else?
My motherboard is an Asus P8Z77-M PRO. I see a pattern.
Offline
P8Z68-V LX here with the same issue.
Offline
Same with virtually any Asus board. I think the kernel mistakes any Asus for an eeepc.
Offline
Funny. While the service does not fail on my EeePC, I have been unable to change the backlight since two kernel versions or so. What can I provide to help?
Offline
Same with virtually any Asus board. I think the kernel mistakes any Asus for an eeepc.
Yes but that never was a problem until systemd 210.
Offline
I also have an ASUS mobo (M5A99X EVO) and also get the backlight fail message.
Strange things is until this update I has a completely silent boot but not anymore. Now I get a screenfull of systemd messages after the backlight fail even though the backlight service is the only one that fails.
Last edited by KairiTech (2014-03-06 15:16:43)
Offline
Strange things is until this update I has a completely silent boot but not anymore. Now I get a screenfull of systemd messages after the backlight fail even though the backlight service is the only one that fails.
A failed service now automatically enables verbose output.
Offline
I had the same issue with an ASUS Sabertooth 990FX.
Blacklisted eeepc-wmi
Time you enjoy wasting isn't wasted time.
Offline
I'd much rather find out what causes this problem than just to deal with the symptoms.
Offline
Have you filed a bug report? I tried searching, but couldn't find one.
archlinux | OpenRC | TOMOYO Linux | Xfce
"In his house at R'lyeh dead Cthulhu waits dreaming."
Offline
I'd much rather find out what causes this problem than just to deal with the symptoms.
Cause 1: The unit is incorrect http://lists.freedesktop.org/archives/s … 17664.html (this causes the actual error message).
Cause 2: The eeepc-wmi driver gets loaded on any Asus board, eeepc or not. Even if the above error is fixed, udev will still try to configure the backlight on boot (max brightness is 0, so there is no effect, but it takes time). I guess the kernel should not export a backlight device unless you are actually on an eeepc.
EDIT: And the patch is merged for systemd 211: http://cgit.freedesktop.org/systemd/sys … f092ef1e5a
Last edited by brain0 (2014-03-07 09:08:54)
Offline
with systemd 211 the bug is fixed;
systemd-backlight@backlight:eeepc-wmi.service loaded active exited Load/Save Screen Backlight Brightness of backlight:eeepc-wmi
But I don't have an eeepc after all. Just an ASUS P8P67 motherboard. So why is it loaded anyways?
Offline
The eeepc-wmi driver is loaded on pretty much all Asus hardware. This is weird, but it is, after all, a kernel issue.
Offline
Are there any downsides to leaving the eeepc-wmi driver blacklisted?
archlinux | OpenRC | TOMOYO Linux | Xfce
"In his house at R'lyeh dead Cthulhu waits dreaming."
Offline
Are there any downsides to leaving the eeepc-wmi driver blacklisted?
If I blacklist it then fancontrol does not find correctly enumeration of the fans!
Btw this error came back since today's upgrade of systemd!
Before it was working with the fix brain0 said, but now even with this fix the fail shows up at boot!
Offline
Different error this time, and I have an idea why.
* When restoring the screen brightness at boot, stay away from
the darkest setting or from the lowest 5% of the available
range, depending on which is the larger value of both. This
should effectively protect the user from rebooting into a
black screen, should the brightness have been set to minimum
by accident.
In our situation, there is only one setting: 0. Hence this error:
Mär 27 22:56:46 lije systemd-backlight[382]: Failed to write system attribute: Invalid argument
EDIT: Fixed it (again): http://lists.freedesktop.org/archives/s … 18259.html
Last edited by brain0 (2014-03-27 22:54:30)
Offline