The e-mail sent to you contained an attachment with a not allowed filetype. Please inform the sender to pack this type of attachment into a password protected ZIP-archive. Eine an Sie gesendete E-Mail enthielt einen nicht erlaubten Dateianhang. Bitte informieren Sie den Absender, diese Art von Anhang kann nur als Passwort geschütztes ZIP-Archiv versendet werden. Details: Sender: Weller.Huang@xxxxxxxxxxxx Recipients: tytso@xxxxxxx;sandeen@xxxxxxxxxx;linux-ext4@xxxxxxxxxxxxxxx Subject: "RE: AW: ext4 filesystem bad extent error review" Time: Mon Jan 6 06:10:55 2014 File: code_out_pc.tar The cleaned message body is below this line or in the attached e-mail. Die bereinigte E-Mail ist unter der folgenden Linie oder in beigefügtem Attachment. -------------------------------------------------------------------------------- >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. Please get code_out.tar.gz from my another mail. About the PC side, I write a win32 application which can send commands via uart to TOE power supplier(the power supplier has remote control mode which it can accept command from its uart interface). The Putty src, I only modified the winser.c which include in the attachment of this mail. There is also a readme.txt to introduce the package. If you want to use my test environment , I think you just need modify the putty_toe.bat with yours. It is easy to understand the commands in this script. You can replace the command to control the power controller with yours. Please feel free to let me know if you have any issue about the environment setup. Thanks Huang weller
