[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