Re: Patch #6 (was Re: Patch #5)
:Matt,
:
:I am feeling really good about this most recent patch. No timeouts so far,
:and no stray interrupts! What did you change?
:
:Also, are buildworlds the best thing to stress I/O? Or is there a better
:stress test?
:
:jm
:--
:My other computer is your Windows box.
Are you getting any diagnostic messages on the console? (run dmesg).
Keep testing. Keep doing whatever you were doing that was causing
timeouts before. I will post another email to kernel@ with the patch
(since I originally only sent it to you)... you won't have to repatch,
it's the same patch that you are running now.
Primarily I retooled the interrupt handler. First I physically disable
the ATA interrupt all the way through DMA setup whereas in the original
ATA code the ATA interrupt was reenabled after the command was queued
but before DMA was started. Second, I added an ATA_INTERRUPT_INTERLOCK
flag to tell the interrupt handler that the ATA command and DMA was still
being programmed, causing the interrupt handler the exit immediately
without polling any I/O registers at all. Since the interrupt is
physically disabled while ATA_INTERRUPT_INTERLOCK is set the interrupt
handler can safely exit without touching anything or clearing the
supposed interrupt without having to worry about a livelocked interrupt.
This fixes several timing races which I think FreeBSD-4 and 5 partially
mask due to other things. From my read, the original ATA code was
not only extremely sensitive to shared interrupts with other devices,
but it was also possible for ATA to queue an interrupt just prior to
it being disabled, for ATA devices to generate spurious interrupts which
would be acted upon by the host OS at the wrong time, and for an ATA
device to generate an interrupt after the command was queued but before
DMA could be initialized, which mightily confuses the interrupt handler.
These problems are most apparent in FreeBSD when the IRQ line is shared,
but appears to be issues in DragonFly whether the IRQ line is shared or
not. I cleaned up the interrupt sequencing so an ATA interrupt would
absolutely not touch the ATA registers at the wrong time.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 2 之 4 篇)：