Re: ATA Patch #7 (Re: ATA Patch #6)
:I took this way, but allowing the blahdelay to be zero(in which case
:DELAY() isn't called). I also made selection delay tunable, and made
:two delays tunable int's so that I can put it in the /boot/loader.conf
: hw.ata.command_delay=0
: hw.ata.selection_delay=0
:(it works on all of my DragonFly machines, but not sure on other machines)
:
:They both default to 10 for safety, but these DELAY()'s seem to have bigger
:impact on performance on slower machines. Does command-start delay really
:need to be 10us(=10000ns) which is far too larger than the required 400ns
:and taking into account the number of instructions between ATA_OUTB()
:and ATA_INB()?
If I remember correctly there was some older hardware that did not
bring BUSY up quickly enough, but I am all for having it under sysctl
and making the default 0.
However, for the 0 case the spec does seem to indicate that a one-IO
delay is required. i.e. you should do a dummy INB for the 0-delay case
rather then do nothing.
:> Here is a posit... if writing to ALTSTATUS (which controls IDS and
:> other bits) is illegal during DMAC, is reading STATUS or ALTSTATUS
:> also illegal during DMAC? The spec seems to indicate that it is
:> not illegal but I'm beginning to think that it may be.
:> If it is then we need to add more code to the interrupt handler, though
:> I'm not sure exactly what we would be able to do.. I guess we could
:> check the DMA controller to see if it indicates that DMA has completed,
:> but that doesn't help us with the ATA_S_ERROR case.
:
:I don't know about that.. Alternate Status register and Device Control register
:are just two separate registers sharing the same address, so I don't think
:the same access restriction as Device Control register applies to Alternate
:Status register. But it may depend on controllers.
Well, I guess the question is... is reading ALTSTAT doing a bus operation
over the IDE cable? If it is the DMA will interfere with it.
Another alternative is, I think, we may be able to safely stop any running
DMA, read ALTSTATUS, and then continue the DMA.
(But for now I'm not going to worry about it).
:> I've synchronized with your patch-7-take-2 so lets form a new basis
:> relative to that. Could you take another pass at the interlock calls
:> you added and remove the ones for situations where no completion
:> interrupt is expected?
:
:Thanks, attached(a diff against CVS-HEAD).
:
:Unfortunately, none of ATA Patch #7, #7 + patch-7-take2, or the patch
:attached to this message worked on a desktop in my office. It's has
:a PentiumIV 1.7GHz running SMP kernel(but HTT is unavailable). No timer
:problem, and not using TIMER_USE_1.
:It frequently timed out trying to identify the media in the CD-ROM drive,
:or when writing to the harddrive. Reading from the harddrive also timed
:out, but only once or so at the beginning.
:Inserting DELAY()'s after the call to ata_clear_interlock() seemed to
:reduce the number of timeouts, but it wasn't quite reproducible.
:Increasing or decreaing command_delay or selection_delay seemed to have
:little to do with the timeout. Sigh. I'll try a UP kernel later to see
:if running an SMP kernel has something to do with this.
Oky doky.
-Matt
討論串 (同標題文章)
完整討論串 (本文為第 6 之 6 篇)：