Am Dienstag, den 21.03.2017, 14:01 +0100 schrieb Hans de Goede: > Hi, > > On 21-03-17 13:57, Max Staudt wrote: > > > > On 03/21/2017 01:52 PM, Oliver Neukum wrote: > > > > > > Hi Hans, > > > > > > we found on our test systems with a bit of experimentation, > > > that actually running into the timeout is bound to hang the whole > > > system within only a few seconds. > > > I was wondering whether the error handling needs to be changed. > > > > In other words, whether we should rather wait for lock acquisition, > > unconditionally. No timeout, just wait. That's what our hardware > > seems to need. > > > > It feels like once the lock has been requested by the Linux driver, > > we can't cancel that request and have to actually follow through > > with accepting the lock and only giving it back after that. > > Resetting the "request" bit to 0 as it is done now doesn't work as > > it leads to the hung system sometime soon after that. > > Hmm, interesting theory. I would say give it a test and if it > helps then maybe increase the timeouts to say 10 seconds or > such, so that e.g. on poweroff we at least report an error > rather then just sitting there ? I did some testing. Unconditionally taking the error path without waiting for the semaphore crashes or freezes the machine in about 3/4 of all tests. As I said, with a timeout of 500ms, this issue is not seen. Do you have reliable information that the error handling works on BayTrail? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
