sos at spider.deepcore.dk
Thu Nov 20 00:35:59 PST 2003
It seems Thomas Moestl wrote:
> The issue is that the chip does not set ATA_BMSTAT_INTERRUPT, even though
> it is DMA-capable. My hackaround is to add an interrupt handler for the
> CMD646 that does only check this bit if a DMA transfer is in progress,
> like it was done in pre-ATAng times. This probably isn't the best solution,
> but it works for now. On the problematic boxen, you will also have to
> set hw.ata.ata_dma=0 (they fell back to PIO before automatically anyway,
> and DMA operations time out even if all interrupts are admitted).
> I am not sure whether this is caused by some missing bit of setup that
> is required, but that the firmware doesn't do for us, or whether it
> applies only to some buggy/crippled chip revision in some machines.
Hmm, the only 646 chip I hace sits in an alpha board which -current
hasn't been upgraded for quite some time as it broke it (might be
fixed in the meantime, I'll try to check..
However if that bit doesn't work the chip has *serious* problems
and cannot be used in DMA mode at all. I dont recall seeing this
problem on the one in my alpha though, so it might be specific to
certain silicon (rev number cannot be trusted in old CMD chips
either, they are so crappy its unbeliveable)...
> Additionally, this patch should fix the panic that were reported on
> request timeouts - the ata_request structure used to print the timeout
> warning could already be freed at that point, causing references to
> locations near 0xdeadc0de. I am not sure that the check for
> (ch->running != request) is completely safe with this in mind, since
> it could be possible that the request was freed and already reinserted.
Right I have a local fix semilar to this, but yes the test could fail
and I've looked at different ways to stay clear, but havn't decided
yet (besides the chances are very small for this to happen)...
> Søren, can you think of a reason why the interrupt bit would not be set?
Bad silicon, broken design - both fit the CMD nicely :(
> Otherwise, can you please take a look at the patch and tweak it so that
> some fix for this problem can be committed?
Yes, I'll see if I can get the alpha in the air with a new -current...
More information about the freebsd-sparc64