[PATCH 1/2] mtdoops: do not schedule work if we are going to die

Aaro Koskinen aaro.koskinen at nokia.com
Fri Oct 2 10:30:51 EDT 2009


Hello,

Simon Kagstrom wrote:
> I was working on the same fix :-)
> 
> On Thu,  1 Oct 2009 18:16:55 +0300
> Aaro Koskinen <aaro.koskinen at nokia.com> wrote:
> 
>> diff --git a/drivers/mtd/mtdoops.c b/drivers/mtd/mtdoops.c
>> index 1060337..ac67833 100644
>> --- a/drivers/mtd/mtdoops.c
>> +++ b/drivers/mtd/mtdoops.c
>> @@ -335,7 +335,7 @@ static void mtdoops_console_sync(void)
>>  	cxt->ready = 0;
>>  	spin_unlock_irqrestore(&cxt->writecount_lock, flags);
>>  
>> -	if (mtd->panic_write && in_interrupt())
>> +	if (mtd->panic_write && (in_interrupt() || panic_on_oops))
>>  		/* Interrupt context, we're going to panic so try and log */
>>  		mtdoops_write(cxt, 1);
> 
> I believe we'll also need to make this module in-kernel with this
> change, since panic_on_oops is not exported. I've sent another patch
> that does these two things together.

Yes, I think you are right.

> I also get problems when mtd->read is called from mtdoops_inc_counter,
> so my patch also skips this if we have panic_on_oops set (there is also
> no point since the board will hang / be restarted after that).

I think you need to call it, otherwise the ready flag does not get set and
you may loose some messages? Which driver you are using? The second patch
I sent for OMAP addressed this problem, basically the driver should know we
are in oops and rely on very minimal functionality in read/write.

A.



More information about the linux-mtd mailing list