From owner-freebsd-scsi@FreeBSD.ORG Sun May 8 20:36:37 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 EF596106566B for ; Sun, 8 May 2011 20:36:37 +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 9B7B28FC17 for ; Sun, 8 May 2011 20:36:37 +0000 (UTC) Received: by uriah.heep.sax.de (Postfix, from userid 107) id 0025F8; Sun, 8 May 2011 22:36:34 +0200 (MET DST) Date: Sun, 8 May 2011 22:36:34 +0200 From: Joerg Wunsch To: freebsd-scsi@freebsd.org Message-ID: <20110508203634.GE5364@uriah.heep.sax.de> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110508113332.GX48734@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110508113332.GX48734@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: Sun, 08 May 2011 20:36:38 -0000 As Kostik Belousov wrote: > > I could perhaps setup a serial console, so to get at least DDB > > functioning if you'd like to see more details. ... > Serial console is fine, I do want to see a backtrace. > There is also "show cdev" command in ddb, that might provide some > useful information. OK, I'm setting up a DDB kernel right now, and attached an old laptop as the console terminal. I also applied your suggested patch. > INVARIANTS may be also useful, since the kernel might catch the > corruption earlier. As INVARIANTS has a performance impact, I'd like to avoid that by now. Let's see first whether an analysis is possible without that. If not, would it suffice to just compile kern_conf.c with INVARIANTS? -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)