lkml.org 
[lkml]   [2015]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used
Date
Hi Jaehoon,

On Wed, 2015-07-08 at 13:14 +0900, Jaehoon Chung wrote:
> Hi, Alexey.
>
> On 06/25/2015 05:25 PM, Alexey Brodkin wrote:
> > As per DW MobileStorage databook "each descriptor can transfer up to 4kB
> > of data in chained mode", moreover buffer size that is put in "des1" is
> > limited to 13 bits, i.e. for example on attempt to
> > IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written
> > will be 0.
> >
> > On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in
> > SG-list of 8kB size and that leads to unpredictable behavior of the
> > SD/MMC controller.
>
> I didn't see your problem, since i didn't test with 8K PAGE_SIZE.
> But I think your patch is reasonable.
> As possible, I want to know in more detail what unpredictable behavior.
> (Just stuck behavior?)

Please find below my observations from before the fix.

I noticed that some simple operations (especially reads of large files from FAT partitions)
lead to dw_mmc being unresponsive, see below and example:
---------------------------------->8------------------------------
$ mkdir /sd1
$ mount /dev/mmcblk0p1 /sd1
FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ARCLinux]$ ls -lah /sd1
total 7252
drwxr-xr-x 8 root root 16.0K Dec 31 16:00 .
drwxrwxrwt 16 root root 380 Dec 31 16:03 ..
-rwxr-xr-x 1 root root 241 Dec 18 2014 boot.scr
-rwxr-xr-x 1 root root 44.3K Dec 18 2014 script.bin
-rwxr-xr-x 1 root root 7.0M Jan 13 2015 uImage
[ARCLinux]$ md5sum /sd1/uImage
---------------------------------->8------------------------------

At this point nothing was happening for a long time, so I pressed Ctrl-C and
run another "ls" that worked perfectly fine on the previous step (see above).
But that time "ls" didn't work, instead I saw:
---------------------------------->8------------------------------
$ mkdir /sd2
$ mount /dev/mmcblk0p2 /sd2
$ ls -lah /sd2
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004

Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004

Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004

Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
INFO: task ls:104 blocked for more than 10 seconds.
Not tainted 3.18.10-01062-g89ecf3c-dirty #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ls D 8020e79c 0 104 84 0x00000004

Stack Trace:
__switch_to+0x0/0x98
__schedule+0x1d0/0x494
io_schedule+0x42/0x6c
bit_wait_io+0x1e/0x40
__wait_on_bit+0x86/0xac
out_of_line_wait_on_bit+0x48/0x58
ext4_bread+0x68/0x7c
__ext4_read_dirblock+0x32/0x320
htree_dirblock_to_tree+0x4a/0x174
ext4_htree_fill_tree+0x76/0x1e0
ext4_readdir+0x5e6/0x86c
iterate_dir+0x80/0xf4
SyS_getdents64+0x64/0xd4
ret_from_system_call+0x0/0x4
---------------------------------->8------------------------------

Seeing that problem I started to check what data is being sent to MMC controller
and pretty quickly found-out that sometimes value 8192 is written in the first
13 bits of DES1 that in case of IDMAC_SET_BUFFER1_SIZE macro usage effectively
writes 0. That was a clean misuse of MMC controller (it gets buffer descriptor
that points to zero-sized buffer). Once I fixed that flaw my initial problem
went away.

Let me know if that description makes sense to you.

-Alexey

\
 
 \ /
  Last update: 2015-07-08 11:01    [W:0.108 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site