On Thu, 4 Mar 2021 at 15:59, Marten Lindahl <marte...@axis.com> wrote: > > On Thu, Mar 04, 2021 at 03:06:54PM +0100, Ulf Hansson wrote: > > On Thu, 4 Mar 2021 at 14:48, Marten Lindahl <marte...@axis.com> wrote: > > > > > > Hi Ulf! My apologies for the delay. > > > > > > On Tue, Mar 02, 2021 at 09:45:02AM +0100, Ulf Hansson wrote: > > > > On Mon, 1 Mar 2021 at 22:59, Marten Lindahl <marte...@axis.com> wrote: > > > > > > > > > > Hi Ulf! > > > > > > > > > > Thank you for your comments! > > > > > > > > > > On Mon, Mar 01, 2021 at 09:50:56AM +0100, Ulf Hansson wrote: > > > > > > + Adrian > > > > > > > > > > > > On Tue, 16 Feb 2021 at 23:43, Mårten Lindahl > > > > > > <marten.lind...@axis.com> wrote: > > > > > > > > > > > > > > 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. > > > > > > > > > > > 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. > > > > > > > > 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
