Strange kernel dumps

[Alex Loes]

Hi.
I have trouble using an LTO Drive (Ultrium 4-SCSI) on an LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08)

In fact, all seems to be normal, but when I do a mt -f /dev/st0 erase, the kernel dumps messages like
INFO: task mt:3892 blocked for more than 120 seconds.
Feb 4 10:06:18 fm kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 4 10:06:18 fm kernel: mt D 00004A2B 3016 3892 3844 (NOTLB)
Feb 4 10:06:18 fm kernel: f5a3ede4 00000082 a7895dce 00004a2b f6edb124 c04e014f 00000001 00000008
Feb 4 10:06:18 fm kernel: f7bc2aa0 a789a30f 00004a2b 00004541 0000000a f7bc2bac d1657b28 f6bed740
Feb 4 10:06:18 fm kernel: f5a3ee80 d16584c8 a780bcca 00004a2b 000022a8 0000000a f7bc2bac ffffffff
Feb 4 10:06:18 fm kernel: Call Trace:
Feb 4 10:06:18 fm kernel: [] __generic_unplug_device+0x1d/0x1f
Feb 4 10:06:18 fm kernel: [] wait_for_completion+0x6b/0x8f
Feb 4 10:06:18 fm kernel: [] default_wake_function+0x0/0xc
Feb 4 10:06:18 fm kernel: [] st_do_scsi+0x1e7/0x20f [st]
Feb 4 10:06:18 fm kernel: [] st_int_ioctl+0x604/0x9a5 [st]
Feb 4 10:06:18 fm kernel: [] st_ioctl+0xaa1/0xde8 [st]
Feb 4 10:06:18 fm kernel: [] avc_has_perm+0x3c/0x46
Feb 4 10:06:18 fm kernel: [] inode_has_perm+0x54/0x5c
Feb 4 10:06:18 fm kernel: [] chrdev_open+0x0/0x132
Feb 4 10:06:18 fm kernel: [] __dentry_open+0xea/0x1ab
Feb 4 10:06:18 fm kernel: [] do_ioctl+0x47/0x5d
Feb 4 10:06:18 fm kernel: [] vfs_ioctl+0x47b/0x4d3
Feb 4 10:06:18 fm kernel: [] sys_ioctl+0x48/0x5f
Feb 4 10:06:18 fm kernel: [] sysenter_past_esp+0x56/0x79
Feb 4 10:06:18 fm kernel: =======================

and the prompt doesn't return.

The used kernel is 2.6.18-194.el5PAE #1 SMP Tue Mar 16 22:00:21 EDT 2010 i686 i686 i386 GNU/Linux (RedHat 5.5).

Can someone help me please?

[Matti_Kurkela]

Erasing a tape can take a long time.

The "mt" command just sends one SCSI command ioctl: "erase the tape". Then it apparently waits for completion... and I think the default timeout is not long enough for the erase operation.

Looking at the Linux SCSI tape driver source code (/drivers/scsi/st.c), I see the driver can do the erase operation (technically known as the MTERASE ioctl) in various ways: it can perform a "long" or a "short" erase, and it can wait for the request to complete, or not. When it is instructed to wait for completion, it waits for 8x the time defined by the "long_timeout" value. The default value of "long_timeout" is 14000 seconds, or 3.9 hours.

If the request does not include the "wait for completion" bit, then the normal request timeout is used. That is 900 seconds by default.

Apparently the mt command always uses some fixed combination of these options. Since the call trace includes "wait_for_completion", the mt command probably has requested to wait for the completion of the erase operation. If so, the prompt will return only after the erase operation is completed. Since it's likely to take way more than 120 seconds, it is likely to trigger an alarm from the kernel's hung task detector (which is what your message is). If the erase operation is proceeding normally, the alarm is false and can be ignored or disabled... as you've done.

On the other hand, it is possible that the tape drive doesn't implement the "erase tape" operation, and just ignores the request. Most modern tape drives won't require a separate erase cycle to re-use a tape: just overwrite the existing data, and the tape drive mechanism does the right thing. If the erase operation is not implemented, overwriting the tape using /dev/zero or /dev/urandom might be a better strategy.

May I ask why you're trying to erase the tapes? If it's for security, please consider this: if the data on any storage media is worth more than the price of the media, most experts generally recommend destroying the media physically (by degaussing/shredding/burning). There is no easy way to know for sure if the "erase" operation of the tape drive is more secure than overwriting the tape with random data, or not.

According to Wikipedia, degaussing an Ultrium tape will destroy the factory-recorded servo tracks along with the data tracks, making the tape unusable.

MK