Hi Joey, On 07/23/2017 05:18 AM, joeyli wrote: > 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? I cannot remember what I mentioned in 2013. Could you tell me url of lkml archive. Thanks, Yasuaki Ishimatsu >> >> 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
