From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 3 23:30:42 2010 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 E45BA106564A for ; Wed, 3 Mar 2010 23:30:42 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2408FC0A for ; Wed, 3 Mar 2010 23:30:42 +0000 (UTC) Received: from [192.168.0.101] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o23NUgHC097023 for ; Wed, 3 Mar 2010 15:30:42 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4B8EF128.8050704@feral.com> Date: Wed, 03 Mar 2010 15:30:48 -0800 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <3bbf2fe11002281655i61a5f0a0if3f381ad0c4a1ef8@mail.gmail.com> <3bbf2fe11003020724m14bebf74y9fa3906418b7cf11@mail.gmail.com> <4B8D3016.2070301@feral.com> <3bbf2fe11003031334g4591c1a3lc52dfb898f728ee2@mail.gmail.com> <20100303214424.GA53790@sandvine.com> <3bbf2fe11003031348q4c1fcccfxd19da32875b43f56@mail.gmail.com> <4B8EDAE8.3080401@feral.com> <3bbf2fe11003031357o518d6028m8157d9110a9122f3@mail.gmail.com> In-Reply-To: <3bbf2fe11003031357o518d6028m8157d9110a9122f3@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Wed, 03 Mar 2010 15:30:42 -0800 (PST) Subject: Re: How is supposed to be protected the units list? 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: Wed, 03 Mar 2010 23:30:43 -0000 On 3/3/2010 1:57 PM, Attilio Rao wrote: > 2010/3/3 Matthew Jacob: > >> On static review, the only code that makes me nervous are >> ata_shutdown/da_shutdown. >> Those are the only places where you hold that lock across an uncertain >> interval. >> > Please note that a def mutex is already held (the cam_periph_lock), > so, unless LORs I'm not thinking about, I don't expect too much > surprises for that codepath. > > Thanks, > Attilio > > > The only potential operational difference was on reattach (power SAN disks on, they attach. Power them off. Wait for 60 seconds. The deattach. Power them on again). I've run this test many times before and haven't seen this. da7: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) (da7:isp0:0:6:0): removing device entry panic: Bad link elm 0xffffff0018fbbc00 next->prev != elm cpuid = 0 KDB: enter: panic [ thread pid 0 tid 100044 ] Stopped at kdb_enter+0x3d: movq $0,0x6b02d0(%rip) db> bt Tracing pid 0 tid 100044 td 0xffffff0002fbe000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b camperiphfree() at camperiphfree+0x1c2 cam_periph_release_locked() at cam_periph_release_locked+0x48 cam_periph_release() at cam_periph_release+0x53 dasysctlinit() at dasysctlinit+0x153 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000188d30, rbp = 0 ---