kernel BUG at fs/jffs2/gc.c:395!

[Tao Ren]

On 8/25/19 3:29 PM, Richard Weinberger wrote:
> ----- Ursprüngliche Mail -----
>> Von: "Tao Ren" <taoren at fb.com>
>> An: "Richard Weinberger" <richard.weinberger at gmail.com>, "Andrew Jeffery" <andrew at aj.id.au>
>> CC: "linux-mtd" <linux-mtd at lists.infradead.org>, "OpenBMC Maillist" <openbmc at lists.ozlabs.org>
>> Gesendet: Montag, 26. August 2019 00:08:08
>> Betreff: Re: kernel BUG at fs/jffs2/gc.c:395!
> 
>> On 8/25/19 12:22 PM, Richard Weinberger wrote:
>>> On Wed, Aug 21, 2019 at 2:06 AM Andrew Jeffery <andrew at aj.id.au> wrote:
>>>> Looks like a lack of robustness to filesystem corruption to me. LWN
>>>
>>> What exactly makes you think so?
>>> The inode cache entry is in state INO_STATE_UNCHECKED while GC run,
>>> which is not allowed.
>>>
>>> Tao, is the error persistent or did it happen only once?
>>
>> Hi Richard,
>>
>> It rarely happens (~1 out of 1000 machines in my environment), but once it
>> happens, it's persistent: the machine will fall into reboot loop due to the
>> crash.
> 
> Can you provide me an image of the filesystem such that I can have a look?
> An image where the issue is persistent...

Hi Richard,

I tried kernel image with jffs2 summary enabled and disabled, and it looks to
me the result is similar: I can reach login screen now, but the same kernel
panic happens after "reboot" command.

The behavior is a little different from what I saw yesterday: previously kernel
panic happened at boot time, and now it's after "reboot" command. I guess it's
because more node being written to the flash?

I understand it's helpful to share the file system image, but unfortunately I
cannot do it because it contains confidential data. Sorry about that..

Thank you again for the help, and kindly let me know if you have further
suggestions.


Cheers,

Tao