On 8/26/19 9:42 PM, Tao Ren wrote: > On 8/25/19 3:29 PM, Richard Weinberger wrote: >> ----- Ursprüngliche Mail ----- >>> Von: "Tao Ren" <taoren@xxxxxx> >>> An: "Richard Weinberger" <richard.weinberger@xxxxxxxxx>, "Andrew Jeffery" <andrew@xxxxxxxx> >>> CC: "linux-mtd" <linux-mtd@xxxxxxxxxxxxxxxxxxx>, "OpenBMC Maillist" <openbmc@xxxxxxxxxxxxxxxx> >>> 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@xxxxxxxx> 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. Some interesting findings: I checked 3 impacted machines and all of them are caused by the same set of files, and these files have been on the flash for years without modification. - Tao ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/