User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b2) Gecko/20090227 Fedora/3.1-0.7.beta2.fc11 Minefield/3.1b2 after plugin in an external disk dirve (Iomega LPHD200-C) over fw400 the following to error messages are shown in /var/log/dmesg firewire_core: phy config: card 0, new root=ffc1, gap_count=5 venetus kernel: firewire_core: giving up on config rom for node id ffc0 System is a Dell Latitude E6400 with 03:01.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 04) Reproducible: Always Steps to Reproduce: 1. connect harddrive to fw port 2. 3. Actual Results: display "giving up on config rom" messages and nothing more apper Expected Results: connect the drive over fw400 and mount them the external drive also has an USB port witch are work very well. All data can be accessed, the fw port runs also well on an other system.
Can you attach the entire dmesg file?
Created attachment 337663 [details] dmesg Entire dmesg from fresh boot with plugin of firewire harddrive.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
There is a slight hardware/firmware problem with this Latitude's FireWire controller: The GUID which is reported for fw0 is not a valid one. (In the logged session, fw0 is the controller.) However, I do not expect this to be the cause of the inability to access the drive; usually FireWire devices accept such invalid GUIDs as long as they are unique on the bus. How is power supplied to the LPHD200-C? With an extra PSU? Or via USB? Most certainly not via FireWire because I presume that the Latitude only has an unpowered, 4-pin FireWire socket. If power is supplied via USB, it may be too weak to properly power the disk and the built-in bridge electronics. If power supply is not an issue, it may or may not help to gather more information from the FireWire drivers. As root user, perform the following steps: Unload the controller driver with "modprobe -r firewire-ohci". Then load it with event logging turned on: "modprobe firewire-ohci debug=-1". Then plug the disk in and post the now more verbose output of dmesg here. Finally, a USB 2.0 + FireWire 400 combo device may perhaps be based on the cheap Prolific Pl-3507 chip. If you have access to a Windows PC, try whether the Prolific firmware uploader tool sees the disk and check which firmware revision the tool reports. (The firmware uploader works over USB and does not modify the installed firmware until instructed to do so.) See the links at http://ieee1394.wiki.kernel.org/index.php/Firmware_Downloads. PL-3507 is known to be widely sold with bad FireWire firmwares which cause trouble under all popular OSs, while their USB part works OK. In many cases, such issues were cured by a firmware update.
Created attachment 381136 [details] A further dmesg exhibiting the same or related problem I have encountered the same or similar bug. My setup is as follows: Intel DP55WB motherboard with an integrated firewire 400 port. Attached to it is a Formac Disk 500 XTR. The Formac is a dual-IDE (master/slave) enclosure containing two 250GB drives which it presents to the Firewire bus as a single 500GB disk. It uses an Oxford 912 bridge chip. The bug occurred after I wrote 226GB to the drives (which show a formatted capacity of 459GB), i.e. possibly once writes to the second disk in the set commenced. The Firewire port then become non-functional (I was unable to attach and have recognized any Firewire device), until I executed "modprobe -r firewire-ohci" and then "modprobe firewire-ohci", following which the Firewire port became fully functional again. The Formac is well powered, and has been working without a hitch for an extended period of time with a Mac. Just prior to attaching it to my Linux server, I took the drives out and tested them internally. I ran "badblocks -w" as well as "smartctl -t offline" and both disks were given a stellar report by smartmontools. I attach the output of dmesg (which includes the output after I ran modprobe and attached another 1TB external Firewire disk).
Re comment 0 and comment 4: Niels, did you have a chance to collect the requested information? Re comment 5: Tom10256, yours is a different issue. The config ROM of Niels' disk cannot be read or parsed already from the outset. But in your case, this succeeded initially, but after a good amount of successful I/O, the bus fell into a loop (or longer series) of bus reset events and some self-identification complete events, yet normal I/O was not possible anymore. Why the bus reset series happened is not clear, but the subsequent inaccessibility of any FireWire device until module reloading can be explained. The OXFW912 in your disk generally works very reliably. I have two different enclosures with this bridge myself (a MacPower and a VulcanTech), each filled to the brim, and on occasions I wrote their whole contents in one go. The only known issue that OXFW912 based devices may have is an erratum of an older Texas Instruments FireWire 800 PHY chip (PHY = physical bus interface) --- TSB81BA3 until revision C inclusive --- but that erratum is only relevant on pure FireWire 800 buses, not FireWire 400. According to a web search, Intel DP55WB's onboard FireWire controller is a Texas Instruments TSB43AB22 or TSB43AB22A. This chip's PHY on the other hand is apparently affected by another erratum, http://focus.ti.com/lit/er/sllz012/sllz012.pdf, which explains the bus becoming non-functional. One *possible* cause for unwanted bus reset storms during I/O is poor layout of circuit boards in a device or PC. Especially FireWire controllers on motherboards are often rather distant from the FireWire port, therefore a part of the interconnect might be slightly off the electrical specification. Surely there are hardware engineers out there who think they could lay out FireWire 400 connections as sloppily as they are used to with USB 2.0 (480 Mb/s) connections. According to Intel's board manual, the layout is the typical underwhelming one found on many FireWire equipped boards: There is a two-port FireWire controller, one of its ports is made available as a standard 6-pin port somewhere at the middle of the back edge of the board, while the other port ends in a pin header somewhere at the left/bottom edge of the board, i.e. fairly distantly from each other. Worse, if a jumper cable is connected to this pin header and a front panel connector, you have another weak link on the bus. Now, what can our drivers do to mitigate such problems? We already worked on making the firewire-sbp2 driver (storage protocol driver) robust against temporary disturbance of the bus. What appears to be missing for a setup like yours is a workaround for erratum SLLZ012. I have logged this as an RFE at http://ieee1394.wiki.kernel.org/index.php/To_Do#firewire-ohci. If you feel that this needs to be tracked in bugzilla, please open a new bug for it either here or at bugzilla.kernel.org. Let's keep /this/ bug entry limited to Niels' particular issue.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.