[#4915] Test spi/SD with exceptionally by framework way

Submitted By: Bill Xie

Open Date

2009-02-17 05:26:32 Close Date

2010-02-17 13:03:46

Priority:

Medium Assignee:

Nobody

Status:

Closed Fixed In Release:

N/A

Found In Release:

2008R1.5-RC3 Release:

uclinux-dist-trunk-7715

Category:

N/A Board:

Custom

Processor:

BF527 Silicon Revision:

Is this bug repeatable?:

Yes Resolution:

Rejected

Uboot version or rev.:

U-Boot 1.1.6 Toolchain version or rev.:

4.1.2

App binary format:

N/A

Summary: Test spi/SD with exceptionally by framework way

Details:

I use other way to test writing data to sd except by bonnie++.Using next ways repetitive test, kernel may be exception.

1:time dd if=/dev/zero of=/mnt/320_1000000.bin bs=320 count=1000000

This way also lead to exceptiona.the count is more big,the problem is easy to emerg.

2.Using program:

Underside is the test code.It write 320 byte data to sd for 100000 times.

if times is more big,the problem is easy to appear.

#include <stdio.h>

#include <sys/time.h>

#include <unistd.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <sys/ioctl.h>

#include <sys/vfs.h>

int main()

{

struct timeval tv,tv1;

struct timezone tz,tz1;

FILE * fp;

short buf[160] = {0};

int num = 0;

int i = 0;

float time;

fp=fopen("/mnt/sd1.dat","w+");

if(fp == NULL)

{

printf("open file faild\n");

return -1;

}

gettimeofday(&tv,&tz);

printf("fwrite before tv_sev: %d\n",tv.tv_sec);

printf("fwrite before tv_usec:%d\n",tv.tv_usec);

while(1)

{

num = fwrite(buf,sizeof(short),160,fp);

if( num!= 160)

{

printf("write data %d is not equal to 160 \n",num);

break;

}

if(i>99999)

{

printf("write data ok %d\n",i);

break;

}

i++;

}

gettimeofday(&tv1,&tz1);

printf("fwite after tv_sev: %d\n",tv1.tv_sec);

printf("fwite after tv_usec:%d\n",tv1.tv_usec);

time= (tv1.tv_sec-tv.tv_sec-1)*1000+(1000000+tv1.tv_usec-tv.tv_usec)/1000;

printf("320 bytes take time is %f ms\n",time/i);

fclose(fp);

return 0;

}

Out message:

syslogd invoked oom-killer: gfp_mask=0x200d2, order=0, oomkilladj=0

Hardware Trace:

Stack info:

SP: [0x006d9b84] <0x006d9b84> /* kernel dynamic memory */

FP: (0x006d9b7c)

Memory from 0x006d9b80 to 006da000

006d9b80:<00039b8e>[00000000]<00031942> 01e89cc0 00000000 0000ffff 01e89868 000200d2

006d9ba0: 00000000 00000000 01ed9040 ffffff1c <00031afa> 000200d2 001b159c 00000008

006d9bc0: 006d8000 <00031ca0> 01e89cc0 001f4f08 00000124 00000008 01ed9040 000000a0

006d9be0: 001f4f08 006d9c08 00000395 006d8000 00000008 00000000 001b159c 006d9be4

006d9c00: 00000395 15382102 00000000 00000001 <00033cc0> 01e89680 0020c234 00000000

006d9c20: 00000000 000200d2 00000000 00000042 000200d2 000200d2 00000000 0020c234

006d9c40: 00000001 00000048 006d8000 006d8000 00000000 000200d2 006d8000 00000010

006d9c60: 00000000 0000000c 00000000 00000000 00000000 <0002f950> ffffffff 01845480

006d9c80: 01845480 00000000 006bdd8c 00000000 00001108 006d9cb4 <0000a5a0><0000a5ca>

006d9ca0: 00000000 <0005441c> 006d9d34 00000000 01108000 0000005f 00001000 <007203e0>

006d9cc0: 00000000 <0002fe1a><0002fdb2> 006d8000 006bdd8c 0000005f 00000000 01108000

006d9ce0: 00001000 <00120baa><0011ced4> 01108000 00000000 0000005f 00000000 006d9d34

006d9d00: 006d9d30 006bdd8c 00177950 006bdcc4 00000000 00000000 00177950 0000000f

006d9d20: 006d9e9c 00000001 0000000f 0000005f 006d9e9c <007203e0> 006bdd8c <000302b2>

006d9d40: 006bdcc4 0000006e 01845480 00000000 006d9e9c 00000000 01107ff1 006d9e18

006d9d60: 00000000 00000000 01107ff1 00000000 006d9e60 0000006e 00000000 006d9e18

006d9d80: 006b57e0 01e90820 00000001 006d9e9c 000000ff 00619f04 51032e06 0000008f

006d9da0: 0000006e 006bdd8c <00030c34> 006d9e18 006bdcc4 01845480 006bdd40 006d9e9c

006d9dc0: 00000000 01107ff1 006d9e18 006d9e9c 00000001 006d9e60 00000001 00000000

006d9de0: 00661e14 <0003f298> 01845480 006d9ef0 00000053 006d9e18 006d9e9c 0000006e

006d9e00: 00000004 00417658 00000000 00000001 01107ff1 00000000 00000000 006bdcc4

006d9e20: 00000000 00000001 ffffffff 01845480 00000000 00000000 00000000 00000000

006d9e40: 01e89680 00000000 00000000 0041775c 01e89680 0001fc80 006d9e58 006d9e58

006d9e60: 01107ff1 00000000 00000000 0000ffff 00000100 00000006 0000006e 006d9ec0

006d9e80: 00000010 <00066c10> 00417738 01845480 00000037 <000682a4> 01845480 006da318

006d9ea0: 0000006e <0003f97c> 01845480 00000004 006d9ef0 006da318 00000001 00000000

006d9ec0:<00661e54> 006d9ef0 00661e8c <0003fce2> 01845480 006da318 0000006e 00000004

006d9ee0: 00000007 001ef540 00000000 006d9ef0 01107ff1 00000000 00000000 <ffa0076c>

006d9f00: 0003fcb0 00000000 ffffe000 ffffe000 00000003 0000fffe 00000004 00000004

006d9f20: 00000004 006027e6 00008000 00000000 00000000 006da000 006027e6 006027e6

006d9f40:<0061a0b0><ffa00ca0> 02001004 0060ad2d 0060be1d 0060ad2c 0060be1a 00000000

006d9f60: 00000000 00000008 00000000 00000008 00000000 00000000 00000000 00000000

006d9f80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

006d9fa0: 00000000 00000000 00000000 00000053 006da170 00661e08 00661e14 00659b04

006d9fc0: 006da318 00000053 0065a0b4 006da388 00000004 0000006e 006da318 00000004

006d9fe0: 00000004 00000004 0000006e 006da318 00000004 00000004 00000004 00000006

006da000: 00000598

Return addresses in stack:

address : <0x00039b8e> { _congestion_wait + 0x62 }

address : <0x00031942> { _oom_kill_process + 0xda }

address : <0x00031afa> { _badness + 0xd2 }

address : <0x00031ca0> { _out_of_memory + 0x128 }

address : <0x00033cc0> { ___alloc_pages_internal + 0x234 }

address : <0x0002f950> { _grab_cache_page_write_begin + 0x58 }

address : <0x0000a5a0> { _try_to_wake_up + 0x50 }

address : <0x0000a5ca> { _try_to_wake_up + 0x7a }

address : <0x0005441c> { _simple_write_begin + 0x28 }

BUG: rwlock cpu recursion on CPU#0, pdflush/355, ff800000

Hardware Trace:

Stack info:

SP: [0x0161ff8c] <0x0161ff8c> /* kernel dynamic memory */

FP: (0x0161ffa0)

Memory from 0x0161ff80 to 01620000

0161ff80: 00000000 0161ff8c 00000163 [ff800000]<000b5e58> ff800000 0161e000 00000000

0161ffa0:(00000000)<00011baa><00011be8> 00000000 0161e000 00000040 0161ffb8 0161ffb8

0161ffc0: 00025ba1 00000001 0161ffc8 0161ffc8 00000000 <0000145a> 00000000 00000000

0161ffe0: 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff 00000006

01620000: 73203a72

Return addresses in stack:

address : <0x000b5e58> { __raw_write_lock + 0x68 }

frame 1 : <0x00011baa> { _do_exit + 0xf6 }

address : <0x00011be8> { _do_exit + 0x134 }

address : <0x0000145a> { _kernel_thread_helper + 0xa }

Follow-ups

--- Sonic Zhang 2009-02-18 04:52:21

Not a bug.

You are running out of memory and your app is killed by oom_kill_process().

--- Bill Xie 2009-02-18 21:38:47

But sd card using blackfin spi bus directly way is ok.

this test program is no problem.

Why?

Thank you.

--- Robin Getz 2009-02-19 09:50:35

Because sd flushes the page cache more often.

-Robin

--- Bill Xie 2009-02-20 01:36:54

Thank you for your reply.In my appliction the data stream is often written to

sd card with large times.But I don't know how to solve or avoid the problem.

--Bill

Files

Changes

Commits

Dependencies

Duplicates

Associations