On Sat, 03 Dec 2005 03:30:56 +0100, Jean-David Beyer <jdbeyer@exit109.com> wrote:

> Enrique Perez-Terron wrote:
[...]
>> Check the file /proc/sys/kernel/hotplug. On my system it contains
>> "/sbin/udevsend".
>
> On my system (CentOS 4.2), it is:
>
> /sbin/hotplug
>
> There is a man page for hotplug.
> It refers me to /etc/hotplug and in there is a file scsi.agent that contains:
>
> #!/bin/sh
> #
> # SCSI hotplug agent for 2.5 kernels
> #
> # ACTION=add
> # DEVPATH=devices/scsi0/0:0:0:0
> #
>
> cd /etc/hotplug
> . ./hotplug.functions
>
> case $ACTION in
>
> add)
> # 2.5.50 kernel bug: this happens sometimes
> if [ ! -d /sys/$DEVPATH ]; then
> mesg "bogus sysfs DEVPATH=$DEVPATH"
> exit 1
> fi
>
> TYPE_ATTR=/sys$DEVPATH/type
>
> # Possibly sleep here to try and avoid races with scsi attributes and block
> # devices
> count=10
> while [ ! -f $TYPE_ATTR -a $count -gt 0 ]
> do
> # We seem to always hit this now, so don't output any message.
> debug_mesg "waiting for $TYPE_ATTR"
> sleep 1
> count=$(($count-1))
> done
>
> if [ ! -f $TYPE_ATTR ]
> then
> mesg "Attribute $TYPE_ATTR does not exist"
> exit 1
> fi
>
> TYPE=$(cat $TYPE_ATTR)
> case "$TYPE" in
> # 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
> 0) TYPE=disk ; MODULE=sd_mod ;;
> # FIXME some tapes use 'osst' not 'st'
> 1) TYPE=tape ; MODULE=st ;;
> 2) TYPE=printer ; MODULE=sg ;;
> 3) TYPE=processor ; MODULE=sg ;;
> 4) TYPE=worm ; MODULE=sr_mod ;;
> 5) TYPE=cdrom ; MODULE=sr_mod ;;
> 6) TYPE=scanner ; MODULE=sg ;;
> 7) TYPE=mod ; MODULE=sd_mod ;;
> 8) TYPE=changer ; MODULE=sg ;;
> 9) TYPE=comm ; MODULE=sg ;;
> 14) TYPE=enclosure ; MODULE=sg ;;
> esac
> if [ "$MODULE" != "" ]; then
> mesg "$TYPE at $DEVPATH"
> modprobe $MODULE
> else
> debug_mesg "how to add device type=$TYPE at $DEVPATH ??"
> fi
> ;;
>
> *)
> debug_mesg SCSI $ACTION event not supported
> exit 1
> ;;
>
> esac
>
> Now if I knew what number code I would get, or what $TYPE_ATTR I would get
> for my cd-rom burner, I could just put a line in there that said, e.g.,
>
> 10) TYPE=cdromburner ; MODULE=sg ;;
>
> in there.

But isn't the file /sys/devices/whatever.../type present on your system?

I think it should be possible to do lspci, and use the output to exclude
most of the irrelevant parts of the /sys/devices file tree. There should
be just one or a handfull directories left to investigate manually.

The first question is if this script is already being called with your
device, but the script does not do the right thing at that point, or
is the hotplug system just not seing the cd burner, PleXWriter, or is it
seeing it before /sbin/hotplug is installed and the udev systems starrted.

In the first case, you could perhaps instrument the script with some
logging, have it show for each invocation what environment variables
it is being called with, and what actions it is taking.

In the latter case, one needs to investigate the existing infrastructure
for simulating hotplug events for devices that are discovered early.

[...]
>> /sbin/udevsend starts /sbin/udevd, a daemon, unless it already runs. Then
>> it sends it a message. /sbin/udevd somehow reorders events that arrive
>> close in time, and starts the program /sbin/udev with each.
>
> At the present moment, udevd is running (according to pstree).

OK, interesting. Would be nice to know what the difference really is,
between /sbin/hotplug and /sbin/udevsend.

[...]
>> This is purely a guess on my part: install a call to modprobe anywhere
>> you like, e.g., in /etc/rc.d/rc.local, but use the udev machinery to set
>> up the /dev nodes.
>
> I do not have to set up the /dev nodes. As soon as I load the sg module,
> with
>
> /sbin/modprobe sg
>
> the /dev nodes are created.

Ah, so some hotplug events are generated by the module once it gets loaded,
and your existing infrastructure knows already how to deal with that.

What is missing is something to trigger the loading of this module.
I suppose the "Symbios SYM20810 PCI to Fast SCSI Host Adapter" does appear
in lspci, and has some directory nodes in the /sys/devices tree. Something
there should be the trigger for the missing thing.

What does this part of the device tree look like? Are any attached devices
visible before you load the sg driver? What driver does scsi host adapter
use? If the attached device is not visible, the presence (or the discovery)
of the host adapter should trigger a program or sequence of events that
lead to the discovery and enumeration of the attached devices. The missing
piece of logic must somehow attach to that.

In the end this will lead to an amendment of the distro scripts that could
be contributed. That is the point I see in not just sticking modprobe
commands in rc.local, to generate something that fits in the general
framework, is maintainable, and will load the correct modules on any
computer, not just your.

-Enrique