Date: Mon, 25 Jun 2012 15:55:43 +0200 From: Holm Tiffe <holm@freibergnet.de> To: "Kenneth D. Merry" <ken@FreeBSD.org> Cc: freebsd-scsi@freebsd.org Subject: Re: Kernel panic in FreeBSD-8.3 from UFS Message-ID: <20120625135543.GA58915@beast.freibergnet.de> In-Reply-To: <20120606170640.GA98428@nargothrond.kdm.org> References: <B2FD678A64EAAD45B089B123FDFC3ED72B9F6C1F79@inbmail01.lsi.com> <20120601124338.GU2358@deviant.kiev.zoral.com.ua> <B2FD678A64EAAD45B089B123FDFC3ED72B9F6C1F7F@inbmail01.lsi.com> <20120601125824.GV2358@deviant.kiev.zoral.com.ua> <B2FD678A64EAAD45B089B123FDFC3ED72B9F6C21A7@inbmail01.lsi.com> <20120606170640.GA98428@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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@tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120625135543.GA58915>