Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163729 - udev not creating scsi tape devices
Summary: udev not creating scsi tape devices
Alias: None
Product: Fedora
Classification: Fedora
Component: udev
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-07-20 18:13 UTC by Sammy
Modified: 2014-03-17 02:54 UTC (History)
1 user (show)

Fixed In Version: 063-2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-08-05 15:53:03 UTC

Attachments (Terms of Use)
change to /sbin/start_udev (deleted)
2005-07-28 21:07 UTC, Bill Nottingham
no flags Details | Diff

Description Sammy 2005-07-20 18:13:24 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux; X11; en_US) KHTML/3.4.2 (like Gecko)

Description of problem:
Afer updating udev, hotplug, mkinitrd (and recreating the boot image) and  
booting my external scsi tape devices are not created. The tape is recognized  
and is there. Before I used to get nstXX devices and a logical link from tape to nst0.  
Going into /dev directory and "MAKEDEV nst" creates all the nst devices and the  
tape is usable.  
PS: I have all packages at rawhide level except kernel, which is 2.6.12-1.1398_FC4smp 
      due to a bug in fusion mpt drivers that panic during boot. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Upgrade to latest udev, hotplug, mkinitrd 
2. reboot 
3. try to use tape 

Additional info:

Comment 1 Sammy 2005-07-21 14:03:55 UTC
cdrom links are not created as well. Device hdc is there but no link. Is this the job of 
udev now? 

Comment 2 Sammy 2005-07-21 18:35:28 UTC
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': 
follow the "device"-link to the physical device: 
  looking at the device chain at 
    SYSFS{model}=="SDT-9000        " 
    SYSFS{vendor}=="SONY    " 
  looking at the device chain at 
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0/host2': 
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0': 
  looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0': 
  looking at the device chain at '/sys/devices/pci0000:00': 

Comment 3 Sammy 2005-07-21 18:41:30 UTC
Note the  SUBSYSTEM=="scsi_tape" line. The line in 50-udev.rules say SUBSYSTEM=="scsi", 
is this a contradiction? 

Comment 4 Harald Hoyer 2005-07-22 06:17:40 UTC
yes, "scsi_tape" != "scsi" ^^ This would explain the missing tape device.

Comment 5 Sammy 2005-07-22 13:37:19 UTC
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?

Comment 6 Harald Hoyer 2005-07-22 14:31:48 UTC
ah, loading the st module was the job of hotplug

Comment 7 Bill Nottingham 2005-07-22 16:24:23 UTC
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?

Comment 8 Sammy 2005-07-22 18:00:38 UTC
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

Comment 9 Bill Nottingham 2005-07-22 18:20:50 UTC
Out of curiousity, what happens if you make the initrd without qla1280?

Comment 10 Sammy 2005-07-22 18:26:11 UTC
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.

Comment 11 Bill Nottingham 2005-07-22 21:25:07 UTC
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.

Comment 12 Bill Nottingham 2005-07-25 03:06:20 UTC
Fixed in 063-2; we were improperly setting SEQNUM on scsi replay events. This
should get handled correctly at boot now.

Comment 13 Sammy 2005-07-25 20:33:55 UTC
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? 

Comment 14 Bill Nottingham 2005-07-25 20:52:11 UTC
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.

Comment 15 Sammy 2005-07-26 00:59:08 UTC
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 

Comment 16 Bill Nottingham 2005-07-26 01:22:48 UTC
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.

Comment 17 Sammy 2005-07-26 13:59:40 UTC
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. 

Comment 18 Bill Nottingham 2005-07-26 16:27:10 UTC
1. is a module bug, it needs to export PCI ids correctly.

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

Comment 19 Sammy 2005-07-27 13:23:11 UTC
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.


Comment 20 Sammy 2005-07-28 18:21:56 UTC
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 
It is not the desired way but does the job. 

Comment 21 Bill Nottingham 2005-07-28 21:07:55 UTC
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.

Comment 22 Sammy 2005-08-02 13:01:53 UTC
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.

Comment 23 Sammy 2005-08-02 15:08:03 UTC
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. 

Comment 24 Sammy 2005-08-05 15:53:03 UTC
OK.... udev-063-6 seems to have solved the problem! 
Thanks, CLOSING. 

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