On Thu, 4 Mar 2021 at 15:59, Marten Lindahl [off-list ref] wrote:

On Thu, Mar 04, 2021 at 03:06:54PM +0100, Ulf Hansson wrote:

quoted

On Thu, 4 Mar 2021 at 14:48, Marten Lindahl [off-list ref] wrote:

quoted

Hi Ulf! My apologies for the delay.

On Tue, Mar 02, 2021 at 09:45:02AM +0100, Ulf Hansson wrote:

quoted

On Mon, 1 Mar 2021 at 22:59, Marten Lindahl [off-list ref] wrote:

quoted

Hi Ulf!

Thank you for your comments!

On Mon, Mar 01, 2021 at 09:50:56AM +0100, Ulf Hansson wrote:

quoted

+ Adrian

On Tue, 16 Feb 2021 at 23:43, Mårten Lindahl [off-list ref] wrote:

quoted

Sometimes SD cards that has been run for a long time enters a state
where it cannot by itself be recovered, but needs a power cycle to be
operational again. Card status analysis has indicated that the card can
end up in a state where all external commands are ignored by the card
since it is halted by data timeouts.

If the card has been heavily used for a long time it can be weared out,
and should typically be replaced. But on some tests, it shows that the
card can still be functional after a power cycle, but as it requires an
operator to do it, the card can remain in a non-operational state for a
long time until the problem has been observed by the operator.

This patch adds function to power cycle the card in case it does not
respond to a command, and then resend the command if the power cycle
was successful. This procedure will be tested 1 time before giving up,
and resuming host operation as normal.

I assume the context above is all about the ioctl interface?

Yes, that's correct. The problem we have seen is triggered by ioctls.

quoted

So, when the card enters this non functional state, have you tried
just reading a block through the regular I/O interface. Does it
trigger a power cycle of the card - and then makes it functional
again?

Yes, we have tried that, and it does trigger a power cycle, making the card
operational again. But as it requires an operator to trigger it, I thought
it might be something that could be automated here. At least once.

Not sure what you mean by operator here? In the end it's a userspace
program running and I assume it can deal with error paths. :-)

In any case, I understand your point.

Yes, we have a userspace program. So if the userspace program will try to
restore the card in a situation such as the one we are trying to solve
here, how shall it perform it? Is it expected that a ioctl CMD0 request
should be enough, or is there any other support for a userspace program to
reset the card?

Correct, there is no way for userspace to reset cards through an ioctl.

quoted

If it falls on a ioctl command to reset the card, how do we handle the case
where the ioctl times out anyway? Or is the only way for a userspace program
to restore the card, to make a block transfer that fails?

Yes, that is what I was thinking. According to the use case you have
described, this should be possible for you to implement as a part of
your userspace program, no?

Ok, I will discuss that with the people maintaining the userspace program :)

But would it be of interest to review a patch introducing a more clean card
reset request, without block transfers?

Well, if you can solve it with block transfers that's the preferred
option, in my opinion.

As I stated earlier, my main issue with the HW reset through the ioctl
interface, is that we don't know what combination of
request/command/response we should be doing a reset for.

Kind regards
Uffe