[SHDCI] Heavy (thousands) DMA leaks

[SHDCI] Heavy (thousands) DMA leaks

[Jiri Slaby]

Hi,

after
commit 348487cb28e66b032bae1b38424d81bf5b444408
Author: Haibo Chen <haibo.chen@freescale.com>
Date:   Tue Dec 9 17:04:05 2014 +0800

    mmc: sdhci: use pipeline mmc requests to improve performance

I see heavy DMA leaks which result in warnings of the dma api debug code:
WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:509 add_dma_entry+0x138/0x150()
DMA-API: exceeded 7 overlapping mappings of cacheline 0x000000000b20ec00



And mainly this one upon sdhci module removal. It is over 4000 leaked
mappings during one card transfer.
mmc0: card e624 removed
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1263 at lib/dma-debug.c:974
dma_debug_device_change+0x158/0x1c0()
pci 0000:02:00.0: DMA-API: device driver has pending DMA allocations
while released from device [count=4041]
One of leaked entries details: [device address=0x00000000ddff0000]
[size=65536 bytes] [mapped with DMA_FROM_DEVICE] [mapped as scather-gather]
Modules linked in:
CPU: 2 PID: 1263 Comm: bash Tainted: G        W       4.2.0-rc4 #12
Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
 ffffffff81cc5e32 ffff8800d03c3b68 ffffffff81820938 0000000000000000
 ffff8800d03c3bb8 ffff8800d03c3ba8 ffffffff810b827a 0000000100260021
 ffff88030e500000 0000000000000fc9 ffff88030d95aeb8 ffff88030e4ddd68
Call Trace:
 [<ffffffff81820938>] dump_stack+0x4c/0x6e
 [<ffffffff810b827a>] warn_slowpath_common+0x8a/0xc0
 [<ffffffff810b82f6>] warn_slowpath_fmt+0x46/0x50
 [<ffffffff813248c8>] dma_debug_device_change+0x158/0x1c0
 [<ffffffff810d4e9d>] notifier_call_chain+0x4d/0x80
 [<ffffffff810d51fd>] __blocking_notifier_call_chain+0x4d/0x70
 [<ffffffff810d5236>] blocking_notifier_call_chain+0x16/0x20
 [<ffffffff814db395>] __device_release_driver+0x105/0x130
 [<ffffffff814db3e3>] device_release_driver+0x23/0x30
 [<ffffffff814d95ca>] unbind_store+0xba/0xe0
 [<ffffffff8123c638>] ? kernfs_fop_write+0xe8/0x170
 [<ffffffff814d8ac4>] drv_attr_store+0x24/0x30
 [<ffffffff8123ce4a>] sysfs_kf_write+0x3a/0x50
 [<ffffffff8123c670>] kernfs_fop_write+0x120/0x170
 [<ffffffff811ce9e8>] __vfs_write+0x28/0xe0
 [<ffffffff811d1209>] ? __sb_start_write+0x49/0xe0
 [<ffffffff810e3ba5>] ? local_clock+0x25/0x30
 [<ffffffff811cf041>] vfs_write+0xa1/0x170
 [<ffffffff810e43c4>] ? vtime_account_user+0x54/0x60
 [<ffffffff811cfce6>] SyS_write+0x46/0xa0
 [<ffffffff81180f83>] ? context_tracking_user_exit+0x13/0x20
 [<ffffffff8182a017>] entry_SYSCALL_64_fastpath+0x12/0x6a
---[ end trace 398181ad32332b33 ]---
Mapped at:
 [<ffffffff81324492>] debug_dma_map_sg+0x122/0x140
 [<ffffffff81616dd3>] sdhci_pre_dma_transfer+0xc3/0x1b0
 [<ffffffff81616f02>] sdhci_pre_req+0x42/0x70
 [<ffffffff81601492>] mmc_pre_req+0x42/0x60
 [<ffffffff8160290e>] mmc_start_req+0x3e/0x400

I already fixed one symptom -- memory corruption. Could you revisit the
commit once again, as there is surely at least one more bug?

thanks,
-- 
js
suse labs

RE: [SHDCI] Heavy (thousands) DMA leaks

[Chen Bough]

Hi Jiri,

I will check this issue ASAP, thanks for report this!


Best Regards
Haibo Chen


> -----Original Message-----
> From: Jiri Slaby [mailto:jslaby@suse.cz]
> Sent: Thursday, July 30, 2015 5:32 PM
> To: Chen Haibo-B51421
> Cc: Ulf Hansson; linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: [SHDCI] Heavy (thousands) DMA leaks
> 
> Hi,
> 
> after
> commit 348487cb28e66b032bae1b38424d81bf5b444408
> Author: Haibo Chen <haibo.chen@freescale.com>
> Date:   Tue Dec 9 17:04:05 2014 +0800
> 
>     mmc: sdhci: use pipeline mmc requests to improve performance
> 
> I see heavy DMA leaks which result in warnings of the dma api debug code:
> WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:509 add_dma_entry+0x138/0x150()
> DMA-API: exceeded 7 overlapping mappings of cacheline 0x000000000b20ec00
> 
> 
> 
> And mainly this one upon sdhci module removal. It is over 4000 leaked
> mappings during one card transfer.
> mmc0: card e624 removed
> ------------[ cut here ]------------
> WARNING: CPU: 2 PID: 1263 at lib/dma-debug.c:974
> dma_debug_device_change+0x158/0x1c0()
> pci 0000:02:00.0: DMA-API: device driver has pending DMA allocations
> while released from device [count=4041] One of leaked entries details:
> [device address=0x00000000ddff0000]
> [size=65536 bytes] [mapped with DMA_FROM_DEVICE] [mapped as scather-
> gather] Modules linked in:
> CPU: 2 PID: 1263 Comm: bash Tainted: G        W       4.2.0-rc4 #12
> Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
>  ffffffff81cc5e32 ffff8800d03c3b68 ffffffff81820938 0000000000000000
>  ffff8800d03c3bb8 ffff8800d03c3ba8 ffffffff810b827a 0000000100260021
>  ffff88030e500000 0000000000000fc9 ffff88030d95aeb8 ffff88030e4ddd68 Call
> Trace:
>  [<ffffffff81820938>] dump_stack+0x4c/0x6e  [<ffffffff810b827a>]
> warn_slowpath_common+0x8a/0xc0  [<ffffffff810b82f6>]
> warn_slowpath_fmt+0x46/0x50  [<ffffffff813248c8>]
> dma_debug_device_change+0x158/0x1c0
>  [<ffffffff810d4e9d>] notifier_call_chain+0x4d/0x80  [<ffffffff810d51fd>]
> __blocking_notifier_call_chain+0x4d/0x70
>  [<ffffffff810d5236>] blocking_notifier_call_chain+0x16/0x20
>  [<ffffffff814db395>] __device_release_driver+0x105/0x130
>  [<ffffffff814db3e3>] device_release_driver+0x23/0x30
> [<ffffffff814d95ca>] unbind_store+0xba/0xe0  [<ffffffff8123c638>] ?
> kernfs_fop_write+0xe8/0x170  [<ffffffff814d8ac4>]
> drv_attr_store+0x24/0x30  [<ffffffff8123ce4a>] sysfs_kf_write+0x3a/0x50
> [<ffffffff8123c670>] kernfs_fop_write+0x120/0x170  [<ffffffff811ce9e8>]
> __vfs_write+0x28/0xe0  [<ffffffff811d1209>] ? __sb_start_write+0x49/0xe0
> [<ffffffff810e3ba5>] ? local_clock+0x25/0x30  [<ffffffff811cf041>]
> vfs_write+0xa1/0x170  [<ffffffff810e43c4>] ? vtime_account_user+0x54/0x60
> [<ffffffff811cfce6>] SyS_write+0x46/0xa0  [<ffffffff81180f83>] ?
> context_tracking_user_exit+0x13/0x20
>  [<ffffffff8182a017>] entry_SYSCALL_64_fastpath+0x12/0x6a
> ---[ end trace 398181ad32332b33 ]---
> Mapped at:
>  [<ffffffff81324492>] debug_dma_map_sg+0x122/0x140  [<ffffffff81616dd3>]
> sdhci_pre_dma_transfer+0xc3/0x1b0  [<ffffffff81616f02>]
> sdhci_pre_req+0x42/0x70  [<ffffffff81601492>] mmc_pre_req+0x42/0x60
> [<ffffffff8160290e>] mmc_start_req+0x3e/0x400
> 
> I already fixed one symptom -- memory corruption. Could you revisit the
> commit once again, as there is surely at least one more bug?
> 
> thanks,
> --
> js
> suse labs

RE: [SHDCI] Heavy (thousands) DMA leaks

[Chen Bough]

Hi Js,

I carefully review my patch, all the DMA memory mapped in sdhci_pre_req() is unmapped in sdhci_post_req.

Can you provide the method of your testing DMA leaks?  You said over 4000 leaked mappings during one card transfer, if true, 
We can't map any dma memory after some sd transfer, do you meet this?


Best Regards
Haibo Chen



> -----Original Message-----
> From: Jiri Slaby [mailto:jslaby@suse.cz]
> Sent: Thursday, July 30, 2015 5:32 PM
> To: Chen Haibo-B51421
> Cc: Ulf Hansson; linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: [SHDCI] Heavy (thousands) DMA leaks
> 
> Hi,
> 
> after
> commit 348487cb28e66b032bae1b38424d81bf5b444408
> Author: Haibo Chen <haibo.chen@freescale.com>
> Date:   Tue Dec 9 17:04:05 2014 +0800
> 
>     mmc: sdhci: use pipeline mmc requests to improve performance
> 
> I see heavy DMA leaks which result in warnings of the dma api debug code:
> WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:509 add_dma_entry+0x138/0x150()
> DMA-API: exceeded 7 overlapping mappings of cacheline 0x000000000b20ec00
> 
> 
> 
> And mainly this one upon sdhci module removal. It is over 4000 leaked
> mappings during one card transfer.
> mmc0: card e624 removed
> ------------[ cut here ]------------
> WARNING: CPU: 2 PID: 1263 at lib/dma-debug.c:974
> dma_debug_device_change+0x158/0x1c0()
> pci 0000:02:00.0: DMA-API: device driver has pending DMA allocations
> while released from device [count=4041] One of leaked entries details:
> [device address=0x00000000ddff0000]
> [size=65536 bytes] [mapped with DMA_FROM_DEVICE] [mapped as scather-
> gather] Modules linked in:
> CPU: 2 PID: 1263 Comm: bash Tainted: G        W       4.2.0-rc4 #12
> Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
>  ffffffff81cc5e32 ffff8800d03c3b68 ffffffff81820938 0000000000000000
>  ffff8800d03c3bb8 ffff8800d03c3ba8 ffffffff810b827a 0000000100260021
>  ffff88030e500000 0000000000000fc9 ffff88030d95aeb8 ffff88030e4ddd68 Call
> Trace:
>  [<ffffffff81820938>] dump_stack+0x4c/0x6e  [<ffffffff810b827a>]
> warn_slowpath_common+0x8a/0xc0  [<ffffffff810b82f6>]
> warn_slowpath_fmt+0x46/0x50  [<ffffffff813248c8>]
> dma_debug_device_change+0x158/0x1c0
>  [<ffffffff810d4e9d>] notifier_call_chain+0x4d/0x80  [<ffffffff810d51fd>]
> __blocking_notifier_call_chain+0x4d/0x70
>  [<ffffffff810d5236>] blocking_notifier_call_chain+0x16/0x20
>  [<ffffffff814db395>] __device_release_driver+0x105/0x130
>  [<ffffffff814db3e3>] device_release_driver+0x23/0x30
> [<ffffffff814d95ca>] unbind_store+0xba/0xe0  [<ffffffff8123c638>] ?
> kernfs_fop_write+0xe8/0x170  [<ffffffff814d8ac4>]
> drv_attr_store+0x24/0x30  [<ffffffff8123ce4a>] sysfs_kf_write+0x3a/0x50
> [<ffffffff8123c670>] kernfs_fop_write+0x120/0x170  [<ffffffff811ce9e8>]
> __vfs_write+0x28/0xe0  [<ffffffff811d1209>] ? __sb_start_write+0x49/0xe0
> [<ffffffff810e3ba5>] ? local_clock+0x25/0x30  [<ffffffff811cf041>]
> vfs_write+0xa1/0x170  [<ffffffff810e43c4>] ? vtime_account_user+0x54/0x60
> [<ffffffff811cfce6>] SyS_write+0x46/0xa0  [<ffffffff81180f83>] ?
> context_tracking_user_exit+0x13/0x20
>  [<ffffffff8182a017>] entry_SYSCALL_64_fastpath+0x12/0x6a
> ---[ end trace 398181ad32332b33 ]---
> Mapped at:
>  [<ffffffff81324492>] debug_dma_map_sg+0x122/0x140  [<ffffffff81616dd3>]
> sdhci_pre_dma_transfer+0xc3/0x1b0  [<ffffffff81616f02>]
> sdhci_pre_req+0x42/0x70  [<ffffffff81601492>] mmc_pre_req+0x42/0x60
> [<ffffffff8160290e>] mmc_start_req+0x3e/0x400
> 
> I already fixed one symptom -- memory corruption. Could you revisit the
> commit once again, as there is surely at least one more bug?
> 
> thanks,
> --
> js
> suse labs

Re: [SHDCI] Heavy (thousands) DMA leaks

[Jiri Slaby]

Hi,

On 08/03/2015, 11:30 AM, Chen Bough wrote:
> I carefully review my patch, all the DMA memory mapped in sdhci_pre_req() is unmapped in sdhci_post_req.

I suspect 'host_cookie' or 'next' handling is bad somewhere. But I don't
know...

> Can you provide the method of your testing DMA leaks?

boot kernel with CONFIG_DMA_API_DEBUG
insert the card
mount it
rsync from the card ~200 MB
umount it
unload the sdhci driver
the leak warning is reported

I am not sure whether suspend-resume is needed after the first step.

> You said over 4000 leaked mappings during one card transfer, if true, 
> We can't map any dma memory after some sd transfer, do you meet this?

Yes, I see:
sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 65536 bytes)
after some time. The driver falls back to non-DMA transfers after that.
It also generates a warning about that:
WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857
sdhci_prepare_data+0x8ec/0x900 [sdhci]()

thanks,
-- 
js
suse labs

Re: [SHDCI] Heavy (thousands) DMA leaks

[Jiri Slaby]

[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]

On 08/03/2015, 11:39 AM, Jiri Slaby wrote:
> Hi,
> 
> On 08/03/2015, 11:30 AM, Chen Bough wrote:
>> I carefully review my patch, all the DMA memory mapped in sdhci_pre_req() is unmapped in sdhci_post_req.
> 
> I suspect 'host_cookie' or 'next' handling is bad somewhere. But I don't
> know...
> 
>> Can you provide the method of your testing DMA leaks?
> 
> boot kernel with CONFIG_DMA_API_DEBUG
> insert the card
> mount it
> rsync from the card ~200 MB
> umount it
> unload the sdhci driver
> the leak warning is reported
> 
> I am not sure whether suspend-resume is needed after the first step.

No, it's not. This is sufficient:
boot kernel with CONFIG_DMA_API_DEBUG
insert the card
<no mounting, partition table read is enough>
remove the card
unload the sdhci driver
the leak warning is reported

>> You said over 4000 leaked mappings during one card transfer, if true, 
>> We can't map any dma memory after some sd transfer, do you meet this?
> 
> Yes, I see:
> sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 65536 bytes)
> after some time. The driver falls back to non-DMA transfers after that.
> It also generates a warning about that:
> WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857
> sdhci_prepare_data+0x8ec/0x900 [sdhci]()

I am attaching a debug patch and a debug log. You can see where
0x00000000fffb0000 and 0x00000000fffe0000 is leaked. It is when 'invalid
cookie' error happens.

regards,
-- 
js
suse labs

[-- Attachment #2: bad_dma --]
[-- Type: text/plain, Size: 30960 bytes --]

[  474.663337] sdhci_pre_dma_transfer: mapped ffff88030bfe7bc0 0x00000000fffff3f0 (wanted=1, got=1), next=          (null), hcook=0, ncook=1
[  474.663844] sdhci_finish_data: unmapping ffff88030bfe7bc0 phys=0x00000000fffff3f0 size=1
[  474.664109] sdhci_pre_dma_transfer: mapped ffff88030bfe7bc0 0x00000000ffffe310 (wanted=1, got=1), next=          (null), hcook=0, ncook=1
[  474.665025] sdhci_finish_data: unmapping ffff88030bfe7bc0 phys=0x00000000ffffe310 size=1
[  474.665136] sdhci_pre_dma_transfer: mapped ffff88030bfe7bd0 0x00000000ffffd310 (wanted=1, got=1), next=          (null), hcook=0, ncook=1
[  474.666746] sdhci_finish_data: unmapping ffff88030bfe7bd0 phys=0x00000000ffffd310 size=1
[  474.666912] sdhci_pre_dma_transfer: mapped ffff88030bfe7be0 0x00000000ffffc310 (wanted=1, got=1), next=          (null), hcook=0, ncook=1
[  474.669979] sdhci_finish_data: unmapping ffff88030bfe7be0 phys=0x00000000ffffc310 size=1
[  474.670405] mmc0: new high speed SDHC card at address e624
[  474.671107] mmcblk0: mmc0:e624 SU16G 14.8 GiB 
[  474.672309] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffb000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=1
[  474.682178] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffb000 size=1
[  474.682234]  mmcblk0: p1
[  474.684064] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffff000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=2
[  474.684825] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffff000 size=1
[  474.684954] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffe000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=3
[  474.685494] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffe000 size=1
[  474.685660] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=4
[  474.686316] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffd000 size=1
[  474.686449] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=5
[  474.686878] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffc000 size=1
[  474.687046] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffa000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=6
[  474.687590] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffa000 size=1
[  474.687720] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff9000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=7
[  474.688203] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff9000 size=1
[  474.688342] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff8000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=8
[  474.688865] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff8000 size=1
[  474.688988] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff7000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=9
[  474.689618] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff7000 size=1
[  474.689748] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff6000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=10
[  474.690393] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff6000 size=1
[  474.690549] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff5000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=11
[  474.691165] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff5000 size=1
[  474.691289] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff4000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=12
[  474.691927] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff4000 size=1
[  474.692066] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff3000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=13
[  474.692690] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff3000 size=1
[  474.692826] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff2000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=14
[  474.693450] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff2000 size=1
[  474.693548] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff1000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=15
[  474.694151] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff1000 size=1
[  474.694304] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffff000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=16
[  474.694915] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffff000 size=1
[  474.695047] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffe000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=17
[  474.695692] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffe000 size=1
[  474.695843] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=18
[  474.696270] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffd000 size=1
[  474.696406] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=19
[  474.696836] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffc000 size=1
[  474.696995] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffb000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=20
[  474.697420] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffb000 size=1
[  474.697543] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffa000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=21
[  474.697967] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffa000 size=1
[  474.698173] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff9000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=22
[  474.698606] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff9000 size=1
[  474.698851] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffe0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=23
[  474.698875] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffd0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=24
[  474.698879] sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25
[  474.698891] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffc0000 (wanted=1, got=1), next=          (null), hcook=0, ncook=25
[  474.700577] sdhci_finish_data: unmapping ffff880306c52e10 phys=0x00000000fffc0000 size=1
[  474.700694] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffb0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=25
[  474.702431] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffd0000 size=1
[  474.702486] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffa8000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=26
[  474.704192] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffb0000 size=1
[  474.704247] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffa4000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=27
[  474.705157] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffa8000 size=1
[  474.705217] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffa3000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=28
[  474.705756] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffa4000 size=1
[  474.706161] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffa3000 size=1
[  474.706339] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffff000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=29
[  474.706869] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffff000 size=1
[  474.707025] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffe000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=30
[  474.707543] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffe000 size=1
[  474.707676] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=31
[  474.708196] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffd000 size=1
[  474.708338] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=32
[  474.708801] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffc000 size=1
[  474.708916] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffb000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=33
[  474.709359] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffb000 size=1
[  474.709513] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffa000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=34
[  474.710003] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffa000 size=1
[  474.710378] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff9000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=35
[  474.710879] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff9000 size=1
[  474.710985] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff8000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=36
[  474.711449] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff8000 size=1
[  474.711572] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff7000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=37
[  474.712051] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff7000 size=1
[  474.712139] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff6000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=38
[  474.712617] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff6000 size=1
[  474.712704] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff5000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=39
[  474.713151] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff5000 size=1
[  474.713221] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff4000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=40
[  474.713666] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff4000 size=1
[  474.713732] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff3000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=41
[  474.714177] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff3000 size=1
[  474.714248] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff2000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=42
[  474.714704] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff2000 size=1
[  474.714832] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff1000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=43
[  474.715296] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff1000 size=1
[  474.715416] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=44
[  474.715867] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff0000 size=1
[  474.715991] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffdf000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=45
[  474.716437] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffdf000 size=1
[  474.716538] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffde000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=46
[  474.716983] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffde000 size=1
[  474.717093] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffdd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=47
[  474.717556] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffdd000 size=1
[  474.717667] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffdc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=48
[  474.718121] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffdc000 size=1
[  474.718278] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffff000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=49
[  474.718722] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffff000 size=1
[  474.718787] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffe000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=50
[  474.719229] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffe000 size=1
[  474.719293] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=51
[  474.719734] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffd000 size=1
[  474.719797] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=52
[  474.720239] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffc000 size=1
[  474.720301] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffb000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=53
[  474.720741] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffb000 size=1
[  474.720804] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffa000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=54
[  474.721245] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffa000 size=1
[  474.721311] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff9000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=55
[  474.721754] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff9000 size=1
[  474.721816] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff8000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=56
[  474.722261] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff8000 size=1
[  474.722465] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff7000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=57
[  474.722925] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff7000 size=1
[  474.723047] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff6000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=58
[  474.723511] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff6000 size=1
[  474.723621] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff5000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=59
[  474.724067] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff5000 size=1
[  474.724140] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff4000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=60
[  474.724583] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff4000 size=1
[  474.724696] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff3000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=61
[  474.725144] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff3000 size=1
[  474.725223] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff2000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=62
[  474.725680] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff2000 size=1
[  474.736023] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffff000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=63
[  474.736711] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffff000 size=1
[  474.736853] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffe000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=64
[  474.737405] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffe000 size=1
[  474.737502] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=65
[  474.738523] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffd000 size=1
[  474.738653] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=66
[  474.739355] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffc000 size=1
[  474.739498] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffb000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=67
[  474.740055] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffb000 size=1
[  474.740169] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffffa000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=68
[  474.740679] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffffa000 size=1
[  474.740817] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff9000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=69
[  474.747111] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff9000 size=1
[  474.747361] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=70
[  474.761987] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff0000 size=1
[  474.762816] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffd0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=71
[  474.767029] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffd0000 size=1
[  474.767181] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffcf000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=72
[  474.767645] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffcf000 size=1
[  474.767777] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffce000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=73
[  474.768244] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffce000 size=1
[  474.768408] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffcd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=74
[  474.768857] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffcd000 size=1
[  474.769387] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffb0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=75
[  474.769444] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffa0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=76
[  474.769449] sdhci[sdhci_pre_dma_transfer] invalid cookie: 76, next-cookie 77
[  474.769464] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fff90000 (wanted=1, got=1), next=          (null), hcook=0, ncook=77
[  474.771224] sdhci_finish_data: unmapping ffff880306dda438 phys=0x00000000fff90000 size=1
[  474.771421] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000ffff0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=77
[  474.773219] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffa0000 size=1
[  474.773315] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffd8000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=78
[  474.775004] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000ffff0000 size=1
[  474.775094] sdhci_pre_dma_transfer: mapped ffff880306dda438 0x00000000fffd4000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=79
[  474.775962] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffd8000 size=1
[  474.776020] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffd3000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=80
[  474.776568] sdhci_post_req: unmapping ffff880306dda438 phys=0x00000000fffd4000 size=1
[  474.776976] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffd3000 size=1
[  474.777183] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffd2000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=81
[  474.777759] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffd2000 size=1
[  474.777883] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffd1000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=82
[  474.778469] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffd1000 size=1
[  474.778637] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffd0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=83
[  474.779233] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffd0000 size=1
[  474.779402] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffcf000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=84
[  474.780032] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffcf000 size=1
[  474.780217] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffce000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=85
[  474.780802] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffce000 size=1
[  474.780944] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffcd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=86
[  474.781493] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffcd000 size=1
[  474.781632] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffcc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=87
[  474.782201] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffcc000 size=1
[  474.782356] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffff000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=88
[  474.782963] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffff000 size=1
[  474.783094] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffe000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=89
[  474.783695] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffe000 size=1
[  474.783800] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=90
[  474.784402] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffd000 size=1
[  474.784518] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=91
[  474.785057] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffc000 size=1
[  474.785160] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffb000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=92
[  474.785716] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffb000 size=1
[  474.785840] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffa000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=93
[  474.786418] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffa000 size=1
[  474.786551] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff9000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=94
[  474.787125] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff9000 size=1
[  474.787249] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff8000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=95
[  474.787805] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff8000 size=1
[  474.787907] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff7000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=96
[  474.788452] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff7000 size=1
[  474.788564] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff6000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=97
[  474.789333] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff6000 size=1
[  474.789426] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff5000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=98
[  474.789947] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff5000 size=1
[  474.790061] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff4000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=99
[  474.790604] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff4000 size=1
[  474.790727] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff3000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=100
[  474.791263] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff3000 size=1
[  474.791389] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff2000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=101
[  474.791922] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff2000 size=1
[  474.792040] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff1000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=102
[  474.792556] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff1000 size=1
[  474.792711] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff0000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=103
[  474.793231] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff0000 size=1
[  474.793326] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffdf000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=104
[  474.793848] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffdf000 size=1
[  474.793964] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffde000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=105
[  474.794502] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffde000 size=1
[  474.794626] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000fffff000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=106
[  474.795162] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000fffff000 size=1
[  474.795285] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffe000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=107
[  474.795824] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffe000 size=1
[  474.795941] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffd000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=108
[  474.796456] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffd000 size=1
[  474.796559] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffc000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=109
[  474.797076] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffc000 size=1
[  474.797180] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffb000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=110
[  474.797962] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffb000 size=1
[  474.798080] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffffa000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=111
[  474.798671] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffffa000 size=1
[  474.798796] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff9000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=112
[  474.799354] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff9000 size=1
[  474.799482] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff8000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=113
[  474.799943] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff8000 size=1
[  474.800063] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff7000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=114
[  474.800527] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff7000 size=1
[  474.800856] sdhci_pre_dma_transfer: mapped ffff880306c52e10 0x00000000ffff6000 (wanted=1, got=1), next=ffff88030bf21aa4, hcook=0, ncook=115
[  474.801523] sdhci_post_req: unmapping ffff880306c52e10 phys=0x00000000ffff6000 size=1
[  537.183193] mmc0: card e624 removed
[  539.324181] ------------[ cut here ]------------
[  539.324189] WARNING: CPU: 2 PID: 1193 at lib/dma-debug.c:974 dma_debug_device_change+0x158/0x1c0()
[  539.324192] pci 0000:02:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=2]
               One of leaked entries details: [device address=0x00000000fffe0000] [size=65536 bytes] [mapped with DMA_FROM_DEVICE] [mapped as scather-gather]
[  539.324194] Modules linked in:
[  539.324198] CPU: 2 PID: 1193 Comm: bash Not tainted 4.2.0-rc4+ #20
[  539.324199] Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
[  539.324201]  ffffffff81cc5faa ffff8800d6bfbb68 ffffffff81820998 0000000000000000
[  539.324204]  ffff8800d6bfbbb8 ffff8800d6bfbba8 ffffffff810b827a 0000000100260024
[  539.324206]  ffff88030e500000 0000000000000002 ffff88030df3f0c0 ffff88030e4ddd68
[  539.324209] Call Trace:
[  539.324213]  [<ffffffff81820998>] dump_stack+0x4c/0x6e
[  539.324217]  [<ffffffff810b827a>] warn_slowpath_common+0x8a/0xc0
[  539.324219]  [<ffffffff810b82f6>] warn_slowpath_fmt+0x46/0x50
[  539.324222]  [<ffffffff813248c8>] dma_debug_device_change+0x158/0x1c0
[  539.324226]  [<ffffffff810d4e9d>] notifier_call_chain+0x4d/0x80
[  539.324250]  [<ffffffff810d51fd>] __blocking_notifier_call_chain+0x4d/0x70
[  539.324253]  [<ffffffff810d5236>] blocking_notifier_call_chain+0x16/0x20
[  539.324256]  [<ffffffff814db395>] __device_release_driver+0x105/0x130
[  539.324258]  [<ffffffff814db3e3>] device_release_driver+0x23/0x30
[  539.324262]  [<ffffffff814d95ca>] unbind_store+0xba/0xe0
[  539.324266]  [<ffffffff8123c638>] ? kernfs_fop_write+0xe8/0x170
[  539.324269]  [<ffffffff814d8ac4>] drv_attr_store+0x24/0x30
[  539.324276]  [<ffffffff8123ce4a>] sysfs_kf_write+0x3a/0x50
[  539.324284]  [<ffffffff8123c670>] kernfs_fop_write+0x120/0x170
[  539.324290]  [<ffffffff811ce9e8>] __vfs_write+0x28/0xe0
[  539.324296]  [<ffffffff811d1209>] ? __sb_start_write+0x49/0xe0
[  539.324302]  [<ffffffff810e3ba5>] ? local_clock+0x25/0x30
[  539.324306]  [<ffffffff810e3d76>] ? get_vtime_delta+0x16/0x80
[  539.324311]  [<ffffffff811cf041>] vfs_write+0xa1/0x170
[  539.324316]  [<ffffffff810e43c4>] ? vtime_account_user+0x54/0x60
[  539.324319]  [<ffffffff811cfce6>] SyS_write+0x46/0xa0
[  539.324322]  [<ffffffff81180f83>] ? context_tracking_user_exit+0x13/0x20
[  539.324326]  [<ffffffff8182a117>] entry_SYSCALL_64_fastpath+0x12/0x6a
[  539.324329] ---[ end trace 08b1aea46b9d093b ]---
[  539.324330] Mapped at:
[  539.324332]  [<ffffffff81324492>] debug_dma_map_sg+0x122/0x140
[  539.324335]  [<ffffffff81616f60>] sdhci_pre_dma_transfer+0xe0/0x1f0
[  539.324338]  [<ffffffff816170b2>] sdhci_pre_req+0x42/0x70
[  539.324340]  [<ffffffff81601572>] mmc_pre_req+0x42/0x60
[  539.324345]  [<ffffffff816029ee>] mmc_start_req+0x3e/0x400

[-- Attachment #3: debug.patch --]
[-- Type: application/mbox, Size: 2473 bytes --]

[RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Jiri Slaby]

[-- Attachment #1: Type: text/plain, Size: 860 bytes --]

On 08/05/2015, 01:52 PM, Jiri Slaby wrote:
>> Yes, I see:
>> sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 65536 bytes)
>> after some time. The driver falls back to non-DMA transfers after that.
>> It also generates a warning about that:
>> WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857
>> sdhci_prepare_data+0x8ec/0x900 [sdhci]()
> 
> I am attaching a debug patch and a debug log. You can see where
> 0x00000000fffb0000 and 0x00000000fffe0000 is leaked. It is when 'invalid
> cookie' error happens.

And you could see the cookie handling is totally bogus.

With this rewrite, I no longer see the problems. Could you confirm it
still does the good job with respect to performance -- the numbers you
mentioned in your commit.

Ulf, what do you think about the attached patch? (Do not look at the
commented info prints.)

thanks,
-- 
js
suse labs

[-- Attachment #2: fix.patch --]
[-- Type: application/mbox, Size: 6244 bytes --]

Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Pavel Machek]

On Wed 2015-08-05 17:11:48, Jiri Slaby wrote:
> On 08/05/2015, 01:52 PM, Jiri Slaby wrote:
> >> Yes, I see:
> >> sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 65536 bytes)
> >> after some time. The driver falls back to non-DMA transfers after that.
> >> It also generates a warning about that:
> >> WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857
> >> sdhci_prepare_data+0x8ec/0x900 [sdhci]()
> > 
> > I am attaching a debug patch and a debug log. You can see where
> > 0x00000000fffb0000 and 0x00000000fffe0000 is leaked. It is when 'invalid
> > cookie' error happens.
> 
> And you could see the cookie handling is totally bogus.
> 
> With this rewrite, I no longer see the problems. Could you confirm it
> still does the good job with respect to performance -- the numbers you
> mentioned in your commit.
> 
> Ulf, what do you think about the attached patch? (Do not look at the
> commented info prints.)

Umm. Normally we inline patches for easier comments.

Attaching it with type of _mailbox_ is not really good.

									Pavel

[-- Attachment #2: fix.patch --]
[-- Type: application/mbox, Encoding: base64, Size: 8.2K --]





-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Chen Bough]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1788 bytes --]

Hi Js,

I read your attached log and patch, yes, dma memory leak will happen when
more than one pre_request execute. The method of ++next->cookie is not good,
your patch seems good, but I still need some time to test the patch, because
you unmap the dma in sdhci_finish_data rather than the sdhci_post_req.

Anyway, thanks for report and debug this issue. I will give you my test result
ASAP.  

Best Regards
Haibo Chen


> -----Original Message-----
> From: Jiri Slaby [mailto:jslaby@suse.cz]
> Sent: Wednesday, August 05, 2015 11:12 PM
> To: Chen Haibo-B51421; Ulf Hansson
> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA
> leaks]
> 
> On 08/05/2015, 01:52 PM, Jiri Slaby wrote:
> >> Yes, I see:
> >> sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 65536 bytes)
> >> after some time. The driver falls back to non-DMA transfers after that.
> >> It also generates a warning about that:
> >> WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857
> >> sdhci_prepare_data+0x8ec/0x900 [sdhci]()
> >
> > I am attaching a debug patch and a debug log. You can see where
> > 0x00000000fffb0000 and 0x00000000fffe0000 is leaked. It is when
> > 'invalid cookie' error happens.
> 
> And you could see the cookie handling is totally bogus.
> 
> With this rewrite, I no longer see the problems. Could you confirm it
> still does the good job with respect to performance -- the numbers you
> mentioned in your commit.
> 
> Ulf, what do you think about the attached patch? (Do not look at the
> commented info prints.)
> 
> thanks,
> --
> js
> suse labs
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Chen Bough]

Hi Js,

I read your attached log and patch, yes, dma memory leak will happen when
more than one pre_request execute. The method of ++next->cookie is not good,
your patch seems good, but I still need some time to test the patch, because
you unmap the dma in sdhci_finish_data rather than the sdhci_post_req.

Anyway, thanks for report and debug this issue. I will give you my test result
ASAP.  

Best Regards
Haibo Chen


> -----Original Message-----
> From: Jiri Slaby [mailto:jslaby@suse.cz]
> Sent: Wednesday, August 05, 2015 11:12 PM
> To: Chen Haibo-B51421; Ulf Hansson
> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA
> leaks]
> 
> On 08/05/2015, 01:52 PM, Jiri Slaby wrote:
> >> Yes, I see:
> >> sdhci-pci 0000:02:00.0: swiotlb buffer is full (sz: 65536 bytes)
> >> after some time. The driver falls back to non-DMA transfers after that.
> >> It also generates a warning about that:
> >> WARNING: CPU: 0 PID: 0 at drivers/mmc/host/sdhci.c:857
> >> sdhci_prepare_data+0x8ec/0x900 [sdhci]()
> >
> > I am attaching a debug patch and a debug log. You can see where
> > 0x00000000fffb0000 and 0x00000000fffe0000 is leaked. It is when
> > 'invalid cookie' error happens.
> 
> And you could see the cookie handling is totally bogus.
> 
> With this rewrite, I no longer see the problems. Could you confirm it
> still does the good job with respect to performance -- the numbers you
> mentioned in your commit.
> 
> Ulf, what do you think about the attached patch? (Do not look at the
> commented info prints.)
> 
> thanks,
> --
> js
> suse labs

Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Jiri Slaby]

On 08/06/2015, 09:42 AM, Chen Bough wrote:
> I read your attached log and patch, yes, dma memory leak will happen when
> more than one pre_request execute. The method of ++next->cookie is not good,
> your patch seems good, but I still need some time to test the patch, because
> you unmap the dma in sdhci_finish_data rather than the sdhci_post_req.

Hi,

yes, this is not correct. We can perhaps differentiate according to the
COOKIE value. Should I fix it or are you going to prepare a patch based
on my RFC?

thanks,
-- 
js
suse labs

RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Chen Bough]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1306 bytes --]

I will format a patch based on your diff file firstly. I will test this on my side,
If any issue, like dma issue or performance issue, I will add some modification.
Then I will send the patch for review, and you can test the patch on your platform.

Best Regards
Haibo Chen


> -----Original Message-----
> From: Jiri Slaby [mailto:jslaby@suse.cz]
> Sent: Thursday, August 06, 2015 5:07 PM
> To: Chen Haibo-B51421; Ulf Hansson
> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
> DMA leaks]
> 
> On 08/06/2015, 09:42 AM, Chen Bough wrote:
> > I read your attached log and patch, yes, dma memory leak will happen
> > when more than one pre_request execute. The method of ++next->cookie
> > is not good, your patch seems good, but I still need some time to test
> > the patch, because you unmap the dma in sdhci_finish_data rather than
> the sdhci_post_req.
> 
> Hi,
> 
> yes, this is not correct. We can perhaps differentiate according to the
> COOKIE value. Should I fix it or are you going to prepare a patch based
> on my RFC?
> 
> thanks,
> --
> js
> suse labs
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Chen Bough]

I will format a patch based on your diff file firstly. I will test this on my side,
If any issue, like dma issue or performance issue, I will add some modification.
Then I will send the patch for review, and you can test the patch on your platform.

Best Regards
Haibo Chen


> -----Original Message-----
> From: Jiri Slaby [mailto:jslaby@suse.cz]
> Sent: Thursday, August 06, 2015 5:07 PM
> To: Chen Haibo-B51421; Ulf Hansson
> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
> DMA leaks]
> 
> On 08/06/2015, 09:42 AM, Chen Bough wrote:
> > I read your attached log and patch, yes, dma memory leak will happen
> > when more than one pre_request execute. The method of ++next->cookie
> > is not good, your patch seems good, but I still need some time to test
> > the patch, because you unmap the dma in sdhci_finish_data rather than
> the sdhci_post_req.
> 
> Hi,
> 
> yes, this is not correct. We can perhaps differentiate according to the
> COOKIE value. Should I fix it or are you going to prepare a patch based
> on my RFC?
> 
> thanks,
> --
> js
> suse labs

Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Laura Abbott]

On 08/06/2015 02:17 AM, Chen Bough wrote:
> I will format a patch based on your diff file firstly. I will test this on my side,
> If any issue, like dma issue or performance issue, I will add some modification.
> Then I will send the patch for review, and you can test the patch on your platform.
>
> Best Regards
> Haibo Chen
>

Did I miss the follow up patch or is this still pending? If it's still pending,
would you mind Ccing me when it's available for testing?

Thanks,
Laura
  
>
>> -----Original Message-----
>> From: Jiri Slaby [mailto:jslaby@suse.cz]
>> Sent: Thursday, August 06, 2015 5:07 PM
>> To: Chen Haibo-B51421; Ulf Hansson
>> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
>> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
>> DMA leaks]
>>
>> On 08/06/2015, 09:42 AM, Chen Bough wrote:
>>> I read your attached log and patch, yes, dma memory leak will happen
>>> when more than one pre_request execute. The method of ++next->cookie
>>> is not good, your patch seems good, but I still need some time to test
>>> the patch, because you unmap the dma in sdhci_finish_data rather than
>> the sdhci_post_req.
>>
>> Hi,
>>
>> yes, this is not correct. We can perhaps differentiate according to the
>> COOKIE value. Should I fix it or are you going to prepare a patch based
>> on my RFC?
>>
>> thanks,
>> --
>> js
>> suse labs

RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Chen Bough]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2097 bytes --]

Hi Laura,

You can find the patch here:
http://patchwork.kernerl.xyz/patch/6967161/

I will send this patch again and cc to you.


Best regards

Haibo



> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com]
> Sent: Tuesday, August 25, 2015 12:27 AM
> To: Chen Haibo-B51421; Jiri Slaby; Ulf Hansson
> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
> DMA leaks]
> 
> On 08/06/2015 02:17 AM, Chen Bough wrote:
> > I will format a patch based on your diff file firstly. I will test
> > this on my side, If any issue, like dma issue or performance issue, I
> will add some modification.
> > Then I will send the patch for review, and you can test the patch on
> your platform.
> >
> > Best Regards
> > Haibo Chen
> >
> 
> Did I miss the follow up patch or is this still pending? If it's still
> pending, would you mind Ccing me when it's available for testing?
> 
> Thanks,
> Laura
> 
> >
> >> -----Original Message-----
> >> From: Jiri Slaby [mailto:jslaby@suse.cz]
> >> Sent: Thursday, August 06, 2015 5:07 PM
> >> To: Chen Haibo-B51421; Ulf Hansson
> >> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> >> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy
> >> (thousands) DMA leaks]
> >>
> >> On 08/06/2015, 09:42 AM, Chen Bough wrote:
> >>> I read your attached log and patch, yes, dma memory leak will happen
> >>> when more than one pre_request execute. The method of ++next->cookie
> >>> is not good, your patch seems good, but I still need some time to
> >>> test the patch, because you unmap the dma in sdhci_finish_data
> >>> rather than
> >> the sdhci_post_req.
> >>
> >> Hi,
> >>
> >> yes, this is not correct. We can perhaps differentiate according to
> >> the COOKIE value. Should I fix it or are you going to prepare a patch
> >> based on my RFC?
> >>
> >> thanks,
> >> --
> >> js
> >> suse labs

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]

[Chen Bough]

Hi Laura,

You can find the patch here:
http://patchwork.kernerl.xyz/patch/6967161/

I will send this patch again and cc to you.


Best regards

Haibo



> -----Original Message-----
> From: Laura Abbott [mailto:labbott@redhat.com]
> Sent: Tuesday, August 25, 2015 12:27 AM
> To: Chen Haibo-B51421; Jiri Slaby; Ulf Hansson
> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
> DMA leaks]
> 
> On 08/06/2015 02:17 AM, Chen Bough wrote:
> > I will format a patch based on your diff file firstly. I will test
> > this on my side, If any issue, like dma issue or performance issue, I
> will add some modification.
> > Then I will send the patch for review, and you can test the patch on
> your platform.
> >
> > Best Regards
> > Haibo Chen
> >
> 
> Did I miss the follow up patch or is this still pending? If it's still
> pending, would you mind Ccing me when it's available for testing?
> 
> Thanks,
> Laura
> 
> >
> >> -----Original Message-----
> >> From: Jiri Slaby [mailto:jslaby@suse.cz]
> >> Sent: Thursday, August 06, 2015 5:07 PM
> >> To: Chen Haibo-B51421; Ulf Hansson
> >> Cc: linux-mmc@vger.kernel.org; Linux kernel mailing list
> >> Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy
> >> (thousands) DMA leaks]
> >>
> >> On 08/06/2015, 09:42 AM, Chen Bough wrote:
> >>> I read your attached log and patch, yes, dma memory leak will happen
> >>> when more than one pre_request execute. The method of ++next->cookie
> >>> is not good, your patch seems good, but I still need some time to
> >>> test the patch, because you unmap the dma in sdhci_finish_data
> >>> rather than
> >> the sdhci_post_req.
> >>
> >> Hi,
> >>
> >> yes, this is not correct. We can perhaps differentiate according to
> >> the COOKIE value. Should I fix it or are you going to prepare a patch
> >> based on my RFC?
> >>
> >> thanks,
> >> --
> >> js
> >> suse labs