All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Jens Axboe <axboe@suse.de>
Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>,
	"Prakash K. Cheemplavam" <prakashkc@gmx.de>,
	marcush@onlinehome.de, linux-kernel@vger.kernel.org,
	eric_mudama@Maxtor.com
Subject: Re: Silicon Image 3112A SATA trouble
Date: Sun, 30 Nov 2003 11:41:55 -0500	[thread overview]
Message-ID: <3FCA1DD3.70004@pobox.com> (raw)
In-Reply-To: <20031130162523.GV10679@suse.de>

Jens Axboe wrote:
> On Sun, Nov 30 2003, Bartlomiej Zolnierkiewicz wrote:
>>Hmm. actually I was under influence that we have generic ioctls in 2.6.x,
>>but I can find only BLKSECTGET, BLKSECTSET was somehow lost.  Jens?
> 
> 
> Probably because it's very dangerous to expose, echo something too big
> and watch your data disappear.


IMO, agreed.

Max KB per request really should be set by the driver, as it's a 
hardware-specific thing that (as we see :)) is often errata-dependent.

Tangent:  My non-pessimistic fix will involve submitting a single sector 
DMA r/w taskfile manually, then proceeding with the remaining sectors in 
another r/w taskfile.  This doubles the interrupts on the affected 
chipset/drive combos, but still allows large requests.  I'm not terribly 
fond of partial completions, as I feel they add complexity, particularly 
so in my case:  I can simply use the same error paths for both the 
single-sector taskfile and the "everything else" taskfile, regardless of 
which taskfile throws the error.

(thinking out loud)  Though best for simplicity, I am curious if a 
succession of "tiny/huge" transaction pairs are efficient?  I am hoping 
that the drive's cache, coupled with the fact that each pair of 
taskfiles is sequentially contiguous, will not hurt speed too much over 
a non-errata configuration...

	Jeff




  reply	other threads:[~2003-11-30 16:42 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-25 13:59 Silicon Image 3112A SATA trouble Prakash K. Cheemplavam
2003-11-29 15:39 ` Prakash K. Cheemplavam
2003-11-29 16:38   ` Julien Oster
2003-11-29 16:54     ` Jeff Garzik
2003-11-29 17:07     ` Craig Bradney
2003-11-30  1:51       ` Prakash K. Cheemplavam
2003-11-29 16:56   ` Jeff Garzik
2003-11-29 17:41     ` Miquel van Smoorenburg
2003-11-29 18:39       ` Jeff Garzik
2003-11-29 20:24     ` Marcus Hartig
2003-11-30  2:00     ` Prakash K. Cheemplavam
2003-11-30 14:47       ` Bartlomiej Zolnierkiewicz
2003-11-30 15:52         ` Prakash K. Cheemplavam
2003-11-30 16:21           ` Bartlomiej Zolnierkiewicz
2003-11-30 16:25             ` Jens Axboe
2003-11-30 16:41               ` Jeff Garzik [this message]
2003-11-30 16:51                 ` Jens Axboe
2003-11-30 16:58                   ` Bartlomiej Zolnierkiewicz
2003-11-30 17:06                     ` Jeff Garzik
2003-11-30 17:10                       ` Jens Axboe
2003-11-30 17:22                         ` Jeff Garzik
2003-11-30 17:31                           ` Jens Axboe
2003-11-30 17:48                             ` Jeff Garzik
2003-11-30 17:56                         ` Vojtech Pavlik
2003-11-30 18:17                           ` Jens Axboe
2003-11-30 18:19                             ` Jeff Garzik
2003-11-30 18:22                               ` Jens Axboe
2003-11-30 18:31                                 ` Jeff Garzik
2003-11-30 19:44                                   ` Vojtech Pavlik
2003-11-30 21:05                                   ` Yaroslav Klyukin
2003-11-30 17:08                     ` Jens Axboe
2003-11-30 17:13                       ` Bartlomiej Zolnierkiewicz
2003-11-30 17:13                         ` Jens Axboe
2003-11-30 17:18                   ` Jeff Garzik
2003-11-30 17:28                     ` Jens Axboe
2003-11-30 17:41                       ` Jeff Garzik
2003-11-30 17:45                         ` Jens Axboe
2003-11-30 17:57                           ` Jeff Garzik
2003-11-30 18:21                             ` Jens Axboe
2003-11-30 19:04                               ` Jeff Garzik
2003-11-30 19:39                                 ` Jens Axboe
2003-11-30 20:35                                   ` Jeff Garzik
2003-12-01  9:02                                     ` Jens Axboe
2003-11-30 17:19             ` Prakash K. Cheemplavam
2003-11-30 18:07               ` Bartlomiej Zolnierkiewicz
2003-11-30 21:34                 ` Prakash K. Cheemplavam
2003-11-30 16:27         ` Jeff Garzik
2003-11-30 16:34           ` Bartlomiej Zolnierkiewicz
     [not found] <Pine.LNX.4.44.0311291453550.838-100000@coffee.psychology.mcmaster.ca>
2003-11-30 16:45 ` Jeff Garzik
  -- strict thread matches above, loose matches on Subject: below --
2003-11-30 17:52 Luis Miguel García
2003-11-30 17:13 ` Craig Bradney
2003-11-30 18:27   ` Jeff Garzik
2003-11-30 18:41 Luis Miguel García
2003-11-30 21:15 ` Craig Bradney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FCA1DD3.70004@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=B.Zolnierkiewicz@elka.pw.edu.pl \
    --cc=axboe@suse.de \
    --cc=eric_mudama@Maxtor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcush@onlinehome.de \
    --cc=prakashkc@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.