DMA breakage in 2.6.29-rc*

DMA breakage in 2.6.29-rc*

[Benjamin Herrenschmidt]

Hi Bart !

On a bunch of pmac's, I'm getting lost interrupts when trying to do DMA
with ide hard disks (first time at boot when reading the partition
table). It then times out, reverts to PIO and boots fine.

Haven't had time to fully bisect yet, but it seem to be somewhere in the
pile of IDE patches (surprise :-) that went in around that time.

I'll dig more next week, but in the meantime, I though you may have a
possible candidate in mind.

Cheers,
Ben.

Re: DMA breakage in 2.6.29-rc*

[Benjamin Herrenschmidt]

On Fri, 2009-01-30 at 16:46 +1100, Benjamin Herrenschmidt wrote:
> Hi Bart !
> 
> On a bunch of pmac's, I'm getting lost interrupts when trying to do DMA
> with ide hard disks (first time at boot when reading the partition
> table). It then times out, reverts to PIO and boots fine.
> 
> Haven't had time to fully bisect yet, but it seem to be somewhere in the
> pile of IDE patches (surprise :-) that went in around that time.
> 
> I'll dig more next week, but in the meantime, I though you may have a
> possible candidate in mind.

Smells like the patch that popped up not long ago already (can't find
the thread now) where you cleaned up the port registration and broke our
trick of passing a different parent device than the one used for DMA or
something like that ... that mixed with something not testing the dma
map results (probably my fault) and I think we are passing crap DMA
addresses to the device.

I'll sort it out. I should be able to just add working dma ops to the
macio_device, it's a lot easier now that ppc32 has the same dma ops
structure in struct device as ppc64.

Cheers,
Ben.

Re: DMA breakage in 2.6.29-rc*

[Mikael Pettersson]

Benjamin Herrenschmidt writes:
 > Hi Bart !
 > 
 > On a bunch of pmac's, I'm getting lost interrupts when trying to do DMA
 > with ide hard disks (first time at boot when reading the partition
 > table). It then times out, reverts to PIO and boots fine.
 > 
 > Haven't had time to fully bisect yet, but it seem to be somewhere in the
 > pile of IDE patches (surprise :-) that went in around that time.

On a slightly related note, any update on the pata_macio driver
you posted last summer? As I recall, it worked ok on my G4, except
for some OF/yaboot mismatch which broke ydl's /sbin/installkernel.

Re: DMA breakage in 2.6.29-rc*

[Benjamin Herrenschmidt]

On Fri, 2009-01-30 at 13:17 +0100, Mikael Pettersson wrote:
> Benjamin Herrenschmidt writes:
>  > Hi Bart !
>  > 
>  > On a bunch of pmac's, I'm getting lost interrupts when trying to do DMA
>  > with ide hard disks (first time at boot when reading the partition
>  > table). It then times out, reverts to PIO and boots fine.
>  > 
>  > Haven't had time to fully bisect yet, but it seem to be somewhere in the
>  > pile of IDE patches (surprise :-) that went in around that time.
> 
> On a slightly related note, any update on the pata_macio driver
> you posted last summer? As I recall, it worked ok on my G4, except
> for some OF/yaboot mismatch which broke ydl's /sbin/installkernel.

I needs more work and I didn't get a chance to do that yet.. It will
need yaboot's ofboot script to be updated too, unfortunately, as it hard
codes things specific to ide-pmac.

Cheers,
Ben.

Re: DMA breakage in 2.6.29-rc*

[Bartlomiej Zolnierkiewicz]

Hi,

On Friday 30 January 2009, Benjamin Herrenschmidt wrote:
> On Fri, 2009-01-30 at 16:46 +1100, Benjamin Herrenschmidt wrote:
> > Hi Bart !
> > 
> > On a bunch of pmac's, I'm getting lost interrupts when trying to do DMA
> > with ide hard disks (first time at boot when reading the partition
> > table). It then times out, reverts to PIO and boots fine.
> > 
> > Haven't had time to fully bisect yet, but it seem to be somewhere in the
> > pile of IDE patches (surprise :-) that went in around that time.
> > 
> > I'll dig more next week, but in the meantime, I though you may have a
> > possible candidate in mind.
> 
> Smells like the patch that popped up not long ago already (can't find
> the thread now) where you cleaned up the port registration and broke our
> trick of passing a different parent device than the one used for DMA or
> something like that ... that mixed with something not testing the dma

Yeah my bad, though thanks to Andreas Schwab it is fixed in -rc3.

> map results (probably my fault) and I think we are passing crap DMA
> addresses to the device.
> 
> I'll sort it out. I should be able to just add working dma ops to the
> macio_device, it's a lot easier now that ppc32 has the same dma ops
> structure in struct device as ppc64.

Would be great as I have completely no idea about this stuff.

While you are at DMA support and will be fixing/testing it anyway
you may try to remove long standing duplication/obfuscation:

	/* Those fields are duplicating what is in hwif. We currently
	 * can't use the hwif ones because of some assumptions that are
	 * beeing done by the generic code about the kind of dma controller
	 * and format of the dma table. This will have to be fixed though.
	 */
	volatile struct dbdma_regs __iomem *	dma_regs;
	struct dbdma_cmd*		dma_table_cpu;

What needs to be done is more-or-less:

- teaching pmac_ide_init_dma() about hwif->prd_max_{nents,size}
  and then converting it to use ide_allocate_dma_engine()

- pmif->dma_regs -> hwif->dma_base

- pmif->dma_table_cpu -> hwif->dmatable_cpu

- sticking ide_release_dma_engine() somewhere (it seems that
  pmac driver never frees DMA memory allocated currently)

Of course while the above would be a nice cleanup+fixup, making
the driver work comes first..

Thanks,
Bart

Re: DMA breakage in 2.6.29-rc*

[Benjamin Herrenschmidt]

> Yeah my bad, though thanks to Andreas Schwab it is fixed in -rc3.

Hrm... I was using rc3 here and had the bug. I'll dig to check it's
really that or something else and send a patch if needed.

> Would be great as I have completely no idea about this stuff.

No worries.

> While you are at DMA support and will be fixing/testing it anyway
> you may try to remove long standing duplication/obfuscation:
> 
> 	/* Those fields are duplicating what is in hwif. We currently
> 	 * can't use the hwif ones because of some assumptions that are
> 	 * beeing done by the generic code about the kind of dma controller
> 	 * and format of the dma table. This will have to be fixed though.
> 	 */
> 	volatile struct dbdma_regs __iomem *	dma_regs;
> 	struct dbdma_cmd*		dma_table_cpu;
> 
> What needs to be done is more-or-less:
> 
> - teaching pmac_ide_init_dma() about hwif->prd_max_{nents,size}
>   and then converting it to use ide_allocate_dma_engine()
> 
> - pmif->dma_regs -> hwif->dma_base
> 
> - pmif->dma_table_cpu -> hwif->dmatable_cpu
> 
> - sticking ide_release_dma_engine() somewhere (it seems that
>   pmac driver never frees DMA memory allocated currently)

I'll have a look. Can't promise I'll get it all done this week tho. I
have several other urgent things on my plate.

> Of course while the above would be a nice cleanup+fixup, making
> the driver work comes first..

Heh, we'll see... ide-pmac was never quite intended as a module and
definitely not a module you can remove. I don't know if it's worth
fixing to be honest.

Cheers,
Ben.

> Thanks,
> Bart

Re: DMA breakage in 2.6.29-rc*

[Benjamin Herrenschmidt]

On Mon, 2009-02-02 at 09:56 +1100, Benjamin Herrenschmidt wrote:
> > Yeah my bad, though thanks to Andreas Schwab it is fixed in -rc3.
> 
> Hrm... I was using rc3 here and had the bug. I'll dig to check it's
> really that or something else and send a patch if needed.

Ok so the test I did was just before -rc3, I just dbl checked and actual
-rc3 does indeed fix it.

I'll look at doing some of the proposed cleanups for the next merge
window.

Cheers,
Ben.