Ticket #183 (closed bug: wontfix)

Opened 15 years ago

Last modified 14 years ago

DRIVER NT: could not run driver cycle

Reported by: arthur Assigned to:
Priority: major Milestone: FFADO 2.0
Component: Version: FFADO SVN (2.0 branch)
Keywords: Cc:
The device the bug applies to:

Description

Echo AudioFire?8

Crashes quite rapidly after startup

Attachments

ffado-logs.tgz (94.5 kB) - added by arthur on 12/04/08 09:28:09.
ffado-jack.log and ffado-diag.log
cnx_refused.log (2.7 kB) - added by arthur on 12/10/08 14:02:33.

Change History

12/04/08 09:28:09 changed by arthur

  • attachment ffado-logs.tgz added.

ffado-jack.log and ffado-diag.log

12/04/08 14:23:41 changed by ppalmers

What happens is that the OHCI card skips one cycle without data loss for one reason or the other. The ECHO doesn't seem to like this and generates a bus reset.

So far for what happens... but why it happens is a mystery at the moment.

12/04/08 14:25:21 changed by ppalmers

Things to try: the configuration file related things mentioned in ticket #181. You are not running the nvidia binary driver by any chance?

12/10/08 12:03:06 changed by arthur

No I'm not using nvidia binary driver. I'm using vesa.

My CPUFreq is set to performance (full CPU usage).

Something I didn't mention, here are the messages I get in dmesg :

[ 781.946271] ohci1394: fw-host0: isochronous cycle too long [ 978.560113] ohci1394: fw-host0: rawiso xmit: packet 64 crosses a page boundary [ 978.747240] jackd[23864]: segfault at 1c6e720 ip 1c6e720 sp 456e4f48 error 15 [ 1046.964562] ohci1394: fw-host0: isochronous cycle too long

Could it be my firewire (pci) card that is bad ?

Checking out that SMP stuff...

12/10/08 12:08:49 changed by arthur

$ lspci -v

02:07.3 FireWire? (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev 46) (prog-if 10)

Subsystem: Device 00ff:9a01 Flags: bus master, stepping, medium devsel, latency 32, IRQ 21 Memory at fddfe000 (32-bit, non-prefetchable) [size=2K] I/O ports at dd00 [size=128] Capabilities: <access denied> Kernel driver in use: ohci1394 Kernel modules: ohci1394

12/10/08 14:02:10 changed by arthur

on a 2.6.27-3-rt kernel with only uses 1 CPU (cf ubuntu bug for the kernel-package) it seems to work correctly.

I now can't connect qjackctl or ardour or hydrogen. Don't know if this is a bug for here or jack or the clients (attaching a log file anyway just in case).

12/10/08 14:02:33 changed by arthur

  • attachment cnx_refused.log added.

11/02/09 02:39:06 changed by jwoithe

Should this ticket be closed since it appears the eventual conclusion was that the firewire chipset was faulty in some obscure way. Or is further debug work continuing?

11/21/09 12:03:27 changed by ppalmers

  • status changed from new to closed.
  • resolution set to wontfix.

This might be a hardware issue or a SMP problem in the kernel drivers. In any case its very unlikely that we are responsible for an "isochronous cycle too long".

Won't fix for now.

11/21/09 16:27:51 changed by stefanr

"isochronous cycle too long" is a condition which is detected by the FireWire? controller hardware which notifies the drivers about it. The drivers practically have no means to correct this condition.

It means that either the cycle master is malfunctioning (hardware problem at the physical layer) or that more isochronous data is sent than the bus has bandwidth (hardware problem or stream configuration problem).

"xmit: packet 64 crosses a page boundary" indicates that the latter is the culprit. It appears the DMA program was corrupted. I find it not very likely to be an SMP related bug in the drivers though --- while this is a possibility, one would expect that more FFADO users would have quickly ran into the same issue. After all, SMP is the norm nowadays even in cheap PCs and notebooks. So, no idea from me either where to look for a source of this corruption.