Bug 181494 - sbp2 not loaded when firewire disk is connected, so no auto mounting on hot plug
sbp2 not loaded when firewire disk is connected, so no auto mounting on hot plug
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
: 182230 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-14 12:16 EST by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 084-11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-06 13:56:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Apply this to /etc/udev/rules.d/50-udev.rules (465 bytes, patch)
2006-03-05 00:05 EST, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Alexandre Oliva 2006-02-14 12:16:54 EST
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.
Comment 1 Bill Nottingham 2006-02-14 12:18:28 EST
What happens if you run udevmonitor while you're plugging it in?

When was the last time this worked?
Comment 2 Alexandre Oliva 2006-02-14 23:01:15 EST
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.
Comment 3 Harald Hoyer 2006-02-15 06:56:23 EST
# modinfo sbp2
..
alias:          ieee1394:ven*mo*sp0000609Ever00010483*
..

Hmm, how can this be automodprobed by udev? Any hints?
Comment 4 Alexandre Oliva 2006-02-15 12:46:15 EST
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.
Comment 5 Alexandre Oliva 2006-02-15 12:47:22 EST
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
Comment 6 Bill Nottingham 2006-02-15 12:50:16 EST
Does the modalias file under the /sys/class/iee1394* directories match
"ieee1394:ven*mo*sp0000609Ever00010483*"?
Comment 7 Alexandre Oliva 2006-02-15 13:04:11 EST
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.
Comment 8 Alexandre Oliva 2006-02-15 13:24:19 EST
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.
Comment 9 Bill Nottingham 2006-02-15 14:13:28 EST
usb-storage is weird, because of ub. It's not a good test case. :)
Comment 10 David Bentley 2006-02-18 11:27:07 EST
See also bug report 173085
Comment 11 David Bentley 2006-02-19 09:12:12 EST
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.
Comment 12 Bill Nottingham 2006-02-21 12:07:41 EST
*** Bug 182230 has been marked as a duplicate of this bug. ***
Comment 13 Ronny Bremer 2006-02-24 02:18:37 EST
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
Comment 14 Bill Nottingham 2006-03-05 00:05:06 EST
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.)
Comment 15 Bill Nottingham 2006-03-05 00:35:17 EST
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}"

Comment 16 Bill Nottingham 2006-03-05 00:52:16 EST
Make that:

ACTION=="add", SUBSYSTEM=="?*", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe
$env{MODALIAS}"
Comment 17 Bill Nottingham 2006-03-05 01:12:24 EST
Should be fixed in udev-084-11.
Comment 18 Alexandre Oliva 2006-03-06 13:46:08 EST
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?
Comment 19 Bill Nottingham 2006-03-06 13:56:35 EST
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.)
Comment 20 Alexandre Oliva 2006-03-06 15:26:39 EST
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.
Comment 21 Alexandre Oliva 2006-03-07 23:35:19 EST
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 :-(

Note You need to log in before you can comment on or make changes to this bug.