Re: [Line6linux-user] HD300 and Jack

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

On Wed, Jun 4, 2014 at 5:49 AM, Patrick Chase <pm...@ve...> wrote:
>
> On 05/28/2014 11:58 AM, Stefan Hajnoczi wrote:
>>
>> On Wed, May 28, 2014 at 5:51 PM, Patrick Chase <pm...@ve...> 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