Hi Linus, On Wed, Feb 21, 2024 at 12:01 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Tue, Feb 20, 2024 at 10:03 PM Geert Uytterhoeven > <geert@xxxxxxxxxxxxxx> wrote: > > > sh_mobile_sdhi ee120000.mmc: mmc1 base at 0xee120000, max clock rate 12 MHz > > mmc2: new high speed MMC card at address 0001 > > sh_mobile_sdhi ee100000.mmc: mmc0 base at 0xee100000, max clock rate 88 MHz > > mmcblk2: mmc2:0001 MMC08G 7.33 GiB > > Hey it reads some blocks... > > > BUG: sleeping function called from invalid context at kernel/workqueue.c:3347 > > in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 35, name: irq/151-ee20000 > (...) > > __might_resched from __flush_work+0x20c/0x2e4 > > __flush_work from __cancel_work_timer+0x118/0x198 > > __cancel_work_timer from sh_mmcif_irqt+0x38/0x8f8 > > sh_mmcif_irqt from irq_thread_fn+0x1c/0x58 > > Actually that is the thread so the message is a bit confusing, the irq thread > isn't atomic. > > I wonder if it is caused by this: > > > > + sg_miter_start(&host->sg_miter, data->sg, data->sg_len, > > > + SG_MITER_ATOMIC | SG_MITER_TO_SG); > > ...because I don't need to ask for atomic miter here, since the poll > functions are actually called in process context. > > I've sent a patch, can you test? > https://lore.kernel.org/linux-mmc/20240220-fix-sh-mmcif-v1-1-b9d08a787c1f@xxxxxxxxxx/T/#u While that patch fixes the BUG, it does not make the eMMC work fully. It spews: sh_mmcif ee200000.mmc: Timeout waiting for 2 on CMD18 and no or limited data is read ("hd /dev/mmcblk..." blocks after no or two lines of output). I still need to revert 27b57277d9ba to restore proper operation. 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
