Re: Acer M5229 IDE bugs (esp. on sparc64)

[Rafal Boni <rafal%pobox.com@localhost>]

Thanks for the reply, Manuel.. glad to have input from someone who knows 
the code and ATA(PI) subsystem well!

Manuel Bouyer wrote:
> On Thu, Feb 14, 2008 at 02:17:47PM -0500, Rafal Boni wrote:
[...]
> > I see that wdc->dma_status is always 0x04 (WDC_DMAST_UNDER), which is a 
> > synthetic error generated only by pciide_dma_finish().  I'm guessing 
> > that the suspect pciiide_dma_finish() is the one called from wdcintr(). 
> >  Because the rev of the M1559 IDE controller I have doesn't have a 
> > chan-id register to determine which channel caused an interrupt, for 
> > this chip we end up *always* checking both channels, and the code in 
> > wdcintr() / pciide_dma_finish() looks very suspicious... stop DMA first, 
> > ask questions later.
>
> AFAIK it's not: before stopping the DMA channel, we check if the controller
> did interrupt (status & IDEDMA_CTL_INTR).

A minor point of clarification here... is that status per-controller, or 
per-channel?  Note that this controller is running in native-PCI mode 
and there is no register to tell is which channel interrupted (see 
aceride.c, ~ line 238).  I'm wondering if one channel interrupting could 
have caused the early-DMA termination on the other.

> We have to stop the DMA first, because in some case the DMA engine will still
> be active at end of transfer (if the device has less data to return than
> requested for example - as the comment says, it's a valid condition for
> ATAPI devices).

Interestingly enough, the ATAPI devices connected to this controller on 
both my machines (a V100, V120 and a T1/200) and machines Julian tested 
(a Blade 100 at least, maybe a V120 as well) both are unable to do any 
sort of DMA to/from the CD anyway.  I'm not sure it's related to this, 
but maybe... (and not just UDMA... the CD downgrades right through the 
UDMA range to MW DMA and then to PIO 4).  Of course, I have no PC's with 
 this cursed controller to test if/whether this is somehow related to 
the sparc64 platform or a generic issue ;)

> > FreeBSD looks like it does the checks a bit differnetly (their whole 
> > handling of the Bus-Master DMA status register -- IDEDMA_CTL -- is a bit 
> > different, but they key is they look like they check the active status 
> > (IDEDMA_CTL_ACT) before attempting to kill the dma vs. our kill-1st, 
> > check if active later.
>
> If this chip asserts IDEDMA_CTL_INTR supriously, and we need to check
> IDEDMA_CTL_ACT instead, then it's broken. So it needs a private intr
> routine, and it needs to disable DMA for ATAPI devices.

Hmm, ok.  Is there a reference somewhere for how CTL_INTR, CTL_ACT and 
generation of the actual hardware interrupt should behave with respect 
to each other?  What I'm after is a way to actually test if the chip is 
asserting IDEDMA_CTL_INTR spuriously or not.

(The other reason I ask is that given what you say, I can't understand 
why FreeBSD would pre-load that register with CTL_INTR | CTL_ERR (or the 
equivalent bits there... (ATA_BMSTAT_INTERRUPT | ATA_BMSTAT_ERROR)).

Thanks, again for your clue here!
--rafal