Port-sparc64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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



Home | Main Index | Thread Index | Old Index