Comment # 18 on bug 1078358 from Joey Lee

(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.