Hi Yasuaki, On Fri, Jul 14, 2017 at 10:44:14PM +0800, joeyli wrote: > On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote: > > On Thu 13-07-17 20:45:21, Joey Lee wrote: > > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote: > > > > On Thu 13-07-17 14:58:06, Joey Lee wrote: > > [...] > > > > > If BIOS emits ejection event for a ACPI0004 container, someone needs > > > > > to handle the offline/eject jobs of container. Either kernel or user > > > > > space. > > > > > > > > > > Only sending uevent to individual child device can simplify udev rule, > > > > > but it also means that the kernel needs to offline/eject container > > > > > after all children devices are offlined. > > > > > > > > Why cannot kernel send this eject command to the BIOS if the whole > > > > container is offline? If it is not then the kernel would send EBUSY to > > > > > > Current kernel container hot-remove process: > > > > > > BIOS -> SCI event -> Kernel ACPI -> uevent -> userland > > > > > > Then, kernel just calls _OST to expose state to BIOS, then process is > > > stopped. Kernel doesn't wait there for userland to offline each child > > > devices. Either BIOS or userland needs to trigger the container > > > ejection. > > > > > > > container is offline? If it is not then the kernel would send EBUSY to > > > > the BIOS and BIOS would have to retry after some timeout. Or is it a > > > > > > The d429e5c122 patch is merged to mainline. So kernel will send > > > DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice > > > to apply the retry approach until OS returns process failure exactly or > > > BIOS timeout. > > > > > > > problem that currently implemented BIOS firmwares do not implement this > > > > retry? > > > > > > Yes, we should consider the behavior of old BIOS. Old BIOS doesn't > > > retry/resend the ejection event. So kernel or userland need to take the > > > retry job. Obviously userland runs the retry since the caa73ea15 patch > > > is merged. > > > > > > IMHO there have two different expectation from user space application. > > > > > > Applications like DVD player or Burner expect that kernel should > > > info userspace for the ejection, then application can do their cleaning > > > job and re-trigger ejection from userland. > > > > I am not sure I understand the DVD example because I do not see how it > > fits into the container and online/offline scenario. > > > > At least Yasuaki raised similar behavior for container in 2013. > It's similar to the DVD player case, user space application needs > to do something then trigger children offline and ejection of > container. > > Base on Yasuaki's explanation, the reason of that he requested the > userland ejection approach is that he got memory hot-remove problem > in 2013. Maybe his problem is already fixed by your patches in current > mainline. > > Hi Yasuaki, could you please check that your memory hot-remove problem > is fixed on mainline kernel? > > If Yasuaki's issue is already fixed, then we should consider to let > kernel does the container hot-remove transparently. Could you please help to check that your memory hot-remove problem in 2013 is fixed on mainline kernel? Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
