Re: [Line6linux-user] line6linux problem with pod xt live

[Markus G. <gr...@ic...>]

Am Dienstag, 8. Januar 2013, 19:03:59 schrieb Mariusz Kozlowski:
> On Tue, Jan 08, 2013 at 01:32:05AM +0100, Markus Grabner wrote:
> > On Monday 07 January 2013 21:49:36 Mariusz Kozlowski wrote:
> > > This is interesting. I tried a couple of times and it always worked.
> > > When I send firmware version request using 'raw data communication'
> > > interface POD responds correctly with firmware version and the driver
> > > completes initialisation - alsa devices are registered and usable.
> > > So this is pretty cool. There is some hope ... ;) Please see attached
> > > line6-4.log with my comments inlined there.
> > 
> > Ok, so there doesn't remain much code to check then :-) At first sight,
> > the
> > statement "kfree(buffer);" in "line6_version_request_async" could be a
> > problem. Can you comment it out just for testing? This creates a memory
> > leak, but shouldn't cause any troubles otherwise.
> 
> Good news :) This fixes the initialisation problem. After first firmware
> request POD responds correctly with firmware version and alsa interface
> gets registered. I tried that on current trunk HEAD.
> 
> I'm looking at this code and wondering why it works. Because if we free
> memory before it really gets send then this should be visible on any
> hardware ... unless this is tight race and for some reason you do not
> observe this on your computer.
I guess it is really a very subtle timing issue, probably not related to the 
POD firmware version.

> Also I never got any use-after-free
> etc... but on the other hand I use stock ubuntu kernel so maybe most of
> checks are disabled. I wonder is some magic debugging options would show
> that on custom build kernel. Freed memory poisoning might not work as
> this is just data - not pointer that would get dereferenced. So the
> pointer would be valid but not the memory itself that it points to.
> Interesting anyway.
I think it is just the DMA controller which is programmed to transfer data 
from some physical address to the USB hardware, and it doesn't care about the 
content of this memory.

> So please prepare final fix and I'll test it :) I think mainline needs
> that fix as well.
A couple of weeks ago an effort has started to move the Line6 driver out of 
the staging area, and now that we found out the reason, I remember that one of 
the patches adressed just this issue. I will look it up and see if we can use 
it here to avoid future conflicts.

In the meantime, you could try to find out the minimum values for the startup 
delays (POD_STARTUP_DELAY[1|2] in pod.h) such that the driver works on your 
system. The first value is the initial delay after the device is connected, 
the second value is the delay between the following initialization steps. 
Since we are currently touching the code, we should use the chance to make 
device initialization faster if possible.

	Kind regards,
		Markus