From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 25 15:53:23 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6856A1065676; Mon, 25 Jun 2012 15:53:23 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 35CDE8FC15; Mon, 25 Jun 2012 15:53:23 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q5PFrGN1041263; Mon, 25 Jun 2012 09:53:16 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q5PFrGeV041262; Mon, 25 Jun 2012 09:53:16 -0600 (MDT) (envelope-from ken) Date: Mon, 25 Jun 2012 09:53:16 -0600 From: "Kenneth D. Merry" To: Holm Tiffe , freebsd-scsi@freebsd.org Message-ID: <20120625155316.GA37535@nargothrond.kdm.org> References: <20120601124338.GU2358@deviant.kiev.zoral.com.ua> <20120601125824.GV2358@deviant.kiev.zoral.com.ua> <20120606170640.GA98428@nargothrond.kdm.org> <20120625135543.GA58915@beast.freibergnet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120625135543.GA58915@beast.freibergnet.de> User-Agent: Mutt/1.4.2i Cc: mav@freebsd.org Subject: Re: Kernel panic in FreeBSD-8.3 from UFS X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:53:23 -0000 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@FreeBSD.ORG > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@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 > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > at scbus0 target 2 lun 0 (pass2,da2) > at scbus0 target 3 lun 0 (pass3,da3) > at scbus1 target 5 lun 0 (pass4,sa0) > 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@FreeBSD.ORG