* Re: 2.4.x end of tape handling error [not found] ` <20030218021039.28335.qmail@scrye.com> @ 2003-02-24 23:53 ` Kevin Fenzi 2003-03-02 19:26 ` Kai Makisara 0 siblings, 1 reply; 4+ messages in thread From: Kevin Fenzi @ 2003-02-24 23:53 UTC (permalink / raw) To: linux-kernel, linux-scsi -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Some more information on this problem discovered by Tim Jones <tjones@tolisgroup.com>: Tim> Additional news. Tim> This is actually related to the check sense bit not being Tim> propagated up to the ST driver. A simpler test (beats writing Tim> 40GB to a tape ...): Tim> use a 2.2.19/20/21 or 22 kernel, or a 2.4.9-34 kernel Remove the Tim> tape from the tape device execute: Tim> tar -cvvf /dev/nst0 /etc Tim> You will receive a "No medium found" message Tim> Replace the kernel with 2.4.11+ and repeat the tar write test. Tim> This time, you will receive a write failure. Tim> This is caused by the check sense not being set and the ST driver Tim> sending up a EIO instead of the ENOMEDIUM. So, it looks like this problem is _not_ in the st driver itself, but somewhere in the SCSI layer. Anyone have any ideas how to better track it down? Happy to run debug code/test cases here. anyone? kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE+WrCT3imCezTjY0ERAoNDAJ9kx5aTtxJZlxKL04IJmVTztvM5MQCeIuFS Y4RxoYEC619ckzSxXGIAlcM= =A5/e -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.4.x end of tape handling error 2003-02-24 23:53 ` 2.4.x end of tape handling error Kevin Fenzi @ 2003-03-02 19:26 ` Kai Makisara 2003-03-03 16:49 ` Kevin Fenzi 0 siblings, 1 reply; 4+ messages in thread From: Kai Makisara @ 2003-03-02 19:26 UTC (permalink / raw) To: Kevin Fenzi; +Cc: linux-scsi On Mon, 24 Feb 2003, Kevin Fenzi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Some more information on this problem discovered by Tim Jones > <tjones@tolisgroup.com>: > > Tim> Additional news. > > Tim> This is actually related to the check sense bit not being > Tim> propagated up to the ST driver. A simpler test (beats writing > Tim> 40GB to a tape ...): > ... > Tim> This is caused by the check sense not being set and the ST driver > Tim> sending up a EIO instead of the ENOMEDIUM. > > So, it looks like this problem is _not_ in the st driver itself, but > somewhere in the SCSI layer. > > Anyone have any ideas how to better track it down? > > Happy to run debug code/test cases here. > If you enable debugging in the st driver, it prints on the console(dmesg)/system log the sense data it gets. (To enable debugging, edit the st source to '#define DEBUG 1' and recompile the kernel/module). The st driver does in some cases behave too conservatively when the EOT early warning is found. This happens when operating in fixed block mode and only with some drives. The drives I use for testing behave in a different way and that is why I have not seen this problem (tracked down with debugging output from one kind user). I have a fix ready but testing will still take some time. This problem is not seen when asynchronous writes and driver buffering are disabled (as suggested in README.st when trying to rely on EOT detection). Kai ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: 2.4.x end of tape handling error 2003-03-02 19:26 ` Kai Makisara @ 2003-03-03 16:49 ` Kevin Fenzi 0 siblings, 0 replies; 4+ messages in thread From: Kevin Fenzi @ 2003-03-03 16:49 UTC (permalink / raw) To: Kai Makisara; +Cc: linux-scsi -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Kai" == Kai Makisara <Kai.Makisara@kolumbus.fi> writes: Kai> On Mon, 24 Feb 2003, Kevin Fenzi wrote: >> Some more information on this problem discovered by Tim Jones >> <tjones@tolisgroup.com>: >> Tim> Additional news. >> Tim> This is actually related to the check sense bit not being Tim> propagated up to the ST driver. A simpler test (beats writing Tim> 40GB to a tape ...): >> Kai> ... Tim> This is caused by the check sense not being set and the ST driver Tim> sending up a EIO instead of the ENOMEDIUM. >> So, it looks like this problem is _not_ in the st driver itself, >> but somewhere in the SCSI layer. >> >> Anyone have any ideas how to better track it down? >> >> Happy to run debug code/test cases here. >> Kai> If you enable debugging in the st driver, it prints on the Kai> console(dmesg)/system log the sense data it gets. (To enable Kai> debugging, edit the st source to '#define DEBUG 1' and recompile Kai> the kernel/module). Yeah, ok. Kai> The st driver does in some cases behave too conservatively when Kai> the EOT early warning is found. This happens when operating in Kai> fixed block mode and only with some drives. The drives I use for Kai> testing behave in a different way and that is why I have not seen Kai> this problem (tracked down with debugging output from one kind Kai> user). I have a fix ready but testing will still take some Kai> time. This problem is not seen when asynchronous writes and Kai> driver buffering are disabled (as suggested in README.st when Kai> trying to rely on EOT detection). Humm... I tried to disable async writes and buffering and still got the problem on my HP DDS2 drive. Whats the correct procedure to disable both those? mt -f /dev/nst0 stoptions buffer-writes 0 mt -f /dev/nst0 stoptions async-writes 0 I can repeat those tests to confirm, but I'm pretty sure I was seeing the problem even with those options set. Would you like debug output from that case? Kai> Kai kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE+Y4em3imCezTjY0ERAsPOAJ4lSsrUfiDHPbdNQ+NcQxEy4w17sACdEkM8 EclBD42iXwpqsbiAJkeelEo= =Uh2S -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <20030210182254.2913.qmail@scrye.com>]
[parent not found: <Pine.LNX.4.52.0302102249480.804@kai.makisara.local>]
* Re: 2.4.x end of tape handling error [not found] ` <Pine.LNX.4.52.0302102249480.804@kai.makisara.local> @ 2003-02-18 3:16 ` Kevin Fenzi 0 siblings, 0 replies; 4+ messages in thread From: Kevin Fenzi @ 2003-02-18 3:16 UTC (permalink / raw) To: Kai Makisara; +Cc: linux-scsi -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Kai" == Kai Makisara <Kai.Makisara@kolumbus.fi> writes: Kai> This discussion should really be moved to linux-scsi... ok. Kai> 10 Feb 2003, Kevin Fenzi wrote: >> Greetings. >> >> I have had reported from a client that they are having problems >> with backups that span more than one tape. Instead of getting an >> EOT error or EOM, they are getting an I/O error wich requires the >> driver to be unloaded and reloaded before the tape will work again. >> Kai> What messages have they seen in the system log? Some messages Kai> should be after this kind of error. It is difficult to see where Kai> the problem is without any details. There have not been any Kai> significant changes in EOM handling in st between the 2.4 Kai> kernels. I have duplicated the problem with a dds2 drive I have here. Basically, they get back a EIO error instead of a ENOSPC error when hitting the end of tape. >> http://www.linuxtapecert.org/ Says that the redhat 2.4.9-34 kernel >> is the last one that had proper EOT handling. Indeed, if they use >> the 2.4.9-34 kernel, the tape works properly. Thats not a very good >> solution however. >> >> Is this fixed in the latest 2.4.21-pres? How about in 2.5.x? >> Kai> Don't know. EOM handling has worked with my test system (HP DDS Kai> drives connected to a SYM53c896) with both 2.4 and 2.5 kernels. I Kai> just reran the eom tests with 2.4.20 and 2.5.60 without problems. My test system is very similar. HP DDS2 drive, on a SYM53c896. ;) Redhat 7.3 machine, running 2.4.18-24.7.x. To test I just used tar and tried to put more on the tape than would fit. I got: ... write(3, "\305\230\240=:-v\t\237&\16\317\234+x\"N(\375\0\264\000"..., 10240) = -1 EIO (Input/output error) write(2, "tar: ", 5) = 5 write(2, "/dev/nst0: Wrote only 0 of 10240"..., 38) = 38 write(2, "\n", 1) = 1 write(2, "tar: ", 5) = 5 write(2, "Error is not recoverable: exitin"..., 37) = 37 write(2, "\n", 1) = 1 munmap(0x4002e000, 4096) = 0 _exit(2) = ? I tried loading the driver with various options, in case it was a buffering issue: modprobe st buffer_kbs=0 write_threshold_kbs=0 max_buffers=0 max_sg_segs=0 Any option I seemed to give it resulted in the same thing. I would be happy to test anything or provide you access to the box with the tape drive on it. Will also try the 2.4.9-34 kernel that is supposed to not have this issue. Kai> Kai kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE+UaWe3imCezTjY0ERAt84AJ9JIzGEwm5H9Id4Tg4k0/o0fzZmgwCgk3zr bP+qoI82jXtyMY7XU2YHjWU= =4Z2L -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-03-03 16:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.1044901620.21591.linux-kernel2news@redhat.com>
[not found] ` <200302101904.h1AJ4US05141@devserv.devel.redhat.com>
[not found] ` <20030218021039.28335.qmail@scrye.com>
2003-02-24 23:53 ` 2.4.x end of tape handling error Kevin Fenzi
2003-03-02 19:26 ` Kai Makisara
2003-03-03 16:49 ` Kevin Fenzi
[not found] <20030210182254.2913.qmail@scrye.com>
[not found] ` <Pine.LNX.4.52.0302102249480.804@kai.makisara.local>
2003-02-18 3:16 ` Kevin Fenzi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox