line6linux-user — mailing list for users of Line6 Linux software

Re: [Line6linux-user] Which version for HD300

[Stefan H. <ste...@gm...>]

On Fri, Jan 11, 2013 at 7:34 AM,  <jea...@fr...> wrote:
> Thanks,
>
> I've take a looj to code of usb-skeleton driver on http://lxr.linux.no ,
> macro module_usb_driver seem to have been introduce  by 3.3 kernel.
>
> This macro does nothing but creating empty side effect for registering
> driver. Do I will try to make a pacth with the good preprocessor test kernel
> version and reintroduce the module_init/exit stuff  this WE.

The simplest solution is probably to build a vanilla kernel.  Try
3.8-rc2, I'm using the upstream driver with my POD HD300 successfully.

Use Debian's make-kpkg and it'll build a .deb for you that installs
just like a distro kernel.

Stefan

Re: [Line6linux-user] Which version for HD300

[<jea...@fr...>]

Thanks, 


I've take a looj to code of usb-skeleton driver on http://lxr.linux.no , macro module_usb_driver seem to have been introduce by 3.3 kernel. 


This macro does nothing but creating empty side effect for registering driver. D o I will try to make a pacth with the good preprocessor test kernel version and reintroduce the module_init/exit stuff this WE. 


best regards 

----- Mail original -----

De: "Markus Grabner" <gr...@ic...> 
À: lin...@li... 
Cc: "jeanseb" <jea...@fr...> 
Envoyé: Jeudi 10 Janvier 2013 20:45:33 
Objet: Re: [Line6linux-user] Which version for HD300 

Am Donnerstag, 10. Januar 2013, 20:24:44 schrieb jeanseb: 
> Hi, 
> 
> 
> I'm looking for what line 6 POD HD 300 driver, compatible with debian 
> wheezy (kernel 3.2.0) or squeeze (kernel 2.6.32) ? 
> 
> I've tried to compile last trunk but module isn't called when the card 
> plugged. 
> 
> at compile time there is this warning : 
> ------ 
> /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1: warning: data 
> definition has no type or storage class [enabled by 
> default] /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1: 
> warning: type defaults to ‘int’ in declaration of 
> ‘module_usb_driver’ [-Wimplicit-int] 
> /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1: warning: parameter 
> names (without types) in function declaration 
> [enabled by 
> default] /home/jeanseb/line6linux/driver/trunk/driver.c:1272:26: 
> warning: ‘line6_driver’ defined but not used [-Wunused-variable] 
> ------ 
Looks like the module_usb_driver macro doesn't exist in your kernel (under 
3.4.11, it's in /usr/src/linux/include/linux/usb.h). This line was introduced 
in r940 when syncing the svn version to the git version. So I believe your 
options are: 
*) downgrade the driver to a release prior to 940, or 
*) upgrade the kernel 

The latter option is certainly preferred. There were no HD300-related changes 
since 940, but if you find out that somethings needs to be modified or fixed, 
this can only be done against the head revision. 

Kind regards, 
Markus 

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

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

Am Donnerstag, 10. Januar 2013, 21:51:56 schrieb Mariusz Kozlowski:
> On Thu, Jan 10, 2013 at 09:24:54PM +0100, Markus Grabner wrote:
> > Am Dienstag, 8. Januar 2013, 23:54:20 schrieben Sie:
> > > BTW. I think I found another bug ... this is minor but probably should
> > > get fixed. If you rmmod before driver finishes initialisation it
> > > is likely to get oops.
> > > 
> > > Try something like this:
> > > 
> > > # while true; do insmod line6usb.ko; sleep 0.1; rmmod line6usb; sleep 1;
> > > done
> > 
> > I let this run for ~30 minutes and did normal work during this time, but
> > was not able to reproduce the crash. Our machines seem to have somewhat
> > different timings...
> > 
> > Nevertheless, termination of the startup procedure could be done more
> > carefully, which I checked in as r987. Another problem might be the sysfs
> > files, which are removed before the startup procedure is terminated, i.e.,
> > in rare occasions those files could be created after the attempt to
> > delete them. Since the sysfs files will be removed from the driver in the
> > future, I don't want to spend too much time on them right now. You could
> > try to move the timer and workqueue related lines in
> > [pod|variax]_destruct into the corresponding *_disconnect function
> > (before the device_remove_file lines) to see if it makes a difference
> > (though I don't think so).
> 
> I'll try to dig a bit deeper on my own. That sounds like a good
> exercise. This isn't a big issue anyway but just could get fixed.
A kernel debugger (http://www.kernel.org/doc/htmldocs/kgdb.html) might be 
helpful. In case of a crash, the processor enters a simple terminal which 
allows you to get a stack dump, examine memory content etc. You should work on 
a text console since the kernel debugger won't switch to text mode if the 
machine was in graphics mode (X11) during the crash. Alternatively, you could 
use a serial port for kernel debugging, but I never tried this. Good luck!

	Kind regards,
		Markus

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

[Mariusz K. <mk...@la...>]

On Thu, Jan 10, 2013 at 09:24:54PM +0100, Markus Grabner wrote:
> Am Dienstag, 8. Januar 2013, 23:54:20 schrieben Sie:
> > BTW. I think I found another bug ... this is minor but probably should
> > get fixed. If you rmmod before driver finishes initialisation it
> > is likely to get oops.
> > 
> > Try something like this:
> > 
> > # while true; do insmod line6usb.ko; sleep 0.1; rmmod line6usb; sleep 1;
> > done
> I let this run for ~30 minutes and did normal work during this time, but was 
> not able to reproduce the crash. Our machines seem to have somewhat different 
> timings...
> 
> Nevertheless, termination of the startup procedure could be done more 
> carefully, which I checked in as r987. Another problem might be the sysfs 
> files, which are removed before the startup procedure is terminated, i.e., in 
> rare occasions those files could be created after the attempt to delete them. 
> Since the sysfs files will be removed from the driver in the future, I don't 
> want to spend too much time on them right now. You could try to move the timer 
> and workqueue related lines in [pod|variax]_destruct into the corresponding 
> *_disconnect function (before the device_remove_file lines) to see if it makes 
> a difference (though I don't think so).

I'll try to dig a bit deeper on my own. That sounds like a good
exercise. This isn't a big issue anyway but just could get fixed.

> Do you get any information on the crash (maybe in the system log file, or on 
> the console when doing insmod/rmmod on a text console)?

No, computer was so dead that nothing was written to disk. All I got was
nice panic message begining of which managed to scroll off the screen
and some leftovers in buffer being played in the loop. I didn't take a
picture but that should be easy to reproduce.

I'll be without access to computer for next few days. I'll try to
reproduce this once I'm back (not sooner than Sunday evening).

Thanks,
-- 
Mariusz Kozlowski

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

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

Am Dienstag, 8. Januar 2013, 23:54:20 schrieben Sie:
> BTW. I think I found another bug ... this is minor but probably should
> get fixed. If you rmmod before driver finishes initialisation it
> is likely to get oops.
> 
> Try something like this:
> 
> # while true; do insmod line6usb.ko; sleep 0.1; rmmod line6usb; sleep 1;
> done
I let this run for ~30 minutes and did normal work during this time, but was 
not able to reproduce the crash. Our machines seem to have somewhat different 
timings...

Nevertheless, termination of the startup procedure could be done more 
carefully, which I checked in as r987. Another problem might be the sysfs 
files, which are removed before the startup procedure is terminated, i.e., in 
rare occasions those files could be created after the attempt to delete them. 
Since the sysfs files will be removed from the driver in the future, I don't 
want to spend too much time on them right now. You could try to move the timer 
and workqueue related lines in [pod|variax]_destruct into the corresponding 
*_disconnect function (before the device_remove_file lines) to see if it makes 
a difference (though I don't think so).

Do you get any information on the crash (maybe in the system log file, or on 
the console when doing insmod/rmmod on a text console)?

	Kind regards,
		Markus

Re: [Line6linux-user] Which version for HD300

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

Am Donnerstag, 10. Januar 2013, 20:24:44 schrieb jeanseb:
> Hi,
> 
> 
> I'm looking for what line 6 POD HD 300 driver, compatible with debian
> wheezy  (kernel 3.2.0) or squeeze (kernel 2.6.32) ?
> 
> I've tried to compile last trunk but module isn't called when the card
> plugged.
> 
> at compile time there is this warning :
> ------
> /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1: warning: data
> definition has no type or storage class [enabled by
> default] /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1:
> warning: type defaults to ‘int’ in declaration of
> ‘module_usb_driver’ [-Wimplicit-int]
> /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1: warning: parameter
> names (without types) in function declaration
> [enabled by
> default] /home/jeanseb/line6linux/driver/trunk/driver.c:1272:26:
> warning: ‘line6_driver’ defined but not used [-Wunused-variable]
> ------
Looks like the module_usb_driver macro doesn't exist in your kernel (under 
3.4.11, it's in /usr/src/linux/include/linux/usb.h). This line was introduced 
in r940 when syncing the svn version to the git version. So I believe your 
options are:
*) downgrade the driver to a release prior to 940, or
*) upgrade the kernel

The latter option is certainly preferred. There were no HD300-related changes 
since 940, but if you find out that somethings needs to be modified or fixed, 
this can only be done against the head revision.

	Kind regards,
		Markus

[Line6linux-user] Which version for HD300

[jeanseb <jea...@fr...>]

Hi, 


I'm looking for what line 6 POD HD 300 driver, compatible with debian
wheezy  (kernel 3.2.0) or squeeze (kernel 2.6.32) ?

I've tried to compile last trunk but module isn't called when the card
plugged.

at compile time there is this warning :
------
/home/jeanseb/line6linux/driver/trunk/driver.c:1284:1: warning: data
definition has no type or storage class [enabled by
default] /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1:
warning: type defaults to ‘int’ in declaration of
‘module_usb_driver’ [-Wimplicit-int] /home/jeanseb/line6linux/driver/trunk/driver.c:1284:1:
warning: parameter names (without types) in function declaration
[enabled by
default] /home/jeanseb/line6linux/driver/trunk/driver.c:1272:26:
warning: ‘line6_driver’ defined but not used [-Wunused-variable]
------


Last one seemed suspect to me so i did a "grep usb_register *" and the
is no answer.


best regards 

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

[Mariusz K. <mk...@la...>]

On Tue, Jan 08, 2013 at 11:48:25PM +0100, Markus Grabner wrote:
> Am Dienstag, 8. Januar 2013, 19:03:59 schrieb Mariusz Kozlowski:
> > So please prepare final fix and I'll test it :) I think mainline needs
> > that fix as well.
> Ok, it's again in
> 
> https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/init

I tested current HEAD of init branch (r984) and it works for me.

Thanks,
-- 
Mariusz Kozlowski

Re: [Line6linux-user] [patch 2/2] staging: line6: use after free bug requesting version

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

Am Donnerstag, 6. Dezember 2012, 10:08:44 schrieb Dan Carpenter:
> On Thu, Dec 06, 2012 at 06:18:02AM +0100, Stefan Hajnoczi wrote:
> > On Wed, Dec 5, 2012 at 7:44 PM, Dan Carpenter <dan...@or...> 
wrote:
> > > diff --git a/drivers/staging/line6/driver.c
> > > b/drivers/staging/line6/driver.c index 8a5d89e..884e0d8 100644
> > > --- a/drivers/staging/line6/driver.c
> > > +++ b/drivers/staging/line6/driver.c
> > > @@ -110,7 +110,7 @@ struct message {
> > > 
> > >  */
> > >  static void line6_data_received(struct urb *urb);
> > >  static int line6_send_raw_message_async_part(struct message *msg,
> > > 
> > > -                                            struct urb *urb);
> > > +                                            struct urb *urb, int free);
> > 
> > s/int/bool/
> > 
> > >  /*
> > >  
> > >         Start to listen on endpoint.
> > > 
> > > @@ -219,24 +219,42 @@ static void line6_async_request_sent(struct urb
> > > *urb)
> > > 
> > >                 usb_free_urb(urb);
> > >                 kfree(msg);
> > >         
> > >         } else
> > > 
> > > -               line6_send_raw_message_async_part(msg, urb);
> > > +               line6_send_raw_message_async_part(msg, urb, 0);
> > > +}
> > 
> > I'd add a bool free_buffer field to struct message and simply modify
> > line6_async_request_sent() to do:
> > 
> > if (msg->free_buffer)
> > 
> >          kfree(msg->buffer);
> > 
> > Then you don't need line6_async_request_sent_free_buffer() and
> > line6_send_raw_message_async_part() doesn't need to take a bool free
> > argument since struct message already contains that information.  It
> > would make the code simpler.
> 
> Yeah.  That's true.  I'll redo it.
Since two users reported this bug to me recently, I proposed a fix and asked 
them to test it. If it works for them, I'll prepare a patch against Stefan's 
repository. This is for your information only to avoid duplicate work in case 
you just wanted to pick this up again.

	Kind regards,
		Markus

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

[Mariusz K. <mk...@la...>]

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.

BTW. I think I found another bug ... this is minor but probably should
get fixed. If you rmmod before driver finishes initialisation it
is likely to get oops.

Try something like this:

# while true; do insmod line6usb.ko; sleep 0.1; rmmod line6usb; sleep 1; done

I tested something like 0.1 to 5 seconds values of the first sleep.

Regards,
-- 
Mariusz Kozlowski

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

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

Am Dienstag, 8. Januar 2013, 19:03:59 schrieb Mariusz Kozlowski:
> So please prepare final fix and I'll test it :) I think mainline needs
> that fix as well.
Ok, it's again in

https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/init

@Nagy: Could you also test this branch please? Mariusz reported similar 
problems as you did in December, so this version might work for you as well.

	Kind regards,
		Markus

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

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

[Mariusz K. <mk...@la...>]

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. 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.

So please prepare final fix and I'll test it :) I think mainline needs
that fix as well.

Thanks,
-- 
Mariusz Kozlowski

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

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

On Monday 07 January 2013 21:49:36 Mariusz Kozlowski wrote:
> Ok. So it looks like there is something wrong with this version, it gets
> stuck at POD startup step #1 and never recovers. Please take a look at
> attached line6-3.log.
That's actually what I expected, it repeats sending the version request over 
and over again. Moreover, you see another interesting thing: the first 16 
bytes of the channel dump response are missing, the message is therefore 
ignored, the channel dump request is correctly repeated, and the second 
attempt succeeds.

> 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.

	Kind regards,
		Markus

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

[Mariusz K. <mk...@la...>]

On Sun, Jan 06, 2013 at 11:13:46PM +0100, Markus Grabner wrote:
> Am Sonntag, 6. Januar 2013, 14:01:02 schrieben Sie:
> > I tested your changes with 1000ms delay (default), 2000ms and 3000ms. It
> > doesn't work but the log says first thing that is sent is version
> > request (twice) and in following packets it is sent three times in a
> > row. I think this is not correct (?).
> Let me answer your last question first:
> "line6usb 3-1:1.0" refers to the POD interface,
> "line6usb 3-1:1.1" refers to the Variax interface
> 
> The Variax interface doesn't respond unless a Variax guitar is connected via 
> the digital cable. I didn't find out how to get notified when a digital 
> connection is established, therefore the interface is "polled" by repeatedly 
> sending these requests. All messages sent to "line6usb 3-1:1.1" can be ignored 
> (at least I assume the Line6 engineers were smart enough to clearly separate 
> these two).

I see. Thanks for info.

> > Looking at the dump from working
> > version the first thing requested is channel dump. Then firmware version
> > is requested (only once). I think it might be a good idea to try to
> > follow that pattern. Also these repeated requests - is it a bug of some
> > sort or was that your intention?
> Let's say it's a simplification :-) The startup procedure is repeatedly 
> started every second until it is completely finished. I observed that 
> sometimes the response to the first channel dump request is incomplete, so it 
> has to be done again. However, if the firmware version request doesn't 
> succeed, the whole procedure is started over again. It's maybe not a bug, but 
> a mess, and I just created a branch where this is fixed:
> 
> https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/init
> 
> This will probably not solve the problem, but make it easier to debug. The 
> head revision also contains some more debugging stuff (including the "Variax 
> disable" patch, so let's continue debugging in this branch to avoid messing up 
> the trunk). I don't expect much news from this, but could you please create 
> another log just to verify that the new startup procedure works at least until 
> the version request?

Ok. So it looks like there is something wrong with this version, it gets
stuck at POD startup step #1 and never recovers. Please take a look at
attached line6-3.log.

> Some more ideas:
> 
> *) There is an alternative way to send data to the device, which is disabled 
> by default. It can be enabled in the driver options dialog (where you also 
> enabled the message debugging feature) by checking "raw data communication". 
> The driver then creates a special file "raw", and any byte sequence copied to 
> this file is immediately sent to the device. You can use the script 
> "create_links.pl" to create symlinks to the sysfs directories containing the 
> special files ("PODxtLive:0" is for the POD interface). Create a file 
> containing the version request byte sequence (F0 7E 7F 06 01 F7) with a hex 
> editor or similar tool, double-check its content, and copy it to "raw" (as 
> root). With message debugging enabled, you can see the message travelling to 
> the device, and the response travelling back (if any). The message takes a 
> slightly different code path inside the driver, which may or may not make a 
> difference.

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.

> *) It would be helpful to know the exact revision number up to which the 
> driver works for you. r611 is particularly interesting since work on the 
> startup procedure was finished there. If you do a binary search (similar to 
> git's bisect feature), you should prefer version numbers after which the 
> driver remained unchanged for some time since these are likely the most stable 
> ones.

I actually use git svn clone of line6linux trunk so git bisect is
available. After some fight ... oopses, etc I managed to narrow it down.
If the driver oopsed I marked revision 'bad'. If only variax interface was
registered I marked revision 'bad'.

Git bisect says first bad commit is r597. Not sure this is exactly _that_
commit as previous step was makred 'bad' because kernel oopsed after
insmod. But that must be around that revision +- a few revisions.

Regards,
-- 
Mariusz Kozlowski

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

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

Am Sonntag, 6. Januar 2013, 14:01:02 schrieben Sie:
> I tested your changes with 1000ms delay (default), 2000ms and 3000ms. It
> doesn't work but the log says first thing that is sent is version
> request (twice) and in following packets it is sent three times in a
> row. I think this is not correct (?).
Let me answer your last question first:
"line6usb 3-1:1.0" refers to the POD interface,
"line6usb 3-1:1.1" refers to the Variax interface

The Variax interface doesn't respond unless a Variax guitar is connected via 
the digital cable. I didn't find out how to get notified when a digital 
connection is established, therefore the interface is "polled" by repeatedly 
sending these requests. All messages sent to "line6usb 3-1:1.1" can be ignored 
(at least I assume the Line6 engineers were smart enough to clearly separate 
these two).

> Looking at the dump from working
> version the first thing requested is channel dump. Then firmware version
> is requested (only once). I think it might be a good idea to try to
> follow that pattern. Also these repeated requests - is it a bug of some
> sort or was that your intention?
Let's say it's a simplification :-) The startup procedure is repeatedly 
started every second until it is completely finished. I observed that 
sometimes the response to the first channel dump request is incomplete, so it 
has to be done again. However, if the firmware version request doesn't 
succeed, the whole procedure is started over again. It's maybe not a bug, but 
a mess, and I just created a branch where this is fixed:

https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/init

This will probably not solve the problem, but make it easier to debug. The 
head revision also contains some more debugging stuff (including the "Variax 
disable" patch, so let's continue debugging in this branch to avoid messing up 
the trunk). I don't expect much news from this, but could you please create 
another log just to verify that the new startup procedure works at least until 
the version request?

Some more ideas:

*) There is an alternative way to send data to the device, which is disabled 
by default. It can be enabled in the driver options dialog (where you also 
enabled the message debugging feature) by checking "raw data communication". 
The driver then creates a special file "raw", and any byte sequence copied to 
this file is immediately sent to the device. You can use the script 
"create_links.pl" to create symlinks to the sysfs directories containing the 
special files ("PODxtLive:0" is for the POD interface). Create a file 
containing the version request byte sequence (F0 7E 7F 06 01 F7) with a hex 
editor or similar tool, double-check its content, and copy it to "raw" (as 
root). With message debugging enabled, you can see the message travelling to 
the device, and the response travelling back (if any). The message takes a 
slightly different code path inside the driver, which may or may not make a 
difference.

*) It would be helpful to know the exact revision number up to which the 
driver works for you. r611 is particularly interesting since work on the 
startup procedure was finished there. If you do a binary search (similar to 
git's bisect feature), you should prefer version numbers after which the 
driver remained unchanged for some time since these are likely the most stable 
ones.

	Kind regards,
		Markus

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

[Mariusz K. <mk...@la...>]

On Sat, Jan 05, 2013 at 09:39:04PM +0100, Markus Grabner wrote:
> > Now I compared the two log files you provided, and the most obvious
> > difference seems to be the fact that in the new version the firmware
> > version request is sent immediately after the channel dump has been
> > received, while in the old version there was a delay of one second before
> > sending the request. Maybe the device needs some time after transmitting
> > data to the host before being able to receive data in firmware version
> > before 3.x, so I slightly changed the startup procedure to introduce a
> > delay of 500ms before sending the firmware version request. In the
> > (unlikely) case that the delay has to be more than 500ms, use "#define
> > POD_STARTUP_DELAY 2000" in pod.h for testing.
> > 
> > The changes are committed to the subversion trunk, so please try again with
> > the current head revision, and if it doesn't work, please send another log
> > file similar to the ones you sent before.
>
> BTW, if this doesn't solve the problem, there is one more thing you can try. 
> Maybe the communication with the Variax interface of the PODxt Live confuses 
> the device, which can be disabled by applying the attached patch.

No, sorry. That didn't help either. I see no difference with this patch.

Thanks,
-- 
Mariusz Kozlowski

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

[Mariusz K. <mk...@la...>]

On Sat, Jan 05, 2013 at 09:26:51PM +0100, Markus Grabner wrote:
> Am Samstag, 5. Januar 2013, 12:49:50 schrieb Mariusz Kozlowski:
> > The oldest version I could (easily) compile is svn rev 549 from July 2009
> > which matches with my emails. Around that time snd_card_create() was
> > introduced and current kernels don't even have snd_card_new(). I had to
> > add a few missing includes, convert err() to printk(KERN_ERR) and enable
> > DEBUG_MESSAGES.
> > 
> > I'm surprised but actually firmware version is detected correctly. The
> > dump looks a bit different. Maybe you can make something out of it.
> > From what I can tell firmware version is send in third 'packet'.
> Now I compared the two log files you provided, and the most obvious difference 
> seems to be the fact that in the new version the firmware version request is 
> sent immediately after the channel dump has been received, while in the old 
> version there was a delay of one second before sending the request. Maybe the 
> device needs some time after transmitting data to the host before being able 
> to receive data in firmware version before 3.x, so I slightly changed the 
> startup procedure to introduce a delay of 500ms before sending the firmware 
> version request. In the (unlikely) case that the delay has to be more than 
> 500ms, use "#define POD_STARTUP_DELAY 2000" in pod.h for testing.
> 
> The changes are committed to the subversion trunk, so please try again with 
> the current head revision, and if it doesn't work, please send another log 
> file similar to the ones you sent before.

I tested your changes with 1000ms delay (default), 2000ms and 3000ms. It
doesn't work but the log says first thing that is sent is version
request (twice) and in following packets it is sent three times in a
row. I think this is not correct (?). Looking at the dump from working
version the first thing requested is channel dump. Then firmware version
is requested (only once). I think it might be a good idea to try to
follow that pattern. Also these repeated requests - is it a bug of some
sort or was that your intention?

One more thing ... I can't figure out what is the difference between
3-1:1.0 and 3-1:1.1. It is shown both in log and in /sys/... path. In
/sys.. they are directories with different set of files. 3-1:1.1 is the
one that has the attribute files defined in the driver. I know it comes
from kobject name but ... maybe you could shed some light on this? I'm
not sure if this matters but in log you can see both of them used when
sending messages.

Please find log attached from current svn trunk with 2000ms delay on pod
startup.

Regards,
-- 
Mariusz Kozlowski

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

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

Am Samstag, 5. Januar 2013, 21:26:51 schrieb Markus Grabner:
> Am Samstag, 5. Januar 2013, 12:49:50 schrieb Mariusz Kozlowski:
> > The oldest version I could (easily) compile is svn rev 549 from July 2009
> > which matches with my emails. Around that time snd_card_create() was
> > introduced and current kernels don't even have snd_card_new(). I had to
> > add a few missing includes, convert err() to printk(KERN_ERR) and enable
> > DEBUG_MESSAGES.
> > 
> > I'm surprised but actually firmware version is detected correctly. The
> > dump looks a bit different. Maybe you can make something out of it.
> > From what I can tell firmware version is send in third 'packet'.
> 
> Now I compared the two log files you provided, and the most obvious
> difference seems to be the fact that in the new version the firmware
> version request is sent immediately after the channel dump has been
> received, while in the old version there was a delay of one second before
> sending the request. Maybe the device needs some time after transmitting
> data to the host before being able to receive data in firmware version
> before 3.x, so I slightly changed the startup procedure to introduce a
> delay of 500ms before sending the firmware version request. In the
> (unlikely) case that the delay has to be more than 500ms, use "#define
> POD_STARTUP_DELAY 2000" in pod.h for testing.
> 
> The changes are committed to the subversion trunk, so please try again with
> the current head revision, and if it doesn't work, please send another log
> file similar to the ones you sent before.
BTW, if this doesn't solve the problem, there is one more thing you can try. 
Maybe the communication with the Variax interface of the PODxt Live confuses 
the device, which can be disabled by applying the attached patch.

	Kind regards,
		Markus

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

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

Am Samstag, 5. Januar 2013, 12:49:50 schrieb Mariusz Kozlowski:
> The oldest version I could (easily) compile is svn rev 549 from July 2009
> which matches with my emails. Around that time snd_card_create() was
> introduced and current kernels don't even have snd_card_new(). I had to
> add a few missing includes, convert err() to printk(KERN_ERR) and enable
> DEBUG_MESSAGES.
> 
> I'm surprised but actually firmware version is detected correctly. The
> dump looks a bit different. Maybe you can make something out of it.
> From what I can tell firmware version is send in third 'packet'.
Now I compared the two log files you provided, and the most obvious difference 
seems to be the fact that in the new version the firmware version request is 
sent immediately after the channel dump has been received, while in the old 
version there was a delay of one second before sending the request. Maybe the 
device needs some time after transmitting data to the host before being able 
to receive data in firmware version before 3.x, so I slightly changed the 
startup procedure to introduce a delay of 500ms before sending the firmware 
version request. In the (unlikely) case that the delay has to be more than 
500ms, use "#define POD_STARTUP_DELAY 2000" in pod.h for testing.

The changes are committed to the subversion trunk, so please try again with 
the current head revision, and if it doesn't work, please send another log 
file similar to the ones you sent before.

	Thanks & kind regards,
		Markus

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

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

On Saturday 05 January 2013 12:49:50 Mariusz Kozlowski wrote:
> On Sat, Jan 05, 2013 at 01:55:23AM +0100, Markus Grabner wrote:
> > On Saturday 05 January 2013 00:13:22 Mariusz Kozlowski wrote:
> > > On Fri, Jan 04, 2013 at 07:53:20PM +0100, Markus Grabner wrote:
> > > > The system log should now contain all relevant messages sent to and
> > > > received from the device. You said that you observed periodic
> > > > requests,
> > > > so could you please extract all lines from the syslog from loading the
> > > > new driver until the periodic message has appeared several times, and
> > > > send this to me?
> > > 
> > > Ok. I modified the code with little printks here and there so please
> > > find both patch (based on svn rev 976) and log attached. Log begins when
> > > I
> > > insmod line6usb and ends when I rmmod line6usb. My changes are probably
> > > not
> > > needed at all as 'dump control messages' shows a lot.
> > 
> > Thanks for the data! I was hoping to see a different response to the
> > version request code (F0 7E 7F 06 01 F7), which could simply be detected,
> > but there doesn't seem to be any response at all. You mentioned that you
> > successfully used the driver 2 years ago, so it would be useful to have
> > the logs (with "dump control messages" enabled) of this old version. It
> > might be difficult, though, to compile it, since the Linux kernel has
> > changed a lot since then, and the Line6 driver changed accordingly. If
> > you succeed, please provide the logs and let me know whether the driver
> > special file "firmware_version" contains the correct value.
> 
> Ok so I checked my emails and last time I'm sure it worked was something
> around the time when line6usb driver was submitted to staging area (if you
> remember I suggested that to you and Greg AFAIR ;)).
To be honest, I didn't remember your name since then, but you are right, your 
proposal dates back to February 11th, 2009 :-)

> The oldest version I could (easily) compile is svn rev 549 from July 2009
> which matches with my emails. Around that time snd_card_create() was
> introduced and current kernels don't even have snd_card_new(). I had to
> add a few missing includes, convert err() to printk(KERN_ERR) and enable
> DEBUG_MESSAGES.
> 
> I'm surprised but actually firmware version is detected correctly. The
> dump looks a bit different. Maybe you can make something out of it.
> From what I can tell firmware version is send in third 'packet'.
I don't have the time right now to look at this in detail, but it looks very 
promising if you have an earlier version which does a correct firmware version 
request.

> > Another debugging option is to record the USB traffic under Windows with
> > the original Line6 driver by some USB logging software. Somewhere during
> > initialization, the firmware version number should be transmitted, though
> > this is somewhat of a needle-in-a-haystack problem.
> 
> Hm.. that can be tricky as I have old disks with windows somewhere which
> were not used for a few years. It's doable I think but first let me know
> if current linux dump is enough or not.
I guess the new dumps (or maybe some additional ones with the same driver 
version) will be enough. I will investigate this in the evening.

> > Do you have a Variax guitar connected to the PODxt Live via the Variax
> > digital cable? Don't know if it is relevant, just to make sure we have
> > the same setup.
> No. It is an electric guitar connected via INPUT jack.
Ok.

> Please find dump and diff based on 549 attached. The kernel I compile
> against is 3.5.0-21-generic from ubuntu.
Thanks! Yesterday I tried r598, which crashed the machine after a few seconds 
:-(, then I gave up. r549 with your patch compiles with kernel 3.4.11, I will 
test it later with my PODxt Live.

	Kind regards,
		Markus

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

[Mariusz K. <mk...@la...>]

On Sat, Jan 05, 2013 at 01:55:23AM +0100, Markus Grabner wrote:
> On Saturday 05 January 2013 00:13:22 Mariusz Kozlowski wrote:
> > On Fri, Jan 04, 2013 at 07:53:20PM +0100, Markus Grabner wrote:
> > > The system log should now contain all relevant messages sent to and
> > > received from the device. You said that you observed periodic requests,
> > > so could you please extract all lines from the syslog from loading the
> > > new driver until the periodic message has appeared several times, and
> > > send this to me?
> > 
> > Ok. I modified the code with little printks here and there so please
> > find both patch (based on svn rev 976) and log attached. Log begins when I
> > insmod line6usb and ends when I rmmod line6usb. My changes are probably not
> > needed at all as 'dump control messages' shows a lot.
> Thanks for the data! I was hoping to see a different response to the version 
> request code (F0 7E 7F 06 01 F7), which could simply be detected, but there 
> doesn't seem to be any response at all. You mentioned that you successfully 
> used the driver 2 years ago, so it would be useful to have the logs (with 
> "dump control messages" enabled) of this old version. It might be difficult, 
> though, to compile it, since the Linux kernel has changed a lot since then, 
> and the Line6 driver changed accordingly. If you succeed, please provide the 
> logs and let me know whether the driver special file "firmware_version" 
> contains the correct value.

Ok so I checked my emails and last time I'm sure it worked was something around
the time when line6usb driver was submitted to staging area (if you
remember I suggested that to you and Greg AFAIR ;)).

The oldest version I could (easily) compile is svn rev 549 from July 2009 which
matches with my emails. Around that time snd_card_create() was
introduced and current kernels don't even have snd_card_new(). I had to
add a few missing includes, convert err() to printk(KERN_ERR) and enable
DEBUG_MESSAGES.

I'm surprised but actually firmware version is detected correctly. The
dump looks a bit different. Maybe you can make something out of it.
>From what I can tell firmware version is send in third 'packet'.

> Another debugging option is to record the USB traffic under Windows with the 
> original Line6 driver by some USB logging software. Somewhere during 
> initialization, the firmware version number should be transmitted, though this 
> is somewhat of a needle-in-a-haystack problem.

Hm.. that can be tricky as I have old disks with windows somewhere which
were not used for a few years. It's doable I think but first let me know
if current linux dump is enough or not.

> Do you have a Variax guitar connected to the PODxt Live via the Variax digital 
> cable? Don't know if it is relevant, just to make sure we have the same setup.

No. It is an electric guitar connected via INPUT jack.

Please find dump and diff based on 549 attached. The kernel I compile
against is 3.5.0-21-generic from ubuntu.

Regards,
-- 
Mariusz Kozlowski

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

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

On Saturday 05 January 2013 00:13:22 Mariusz Kozlowski wrote:
> On Fri, Jan 04, 2013 at 07:53:20PM +0100, Markus Grabner wrote:
> > The system log should now contain all relevant messages sent to and
> > received from the device. You said that you observed periodic requests,
> > so could you please extract all lines from the syslog from loading the
> > new driver until the periodic message has appeared several times, and
> > send this to me?
> 
> Ok. I modified the code with little printks here and there so please
> find both patch (based on svn rev 976) and log attached. Log begins when I
> insmod line6usb and ends when I rmmod line6usb. My changes are probably not
> needed at all as 'dump control messages' shows a lot.
Thanks for the data! I was hoping to see a different response to the version 
request code (F0 7E 7F 06 01 F7), which could simply be detected, but there 
doesn't seem to be any response at all. You mentioned that you successfully 
used the driver 2 years ago, so it would be useful to have the logs (with 
"dump control messages" enabled) of this old version. It might be difficult, 
though, to compile it, since the Linux kernel has changed a lot since then, 
and the Line6 driver changed accordingly. If you succeed, please provide the 
logs and let me know whether the driver special file "firmware_version" 
contains the correct value.

Another debugging option is to record the USB traffic under Windows with the 
original Line6 driver by some USB logging software. Somewhere during 
initialization, the firmware version number should be transmitted, though this 
is somewhat of a needle-in-a-haystack problem.

Do you have a Variax guitar connected to the PODxt Live via the Variax digital 
cable? Don't know if it is relevant, just to make sure we have the same setup.

	Kind regards,
		Markus

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

[Mariusz K. <mk...@la...>]

On Fri, Jan 04, 2013 at 07:53:20PM +0100, Markus Grabner wrote:
> On Friday 04 January 2013 13:18:10 you wrote:
> > On Thu, Jan 03, 2013 at 09:09:51PM +0100, Markus Grabner wrote:
> > > This is how it was done in an earlier version of the driver, but it turned
> > > out to be unreliable, therefore I introduced the delayed startup
> > > procedure. Can you please try to find out which of the pod_startup<n>
> > > (with n = 1...5) functions are called on your system? From the symptoms
> > > you describe I believe that 1, 2, and 3 are executed, but 4 and 5 are
> > > not. It seems that there is no response to the request for the firmware
> > > version submitted in pod_startup3.
> > Yes, you are correct. I can see pod_startup1(), then 2, and then it gets
> > stuck in pod_startup3(). It keeps firing up periodically requesting the
> > firmware but response matches 'line6_midi_id' so it never hits 'else if'
> > part.
> > > Can you please let me know the firmware version of your PODxt Live (you
> > > obviously can't find it out with the Linux driver, but it's displayed on
> > > the last page of the device's system menu)?
> > 
> > That's what it says:
> > 
> > POD XT LIVE v2.14
> Ok, I have v3.01 or something, so this might indeed make a difference. 
> Unfortunatley I didn't note when I updated my POD, so I can't verify if I 
> changed the startup procedure roughly at the same time. Nevertheless, please 
> *don't* upgrade right now since I believe this isn't too hard to fix.

That was my thought also. I could upgrade to v3.01 but then there is a
chance I could be unable to reproduce that issue. Telling people that
they should have firmware v3.01 is acceptable IMO but better to have the
fix in the driver.

> > If you have any ideas how to fix this or patches to test let me know.
> I'd like to see the messages exchanged on your system. Can please do the 
> following:
> *) enter "make xconfig" in the svn working copy of the Line6 driver sources
> *) open the Line6 driver options (menu "Edit->Find...", then enter "line6")
> *) select "dump control messages"
> *) save the configuration, compile and install the new Line6 kernel module

Done.

> The system log should now contain all relevant messages sent to and received 
> from the device. You said that you observed periodic requests, so could you 
> please extract all lines from the syslog from loading the new driver until the 
> periodic message has appeared several times, and send this to me?

Ok. I modified the code with little printks here and there so please
find both patch (based on svn rev 976) and log attached. Log begins when I insmod
line6usb and ends when I rmmod line6usb. My changes are probably not
needed at all as 'dump control messages' shows a lot.

> 	Thanks & kind regards,
> 		Markus
> 
> 
> P.S.: I forward this message to the Line6 mailing list since a similar issue 
> (driver module loaded, but no audio I/O) has just been raised there, so others 
> might benefit as well if we find a solution. May I suggest that you subscribe 
> to this list, and we continue the discussion on the mailing list? Here is the 
> subscription URL:

Sure. Done.

Regards,
-- 
Mariusz Kozlowski

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

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

On Friday 04 January 2013 13:18:10 you wrote:
> On Thu, Jan 03, 2013 at 09:09:51PM +0100, Markus Grabner wrote:
> > This is how it was done in an earlier version of the driver, but it turned
> > out to be unreliable, therefore I introduced the delayed startup
> > procedure. Can you please try to find out which of the pod_startup<n>
> > (with n = 1...5) functions are called on your system? From the symptoms
> > you describe I believe that 1, 2, and 3 are executed, but 4 and 5 are
> > not. It seems that there is no response to the request for the firmware
> > version submitted in pod_startup3.
> Yes, you are correct. I can see pod_startup1(), then 2, and then it gets
> stuck in pod_startup3(). It keeps firing up periodically requesting the
> firmware but response matches 'line6_midi_id' so it never hits 'else if'
> part.
> > Can you please let me know the firmware version of your PODxt Live (you
> > obviously can't find it out with the Linux driver, but it's displayed on
> > the last page of the device's system menu)?
> 
> That's what it says:
> 
> POD XT LIVE v2.14
Ok, I have v3.01 or something, so this might indeed make a difference. 
Unfortunatley I didn't note when I updated my POD, so I can't verify if I 
changed the startup procedure roughly at the same time. Nevertheless, please 
*don't* upgrade right now since I believe this isn't too hard to fix.

> If you have any ideas how to fix this or patches to test let me know.
I'd like to see the messages exchanged on your system. Can please do the 
following:
*) enter "make xconfig" in the svn working copy of the Line6 driver sources
*) open the Line6 driver options (menu "Edit->Find...", then enter "line6")
*) select "dump control messages"
*) save the configuration, compile and install the new Line6 kernel module

The system log should now contain all relevant messages sent to and received 
from the device. You said that you observed periodic requests, so could you 
please extract all lines from the syslog from loading the new driver until the 
periodic message has appeared several times, and send this to me?

	Thanks & kind regards,
		Markus


P.S.: I forward this message to the Line6 mailing list since a similar issue 
(driver module loaded, but no audio I/O) has just been raised there, so others 
might benefit as well if we find a solution. May I suggest that you subscribe 
to this list, and we continue the discussion on the mailing list? Here is the 
subscription URL:

https://lists.sourceforge.net/lists/listinfo/line6linux-user