freecom firewire drive not mounted

wessel_k · 10-31-2008, 11:47 AM

Hi,

I'm wondering if anybody can help me out here.
I've bought a 1TB freecom firewire disk (no USB-connectors present, with a SATA drive). It was MAC HFS+ pre-formatted, but I've reformatted it to NTFS and later to FAT32. But it doesn't want to be mounted on my ubuntu machine. The weird part is that we also have a usb/firewire casing with IDE-connector and that one mounts perfectly fine, even if we switch disks.
The only errors I can find at the moment are listed below:

[ 190.919443] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
[ 190.919452] ieee1394: Node suspended: ID:BUS[0-00:1023]
GUID[0001db8000000264]
[ 199.782659] ieee1394: The root node is not cycle master capable;
selecting a new root node and resetting...
[ 200.054417] ieee1394: Node changed: 0-00:1023 -> 0-01:1023
[ 207.950743] ieee1394: Node resumed: ID:BUS[0-00:1023]
GUID[0001db8000000264]
[ 222.064682] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
[ 222.064693] ieee1394: Node suspended: ID:BUS[0-00:1023]
GUID[0001db8000000264]
[ 473.363111] ieee1394: Current remote IRM is not 1394a-2000 compliant,
resetting...
[ 473.634731] ieee1394: Node resumed: ID:BUS[0-00:1023]
GUID[0001db8000000264]
[ 473.635060] ieee1394: Node changed: 0-00:1023 -> 0-01:1023

A rescan-scsi-bus.sh doesn't help me out either.

The last thing I can find at the moment is the command gscanbus. This gives me a graphical user interface showing the Freecom disk being 'attached' to the ohci1394 module.

I hope someone can point me into the right direction. I've run out of search options. I'm probably overlooking something.

Kind Regards,

Wessel

unSpawn · 11-02-2008, 05:40 AM

Quote:

Originally Posted by wessel_k

The weird part is that we also have a usb/firewire casing with IDE-connector and that one mounts perfectly fine, even if we switch disks.

From working with a lot of different types of external devices I know some chipsets just won't work. Sure, that might not be the case here but since the other device loads OK, and even though (most if not all brands) don't list chipsets, there should be enough info floating around to pick one that's supported.

wessel_k · 11-02-2008, 01:44 PM

hanx, you triggered something.
I was able to retrieve the following information of my external drive through gscanbus:

SelfID Info
-----
Physical ID:0
Link Active: Yes
Gap Count: 63
PHY Speed: S400
PHY Delay: <=144ns
IRM Capable: Yes
Power Class: -1W
Port 0: Not connected
Port 1: Connected to parent node
Init. reset: No

CSR ROM Info
-----
GUID: 0c0001DB8000000264
Vendor ID: 0x00001B8C
Unit Spec ID: 0x0000609E
Unit SW Version: 0x00010483
Model ID: 0x0000353A
Nr. Textual Leafes: 1

Vendor: Unknown
Textual Leafes: Freecom

AV/C Subunits
N/A

So it seems to be recognized but after that it stops. Any hints to continue searching.The vendor doesn't seem to be recognized.

Hope you can help me further on this matter. Do you have any idea, what the 'root cycle master' is? Or IRM?

Regards,

Wessel

unSpawn · 11-02-2008, 05:39 PM

The "(root) cycle master" and "isochronous resource manager" are properties of the firewire protocol. Alas explaining ieee1394's initalisation cycle isn't exactly my cup of %{beverage}. Luckily the 'net is chockful of interesting docs wrt firewire architecture. You could boot a Live CD or build a vanilla kernel.org -current kernel and see if that recognises things. If that doesn't work maybe trawl the LKML for similar errors and possible workarounds.

Electro · 11-02-2008, 06:12 PM

Use fdisk -l before connecting the device and use it after the device is connected. It should list the new device using SCSI device nodes. In some cases it may not come up, so you may have to spy on the logs to know what device node the kernel or udev designates for the drive. Probably the kernel is waiting for the device to settle down or does not know what to do. You can try load up the sd and sbp2 module if they are not loaded.

Since IEEE-1394 uses SCSI when it access devices, you may have to use the same commands to add and remove SCSI devices.

Remove SCSI:
echo "scsi remove-single-device host channel ID LUN " > /proc/scsi/scsi

Add SCSI:
echo "scsi add-single-device host channel ID LUN " > /proc/scsi/scsi

You can get the host, channel, ID, and LUN using "cdrecord -scanbus".

I have not yet bought an IEEE-1394 storage device.

wessel_k · 11-04-2008, 02:41 PM

Working on it. Not getting anywhere yet. With a 2.6.27 kernel still getting the same message. Maybe the fact that I have a controller that mounts all my harddisks and usb cardreader as scsi/sd*.
Hope to find more tomorrow.

Regards,

Wessel

cjmueller · 12-12-2008, 03:52 PM

I had the same problem after getting a 1TB firewire drive from Freecom. Turned out the reason was that the code reading from the config ROM attempted to read too many bytes and the drive controller simply returned -- nothing, not even an error. Thus, the resulting data was incorrect, the IEEE stack considered this part of the config ROM invalid and the device recognition failed.

In order to hack around this issue, find the following code in .../drivers/ieee1394/csr1212.c and force the maximum number of bytes read from the config ROM to 4:

Code:

        if (!csr->ops->get_max_rom) {
                csr->max_rom = mr_map[0];       /* default value */
        } else {
                int i = csr->ops->get_max_rom(csr->bus_info_data,
                                              csr->private);
                if (i & ~0x3)
                        return -EINVAL;
                csr->max_rom = mr_map[i];
        }

        /* hack for Freecom 1TB drive: force max_rom to 4 */
        csr->max_rom = 4;

I also submitted a kernel bug to have a proper module parameter for this. Check out bug #12206 on kernel.org (sorry, on URL because this is my first post here)

Thanks,
--Christian

wessel_k · 12-13-2008, 09:28 AM

Great, looks like the solution to my problem. But now I have to play the noob. Where do I find that file? I can't seem to find it at the moment.

Do you know of a manual to get it done?

I'm a little clueless how to get this done. ;-)

Sorry.

But thanks in advance.

Regards,

Wessel

PS. which line(s) do I have to replace. Both or only the first/last one?

tredegar · 12-13-2008, 10:50 AM

cjmueller is saying that this is a bug in the kernel (or maybe a bug in the controller for your firewire disk that the kernel needs to work around)
He has posted to kernel.org about the bug here: http://bugzilla.kernel.org/show_bug.cgi?id=12206

It is interesting to read.

Quote:

In order to hack around this issue, find the following code in .../drivers/ieee1394/csr1212.c

He is suggesting you patch your kernel sourcecode, and then recompile the kernel. This can be a scary thing to do as a newbie, but feels really good when you have done it. A sort of "Linux rite of passage"

I am probably not the best person to help you do this (it's been a while since I last recompiled the kernel), but I'll do my best, or you can search LQ / internet search engine for "Recompile kernel HOWTO".

Basically you need to start by:
Installing build-essential so you can use the C compiler
Installing your running kernel version's sourcecode by using your package-manager to install linux-source and then untarring the file linux-source-2.6.24.tar.bz2 (warning: your kernel numbers may be different) that you will find installing linux-source has put in /usr/src.
Make sure you have linux-headers-Your-Kernel-Number installed.

Once you have done all that, you'll find the file cjmueller is referring to at /usr/src/linux-source-2.6.24/linux-source-2.6.24/drivers/ieee1394/csr1212.c (warning: your kernel numbers may be different) and you are in business.

The code he has given in bold is what needs to be added to that file (in the right place of course). The first line is a comment, the second, the fix.

Once you have made that change, recompile the kernel

This is quite a good tutorial, and was, I think, one of the HOWTOs I followed ( I see it is dated 2003, that's about right): http://www.linuxquestions.org/questi...36/#post379355

You do not need to make config ubuntu has already done all that for you, use your old config so follow that step where it says
cp /usr/src/linux-2.4.x/.config /usr/src/linux and then skip straight down to where it says "START HERE IF COMPILING A 2.6.x KERNEL"
This makes life easier for you.

If you run into problems, I suggest you start a new thread titled "Help compiling a new kernel", and let us know how far you got, what you tried, and what isn't working for you (error messages).

Good luck.

wessel_k · 12-13-2008, 11:07 AM

Wow, great just the help I needed. I'll make a new thread if necessary. One last question; So I add the lines below the right text file or do I need to replace the old ones, that's not completely clear to me.

Regards,

Wessel

tredegar · 12-13-2008, 11:21 AM

Quote:

One last question....

I just took a look at that file.
Here is the relevant block of code, which on my system starts at line 1442 but YMMV, so just open the file csr1212.c and search for int csr1212_parse_csr(struct csr1212_csr *csr) Then scroll down a bit.

Code:

int csr1212_parse_csr(struct csr1212_csr *csr)
{
	static const int mr_map[] = { 4, 64, 1024, 0 };
	struct csr1212_dentry *dentry;
	int ret;

	BUG_ON(!csr || !csr->ops || !csr->ops->bus_read);

	ret = csr1212_parse_bus_info_block(csr);
	if (ret != CSR1212_SUCCESS)
		return ret;

	if (!csr->ops->get_max_rom) {
		csr->max_rom = mr_map[0];	/* default value */
	} else {
		int i = csr->ops->get_max_rom(csr->bus_info_data,
					      csr->private);
		if (i & ~0x3)
			return -EINVAL;
		csr->max_rom = mr_map[i];
	}
        /* hack for Freecom 1TB drive: force max_rom to 4 */
        csr->max_rom = 4;
	csr->cache_head->layout_head = csr->root_kv;
	csr->cache_head->layout_tail = csr->root_kv;

	csr->root_kv->offset = (CSR1212_CONFIG_ROM_SPACE_BASE & 0xffff) +
		csr->bus_info_len;

	csr->root_kv->valid = 0;
	csr->root_kv->next = csr->root_kv;
	csr->root_kv->prev = csr->root_kv;
	ret = csr1212_read_keyval(csr, csr->root_kv);
	if (ret != CSR1212_SUCCESS)
		return ret;

	/* Scan through the Root directory finding all extended ROM regions
	 * and make cache regions for them */
	for (dentry = csr->root_kv->value.directory.dentries_head;
	     dentry; dentry = dentry->next) {
		if (dentry->kv->key.id == CSR1212_KV_ID_EXTENDED_ROM &&
			!dentry->kv->valid) {
			ret = csr1212_read_keyval(csr, dentry->kv);
			if (ret != CSR1212_SUCCESS)
				return ret;
		}
	}

	return CSR1212_SUCCESS;
}

I have made the patch for you, it is in red.

tredegar · 12-13-2008, 12:22 PM

I have been thinking about this (not always a "good thing").

I think that you should not have to recompile the whole kernel (this may take some time (eg > 2Hrs on a 1GHz PIII), depending on the speed of your CPU, but is fun to do).

All you really need to do (I think) is make the changes to that file and then just recompile the ieee1394 module. This should take moments rather than hours, and you won't have to worry about setting up booting to your new kernel. Look into compiling a single module, or just say "Here's my excuse to recompile my kernel. Let's go for it!".

If you get stuck and start another thread, please post a link to it here.

cjmueller · 12-15-2008, 02:26 AM

As a [minor] follow-up, I sometimes have to remove the firewire modules and load them again to have the drive detected properly. This can be done as follows:

Code:

sudo modprobe -r sbp2 raw1394 ohci1394
lsmod | grep ieee1394
sudo modprobe ohci1394 sbp2 raw1394

The "lsmod | grep ieee" should return nothing. If the modules are still loaded, try unmounting and disconnecting all remaining firewire devices.

BTW, the bug on kernel.org has caused the firewire maintainers to switch to a default of 4 bytes for config ROM access in the [old] ieee1394 drivers. This should eventually appear in the mainstream kernels.

BTW2, the new firewire-* drivers apparently already do this so the drive should work fine when using the new drivers. However, those new drivers are beta at this point and you will need 2.6.27 or better 2.6.28 to get a reasonable chance of success. If you want to try them, remove all the ieee drivers as outlined above, then load the new firewire-* drivers instead:

Code:

sudo modprobe -r sbp2 raw1394 ohci1394
sudo modprobe firewire-ohci

This requires the new drivers to be compiled into the kernel, of course. If the Ubuntu kernels don't have them, you're back to compiling your own kernel again.

Either way, if you have both sets of drivers (the old and the new stack) as modules, you need to blacklist one of them to prevent them from being loaded automatically. This can be done in /etc/modprobe.d/blacklist. Insert either "blacklist firewire-ohci" or "blacklist-ohci1394" into this file to disable the new or the old stack, respectively.

I didn't try the new stack, being on 2.6.22, but when I eventually move from Debian Etch to the upcoming release I might give it a shot.

wessel_k · 12-15-2008, 09:59 AM

Hi Guys,

I worked on it all weekend. I couldn't get the ieee1394 compiled by itself. And compiling the kernel caused some space issues. ;-) And it took quite a while to complete, although I thought I had the distcc up and running.
Anyway it works!!!!! You're great.

cjmueller; I read about the firewire-ohci, but I couldn't find it at first. But came across it during the compile. But the beta 'warning' scared me. ;-) So I used your first solution. And I'll wait for the official release.

But thanks for all your support! I'm not abandoning linux!!!

Regards,

Wessel

tredegar · 12-15-2008, 11:44 AM

Pleased you got it working. 6 posts and you've already managed to recompile your kernel, see, even "newbies" can do it! I hope you have a nice warm feeling.

@cjmueller,
Thanks for your useful and concise input, and a belated Welcome to LQ! I hope you choose to stay around