Pavel Herrmann wrote:

On Thursday, June 30, 2011 04:45:18 PM Stanislav Brabec wrote:

quoted

Then I tried to apply "[PATCH] MAX1111: Fix race condition causing NULL

quoted

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