Re: [FFADO-user] Problem getting ESI QuataFire 610 recognized by jack

[Jonathan W. <jw...@ju...>]

Hi Jean-Christophe

I have only a limited opportunity to provide feedback this week.  Here goes
something.

> Ok, I get my hands on the machine again.
> /usr/bin/jackd -p 128 -R -P 60 -d firewire -n 3 -r 48000 -p 256 -v 6 2>&1 |tee jackerror6.txt
> 
> See attached file.

I will later. :-)

> I can't Ctrl-C from the terminal when jackd hangs.
> 
> What I see from ps auxwf :
> root       766  0.0  0.1  49956  2872 ?        Ss   Jan18   0:00 /usr/sbin/sshd -D
> root      1956  0.0  0.1  90160  3940 ?        Ss   02:21   0:00  \_ sshd: djedg [priv]  
> djedg     2146  0.0  0.0  90160  1808 ?        S    02:21   0:00  |   \_ sshd: djedg@pts/0   
> djedg     2147  0.2  0.3  31052  7960 pts/0    Ss   02:21   0:00  |       \_ -bash
> djedg     2641  0.7  0.0      0     0 pts/0    D+   02:22   0:01  |           \_ [jackd]

What is djedg?  Whatever it is, it's in the uninterruptible sleep (D) state.
That's interesting.

> dmesg says :
> 
> [14640.488249] INFO: task jackd:2641 blocked for more than 120 seconds.
> [14640.488258] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [14640.488265] jackd           D ffffffff81806240     0  2641   2147 0x00000000

This is curious - the jackd process is blocked for some reason which may be
in the call trace (I'll try to get a chance to look at it more carefully
soon).  At first glance it seems that perhaps the firewire kernel driver is
getting itself into a knot.

Stefan: do you have any ideas?  I see fw_device_op_release() pretty high up.

These traces may explain why a reboot is needed after this happens: the
driver probably thinks it's still busy indefinitely.

Of course the other thing worth pondering is why ffado is able to get the
driver to do this.

Regards
  jonathan