jackd core dump w/ FA-66

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

jackd core dump w/ FA-66

I. E. Smith-Heisters-2
Hi all,

I've been having a very regular problem with jack and my Edirol FA-66.
The problem was on Ubuntu Feisty (Jack 0.102.0), and persists on
Ubuntu Gutsy (Jack 0.103.0). Basically everything will work for a
while and then it will crash. Sometimes it works all day without
crashing, other times it will crash immediately. Sometimes reloading
the raw1394 module and restarting jackd will get it running again.

The FA-66 is plugged into a small firewire input and is powered by an
external supply, not over firewire.

The output on crash is usually something like this (I think the number
before "Aborted" varies:

$ ./.jackdrc
jackd 0.103.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver ..
Freebob using Firewire port 0, node -1
libiec61883 warning: Established connection on channel 0.
You may need to manually set the channel on the receiving node.
libiec61883 warning: Established connection on channel 1.
You may need to manually set the channel on the transmitting node.
./.jackdrc: line 1:  7091 Aborted                 (core dumped) jackd
-R -P70 -dfreebob -r48000 -p512 -n2

The gdb output (below) isn't very illuminating (at least to me). Any ideas?

Thanks,
Ian


$ uname -a
Linux kasai 2.6.22-14-rt #1 SMP PREEMPT RT Mon Oct 15 01:05:51 GMT
2007 i686 GNU/Linux
$ gdb jackd
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run -R -P70 -dfreebob -r48000 -p512 -n2
Starting program: /usr/bin/jackd -R -P70 -dfreebob -r48000 -p512 -n2
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1210012992 (LWP 6765)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
jackd 0.103.0
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
[New Thread -1210016880 (LWP 6768)]
[New Thread -1218495600 (LWP 6769)]
loading driver ..
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Freebob using Firewire port 0, node -1
[New Thread -1231623280 (LWP 6770)]
[New Thread -1240015984 (LWP 6771)]
[New Thread -1240544368 (LWP 6772)]
[New Thread -1241072752 (LWP 6773)]
[New Thread -1241601136 (LWP 6774)]
libiec61883 warning: Established connection on channel 0.
You may need to manually set the channel on the receiving node.
libiec61883 warning: Established connection on channel 1.
You may need to manually set the channel on the transmitting node.
[New Thread -1242129520 (LWP 6775)]
[New Thread -1250522224 (LWP 6776)]

Program exited with code 01.
(gdb)

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd core dump w/ FA-66

Daniel Wagner-4
> Basically everything will work for a
> while and then it will crash. Sometimes it works all day without
> crashing, other times it will crash immediately. Sometimes reloading
> the raw1394 module and restarting jackd will get it running again.

Could you check the kernel messages (dmesg)? And also check the firewire
chipset in your computer (lspci -v).

daniel


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd core dump w/ FA-66

I. E. Smith-Heisters-2
On 12/1/07, Daniel Wagner <[hidden email]> wrote:
> > Basically everything will work for a
> > while and then it will crash. Sometimes it works all day without
> > crashing, other times it will crash immediately. Sometimes reloading
> > the raw1394 module and restarting jackd will get it running again.
>
> Could you check the kernel messages (dmesg)? And also check the firewire
> chipset in your computer (lspci -v).

Sure:

$ dmesg
<snip>
[  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
[ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
[ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
ctrl[20649806] cmdptr[f000e2c3]

$ lspci -v
<snip>
03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
(prog-if 10 [OHCI])
        Subsystem: Dell Unknown device 01cd
        Flags: bus master, medium devsel, latency 64, IRQ 18
        Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
        Capabilities: <access denied>
<schnap>

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd core dump w/ FA-66

Daniel Wagner-4
I. E. Smith-Heisters wrote:

> On 12/1/07, Daniel Wagner <[hidden email]> wrote:
>>> Basically everything will work for a
>>> while and then it will crash. Sometimes it works all day without
>>> crashing, other times it will crash immediately. Sometimes reloading
>>> the raw1394 module and restarting jackd will get it running again.
>> Could you check the kernel messages (dmesg)? And also check the firewire
>> chipset in your computer (lspci -v).
>
> Sure:
>
> $ dmesg
> <snip>
> [  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
> [ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
> [ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
> ctrl[20649806] cmdptr[f000e2c3]

There we have it: the transfer between device and PC stops working. So
this is not a jackd problem at all.

> $ lspci -v
> <snip>
> 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
> (prog-if 10 [OHCI])
>         Subsystem: Dell Unknown device 01cd
>         Flags: bus master, medium devsel, latency 64, IRQ 18
>         Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
>         Capabilities: <access denied>
> <schnap>

I suspected that it is a Ricoh chipset. I also have one in my laptop
with the same behavior. Normally after a few minutes the stream breaks,
even under windows. Although there exists some Ricoh chipsets which are
reported to work.

The current workaround is to use an cardbus firewire adapter. Up to now
nobody had enough time/energy to go after that bug. Sorry about that.

daniel



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd core dump w/ FA-66

Pieter Palmers
Daniel Wagner wrote:

> I. E. Smith-Heisters wrote:
>> On 12/1/07, Daniel Wagner <[hidden email]> wrote:
>>>> Basically everything will work for a
>>>> while and then it will crash. Sometimes it works all day without
>>>> crashing, other times it will crash immediately. Sometimes reloading
>>>> the raw1394 module and restarting jackd will get it running again.
>>> Could you check the kernel messages (dmesg)? And also check the firewire
>>> chipset in your computer (lspci -v).
>> Sure:
>>
>> $ dmesg
>> <snip>
>> [  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
>> [ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
>> [ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
>> ctrl[20649806] cmdptr[f000e2c3]
>
> There we have it: the transfer between device and PC stops working. So
> this is not a jackd problem at all.
>
>> $ lspci -v
>> <snip>
>> 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
>> (prog-if 10 [OHCI])
>>         Subsystem: Dell Unknown device 01cd
>>         Flags: bus master, medium devsel, latency 64, IRQ 18
>>         Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
>>         Capabilities: <access denied>
>> <schnap>
>
> I suspected that it is a Ricoh chipset. I also have one in my laptop
> with the same behavior. Normally after a few minutes the stream breaks,
> even under windows. Although there exists some Ricoh chipsets which are
> reported to work.
>
> The current workaround is to use an cardbus firewire adapter. Up to now
> nobody had enough time/energy to go after that bug. Sorry about that.
It's important to note that this is a kernel level bug, and that we
(=the freebob/ffado team) are not really the people working on the
kernel level 1394 support/bugs.

Greets,

Pieter

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd core dump w/ FA-66

I. E. Smith-Heisters-2
In reply to this post by Daniel Wagner-4
On 12/2/07, Daniel Wagner <[hidden email]> wrote:

> I. E. Smith-Heisters wrote:
> > On 12/1/07, Daniel Wagner <[hidden email]> wrote:
> >>> Basically everything will work for a
> >>> while and then it will crash. Sometimes it works all day without
> >>> crashing, other times it will crash immediately. Sometimes reloading
> >>> the raw1394 module and restarting jackd will get it running again.
> >> Could you check the kernel messages (dmesg)? And also check the firewire
> >> chipset in your computer (lspci -v).
> >
> > Sure:
> >
> > $ dmesg
> > <snip>
> > [  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
> > [ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
> > [ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
> > ctrl[20649806] cmdptr[f000e2c3]
>
> There we have it: the transfer between device and PC stops working. So
> this is not a jackd problem at all.
>
> > $ lspci -v
> > <snip>
> > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
> > (prog-if 10 [OHCI])
> >         Subsystem: Dell Unknown device 01cd
> >         Flags: bus master, medium devsel, latency 64, IRQ 18
> >         Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
> >         Capabilities: <access denied>
> > <schnap>
>
> I suspected that it is a Ricoh chipset. I also have one in my laptop
> with the same behavior. Normally after a few minutes the stream breaks,
> even under windows. Although there exists some Ricoh chipsets which are
> reported to work.
>
> The current workaround is to use an cardbus firewire adapter. Up to now
> nobody had enough time/energy to go after that bug. Sorry about that.
>
> daniel
>
>
>

Hey, cool, at least the bug is known and I've got a fix now. Thanks a bunch.

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jackd core dump w/ FA-66

I. E. Smith-Heisters-2
For the archives and any others in this situation:

I bought a Bytecc 1394a Expresscard, which uses a TI chipset:

$ lspci | grep IEEE
03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
0e:00.0 FireWire (IEEE 1394): Texas Instruments XIO2200(A)
IEEE-1394a-2000 Controller (PHY/Link) (rev 01)

I then had to install Dell's A09 BIOS update, even though it claims
that it's only for 1394b. Now everything seems to work perfectly,
except that I haven't tried hotplugging it yet; but that should just
be a modprobe matter if anything doesn't work.

Thanks again.

On 12/2/07, I. E. Smith-Heisters <[hidden email]> wrote:

> On 12/2/07, Daniel Wagner <[hidden email]> wrote:
> > I. E. Smith-Heisters wrote:
> > > On 12/1/07, Daniel Wagner <[hidden email]> wrote:
> > >>> Basically everything will work for a
> > >>> while and then it will crash. Sometimes it works all day without
> > >>> crashing, other times it will crash immediately. Sometimes reloading
> > >>> the raw1394 module and restarting jackd will get it running again.
> > >> Could you check the kernel messages (dmesg)? And also check the firewire
> > >> chipset in your computer (lspci -v).
> > >
> > > Sure:
> > >
> > > $ dmesg
> > > <snip>
> > > [  175.952817] ipw3945: Error sending cmd #07 to daemon: time out after 500ms.
> > > [ 1324.762525] ohci1394: fw-host0: Unrecoverable error!
> > > [ 1324.762556] ohci1394: fw-host0: Iso Xmit 0 Context died:
> > > ctrl[20649806] cmdptr[f000e2c3]
> >
> > There we have it: the transfer between device and PC stops working. So
> > this is not a jackd problem at all.
> >
> > > $ lspci -v
> > > <snip>
> > > 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller
> > > (prog-if 10 [OHCI])
> > >         Subsystem: Dell Unknown device 01cd
> > >         Flags: bus master, medium devsel, latency 64, IRQ 18
> > >         Memory at dcbfd800 (32-bit, non-prefetchable) [size=2K]
> > >         Capabilities: <access denied>
> > > <schnap>
> >
> > I suspected that it is a Ricoh chipset. I also have one in my laptop
> > with the same behavior. Normally after a few minutes the stream breaks,
> > even under windows. Although there exists some Ricoh chipsets which are
> > reported to work.
> >
> > The current workaround is to use an cardbus firewire adapter. Up to now
> > nobody had enough time/energy to go after that bug. Sorry about that.
> >
> > daniel
> >
> >
> >
>
> Hey, cool, at least the bug is known and I've got a fix now. Thanks a bunch.
>

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel