[ECOS] jffs2_1 test case error

[ECOS] jffs2_1 test case error

[Srinivas rao]

Hi All,

Iam running jffs2 test cases on my board. After
reading the directories getting error like below.
Pls give me the solution.

<INFO>: reading directory /
<INFO>: entry              . [mode 016f0001 ino
00000001 nlink 1 size 0]
<INFO>: entry             .. [mode 016f0001 ino
00000001 nlink 1 size 0]
<INFO>: entry            etc [mode 017f0001 ino
00000004 nlink 1 size 0]
<INFO>: entry            dev<FAIL>: stat() returned -1
No such entity

<INFO>: entry            bin [mode 017f0001 ino
00000002 nlink 1 size 0]
<INFO>: entry            lib [mode 017f0001 ino
00000005 nlink 1 size 0]
<INFO>: entry            mnt [mode 017f0001 ino
00000006 nlink 1 size 0]
<INFO>: entry            var [mode 017f0001 ino
000000f6 nlink 1 size 0]
<INFO>: entry            tmp [mode 017f0001 ino
000000fb nlink 1 size 0]
<INFO>: entry           sbin [mode 017f0001 ino
00000007 nlink 1 size 0]
<INFO>: create file /foo size 202
<5>Write of 68 bytes at 0x003e3144 failed. returned
-5, retlen 68
<5>Write of 68 bytes at 0x003e3188 failed. returned
-5, retlen 68
<FAIL>: open() returned -1 I/O error
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle
<FAIL>: write() returned -1 Bad file handle

Thanks & Regards 
Srinivas rao


		
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] jffs2_1 test case error

[Andrew Lunn]

On Thu, Oct 26, 2006 at 11:33:41AM +0100, Srinivas rao wrote:
> Hi All,
> 
> Iam running jffs2 test cases on my board. After
> reading the directories getting error like below.
> Pls give me the solution.

Sorry, but we don't give solutions. We try to help you find the
solution to your problem.

> 
> <INFO>: reading directory /
> <INFO>: entry              . [mode 016f0001 ino
> 00000001 nlink 1 size 0]
> <INFO>: entry             .. [mode 016f0001 ino
> 00000001 nlink 1 size 0]
> <INFO>: entry            etc [mode 017f0001 ino
> 00000004 nlink 1 size 0]
> <INFO>: entry            dev<FAIL>: stat() returned -1
> No such entity
> 
> <INFO>: entry            bin [mode 017f0001 ino
> 00000002 nlink 1 size 0]
> <INFO>: entry            lib [mode 017f0001 ino
> 00000005 nlink 1 size 0]
> <INFO>: entry            mnt [mode 017f0001 ino
> 00000006 nlink 1 size 0]
> <INFO>: entry            var [mode 017f0001 ino
> 000000f6 nlink 1 size 0]
> <INFO>: entry            tmp [mode 017f0001 ino
> 000000fb nlink 1 size 0]
> <INFO>: entry           sbin [mode 017f0001 ino
> 00000007 nlink 1 size 0]
> <INFO>: create file /foo size 202
> <5>Write of 68 bytes at 0x003e3144 failed. returned
> -5, retlen 68

Well if you look in packages/error/current/include/codes.h you will
find that 5 is EIO. So you probably need to single step this write
call and find out where and why it returns EIO.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Two things about cyg_types

[Stefan Sommerfeld]

Hello,

I found two strange things in cyg_types. The first one is in line 316 where 
__GNUC_VERSION__ is defined. To define the whole gcc version it tries to 
find out if PATCHLEVEL is defined. My gcc (3.4.6) has __GNUC_PATCHLEVEL__ 
defined by cyg_types checks for __GNU_PATCHLEVEL__ but uses the GNUC 
define. I think the line 316 should look more like
#if defined(__GNUC_PATCHLEVEL__)

Second one is a comment which doesn't fit the define. At line 395 where 
CYGBLD_ATTRIB_USED is defined the comment says that the define changes for 
gcc 3.3.4 and above, but the define uses gcc 3.4.4. Something is wrong 
here, the comment or the define.

Quick help would be nice ....

Bye....


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Two things about cyg_types

[Andrew Lunn]

On Thu, Oct 26, 2006 at 02:01:59PM +0200, Stefan Sommerfeld wrote:
> Hello,
> 
> I found two strange things in cyg_types. The first one is in line 316 where 
> __GNUC_VERSION__ is defined. To define the whole gcc version it tries to 
> find out if PATCHLEVEL is defined. My gcc (3.4.6) has __GNUC_PATCHLEVEL__ 
> defined by cyg_types checks for __GNU_PATCHLEVEL__ but uses the GNUC 
> define. I think the line 316 should look more like
> #if defined(__GNUC_PATCHLEVEL__)

Yes, that looks like a typo. Please produce a patch and i will test it
with the stock arm compiler and my native compiler for synth.

> Second one is a comment which doesn't fit the define. At line 395 where 
> CYGBLD_ATTRIB_USED is defined the comment says that the define changes for 
> gcc 3.3.4 and above, but the define uses gcc 3.4.4. Something is wrong 
> here, the comment or the define.

Looking at
http://www.ohse.de/uwe/articles/gcc-attributes.html#func-unused
suggests that both are supported up to 3.4. I would suggest changing
the comment unless its actually causing you a problem with 3.4.6.
Please send us a patch.

    Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] jffs2_1 test case error

[Chris Zimman]

Just for what it's worth -- unless you are using the new eCosCentric V2
flash drivers, make sure you have interrupts disabled during JFFS2
access.  eCosCentric did a lot of work on JFFS2 to make it stable under
eCos.  I have no idea how well the stock JFFS2 code works.

--Chris
 
-----Original Message-----
From: ecos-discuss-owner@ecos.sourceware.org
[mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Andrew Lunn
Sent: 26 October 2006 12:35
To: Srinivas rao
Cc: ecos
Subject: Re: [ECOS] jffs2_1 test case error

On Thu, Oct 26, 2006 at 11:33:41AM +0100, Srinivas rao wrote:
> Hi All,
> 
> Iam running jffs2 test cases on my board. After
> reading the directories getting error like below.
> Pls give me the solution.

Sorry, but we don't give solutions. We try to help you find the
solution to your problem.

> 
> <INFO>: reading directory /
> <INFO>: entry              . [mode 016f0001 ino
> 00000001 nlink 1 size 0]
> <INFO>: entry             .. [mode 016f0001 ino
> 00000001 nlink 1 size 0]
> <INFO>: entry            etc [mode 017f0001 ino
> 00000004 nlink 1 size 0]
> <INFO>: entry            dev<FAIL>: stat() returned -1
> No such entity
> 
> <INFO>: entry            bin [mode 017f0001 ino
> 00000002 nlink 1 size 0]
> <INFO>: entry            lib [mode 017f0001 ino
> 00000005 nlink 1 size 0]
> <INFO>: entry            mnt [mode 017f0001 ino
> 00000006 nlink 1 size 0]
> <INFO>: entry            var [mode 017f0001 ino
> 000000f6 nlink 1 size 0]
> <INFO>: entry            tmp [mode 017f0001 ino
> 000000fb nlink 1 size 0]
> <INFO>: entry           sbin [mode 017f0001 ino
> 00000007 nlink 1 size 0]
> <INFO>: create file /foo size 202
> <5>Write of 68 bytes at 0x003e3144 failed. returned
> -5, retlen 68

Well if you look in packages/error/current/include/codes.h you will
find that 5 is EIO. So you probably need to single step this write
call and find out where and why it returns EIO.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] jffs2_1 test case error

[Jürgen Lambrecht]

Chris Zimman wrote:

>Just for what it's worth -- unless you are using the new eCosCentric V2
>flash drivers, make sure you have interrupts disabled during JFFS2
>  
>
JFFS2 accesses take so long that I cannot allow to disable interrupts

>access.  eCosCentric did a lot of work on JFFS2 to make it stable under
>eCos.  I have no idea how well the stock JFFS2 code works.
>  
>
Would it be a good idea to use the flash_v2 branch?
I don't know if all eCosCentric code is already commited there?
Kind regards,
Jürgen

>--Chris
>  
>


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] jffs2_1 test case error

[Chris Zimman]

> JFFS2 accesses take so long that I cannot allow to disable interrupts

If you're using V1 flash drivers, you're out of luck.  They are not interrupt
safe and you will crash at some point.

> Would it be a good idea to use the flash_v2 branch?
> I don't know if all eCosCentric code is already commited there?

I don't know if it's in there or not.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] jffs2_1 test case error

[Jürgen Lambrecht]

Jürgen Lambrecht wrote:

> Chris Zimman wrote:
>
>> Just for what it's worth -- unless you are using the new eCosCentric V2
>> flash drivers, make sure you have interrupts disabled during JFFS2 
>
The manual states it is only necessary to disable interrupts during 
flash accesses if your code also resides in flash (ROM image) 
(http://ecos.sourceware.org/docs-latest/ref/ecos-flash-library.html).

Jürgen

>>
> JFFS2 accesses take so long that I cannot allow to disable interrupts
>
>> access.  eCosCentric did a lot of work on JFFS2 to make it stable under
>> eCos.  I have no idea how well the stock JFFS2 code works.
>>  
>>
> Would it be a good idea to use the flash_v2 branch?
> I don't know if all eCosCentric code is already commited there?
> Kind regards,
> Jürgen
>
>> --Chris
>>  
>>
>
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] jffs2_1 test case error

[Chris Zimman]

> The manual states it is only necessary to disable interrupts during
> flash accesses if your code also resides in flash (ROM image)
> (http://ecos.sourceware.org/docs-latest/ref/ecos-flash-library.html).

Regardless of what the manual says, I'm telling you from experience, the V1
flash drivers are not interrupt safe.  If you don't disable interrupts while
flash access is going on, you are going to have problems.

--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] jffs2_1 test case error

[Jürgen Lambrecht]

Chris Zimman wrote:

>>The manual states it is only necessary to disable interrupts during
>>flash accesses if your code also resides in flash (ROM image)
>>(http://ecos.sourceware.org/docs-latest/ref/ecos-flash-library.html).
>>    
>>
>
>Regardless of what the manual says, I'm telling you from experience, the V1
>flash drivers are not interrupt safe.  If you don't disable interrupts while
>flash access is going on, you are going to have problems.
>  
>
I have to admit that we *have* problems...
OK, you mean not interrupt safe, so this means the flash drivers need 
exact timing...
I'll try the flash_v2 drivers, and I'll keep you informed.
Thanks,
Jürgen

>--Chris
>
>  
>

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

RE: [ECOS] jffs2_1 test case error

[Chris Zimman]

> I have to admit that we *have* problems...
> OK, you mean not interrupt safe, so this means the flash drivers need
> exact timing...
> I'll try the flash_v2 drivers, and I'll keep you informed.

Hi Jürgen,

I mean that you *cannot* have interrupts enabled with the V1 drivers, no way,
no how.  It will not be reliable and you will crash at some point.
It's not a timing thing, it's that the drivers only support uninterrupted
operations right now.
 
--Chris

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss