From owner-freebsd-scsi@FreeBSD.ORG Mon Jun 25 16:05:18 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 9FA9C106566C; Mon, 25 Jun 2012 16:05:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id DBACF8FC1A; Mon, 25 Jun 2012 16:05:17 +0000 (UTC) Received: by lbon10 with SMTP id n10so8197332lbo.13 for ; Mon, 25 Jun 2012 09:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gA5BNF2HqBgfCCgPFGwRP7ilu9p4skX+SV+NS1zbs7c=; b=vLpGRz9ZBY+gA/a5dzbPqNJwu6KSppbZrX7jk+VC74ZP0Nn5F14dHyu2QKsNDu0d4A pQG0qzj+sWqiZ1YbNXYlRuoqP+PlmYW9vJi+CZrukz9uaTTohEYkzdRj5JrKUF8VNtPM pl8ZDVvP+F7nlmPs+vSeDDsY3GCCs7dF1anZQnsOs+TwYbTjsRA32fMS/z36n2JzNcqg HY5RYEaOw5cxL8GmzRcpRo8YO29txhX867TBnKjpaHIyXfBshTxu7ROrmfKBUakd8wCQ P4iIcfBI914fp7GtNawDOfsc2Qi9e08+i6MnbgzYa6Xbt1XlQ6SKWCXy12WgzFf4Vi1s iGvA== Received: by 10.112.11.38 with SMTP id n6mr5912877lbb.82.1340640316642; Mon, 25 Jun 2012 09:05:16 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id hz16sm71728052lab.6.2012.06.25.09.05.14 (version=SSLv3 cipher=OTHER); Mon, 25 Jun 2012 09:05:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FE88C33.1020008@FreeBSD.org> Date: Mon, 25 Jun 2012 19:05:07 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: Holm Tiffe 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> <20120625155316.GA37535@nargothrond.kdm.org> In-Reply-To: <20120625155316.GA37535@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" 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 16:05:18 -0000 On 06/25/12 18:53, Kenneth D. Merry wrote: > 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. You may try to boot with verbose kernel messages and enable some CAM debug with `camcontrol debug -I all` and then repeat your tests. It should probably make kernel to tell more about errors. >> 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? -- Alexander Motin