From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 16 11:06:51 2013 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD007C34 for ; Mon, 16 Sep 2013 11:06:51 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B51402165 for ; Mon, 16 Sep 2013 11:06:51 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r8GB6pQp089746 for ; Mon, 16 Sep 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r8GB6pgd089743 for freebsd-scsi@FreeBSD.org; Mon, 16 Sep 2013 11:06:51 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Sep 2013 11:06:51 GMT Message-Id: <201309161106.r8GB6pgd089743@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 11:06:51 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/179932 scsi [ciss] ciss i/o stall problem with HP Bl Gen8 (and HP o kern/178795 scsi [mps] MSI for mps driver doesn't work under vmware o kern/165982 scsi [mpt] mpt instability, drive resets, and losses on Fre o kern/165740 scsi [cam] SCSI code must drain callbacks before free f kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c o kern/148083 scsi [aac] Strange device reporting o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 f kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus f kern/123674 scsi [ahc] ahc driver dumping o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc 14 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 16 18:27:47 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id 0CC7ED22; Mon, 16 Sep 2013 18:27:47 +0000 (UTC) Date: Mon, 16 Sep 2013 18:27:47 +0000 From: John To: FreeBSD-SCSI Subject: Re: Panic: 9.2-PRERELEASE - enc_daemon Message-ID: <20130916182747.GB60744@FreeBSD.org> References: <20130721134548.GA78666@FreeBSD.org> <20130916182450.GA60744@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130916182450.GA60744@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:27:47 -0000 Meant to post this to -scsi not -stable as I just did... ----- John's Original Message ----- > Hi Folks, > > I'm seeing a panic with the 9.2-PRERELEASE code. The system > will stay up for anywhere from a couple of seconds to a few hours > and then panic. I have continued to look at this problem and believe I have made some progress but still have no solution... Just questions :-) I have updated my source to r255r73 which includes all the recent MFCs to cam/xpt/scsi. The problem still persists. I have attempted to simplify the problem and have been able to duplicate part of the problem with just two shelves attached serially. I have the following debugging diffs: Index: scsi/scsi_xpt.c =================================================================== --- scsi/scsi_xpt.c (revision 255573) +++ scsi/scsi_xpt.c (working copy) @@ -2445,6 +2445,15 @@ case CDAI_TYPE_PHYS_PATH: if (cdai->flags & CDAI_FLAG_STORE) { if (device->physpath != NULL) { + /* In theory the following should not be the same - see ses_setphyspath_callback() */ + printf("incoming %d %.*s\n",(int)cdai->bufsiz,(int)cdai->bufsiz,cdai->buf); + printf("current %d %.*s %*s\n",(int)device->physpath_len,(int)device->physpath_len,device->physpath,device->serial_num_len,device->serial_num); + free(device->physpath, M_CAMXPT); device->physpath = NULL; } and to ses_devids_iter(): Index: scsi/scsi_enc_ses.c =================================================================== --- scsi/scsi_enc_ses.c (revision 255573) +++ scsi/scsi_enc_ses.c (working copy) @@ -849,6 +849,7 @@ devid->length = sizeof(struct scsi_vpd_id_naa_ieee_reg); memcpy(devid->identifier, phy_addr, devid->length); + printf("callback: i=%d device=%08x\n",i,*phy_addr); callback(enc, elm, devid, callback_arg); } } The first patch shows the currently stored versus the about to be stored physpath. The 2nd patch adds some debug information to show which phys (i value) is being processed. What I find is a constant flip/flop between the device ids of the 2 shelves being stored into what I believe is the first shelves descriptor. Sep 16 17:01:22 testsys1 kernel: callback: i=0 device=00000050 Sep 16 17:01:22 testsys1 last message repeated 23 times Sep 16 17:01:22 testsys1 kernel: callback: i=0 device=00000020 Sep 16 17:01:22 testsys1 kernel: callback: i=1 device=0000002e Sep 16 17:01:22 testsys1 kernel: callback: i=2 device=000000ff Sep 16 17:01:22 testsys1 kernel: callback: i=3 device=000000ff Sep 16 17:01:22 testsys1 kernel: callback: i=4 device=000000ff Sep 16 17:01:22 testsys1 kernel: callback: i=5 device=000000ff Sep 16 17:01:22 testsys1 kernel: callback: i=6 device=00000000 Sep 16 17:01:22 testsys1 kernel: incoming 60 id1,enc@n5001438023478280/type@9/slot@1/elmdesc@900080050002 Sep 16 17:01:22 testsys1 kernel: current 60 id1,enc@n5001438023441700/type@9/slot@1/elmdesc@900080050002 5C7237P403 Sep 16 17:01:22 testsys1 kernel: callback: i=7 device=00000000 5C7237P403 is the serial of the 1st shelf: # camcontrol inquiry ses0 pass29: Fixed Enclosure Services SCSI-5 device pass29: Serial Number 5C7237P403 pass29: 600.000MB/s transfers, Command Queueing Enabled # camcontrol inquiry ses1 pass55: Fixed Enclosure Services SCSI-5 device pass55: Serial Number 5C7236P2T5 pass55: 600.000MB/s transfers, Command Queueing Enabled A sample grep to show the flip/flop'ing... Sep 16 17:00:22 testsys1 kernel: incoming 60 id1,enc@n5001438023478280/type@9/slot@1/elmdesc@900080050002 Sep 16 17:00:22 testsys1 kernel: current 60 id1,enc@n5001438023441700/type@9/slot@1/elmdesc@900080050002 5C7237P403 Sep 16 17:00:23 testsys1 kernel: incoming 60 id1,enc@n5001438023441700/type@9/slot@1/elmdesc@900080050002 Sep 16 17:00:23 testsys1 kernel: current 60 id1,enc@n5001438023478280/type@9/slot@1/elmdesc@900080050002 5C7237P403 Sep 16 17:01:22 testsys1 kernel: incoming 60 id1,enc@n5001438023478280/type@9/slot@1/elmdesc@900080050002 Sep 16 17:01:22 testsys1 kernel: current 60 id1,enc@n5001438023441700/type@9/slot@1/elmdesc@900080050002 5C7237P403 Sep 16 17:01:23 testsys1 kernel: incoming 60 id1,enc@n5001438023441700/type@9/slot@1/elmdesc@900080050002 Sep 16 17:01:23 testsys1 kernel: current 60 id1,enc@n5001438023478280/type@9/slot@1/elmdesc@900080050002 5C7237P403 Sep 16 17:02:22 testsys1 kernel: incoming 60 id1,enc@n5001438023478280/type@9/slot@1/elmdesc@900080050002 Sep 16 17:02:22 testsys1 kernel: current 60 id1,enc@n5001438023441700/type@9/slot@1/elmdesc@900080050002 5C7237P403 Sep 16 17:02:23 testsys1 kernel: incoming 60 id1,enc@n5001438023441700/type@9/slot@1/elmdesc@900080050002 Sep 16 17:02:23 testsys1 kernel: current 60 id1,enc@n5001438023478280/type@9/slot@1/elmdesc@900080050002 5C7237P403 I'm not sure why this shows up for i=6... After alot of reading & experimenting, I saw the following when running the: sg_ses -p ed ses0 command... # sg_ses -p ed ses0 HP D2700 SAS AJ941A 0147 Primary enclosure logical identifier (hex): 5001438023478280 Element Descriptor In diagnostic page: generation code: 0x0 element descriptor by type list Element type: Array device slot, subenclosure id: 0 [ti=0] Overall descriptor: Element 0 descriptor: ... Element 23 descriptor: Element 24 descriptor: Element type: SAS connector, subenclosure id: 0 [ti=1] Overall descriptor: Element 0 descriptor: ... Element 23 descriptor: Element 24 descriptor: Element type: vendor specific [0xff], subenclosure id: 0 [ti=2] Overall descriptor: Element 0 descriptor: 5C7237P403 Element type: Power supply, subenclosure id: 0 [ti=3] Overall descriptor: Element 0 descriptor: 20LiteOn 5ANLE0CLL3K6VI Element 1 descriptor: 20LiteOn 5ANLE0CLL3K6V7 Element type: Cooling, subenclosure id: 0 [ti=4] Overall descriptor: B PAVCA0B9V3E4I0 Element 0 descriptor: Element 1 descriptor: Element type: Cooling, subenclosure id: 0 [ti=5] Overall descriptor: B PAVCA0B9V3E4HH Element 0 descriptor: Element 1 descriptor: Element type: Enclosure services controller electronics, subenclosure id: 0 [ti=6] Overall descriptor: Element 0 descriptor: 014701B0PAZAV0BTM3F17A 0026 ... Could the enclosure services controller at ti=6 somehow be related to what I'm seeing? If anyone has any ideas I'd appreciate any ideas, pointers,etc. Thanks, John ps: full output from smp_discover for both shelves.. # smp_discover ses0 phy 0:D:attached:[500003944822dd2a:00 t(SSP)] 6 Gbps phy 1:D:attached:[500003944822dc96:00 t(SSP)] 6 Gbps phy 2:D:attached:[500003944822dcbe:00 t(SSP)] 6 Gbps phy 3:D:attached:[500003944822f8a2:00 t(SSP)] 6 Gbps phy 4:D:attached:[500003944822d876:00 t(SSP)] 6 Gbps phy 5:D:attached:[500003944822d776:00 t(SSP)] 6 Gbps phy 6:D:attached:[5000039448232726:00 t(SSP)] 6 Gbps phy 7:D:attached:[500003944823b8aa:00 t(SSP)] 6 Gbps phy 8:D:attached:[500003944823b846:00 t(SSP)] 6 Gbps phy 9:D:attached:[500003944822d7ae:00 t(SSP)] 6 Gbps phy 10:D:attached:[500003944823b2f2:00 t(SSP)] 6 Gbps phy 11:D:attached:[500003944823b04a:00 t(SSP)] 6 Gbps phy 12:D:attached:[5000039448239ff2:00 t(SSP)] 6 Gbps phy 13:D:attached:[500003944823db72:00 t(SSP)] 6 Gbps phy 14:D:attached:[500003944823b7a6:00 t(SSP)] 6 Gbps phy 15:D:attached:[500003944823dcc6:00 t(SSP)] 6 Gbps phy 16:D:attached:[500003944823787a:00 t(SSP)] 6 Gbps phy 17:D:attached:[500003944823b30a:00 t(SSP)] 6 Gbps phy 18:D:attached:[500003944823b0de:00 t(SSP)] 6 Gbps phy 19:D:attached:[500003944823b506:00 t(SSP)] 6 Gbps phy 20:D:attached:[500003944823e7b6:00 t(SSP)] 6 Gbps phy 21:D:attached:[5000039448232e7a:00 t(SSP)] 6 Gbps phy 22:D:attached:[500003944823cfde:00 t(SSP)] 6 Gbps phy 23:D:attached:[500003944823dc52:00 t(SSP)] 6 Gbps phy 24:D:attached:[500003944823c9e6:00 t(SSP)] 6 Gbps phy 25:S:attached:[500605b0050a7660:03 i(SSP+STP+SMP)] 6 Gbps phy 26:S:attached:[500605b0050a7660:02 i(SSP+STP+SMP)] 6 Gbps phy 27:S:attached:[500605b0050a7660:01 i(SSP+STP+SMP)] 6 Gbps phy 28:S:attached:[500605b0050a7660:00 i(SSP+STP+SMP)] 6 Gbps phy 29:T:attached:[500143802344173f:25 exp i(SMP) t(SMP)] 6 Gbps phy 30:T:attached:[500143802344173f:26 exp i(SMP) t(SMP)] 6 Gbps phy 31:T:attached:[500143802344173f:27 exp i(SMP) t(SMP)] 6 Gbps phy 32:T:attached:[500143802344173f:28 exp i(SMP) t(SMP)] 6 Gbps phy 33: inaccessible (phy vacant) phy 34: inaccessible (phy vacant) phy 35: inaccessible (phy vacant) phy 36:D:attached:[50014380234782be:36 V i(SSP) t(SSP)] 6 Gbps # smp_discover ses1 phy 0:D:attached:[500003944823cbfa:00 t(SSP)] 6 Gbps phy 1:D:attached:[500003944823ddbe:00 t(SSP)] 6 Gbps phy 2:D:attached:[500003944823d9ee:00 t(SSP)] 6 Gbps phy 3:D:attached:[500003944823c2f6:00 t(SSP)] 6 Gbps phy 4:D:attached:[500003944823c2ca:00 t(SSP)] 6 Gbps phy 5:D:attached:[500003944823d8c2:00 t(SSP)] 6 Gbps phy 6:D:attached:[500003944823cc3e:00 t(SSP)] 6 Gbps phy 7:D:attached:[500003944823d3e2:00 t(SSP)] 6 Gbps phy 8:D:attached:[500003944823d8da:00 t(SSP)] 6 Gbps phy 9:D:attached:[500003944823c39a:00 t(SSP)] 6 Gbps phy 10:D:attached:[500003944823d896:00 t(SSP)] 6 Gbps phy 11:D:attached:[500003944823dbb6:00 t(SSP)] 6 Gbps phy 12:D:attached:[500003944823c6a2:00 t(SSP)] 6 Gbps phy 13:D:attached:[500003944823dc86:00 t(SSP)] 6 Gbps phy 14:D:attached:[500003944823e7e2:00 t(SSP)] 6 Gbps phy 15:D:attached:[500003944823cae6:00 t(SSP)] 6 Gbps phy 16:D:attached:[500003944823d44a:00 t(SSP)] 6 Gbps phy 17:D:attached:[500003944823d27a:00 t(SSP)] 6 Gbps phy 18:D:attached:[5000039448234122:00 t(SSP)] 6 Gbps phy 19:D:attached:[500003944823b17e:00 t(SSP)] 6 Gbps phy 20:D:attached:[500003944823c6fe:00 t(SSP)] 6 Gbps phy 21:D:attached:[500003944823435e:00 t(SSP)] 6 Gbps phy 22:D:attached:[500003944823c776:00 t(SSP)] 6 Gbps phy 23:D:attached:[50000394482341da:00 t(SSP)] 6 Gbps phy 24:D:attached:[500003944823cc62:00 t(SSP)] 6 Gbps phy 25:S:attached:[50014380234782bf:29 exp i(SMP) t(SMP)] 6 Gbps phy 26:S:attached:[50014380234782bf:30 exp i(SMP) t(SMP)] 6 Gbps phy 27:S:attached:[50014380234782bf:31 exp i(SMP) t(SMP)] 6 Gbps phy 28:S:attached:[50014380234782bf:32 exp i(SMP) t(SMP)] 6 Gbps phy 33: inaccessible (phy vacant) phy 34: inaccessible (phy vacant) phy 35: inaccessible (phy vacant) phy 36:D:attached:[500143802344173e:36 V i(SSP) t(SSP)] 6 Gbps # camcontrol smpmaninfo ses0 Report Manufacturer Information Expander Change count: 1815 SAS 1.1 Format: Yes Component Vendor: PMCSIERA Component ID: 0x8005 Component Revision: 0x2 Vendor Specific: 0x0000000000000000 > Fatal trap 12: page fault while in kernel mode > cpuid = 31; apic id = 2f > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80d2b018 > stack pointer = 0x28:0xffffffbfd0fea080 > frame pointer = 0x28:0xffffffbfd0fea0b0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 25 (enc_daemon7) > > and: > > db:0:kdb.enter.default> show pcpu > cpuid = 31 > dynamic pcpu = 0xffffff807f203880 > curthread = 0xfffffe0032f53920: pid 25 "enc_daemon7" > curpcb = 0xffffffbfd0feabc0 > fpcurthread = none > idlethread = 0xfffffe002600b920: tid 100034 "idle: cpu31" > curpmap = 0xffffffff8141b510 > tssp = 0xffffffff81489e98 > commontssp = 0xffffffff81489e98 > rsp0 = 0xffffffbfd0feabc0 > gs32p = 0xffffffff81487fd0 > ldt = 0xffffffff81488010 > tss = 0xffffffff81488000 > > > > This looks like a bug I started tracing down a while back with > the new enclosure services (r246437 and later). I added witness > into the kernel and received the following LOR: > > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex MPT2SAS lock (MPT2SAS lock) r = 0 (0xffffff8003c851b8) locked @ cam/cam_periph.h:192 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffffbfd0f3cb20 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffffbfd0f3cbe0 > _witness_debugger() at _witness_debugger+0x2c/frame 0xffffffbfd0f3cc00 > witness_warn() at witness_warn+0x2d2/frame 0xffffffbfd0f3cd40 > trap_pfault() at trap_pfault+0x6a/frame 0xffffffbfd0f3cdd0 > trap() at trap+0x344/frame 0xffffffbfd0f3cfd0 > calltrap() at calltrap+0x8/frame 0xffffffbfd0f3cfd0 > --- trap 0xc, rip = 0xffffffff80ca8478, rsp = 0xffffffbfd0f3d090, rbp = 0xffffffbfd0f3d0c0 --- > memcpy() at memcpy+0x8/frame 0xffffffbfd0f3d0c0 > ses_setphyspath_callback() at ses_setphyspath_callback+0xb3/frame 0xffffffbfd0f3d1d0 > ses_path_iter_devid_callback() at ses_path_iter_devid_callback+0x1c6/frame 0xffffffbfd0f3d770 > ses_devids_iter() at ses_devids_iter+0xb1/frame 0xffffffbfd0f3d7f0 > ses_paths_iter() at ses_paths_iter+0x20/frame 0xffffffbfd0f3d810 > ses_publish_physpaths() at ses_publish_physpaths+0x264/frame 0xffffffbfd0f3da40 > enc_daemon() at enc_daemon+0x2a4/frame 0xffffffbfd0f3daa0 > fork_exit() at fork_exit+0x11d/frame 0xffffffbfd0f3daf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffffbfd0f3daf0 > --- trap 0, rip = 0, rsp = 0xffffffbfd0f3dbb0, rbp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 8; apic id = 08 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80ca8478 > stack pointer = 0x28:0xffffffbfd0f3d090 > frame pointer = 0x28:0xffffffbfd0f3d0c0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 30 (enc_daemon12) > lock order reversal: (Giant after non-sleepable) > 1st 0xffffff8003c851b8 MPT2SAS lock (MPT2SAS lock) @ cam/cam_periph.h:192 > 2nd 0xffffffff8139bc80 Giant (Giant) @ dev/usb/input/ukbd.c:1942 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I'm wondering if there is a bad interaction here. > > > The system has 8 DS2700 shelves dual attached to a pair > of LSI 8e cards, thus the kernel configuration with an increased > msgbuf size. > > Kernel conf: > > include GENERIC > ident ZFS > options DDB > options KDB > options WITNESS > options MSGBUF_SIZE=(32768*16) > > And some ddb output: > > db:0:kdb.enter.default> run lockinfo > db:1:lockinfo> show locks > exclusive sleep mutex MPT2SAS lock (MPT2SAS lock) r = 0 (0xffffff8003c851b8) locked @ cam/cam_periph.h:192 > db:1:locks> show alllocks > Process 30 (enc_daemon12) thread 0xfffffe003421a000 (100155) > exclusive sleep mutex MPT2SAS lock (MPT2SAS lock) r = 0 (0xffffff8003c851b8) locked @ cam/cam_periph.h:192 > db:1:alllocks> show lockedvnods > Locked vnodes > db:0:kdb.enter.default> show pcpu > cpuid = 8 > dynamic pcpu = 0xffffff807f1e4800 > curthread = 0xfffffe003421a000: pid 30 "enc_daemon12" > curpcb = 0xffffffbfd0f3dbc0 > fpcurthread = none > idlethread = 0xfffffe0021ffe490: tid 100011 "idle: cpu8" > curpmap = 0xffffffff81399590 > tssp = 0xffffffff815a5640 > commontssp = 0xffffffff815a5640 > rsp0 = 0xffffffbfd0f3dbc0 > gs32p = 0xffffffff815a3778 > ldt = 0xffffffff815a37b8 > tss = 0xffffffff815a37a8 > spin locks held: > db:0:kdb.enter.default> bt > Tracing pid 30 tid 100155 td 0xfffffe003421a000 > memcpy() at memcpy+0x8/frame 0xffffffbfd0f3d0c0 > ses_setphyspath_callback() at ses_setphyspath_callback+0xb3/frame 0xffffffbfd0f3d1d0 > ses_path_iter_devid_callback() at ses_path_iter_devid_callback+0x1c6/frame 0xffffffbfd0f3d770 > ses_devids_iter() at ses_devids_iter+0xb1/frame 0xffffffbfd0f3d7f0 > ses_paths_iter() at ses_paths_iter+0x20/frame 0xffffffbfd0f3d810 > ses_publish_physpaths() at ses_publish_physpaths+0x264/frame 0xffffffbfd0f3da40 > enc_daemon() at enc_daemon+0x2a4/frame 0xffffffbfd0f3daa0 > fork_exit() at fork_exit+0x11d/frame 0xffffffbfd0f3daf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffffbfd0f3daf0 > --- trap 0, rip = 0, rsp = 0xffffffbfd0f3dbb0, rbp = 0 --- > > Any thoughts/ideas are appreciated. I've reviewed the code and > don't see anything obvious. > > Thanks, > John > > > From owner-freebsd-scsi@FreeBSD.ORG Tue Sep 17 00:30:46 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 50204FFE; Tue, 17 Sep 2013 00:30:46 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D65792BE5; Tue, 17 Sep 2013 00:30:45 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.7/8.14.7/ALCHEMY.FRANKEN.DE) with ESMTP id r8H0UffE037900; Tue, 17 Sep 2013 02:30:41 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.7/8.14.7/Submit) id r8H0UfMq037899; Tue, 17 Sep 2013 02:30:41 +0200 (CEST) (envelope-from marius) Date: Tue, 17 Sep 2013 02:30:41 +0200 From: Marius Strobl To: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= Subject: Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking Message-ID: <20130917003041.GA74198@alchemy.franken.de> References: <520D4ADB.50209@FreeBSD.org> <5224511D.4090503@FreeBSD.org> <20130903134251.GB43281@caravan.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, Alexander Motin , "freebsd-current@freebsd.org" , FreeBSD SCSI , Outback Dingo X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 00:30:46 -0000 On Tue, Sep 03, 2013 at 11:48:38PM +0200, Olivier Cochard-Labbé wrote: > On Tue, Sep 3, 2013 at 8:10 PM, Outback Dingo wrote: > > Can anyone confirm how well tested/stable this patch set might be?? if > > theres positive input i have a zoo of dev machines i could load it on, to > > help further it. > > Just checking to see how widely its been tested, > > I've installed this patch on 3 differents machines there status after > about 12hours: > - SUN FIRE X4170 M2 (amd64: r255178) with 6 SAS harddrives in one big > zraid (LSI MegaSAS Gen2 controller): Used for generating package with > poudriere? no probleme since; > - HAL/Fujitsu SPARC64-V (sparc64: r255178) with two SCSI-3 disks in > gmirror: Used for generating package with poudriere too? no probleme > since; For testing GEOM direct dispatch on sparc64, please additionally use the following patch: http://people.freebsd.org/~marius/sparc64_GET_STACK_USAGE.diff Marius From owner-freebsd-scsi@FreeBSD.ORG Thu Sep 19 22:42:44 2013 Return-Path: Delivered-To: FreeBSD-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0640F85E for ; Thu, 19 Sep 2013 22:42:44 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm39-vm8.bullet.mail.gq1.yahoo.com (nm39-vm8.bullet.mail.gq1.yahoo.com [98.136.217.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 98C402E78 for ; Thu, 19 Sep 2013 22:42:43 +0000 (UTC) Received: from [98.137.12.63] by nm39.bullet.mail.gq1.yahoo.com with NNFMP; 19 Sep 2013 22:42:37 -0000 Received: from [208.71.42.196] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 19 Sep 2013 22:42:37 -0000 Received: from [127.0.0.1] by smtp207.mail.gq1.yahoo.com with NNFMP; 19 Sep 2013 22:42:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379630557; bh=uNw7bUY1lKhMZz+YGNMPNXVAqywDCOETiIn058a5OQs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=54y6TNTHCAv7EVRYdGMBi4INpQgtiFFbZLsHDiMcCJqDebMhV9vhFOTPoLwtKAPEKWWa8AN1KKzVhkwG2xCDA2HmVj6jscYDPbgY8Ub2kGNAx8W0hHiWke6ol7DMgS+p9sUtcPFcZ97H4+E4ovkMN5IheNPWKZRlIDrM1dQYOg8= X-Yahoo-Newman-Id: 866590.21332.bm@smtp207.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: d1n0fsMVM1kZUCusWwriR2ECRcG9QBpHHVzlSfB2J0kvKtj 87BWlN7xKUQfuWicb7nmcMNWNLaaTTm2_nlv9cQuvjQ8qXLzWHzKGa.8AxG. .K5C_rAnWXv47kSlvCgHNmNlSG6nBsJ3lvOYq.eG_MozKTHDf0cVE0j7SVJW PUuZlUZawXWzEX5HZOktQ7dhjZytFmMLvEemcDxQcy44xAjFzojkobIFD6LW Yu53f7Cn4F6gMUhNX_T5tAkqedBhFUdCYlhl5C4.sp82sI8tURxdeJjXkoT. 7lyss7tKICnLm8gxN2ATOFB6qfcoQT2L_ANzS0BaULVqnXIuu4KuHiqAHekH 0pZ59uKfkkMRZvDnXgi0I8XUP9CiZoTCxvSra_57FJXtrGElBRIx6ZKiItvP IjpCGo09JFc1hWZkmd9878.RUqJXko2IBHTg1o9.NZo.2..Wk8ExbodD.meF zliOzZjBDT1Ilzt_lKcsJHD0XHTHM5VIQ3JPVTWf3TCwF4WZTqhwp3nSX0f_ feaG8v18wRY4jviJ6_.pXVw0IghG23AyNimbbSixClR4AFy3oy_bbKGxIRgP wjW_iLBcxAIqj.WcoZHKCd7lP3e_7S1jWisj7PNt_kwNNo4HCNlrDEXq4W94 bsz3jzydDUHjhnQ47QcZf9p8tpv.i.hJHR.GZqn3dZw.nhcPToc.g.h5dT_g - X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp207.mail.gq1.yahoo.com with SMTP; 19 Sep 2013 15:42:37 -0700 PDT Subject: [CFT] mfiutil controller properties set/get From: Sean Bruno To: "FreeBSD-scsi@freebsd.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-A8qn1fZm8nENcI+PO+mV" Date: Thu, 19 Sep 2013 15:42:36 -0700 Message-ID: <1379630556.1841.43.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 22:42:44 -0000 --=-A8qn1fZm8nENcI+PO+mV Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Spent a bit of time today rev engineering the controller properties commands and was able to get/set the rebuild rate for my $dayjob to be adjustable for "reasons" This is just the beginning of what can be exported here, but I have stopped at the RebuildRate as that's what I need ATM. http://people.freebsd.org/~sbruno/mfiutil_controller_prps.txt If there are no objections to this stuffs, I'll chuck it at RE this weekend. Sean --=-A8qn1fZm8nENcI+PO+mV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSO33cAAoJEBkJRdwI6BaHr2IH/0ToPS9ioVDTt3IjaYJgF/SV X7rJ4XlQi1O9U80K94/xFgWLi6uAFfYR3I67jg4AeSLnzDd9nYTRnkNJONjsk+cD SYxqQKpZDYBfvb1sranyvPPTJ1QN1gTJ33ZpNpmOUFueNoDJCtrHzAd5FaOKcU0i 3A62vr91EuCWq4h1PkgWycobQbEMRdDUlqa/hTRnJ+6X/1ESrW+LqEiO21+ELTD3 Mxe5ZyB11UqNIgGuWUg4DKEc7tcWa6OTBETGswuR/uuSMut/BDjNfNiaMihtPvbb Xhq/VXyAm3xfFcLSX5+Xcw0YCzwhWl4PW3+iQgNwq0Dgxislm2WrMYI2e3D6Y4s= =gRWK -----END PGP SIGNATURE----- --=-A8qn1fZm8nENcI+PO+mV-- From owner-freebsd-scsi@FreeBSD.ORG Fri Sep 20 04:52:45 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3B3C7D5A for ; Fri, 20 Sep 2013 04:52:45 +0000 (UTC) (envelope-from martin@gneto.com) Received: from smtp.mullet.se (smtp.mullet.se [94.247.168.122]) by mx1.freebsd.org (Postfix) with ESMTP id F2FD12D69 for ; Fri, 20 Sep 2013 04:52:44 +0000 (UTC) Received: from mbp.gneto.com (ua-83-227-181-30.cust.bredbandsbolaget.se [83.227.181.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mullet.se (Postfix) with ESMTPSA id A2F3D6270003 for ; Fri, 20 Sep 2013 06:45:37 +0200 (CEST) Message-ID: <523BD2EE.1030701@gneto.com> Date: Fri, 20 Sep 2013 06:45:34 +0200 From: Martin Nilsson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Re: [CFT] mfiutil controller properties set/get References: <1379630556.1841.43.camel@localhost> In-Reply-To: <1379630556.1841.43.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 04:52:45 -0000 On 2013-09-20 00:42, Sean Bruno wrote: > Spent a bit of time today rev engineering the controller properties > commands and was able to get/set the rebuild rate for my $dayjob to be > adjustable for "reasons" > > This is just the beginning of what can be exported here, but I have > stopped at the RebuildRate as that's what I need ATM. > > IMHO, there are two important things missing from mfiutil. 1. Silence alarm - it is very stressful trying to do any work when the alarm is on. 2. Drive identify - convienient to check that the backplane is correctly configured, and that my idea of where the drives are is the same as the controllers If it's possible to add these two to mfiutil it would be great. Martin From owner-freebsd-scsi@FreeBSD.ORG Fri Sep 20 18:28:04 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7950A9EA for ; Fri, 20 Sep 2013 18:28:04 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm10-vm3.bullet.mail.ne1.yahoo.com (nm10-vm3.bullet.mail.ne1.yahoo.com [98.138.91.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 15AA628D8 for ; Fri, 20 Sep 2013 18:28:03 +0000 (UTC) Received: from [98.138.90.55] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2013 18:24:49 -0000 Received: from [98.138.226.31] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 20 Sep 2013 18:24:49 -0000 Received: from [127.0.0.1] by smtp202.mail.ne1.yahoo.com with NNFMP; 20 Sep 2013 18:24:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1379701489; bh=xdbLly2C32zq+fqLm1kdb5r1hDGT4JPNRw6zG8siwTA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=0N//RAZQ7dIwExIFvDmQNH6Bc4cjDFuFtAsoarGYvKE0vMTZ283ajkwc1G5DAQhVKlPXokeCQqiKV0A0ih53ulc7n4Nu+od2wtXzqezLZKUcRcsUdpv2/tcaXBBhg+8xMvLICS3yPrCFkLMu6565DcMk3YfS03tjN7kdSk2AXCc= X-Yahoo-Newman-Id: 67132.19520.bm@smtp202.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1tTESo8VM1mKk5fd5RQXJ5BceBKtyJOfO3ZTy0U_G2SrAE3 74oEWOYAhbdZ0J4NG_5x8oGn29BwDG7RNAXRwzLgC1JSBLSdWu1a4n3mWCIg V_dyL16v6MqZxC_WYjec4CSYf9KRfk15VkJnLVfcy0OrTyURAZVNqQc0mzyb 4R_DBgiF3pT95l0Kpd4Ua7Sd81nC5Mk3Ste2AIhv4_5t571w9V8RkPdFoM2. zQvYIcveanZIrd60e1QG.13KKPwa3JEaJZSG6FLDKo8zIIWDg1cBC8yYiaOR lLmipEEX4tIHmOezp1Y79wUR9yYPyOI3KQ9xUv65e1ZRYSXD8vjEFskELLTe 3M_mpQFPbmgKCzsJdWmDQjwurm03ce8yV6xkjTwGVVASoAu5Zyxeh4qhUYor m.GQs2qMwOq4iFtMTJuhCYCwqsthGMKn85AdAj3z2zXQ7HVmZgnGzEi0ro.M oCyOTrNoPVAqVaXiQWxfmMp9nnkFtb0a9qsvfAEwEFHotPYF5ivhVklseq5A 9JtR7rpKZS.pIQhcZ4NaFWi41efo39ZFBz_qzzrOF5FbHXBISr5caRitYi6U lpVl7svAHqiHiU6v59d..zD4xCkUF5boUPmGC0M2kYxOjAEE8K9R1OmyZSbd a0qJTYnD9eLqaI5OL2BQESuohq2H5ElZ.M6TGBeqJuA-- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.160.242] (sean_bruno@209.131.62.116 with ) by smtp202.mail.ne1.yahoo.com with SMTP; 20 Sep 2013 11:24:49 -0700 PDT Subject: Re: [CFT] mfiutil controller properties set/get From: Sean Bruno To: Martin Nilsson In-Reply-To: <523BD2EE.1030701@gneto.com> References: <1379630556.1841.43.camel@localhost> <523BD2EE.1030701@gneto.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-x8dkFYQBTY3Q9MfyZlJt" Date: Fri, 20 Sep 2013 11:24:47 -0700 Message-ID: <1379701487.2376.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 18:28:04 -0000 --=-x8dkFYQBTY3Q9MfyZlJt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > 1. Silence alarm - it is very stressful trying to do any work when the= =20 > alarm is on. >=20 This I can do with the ctrl_props struct. See regenerated patch to get this support. http://people.freebsd.org/~sbruno/mfi_properties.txt > 2. Drive identify - convienient to check that the backplane is correctly= =20 > configured, and that my idea of where the drives are is the same as the= =20 > controllers This item is handled via "locate" if I read the code correctly. Setting this will blink the LED on the disk so you know which drive your messing with. locate - toggle drive LED --=-x8dkFYQBTY3Q9MfyZlJt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (FreeBSD) iQEcBAABAgAGBQJSPJLpAAoJEBkJRdwI6BaH3EkH/1e5GKNPZkx7XG7vVPyU7G+m 8OwjBcGwYwMAuPS+0y3TDJDlJIOEM9ovC2bbKt5dEH29tanVOtfGIysm7nYxNFBY 7Z43TTrnL73+R/WAy+ruYnRtl4dqsKLF75rY9CwWweAv0Urze1f4SEZAgXTL282N DM9R5Ud2Nw9GNcsZ6tf75tH1EyP9hS9ZlsFuW9WeDFwRy1kcmJwuf2kGMPCJRzFx rwIVYsSZTLceNe3LnFxh4pdU1r+uTaK8I6quO3pDYssSkOqFArW6hqwwfZJbfL9+ iw8wOGLXWv8Z4j5hGiu0UJlECl4R/bB4m1EXT/otfKhqkwzo9o64jOZgZJc+Igg= =K7SL -----END PGP SIGNATURE----- --=-x8dkFYQBTY3Q9MfyZlJt--