From the description it's pretty clear the issue is specific to Lite-on SSDs. Did they already reach out to Acer?

They have a big fleet with those SSDs, so they don't want to start with RMA yet. And this issue only started with v63

kathrelkeld@/krishnargv@, do you have the same device model in our setup to check if the issue is reproducible?

Hi all,

Do we have any updates on this issue?

Thanks!

We've had the same issue from v62 - 65.0.3325.65. 

V61 looks like it's working okay, but obviously that's a temp fix. 

Hi kathrelkeld@, 
Do you have any updates?

Hi kathrelkeld@, 
In email "Paine with Lite-on SSD" looks like we cannot find any device with Lite-on ssd here. What else can we do with it, does it make sense to request affected device from customer then?

Another customer reported a similar issue on a Chromebase (buddy). 
Error in /var/log/messages:

[    5.347702] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   34.752670] ata1.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6 frozen
[   34.752695] ata1.00: failed command: WRITE FPDMA QUEUED
[   34.752717] ata1.00: cmd 61/10:00:10:28:89/01:00:00:00:00/40 tag 0 ncq 139264 out
                        res 40/00:00:e0:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
[   34.752746] ata1.00: status: { DRDY }
[   34.752758] ata1.00: failed command: WRITE FPDMA QUEUED
[   34.752777] ata1.00: cmd 61/a8:08:c8:15:db/00:00:00:00:00/40 tag 1 ncq 86016 out
                        res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[   34.752805] ata1.00: status: { DRDY }
[   34.752824] ata1: hard resetting link
[   35.017754] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   35.020973] ata1.00: configured for UDMA/133
[   35.021017] ata1.00: device reported invalid CHS sector 0
[   35.021056] ata1: EH complete

SSD info related to comment #9:

ATA device, with non-removable media
	Model Number:       LITEON LST-16S9G                        
	Serial Number:      4
	Firmware Revision:  ZS21202 
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0

Changed summary as we now have reports from multiple device models.

@mpricone, can you add a link to the logs you reviewed? Also, customer mentioned the issue started when they updated Buddy from M53 to M64, right?

@kbleicher, can you help route this bug to appropriate Eng team?

One more customer with buddy with Liteon on 62,63,64,65.

Maybe we can request customer in #1 (as device is paine, which is smaller than buddy) to send us one affected device, so since it's software issues, we could bisect to at which change it was broken?

Hello,

I am the original customer that reported the issue in #1 to Google Support. The update to 65 stable seems to have resolved the issue, with the fix for  bug 697805  seeming to be what fixed it. (The issue was present in 65 dev but seems fixed in 67 dev).

Going to about:system > storage_info and scrolling down shows "smartctl -x /dev/sda" on affected versions (with Liteon SSD) and "smartctl -a -f brief /dev/sda" on fixed versions (with Liteon SSD).

Also, the Acer C740s with manufacture date 2015-2016 seem to all have Kingston SSDs, where those manufactured in 2017 (and ones with dead SSDs replaced by RMA) have the affected Liteon SSD.

I am not sure if this could be related but we seem to be struggling with a similar issue with our Dell Chromebook 13 lulu devices.  It seems all (or most) of our devices are using Sandisk SSDs and we have had a good amount of users report frequent lockups.  As in everything is fine and then everything freezes for 30 seconds and then everything is fine again.  

We have replaced the ssd with the a different brand and it seems to have fixed the problem.  I can confirm our problems still exist in 65.  I think we have had too many cases of this issue for it to be hardware, we are likely looking at a software issue causing this as well.  

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

Based on comment 13 seems like it may be resolved in 65. And we havne't seen more incidents around this bug since. Closing the bug. If this is still an issue, lets create a new bug with new details and mention this bug in it.