From: Jens Axboe <axboe@suse.de>
To: Andre Hedrick <andre@linuxdiskcert.org>
Cc: Davide Libenzi <davidel@xmailserver.org>,
Anton Altaparmakov <aia21@cam.ac.uk>,
Linus Torvalds <torvalds@transmeta.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.5.3-pre1-aia1
Date: Mon, 21 Jan 2002 09:01:56 +0100 [thread overview]
Message-ID: <20020121090156.O27835@suse.de> (raw)
In-Reply-To: <20020121083653.N27835@suse.de> <Pine.LNX.4.10.10201202338470.13650-100000@master.linux-ide.org>
In-Reply-To: <Pine.LNX.4.10.10201202338470.13650-100000@master.linux-ide.org>
On Sun, Jan 20 2002, Andre Hedrick wrote:
> > No it's not. By your standards, that would mean that if the device is
> > setup for 16 sector multi mode, then I could never ever issue requests
> > less than that (without doing some crap 'toss away extra data' stuff).
> > How else would you handle, eg, 2 sector requests with multi mode set?
>
> Change the opcode in the command block to single sector, if
> rq->current_nr_sectors != drive->multcount.
That crossed my mind too, however that's not what we've been doing in
the past and multi mode has worked fine.
> > > The effective operations your changes have created without addressing all
> > > the variables is to terminate the command in process. Therefore, the
> > > decision made by you was to restrict the transfers to be process to the
> > > count in rq->current_nr_sectors. There is no bounds checking based on the
> > > command executed.
> >
> > I'm not stopping a request in progress. I told the drive that the
> > request is current_nr_sectors big, so once it finishes transferring
> > current_nr_sectors sectors it truly thinks it's really done with that
> > request. And it is. However, I'm leaving the request on the queue (or,
> > really, ide_end_request is not taking it off because
> > end_that_request_first is not indicating it's complete). So I'm simply
> > starting from scratch with the remaining data. See?
>
> I know what you are doing, and I am trying to mate the requirement to use
Yes
> the hardware to what you are sending down. The question you need to
> answer is issuing a request for multi-sector transfers less than what the
> device is expecting, sane and correct. If you tell me it is correct,
> please show me where I read something wrong in the specification.
You are saying that even when I do:
/* this is our request */
rq->nr_sectors = 48;
rq->current_nr_sectors = 8;
/* drive->mult_count has been programmed to 16 */
/* bla bla command setup */
OUT_BYTE(rq->current_nr_sectors, IDE_NSECTOR_REG);
ide_set_hander(...);
OUT_BYTE(WIN_MULTREAD, IDE_COMMAND_REG);
The drive will be wanting to transfer _16_ sectors, even though I told
it that I want _8_. This sounds very strange to me, and it means that
2.2/2.4 etc should have never worked in multi mode. I'll go find the
spec now... I am just talking out of my ass.
> > > *****************************
> > > The questions to ask "How would the host terminate a command in progress,
> > > since BSY=1 (or DRQ=1) at this point? Is that done via a DEVICE_RESET or
> > > SRST write?"
> >
> > [snip]
> >
> > Moot, there's no premature termination going on.
>
> >From the OS/HOST side you are 100% correct.
Yep
> >From the device side, do you know that for a fact?
No
> Please read the difference in the two state-machine diagrams, the have the
> same name phasing, but each describes which end of the cable you are on
> and the expected behavors.
I will do so now, I think I've stated my speculation above and in
earlier mails :-)
--
Jens Axboe
next prev parent reply other threads:[~2002-01-21 8:02 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-18 2:27 Linux 2.5.3-pre1-aia1 Anton Altaparmakov
2002-01-18 17:32 ` Davide Libenzi
2002-01-18 19:05 ` Jens Axboe
2002-01-18 19:23 ` Davide Libenzi
2002-01-18 19:28 ` Andre Hedrick
2002-01-18 19:48 ` Davide Libenzi
2002-01-18 19:40 ` Andre Hedrick
2002-01-18 19:44 ` Andre Hedrick
2002-01-19 11:40 ` Jens Axboe
2002-01-19 11:37 ` Andre Hedrick
2002-01-19 15:45 ` Jens Axboe
2002-01-19 20:36 ` Andre Hedrick
2002-01-19 21:44 ` Davide Libenzi
2002-01-20 0:31 ` Andre Hedrick
2002-01-20 2:02 ` Davide Libenzi
2002-01-20 10:48 ` Jens Axboe
2002-01-20 18:55 ` Davide Libenzi
2002-01-21 0:12 ` Andre Hedrick
2002-01-21 10:43 ` Vojtech Pavlik
2002-01-21 10:48 ` Jens Axboe
2002-01-21 10:56 ` Jens Axboe
2002-01-21 17:44 ` Davide Libenzi
2002-01-21 11:14 ` Vojtech Pavlik
2002-01-21 11:29 ` Jens Axboe
2002-01-21 11:38 ` Vojtech Pavlik
2002-01-21 11:51 ` Andre Hedrick
2002-01-21 11:34 ` Andre Hedrick
2002-01-21 17:44 ` Jens Axboe
2002-01-21 20:18 ` Andre Hedrick
2002-01-21 22:57 ` Vojtech Pavlik
2002-01-21 23:53 ` Andre Hedrick
2002-01-22 7:20 ` Vojtech Pavlik
2002-01-22 7:52 ` Andre Hedrick
2002-01-22 8:16 ` Jens Axboe
2002-01-22 9:45 ` Andre Hedrick
2002-01-22 10:06 ` Jens Axboe
2002-01-22 23:18 ` END GAME (Re: Linux 2.5.3-pre1-aia1) Andre Hedrick
2002-01-23 8:55 ` Jens Axboe
2002-01-23 20:57 ` Andre Hedrick
2002-01-22 10:26 ` Linux 2.5.3-pre1-aia1 Anton Altaparmakov
2002-01-22 16:49 ` Linus Torvalds
2002-01-22 18:45 ` Andre Hedrick
2002-01-21 21:44 ` Andre Hedrick
2002-01-22 7:32 ` Jens Axboe
2002-01-21 11:22 ` Andre Hedrick
2002-01-21 11:32 ` Vojtech Pavlik
2002-01-21 11:34 ` Jens Axboe
2002-01-21 1:48 ` Andre Hedrick
2002-01-21 7:36 ` Jens Axboe
2002-01-21 7:46 ` Andre Hedrick
2002-01-21 8:01 ` Jens Axboe [this message]
2002-01-21 8:42 ` Andre Hedrick
2002-01-21 9:00 ` Jens Axboe
2002-01-21 8:59 ` Andre Hedrick
2002-01-21 9:07 ` Jens Axboe
2002-01-21 9:48 ` Andre Hedrick
2002-01-18 19:26 ` Andre Hedrick
-- strict thread matches above, loose matches on Subject: below --
2002-01-21 4:40 Andre Hedrick
2002-01-21 4:40 Andre Hedrick
2002-01-21 6:19 ` Matti Aarnio
2002-01-21 22:45 Petr Vandrovec
2002-01-21 23:27 ` Andre Hedrick
2002-01-22 7:58 ` Jens Axboe
2002-01-22 8:52 ` Andre Hedrick
2002-01-22 14:17 ` Denis Vlasenko
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=20020121090156.O27835@suse.de \
--to=axboe@suse.de \
--cc=aia21@cam.ac.uk \
--cc=andre@linuxdiskcert.org \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox