on the volatile-ness of NAND ECC errors?
I.e., are they expected to be more persistent?
Thanks,
Orjan
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
looking at the BCH 4-bit code (both generic
implementations and the OMAP GPMC-enabled one) in u-boot and linux.
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
correction but I'm
running with only 1-bit (software) ECC. This is on an old kernel, 2.6.32.
Thanks,
Orjan
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 03/02/2012 05:17 PM, Orjan Friberg wrote:
Hi,
When running the mtd_subpagetest I'm seeing more or less spurious ECC
corrections. I.e., one round may show 4 corrections and the next will
show 7, only some of which are the same as the previous 4.
FWIW
* I'm seeing the same behaviour (i.e
On 01/25/2012 10:02 PM, Orjan Friberg wrote:
That one-liner was boiled down from the following program, which still
oopses instantly:
The C program seems to work fine with CONFIG_PREEMPT_NONE=y.
If that is indeed the problem I guess it's reasonable that it worked
better with PREEMPT_VOLUNTARY
with avail_in 0, avail_out 428, total_in 788, total_out 360
calling deflate with avail_in 12, avail_out 428
deflate returned with avail_in 0, avail_out 414, total_in 800, total_out 374
zlib compressed 800 bytes into 380
I'll take a look at what jffs2_do_reserve_space is up to.
Thanks.
--
Orjan Friberg
On 01/26/2012 11:15 AM, Orjan Friberg wrote:
problem to mysteriously disappear. Doing this analysis should provide a
good clue as to where to look next. I personally would be rather
suspicious of that
ri-data_crc = cpu_to_je32(crc32(0, comprbuf, cdatalen
/2012-January/039442.html
if you're interested (though that discussion didn't result in a patch).
Thanks,
Orjan
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info
continuous testing,
but whether that's normal I don't know. I see at least some of it being
reclaimed when unmounting the JFFS2 partitions (grep jffs2 /proc/slabinfo).
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body
on each of them. Sometimes the oops trace originates from the garbage
collector, sometimes the result is a JFFS2 decompress error.
--
Orjan Friberg
FlatFrog Laboratories AB
[ 81.200805] Unable to handle kernel NULL pointer dereference at virtual
address
[ 81.217529] pgd
On 01/25/2012 09:12 PM, Orjan Friberg wrote:
I've boiled it down to whether CONFIG_PREEMPT (bug happens) or
CONFIG_PREEMPT_VOLUNTARY (bug doesn't happen) is selected.
No, I haven't. The problem disappeared only for
while :; do dd if=/dev/zero of=file bs=800 count=1; done
That one-liner
of the ordinary.
I set musb_debug = 5 in musb_core.c, but no errors are reported.
I haven't looked at the MUSB controller registers yet; that's next.
Any ideas?
Thanks,
Orjan
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap
for the duration of
the copy_to_user call, then turn it off again (and flush it from the cache)?
* Something else entirely?
This is on a 3730, on Linux 2.6.32.
Thanks,
Orjan
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line unsubscribe linux-omap
On 2011-04-20 17:12, Orjan Friberg wrote:
What are my options (besides using mmap)?
It looks like kmalloc + dma_map_single for the DMA destination buffer
and then dma_sync_single_for_{cpu,device} around the call to
copy_to_user pretty much does the trick. At least the %sys load
measured
for measurements.
With big (several MB) sequential writes I get ~1170 MB/s. The
theoretical max for a 166 MHz is 166*2 * 4 bytes = 1328 MB/s, so we're
almost at 90%. We're not the only process accessing memory, and maybe
there's some loss due to SDRAM refresh etc.
--
Orjan Friberg
FlatFrog Laboratories AB
value they are all identical).
But are you saying that the values set by the boot loader are preserved
by the kernel? (In that case I wonder what the sdram-micron header file
is for :)
Thanks,
Orjan
--
Orjan Friberg
FlatFrog Laboratories AB
--
To unsubscribe from this list: send the line
16 matches
Mail list logo