Hi there!
I received my pod xt today and was very excited to try it and test the line6usb driver.
So far I got everything working fine: alsa, pulse, jackd, ardour.
I use the pod as input and output device and even the sample rate issue seems to be of no problem.
However, I already got 3 freezes today which is something that should not happen, especially on a system considered stable.
Can you guide me to tracking down the reason for those freezes?
What is your experience with the stability of the line6usb driver?
It appears that the freezes occurred while I was playing the guitar and using the (connected) floorboard.
I did not record while this was happening nor was I playing back sound from the computer.
Any help is much appreciated!
Thanks,
Dan
P.S. Keep up the good work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh btw., I am using the currect svn version (Rev 601) of the driver, compiled from sources on a Ubuntu 9.10 machine with stock 2.6.31 kernel (no rt) and alsa 1.0.20 and jack 0.116.1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did some more testing and
1. the good news is, everything seems to work fine with my thinkpad running Debian lenny and line6usb 0.8.1 !
2. On my other machine deinstalling pulseaudio seems to have improved stability of the driver, too.
3. However, hibernation doesn't work anymore using either 0.8.1 or 0.9 (R601). The screen gets black but from there nothing happens so I have to reboot. Only workaround I found is to unload the line6usb driver before hibernation (which requires killing all audio applications beforehand). Interesting is that I can hibernate on the Thinkpad without unloading the driver.
4. Debian squueze and Ubuntu 9.10 often crash when I try to unload line6usb 0.9 (R601). 0.8.1 unloads fine.
5. The kernel gives me some warnings. These repeat periodically every 2 seconds as long as line6usb (0.8.1 or 0.9) are loaded:
Could you please tell me exactly which device you are using (i.e., the output of "lsusb | grep Line6")? And did you try the most recent driver version (R604)? I made some changes which might be related to the periodically repeating messages. BTW, the snippet from your log file is cut off at the point where it becomes interesting :-), is there more information available below " Call Trace:"?
Kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply.
I do have a PodXT (no pro, no live).
The output of lsusb is:
Bus 003 Device 005: ID 0e41:5044 Line6, Inc. PODxt
I tried the R605 version of the driver however the problem persits.
I also noted a system freeze, probably caused by an un-killable jackd running with the pod as audio interface and consuming nearly 99% cpu time.
There were no more lines in that particular call trace. However I found a line which is often followed by the previously posted trace in one of the system logs:
[ ? start_kernel+0x30c/0x311
Any ideas?
Best regards,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do the periodic warnings (your issue #5) still appear with R605? If they do, you can try the debug version at "https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/debug". It is identical to the "trunk" driver, but outputs a (somewhat) detailled trace in the syslog, which might indicate where the warning is triggered.
It would be extremely helpful if you could find out the exact driver revision at which problem #4 appears for the first time. This is straightforward, although quite tedious: pick any revision somewhere in the middle between 547 (0.8.1 release) and the current revision 605. If that revision has the same problem, try again with a lower revision, otherwise with a higher one, and so.
Kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The periodic warnings are always there, from R547 to R606.
However, R547 seems much more stable on my system.
I am using the debug version of R606 right now and the call trace remains the same for most of the time.
However, I also encountered the following trace:
> ? __scsi_put_command+0x38/0x51
These are not (obviously) related to the Line6 driver - no idea where they come from…
> Apr 17 15:41:44 mini kernel: BUG: scheduling while atomic: ksoftirqd/0/4/0x10000100
This one is very interesting, and fortunately the syslog tells us where it happens:
> Apr 17 15:41:44 mini kernel: ? line6_alloc_sysex_buffer+0x1b/0x6c
It looks like you are running out of physical memory on your machine while the Line6 device is being used. I never encountered this bug since I have 8GB of RAM in my development machine :-) I tried to blindly fix this, though I can't confirm it since - as I said - I didn't have the problem before. Could you please try the most recent driver version (the proposed fix is both in the trunk and in the debug branch)?
Thanks & kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A first remark on the current driver version:
The error message did not go away. I start thinking this is rather caused by the kernel than line6usb, although it's weird that it only occurs if the driver is loaded. But here is something similar: http://www.mail-archive.com/debian-kernel@lists.debian.org/msg51554.html. A lot of people seem to receive similar call traces wit 2.6.30+ kernels.
What I noticed is that with the current driver versions sometimes alsa fail to detect the pod as soundcard. So it is not listed in /proc/asound/cards although line6usb is loaded. Reloading (rmmod + modprobe) the driver doesn't help but switching back to 0.8.1 resolves this issue.
I also noticed that sometimes the sound from the pod starts lagging including the sound from the guitar. And it even happend to me that all of a sudden the current channel of the pod got changed. Don't know if this is caused by the driver or just a malfunctioning pod..
Thanks!
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just reproduced the channel switching thing a few times with loaded line6usb but couldnt reproduce it with unloaded line6usb.
To reproduce it selected a high gain amp model and produced some pinch harmonics and the pod would always switch the channel 3A. Could this be an issue with clipping detection/handling?
Driver version was 0.8.1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> What I noticed is that with the current driver versions sometimes alsa fail to detect the pod as soundcard.
I modified the startup procedure to only create ALSA entries after the device is fully initialized, which takes a couple of seconds. So if you check ALSA soundcards immediately after inserting the line6usb module, your Line6 device won't show up. Make sure to wait 5-10 seconds. Another reason could be a different startup behaviour of the PODxt. In any case, it would be useful to see the USB messages travelling over the bus. The driver contains debugging code to dump these messages to the syslog. Please use the debug branch (see message #6 above) at revision >= 616 and proceed as follows:
*) type "make xconfig"
*) search for "Line6" (menu "Edit->Find")
*) check the box "dump control messages"
*) save the configuration and exit the configuration tool
*) recompile and reinsert the driver
Please post your syslog from inserting the driver until ~10 seconds later. Moreover, if the driver is responsible for switching the channel, the corresponding messages should also show up in the syslog, which is best observed in a "live view" of the log file (i.e., "tail -f /var/log/messages"). If you find these codes in the syslog, please post them as well.
BTW, in which timezone are you located? It's probably more efficient to have a skype chat.
Kind regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess that would be really easier :)
My timezone is GMT+1, so we should be able to find a common spot :)
Maybe Friday after 18.00 or Saturday afternoon? Unfortunately I dont have a headset (but my soundcard's mic-in is not working anyways) so I will have text chat.
I ran into some troubles following your xconfig guide.
First, the directory $(KDIR)/source/$(SUBDIR) does not exist, so I created it.
However make xconfig still fails with this error message:
make: Entering directory `/usr/src/linux-headers-2.6.32-trunk-686'
/usr/src/linux-headers-2.6.32-trunk-common/scripts/Makefile.build:44: /usr/src/linux-headers-2.6.32-trunk-common/scripts/basic/Makefile: No such file or directory
seems like it is looking for a makefile in all subfolders of scripts/basic however there aren't any..
Best regards,
Dan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh and btw. I waited for almost 5 minutes and the device did (and right now does) not show up in aplay -l or /proc/asound/cards.
This is what dmesg shows:
line6usb driver version 0.9.0 (revision 616M)
line6usb 2-7:1.0: Line6 PODxt found
line6usb 2-7:1.0: Line6 PODxt now attached
Line6 device 0: PODxt:0
Line6 device 1: (not used)
Line6 device 2: (not used)
Line6 device 3: (not used)
Line6 device 4: (not used)
Line6 device 5: (not used)
Line6 device 6: (not used)
Line6 device 7: (not used)
usbcore: registered new interface driver line6usb
(why is there no edit function for posts ? )
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> I ran into some troubles following your xconfig guide.
It seems your Linux distro has other conventions for the location of Linux kernel headers and sources :-( I'm using openSUSE-11.2, which distro are you using?
You should at least have the directory "/lib/modules/$(uname -r)" containing the modules for the running kernel. Can you locate the corresponding sources and objects on your system? For me, these are "/usr/src/linux-2.6.31.12-0.2" and "/usr/src/linux-2.6.31.12-0.2-obj/x86_64/desktop", respectively.
Do you have a skype account? Would make it a lot easier…
I am using debian squeeze.
There is a lib/modules/2.6.32-trunk-686/ and link called sources pointing to /usr/src/linux-headers-2.6.32-trunk-common
The kernel sources a located in /usr/src/linux-source-2.6.32.
The headers in /usr/src/linux-headers-2.6.32-trunk-686 (arch dependent) and /usr/src/linux-headers-2.6.32-trunk-common (arch independent).
The kernel *.ko files are located in /lib/modules/2.6.32-trunk-686/kernel.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there!
I received my pod xt today and was very excited to try it and test the line6usb driver.
So far I got everything working fine: alsa, pulse, jackd, ardour.
I use the pod as input and output device and even the sample rate issue seems to be of no problem.
However, I already got 3 freezes today which is something that should not happen, especially on a system considered stable.
Can you guide me to tracking down the reason for those freezes?
What is your experience with the stability of the line6usb driver?
It appears that the freezes occurred while I was playing the guitar and using the (connected) floorboard.
I did not record while this was happening nor was I playing back sound from the computer.
Any help is much appreciated!
Thanks,
Dan
P.S. Keep up the good work!
Oh btw., I am using the currect svn version (Rev 601) of the driver, compiled from sources on a Ubuntu 9.10 machine with stock 2.6.31 kernel (no rt) and alsa 1.0.20 and jack 0.116.1
Hi again,
I did some more testing and
1. the good news is, everything seems to work fine with my thinkpad running Debian lenny and line6usb 0.8.1 !
2. On my other machine deinstalling pulseaudio seems to have improved stability of the driver, too.
3. However, hibernation doesn't work anymore using either 0.8.1 or 0.9 (R601). The screen gets black but from there nothing happens so I have to reboot. Only workaround I found is to unload the line6usb driver before hibernation (which requires killing all audio applications beforehand). Interesting is that I can hibernate on the Thinkpad without unloading the driver.
4. Debian squueze and Ubuntu 9.10 often crash when I try to unload line6usb 0.9 (R601). 0.8.1 unloads fine.
5. The kernel gives me some warnings. These repeat periodically every 2 seconds as long as line6usb (0.8.1 or 0.9) are loaded:
If there is anything I can do to help you debugging this just let me know!
Could you please tell me exactly which device you are using (i.e., the output of "lsusb | grep Line6")? And did you try the most recent driver version (R604)? I made some changes which might be related to the periodically repeating messages. BTW, the snippet from your log file is cut off at the point where it becomes interesting :-), is there more information available below " Call Trace:"?
Kind regards,
Markus
Hi Markus!
Thanks for your reply.
I do have a PodXT (no pro, no live).
The output of lsusb is:
Bus 003 Device 005: ID 0e41:5044 Line6, Inc. PODxt
I tried the R605 version of the driver however the problem persits.
I also noted a system freeze, probably caused by an un-killable jackd running with the pod as audio interface and consuming nearly 99% cpu time.
There were no more lines in that particular call trace. However I found a line which is often followed by the previously posted trace in one of the system logs:
[ ? start_kernel+0x30c/0x311
Any ideas?
Best regards,
Dan
Do the periodic warnings (your issue #5) still appear with R605? If they do, you can try the debug version at "https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/debug". It is identical to the "trunk" driver, but outputs a (somewhat) detailled trace in the syslog, which might indicate where the warning is triggered.
It would be extremely helpful if you could find out the exact driver revision at which problem #4 appears for the first time. This is straightforward, although quite tedious: pick any revision somewhere in the middle between 547 (0.8.1 release) and the current revision 605. If that revision has the same problem, try again with a lower revision, otherwise with a higher one, and so.
Kind regards,
Markus
The periodic warnings are always there, from R547 to R606.
However, R547 seems much more stable on my system.
I am using the debug version of R606 right now and the call trace remains the same for most of the time.
However, I also encountered the following trace:
? __scsi_put_command+0x38/0x51
? scsi_next_command+0x1e/0x2f
? scsi_io_completion+0x373/0x394
? scsi_finish_command+0xaa/0xc2
? blk_done_softirq+0x53/0x5f
? __do_softirq+0xaa/0x151
? do_softirq+0x31/0x3c
? irq_exit+0x26/0x58
? do_IRQ+0x78/0x89
? common_interrupt+0x30/0x38
? acpi_idle_enter_bm+0x246/0x281
? cpuidle_idle_call+0x68/0xbb
? cpu_idle+0x89/0xa5
? start_kernel+0x30c/0x311
Although it doesn't look related to line6usb imo, I have only seen those error messages when line6usb is loaded.
Here is another one (likely more related):
Apr 17 15:41:44 mini kernel: BUG: scheduling while atomic: ksoftirqd/0/4/0x10000100
Apr 17 15:41:44 mini kernel: Modules linked in: line6usb snd_seq_dummy fuse snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq_midi snd_pcm_oss snd_rawmidi snd_mixer_oss snd_seq_midi_event snd_seq snd_pcm btusb bluetooth nvidia(P) snd_timer rfkill agpgart snd_seq_device i2c_nforce2 snd i2c_core shpchp soundcore snd_page_alloc pci_hotplug applesmc led_class input_polldev evdev pcspkr processor hid_apple ext3 jbd mbcache usbhid hid sg sr_mod sd_mod cdrom crc_t10dif ide_pci_generic ide_core ata_generic ssb mmc_core ahci pcmcia ohci_hcd firewire_ohci firewire_core crc_itu_t pcmcia_core forcedeth libata button scsi_mod ehci_hcd usbcore nls_base thermal fan thermal_sys
Apr 17 15:41:44 mini kernel: Pid: 4, comm: ksoftirqd/0 Tainted: P W 2.6.32-trunk-686 #1
Apr 17 15:41:44 mini kernel: Call Trace:
Apr 17 15:41:44 mini kernel: ? schedule+0x7e/0x7dc
Apr 17 15:41:44 mini kernel: ? update_curr+0x106/0x1b3
Apr 17 15:41:44 mini kernel: ? update_curr+0x106/0x1b3
Apr 17 15:41:44 mini kernel: ? _cond_resched+0x25/0x3c
Apr 17 15:41:44 mini kernel: ? __kmalloc+0x8e/0x128
Apr 17 15:41:44 mini kernel: ? line6_alloc_sysex_buffer+0x1b/0x6c
Apr 17 15:41:44 mini kernel: ? line6_alloc_sysex_buffer+0x1b/0x6c
Apr 17 15:41:44 mini kernel: ? pod_startup_timeout+0x0/0x8a
Apr 17 15:41:44 mini kernel: ? pod_startup_timeout+0x53/0x8a
Apr 17 15:41:44 mini kernel: ? run_timer_softirq+0x16a/0x1eb
Apr 17 15:41:44 mini kernel: ? __do_softirq+0xaa/0x151
Apr 17 15:41:44 mini kernel: ? do_softirq+0x31/0x3c
Apr 17 15:41:44 mini kernel: ? ksoftirqd+0x44/0xa5
Apr 17 15:41:44 mini kernel: ? ksoftirqd+0x0/0xa5
Apr 17 15:41:44 mini kernel: ? kthread+0x61/0x66
Apr 17 15:41:44 mini kernel: ? kthread+0x0/0x66
Apr 17 15:41:44 mini kernel: ? kernel_thread_helper+0x7/0x10
I first thought it might be an irq issue so I tried another port usb port but without success.
> ? __scsi_put_command+0x38/0x51
These are not (obviously) related to the Line6 driver - no idea where they come from…
> Apr 17 15:41:44 mini kernel: BUG: scheduling while atomic: ksoftirqd/0/4/0x10000100
This one is very interesting, and fortunately the syslog tells us where it happens:
> Apr 17 15:41:44 mini kernel: ? line6_alloc_sysex_buffer+0x1b/0x6c
It looks like you are running out of physical memory on your machine while the Line6 device is being used. I never encountered this bug since I have 8GB of RAM in my development machine :-) I tried to blindly fix this, though I can't confirm it since - as I said - I didn't have the problem before. Could you please try the most recent driver version (the proposed fix is both in the trunk and in the debug branch)?
Thanks & kind regards,
Markus
BTW, I just noticed another thing in your syslog:
> Apr 17 15:41:44 mini kernel: ? pod_startup_timeout+0x0/0x8a
There is no "pod_startup_timeout" in the current driver version, so you are not using the most recent version. Can you please run the command
grep "line6usb driver version" /var/log/messages
to identify the exact version of the Line6 driver loaded on your system?
Thanks & kind regards,
Markus
Hi Markus!
A first remark on the current driver version:
The error message did not go away. I start thinking this is rather caused by the kernel than line6usb, although it's weird that it only occurs if the driver is loaded. But here is something similar: http://www.mail-archive.com/debian-kernel@lists.debian.org/msg51554.html. A lot of people seem to receive similar call traces wit 2.6.30+ kernels.
What I noticed is that with the current driver versions sometimes alsa fail to detect the pod as soundcard. So it is not listed in /proc/asound/cards although line6usb is loaded. Reloading (rmmod + modprobe) the driver doesn't help but switching back to 0.8.1 resolves this issue.
I also noticed that sometimes the sound from the pod starts lagging including the sound from the guitar. And it even happend to me that all of a sudden the current channel of the pod got changed. Don't know if this is caused by the driver or just a malfunctioning pod..
Thanks!
Dan
Just reproduced the channel switching thing a few times with loaded line6usb but couldnt reproduce it with unloaded line6usb.
To reproduce it selected a high gain amp model and produced some pinch harmonics and the pod would always switch the channel 3A. Could this be an issue with clipping detection/handling?
Driver version was 0.8.1
> What I noticed is that with the current driver versions sometimes alsa fail to detect the pod as soundcard.
I modified the startup procedure to only create ALSA entries after the device is fully initialized, which takes a couple of seconds. So if you check ALSA soundcards immediately after inserting the line6usb module, your Line6 device won't show up. Make sure to wait 5-10 seconds. Another reason could be a different startup behaviour of the PODxt. In any case, it would be useful to see the USB messages travelling over the bus. The driver contains debugging code to dump these messages to the syslog. Please use the debug branch (see message #6 above) at revision >= 616 and proceed as follows:
*) type "make xconfig"
*) search for "Line6" (menu "Edit->Find")
*) check the box "dump control messages"
*) save the configuration and exit the configuration tool
*) recompile and reinsert the driver
Please post your syslog from inserting the driver until ~10 seconds later. Moreover, if the driver is responsible for switching the channel, the corresponding messages should also show up in the syslog, which is best observed in a "live view" of the log file (i.e., "tail -f /var/log/messages"). If you find these codes in the syslog, please post them as well.
BTW, in which timezone are you located? It's probably more efficient to have a skype chat.
Kind regards,
Markus
Hi!
I guess that would be really easier :)
My timezone is GMT+1, so we should be able to find a common spot :)
Maybe Friday after 18.00 or Saturday afternoon? Unfortunately I dont have a headset (but my soundcard's mic-in is not working anyways) so I will have text chat.
I ran into some troubles following your xconfig guide.
First, the directory $(KDIR)/source/$(SUBDIR) does not exist, so I created it.
However make xconfig still fails with this error message:
make: Entering directory `/usr/src/linux-headers-2.6.32-trunk-686'
/usr/src/linux-headers-2.6.32-trunk-common/scripts/Makefile.build:44: /usr/src/linux-headers-2.6.32-trunk-common/scripts/basic/Makefile: No such file or directory
seems like it is looking for a makefile in all subfolders of scripts/basic however there aren't any..
Best regards,
Dan
Oh and btw. I waited for almost 5 minutes and the device did (and right now does) not show up in aplay -l or /proc/asound/cards.
This is what dmesg shows:
line6usb driver version 0.9.0 (revision 616M)
line6usb 2-7:1.0: Line6 PODxt found
line6usb 2-7:1.0: Line6 PODxt now attached
Line6 device 0: PODxt:0
Line6 device 1: (not used)
Line6 device 2: (not used)
Line6 device 3: (not used)
Line6 device 4: (not used)
Line6 device 5: (not used)
Line6 device 6: (not used)
Line6 device 7: (not used)
usbcore: registered new interface driver line6usb
(why is there no edit function for posts ? )
> I ran into some troubles following your xconfig guide.
It seems your Linux distro has other conventions for the location of Linux kernel headers and sources :-( I'm using openSUSE-11.2, which distro are you using?
You should at least have the directory "/lib/modules/$(uname -r)" containing the modules for the running kernel. Can you locate the corresponding sources and objects on your system? For me, these are "/usr/src/linux-2.6.31.12-0.2" and "/usr/src/linux-2.6.31.12-0.2-obj/x86_64/desktop", respectively.
> This is what dmesg shows:
Are you sure that this is the "debug" driver (from "https://line6linux.svn.sourceforge.net/svnroot/line6linux/driver/branches/debug")? It should be much more verbose.
Kind regards,
Markus
Do you have a skype account? Would make it a lot easier…
I am using debian squeeze.
There is a lib/modules/2.6.32-trunk-686/ and link called sources pointing to /usr/src/linux-headers-2.6.32-trunk-common
The kernel sources a located in /usr/src/linux-source-2.6.32.
The headers in /usr/src/linux-headers-2.6.32-trunk-686 (arch dependent) and /usr/src/linux-headers-2.6.32-trunk-common (arch independent).
The kernel *.ko files are located in /lib/modules/2.6.32-trunk-686/kernel.
> Do you have a skype account?
I sent it to your sourceforge email address, did you get it?
Kind regards,
Markus