Problems with SCSI tape rewind / verify on 2.4.29

Problems with SCSI tape rewind / verify on 2.4.29

[Mark Yeatman]

Hi

Never had to log a bug before, hope this is correctly done.

Thanks

Mark

Detail....

[1.] One line summary of the problem:    
SCSI tape drive is refusing to rewind after backup to allow verify and
causing illegal seek error

[2.] Full description of the problem/report:
On backup the tape drive is reporting the following error and failing
it's backups.

tar: /dev/st0: Warning: Cannot seek: Illegal seek

I have traced this back to failing at an upgrade of the kernel to 2.4.29
on Feb 8th. The backups have not worked since. Replacement Drives have
been tried and cables to no avail. I noticed in the the changelog that a
patch by Solar Designer to the Scsi tape return code had been made. 

Solar Designer:
  o Fix SCSI tape driver return code

The tape appears to back up correctly but will not verify.

[3.] Keywords (i.e., modules, networking, kernel):
Solar Designer, Tape, Scsi, 2.4.29

[4.] Kernel version (from /proc/version):
Linux version 2.4.29-vs1.2.10 (root@raptor) (gcc version 3.2.3) #1 SMP
Tue Feb 8 15:55:58 UTC 2005
 
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)

[6.] A small shell script or example program which triggers the
     problem (if possible)
     
tar cf /dev/st0 -W -P --exclude proc --exclude dev / 1>>
/var/log/backup.log 2>>/var/log/backup.log
 
 
[7.] Environment



[7.1.] Software (add the output of the ver_linux script here)

Linux raptor 2.4.29-vs1.2.10 #1 SMP Tue Feb 8 15:55:58 UTC 2005 i686
unknown unk
nown GNU/Linux

Gnu C                  3.2.3
Gnu make               3.80
util-linux             2.12
mount                  2.12
modutils               2.4.25
e2fsprogs              1.34
Linux C Library        2.3.2
Dynamic linker (ldd)   2.3.2
Linux C++ Library      5.0.3
Procps                 2.0.16
Net-tools              1.60
Kbd                    1.08
Sh-utils               5.0
Modules Loaded

[7.2.] Processor information (from /proc/cpuinfo):
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.06GHz
stepping        : 7
cpu MHz         : 3059.270
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips        : 6107.95

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 3.06GHz
stepping        : 7
cpu MHz         : 3059.270
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips        : 6107.95


[7.3.] Module information (from /proc/modules):
No output from here.

[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
a800-a8ff : Adaptec ASC-29320 U320
b000-b0ff : Adaptec ASC-29320 U320
b400-b4ff : Adaptec ASC-29320 U320 (#2)
b800-b8ff : Adaptec ASC-29320 U320 (#2)
bc00-bc3f : PCI device 8086:1050 (Intel Corp.)
  bc00-bc3f : e100
c400-c41f : Intel Corp. 82801EB SMBus Controller
c800-c81f : Intel Corp. 82801EB USB
cc00-cc1f : Intel Corp. 82801EB USB
d000-d01f : Intel Corp. 82801EB USB
d400-d41f : Intel Corp. 82801EB USB
d800-d80f : Intel Corp. 82801EB Ultra ATA Storage Controller
dc00-dc03 : Intel Corp. 82801EB Ultra ATA Storage Controller
e000-e007 : Intel Corp. 82801EB Ultra ATA Storage Controller
e400-e403 : Intel Corp. 82801EB Ultra ATA Storage Controller
e800-e807 : Intel Corp. 82801EB Ultra ATA Storage Controller
ec00-ec07 : Intel Corp. 82865G Integrated Graphics Device
ffa0-ffaf : Intel Corp. 82801EB Ultra ATA Storage Controller

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000ca000-000d39ff : Extension ROM
000f0000-000fffff : System ROM
00100000-7ef2fbff : System RAM
  00100000-002b9f80 : Kernel code
  002b9f81-00354667 : Kernel data
7ef2fc00-7ef2ffff : ACPI Non-volatile Storage
7ef30000-7ef3ffff : ACPI Tables
7ef40000-7efeffff : ACPI Non-volatile Storage
7eff0000-7effffff : reserved
7f000000-7f0003ff : Intel Corp. 82801EB Ultra ATA Storage Controller
f0000000-f7ffffff : Intel Corp. 82865G Integrated Graphics Device
f8000000-fbffffff : Intel Corp. 82865G/PE/P Processor to I/O Controller
fecf0000-fecf0fff : reserved
fed20000-fed9ffff : reserved
ff8fb000-ff8fbfff : PCI device 8086:1050 (Intel Corp.)
  ff8fb000-ff8fbfff : e100
ff8fc000-ff8fdfff : Adaptec ASC-29320 U320
  ff8fc000-ff8fcfff : aic79xx
ff8fe000-ff8fffff : Adaptec ASC-29320 U320 (#2)
  ff8fe000-ff8fefff : aic79xx
ffa80000-ffafffff : Intel Corp. 82865G Integrated Graphics Device


[7.5.] PCI information ('lspci -vvv' as root)

00:00.0 Host bridge: Intel Corp.: Unknown device 2570 (rev 02)
        Subsystem: Intel Corp.: Unknown device 2570
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort-
<MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [e4] #09 [0106]

00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2572 (rev
02) (pr
og-if 00 [VGA])
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Region 1: Memory at ffa80000 (32-bit, non-prefetchable)
[size=512K]
        Region 2: I/O ports at ec00 [size=8]
        Capabilities: [d0] Power Management version 1
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:1d.0 USB Controller: Intel Corp.: Unknown device 24d2 (rev 02)
(prog-if 00 [U
HCI])
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 4: I/O ports at c800 [size=32]

00:1d.1 USB Controller: Intel Corp.: Unknown device 24d4 (rev 02)
(prog-if 00 [U
HCI])
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 9
        Region 4: I/O ports at cc00 [size=32]

00:1d.2 USB Controller: Intel Corp.: Unknown device 24d7 (rev 02)
(prog-if 00 [U
HCI])
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 10
        Region 4: I/O ports at d000 [size=32]

00:1d.3 USB Controller: Intel Corp.: Unknown device 24de (rev 02)
(prog-if 00 [U
HCI])
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 11
        Region 4: I/O ports at d400 [size=32]

00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev c2)
(prog-if 00 [N
ormal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
<TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        I/O behind bridge: 0000a000-0000bfff
        Memory behind bridge: ff600000-ff8fffff
        Prefetchable memory behind bridge: e6a00000-e6afffff
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corp.: Unknown device 24d0 (rev 02)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop-
ParErr- Step
ping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0

00:1f.1 IDE interface: Intel Corp.: Unknown device 24db (rev 02)
(prog-if 8a [Ma
ster SecP PriP])
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at <unassigned>
        Region 1: I/O ports at <unassigned>
        Region 2: I/O ports at <unassigned>
        Region 3: I/O ports at <unassigned>
        Region 4: I/O ports at ffa0 [size=16]
        Region 5: Memory at 7f000000 (32-bit, non-prefetchable)
[disabled] [size
=1K]

00:1f.2 IDE interface: Intel Corp.: Unknown device 24d1 (rev 02)
(prog-if 8f [Ma
ster SecP SecO PriP PriO])
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at e800 [size=8]
        Region 1: I/O ports at e400 [size=4]
        Region 2: I/O ports at e000 [size=8]
        Region 3: I/O ports at dc00 [size=4]
        Region 4: I/O ports at d800 [size=16]

00:1f.3 SMBus: Intel Corp.: Unknown device 24d3 (rev 02)
        Subsystem: Intel Corp.: Unknown device 4246
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Step
ping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Interrupt: pin B routed to IRQ 5
        Region 4: I/O ports at c400 [size=32]

01:03.1 SCSI storage controller: Adaptec ASC-29320 U320 (rev 03)
        Subsystem: Adaptec: Unknown device 0042
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Step
ping- SERR+ FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (10000ns min, 6250ns max), cache line size 10
        Interrupt: pin B routed to IRQ 10
        Region 0: I/O ports at b800 [disabled] [size=256]
        Region 1: Memory at ff8fe000 (64-bit, non-prefetchable)
[size=8K]
        Region 3: I/O ports at b400 [disabled] [size=256]
        Expansion ROM at ff800000 [disabled] [size=512K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a0] Message Signalled Interrupts: 64bit+
Queue=0/1 Enable
-
                Address: 0000000000000000  Data: 0000
        Capabilities: [94]
01:08.0 Ethernet controller: Intel Corp.: Unknown device 1050 (rev 01)
        Subsystem: Intel Corp.: Unknown device 302f
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Step
ping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort
- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min, 14000ns max), cache line size 10
        Interrupt: pin A routed to IRQ 3
        Region 0: Memory at ff8fb000 (32-bit, non-prefetchable)
[size=4K]
        Region 1: I/O ports at bc00 [size=64]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot
+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

[7.6.] SCSI information (from /proc/scsi/scsi)

Attached devices:
Host: scsi0 Channel: 00 Id: 03 Lun: 00
  Vendor: HP       Model: C7438A           Rev: V312
  Type:   Sequential-Access                ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: SEAGATE  Model: ST336732LW       Rev: 0022
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 01 Lun: 00
  Vendor: SEAGATE  Model: ST336732LW       Rev: 0022
  Type:   Direct-Access                    ANSI SCSI revision: 03


[7.7.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):

[X.] Other notes, patches, fixes, workarounds:

No workarounds as yet, however can we back out just the patch from Solar
Designer?

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Marcelo Tosatti]

On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> Hi
> 
> Never had to log a bug before, hope this is correctly done.
> 
> Thanks
> 
> Mark
> 
> Detail....
> 
> [1.] One line summary of the problem:    
> SCSI tape drive is refusing to rewind after backup to allow verify and
> causing illegal seek error
> 
> [2.] Full description of the problem/report:
> On backup the tape drive is reporting the following error and failing
> it's backups.
> 
> tar: /dev/st0: Warning: Cannot seek: Illegal seek
> 
> I have traced this back to failing at an upgrade of the kernel to 2.4.29
> on Feb 8th. The backups have not worked since. Replacement Drives have
> been tried and cables to no avail. I noticed in the the changelog that a
> patch by Solar Designer to the Scsi tape return code had been made. 

v2.6 also contains the same problem BTW.

Try this:

--- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
+++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
@@ -3778,7 +3778,6 @@
 	read:		st_read,
 	write:		st_write,
 	ioctl:		st_ioctl,
-	llseek:		no_llseek,
 	open:		st_open,
 	flush:		st_flush,
 	release:	st_release,

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Gene Heskett]

On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote:
>On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
>> Hi
>>
>> Never had to log a bug before, hope this is correctly done.
>>
>> Thanks
>>
>> Mark
>>
>> Detail....
>>
>> [1.] One line summary of the problem:
>> SCSI tape drive is refusing to rewind after backup to allow verify
>> and causing illegal seek error
>>
>> [2.] Full description of the problem/report:
>> On backup the tape drive is reporting the following error and
>> failing it's backups.
>>
>> tar: /dev/st0: Warning: Cannot seek: Illegal seek
>>
>> I have traced this back to failing at an upgrade of the kernel to
>> 2.4.29 on Feb 8th. The backups have not worked since. Replacement
>> Drives have been tried and cables to no avail. I noticed in the
>> the changelog that a patch by Solar Designer to the Scsi tape
>> return code had been made.
>
>v2.6 also contains the same problem BTW.
>
>Try this:
>
>--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300
>+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
>@@ -3778,7 +3778,6 @@
>  read:  st_read,
>  write:  st_write,
>  ioctl:  st_ioctl,
>- llseek:  no_llseek,
>  open:  st_open,
>  flush:  st_flush,
>  release: st_release,
>-

Interesting Marcelo.  How long has this been true in 2.6?

I thought I had an amanda problem, and eventually went to virtual 
tapes on disk, largely because of this.  However, I have to say it is 
working better than tapes ever did here.  Unforch, that 200GB disk is 
certainly a single point of failure I don't relish thinking about...

>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Marcelo Tosatti]

n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote:
> On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote:
> >On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> >> Hi
> >>
> >> Never had to log a bug before, hope this is correctly done.
> >>
> >> Thanks
> >>
> >> Mark
> >>
> >> Detail....
> >>
> >> [1.] One line summary of the problem:
> >> SCSI tape drive is refusing to rewind after backup to allow verify
> >> and causing illegal seek error
> >>
> >> [2.] Full description of the problem/report:
> >> On backup the tape drive is reporting the following error and
> >> failing it's backups.
> >>
> >> tar: /dev/st0: Warning: Cannot seek: Illegal seek
> >>
> >> I have traced this back to failing at an upgrade of the kernel to
> >> 2.4.29 on Feb 8th. The backups have not worked since. Replacement
> >> Drives have been tried and cables to no avail. I noticed in the
> >> the changelog that a patch by Solar Designer to the Scsi tape
> >> return code had been made.
> >
> >v2.6 also contains the same problem BTW.
> >
> >Try this:
> >
> >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300
> >+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
> >@@ -3778,7 +3778,6 @@
> >  read:  st_read,
> >  write:  st_write,
> >  ioctl:  st_ioctl,
> >- llseek:  no_llseek,
> >  open:  st_open,
> >  flush:  st_flush,
> >  release: st_release,
> >-
> 
> Interesting Marcelo.  How long has this been true in 2.6?

Actually I just checked and it seems v2.6 is not using "no_llseek".

However John L. Males reports the same problem with v2.6 - John, care
to retest with v2.6.10 ?

> I thought I had an amanda problem, and eventually went to virtual 
> tapes on disk, largely because of this.  However, I have to say it is 
> working better than tapes ever did here.  Unforch, that 200GB disk is 
> certainly a single point of failure I don't relish thinking about...

:)

Re[03]: Problems with SCSI tape rewind / verify on 2.4.29

[John L. Males]

[-- Attachment #1: Type: text/plain, Size: 6311 bytes --]

Hi Marcello,


********** Reply Seperator **********

On (Wed) 2005-03-02 11:34:41 -0300 
Marcelo Tosatti wrote in Message-ID: 20050302143440.GA2543@logos.cnet

To: Gene Heskett <gene.heskett@verizon.net>
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29
Date: Wed, 2 Mar 2005 11:34:41 -0300

> 
> n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote:
> > On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote:
> > >On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> > >> Hi
> > >>
> > >> Never had to log a bug before, hope this is correctly done.
> > >>
> > >> Thanks
> > >>
> > >> Mark
> > >>
> > >> Detail....
> > >>
> > >> [1.] One line summary of the problem:
> > >> SCSI tape drive is refusing to rewind after backup to allow
> > >verify> and causing illegal seek error

In my experiences with this problem that I am sure is exactly the same
issue, the tape in fact does rewind after creating the tar to then
perfore the --verify option.  The illegal see error seems to arise
after the rewind or more correctly bsf commands may be being used (but
not confirmed this yet, another test I need to do in few days).  For
sure the tape is positionted back.  I know as I have also done this
test with larger directories and know and have heard the tape take
long time to naturally get back to the start of tar file to be able to
perform the --verify option.  That said I am using a DLT drive. 
Perhpas with different drivers or tape drivers this issue may have
variations on theme and behaviour with net result the same error
message and/or root cause.

> > >>
> > >> [2.] Full description of the problem/report:
> > >> On backup the tape drive is reporting the following error and
> > >> failing it's backups.
> > >>
> > >> tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > >>
> > >> I have traced this back to failing at an upgrade of the kernel
> > >to> 2.4.29 on Feb 8th. The backups have not worked since.
> > >Replacement> Drives have been tried and cables to no avail. I
> > >noticed in the> the changelog that a patch by Solar Designer to
> > >the Scsi tape> return code had been made.

Last kernel to work correctly in 2.4 branch was 2.4.26.  Kernel
versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience
with DLT SCSI based tape.

> > >
> > >v2.6 also contains the same problem BTW.
> > >
> > >Try this:
> > >
> > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144 -0300
> > >+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200 -0300
> > >@@ -3778,7 +3778,6 @@
> > >  read:  st_read,
> > >  write:  st_write,
> > >  ioctl:  st_ioctl,
> > >- llseek:  no_llseek,
> > >  open:  st_open,
> > >  flush:  st_flush,
> > >  release: st_release,
> > >-
> > 
> > Interesting Marcelo.  How long has this been true in 2.6?

In the 2.6 tree the tar --verify works with 2.6.7, but fails with
2.6.9. I am unable to test 2.6.8, but based on research of the code
changes of 2.6.8 compared to the changes made in 2.4.27 re llseek I
would expect 2.6.8 to fail as well with my DLT SCSI tape. 

> 
> Actually I just checked and it seems v2.6 is not using "no_llseek".
> 
> However John L. Males reports the same problem with v2.6 - John,
> care to retest with v2.6.10 ?

My ability to test a 2.6.x kernel is limited to what 2.6.x kernel I
can find on a livecd.  The 2.6.7 and 2.6.9 kernel tests I conducted
were using Knoppix 3.6 and 3.7.  I do not have means at this time, nor
time, to build up a dedicated drive to test 2.6.x kernels.  If someone
knows of or can build a 2.6.10 kernel on a live CD I will be happy to
do the test.  That said, I looked at the patch for 2.6.10 and seems
alot of changes were made to st.c in 2.6.10.  I did not see, but could
of missed in looking, any lseek related change in 2.6.10.  Given how
it seems the test I ran with the change in st.c Marcell suggested what
is the expected thought on this issue with 2.6.10?  I am just asking
from curiousity.  Again, if someone can tell me of a live cd or can
easly make a live cd with the 2.6.10 kernel I can test this issue wiht
2.6.10.  Perhaps there is someone else with a DLT/SCSI tape driver
that could test this tar --verify issue on 2.6.10?

> 
> > I thought I had an amanda problem, and eventually went to virtual 
> > tapes on disk, largely because of this.  However, I have to say it
> > is working better than tapes ever did here.  Unforch, that 200GB
> > disk is certainly a single point of failure I don't relish
> > thinking about...
> 
> :)


Regards,

John L. Males
Willowdale, Ontario
Canada
02 March 2005 (15:00 -) 15:46


==================================================================


"Boooomer ... Boom Boom, how are you Boom Boom"
"Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
     intent Boomer is coming for attention
Loved to kneed arm and lick arm with Boomers very large
     tongue
Able to catch, or at least hit, almost any object in flight
     withing reach of front paws
Boomer 1985 (Born), Adopted 04 September 1991
04 September 1991 - 08 February 2000 18:50

"How are you Mr. Sylvester?"
"... Grunt Grunt" ... quick licks of nose
Rolls over for pet and stomac rub when Dad arrives home
     and grunting
Runs back and forth from study, tilts head as glowing green
     eyes stare for "attention please", grunts and meows,
     repeats run, tilt head and stare few times for good
     measure, grunts and meows
Lays on floor just outside study to guard Dad
Loved to groom Miss Mahogany, and let Mahogany cuddle beside
Sylvester 1989 (estimated Born)
Found in building mail area noon hour 09 Feburary 1992
09 February 1992 - 19 January 2003 23:25

"Hello Miss Chicago 'White Sox', how are you 'Chico'?"
"Grunt" (thank you) ... as put out food for Chicago
"MEEEEEOOOOWWWW" So loud the world stops
A very determined Miss "White Sox"
AKA "Chico" ... Cheryl Crawford used as nickname
Loved to chase kibble slid down hall floor,
     bat about and then eat
Loved to hook paw in dish to toss out a single kibble
     at time, dart at as moved, then eat ... "Crunches"
Chicago "White Sox", "Chico" August 1989 (born),
     adopted 04 February 1991
05 October 2004 06:52 Quite "Grunts" ....
                      as lay Chicago on bed for last time
04 February 1991 - 05 October 2004 07:32


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29

[John L. Males]

[-- Attachment #1: Type: text/plain, Size: 9072 bytes --]

Marcelo,

Sorry gents, seems the LKML used to handel the RE numbering in long
past when I last mailed to LKML, bit not now, so resending this eMail
to ensure goes back to orignal thread so all the eMail discussion is
in one eMail thread.

My applogies if this caused confusion on the LKML.


Regards,

John L. Males
Willowdale, Ontario
Canada
02 March 2005 (16:06 -) 16:15


********** Reply Seperator **********

On (Wed) 2005-03-02 15:46:26 -0500 
John L. Males wrote in Message-ID:
20050302154626.65bc03e5.jlmales@softhome.net

To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
From: John L. Males <jlmales@softhome.net>
Subject: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29
Date: Wed, 2 Mar 2005 15:46:26 -0500

> Hi Marcello,
> 
> 
> ********** Reply Seperator **********
> 
> On (Wed) 2005-03-02 11:34:41 -0300 
> Marcelo Tosatti wrote in Message-ID:
> 20050302143440.GA2543@logos.cnet
> 
> To: Gene Heskett <gene.heskett@verizon.net>
> From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
> Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29
> Date: Wed, 2 Mar 2005 11:34:41 -0300
> 
> > 
> > n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote:
> > > On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote:
> > > >On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> > > >> Hi
> > > >>
> > > >> Never had to log a bug before, hope this is correctly done.
> > > >>
> > > >> Thanks
> > > >>
> > > >> Mark
> > > >>
> > > >> Detail....
> > > >>
> > > >> [1.] One line summary of the problem:
> > > >> SCSI tape drive is refusing to rewind after backup to allow
> > > >verify> and causing illegal seek error
> 
> In my experiences with this problem that I am sure is exactly the
> same issue, the tape in fact does rewind after creating the tar to
> then perfore the --verify option.  The illegal see error seems to
> arise after the rewind or more correctly bsf commands may be being
> used (but not confirmed this yet, another test I need to do in few
> days).  For sure the tape is positionted back.  I know as I have
> also done this test with larger directories and know and have heard
> the tape take long time to naturally get back to the start of tar
> file to be able to perform the --verify option.  That said I am
> using a DLT drive. Perhpas with different drivers or tape drivers
> this issue may have variations on theme and behaviour with net
> result the same error message and/or root cause.
> 
> > > >>
> > > >> [2.] Full description of the problem/report:
> > > >> On backup the tape drive is reporting the following error and
> > > >> failing it's backups.
> > > >>
> > > >> tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > > >>
> > > >> I have traced this back to failing at an upgrade of the
> > > >kernel to> 2.4.29 on Feb 8th. The backups have not worked
> > > >since. Replacement> Drives have been tried and cables to no
> > > >avail. I noticed in the> the changelog that a patch by Solar
> > > >Designer to the Scsi tape> return code had been made.
> 
> Last kernel to work correctly in 2.4 branch was 2.4.26.  Kernel
> versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience
> with DLT SCSI based tape.
> 
> > > >
> > > >v2.6 also contains the same problem BTW.
> > > >
> > > >Try this:
> > > >
> > > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144
> > > >-0300+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200
> > > >-0300@@ -3778,7 +3778,6 @@
> > > >  read:  st_read,
> > > >  write:  st_write,
> > > >  ioctl:  st_ioctl,
> > > >- llseek:  no_llseek,
> > > >  open:  st_open,
> > > >  flush:  st_flush,
> > > >  release: st_release,
> > > >-
> > > 
> > > Interesting Marcelo.  How long has this been true in 2.6?
> 
> In the 2.6 tree the tar --verify works with 2.6.7, but fails with
> 2.6.9. I am unable to test 2.6.8, but based on research of the code
> changes of 2.6.8 compared to the changes made in 2.4.27 re llseek I
> would expect 2.6.8 to fail as well with my DLT SCSI tape. 
> 
> > 
> > Actually I just checked and it seems v2.6 is not using
> > "no_llseek".
> > 
> > However John L. Males reports the same problem with v2.6 - John,
> > care to retest with v2.6.10 ?
> 
> My ability to test a 2.6.x kernel is limited to what 2.6.x kernel I
> can find on a livecd.  The 2.6.7 and 2.6.9 kernel tests I conducted
> were using Knoppix 3.6 and 3.7.  I do not have means at this time,
> nor time, to build up a dedicated drive to test 2.6.x kernels.  If
> someone knows of or can build a 2.6.10 kernel on a live CD I will be
> happy to do the test.  That said, I looked at the patch for 2.6.10
> and seems alot of changes were made to st.c in 2.6.10.  I did not
> see, but could of missed in looking, any lseek related change in
> 2.6.10.  Given how it seems the test I ran with the change in st.c
> Marcell suggested what is the expected thought on this issue with
> 2.6.10?  I am just asking from curiousity.  Again, if someone can
> tell me of a live cd or can easly make a live cd with the 2.6.10
> kernel I can test this issue wiht 2.6.10.  Perhaps there is someone
> else with a DLT/SCSI tape driver that could test this tar --verify
> issue on 2.6.10?
> 
> > 
> > > I thought I had an amanda problem, and eventually went to
> > > virtual tapes on disk, largely because of this.  However, I have
> > > to say it is working better than tapes ever did here.  Unforch,
> > > that 200GB disk is certainly a single point of failure I don't
> > > relish thinking about...
> > 
> > :)
> 
> 
> Regards,
> 
> John L. Males
> Willowdale, Ontario
> Canada
> 02 March 2005 (15:00 -) 15:46
> 
> 
> ==================================================================
> 
> 
> "Boooomer ... Boom Boom, how are you Boom Boom"
> "Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
>      intent Boomer is coming for attention
> Loved to kneed arm and lick arm with Boomers very large
>      tongue
> Able to catch, or at least hit, almost any object in flight
>      withing reach of front paws
> Boomer 1985 (Born), Adopted 04 September 1991
> 04 September 1991 - 08 February 2000 18:50
> 
> "How are you Mr. Sylvester?"
> "... Grunt Grunt" ... quick licks of nose
> Rolls over for pet and stomac rub when Dad arrives home
>      and grunting
> Runs back and forth from study, tilts head as glowing green
>      eyes stare for "attention please", grunts and meows,
>      repeats run, tilt head and stare few times for good
>      measure, grunts and meows
> Lays on floor just outside study to guard Dad
> Loved to groom Miss Mahogany, and let Mahogany cuddle beside
> Sylvester 1989 (estimated Born)
> Found in building mail area noon hour 09 Feburary 1992
> 09 February 1992 - 19 January 2003 23:25
> 
> "Hello Miss Chicago 'White Sox', how are you 'Chico'?"
> "Grunt" (thank you) ... as put out food for Chicago
> "MEEEEEOOOOWWWW" So loud the world stops
> A very determined Miss "White Sox"
> AKA "Chico" ... Cheryl Crawford used as nickname
> Loved to chase kibble slid down hall floor,
>      bat about and then eat
> Loved to hook paw in dish to toss out a single kibble
>      at time, dart at as moved, then eat ... "Crunches"
> Chicago "White Sox", "Chico" August 1989 (born),
>      adopted 04 February 1991
> 05 October 2004 06:52 Quite "Grunts" ....
>                       as lay Chicago on bed for last time
> 04 February 1991 - 05 October 2004 07:32
> 
> 


==================================================================


"Boooomer ... Boom Boom, how are you Boom Boom"
"Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
     intent Boomer is coming for attention
Loved to kneed arm and lick arm with Boomers very large
     tongue
Able to catch, or at least hit, almost any object in flight
     withing reach of front paws
Boomer 1985 (Born), Adopted 04 September 1991
04 September 1991 - 08 February 2000 18:50

"How are you Mr. Sylvester?"
"... Grunt Grunt" ... quick licks of nose
Rolls over for pet and stomac rub when Dad arrives home
     and grunting
Runs back and forth from study, tilts head as glowing green
     eyes stare for "attention please", grunts and meows,
     repeats run, tilt head and stare few times for good
     measure, grunts and meows
Lays on floor just outside study to guard Dad
Loved to groom Miss Mahogany, and let Mahogany cuddle beside
Sylvester 1989 (estimated Born)
Found in building mail area noon hour 09 Feburary 1992
09 February 1992 - 19 January 2003 23:25

"Hello Miss Chicago 'White Sox', how are you 'Chico'?"
"Grunt" (thank you) ... as put out food for Chicago
"MEEEEEOOOOWWWW" So loud the world stops
A very determined Miss "White Sox"
AKA "Chico" ... Cheryl Crawford used as nickname
Loved to chase kibble slid down hall floor,
     bat about and then eat
Loved to hook paw in dish to toss out a single kibble
     at time, dart at as moved, then eat ... "Crunches"
Chicago "White Sox", "Chico" August 1989 (born),
     adopted 04 February 1991
05 October 2004 06:52 Quite "Grunts" ....
                      as lay Chicago on bed for last time
04 February 1991 - 05 October 2004 07:32


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems with SCSI tape rewind / verify on 2.4.29

[John L. Males]

[-- Attachment #1: Type: text/plain, Size: 11721 bytes --]

Sorry gents,

Let me correct this one more time.


Regards,

John L. Males
Willowdale, Ontario
Canada
02 March 2005 16:26


********** Reply Seperator **********

On (Wed) 2005-03-02 16:15:07 -0500 
John L. Males wrote in Message-ID:
20050302161507.2a67385c.jlmales@softhome.net

To: marcelo.tosatti@cyclades.com
From: John L. Males <jlmales@softhome.net>
Subject: Re: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29
Date: Wed, 2 Mar 2005 16:15:07 -0500

> Marcelo,
> 
> Sorry gents, seems the LKML used to handel the RE numbering in long
> past when I last mailed to LKML, bit not now, so resending this
> eMail to ensure goes back to orignal thread so all the eMail
> discussion is in one eMail thread.
> 
> My applogies if this caused confusion on the LKML.
> 
> 
> Regards,
> 
> John L. Males
> Willowdale, Ontario
> Canada
> 02 March 2005 (16:06 -) 16:15
> 
> 
> ********** Reply Seperator **********
> 
> On (Wed) 2005-03-02 15:46:26 -0500 
> John L. Males wrote in Message-ID:
> 20050302154626.65bc03e5.jlmales@softhome.net
> 
> To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
> From: John L. Males <jlmales@softhome.net>
> Subject: Re[03]: Problems with SCSI tape rewind / verify on 2.4.29
> Date: Wed, 2 Mar 2005 15:46:26 -0500
> 
> > Hi Marcello,
> > 
> > 
> > ********** Reply Seperator **********
> > 
> > On (Wed) 2005-03-02 11:34:41 -0300 
> > Marcelo Tosatti wrote in Message-ID:
> > 20050302143440.GA2543@logos.cnet
> > 
> > To: Gene Heskett <gene.heskett@verizon.net>
> > From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
> > Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29
> > Date: Wed, 2 Mar 2005 11:34:41 -0300
> > 
> > > 
> > > n Wed, Mar 02, 2005 at 12:08:51PM -0500, Gene Heskett wrote:
> > > > On Wednesday 02 March 2005 07:03, Marcelo Tosatti wrote:
> > > > >On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> > > > >> Hi
> > > > >>
> > > > >> Never had to log a bug before, hope this is correctly done.
> > > > >>
> > > > >> Thanks
> > > > >>
> > > > >> Mark
> > > > >>
> > > > >> Detail....
> > > > >>
> > > > >> [1.] One line summary of the problem:
> > > > >> SCSI tape drive is refusing to rewind after backup to allow
> > > > >verify> and causing illegal seek error
> > 
> > In my experiences with this problem that I am sure is exactly the
> > same issue, the tape in fact does rewind after creating the tar to
> > then perfore the --verify option.  The illegal see error seems to
> > arise after the rewind or more correctly bsf commands may be being
> > used (but not confirmed this yet, another test I need to do in few
> > days).  For sure the tape is positionted back.  I know as I have
> > also done this test with larger directories and know and have
> > heard the tape take long time to naturally get back to the start
> > of tar file to be able to perform the --verify option.  That said
> > I am using a DLT drive. Perhpas with different drivers or tape
> > drivers this issue may have variations on theme and behaviour with
> > net result the same error message and/or root cause.
> > 
> > > > >>
> > > > >> [2.] Full description of the problem/report:
> > > > >> On backup the tape drive is reporting the following error
> > > > >and> failing it's backups.
> > > > >>
> > > > >> tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > > > >>
> > > > >> I have traced this back to failing at an upgrade of the
> > > > >kernel to> 2.4.29 on Feb 8th. The backups have not worked
> > > > >since. Replacement> Drives have been tried and cables to no
> > > > >avail. I noticed in the> the changelog that a patch by Solar
> > > > >Designer to the Scsi tape> return code had been made.
> > 
> > Last kernel to work correctly in 2.4 branch was 2.4.26.  Kernel
> > versions 2.4.27, 2.4.28 and 2.4.29 all fail based on my experience
> > with DLT SCSI based tape.
> > 
> > > > >
> > > > >v2.6 also contains the same problem BTW.
> > > > >
> > > > >Try this:
> > > > >
> > > > >--- a/drivers/scsi/st.c.orig 2005-03-02 09:02:13.637158144
> > > > >-0300+++ b/drivers/scsi/st.c 2005-03-02 09:02:20.208159200
> > > > >-0300@@ -3778,7 +3778,6 @@
> > > > >  read:  st_read,
> > > > >  write:  st_write,
> > > > >  ioctl:  st_ioctl,
> > > > >- llseek:  no_llseek,
> > > > >  open:  st_open,
> > > > >  flush:  st_flush,
> > > > >  release: st_release,
> > > > >-
> > > > 
> > > > Interesting Marcelo.  How long has this been true in 2.6?
> > 
> > In the 2.6 tree the tar --verify works with 2.6.7, but fails with
> > 2.6.9. I am unable to test 2.6.8, but based on research of the
> > code changes of 2.6.8 compared to the changes made in 2.4.27 re
> > llseek I would expect 2.6.8 to fail as well with my DLT SCSI tape.
> > 
> > 
> > > 
> > > Actually I just checked and it seems v2.6 is not using
> > > "no_llseek".
> > > 
> > > However John L. Males reports the same problem with v2.6 - John,
> > > care to retest with v2.6.10 ?
> > 
> > My ability to test a 2.6.x kernel is limited to what 2.6.x kernel
> > I can find on a livecd.  The 2.6.7 and 2.6.9 kernel tests I
> > conducted were using Knoppix 3.6 and 3.7.  I do not have means at
> > this time, nor time, to build up a dedicated drive to test 2.6.x
> > kernels.  If someone knows of or can build a 2.6.10 kernel on a
> > live CD I will be happy to do the test.  That said, I looked at
> > the patch for 2.6.10 and seems alot of changes were made to st.c
> > in 2.6.10.  I did not see, but could of missed in looking, any
> > lseek related change in 2.6.10.  Given how it seems the test I ran
> > with the change in st.c Marcell suggested what is the expected
> > thought on this issue with 2.6.10?  I am just asking from
> > curiousity.  Again, if someone can tell me of a live cd or can
> > easly make a live cd with the 2.6.10 kernel I can test this issue
> > wiht 2.6.10.  Perhaps there is someone else with a DLT/SCSI tape
> > driver that could test this tar --verify issue on 2.6.10?
> > 
> > > 
> > > > I thought I had an amanda problem, and eventually went to
> > > > virtual tapes on disk, largely because of this.  However, I
> > > > have to say it is working better than tapes ever did here. 
> > > > Unforch, that 200GB disk is certainly a single point of
> > > > failure I don't relish thinking about...
> > > 
> > > :)
> > 
> > 
> > Regards,
> > 
> > John L. Males
> > Willowdale, Ontario
> > Canada
> > 02 March 2005 (15:00 -) 15:46
> > 
> > 
> > ==================================================================
> > 
> > 
> > "Boooomer ... Boom Boom, how are you Boom Boom"
> > "Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
> >      intent Boomer is coming for attention
> > Loved to kneed arm and lick arm with Boomers very large
> >      tongue
> > Able to catch, or at least hit, almost any object in flight
> >      withing reach of front paws
> > Boomer 1985 (Born), Adopted 04 September 1991
> > 04 September 1991 - 08 February 2000 18:50
> > 
> > "How are you Mr. Sylvester?"
> > "... Grunt Grunt" ... quick licks of nose
> > Rolls over for pet and stomac rub when Dad arrives home
> >      and grunting
> > Runs back and forth from study, tilts head as glowing green
> >      eyes stare for "attention please", grunts and meows,
> >      repeats run, tilt head and stare few times for good
> >      measure, grunts and meows
> > Lays on floor just outside study to guard Dad
> > Loved to groom Miss Mahogany, and let Mahogany cuddle beside
> > Sylvester 1989 (estimated Born)
> > Found in building mail area noon hour 09 Feburary 1992
> > 09 February 1992 - 19 January 2003 23:25
> > 
> > "Hello Miss Chicago 'White Sox', how are you 'Chico'?"
> > "Grunt" (thank you) ... as put out food for Chicago
> > "MEEEEEOOOOWWWW" So loud the world stops
> > A very determined Miss "White Sox"
> > AKA "Chico" ... Cheryl Crawford used as nickname
> > Loved to chase kibble slid down hall floor,
> >      bat about and then eat
> > Loved to hook paw in dish to toss out a single kibble
> >      at time, dart at as moved, then eat ... "Crunches"
> > Chicago "White Sox", "Chico" August 1989 (born),
> >      adopted 04 February 1991
> > 05 October 2004 06:52 Quite "Grunts" ....
> >                       as lay Chicago on bed for last time
> > 04 February 1991 - 05 October 2004 07:32
> > 
> > 
> 
> 
> ==================================================================
> 
> 
> "Boooomer ... Boom Boom, how are you Boom Boom"
> "Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
>      intent Boomer is coming for attention
> Loved to kneed arm and lick arm with Boomers very large
>      tongue
> Able to catch, or at least hit, almost any object in flight
>      withing reach of front paws
> Boomer 1985 (Born), Adopted 04 September 1991
> 04 September 1991 - 08 February 2000 18:50
> 
> "How are you Mr. Sylvester?"
> "... Grunt Grunt" ... quick licks of nose
> Rolls over for pet and stomac rub when Dad arrives home
>      and grunting
> Runs back and forth from study, tilts head as glowing green
>      eyes stare for "attention please", grunts and meows,
>      repeats run, tilt head and stare few times for good
>      measure, grunts and meows
> Lays on floor just outside study to guard Dad
> Loved to groom Miss Mahogany, and let Mahogany cuddle beside
> Sylvester 1989 (estimated Born)
> Found in building mail area noon hour 09 Feburary 1992
> 09 February 1992 - 19 January 2003 23:25
> 
> "Hello Miss Chicago 'White Sox', how are you 'Chico'?"
> "Grunt" (thank you) ... as put out food for Chicago
> "MEEEEEOOOOWWWW" So loud the world stops
> A very determined Miss "White Sox"
> AKA "Chico" ... Cheryl Crawford used as nickname
> Loved to chase kibble slid down hall floor,
>      bat about and then eat
> Loved to hook paw in dish to toss out a single kibble
>      at time, dart at as moved, then eat ... "Crunches"
> Chicago "White Sox", "Chico" August 1989 (born),
>      adopted 04 February 1991
> 05 October 2004 06:52 Quite "Grunts" ....
>                       as lay Chicago on bed for last time
> 04 February 1991 - 05 October 2004 07:32
> 
> 


==================================================================


"Boooomer ... Boom Boom, how are you Boom Boom"
"Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
     intent Boomer is coming for attention
Loved to kneed arm and lick arm with Boomers very large
     tongue
Able to catch, or at least hit, almost any object in flight
     withing reach of front paws
Boomer 1985 (Born), Adopted 04 September 1991
04 September 1991 - 08 February 2000 18:50

"How are you Mr. Sylvester?"
"... Grunt Grunt" ... quick licks of nose
Rolls over for pet and stomac rub when Dad arrives home
     and grunting
Runs back and forth from study, tilts head as glowing green
     eyes stare for "attention please", grunts and meows,
     repeats run, tilt head and stare few times for good
     measure, grunts and meows
Lays on floor just outside study to guard Dad
Loved to groom Miss Mahogany, and let Mahogany cuddle beside
Sylvester 1989 (estimated Born)
Found in building mail area noon hour 09 Feburary 1992
09 February 1992 - 19 January 2003 23:25

"Hello Miss Chicago 'White Sox', how are you 'Chico'?"
"Grunt" (thank you) ... as put out food for Chicago
"MEEEEEOOOOWWWW" So loud the world stops
A very determined Miss "White Sox"
AKA "Chico" ... Cheryl Crawford used as nickname
Loved to chase kibble slid down hall floor,
     bat about and then eat
Loved to hook paw in dish to toss out a single kibble
     at time, dart at as moved, then eat ... "Crunches"
Chicago "White Sox", "Chico" August 1989 (born),
     adopted 04 February 1991
05 October 2004 06:52 Quite "Grunts" ....
                      as lay Chicago on bed for last time
04 February 1991 - 05 October 2004 07:32


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Kai Makisara]

On Wed, 2 Mar 2005, Marcelo Tosatti wrote:

> On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> > Hi
> > 
> > Never had to log a bug before, hope this is correctly done.
> > 
> > Thanks
> > 
> > Mark
> > 
> > Detail....
> > 
> > [1.] One line summary of the problem:    
> > SCSI tape drive is refusing to rewind after backup to allow verify and
> > causing illegal seek error
> > 
> > [2.] Full description of the problem/report:
> > On backup the tape drive is reporting the following error and failing
> > it's backups.
> > 
> > tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > 
> > I have traced this back to failing at an upgrade of the kernel to 2.4.29
> > on Feb 8th. The backups have not worked since. Replacement Drives have
> > been tried and cables to no avail. I noticed in the the changelog that a
> > patch by Solar Designer to the Scsi tape return code had been made. 

BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a tape 
driver is supposed to return ENOMEM in the case that was changed to return 
EIO ;-(

> 
> v2.6 also contains the same problem BTW.
> 
> Try this:
> 
> --- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
> +++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
> @@ -3778,7 +3778,6 @@
>  	read:		st_read,
>  	write:		st_write,
>  	ioctl:		st_ioctl,
> -	llseek:		no_llseek,
>  	open:		st_open,
>  	flush:		st_flush,
>  	release:	st_release,

This change covers up the problem. The real bug is in tar. The following 
code is from tar is supposed to reposition the tape to the beginning of 
the file jus written:

#ifdef MTIOCTOP
  {
    struct mtop operation;
    int status;

    operation.mt_op = MTBSF;
    operation.mt_count = 1;
    if (status = rmtioctl (archive, MTIOCTOP, (char *) &operation), status 
< 0)
      {
        if (errno != EIO
            || (status = rmtioctl (archive, MTIOCTOP, (char *) 
&operation),
                status < 0))
          {
#endif
            if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
              {
                /* Lseek failed.  Try a different method.  */
                seek_warn (archive_name_array[0]);
                return;
              }
#ifdef MTIOCTOP
          }
      }
  }
#endif


Here is output from strace showing what happens with 'tar -c -W' applied 
at the beginning of the tape (this is using kernel 2.6.11-rc4 but the same 
probably happens with 2.4.29):
...
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 
0x7fffffffecd0) = -1 EIO (Input/output error)
ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 
0x7fffffffecd0) = -1 EIO (Input/output error)
lseek(3, 0, SEEK_SET)                   = -1 ESPIPE (Illegal seek)

So, both tape positioning commands fail and the code falls back to lseek. 
Earlier it has returned success even though it has not done anything (this 
was on purpose because it is the way some other Unices behave and with 
reason). In that case this tar succeeded but it was pure luck. The first 
BSF did position the tape correctly although it did fail.

The 2.6 st driver does contain this near the beginning of st_open():

        nonseekable_open(inode, filp);

This probably makes lseek fail. This code has been in st.c since 2.6.8.




-- 
Kai

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Marcelo Tosatti]

On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote:
> On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
> 
> > On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> > > Hi
> > > 
> > > Never had to log a bug before, hope this is correctly done.
> > > 
> > > Thanks
> > > 
> > > Mark
> > > 
> > > Detail....
> > > 
> > > [1.] One line summary of the problem:    
> > > SCSI tape drive is refusing to rewind after backup to allow verify and
> > > causing illegal seek error
> > > 
> > > [2.] Full description of the problem/report:
> > > On backup the tape drive is reporting the following error and failing
> > > it's backups.
> > > 
> > > tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > > 
> > > I have traced this back to failing at an upgrade of the kernel to 2.4.29
> > > on Feb 8th. The backups have not worked since. Replacement Drives have
> > > been tried and cables to no avail. I noticed in the the changelog that a
> > > patch by Solar Designer to the Scsi tape return code had been made. 
> 
> BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a tape 
> driver is supposed to return ENOMEM in the case that was changed to return 
> EIO ;-(

Reverted.

> > v2.6 also contains the same problem BTW.
> > 
> > Try this:
> > 
> > --- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
> > +++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
> > @@ -3778,7 +3778,6 @@
> >  	read:		st_read,
> >  	write:		st_write,
> >  	ioctl:		st_ioctl,
> > -	llseek:		no_llseek,
> >  	open:		st_open,
> >  	flush:		st_flush,
> >  	release:	st_release,
> 
> This change covers up the problem. The real bug is in tar. The following 
> code is from tar is supposed to reposition the tape to the beginning of 
> the file jus written:
> 
> #ifdef MTIOCTOP
>   {
>     struct mtop operation;
>     int status;
> 
>     operation.mt_op = MTBSF;
>     operation.mt_count = 1;
>     if (status = rmtioctl (archive, MTIOCTOP, (char *) &operation), status 
> < 0)
>       {
>         if (errno != EIO
>             || (status = rmtioctl (archive, MTIOCTOP, (char *) 
> &operation),
>                 status < 0))
>           {
> #endif
>             if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
>               {
>                 /* Lseek failed.  Try a different method.  */
>                 seek_warn (archive_name_array[0]);
>                 return;
>               }
> #ifdef MTIOCTOP
>           }
>       }
>   }
> #endif
> 
> 
> Here is output from strace showing what happens with 'tar -c -W' applied 
> at the beginning of the tape (this is using kernel 2.6.11-rc4 but the same 
> probably happens with 2.4.29):
> ...
> ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 
> 0x7fffffffecd0) = -1 EIO (Input/output error)
> ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 
> 0x7fffffffecd0) = -1 EIO (Input/output error)
> lseek(3, 0, SEEK_SET)                   = -1 ESPIPE (Illegal seek)
> 
> So, both tape positioning commands fail and the code falls back to lseek. 
> Earlier it has returned success even though it has not done anything (this 
> was on purpose because it is the way some other Unices behave and with 
> reason). In that case this tar succeeded but it was pure luck. The first 
> BSF did position the tape correctly although it did fail.
> 
> The 2.6 st driver does contain this near the beginning of st_open():
> 
>         nonseekable_open(inode, filp);
> 
> This probably makes lseek fail. This code has been in st.c since 2.6.8.

Thanks for the cluebat Kai, is this problem fixed in newer versions of tar? 

I suspect v2.4 should work with older versions of tar, so we should keep 
"lseek" working to make it happy. What is your opinion?

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Kai Makisara]

On Wed, 2 Mar 2005, Marcelo Tosatti wrote:

> On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote:
...
> > BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a tape 
> > driver is supposed to return ENOMEM in the case that was changed to return 
> > EIO ;-(
> 
> Reverted.
> 
Thanks.

...
> Thanks for the cluebat Kai, is this problem fixed in newer versions of tar? 
> 
The current CVS version seems to have the same code I quoted.

> I suspect v2.4 should work with older versions of tar, so we should keep 
> "lseek" working to make it happy. What is your opinion?
> 
I commented this in the other reply I just sent and I don't have a clear 
preference. I just hope that 2.4 and 2.6 are fixed in a compatible way.

-- 
Kai

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Andrew Morton]

Kai Makisara <Kai.Makisara@kolumbus.fi> wrote:
>
> > 
>  > v2.6 also contains the same problem BTW.
>  > 
>  > Try this:
>  > 
>  > --- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
>  > +++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
>  > @@ -3778,7 +3778,6 @@
>  >  	read:		st_read,
>  >  	write:		st_write,
>  >  	ioctl:		st_ioctl,
>  > -	llseek:		no_llseek,
>  >  	open:		st_open,
>  >  	flush:		st_flush,
>  >  	release:	st_release,
> 
>  This change covers up the problem. The real bug is in tar.

In that case we're kinda screwed, and should change the kernel to make tar
work again.  We can send a bug report to the tar folks (good luck) and wait
a few years.

>  The first BSF did position the tape correctly although it did fail.

(what's a BSF?)

If it positioned the tape successfully, why did it claim that it failed? 
If we were to fix that up, would tar then be happy?

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Andreas Steinmetz]

Andrew Morton wrote:
> (what's a BSF?)

Backward space count files (man mt).

-- 
Andreas Steinmetz                       SPAMmers use robotrap@domdv.de

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Kai Makisara]

On Wed, 2 Mar 2005, Andrew Morton wrote:

> Kai Makisara <Kai.Makisara@kolumbus.fi> wrote:
> >
> > > 
> >  > v2.6 also contains the same problem BTW.
> >  > 
> >  > Try this:
> >  > 
> >  > --- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
> >  > +++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
> >  > @@ -3778,7 +3778,6 @@
> >  >  	read:		st_read,
> >  >  	write:		st_write,
> >  >  	ioctl:		st_ioctl,
> >  > -	llseek:		no_llseek,
> >  >  	open:		st_open,
> >  >  	flush:		st_flush,
> >  >  	release:	st_release,
> > 
> >  This change covers up the problem. The real bug is in tar.
> 
> In that case we're kinda screwed, and should change the kernel to make tar
> work again.  We can send a bug report to the tar folks (good luck) and wait
> a few years.
> 
> >  The first BSF did position the tape correctly although it did fail.
> 
> (what's a BSF?)
> 
> If it positioned the tape successfully, why did it claim that it failed? 

BSF moves the tape backwards over filemarks. tar tries to move over one 
filemark. It does not find it because it ends to the beginning of the 
tape. This is why the operation fails. However, the tape is at the 
beginning and this is the correct place with regard to what is done next.

> If we were to fix that up, would tar then be happy?

It is not fixable in the kernel. The beginning of the tape is a special 
case because there is no filemark. Any application should take this into 
account. We could fake a filemark there but this would lead to problems 
because then we could "skip" backwards indefinitely even when the tape 
moves nowhere. This could confuse other applications.

If seek with tape is changed back to returning success, this would enable 
correct tar --verify at the beginning of the tape. However, I am not sure 
what happens if we are not at the beginning. I will investigate this and 
suggest a long term fix to the tar people (a fix that should be compatible 
with all Unix tape semantics I know) and also suggest possible fixes to st 
(this may include automatic writing of a filemark when BSF is used after 
writes).

If you think want to make st return success for seeks even if nothing 
happens (as it did earlier), I don't have anything against that. It would 
solve the practical problem several people have reported recently. (My 
recommendation for the people seeing this problem is to do verification 
separately with 'tar -d'.)

-- 
Kai

Re: Problems with SCSI tape rewind / verify on 2.4.29

[Andrew Morton]

Kai Makisara <Kai.Makisara@kolumbus.fi> wrote:
>
> f seek with tape is changed back to returning success, this would enable 
> correct tar --verify at the beginning of the tape. However, I am not sure 
> what happens if we are not at the beginning. I will investigate this and 
> suggest a long term fix to the tar people (a fix that should be compatible 
> with all Unix tape semantics I know) and also suggest possible fixes to st 
> (this may include automatic writing of a filemark when BSF is used after 
> writes).

Yes, please let's get a tar fix in the pipeline.

GNU tar must run on a lot of operating systems.  It's odd.

> If you think want to make st return success for seeks even if nothing 
> happens (as it did earlier), I don't have anything against that. It would 
> solve the practical problem several people have reported recently. (My 
> recommendation for the people seeing this problem is to do verification 
> separately with 'tar -d'.)

Yes, I think we need to grit our teeth and do this.  I'll stick a comment
in there.

RE: Problems with SCSI tape rewind / verify on 2.4.29

[Mark Yeatman]

Hi

Many Thanks Marcelo, the patch has corrected the fault in our 2.4.29
kernel.

Mark 

-----Original Message-----
From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com] 
Sent: 02 March 2005 12:04
To: Mark Yeatman
Cc: linux-kernel@vger.kernel.org; akpm@osdl.org
Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29

On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> Hi
> 
> Never had to log a bug before, hope this is correctly done.
> 
> Thanks
> 
> Mark
> 
> Detail....
> 
> [1.] One line summary of the problem:    
> SCSI tape drive is refusing to rewind after backup to allow verify and
> causing illegal seek error
> 
> [2.] Full description of the problem/report:
> On backup the tape drive is reporting the following error and failing
> it's backups.
> 
> tar: /dev/st0: Warning: Cannot seek: Illegal seek
> 
> I have traced this back to failing at an upgrade of the kernel to
2.4.29
> on Feb 8th. The backups have not worked since. Replacement Drives have
> been tried and cables to no avail. I noticed in the the changelog that
a
> patch by Solar Designer to the Scsi tape return code had been made. 

v2.6 also contains the same problem BTW.

Try this:

--- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
+++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
@@ -3778,7 +3778,6 @@
 	read:		st_read,
 	write:		st_write,
 	ioctl:		st_ioctl,
-	llseek:		no_llseek,
 	open:		st_open,
 	flush:		st_flush,
 	release:	st_release,

Re: Problems with SCSI tape rewind / verify on 2.4.29

[John L. Males]

[-- Attachment #1: Type: text/plain, Size: 6129 bytes --]

Marcelo,

My couple cents worth:

> On Wed, Mar 02, 2005 at 11:17:19PM +0200, Kai Makisara wrote:
> > On Wed, 2 Mar 2005, Marcelo Tosatti wrote:
> > 
> > > On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> > > > Hi
> > > > 
> > > > Never had to log a bug before, hope this is correctly done.
> > > > 
> > > > Thanks
> > > > 
> > > > Mark
> > > > 
> > > > Detail....
> > > > 
> > > > [1.] One line summary of the problem:    
> > > > SCSI tape drive is refusing to rewind after backup to allow
> > > > verify and causing illegal seek error
> > > > 
> > > > [2.] Full description of the problem/report:
> > > > On backup the tape drive is reporting the following error and
> > > > failing it's backups.
> > > > 
> > > > tar: /dev/st0: Warning: Cannot seek: Illegal seek
> > > > 
> > > > I have traced this back to failing at an upgrade of the kernel
> > > > to 2.4.29 on Feb 8th. The backups have not worked since.
> > > > Replacement Drives have been tried and cables to no avail. I
> > > > noticed in the the changelog that a patch by Solar Designer to
> > > > the Scsi tape return code had been made. 
> > 
> > BTW, this "fix" by Solar Designer introduces a bug to 2.4.29: a
> > tape driver is supposed to return ENOMEM in the case that was
> > changed to return EIO ;-(
> 
> Reverted.
> 
> > > v2.6 also contains the same problem BTW.
> > > 
> > > Try this:
> > > 
> > > --- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
> > > +++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
> > > @@ -3778,7 +3778,6 @@
> > >  	read:		st_read,
> > >  	write:		st_write,
> > >  	ioctl:		st_ioctl,
> > > -	llseek:		no_llseek,
> > >  	open:		st_open,
> > >  	flush:		st_flush,
> > >  	release:	st_release,
> > 
> > This change covers up the problem. The real bug is in tar. The
> > following code is from tar is supposed to reposition the tape to
> > the beginning of the file jus written:
> > 
> > #ifdef MTIOCTOP
> >   {
> >     struct mtop operation;
> >     int status;
> > 
> >     operation.mt_op = MTBSF;
> >     operation.mt_count = 1;
> >     if (status = rmtioctl (archive, MTIOCTOP, (char *)
> >     &operation), status 
> > < 0)
> >       {
> >         if (errno != EIO
> >             || (status = rmtioctl (archive, MTIOCTOP, (char *) 
> > &operation),
> >                 status < 0))
> >           {
> > #endif
> >             if (rmtlseek (archive, (off_t) 0, SEEK_SET) != 0)
> >               {
> >                 /* Lseek failed.  Try a different method.  */
> >                 seek_warn (archive_name_array[0]);
> >                 return;
> >               }
> > #ifdef MTIOCTOP
> >           }
> >       }
> >   }
> > #endif
> > 
> > 
> > Here is output from strace showing what happens with 'tar -c -W'
> > applied at the beginning of the tape (this is using kernel
> > 2.6.11-rc4 but the same probably happens with 2.4.29):
> > ...
> > ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 
> > 0x7fffffffecd0) = -1 EIO (Input/output error)
> > ioctl(3, MGSL_IOCGPARAMS or MTIOCTOP or SNDCTL_MIDI_MPUMODE, 
> > 0x7fffffffecd0) = -1 EIO (Input/output error)
> > lseek(3, 0, SEEK_SET)                   = -1 ESPIPE (Illegal seek)
> > 
> > So, both tape positioning commands fail and the code falls back to
> > lseek. Earlier it has returned success even though it has not done
> > anything (this was on purpose because it is the way some other
> > Unices behave and with reason). In that case this tar succeeded
> > but it was pure luck. The first BSF did position the tape
> > correctly although it did fail.
> > 
> > The 2.6 st driver does contain this near the beginning of
> > st_open():
> > 
> >         nonseekable_open(inode, filp);
> > 
> > This probably makes lseek fail. This code has been in st.c since
> > 2.6.8.
> 
> Thanks for the cluebat Kai, is this problem fixed in newer versions
> of tar? 

My testing last week or so has been with the latest tar, tar-1.15.1-2,
tar 1.14 and 1.13 had same lseek --verify issues.

> 
> I suspect v2.4 should work with older versions of tar, so we should
> keep "lseek" working to make it happy. What is your opinion?


I would agree in the lseek sense.  I feel that if there is some bad
behaviour in tar it should be reported to the tar folks to be fixed so
long term things are done correctly and over time the kernel
worarounds can be depreciated.


Regards

John L. Males
Willowdale, Ontario
Canada
02 March 2005 (17:04 -) 17:25


==================================================================


"Boooomer ... Boom Boom, how are you Boom Boom"
"Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
     intent Boomer is coming for attention
Loved to kneed arm and lick arm with Boomers very large
     tongue
Able to catch, or at least hit, almost any object in flight
     withing reach of front paws
Boomer 1985 (Born), Adopted 04 September 1991
04 September 1991 - 08 February 2000 18:50

"How are you Mr. Sylvester?"
"... Grunt Grunt" ... quick licks of nose
Rolls over for pet and stomac rub when Dad arrives home
     and grunting
Runs back and forth from study, tilts head as glowing green
     eyes stare for "attention please", grunts and meows,
     repeats run, tilt head and stare few times for good
     measure, grunts and meows
Lays on floor just outside study to guard Dad
Loved to groom Miss Mahogany, and let Mahogany cuddle beside
Sylvester 1989 (estimated Born)
Found in building mail area noon hour 09 Feburary 1992
09 February 1992 - 19 January 2003 23:25

"Hello Miss Chicago 'White Sox', how are you 'Chico'?"
"Grunt" (thank you) ... as put out food for Chicago
"MEEEEEOOOOWWWW" So loud the world stops
A very determined Miss "White Sox"
AKA "Chico" ... Cheryl Crawford used as nickname
Loved to chase kibble slid down hall floor,
     bat about and then eat
Loved to hook paw in dish to toss out a single kibble
     at time, dart at as moved, then eat ... "Crunches"
Chicago "White Sox", "Chico" August 1989 (born),
     adopted 04 February 1991
05 October 2004 06:52 Quite "Grunts" ....
                      as lay Chicago on bed for last time
04 February 1991 - 05 October 2004 07:32


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems with SCSI tape rewind / verify on 2.4.29

[John L. Males]

[-- Attachment #1: Type: text/plain, Size: 4305 bytes --]

Andrew/Kai,

> List:       linux-kernel
> Subject:    Re: Problems with SCSI tape rewind / verify on 2.4.29
> From:       Andrew Morton <akpm () osdl ! org>
> Date:       2005-03-02 22:17:11
> Message-ID: <20050302141711.00ec7147.akpm () osdl ! org>
> [Download message RAW]
> 
> Kai Makisara <Kai.Makisara@kolumbus.fi> wrote:
> >
> > f seek with tape is changed back to returning success, this would
> > enable correct tar --verify at the beginning of the tape. However,
> > I am not sure what happens if we are not at the beginning. I will
> > investigate this and suggest a long term fix to the tar people (a
> > fix that should be compatible with all Unix tape semantics I know)
> > and also suggest possible fixes to st (this may include automatic
> > writing of a filemark when BSF is used after writes).

Kai,

I have a second problem that is perhaps another case of kernel and tar
combined effect problem.  I have not had time to test with the 2.6.7
and 2.6.9 knoppix based kernels to see if same problem as >= 2.4.26
has.  Can you hold out about 3-4 days for me to do the test and report
the issue to Marcelo to screen first, Kai?  I have feeling what I
experienced in testing change to st.c Marcelo suggested that caused me
to try 2.4.26 again and fail on this new issue has some bearing on
tape positioning you want to check out.

> 
> Yes, please let's get a tar fix in the pipeline.
> 
> GNU tar must run on a lot of operating systems.  It's odd.
> 
> > If you think want to make st return success for seeks even if
> > nothing happens (as it did earlier), I don't have anything against
> > that. It would 

I think it is important if an error is enccountered a non-successful
return (code) is returned.  If an action is required that requires no
action as it is at the place/state/position being requested it is
reasonable to return a successful return (code). 

> > solve the practical problem several people have reported recently.
> > (My recommendation for the people seeing this problem is to do
> > verification separately with 'tar -d'.)

As aside, I have tried the tar -d option as well and it worked, but
was my understanding the --verify does a data readback compare of the
files in the tar, whereas the tar -d option only compares if files
names in tar to directory?  That to me means a big difference in
confidance the tar backup is ok, as I look to have readback verify to
increase confidance of backup success.

> 
> Yes, I think we need to grit our teeth and do this.  I'll stick a
> comment in there.


Regards,

John L. Males
Willowdale, Ontario
Canada
02 March 2005 (17:45 -) 18:51

==================================================================


"Boooomer ... Boom Boom, how are you Boom Boom"
"Meoaaaawwwww, meoaaaaaawwww" as Boomer loudly announces
     intent Boomer is coming for attention
Loved to kneed arm and lick arm with Boomers very large
     tongue
Able to catch, or at least hit, almost any object in flight
     withing reach of front paws
Boomer 1985 (Born), Adopted 04 September 1991
04 September 1991 - 08 February 2000 18:50

"How are you Mr. Sylvester?"
"... Grunt Grunt" ... quick licks of nose
Rolls over for pet and stomac rub when Dad arrives home
     and grunting
Runs back and forth from study, tilts head as glowing green
     eyes stare for "attention please", grunts and meows,
     repeats run, tilt head and stare few times for good
     measure, grunts and meows
Lays on floor just outside study to guard Dad
Loved to groom Miss Mahogany, and let Mahogany cuddle beside
Sylvester 1989 (estimated Born)
Found in building mail area noon hour 09 Feburary 1992
09 February 1992 - 19 January 2003 23:25

"Hello Miss Chicago 'White Sox', how are you 'Chico'?"
"Grunt" (thank you) ... as put out food for Chicago
"MEEEEEOOOOWWWW" So loud the world stops
A very determined Miss "White Sox"
AKA "Chico" ... Cheryl Crawford used as nickname
Loved to chase kibble slid down hall floor,
     bat about and then eat
Loved to hook paw in dish to toss out a single kibble
     at time, dart at as moved, then eat ... "Crunches"
Chicago "White Sox", "Chico" August 1989 (born),
     adopted 04 February 1991
05 October 2004 06:52 Quite "Grunts" ....
                      as lay Chicago on bed for last time
04 February 1991 - 05 October 2004 07:32


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: Problems with SCSI tape rewind / verify on 2.4.29

[Mark Yeatman]

This corrected the problem on 2.4.29. Thanks Marcelo and all for your
help.

Mark


-----Original Message-----
From: Marcelo Tosatti [mailto:marcelo.tosatti@cyclades.com] 
Sent: 02 March 2005 12:04
To: Mark Yeatman
Cc: linux-kernel@vger.kernel.org; akpm@osdl.org
Subject: Re: Problems with SCSI tape rewind / verify on 2.4.29

On Wed, Mar 02, 2005 at 11:15:42AM -0000, Mark Yeatman wrote:
> Hi
> 
> Never had to log a bug before, hope this is correctly done.
> 
> Thanks
> 
> Mark
> 
> Detail....
> 
> [1.] One line summary of the problem:    
> SCSI tape drive is refusing to rewind after backup to allow verify and
> causing illegal seek error
> 
> [2.] Full description of the problem/report:
> On backup the tape drive is reporting the following error and failing
> it's backups.
> 
> tar: /dev/st0: Warning: Cannot seek: Illegal seek
> 
> I have traced this back to failing at an upgrade of the kernel to
2.4.29
> on Feb 8th. The backups have not worked since. Replacement Drives have
> been tried and cables to no avail. I noticed in the the changelog that
a
> patch by Solar Designer to the Scsi tape return code had been made. 

v2.6 also contains the same problem BTW.

Try this:

--- a/drivers/scsi/st.c.orig	2005-03-02 09:02:13.637158144 -0300
+++ b/drivers/scsi/st.c	2005-03-02 09:02:20.208159200 -0300
@@ -3778,7 +3778,6 @@
 	read:		st_read,
 	write:		st_write,
 	ioctl:		st_ioctl,
-	llseek:		no_llseek,
 	open:		st_open,
 	flush:		st_flush,
 	release:	st_release,