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

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

Am Sonntag, 13. Januar 2013, 22:23:13 schrieb Markus Grabner:
> Am Dienstag, 8. Januar 2013, 23:54:20 schrieb Mariusz Kozlowski:
> > On Tue, Jan 08, 2013 at 09:21:49PM +0100, Markus Grabner wrote:
> > > 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.
> > 
> > Ok so this is how I tested it:
> > 
> > 1. <change pod.h> && make
> > 2. <try to play some samples via POD alsa interface>
> > 3. while true; do sudo insmod line6usb.ko; sleep 4; sudo rmmod line6usb;
> > done
> > 
> > And that's left for a few miutes to see if anything blows up.
> > 
> > D1     D2
> > 1000 + 100 -> works ok
> > 100 + 50 -> works ok
> > 50 + 10 -> oops on insmod from time to time
> > 0 + 20 -> oops on insmod
> > 0 + 0 -> sometimes works, sometimes oops
> > 
> > Tests with values of D1 below 100 produce lots of additional communication
> > until firmware version request arrives. That is not seen for values above
> > 100 but maybe certain combination of D1 + D2 triggers that additional
> > messages.
> > 
> > So 100 + 50 seems reasonable.
> 
> Thanks for testing! I tried these settings, but they didn't work for me. I
> did the following:
> *) compile and install the driver
> *) connect the PODxt Live with main powers switched off
> *) switch on main powers of PODxt Live
> 
> Then the message "Invalid Code Error 8" is displayed on the device (which
> was actually the reason for implementing the delayed startup procedure in
> the first place). D1=200 and D1=300 have the same problem, only with D1=400
> the device starts up correctly. D2=50 works fine. I will test with these
> values for a while and then commit them with a broad safety margin.
I didn't experience any problems with these values, but considering a safety 
margin, I will keep the old values (D1=1000, D2=100) which are well tested by 
others. I just committed the new initialization procedure to the trunk.

	Kind regards,
		Markus