Description of problem: ohci1394 and ieee1394 modules are loaded, but sbp2 is not. I plug in a firewire HD and see the following (normal) message in /var/log/messages: ieee1394: Error parsing configrom for node 0-00:1023 and that's all. The disk is not detected, mounted or anything. Now if I modprobe sbp2, all that magic happens. I don't know whether it is hotplug that should auto-load sbp2 on demand, or it should be loaded earlier in the boot to stand by, but whatever should be loading it to enable filesystems to be auto-mounted is not working. Version-Release number of selected component (if applicable): package hotplug is not installed (I can't figure out what obsoleted it) initscripts-8.28-1 kernel-2.6.15-1.1948_FC5 How reproducible: Every time Steps to Reproduce: 1.Make sure sbp2 is not loaded, but ohci1394 and ieee1394 are 2.Plug in some firewire disk 3.Check whether sbp2 is loaded and that the filesystem in the disk is mounted Actual results: sbp2 is not loaded Expected results: It should be, I was told Additional info: If sbp2 is loaded by hand, even after the disk is plugged in, then the filesystem is mounted automatically at that time.
What happens if you run udevmonitor while you're plugging it in? When was the last time this worked?
I'll try udevmonitor tomorrow. As for when it worked, I've no idea if it ever did. I'd always had sbp2 loaded on boot, because the Firewire disks used to RAID-mirror my notebook's internal disk. I've now moved to a desktop with two internal disks, so I don't need external redundancy, so I assigned one of my external disks for backups.
# modinfo sbp2 .. alias: ieee1394:ven*mo*sp0000609Ever00010483* .. Hmm, how can this be automodprobed by udev? Any hints?
This is the relevant code from kernel/drivers/ieee1394/nodemgr.c:nodemgr_uevent() PUT_ENVP("VENDOR_ID=%06x", ud->vendor_id); PUT_ENVP("MODEL_ID=%06x", ud->model_id); PUT_ENVP("GUID=%016Lx", (unsigned long long)ud->ne->guid); PUT_ENVP("SPECIFIER_ID=%06x", ud->specifier_id); PUT_ENVP("VERSION=%06x", ud->version); snprintf(buf, sizeof(buf), "ieee1394:ven%08Xmo%08Xsp%08Xver%08X", ud->vendor_id, ud->model_id, ud->specifier_id, ud->version); PUT_ENVP("MODALIAS=%s", buf); Does this answer your question at all? I'm totally unfamiliar with udev, so I don't even know what kinds of constraints there are on what it can or cannot match.
Here's what I got from udevmonitor when I plugged my disk in with sbp2 not loaded: UEVENT[1140024873.042132] add@/devices/pci0000:00/0000:00:07.0/fw-host0/0010b92000d5b665 UEVENT[1140024873.042179] add@/class/ieee1394_node/0010b92000d5b665 UEVENT[1140024873.043910] add@/devices/pci0000:00/0000:00:07.0/fw-host0/0010b92000d5b665/0010b92000d5b665-0 UEVENT[1140024873.043934] add@/class/ieee1394/0010b92000d5b665-0 UEVENT[1140024873.043946] add@/devices/pci0000:00/0000:00:07.0/fw-host0/0010b92000d5b665/0010b92000d5b665-1 UEVENT[1140024873.043958] add@/class/ieee1394/0010b92000d5b665-1 UDEV [1140024873.128355] add@/devices/pci0000:00/0000:00:07.0/fw-host0/0010b92000d5b665 UDEV [1140024873.201695] add@/class/ieee1394_node/0010b92000d5b665 UDEV [1140024873.208862] add@/devices/pci0000:00/0000:00:07.0/fw-host0/0010b92000d5b665/0010b92000d5b665-0 UDEV [1140024873.215085] add@/devices/pci0000:00/0000:00:07.0/fw-host0/0010b92000d5b665/0010b92000d5b665-1 UDEV [1140024873.216013] add@/class/ieee1394/0010b92000d5b665-0 UDEV [1140024873.231602] add@/class/ieee1394/0010b92000d5b665-1
Does the modalias file under the /sys/class/iee1394* directories match "ieee1394:ven*mo*sp0000609Ever00010483*"?
I'm trying to figure out how udev manages to autoload usb-storage, to try to model the loading of sbp2 after that, but I can't find any reference to usb-storage in neither /etc/udev nor /lib/modules/`uname -r`/modules.alias. I don't see any modalias file at all within /sys/class/ieee1394*. They're only present in /sys/class/input on my box, even after plugging in the same external disk using its USB interface.
Aha, found the modalias thingie for the USB case. udevmonitor displays: UEVENT[1140027362.525575] add@/devices/pci0000:00/0000:00:10.4/usb1/1-2 UEVENT[1140027362.525650] add@/devices/pci0000:00/0000:00:10.4/usb1/1-2/1-2:1.0 UEVENT[1140027362.525672] add@/class/usb_device/usbdev1.5 and I do see the modalias file in /sys/devices/pci0000:00/0000:00:10.4/usb1/1-2/1-2:1.0 That file says: usb:v0D49p5020d0100dc00dsc00dp00ic08isc06ip50 I still can't figure out how udev goes from that usb-storage.
usb-storage is weird, because of ub. It's not a good test case. :)
See also bug report 173085
Just tried modprobe sbp2 in a console window on my test system with the two firewire disks attached and powered that I have reported problems with in bug report 173085 and another one which I normally use on a windows only machine all the partitions appear in the computer folder but nothing shows up on the desktop at this stage nor do they appear in media. One drive is split 20gig NTFS 60gig EXT3 the other normally attached to the test machine is a single 160gig EXT3 partition and the drive which is normally on my windows only machine is split into 3 partitions one 80gig NTFS and two FAT32(VFAT) of 30gig and 5gig. Selecting and opening any of the FAT32 partitions results in a folder in media which opens for browsing on the desktop and a corresponding firewire disc icon on the desktop. Selecting and opening any NTFS partition you get two boxes appear both with the error icon one box has no title and just an OK button the other box is titled error and has the expected text that explains that the NTFS file system is unsupported. Selecting and opening any of the EXT3 partitions results in a folder appearing in media but this time you dont have to refresh to see it. The folder does not open automatically nor does it get an icon on the desktop. Opening the folder reveals its contents as expected. Selecting and opening the an EXT3 partition in computer a second time results in two boxes one with no title the error icon and an OK button and another titled error with an error icon an OK button and text saying canot mount volume. Doing the same for a FAT32 partition results in afolder opening on the desktop as expected. I hope this errors of no icons on the desktop for EXT3 partitions and the error behaviour described will not be present when hotplug mounting and mounting when already connected at boot gets fixed. NB the same behaviour is seen for the EXT3 partitions if the drive is hotpluged or attached at boot via its alternate USB interface. It appears in computer (with a USB disk icon) but not in media and when you select and open it then it appears in media and you can use it but you get the same error boxes as before if you try to open it a second time. Is this error behavior a problem with gnome-mount and not as a result of the way the device was descovered and made available for mounting.
*** Bug 182230 has been marked as a duplicate of this bug. ***
I did the same test as suggested, running udevmonitor while plugging in the drive. Interesting though, I only got the following line in /var/log/messages, but nothing appeared in the udevmonitor window: Feb 24 08:21:10 fgrbhw01 kernel: ieee1394: Error parsing configrom for node 0-00:1023 This is a firewire drive plugged into a Soundblaster Audigy 4 Pro IEEE port. The fix from Stefan (scsi_mod param_dev=8192) is applied, to circumvent the slab_free bug in scsi_mod. sbp2 gets not loaded, but if udevmonitor is empty, then it can't, right? What can I do next? Thanks, Ron
Created attachment 125660 [details] Apply this to /etc/udev/rules.d/50-udev.rules It appears the ieee1394 subsystem is rather broken, and doesn't actually generate modaliases. So nothing will ever get loaded, unless you whack it in by hand. If your device has already been plugged in, you'll need to unload/reload ohci1394 to get this rule to take effect; ohci1394 treats disconnect/reconnect as device suspend/resume, and doesn't actually generate new events when you reconnect. Long term, the kernel needs fixed. This is just papering over it for sbp2 (have't looked at other 1394 devices just yet.)
Strike that. The much simpler solution is to change: ACTION=="add", SUBSYSTEM=="?*", MODALIAS=="?*", RUN+="/sbin/modprobe $modalias" to ACTION=="add", SUBSYSTEM=="?*", MODALIAS=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
Make that: ACTION=="add", SUBSYSTEM=="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
Should be fixed in udev-084-11.
It works at the time a firewire disk is connected, indeed. Unfortunately, that's not quite enough to get users to mount/unmount filesystems in Firewire disks that are plugged in at boot time, and that can't be plugged out (say because they contain not only user-mountable filesystems, but also RAID 1 replicas of /, or even the / device itself). Is there any possibility of a solution for this? Couldn't say udevstart create the mount points after / is mounted read-write or something like that? Or could it have some user-accessible means to pretend a disk was plugged back in without having to physically mess with it, or remove a module that is busy?
udevstart doesn't care about mount points, or mounting filesystems. That is the provence of things like gnome-mount, etc. It sounds like a completely separate problem outside of support for making sure firewire devices are found (please file seperately.)
Aah, that would explain it. I'm seldom actually logged in on that box and, when I am, it's in a non-gnome fail-safe section, to use it as a vnc client. I'll see if logging into gnome helps and file a separate bug rerpot if it doesn't.
Confirmed, logging into gnome automatically mounts the filesystem from an external disk that was plugged in before boot time. Too bad I couldn't figure out how to use gnome-mount from a ssh session. I wonder if that is even supposed to be possible. I guess not :-(