Messages in this thread | | | Date | Tue, 22 Jan 2002 11:06:22 +0100 | From | Jens Axboe <> | Subject | Re: Linux 2.5.3-pre1-aia1 |
| |
On Tue, Jan 22 2002, Andre Hedrick wrote: > > A CLUE HAS ARRIVED ... > > On Tue, 22 Jan 2002, Jens Axboe wrote: > > > On Mon, Jan 21 2002, Andre Hedrick wrote: > > > > On Mon, Jan 21, 2002 at 03:53:20PM -0800, Andre Hedrick wrote: > > > > > On Mon, 21 Jan 2002, Vojtech Pavlik wrote: > > > > > Okay if the execution of the command block is ATOMIC, and we want to stop > > > > > an ATOMIC operation to go alter buffers? > > > > > > > > YES! I think you got it! Because atomic here doesn't mean 'do it all as > > > > soon as possible with no delay', but 'do nothing else on the ATA bus > > > > inbetween'. > > > > > > In order to do this you can not issue a sector request larger than an > > > addressable buffer, since the request walking of the rq->buffer is not > > > allowed. > > > > It's not that it's not allowed, it's that it doesn't work the way you > > want it. ->buffer is just the first segment, which is 8 sectors max, > > that much is correct. But nothing prevents your from ending the front > > of the request and continuing and the drive will never know. Just see > > task_mulin_intr. > > Is this not the effect of stopping the actual IO?
No, not at all. It goes something like this (for multi read, the case discussed here). Settings for this sample-run are:
- multi mode set to 16 sectors - request: nr_sectors 24 sectors, current_nr_sectors 8. request is thus split in 3 parts, we need to partially complete it do finish it.
o ide_do_request, get new active request o start_request, hand off to ide-disk:do_rw_disk() o do_rw_disk: setup taskfile, arm interrupt handler, return
[interrupt triggers]
o status is good, we can transfer the 16 sectors the drive expects
o taskfile_input_data for 8 sectors:
nsect = rq->current_nr_sectors; if (nsect > msect) nsect = msect;
o call ide_end_request to indicate completion of these 8 sectors. o calls end_that_request_last to complete the first buffer head in the request, resetup request for next transfer.
o ide_end_request returns 1, request is not complete.
o taskfile_input_data for 8 sectors.
o call ide_end_request again, still returns 1 (now we have 8 sectors left in the request)
o now we have transferred the 16 sectors inside the interrupt handler, since request is not complete rearm interrupt handler and return.
Next time task_mulin_intr is fired, we do the remaining 8 sectors. This time the drive knows to expect only 8 sectors, since we originally programmed it for 24 sectors total for this request.
> Then you have to issue another ACB to restart the IO for the next segment? > The device has to know when to stop sending.
Nope, see the above.
> It may be possible to do this is paging requirement if on a READ(any pio), > reset or update the rq->buffer prior to reading from the data register.
Yes that's very important, the ordering must be right or we are screwed.
> Now what guarentee will the driver have if a the buffer being a full 8 > sectors before the first read, and if that is not enough for the complete > segment transaction, then if we reduce the expected transfers size between > interrupts, it will allow for larger values to be put into the > sector_count register. This reduction must correspond to the expected and > required 4k page.
But why? The above scenario works.
> This I can do, and we can move forward. > > If the update of the rq->buffer occurrs afterwards, we may face a > driver--device race w/ an early and missied interrupt asserted.
We don't care about rq->buffer at all. What is important is correct (and ordered) rq->current_nr_sectors updates so that ide_map_rq returns the right transfer location.
> This sounds like what "Davide Libenzi" is reporting. > Not really a losted, but arrived while the rq->buffer is being updated. > Thus ordering of events are wrong.
It very well could be.
-- 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/
| |