From owner-freebsd-scsi@FreeBSD.ORG Sun Mar 4 07:36:03 2012 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 200BD1065672 for ; Sun, 4 Mar 2012 07:36:03 +0000 (UTC) (envelope-from bsalinux@gmail.com) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx1.freebsd.org (Postfix) with ESMTP id B704F8FC08 for ; Sun, 4 Mar 2012 07:36:02 +0000 (UTC) Received: by qcsq13 with SMTP id q13so1257556qcs.17 for ; Sat, 03 Mar 2012 23:35:56 -0800 (PST) Received-SPF: pass (google.com: domain of bsalinux@gmail.com designates 10.224.100.197 as permitted sender) client-ip=10.224.100.197; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bsalinux@gmail.com designates 10.224.100.197 as permitted sender) smtp.mail=bsalinux@gmail.com; dkim=pass header.i=bsalinux@gmail.com Received: from mr.google.com ([10.224.100.197]) by 10.224.100.197 with SMTP id z5mr6540429qan.61.1330846556214 (num_hops = 1); Sat, 03 Mar 2012 23:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2Q/zob3d8896Hi7FQX9y/k8ddlM5DMEwxdxwZuUCWWw=; b=s+oGOr8LJhQk3jRNQB/mQutK30tRm7BwIirbfQ98DamsUjawSGybOEPX+3nHKPdNGF ME1jmDpnI4s/Z+VUuuHCGKwO7wAtFuEC/ze5stdxgm2yps0zlyqbqTBioNdu+t4fV0dI LPizdppXM+Gks2plGk30VFXZhOSDTs0kU6njljQWzEE8DTdzVGiD9WvU5XL+ESsE8G7m khbCBUspOscwRojq4Q8rQkUSwJ1qlHVBQhKK8qSnOFEAnM2ibbN9umAOdFZhxA4QjfJE CwI/Tf2tRb5tDS8AjmJQFtEQEV29O7+H7te70178bM7HBLG1TSLhYErQ7krJtQbtNmI2 FJ1A== MIME-Version: 1.0 Received: by 10.224.100.197 with SMTP id z5mr5559793qan.61.1330846556090; Sat, 03 Mar 2012 23:35:56 -0800 (PST) Received: by 10.229.211.80 with HTTP; Sat, 3 Mar 2012 23:35:56 -0800 (PST) Date: Sat, 3 Mar 2012 23:35:56 -0800 Message-ID: From: "bsalinux@gmail.com" To: freebsd-scsi@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: HP SmartArray P400 with 1TB Drives 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: Sun, 04 Mar 2012 07:36:03 -0000 Hi, Are there any concerns using 8x 1TB SAS drives with HP P400 controller running raid5. I would appreciate any usage reports or comments if you are running similar configuration. Thanks. From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 5 11:07:18 2012 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 5A37C1065670 for ; Mon, 5 Mar 2012 11:07:18 +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 4876E8FC13 for ; Mon, 5 Mar 2012 11:07:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q25B7ItO035018 for ; Mon, 5 Mar 2012 11:07:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q25B7HDe035014 for freebsd-scsi@FreeBSD.org; Mon, 5 Mar 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Mar 2012 11:07:17 GMT Message-Id: <201203051107.q25B7HDe035014@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 Mar 2012 11:07:18 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/163713 scsi [aic7xxx] [patch] Add Adaptec29329LPE to aic79xx_pci.c o kern/162256 scsi [mpt] QUEUE FULL EVENT and 'mpt_cam_event: 0x0' o kern/161809 scsi [cam] [patch] set kern.cam.boot_delay via build option o kern/159412 scsi [ciss] 7.3 RELEASE: ciss0 ADAPTER HEARTBEAT FAILED err o kern/157770 scsi [iscsi] [panic] iscsi_initiator panic o kern/154432 scsi [xpt] run_interrupt_driven_hooks: still waiting after o kern/153514 scsi [cam] [panic] CAM related panic o kern/153361 scsi [ciss] Smart Array 5300 boot/detect drive problem o kern/152250 scsi [ciss] [patch] Kernel panic when hw.ciss.expose_hidden o kern/151564 scsi [ciss] ciss(4) should increase CISS_MAX_LOGICAL to 10 o docs/151336 scsi Missing documentation of scsi_ and ata_ functions in c s kern/149927 scsi [cam] hard drive not stopped before removing power dur o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/134488 scsi [mpt] MPT SCSI driver probes max. 8 LUNs per device o kern/132250 scsi [ciss] ciss driver does not support more then 15 drive o kern/132206 scsi [mpt] system panics on boot when mirroring and 2nd dri o kern/130621 scsi [mpt] tranfer rate is inscrutable slow when use lsi213 o kern/129602 scsi [ahd] ahd(4) gets confused and wedges SCSI bus o kern/128452 scsi [sa] [panic] Accessing SCSI tape drive randomly crashe o kern/128245 scsi [scsi] "inquiry data fails comparison at DV1 step" [re o kern/127927 scsi [isp] isp(4) target driver crashes kernel when set up o kern/127717 scsi [ata] [patch] [request] - support write cache toggling o kern/123674 scsi [ahc] ahc driver dumping o kern/123520 scsi [ahd] unable to boot from net while using ahd o sparc/121676 scsi [iscsi] iscontrol do not connect iscsi-target on sparc o kern/120487 scsi [sg] scsi_sg incompatible with scanners o kern/120247 scsi [mpt] FreeBSD 6.3 and LSI Logic 1030 = only 3.300MB/s o kern/114597 scsi [sym] System hangs at SCSI bus reset with dual HBAs o kern/110847 scsi [ahd] Tyan U320 onboard problem with more than 3 disks o kern/99954 scsi [ahc] reading from DVD failes on 6.x [regression] o kern/92798 scsi [ahc] SCSI problem with timeouts o kern/90282 scsi [sym] SCSI bus resets cause loss of ch device o kern/76178 scsi [ahd] Problem with ahd and large SCSI Raid system o kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5.3 s kern/61165 scsi [panic] kernel page fault after calling cam_send_ccb o kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C810 under load o kern/60598 scsi wire down of scsi devices conflicts with config s kern/57398 scsi [mly] Current fails to install on mly(4) based RAID di o kern/52638 scsi [panic] SCSI U320 on SMP server won't run faster than o kern/44587 scsi dev/dpt/dpt.h is missing defines required for DPT_HAND o kern/39388 scsi ncr/sym drivers fail with 53c810 and more than 256MB m o kern/35234 scsi World access to /dev/pass? (for scanner) requires acce 48 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 5 18:59:10 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 420521065676 for ; Mon, 5 Mar 2012 18:59:10 +0000 (UTC) (envelope-from i@levsha.me) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id EB8908FC16 for ; Mon, 5 Mar 2012 18:59:09 +0000 (UTC) Received: from [95.132.152.101] (helo=laptop.levsha.me) by expo.ukrweb.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S4csU-000HTN-KX; Mon, 05 Mar 2012 20:43:25 +0200 Received: from levsha by laptop.levsha.me with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S4csM-00016a-6A; Mon, 05 Mar 2012 20:43:14 +0200 Date: Mon, 5 Mar 2012 20:43:14 +0200 From: Mykola Dzham To: "Desai, Kashyap" Message-ID: <20120305184313.GA3215@laptop.levsha.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Mykola Dzham X-SA-Exim-Connect-IP: 95.132.152.101 X-SA-Exim-Mail-From: i@levsha.me X-SA-Exim-Scanned: No (on expo.ukrweb.net); SAEximRunCond expanded to false Cc: freebsd-scsi@freebsd.org Subject: Can't load mps as module with custom kernel 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 Mar 2012 18:59:10 -0000 Hi! My FreeBSD box running on custom kernel config, without device mps When i attempt to load mps as module: # sudo kldload mps kldload: can't load mps: Exec format error Mar 5 09:33:35 laptop kernel: link_elf_obj: symbol xpt_freeze_simq undefined Mar 5 09:33:35 laptop kernel: linker_load_file: Unsupported file type # uname -a FreeBSD laptop.levsha.me 10.0-CURRENT FreeBSD 10.0-CURRENT #48 r232475M: Mon Mar 5 09:47:35 EET 2012 root@laptop.levsha.me:/usr/obj/usr/src/sys/LEVSHA amd64 Fix: Index: sys/dev/mps/mps_pci.c =================================================================== --- sys/dev/mps/mps_pci.c (revision 232475) +++ sys/dev/mps/mps_pci.c (working copy) @@ -87,6 +87,7 @@ static devclass_t mps_devclass; DRIVER_MODULE(mps, pci, mps_pci_driver, mps_devclass, 0, 0); +MODULE_DEPEND(mps, cam, 1, 1, 1); struct mps_ident { uint16_t vendor; -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 5 22:25:54 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 040B4106564A for ; Mon, 5 Mar 2012 22:25:54 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id B21B88FC0A for ; Mon, 5 Mar 2012 22:25:53 +0000 (UTC) Received: by ghrr20 with SMTP id r20so2227189ghr.13 for ; Mon, 05 Mar 2012 14:25:53 -0800 (PST) Received-SPF: pass (google.com: domain of chuck@tuffli.net designates 10.60.3.9 as permitted sender) client-ip=10.60.3.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of chuck@tuffli.net designates 10.60.3.9 as permitted sender) smtp.mail=chuck@tuffli.net Received: from mr.google.com ([10.60.3.9]) by 10.60.3.9 with SMTP id 9mr8237832oey.49.1330986352990 (num_hops = 1); Mon, 05 Mar 2012 14:25:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.3.9 with SMTP id 9mr7268730oey.49.1330986352919; Mon, 05 Mar 2012 14:25:52 -0800 (PST) Received: by 10.60.67.226 with HTTP; Mon, 5 Mar 2012 14:25:52 -0800 (PST) Date: Mon, 5 Mar 2012 14:25:52 -0800 Message-ID: From: Chuck Tuffli To: freebsd-scsi Content-Type: multipart/mixed; boundary=e89a8f83ae2bc442c104ba866897 X-Gm-Message-State: ALoCoQnAWTQP97hcgOSDTV9/6gg8ZLBOcNOAQOe8Zn9fAoQLHNky6T7l3BDMD9BPPqrT/viUVyuV X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [patch] CTL not setting CAM_DIR_NONE 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 Mar 2012 22:25:54 -0000 --e89a8f83ae2bc442c104ba866897 Content-Type: text/plain; charset=ISO-8859-1 When the front end start (a.k.a. ctlfestart) sends back status without data, it should set CAM_DIR_NONE in the CTIO flags. ---chuck --e89a8f83ae2bc442c104ba866897-- From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 5 22:31:12 2012 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 DADB5106566C for ; Mon, 5 Mar 2012 22:31:12 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6EF8FC0A for ; Mon, 5 Mar 2012 22:31:12 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q25MVBVk027452; Mon, 5 Mar 2012 15:31:11 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q25MVBxo027451; Mon, 5 Mar 2012 15:31:11 -0700 (MST) (envelope-from ken) Date: Mon, 5 Mar 2012 15:31:11 -0700 From: "Kenneth D. Merry" To: Chuck Tuffli Message-ID: <20120305223111.GA26394@nargothrond.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-scsi Subject: Re: [patch] CTL not setting CAM_DIR_NONE 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 Mar 2012 22:31:12 -0000 On Mon, Mar 05, 2012 at 14:25:52 -0800, Chuck Tuffli wrote: > When the front end start (a.k.a. ctlfestart) sends back status without > data, it should set CAM_DIR_NONE in the CTIO flags. I don't see the patch... Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 5 22:44:20 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFBB3106566C for ; Mon, 5 Mar 2012 22:44:20 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 92E798FC16 for ; Mon, 5 Mar 2012 22:44:20 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so6980904obb.13 for ; Mon, 05 Mar 2012 14:44:20 -0800 (PST) Received-SPF: pass (google.com: domain of chuck@tuffli.net designates 10.182.54.114 as permitted sender) client-ip=10.182.54.114; Authentication-Results: mr.google.com; spf=pass (google.com: domain of chuck@tuffli.net designates 10.182.54.114 as permitted sender) smtp.mail=chuck@tuffli.net Received: from mr.google.com ([10.182.54.114]) by 10.182.54.114 with SMTP id i18mr8710284obp.49.1330987460108 (num_hops = 1); Mon, 05 Mar 2012 14:44:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr7670305obp.49.1330987460023; Mon, 05 Mar 2012 14:44:20 -0800 (PST) Received: by 10.60.67.226 with HTTP; Mon, 5 Mar 2012 14:44:19 -0800 (PST) In-Reply-To: <20120305223111.GA26394@nargothrond.kdm.org> References: <20120305223111.GA26394@nargothrond.kdm.org> Date: Mon, 5 Mar 2012 14:44:19 -0800 Message-ID: From: Chuck Tuffli To: "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmIR2hjkUr1jnmP883rGACCTzo+gH2MWYmSt6QcdPLrMHOLEKwuPW9tqeeEy2Y0zZgmi2Jw Cc: freebsd-scsi Subject: Re: [patch] CTL not setting CAM_DIR_NONE 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 Mar 2012 22:44:20 -0000 On Mon, Mar 5, 2012 at 2:31 PM, Kenneth D. Merry wrote: > On Mon, Mar 05, 2012 at 14:25:52 -0800, Chuck Tuffli wrote: >> When the front end start (a.k.a. ctlfestart) sends back status without >> data, it should set CAM_DIR_NONE in the CTIO flags. > > I don't see the patch... Sorry about that. Try https://gist.github.com/1981677 ---chuck From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 5 22:46:53 2012 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 95539106564A for ; Mon, 5 Mar 2012 22:46:53 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 242B68FC08 for ; Mon, 5 Mar 2012 22:46:53 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so6984541obb.13 for ; Mon, 05 Mar 2012 14:46:52 -0800 (PST) Received-SPF: pass (google.com: domain of chuck@tuffli.net designates 10.182.52.104 as permitted sender) client-ip=10.182.52.104; Authentication-Results: mr.google.com; spf=pass (google.com: domain of chuck@tuffli.net designates 10.182.52.104 as permitted sender) smtp.mail=chuck@tuffli.net Received: from mr.google.com ([10.182.52.104]) by 10.182.52.104 with SMTP id s8mr1856620obo.59.1330987612848 (num_hops = 1); Mon, 05 Mar 2012 14:46:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.52.104 with SMTP id s8mr1632686obo.59.1330987612790; Mon, 05 Mar 2012 14:46:52 -0800 (PST) Received: by 10.60.67.226 with HTTP; Mon, 5 Mar 2012 14:46:52 -0800 (PST) Date: Mon, 5 Mar 2012 14:46:52 -0800 Message-ID: From: Chuck Tuffli To: freebsd-scsi Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmrOaH5oylsregyhARarQdOfx80ksNZTU+pW2vhjSCin+2BiNj8+uuSimvPzISQXt2kDuNd Subject: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 22:46:53 -0000 Currently, the CTL responds to INQUIRY commands targeted at invalid LUNs by returning valid data with the peripheral qualifier set to LU OFFLINE. This patch instead returns a check condition with LU NOT READY. Linux initiators see the LU OFFLINE and start creating SG devices, but are not able to finish. The offline also causes them to keep probing LUNs. https://gist.github.com/1981701 ---chuck From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 6 00:17:33 2012 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 5AFF3106564A for ; Tue, 6 Mar 2012 00:17:33 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 23BB28FC19 for ; Tue, 6 Mar 2012 00:17:33 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q260HWGl038266; Mon, 5 Mar 2012 17:17:32 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q260HV8B038265; Mon, 5 Mar 2012 17:17:31 -0700 (MST) (envelope-from ken) Date: Mon, 5 Mar 2012 17:17:31 -0700 From: "Kenneth D. Merry" To: Chuck Tuffli Message-ID: <20120306001731.GA38229@nargothrond.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-scsi Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 00:17:33 -0000 On Mon, Mar 05, 2012 at 14:46:52 -0800, Chuck Tuffli wrote: > Currently, the CTL responds to INQUIRY commands targeted at invalid > LUNs by returning valid data with the peripheral qualifier set to LU > OFFLINE. This patch instead returns a check condition with LU NOT > READY. > > Linux initiators see the LU OFFLINE and start creating SG devices, but > are not able to finish. The offline also causes them to keep probing > LUNs. Linux used to behave properly. What version are you testing with? Returning a check condition is not correct according to the spec. This is from SPC-4 (r31): "In response to an INQUIRY command received by an incorrect logical unit, the SCSI target device shall return the INQUIRY data with the peripheral qualifier set to the value defined in 6.4.2. The INQUIRY command shall return CHECK CONDITION status only when the device server is unable to return the requested INQUIRY data." Since CTL can support a LUN at the requested address, but there isn't one there, it returns OFFLINE status. They should be issuing a REPORT LUNs and then probe the LUNs that are returned... Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 6 02:45:27 2012 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 C544C106566C for ; Tue, 6 Mar 2012 02:45:27 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 92E148FC20 for ; Tue, 6 Mar 2012 02:45:27 +0000 (UTC) Received: from [192.168.135.100] (c-76-126-166-136.hsd1.ca.comcast.net [76.126.166.136]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q262jKQe015175 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 5 Mar 2012 18:45:21 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4F557A3C.4080100@feral.com> Date: Mon, 05 Mar 2012 18:45:16 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <20120306001731.GA38229@nargothrond.kdm.org> In-Reply-To: <20120306001731.GA38229@nargothrond.kdm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Mon, 05 Mar 2012 18:45:21 -0800 (PST) Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 02:45:27 -0000 On 3/5/2012 4:17 PM, Kenneth D. Merry wrote: > On Mon, Mar 05, 2012 at 14:46:52 -0800, Chuck Tuffli wrote: >> Currently, the CTL responds to INQUIRY commands targeted at invalid >> LUNs by returning valid data with the peripheral qualifier set to LU >> OFFLINE. This patch instead returns a check condition with LU NOT >> READY. >> >> Linux initiators see the LU OFFLINE and start creating SG devices, but >> are not able to finish. The offline also causes them to keep probing >> LUNs. > Linux used to behave properly. What version are you testing with? > > Returning a check condition is not correct according to the spec. This is > from SPC-4 (r31): > > \ Ken (and t10) is right > Since CTL can support a LUN at the requested address, but there isn't one > there, it returns OFFLINE status. > > They should be issuing a REPORT LUNs and then probe the LUNs that are > returned... > > "They"... would that be FreeBSD which is timid to the point of frigidity on this topic? From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 6 06:52:08 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8826B1065675 for ; Tue, 6 Mar 2012 06:52:08 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 612D28FC1D for ; Tue, 6 Mar 2012 06:52:08 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1S4o0R-00012h-7y for freebsd-scsi@freebsd.org; Mon, 05 Mar 2012 22:36:19 -0800 Date: Mon, 5 Mar 2012 22:36:19 -0800 (PST) From: timp To: freebsd-scsi@freebsd.org Message-ID: <1331015779239-5540038.post@n5.nabble.com> In-Reply-To: <20120305184313.GA3215@laptop.levsha.me> References: <20120305184313.GA3215@laptop.levsha.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Can't load mps as module with custom kernel 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 Mar 2012 06:52:08 -0000 There are some more scsi modules that have such bug http://lists.freebsd.org/pipermail/freebsd-stable/2012-March/066607.html -- View this message in context: http://freebsd.1045724.n5.nabble.com/Can-t-load-mps-as-module-with-custom-kernel-tp5538504p5540038.html Sent from the freebsd-scsi mailing list archive at Nabble.com. From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 6 17:40:51 2012 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 537BD106564A; Tue, 6 Mar 2012 17:40:51 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by mx1.freebsd.org (Postfix) with ESMTP id B715F8FC08; Tue, 6 Mar 2012 17:40:50 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT1ZMGxZlY9K23f3t7DRI+8hIxPed/1Yp@postini.com; Tue, 06 Mar 2012 09:40:50 PST Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 12:46:03 -0500 Received: from inbexch01.lsi.com (135.36.98.37) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 6 Mar 2012 12:40:43 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch01.lsi.com ([135.36.98.37]) with mapi; Tue, 6 Mar 2012 23:10:39 +0530 From: "Desai, Kashyap" To: Mykola Dzham Date: Tue, 6 Mar 2012 23:10:37 +0530 Thread-Topic: Can't load mps as module with custom kernel Thread-Index: Acz6/95Ip9Rqs5BSRpWQBpTZMenJoQAwEqpg Message-ID: References: <20120305184313.GA3215@laptop.levsha.me> In-Reply-To: <20120305184313.GA3215@laptop.levsha.me> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" , "Kenneth D. Merry" , "McConnell, Stephen" Subject: RE: Can't load mps as module with custom kernel 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 Mar 2012 17:40:51 -0000 I agree with the proposed fix. Adding Ken to pick this for upstream commit. ` Kashyap > -----Original Message----- > From: Mykola Dzham [mailto:i@levsha.me] > Sent: Tuesday, March 06, 2012 12:13 AM > To: Desai, Kashyap > Cc: freebsd-scsi@freebsd.org > Subject: Can't load mps as module with custom kernel >=20 > Hi! > My FreeBSD box running on custom kernel config, without device mps > When i attempt to load mps as module: >=20 > # sudo kldload mps > kldload: can't load mps: Exec format error >=20 > Mar 5 09:33:35 laptop kernel: link_elf_obj: symbol xpt_freeze_simq > undefined > Mar 5 09:33:35 laptop kernel: linker_load_file: Unsupported file type >=20 > # uname -a > FreeBSD laptop.levsha.me 10.0-CURRENT FreeBSD 10.0-CURRENT #48 r232475M: > Mon Mar 5 09:47:35 EET 2012 > root@laptop.levsha.me:/usr/obj/usr/src/sys/LEVSHA amd64 >=20 > Fix: >=20 > Index: sys/dev/mps/mps_pci.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/mps/mps_pci.c (revision 232475) > +++ sys/dev/mps/mps_pci.c (working copy) > @@ -87,6 +87,7 @@ >=20 > static devclass_t mps_devclass; > DRIVER_MODULE(mps, pci, mps_pci_driver, mps_devclass, 0, 0); > +MODULE_DEPEND(mps, cam, 1, 1, 1); >=20 > struct mps_ident { > uint16_t vendor; >=20 > -- > LEFT-(UANIC|RIPE) > JID: levsha@jabber.net.ua > PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 00:30:23 2012 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 9E2471065678 for ; Wed, 7 Mar 2012 00:30:23 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6696B8FC1D for ; Wed, 7 Mar 2012 00:30:23 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so8920399obb.13 for ; Tue, 06 Mar 2012 16:30:22 -0800 (PST) Received-SPF: pass (google.com: domain of chuck@tuffli.net designates 10.182.54.114 as permitted sender) client-ip=10.182.54.114; Authentication-Results: mr.google.com; spf=pass (google.com: domain of chuck@tuffli.net designates 10.182.54.114 as permitted sender) smtp.mail=chuck@tuffli.net Received: from mr.google.com ([10.182.54.114]) by 10.182.54.114 with SMTP id i18mr10621102obp.49.1331080222902 (num_hops = 1); Tue, 06 Mar 2012 16:30:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr9315365obp.49.1331080222821; Tue, 06 Mar 2012 16:30:22 -0800 (PST) Received: by 10.60.67.226 with HTTP; Tue, 6 Mar 2012 16:30:22 -0800 (PST) In-Reply-To: <20120306001731.GA38229@nargothrond.kdm.org> References: <20120306001731.GA38229@nargothrond.kdm.org> Date: Tue, 6 Mar 2012 16:30:22 -0800 Message-ID: From: Chuck Tuffli To: "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnmqa/K0UH7uMCHX2C9fV7o3JQpVmGl1AGiT2gvPegIwozaWSJdytbXM+3ytp+qIF+Pe9lW Cc: freebsd-scsi Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 00:30:23 -0000 On Mon, Mar 5, 2012 at 4:17 PM, Kenneth D. Merry wrote: > On Mon, Mar 05, 2012 at 14:46:52 -0800, Chuck Tuffli wrote: >> Currently, the CTL responds to INQUIRY commands targeted at invalid >> LUNs by returning valid data with the peripheral qualifier set to LU >> OFFLINE. This patch instead returns a check condition with LU NOT >> READY. >> >> Linux initiators see the LU OFFLINE and start creating SG devices, but >> are not able to finish. The offline also causes them to keep probing >> LUNs. > > Linux used to behave properly. =A0What version are you testing with? RHEL 6.1 > Returning a check condition is not correct according to the spec. =A0This= is > from SPC-4 (r31): > > "In response to an INQUIRY command received by an incorrect logical unit, > the SCSI target device shall return the INQUIRY data with the peripheral > qualifier set to the value defined in 6.4.2. The INQUIRY command shall > return CHECK CONDITION status only when the device server is unable to > return the requested INQUIRY data." You are correct, so I agree the patch I submitted yesterday is wrong, but := ) > Since CTL can support a LUN at the requested address, but there isn't one > there, it returns OFFLINE status. this offline status causes Linux to create 255 sg additional devices. While this isn't directly a CTL problem, I'm sure I will end up having to explain why this happens more than once and would rather head off the problem. Would you be willing to consider changing the returned peripheral qualifier from (SID_QUAL_LU_OFFLINE << 5) | T_DIRECT to (SID_QUAL_BAD_LU << 5) | T_NODEVICE ? Linux seems happier with this FWIW. > They should be issuing a REPORT LUNs and then probe the LUNs that are > returned... Linux does issue REPORT LUNs, but most of the time, this gets check-conditioned with illegal request, overlapped commands attempted. ---chuck From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 17:45:56 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 30BEF106566B for ; Wed, 7 Mar 2012 17:45:56 +0000 (UTC) (envelope-from Kashyap.Desai@lsi.com) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4DB8FC12 for ; Wed, 7 Mar 2012 17:45:55 +0000 (UTC) Received: from paledge01.lsi.com ([192.19.193.42]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKT1eezFgpn+kOWJbYq61N5Lhvo8RQJDLu@postini.com; Wed, 07 Mar 2012 09:45:55 PST Received: from PALCAS01.lsi.com (128.94.213.117) by PALEDGE01.lsi.com (192.19.193.42) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 7 Mar 2012 12:49:54 -0500 Received: from inbexch02.lsi.com (135.36.98.40) by PALCAS01.lsi.com (128.94.213.117) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 7 Mar 2012 12:44:37 -0500 Received: from inbmail01.lsi.com ([135.36.98.64]) by inbexch02.lsi.com ([135.36.98.40]) with mapi; Wed, 7 Mar 2012 23:14:33 +0530 From: "Desai, Kashyap" To: "dgilbert@interlog.com" , Jason Wolfe Date: Wed, 7 Mar 2012 23:14:29 +0530 Thread-Topic: LSI2008 controller clobbers first disk with new LSI mps driver Thread-Index: Acz1qVrkiusUZ1ojROe2toFMjfTklwBVq20wAWJDjWA= Message-ID: References: <4F450814.4020100@interlog.com> <4F4C14A8.3050105@interlog.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-scsi@freebsd.org" , "McConnell, Stephen" Subject: RE: LSI2008 controller clobbers first disk with new LSI mps driver 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 Mar 2012 17:45:56 -0000 Jason, We discuss this issue with our architect and he has strong recommendation n= ot to provide any work-around where Enclosure configuration is not correct. Similar issue was reported by other customer sometimes back and they have a= lso configured their Enclosure to resolve this issue. "The enclosure configuration needs to be fixed so it advertises enough slot= s (phys disks + num of SES devices) and it places the SES devices (assigned= slot numbers) above the physical disks." ` Kashyap > -----Original Message----- > From: Desai, Kashyap > Sent: Wednesday, February 29, 2012 10:08 PM > To: 'dgilbert@interlog.com'; Jason Wolfe > Cc: freebsd-scsi@freebsd.org; McConnell, Stephen > Subject: RE: LSI2008 controller clobbers first disk with new LSI mps > driver >=20 > Hi Jason, >=20 > I have started discussion with LSI internal folks to get better clarity > on this issue. Since our key person is on vacation, we may get clarity > on this next week. > I cannot provide some temporary workaround in upstream(because this is > against our design), but if you want to use for your environment, I can > provide you some temporary patch. >=20 > Doug, >=20 > Thanks for providing your view and I have convey this to our architect. >=20 > ~ Kashyap >=20 > > -----Original Message----- > > From: Douglas Gilbert [mailto:dgilbert@interlog.com] > > Sent: Tuesday, February 28, 2012 5:11 AM > > To: Jason Wolfe > > Cc: Desai, Kashyap; freebsd-scsi@freebsd.org; McConnell, Stephen > > Subject: Re: LSI2008 controller clobbers first disk with new LSI mps > > driver > > > > On 12-02-27 02:59 PM, Jason Wolfe wrote: > > > On Wed, Feb 22, 2012 at 9:11 AM, Desai, > Kashyap > > wrote: > > >> > > >> > > >>> -----Original Message----- > > >>> From: Douglas Gilbert [mailto:dgilbert@interlog.com] > > >>> Sent: Wednesday, February 22, 2012 8:52 PM > > >>> To: Desai, Kashyap > > >>> Cc: Jason Wolfe; freebsd-scsi@freebsd.org; McConnell, Stephen > > >>> Subject: Re: LSI2008 controller clobbers first disk with new LSI > mps > > >>> driver > > >>> > > >>> On 12-02-22 03:39 AM, Desai, Kashyap wrote: > > >>>> Here is a possible root cause of this issue. > > >>>> > > >>>> Enclosure which you are using in your setup (might be) not > > configured > > >>> properly. > > >>>> > > >>>> You have Enclosure with 12 Slots + 1 SES Device. > > >>>> See below detail from the log. > > >>>> > > >>>> EventDataLength: 5 > > >>>> AckRequired: 0 > > >>>> Event: SasEnclDeviceStatusChange (0x1d) > > >>>> EventContext: 0x0 > > >>>> EnclosureHandle: 0x2 > > >>>> ReasonCode: Added > > >>>> PhysicalPort: 0 > > >>>> NumSlots: 13 > > >>>> StartSlot: 0 > > >>>> PhyBits: 0xff > > >>>> > > >>>> StartSlot is 0 in this case. > > >>>> Correct behavior should be each device on your enclosure must > have > > >>> different slot number starting from 0 till 12. > > >>>> I have doubt that SES device has not configured well and it is > > using > > >>> slot-0 as default. This can create issue for actual device which > is > > >>> connected to slot-0. > > >>>> So In your setup you will have slot-0 till slot-11 assigned for > > actual > > >>> Phys of your enclosures and again slot-0 is assigned for SES > device > > >>> instead of Slot-12. > > >>> > > >>> No. SAS-2 expanders typically have an integral SES device on an > > >>> expander _virtual_ phy (see SMP DISCOVER (LIST) response). Once > > >>> you see that virtual phy flag the slot number is irrelevant. > > >> > > >> Doug, > > >> > > >> I need some more info so that I can understand your point better. > > >> > > >> I have one Enclosure setup on FreeBSD. Here is smp_discover output. > > (smp_discover_list is failing for me) > > >> > > >> phy 0: inaccessible (phy vacant) > > >> phy 1: inaccessible (phy vacant) > > >> phy 2: inaccessible (phy vacant) > > >> phy 3: inaccessible (phy vacant) > > >> phy 4:S:attached:[500605b012345888:03 i(SSP+STP+SMP)] 6 Gbps > > >> phy 5:S:attached:[500605b012345888:02 i(SSP+STP+SMP)] 6 Gbps > > >> phy 6:S:attached:[500605b012345888:01 i(SSP+STP+SMP)] 6 Gbps > > >> phy 7:S:attached:[500605b012345888:00 i(SSP+STP+SMP)] 6 Gbps > > >> phy 12:D:attached:[5000c5003bc2c389:00 t(SSP)] 6 Gbps > > >> phy 13:D:attached:[500000e116ee91e2:00 t(SSP)] 6 Gbps > > >> phy 14:D:attached:[5000c5003bc308e5:00 t(SSP)] 6 Gbps > > >> phy 15:D:attached:[5000c5003bc2f0d1:00 t(SSP)] 6 Gbps > > >> phy 16:D:attached:[5000c5003bc2ff3d:00 t(SSP)] 6 Gbps > > >> phy 17:D:attached:[5000c5003bae5fdd:00 t(SSP)] 6 Gbps > > >> phy 18:D:attached:[5000c5003bae5eb1:00 t(SSP)] 6 Gbps > > >> phy 19:D:attached:[5000c5003bc2d135:00 t(SSP)] 6 Gbps > > >> phy 20:D:attached:[5000c5003baea36d:00 t(SSP)] 6 Gbps > > >> phy 21:D:attached:[5000c5003bc2a8c9:00 t(SSP)] 6 Gbps > > >> phy 22:D:attached:[5000c5003bc237a9:00 t(SSP)] 6 Gbps > > >> phy 23:D:attached:[5000c5003bc2cec1:00 t(SSP)] 6 Gbps > > >> phy 24:D:attached:[500000e01d92cb52:00 t(SSP)] 3 Gbps > > >> phy 25:D:attached:[500000e01d74cfb2:00 t(SSP)] 3 Gbps > > >> phy 26:D:attached:[500000e01d656052:00 t(SSP)] 3 Gbps > > >> phy 27:D:attached:[500000e01d7cad52:00 t(SSP)] 3 Gbps > > >> phy 28:D:attached:[500c04f2b64cdd1c:00 t(SATA)] 3 Gbps > > >> phy 29:D:attached:[500c04f2b64cdd1d:00 t(SATA)] 3 Gbps > > >> phy 30:D:attached:[500000e01d73c262:00 t(SSP)] 3 Gbps > > >> phy 31:D:attached:[500000e01d536b22:00 t(SSP)] 3 Gbps > > >> phy 32:D:attached:[500000e01d92cab2:00 t(SSP)] 3 Gbps > > >> phy 33:D:attached:[500000e01afd8792:00 t(SSP)] 3 Gbps > > >> phy 34:D:attached:[5000c5003bc30301:00 t(SSP)] 6 Gbps > > >> phy 35:D:attached:[5000c5003bb09a69:00 t(SSP)] 6 Gbps > > >> phy 36:D:attached:[500c04f2b64cdd3d:00 V i(SSP) t(SSP)] 6 > Gbps<- > > -- This has virtual phy set. > > >> > > >> What I understood from your explanation is if we have virt_phy > field > > set, we should not trust slot for that entry. > > >> You are suggesting to use phy index instead of slot. Just for info: > > But how to see Slot details mapping with phy ? > > > > Kashyap, > > I haven't written a SAS discover algorithm but there > > must be plenty of examples out there. One way to do it > > is to find all the phy_ids attached to targets, in this > > case there are SAS (SSP) and SATA targets. Each SATA > > target phy_id will correspond to one SATA disk (or could be an > > ATAPI device (e.g. DVD/BD player)). The SSP targets are a > > bit trickier because two (or more) phys could be connected > > to the same target (either a wide port or multiple (target) > > ports). With a wide port each component phy has the same > > attached SAS address (so above you have a wide initiator > > port (phy ids 4,5,6,7) but no wide target ports). If a > > SAS disk has multiple target ports connected, FreeBSD > > probably has a device node for each. So for each SCSI (SSP) > > target port you need a REPORT LUNS command issued on LUN 0 > > (or the REPORT LUNS well known logical unit) to find the > > LUs it contains. A device node is created for each LU. > > > > Anyway I'm sure many folks in LSI know the SAS discover > > process better than I do. Ask them :-) Surely most of > > the above is already done in your HBA's firmware. > > > > > > BTW I don't think slot numbers are reliable and don't apply > > to things on virtual phys so they will just cause you > > problems when used in the discover process, as this thread > > attests. The BIOS on LSI's HBAs does a discover process > > but is only interested in bootable devices so SES devices > > don't appear. > > > > > > Doug Gilbert > > > > > Kashyap, > > > > > > Let me know if there are any changes agreed upon, I'm happy to test > > > out patches as this is affecting a large number of our machines. I > > > can only imagine the same for others as they start to upgrade, as > this > > > is standard SuperMicro hardware. > > > > > > Thanks, > > > Jason > > > From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 20:22:01 2012 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 C7C77106566C for ; Wed, 7 Mar 2012 20:22:01 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 73E078FC13 for ; Wed, 7 Mar 2012 20:22:01 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q27KM05H024904; Wed, 7 Mar 2012 13:22:00 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q27KM0KN024890; Wed, 7 Mar 2012 13:22:00 -0700 (MST) (envelope-from ken) Date: Wed, 7 Mar 2012 13:22:00 -0700 From: "Kenneth D. Merry" To: Chuck Tuffli Message-ID: <20120307202200.GA23825@nargothrond.kdm.org> References: <20120306001731.GA38229@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-scsi Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 20:22:01 -0000 On Tue, Mar 06, 2012 at 16:30:22 -0800, Chuck Tuffli wrote: > On Mon, Mar 5, 2012 at 4:17 PM, Kenneth D. Merry wrote: > > On Mon, Mar 05, 2012 at 14:46:52 -0800, Chuck Tuffli wrote: > >> Currently, the CTL responds to INQUIRY commands targeted at invalid > >> LUNs by returning valid data with the peripheral qualifier set to LU > >> OFFLINE. This patch instead returns a check condition with LU NOT > >> READY. > >> > >> Linux initiators see the LU OFFLINE and start creating SG devices, but > >> are not able to finish. The offline also causes them to keep probing > >> LUNs. > > > > Linux used to behave properly. ?What version are you testing with? > > RHEL 6.1 > > > Returning a check condition is not correct according to the spec. ?This is > > from SPC-4 (r31): > > > > "In response to an INQUIRY command received by an incorrect logical unit, > > the SCSI target device shall return the INQUIRY data with the peripheral > > qualifier set to the value defined in 6.4.2. The INQUIRY command shall > > return CHECK CONDITION status only when the device server is unable to > > return the requested INQUIRY data." > > You are correct, so I agree the patch I submitted yesterday is wrong, but :) > > > Since CTL can support a LUN at the requested address, but there isn't one > > there, it returns OFFLINE status. > > this offline status causes Linux to create 255 sg additional devices. > While this isn't directly a CTL problem, I'm sure I will end up having > to explain why this happens more than once and would rather head off > the problem. Would you be willing to consider changing the returned > peripheral qualifier from > (SID_QUAL_LU_OFFLINE << 5) | T_DIRECT > to > (SID_QUAL_BAD_LU << 5) | T_NODEVICE > ? Linux seems happier with this FWIW. > > > They should be issuing a REPORT LUNs and then probe the LUNs that are > > returned... > > Linux does issue REPORT LUNs, but most of the time, this gets > check-conditioned with illegal request, overlapped commands attempted. Hmm, that sounds suspicious. What is the exact ASC/ASCQ reported? Are you setting the tag_action field in the ATIO that gets sent to CTL? Only one untagged command is allowed at a time. If the tag action is getting set to simple, ordered, etc., then we need to make sure that the same tag IDs aren't in use at the same time. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 22:17:15 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4B4D1065673 for ; Wed, 7 Mar 2012 22:17:15 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AA268FC12 for ; Wed, 7 Mar 2012 22:17:14 +0000 (UTC) Received: by yenl9 with SMTP id l9so3501740yen.13 for ; Wed, 07 Mar 2012 14:17:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.22.40 with SMTP id a8mr1512512oef.59.1331158634284; Wed, 07 Mar 2012 14:17:14 -0800 (PST) Received: by 10.60.67.226 with HTTP; Wed, 7 Mar 2012 14:17:14 -0800 (PST) In-Reply-To: <20120307202200.GA23825@nargothrond.kdm.org> References: <20120306001731.GA38229@nargothrond.kdm.org> <20120307202200.GA23825@nargothrond.kdm.org> Date: Wed, 7 Mar 2012 14:17:14 -0800 Message-ID: From: Chuck Tuffli To: "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkshIG/aCY1WjJIg3ZnNl7UO1e5o3yxb2uTmwUYbSoUaTi4PVfTouyQ4zSLHQTYP0DIto98 Cc: freebsd-scsi Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 22:17:15 -0000 On Wed, Mar 7, 2012 at 12:22 PM, Kenneth D. Merry wrote: > On Tue, Mar 06, 2012 at 16:30:22 -0800, Chuck Tuffli wrote: ... >> Linux does issue REPORT LUNs, but most of the time, this gets >> check-conditioned with illegal request, overlapped commands attempted. > > Hmm, that sounds suspicious. =A0What is the exact ASC/ASCQ reported? > > Are you setting the tag_action field in the ATIO that gets sent to CTL? > Only one untagged command is allowed at a time. Ooops, no I wasn't. Fixed that and the illegal request check condition has gone away (tnx!) ---chuck From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 22:25:47 2012 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 44CBD1065686 for ; Wed, 7 Mar 2012 22:25:47 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 0F0EE8FC0A for ; Wed, 7 Mar 2012 22:25:46 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q27MPkMC038598; Wed, 7 Mar 2012 15:25:46 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q27MPkTG038597; Wed, 7 Mar 2012 15:25:46 -0700 (MST) (envelope-from ken) Date: Wed, 7 Mar 2012 15:25:46 -0700 From: "Kenneth D. Merry" To: Chuck Tuffli Message-ID: <20120307222546.GA38581@nargothrond.kdm.org> References: <20120306001731.GA38229@nargothrond.kdm.org> <20120307202200.GA23825@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-scsi Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 22:25:47 -0000 On Wed, Mar 07, 2012 at 14:17:14 -0800, Chuck Tuffli wrote: > On Wed, Mar 7, 2012 at 12:22 PM, Kenneth D. Merry wrote: > > On Tue, Mar 06, 2012 at 16:30:22 -0800, Chuck Tuffli wrote: > ... > >> Linux does issue REPORT LUNs, but most of the time, this gets > >> check-conditioned with illegal request, overlapped commands attempted. > > > > Hmm, that sounds suspicious. ?What is the exact ASC/ASCQ reported? > > > > Are you setting the tag_action field in the ATIO that gets sent to CTL? > > Only one untagged command is allowed at a time. > > Ooops, no I wasn't. Fixed that and the illegal request check condition > has gone away (tnx!) Ahh, cool. So is Linux probing things properly now? Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 22:40:03 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2855A106567C for ; Wed, 7 Mar 2012 22:40:03 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id DF4868FC08 for ; Wed, 7 Mar 2012 22:40:00 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q27Me088039766; Wed, 7 Mar 2012 15:40:00 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q27MdxkV039765; Wed, 7 Mar 2012 15:39:59 -0700 (MST) (envelope-from ken) Date: Wed, 7 Mar 2012 15:39:59 -0700 From: "Kenneth D. Merry" To: Mykola Dzham Message-ID: <20120307223959.GA39737@nargothrond.kdm.org> References: <20120305184313.GA3215@laptop.levsha.me> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120305184313.GA3215@laptop.levsha.me> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org, "Desai, Kashyap" Subject: Re: Can't load mps as module with custom kernel 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 Mar 2012 22:40:03 -0000 On Mon, Mar 05, 2012 at 20:43:14 +0200, Mykola Dzham wrote: > Hi! > My FreeBSD box running on custom kernel config, without device mps > When i attempt to load mps as module: > > # sudo kldload mps > kldload: can't load mps: Exec format error > > Mar 5 09:33:35 laptop kernel: link_elf_obj: symbol xpt_freeze_simq undefined > Mar 5 09:33:35 laptop kernel: linker_load_file: Unsupported file type > > # uname -a > FreeBSD laptop.levsha.me 10.0-CURRENT FreeBSD 10.0-CURRENT #48 r232475M: Mon Mar 5 09:47:35 EET 2012 root@laptop.levsha.me:/usr/obj/usr/src/sys/LEVSHA amd64 > > Fix: > > Index: sys/dev/mps/mps_pci.c > =================================================================== > --- sys/dev/mps/mps_pci.c (revision 232475) > +++ sys/dev/mps/mps_pci.c (working copy) > @@ -87,6 +87,7 @@ > > static devclass_t mps_devclass; > DRIVER_MODULE(mps, pci, mps_pci_driver, mps_devclass, 0, 0); > +MODULE_DEPEND(mps, cam, 1, 1, 1); > > struct mps_ident { > uint16_t vendor; > Committed to FreeBSD/head, thanks! Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 22:40:05 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA688106566C for ; Wed, 7 Mar 2012 22:40:05 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 895E58FC14 for ; Wed, 7 Mar 2012 22:40:05 +0000 (UTC) Received: by obbwc7 with SMTP id wc7so10732744obb.13 for ; Wed, 07 Mar 2012 14:40:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.41.5 with SMTP id b5mr1410372obl.79.1331160005170; Wed, 07 Mar 2012 14:40:05 -0800 (PST) Received: by 10.60.67.226 with HTTP; Wed, 7 Mar 2012 14:40:05 -0800 (PST) In-Reply-To: <20120307222546.GA38581@nargothrond.kdm.org> References: <20120306001731.GA38229@nargothrond.kdm.org> <20120307202200.GA23825@nargothrond.kdm.org> <20120307222546.GA38581@nargothrond.kdm.org> Date: Wed, 7 Mar 2012 14:40:05 -0800 Message-ID: From: Chuck Tuffli To: "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQngTrHi5kGbnaB8x7Dzn78hhdqaPx3CQGw7OvBKPUJQ3K4ev1En223FEdUzJMIc7wJzrZ0M Cc: freebsd-scsi Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 22:40:05 -0000 On Wed, Mar 7, 2012 at 2:25 PM, Kenneth D. Merry wrote: > On Wed, Mar 07, 2012 at 14:17:14 -0800, Chuck Tuffli wrote: >> On Wed, Mar 7, 2012 at 12:22 PM, Kenneth D. Merry wrot= e: >> > On Tue, Mar 06, 2012 at 16:30:22 -0800, Chuck Tuffli wrote: >> ... >> >> Linux does issue REPORT LUNs, but most of the time, this gets >> >> check-conditioned with illegal request, overlapped commands attempted= . >> > >> > Hmm, that sounds suspicious. ?What is the exact ASC/ASCQ reported? >> > >> > Are you setting the tag_action field in the ATIO that gets sent to CTL= ? >> > Only one untagged command is allowed at a time. >> >> Ooops, no I wasn't. Fixed that and the illegal request check condition >> has gone away (tnx!) > > Ahh, cool. =A0So is Linux probing things properly now? No, the probing is messed up unless I change the inquiry device qualifier/type to 0x3/0x1f, but the spurious check conditions are now gone. ---chuck From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 7 22:47:16 2012 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 AADB31065673 for ; Wed, 7 Mar 2012 22:47:16 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 71B638FC12 for ; Wed, 7 Mar 2012 22:47:16 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q27Mkx53040918; Wed, 7 Mar 2012 15:46:59 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q27MkxAU040917; Wed, 7 Mar 2012 15:46:59 -0700 (MST) (envelope-from ken) Date: Wed, 7 Mar 2012 15:46:59 -0700 From: "Kenneth D. Merry" To: Chuck Tuffli Message-ID: <20120307224659.GA40869@nargothrond.kdm.org> References: <20120306001731.GA38229@nargothrond.kdm.org> <20120307202200.GA23825@nargothrond.kdm.org> <20120307222546.GA38581@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-scsi Subject: Re: [patch] CTL should check condition INQUIRY with invalid LUN 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 Mar 2012 22:47:16 -0000 On Wed, Mar 07, 2012 at 14:40:05 -0800, Chuck Tuffli wrote: > On Wed, Mar 7, 2012 at 2:25 PM, Kenneth D. Merry wrote: > > On Wed, Mar 07, 2012 at 14:17:14 -0800, Chuck Tuffli wrote: > >> On Wed, Mar 7, 2012 at 12:22 PM, Kenneth D. Merry wrote: > >> > On Tue, Mar 06, 2012 at 16:30:22 -0800, Chuck Tuffli wrote: > >> ... > >> >> Linux does issue REPORT LUNs, but most of the time, this gets > >> >> check-conditioned with illegal request, overlapped commands attempted. > >> > > >> > Hmm, that sounds suspicious. ?What is the exact ASC/ASCQ reported? > >> > > >> > Are you setting the tag_action field in the ATIO that gets sent to CTL? > >> > Only one untagged command is allowed at a time. > >> > >> Ooops, no I wasn't. Fixed that and the illegal request check condition > >> has gone away (tnx!) > > > > Ahh, cool. ?So is Linux probing things properly now? > > No, the probing is messed up unless I change the inquiry device > qualifier/type to 0x3/0x1f, but the spurious check conditions are now > gone. So that means it is sending a REPORT LUNS, but ignoring the results? If it were using the results to decide which LUNs to probe, then it wouldn't be sending inquiry commands to unsupported LUNs. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 8 06:27:12 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0BD3D1065673 for ; Thu, 8 Mar 2012 06:27:12 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id CF28E8FC0C for ; Thu, 8 Mar 2012 06:27:11 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1S5Woh-0004Os-7l for freebsd-scsi@freebsd.org; Wed, 07 Mar 2012 22:27:11 -0800 Date: Wed, 7 Mar 2012 22:27:11 -0800 (PST) From: timp To: freebsd-scsi@freebsd.org Message-ID: <1331188031232-5546565.post@n5.nabble.com> In-Reply-To: <20120307223959.GA39737@nargothrond.kdm.org> References: <20120305184313.GA3215@laptop.levsha.me> <20120307223959.GA39737@nargothrond.kdm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Can't load mps as module with custom kernel 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 Mar 2012 06:27:12 -0000 >On Mon, Mar 05, 2012 at 20:43:14 +0200, Mykola Dzham wrote: > >> Hi! >> My FreeBSD box running on custom kernel config, without device mps >> When i attempt to load mps as module: >> >> # sudo kldload mps >> kldload: can't load mps: Exec format error >> >> Mar 5 09:33:35 laptop kernel: link_elf_obj: symbol xpt_freeze_simq >> undefined >> Mar 5 09:33:35 laptop kernel: linker_load_file: Unsupported file type >> >> # uname -a >> FreeBSD laptop.levsha.me 10.0-CURRENT FreeBSD 10.0-CURRENT #48 r232475M: >> Mon Mar 5 09:47:35 EET 2012 [hidden >> email]:/usr/obj/usr/src/sys/LEVSHA amd64 >> >> Fix: >> >> Index: sys/dev/mps/mps_pci.c >> =================================================================== >> --- sys/dev/mps/mps_pci.c (revision 232475) >> +++ sys/dev/mps/mps_pci.c (working copy) >> @@ -87,6 +87,7 @@ >> >> static devclass_t mps_devclass; >> DRIVER_MODULE(mps, pci, mps_pci_driver, mps_devclass, 0, 0); >> +MODULE_DEPEND(mps, cam, 1, 1, 1); >> >> struct mps_ident { >> uint16_t vendor; >> > >Committed to FreeBSD/head, thanks! > >Ken >-- >Kenneth Merry I'm sorry, but what about similar bugs in hptiop, isp and hptmv? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Can-t-load-mps-as-module-with-custom-kernel-tp5538504p5546565.html Sent from the freebsd-scsi mailing list archive at Nabble.com. From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 8 17:54:23 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 12CDF106566B for ; Thu, 8 Mar 2012 17:54:23 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id CAE1D8FC1E for ; Thu, 8 Mar 2012 17:54:22 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q28HhkeB069078; Thu, 8 Mar 2012 09:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1331228626; bh=/pVzFPgzaJFcybhlDssswJ4ilJyBM/h029WabJpfgw4=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=Tfu2o+IMDYKRQVwI/RFpXXV0CNjXSNm5x3CkUpGpDwQ8SfjyPMJYFCddFehvyavi1 YTe4RBPmPcIt7+xmHSFAXDfrAftf5xv2aA324MWqUNyKknVxZEtAtsO7akPyKBjVlr A846BBf4NR9UsRweZN4zPL7gQYlpBBcDXs/Jl4rg= From: Sean Bruno To: timp In-Reply-To: <1331188031232-5546565.post@n5.nabble.com> References: <20120305184313.GA3215@laptop.levsha.me> <20120307223959.GA39737@nargothrond.kdm.org> <1331188031232-5546565.post@n5.nabble.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 08 Mar 2012 09:43:45 -0800 Message-ID: <1331228625.3075.11.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-scsi@freebsd.org" Subject: Re: Can't load mps as module with custom kernel 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 Mar 2012 17:54:23 -0000 On Wed, 2012-03-07 at 22:27 -0800, timp wrote: > > I'm sorry, but what about similar bugs in hptiop, isp and hptmv? If you have time, and the patience, can you generate patches for this, test and submit them? There's a few commiters that pay attention to this list and were more than happy to review/commit appropriate patches. Sean From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 8 18:26:50 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9090106564A for ; Thu, 8 Mar 2012 18:26:50 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 68BD98FC13 for ; Thu, 8 Mar 2012 18:26:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 97B23204175; Thu, 8 Mar 2012 19:26:40 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPVuOjROsgqs; Thu, 8 Mar 2012 19:26:38 +0100 (CET) Received: from [192.168.48.66] (unknown [206.126.87.151]) by smtp.infotech.no (Postfix) with ESMTPA id 3E7F1204115; Thu, 8 Mar 2012 19:26:36 +0100 (CET) Message-ID: <4F58F9DC.2040606@interlog.com> Date: Thu, 08 Mar 2012 13:26:36 -0500 From: Douglas Gilbert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Desai, Kashyap" References: <4F450814.4020100@interlog.com> <4F4C14A8.3050105@interlog.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-scsi@freebsd.org" , "McConnell, Stephen" Subject: Re: LSI2008 controller clobbers first disk with new LSI mps driver X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dgilbert@interlog.com List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 18:26:50 -0000 Kashyap, Backing up ... I thought this thread was about the mps driver failing to do the SAS discover process properly. Hence a disk did not appear because it was "hidden" by a SES device which had the same (device?) slot number. The SAS discover process is described in section 4.2 of spl2r04b.pdf (at t10.org). That is the latest draft. Please note that section never mentions the word "slot". I would hazard a guess that no SAS standard or draft has ever mentioned slots in the context of the discover process. The concept of device "slot" *** numbers comes from the SCSI Enclosure Services (SES) standards of which ses3r04.pdf is the latest draft. SAS provides the slot number _optionally_ in the long form SMP DISCOVER response and does _not_ provide the device slot number in the SMP DISCOVER LIST short form response. So IMO the device slot number is just a bit of helpful information that SAS might provide and that slot number should not interfere with the SAS discover process. *** the term "slot" is used in the SAS port layer state machine in a different context. It is also possible that "slot" is a term used in LSI firmware. A few data points: I have an Intel RES2SV240 which contains a LSI SAS2X24 expander and a HP Expander card which contains a PMC Sierra PM8005 SAS-2 expander. Both report a device slot number of 255 (i.e. not provided) via their SMP DISCOVER responses. When the inbuilt SES device on each expander is probed, the LSI part reports device slot numbers 0 through 23 while the PMC part reports a device slot number of 0 for all array devices. In both cases the SES device itself is not listed amongst the SES "array device slot" elements. Doug Gilbert On 12-03-07 12:44 PM, Desai, Kashyap wrote: > Jason, > > We discuss this issue with our architect and he has strong recommendation not to provide any work-around where Enclosure configuration is not correct. > Similar issue was reported by other customer sometimes back and they have also configured their Enclosure to resolve this issue. > "The enclosure configuration needs to be fixed so it advertises enough slots (phys disks + num of SES devices) and it places the SES devices (assigned slot numbers) above the physical disks." > > > ` Kashyap > > >> -----Original Message----- >> From: Desai, Kashyap >> Sent: Wednesday, February 29, 2012 10:08 PM >> To: 'dgilbert@interlog.com'; Jason Wolfe >> Cc: freebsd-scsi@freebsd.org; McConnell, Stephen >> Subject: RE: LSI2008 controller clobbers first disk with new LSI mps >> driver >> >> Hi Jason, >> >> I have started discussion with LSI internal folks to get better clarity >> on this issue. Since our key person is on vacation, we may get clarity >> on this next week. >> I cannot provide some temporary workaround in upstream(because this is >> against our design), but if you want to use for your environment, I can >> provide you some temporary patch. >> >> Doug, >> >> Thanks for providing your view and I have convey this to our architect. >> >> ~ Kashyap >> >>> -----Original Message----- >>> From: Douglas Gilbert [mailto:dgilbert@interlog.com] >>> Sent: Tuesday, February 28, 2012 5:11 AM >>> To: Jason Wolfe >>> Cc: Desai, Kashyap; freebsd-scsi@freebsd.org; McConnell, Stephen >>> Subject: Re: LSI2008 controller clobbers first disk with new LSI mps >>> driver >>> >>> On 12-02-27 02:59 PM, Jason Wolfe wrote: >>>> On Wed, Feb 22, 2012 at 9:11 AM, Desai, >> Kashyap >>> wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Douglas Gilbert [mailto:dgilbert@interlog.com] >>>>>> Sent: Wednesday, February 22, 2012 8:52 PM >>>>>> To: Desai, Kashyap >>>>>> Cc: Jason Wolfe; freebsd-scsi@freebsd.org; McConnell, Stephen >>>>>> Subject: Re: LSI2008 controller clobbers first disk with new LSI >> mps >>>>>> driver >>>>>> >>>>>> On 12-02-22 03:39 AM, Desai, Kashyap wrote: >>>>>>> Here is a possible root cause of this issue. >>>>>>> >>>>>>> Enclosure which you are using in your setup (might be) not >>> configured >>>>>> properly. >>>>>>> >>>>>>> You have Enclosure with 12 Slots + 1 SES Device. >>>>>>> See below detail from the log. >>>>>>> >>>>>>> EventDataLength: 5 >>>>>>> AckRequired: 0 >>>>>>> Event: SasEnclDeviceStatusChange (0x1d) >>>>>>> EventContext: 0x0 >>>>>>> EnclosureHandle: 0x2 >>>>>>> ReasonCode: Added >>>>>>> PhysicalPort: 0 >>>>>>> NumSlots: 13 >>>>>>> StartSlot: 0 >>>>>>> PhyBits: 0xff >>>>>>> >>>>>>> StartSlot is 0 in this case. >>>>>>> Correct behavior should be each device on your enclosure must >> have >>>>>> different slot number starting from 0 till 12. >>>>>>> I have doubt that SES device has not configured well and it is >>> using >>>>>> slot-0 as default. This can create issue for actual device which >> is >>>>>> connected to slot-0. >>>>>>> So In your setup you will have slot-0 till slot-11 assigned for >>> actual >>>>>> Phys of your enclosures and again slot-0 is assigned for SES >> device >>>>>> instead of Slot-12. >>>>>> >>>>>> No. SAS-2 expanders typically have an integral SES device on an >>>>>> expander _virtual_ phy (see SMP DISCOVER (LIST) response). Once >>>>>> you see that virtual phy flag the slot number is irrelevant. >>>>> >>>>> Doug, >>>>> >>>>> I need some more info so that I can understand your point better. >>>>> >>>>> I have one Enclosure setup on FreeBSD. Here is smp_discover output. >>> (smp_discover_list is failing for me) >>>>> >>>>> phy 0: inaccessible (phy vacant) >>>>> phy 1: inaccessible (phy vacant) >>>>> phy 2: inaccessible (phy vacant) >>>>> phy 3: inaccessible (phy vacant) >>>>> phy 4:S:attached:[500605b012345888:03 i(SSP+STP+SMP)] 6 Gbps >>>>> phy 5:S:attached:[500605b012345888:02 i(SSP+STP+SMP)] 6 Gbps >>>>> phy 6:S:attached:[500605b012345888:01 i(SSP+STP+SMP)] 6 Gbps >>>>> phy 7:S:attached:[500605b012345888:00 i(SSP+STP+SMP)] 6 Gbps >>>>> phy 12:D:attached:[5000c5003bc2c389:00 t(SSP)] 6 Gbps >>>>> phy 13:D:attached:[500000e116ee91e2:00 t(SSP)] 6 Gbps >>>>> phy 14:D:attached:[5000c5003bc308e5:00 t(SSP)] 6 Gbps >>>>> phy 15:D:attached:[5000c5003bc2f0d1:00 t(SSP)] 6 Gbps >>>>> phy 16:D:attached:[5000c5003bc2ff3d:00 t(SSP)] 6 Gbps >>>>> phy 17:D:attached:[5000c5003bae5fdd:00 t(SSP)] 6 Gbps >>>>> phy 18:D:attached:[5000c5003bae5eb1:00 t(SSP)] 6 Gbps >>>>> phy 19:D:attached:[5000c5003bc2d135:00 t(SSP)] 6 Gbps >>>>> phy 20:D:attached:[5000c5003baea36d:00 t(SSP)] 6 Gbps >>>>> phy 21:D:attached:[5000c5003bc2a8c9:00 t(SSP)] 6 Gbps >>>>> phy 22:D:attached:[5000c5003bc237a9:00 t(SSP)] 6 Gbps >>>>> phy 23:D:attached:[5000c5003bc2cec1:00 t(SSP)] 6 Gbps >>>>> phy 24:D:attached:[500000e01d92cb52:00 t(SSP)] 3 Gbps >>>>> phy 25:D:attached:[500000e01d74cfb2:00 t(SSP)] 3 Gbps >>>>> phy 26:D:attached:[500000e01d656052:00 t(SSP)] 3 Gbps >>>>> phy 27:D:attached:[500000e01d7cad52:00 t(SSP)] 3 Gbps >>>>> phy 28:D:attached:[500c04f2b64cdd1c:00 t(SATA)] 3 Gbps >>>>> phy 29:D:attached:[500c04f2b64cdd1d:00 t(SATA)] 3 Gbps >>>>> phy 30:D:attached:[500000e01d73c262:00 t(SSP)] 3 Gbps >>>>> phy 31:D:attached:[500000e01d536b22:00 t(SSP)] 3 Gbps >>>>> phy 32:D:attached:[500000e01d92cab2:00 t(SSP)] 3 Gbps >>>>> phy 33:D:attached:[500000e01afd8792:00 t(SSP)] 3 Gbps >>>>> phy 34:D:attached:[5000c5003bc30301:00 t(SSP)] 6 Gbps >>>>> phy 35:D:attached:[5000c5003bb09a69:00 t(SSP)] 6 Gbps >>>>> phy 36:D:attached:[500c04f2b64cdd3d:00 V i(SSP) t(SSP)] 6 >> Gbps<- >>> -- This has virtual phy set. >>>>> >>>>> What I understood from your explanation is if we have virt_phy >> field >>> set, we should not trust slot for that entry. >>>>> You are suggesting to use phy index instead of slot. Just for info: >>> But how to see Slot details mapping with phy ? >>> >>> Kashyap, >>> I haven't written a SAS discover algorithm but there >>> must be plenty of examples out there. One way to do it >>> is to find all the phy_ids attached to targets, in this >>> case there are SAS (SSP) and SATA targets. Each SATA >>> target phy_id will correspond to one SATA disk (or could be an >>> ATAPI device (e.g. DVD/BD player)). The SSP targets are a >>> bit trickier because two (or more) phys could be connected >>> to the same target (either a wide port or multiple (target) >>> ports). With a wide port each component phy has the same >>> attached SAS address (so above you have a wide initiator >>> port (phy ids 4,5,6,7) but no wide target ports). If a >>> SAS disk has multiple target ports connected, FreeBSD >>> probably has a device node for each. So for each SCSI (SSP) >>> target port you need a REPORT LUNS command issued on LUN 0 >>> (or the REPORT LUNS well known logical unit) to find the >>> LUs it contains. A device node is created for each LU. >>> >>> Anyway I'm sure many folks in LSI know the SAS discover >>> process better than I do. Ask them :-) Surely most of >>> the above is already done in your HBA's firmware. >>> >>> >>> BTW I don't think slot numbers are reliable and don't apply >>> to things on virtual phys so they will just cause you >>> problems when used in the discover process, as this thread >>> attests. The BIOS on LSI's HBAs does a discover process >>> but is only interested in bootable devices so SES devices >>> don't appear. >>> >>> >>> Doug Gilbert >>> >>>> Kashyap, >>>> >>>> Let me know if there are any changes agreed upon, I'm happy to test >>>> out patches as this is affecting a large number of our machines. I >>>> can only imagine the same for others as they start to upgrade, as >> this >>>> is standard SuperMicro hardware. >>>> >>>> Thanks, >>>> Jason >>>> > > From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 8 21:15:02 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4BF1106564A for ; Thu, 8 Mar 2012 21:15:02 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC388FC18 for ; Thu, 8 Mar 2012 21:15:02 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id q28LEuPB086117; Thu, 8 Mar 2012 14:14:56 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id q28LEt7v086116; Thu, 8 Mar 2012 14:14:55 -0700 (MST) (envelope-from ken) Date: Thu, 8 Mar 2012 14:14:55 -0700 From: "Kenneth D. Merry" To: Chuck Tuffli Message-ID: <20120308211455.GA85033@nargothrond.kdm.org> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Cc: freebsd-scsi Subject: Re: CTL panic 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 Mar 2012 21:15:02 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 23, 2012 at 13:44:10 -0800, Chuck Tuffli wrote: > I just tried using our targ(9) compatible driver with CTL today and > get the below panic. Our driver didn't recognize the > XPT_IMMEDIATE_NOTIFY and returned CAM_REQ_INVALID which ctlfedone > doesn't handle explicitly. The following patch seems to avoid this > problem for me, but there might be a better fix. Sorry for the delayed response. Here is a patch that should fix it. Although it isn't relevant for you now, since your driver is talking to CTL successfully, it is still needed for the mpt(4), ahc(4), ahd(4), and firewire drivers that support the older target mode API. This hopefully fixes some of the issues inside CTL, and then essentially prevents CTL from talking to target-capable SIMs that haven't been updated to support the CCBs that CTL needs. I'll probably tweak it some more before it goes in the tree. I got a bug report from someone with an mpt(4)-based FC controller. He is running into the same issue, so I imagine anyone else with an mpt(4) FC controller will see it as well. The other drivers don't enable target mode by default, and so won't trigger this bug unless the user has enabled it in the driver. Ken -- Kenneth Merry ken@FreeBSD.ORG --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cam_target.20120308.1.txt" ==== //depot/users/kenm/FreeBSD-test/sys/cam/cam_ccb.h#12 - /usr/home/kenm/perforce4/kenm/FreeBSD-test/sys/cam/cam_ccb.h ==== *** /tmp/tmp.350.95 Thu Mar 8 13:44:51 2012 --- /usr/home/kenm/perforce4/kenm/FreeBSD-test/sys/cam/cam_ccb.h Thu Mar 8 13:24:26 2012 *************** *** 558,564 **** PIT_DISCONNECT = 0x20, /* Disconnects supported in target mode */ PIT_TERM_IO = 0x10, /* Terminate I/O message supported in TM */ PIT_GRP_6 = 0x08, /* Group 6 commands supported */ ! PIT_GRP_7 = 0x04 /* Group 7 commands supported */ } pi_tmflag; typedef enum { --- 558,565 ---- PIT_DISCONNECT = 0x20, /* Disconnects supported in target mode */ PIT_TERM_IO = 0x10, /* Terminate I/O message supported in TM */ PIT_GRP_6 = 0x08, /* Group 6 commands supported */ ! PIT_GRP_7 = 0x04, /* Group 7 commands supported */ ! PIT_PROC_CTL = 0x02 /* Target mode processor (CTL compatible) */ } pi_tmflag; typedef enum { ==== //depot/users/kenm/FreeBSD-test/sys/cam/ctl/scsi_ctl.c#3 - /usr/home/kenm/perforce4/kenm/FreeBSD-test/sys/cam/ctl/scsi_ctl.c ==== *** /tmp/tmp.350.168 Thu Mar 8 13:44:51 2012 --- /usr/home/kenm/perforce4/kenm/FreeBSD-test/sys/cam/ctl/scsi_ctl.c Thu Mar 8 12:45:29 2012 *************** *** 304,312 **** cpi = (struct ccb_pathinq *)arg; /* Don't attach if it doesn't support target mode */ ! if ((cpi->target_sprt & PIT_PROCESSOR) == 0) { #ifdef CTLFEDEBUG ! printf("%s: SIM %s%d doesn't support target mode\n", __func__, cpi->dev_name, cpi->unit_number); #endif break; --- 304,313 ---- cpi = (struct ccb_pathinq *)arg; /* Don't attach if it doesn't support target mode */ ! if ((cpi->target_sprt & PIT_PROC_CTL) == 0) { #ifdef CTLFEDEBUG ! printf("%s: SIM %s%d doesn't support CTL-compatible " ! "target mode API\n", __func__, cpi->dev_name, cpi->unit_number); #endif break; *************** *** 628,639 **** xpt_action(new_ccb); softc->inots_sent++; status = new_ccb->ccb_h.status; ! if (status != CAM_REQ_INPROG) { ! free(new_ccb, M_CTLFE); break; } } ! if (i == 0) { xpt_print(periph->path, "%s: could not allocate immediate " "notify CCBs, status 0x%x\n", __func__, status); return (CAM_REQ_CMP_ERR); --- 629,650 ---- xpt_action(new_ccb); softc->inots_sent++; status = new_ccb->ccb_h.status; ! if ((status & CAM_STATUS_MASK) != CAM_REQ_INPROG) { ! /* ! * Note that we don't free the CCB here. If the ! * status is not CAM_REQ_INPROG, then we're ! * probably talking to a SIM that says it is ! * target-capable but doesn't support the ! * XPT_IMMEDIATE_NOTIFY CCB. i.e. it supports the ! * older API. In that case, it'll call xpt_done() ! * on the CCB, and we need to free it in our done ! * routine as a result. ! */ break; } } ! if ((i == 0) ! || (status != CAM_REQ_INPROG)) { xpt_print(periph->path, "%s: could not allocate immediate " "notify CCBs, status 0x%x\n", __func__, status); return (CAM_REQ_CMP_ERR); *************** *** 1460,1471 **** */ send_ctl_io = 0; break; default: ! xpt_print(periph->path, "%s: " ! "unsupported CAM status 0x%x\n", ! __func__, status); ! send_ctl_io = 0; ! break; } if (send_ctl_io != 0) { ctl_queue(io); --- 1471,1499 ---- */ send_ctl_io = 0; break; + case CAM_REQ_INVALID: + case CAM_PROVIDE_FAIL: default: ! /* ! * We should only get here if we're talking ! * to a talking to a SIM that is target ! * capable but supports the old API. In ! * that case, we need to just free the CCB. ! * If we actually send a notify acknowledge, ! * it will send that back with an error as ! * well. ! */ ! ! if ((status != CAM_REQ_INVALID) ! && (status != CAM_PROVIDE_FAIL)) ! xpt_print(periph->path, "%s: " ! "unsupported CAM status " ! "0x%x\n", __func__, status); ! ! ctl_free_io(io); ! ctlfe_free_ccb(periph, done_ccb); ! ! return; } if (send_ctl_io != 0) { ctl_queue(io); ==== //depot/users/kenm/FreeBSD-test/sys/dev/isp/isp_freebsd.c#6 - /usr/home/kenm/perforce4/kenm/FreeBSD-test/sys/dev/isp/isp_freebsd.c ==== *** /tmp/tmp.350.194 Thu Mar 8 13:44:51 2012 --- /usr/home/kenm/perforce4/kenm/FreeBSD-test/sys/dev/isp/isp_freebsd.c Thu Mar 8 12:46:00 2012 *************** *** 4849,4854 **** --- 4849,4855 ---- cpi->version_num = 1; #ifdef ISP_TARGET_MODE cpi->target_sprt = PIT_PROCESSOR | PIT_DISCONNECT | PIT_TERM_IO; + cpi->target_sprt |= PIT_PROC_CTL; #else cpi->target_sprt = 0; #endif --3MwIy2ne0vdjdPXF-- From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 8 22:49:56 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFA97106564A for ; Thu, 8 Mar 2012 22:49:56 +0000 (UTC) (envelope-from chuck@tuffli.net) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9672C8FC13 for ; Thu, 8 Mar 2012 22:49:56 +0000 (UTC) Received: by yhgm50 with SMTP id m50so684620yhg.13 for ; Thu, 08 Mar 2012 14:49:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.25.37 with SMTP id z5mr3092831oef.69.1331246989958; Thu, 08 Mar 2012 14:49:49 -0800 (PST) Received: by 10.60.67.226 with HTTP; Thu, 8 Mar 2012 14:49:49 -0800 (PST) In-Reply-To: <20120308211455.GA85033@nargothrond.kdm.org> References: <20120308211455.GA85033@nargothrond.kdm.org> Date: Thu, 8 Mar 2012 14:49:49 -0800 Message-ID: From: Chuck Tuffli To: "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkWrNlTg6qdImyOWG4n0atQd5z/4Pdgq7H55X1J0yLROnnkQARihxhe3zi5LXzL0w0Zf+Sx Cc: freebsd-scsi Subject: Re: CTL panic 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 Mar 2012 22:49:56 -0000 On Thu, Mar 8, 2012 at 1:14 PM, Kenneth D. Merry wrote: > On Thu, Feb 23, 2012 at 13:44:10 -0800, Chuck Tuffli wrote: >> I just tried using our targ(9) compatible driver with CTL today and >> get the below panic. Our driver didn't recognize the >> XPT_IMMEDIATE_NOTIFY and returned CAM_REQ_INVALID which ctlfedone >> doesn't handle explicitly. The following patch seems to avoid this >> problem for me, but there might be a better fix. > > Sorry for the delayed response. No worries > Here is a patch that should fix it. =A0Although it isn't relevant for you > now, since your driver is talking to CTL successfully, it is still needed > for the mpt(4), ahc(4), ahd(4), and firewire drivers that support the old= er > target mode API. > > This hopefully fixes some of the issues inside CTL, and then essentially > prevents CTL from talking to target-capable SIMs that haven't been update= d > to support the CCBs that CTL needs. I tested this patch using our driver both - with PIT_PROCESSOR set and no XPT_IMMEDIATE_NOTIFY support - with PIT_PROC_CTL set and XPT_IMMEDIATE_NOTIFY support and both work as expected. So patch-wise, ACK / "works for me" ---chuck From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 9 18:49:32 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90AF2106564A; Fri, 9 Mar 2012 18:49:32 +0000 (UTC) (envelope-from prvs=14151bc171=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id F080F8FC0A; Fri, 9 Mar 2012 18:49:31 +0000 (UTC) X-Spam-Processed: mail1.multiplay.co.uk, Fri, 09 Mar 2012 18:38:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50018461258.msg; Fri, 09 Mar 2012 18:38:45 +0000 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=14151bc171=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <1DD65E0CC5144356A161732587F26266@multiplay.co.uk> From: "Steven Hartland" To: "Kenneth D. Merry" References: <02B04E968B8648CC83F274B32090B937@multiplay.co.uk> <20111024171039.GA39194@nargothrond.kdm.org> <7E5239236AA04319B4C090E5F199DC64@multiplay.co.uk> <20111025173148.GA93047@nargothrond.kdm.org> Date: Fri, 9 Mar 2012 18:38:35 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-scsi@freebsd.org, Eygene Ryabinkin Subject: Re: Looking for a committer for cam fixes / enhancements 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: Fri, 09 Mar 2012 18:49:32 -0000 ----- Original Message ----- From: "Kenneth D. Merry" Sorry its been a quite a while, had no free time to look at this until now, but I have got a few questions if you would be so kind:- >> Could you give me some points on the things you spotted weren't "KNR" >> I've tried to stick with what I saw as the current formatting but clearly >> missed something's ;-) > > To match the rest of the file this: > > static int > atasecurity_set_password(struct cam_device *device, union ccb *ccb, int retry_count, > u_int32_t timeout, struct ata_security_password *pwd, int quiet) > { > > Should look like this: > static int > atasecurity_set_password(struct cam_device *device, union ccb *ccb, > int retry_count, u_int32_t timeout, > struct ata_security_password *pwd, int quiet) > { > > And this: > > cam_fill_ataio(&ccb->ataio, > retry_count, > NULL, > /*flags*/CAM_DIR_OUT, > MSG_SIMPLE_Q_TAG, > /*data_ptr*/(u_int8_t *)pwd, > /*dxfer_len*/sizeof(struct ata_security_password), > timeout); > > Shoud look like this: > > cam_fill_ataio(&ccb->ataio, > retry_count, > NULL, > /*flags*/CAM_DIR_OUT, > MSG_SIMPLE_Q_TAG, > /*data_ptr*/(u_int8_t *)pwd, > /*dxfer_len*/sizeof(struct ata_security_password), > timeout); > > So are you saying that all wrapped function definitions should have their wrapped lines indented via tabs (using ts=8) + spaces such that the wrapped lines align with the opening bracket of the arg list? If this is the case can you explain why as it means that all formatting needs to be done manually which seems needless? > Everything that exceeds 80 columns should not exceed that. Make sure the > tab stop in your editor is set to 8 when editing code. Again why in this day and age limit to 80? 132 I could just about understand but not 80 chars, does anyone really have a screen which can only display this amount of characters which they use to code on in this day and age especially given 8 char tab stops? The file already doesn't comply with this e.g. ata_bpack(ident_buf->revision, ident_buf->revision, sizeof(ident_buf->revision)); ata_btrim(ident_buf->serial, sizeof(ident_buf->serial)); ata_bpack(ident_buf->serial, ident_buf->serial, sizeof(ident_buf->serial)); In addition how do you deal with cases where a literal string e.g. if a printf is longer than 80 chars does that have to be split up? Overall this makes it harder to write compliant code (cant use standard editor formatting cabailities) as well as creating harder to read code, which all seems quite needless i.e. instead of:- error = atasecurity_unlock(device, ccb, retry_count, timeout, &pwd, quiet); I would have to have:- error = atasecurity_unlock(device, ccb, retry_count, timeout, &pwd, quiet); > I'm not suggesting short options, but a slightly different approach. > Instead of --option, or -r, use -o foopassword=blah. > > It might be interesting to do this: > > cd src > find bin sbin usr.sbin usr.bin -name "*.c" -print |xargs grep getopt_long > > The list of programs that use getopt_long() is very short, and almost all > of them are either GNU programs, or maintaining compatibility with GNU > programs (e.g. tar, cpio) Sorry I don't mean to be a pain, but while this maybe what other programs are doing, are they also supporting as many options as camcontrol? Does it really make sense to have utils all do their own command line argument parsing which is required to process -o foopassword=blah, as suggested, instead of using the existing library designed to do this job for you? Seems like trying to stick with something that's no longer suitable, which will only cause supportability issues, simply because that's how its been done in the past? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 10 05:50:32 2012 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4C7B6106564A; Sat, 10 Mar 2012 05:50:32 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 23EB98FC0C; Sat, 10 Mar 2012 05:50:32 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2A5oWY1003204; Sat, 10 Mar 2012 05:50:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2A5oWdN003200; Sat, 10 Mar 2012 05:50:32 GMT (envelope-from linimon) Date: Sat, 10 Mar 2012 05:50:32 GMT Message-Id: <201203100550.q2A5oWdN003200@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165740: [cam] SCSI code must drain callbacks before free 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 Mar 2012 05:50:32 -0000 Old Synopsis: SCSI code must drain callbacks before free New Synopsis: [cam] SCSI code must drain callbacks before free Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 10 05:49:55 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165740