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)
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.)
Created attachment 156870 [details] Here is the /sys/bus/firewire/devices/fw0/config_rom file
Created attachment 156872 [details] Here is the /sys/bus/firewire/devices/fw0/config_rom file
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.
Someone have a solution ? :s
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.
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.
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?
This is this model : http://www.wdc.com/fr/products/products.asp?driveid=322 with a 500 Gb capacity.
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.
If you still got an FC6 box, the syslog messages when you power down the drive on this one would be good to know.
I will test it with a Zod's LiveCD this week end (Friday) because i'm not at home here. Thanks you !
In the fact, how you make to read this config_rom file?
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.
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.
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]
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. :-)
Thanks you. If the manufacturers don't respect the standards ... :/ Particularly, manufacturers like Western Digital ...
For information, this problem persists on Fedora 8 Test 1.
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
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.)
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)
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.
The related issue from comment #21 is still there, therefore it is very likely that the power-off problem also still exists.
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.
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.)
Not sure if Jarod is doing backports to F7 but I'll re-assign this to him anyway.
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.
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.
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.)
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.)
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.
"r . 0 0xfffff0000414 4" is interesting too; that's length and CRC of the root directory.
Can the drive be powered down after "modprobe -r firewire-sbp2"?
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"
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.
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.)
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
I posted a patch which lets firewire-core recognize config ROM changes: http://lkml.org/lkml/2008/3/2/188
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...
Patch added to rawhide, will be present in kernel-2.6.25-0.86.rc3.git4.fc9 and later.
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
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.
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
I suggest this bug be closed.
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.
Yes, it's works ! Tkanks.