> + Ricky > > On Fri, 21 Feb 2025 at 18:20, Bart Van Assche <bvanassche@xxxxxxx> wrote: > > > > > > On 2/21/25 7:41 AM, Thomas Haschka wrote: > > > Bug Fix: block: Improve stability of SD cards in Microsoft Surface GO 2 and > > > possibly other devices. > > > > > > > > > The commit 65a558f66c308 > > > block: Improve performance for BLK_MQ_F_BLOCKING drivers > > > > > > basically made the use of SD cards in my Microsoft Surface GO 2 > impossible. > > > The cards do stop functioning after about 15 minutes. Mostly at io > > > intensive tasks. > > > > > > As outlined in https://bugzilla.kernel.org/show_bug.cgi?id=218821 > > > i bisected the problem that yielded an unstable operation of the > > > cardreader on my Surface GO 2. > > > I successfully reversed the commit 65a558f66c308 in 6.12.16 using > > > the attached patch. As I suppose the bug introduced with this commit > > > might hit other users of sd-cards in similar hardware I suggest this > > > commit shall be reversed, even if the improved performance might be > gone. > > > > Thank you for having bisected this issue and for having shared the > > result of the bisection process. This is very useful information. > > > > Since the commit mentioned above is about 1.5 years old and has not > > caused any issues for anyone who is not using an SD card reader, that > > commit is probably not the root cause of the reported behavior. Are SD > > cards controlled by the MMC driver? If so, I think the next step is to > > take a close look at the MMC driver. I have Cc-ed the MMC driver > maintainer. > > There was another thread [1] where I tried to loop in Ricky Wu, but there was > no response. I have added him to this tread too. > Hi Ulf, Because I was waiting for the result that revert 101bd907b424 ("misc: rtsx: judge ASPM Mode to set PETXCFG Reg") Can fix this issue or not, but I did not see any response... Hi Thomas, This issue(this mail thread) and [1] are the same issue? And this issue only can reproduce on surface go 2? If so, I need to find correct platform to reproduce this issue on my hand > For the record, I agree, even if reverting 65a558f66c308 solves the issue, it's > not the correct fix. > > Unless we can get some help from Ricky, we can try to drop assigning > "MMC_CAP_AGGRESSIVE_PM" in realtek_init_host() to see if that solves the > problem. Or if debugfs is enabled, we can disable > MMC_CAP_AGGRESSIVE_PM for the mmc host via the "caps" debugfs-node. > > Thomas can you try to drop MMC_CAP_AGGRESSIVE_PM and see if that solves > the problem? > > Kind regards > Uffe > > [1] > https://lore.kernel.org/all/CAPDyKFq4-fL3oHeT9phThWQJqzicKeA447WBJUbtc > KPhdZ2d1A@xxxxxxxxxxxxxx/
