Has mhvtl been tested with RHEL10?

[rohr22]

We are trying to use the latest mhvtl version (Version: 1.7.2 commit: 584b28b 2026-01-04T22:52:01-05:00) on a RHEL 10.0 system, but it seems unstable. We were not able to import some IBM LTO-6 mhvtl tapes into our application but we can do this without issue on prior RHEL version like RHEL9. Also, I tried to start the mhvtl.target service and it caused a kernel crash.

I hopefully can provide some detailed log files if that will help, but I was wondering if anyone got mhvtl to work on RHEL10.

Thank you,
Peter

[rohr22]

Attached are /var/log/messages that occurred during a tape import attempt. My /etc/mhvtl/mhvtl.conf file contained VERBOSE=3.

issue_importing_mhvtl_tape.tar.gz

[markh794]

Hi Peter,

I'm currently away from a computer for a few days.

I can't say that I've tried RHEL 10 as yet but will check it out as soon as possible.
Mark

[markh794]

This error appears to be more in the udev area... Might have to enable udev debugging/verbose to determine what's going on.

Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: CDB (6709) (delay 405): 00 00 00 00 00 00
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: return_sense(): [Key/ASC/ASCQ] [02 3a 00]
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: ssc_tur(): Test Unit Ready (6709) ** : No, No tape loaded
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: completeSCSICommand(): s/n: (6709), sz: 0, sam_status: 2 [02 3a 00]
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: CDB (6710) (delay 405): 4d 00 51 00 00 00 00 00 0c 00
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: ssc_log_sense(): LOG SENSE (6710) ** :  VHF Device Status page
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: lookup_log_pg(): Looking for: log page 0x11
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: lookup_log_pg(): Device Status (0x11)
Feb 20 18:31:07 nickle /usr/bin/vtltape[4072]: completeSCSICommand(): OP s/n: (6710), sz: 12, sam_status: 0
Feb 20 18:31:09 nickle systemd[1]: systemd-hostnamed.service: Deactivated successfully.
<<< Our application returned an error that it could not stat one of the st links corresponding to one of the mhvtl devices>>
Feb 20 18:31:10 nickle /usr/bin/vtltape[4072]: CDB (6711) (delay 49205): 00 00 00 00 00 00
Feb 20 18:31:10 nickle /usr/bin/vtltape[4072]: return_sense(): [Key/ASC/ASCQ] [02 3a 00]
Feb 20 18:31:10 nickle /usr/bin/vtltape[4072]: ssc_tur(): Test Unit Ready (6711) ** : No, No tape loaded 
Feb 20 18:31:10 nickle /usr/bin/vtltape[4072]: completeSCSICommand(): s/n: (6711), sz: 0, sam_status: 2 [02 3a 00]

[markh794]

looking into this one... Also looks more in the udev side of things. (scsi mid layer) before it ever gets to the low level driver like mhvtl.ko

Feb 20 18:31:21 nickle /usr/bin/vtllibrary[4069]: check_tape_load(): 10: Received "Loaded OK: F01004L6" from snd_id 15
Feb 20 18:31:21 nickle /usr/bin/vtllibrary[4069]: is_map_slot(): slot type 4: NOT A MAP
Feb 20 18:31:21 nickle /usr/bin/vtllibrary[4069]: move_cart(): Setting src slot access true
Feb 20 18:31:21 nickle /usr/bin/vtllibrary[4069]: completeSCSICommand(): OP s/n: (6755), sz: 0, sam_status: 0
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: CDB (6756) (delay 742005): 00 00 00 00 00 00
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: ssc_tur(): Test Unit Ready (6756) ** : Yes
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: completeSCSICommand(): OP s/n: (6756), sz: 0, sam_status: 0
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: CDB (6757) (delay 405): 05 00 00 00 00 00
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: ssc_read_block_limits(): READ BLOCK LIMITS (6757) **
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: resp_read_block_limits(): Min/Max sz: 1/2097152
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: completeSCSICommand(): OP s/n: (6757), sz: 6, sam_status: 0
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: CDB (6758) (delay 805): 1a 00 00 00 0c 00
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: spc_mode_sense(): MODE SENSE 6 (6758) **
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: spc_mode_sense():  Page Control     : Current values(0x00)
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: spc_mode_sense():  Page/Subpage Code: 0x00/0x00
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: spc_mode_sense():  Report Block Descriptor
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: spc_mode_sense():  Allocation len   : 12
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: completeSCSICommand(): OP s/n: (6758), sz: 12, sam_status: 0
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: CDB (6759) (delay 405): 01 00 00 00 00 00
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: ssc_rewind(): REWINDING (6759) **
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: lookup_log_pg(): Looking for: log page 0x11
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: lookup_log_pg(): Device Status (0x11)
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: read_header(): Reading header for block 0
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: read_header(): Reading header 0 at offset 0, type: END OF DATA, size: 0
Feb 20 18:31:21 nickle kernel: st 6:0:5:0: [st4] Block limits 1 - 2097152 bytes.
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: rewind_tape(): Media is writable
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: delay_opcode(): +++ Trace --> what: 4, value: 0
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: delay_opcode(): Completed 4, sleep(0)
Feb 20 18:31:21 nickle /usr/bin/vtltape[4074]: completeSCSICommand(): OP s/n: (6759), sz: 0, sam_status: 0
<<< Our application returned an error about an ioctl issue SCSI_IOCTL_GET_IDLUN on one of the mhvtl devices>>>

https://tldp.org/HOWTO/SCSI-Generic-HOWTO/scsi_g_idlun.html

Let me investigate further once I get back.

[rohr22]

This error appears to be more in the udev area... Might have to enable udev debugging/verbose to determine what's going on.

If you think it would be helpful, can you explain how I can do this? Also, would it be helpful to show more complete logging from the time mhvtl is started until the time our application has issues trying to use mhvtl devices?

[rohr22]

Also, I should have 10 tape devices configured. But I only see 9 listed:

# lsscsi 
[6:0:0:0]    mediumx IBM      3584             0107  /dev/sch0
[6:0:1:0]    tape    IBM      ULT3580-TD6      0107  /dev/st0 
[6:0:2:0]    tape    IBM      ULT3580-TD6      0107  /dev/st1 
[6:0:3:0]    tape    IBM      ULT3580-TD6      0107  /dev/st2 
[6:0:4:0]    tape    IBM      ULT3580-TD6      0107  /dev/st3 
[6:0:5:0]    tape    IBM      ULT3580-TD6      0107  /dev/st4 
[6:0:6:0]    tape    IBM      ULT3580-TD6      0107  /dev/st5 
[6:0:8:0]    tape    IBM      ULT3580-TD6      0107  /dev/st6 
[6:0:9:0]    tape    IBM      ULT3580-TD6      0107  /dev/st8 
[6:0:10:0]   tape    IBM      ULT3580-TD6      0107  /dev/st7 

Where is the device for [6:0:7:0]? As you can see in the attached device.conf file, which is at /etc/mhvtl/device.conf on our system, it lists 10 different devices.

device.tar.gz

[rohr22]

Also, with mhvtl up and running, doing a systemctl stop mhvtl.target caused a kernel crash/reboot. Attached is a snapshot from part of the vmcore-dmesg.txt file.

vmcore-dmesg-part.tar.gz