Messages in this thread | | | From | Alexey Brodkin <> | Subject | Re: [PATCH] mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used | Date | Wed, 8 Jul 2015 08:45:45 +0000 |
| |
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
| |