On Tue, 2018-11-20 at 15:24 +0100, Ulf Hansson wrote: > On 20 November 2018 at 15:00, Sjoerd Simons > <sjoerd.simons@xxxxxxxxxxxxxxx> wrote: > > On Tue, 2018-11-20 at 14:08 +0100, Ulf Hansson wrote: > > > + Hal Emmerich > > > > > > On 20 November 2018 at 12:38, Sjoerd Simons > > > <sjoerd.simons@xxxxxxxxxxxxxxx> wrote: > > > > On Tue, 2018-11-20 at 11:23 +0100, Wolfram Sang wrote: > > > > So if you know the pattern, or just happen to hit it often in > > > > e.g. > > > > automated testing, it does show up during development. > > > > Otherwise it > > > > can > > > > appear to "happen once in a while randomly". > > > > > > I don't quite follow. As far as I understand, the extended > > > timeout is > > > needed when turning the cache on. > > > > > > The above seems more related to flushing the cache, no? Flushing > > > have > > > no timeout (also reported to be an issue [1]), which happens > > > either > > > at > > > _mmc_hw_reset() or at _mmc_suspend(). > > > > > > What is the relation here? > > > > Yes it's the kinda of behaviour you would expect on a flush indeed! > > I > > don't know what the card actaully does when turning the cache on, > > whether it's actually flush of something persistent when turning > > the > > cache on after a hard poweroff or doing some other validation. > > > > All i can share is what our testing seems to indicate, which is > > that > > there is a wide spread in the time the card needs *and* there seems > > to > > be strong correlation to the I/O activity before the hard power off > > and > > the time taken by "cache on". > > So the hard power off, means that you are cutting the power to the > platform and not doing a graceful power off? Just so I understand > correctly. Correct. With hard power off i mean cutting the power to the board in some way. When doing a gracefull power off, the issue does not occur on my boards (cache on is fast). Presumably as the eMMC got its cache flushed as part of the shutdown procedure.. > > > Using no limit of the timeout, would mean we may hang for ~10 > > > minutes > > > (MMC_OPS_TIMEOUT_MS) instead, no thanks. > > > > Probably a silly question, but would this actually cause e.g. boot > > to > > hang while waiting for the card (assuming rootfs is somewhere > > else)? > > Nope. > > [...] Then i'm probably just being dense, but i'm unsure what the issue is with waiting for 10 minuts in this case. Apart from having to wait for 10 minutes before the user gets an indication in the kernel that the card is not usable? -- Sjoerd Simons Collabora Ltd.
