Re: IDE from current bk tree, UDMA and two channels...

[Marcin Dalecki <dalecki@evision.ag>]

Jens Axboe wrote:
> On Wed, Jul 31 2002, Marcin Dalecki wrote:
> 
>>>Unfortunately, problem is still here: when kernel was in idedisk_do_request
>>>performed on channel 0, IRQ for channel 1 arrived, and this irq found 
>>>channel 1 DMA engine ready, but drive had DRQ set... oops. Shortly after 
>>>that IRQ for channel 1 arrived again, but as it was unexpected, nothing 
>>>happened. 
>>>
>>>I hope that i845 is not simplex device, but first (unexpected) IRQ arrived 
>>>just when channel 0 code wrote new value to its IDE_SELECT_REG register. 
>>>Now I even disconnected DVD drive, so it is simple two masters, two
>>>channels configuration, but it still happens.
>>
>>One idea and one experiment I was already thinking about is
>>to change do_ide_request to actually *not* select delibreately which 
>>device do handle. (The big for loop found there...)
>>One can instead search for a device on the channel which is matching
>>the queue for which do_ide_request() was called.
>>
>>for (unit = 0; unit < MAX_DEVICES; ++unit) {
>>  ....
>>  if (tmp->queue == q) {
>>        drive = tmp;
>>	break;
>>  }
>>}
>>if (!drive)
>>  BUG();
> 
> 
> hey that sucks :-)

Since IDE 111 not any more...

> seriously, the better way to do this would be to change the q->queuedata
> to be a pointer to drive instead of the channel.

... becouse this is already *done* there :-).

> that would work, but I think it would seriously starve the other device
> on the same channel.

We starve anyway, becouse the kernel isn't real time and we can't
guarantee "sleeping" for some maximum time and comming back.
We don't reschedule the kernel during this kind of "sleeping".
And we can't know that a command on the "mate" will not take 
extraordinary amounts of time. It's only a problem if mixing travan
tapes with disks on a channel.