Kernel panic in FreeBSD-8.3 from UFS

[Holm Tiffe]

Kenneth D. Merry wrote:

> On Tue, Jun 05, 2012 at 17:49:05 +0530, Desai, Kashyap wrote:
> > Hi All,
> > 
> > We found some potential area of memory leak in CAM layer. 
> > CAM XPT Memory leak is due to following  function in scsi/scsi_all.c
> > 
> > int
> > scsi_command_string(struct ccb_scsiio *csio, struct sbuf *sb)                                
> > 
> > 
> > In above function, CAM layer allocate memory for ccb  device as below
> >   if ((cgd = (struct ccb_getdev*)xpt_alloc_ccb_nowait()) == NULL)
> > 
> > 
> > _But_, unfortunately we never free the allocated memory and we see memory leak of 2K every time when someone is calling 
> > Scsi_command_string from kernel mode.
> > 
> > 
> > Attached is a proposed patch for this issue.
> 
> The patch looks good, I just committed it.
> 
> Thanks!
> 
> Ken
> -- 
> Kenneth Merry
> ken at FreeBSD.ORG
> _______________________________________________
> freebsd-scsi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"


It looks that this patch or something related to it broke my tape backups.
I do have two SCSI Tapes connected to my system:

# camcontrol devlist
<IBM-SSG S53D073 C61E>             at scbus0 target 0 lun 0 (pass0,da0)
<IBM-SSG S53D073 C61E>             at scbus0 target 1 lun 0 (pass1,da1)
<IBM-SSG S53D073 C61A>             at scbus0 target 2 lun 0 (pass2,da2)
<IBM-SSG S53D073 C61A>             at scbus0 target 3 lun 0 (pass3,da3)
<TANDBERG SLR5 4/8GB =09:>         at scbus1 target 5 lun 0 (pass4,sa0)
<COMPAQ DLT4000 D887>              at scbus1 target 6 lun 0 (pass5,sa1)

an with an 8.3 stable from Jun 14 both of them arent able anymore to do 
blocksizes over 8k and 8k are only working sometimes (huh?!).

# mt -f /dev/sa1 status
Mode      Density              Blocksize      bpi      Compression
Current:  0x1a:DLTapeIV(20GB)    variable       81633    IDRC
---------available modes---------
0:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
1:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
2:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
3:        0x1a:DLTapeIV(20GB)    variable       81633    IDRC
---------------------------------
Current Driver State: at rest.
---------------------------------
File Number: 0  Record Number: 0        Residual Count 0

# dd if=/dev/zero of=/dev/sa1 bs=1k count=1000
1000+0 records in
1000+0 records out
1024000 bytes transferred in 4.330778 secs (236447 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=2k count=1000
1000+0 records in
1000+0 records out
2048000 bytes transferred in 3.252421 secs (629685 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=4k count=1000
1000+0 records in
1000+0 records out
4096000 bytes transferred in 2.933208 secs (1396423 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=8k count=1000
1000+0 records in
1000+0 records out
8192000 bytes transferred in 3.567864 secs (2296052 bytes/sec)
# dd if=/dev/zero of=/dev/sa1 bs=16k count=1000
dd: /dev/sa1: Input/output error
1+0 records in
0+0 records out
0 bytes transferred in 0.000253 secs (0 bytes/sec)

There is no error message from the kernel related to that.

If I try to read an older backup tape (used 64k Tape Blocks for that):
# dd if=/dev/sa1 of=/dev/null bs=64k count=10
dd: /dev/sa1: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 0.000824 secs (0 bytes/sec)
# 
... I get in /var/log/messages:

Jun 25 14:56:05 unicorn kernel: (sa1:sym0:0:6:0): 65536-byte tape record
bigger than supplied buffer

Nice ehy?

I've now booted kernel.old from Mar 15 and the problems are gone on both
drives.

Please check this.

Regards,

Holm

PS: Please Cc me, I'm not on that list anymore.
-- 
      Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, 
     Freiberger Straße 42, 09600 Oberschöna, USt-Id: DE253710583
  www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741