General performance of NAND operations i.e mount and ls

General performance of NAND operations i.e mount and ls

[Konstantin Kletschke]

Finally I have my NAND driver running quite well.

It is attached to this Platform:

CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f
Machine: synertronixx GmbH scb9520 module
Memory policy: ECC disabled, Data cache writeback
Run Mode clock: 208.00MHz (*16)
Turbo Mode clock: 520.00MHz (*2.5, active)
Memory clock: 208.00MHz (/2)
System bus clock: 208.00MHz
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets

What I want to aks is, if my performance is reasonable or if I have
built in a show stopper there. 
Modprobe takes two seconds, okay:

# time modprobe scb9xxx
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)
2 NAND chips detected
Scanning device for bad blocks
Creating 1 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x00000000-0x80000000 : "NAND Flash"
real    0m 1.49s
user    0m 0.01s
sys     0m 1.40s

dmesg:

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V
8-bit)
2 NAND chips detected
Scanning device for bad blocks
Bad eraseblock 1838 at 0x0e5c0000
Bad eraseblock 2697 at 0x15120000
Bad eraseblock 3888 at 0x1e600000
Bad eraseblock 4338 at 0x21e40000
Bad eraseblock 4501 at 0x232a0000
Bad eraseblock 8534 at 0x42ac0000
Bad eraseblock 14308 at 0x6fc80000
Bad eraseblock 14329 at 0x6ff20000
Bad eraseblock 16142 at 0x7e1c0000
Creating 1 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x00000000-0x80000000 : "NAND Flash"

Mounting lasts 20 seconds, is that a reasonable time for jffs2 on 2GiB
NAND? May be...

# time mount -t jffs2 /dev/mtdblock4 /mnt
JFFS2 notice: (186) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0
of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
real    0m 19.03s
user    0m 0.01s
sys     0m 19.01s

But the fist/initital ls takes half an hour, is this okay or are your
faster?

# time ls -la /mnt
drwxr-xr-x    3 root     root            0 Jan  1 02:00 .
drwxr-xr-x   18 root     root            0 Jan  1 02:00 ..
-rw-r--r--    1 root     root    1693788160 Jan  1  1970 buildroot-20070607-scb9xxx-5.0.3.tar
-rw-r--r--    1 root     root    1693788160 Jan  1  1970 copi
real    16m 32.38s
user    0m 0.00s
sys     10m 3.32s
#

What are your experiences on flash devices?

Konsti


-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: General performance of NAND operations i.e mount and ls

[Artem Bityutskiy]

Hi,

On Thu, 2007-09-06 at 10:12 +0200, Konstantin Kletschke wrote:
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V
> 8-bit)
> 2 NAND chips detected
> Scanning device for bad blocks
> Bad eraseblock 1838 at 0x0e5c0000
> Bad eraseblock 2697 at 0x15120000
> Bad eraseblock 3888 at 0x1e600000
> Bad eraseblock 4338 at 0x21e40000
> Bad eraseblock 4501 at 0x232a0000
> Bad eraseblock 8534 at 0x42ac0000
> Bad eraseblock 14308 at 0x6fc80000
> Bad eraseblock 14329 at 0x6ff20000
> Bad eraseblock 16142 at 0x7e1c0000
> Creating 1 MTD partitions on "NAND 1GiB 3,3V 8-bit":
> 0x00000000-0x80000000 : "NAND Flash"

If you useed on-flash BBT, you'd avoid scanning and make this phase
faster. But the improvement would be nothing comparing to JFFS2's delay.

> Mounting lasts 20 seconds, is that a reasonable time for jffs2 on 2GiB
> NAND? May be...

Well, JFFS2 scans on mount, so no wonder it is that long. Summary should
improves the situation - do you have it enabled?

> # time mount -t jffs2 /dev/mtdblock4 /mnt
> JFFS2 notice: (186) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0
> of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
> real    0m 19.03s
> user    0m 0.01s
> sys     0m 19.01s
> 
> But the fist/initital ls takes half an hour, is this okay or are your
> faster?

It's because you use -a, which causes stat() to be called for each file.
Stat causes read_inode(), which is slow. It builds file's fragtree,
which means it reads and checks each of its nodes. So the larger is the
file the longer it takes to stat() it for the first time (the second and
later are cached).

> What are your experiences on flash devices?

I do not think you may make JFFS2 work faster on such big flash with
such big files, at least it will be difficult and would require core
jffs2 changes.

I'd suggest you to try UBIFS - it must be faster. We would also be
interested to get a feedback.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: General performance of NAND operations i.e mount and ls

[Konstantin Kletschke]

Am 2007-09-06 11:27 +0300 schrieb Artem Bityutskiy:
> Hi,

Hi There :-)

> If you useed on-flash BBT, you'd avoid scanning and make this phase
> faster. But the improvement would be nothing comparing to JFFS2's delay.

Yes, it is on-flash BBT but the scan time is okay and the probing
lasting two seconds is no issue.

> Well, JFFS2 scans on mount, so no wonder it is that long. Summary should
> improves the situation - do you have it enabled?

Summary is enabled in Kernel but I created the files with flash_eraseall
and mounted the block device as jffs2 and copied the files onto it in
system. So no summaryze, is that right?

> It's because you use -a, which causes stat() to be called for each file.
> Stat causes read_inode(), which is slow. It builds file's fragtree,
> which means it reads and checks each of its nodes. So the larger is the
> file the longer it takes to stat() it for the first time (the second and
> later are cached).

Okay.

> I do not think you may make JFFS2 work faster on such big flash with
> such big files, at least it will be difficult and would require core
> jffs2 changes.

Okay, I wanted to check if the time is okay for 520MHz core with 104MHz
Bus and 8Bit flash. If this is the case my Hardware driver is okay.
There is no urge to improve this stat() time and fragtree building at
the moment. If it takes so long and the driver is okay it wioll take so
long (arguing with boss and customers :-)).

> I'd suggest you to try UBIFS - it must be faster. We would also be
> interested to get a feedback.

Hmm. I will take a look at this :-)

Kind Regards, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: General performance of NAND operations i.e mount and ls

[Artem Bityutskiy]

On Thu, 2007-09-06 at 10:44 +0200, Konstantin Kletschke wrote:
> > Well, JFFS2 scans on mount, so no wonder it is that long. Summary should
> > improves the situation - do you have it enabled?
> 
> Summary is enabled in Kernel but I created the files with flash_eraseall
> and mounted the block device as jffs2 and copied the files onto it in
> system. So no summaryze, is that right?

Yup, summaries are there then.

> > I do not think you may make JFFS2 work faster on such big flash with
> > such big files, at least it will be difficult and would require core
> > jffs2 changes.
> 
> Okay, I wanted to check if the time is okay for 520MHz core with 104MHz
> Bus and 8Bit flash. If this is the case my Hardware driver is okay.
> There is no urge to improve this stat() time and fragtree building at
> the moment. If it takes so long and the driver is okay it wioll take so
> long (arguing with boss and customers :-)).

Try to measure raw R/W, e.g with dd. But beware dd will fail at the
first met bad block. Something like:

Read: dd if=/dev/mtd4 of=/dev/null bs=4096 count=512
Write: dd if=/dev/zero of=/dev/mtd4 bs=4096 count=512

It'll print raw R/W speed.  But beware dd will fail at the first bad
block, so yo may have to play with count= or skip= for read and seek=
for write to find a large enough contiguous area without bad blocks.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: General performance of NAND operations i.e mount and ls

[Konstantin Kletschke]

Am 2007-09-06 12:11 +0300 schrieb Artem Bityutskiy:

> Try to measure raw R/W, e.g with dd. But beware dd will fail at the
> first met bad block. Something like:

Okay, what would I roughly excpect on this system?

# time dd if=/dev/mtd4 of=/dev/null bs=4096 count=512
512+0 records in
512+0 records out
real    0m 0.61s
user    0m 0.01s
sys     0m 0.61s
# time dd if=/dev/zero of=/dev/mtd4 bs=4096 count=512
512+0 records in
512+0 records out
real    0m 1.08s
user    0m 0.00s
sys     0m 1.08s

Meanwhile I played around with 2.6.23-rc3:

modprobe ubi mtd=4:

UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 0:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 2:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 3:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 4:512,
written 0 bytes
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 5:512,
written 0 bytes
UBI warning: io_init: EC and VID headers are in the same minimal I/O
unit, switch to read-only mode
UBI error: validate_ec_hdr: bad VID header offset 512, expected 128
UBI error: validate_ec_hdr: bad EC header
UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0

Konsti

PS.: does anybody know where the IRQs have gone?
2.6.20:
eth0: dm9000 at c8850000,c8852004 IRQ 133 MAC: 00:0c:7f:01:23:47
2.6.23-rc3:
eth0: dm9000 at c8878000,c887a004 IRQ 165 MAC: 00:0c:7f:01:23:47
Both cases on GPIO101

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: General performance of NAND operations i.e mount and ls

[Artem Bityutskiy]

On Thu, 2007-09-06 at 11:37 +0200, Konstantin Kletschke wrote:
> UBI: empty MTD device detected
> UBI: create volume table (copy #1)
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 0:512,
> written 0 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1:512,
> written 0 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 2:512,
> written 0 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 3:512,
> written 0 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 4:512,
> written 0 bytes
> UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 5:512,
> written 0 bytes
> UBI warning: io_init: EC and VID headers are in the same minimal I/O
> unit, switch to read-only mode
> UBI error: validate_ec_hdr: bad VID header offset 512, expected 128
> UBI error: validate_ec_hdr: bad EC header
> UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0

This means your driver does not support sub-pages, but reports it does.
You should either fix sub-page support or do not report it is present.

There are good NANDtests available at

git://git.infradead.org/~ahunter/nand-tests.git
(http://git.infradead.org/?p=users/ahunter/nand-tests.git;a=summary)


Try them to make sure your NAND driver is all-right. Well, you may want
to avoid the torture test, but it is also very useful to run it with
limited amount of erase cycles to make sure your flash/driver survive
really high I/O load.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: General performance of NAND operations i.e mount and ls

[Artem Bityutskiy]

On Thu, 2007-09-06 at 12:11 +0300, Artem Bityutskiy wrote:

> > Okay, I wanted to check if the time is okay for 520MHz core with 104MHz
> > Bus and 8Bit flash. If this is the case my Hardware driver is okay.
> > There is no urge to improve this stat() time and fragtree building at
> > the moment. If it takes so long and the driver is okay it wioll take so
> > long (arguing with boss and customers :-)).
> 
> Try to measure raw R/W, e.g with dd. But beware dd will fail at the
> first met bad block. Something like:
> 
> Read: dd if=/dev/mtd4 of=/dev/null bs=4096 count=512
> Write: dd if=/dev/zero of=/dev/mtd4 bs=4096 count=512
> 
> It'll print raw R/W speed.  But beware dd will fail at the first bad
> block, so yo may have to play with count= or skip= for read and seek=
> for write to find a large enough contiguous area without bad blocks.

Konste,

may you please go to Device Drivers--->Memory Technology Device (MTD)
support--->UBI - Unsorted block images---> in menuconfig and enable "UBI
debugging", "UBI debugging messages", and "Extra self-checks" and try
again? Then send what UBI prints. I'll try to figure out what is wrong.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: General performance of NAND operations i.e mount and ls

[Artem Bityutskiy]

On Thu, 2007-09-06 at 11:37 +0200, Konstantin Kletschke wrote:
> Okay, what would I roughly excpect on this system?
> 
> # time dd if=/dev/mtd4 of=/dev/null bs=4096 count=512
> 512+0 records in
> 512+0 records out
> real    0m 0.61s
> user    0m 0.01s
> sys     0m 0.61s
> # time dd if=/dev/zero of=/dev/mtd4 bs=4096 count=512
> 512+0 records in
> 512+0 records out
> real    0m 1.08s
> user    0m 0.00s
> sys     0m 1.08s

Not sure about your system, but the hardware I worked with was ~8 times
faster on read and ~3 times faster on write.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: General performance of NAND operations i.e mount and ls

[Konstantin Kletschke]

Am 2007-09-06 14:11 +0300 schrieb Artem Bityutskiy:

> may you please go to Device Drivers--->Memory Technology Device (MTD)
> support--->UBI - Unsorted block images---> in menuconfig and enable "UBI
> debugging", "UBI debugging messages", and "Extra self-checks" and try
> again? Then send what UBI prints. I'll try to figure out what is wrong.

Well after half an hour I got this:

UBI DBG: attach_mtd_dev: attaching mtd4 to ubi0: VID header offset 0 data offset 0
UBI DBG: io_init: min_io_size      2048
UBI DBG: io_init: hdrs_min_io_size 512
UBI DBG: io_init: ec_hdr_alsize    512
UBI DBG: io_init: vid_hdr_alsize   512
UBI DBG: io_init: vid_hdr_offset   512
UBI DBG: io_init: vid_hdr_aloffset 512
UBI DBG: io_init: vid_hdr_shift    0
UBI DBG: io_init: leb_start        2048
UBI DBG: io_init: leb_size         129024
UBI DBG: io_init: ro_mode          0
UBI DBG: ubi_scan: scanning is finished
UBI: empty MTD device detected
UBI: create volume table (copy #1)
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 0:512, written 0 bytes
Function entered at [<c001df40>] from [<bf0528a0>]
Function entered at [<bf052694>] from [<bf052994>]
Function entered at [<bf0528c8>] from [<bf04b67c>]
 r6:00000100 r5:00000000 r4:00000001
Function entered at [<bf04b448>] from [<bf04b9c4>]
Function entered at [<bf04b8b0>] from [<bf06163c>]
Function entered at [<bf06120c>] from [<c004dc44>]
Function entered at [<c004cb40>] from [<c0019f40>]
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 1:512, written 0 bytes
Function entered at [<c001df40>] from [<bf0528a0>]
Function entered at [<bf052694>] from [<bf052994>]
Function entered at [<bf0528c8>] from [<bf04b67c>]
 r6:00000200 r5:00000000 r4:00000002
Function entered at [<bf04b448>] from [<bf04b9c4>]
Function entered at [<bf04b8b0>] from [<bf06163c>]
Function entered at [<bf06120c>] from [<c004dc44>]
Function entered at [<c004cb40>] from [<c0019f40>]
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 2:512, written 0 bytes
Function entered at [<c001df40>] from [<bf0528a0>]
Function entered at [<bf052694>] from [<bf052994>]
Function entered at [<bf0528c8>] from [<bf04b67c>]
 r6:00000300 r5:00000000 r4:00000003
Function entered at [<bf04b448>] from [<bf04b9c4>]
Function entered at [<bf04b8b0>] from [<bf06163c>]
Function entered at [<bf06120c>] from [<c004dc44>]
Function entered at [<c004cb40>] from [<c0019f40>]
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 3:512, written 0 bytes
Function entered at [<c001df40>] from [<bf0528a0>]
Function entered at [<bf052694>] from [<bf052994>]
Function entered at [<bf0528c8>] from [<bf04b67c>]
 r6:00000400 r5:00000000 r4:00000004
Function entered at [<bf04b448>] from [<bf04b9c4>]
Function entered at [<bf04b8b0>] from [<bf06163c>]
Function entered at [<bf06120c>] from [<c004dc44>]
Function entered at [<c004cb40>] from [<c0019f40>]
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 4:512, written 0 bytes
Function entered at [<c001df40>] from [<bf0528a0>]
Function entered at [<bf052694>] from [<bf052994>]
Function entered at [<bf0528c8>] from [<bf04b67c>]
 r6:00000500 r5:00000000 r4:00000005
Function entered at [<bf04b448>] from [<bf04b9c4>]
Function entered at [<bf04b8b0>] from [<bf06163c>]
Function entered at [<bf06120c>] from [<c004dc44>]
Function entered at [<c004cb40>] from [<c0019f40>]
UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 5:512, written 0 bytes
Function entered at [<c001df40>] from [<bf0528a0>]
Function entered at [<bf052694>] from [<bf052994>]
Function entered at [<bf0528c8>] from [<bf04b67c>]
 r6:00000600 r5:00000000 r4:00000006
Function entered at [<bf04b448>] from [<bf04b9c4>]
Function entered at [<bf04b8b0>] from [<bf06163c>]
Function entered at [<bf06120c>] from [<c004dc44>]
Function entered at [<c004cb40>] from [<c0019f40>]
UBI error: attach_mtd_dev: failed to attach by scanning, error -5

To not flood the console/kernlog I disabled

#warning KKK
// KKK          dbg_msg("process PEB %d", pnum);

though.

Kind regards, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: General performance of NAND operations i.e mount and ls

[Artem Bityutskiy]

On Thu, 2007-09-06 at 18:03 +0200, Konstantin Kletschke wrote:
> > may you please go to Device Drivers--->Memory Technology Device (MTD)
> > support--->UBI - Unsorted block images---> in menuconfig and enable "UBI
> > debugging", "UBI debugging messages", and "Extra self-checks" and try
> > again? Then send what UBI prints. I'll try to figure out what is wrong.
> 
> Well after half an hour I got this:

It is long because you enabled paranoid checks. One of them scans whole
media and makes sure it is really empty and contains only 0xFFs. You may
disable paranoid checks to make it faster.

> UBI DBG: attach_mtd_dev: attaching mtd4 to ubi0: VID header offset 0 data offset 0
> UBI DBG: io_init: min_io_size      2048
> UBI DBG: io_init: hdrs_min_io_size 512
> UBI DBG: io_init: ec_hdr_alsize    512
> UBI DBG: io_init: vid_hdr_alsize   512
> UBI DBG: io_init: vid_hdr_offset   512
> UBI DBG: io_init: vid_hdr_aloffset 512
> UBI DBG: io_init: vid_hdr_shift    0
> UBI DBG: io_init: leb_start        2048
> UBI DBG: io_init: leb_size         129024
> UBI DBG: io_init: ro_mode          0
> UBI DBG: ubi_scan: scanning is finished

Yeah, your flash driver is not OK. It reports 2 in mtd->subpage_sft, but
it is unable to write in sub-page chunks (512 bytes) - it returns -EIO. 

You should either teach it to write sub-pages (preferable) or report 0
in mtd->subpage_sft, which would mean "no sub-page support".

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: General performance of NAND operations i.e mount and ls

[Konstantin Kletschke]

Am 2007-09-07 08:47 +0300 schrieb Artem Bityutskiy:

> It is long because you enabled paranoid checks. One of them scans whole

Ah okay, "Extra self checks"...

> media and makes sure it is really empty and contains only 0xFFs. You may
> disable paranoid checks to make it faster.

I disabled these.

> Yeah, your flash driver is not OK. It reports 2 in mtd->subpage_sft, but
> it is unable to write in sub-page chunks (512 bytes) - it returns -EIO. 

Hm okay, this may be since this is my first NAND driver and its only a
couple of hours old, so its possible the case I messed up something.

> You should either teach it to write sub-pages (preferable) or report 0

I don't know how to implement these sub pages since I found no example
on how to do this yet, so I tried to disable them. I put a 0 into the
variable, but it is set to 2 in nand base:

        printk("mtd->subpage_sft is now %i\n", mtd->subpage_sft);
        if (!(chip->options & NAND_NO_SUBPAGE_WRITE) &&
            !(chip->cellinfo & NAND_CI_CELLTYPE_MSK)) {
                switch(chip->ecc.steps) {
                case 2:
                        mtd->subpage_sft = 1;
                        break;
                case 4:
                case 8:
                        mtd->subpage_sft = 2;
                        break;
                }
        }
        chip->subpagesize = mtd->writesize >> mtd->subpage_sft;
        printk("mtd->subpage_sft is now %i\n", mtd->subpage_sft);


gives:

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)
2 NAND chips detected
mtd->subpage_sft is now 0
mtd->subpage_sft is now 2
Scanning device for bad blocks
Creating 1 MTD partitions on "NAND 1GiB 3,3V 8-bit":
0x00000000-0x80000000 : "NAND Flash"

Hm, I investigate where this comes from ATM.

Regards Konsti

PS.: Your examples of NAND performance are astonishing, but I don't see
where I even could waste performance on my setup :-)



-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

JFFS2 CRC problems

[Stefan Roese]

Hi Konstantin!

While debugging and researching a problem we experience on our MPC5200 system, 
I found a thread on the MTD list "jffs2 with sync burst mode" initiated by 
you. This pretty much seems to be the same problem that we are experiencing on 
our MPC5200 system using JFFS2 on Intel Strataflash NOR devices.

-bash-3.2# mount -t jffs2 /dev/mtdblock3 /mnt
[  266.571967] jffs2: jffs2_scan_dirent_node(): Name CRC failed on node at 
0x002c0050: Read 0x1c0cc6df, calculated 0x5eb3f212
-bash-3.2#

While I'm continuing to dig into this, I wanted to "poll" your status on this 
issue. I know that it was a long time ago. But perhaps you can remember the 
outcome of this issue. What caused it? How did you fix it?

Any pointers are really welcome.

BTW: We are using latest Linux kernel here (currently testing with v3.4).

Thanks.

Best regards,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de