[BUG] Sym. 53c895 fails accessing tape device - kernel 2.9.1-rc1-bk1 trough rc2-bk12

[BUG] Sym. 53c895 fails accessing tape device - kernel 2.9.1-rc1-bk1 trough rc2-bk12

[Alexander Stohr]

Hello,

with latest update to a test kernel,
i was suddenly unable to access the data on my backup tapes.

the problem is not present for kernel 2.6.8.1
but it is verified from 2.9.1-rc1-bk1 till rc2-bk12
with some spaces and some variations in error.

in the beginning it merely looks like this:
  kernel: st0: Incorrect block size.

then it changed slightly to this:
  kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 
  kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 
  kernel: st0: Block limits 1 - 16777215 bytes. 
  kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 
  kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 
  kernel: st0: Incorrect block size. 
  kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6.

for the latest revisions i only do get this:
  kernel: sym0:1:0:phase change 6-7 11@37d45f84 resid=6. 
  last message repeated 8 times
with variations of this:
  kernel: sym0:1:0:phase change 6-7 11@37d45f84 resid=6. 
  kernel: sym0:1:0:phase change 6-7 11@37d45f84 resid=6. 
  kernel: sym0:1:0:phase change 6-7 9@37d45f90 resid=6. 
  kernel: sym0:1:0:phase change 6-7 11@37d45f84 resid=6. 
  kernel: sym0:1:0:phase change 6-7 11@37d45f84 resid=6. 
  kernel: sym0:1:0:phase change 6-7 9@37d45f90 resid=6. 
  kernel: scsi(0:0:1:0): Domain Validation skipping write tests 
  kernel: scsi(0:0:1:0): Ending Domain Validation 
  kernel: sym0:1:0:phase change 6-7 11@37d45f84 resid=6. 
  kernel: ACPI: PCI interrupt 0000:00:0d.0[A] -> GSI 17 (level, low) -> IRQ
17 
  kernel: sym1: <810a> rev 0x12 at pci 0000:00:0d.0 irq 17 
  kernel: sym1: No NVRAM, ID 7, Fast-10, SE, parity checking 
  kernel: sym1: SCSI BUS has been reset. 
  kernel: scsi1 : sym-2.1.18j

i just tried commands like this:
  mt status
  mt rewind
  mt asf 0
  mt asf 1
  tar -tvf /dev/tape
the last three are the ones that do raise the misc problems.

i tested this by just replacing the scsi subdir for the 53c8xx
of a 2.6.9-rc2-bk12 kernel with the misc implementations.
Those sources are absolutely interchangeable as i spotted
neither kernel build errors nor did i have any problems
when using the files from 2.6.8.1 at this location.

thats the host adapter info from proc filesystem:
  Chip sym53c895, device id 0xc, revision id 0x1                            
     
  At PCI address 0000:00:0c.0, IRQ 16                                       
     
  Min. period factor 10, Wide SCSI BUS                                      
     
  Max. started commands 448, max. commands per LUN 32

and this is the bus information on devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: IC35L036UWPR15-0 Rev: S70H
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: IBM-PSG  Model: DRHS36D       !# Rev: 0272
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 04 Lun: 00
  Vendor: SEAGATE  Model: DAT    9SP40-000 Rev: 910B
  Type:   Sequential-Access                ANSI SCSI revision: 03

The device is accessed via /dev/nst0, meaning the 
SCSI tape device without autmatic rewind.

I hope that is enough for you to understand whats
going odd in the recent versions of the kernel.
If you do need further information or do want me
to assist you in more advanced diagnostings
on that machine it should be feasible. I am able
to hack kernel code, but just the SCSI part is
an area where my understanding of the system
should get deepened somewhat, especially for that
changes you applied since the very last kernel release.

-Alex.

PS: please CC me on replys, i am not subscribed to the list.

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

Re: [BUG] Sym. 53c895 fails accessing tape device - kernel 2.9.1-rc1-bk1 trough rc2-bk12

[James Bottomley]

On Wed, 2004-09-29 at 11:47, Alexander Stohr wrote:
> in the beginning it merely looks like this:
>   kernel: st0: Incorrect block size.

I think this is the key to the problem.  It looks like some sort of tape
error.

> then it changed slightly to this:
>   kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 
>   kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 

These are normal messages printed during sym2 negotiation.  The way it
does negotiation changed recently, so these became more prevalent

Kai, could you look into this?

When I haul an old DAT tape out of the cupboard and attach it to a
sym1010, it all seems to work until I try to manipulate the block size,
so

dd of=/dev/nst0 if=linux-2.6.8.tar.gz

works just fine ... I can read and write to the tape

dd of=/dev/nst0 if=linux-2.6.8.tar.gz obs=16k

fails with the kernel message

st0: Write not multiple of tape block size.

And then I start to get errors from the tape device.

It looks like the block size setting has been broken somehow.

James

Re: [BUG] Sym. 53c895 fails accessing tape device - kernel 2.9.1-rc1-bk1 trough rc2-bk12

[Kai Makisara]

On Sat, 2 Oct 2004, James Bottomley wrote:

> On Wed, 2004-09-29 at 11:47, Alexander Stohr wrote:
> > in the beginning it merely looks like this:
> >   kernel: st0: Incorrect block size.
> 
> I think this is the key to the problem.  It looks like some sort of tape
> error.
> 
This is a user error but a normal situation with tapes. The drive is in 
fixed block mode and it encounters a block that is of different size. 
Sense data is returned with the ILI bit set.

I tested this with the following commands:

mt seblk 0
dd of=/dev/nst0 if=linux-2.6.9-rc2.tar.bz2
mt rewi
mt setblk 512
dd if=/dev/nst0 of=pup

dmesg shows the warning about incorrect block size but everything works 
fine. This is with HP C5713A DDS-4 dat and Sym53c1010. The kernel is 
2.6.9-rc3. Note that this kernel contains the spi fixes that fix the 
negotiation problems. Before these fixes my tape drives could not 
negotiate correct speeds (but worked in spite of that, although with 
non-optimal speed).

(I had to use linux-2.6.9-rc2.tar.bz2 instead of linux-2.6.8.tar.gz 
because the latter had odd byte count. The drive is on wide bus and 
sym53c8xx_2 can't do odd transfers on a wide bus. This is a bug that some 
people call a feature. dmesg shows there messages:
sym0:5:0:extraneous data discarded.
sym0:5:0:ODD transfer in DATA OUT phase.
sym0:5:0:COMMAND FAILED (87 0 9).
)

> > then it changed slightly to this:
> >   kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 
> >   kernel: sym1:4:0:phase change 6-7 9@37d30f84 resid=6. 
> 
> These are normal messages printed during sym2 negotiation.  The way it
> does negotiation changed recently, so these became more prevalent
> 
> Kai, could you look into this?
> 
> When I haul an old DAT tape out of the cupboard and attach it to a
> sym1010, it all seems to work until I try to manipulate the block size,
> so
> 
You have not manipulated the tape block size but the write() and read() 
byte counts from dd. In variable block mode these are the same as tape 
block size but in fixed block mode they are not the same thing.

> dd of=/dev/nst0 if=linux-2.6.8.tar.gz
> 
> works just fine ... I can read and write to the tape
> 
> dd of=/dev/nst0 if=linux-2.6.8.tar.gz obs=16k
> 
> fails with the kernel message
> 
> st0: Write not multiple of tape block size.
> 
I would like to have a little more details. In order to see this message, 
the tape drive should have been in fixed block mode. By default dd uses 
write() size of 512 bytes. The size of linux-2.6.8.tar.gz is 44678561 
bytes. This is not divisible by 512 and this means that the last write of 
dd is not 512 bytes and the write fails in foxed block mode (it fails in 
my tests). Could you give the exact command sequence leading to the error 
and the result from 'mt status' before this sequence?

Whatever I have tested now, I have not managed to get any messages from 
sym53c8xx_2 (except the odd transfer error but that is transient).

-- 
Kai

Re: [BUG] Sym. 53c895 fails accessing tape device - kernel 2.9.1-rc1-bk1 trough rc2-bk12

[James Bottomley]

On Sat, 2004-10-02 at 16:25, Kai Makisara wrote:
> (I had to use linux-2.6.9-rc2.tar.bz2 instead of linux-2.6.8.tar.gz 
> because the latter had odd byte count. The drive is on wide bus and 
> sym53c8xx_2 can't do odd transfers on a wide bus. This is a bug that some 
> people call a feature. dmesg shows there messages:
> sym0:5:0:extraneous data discarded.
> sym0:5:0:ODD transfer in DATA OUT phase.
> sym0:5:0:COMMAND FAILED (87 0 9).

Yes, I think this is a disagreement over the standards meaning of IGNORE
WIDE RESIDUE between the device and the sym2 driver.

When requesting an odd byte transfer on a wide bus, the sym2 driver
apparently always expects ignore wide residue for the last byte used to
pad the transfer to the bus size.  However, the standards say that if
the last byte is not a discardable pad but legitimate data, the device
doesn't have to send an IGNORE WIDE RESIDUE message (it may discard the
byte at its option, but if it wishes to keep it, the lack of the msg
indicates that the last byte contains valid data).

> I would like to have a little more details. In order to see this message, 
> the tape drive should have been in fixed block mode. By default dd uses 
> write() size of 512 bytes. The size of linux-2.6.8.tar.gz is 44678561 
> bytes. This is not divisible by 512 and this means that the last write of 
> dd is not 512 bytes and the write fails in foxed block mode (it fails in 
> my tests). Could you give the exact command sequence leading to the error 
> and the result from 'mt status' before this sequence?

OK, help me out a little here.  To set the tape to fixed block mode, I
should do a mt setblk?  OK, will try to reproduce.

> Whatever I have tested now, I have not managed to get any messages from 
> sym53c8xx_2 (except the odd transfer error but that is transient).

Same for my tapes...but the DAT is old and narrow bus.

James

Re: [BUG] Sym. 53c895 fails accessing tape device - kernel 2.9.1-rc1-bk1 trough rc2-bk12

[James Bottomley]

On Sat, 2004-10-02 at 16:25, Kai Makisara wrote:
> I would like to have a little more details. In order to see this message, 
> the tape drive should have been in fixed block mode. By default dd uses 
> write() size of 512 bytes. The size of linux-2.6.8.tar.gz is 44678561 
> bytes. This is not divisible by 512 and this means that the last write of 
> dd is not 512 bytes and the write fails in foxed block mode (it fails in 
> my tests). Could you give the exact command sequence leading to the error 
> and the result from 'mt status' before this sequence?> 
> Whatever I have tested now, I have not managed to get any messages from 
> sym53c8xx_2 (except the odd transfer error but that is transient).

Well, I have to admit that I changed the tape (got HW errors) and
everything's OK now.

James

Re: [BUG] Sym. 53c895 fails accessing tape device - kernel2.9.1-rc1-bk1 trough rc2-bk12

[Alexander Stohr]

what information would you need from me
to identify the bitness of the adapter and
the device so that i can see an advance
in my situation as well?

-Alex.

----- Original Message ----- 
From: "James Bottomley" <James.Bottomley@HansenPartnership.com>
To: "Kai Makisara" <Kai.Makisara@kolumbus.fi>
Cc: "Alexander Stohr" <Alexander.Stohr@gmx.de>; "SCSI Mailing List" <linux-scsi@vger.kernel.org>; <matthew@wil.cx>; <akpm@digeo.com>
Sent: Sunday, October 03, 2004 12:28 AM
Subject: Re: [BUG] Sym. 53c895 fails accessing tape device - kernel2.9.1-rc1-bk1 trough rc2-bk12


> On Sat, 2004-10-02 at 16:25, Kai Makisara wrote:
> > I would like to have a little more details. In order to see this message,
> > the tape drive should have been in fixed block mode. By default dd uses
> > write() size of 512 bytes. The size of linux-2.6.8.tar.gz is 44678561
> > bytes. This is not divisible by 512 and this means that the last write of
> > dd is not 512 bytes and the write fails in foxed block mode (it fails in
> > my tests). Could you give the exact command sequence leading to the error
> > and the result from 'mt status' before this sequence?>
> > Whatever I have tested now, I have not managed to get any messages from
> > sym53c8xx_2 (except the odd transfer error but that is transient).
>
> Well, I have to admit that I changed the tape (got HW errors) and
> everything's OK now.
>
> James
>
>

Re: [BUG] Sym. 53c895 fails accessing tape device - kernel2.9.1-rc1-bk1 trough rc2-bk12

[Kai Makisara]

On Sun, 3 Oct 2004, Alexander Stohr wrote:

> what information would you need from me
> to identify the bitness of the adapter and
> the device so that i can see an advance
> in my situation as well?
> 
Whenever you report tape problems, it would be helpful to know at least 
the drive mode (fixed vs. variable block mode) and block size (if fixed 
block mode). You can get this information with 'mt status'. Additionally 
it is useful to see the sequence of commands leading to the problem. The 
tape is a sequential device and all previous operations may influence what 
happens next. These things allow duplication of the problem. Additionally, 
it is useful to know the SCSI adapter and drive model (which you have 
included already).

What you see suggests that you are trying to do something that one should 
not do with tapes, i.e., trying to read the tape in fixed block mode with 
different block size than was used when writing. However, from the system 
point of view, this should not cause problems. The drive should report the 
conditions cleanly to st using sense data.

To me your problems seem to be in the communication between the drive and 
the adapter. The sym53c8xx_2 driver has had problems in speed negotiation 
recently. As I mentioned, the speed negotiation did not succeed with my 
drives at some point. I have here patch-2.6.9-rc2-bk14 and it does not 
seem to have those fixes yet. It might be good if you could try a new 
kernel (2.6.9-rc3 is certainly new enough) and see if this helps.

--
Kai