From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 10 10:13:54 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92FD0EAA for ; Mon, 10 Nov 2014 10:13:54 +0000 (UTC) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10F01C09 for ; Mon, 10 Nov 2014 10:13:53 +0000 (UTC) Received: from mail-wi0-f174.google.com ([209.85.212.174]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKVGCP2sSuwlfd9RiJtS8prvR85OLM6Zgt@postini.com; Mon, 10 Nov 2014 02:13:54 PST Received: by mail-wi0-f174.google.com with SMTP id d1so9904005wiv.13 for ; Mon, 10 Nov 2014 02:13:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=WxjAFMaahn7rRsjesLD1WvE0YlBgdqtENQRLWBOuLQo=; b=HQCaJJahIAqO7ozuHBs/W7JtOazU75nf5CpvG8nT7VhD31czmfgm0MplOXx9k6Epid ERcWLMuam0KGsnuwR30rzgMJKxIAJ7CX9ikfDhAw2vt7PHEK6j4KmC41sPhF1HQTHs2u +Ao1ur2OfPDLlQY0Em61vzbfGXiv9jArz2YGqPkwjfKkUStQ+vb6bi/z4a9Y9Z0NDeGd 5CttBA/YotUHaQq9NzAz3f3Y1PQs1MGMOhHwoOFg60j/5gm4UdtfL7OBRW1E21xc+FZ+ zjbKGayuCIkun+PTuHN7nZ1p9ouLV02kZJdIsnIddpRUFAb6jnhv0uJB7yqL7Vp/n6wy ALLQ== X-Gm-Message-State: ALoCoQncAyPnTBu0z0jqDLFacV5lIN6aE+rwBjQpRhg1Dauzh94pH8PeVoV65dWuSjPDvhclQdmFD+mV0IKzcxaRqfaWVme+Sw3x7++Vt6UjAiZEG1u23D8fC77htHGG6KY5HbZI23KBiTbYzKWi5Lmel3+8DzZP5w== X-Received: by 10.180.94.100 with SMTP id db4mr2418962wib.12.1415614425465; Mon, 10 Nov 2014 02:13:45 -0800 (PST) X-Received: by 10.180.94.100 with SMTP id db4mr2418923wib.12.1415614425256; Mon, 10 Nov 2014 02:13:45 -0800 (PST) From: Sibananda Sahu References: <20141107142309.GR53947@kib.kiev.ua> In-Reply-To: <20141107142309.GR53947@kib.kiev.ua> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHOFZwIN+Ws4Ocpo748IHVzw+f7fgJUf99/nErNJcA= Date: Mon, 10 Nov 2014 15:43:44 +0530 Message-ID: Subject: RE: Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb() To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-scsi@freebsd.org, Kashyap Desai X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 10:13:54 -0000 Hi Konstantin, +++Look at the code. In particular, the definition of the struct bio in sys/sys/bio.h. There, the buffer pointed by bio_data is passed if BIO_UNMAPPED flag is not set, but when the flag is set, bio_ma* fields describe an +++array of physical memory pages where the data for i/o request are scattered. The pages are not neccessary mapped into the KVA, which explains the terminology. +++The i/o stack and busdma(9) where modified to transparently handle such requests, and you correctly described the minimal changes, required from the driver side to process the unmapped requests. +++The passing of a pointer to bio instead of the pointer to buffer allows drivers to not care about mapped/not mapped requests, assuming the suitable KPI like bus_dma_load_ccb() prepares the buffer for dma +++engine of the controller. Thanks for this information. I have checked the header for the above mentioned data and understood how it happens. Further I have observed that the CAM_DATA_BIO is the case when I am reading some data out of the disk. But when I am writing some data to the disk I am getting the request via CAM_DATA_VADDR. Is the BIO meant only for READs??? Can you please put some light on this and please correct me if I have observed it wrong. Thanks, Sibananda Sahu -----Original Message----- From: Konstantin Belousov [mailto:kostikbel@gmail.com] Sent: Friday, November 07, 2014 7:53 PM To: Sibananda Sahu Cc: freebsd-scsi@freebsd.org Subject: Re: Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb() On Fri, Nov 07, 2014 at 05:07:59AM +0530, Sibananda Sahu wrote: > Hi All, > > > > I have raised this query regarding the following mail: > > https://lists.freebsd.org/pipermail/freebsd-scsi/2014-July/006407.html > > > > Where Alexander Motin talks of Unmapped I/O. > > As per his direction I have declared the below statement in my driver code: > > > > ccb->cpi.hba_misc = PIM_NOBUSRESET | PIM_UNMAPPED; > > > > Before enabling PIM_UNMAPPED I was getting the (ccb->ccb_h.flags & > CAM_DATA_MASK) as CAM_DATA_VADDR and handling accordingly. > > But after enabling PIM_UNMAPPED in cpi.hba_misc I am getting the > (ccb->ccb_h.flags & CAM_DATA_MASK) as CAM_DATA_BIO and handling the > data that comes with bus_dma_load_ccb(). Right. Look at the code. In particular, the definition of the struct bio in sys/sys/bio.h. There, the buffer pointed by bio_data is passed if BIO_UNMAPPED flag is not set, but when the flag is set, bio_ma* fields describe an array of physical memory pages where the data for i/o request are scattered. The pages are not neccessary mapped into the KVA, which explains the terminology. Thanks for this information. I have checked the header for the above mentioned data and understood how it happens. The i/o stack and busdma(9) where modified to transparently handle such requests, and you correctly described the minimal changes, required from the driver side to process the unmapped requests. The passing of a pointer to bio instead of the pointer to buffer allows drivers to not care about mapped/not mapped requests, assuming the suitable KPI like bus_dma_load_ccb() prepares the buffer for dma engine of the controller. > > > > I just did the same thing according to the mps(4) driver as referred > by Alexander Motin. > > > > So I just wanted to know what exactly happening when I am enabling the > PIM_UNMAPPED in the cpi.hba_misc field. > > And what the CAM_DATA_BIO really means in the CAM_DATA_MASK. > > > > > > It would be great idea if somebody explains what exactly happening or > at least give me some references where can I have a look and move forward. > > > > > > Thanks, > > Sibananda Sahu > _______________________________________________ > 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 Mon Nov 10 10:38:41 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75FEF31E for ; Mon, 10 Nov 2014 10:38:41 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DBD93E7C for ; Mon, 10 Nov 2014 10:38:40 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sAAAcVJD003073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Nov 2014 12:38:31 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sAAAcVJD003073 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sAAAcUB0003072; Mon, 10 Nov 2014 12:38:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 10 Nov 2014 12:38:30 +0200 From: Konstantin Belousov To: Sibananda Sahu Subject: Re: Query regarding Unmapped IO, PIM_UNMAPPED and bus_dmamap_load_ccb() Message-ID: <20141110103830.GH53947@kib.kiev.ua> References: <20141107142309.GR53947@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-scsi@freebsd.org, Kashyap Desai X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 10:38:41 -0000 On Mon, Nov 10, 2014 at 03:43:44PM +0530, Sibananda Sahu wrote: > Hi Konstantin, > > +++Look at the code. In particular, the definition of the struct bio in > sys/sys/bio.h. There, the buffer pointed by bio_data is passed if > BIO_UNMAPPED flag is not set, but when the flag is set, bio_ma* fields > describe an +++array of physical memory pages where the data for i/o > request are scattered. The pages are not neccessary mapped into the KVA, > which explains the terminology. > > +++The i/o stack and busdma(9) where modified to transparently handle such > requests, and you correctly described the minimal changes, required from > the driver side to process the unmapped requests. > +++The passing of a pointer to bio instead of the pointer to buffer allows > drivers to not care about mapped/not mapped requests, assuming the > suitable KPI like bus_dma_load_ccb() prepares the buffer for dma +++engine > of the controller. > > Thanks for this information. > I have checked the header for the above mentioned data and understood how > it happens. > > Further I have observed that the CAM_DATA_BIO is the case when I am > reading some data out of the disk. > But when I am writing some data to the disk I am getting the request via > CAM_DATA_VADDR. > Is the BIO meant only for READs??? BIOs are used both for reads and writes. Your VADDR request is some BIO as well, it was just 'disassembled' into the buffer request by some upper layer before reaching the driver. Your observation that you only get unmapped reads is due to your testing load, and is not something that system enforces. Both reads and writes may happen mapped or unmapped, driver cannot rely on absence of any specific requests. Test UFS-formatted volume on the disk handled by the driver, it will give you ample amount of unmapped reads and writes. From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 12 23:47:57 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id 86675E95; Wed, 12 Nov 2014 23:47:57 +0000 (UTC) Date: Wed, 12 Nov 2014 23:47:57 +0000 From: John To: FreeBSD-scsi Subject: LSI 9300-8e performance experiences / pcie negotiation / Down reving protocol Message-ID: <20141112234757.GA85337@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:47:57 -0000 Hi Folks, Does anyone have any experience with the LSI 9300 HBA adapter? I've been putting together a new server with a pair of these cards going into a quad-cabled SuperMicro storage enclosure and am not seeing the performance I think I should. I currently have 1 cable from each card going to each expander set. I am unable to get better than 5.5GB/sec through-put. pciconf shows the following for the cards: mpr0@pci0:2:0:0: class=0x010700 card=0x30a01000 chip=0x00971000 rev=0x02 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS3008 PCI-Express Fusion-MPT SAS-3' class = mass storage subclass = SAS bar [10] = type I/O Port, range 32, base 0x5000, size 256, enabled bar [14] = type Memory, range 64, base 0xc7500000, size 65536, enabled cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[68] = PCI-Express 2 endpoint max data 256(4096) FLR link x8(x8) speed 8.0(8.0) cap 03[d0] = VPD cap 05[a8] = MSI supports 1 message, 64 bit, vector masks cap 11[c0] = MSI-X supports 96 messages, enabled Table in map 0x14[0xe000], PBA in map 0x14[0xf000] ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0019[1e0] = PCIe Sec 1 lane errors 0 ecap 0004[1c0] = Power Budgeting 1 ecap 0016[190] = DPA 1 ecap 0010[150] = SRIOV 1 ecap 000e[148] = ARI 1 mpr1 is the same. I am curious about cap 10[68]. While the link widths and speeds show correctly, it is a pcie3 card. All firmware is up-to-date (I've actually tried all of them from 1 to 6 (no P3)). Cards are plugged into PCI-Express 3 x16 slots. From dmidecode --type 9: Designation: CPU1 SLOT3 PCI-E 3.0 X16 Type: x16 PCI Express 3 x16 3 x shelves: 24 drives ea. 72 total (da0 - da143) # camcontrol inquiry ses1 pass49: Fixed Enclosure Services SCSI-5 device pass49: Serial Number pass49: 1200.000MB/s transfers, Command Queueing Enabled # camcontrol inquiry da0 pass0: Fixed Direct Access SCSI-6 device pass0: Serial Number S3L0EENZ0000M446AG8K pass0: 1200.000MB/s transfers, Command Queueing Enabled gmultipath enabled alternating i/o paths. Booting the system with verbose enabled, I do see the following: (probe0:mpr1:0:8:0): Down reving Protocol Version from 4 to 0? It looks like 1 of these messages for every disk, coming from cam/scsi/scsi_xpt.c: if (cts->protocol_version > device->protocol_version) { if (bootverbose) { xpt_print(path, "Down reving Protocol " "Version from %d to %d?\n", cts->protocol_version, device->protocol_version); } cts->protocol_version = device->protocol_version; } If anyone has any thoughts please let me know. Thanks, John Current test: Write test files: iozone -w -+N -+u -P 0 -i 0 -+n -s 16g -r 128k -t 24 -I -F /poollsi/01.tmp ... export/import/rotate pool Read test: iozone -+N -+u -P 0 -i 1 -+n -s 16g -r 128k -t 24 -I -F /poollsi/01.tmp ... Children see throughput for 24 readers = 5481194.48 KB/sec Parent sees throughput for 24 readers = 5478389.11 KB/sec Min throughput per process = 222687.09 KB/sec Max throughput per process = 234463.22 KB/sec Avg throughput per process = 228383.10 KB/sec Min xfer = 15934592.00 KB CPU utilization: Wall time 71.607 CPU time 563.762 CPU utilization 787.30 % (out of 24 cpus) IOCFacts: mpr1: port 0xe000-0xe0ff mem 0xfbd00000-0xfbd0ffff irq 56 at device 0.0 on pci135 mpr1: IOCFacts : MsgVersion: 0x205 HeaderVersion: 0x2300 IOCNumber: 0 IOCExceptions: 0x0 MaxChainDepth: 128 NumberOfPorts: 1 RequestCredit: 10176 ProductID: 0x2221 IOCRequestFrameSize: 32 MaxInitiators: 32 MaxTargets: 1024 MaxSasExpanders: 64 MaxEnclosures: 65 HighPriorityCredit: 124 MaxReplyDescriptorPostQueueDepth: 65504 ReplyFrameSize: 32 MaxVolumes: 0 MaxDevHandle: 1128 MaxPersistentEntries: 128 mpr1: Firmware: 06.00.00.00, Driver: 05.255.05.00-fbsd mpr1: IOCCapabilities: 7a85c mpr1: attempting to allocate 1 MSI-X vectors (96 supported) msi: routing MSI-X IRQ 324 to local APIC 0 vector 121 mpr1: using IRQ 324 for MSI-X From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 15 05:50:34 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 821) id 10116A26; Sat, 15 Nov 2014 05:50:34 +0000 (UTC) Date: Sat, 15 Nov 2014 05:50:34 +0000 From: John To: FreeBSD-scsi Subject: enc@ 'path too long' sys/param.h patch Message-ID: <20141115055033.GA5740@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 05:50:34 -0000 Hi Folks, I've been booting with verbose enabled and I've been getting many msgs similar to the following: kernel: WARNING: Unable to alias diskid/MULTIPATH-S3L0EX490000S349YJZ3 to enc@n500304800169db3d/type@0/slot@8/elmdesc@Slot07/diskid/MULTIPATH-S3L0EX490000S349YJZ3 - path too long SPECNAMELEN is 63 which is too small. The following small patch and a rebuild of both world & kernel fixes the problem: Index: sys/sys/param.h =================================================================== --- sys/sys/param.h (revision 274524) +++ sys/sys/param.h (working copy) @@ -105,7 +105,7 @@ #define NOFILE OPEN_MAX /* max open files per process */ #define NOGROUP 65535 /* marker for empty group set member */ #define MAXHOSTNAMELEN 256 /* max hostname size */ -#define SPECNAMELEN 63 /* max length of devicename */ +#define SPECNAMELEN 127 /* max length of devicename */ /* More types and definitions used throughout the kernel. */ #ifdef _KERNEL The directory structure now comes up: enc@n500304800169db3d/type@0/slot@3/elmdesc@Slot02/da0 enc@n500304800169db3d/type@0/slot@3/elmdesc@Slot02/multipath/Z56 enc@n500304800169db3d/type@0/slot@3/elmdesc@Slot02/diskid/MULTIPATH-S3L03ASE0000M446F6CV However, the other disk in Z56 is not present: # gmultipath status Z56 Name Status Components multipath/Z56 OPTIMAL da0 (ACTIVE) da87 (PASSIVE) # find enc* | grep da87 # All the elements found in the current structure are under mpr0. Nothing in mpr1 is present (the 2nd channel). The shelves are quad channeled with two cables currently plugged in - so I was expecting to see two paths of disks. A second item is the symlink values are current directory only: enc@n500304800169db3d/type@0/slot@3/elmdesc@Slot02/da0 -> da0 enc@n500304800169db3d/type@0/slot@3/elmdesc@Slot02/diskid/MULTIPATH-S3L03ASE0000M446F6CV -> diskid/MULTIPATH-S3L03ASE0000M446F6CV enc@n500304800169db3d/type@0/slot@3/elmdesc@Slot02/multipath/Z56 -> multipath/Z56 Thus the entries are not usable as is. Could da0 & da87 simply both show up in the same Slot02 structure? # camcontrol smpphylist ses4 | grep da0 2 0x5000c500767baa51 (da0,pass7) # camcontrol smpphylist ses7 | grep da87 2 0x5000c500767baa51 (da87,pass94) Thoughts? Thanks! John From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 15 19:08:37 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0745424B; Sat, 15 Nov 2014 19:08:37 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B892B74; Sat, 15 Nov 2014 19:08:33 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id k14so2548344wgh.38 for ; Sat, 15 Nov 2014 11:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=nUIDpXY0pKwcvftgl7Euy6VEWJf5GysIIO1HLRs5X6g=; b=xkcYHw1lUNyRdZPkTnkMosG8dNd29djRm8v8Zk+5OU8Nz16Aa7wNMSBih83pXWKTly PNU0B8hS+sUcH6lx74KFZoDOLaQvV9UMidMnnGTJeupPZHGvLGlcyH66R2J01SI2KKYA xcljR77blPuBUWe0zSzxrw4IMvlu8vySdc6OCg0f6m/MjSiS5W0VI1dwZ7mrQPbN8dlm zXrPuTlnRs+yHs2ERMgR2Y/sFt22kY3AalP2llNfiWqkPJ3DfufFyeJ0uVkNLqJOI0v6 Ih1YJ35NYPUhK43Rp8dCgR0Va3G5gZoxeHI/FP4Z7jhcEIFmLovFUqSa02Hj71Y9hJJb QpRg== MIME-Version: 1.0 X-Received: by 10.194.94.132 with SMTP id dc4mr25903940wjb.56.1416078511948; Sat, 15 Nov 2014 11:08:31 -0800 (PST) Received: by 10.217.106.69 with HTTP; Sat, 15 Nov 2014 11:08:31 -0800 (PST) Reply-To: pechter@gmail.com Date: Sat, 15 Nov 2014 14:08:31 -0500 Message-ID: Subject: Anyone working on the Marvell 88se64xx sas/sata chip driver? From: Bill Pechter To: FreeBSD-hardware@freebsd.org, freebsd-scsi@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 19:08:37 -0000 I've got a really nice Lenovo D20 that I need to share between FreeBSD/Linux and Windows Server 2012 for some testing. I've got the Marvell driver up on Linux and Windows but it appears that I have to move the SATA drives to the Intel SATA chips if I want to share between FreeBSD/Linux/Windows. I hate to have to rebuild this all... Is there a test driver for the 88se63xx/64xx drivers available in 10.1 or -stable? Bill -- d|i|g|i|t|a|l had it THEN. Don't you wish you could still buy it now! pechter-at-gmail.com