[Milkymist-devel] Data cache problems

Sébastien Bourdeauducq sebastien.bourdeauducq at lekernel.net
Sat Aug 22 05:25:55 PDT 2009


Hi,

I tried running Takeshi's binaries with the data cache disabled. Log is below, 
and confirms Takeshi's results.

I'm starting to have serious doubts about the data cache. When porting DOpE, 
results are clear:
- when the data cache is disabled, DOpE works perfectly
- when it is enabled, DOpE crashes at random points and fails to paint the 
whole screen (some elements from http://lekernel.net/blog/wp-
content/uploads/2009/08/dope.jpg are missing). The problem is highly random in 
nature: the missing elements are not always the same, and when adding debug 
printf's to sort out the issue they changed. And when everything was full of 
printf's, the problem even disappeared!!!

At first sight, what DOpE and Linux have in common is that they both have a 
relatively big memory footprint (the DOpE image is 1.5MB), while other code 
I've run without experiencing data cache problems was less than 110KB.

My plan suggestion is:
- we continue to work on Linux with the data cache disabled
- once Linux is clearly working without the cache (with userland etc.) and 
crashing with the cache, we ask a Lattice engineer about the problem
In the meantime:
- we may try to get our hands on a Lattice board to compare results and 
experiment with the cache
- we may try to synthesize the bitstream with other tools than Xst - it might 
be that Xst produces a broken netlist, at the origin of the bug

Regards,
Sébastien

===
I: Read a 1447680 byte image from BOOT.BIN, CRC32 a76e29ab
I: Read a 15 byte image from CMDLINE.TXT, CRC32 0a586c34
I: Read a 16777216 byte image from INITRD.BIN, CRC32 92ed69ee
I: Booting...
[42949372.960000] Linux version 2.6.23 (tmatsuya at tmatsuyaxpc) (gcc version 
4.4.0 (GCC) ) #39 Thu Aug 20 02:14:03 JST 2009
[42949372.960000] console [early0] enabled
[42949372.960000] memory from 40171000 - 44000000
[42949372.960000] reserving initrd memory: 41002000 size 1000000
[42949372.960000] start_mem is 0x40171000
[42949372.960000] virtual_end is 0x44000000
[42949372.960000] before free_area_init
[42949372.960000] free_area_init -> start_mem is 0x40171000
[42949372.960000] virtual_end is 0x44000000
[42949372.960000] after free_area_init
[42949372.960000] Built 1 zonelists in Zone order.  Total pages: 276352
[42949372.960000] Kernel command line: console=early
[42949372.960000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[42949373.020000] Dentry cache hash table entries: 262144 (order: 8, 1048576 
bytes)
[42949373.100000] Inode-cache hash table entries: 131072 (order: 7, 524288 
bytes)
[42949373.140000] Memory available: 37120k/65536k RAM, (1356k kernel code, 58k 
data)
[42949373.150000] Calibrating delay loop... 158.92 BogoMIPS (lpj=794624)
[42949373.380000] Mount-cache hash table entries: 512
[42949373.390000] NET: Registered protocol family 16
[42949373.430000] checking if image is initramfs...it isn't (bad gzip magic 
numbers); looks like an initrd
[42949377.530000] Freeing initrd mem: 16383k freed
[42949377.570000] io scheduler noop registered (default)
[42949378.160000] RAMDISK driver initialized: 1 RAM disks of 16384K size 1024 
blocksize
[42949378.170000] RAMDISK: ext2 filesystem found at block 0
[42949378.180000] RAMDISK: Loading 16384KiB [1 disk] into ram disk... done.
[42949384.890000] VFS: Mounted root (ext2 filesystem).
[42949384.960000] BUG: failure at mm/nommu.c:114/kobjsize()!
[42949384.960000] Kernel panic - not syncing: BUG!



More information about the Devel mailing list