Lucid Beta 1 cannot use firewire hard disk

Bug #543488 reported by Huygens
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
New
Undecided
Unassigned

Bug Description

Prerequisite:
You need to have a firewire hard disk.

How to reproduce it:
Start Lucid and plug in the firewire hard disk. Nothing is happening.

Technical details:
Dmesg reports the connexion but it cannot add a corresponding device.
[ 721.380350] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
[ 721.703926] ieee1394: Node added: ID:BUS[0-00:1023] GUID[0090a991e0107124]
[ 721.704034] ieee1394: Node changed: 0-00:1023 -> 0-01:1023
[ 721.740525] scsi5 : SBP-2 IEEE-1394
[ 723.062713] ieee1394: sbp2: Logged into SBP-2 device
[ 723.063601] ieee1394: sbp2: Node 0-00:1023: Max speed [S400] - Max payload [2048]
[ 744.040223] ieee1394: sbp2: aborting sbp2 command
[ 744.040236] scsi 5:0:1:0: CDB: Inquiry: 12 00 00 00 24 00
[ 754.040203] ieee1394: sbp2: aborting sbp2 command
[ 754.040214] scsi 5:0:1:0: CDB: Test Unit Ready: 00 00 00 00 00 00
[ 754.040823] ieee1394: sbp2: reset requested
[ 754.040828] ieee1394: sbp2: generating sbp2 fetch agent reset
[ 764.040233] ieee1394: sbp2: aborting sbp2 command
[ 764.040242] scsi 5:0:1:0: CDB: Test Unit Ready: 00 00 00 00 00 00
[ 764.040869] scsi 5:0:1:0: Device offlined - not ready after error recovery
[ 764.040943] ieee1394: sbp2: scsi_add_device failed

Lucid Beta 1 is still using the old firewire stack and it does not work anylonger with the new kernel. It does work still in Karmic.

Switching to the new firewire stack does not help. As with Karmic, Lucid Beta 1 cannot switch to the new stack following the maintainer instructions (see Juju migration guide https://ieee1394.wiki.kernel.org/index.php/Juju_Migration and the already reported bug on Karmic Bug #529524)

The conclusion is:
With Lucid beta 1 you cannot use a firewire hard disk either with the old or the new firewire stack. I think that this is a major regression, especially for an LTS.

For more information, check mainly the initial question and check the related bug if you would like to see if the new stack could help.

I can help for further assistance is understanding the roots of this bug. I have the necessary hardware and the will to help :-)

Screatch (screatch)
description: updated
affects: ubuntu → linux (Ubuntu)
tags: added: kernel-series-unknown
Revision history for this message
Jerone Young (jerone) wrote :

Can somone try this:

         Can you remove file /lib/udev/85-hdparm.rules & reboot and see it works.

           It may be hdparm at fault?

Revision history for this message
Jeremy Teale (jteale) wrote :

sudo mv /lib/udev/rules.d/85-hdparm.rules /lib/udev/rules.d/85-hdparm.disabled fixes this issue for me. I am using the new firewire subsystem.

jeremy@hephaestus:~$ lsmod | grep firewire
firewire_sbp2 15009 2
firewire_ohci 25343 0
firewire_core 51537 2 firewire_sbp2,firewire_ohci
crc_itu_t 1715 1 firewire_core

Revision history for this message
axmukher (axmukher) wrote :

sudo mv /lib/udev/rules.d/85-hdparm.rules /lib/udev/rules.d/85-hdparm
works for me too
Thanks Jeremy, Jerone ...

Revision history for this message
Kenny Mayne (snapback77) wrote :

Thanks, the above worked for me too. Thanks, Michael, Jeremy, Jerome....

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.