RE: mmc0: error -95 doing runtime resume

[Thomas Haschka <thomas.haschka@tuwien.ac.at>]

Hello Ricky,

yes [1] and this issue are the same. As I only have a Surface GO 2
at hand I can not speak for other effected systems, though I guess it is
reasonable that others are effected.
It probably works for some use cases, as it only fails if I read a
lot of files, like opening emacs or firefox ( from the SD Card ). Which then
causes symptoms as outlined
here: https://bugzilla.kernel.org/show_bug.cgi?id=218821

Hello Uffe,
I will try to see what I can do with MMC_CAP_AGGRESSIVE_PM.

All the best,
- Thomas


On Thu, 27 Feb 2025, Ricky WU wrote:

>> + Ricky
>>
>> On Fri, 21 Feb 2025 at 18:20, Bart Van Assche <bvanassche@acm.org> 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@mail.gmail.com/
>