Re: Unable to access firewire hard drive
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2012-02-20 19:22:05
|
On Feb 20 Clemens Ladisch wrote: > Peter Christy wrote: >> Under Windoze, the drive functions perfectly as either USB or FireWire (ie >> this is not a hardware fault!) It certainly isn't a hardware fault but a firmware fault. USB + FireWire disk enclosure have entirely different firmwares for the USB part and the FireWire part. Your disk enclosure contains a Prolific chip. Enclosures with this chip were regularly shipped with excessively buggy FireWire firmware (but proper USB firmware). >> Under Slackware, when connected as USB, the drive is immediately recognised, >> and a prompt appears on the desktop asking if I want to mount it. If I accept, >> it is mounted as /media/Video (the partition label). >> >> If I connect it as Firewire, although the kernel appears to recognise it (see >> demsg above), no prompt to mount it appears. Attempting to mount it manually >> creates an eror message saying it can't identify the filing system. Specifying >> ntfs-3g produces a "wrong super-block" error. > > Please show the output of these commands: > xxd -g1 /dev/sdd | head -32 > xxd -g1 /dev/sdd1 | head -32 > for both USB and FireWire. > >> sd 5:0:0:0: [sdd] 312558593 512-byte logical blocks: (160 GB/149 GiB) > > Is this size exactly the same with USB and FireWire? Yep, the FireWire firmware might return false size information, read from bogus offsets, or give whatever else false information. [...] >> In other words, although the disk works fine under Windows, and under >> Linux as USB, it doesn't work under FireWire, as the system is unable to >> identify the partition, although it knows it exists! >> >> I haven't used this caddy for a while, but it used to work perfectly >> under the old FireWire stack. (I was unaware that there was a new stack >> until I started trying to debug this problem!) The change from ohci1394 + ieee1394 + sbp2 to firewire-ohci + firewire-core + firewire-sbp2 has very very little impact on the operation of FireWire storage devices. (The latter set of drivers is faster with 1394a and some mixed 1394b/1394a buses due to optimized bus arbitration gaps, anything else that concerns SBP-2 and its underpinnings hasn't changed much.) Much more impact have - changes in the kernel's SCSI and block layer drivers, - changes in the low-level userland, i.e. formerly HAL, now udev and their respective helper programs. The general trend, at least of the kernel side of the equation, is to more and more mimic the behaviour Windows, as far as details of Windows behavior become known. But this is only a general trend; there may well be occasional changes contrary to this. I can't say the same about low-level userland; this part of Linux might more rely on standards-compliant behavior of devices than the kernel itself does. Consumer-grade storage device firmwares do not really conform to any kind of standard; more commonly they are a heap of hacked-together stuff which just so happens to work with a somewhat current version of MS Windows with a narrow type of workload --- i.e. what the firmware coders did briefly test. Send an unexpected SCSI request to a Prolific FireWire firmware, and the firmware will hang (good, then it is at least immediately clear that the device got into trouble), or start mangling block addresses or data or whatever. >> I am not a programmer, though I would claim to be "computer literate". >> This may be an error on my part, but if so it is not obvious to me. >> Googling for solutions to this issue has produced a number of hits for >> Ubuntu users with the same problem, but no apparent solution! Do you have bookmarks of such discussions? It might be interesting to have a look at those. However, it is not uncommon that users identify as "the same problem" what in reality are quite different problems. This is to be expected, given how complex the whole hardware--firmware--OS-- application stack is nowadays. On a related note: I have a Prolific based enclosure myself, but with an optical drive in it instead of a HDD. For a time I also had a cheap Prolific based 2.5" HDD enclosure but its bridge board died a sudden and soon death. Is anybody aware of Prolific based devices still being sold anywhere? As IDE bridges, these chips are obsolete nowadays, but I have seen a case once where a FireWire-to-IDE bridge from another vendor was paired with an IDE-to-SATA bridge to make up a FireWire-to-SATA bridge board, presumably a few cents cheaper than with a native FireWire-to-SATA chip. Would be good to have a Prolific based HDD enclosure as a specimen for driver tests. My ODD enclosure works with HDDs too but it is inconvenient to swap the drives when needed. Plus, there seems to be quite a bit of variation between firmwares for the Prolific chip. -- Stefan Richter -=====-===-- --=- =-=-- http://arcgraph.de/sr/ |