Message-ID: <AE39A478622CF340ABEC2418D74074F61FC5AA2465@SGPMBX05.APAC.bosch.com>
Date:	Tue, 7 Jan 2014 17:10:40 +0800
From:	"Huang Weller (CM/ESW12-CN)" <Weller.Huang@...bosch.com>
To:	Eric Sandeen <sandeen@...hat.com>,
	"Juergens Dirk (CM-AI/ECO2)" <Dirk.Juergens@...bosch.com>,
	Theodore Ts'o <tytso@....edu>
CC:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: [Attachment has been removed]RE: AW: ext4 filesystem bad extent error review

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@...bosch.com
Recipients: tytso@....edu;sandeen@...hat.com;linux-ext4@...r.kernel.org
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: linux-ext4@...r.kernel.org
> 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.

Powered by blists - more mailing lists