Re: sata_nv + ADMA + Samsung disk problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tejun Heo wrote:
[cc'ing Robert Hancock and NVidia people]

Whole thread can be read from the following URL.

  http://thread.gmane.org/gmane.linux.ide/21710

In a nutshell, with ADMA enabled, FLUSH_EXT occasionally times out.  I
first suspected faulty disk (reallocation failure on flush) but SMART
reports nothing suspicious and w/ ADMA disabled, the drive works just fine.

On a side note, on 2.6.22.1, SMART fails from time to time but the
problem went away on 2.6.24-rc6.  This was apparently fixed during that
period.  I guess we can ignore this for now.

Thanks.

This is kind of a longstanding problem which has been partially worked around, but it seems not entirely. This is what I had diagnosed some time ago:

"recently, some issues cropped up with command timeouts when a cache flush command was immediately followed by an NCQ write. In this case, sometimes when the NCQ write was issued, the status register changed from 0x500 (Stopped and Idle) to 0x400 (Stopped) as it normally appears to, however it seems like the controller would get hung in that state, and we would time out with no notifiers set, the gen_ctl register not indicating interrupt status, and the CPB response flags still 0 as we left them, seemingly indicating the controller hasn't done anything with it. Then, when the error handler kicks in we clear the GO bit to put it back into register mode, but the Legacy flag in the status register doesn't get set (or at least it takes longer than 1 microsecond). Finally when we do an ADMA channel reset that seems to get it responding again, until this happens the next time.

From some experimentation, I found that when we are issuing a NCQ
command when the last command was non-NCQ, or vice versa, if I added in
a delay of 20 microseconds between setting up the CPB and writing to the
append register, the problem appeared to go away. Problem is I don't
know if that's because it actually needs this delay, or because it
changes the timing so that it happens to work even though we're doing
something wrong, there's some event we're not waiting for, etc.

I've now verified that no switches between ADMA and register mode occur near the time of these timeouts. Neither are we reading or writing any of the ATA shadow registers while we're in ADMA mode."

It seems likely that this is what is happening here (a switch from an NCQ command to a non-NCQ command, then the non-NCQ times out). It could be in some cases the 20 microsecond delay is not enough. But it seems bogus that we should need such an arbitrary delay in the first place.

The question I had for NVIDIA regarding this that I never got answered was, is there any reason why we would need a delay when switching between NCQ and non-NCQ commands on ADMA, and if not, is there any known cause that could cause the controller to get into this seemingly locked-up state?

--
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux