On 1/3/14, 10:29 AM, Juergens Dirk (CM-AI/ECO2) wrote: > So, I think there _might_ be a kernel bug, but it could be also a problem > related to the particular type of eMMC. We did not observe the same issue > in previous tests with another type of eMMC from another supplier, but this > was with an older kernel patch level and with another HW design. > > Regarding a possible kernel bug: Is there any chance that the invalid > ee_len or ee_start are returned by, e.g., the block allocator ? > If so, can we try to instrument the code to get suitable traces ? > Just to see or to exclude that the corrupted inode is really written > to the eMMC ? >From your description it does sound possible that it's a kernel bug. Adding testcases to the code to catch it before it hits the journal might be helpful - but then maybe this is something getting overwritten after the fact - hard to say. Can you share more details of the test you are running? Or maybe even the test itself? I've used a test framework in the past to simulate resets w/o needing to reset the box, and do many journal replays very quickly. It'd be interesting to run it using your testcase. Thanks, -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
