http://bugzilla.suse.com/show_bug.cgi?id=1078358 http://bugzilla.suse.com/show_bug.cgi?id=1078358#c20 --- Comment #20 from Mario Goppold <mgoppold@web.de> --- (In reply to Joey Lee from comment #18)
(In reply to Mario Goppold from comment #16)
(In reply to Joey Lee from comment #13)
(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.
In kernel ACPI subsystem, it emits CHANGE event to userland to indicate that the device will be removed. Then userland should performs necessary cleaning job and offline the children devices.
The "udevadm trigger" didn't get side effect before because udev doesn't have rule to handle the CHANGE event. I was curious why the "udevadm trigger" must be performed after adding a new rule?
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?
We have tested this rule for handling the CHANGE event on Kunlun, but this behavior doesn't specific on Kunlun. The CHANGE event is used by ACPI container in kernel that it should be handled by user space.
Please aware that the "udevadm trigger" will emit CHANGE event to ALL devices. Which means that all udev rules that handle CHANGE event will be performed.
The 80-hotremove-acpi-container.rules is a default rule for ACPI container offline. I will update the comment of the rule to mention that how to disable it.
OK, I understand the changes and also that "udevadm trigger" globally triggers events that may not be wanted. The use case for a trigger is: plug a device and realize that it was not correctly initialized. Add a useful udev rule and you dont want to go downstairs to unplug and plug the device again. In such caces I will restrict the trigger to the devices I wand to change, for example: udevadm trigger --verbose --type=devices --subsystem-match=usb For me, the incident is complete. Are there any objections? -- You are receiving this mail because: You are on the CC list for the bug.