[lkml]   [2008]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] firewire: fw-ohci: sync AT dma buffer before use
On Thursday 13 March 2008 04:49:03 am Stefan Richter wrote:
> >> So this patch shouldn't do
> >> anything, except that it inserts a call which happens to have barrier
> >> characteristics on some platforms.
> ...and potentially delays execution.
> > ...but got lucky in that it actually helps this particular setup (x86_64
> > kernel, dual quad-core opteron, 8G RAM, 3 FireWire controllers). Hrm.
> Unless you or I spot the real solution earlier, you could also try
> replacing your dma_sync_ with mb() and with mdelay() respectively to see
> what aspect of the dma_sync_ is fixing your setup.  Also move the mb()
> to other interesting places of the involved code.

So it would seem I screwed up something in my testing, and failed to reproduce
the panic after adding '[PATCH] firewire: fw-ohci: use dma_alloc_coherent for
ar_buffer' to the mix. Best as I can tell now, the panic was actually
resolved by that patch, as backing out the sync altogether now works just as
well as with the sync, with an mb and with an mdelay.

This sort of makes some degree of sense, since this is another x86_64 system
w/>= 4GB of RAM. It would appear possible that at some higher layer, where AT
and AR transactions are coordinated with one another, we were getting an AT
packet into a bad state due to its corresponding AR traffic being stuck in a
non-coherent buffer we couldn't read. But this is only semi-informed

Jarod Wilson
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-03-14 19:31    [W:0.032 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site