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 Mon, Jan 21, 2002 at 11:48:30AM +0100, Jens Axboe wrote:
    > On Mon, Jan 21 2002, Vojtech Pavlik wrote:
    > > On Sun, Jan 20, 2002 at 04:12:36PM -0800, Andre Hedrick wrote:
    > >
    > > > > > > We only read out 4k thus the device has the the next 4k we may be wanting
    > > > > > > ready. Look at it as a dirty prefetch, but eventally the drive is going
    > > > > > > to want to go south, thus [lost interrupt]
    > > > > >
    > > > > > Even if the drive is programmed for 16 sectors in multi mode, it still
    > > > > > must honor lower transfer sizes. The fix I did was not to limit this,
    > > > > > but rather to only setup transfers for the amount of sectors in the
    > > > > > first chunk. This is indeed necessary now that we do not have a copy of
    > > > > > the request to fool around with.
    > > >
    > > > Listen and for just a second okay.
    > > >
    > > > Since the set multimode command is similar to the set transfer rate, if
    > > > you program the drive to run at U100 but the host can feed only U33 you
    > > > have problems. Much of this simple arguement is the same answer for
    > > > multimode.
    > > >
    > > > Same thing here but a variation, of the operations,
    > >
    > > So you're saying that if you program the drive to multimode 16, you
    > > can't read a single sector and always have to read 16? That not only
    > > doesn't make sense to me, but it also contradicts anything that I've
    > > heard before.
    >
    > Well it didn't/doesn't make sense to me either, let me quote spec
    > though:
    >
    > (READ_MULTIPLE)
    >
    > "If the number of requested sectors is not evenly divisible by the block
    > count, as many full blocks as possible are transferred, followed by a
    > final, partial block transfer."
    >
    > (block count being the multi setting here)
    >
    > I actually misread this the first time around, it seems my original code
    > was indeed correct (and that 2.4 of course also is). For the example 24
    > sector request and multi mode of 16, the drive _will_ only expect 8
    > sectors in the final run. That makes sense to me again, I couldn't
    > understand the apparent brain damage in the model Andre suggested.
    >
    > Time for a new patch...

    I always thought it is like this (and this is what I still believe after
    having read the sprcification):

    ---
    SET_MUTIPLE 16 sectors
    ---
    READ_MULTIPLE 24 sectors
    IRQ
    PIO transfer 16 sectors
    IRQ
    PIO transfer 8 sectors
    ---

    Where am I wrong?

    By the way, the device *isn't* required to support any lower multiple
    count than the maximum one it advertizes. Ugly.

    --
    Vojtech Pavlik
    SuSE Labs
    -
    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:0.027 / U:0.776 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site