On Wed, Jun 4, 2014 at 5:49 AM, Patrick Chase <[email protected]> wrote: > > On 05/28/2014 11:58 AM, Stefan Hajnoczi wrote: >> >> On Wed, May 28, 2014 at 5:51 PM, Patrick Chase <[email protected]> wrote: >>> >>> Hi Stephan. USB looks fine, but it's not available as a soundcard. >>> Details on my troubleshooting is in the AV Linux support forum here: >>> http://www.remastersys.com/forums/index.php?topic=3291 Bottom-line is that >>> the drivers are there, they load properly, the USB device attaches and >>> disconnects as expected, but the device does not show up as a soundcard and >>> is not available in alsamixer. I suspect either a kernel support issue or an >>> alsa support issue (i.e. drivers OK, but not supported). It works >>> out-of-the-box with the included kernel module in Mint 13 (kernel 3.2.0-23) >>> and Ubuntu Studio 12.04 (all in 64-bit fwiw). I can't remember which kernel >>> AV Linux uses but can check. I had planned on trying alternate kernels >>> anyway (to get this working). Thanks in advance for any guidance you can >>> provide. >> >> Hard to say what the issue is. Personally, I don't use the svn source >> tree. Instead I check out the linux.git release tag for the >> appropriate kernel version (check uname -r) and compile the module. >> >> That way I know the driver is running on the kernel version it was >> intended for. The downside is that you don't get fixes that were >> committed in svn after the kernel release. But since development is >> not very active anyway, that's only an issue if you are using a very >> old kernel version. >> >> Anyway, if you want to get to the bottom of it, try adding printk() >> calls or use perf-probe(1) to see which functions in the driver are >> getting called. If it doesn't register an ALSA sound card then >> something must be going pretty wrong during initialization. >> > > Hi Stefan. I can tell you that AV Linux 6.02 is using kernel 3.6.11.2. I bet > if I found an old AV Linux version that used a 3.2 kernel it would work.
If you have a working and a non-working version, then the most straightforward way to solve the mystery is bisection. http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search https://www.kernel.org/pub/software/scm/git/docs/git-bisect.html git-bisect(1) performs a binary search on the commit history between two commits. At each step in the search you compile and test the kernel. In the end it leaves you at the commit when the bug was introduced. There are plenty of tutorials online about using git-bisect(1). It can be time-consuming due to the kernel compilation time, but it will identify the exact commit where the bug was introduced. Good luck! Stefan ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Line6linux-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/line6linux-user
