Re: [PATCH] mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used

[Alexey Brodkin <Alexey.Brodkin@synopsys.com>]

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