Re: Linux 5.18.x: sdhci issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 31, 2022 at 11:23 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Tue, May 31, 2022 at 10:28 AM Yegor Yefremov
> <yegorslists@xxxxxxxxxxxxxx> wrote:
> > On Thu, May 5, 2022 at 7:03 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> > >
> > > Hi,
> > >
> > > * Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx> [220504 09:12]:
> > > > Hi Tony, all,
> > > >
> > > > During the kernel boot I see the following error. The device is still
> > > > working afterwards. 5.17.5 shows the same behavior. Is this a known
> > > > issue?
> > >
> > > Thanks for reporting it, I was not aware of this one. Might be worth
> > > bisecting. Adding linux-mmc and Ulf.
> >
> > After enabling the CONFIG_DMA_API_DEBUG option, I also get the following error:
>
> > [    7.603288]  dma_map_sg_attrs from sdhci_pre_dma_transfer+0xcc/0x134
> > [    7.609705]  sdhci_pre_dma_transfer from mmc_blk_mq_issue_rq+0x2f4/0xa58
> > [    7.616462]  mmc_blk_mq_issue_rq from mmc_mq_queue_rq+0x124/0x258
> > [    7.622604]  mmc_mq_queue_rq from blk_mq_dispatch_rq_list+0x1b8/0x8ac
> > [    7.629104]  blk_mq_dispatch_rq_list from
> > blk_mq_do_dispatch_sched+0x2ec/0x350
> > [    7.636387]  blk_mq_do_dispatch_sched from
> > __blk_mq_sched_dispatch_requests+0x118/0x170
> > [    7.644448]  __blk_mq_sched_dispatch_requests from
> > blk_mq_sched_dispatch_requests+0x34/0x5c
> > [    7.652859]  blk_mq_sched_dispatch_requests from
> > __blk_mq_run_hw_queue+0xf8/0x230
> > [    7.660402]  __blk_mq_run_hw_queue from process_one_work+0x284/0x72c
>
> This is the blk_mq code taking things off the queue, so we don't really
> know how they got put on there at this point. To find that, we'd need to
> annotate the mmc code with the same kind of check to test the buffer
> address whenever something gets submitted on the blk_mq queue.
>
> Looking at the calls to sg_init*(), I found sdio_io_rw_ext_helper(), which
> is what all sdio commands pass through. We could annotate that using
>
> diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> index 79dbf90216b5..4ab063c50649 100644
> --- a/drivers/mmc/core/sdio_io.c
> +++ b/drivers/mmc/core/sdio_io.c
> @@ -322,6 +322,11 @@ static int sdio_io_rw_ext_helper(struct sdio_func
> *func, int write,
>         if (!func || (func->num > 7))
>                 return -EINVAL;
>
> +       WARN_ON_ONCE(memory_intersects(_stext, _etext, buf, size));
> +       WARN_ON_ONCE(memory_intersects(__start_rodata, __end_rodata,
> buf, size));
> +       WARN_ON_ONCE(object_is_on_stack(buf));
> +       WARN_ON_ONCE(is_vmalloc_or_module_addr(buf));
> +
>         /* Do the bulk of the transfer using block mode (if supported). */
>         if (func->card->cccr.multi_block && (size > sdio_max_byte_size(func))) {
>                 /* Blocks per command is limited by host count, host transfer
>
>  Does that show something new?
>
> If this is a block device, the change won't help, but I can't find a good place
> to hook into that at the moment. mmc_mq_queue_rq() might work, but
> I think that is still called asynchronously.

No, the patch provides the same output.

Yegor



[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux