Bug 243210 - [firewire] unmounted fw-sbp2 hard disk unable to power down
[firewire] unmounted fw-sbp2 hard disk unable to power down
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i386 Linux
low Severity high
: ---
: ---
Assigned To: Jarod Wilson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-07 18:02 EDT by Loïc GRENON
Modified: 2008-06-04 16:42 EDT (History)
4 users (show)

See Also:
Fixed In Version: 2.6.25.3-18.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-03 12:10:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Here is the /sys/bus/firewire/devices/fw0/config_rom file (88 bytes, application/octet-stream)
2007-06-13 09:24 EDT, Loïc GRENON
no flags Details
Here is the /sys/bus/firewire/devices/fw0/config_rom file (88 bytes, application/octet-stream)
2007-06-13 09:27 EDT, Loïc GRENON
no flags Details
/sys/bus/firewire/devices/fw1/config_rom (532 bytes, application/octet-stream)
2007-07-16 10:16 EDT, Loïc GRENON
no flags Details

  None (edit)
Description Loïc GRENON 2007-06-07 18:02:07 EDT
A Western Digital extern hard drive with both USB and Firewire connections works
well when using FC6.
When running FC7, i can't poweroff it.
Normally, it should poweroff when has been unmounted.
When unmount the disk and force the poweroff by pressing the power button, the
disk restarts and these messages appears in /var/log/messages :

[Disk plug]
Jun  7 23:42:46 localhost kernel: fw_core: created new fw device fw1 (0 config
rom retries)
Jun  7 23:42:46 localhost kernel: fw_core: phy config: card 0, new root=ffc0,
gap_count=63
Jun  7 23:42:47 localhost kernel: fw_sbp2: logged in to sbp2 unit fw1.1 (0 retries)
Jun  7 23:42:47 localhost kernel: fw_sbp2:  - management_agent_address:   
0xfffff0030000
Jun  7 23:42:47 localhost kernel: fw_sbp2:  - command_block_agent_address:
0xfffff0100000
Jun  7 23:42:47 localhost kernel: fw_sbp2:  - status write address:       
0x000100000000
Jun  7 23:42:47 localhost kernel: scsi5 : SBP-2 IEEE-1394
Jun  7 23:42:53 localhost kernel: fw_sbp2: sbp2_scsi_abort
Jun  7 23:42:59 localhost kernel: scsi 5:0:0:0: Direct-Access     WD      
5000KS External  106a PQ: 0 ANSI: 4
Jun  7 23:42:59 localhost kernel: SCSI device sdf: 976773168 512-byte hdwr
sectors (500108 MB)
Jun  7 23:42:59 localhost kernel: sdf: Write Protect is off
Jun  7 23:42:59 localhost kernel: sdf: cache data unavailable
Jun  7 23:42:59 localhost kernel: sdf: assuming drive cache: write through
Jun  7 23:42:59 localhost kernel: SCSI device sdf: 976773168 512-byte hdwr
sectors (500108 MB)
Jun  7 23:42:59 localhost kernel: sdf: Write Protect is off
Jun  7 23:42:59 localhost kernel: sdf: cache data unavailable
Jun  7 23:42:59 localhost kernel: sdf: assuming drive cache: write through
Jun  7 23:42:59 localhost kernel:  sdf: sdf1
Jun  7 23:42:59 localhost kernel: sd 5:0:0:0: Attached scsi disk sdf
Jun  7 23:42:59 localhost kernel: sd 5:0:0:0: Attached scsi generic sg6 type 0
Jun  7 23:43:00 localhost hald: mounted /dev/sdf1 on behalf of uid 500

[Unmount disk]
Jun  7 23:43:16 localhost hald: unmounted /dev/sdf1 from '/media/My Book' on
behalf of uid 500

[Poweroff button pressing]
Jun  7 23:43:37 localhost kernel: fw_sbp2: management write failed, rcode 0x12
Jun  7 23:43:38 localhost kernel: fw_sbp2: reconnected to unit fw1.1 (1 retries)
Comment 1 Stefan Richter 2007-06-10 08:45:46 EDT
The WD disk obviously doesn't completely power down but merely signifies that it
is about to disable its SBP-2 logical unit, somehow.  The new FireWire stack
obviously ignores whatever has changed and reconnects to the logical unit.

Could you please attach the file /sys/bus/firewire/devices/fw1/config_rom?  (I
suppose the file will look the same before and after the power-off button is
pressed.)
Comment 2 Loïc GRENON 2007-06-13 09:24:11 EDT
Created attachment 156870 [details]
Here is the /sys/bus/firewire/devices/fw0/config_rom file
Comment 3 Loïc GRENON 2007-06-13 09:27:26 EDT
Created attachment 156872 [details]
Here is the /sys/bus/firewire/devices/fw0/config_rom file
Comment 4 Loïc GRENON 2007-06-13 11:50:24 EDT
Comment on attachment 156872 [details]
Here is the /sys/bus/firewire/devices/fw0/config_rom file

I'm saddened for the delay but I was not at home.
Comment 5 Loïc GRENON 2007-07-16 05:57:43 EDT
Someone have a solution ? :s
Comment 6 Stefan Richter 2007-07-16 10:04:15 EDT
Sorry that I didn't notice it earlier:  You provided the config_rom from fw0,
which is the local node.  Please attach the config_rom from fw1 = the disk's node.
Comment 7 Loïc GRENON 2007-07-16 10:16:17 EDT
Created attachment 159322 [details]
/sys/bus/firewire/devices/fw1/config_rom

Sorry for this error but i haven't the good file because the disk wasn't
mounted.
Here is the /sys/bus/firewire/devices/fw1/config_rom file.
Comment 8 Stefan Richter 2007-07-16 17:30:10 EDT
Thanks.  I was particularly interested in the 3rd quadlet of the ROM.  It's
generation field contains "1", which means that the config ROM of this device
will (allegedly) never change.  Strange.  I wonder how the disk succeeded to
disconnect from the old IEEE 1394 drivers when the power-off button was pressed.
 Can you point me to a web site which shows the exact model of the WD enclosure?
Comment 9 Loïc GRENON 2007-07-17 03:11:44 EDT
This is this model : http://www.wdc.com/fr/products/products.asp?driveid=322
with a 500 Gb capacity.
Comment 10 Stefan Richter 2007-07-17 05:18:55 EDT
http://www.amazon.de/Western-Digital-Festplatte-Firewire-Anschlu%C3%9F/dp/B000G12W3Q
One reviewer says the device draws ~6 Watts when plugged out of the PC; and the
PSU alone draws ~4 Watts when plugged out of the disk.  Another reviewer says
the power-off button doesn't work (under Linux?) when connected via FireWire.

http://www.amazon.com/Western-Digital-External-Interface-WDG1T2500N/dp/B000G27F14/
One reviewer says the power button does not work reliably.

http://www.amazon.com/Western-Digital-External-Triple-Interface/dp/B000G2BGFK/
One reviewer says he has to push and hold the power button to switch it off.

There are generally a number of reports about various different firmware bugs of
the WD MyBook series, like for example hangs during transfer, difficulties to
discover the drive after warm boot or PM resume, or GUIDs which are not Globally
Unique --- a rather basic and stupid firmware bug which doesn't inspire
confidence in WD's firmware programmers.

But since the power-down function worked for you under FC6 I will continue to
find a solution.  Maybe I find someone who can lend me one of these.
Comment 11 Stefan Richter 2007-07-17 05:26:49 EDT
If you still got an FC6 box, the syslog messages when you power down the drive
on this one would be good to know.
Comment 12 Loïc GRENON 2007-07-17 06:25:14 EDT
I will test it with a Zod's LiveCD this week end (Friday) because i'm not at
home here.
Thanks you !
Comment 13 Loïc GRENON 2007-07-17 07:22:52 EDT
In the fact, how you make to read this config_rom file?
Comment 14 Stefan Richter 2007-07-17 07:32:09 EDT
I read it in a hex editor, khexedit.  This ROM is basically a bunch of bitfields
whose contents are defined by IEEE 1212, IEEE 1394(a), and SBP-2.  It also isn't
a hardware ROM, it only looks to the PC like a ROM.  It is usually assembled in
on-chip RAM by the firmware of the disk's SBP-2 bridge chip after each power
state change.
Comment 15 Stefan Richter 2007-07-17 07:39:53 EDT
PS:  Don't be irritated when you try FC6 again; the older ieee1394 drivers on
FC6 don't expose a config_rom file.  Therefore, log messages will be all that's
easily accessible for comparison between Fedora Core 6 and Fedora 7.  The ROM
will be the same anyway, but the protocol exchange between the old and new
drivers and the disk is obviously different.
Comment 16 Loïc GRENON 2007-07-27 04:40:45 EDT
I made the same operations under FC6 (LiveCD), by reading the file
/var/log/messages and dmesg.

----------------------------

When umount the disk and power off :

[root@localhost ~]# tail -f /var/log/messages
Jul 26 18:05:37 localhost kernel: ieee1394: sbp2: Driver forced to serialize I/O
(serialize_io=1)
Jul 26 18:05:37 localhost kernel: ieee1394: sbp2: Try serialize_io=0 for better
performance
Jul 26 18:05:37 localhost kernel: scsi3 : SBP-2 IEEE-1394
Jul 26 18:05:38 localhost kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 26 18:05:44 localhost kernel: ieee1394: sbp2: aborting sbp2 command
Jul 26 18:05:44 localhost kernel: scsi 3:0:1:0: 
Jul 26 18:05:44 localhost kernel:         command: Inquiry: 12 00 00 00 24 00
Jul 26 18:05:50 localhost kernel:   Vendor: WD        Model: 5000KS External  
Rev: 106a
Jul 26 18:05:50 localhost kernel:   Type:   Direct-Access                     
ANSI SCSI revision: 04
Jul 26 18:05:50 localhost kernel: SCSI device sdf: 976773168 512-byte hdwr
sectors (500108 MB)
Jul 26 18:05:50 localhost kernel: sdf: Write Protect is off
Jul 26 18:05:50 localhost kernel: sdf: cache data unavailable
Jul 26 18:05:50 localhost kernel: sdf: assuming drive cache: write through
Jul 26 18:05:50 localhost kernel: SCSI device sdf: 976773168 512-byte hdwr
sectors (500108 MB)
Jul 26 18:05:50 localhost kernel: sdf: Write Protect is off
Jul 26 18:05:50 localhost kernel: sdf: cache data unavailable
Jul 26 18:05:50 localhost kernel: sdf: assuming drive cache: write through
Jul 26 18:05:50 localhost kernel:  sdf: sdf1
Jul 26 18:05:50 localhost kernel: sd 3:0:1:0: Attached scsi disk sdf
Jul 26 18:05:50 localhost kernel: sd 3:0:1:0: Attached scsi generic sg5 type 0
Jul 26 18:05:51 localhost kernel: SELinux: initialized (dev sdf1, type vfat),
uses genfs_contexts
Jul 26 18:05:51 localhost hald: mounted /dev/sdf1 on behalf of uid 500
Jul 26 18:06:08 localhost hald: unmounted /dev/sdf1 from '/media/My Book' on
behalf of uid 500
Jul 26 18:06:27 localhost kernel: ieee1394: Error parsing configrom for node
0-00:1023

----------------------------

When power off without unmouting :

[root@localhost ~]# tail -f /var/log/messages
Jul 26 18:06:44 localhost kernel: scsi4 : SBP-2 IEEE-1394
Jul 26 18:06:45 localhost kernel: ieee1394: sbp2: Logged into SBP-2 device
Jul 26 18:06:50 localhost kernel: ieee1394: sbp2: aborting sbp2 command
Jul 26 18:06:50 localhost kernel: scsi 4:0:1:0: 
Jul 26 18:06:50 localhost kernel:         command: Inquiry: 12 00 00 00 24 00
Jul 26 18:06:55 localhost kernel:   Vendor: WD        Model: 5000KS External  
Rev: 106a
Jul 26 18:06:55 localhost kernel:   Type:   Direct-Access                     
ANSI SCSI revision: 04
Jul 26 18:06:55 localhost kernel: SCSI device sdf: 976773168 512-byte hdwr
sectors (500108 MB)
Jul 26 18:06:55 localhost kernel: sdf: Write Protect is off
Jul 26 18:06:55 localhost kernel: sdf: cache data unavailable
Jul 26 18:06:55 localhost kernel: sdf: assuming drive cache: write through
Jul 26 18:06:55 localhost kernel: SCSI device sdf: 976773168 512-byte hdwr
sectors (500108 MB)
Jul 26 18:06:55 localhost kernel: sdf: Write Protect is off
Jul 26 18:06:55 localhost kernel: sdf: cache data unavailable
Jul 26 18:06:55 localhost kernel: sdf: assuming drive cache: write through
Jul 26 18:06:55 localhost kernel:  sdf: sdf1
Jul 26 18:06:55 localhost kernel: sd 4:0:1:0: Attached scsi disk sdf
Jul 26 18:06:55 localhost kernel: sd 4:0:1:0: Attached scsi generic sg5 type 0
Jul 26 18:06:55 localhost kernel: SELinux: initialized (dev sdf1, type vfat),
uses genfs_contexts
Jul 26 18:06:56 localhost hald: mounted /dev/sdf1 on behalf of uid 500
Jul 26 18:07:05 localhost kernel: ieee1394: Error parsing configrom for node
0-00:1023
Jul 26 18:07:05 localhost kernel: sd 4:0:1:0: rejecting I/O to device being removed
Jul 26 18:07:05 localhost kernel: Buffer I/O error on device sdf1, logical block
238472
Jul 26 18:07:05 localhost kernel: lost page write due to I/O error on sdf1
Jul 26 18:07:05 localhost hald[3254]: forcibly attempting to lazy unmount
/dev/sdf1 as enclosing drive was disconnected
Jul 26 18:07:05 localhost hald: unmounted /dev/sdf1 from '/media/My Book' on
behalf of uid 0

----------------------------

Power On :

[fedora@localhost ~]$ dmesg
ieee1394: Node resumed: ID:BUS[0-00:1023]  GUID[0090a990e011379d]
scsi6 : SBP-2 IEEE-1394
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
ieee1394: sbp2: aborting sbp2 command
scsi 6:0:1:0: 
        command: Inquiry: 12 00 00 00 24 00
  Vendor: WD        Model: 5000KS External   Rev: 106a
  Type:   Direct-Access                      ANSI SCSI revision: 04
SCSI device sdg: 976773168 512-byte hdwr sectors (500108 MB)
sdg: Write Protect is off
sdg: Mode Sense: 11 00 00 00
sdg: cache data unavailable
sdg: assuming drive cache: write through
SCSI device sdg: 976773168 512-byte hdwr sectors (500108 MB)
sdg: Write Protect is off
sdg: Mode Sense: 11 00 00 00
sdg: cache data unavailable
sdg: assuming drive cache: write through
 sdg: sdg1
sd 6:0:1:0: Attached scsi disk sdg
sd 6:0:1:0: Attached scsi generic sg6 type 0
SELinux: initialized (dev sdg1, type vfat), uses genfs_contexts

----------------------------

Power off :

[fedora@localhost ~]$ dmesg
SELinux: initialized (dev sdg1, type vfat), uses genfs_contexts
ieee1394: Error parsing configrom for node 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023]  GUID[0090a990e011379d]
Comment 17 Stefan Richter 2007-07-27 09:05:41 EDT
Thanks.  I gather:
  - When the disk is on, it shows a bus_info.generation = 1 (immutable ROM).
  - When the disk is powered down, it sends a bus reset with a
    self_ID.link = 1 (link active) but the ROM is gone.
That's not quite standards-compliant, but the ieee1394/nodemgr in FC 6 happens
work with this.  I will look into how fw-core in FC 7 can be changed to cope
with it too.

PS: Don't power off before umount, unless you mounted read-only. :-)
Comment 18 Loïc GRENON 2007-07-27 12:19:03 EDT
Thanks you.
If the manufacturers don't respect the standards ... :/
Particularly, manufacturers like Western Digital ...
Comment 19 Loïc GRENON 2007-08-20 10:27:33 EDT
For information, this problem persists on Fedora 8 Test 1.
Comment 20 Christopher Brown 2007-09-14 08:54:03 EDT
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the Fedora 8 Test 2.

I've re-assigned the bug to the Fedora firewire subsystem maintainer which may
generate more reviews of your issue.

Cheers
Chris
Comment 21 Stefan Richter 2007-09-14 09:44:14 EDT
Although I am not the reporter nor have the particular hardware, I am quite
certain that the problem still exists and is an upstream bug.  (I am upstream
co-maintainer of the Linux kernel FireWire subsystem.)

I noticed a similar issue with an IOI FWB-IDE01AB bridge board (based on Initio
INIC-2430).  When the extra power supply is turned off but there is still bus
power, the bridge's PHY and perhaps its link are still on, only the disk is
powered off.  The firewire drivers attempt to reconnect and eventually fail.  If
we are lucky, a solution to this issue might also solve the issue with the WD My
Book Pro.

(As another data point:  I have also enclosures with OxSemi based bridge boards
which, when powered off, switch disk and link off but keep the PHY powered up by
bus power, so that it continues to function as repeater in the FireWire daisy
chain.  This kind of device is correctly handled by the firewire drivers.)
Comment 22 Loïc GRENON 2007-09-14 12:56:46 EDT
The problem persist with Fedora 8 test 2.
I have these messages in /var/log/messages when umount the disk and push in the
power-off button :

Sep 14 18:50:07 localhost hald: unmounted /dev/sdf1 from '/media/My Book' on
behalf of uid 500
Sep 14 18:50:19 localhost kernel: firewire_core: phy config: card 0, new
root=ffc1, gap_count=5
Sep 14 18:50:21 localhost kernel: firewire_sbp2: orb reply timed out, rcode=0x11
Sep 14 18:50:21 localhost kernel: firewire_sbp2: error status: 0:9
Sep 14 18:50:22 localhost kernel:last message repeated 4 times
Sep 14 18:50:22 localhost kernel: firewire_sbp2: failed to reconnect to fw1.1
Sep 14 18:50:23 localhost kernel: firewire_sbp2: logged in to fw1.1 LUN 0000 (0
retries)
Comment 23 Christopher Brown 2008-01-09 08:40:20 EST
Hello Loïc,

Its been a while - are you still having this issue? The firewire stack has seen
several improvements - you may even wish to test with a 2.6.24 kernel from
rawhide if you are able.
Comment 24 Stefan Richter 2008-01-09 15:46:18 EST
The related issue from comment #21 is still there, therefore it is very likely
that the power-off problem also still exists.
Comment 25 Stefan Richter 2008-01-20 07:52:22 EST
Maybe what should be done is:

in fw-topology.h:
  - add an FW_NODE_INITIATED_RESET event to the enum

in fw-topology.c:
  - this event is to be triggered when selfID.i == 1 and none of
    _CREATED, _LINK_ON, _LINK_OFF apply
  - _INITIATED_RESET supersedes _UPDATED

in fw-device.c:
  - on _INITIATED_RESET, fw_node_event() needs to issue a workqueue
    job which re-reads the config ROM and compares it with a previously
    read ROM.  Then act according to the found differences; notably
    added or removed unit directories

I need to check whether this is what the device in comment #21 wants.
Comment 26 Stefan Richter 2008-01-20 08:25:00 EST
Addendum to comment #21:
Vice versa, if the device is started with bus power (drives powered down), no
units are discovered on it.  If self power is switched on (drives powered up),
ieee1394 rescans and detects the SBP-2 units but fw-core doesn't.

(I only mention this here because a cure to this might also be a cure to the
problem of the bug opener.)
Comment 27 Christopher Brown 2008-02-15 21:04:45 EST
Not sure if Jarod is doing backports to F7 but I'll re-assign this to him anyway.
Comment 28 Jarod Wilson 2008-02-20 12:01:39 EST
At the moment, the plan is to let 2.6.24.x, which has most of the previously
mentioned fixes, soak in f8, then trickle back to f7. Sounds like this
particular bug is still present even in current rawhide though. I should poke
through my stack of drives and see if I can reproduce...

If nobody objects, I'm going to move this bug from f7 to rawhide.
Comment 29 Jarod Wilson 2008-02-27 17:40:10 EST
Okay, I'm able to reproduce the behavior in comment #22 on another Western
Digital drive here on my end (non-pro 250G My Book), similar behavior from
2.6.23 up to 2.6.25-rc3 + linux1394-2.6.git patches.
Comment 30 Stefan Richter 2008-02-27 18:00:46 EST
Do you have a way to have the WD drive attached in sleep mode?  If so, does it
show a config ROM to the drivers while in this state?  And would that config ROM
differ from when the drive is up and running?  (Compare the contents of
/sys/bus/firewire/devices/fw${WD_DISK}/config_rom.)
Comment 31 Jarod Wilson 2008-02-27 18:13:17 EST
Trying to get a look at the config rom while the disk is sleeping is on my todo
list for this evening. (I figure worst-case, I'll be able to do it under Mac OS
X. Apple FireWire SDK has some decent tools for prodding devices in it.)
Comment 32 Stefan Richter 2008-02-27 18:22:47 EST
ieee1394 might work as well for that; though you'd have to fetch the ROM
manually with firecontrol or gscanbus then.  "r . 0 0xfffff0000400 20" in
firecontrol fetches the first 5 quadlets of the config ROM ( = the bus info
block) of node 0.
Comment 33 Stefan Richter 2008-02-27 18:37:54 EST
"r . 0 0xfffff0000414 4" is interesting too; that's length and CRC of the root
directory.
Comment 34 Stefan Richter 2008-02-27 19:11:11 EST
Can the drive be powered down after "modprobe -r firewire-sbp2"?
Comment 35 Jarod Wilson 2008-02-27 23:45:21 EST
While powered up:

$ csr-dump /sys/bus/firewire/devices/fw1/config_rom 
config rom length: 133
bus info block, length 4
  bus options:                  0x00ff5113
  guid:                         0x0090a991e0112c98
root directory
  node capabilities:            0x0083c0
  vendor:                       WESTERN DIGITAL (0x0090a9)
  textual descriptor:           "WD"
  hardware version:             0x00f924
  textual descriptor:           "924DS"
  unit directory:               0x000005
  unit directory:               0x000015
unit directory
  specifier_id:                 WESTERN DIGITAL (0x0090a9)
  version:                      0xce0002
  0x21:                         0x000002
  0x38:                         0x014004
  model:                        0x000000
  textual descriptor:           "External HDD Button & Lights"
unit directory
  specifier_id:                 ASC X3 - INFORMATION TECHNOLOGY STANDARDS
SECRETARIATS (0x00609e)
  version:                      0x010483
  sb2 firmware revision:                0x000100
  dependent info offset:        0x00c000
  sb2 mgt_ORB_timeout:          0x00003c (30s)
  sb2 command set specifier:    ASC X3 - INFORMATION TECHNOLOGY STANDARDS
SECRETARIATS (0x00609e)
  sb2 command set:              0x0104d8
  sb2 command set revision:             0x000000
  0x21:                         0x000001
  dependent info:               0x4e0000
  model:                        0x000000
  textual descriptor:           "External HDD Device"

While powered down, with firewire-sbp2 unloaded:

$ csr-dump /sys/bus/firewire/devices/fw1/config_rom 
config rom length: 133
bus info block, length 4
  bus options:                  0x00ff5113
  guid:                         0x0090a991e0112c98
root directory
  node capabilities:            0x0083c0
  vendor:                       WESTERN DIGITAL (0x0090a9)
  textual descriptor:           "WD"
  hardware version:             0x00f924
  textual descriptor:           "924DS"
  unit directory:               0x000005
  unit directory:               0x000015
unit directory
  specifier_id:                 WESTERN DIGITAL (0x0090a9)
  version:                      0xce0002
  0x21:                         0x000002
  0x38:                         0x014004
  model:                        0x000000
  textual descriptor:           "External HDD Button & Lights"
unit directory
  specifier_id:                 ASC X3 - INFORMATION TECHNOLOGY STANDARDS
SECRETARIATS (0x00609e)
  version:                      0x010483
  sb2 firmware revision:                0x000100
  dependent info offset:        0x00c000
  sb2 mgt_ORB_timeout:          0x00003c (30s)
  sb2 command set specifier:    ASC X3 - INFORMATION TECHNOLOGY STANDARDS
SECRETARIATS (0x00609e)
  sb2 command set:              0x0104d8
  sb2 command set revision:             0x000000
  0x21:                         0x000001
  dependent info:               0x4e0000
  model:                        0x000000
  textual descriptor:           "External HDD Device"
Comment 36 Jarod Wilson 2008-02-27 23:55:30 EST
Hrm. Zero difference. I even unplugged the disk, moved firewire-sbp2.ko out of
the way so it couldn't load, then reconnected the disk. Its found just fine, and
the disk never powers up, but the config_rom dump in that case is still
identical to the above.
Comment 37 Stefan Richter 2008-02-28 03:12:01 EST
The config ROM dump is what firewire-core reads, isn't it?  firewire-core never
rereads the ROM after it read it successfully for the first time, even though it
should do so when the device caused the bus reset.

Please also read the ROM independently with firecontrol.  Quadlet reads at 400
(length and CRC of the bus info block), 408 (bus options), 414 (root directory
header), and maybe the two unit directory headers would be most interesting; but
better would be to read the ROM completely.  (Offsets relative to 0xfffff0000000.)

The bus options according to csr-dump indicate:

max_rec = 5  ->  read and write requests with up to 64 bytes payload accepted

max_ROM = 1  ->  read requests in the config ROM region shall be either quadlet
read requests (4 bytes payload, 4 bytes aligned) or block read requests with 64
bytes payload and 64 bytes alignment  (I.e. you probably can't let firecontrol
read everything in one go.)

generation = 1  ->  config ROM will never change  (If that is true, then I am on
a wild goose chase.)
Comment 38 Jarod Wilson 2008-02-28 10:36:51 EST
As mentioned on irc, I haven't got around to poking with firecontrol, but did
take a look at the drive under Mac OS X, using some of Apple's FireWire SDK
tools. The config rom *does* change when the drive is powered down.

Drive powered up:

(0xf0000400) 0x04044eaa  ROM Header (General), info_len = 0x4 quadlets, crc_len
= 0x4 quadlets, crc = 0x4eaa
Bus Information Block:
(0xf0000404) 0x31333934  "1394" 
(0xf0000408) 0x00ff5113  MaxRec = 0x05 (64 bytes) 
(0xf000040c) 0x0090a991  NodeVendorID = 0x0090a9, ChipIDHi = 0x91
(0xf0000410) 0xe0112c98  ChipIDLo = 0xe0112c98
Root Directory:
(0xf0000414) 0x00074937  Directory header, length = 0x7 quadlets, crc = 0x4937
(0xf0000418) 0x0c0083c0  Key type = 0 (Imm), Key = 0x0c (Node Capabilities),
Data = 0x0083c0 (DRQ, LST, FIX, 64Bit, SPT)
(0xf000041c) 0x030090a9  Key type = 0 (Imm), Key = 0x03 (Module Vendor ID), Data
= 0x0090a9
(0xf0000420) 0x81000074  Key type = 2 (Leaf), Key = 0x01 (Text), Rel. Offset =
0x000074 (0xf00005f0)
   (0xf00005f0) 0x0003e57b  Leaf header, length = 0x3 quadlets, crc = 0xe57b
   (0xf00005f4)   00000000 00000000 57440000   ........WD..
(0xf0000424) 0x0400f924  Key type = 0 (Imm), Key = 0x04 (Module HW Version),
Data = 0x00f924
(0xf0000428) 0x81000076  Key type = 2 (Leaf), Key = 0x01 (Text), Rel. Offset =
0x000076 (0xf0000600)
   (0xf0000600) 0x0004791f  Leaf header, length = 0x4 quadlets, crc = 0x791f
   (0xf0000604)   00000000 00000000 39323444 53000000   ........924DS...
(0xf000042c) 0xd1000005  Key type = 3 (Dir), Key = 0x11 (Unit Dir), Rel. Offset
= 0x000005 (0xf0000440)
   Unit Directory:
   (0xf0000440) 0x00066a83  Directory header, length = 0x6 quadlets, crc = 0x6a83
   (0xf0000444) 0x120090a9  Key type = 0 (Imm), Key = 0x12 (Unit Spec ID), Data
= 0x0090a9
   (0xf0000448) 0x13ce0002  Key type = 0 (Imm), Key = 0x13 (Unit SW Version),
Data = 0xce0002
   (0xf000044c) 0x21000002  Key type = 0 (Imm), Key = 0x21 (revision), Data =
0x000002
   (0xf0000450) 0x38014004  Key type = 0 (Imm), Key = 0x38, Data = 0x014004
   (0xf0000454) 0x17000000  Key type = 0 (Imm), Key = 0x17 (Model ID), Data =
0x000000
   (0xf0000458) 0x81000001  Key type = 2 (Leaf), Key = 0x01 (Text), Rel. Offset
= 0x000001 (0xf000045c)
      (0xf000045c) 0x000928e1  Leaf header, length = 0x9 quadlets, crc = 0x28e1
      (0xf0000460)   00000000 00000000 45787465 726e616c   ........External
      (0xf0000470)   20484444 20427574 746f6e20 26204c69    HDD Button & Li
      (0xf0000480)   67687473                              ghts            
(0xf0000430) 0xd1000015  Key type = 3 (Dir), Key = 0x11 (Unit Dir), Rel. Offset
= 0x000015 (0xf0000484)
   Unit Directory:
   (0xf0000484) 0x000dfb9e  Directory header, length = 0xd quadlets, crc = 0xfb9e
   (0xf0000488) 0x1200609e  Key type = 0 (Imm), Key = 0x12 (Unit Spec ID), Data
= 0x00609e (NCITS/T10)
   (0xf000048c) 0x13010483  Key type = 0 (Imm), Key = 0x13 (Unit SW Version),
Data = 0x010483 (SBP)
   (0xf0000490) 0x3c000100  Key type = 0 (Imm), Key = 0x3c (Firmware Revision),
Data = 0x000100
   (0xf0000494) 0x5400c000  Key type = 1 (Offset), Key = 0x14 (Management
Agent), Abs. Offset = 0x00c000 (0xf0030000)
   (0xf0000498) 0x3a003c08  Key type = 0 (Imm), Key = 0x3a (Unit
Characteristics), Data = 0x003c08
                                                           (mgt_timeout = 0x3c *
500 ms, ORB_size = 0x8 quadlets)
   (0xf000049c) 0x3800609e  Key type = 0 (Imm), Key = 0x38 (Command Set Spec
ID), Data = 0x00609e
   (0xf00004a0) 0x390104d8  Key type = 0 (Imm), Key = 0x39 (Command Set), Data =
0x0104d8
   (0xf00004a4) 0x3b000000  Key type = 0 (Imm), Key = 0x3b (Command Set
Revision), Data = 0x000000
   (0xf00004a8) 0x3d000003  Key type = 0 (Imm), Key = 0x3d (Reconnect Timeout),
Data = 0x000003
   (0xf00004ac) 0x21000001  Key type = 0 (Imm), Key = 0x21 (revision), Data =
0x000001 (SBP-3)
   (0xf00004b0) 0x144e0000  Key type = 0 (Imm), Key = 0x14 (LUN), Data =
0x4e0000 (ordered = 1, type = 0xe, lun = 0x0)
   (0xf00004b4) 0x17000000  Key type = 0 (Imm), Key = 0x17 (Model ID), Data =
0x000000
   (0xf00004b8) 0x81000001  Key type = 2 (Leaf), Key = 0x01 (Text), Rel. Offset
= 0x000001 (0xf00004bc)
      (0xf00004bc) 0x0007bc02  Leaf header, length = 0x7 quadlets, crc = 0xbc02
      (0xf00004c0)   00000000 00000000 45787465 726e616c   ........External
      (0xf00004d0)   20484444 20446576 69636500             HDD Device.


Drive powered down:

(0xf0000400) 0x00000000  ROM Header (General), info_len = 0x0 quadlets, crc_len
= 0x0 quadlets, crc = 0x0000
Bus Information Block:
(0xf0000404) 0x00000000  ERROR does not equal "1394"
(0xf0000408) 0x00000000  CycClkAcc = 0x00 
(0xf000040c) 0x00000000  NodeVendorID = 0x000000, ChipIDHi = 0x00
(0xf0000410) 0x00000000  ChipIDLo = 0x00000000
Root Directory:
(0xf0000414) 0x00000000  Directory header, length = 0x0 quadlets, crc = 0x0000
Comment 39 Stefan Richter 2008-03-02 20:50:37 EST
I posted a patch which lets firewire-core recognize config ROM changes:
http://lkml.org/lkml/2008/3/2/188
Comment 40 Jarod Wilson 2008-03-03 15:16:47 EST
I've verified this patch does allow the Western Digital drive I've got here to
power down, as well as get recognized and logged back into once its powered up
again. Good stuff! Will be in rawhide soon...
Comment 41 Jarod Wilson 2008-03-03 16:35:10 EST
Patch added to rawhide, will be present in kernel-2.6.25-0.86.rc3.git4.fc9 and
later.
Comment 42 Jarod Wilson 2008-03-04 00:27:22 EST
Also patched into a forthcoming f8 kernel build, kernel-2.6.24.3-17.fc8, which
may be easier for f8 (and f7) users wanting to test to digest.

http://koji.fedoraproject.org/koji/taskinfo?taskID=489639
Comment 43 Jarod Wilson 2008-03-04 14:53:41 EST
Please test with either a rawhide kernel or fedora 8's kernel-2.6.24.3-17.fc8 or
later (-17.fc8 is available from koji, link in comment #42) to verify the
problem is resolved.
Comment 44 Bug Zapper 2008-05-13 22:58:34 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 45 Stefan Richter 2008-06-03 12:01:17 EDT
I suggest this bug be closed.
Comment 46 Jarod Wilson 2008-06-03 12:10:29 EDT
Yeah, I'll just go ahead and close this one, I was waiting for the original bug
reported to report back, but I think we've got enough confirmation this has been
fixed.
Comment 47 Loïc GRENON 2008-06-04 16:42:22 EDT
Yes, it's works !
Tkanks.

Note You need to log in before you can comment on or make changes to this bug.