From owner-freebsd-scsi@FreeBSD.ORG Fri May 20 20:37:33 2011 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2432C1065672 for ; Fri, 20 May 2011 20:37:33 +0000 (UTC) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (uriah.heep.sax.de [213.240.137.9]) by mx1.freebsd.org (Postfix) with ESMTP id C01A08FC14 for ; Fri, 20 May 2011 20:37:32 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 40A8D1E; Fri, 20 May 2011 22:37:31 +0200 (MET DST) Date: Fri, 20 May 2011 22:37:31 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Message-ID: <20110520203731.GG2277@uriah.heep.sax.de> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110518060429.GA4146@uriah.heep.sax.de> <20110518165120.GT48734@deviant.kiev.zoral.com.ua> <20110520083948.GA2277@uriah.heep.sax.de> <20110520201757.GE48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110520201757.GE48734@deviant.kiev.zoral.com.ua> X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: Panic when removing a SCSI device entry X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joerg Wunsch List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 20:37:33 -0000 As Kostik Belousov wrote: > > > Please do "p *(struct cdev_priv *)0xe98804f4" and > > > "p *(struct cdev_priv *)0xce0dc900" from kgdb. > > > > Well, that kernel unfortunately lacked debugging symbols, and while > > I've still been thinking about the best way to recompile an exact > > same kernel with them ... > Yes, it would be quite interesting to see the data I asked for. OK, I found a way to cheat around the missing -g symbols ... and: all the data at 0xce0dc900 are zeroed out. The other address does not make any sense at all: (kgdb) p *(struct cdev_priv *)0xe98804f4 $1 = {cdp_c = {__si_reserved = 0xe988097c, si_flags = 3225728383, si_atime = {tv_sec = -871690624, tv_nsec = -1065413093}, si_ctime = {tv_sec = 18, tv_nsec = 0}, si_mtime = {tv_sec = -376961680, tv_nsec = -927034656}, si_uid = 3239626616, si_gid = 0, si_mode = 1316, si_cred = 0xdad13340, si_drv0 = -376961728, si_refcount = -1068057405, si_list = {le_next = 0x0, le_prev = 0xe9880538}, si_clone = {le_next = 0xe9880538, le_prev = 0x202}, si_children = {lh_first = 0x2}, si_siblings = { le_next = 0xdad13340, le_prev = 0x0}, si_parent = 0xe9880564, si_name = 0xc056bcc3 "\213]�213u�213}�211��\211�213U\f\205�\r�����\213E\b����]�215�&", si_drv1 = 0x0, si_drv2 = 0x1, si_devsw = 0x0, si_iosize_max = -1055340680, si_usecount = 3918005652, si_threadcount = 3671143232, __si_u = {__sid_snapdata = 0x0}, __si_namebuf = "\000�030�000\000\000\000@3�|\005\210�000\000\000\000\000@�\224\005\210��V�001\000\000\000\020\000\000\000�\005\210��V�\234\204�020\000\000\000\001\000\000\000\006\000\000"}, cdp_list = {tqe_next = 0xe988061a, tqe_prev = 0x4}, cdp_inode = 2147289763, cdp_flags = 3918005812, cdp_inuse = 3671349200, cdp_maxdirent = 3671143232, cdp_dirents = 0x6400, cdp_dirent0 = 0xe0badfa7, cdp_dtr_list = {tqe_next = 0x257, tqe_prev = 0xc056bc4a}, cdp_dtr_cb = 0x404a9c20, cdp_dtr_cb_arg = 0xc084b894, cdp_fdpriv = {lh_first = 0xe9880674}} > What is the exact revision of your sources ? It's a checkout from a CVS tree, so I cannot give you an exact SVN revision number. The checkout has been done on April 13. > This looks like a CAM issue, which is out of my scope. This was my fear, and that's why I wrote to the freebsd-scsi list. > > si_name = 0xc8d9ba78 "nsa0.0", Could that be an issue with the multiple SCSI tape drive device nodes? I see, /dev/nsa0.0 is somehow involved into the panic, yet other processes might access just /dev/nsa0 (which is a different cdev). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)