Pavel Herrmann wrote: > On Thursday, June 30, 2011 04:45:18 PM Stanislav Brabec wrote: > > Then I tried to apply "[PATCH] MAX1111: Fix race condition causing NULL > > > So I guess that MAX1111 AC voltage reading (via SPI) was involved in an > > incorrect moment and race happened there and your MAX1111 race condition > > fix fixes it.
> Are you using the first or second version of the patch? if the former, please > use v2 (sent a few days later), which has solved the same problem by using a > mutex instead of allocating message data on stack (which is not good for DMA) I guess the second one with mutex. This is my work-in-progress-mix patch: http://www.penguin.cz/~utx/zaurus/feed/images/spitz/zImage-3.0.0-rc5+-spitz.diff Several hours later, charging was turned on/off at least 1000 times without any crash. So it seems that it was the correct race condition fix. > as for the backstory, this crash ocurrs when a short (measured in time spent) > message was enqueued after a long message, so that the short one finished > first > (the actual bug was present even if the long one finished first, but in that > case there was double complete() on the one completion instead of a NULL > dereference) I guess that inserting of power supply initiates reading of voltages on MAX1111. The long one may be touchscreen or LCD control. -- Stanislav Brabec http://www.penguin.cz/~utx ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
