Bug 181494

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 :-(