CC LinusW, Ulf, linux-mmc
On Mon, Oct 16, 2017 at 10:36 AM, Yoshihiro Shimoda
<yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote:
>> From: Dirk Behme, Sent: Thursday, October 12, 2017 6:13 PM
>> On 12.10.2017 10:20, Dirk Behme wrote:
>> > On 11.10.2017 15:20, Geert Uytterhoeven wrote:
>> >> On Wed, Oct 11, 2017 at 2:57 PM, Dirk Behme <dirk.behme@xxxxxxxxxxxx>
>> >> wrote:
>> >>> On 11.10.2017 14:42, Geert Uytterhoeven wrote:
>> >>>> On Wed, Oct 11, 2017 at 2:23 PM, Dirk Behme <dirk.behme@xxxxxxxxxxxx>
>> >>>> wrote:
>> >>>>> trying to boot recent mainline v4.14-rc4 on a custom H3 ES2.0 board
>> >>>>> with
>> >>>>> rootfs on SD card I'm getting [1].
>> >>>>>
>> >>>>> Last time I think I used v4.13 in the same environment and I think it
>> >>>>> worked
>> >>>>> fine, most probably because renesas_sdhi_internal_dmac wasn't
>> >>>>> there, yet
>> >>>>> ;)
>> >>>>>
>> >>>>> I checked renesas-drivers-2017-10-03-v4.14-rc3 if there is anything
>> >>>>> newer
>> >>>>> regarding drivers/mmc/host/renesas_sdhi_internal_dmac.c but doesn't
>> >>>>> look
>> >>>>> so.
>> >>>>>
>> >>>>> Any idea what I missed?
>> >>>>>
>> >>>> How much swiotlb memory do you have? The default is 64 MiB:
>> >>>>
>> >>>> software IO TLB [mem 0x77fff000-0x7bfff000] (64MB) mapped at
>> >>>> [ffffffc037fff000-ffffffc03bffefff]
>> >>>
>> >>> Same here:
>> >>
>> >> OK.
>> >>
>> >>>> Then, who else is consuming lots of swiotlb memory?
>> >>
>> >> Or, not freeing allocated memory.
>> >>
>> >>> Hmm, any idea how to find that?
>> >>>
>> >>> The dmesg doesn't seem to have more infos about that (?)
>> >>
>> >> I'm afraid you have to add some prints to swiotlb_tbl_map_single()
>> >> (and swiotlb_tbl_unmap_single())...
>> >
>> >
>> > With [1] I'm getting [2]. What doesn't look that bad, at least quite
>> > symmetric. Having a quick look I can't find any obvious not freed mem.
>> > Hmm ...
>>
>>
>> Ok, it seems to be somehow easy ;) It seems that the 524288 bytes them
>> self are the issue, independent on the usage of the swiotlb memory.
>>
>> Doing a hack like [3], i.e. trying to map 524288 bytes at the first
>> access, already, crashes, too [4].
>>
>> So seems we have two issues?
>>
>> a) swiotlb_tbl_map_single() can't handle 524288 bytes
>>
>> and
>>
>> b) failing swiotlb_tbl_map_single() results in a kernel crash
>>
>>
>> Now, I'm not sure whom to address both to? Is it an issue of
>> renesas_sdhi_internal_dmac() which shouldn't call swiotlb with 524288
>> bytes? Or is this an error of swiotlb? Same for the kernel crash.
>
> Our team also reproduced this issue if we did the following command on H3.
> # dd if=/dev/mmcblk0 of=/dev/null bs=512k count=200
>
> I investigate the issue and then if I modified the value of IO_TLB_SEGSIZE to 256,
> the issue disappeared. However, other issue happens if I dropped "count=200"...
> So, I will investigate the issues more...
>
> IIUC,
> - Since the MMC_BOUNCE disappeared in v4.14-rc1, the MMC core will request a command with 64kbyte+ size.
> - So, swiotlb will got request 64kbyte+ size. This is different with previous version.
>
> Best regards,
> Yoshihiro Shimoda
>
>>
>> Best regards
>>
>> Dirk
>>
>> [3]
>>
>> --- a/lib/swiotlb.c
>> +++ b/lib/swiotlb.c
>> @@ -510,6 +510,10 @@ phys_addr_t swiotlb_tbl_map_single(struct device
>> *hwdev,
>> if (sme_active())
>> pr_warn_once("SME is active and system is using DMA
>> bounce buffers\n");
>>
>> + dev_warn(hwdev, "swiotlb_tbl_map_single: trying to map %zd
>> bytes\n", size);
>> + size = (size_t)524288;
>> + dev_warn(hwdev, "swiotlb_tbl_map_single: test: size modified to
>> %zd bytes\n", size);
>> +
>> mask = dma_get_seg_boundary(hwdev);
>>
>> tbl_dma_addr &= mask;
>>
>> [4]
>>
>> renesas_sdhi_internal_dmac ee100000.sd: swiotlb_tbl_map_single: trying
>> to map 8 bytes
>> renesas_sdhi_internal_dmac ee100000.sd: swiotlb_tbl_map_single: test:
>> size modified to 524288 bytes
>> renesas_sdhi_internal_dmac ee100000.sd: swiotlb buffer is full (sz:
>> 524288 bytes)
>> renesas_sdhi_internal_dmac ee100000.sd: DMA: Out of SW-IOMMU space for 8
>> bytes
>> Unable to handle kernel paging request at virtual address ffffffffc0000000
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
