Re: no tape device(s) under Debian Stretch
On Thu, Sep 21, 2017 at 10:01:06 +0200, Stefan G. Weichinger wrote:
> And I did the suggested:
>
> # udevadm info -a -n /dev/st0
>
> looking at device
> '/devices/pci:00/:00:01.1/:02:00.0/host6/target6:0:4/6:0:4:0/scsi_tape/st0':
> KERNEL=="st0"
> SUBSYSTEM=="scsi_tape"
> DRIVER==""
> ATTR{default_blksize}=="-1"
> ATTR{default_compression}=="-1"
> ATTR{default_density}=="-1"
> ATTR{defined}=="1"
> ATTR{options}=="0x0107"
>
> looking at parent device
> '/devices/pci:00/:00:01.1/:02:00.0/host6/target6:0:4/6:0:4:0':
> KERNELS=="6:0:4:0"
> SUBSYSTEMS=="scsi"
> DRIVERS=="st"
[...]
>
> looking at parent device '/devices/pci:00/:00:01.1/:02:00.0':
> KERNELS==":02:00.0"
> SUBSYSTEMS=="pci"
> DRIVERS=="megaraid_sas"
[...]
> --- so only megaraid_sas involved here, as it seems.
Well, the other part I was interested to see is what driver actually
provided the "/dev/st0" device... but this confirms that under Gentoo it
was the "st" kernel module (just as it is for our "plain scsi" tape
drive under Ubuntu).
I would certainly expect that to be a standard part of the
Debian-distributed kernel, so it does seem like your next step is to
investigate the details of loading the megaraid_sas module and try to
figure out why that is failing to enumerate the devices on the SAS
bus...
Nathan
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: no tape device(s) under Debian Stretch
Am 2017-09-20 um 21:58 schrieb Nathan Stratton Treadway:
> On Wed, Sep 20, 2017 at 20:56:22 +0200, Stefan G. Weichinger wrote:
>>
>> put the controller + drive back into the gentoo server
>>
> [...]
>> Maybe someone on the list with similar hardware could compare "dmesg" ?
>
> Does Gentoo have the "udevadm" command installed? If so, what does
> $ udevadm info -a -n /dev/st0
>
> (or
> $ udevadm info --attribute-walk --name /dev/st0
> in long-option format)
>
> give you? Hopefully it will show you the set of kernel modules
> (DRIVERS=) involved in providing the /dev/st0 device file
I am sorry to get a bit off topic on the amanda-users-ml now ...
I filed an issue at
https://github.com/eLvErDe/hwraid/issues/71
maybe that helps.
And I did the suggested:
# udevadm info -a -n /dev/st0
looking at device
'/devices/pci:00/:00:01.1/:02:00.0/host6/target6:0:4/6:0:4:0/scsi_tape/st0':
KERNEL=="st0"
SUBSYSTEM=="scsi_tape"
DRIVER==""
ATTR{default_blksize}=="-1"
ATTR{default_compression}=="-1"
ATTR{default_density}=="-1"
ATTR{defined}=="1"
ATTR{options}=="0x0107"
looking at parent device
'/devices/pci:00/:00:01.1/:02:00.0/host6/target6:0:4/6:0:4:0':
KERNELS=="6:0:4:0"
SUBSYSTEMS=="scsi"
DRIVERS=="st"
ATTRS{device_blocked}=="0"
ATTRS{eh_timeout}=="10"
ATTRS{evt_capacity_change_reported}=="0"
ATTRS{evt_inquiry_change_reported}=="0"
ATTRS{evt_lun_change_reported}=="0"
ATTRS{evt_media_change}=="0"
ATTRS{evt_mode_parameter_change_reported}=="0"
ATTRS{evt_soft_threshold_reached}=="0"
ATTRS{iocounterbits}=="32"
ATTRS{iodone_cnt}=="0x316574"
ATTRS{ioerr_cnt}=="0x4"
ATTRS{iorequest_cnt}=="0x316574"
ATTRS{model}=="Ultrium 3-SCSI "
ATTRS{queue_depth}=="256"
ATTRS{queue_ramp_up_period}=="12"
ATTRS{queue_type}=="none"
ATTRS{rev}=="Q51D"
ATTRS{scsi_level}=="6"
ATTRS{state}=="running"
ATTRS{timeout}=="900"
ATTRS{type}=="1"
ATTRS{vendor}=="HP "
looking at parent device
'/devices/pci:00/:00:01.1/:02:00.0/host6/target6:0:4':
KERNELS=="target6:0:4"
SUBSYSTEMS=="scsi"
DRIVERS==""
looking at parent device
'/devices/pci:00/:00:01.1/:02:00.0/host6':
KERNELS=="host6"
SUBSYSTEMS=="scsi"
DRIVERS==""
looking at parent device '/devices/pci:00/:00:01.1/:02:00.0':
KERNELS==":02:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="megaraid_sas"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x010400"
ATTRS{config}==""
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{d3cold_allowed}=="1"
ATTRS{device}=="0x0073"
ATTRS{dma_mask_bits}=="64"
ATTRS{enable}=="1"
ATTRS{irq}=="17"
ATTRS{local_cpulist}=="0-31"
ATTRS{local_cpus}==""
ATTRS{msi_bus}==""
ATTRS{subsystem_device}=="0x1177"
ATTRS{subsystem_vendor}=="0x1734"
ATTRS{vendor}=="0x1000"
looking at parent device '/devices/pci:00/:00:01.1':
KERNELS==":00:01.1"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{d3cold_allowed}=="0"
ATTRS{device}=="0x0155"
ATTRS{dma_mask_bits}=="32"
ATTRS{enable}=="1"
ATTRS{irq}=="41"
ATTRS{local_cpulist}=="0-31"
ATTRS{local_cpus}==""
ATTRS{msi_bus}=="1"
ATTRS{subsystem_device}=="0x11d7"
ATTRS{subsystem_vendor}=="0x1734"
ATTRS{vendor}=="0x8086"
looking at parent device '/devices/pci:00':
KERNELS=="pci:00"
SUBSYSTEMS==""
DRIVERS==""
--- so only megaraid_sas involved here, as it seems.
Re: no tape device(s) under Debian Stretch
On Wed, Sep 20, 2017 at 20:56:22 +0200, Stefan G. Weichinger wrote: > > put the controller + drive back into the gentoo server > [...] > Maybe someone on the list with similar hardware could compare "dmesg" ? Does Gentoo have the "udevadm" command installed? If so, what does $ udevadm info -a -n /dev/st0 (or $ udevadm info --attribute-walk --name /dev/st0 in long-option format) give you? Hopefully it will show you the set of kernel modules (DRIVERS=) involved in providing the /dev/st0 device file Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: no tape device(s) under Debian Stretch
put the controller + drive back into the gentoo server seems it loads one more module: # dmesg | grep mega [2.119694] megasas: 06.700.06.00-rc1 Sat. Aug. 31 17:00:00 PDT 2013 [2.119708] megasas: 0x1000:0x0073:0x1734:0x1177: bus 2:slot 0:func 0 [2.119821] megasas: FW now in Ready state [2.119838] megaraid_sas :02:00.0: irq 45 for MSI/MSI-X [2.119849] megaraid_sas :02:00.0: [scsi6]: FW supports<0> MSIX vector,Online CPUs: <4>,Current MSIX <1> [2.147598] megasas_init_mfi: fw_support_ieee=67108864 [2.147599] megasas: INIT adapter done [2.237574] megaraid_sas :02:00.0: Controller type: iMR and no FW init problem message. So maybe I have to force loading the "megasas" module under debian or so. For now we run amanda on the gentoo box (as years before) to get backups. The server is ~100 miles away from me and the guy who serves as my "remote hands" isn't employed there ... ;-) ... so swapping hardware again will take some time. Maybe someone on the list with similar hardware could compare "dmesg" ? thanks, Stefan
Re: no tape device(s) under Debian Stretch
Am 2017-09-20 um 00:27 schrieb Nathan Stratton Treadway: > I don't know the specifics for a SAS-based tape drive, but in general my > impression is that (on modern Debian Linux systems) all device files > should be aotmatically created (via udev) when the related kernel module > is loaded. correct. > (See /lib/udev/rules.d/60-persistent-storage-tape.rules for a little > more information, though that mostly just shows how the /dev/tape/by-id > and by-path symlinks get created pointing to the kernel-module-default > /dev/st* device files.) Yes, been there ... > For a "plain" SCSI tape drive we have, the kernel module in question (on > an old server running linux 2.6) is just "st.ko" . So, there is a > module for the SCSI card that gets loaded (by the PCI-bus scanning > process), then the st.ko module gets loaded when the tape drive is > detected on the SCSI bus. You run a kernel 2.6 still ? phew ;-) > Sounds like your SAS card driver is being detected by the PCI scan, but > I'm not sure which module is supposed to handle the tape drive in your > case... (or the answer to your question about firmware...). The module "st" is not loaded automatically and even when I modprobe it myself I don't get the device file(s), only this line in dmesg: [Die Sep 19 18:22:36 2017] st: Version 20160209, fixed bufsize 32768, s/g segs 256 I am not sure if that means it recognizes the drive at all? According to "man 4 st" there should be something in /sys/class/scsi_tape/ ... it's empty here.
Re: no tape device(s) under Debian Stretch
On Tue, Sep 19, 2017 at 18:44:35 +0200, Stefan G. Weichinger wrote: > Problem: > > even after installing mt-st, scsiutils etc and repeated reboots I > don't get any device files (/dev/nst? /dev/st? /dev/tape* etc) > > Even a mknod or modprobe st does not help: > > # mknod /dev/st0 c 9 0 > > # mt -f /dev/st0 status > /dev/st0: No such device or address > > Any advice? > I don't know the specifics for a SAS-based tape drive, but in general my impression is that (on modern Debian Linux systems) all device files should be aotmatically created (via udev) when the related kernel module is loaded. (See /lib/udev/rules.d/60-persistent-storage-tape.rules for a little more information, though that mostly just shows how the /dev/tape/by-id and by-path symlinks get created pointing to the kernel-module-default /dev/st* device files.) For a "plain" SCSI tape drive we have, the kernel module in question (on an old server running linux 2.6) is just "st.ko" . So, there is a module for the SCSI card that gets loaded (by the PCI-bus scanning process), then the st.ko module gets loaded when the tape drive is detected on the SCSI bus. Sounds like your SAS card driver is being detected by the PCI scan, but I'm not sure which module is supposed to handle the tape drive in your case... (or the answer to your question about firmware...). Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
no tape device(s) under Debian Stretch
Hello, amanda-users, today I removed a LTO-3-drive from a gentoo linux server, with its accompanying SAS-Controller-Card, and built it into a shiny new Fuji TX1330M3 running debian linux 9.1 (with latest updates). lspci shows 02:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2008 [Falcon] (rev 03) Subsystem: Fujitsu Technology Solutions RAID Ctrl SAS 6G 0/1 (D2607) Flags: fast devsel, IRQ 17 I/O ports at e000 [disabled] [size=256] Memory at dfb6 (64-bit, non-prefetchable) [size=16K] Memory at dfb0 (64-bit, non-prefetchable) [size=256K] Expansion ROM at dfb4 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [68] Express Endpoint, MSI 00 Capabilities: [a8] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [c0] MSI-X: Enable- Count=15 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [138] Power Budgeting Kernel modules: megaraid_sas Problem: even after installing mt-st, scsiutils etc and repeated reboots I don't get any device files (/dev/nst? /dev/st? /dev/tape* etc) Even a mknod or modprobe st does not help: # mknod /dev/st0 c 9 0 # mt -f /dev/st0 status /dev/st0: No such device or address Any advice? The drive was reconnected twice, I checked all the cables, for example inserting a tape leads to working motor etc The drive worked in the gentoo server without problems for years now. Maybe I have to install something else? What I see: #dmesg megaraid_sas :02:00.0: Failed to init firmware Do I have to install some binary blob? Thanks for any help, Stefan
