http://bugzilla.suse.com/show_bug.cgi?id=1078358
http://bugzilla.suse.com/show_bug.cgi?id=1078358#c16
--- Comment #16 from Mario Goppold
(In reply to Mario Goppold from comment #10)
(In reply to Joey Lee from comment #9)
(In reply to Mario Goppold from comment #8)
Here is my Log:
virtserv2:~ # mv /usr/lib/udev/rules.d/80-acpi-container-hotplug.rules _usr_lib_udev_rules.d_80-acpi-container-hotplug.rules virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo 24 virtserv2:~ # udevadm trigger --verbose > udevadm_trigger.log 2>&1 virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo 24 virtserv2:~ # mv _usr_lib_udev_rules.d_80-acpi-container-hotplug.rules /usr/lib/udev/rules.d/80-acpi-container-hotplug.rules virtserv2:~ # udevadm trigger --verbose > udevadm_trigger_2.log 2>&1 virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo 4 virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo 1
The Logfiles udevadm_trigger.log and udevadm_trigger_2.log looks like the first attachment and does not differ.
I have checked the src/udev/udevadm-trigger.c code in systemd. It makes sense for "udevadm trigger" triggers the CHANGE event to container because "change" is the default action for "udevadm trigger".
If you still want to use "udevadm trigger" but do not want the 80-hotremove-acpi-container.rules to be triggered. Please run:
$ ln -s /dev/null /etc/udev/rules.d/80-hotremove-acpi-container.rules
yes, I moved the file away and everything will be ok till the next udev-update. I think the rule should be much more special than it is now, maybe with vendor or SUBSYSTEM!="cpu" or ...
The "udevadm trigger" triggers CHANGE event to _all_ devices. Why you want to do that after you add a rule about USB?
On your machine, there have ACPI0004 container that it collects CPUs. If you trigger CHANGE event to container from user space, then the children devices (CPUs in this case) will be offline by the 80-hotremove-acpi-container rule. Why you want to trigger CHANGE event to all devices?
Because I did not know that it would be necessary to limit to a subsystem and over the years I have not seen such behavior. 8 out of 10 search results for udev reload do not mention the need for any restrictions. Once again: In the comment of the rule stand: "ACPI0004 container offline for Huawei Kunlun" but I can not see that the actual rule reflect these specific machine. Have this no vendor id? -- You are receiving this mail because: You are on the CC list for the bug.