Ticket #288 (closed bug: wontfix)

Opened 10 years ago

Last modified 8 years ago

FFADO fails from screensaver/screenblank

Reported by: shuberts Assigned to:
Priority: major Milestone:
Component: generic Version: FFADO 2.0.1
Keywords: IsoHandler, requestEnable, crash, Cc:
The device the bug applies to:

Description (Last modified by arnonym)

When my screensaver or screenblank kicks in, FFADO crashes with error message:

Error (IsoHandler.cpp)[ 733] requestEnable: Enable requested on stream with state: 2
Debug (IsoHandlerManager.cpp)[1019] startHandlerForStream:  could not request enable for handler 0x8294c28)

This is 100% repeatable. And, though I can work around it by disabling compiz, disabling any video acceleration, and disabling the screen savers and screen blanking, this seems a little extreme.

To make matters worse, this also happens when I try to use any advanced video features, e.g. compiz cube, etc.

Here is my config:

  • Intel Pentium 4 processor at ~1GHz.
  • 768 Mb RAM.
  • NVIDIA GeForce? 5 card (restricted binary drivers v173, but also happens when using generic SVGA drivers).
  • Firewire interface.
  • PreSonus? FP10.
  • Ubuntu Studio 10.04 (Linux xxxxx 2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 22:02:19 UTC 2010 i686 GNU/Linux)

GDB backtrace:

(gdb) list -20,+20
692	    m_State = eHS_Stopped;
693	    m_NextState = eHS_Stopped;
694	    return true;
695	}
697	// functions to request enable or disable at the next opportunity
698	bool
699	IsoHandler::requestEnable(int cycle)
700	{
701	    if (m_State == eHS_Running) {
702	        debugError("Enable requested on enabled stream\n");
703	        return false;
704	    }
705	    if (m_State != eHS_Stopped) {
706	        debugError("Enable requested on stream with state: %d\n", m_State);
707	        return false;
708	    }
709	    m_NextState = eHS_Running;
710	    return true;
711	}
(gdb) backtrace
#0  IsoHandler::requestEnable (this=0x816f6a0, cycle=3683)
    at src/libieee1394/IsoHandler.cpp:706
#1  0x004415b7 in IsoHandlerManager::startHandlerForStream (this=0x80846c8, 
    stream=0x816f710, cycle=3683) at src/libieee1394/IsoHandlerManager.cpp:1015
#2  0x0045267e in Streaming::StreamProcessor::scheduleStartDryRunning (
    this=0x816f710, t=-1) at src/libstreaming/generic/StreamProcessor.cpp:1173
#3  0x00446911 in Streaming::StreamProcessorManager::startDryRunning (
    this=0x8077890) at src/libstreaming/StreamProcessorManager.cpp:423
#4  0x0044a23e in Streaming::StreamProcessorManager::handleXrun (
    this=0x8077890) at src/libstreaming/StreamProcessorManager.cpp:1055
#5  0x003d64fe in DeviceManager::waitForPeriod (this=0x8077710)
    at src/devicemanager.cpp:983
#6  0x003deb77 in ffado_streaming_wait (dev=0x8056ed8) at src/ffado.cpp:253
#7  0x003020d6 in ffado_driver_wait (driver=0x80534c0, extra_fd=-1, 
    status=0xb03c1328, delayed_usecs=0xb03c1324) at ffado_driver.c:531
#8  0x0030228c in ffado_driver_run_cycle (driver=0x80534c0)
    at ffado_driver.c:583
#9  0x001443dc in jack_driver_nt_thread (arg=0x80534c0)
    at ../libjack/driver.c:122
#10 0x00148262 in jack_thread_proxy (varg=0x809d810) at ../libjack/thread.c:118
#11 0x0018d96e in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#12 0x00272a4e in clone () from /lib/tls/i686/cmov/libc.so.6


ffado info (23.9 kB) - added by shuberts on 06/20/10 19:05:21.
lspci and ffado-diag output

Change History

06/19/10 20:11:56 changed by shuberts

Oh - and I forgot to say - thanks for looking in to this!

06/20/10 06:59:19 changed by arnonym

  • milestone deleted.

Please take a look at the output of "lspci" or "cat /proc/interrupts" to see whether your firewire controller shares its interrupt with the graphics card. If yes, try to make them not share an interrupt.

And please attach the output of "ffado-diag".

But it really sounds like an interrupt problem. I do have ffado run together with nvidia cards without problems. And without shared interrupts.

06/20/10 15:20:01 changed by arnonym

  • keywords changed from 2.0.1, IsoHandler, requestEnable, crash, to IsoHandler, requestEnable, crash,.
  • version changed from FFADO 2.0.0 to FFADO 2.0.1.
  • description changed.

06/20/10 19:05:21 changed by shuberts

  • attachment ffado info added.

lspci and ffado-diag output

06/20/10 19:06:03 changed by shuberts

Thanks for looking in on this, arnonym. This may have provided a step forward (though it doesn't seem to be a complete fix).

It turned out that I had two firewire cards in the machine, one of which shared and IRQ with the video card. I removed one card and moved the other to another slot so that the IRQ conflict was removed. However, the screensaver and screenblank still bring FFADO down.

I;ve attached my before-and after lspci and ffado-diag output. Do you see anything?

06/21/10 19:30:07 changed by shuberts

I've been poking around with this a bit, and have found the following:

1) The error message in question can only happen when IsoHandler?.m_state == eHS_Error (integer value 2).

2) IsoHandler?.m_state is only set to eHS_Error in IsoHandler::notifyOfDeath()

3) IsoHandler::notifyOfDeath() is only called in IsoTask::Execute() [IsoHandlerManager.cpp: 337] when measured_diff_ticks > max_diff_ticks. This seems to be a timeout condition when IsoHandler::getLastPacketTime() exceeds IsoTask:m_manager.get1394Service().getCycleTimer() by two seconds or more.

The debug output from this condition says:

:~$ /usr/bin/jackd -P89 -dfirewire -v1 -dhw:0 -r96000 -p512 -n3 
jackd 0.118.0
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

Memory locking is unlimited - this is dangerous. You should probably alter the line:
     @audio   -  memlock    unlimited
in your /etc/limits.conf to read:
     @audio   -  memlock    575715
no message buffer overruns
JACK compiled with System V SHM support.
loading driver ..
00960221744:  (ffado.cpp)[  92] ffado_streaming_init: libffado 2.0.1 built Jun 19 2010 17:04:03
firewire ERR: wait status < 0! (= -1)
DRIVER NT: could not run driver cycle
00998222555: Fatal (IsoHandlerManager.cpp)[ 336] Execute: (0x92c9000, Receive) Handler died: now: E953B66E, last: E5525292, diff: 49220572 (max: 49152000)
00998223267: Fatal (StreamProcessorManager.cpp)[1070] handleXrun: Could not syncStartAll...
jack main caught signal 12
no message buffer overruns

Does this help at all?

(follow-up: ↓ 7 ) 04/01/12 07:50:38 changed by jwoithe

Apologies that communication seems to have ground to a halt nearly 2 years ago.

Regarding the lspci output, it confirms that after the hardware shuffling the TI card is the only remaining firewire card present and it has its own interrupt. All this is good - and yet the problem remains.

I'm no expert in these things, but it may be worth trying with another firewire cable if this is convenient. Assuming the code analysis is correct it seems that for some reason the packet stream from the device just stops for no apparent reason. Since you have a good firewire card (TI based) and assuming there's no hardware fault with either the firewire card or the audio interface itself there's only a limited number of things which could cause these symptoms.

Another thing which would be worth trying is upgraded versions of some things on your system. Both the kernel and libraw1304 are fairly old by today's standards (although admittedly at the time the ticket was created their relative ages weren't quite so old). It may be that newer versions of one or both may help to some extent.

(in reply to: ↑ 6 ) 04/01/12 12:02:50 changed by stefanr

Replying to jwoithe:

Another thing which would be worth trying is upgraded versions of some things on your system. Both the kernel and libraw1304 are fairly old by today's standards (although admittedly at the time the ticket was created their relative ages weren't quite so old). It may be that newer versions of one or both may help to some extent.

Regarding libraw1394: At the time, the ohci/ieee/raw1394 kernel drivers were used. Libraw1394's backend code for them hasn't changed in the meantime, so from that point of view libraw1394 was already current.

Nevertheless it may be worth trying a newer kernel if this is conveniently possible. But if so, libraw1394 should also be updated to at least v2.0.7 or to the current v2.0.8 because firewire-ohci/core are now in use and pretty much require the fixes which went into the corresponding libraw1394 backend.

Actually, the kind of problem that the reporter got definitely calls for retesting with a much newer kernel. With a newer kernel, the closed nvidia driver and the reverse-engineered noveau driver should both be tried --- or the NVidia card replaced by an AMD/ATI one.

06/01/12 03:39:17 changed by jwoithe

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

Since bumping this thread two months ago there has been no further contact from the original poster. Without the re-testing mentioned in the previous two posts there isn't much we can do to track this issue down - assuming the problem hasn't been resolved by any of the numerous changes made to the various components over the past two years.

Consequently I'll close this ticket as "wontfix". If further testing demonstrates that there is still a problem with current software the ticket can always be re-opened.

As a closing comment, I note that the kernel in use at the time the ticket was created was the generic Ubuntu kernel of the day. In particular, it was not a PREEMPT ("low latency desktop") kernel. Based on other reports over the last few months, the root cause of the reporter's problem may have simply been the use of the "generic" kernel.