Stack trace in WARN_UNLESS #137
Assignees
Comments
thehajime
pushed a commit
to thehajime/linux
that referenced
this issue
Aug 5, 2022
On Thundercomm TurboX CM2290, the eMMC OCR reports vdd = 23 (3.5 ~ 3.6 V), which is being treated as an invalid value by sdhci_set_power_noreg(). And thus eMMC is totally broken on the platform. [ 1.436599] ------------[ cut here ]------------ [ 1.436606] mmc0: Invalid vdd 0x17 [ 1.436640] WARNING: CPU: 2 PID: 69 at drivers/mmc/host/sdhci.c:2048 sdhci_set_power_noreg+0x168/0x2b4 [ 1.436655] Modules linked in: [ 1.436662] CPU: 2 PID: 69 Comm: kworker/u8:1 Tainted: G W 5.15.0-rc1+ lkl#137 [ 1.436669] Hardware name: Thundercomm TurboX CM2290 (DT) [ 1.436674] Workqueue: events_unbound async_run_entry_fn [ 1.436685] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.436692] pc : sdhci_set_power_noreg+0x168/0x2b4 [ 1.436698] lr : sdhci_set_power_noreg+0x168/0x2b4 [ 1.436703] sp : ffff800010803a60 [ 1.436705] x29: ffff800010803a60 x28: ffff6a9102465f00 x27: ffff6a9101720a70 [ 1.436715] x26: ffff6a91014de1c0 x25: ffff6a91014de010 x24: ffff6a91016af280 [ 1.436724] x23: ffffaf7b1b276640 x22: 0000000000000000 x21: ffff6a9101720000 [ 1.436733] x20: ffff6a9101720370 x19: ffff6a9101720580 x18: 0000000000000020 [ 1.436743] x17: 0000000000000000 x16: 0000000000000004 x15: ffffffffffffffff [ 1.436751] x14: 0000000000000000 x13: 00000000fffffffd x12: ffffaf7b1b84b0bc [ 1.436760] x11: ffffaf7b1b720d10 x10: 000000000000000a x9 : ffff800010803a60 [ 1.436769] x8 : 000000000000000a x7 : 000000000000000f x6 : 00000000fffff159 [ 1.436778] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000ffffffff [ 1.436787] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff6a9101718d80 [ 1.436797] Call trace: [ 1.436800] sdhci_set_power_noreg+0x168/0x2b4 [ 1.436805] sdhci_set_ios+0xa0/0x7fc [ 1.436811] mmc_power_up.part.0+0xc4/0x164 [ 1.436818] mmc_start_host+0xa0/0xb0 [ 1.436824] mmc_add_host+0x60/0x90 [ 1.436830] __sdhci_add_host+0x174/0x330 [ 1.436836] sdhci_msm_probe+0x7c0/0x920 [ 1.436842] platform_probe+0x68/0xe0 [ 1.436850] really_probe.part.0+0x9c/0x31c [ 1.436857] __driver_probe_device+0x98/0x144 [ 1.436863] driver_probe_device+0xc8/0x15c [ 1.436869] __device_attach_driver+0xb4/0x120 [ 1.436875] bus_for_each_drv+0x78/0xd0 [ 1.436881] __device_attach_async_helper+0xac/0xd0 [ 1.436888] async_run_entry_fn+0x34/0x110 [ 1.436895] process_one_work+0x1d0/0x354 [ 1.436903] worker_thread+0x13c/0x470 [ 1.436910] kthread+0x150/0x160 [ 1.436915] ret_from_fork+0x10/0x20 [ 1.436923] ---[ end trace fcfac44cb045c3a8 ]--- Fix the issue by mapping MMC_VDD_35_36 (and MMC_VDD_34_35) to SDHCI_POWER_330 as well. Signed-off-by: Shawn Guo <[email protected]> Acked-by: Adrian Hunter <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It would be nice if a stack trace can be printed in WARN_UNLESS so it's easier to identify the code path that's triggering that warning.
Can we reuse dump_stack in kernel code?
The text was updated successfully, but these errors were encountered: