cdrom links are not created as well. Device hdc is there but no link. Is this the job of 
udev now? 
Thanks 

Some more info on the SCSI tape case: The tape uses the qla1280 driver, which is loaded    
via modprobe.conf. This is the 2nd scsi adapter, the first one being the internal disk.    
Modules are all loaded properly, just no device nst0 and logical link. Does SYMLINK have to be   
on the ACTION line?  I am all confused. Below is the output of udevinfo for nst0. 
 
=================================================== 
 
 
  # udevinfo -a -p `udevinfo -q path -n /dev/nst0` 
 
udevinfo starts with the device the node belongs to and then walks up the 
device chain, to print for every device found, all possibly useful attributes 
in the udev key format. 
Only attributes within one device section may be used together in one rule, 
to match the device for which the node will be created. 
 
device '/sys/class/scsi_tape/nst0' has major:minor 9:128 
  looking at class device '/sys/class/scsi_tape/nst0': 
    SUBSYSTEM=="scsi_tape" 
    SYSFS{default_blksize}=="-1" 
    SYSFS{default_compression}=="-1" 
    SYSFS{default_density}=="-1" 
    SYSFS{defined}=="1" 
    SYSFS{dev}=="9:128" 
 
follow the "device"-link to the physical device: 
  looking at the device chain at 
'/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0/host2/target2:0:2/2:0:2:0': 
    BUS=="scsi" 
    ID=="2:0:2:0" 
    DRIVER=="st" 
    SYSFS{device_blocked}=="0" 
    SYSFS{iocounterbits}=="32" 
    SYSFS{iodone_cnt}=="0x24d88" 
    SYSFS{ioerr_cnt}=="0x1" 
    SYSFS{iorequest_cnt}=="0x24d88" 
    SYSFS{model}=="SDT-9000        " 
    SYSFS{queue_depth}=="3" 
    SYSFS{queue_type}=="none" 
    SYSFS{rev}=="0400" 
    SYSFS{scsi_level}=="3" 
    SYSFS{state}=="running" 
    SYSFS{timeout}=="900" 
    SYSFS{type}=="1" 
    SYSFS{vendor}=="SONY    " 
 
  looking at the device chain at 
'/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0/host2/target2:0:2': 
    BUS=="" 
    ID=="target2:0:2" 
    DRIVER=="unknown" 
 
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0/host2': 
    BUS=="" 
    ID=="host2" 
    DRIVER=="unknown" 
 
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0': 
    BUS=="pci" 
    ID=="0000:02:09.0" 
    DRIVER=="qla1280" 
    SYSFS{class}=="0x010000" 
    SYSFS{device}=="0x1020" 
    SYSFS{irq}=="177" 
    SYSFS{local_cpus}=="00000001" 
    SYSFS{modalias}=="pci:v00001077d00001020sv00002050sd00005349bc01sc00i00" 
    SYSFS{subsystem_device}=="0x5349" 
    SYSFS{subsystem_vendor}=="0x2050" 
    SYSFS{vendor}=="0x1077" 
 
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0': 
    BUS=="pci" 
    ID=="0000:00:1e.0" 
    DRIVER=="unknown" 
    SYSFS{class}=="0x060400" 
    SYSFS{device}=="0x244e" 
    SYSFS{irq}=="0" 
    SYSFS{local_cpus}=="00000001" 
    SYSFS{modalias}=="pci:v00008086d0000244Esv00000000sd00000000bc06sc04i00" 
    SYSFS{subsystem_device}=="0x0000" 
    SYSFS{subsystem_vendor}=="0x0000" 
    SYSFS{vendor}=="0x8086" 
 
  looking at the device chain at '/sys/devices/pci0000:00': 
    BUS=="" 
    ID=="pci0000:00" 
    DRIVER=="unknown" 
 
   
    

Note the  SUBSYSTEM=="scsi_tape" line. The line in 50-udev.rules say SUBSYSTEM=="scsi", 
is this a contradiction? 

yes, "scsi_tape" != "scsi" ^^ This would explain the missing tape device.

Well, that change did not do it (just changing the rules file).

When I boot there is no class/scsi_tape either under /sys or in /dev/.udevdb/.
If I "modprobe st" then they are created.

What can I do?

ah, loading the st module was the job of hotplug

Switching component back, as this will get fixed in udev regardless.

Does scsi_mod & sd_mod get loaded correctly? If so, are those loaded from the
initrd, or from udev?

Yes, they are loaded correctly.

They are loaded from initrd since I have a scsi system. Here are the modules
in initrd:

ext3.ko  jbd.ko  mptbase.ko  mptscsih.ko  qla1280.ko  scsi_mod.ko  sd_mod.ko

qla1280.ko is for the second scsi adapter on which only the external tape is
attached.

Out of curiousity, what happens if you make the initrd without qla1280?

I have a long job running on the machine that I don't want to kill write now.
I'll try this as soon as possible.

What I suspect is happening here is that you're not getting the hotplug event
for the scsi tape device, because the adapter is being loaded in the initrd.

If you were to do 'modprobe -r qla1280 ; modprobe qla1280' I *suspect* the node
would be created correctly.

Fixed in 063-2; we were improperly setting SEQNUM on scsi replay events. This
should get handled correctly at boot now.

Unfortunately that did not solve my problem. When I remove the qla1280 from the 
initrd than the module is not loaded after a boot. This has been the case in the past 
and that is why I added that into modprobe.conf. 
 
Doing a "modprobe qla1280" does load the module as well as the st module and creates all 
the /dev/nst0 etc. 
 
The tape is attached to an old Qlogic ISP1020 adapter (only used externally), which now 
is also managed by the qla1280 module. 
 
The line that I put into /etc/modprobe.conf are: 
 
alias scsi_hostadapter2 qla1280 
install qla1280 /sbin/modprobe --ignore-install qla1280 
 
The tape is SONY SDT-9000, which is on during the boot. As I said I had this problem before 
udev (device not being detected). 
 
Any ideas? 

Hm, 063-2 didn't help at all?

I don't have a tape device, so I was testing with sd_mod; it worked in testing here.

Well, I just looked into the boot log and the adapter is reported by QLA1280 to 
be QLA1040 as shown below. This used to be ISP1020 but they changed names 
I guess. Where does one put this association to tell them to load qla1280 driver. 
I don't see the PCI ID in the hwdata. 
 
================================================================= 
 
Jul 20 08:04:54 compsci kernel: qla1280: QLA1040 found on PCI bus 2, dev 9 
Jul 20 08:04:54 compsci kernel: scsi(2:0): Resetting SCSI BUS 
Jul 20 08:04:54 compsci kernel: scsi2 : QLogic QLA1040 PCI to SCSI Host Adapter 
Jul 20 08:04:54 compsci kernel:        Firmware version:  7.65.00, Driver version 3.25 
Jul 20 08:04:54 compsci kernel:   Vendor: SONY      Model: SDT-9000          Rev: 0400 
Jul 20 08:04:54 compsci kernel:   Type:   Sequential-Access                  ANSI SCSI 
revision: 02 
Jul 20 08:04:54 compsci kernel: scsi(2:0:2:0): Sync: period 10, offset 12 
 

OK, I think we're talking cross-purposes now.

The new udev-063-2 should work with *whatever* your initrd was before (i.e.,
with both scsi adapters in it). The comments before about changing what was in
the initrd were for debugging, attempting to figure out where the failure was.

OK. This is the summary: 
 
  1. Without qla1280 in the initrd hotplug *never* found this device (going back the FC2/FC3 
      days). In the past the driver was called qlogicisp, which was recently changed to be a 
      submodule for qla1280. 
 
  2. When the qla1280 was in initrd something loaded the "st" module and created the device 
       nodes and the logical link to tape. I don't exactly know when this stopped working 
       but it is at most a week or two. 
 
       So, it seems like as hotplug functions are transferred to udev this device, which had prolems 
       to begin with, has fallen into the undefined zone! 
 
Please let me know what other information I can supply. 

1. is a module bug, it needs to export PCI ids correctly.

The new udev (063-2) does not solve #2?

No. 063-2 does not solve "2" i.e. it does not load the "st" module.

I am sorry for the delayed response but I am running very long jobs and I
have to wait till they finish before reboot.

Thanks

I have found/added the following to rc.sysinit file that does the job: 
 
# If a SCSI tape has been detected, load the st module unconditionally 
# since many SCSI tapes don't deal well with st being loaded and unloaded 
if [ -f /proc/scsi/scsi ] && LC_ALL=C grep -q 'Type:   Sequential-Access' /proc/scsi/scsi 
2>/dev/null ; then 
      LC_ALL=C fgrep -q ' 9 st' /proc/devices || modprobe st >/dev/null 2>&1 
fi 
 
It is not the desired way but does the job. 

Created attachment 117246 [details]
change to /sbin/start_udev

Can you try this patch to /sbin/start_udev?

Relaying the hotplug events via udev doesn't seem to quite make sense if udev
isn't running at the time.

No, it did not help. Furhermore, during boot it gave the [FAILED] message
when udev was starting but continued anyway. No tape devices were created.

One more thing; after doing "modprobe st" now only devices created are nst0a, nst0l, and 
nst0m. No logical link to tape and no nst0. This is using the udev from rawhide and the above 
lines in rc.sysinit. 
 
This used to work fine with the latest udev so it may have to do with MAKEDEV removal. 
 

OK.... udev-063-6 seems to have solved the problem! 
Thanks, CLOSING.