Cannot get SD card (ntfs and exFAT) data after resuming from suspend |
||||
Issue descriptionReproduced with multiple platforms/devices - samus, link, chell, minnie M52, M53, M55 What steps will reproduce the problem? 1.Insert SD card 2.Play video in SD card 3.Lid close to let system go into s3 or s0ix 4.Lid open What is the expected output? The SD data can be seen. The video should continues playing What do you see instead? SD data cannot be seen after choose Download file and choose SD card back again. The video stop playing after several seconds. From yamaguchi@google.com: Mounting of ntfs and exFAT seems to be the key condition of repro. The filesystem mount seems to be in a wrong state when this happens. (In this log, "ntfs" is the volume label name of the partition) << after repro >> chronos@localhost / $ mount | grep ntf /dev/sdb1 on /media/removable/ntfs type fuseblk (rw,nosuid,nodev,noexec,relatime,dirsync,user_id=300,group_id=300,default_permissions,allow_other,blksize=4096) chronos@localhost / $ ls /media/removable/ntfs ls: cannot access /media/removable/ntfs: Transport endpoint is not connected << when working correctly >> chronos@localhost / $ mount | grep ntf /dev/sdb1 on /media/removable/ntfs type fuseblk (rw,nosuid,nodev,noexec,relatime,dirsync,user_id=300,group_id=300,default_permissions,allow_other,blksize=4096) chronos@localhost / $ ls /media/removable/ntfs elephants-dream.webm
,
Sep 13 2016
When Chrome tries to unmount an exFAT-formatted SD drive before the system goes into suspsend, it does so by instructing cros-disks to force unmount (see kDefaultUnmountOptions in CrosDisksClient::Unmount) the mounted drive. This seems to cause mount.exfat-fuse process to terminate and leave the FUSE pipe broken on one side. The broken mount point can be removed by running umount() again. Instead of force mounting the drive, I wonder if it's better to do lazy umount in this case. The mount.exfat-fuse process may still terminate due to I/O error after the SD drive loses power during suspend, but the mount entry should have been removed.
,
Sep 22 2016
This seems not very good UE. Any chance to increase priority abd target this on M55 or M54? Thanks.
,
Sep 22 2016
Need more testing, but this could be an interim solution for M54 / M55: https://chromium-review.googlesource.com/c/388592/
,
Oct 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/platform2/+/2ebd3d61bc6b409fd7e460df81a7ba9a9f8f5c12 commit 2ebd3d61bc6b409fd7e460df81a7ba9a9f8f5c12 Author: Ben Chan <benchan@chromium.org> Date: Thu Sep 22 18:53:49 2016 cros-disks: improve handling of unmounting busy devices The USB or SD drive on some system may be powered off after the system goes into the S3 suspend state. To avoid leaving a mount point in a stale state while its associated physical drive is gone, the cros-disks client on the Chrome side unmounts all the mount points it manages before the system goes into suspend. However, an ongoing filesystem access may keep a mount point busy, which is beyond the control of Chrome or cros-disks. We used to force umount the mount points but that has become undesirable. For instance, when force unmounting a mount point backed by a FUSE process, umount2() reports an error and the mount point is left in a half-broken state. This CL changes how DiskManager handles unmounting of busy devices. The force option instructed by Chrome is filtered out. Instead, DiskManager first tries to perform a normal unmount. If that fails because of the device being unmounted is busy, DiskManager retries with a lazy unmount before giving up and reporting an error. BUG= chromium:646224 TEST=Tested the following: 1. Build and run unit tests. 2. Run platform_CrosDisksDBus and platform_CrosDisksFilesystem. 3. Manually copy a big file to a mounted USB / SD drive, put the system in S3 suspend before the copy operation completes, resume the system and observe that the USB / SD drive is remounted correctly by Files.app. Also observe /var/log/message to confirm that cros-disks retried a lazy unmount on the drive before the system went into suspend. Change-Id: I51a645e8cb063b5a2725ce365d2a8428f4959474 Reviewed-on: https://chromium-review.googlesource.com/388592 Commit-Ready: Ben Chan <benchan@chromium.org> Tested-by: Ben Chan <benchan@chromium.org> Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> [modify] https://crrev.com/2ebd3d61bc6b409fd7e460df81a7ba9a9f8f5c12/cros-disks/disk_manager.cc
,
Oct 3 2016
,
Oct 7 2016
,
Oct 10 2016
Just for the record, a duplicate: https://crosbug.com/p/50715
,
Oct 22 2016
Verified on ChromeOS 8872.19.0, 55.0.2883.22 |
||||
►
Sign in to add a comment |
||||
Comment 1 by satorux@chromium.org
, Sep 13 2016