I have 4 scsi tape drives. udev correctly creates /dev/st{0,3} and /dev/nst{0-3} however some links created in /dev/tape/by-id are missing or just plain wrong. In my case, two of the drives are DLT-8000's in a storagetek L80, one each on a channel of a 3944AUWD. one channel has the Changer on it also. Since I don't always have the L80 powered on, I can't use the nst device directly because the numbers change. Reproducible: Always Actual Results: lrwxrwxrwx 1 root root 10 Nov 22 16:43 scsi--nst -> ../../nst3 lrwxrwxrwx 1 root root 10 Nov 22 16:28 scsi-1HP_C7438A_HU107108XD-nst -> ../../nst1 lrwxrwxrwx 1 root root 10 Nov 22 16:28 scsi-1HP_Ultrium_1-SCSI_HU84H06998-nst -> ../../nst0 lrwxrwxrwx 1 root root 9 Nov 22 16:43 scsi-200e09e6000046d46 -> ../../st3 lrwxrwxrwx 1 root root 9 Nov 22 16:43 scsi-200e09e6000051628 -> ../../st2 lrwxrwxrwx 1 root root 10 Nov 22 16:44 scsi-SSTK_L80_LLC02205205 -> ../../sg11 lrwxrwxrwx 1 root root 10 Nov 22 16:28 usb-HP_C7438A_4855310710385844-0:0 -> ../../st1m Expected Results: Line 1, scsi--nst -> ../../nst3 is garbage. a link to st0 is missing a link to nst2 is missing paludis --info paludis 0.26.0_alpha4 Paludis build information: Compiler: CXX: x86_64-pc-linux-gnu-g++ 4.1.2 (Gentoo 4.1.2) CXXFLAGS: -march=nocona -O2 -pipe -mno-tls-direct-seg-refs -g LDFLAGS: DATE: 2007-11-22T17:15:04+1300 Libraries: C++ Library: GNU libstdc++ 20070214 Reduced Privs: reduced_uid: 101 reduced_uid->name: paludisbuild reduced_uid->dir: /dev/null reduced_gid: 407 reduced_gid->name: paludisbuild Paths: DATADIR: /usr/share LIBDIR: /usr/lib64 LIBEXECDIR: /usr/libexec SYSCONFDIR: /etc PYTHONINSTALLDIR: RUBYINSTALLDIR: Repository virtuals: format: virtuals Repository installed-virtuals: root: / format: installed_virtuals Repository gentoo: format: ebuild layout: traditional location: /var/portage profiles: /var/portage/profiles/default-linux/amd64/2007.0 cache: /var/portage/metadata/cache write_cache: /var/portage/.cache/write append_repository_name_to_write_cache: true ignore_deprecated_profiles: false names_cache: /var/portage/.cache/names distdir: /var/portage/distfiles eclassdirs: /var/portage/eclass securitydir: /var/portage/metadata/glsa setsdir: /var/portage/sets newsdir: /var/portage/metadata/news sync: rsync://rsync.au.gentoo.org/gentoo-portage sync_options: builddir: /var/tmp/paludis eapi_when_unknown: 0 eapi_when_unspecified: 0 profile_eapi: 0 Package information: app-admin/eselect-compiler: (none) app-shells/bash: 3.2_p17 dev-java/java-config: (none) dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/confcache: (none) sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13 2.61-r1 sys-devel/automake: 1.10 1.4_p6 1.5 1.6.3 1.7.9-r1 1.8.5-r3 1.9.6-r2 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 (for sys-kernel/linux-headers::installed)
Created attachment 137074 [details] tapeinfo on all generics
Created attachment 137078 [details] run scsi_id manually I had no success getting scsi_id to work using --device=/dev/st0. Odd.
whoops, I've just realised that the listing of tape/by-id was done a few days ago (I.e I've rebooted) it is now scsi--nst -> ../../nst2 scsi-1HP_C7438A_HU107108XD-nst -> ../../nst3 scsi-200e09e6000046d46-nst -> ../../nst1 scsi-200e09e6000051628 -> ../../st0 scsi-SSTK_L80_LLC02205205 -> ../../sg2 usb-HP_C7438A_4855310710385844-0:0 -> ../../st3
hi, thanks for the initial data. Could I get you to produce some more specific output for me? You'll need to do 2-4 with no reboots between them, and all of your devices turned on, so the numbering all corresponds. 1. emerge lsscsi 2. lsscsi -H -t 3. lsscsi --list -g -d 4. manually run scsi_id for every applicable device from #3 (generics, disks, tapes), just like you did for the existing tapes. I suspect the scsi--nst cases are the locking issue that I originally described when I wrote the tape-id stuff biting us.
here's lsscsi -H -t [0] aic7xxx spi: [1] aic7xxx spi: [2] sym53c8xx spi: [3] sym53c8xx spi: [4] ahci [5] ahci [6] ahci [7] ahci [8] ahci [9] ahci [10] ata_piix [11] ata_piix [12] mptsas sas:0x500605b0004271c0 [13] usb-storage Here is lsscsi --list -g -d [0:0:0:0] tape QUANTUM DLT8000 0233 /dev/st0[9:0] /dev/sg0[21:0] device_blocked=0 iocounterbits=32 iodone_cnt=0x11 ioerr_cnt=0x3 iorequest_cnt=0x11 queue_depth=2 queue_type=none scsi_level=3 state=running timeout=900 type=1 [1:0:0:0] tape QUANTUM DLT8000 0233 /dev/st1[9:1] /dev/sg1[21:1] device_blocked=0 iocounterbits=32 iodone_cnt=0x11 ioerr_cnt=0x3 iorequest_cnt=0x11 queue_depth=2 queue_type=none scsi_level=3 state=running timeout=900 type=1 [1:0:15:0] mediumx STK L80 0215 - /dev/sg2[21:2] device_blocked=0 iocounterbits=32 iodone_cnt=0x1d ioerr_cnt=0x1 iorequest_cnt=0x1d queue_depth=2 queue_type=none scsi_level=4 state=running timeout=0 type=8 [3:0:3:0] tape HP Ultrium 1-SCSI N27D /dev/st2[9:2] /dev/sg3[21:3] device_blocked=0 iocounterbits=32 iodone_cnt=0x11 ioerr_cnt=0x2 iorequest_cnt=0x11 queue_depth=2 queue_type=none scsi_level=4 state=running timeout=900 type=1 [6:0:0:0] cd/dvd ASUS DRW-1814BLT 1.13 /dev/sr0[11:0] /dev/sg4[21:4] device_blocked=0 iocounterbits=32 iodone_cnt=0x13 ioerr_cnt=0x0 iorequest_cnt=0x8b2 queue_depth=1 queue_type=none scsi_level=6 state=running timeout=0 type=5 [10:0:1:0] disk ATA WDC WD1600BB-22G 08.0 /dev/sda[8:0] /dev/sg5[21:5] device_blocked=0 iocounterbits=32 iodone_cnt=0x3c3 ioerr_cnt=0x0 iorequest_cnt=0x3c3 queue_depth=1 queue_type=none scsi_level=6 state=running timeout=60 type=0 [12:0:0:0] disk ATA ST3250620NS BJH - /dev/sg6[21:6] device_blocked=0 iocounterbits=32 iodone_cnt=0x4 ioerr_cnt=0x1 iorequest_cnt=0x4 queue_depth=64 queue_type=simple scsi_level=6 state=running timeout=60 type=0 [12:0:1:0] disk ATA ST3250620NS BJH - /dev/sg7[21:7] device_blocked=0 iocounterbits=32 iodone_cnt=0x4 ioerr_cnt=0x1 iorequest_cnt=0x4 queue_depth=64 queue_type=simple scsi_level=6 state=running timeout=60 type=0 [12:0:2:0] disk HP DF036A8B55 HPD7 /dev/sdb[8:16] /dev/sg8[21:8] device_blocked=0 iocounterbits=32 iodone_cnt=0x461 ioerr_cnt=0x0 iorequest_cnt=0x461 queue_depth=64 queue_type=simple scsi_level=6 state=running timeout=60 type=0 [12:0:3:0] disk HP DF036A8B55 HPD7 /dev/sdc[8:32] /dev/sg9[21:9] device_blocked=0 iocounterbits=32 iodone_cnt=0x3bd ioerr_cnt=0x0 iorequest_cnt=0x3bd queue_depth=64 queue_type=simple scsi_level=6 state=running timeout=60 type=0 [12:1:1:0] disk LSILOGIC Logical Volume 3000 /dev/sdd[8:48] /dev/sg10[21:10] device_blocked=0 iocounterbits=32 iodone_cnt=0x46c0 ioerr_cnt=0x0 iorequest_cnt=0x46c0 queue_depth=64 queue_type=simple scsi_level=3 state=running timeout=60 type=0 [13:0:0:0] tape HP C7438A ZU5A /dev/st3[9:3] /dev/sg11[21:11] device_blocked=0 iocounterbits=32 iodone_cnt=0x6 ioerr_cnt=0x2 iorequest_cnt=0x6 queue_depth=1 queue_type=none scsi_level=4 state=running timeout=900 type=1 I'll working on getting the scsi_id stuff. Thanks for you prompt attenstion. --john
Created attachment 137165 [details] All the additional scsi_id stuff as requested
I guess this bug is related to buggy firmwares not responding correctly to multiple inquire commands, and to parallel running scsi_id-calls. So we can block scsi--nst by checking for empty id. But this does not solve the problem. So maybe we need a way to just query each device once - and save the data maybe indexed by scsi-id/lun.
This seems to have been caused by a faulty scsi cable. Bug http://bugzilla.kernel.org/show_bug.cgi?id=9775 relates. Thanks muchly for your time. --John
