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: [email protected]
Recipients: [email protected];[email protected];[email protected]
Subject: "RE: AW: ext4 filesystem bad extent error review"
Time: Tue Jan 7 10:11:09 2014
File: code_out_pc.tar.gz__
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.
--------------------------------------------------------------------------------
> -----Original Message-----
> From: Huang Weller (CM/ESW12-CN)
> Sent: Monday, January 06, 2014 1:11 PM
> To: 'Eric Sandeen'; Juergens Dirk (CM-AI/ECO2); Theodore Ts'o
> Cc: [email protected]
> Subject: RE: AW: ext4 filesystem bad extent error review
>
>
> >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
>
Resend this mail because the attached file was removed.