From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 5 09:00:49 2007 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 25E3716A417 for ; Mon, 5 Nov 2007 09:00:49 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by mx1.freebsd.org (Postfix) with ESMTP id 00A3F13C4A3 for ; Mon, 5 Nov 2007 09:00:48 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from localhost (localhost [127.0.0.1]) by ly.sdf.com (Postfix) with ESMTP id 580151FC003; Sun, 4 Nov 2007 22:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -4.049 X-Spam-Level: X-Spam-Status: No, score=-4.049 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.350, BAYES_00=-2.599] Received: from ly.sdf.com ([127.0.0.1]) by localhost (ly.sdf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHCIGRbqb8Ow; Sun, 4 Nov 2007 22:57:44 -0800 (PST) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by ly.sdf.com (Postfix) with ESMTP id 4D5521FC001; Sun, 4 Nov 2007 22:57:44 -0800 (PST) Date: Sun, 4 Nov 2007 22:57:44 -0800 (PST) From: Tom Samplonius To: James Mansion Message-ID: <11986784.3811194245864164.JavaMail.root@ly.sdf.com> In-Reply-To: <472C458E.1060309@mansionfamily.plus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.113.193.90] Cc: freebsd-scsi@freebsd.org Subject: Re: iSCSI in 7.0 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: Mon, 05 Nov 2007 09:00:49 -0000 ----- "James Mansion" wrote: > Have to say I was very pleasntly shocked to see iSCSI initiator > support > in the 7.0 overview. > > Is this the right place to ask about it? > > Specifically, does FreeBSD ensure that socket buffers are allocated > from > a set-aside pool > for iSCSI data, so that iSCSI can be used for swap in a diskless > environment? (Perhaps > ideally it would be a mount-time option for this: its only really swap Well, since it is a kernel mode driver, it has to be use kernel memory. There should be no issue with a swap deadlock, because the iSCSI client can't get more memory until some memory is swapped in. But FreeBSD does not generally like running out kernel memory either. > that needs it after all) > > Linux fails to do this for iSCSI or AoE or nbd and prone (perhaps > theoretically prone, > but its a worry) to deadlock when swapping over the network. I think Linux is using a kernel mode driver too. Well, there were several iSCSI clients when I checked. I'm not sure which you are looking at. > Also, is the framework support such that it could be extended to > support > coraid AoE or > simple nbd like Linux, but without the limitation above? Well, FreeBSD has ggated for ndb like things. It has been around for a while. AoE sounds completely retarded. I hope it disappears before people think it is actually something serious. > Thanks > James Tom From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 5 11:07:05 2007 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E11616A508 for ; Mon, 5 Nov 2007 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECC313C48E for ; Mon, 5 Nov 2007 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lA5B75Go026433 for ; Mon, 5 Nov 2007 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lA5B74gc026429 for freebsd-scsi@FreeBSD.org; Mon, 5 Nov 2007 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Nov 2007 11:07:04 GMT Message-Id: <200711051107.lA5B74gc026429@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 Cc: Subject: Current problem reports assigned to freebsd-scsi@FreeBSD.org 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: Mon, 05 Nov 2007 11:07:05 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/40895 scsi wierd kernel / device driver bug o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/60598 scsi wire down of scsi devices conflicts with config o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 o kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceProbeInfo comm o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/93128 scsi [sym] FreeBSD 6.1 BETA 1 has problems with Symbios/LSI o kern/94838 scsi Kernel panic while mounting SD card with lock switch o o kern/99954 scsi [ahc] reading from DVD failes on 6.x (regression) o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/23314 scsi [aic] aic driver fails to detect Adaptec 1520B unless o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce o kern/38828 scsi [feature request] DPT PM2012B/90 doesn't work o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs 6 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 5 21:41:00 2007 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 8B7F616A419 for ; Mon, 5 Nov 2007 21:41:00 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 591F713C4B7 for ; Mon, 5 Nov 2007 21:41:00 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 05 Nov 2007 13:21:42 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id lA5LRcoE035715; Mon, 5 Nov 2007 13:27:38 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id lA5LRblV035714; Mon, 5 Nov 2007 13:27:37 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200711052127.lA5LRblV035714@ambrisko.com> In-Reply-To: <4727FA4A.2000708@samsco.org> To: Scott Long Date: Mon, 5 Nov 2007 13:27:37 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-scsi@freebsd.org Subject: Re: MFI and passthrough 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: Mon, 05 Nov 2007 21:41:00 -0000 Scott Long writes: | The passthrough interface is really only meant for doing management | tasks like SMART monitoring and firmware flashes. I've also seen it | used for low-duty devices like tape drives. I do not recommend using it | to directly control disks in a primary fashion. However, since this is | open source, I won't prevent you from trying =-) Try the following | patch: | | --- mfi_cam.c 12 Oct 2007 16:52:55 -0000 1.3 | +++ mfi_cam.c 31 Oct 2007 03:42:25 -0000 | @@ -344,9 +344,11 @@ | command = ccb->csio.cdb_io.cdb_bytes[0]; | if (command == INQUIRY) { | device = ccb->csio.data_ptr[0] & 0x1f; | +#if 0 | if ((device == T_DIRECT) || (device == | T_PROCESSOR)) | csio->data_ptr[0] = | (device & 0xe0) | T_NODEVICE; | +#endif | } | break; | } BTW, it works great in this mode if you know what you are doing :-) | I do believe that Dell does sell a direct attached disk option for | the 2950/1950 called the PERC5/e. It's essentially an LSI MPT-SAS | controller that directly replaces the PERC5/i card that you have now. | It should be able to control all 6 disk slots, and can do both SAS | and SATA. I've been told the PERC5/e and PERC5/i are the same except for PCI sub-device ID and are both the mfi(4) RAID controllers. They do have a mpt(4) based card but it only supports 4 bays. I'm not sure what it's real name is but we have some lying around for random testing. I don't leave them in machines. Doug A. From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 06:32:52 2007 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 3178C16A418 for ; Tue, 6 Nov 2007 06:32:52 +0000 (UTC) (envelope-from james@mansionfamily.plus.com) Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by mx1.freebsd.org (Postfix) with ESMTP id B8C5D13C4B8 for ; Tue, 6 Nov 2007 06:32:51 +0000 (UTC) (envelope-from james@mansionfamily.plus.com) Received: from [80.229.150.39] (helo=mansionfamily.plus.com) by pih-relay04.plus.net with esmtp (Exim) id 1IpHzO-00039U-IK for freebsd-scsi@freebsd.org; Tue, 06 Nov 2007 06:32:42 +0000 Received: from [192.168.0.120] ([192.168.0.120]:3475) by mansionfamily.plus.com with [XMail 1.22 ESMTP Server] id for from ; Tue, 6 Nov 2007 06:37:05 -0000 Message-ID: <47300ADE.5070506@mansionfamily.plus.com> Date: Tue, 06 Nov 2007 06:34:06 +0000 From: James Mansion User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org, tom@samplonius.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: iSCSI in 7.0 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: Tue, 06 Nov 2007 06:32:52 -0000 (Apologies for the bad quoting: I had to copy the response from a web view of the archive since I don't seem to have received anything except the 'Current problems' mail. Weird.) Tom Samplonius wrote: >Well, since it is a kernel mode driver, it has to be use kernel memory. Yes, but ... >There should be no issue with a swap deadlock, because the iSCSI client >can't get more memory until some memory is swapped in. But FreeBSD >does not generally like running out kernel memory either. That does not *necessarily* follow, which is the crux of my question. Most kernels will have a pool for non-pageable memory and allocate from a pageable pool too, even though the memory is 'kernel memory' and not addressable from any user context. FreeBSD can run with a very lean kernel footprint (which is the reason for my interest) and yet support C10k systems with kqueue without static reconfiguration of the kernel, and its hard to see how this could possibly be the case with a fully static allocation. In many cases thread stacks, socket send and receive buffers, pipe buffers etc *will* be pageable. That's the case for the buffers used to receive and process IP datagrams in Linux I believe. > I think Linux is using a kernel mode driver too. Well, there were several iSCSI clients > when I checked. I'm not sure which you are looking at. I think your reasoning is flawed here, for the same reason. Now, it may be that FreeBSD does have a lot more non-pageable allocation and is able to reassemble incoming IP packets and process iSCSI data without any allocation from pageable memory. I believe its not normally a trivial problem unless you are prepared to perform an extra copy operation. Do you know this for a fact? > AoE sounds completely retarded. I hope it disappears before people think it is actually something serious. Well, that's simply opinion. It is certainly a simplified approach, but I think to suggest that it is entirely without merit is bogus. And I have discussed the issue with Linux IP memory management and swap support with the Coraid developer - its a known 'issue' (or non-issue for Linus it seems: its only swap rather than net boot that's affected after all, and most blades do come with disks). James From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 14:10:27 2007 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 5C57216A420; Tue, 6 Nov 2007 14:10:27 +0000 (UTC) (envelope-from oleg.lomaka@gmail.com) Received: from gnome.kiev.sovam.com (gnome.kiev.sovam.com [212.109.32.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8C07113C49D; Tue, 6 Nov 2007 14:10:25 +0000 (UTC) (envelope-from oleg.lomaka@gmail.com) Received: from relay02.kiev.sovam.com ([62.64.120.197]) by gnome.kiev.sovam.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IpP88-0006i7-8i; Tue, 06 Nov 2007 16:10:12 +0200 Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IpP83-0003U2-Jn; Tue, 06 Nov 2007 16:10:10 +0200 Received: from tdevil.lomaka.org.ua (fc2.kiev.zoral.com.ua [10.1.1.7]) (authenticated bits=0) by skuns.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id lA6E9qYV002082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Nov 2007 16:09:52 +0200 (EET) (envelope-from oleg.lomaka@gmail.com) Message-ID: <473075B4.4000600@gmail.com> Date: Tue, 06 Nov 2007 16:09:56 +0200 From: Oleg Lomaka User-Agent: Thunderbird 2.0.0.6 (X11/20071102) MIME-Version: 1.0 To: Scott Long References: <4729E8D3.2020404@gmail.com> <472A8D31.2080503@samsco.org> <472AF723.7080802@gmail.com> <472B4419.3030805@samsco.org> In-Reply-To: <472B4419.3030805@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 738383df96b2f9821994c426902f10af X-DrWeb-checked: yes X-SpamTest-Envelope-From: oleg.lomaka@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1739 [Nov 06 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-scsi@freebsd.org, Oleg Lomaka , scottl@freebsd.org, kib@freebsd.org Subject: Re: RELENG_7 core dump (sgread) 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: Tue, 06 Nov 2007 14:10:27 -0000 I'm sorry for a long delay. Kernel failed to compile after patch. I've got more info about crash. It looks like it happening when I plug in USB HDD. In some cases I can plug it in and make mount, in some cases I just plug it in, and core dumps. cc -O2 -fno-strict-aliasing -pipe -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/TDEVIL-7.kernconf/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/TDEVIL-7.kernconf -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c: In function 'sgdone': /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c:366: error: 'sc' undeclared (first use in this function) /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c:366: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c:366: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/cam. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/TDEVIL-7.kernconf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. tdevil% Scott Long wrote: > Oops, disregard the last, please try the patch at: > > http://people.freebsd.org/~scottl/scsi_sg.diff > > Scott > > > Oleg Lomaka wrote: >> Hello, >> >> For usb hdd. Kostik (kib) thinks this caused by hald daemon that used >> by gnome. Today got this trap again: >> >> Fatal trap 12: page fault while in kernel mode >> fault virtual address = 0x18 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc04d6a62 >> stack pointer = 0x28:0xe74e5ac0 >> frame pointer = 0x28:0xe74e5ad8 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 1394 (hald-probe-storage) >> trap number = 12 >> panic: page fault >> KDB: stack backtrace: >> db_trace_self_wrapper(c06b2ef4,e74e59a0,c04aadca,c06b10e6,c07245c0,...) >> at 0xc044a886 = db_trace_self_wrapper+0x26 >> kdb_backtrace(c06b10e6,c07245c0,c06a9c87,e74e59ac,e74e59ac,...) at >> 0xc04cd629 = kdb_backtrace+0x29 >> panic(c06a9c87,c06ce667,c5d42220,1,1,...) at 0xc04aadca = panic+0xaa >> trap_fatal(c06ce569,c,0,74e5a00,c,...) at 0xc0689343 = trap_fatal+0x303 >> trap(e74e5a80) at 0xc0689b7a = trap+0x14a >> calltrap() at 0xc067410b = calltrap+0x6 >> --- trap 0xc, eip = 0xc04d6a62, esp = 0xe74e5ac0, ebp = 0xe74e5ad8 --- >> turnstile_broadcast(0,0,4,c5aef840,e74e5b0c,...) at 0xc04d6a62 = >> turnstile_broadcast+0x32 >> _mtx_unlock_sleep(c0724410,0,c06b0793,9e) at 0xc04a0b92 = >> _mtx_unlock_sleep+0x52 >> _mtx_unlock_flags(c0724410,0,c06b0793,9e,e74e5b5c,...) at 0xc04a0c11 >> = _mtx_unlock_flags+0x51 >> unlock_mtx(c0724410,0,c06b1680,b8,e74e5c60,...) at 0xc04a0c49 = >> unlock_mtx+0x29 >> _sleep(0,c0724410,100,c08c57e6,0,...) at 0xc04b1feb = _sleep+0x15b >> sgread(c5ca9b00,e74e5c60,0,168,0,...) at 0xc08bb2ef = sgread+0xff >> giant_read(c5ca9b00,e74e5c60,0,0,c00,...) at 0xc047eed8 = >> giant_read+0x48 >> devfs_read_f(c5c9e240,e74e5c60,c437c800,0,c5aef840,...) at 0xc04645c1 >> = devfs_read_f+0x71 >> dofileread(e74e5c60,ffffffff,ffffffff,0,c5c9e240,...) at 0xc04da116 = >> dofileread+0x96 >> kern_readv(c5aef840,4,e74e5c60,2842a00c,bf4,...) at 0xc04da488 = >> kern_readv+0x58 >> read(c5aef840,e74e5cfc,c,c5aef840,c06d8e28,...) at 0xc04da56f = >> read+0x4f >> syscall(e74e5d38) at 0xc06897f3 = syscall+0x2b3 >> Xint0x80_syscall() at 0xc0674170 = Xint0x80_syscall+0x20 >> --- syscall (3, FreeBSD ELF32, read), eip = 0x283504a3, esp = >> 0xbfbfe69c, ebp = 0xbfbfe6f8 --- >> >> >> Scott Long wrote: >>> What are you using the sg driver for? >>> >>> Scott >>> >>> >>> Oleg Lomaka wrote: >>>> Hello. Last days I have periodically kernel crashes. >>>> Following are back trace and variables info. Should I need to post >>>> anything else? >>>> Thanks. >>>> >>>> ps: I do not try to disconnect mounted usb drives. >>>> >>>> #0 doadump () at pcpu.h:195 >>>> #1 0xc04aa7b3 in boot (howto=260) at >>>> /usr/src/sys/kern/kern_shutdown.c:409 >>>> #2 0xc04aa97c in panic (fmt=Variable "fmt" is not available. >>>> ) at /usr/src/sys/kern/kern_shutdown.c:563 >>>> #3 0xc0688c23 in trap_fatal (frame=0xe7502a80, eva=24) at >>>> /usr/src/sys/i386/i386/trap.c:872 >>>> #4 0xc068945a in trap (frame=0xe7502a80) at >>>> /usr/src/sys/i386/i386/trap.c:277 >>>> #5 0xc06739eb in calltrap () at >>>> /usr/src/sys/i386/i386/exception.s:139 >>>> #6 0xc04d65e2 in turnstile_broadcast (ts=0x0, queue=0) at >>>> /usr/src/sys/kern/subr_turnstile.c:834 >>>> #7 0xc04a0712 in _mtx_unlock_sleep (m=0xc0723ed0, opts=0, >>>> file=0xc06b01a7 "/usr/src/sys/kern/kern_mutex.c", >>>> line=158) at /usr/src/sys/kern/kern_mutex.c:593 >>>> #8 0xc04a0791 in _mtx_unlock_flags (m=0xc0723ed0, opts=0, >>>> file=0xc06b01a7 "/usr/src/sys/kern/kern_mutex.c", >>>> line=158) at /usr/src/sys/kern/kern_mutex.c:210 >>>> #9 0xc04a07c9 in unlock_mtx (lock=0xc0723ed0) at >>>> /usr/src/sys/kern/kern_mutex.c:158 >>>> #10 0xc04b1b6b in _sleep (ident=0x0, lock=0xc0723ed0, priority=256, >>>> wmesg=0xc08c57e6 "sgread", timo=0) >>>> at /usr/src/sys/kern/kern_synch.c:187 >>>> #11 0xc08bb2ef in sgread (dev=0xc4f53500, uio=0xe7502c60, ioflag=0) >>>> at /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c:798 >>>> #12 0xc047ea58 in giant_read (dev=0xc4f53500, uio=0xe7502c60, >>>> ioflag=0) at /usr/src/sys/kern/kern_conf.c:361 >>>> #13 0xc0464141 in devfs_read_f (fp=0xc5bfdbd0, uio=0xe7502c60, >>>> cred=0xc437c800, flags=0, td=0xc594b210) >>>> at /usr/src/sys/fs/devfs/devfs_vnops.c:880 >>>> #14 0xc04d9c96 in dofileread (td=0xc594b210, fd=4, fp=0xc5bfdbd0, >>>> auio=0xe7502c60, offset=-1, flags=0) at file.h:242 >>>> #15 0xc04da008 in kern_readv (td=0xc594b210, fd=4, auio=0xe7502c60) >>>> at /usr/src/sys/kern/sys_generic.c:192 >>>> #16 0xc04da0ef in read (td=0xc594b210, uap=0xe7502cfc) at >>>> /usr/src/sys/kern/sys_generic.c:108 >>>> #17 0xc06890d3 in syscall (frame=0xe7502d38) at >>>> /usr/src/sys/i386/i386/trap.c:1008 >>>> #18 0xc0673a50 in Xint0x80_syscall () at >>>> /usr/src/sys/i386/i386/exception.s:196 >>>> #19 0x00000033 in ?? () >>>> >>>> >>>> (kgdb) frame 11 >>>> #11 0xc08bb2ef in sgread (dev=0xc4f53500, uio=0xe7502c60, ioflag=0) >>>> at /usr/src/sys/modules/cam/../../cam/scsi/scsi_sg.c:798 >>>> 798 if (msleep(rdwr, periph->sim->mtx, PCATCH, >>>> "sgread", 0) == ERESTART) >>>> >>>> (kgdb) info locals >>>> sc = (struct sg_softc *) 0xc4468000 >>>> rdwr = (struct sg_rdwr *) 0x0 >>>> hstat = Variable "hstat" is not available. >>>> >>>> (kgdb) p *sc >>>> $2 = {state = SG_STATE_NORMAL, flags = SG_FLAG_OPEN, device_stats = >>>> 0xc468b960, rdwr_done = {tqh_first = 0x0, >>>> tqh_last = 0xc446800c}, dev = 0xc4f53500, sg_timeout = 60000, >>>> sg_user_timeout = 60000, pd_type = 0 '\0', >>>> saved_ccb = {ccb_h = {pinfo = {priority = 0, generation = 0, index >>>> = 0}, xpt_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next = >>>> 0x0, tqe_prev = 0x0}, stqe = {stqe_next = 0x0}}, >>>> sim_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = >>>> {sle_next = 0x0}, tqe = {tqe_next = 0x0, >>>> tqe_prev = 0x0}, stqe = {stqe_next = 0x0}}, periph_links = >>>> {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, retry_count = 0, >>>> cbfcnp = 0, func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, >>>> flags = 0, periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field = >>>> 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, csio = {ccb_h = { >>>> pinfo = {priority = 0, generation = 0, index = 0}, xpt_links >>>> = {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, next_ccb = 0x0, >>>> req_map = 0x0, data_ptr = 0x0, dxfer_len = 0, sense_data = >>>> {error_code = 0 '\0', segment = 0 '\0', >>>> flags = 0 '\0', info = "\000\000\000", extra_len = 0 '\0', >>>> cmd_spec_info = "\000\000\000", >>>> add_sense_code = 0 '\0', add_sense_code_qual = 0 '\0', fru = >>>> 0 '\0', sense_key_spec = "\000\000", >>>> extra_bytes = '\0' }, sense_len = 0 '\0', cdb_len = 0 '\0', >>>> sglist_cnt = 0, >>>> scsi_status = 0 '\0', sense_resid = 0 '\0', resid = 0, cdb_io >>>> = {cdb_ptr = 0x0, >>>> cdb_bytes = '\0' }, msg_ptr = 0x0, msg_len = 0, tag_action = >>>> 0 '\0', tag_id = 0, >>>> init_id = 0}, cgd = {ccb_h = {pinfo = {priority = 0, >>>> generation = 0, index = 0}, xpt_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, inq_data = { >>>> device = 0 '\0', dev_qual2 = 0 '\0', version = 0 '\0', >>>> response_format = 0 '\0', additional_length = 0 '\0', >>>> reserved = 0 '\0', spc2_flags = 0 '\0', flags = 0 '\0', >>>> vendor = "\000\000\000\000\000\000\000", >>>> product = '\0' , revision = "\000\000\000", vendor_specific0 >>>> = '\0' , >>>> spi3data = 0 '\0', reserved2 = 0 '\0', version1 = "\000", >>>> version2 = "\000", version3 = "\000", >>>> version4 = "\000", version5 = "\000", version6 = "\000", >>>> version7 = "\000", version8 = "\000", >>>> reserved3 = '\0' , vendor_specific1 = '\0' }, >>>> serial_num = '\0' , reserved = 0 '\0', serial_num_len = 0 >>>> '\0'}, cgdl = {ccb_h = {pinfo = { >>>> priority = 0, generation = 0, index = 0}, xpt_links = {le >>>> = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, >>>> periph_name = '\0' , unit_number = 0, generation = 0, index = 0, >>>> status = CAM_GDEVLIST_LAST_DEVICE}, cpi = {ccb_h = {pinfo = >>>> {priority = 0, generation = 0, index = 0}, >>>> xpt_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = >>>> {sle_next = 0x0}, tqe = {tqe_next = 0x0, >>>> tqe_prev = 0x0}, stqe = {stqe_next = 0x0}}, sim_links = >>>> {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, periph_links = { >>>> le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = >>>> 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, version_num = 0 '\0', >>>> hba_inquiry = 0 '\0', target_sprt = 0 '\0', hba_misc = 0 '\0', >>>> hba_eng_cnt = 0, >>>> vuhba_flags = '\0' , max_target = 0, max_lun = 0, async_flags >>>> = 0, hpath_id = 0, >>>> initiator_id = 0, sim_vid = '\0' , hba_vid = '\0' , >>>> dev_name = '\0' , unit_number = 0, bus_id = 0, >>>> base_transfer_speed = 0, >>>> protocol = PROTO_UNKNOWN, protocol_version = 0, transport = >>>> XPORT_UNKNOWN, transport_version = 0, >>>> xport_specific = {spi = {ppr_options = 0 '\0'}, fc = {wwnn = >>>> 0, wwpn = 0, port = 0, bitrate = 0}, sas = { >>>> bitrate = 0}, ccb_pathinq_settings_opaque = '\0' }}, crs = >>>> {ccb_h = {pinfo = { >>>> priority = 0, generation = 0, index = 0}, xpt_links = {le >>>> = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, release_flags = 0, >>>> openings = 0, release_timeout = 0, qfrozen_cnt = 0}, csa = >>>> {ccb_h = {pinfo = {priority = 0, generation = 0, >>>> index = 0}, xpt_links = {le = {le_next = 0x0, le_prev = >>>> 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, event_enable = 0, >>>> callback = 0, callback_arg = 0x0}, csd = {ccb_h = {pinfo = >>>> {priority = 0, generation = 0, index = 0}, >>>> xpt_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = >>>> {sle_next = 0x0}, tqe = {tqe_next = 0x0, >>>> tqe_prev = 0x0}, stqe = {stqe_next = 0x0}}, sim_links = >>>> {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, periph_links = { >>>> le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = >>>> 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, dev_type = 0 '\0'}, >>>> cpis = {ccb_h = {pinfo = {priority = 0, generation = 0, index = >>>> 0}, xpt_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, last_reset = { >>>> tv_sec = 0, tv_usec = 0}}, cgds = {ccb_h = {pinfo = >>>> {priority = 0, generation = 0, index = 0}, xpt_links = { >>>> le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = >>>> 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = {le_next = >>>> 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next >>>> = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, dev_openings = 0, >>>> dev_active = 0, devq_openings = 0, devq_queued = 0, held = 0, >>>> maxtags = 0, mintags = 0, last_reset = { >>>> tv_sec = 0, tv_usec = 0}}, cdm = {ccb_h = {pinfo = {priority >>>> = 0, generation = 0, index = 0}, xpt_links = { >>>> le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = >>>> 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = {le_next = >>>> 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next >>>> = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, >>>> status = CAM_DEV_MATCH_LAST, num_patterns = 0, pattern_buf_len >>>> = 0, patterns = 0x0, num_matches = 0, >>>> match_buf_len = 0, matches = 0x0, pos = {generations = {0, 0, >>>> 0, 0}, position_type = CAM_DEV_POS_NONE, >>>> cookie = {bus = 0x0, target = 0x0, device = 0x0, periph = >>>> 0x0, pdrv = 0x0}}}, cts = {ccb_h = {pinfo = { >>>> priority = 0, generation = 0, index = 0}, xpt_links = {le >>>> = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, >>>> type = CTS_TYPE_CURRENT_SETTINGS, protocol = PROTO_UNKNOWN, >>>> protocol_version = 0, transport = XPORT_UNKNOWN, >>>> transport_version = 0, proto_specific = {valid = 0, scsi = >>>> {valid = 0, flags = 0}}, xport_specific = { >>>> valid = 0, spi = {valid = 0, flags = 0, sync_period = 0, >>>> sync_offset = 0, bus_width = 0, ppr_options = 0}, >>>> fc = {valid = 0, wwnn = 0, wwpn = 0, port = 0, bitrate = 0}, >>>> sas = {valid = 0, bitrate = 0}}}, ccg = { >>>> ccb_h = {pinfo = {priority = 0, generation = 0, index = 0}, >>>> xpt_links = {le = {le_next = 0x0, le_prev = 0x0}, >>>> sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = >>>> 0x0}, stqe = {stqe_next = 0x0}}, sim_links = { >>>> le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = >>>> 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, periph_links = {le = {le_next = >>>> 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next >>>> = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, block_size = 0, >>>> volume_size = 0, cylinders = 0, heads = 0 '\0', secs_per_track >>>> = 0 '\0'}, cab = {ccb_h = {pinfo = { >>>> priority = 0, generation = 0, index = 0}, xpt_links = {le >>>> = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, abort_ccb = 0x0}, >>>> crb = {ccb_h = {pinfo = {priority = 0, generation = 0, index = >>>> 0}, xpt_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}}, crd = {ccb_h = { >>>> pinfo = {priority = 0, generation = 0, index = 0}, xpt_links >>>> = {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}}, tio = {ccb_h = { >>>> pinfo = {priority = 0, generation = 0, index = 0}, xpt_links >>>> = {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, sim_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, termio_ccb = 0x0}, >>>> atio = {ccb_h = {pinfo = {priority = 0, generation = 0, index = >>>> 0}, xpt_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, cdb_io = { >>>> cdb_ptr = 0x0, cdb_bytes = '\0' }, cdb_len = 0 '\0', >>>> tag_action = 0 '\0', >>>> sense_len = 0 '\0', tag_id = 0, init_id = 0, sense_data = >>>> {error_code = 0 '\0', segment = 0 '\0', >>>> flags = 0 '\0', info = "\000\000\000", extra_len = 0 '\0', >>>> cmd_spec_info = "\000\000\000", >>>> add_sense_code = 0 '\0', add_sense_code_qual = 0 '\0', fru = >>>> 0 '\0', sense_key_spec = "\000\000", >>>> extra_bytes = '\0' }}, ctio = {ccb_h = {pinfo = {priority = >>>> 0, generation = 0, index = 0}, >>>> xpt_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = >>>> {sle_next = 0x0}, tqe = {tqe_next = 0x0, >>>> tqe_prev = 0x0}, stqe = {stqe_next = 0x0}}, sim_links = >>>> {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, periph_links = { >>>> le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = >>>> 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, next_ccb = 0x0, >>>> req_map = 0x0, data_ptr = 0x0, dxfer_len = 0, sense_data = >>>> {error_code = 0 '\0', segment = 0 '\0', >>>> flags = 0 '\0', info = "\000\000\000", extra_len = 0 '\0', >>>> cmd_spec_info = "\000\000\000", >>>> add_sense_code = 0 '\0', add_sense_code_qual = 0 '\0', fru = >>>> 0 '\0', sense_key_spec = "\000\000", >>>> extra_bytes = '\0' }, sense_len = 0 '\0', cdb_len = 0 '\0', >>>> sglist_cnt = 0, >>>> scsi_status = 0 '\0', sense_resid = 0 '\0', resid = 0, cdb_io >>>> = {cdb_ptr = 0x0, >>>> cdb_bytes = '\0' }, msg_ptr = 0x0, msg_len = 0, tag_action = >>>> 0 '\0', tag_id = 0, >>>> init_id = 0}, cel = {ccb_h = {pinfo = {priority = 0, >>>> generation = 0, index = 0}, xpt_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, grp6_len = 0, >>>> grp7_len = 0, enable = 0 '\0'}, cin = {ccb_h = {pinfo = >>>> {priority = 0, generation = 0, index = 0}, >>>> xpt_links = {le = {le_next = 0x0, le_prev = 0x0}, sle = >>>> {sle_next = 0x0}, tqe = {tqe_next = 0x0, >>>> tqe_prev = 0x0}, stqe = {stqe_next = 0x0}}, sim_links = >>>> {le = {le_next = 0x0, le_prev = 0x0}, sle = { >>>> sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, periph_links = { >>>> le = {le_next = 0x0, le_prev = 0x0}, sle = {sle_next = >>>> 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}, >>>> stqe = {stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, sense_data = { >>>> error_code = 0 '\0', segment = 0 '\0', flags = 0 '\0', info >>>> = "\000\000\000", extra_len = 0 '\0', >>>> cmd_spec_info = "\000\000\000", add_sense_code = 0 '\0', >>>> add_sense_code_qual = 0 '\0', fru = 0 '\0', >>>> sense_key_spec = "\000\000", extra_bytes = '\0' }, sense_len >>>> = 0 '\0', >>>> initiator_id = 0 '\0', message_args = >>>> "\000\000\000\000\000\000"}, cna = {ccb_h = {pinfo = {priority = 0, >>>> generation = 0, index = 0}, xpt_links = {le = {le_next = >>>> 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next >>>> = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, seq_id = 0, >>>> event = 0 '\0'}, cei = {ccb_h = {pinfo = {priority = 0, >>>> generation = 0, index = 0}, xpt_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, eng_num = 0, >>>> eng_type = EIT_BUFFER, eng_algo = EAD_VUNIQUE, eng_memeory = >>>> 0}, cee = {ccb_h = {pinfo = {priority = 0, >>>> generation = 0, index = 0}, xpt_links = {le = {le_next = >>>> 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next >>>> = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, pdrv_ptr = 0x0, >>>> req_map = 0x0, data_ptr = 0x0, dxfer_len = 0, engdata_ptr = >>>> 0x0, sglist_cnt = 0, dmax_len = 0, dest_len = 0, >>>> src_resid = 0, timeout = 0, eng_num = 0, vu_flags = 0}, crcn = >>>> {ccb_h = {pinfo = {priority = 0, >>>> generation = 0, index = 0}, xpt_links = {le = {le_next = >>>> 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next >>>> = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, path_id = 0, >>>> target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, bytes = >>>> "\000\000\000"}, {ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}}, bytes = >>>> "\000\000\000\000\000\000\000"}, sim_priv = {entries = {{ptr = 0x0, >>>> field = 0, bytes = "\000\000\000"}, {ptr = 0x0, field >>>> = 0, bytes = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, >>>> flags = CAM_FLAG_NONE}, cdbg = {ccb_h = {pinfo = {priority = >>>> 0, generation = 0, index = 0}, xpt_links = {le = { >>>> le_next = 0x0, le_prev = 0x0}, sle = {sle_next = 0x0}, >>>> tqe = {tqe_next = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, sim_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = { >>>> tqe_next = 0x0, tqe_prev = 0x0}, stqe = {stqe_next = >>>> 0x0}}, periph_links = {le = {le_next = 0x0, >>>> le_prev = 0x0}, sle = {sle_next = 0x0}, tqe = {tqe_next >>>> = 0x0, tqe_prev = 0x0}, stqe = { >>>> stqe_next = 0x0}}, retry_count = 0, cbfcnp = 0, >>>> func_code = XPT_NOOP, status = 0, path = 0x0, >>>> path_id = 0, target_id = 0, target_lun = 0, flags = 0, >>>> periph_priv = {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, sim_priv = >>>> {entries = {{ptr = 0x0, field = 0, >>>> bytes = "\000\000\000"}, {ptr = 0x0, field = 0, bytes >>>> = "\000\000\000"}}, >>>> bytes = "\000\000\000\000\000\000\000"}, timeout = 0, >>>> timeout_ch = {callout = 0x0}}, >>>> flags = CAM_DEBUG_NONE}}} >>>> >>> >> > From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 14:17:30 2007 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 4957116A46C; Tue, 6 Nov 2007 14:17:30 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 18C2E13C4C2; Tue, 6 Nov 2007 14:17:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lA6EHH8r059983; Tue, 6 Nov 2007 07:17:18 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4730776B.3020804@samsco.org> Date: Tue, 06 Nov 2007 07:17:15 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Oleg Lomaka References: <4729E8D3.2020404@gmail.com> <472A8D31.2080503@samsco.org> <472AF723.7080802@gmail.com> <472B4419.3030805@samsco.org> <473075B4.4000600@gmail.com> In-Reply-To: <473075B4.4000600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 06 Nov 2007 07:17:18 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, kib@freebsd.org Subject: Re: RELENG_7 core dump (sgread) 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: Tue, 06 Nov 2007 14:17:30 -0000 Oleg Lomaka wrote: > I'm sorry for a long delay. > Kernel failed to compile after patch. > I've got more info about crash. It looks like it happening when I plug > in USB HDD. In some cases I can plug it in and make mount, in some cases > I just plug it in, and core dumps. > Sorry about the typo, take the same patch and change the "sc" on line 366 to "softc". Panic due to USB drive insertion and removal are unfortunately expected right now. I'm looking into it. However, please do test the sg patch; the panic that you originally reported is not related to the known problems with USB. Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 15:04:38 2007 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 CE92016A46D for ; Tue, 6 Nov 2007 15:04:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 638C113C4B3 for ; Tue, 6 Nov 2007 15:04:36 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lA6F2raM060636; Tue, 6 Nov 2007 08:02:54 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4730821B.3060403@samsco.org> Date: Tue, 06 Nov 2007 08:02:51 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Doug Ambrisko References: <200711052127.lA5LRblV035714@ambrisko.com> In-Reply-To: <200711052127.lA5LRblV035714@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 06 Nov 2007 08:02:54 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: MFI and passthrough 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: Tue, 06 Nov 2007 15:04:38 -0000 Doug Ambrisko wrote: > Scott Long writes: > | The passthrough interface is really only meant for doing management > | tasks like SMART monitoring and firmware flashes. I've also seen it > | used for low-duty devices like tape drives. I do not recommend using it > | to directly control disks in a primary fashion. However, since this is > | open source, I won't prevent you from trying =-) Try the following > | patch: > | > | --- mfi_cam.c 12 Oct 2007 16:52:55 -0000 1.3 > | +++ mfi_cam.c 31 Oct 2007 03:42:25 -0000 > | @@ -344,9 +344,11 @@ > | command = ccb->csio.cdb_io.cdb_bytes[0]; > | if (command == INQUIRY) { > | device = ccb->csio.data_ptr[0] & 0x1f; > | +#if 0 > | if ((device == T_DIRECT) || (device == > | T_PROCESSOR)) > | csio->data_ptr[0] = > | (device & 0xe0) | T_NODEVICE; > | +#endif > | } > | break; > | } > > BTW, it works great in this mode if you know what you are doing :-) > Can you explain what that means? I recommend against it because it's not a well-tested configuration either in FreeBSD or in Dell. It's not clear, at least to me, how basic things like i/o errors get handled; does SCSI sense data get consumed by the controller firmware, or is it passed through to the OS without problem? > | I do believe that Dell does sell a direct attached disk option for > | the 2950/1950 called the PERC5/e. It's essentially an LSI MPT-SAS > | controller that directly replaces the PERC5/i card that you have now. > | It should be able to control all 6 disk slots, and can do both SAS > | and SATA. > > I've been told the PERC5/e and PERC5/i are the same except for PCI > sub-device ID and are both the mfi(4) RAID controllers. They do > have a mpt(4) based card but it only supports 4 bays. I'm not sure > what it's real name is but we have some lying around for random > testing. I don't leave them in machines. > We should get a definitive answer on this. Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 15:21:46 2007 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 1DAD916A417 for ; Tue, 6 Nov 2007 15:21:46 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id DE2CE13C4B3 for ; Tue, 6 Nov 2007 15:21:45 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 06 Nov 2007 07:15:30 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id lA6FLQ83094856; Tue, 6 Nov 2007 07:21:26 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id lA6FLQr8094855; Tue, 6 Nov 2007 07:21:26 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200711061521.lA6FLQr8094855@ambrisko.com> In-Reply-To: <4730821B.3060403@samsco.org> To: Scott Long Date: Tue, 6 Nov 2007 07:21:26 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-scsi@freebsd.org Subject: Re: MFI and passthrough 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: Tue, 06 Nov 2007 15:21:46 -0000 Scott Long writes: | Doug Ambrisko wrote: | > Scott Long writes: | > | The passthrough interface is really only meant for doing management | > | tasks like SMART monitoring and firmware flashes. I've also seen it | > | used for low-duty devices like tape drives. I do not recommend using it | > | to directly control disks in a primary fashion. However, since this is | > | open source, I won't prevent you from trying =-) Try the following | > | patch: | > | | > | --- mfi_cam.c 12 Oct 2007 16:52:55 -0000 1.3 | > | +++ mfi_cam.c 31 Oct 2007 03:42:25 -0000 | > | @@ -344,9 +344,11 @@ | > | command = ccb->csio.cdb_io.cdb_bytes[0]; | > | if (command == INQUIRY) { | > | device = ccb->csio.data_ptr[0] & 0x1f; | > | +#if 0 | > | if ((device == T_DIRECT) || (device == | > | T_PROCESSOR)) | > | csio->data_ptr[0] = | > | (device & 0xe0) | T_NODEVICE; | > | +#endif | > | } | > | break; | > | } | > | > BTW, it works great in this mode if you know what you are doing :-) | | Can you explain what that means? I recommend against it because it's | not a well-tested configuration either in FreeBSD or in Dell. It's not | clear, at least to me, how basic things like i/o errors get handled; | does SCSI sense data get consumed by the controller firmware, or is it | passed through to the OS without problem? That's what the "know what you are doing" comes in. It should only be used by people that know what they want and willing to take the risks. There are a bunch of pit falls like blowing up your RAID by messing with disks under the RAID controller. It seems to survive a few failures but I haven't done exhaustive testing. I did run into an issue with one version of 7-current in which a one bad drive would trip up a boot since a mfi command didn't complete. Upgrading to a newer 7-current solved that problem. I should test out a bunch of our bad disks with it but haven't had the time for that. Doug A. From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 15:48:33 2007 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 40BEC16A419 for ; Tue, 6 Nov 2007 15:48:33 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from proxypop1.sarenet.es (proxypop1.sarenet.es [194.30.0.99]) by mx1.freebsd.org (Postfix) with ESMTP id F2D7B13C4AA for ; Tue, 6 Nov 2007 15:48:32 +0000 (UTC) (envelope-from borjam@sarenet.es) Received: from [172.16.1.167] (izaro.sarenet.es [192.148.167.11]) by proxypop1.sarenet.es (Postfix) with ESMTP id 934855D58; Tue, 6 Nov 2007 16:48:23 +0100 (CET) In-Reply-To: <4730821B.3060403@samsco.org> References: <200711052127.lA5LRblV035714@ambrisko.com> <4730821B.3060403@samsco.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Tue, 6 Nov 2007 16:48:19 +0100 To: Scott Long X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.752.2) Cc: freebsd-scsi@freebsd.org Subject: Re: MFI and passthrough 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: Tue, 06 Nov 2007 15:48:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 6, 2007, at 4:02 PM, Scott Long wrote: > Doug Ambrisko wrote: >> BTW, it works great in this mode if you know what you are doing :-) > > Can you explain what that means? I recommend against it because it's > not a well-tested configuration either in FreeBSD or in Dell. It's > not > clear, at least to me, how basic things like i/o errors get > handled; does SCSI sense data get consumed by the controller > firmware, or is it > passed through to the OS without problem? Aha, I see. I assumed that the controller would pass the sense data, etc, without problems. >> | I do believe that Dell does sell a direct attached disk option for >> | the 2950/1950 called the PERC5/e. It's essentially an LSI MPT-SAS >> | controller that directly replaces the PERC5/i card that you have >> now. >> | It should be able to control all 6 disk slots, and can do both SAS >> | and SATA. >> I've been told the PERC5/e and PERC5/i are the same except for PCI >> sub-device ID and are both the mfi(4) RAID controllers. They do >> have a mpt(4) based card but it only supports 4 bays. I'm not sure >> what it's real name is but we have some lying around for random >> testing. I don't leave them in machines. > > We should get a definitive answer on this. We asked our Dell salesman and he confirmed that there's a non disk array card for this machine, but it only supports 4 disks, not 6. Borja -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFHMIzGULpVo4XWgJ8RAkYvAJ9D9WrQIGVKXjS5SYgEHJBGJAvcdgCfYZts jrV84cxmIWKkcMfuX+ceChI= =wucb -----END PGP SIGNATURE----- From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 6 20:03:38 2007 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 E5F5516A417 for ; Tue, 6 Nov 2007 20:03:38 +0000 (UTC) (envelope-from james@mansionfamily.plus.com) Received: from pih-relay04.plus.net (pih-relay04.plus.net [212.159.14.131]) by mx1.freebsd.org (Postfix) with ESMTP id AE2D813C4B8 for ; Tue, 6 Nov 2007 20:03:38 +0000 (UTC) (envelope-from james@mansionfamily.plus.com) Received: from [80.229.150.39] (helo=mansionfamily.plus.com) by pih-relay04.plus.net with esmtp (Exim) id 1IpUeA-00010q-0e for freebsd-scsi@freebsd.org; Tue, 06 Nov 2007 20:03:38 +0000 Received: from [192.168.0.87] ([192.168.0.87]:3572) by mansionfamily.plus.com with [XMail 1.22 ESMTP Server] id for from ; Tue, 6 Nov 2007 20:08:01 -0000 Message-ID: <4730C8EC.7050002@mansionfamily.plus.com> Date: Tue, 06 Nov 2007 20:05:00 +0000 From: James Mansion User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org, tom@samplonius.org References: <47300ADE.5070506@mansionfamily.plus.com> In-Reply-To: <47300ADE.5070506@mansionfamily.plus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: iSCSI in 7.0 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: Tue, 06 Nov 2007 20:03:39 -0000 James Mansion wrote: > and its hard to see how this could possibly be the case with a fully > static > allocation. And I guess I'm also guilty of haste, because kernel != non-paged, and *also* static != non-paged. I suppose I have an assumption that the kernel will have defined-in static structures that are normally non-pageable, plus some further non-pageable structures based on what it finds in the options and actual device probe, and a further pool of pageable kernel memory. But this may be false - and it may be that FreeBSD could make all its kernel mode memory non-pageable. So I guess the question really is - are you saying that in this case all kernel memory is non-pageable - or that you know that for the IP stack and iSCSI initiator, all the memory is non-pageable? James From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 7 14:19:15 2007 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 DEE4216A41B for ; Wed, 7 Nov 2007 14:19:15 +0000 (UTC) (envelope-from freebsd-scsi@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC6213C4A3 for ; Wed, 7 Nov 2007 14:19:15 +0000 (UTC) (envelope-from freebsd-scsi@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IpkVm-0004NA-MD for freebsd-scsi@freebsd.org; Wed, 07 Nov 2007 13:00:02 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Nov 2007 13:00:02 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Nov 2007 13:00:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-scsi@freebsd.org From: Ivan Voras Date: Wed, 07 Nov 2007 12:48:23 +0100 Lines: 10 Message-ID: References: <47300ADE.5070506@mansionfamily.plus.com> <4730C8EC.7050002@mansionfamily.plus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.6 (X11/20070801) In-Reply-To: <4730C8EC.7050002@mansionfamily.plus.com> Sender: news Subject: Re: iSCSI in 7.0 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, 07 Nov 2007 14:19:16 -0000 James Mansion wrote: > So I guess the question really is - are you saying that in this case > all kernel memory is non-pageable - or that you know that for the > IP stack and iSCSI initiator, all the memory is non-pageable? If you don't get a definite answer here, you might want to ask that particular questions on hackers @ freebsd.org or architecture @ freebsd.org to get a wider audience of people who deal with low-level systems like the VM. From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 8 08:10:04 2007 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 93D6F16A418 for ; Thu, 8 Nov 2007 08:10:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 229BB13C4C4 for ; Thu, 8 Nov 2007 08:10:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lA889i0t073405; Thu, 8 Nov 2007 01:09:45 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4732C443.1070100@samsco.org> Date: Thu, 08 Nov 2007 01:09:39 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Borja Marcos References: <200711052127.lA5LRblV035714@ambrisko.com> <4730821B.3060403@samsco.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 08 Nov 2007 01:09:45 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: MFI and passthrough 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: Thu, 08 Nov 2007 08:10:04 -0000 Borja Marcos wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Nov 6, 2007, at 4:02 PM, Scott Long wrote: > >> Doug Ambrisko wrote: >>> BTW, it works great in this mode if you know what you are doing :-) >> >> Can you explain what that means? I recommend against it because it's >> not a well-tested configuration either in FreeBSD or in Dell. It's not >> clear, at least to me, how basic things like i/o errors get handled; >> does SCSI sense data get consumed by the controller firmware, or is it >> passed through to the OS without problem? > > Aha, I see. I assumed that the controller would pass the sense data, > etc, without problems. > >>> | I do believe that Dell does sell a direct attached disk option for >>> | the 2950/1950 called the PERC5/e. It's essentially an LSI MPT-SAS >>> | controller that directly replaces the PERC5/i card that you have now. >>> | It should be able to control all 6 disk slots, and can do both SAS >>> | and SATA. >>> I've been told the PERC5/e and PERC5/i are the same except for PCI >>> sub-device ID and are both the mfi(4) RAID controllers. They do >>> have a mpt(4) based card but it only supports 4 bays. I'm not sure >>> what it's real name is but we have some lying around for random >>> testing. I don't leave them in machines. >> >> We should get a definitive answer on this. > > We asked our Dell salesman and he confirmed that there's a non disk > array card for this machine, > but it only supports 4 disks, not 6. > Ok, I thought that the 4 disk option just routed the motherboard SATA connectors to the backplane, and that there was a 6 disk SAS+SATA option that put an MPT card into the slot behind the backplane. Oh well. Scott From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 8 08:25:20 2007 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 E2ED216A418 for ; Thu, 8 Nov 2007 08:25:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 88E3713C4A3 for ; Thu, 8 Nov 2007 08:25:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id lA88P5LJ073498; Thu, 8 Nov 2007 01:25:06 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4732C7DC.60902@samsco.org> Date: Thu, 08 Nov 2007 01:25:00 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Ivan Voras References: <47300ADE.5070506@mansionfamily.plus.com> <4730C8EC.7050002@mansionfamily.plus.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 08 Nov 2007 01:25:06 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: iSCSI in 7.0 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: Thu, 08 Nov 2007 08:25:21 -0000 Ivan Voras wrote: > James Mansion wrote: > >> So I guess the question really is - are you saying that in this case >> all kernel memory is non-pageable - or that you know that for the >> IP stack and iSCSI initiator, all the memory is non-pageable? > > If you don't get a definite answer here, you might want to ask that > particular questions on hackers @ freebsd.org or architecture @ > freebsd.org to get a wider audience of people who deal with low-level > systems like the VM. > Kernel text (executable code) and kernel data (malloc, zone, and module data segment memory) are non-pageable. Kernel stacks used to be pageable, but there was discussion some time ago about removing that feature and I don't recall the outcome. The real danger to memory deadlocks is mallocing in the I/O path. Even though kernel memory isn't pageable, the VM may need to page out some userland pages to satisfy a malloc. If that page-out goes through an I/O path that also needs to do a malloc, you get a deadlock. The CAM layer is free of these deadlocks, as are most storage drivers. I don't know if the iscsi-initiator driver is or not, I haven't inspected it closely for this. Unfortunately, the GEOM block layer is not free of this deadlock, so this whole discussion is mostly academic (the GEOM problem is small and very hard to trigger since it uses the zone allocator, but problems have been observed in real-world situations, which is a shame). Scott From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 8 10:25:15 2007 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 C70DF16A419 for ; Thu, 8 Nov 2007 10:25:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 8FAEC13C4C6 for ; Thu, 8 Nov 2007 10:25:15 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so92289rvb for ; Thu, 08 Nov 2007 02:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=pswP2aIyCyKE5wANC8Oo8EvsQAwEWoGr53pGekKo4LE=; b=BrMfu/5ofWcYppJtwaUieHGCu3SrAdBA+NqvtdoO1Q9Kr0MRIVHd6E7LLlbQRjs9QsyIrOoC9VD+l2jVrOHAR379wC106IzwhNhvliZzFyBdwDi/4XLh/2e1STTTAlcT9D5Rtlz64k8Q3oBAf2+2yFyT72KLdghxJ2V6xQHmTGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=UC/LskU1zfnJABri+HiIu3E2Q+UIRmgG0/9QCLRpYOrDpHRnA/5qV9qtWzzznKg04+K1jM7EQepbsvnVHau1tlUd4kGIjIQU97mFf1gxrTYj2uF9Uz9tOb73UhrkhQSjMD1DYsgJFdeDoUsfRUXB+UExj2zlWvZBB+Jyvyw+qFQ= Received: by 10.140.249.20 with SMTP id w20mr149091rvh.1194515783342; Thu, 08 Nov 2007 01:56:23 -0800 (PST) Received: by 10.141.211.5 with HTTP; Thu, 8 Nov 2007 01:56:23 -0800 (PST) Message-ID: <9bbcef730711080156n6a914be6m6ae478ceef7c14a9@mail.gmail.com> Date: Thu, 8 Nov 2007 10:56:23 +0100 From: "Ivan Voras" Sender: ivoras@gmail.com To: "Scott Long" In-Reply-To: <4732C7DC.60902@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47300ADE.5070506@mansionfamily.plus.com> <4730C8EC.7050002@mansionfamily.plus.com> <4732C7DC.60902@samsco.org> X-Google-Sender-Auth: a2ad32b9d877a929 Cc: freebsd-scsi@freebsd.org Subject: Re: iSCSI in 7.0 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: Thu, 08 Nov 2007 10:25:15 -0000 On 08/11/2007, Scott Long wrote: > Unfortunately, the GEOM block layer is > not free of this deadlock, so this whole discussion is mostly academic > (the GEOM problem is small and very hard to trigger since it uses the > zone allocator, but problems have been observed in real-world > situations, which is a shame). Maybe not the GEOM layer itself but various GEOM classes. For example, most non-trivial classes spawn handler threads that do malloc(M_WAITOK). From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 8 15:18:17 2007 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 12BD516A46C for ; Thu, 8 Nov 2007 15:18:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id C76DF13C4B2 for ; Thu, 8 Nov 2007 15:18:11 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport2.ambrisko.com with ESMTP; 08 Nov 2007 07:12:05 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.12.11) with ESMTP id lA8FI3kw057304; Thu, 8 Nov 2007 07:18:03 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.13.1/Submit) id lA8FI2O2057303; Thu, 8 Nov 2007 07:18:02 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200711081518.lA8FI2O2057303@ambrisko.com> In-Reply-To: <4732C443.1070100@samsco.org> To: Scott Long Date: Thu, 8 Nov 2007 07:18:02 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-scsi@freebsd.org Subject: Re: MFI and passthrough 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: Thu, 08 Nov 2007 15:18:17 -0000 Scott Long writes: | Borja Marcos wrote: | > On Nov 6, 2007, at 4:02 PM, Scott Long wrote: | > | >> Doug Ambrisko wrote: | >>> BTW, it works great in this mode if you know what you are doing :-) | >> | >> Can you explain what that means? I recommend against it because it's | >> not a well-tested configuration either in FreeBSD or in Dell. It's not | >> clear, at least to me, how basic things like i/o errors get handled; | >> does SCSI sense data get consumed by the controller firmware, or is it | >> passed through to the OS without problem? | > | > Aha, I see. I assumed that the controller would pass the sense data, | > etc, without problems. | > | >>> | I do believe that Dell does sell a direct attached disk option for | >>> | the 2950/1950 called the PERC5/e. It's essentially an LSI MPT-SAS | >>> | controller that directly replaces the PERC5/i card that you have now. | >>> | It should be able to control all 6 disk slots, and can do both SAS | >>> | and SATA. | >>> I've been told the PERC5/e and PERC5/i are the same except for PCI | >>> sub-device ID and are both the mfi(4) RAID controllers. They do | >>> have a mpt(4) based card but it only supports 4 bays. I'm not sure | >>> what it's real name is but we have some lying around for random | >>> testing. I don't leave them in machines. | >> | >> We should get a definitive answer on this. | > | > We asked our Dell salesman and he confirmed that there's a non disk | > array card for this machine, | > but it only supports 4 disks, not 6. | | Ok, I thought that the 4 disk option just routed the motherboard SATA | connectors to the backplane, and that there was a 6 disk SAS+SATA option | that put an MPT card into the slot behind the backplane. Oh well. The Dell storage cards are interesting now. The built-in cards are a PCIe card on a horizontal tray the plug in a special PCIe slot by the front. You can take it off the tray, screw on a PC slot bracket then plug it into a PCIe slot. So the same cards can be used for either in the special slot in the PE2950 or in the other Dell machines via a generic PCIe slot. The mpt(4) card only has on SAS connector on that can only plug into one of the SAS back-planes connector. So you are limited to 4 SAS bays. The mfi(4) cards have 2 so you can use all drive bays. Dell's current mpt(4) and mfi(4) cards have been layed out so they can be interchanged with their mounting HW. The only this I don't know is their naming since PERC is for "built-in" and CERC is external. Also I'm not sure what they do for the battery if in generic PCIe mode. They could make a battery that bolts on or piggy back the DIMM like LSI does. I don't know all of the specifics since we order random things that I just make work. It's a fairly smart move since they can offer the same RAID/SAS stuff across their product line and only use 2 cards. Since they share the SAS card and some platforms don't have the space for a lot of drives they probably cost reduced it to one connector versus the 2. Note moving cards around like this is probably not supported but I do things like this to test out things. Doug A. From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 10 12:59:35 2007 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 48F0716A41B; Sat, 10 Nov 2007 12:59:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.freebsd.org (Postfix) with ESMTP id E6A3913C4B6; Sat, 10 Nov 2007 12:59:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1IqpIS-0009Ka-Mb; Sat, 10 Nov 2007 14:18:44 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Scott Long In-reply-to: <4732C7DC.60902@samsco.org> References: <47300ADE.5070506@mansionfamily.plus.com> <4730C8EC.7050002@mansionfamily.plus.com> <4732C7DC.60902@samsco.org> Comments: In-reply-to Scott Long message dated "Thu, 08 Nov 2007 01:25:00 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Nov 2007 14:18:44 +0200 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, Ivan Voras Subject: Re: iSCSI in 7.0 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: Sat, 10 Nov 2007 12:59:35 -0000 > Ivan Voras wrote: > > James Mansion wrote: > > > >> So I guess the question really is - are you saying that in this case > >> all kernel memory is non-pageable - or that you know that for the > >> IP stack and iSCSI initiator, all the memory is non-pageable? > > > > If you don't get a definite answer here, you might want to ask that > > particular questions on hackers @ freebsd.org or architecture @ > > freebsd.org to get a wider audience of people who deal with low-level > > systems like the VM. > > > > Kernel text (executable code) and kernel data (malloc, zone, and module > data segment memory) are non-pageable. Kernel stacks used to be > pageable, but there was discussion some time ago about removing that > feature and I don't recall the outcome. > > The real danger to memory deadlocks is mallocing in the I/O path. Even > though kernel memory isn't pageable, the VM may need to page out some > userland pages to satisfy a malloc. If that page-out goes through an > I/O path that also needs to do a malloc, you get a deadlock. > > The CAM layer is free of these deadlocks, as are most storage drivers. > I don't know if the iscsi-initiator driver is or not, I haven't > inspected it closely for this. the iscsi-initiator does some malloc's but very early in the initialization process. > Unfortunately, the GEOM block layer is > not free of this deadlock, so this whole discussion is mostly academic > (the GEOM problem is small and very hard to trigger since it uses the > zone allocator, but problems have been observed in real-world > situations, which is a shame). > > Scott > _______________________________________________ > 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" > From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 10 18:34:24 2007 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 0F72416A41A for ; Sat, 10 Nov 2007 18:34:24 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::5e5]) by mx1.freebsd.org (Postfix) with ESMTP id BCEE813C48A for ; Sat, 10 Nov 2007 18:34:23 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (cpe-68-175-8-11.hvc.res.rr.com [68.175.8.11]) (authenticated bits=0) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id lAAIYMFd005573 for ; Sat, 10 Nov 2007 13:34:23 -0500 (EST) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6) with ESMTP id lAAIYHJG046730 for ; Sat, 10 Nov 2007 13:34:17 -0500 (EST) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6/Submit) id lAAIYHAH046729 for freebsd-scsi@freebsd.org; Sat, 10 Nov 2007 13:34:17 -0500 (EST) (envelope-from tbohml) From: "Tuc at T-B-O-H.NET" Message-Id: <200711101834.lAAIYHAH046729@himinbjorg.tucs-beachin-obx-house.com> To: freebsd-scsi@freebsd.org Date: Sat, 10 Nov 2007 13:34:17 -0500 (EST) X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Problems with LSI MegaRAID "disappearing" 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: Sat, 10 Nov 2007 18:34:24 -0000 Hi, Last nites run of megarc showed that apparently my entire controller "disappeared". Its done this once before, and Scott Long said there was an issue addressed about it, but I don't know how... Finding Devices On Each MegaRAID Adapter... ... + Error: Failed to get DiskCapacity: Ch 0, Id 0 on Adp-0 - ********************************************************************** - Existing Logical Drive Information - By LSI Logic Corp.,USA - ********************************************************************** - [Note: For SATA-2, 4 and 6 channel controllers, please specify - Ch=0 Id=0..15 for specifying physical drive(Ch=channel, Id=Target)] - - - Logical Drive : 0( Adapter: 0 ): Status: OPTIMAL - --------------------------------------------------- - SpanDepth :01 RaidLevel: 5 RdAhead : Adaptive Cache: DirectIo - StripSz :064KB Stripes : 3 WrPolicy: WriteThru - - Logical Drive 0 : SpanLevel_0 Disks - Chnl Target StartBlock Blocks Physical Target Status - ---- ------ ---------- ------ ---------------------- - 0 00 0x00000000 0x087f9000 ONLINE - 0 01 0x00000000 0x087f9000 ONLINE - 0 02 0x00000000 0x087f9000 ONLINE + Request Sense Data: + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - HotSpare Disk at Channel No. 0 and ID No. 3 + This disk is considered UNUSABLE. + + Error: Failed to get DiskCapacity: Ch 0, Id 1 on Adp-0 + + Request Sense Data: + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + This disk is considered UNUSABLE. + + Error: Failed to get DiskCapacity: Ch 0, Id 2 on Adp-0 + + Request Sense Data: + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + This disk is considered UNUSABLE. + + Error: Failed to get DiskCapacity: Ch 0, Id 3 on Adp-0 + + Request Sense Data: + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + + This disk is considered UNUSABLE. + + Error: Failed to find configurable devices Thanks, Tuc