Impossible to activate the new firewire kernel stack on Karmic or Lucid

Bug #529524 reported by Huygens
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

I have posted a thread on the Ubuntu forums but as I did not get any answer, it is probably a bug, and not my own mistake. This bug is related to Bug #276463 which purpose was to provide both old and new stack on Ubuntu but still defaulting to the old one. This current bug report is stating that eventhough the new stack is also provided, it is not possible to activate it.

Here is what I reported back a few weeks ago in the forums (http://ubuntuforums.org/showthread.php?t=1389329):
As the new firewire kernel stack is not experimental since kernel 2.6.31 (the version on Karmic), I thought about giving it a try.
I've checked the official stack migration wiki (http://ieee1394.wiki.kernel.org/index.php/Juju_Migration) and did what was recommended there. As Ubuntu shipped with both the old and new stack but with the new one disabled in /etc/modprobe.d/blacklist-firewire.conf
Therefore, I've modified this last file so that it looks like this now:
blacklist ohci1394
blacklist sbp2
blacklist dv1394
blacklist raw1394
blacklist video1394

#blacklist firewire-ohci
#blacklist firewire-sbp2

So the old ieee1394 stack is blacklisted and the new firewire stack should be automatically loaded.

I have rebooted my computer so changes take effect and I've performed an lsmod which did not display the expected result
Module Size Used by
firewire_sbp2 15112 0
firewire_core 47296 1 firewire_sbp2
crc_itu_t 1852 2 rt61pci,firewire_core
sbp2 22888 1
ohci1394 29900 1
ieee1394 86596 2 sbp2,ohci1394

As you can see the firewire_sbp2 is unused, whereas the sbp2 (the old stack) is used (I have an external firewire hard drive plugged in). If I plug out my HD, then the sbp2 gets also unused. Thus, it is the one used for the HD. And as you can see from the dependency sbp2 is based on the old stack which I had blacklisted.
Side note: I have unplugged my HD, then using 'modprobe -r' I removed the sbp2 and ohci1394 modules. Then, I plugged back my HD hoping that the new stack would be used... No success. Linux did not even see that I had plugged back my HD, as you can see in the dmesg output below, which only shows the device and modules removal:
[ 268.610021] sd 6:0:1:0: [sdc] Stopping disk
[ 268.650880] ieee1394: sbp2: Logged out of SBP-2 device
[ 304.998148] ieee1394: Node removed: ID:BUS[0-00:1023] GUID[0090a991e0107124]
[ 304.998375] ieee1394: Node removed: ID:BUS[0-01:1023] GUID[0010dc00006c3bb8]

As I have followed the migration guide and blacklisted the old stack, I was expecting the new stack to be operationnal. However, the old one is still the one operationnal and eventhough the new one is "loaded" it is not used.

Updated: I have tested it with the latest Karmic update and when I activate the new stack and restart the computer, the behaviour is slightly different now than a few weeks ago. Here is the output of the lsmod:
Module Size Used by
firewire_sbp2 15272 0
firewire_core 47392 1 firewire_sbp2
crc_itu_t 1852 1 firewire_core
ohci1394 30220 0
ieee1394 86628 1 ohci1394

For information, the firewire drive was plugged in, but no module where loaded, so I could not access it. Here is a more interesting output from dmesg, this time Linux detects that I plug the drive out and in, but nothing more is happening.
[ 166.241229] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
[ 166.241244] ieee1394: Node paused: ID:BUS[0-00:1023] GUID[0090a991e0107124]
[ 169.300088] ieee1394: Node removed: ID:BUS[0-00:1023] GUID[0090a991e0107124]
[ 171.380328] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
[ 171.655903] ieee1394: Node added: ID:BUS[0-00:1023] GUID[0090a991e0107124]
[ 171.658338] ieee1394: Node changed: 0-00:1023 -> 0-01:1023

ProblemType: Bug
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: jean-christophe 2345 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xfc020000 irq 17'
   Mixer name : 'Conexant CX20561 (Hermosa)'
   Components : 'HDA:14f15051,17aa2100,00100000'
   Controls : 14
   Simple ctrls : 7
Date: Sun Feb 28 17:24:09 2010
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=9c8acd99-53cc-497d-a89e-3a3142ae8716
MachineType: LENOVO 2241BN5
Package: linux-image-2.6.31-19-generic-pae 2.6.31-19.56
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: root=UUID=66ce5f80-3e6d-40af-a6e0-a678ba8e7383 ro quiet splash crashkernel=384M-2G:64M,2G-:128M
ProcEnviron:
 LANGUAGE=en_GB.UTF-8
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-19.56-generic-pae
RelatedPackageVersions:
 linux-backports-modules-2.6.31-19-generic-pae N/A
 linux-firmware 1.26
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
Uname: Linux 2.6.31-19-generic-pae i686
WpaSupplicantLog:

XsessionErrors:
 (gnome-settings-daemon:2466): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
 (nautilus:2613): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:2630): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (gnome-panel:2612): Gdk-WARNING **: /build/buildd/gtk+2.0-2.18.3/gdk/x11/gdkdrawable-x11.c:952 drawable is not a pixmap or window
dmi.bios.date: 11/26/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 6FET82WW (3.12 )
dmi.board.name: 2241BN5
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: FR500089
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6FET82WW(3.12):bd11/26/2009:svnLENOVO:pn2241BN5:pvrThinkPadT500:rvnLENOVO:rn2241BN5:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 2241BN5
dmi.product.version: ThinkPad T500
dmi.sys.vendor: LENOVO

Revision history for this message
Huygens (huygens-25) wrote :
tags: added: karmic
Revision history for this message
Huygens (huygens-25) wrote :

This bug also affects Lucid Beta 1
Check related bug report (related, not duplicate because with Lucid the old firewire stack does not work!) Bug #543488

tags: added: lucid
summary: - Impossible to activate the new firewire kernel stack on Karmic
+ Impossible to activate the new firewire kernel stack on Karmic or Lucid
Revision history for this message
Huygens (huygens-25) wrote :

I have upgraded to Lucid Beta 2. The problem is still present... Here is the dmesg output when using the new kernel stack:
[ 151.205001] ieee1394: Node added: ID:BUS[0-00:1023] GUID[0090a991e0107124]
[ 151.205112] ieee1394: Node changed: 0-00:1023 -> 0-01:1023

And the lsmod output for what's regarding firewire/ieee1394 modules:
firewire_sbp2 15009 0
firewire_core 51537 1 firewire_sbp2
crc_itu_t 1715 1 firewire_core
ohci1394 30548 0
ieee1394 94798 1 ohci1394

Revision history for this message
Huygens (huygens-25) wrote :

While investigating another bug for Lucid (Bug #548513), I have found out a patch that work while using the new kernel stack with Lucid Lynx Beta 2.
The patch requires changing /lib/udev/rules.d/85-hdparm to:
ACTION=="add", SUBSYSTEM=="block", KERNEL=="[sh]d[a-z]", \
 ENV{ID_PATH}!="pci-*-ieee1394-*|pci-*-usb-*", \
 RUN+="/lib/udev/hdparm"

Revision history for this message
Huygens (huygens-25) wrote :

I confirm that the patch is also working for Karmic :-)

Revision history for this message
Jeff (jdorenbush) wrote :

I am using Ubuntu 10.04, kernel 2.6.32-19

This affects me. I am unable to access my Western Digital 500GB My Book External Harddrive through Firewire.

I'm not familiar with installing patches so I was unable to try the patch. Can someone assist me in this?

tags: added: kj-triage
Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

Hi Huygens,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 529524

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Huygens (huygens-25) wrote :

I will do the test in the coming week! Thanks for helping.

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

Hi Huygens,

Dan Dennedy wrote at bug #6290 comment #78:
> I learned that you must update the initrd images after changing the blacklist file:
> sudo update-initramfs -k all -u

I.e. because ohci1394 is present in the original initrd (initial RAM disk with a minimal preliminary root filesystem), it got bound to the OHCI-1394 controller during boot-up instead of firewire-ohci. (The wiki page at kernel.org does currently lack this extra information. I'll add it soon.)

Later on, when ieee1394 discovered that an SBP-2 compliant device is present behind the OHCI-1394 controller, it sends an "uevent" to userspace with the SBP-2 module alias. Both the new firewire-core-based firewire-sbp2 driver and the old ieee1394-based sbp2 driver match this alias. Modprobe will load the first one of these modules (minus any that was blacklisted), in your case firewire-sbp2. firewire-core gets loaded as a prerequisite for firewire-sbp2. However, since firewire-core sees no controller (only ieee1394 sees one), firewire-sbp2 gets nothing to do either. You could use the SBP-2 device only if you manually load sbp2.

/Or/ you manually unload ohci1394, then manually load firewire-ohci. After that, the new stack will work, including firewire-sbp2 being automatically loaded and bound to the SBP-2 device.

/Or/ you can attempt to replace the initrd as described by Dan. That change will become effective at the next reboot.

Revision history for this message
Jeremy Foshee (jeremyfoshee) wrote :

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: kj-expired
Changed in linux (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Huygens (huygens-25) wrote :

Sorry, I do not manage to find time for these tests... I cannot give any date as of now, but I hope that with a month or two, I will be able to test it.

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

Other bug subscribers

Remote bug watches

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