Bug 201935 - Writing data to tape broken
Summary: Writing data to tape broken
Status: NEW
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: SCSI (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: linux-scsi@vger.kernel.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-09 04:50 UTC by Todd Aiken
Modified: 2018-12-20 16:08 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.19.5
Tree: Mainline
Regression: No


Attachments

Description Todd Aiken 2018-12-09 04:50:22 UTC
Running Slackware64-current on an IBM x3650 server, after upgrading system to kernel version 4.19.5, I am no longer able to write data to my LTO tape drives. Using a Dell PowerVault 132t connected to the server via an Adaptec ASC-29320ALP U320 card (aic79xx module).  I can run the mtx command to load/unload and move tapes around fine, and the mt command also works fine with accessing tapes in either of the LTO2 drives.  However, if I run the command "tar -cvf /dev/st0 /path/to/backup", the system acts like it is writing the files to tape, but nothing seems to get actually written except filemarks.  Running a "tar -tvf /dev/st0" immediately exits.  Reverting back to the Slackware64-current kernel-generic-4.19.4 package and everything works fine again.  This same thing is happening on a second Slackware64-current IBM workstation, with an Adaptec AHA-2940U2/U2W card (aic7xxx module), accessing a second PowerVault 132t tape library. There are no logs generated in /var/log/syslog or /var/log/messages on either system.  Latest kernel tested is 4.19.8.  If I write data to tape with 4.19.4, I am still able to read it with the newer kernels, but data written with 4.19.5 or higher cannot be read.
Comment 1 Bart Van Assche 2018-12-09 17:01:04 UTC
Can you check whether reverting commit f3587d76da05f68098ddb1cb3c98cc6a9e8a402c helps, and if that doesn't help, run a bisect between kernel versions v4.19 and v4.20-rc5?
Comment 2 Todd Aiken 2018-12-10 01:48:12 UTC
I can confirm that reverting commit f3587d76da05f68098ddb1cb3c98cc6a9e8a402c does indeed solve the problem.
Comment 3 Bart Van Assche 2018-12-18 18:45:36 UTC
A fix has been queued for the 4.19 stable series and should be included in a 4.19.x stable kernel soon. See also
https://lore.kernel.org/lkml/20181218163929.193192006@linuxfoundation.org/.
Comment 4 Todd Aiken 2018-12-20 16:08:39 UTC
Just installed 4.19.11, and the fix works.  Many thanks to everyone who helped squash this bug.  :-)

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