Enable new Firewire stack in default kernel config

Bug #276463 reported by Duncan Lithgow
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Andy Whitcroft
Won't Fix

Bug Description

An updated firewire stack and associate drivers has been merged into the mainline kernel for quite some time. This new stack fixes many design flaws present in the old stack.

Please also see the blueprint at https://blueprints.edge.launchpad.net/ubuntu/+spec/firewire-core/

description: updated
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Duncan,

I assume you are referring to the CONFIG_FIREWIRE kernel config option. I'm pasting the Kconfig excerpt for the kernel team to reference when considering to enable this option:

comment "Enable only one of the two stacks, unless you know what you are doing"
    depends on EXPERIMENTAL

    tristate "New FireWire stack, EXPERIMENTAL"
    depends on EXPERIMENTAL
    select CRC_ITU_T
      This is the "Juju" FireWire stack, a new alternative implementation
      designed for robustness and simplicity. You can build either this
      stack, or the old stack (the ieee1394 driver, ohci1394 etc.) or both.
      Please read http://ieee1394.wiki.kernel.org/index.php/Juju_Migration
      before you enable the new stack.

      To compile this driver as a module, say M here: the module will be
      called firewire-core.

      This module functionally replaces ieee1394, raw1394, and video1394.
      To access it from application programs, you generally need at least
      libraw1394 version 2. IIDC/DCAM applications also need libdc1394
      version 2. No libraries are required to access storage devices
      through the firewire-sbp2 driver.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Stefan Richter (stefan-r-ubz) wrote :

There are still some very visible regressions of the new vs. the old stack, see ieee1394.wiki.kernel.org. Alas, upstream work on these issues slowed down again during the last few months due to lack of developer manhours.

Revision history for this message
Thomas E Jenkins (thomas-jenkins) wrote :

According to http://ieee1394.wiki.kernel.org/index.php/Juju_Migration as of kernel 2.6.26 it is possible to build both stacks as modules provided one is properly blacklisted. Version 2 of libraw1394 would also be required to actually use the new stack.

This config would allow those inclined to test the new stack without compiling a custom kernel. I think v2 of libraw1394 could be installed parallel to v1 without impact.

From the above page:

"Regarding Linux 2.6.26, the best advice to Linux distributors (kernel packagers) as well as to regular users is: Build only the old IEEE 1394 drivers. — Alternatively, build both stacks as modules but make sure that only one of them (the one you want) is being loaded. I.e. create proper blacklist entries in /etc/modprobe.conf; see below. Also, you need to upgrade your userland to libraw1394 v2 if you want to switch to the new drivers (or freely between old and new drivers)."

Revision history for this message
Thomas E Jenkins (thomas-jenkins) wrote :
Revision history for this message
Andy Whitcroft (apw) wrote :

We are not planning on enabling both stacks for Intrepid. We are following upstream recommendation for which stack should be enabled.

Changed in linux:
assignee: nobody → apw
status: New → Invalid
Tim Gardner (timg-tpi)
Changed in linux:
assignee: apw → nobody
status: Invalid → Won't Fix
Revision history for this message
Christian Kujau (christiank) wrote :

Please reconsider your decision and enable the new stack as a module, but *use the old one as a default*, as recommended upstream.

Despite possibly existing bugs in the new implementation and/or libraw1394, Firewire can also be used to attach storage devices, no libraw1394 involved here. When using the old stack, I got only half the performance (literally, as in "50% of the performance" when using the same setup with the new stack). AFAIK the two stacks can co-exist and we could blacklist the new stack, so that no user will accidently be provided with the new one. For me, this is the only reason why I have to recompile the ubuntu kernel - if the new stack would be enabled, I could use a stock ubuntu kernel. Thanks.

Revision history for this message
Stefan Richter (stefan-r-ubz) wrote :

Yes, there would be some benefits to provide the new drivers as an opt-in alternative, i.e. enabled in the build configuration but blacklisted to prevent automatic loading:
  - Asynchronous performance of 1394a buses (a.k.a. FireWire 400) is indeed considerably higher in the new firewire drivers.
  - They are more secure due to physical DMA filtering and possibly finer-grained character device file permissions.
  - Having the new drivers may help when trying to debug issues with FireWire devices.
  - Upstream development activities are focused on the new drivers.
  - Advanced users of pro/ semi-pro FireWire applications may be interested to try the new drivers.

However,the new drivers are of lesser usefulness on distributions which still provide libraw1394 v1 instead of v2. SBP-2 (storage) devices would indeed be the only device class that can be accessed through the new drivers without libraw1394 v2 and libdc1394 v2.

Revision history for this message
Allison Karlitskaya (desrt) wrote :

+1 from another sbp2 user here (and as the person that filed the original report)

Revision history for this message
Duncan Lithgow (duncan-lithgow) wrote : Re: [Bug 276463] Re: Enable new Firewire stack in default kernel config

I would also support having the option of testing the new stack. It
would be a blessing if firewire worked out of the box in Ubuntu in the

Revision history for this message
Andy Whitcroft (apw) wrote :

Having read the linked wiki pages, this new stack is still rather raw. It does appear we could enable both and blacklist the new. This would be helpful for porters etc. Will propose this to the kernel team.

Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Andy Whitcroft (apw)
Changed in linux:
assignee: nobody → apw
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.28-4.5

linux (2.6.28-4.5) jaunty; urgency=low

  [ Andy Whitcroft ]

  * clean up module dependancy information on package removal/purge
    - LP: #300773

  [ Tim Gardner ]

  * Update iscsitarget to 0.4.17
  * Build in ext{234}
  * Build in Crypto modules AES, CBC, ECB
  * Build in AGP intel,via,sis,ali,amd,amd64,efficeon,nvidia,sworks
  * Build in ata,dev_dm,dev_loop,dev_md,dev_sd,dev_sr
  * Build in BT l2cap,rfcomm,sco
  * Build in CPU_FREQ
  * Build in DRM
  * Build in HID
  * Build in I2C
  * Build in IEEE1394 OHCI1394
  * Build in INPUT EVDEV
  * Build in IPV6
  * Build in MMC
  * Build in PACKET
  * Enable both IEEE1394 (Firewire) stacks as modules
    - LP: #276463
    - LP: #306016
  * Enable dm-raid4-5
    - LP: #309378
  * Build in PPP
  * Build in RFKILL
  * Build in USB SERIAL

  [ Upstream Kernel Changes ]

  * Rebased to v2.6.28

 -- Tim Gardner <email address hidden> Thu, 18 Dec 2008 21:18:44 -0700

Changed in linux:
status: In Progress → Fix Released
Revision history for this message
Christian Kujau (christiank) wrote :


...erm, what I meant to say was: Thanks to all involved for fixing this one!

Christian ;-)

Revision history for this message
Duncan Lithgow (duncan-lithgow) wrote :

Does anyone have an overview of which key apps need testing with this new stack so they can be ready when the new stack becomes the default? I only know of dvgrab/kino and similar video apps...

Revision history for this message
Thomas E Jenkins (thomas-jenkins) wrote :

There is a Jack driver to test as well that I believe is already packaged.

Revision history for this message
Dan Dennedy (dan-dennedy) wrote :

Yeah, unfortunately, the Jack driver FFADO is known to not be working with new firewire. I was working on some minor fixes in libraw1394 with the FFADO project earlier in the month, but we got stuck on one last issue just before the holidays. I will ping them.

Revision history for this message
Thomas E Jenkins (thomas-jenkins) wrote :

I updated the libraw1394 package to 2.0.1, see LP: #311804 (I blame Launchpad for the triplicate post in that bug). Using the libffado2 packages from the ubuntustudio-dev PPA I can start the ffado-dbus-server and connect the ffado-mixer to my device successfully. I can rebuild the 0.116.1 Jack packages in main to include the firewire driver but I cannot get the driver to successfully start. Possibly the issue you were working on. So, some limited success with an Edirol FA-66.

Revision history for this message
Thomas E Jenkins (thomas-jenkins) wrote :

After looking into things more I basically have the exact issue mentioned in this FFADO upstream report that I assume is also the issues Dan Dennedy was refering to.


For FFADO 2.0 the focus is not on porting to the new firewire stack, but rather relying on libraw1394 to provide compatible access to both. So the issues being worked in that FFADO bug report are being fixed in libraw1394. I couldn't find an upstream libraw1394 bug referencing the work.

If there is any other testing I can do of the new firewire stack with an audio interface, please let me know.

Revision history for this message
Stefan Richter (stefan-r-ubz) wrote :

Kernel 2.6.32 (2 December 2009) and libraw1394 v2.0.5 (26 December 2009) contain the fixes that are required for FFADO. Debugged and implemented by Jay Fenlason.

I believe I had vanilla FFADO v2.0.0 running with these, but Debian's FFADO maintainer packages FFADO trunk which contains a small fix that is related to the new FireWire drivers. I don't know how essential that fix is. I heard FFADO is going to do a v2.0.1 maintenance release eventually; however, Debian's current FFADO package is closer t what will become FFADO v2.1 --- also to be released "any day now" with much extended hardware support (independent of whether old or new firewire kernel drivers are used).

In short: After storage, consumer video, industrial video, and IP networking, FireWire audio as the last missing piece in the puzzle works through the new kernel driver stack too since end of 12/2009.

Note that Ubuntu's current defaults (old stack, no user access to raw1394) effectively prevents non-experts from using FireWire for anything else than storage devices (and even those with less performance and compatibility than the new drivers offer).

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.