Menu
▾
▴
Re: [Gumstix-users] microSD issue
|
From: Ash C. <ash...@gm...> - 2010-04-13 06:39:56
|
Hi Nigel, So I did a bit of hunting on Google to see what I could find as I wasn't able to recreate this error. Do you notice high CPU utilization by the mmc work queue daemon (mmcqd)? If you run top, what is the 'niceness' of this process? One thread suggested the the priority of the thread was too high (nice=-5) and that a $ renice 0 `pidof mmcqd` might help fix the problem (this seemed a bit counterintuitive to me). -Ash On Mon, Apr 12, 2010 at 8:28 PM, Nigel <nig...@gm...> wrote: > Hi, > > So I put the original factory kernel and rootfs back onto the gumstix and > the microsd card works fine. > I have dumped 5GB of data onto it without the failure. > I will try it on another gumstix to see if it is just the combo of that > kernel with a particular gumstix. > > Looks like it is the old kernel for me. > > Nigel. > > On 9 April 2010 13:50, Nigel <nig...@gm...> wrote: >> >> Hi Ash, >> >> Thanks for responding. >> >> Initially it was wget. Then I tried bunzip2, then cat /dev/zero > ./zero >> >> All eventually gave the same error. >> >> Also when wget wouldn't work I download it on an another machine an SCPed >> it on with no problems. The only thing I can think for the difference is >> that wget was transfering at 100kbs and scp at 600kbs. >> >> Maybe there is a time component as the quicker processes got more written >> before the error occourd. >> >> eg: >> wget wrote 20ish MB >> bunzip wrote 206MB >> and cat /dev/zero wrote 903MB >> >> >> >> Also, the kernel built from the stock kernel config in the from the git >> repo doesn't fit in the allocated 1MB. Since I am not using the flash for >> the root file system I just use a bigger chunk for the kernel. I doubt that >> this has anything to do with the problem, but I thought I should bring it >> up. >> >> Thanks, >> >> Nigel. >> >> On 9 April 2010 03:02, Ash Charles <as...@gu...> wrote: >>> >>> Hi Nigel, >>> >>> What test are you doing to stress the microSD card? >>> >>> I don't see this on a VerdexPRO when I read or write to microSD but I >>> was just cat'ing /dev/urandom to a file. >>> >>> -Ash >>> >>> On Wed, Apr 7, 2010 at 7:41 PM, Nigel <nig...@gm...> wrote: >>> > Hi, >>> > >>> > I have a verdex XL6P with the following expansion boards: a >>> > netwifimicroSD-FCC and a consoleLCD-vx. >>> > >>> > I have built a verdex-console-image in a manor very similar to that >>> > described in: >>> > http://www.gumstix.net/wiki/index.php?title=Verdex_Git_Repository >>> > except uboot dosn't find my microSD card with mmcinit, so the kernel is >>> > in >>> > flash. >>> > >>> > I am using a microSD as my root filesystem. >>> > >>> > Everything boots up fine. >>> > >>> > But with any kind of intensive IO access to the microSD card I get: >>> > >>> > mmcblk0: error -110 sending stop command, response 0x900, card >>> > status >>> > 0xc00d00 >>> > end_request: I/O error, dev mmcblk0, sector 454808 >>> > Buffer I/O error on device mmcblk0p2, logical block 46726 >>> > lost page write due to I/O error on mmcblk0p2 >>> > >>> > then after some time sitting there: >>> > >>> > INFO: task mmcqd:18 blocked for more than 120 seconds. >>> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this >>> > message. >>> > mmcqd D c01d9aa8 0 18 2 0x00000000 >>> > [<c01d9aa8>] (schedule+0x428/0x484) from [<c01d9c5c>] >>> > (schedule_timeout+0x1c/0x184) >>> > [<c01d9c5c>] (schedule_timeout+0x1c/0x184) from [<c01d9550>] >>> > (wait_for_common+0xd8/0x174) >>> > [<c01d9550>] (wait_for_common+0xd8/0x174) from [<c0161530>] >>> > (mmc_wait_for_req+0x110/0x120) >>> > [<c0161530>] (mmc_wait_for_req+0x110/0x120) from [<c01665c8>] >>> > (mmc_blk_issue_rq+0x1c0/0x6c8) >>> > [<c01665c8>] (mmc_blk_issue_rq+0x1c0/0x6c8) from [<c0167120>] >>> > (mmc_queue_thread+0xe4/0xe8) >>> > [<c0167120>] (mmc_queue_thread+0xe4/0xe8) from [<c00551c0>] >>> > (kthread+0x78/0x80) >>> > [<c00551c0>] (kthread+0x78/0x80) from [<c003085c>] >>> > (kernel_thread_exit+0x0/0x8) >>> > INFO: task kjournald:19 blocked for more than 120 seconds. >>> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this >>> > message. >>> > kjournald D c01d9aa8 0 19 2 0x00000000 >>> > [<c01d9aa8>] (schedule+0x428/0x484) from [<c01d9b38>] >>> > (io_schedule+0x34/0x58) >>> > [<c01d9b38>] (io_schedule+0x34/0x58) from [<c00addf0>] >>> > (sync_buffer+0x48/0x54) >>> > [<c00addf0>] (sync_buffer+0x48/0x54) from [<c01d9e68>] >>> > (__wait_on_bit+0x5c/0xa8) >>> > [<c01d9e68>] (__wait_on_bit+0x5c/0xa8) from [<c01d9f24>] >>> > (out_of_line_wait_on_bit+0x70/0x7c) >>> > [<c01d9f24>] (out_of_line_wait_on_bit+0x70/0x7c) from [<c00eb844>] >>> > (journal_commit_transaction+0x9e4/0x10d0) >>> > [<c00eb844>] (journal_commit_transaction+0x9e4/0x10d0) from >>> > [<c00eec94>] >>> > (kjournald+0xa8/0x1d4) >>> > [<c00eec94>] (kjournald+0xa8/0x1d4) from [<c00551c0>] >>> > (kthread+0x78/0x80) >>> > [<c00551c0>] (kthread+0x78/0x80) from [<c003085c>] >>> > (kernel_thread_exit+0x0/0x8) >>> > INFO: task bunzip2:658 blocked for more than 120 seconds. >>> > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this >>> > message. >>> > bunzip2 D c01d9aa8 0 658 653 0x00020000 >>> > [<c01d9aa8>] (schedule+0x428/0x484) from [<c00ea3c8>] >>> > (do_get_write_access+0x240/0x420) >>> > [<c00ea3c8>] (do_get_write_access+0x240/0x420) from [<c00ea5d0>] >>> > (journal_get_write_access+0x28/0x40) >>> > [<c00ea5d0>] (journal_get_write_access+0x28/0x40) from [<c00e0130>] >>> > (__ext3_journal_get_write_access+0x20/0x50) >>> > [<c00e0130>] (__ext3_journal_get_write_access+0x20/0x50) from >>> > [<c00d4768>] (ext3_reserve_inode_write+0x40/0x80) >>> > [<c00d4768>] (ext3_reserve_inode_write+0x40/0x80) from [<c00d47c4>] >>> > (ext3_mark_inode_dirty+0x1c/0x3c) >>> > [<c00d47c4>] (ext3_mark_inode_dirty+0x1c/0x3c) from [<c00d490c>] >>> > (ext3_dirty_inode+0x64/0x80) >>> > [<c00d490c>] (ext3_dirty_inode+0x64/0x80) from [<c00a8484>] >>> > (__mark_inode_dirty+0x2c/0xe4) >>> > [<c00a8484>] (__mark_inode_dirty+0x2c/0xe4) from [<c00d19f8>] >>> > (ext3_new_blocks+0x7c/0x550) >>> > [<c00d19f8>] (ext3_new_blocks+0x7c/0x550) from [<c00d59cc>] >>> > (ext3_get_blocks_handle+0x3e4/0x8e0) >>> > [<c00d59cc>] (ext3_get_blocks_handle+0x3e4/0x8e0) from [<c00d5f60>] >>> > (ext3_get_block+0x98/0xd0) >>> > [<c00d5f60>] (ext3_get_block+0x98/0xd0) from [<c00aed70>] >>> > (__block_prepare_write+0x1b4/0x480) >>> > [<c00aed70>] (__block_prepare_write+0x1b4/0x480) from [<c00af234>] >>> > (block_write_begin+0x90/0x114) >>> > [<c00af234>] (block_write_begin+0x90/0x114) from [<c00d7684>] >>> > (ext3_write_begin+0xf8/0x228) >>> > [<c00d7684>] (ext3_write_begin+0xf8/0x228) from [<c006f280>] >>> > (generic_file_buffered_write+0x104/0x2f0) >>> > [<c006f280>] (generic_file_buffered_write+0x104/0x2f0) from >>> > [<c006fa80>] >>> > (__generic_file_aio_write_nolock+0x41c/0x468) >>> > [<c006fa80>] (__generic_file_aio_write_nolock+0x41c/0x468) from >>> > [<c007048c>] (generic_file_aio_write+0x74/0xec) >>> > [<c007048c>] (generic_file_aio_write+0x74/0xec) from [<c00d29a8>] >>> > (ext3_file_write+0x20/0xa0) >>> > [<c00d29a8>] (ext3_file_write+0x20/0xa0) from [<c008e5ec>] >>> > (do_sync_write+0xb4/0x100) >>> > [<c008e5ec>] (do_sync_write+0xb4/0x100) from [<c008f090>] >>> > (vfs_write+0xac/0x158) >>> > [<c008f090>] (vfs_write+0xac/0x158) from [<c008f1f4>] >>> > (sys_write+0x40/0x6c) >>> > [<c008f1f4>] (sys_write+0x40/0x6c) from [<c002fea0>] >>> > (ret_fast_syscall+0x0/0x2c) >>> > >>> > >>> > I have tried 2 microSD cards, one Sandisk 8gb, and some other 2gb card. >>> > I have tried different file systems. >>> > I have tried swapping the netwifimicroSD-FCC board. >>> > and still I get the error. >>> > >>> > Any light anyone could shed would be greatly appreciated. >>> > >>> > Thanks, >>> > >>> > NigelB. >>> > >>> > >>> > ------------------------------------------------------------------------------ >>> > Download Intel® Parallel Studio Eval >>> > Try the new software tools for yourself. Speed compiling, find bugs >>> > proactively, and fine-tune applications for parallel performance. >>> > See why Intel Parallel Studio got high marks during beta. >>> > http://p.sf.net/sfu/intel-sw-dev >>> > _______________________________________________ >>> > gumstix-users mailing list >>> > gum...@li... >>> > https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> > >>> > >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |