Benjamin Herrenschmidt wrote:
>While I agree with you here, I don't think it's what's happening.
> /* clear INTR & ERROR flags */
> hwif->OUTB(dma_stat|6, hwif->dma_status);
>
>
>
You have way to much faith in the hardware. Promise is especially known
for not keeping to the spec. I wouldn't trust the interrupt bit to be
valid unless a dma is actually active, i.e. that
hwif->OUTB(hwif->INB(dma_base)|1, dma_base);
has actually been written.
I've actually had a manufacturer tell me that they don't worry about the
spec, just making things work with Windows.
Ross
On Wed, 2003-02-05 at 18:19, Ross Biro wrote:
> Benjamin Herrenschmidt wrote:
>
> >While I agree with you here, I don't think it's what's happening.
> > /* clear INTR & ERROR flags */
> > hwif->OUTB(dma_stat|6, hwif->dma_status);
> >
> >
> >
> You have way to much faith in the hardware. Promise is especially known
> for not keeping to the spec. I wouldn't trust the interrupt bit to be
> valid unless a dma is actually active, i.e. that
>
> hwif->OUTB(hwif->INB(dma_base)|1, dma_base);
>
> has actually been written.
>
> I've actually had a manufacturer tell me that they don't worry about the
> spec, just making things work with Windows.
Ok, so that gives us 2 possibilities. The above problem, which would be
fixed by locking all around ide_dma_read/write (or rather in the
_caller_, seems better so we don't have to drop the lock for ATAPI).
And a possible wraparound of waiting_for_dma if 255 IRQs come in from
whatever device we share the IRQ line with.
I beleive both need fixing...
Ben.
On 05 Feb 2003 18:34:55 +0100
Benjamin Herrenschmidt <[email protected]> wrote:
> On Wed, 2003-02-05 at 18:19, Ross Biro wrote:
> > Benjamin Herrenschmidt wrote:
> >
> > >While I agree with you here, I don't think it's what's happening.
> > > /* clear INTR & ERROR flags */
> > > hwif->OUTB(dma_stat|6, hwif->dma_status);
> > >
> > >
> > >
> > You have way to much faith in the hardware. Promise is especially known
> > for not keeping to the spec. I wouldn't trust the interrupt bit to be
> > valid unless a dma is actually active, i.e. that
> >
> > hwif->OUTB(hwif->INB(dma_base)|1, dma_base);
> >
> > has actually been written.
> >
> > I've actually had a manufacturer tell me that they don't worry about the
> > spec, just making things work with Windows.
>
> Ok, so that gives us 2 possibilities. The above problem, which would be
> fixed by locking all around ide_dma_read/write (or rather in the
> _caller_, seems better so we don't have to drop the lock for ATAPI).
>
> And a possible wraparound of waiting_for_dma if 255 IRQs come in from
> whatever device we share the IRQ line with.
>
> I beleive both need fixing...
>
> Ben.
Ok, yet another small brick in the wall: this mb has 64bit/66MHz PCI slots. PDC
is only 32bit/33MHz PCI. So it may well be that others are in fact _able_ to
produce a damn lot more data/interrupts than the PDC. I am pretty astonished by
the number of interrupts created by the 3com tg3 cards anyways...
--
Regards,
Stephan
On Wed, 2003-02-05 at 17:19, Ross Biro wrote:
> I've actually had a manufacturer tell me that they don't worry about the
> spec, just making things work with Windows.
Its very common. As a customer always ask the vendor if they are
compliant to each appropriate standard in writing. If they say yes it
has nice little liability issues should they be lying 8)