Kernel panic in FreeBSD-8.3 from UFS

[Kenneth D. Merry]

On Mon, Jun 25, 2012 at 15:55:43 +0200, Holm Tiffe wrote:
> 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?!).

The change in the above email didn't get merged back to stable/8 until June
20th.  So it isn't that.

There were no changes to the sa(4) driver in stable/8 from March 15th to
June 14th, but there were lots of other CAM changes.

> # 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.

It isn't obvious where the problem was introduced, unfortunately.

Could you do a binary search to figure out which revision broke things for
you?

Ken
-- 
Kenneth Merry
ken at FreeBSD.ORG