lkml.org 
[lkml]   [2002]   [Jan]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Linux 2.5.3-pre1-aia1
    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:15    [W:2.953 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site