linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* mod15write
@ 2005-12-03 19:05 Jeff Garzik
  2005-12-05 15:04 ` mod15write Tejun Heo
  0 siblings, 1 reply; 3+ messages in thread
From: Jeff Garzik @ 2005-12-03 19:05 UTC (permalink / raw)
  To: linux-ide@vger.kernel.org, Tejun Heo; +Cc: Carlos Pardo


IIRC, the specific mod15write problem is that we don't want the final 
Data FIS generated by the 3112 to end on a pure 8K or 7.5K boundary 
(Carlos, check me here...)

Thus, a potential solution might be to do full speed read commands, and 
split write commands into two commands:  one write with the majority of 
the transfer, and a second write with the remainder.

	Jeff




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mod15write
  2005-12-03 19:05 mod15write Jeff Garzik
@ 2005-12-05 15:04 ` Tejun Heo
  2005-12-05 18:24   ` mod15write Jeff Garzik
  0 siblings, 1 reply; 3+ messages in thread
From: Tejun Heo @ 2005-12-05 15:04 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: linux-ide@vger.kernel.org, Carlos Pardo

Jeff Garzik wrote:
> 
> IIRC, the specific mod15write problem is that we don't want the final 
> Data FIS generated by the 3112 to end on a pure 8K or 7.5K boundary 
> (Carlos, check me here...)
> 
> Thus, a potential solution might be to do full speed read commands, and 
> split write commands into two commands:  one write with the majority of 
> the transfer, and a second write with the remainder.
> 

Hello, Jeff and Carlos.

I did some tests with m15w workaround I'm maintaining.  It was quite 
easy to do what Jeff said instead of the original workaround (chopping 
off large write requests to writes <= 15 sectors).

3112: For some mysterious reason, I couldn't regenerate m15w problem on 
the controller.  Even without any patch, the drive works perfectly no 
matter what I do.  I used to be able to cause m15w lockup on this 
controller previously on the older testing machine.

3114: This locks up very easily.  We currently don't know whether 3114 
has m15w or not, but 3114 locks up without the workaround and with the 
modified workaround, but works fine with the original workaround.

So, if the lock ups of 3114 are actually m15w, splitting writes into two 
commands such that it doesn't end on a 8k or 7.5k boundary doesn't seem 
to work.  I'll retest 3112 on the older machine and report.

-- 
tejun

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: mod15write
  2005-12-05 15:04 ` mod15write Tejun Heo
@ 2005-12-05 18:24   ` Jeff Garzik
  0 siblings, 0 replies; 3+ messages in thread
From: Jeff Garzik @ 2005-12-05 18:24 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-ide@vger.kernel.org, Carlos Pardo

Tejun Heo wrote:
> So, if the lock ups of 3114 are actually m15w, splitting writes into two 
> commands such that it doesn't end on a 8k or 7.5k boundary doesn't seem 
> to work.  I'll retest 3112 on the older machine and report.

sata_sil has always had lock-up reports, so don't be too quick to blame 
mod15write.  It's likely there is some other problem.

I wonder if we could get this looked at in a SATA bus analyzer...  (I 
don't have one, alas)

	Jeff



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-12-05 18:24 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-03 19:05 mod15write Jeff Garzik
2005-12-05 15:04 ` mod15write Tejun Heo
2005-12-05 18:24   ` mod15write Jeff Garzik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).