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

Unfortunately ATA/ATAPIv7 says that single interrupt is triggered after command is done and all data transfered, and we do not play with select bit. But we play with nIEN bit of disk. Do you see any reason why this should cause spurious interrupt? (system is using XT-PIC, FYI)

Quoted 5 lines · I wrote:

Unfortunately ATA/ATAPIv7 says that single interrupt is triggered after command is done and all data transfered, and we do not play with select bit. But we play with nIEN bit of disk. Do you see any reason why this should cause spurious interrupt? (system is using XT-PIC, FYI)

OK. As I am using only one device on each channel, I commented out ata_irq_enable(drive, 1) in ide-disk.c when issuing command, and removed disabling irq in ide_do_request in ide.c when we do not issue command to the drive, and spurious interrupts disappeared. So now I'm getting only half of IRQs for channel 0, and system still works as before ;-)

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.

And as always, something else: ata_error does:

OUT_BYTE(WIN_NOP, ch->ports[IDE_CONTROL_OFFSET])

I'd say that it should use 0x00 instead of WIN_NOP, and also tha comment above OUT_BYTE(0x04, ch->ports[IDE_CONTROL_OFFSET]) is bogus. Command register is IDE_COMMAND, not IDE_CONTROL ;-)

Quoted 10 lines

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();

Quoted 13 lines · Marcin Dalecki

Quoted 5 lines

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) {
....

Quoted 7 lines

 if (tmp->queue == q) {
       drive = tmp;
	break;

}
}
if (!drive)
BUG();

hey that sucks :-)

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

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

Quoted 1 line

hey that sucks :-)

Since IDE 111 not any more...

Quoted 2 lines

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 :-).

Quoted 2 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

I'm thinking about the alternation of the devices so one device can't starve the other device off the channel.

Quoted 11 lines · Jens Axboe

Quoted 9 lines

Quoted 2 lines

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.

Quoted 2 lines

I'm thinking about the alternation of the devices so one device can't starve the other device off the channel.

Ah so you are thinking about two equally powered devices competing for the channel. Something I would call the "sumo fight" situation. Well disks didn't use the "sleeping" mechanism at all anyway and the chances someone would do cp from CD-ROM to CD-ROM are low.

Finally I think that the proper granularity of scheduling requests to the drive is, well, the request layer. The queue processing layer should handle this becouse otherwise we would have two "competing" optimization mechanisms. And there we are indeed able to actually relinquish some CPU time. If you look at an request processing optimization as a low pass signal filter it's immediately obvious that the effects of chaining them can be, well at least "counter intuitive".