Ticket #245 (closed defect: fixed)
Neo crashes when writing large amounts of data to SD
| Reported by: | jluebbe@… | Owned by: | laforge@… |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | kernel | Version: | unspecified |
| Severity: | normal | Keywords: | |
| Cc: | buglog@…, alphaone@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
dd bs=1k if=/dev/zero of=/dev/mmcblk0p1 count=10000 works
dd bs=1k if=/dev/zero of=/dev/mmcblk0p1 count=50000 stops responding after some
seconds, even ping stops working
Attachments
Change History
comment:1 Changed 6 years ago by jluebbe@…
- Summary changed from Neo crashes when writing large amounts of data do SD to Neo crashes when writing large amounts of data to SD
comment:2 Changed 6 years ago by laforge@…
If you have a debug board handy, please try to reproduce a couple of times and
grab the kernel oops from the serial console.
Changed 6 years ago by stefan@…
- Attachment high-io-oops.txt added
Oops captured with serial console from debug board
comment:5 Changed 6 years ago by laforge@…
can you please run those tests a couple of times and check if the opps backtrace
is always the same? If yes, then it sounds more or less easy to fix. If it
crashes all over the place, then it could be about anything :(
Also, please compare with large NAND read/write tests, and with read/write tests
on NFS. We need to basically find some way how to determine if this is
1) something generic about block read/write
2) something specific to SD or NAND hardware [drivers]
3) some generic issue about data corruption or system instability
comment:6 Changed 6 years ago by alphaone@…
root@fic-gta01:~$ dd if=/dev/zero of=/dev/null bs=1k
does not show any problems, though.
I'll see if I can trace down the problem with JTAG.
Changed 6 years ago by jluebbe@…
- Attachment screenlog.0 added
Panic when reading from mtd with 2.6.20.2
comment:7 Changed 6 years ago by jluebbe@…
- attachments.mimetype changed from application/octet-stream to text/plain
comment:9 Changed 6 years ago by jluebbe@…
I've made some test by dd-ing from /dev/zero to /media/ram (which is a tmpfs):
Case 1: Fill up /media/ram with 10MB files...
root@fic-gta01:~$ dd bs=1k count=10k if=/dev/zero of=/media/ram/test0
10240+0 records in
10240+0 records out
root@fic-gta01:~$ dd bs=1k count=10k if=/dev/zero of=/media/ram/test1
10240+0 records in
10240+0 records out
root@fic-gta01:~$ dd bs=1k count=10k if=/dev/zero of=/media/ram/test2
<CRASHED>
Case 2: The same, but overwrite each file 100 times...
root@fic-gta01:~$ for i in seq 1 100; do echo -n "$i "; dd bs=1k count=10k
if=/dev/zero of=/media/ram/test0 2> /dev/null; done; echo
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
root@fic-gta01:~$ for i in seq 1 100; do echo -n "$i "; dd bs=1k count=10k
if=/dev/zero of=/media/ram/test1 2> /dev/null; done; echo
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57
58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
root@fic-gta01:~$ free
total used free shared buffers cached
Mem: 126832 57792 69040 0 0 43200
-/+ buffers/cache: 14592 112240
Swap: 0 0 0
root@fic-gta01:~$ df /media/ram
Filesystem 1k-blocks Used Available Use% Mounted on
tmpfs 63416 20512 42904 32% /media/ram
root@fic-gta01:~$ for i in seq 1 100; do echo -n "$i "; dd bs=1k count=10k
if=/dev/zero of=/media/ram/test2 2> /dev/null; done; echo
1
<CRASHED>
Case 3: Fill up /media/ram 64kB at a time...
root@fic-gta01:~$ free; for i in seq 1 10000; do echo -n "$i: "; dd bs=1k
count=64 if=/dev/zero of=/media/ram/test$i 2> /dev/null; free | grep Mem; done;
total used free shared buffers cached
Mem: 126832 37112 89720 0 0 22656
-/+ buffers/cache: 14456 112376
Swap: 0 0 0
355: Mem: 126832 60404 66428 0 0 45440
356: Mem: 126832 60468 66364 0 0 45504
357: Mem: 126832 60544 66288 0 0 45568
358: Mem: 126832 60708 66124 0 0 45632
359: Mem: 126832 60736 66096 0 0 45696
360: Mem: 126832 60792 66040 0 0 45760
361: Mem: 126832 60796 66036 0 0 45824
362: Mem: 126832 60852 65980 0 0 45888
363: Mem: 126832 61016 65816 0 0 45952
364: Mem: 126832 61016 65816 0 0 46016
365: Mem: 126832 61100 65732 0 0 46080
366: Mem: 126832 61104 65728 0 0 46144
367: Mem: 126832 61188 65644 0 0 46208
368: Segmentation fault
369:
<CRASHED>
Case 4: Fill up /media/ram 1MB at a time...
root@fic-gta01:~$ free; for i in seq 1 100; do echo -n "$i: "; dd bs=1k
count=1k if=/dev/zero of=/media/ram/test$i 2> /dev/null; free | grep Mem; done;
total used free shared buffers cached
Mem: 126832 37428 89404 0 0 22704
-/+ buffers/cache: 14724 112108
Swap: 0 0 0
1: Mem: 126832 38488 88344 0 0 23728
2: Mem: 126832 39496 87336 0 0 24752
3: Mem: 126832 40480 86352 0 0 25776
4: Mem: 126832 41596 85236 0 0 26800
5: Mem: 126832 42632 84200 0 0 27824
6: Mem: 126832 43640 83192 0 0 28848
7: Mem: 126832 44604 82228 0 0 29872
8: Mem: 126832 45740 81092 0 0 30896
9: Mem: 126832 46692 80140 0 0 31920
10: Mem: 126832 47728 79104 0 0 32944
11: Mem: 126832 48820 78012 0 0 33968
12: Mem: 126832 49828 77004 0 0 34992
13: Mem: 126832 50892 75940 0 0 36016
14: Mem: 126832 51928 74904 0 0 37040
15: Mem: 126832 52884 73948 0 0 38064
16: Mem: 126832 53928 72904 0 0 39088
17: Mem: 126832 55036 71796 0 0 40112
18: Mem: 126832 56016 70816 0 0 41136
19: Mem: 126832 57052 69780 0 0 42160
20: Mem: 126832 58088 68744 0 0 43184
21: Mem: 126832 59152 67680 0 0 44208
22: Mem: 126832 60160 66672 0 0 45232
23: Mem: 126832 61144 65688 0 0 46256
24:
<CRASHED>
Ok, what does this tell us? The crashes are *not* dependent on how much IO is
being done at a time. Writing to the same part of memory over and over again is
no problem.
I've repeated case 3 and 4 several times, it always crashes when free memory is
near 64MB.
So there seems to be some problem with the second ram bank?
comment:10 Changed 6 years ago by jluebbe@…
- Status changed from new to closed
- Resolution set to fixed
laforge has fixed a bug in u-boot and the current version no longer causes this bug:
root@fic-gta01:~$ dd bs=1k count=50k if=/dev/zero of=/media/ram/test
51200+0 records in
51200+0 records out
The relevant commit is:
http://svnweb.openmoko.org/trunk/src/target/u-boot/patches/uboot-20061030-neo1973.patch?rev=1320&r1=1176&r2=1320
