From owner-freebsd-scsi@FreeBSD.ORG Mon Apr 19 11:07:07 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83593106566B for ; Mon, 19 Apr 2010 11:07:07 +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 70ECF8FC20 for ; Mon, 19 Apr 2010 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3JB77w1034213 for ; Mon, 19 Apr 2010 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3JB763l034211 for freebsd-scsi@FreeBSD.org; Mon, 19 Apr 2010 11:07:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Apr 2010 11:07:06 GMT Message-Id: <201004191107.o3JB763l034211@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, 19 Apr 2010 11:07:07 -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/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/141934 scsi [cam] [patch] add support for SEAGATE DAT Scopion 130 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 p kern/130735 scsi [cam] [patch] pass M_NOWAIT to the malloc() call insid 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/124667 scsi [amd] [panic] FreeBSD-7 kernel page faults at amd-scsi o kern/123674 scsi [ahc] ahc driver dumping f kern/123666 scsi [aac] attach fails with Adaptec SAS RAID 3805 controll 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/119668 scsi [cam] [patch] certain errors are too verbose comparing 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/94838 scsi Kernel panic while mounting SD card with lock switch o 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/40895 scsi wierd kernel / device driver bug 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 37 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue Apr 20 18:01:30 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E5BF1065674 for ; Tue, 20 Apr 2010 18:01:30 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D77708FC1B for ; Tue, 20 Apr 2010 18:01:29 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA00996 for ; Tue, 20 Apr 2010 21:01:27 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BCDEBF6.3030609@icyb.net.ua> Date: Tue, 20 Apr 2010 21:01:26 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: cam.3: do not discourage use of cam_open_device 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, 20 Apr 2010 18:01:30 -0000 This is based on my understanding what Scott Long tried to explain me a while ago. Index: lib/libcam/cam.3 =================================================================== --- lib/libcam/cam.3 (revision 206902) +++ lib/libcam/cam.3 (working copy) @@ -190,12 +190,6 @@ Once the device name and unit number are determined, a lookup is performed to determine the passthrough device that corresponds to the given device. -.Fn cam_open_device -is rather simple to use, but it is not really suitable for general use -because its behavior is not necessarily deterministic. -Programmers writing -new applications should make the extra effort to use one of the other open -routines documented below. .Pp .Fn cam_open_spec_device opens the It seems that this warning about ambiguity came from pre-devfs days when e.g. cd0 nodes in different directories could correspond to different actual SCSI peripherals. It seems that there wasn't an ambiguity if an absolute device path was given. Nowadays, cam_open_device seems to always do a proper job of finding a correct pass device. -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 01:57:21 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44F93106564A for ; Wed, 21 Apr 2010 01:57:21 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id DFB758FC24 for ; Wed, 21 Apr 2010 01:57:20 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 7F42D439E38 for ; Tue, 20 Apr 2010 20:57:46 -0500 (CDT) Message-ID: <4BCE6988.1060302@fuujingroup.com> Date: Tue, 20 Apr 2010 20:57:12 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: isp and scsi_target 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, 21 Apr 2010 01:57:21 -0000 We're trying to get an emulated disk to show up on 7.3-REL and not having much luck. This is a point-to-point connection with a pair of Qlogic cards (pciconf below). There is no FC switch in between the machines, and both cards were defaulted prior to testing (factory BIOS settings). The moment I rescan the bus on the initiator, the target machine panics and dumps core. The initiator hangs until the FC card on the initiator resets, then returns to the prompt (wedge??). Here's the card (same in both machines though different scsi bus) isp0@pci0:5:1:0: class=0x0c0400 card=0x00091077 chip=0x23001077 rev=0x01 hdr=0x00 vendor = 'QLogic Corporation' device = 'QLA2300 SANblade 2300 64-bit FC-AL Adapter' class = serial bus subclass = Fibre Channel I get tons of debugging output on the target machine when launching scsi_target with the following command: test001# scsi_target -d 3:0:0 /usr/home/testuser/target0 Here's a snip-it of the debugging output on the target machine after the above command (goes on for pages): scsi_target: sending ccb (0x332) scsi_target: sending ccb (0x334) scsi_target: sending ccb (0x332) scsi_target: sending ccb (0x334) scsi_target: main loop beginning Then this when the initiator rescans the bus just before it tanks: scsi_target: read ready scsi_target: event -1 done scsi_target: Working on ATIO 0x2825c200 scsi_target: tcmd_handle atio 0x2825c200 ctio 0x2825e0c0 atioflags 0x8000 And this in the log on the initiator when it comes back up: isp0: bad pdb (110) @ handle 0x1 isp0: 0: hdl 0x1 PROB al1 tgt 0 TGT 0x0000e8 => UNK 0x000000; WWNN 0x200000e08b08f56d WWPN 0x210000e08b08f56d Here's the relevant kernel info on the target: # ISP SCSI Controllers device isp # Qlogic family device ispfw # Firmware for QLogic HBAs options ISP_TARGET_MODE # Qlogic family target mode device targ device targbh options CAMDEBUG options VFS_AIO /boot/device.hints on the target: hint.isp.0.fullduplex="1" hint.isp.0.topology="nport-only" hint.isp.0.role="target" Here's the relevant kernel info on the initiator: # ISP SCSI Controllers device isp # Qlogic family device ispfw # Firmware for QLogic HBAs device targ device targbh options CAMDEBUG options VFS_AIO /boot/device.hints on the initiator: hint.isp.0.fullduplex="1" hint.isp.0.topology="nport-only" hint.isp.0.role="initiator" hint.isp.0.iid="4" I'm seeing this in the syslog on the initiator: Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, resid 36, status not marked) Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, resid 36, status not marked) Here's the bt for the core dump after the panic which looks to be pretty useless from my observation (I'd _love_ to be wrong!!): test001# kgdb kernel.debug /var/crash/vmcore.0 Unread portion of the kernel message buffer: (targ0:isp0:0:0:0): targdone 0xc7b7b400 (targ0:isp0:0:0:0): targread (targ0:isp0:0:0:0): targread ccb 0xc7b7b400 (0x2825c200) (targ0:isp0:0:0:0): targreturnccb 0xc7b7b400 cam_debug: targfreeccb descr 0xc7b80060 and cam_debug: freeing ccb 0xc7b7b400 (targ0:isp0:0:0:0): write - uio_resid 4 (targ0:isp0:0:0:0): Sending queued ccb 0x933 (0x2825e0c0) (targ0:isp0:0:0:0): targstart 0xc73bd400 (targ0:isp0:0:0:0): sendccb 0xc73bd400 Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x20:0xc04f0a66 stack pointer = 0x28:0xc6fe5900 frame pointer = 0x28:0xc6fe5950 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 639 (scsi_target) trap number = 12 panic: page fault cpuid = 4 Uptime: 51s Physical memory: 3767 MB Dumping 102 MB: 87 71 55 39 23 7 Reading symbols from /boot/kernel/ispfw.ko...Reading symbols from /boot/kernel/ispfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ispfw.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05c4e87 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05c5159 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc08258bc in trap_fatal (frame=0xc6fe58c0, eva=4) at /usr/src/sys/i386/i386/trap.c:950 #4 0xc0825b20 in trap_pfault (frame=0xc6fe58c0, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:863 #5 0xc08264d9 in trap (frame=0xc6fe58c0) at /usr/src/sys/i386/i386/trap.c:541 #6 0xc080a1db in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc04f0a66 in isp_pci_dmasetup (isp=0xc71de000, csio=0xc73bd400, rq=0xc6fe59c4, nxtip=0xc6fe5a0c, optr=1) at /usr/src/sys/dev/isp/isp_pci.c:2781 #8 0xc04e96a1 in isp_action (sim=0xc7198e00, ccb=0xc73bd400) at /usr/src/sys/dev/isp/isp_freebsd.c:1373 #9 0xc0449104 in xpt_run_dev_sendq (bus=0xc71d65c0) at /usr/src/sys/cam/cam_xpt.c:3894 #10 0xc04495ce in xpt_action (start_ccb=0xc73bd400) at /usr/src/sys/cam/cam_xpt.c:3056 #11 0xc0466ee6 in targsendccb (softc=0xc744ee00, ccb=0xc73bd400, descr=0xc7b80020) at /usr/src/sys/cam/scsi/scsi_target.c:787 #12 0xc0467027 in targstart (periph=0xc71cc700, start_ccb=0xc73bd400) at /usr/src/sys/cam/scsi/scsi_target.c:654 #13 0xc044dd1d in xpt_run_dev_allocq (bus=0xc71d65c0) at /usr/src/sys/cam/cam_xpt.c:3765 #14 0xc044e0ad in xpt_schedule (perph=0xc71cc700, new_priority=1) at /usr/src/sys/cam/cam_xpt.c:3665 #15 0xc04684f4 in targwrite (dev=0xc7681000, uio=0xc6fe5c60, ioflag=0) at /usr/src/sys/cam/scsi/scsi_target.c:599 #16 0xc0586359 in giant_write (dev=0xc7681000, uio=0xc6fe5c60, ioflag=0) at /usr/src/sys/kern/kern_conf.c:434 #17 0xc054cbde in devfs_write_f (fp=0xc7631b94, uio=0xc6fe5c60, cred=0xc7681600, flags=0, td=0xc7889240) at /usr/src/sys/fs/devfs/devfs_vnops.c:1446 #18 0xc05ff917 in dofilewrite (td=0xc7889240, fd=4, fp=0xc7631b94, auio=0xc6fe5c60, offset=-1, flags=0) at file.h:257 #19 0xc05ffbf8 in kern_writev (td=0xc7889240, fd=4, auio=0xc6fe5c60) at /usr/src/sys/kern/sys_generic.c:402 #20 0xc05ffc6f in write (td=0xc7889240, uap=0xc6fe5cfc) at /usr/src/sys/kern/sys_generic.c:318 #21 0xc0825e75 in syscall (frame=0xc6fe5d38) at /usr/src/sys/i386/i386/trap.c:1101 #22 0xc080a240 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #23 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Platform is a pair of HP DL580-G3 servers, quad 2.8GHz Xeon CPU's with 4 gigs of ram in each (x86-32/i386, not x86-64/amd64). I've tried this with and without the device.hints options, all resulting in a core dump on the target and a hang on the initiator until the card in the target gets reset on reboot. Any thoughts would be great. I'd like to get a SQL server up on these FC cards. I understand I could use iSCSI, but the powers that be have requested FC. -- Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 02:16:32 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80D24106567E for ; Wed, 21 Apr 2010 02:16:32 +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 2FBC18FC1A for ; Wed, 21 Apr 2010 02:16:31 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o3L2GVSP053993 for ; Tue, 20 Apr 2010 19:16:31 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BCE6016.5020108@feral.com> Date: Tue, 20 Apr 2010 19:16:54 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BCE6988.1060302@fuujingroup.com> In-Reply-To: <4BCE6988.1060302@fuujingroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Tue, 20 Apr 2010 19:16:31 -0700 (PDT) Subject: Re: isp and scsi_target 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, 21 Apr 2010 02:16:32 -0000 What a mess. I need to look at this in detail. The stuff was working (sort of) in RELENG_8, but got very little testing otherwise. > We're trying to get an emulated disk to show up on 7.3-REL and not > having much luck. This is a point-to-point connection with a pair of > Qlogic cards (pciconf below). There is no FC switch in between the > machines, and both cards were defaulted prior to testing (factory BIOS > settings). The moment I rescan the bus on the initiator, the target > machine panics and dumps core. The initiator hangs until the FC card > on the initiator resets, then returns to the prompt (wedge??). > > Here's the card (same in both machines though different scsi bus) > > isp0@pci0:5:1:0: class=0x0c0400 card=0x00091077 chip=0x23001077 > rev=0x01 hdr=0x00 > vendor = 'QLogic Corporation' > device = 'QLA2300 SANblade 2300 64-bit FC-AL Adapter' > class = serial bus > subclass = Fibre Channel > > > I get tons of debugging output on the target machine when launching > scsi_target with the following command: > > test001# scsi_target -d 3:0:0 /usr/home/testuser/target0 > > Here's a snip-it of the debugging output on the target machine after > the above command (goes on for pages): > > scsi_target: sending ccb (0x332) > scsi_target: sending ccb (0x334) > scsi_target: sending ccb (0x332) > scsi_target: sending ccb (0x334) > scsi_target: main loop beginning > > Then this when the initiator rescans the bus just before it tanks: > > scsi_target: read ready > scsi_target: event -1 done > scsi_target: Working on ATIO 0x2825c200 > scsi_target: tcmd_handle atio 0x2825c200 ctio 0x2825e0c0 atioflags 0x8000 > > And this in the log on the initiator when it comes back up: > > isp0: bad pdb (110) @ handle 0x1 > isp0: 0: hdl 0x1 PROB al1 tgt 0 TGT 0x0000e8 => UNK 0x000000; WWNN > 0x200000e08b08f56d WWPN 0x210000e08b08f56d > > > Here's the relevant kernel info on the target: > > # ISP SCSI Controllers > device isp # Qlogic family > device ispfw # Firmware for QLogic HBAs > options ISP_TARGET_MODE # Qlogic family target mode > device targ > device targbh > options CAMDEBUG > options VFS_AIO > > /boot/device.hints on the target: > > hint.isp.0.fullduplex="1" > hint.isp.0.topology="nport-only" > hint.isp.0.role="target" > > Here's the relevant kernel info on the initiator: > > # ISP SCSI Controllers > device isp # Qlogic family > device ispfw # Firmware for QLogic HBAs > device targ > device targbh > options CAMDEBUG > options VFS_AIO > > /boot/device.hints on the initiator: > > hint.isp.0.fullduplex="1" > hint.isp.0.topology="nport-only" > hint.isp.0.role="initiator" > hint.isp.0.iid="4" > > > I'm seeing this in the syslog on the initiator: > > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > resid 36, status not marked) > Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > resid 36, status not marked) > > > Here's the bt for the core dump after the panic which looks to be > pretty useless from my observation (I'd _love_ to be wrong!!): > > test001# kgdb kernel.debug /var/crash/vmcore.0 > > Unread portion of the kernel message buffer: > (targ0:isp0:0:0:0): targdone 0xc7b7b400 > (targ0:isp0:0:0:0): targread > (targ0:isp0:0:0:0): targread ccb 0xc7b7b400 (0x2825c200) > (targ0:isp0:0:0:0): targreturnccb 0xc7b7b400 > cam_debug: targfreeccb descr 0xc7b80060 and > cam_debug: freeing ccb 0xc7b7b400 > (targ0:isp0:0:0:0): write - uio_resid 4 > (targ0:isp0:0:0:0): Sending queued ccb 0x933 (0x2825e0c0) > (targ0:isp0:0:0:0): targstart 0xc73bd400 > (targ0:isp0:0:0:0): sendccb 0xc73bd400 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc04f0a66 > stack pointer = 0x28:0xc6fe5900 > frame pointer = 0x28:0xc6fe5950 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 639 (scsi_target) > trap number = 12 > panic: page fault > cpuid = 4 > Uptime: 51s > Physical memory: 3767 MB > Dumping 102 MB: 87 71 55 39 23 7 > > Reading symbols from /boot/kernel/ispfw.ko...Reading symbols from > /boot/kernel/ispfw.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ispfw.ko > Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > /boot/kernel/acpi.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/acpi.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc05c4e87 in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc05c5159 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc08258bc in trap_fatal (frame=0xc6fe58c0, eva=4) at > /usr/src/sys/i386/i386/trap.c:950 > #4 0xc0825b20 in trap_pfault (frame=0xc6fe58c0, usermode=0, eva=4) at > /usr/src/sys/i386/i386/trap.c:863 > #5 0xc08264d9 in trap (frame=0xc6fe58c0) at > /usr/src/sys/i386/i386/trap.c:541 > #6 0xc080a1db in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > #7 0xc04f0a66 in isp_pci_dmasetup (isp=0xc71de000, csio=0xc73bd400, > rq=0xc6fe59c4, nxtip=0xc6fe5a0c, optr=1) at > /usr/src/sys/dev/isp/isp_pci.c:2781 > #8 0xc04e96a1 in isp_action (sim=0xc7198e00, ccb=0xc73bd400) at > /usr/src/sys/dev/isp/isp_freebsd.c:1373 > #9 0xc0449104 in xpt_run_dev_sendq (bus=0xc71d65c0) at > /usr/src/sys/cam/cam_xpt.c:3894 > #10 0xc04495ce in xpt_action (start_ccb=0xc73bd400) at > /usr/src/sys/cam/cam_xpt.c:3056 > #11 0xc0466ee6 in targsendccb (softc=0xc744ee00, ccb=0xc73bd400, > descr=0xc7b80020) at /usr/src/sys/cam/scsi/scsi_target.c:787 > #12 0xc0467027 in targstart (periph=0xc71cc700, start_ccb=0xc73bd400) > at /usr/src/sys/cam/scsi/scsi_target.c:654 > #13 0xc044dd1d in xpt_run_dev_allocq (bus=0xc71d65c0) at > /usr/src/sys/cam/cam_xpt.c:3765 > #14 0xc044e0ad in xpt_schedule (perph=0xc71cc700, new_priority=1) at > /usr/src/sys/cam/cam_xpt.c:3665 > #15 0xc04684f4 in targwrite (dev=0xc7681000, uio=0xc6fe5c60, ioflag=0) > at /usr/src/sys/cam/scsi/scsi_target.c:599 > #16 0xc0586359 in giant_write (dev=0xc7681000, uio=0xc6fe5c60, > ioflag=0) at /usr/src/sys/kern/kern_conf.c:434 > #17 0xc054cbde in devfs_write_f (fp=0xc7631b94, uio=0xc6fe5c60, > cred=0xc7681600, flags=0, td=0xc7889240) at > /usr/src/sys/fs/devfs/devfs_vnops.c:1446 > #18 0xc05ff917 in dofilewrite (td=0xc7889240, fd=4, fp=0xc7631b94, > auio=0xc6fe5c60, offset=-1, flags=0) at file.h:257 > #19 0xc05ffbf8 in kern_writev (td=0xc7889240, fd=4, auio=0xc6fe5c60) > at /usr/src/sys/kern/sys_generic.c:402 > #20 0xc05ffc6f in write (td=0xc7889240, uap=0xc6fe5cfc) at > /usr/src/sys/kern/sys_generic.c:318 > #21 0xc0825e75 in syscall (frame=0xc6fe5d38) at > /usr/src/sys/i386/i386/trap.c:1101 > #22 0xc080a240 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:262 > #23 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Platform is a pair of HP DL580-G3 servers, quad 2.8GHz Xeon CPU's with > 4 gigs of ram in each (x86-32/i386, not x86-64/amd64). I've tried this > with and without the device.hints options, all resulting in a core > dump on the target and a hang on the initiator until the card in the > target gets reset on reboot. > > Any thoughts would be great. I'd like to get a SQL server up on these > FC cards. I understand I could use iSCSI, but the powers that be have > requested FC. > From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 02:18:01 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA0721065760 for ; Wed, 21 Apr 2010 02:17:59 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id BCA578FC12 for ; Wed, 21 Apr 2010 02:17:59 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id B5ECA439E3C; Tue, 20 Apr 2010 21:18:25 -0500 (CDT) Message-ID: <4BCE6E5F.7020000@fuujingroup.com> Date: Tue, 20 Apr 2010 21:17:51 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matthew Jacob References: <4BCE6988.1060302@fuujingroup.com> <4BCE6016.5020108@feral.com> In-Reply-To: <4BCE6016.5020108@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: isp and scsi_target 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, 21 Apr 2010 02:18:01 -0000 I can provide SSH access to the hardware if you like. Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder Matthew Jacob wrote: > What a mess. > > I need to look at this in detail. The stuff was working (sort of) in > RELENG_8, but got very little testing otherwise. > > > > >> We're trying to get an emulated disk to show up on 7.3-REL and not >> having much luck. This is a point-to-point connection with a pair of >> Qlogic cards (pciconf below). There is no FC switch in between the >> machines, and both cards were defaulted prior to testing (factory BIOS >> settings). The moment I rescan the bus on the initiator, the target >> machine panics and dumps core. The initiator hangs until the FC card >> on the initiator resets, then returns to the prompt (wedge??). >> >> Here's the card (same in both machines though different scsi bus) >> >> isp0@pci0:5:1:0: class=0x0c0400 card=0x00091077 chip=0x23001077 >> rev=0x01 hdr=0x00 >> vendor = 'QLogic Corporation' >> device = 'QLA2300 SANblade 2300 64-bit FC-AL Adapter' >> class = serial bus >> subclass = Fibre Channel >> >> >> I get tons of debugging output on the target machine when launching >> scsi_target with the following command: >> >> test001# scsi_target -d 3:0:0 /usr/home/testuser/target0 >> >> Here's a snip-it of the debugging output on the target machine after >> the above command (goes on for pages): >> >> scsi_target: sending ccb (0x332) >> scsi_target: sending ccb (0x334) >> scsi_target: sending ccb (0x332) >> scsi_target: sending ccb (0x334) >> scsi_target: main loop beginning >> >> Then this when the initiator rescans the bus just before it tanks: >> >> scsi_target: read ready >> scsi_target: event -1 done >> scsi_target: Working on ATIO 0x2825c200 >> scsi_target: tcmd_handle atio 0x2825c200 ctio 0x2825e0c0 atioflags 0x8000 >> >> And this in the log on the initiator when it comes back up: >> >> isp0: bad pdb (110) @ handle 0x1 >> isp0: 0: hdl 0x1 PROB al1 tgt 0 TGT 0x0000e8 => UNK 0x000000; WWNN >> 0x200000e08b08f56d WWPN 0x210000e08b08f56d >> >> >> Here's the relevant kernel info on the target: >> >> # ISP SCSI Controllers >> device isp # Qlogic family >> device ispfw # Firmware for QLogic HBAs >> options ISP_TARGET_MODE # Qlogic family target mode >> device targ >> device targbh >> options CAMDEBUG >> options VFS_AIO >> >> /boot/device.hints on the target: >> >> hint.isp.0.fullduplex="1" >> hint.isp.0.topology="nport-only" >> hint.isp.0.role="target" >> >> Here's the relevant kernel info on the initiator: >> >> # ISP SCSI Controllers >> device isp # Qlogic family >> device ispfw # Firmware for QLogic HBAs >> device targ >> device targbh >> options CAMDEBUG >> options VFS_AIO >> >> /boot/device.hints on the initiator: >> >> hint.isp.0.fullduplex="1" >> hint.isp.0.topology="nport-only" >> hint.isp.0.role="initiator" >> hint.isp.0.iid="4" >> >> >> I'm seeing this in the syslog on the initiator: >> >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, >> resid 36, status not marked) >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, >> resid 36, status not marked) >> >> >> Here's the bt for the core dump after the panic which looks to be >> pretty useless from my observation (I'd _love_ to be wrong!!): >> >> test001# kgdb kernel.debug /var/crash/vmcore.0 >> >> Unread portion of the kernel message buffer: >> (targ0:isp0:0:0:0): targdone 0xc7b7b400 >> (targ0:isp0:0:0:0): targread >> (targ0:isp0:0:0:0): targread ccb 0xc7b7b400 (0x2825c200) >> (targ0:isp0:0:0:0): targreturnccb 0xc7b7b400 >> cam_debug: targfreeccb descr 0xc7b80060 and >> cam_debug: freeing ccb 0xc7b7b400 >> (targ0:isp0:0:0:0): write - uio_resid 4 >> (targ0:isp0:0:0:0): Sending queued ccb 0x933 (0x2825e0c0) >> (targ0:isp0:0:0:0): targstart 0xc73bd400 >> (targ0:isp0:0:0:0): sendccb 0xc73bd400 >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 4; apic id = 04 >> fault virtual address = 0x4 >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc04f0a66 >> stack pointer = 0x28:0xc6fe5900 >> frame pointer = 0x28:0xc6fe5950 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 639 (scsi_target) >> trap number = 12 >> panic: page fault >> cpuid = 4 >> Uptime: 51s >> Physical memory: 3767 MB >> Dumping 102 MB: 87 71 55 39 23 7 >> >> Reading symbols from /boot/kernel/ispfw.ko...Reading symbols from >> /boot/kernel/ispfw.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/ispfw.ko >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from >> /boot/kernel/acpi.ko.symbols...done. >> done. >> Loaded symbols for /boot/kernel/acpi.ko >> #0 doadump () at pcpu.h:196 >> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); >> (kgdb) bt >> #0 doadump () at pcpu.h:196 >> #1 0xc05c4e87 in boot (howto=260) at >> /usr/src/sys/kern/kern_shutdown.c:418 >> #2 0xc05c5159 in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:574 >> #3 0xc08258bc in trap_fatal (frame=0xc6fe58c0, eva=4) at >> /usr/src/sys/i386/i386/trap.c:950 >> #4 0xc0825b20 in trap_pfault (frame=0xc6fe58c0, usermode=0, eva=4) at >> /usr/src/sys/i386/i386/trap.c:863 >> #5 0xc08264d9 in trap (frame=0xc6fe58c0) at >> /usr/src/sys/i386/i386/trap.c:541 >> #6 0xc080a1db in calltrap () at /usr/src/sys/i386/i386/exception.s:166 >> #7 0xc04f0a66 in isp_pci_dmasetup (isp=0xc71de000, csio=0xc73bd400, >> rq=0xc6fe59c4, nxtip=0xc6fe5a0c, optr=1) at >> /usr/src/sys/dev/isp/isp_pci.c:2781 >> #8 0xc04e96a1 in isp_action (sim=0xc7198e00, ccb=0xc73bd400) at >> /usr/src/sys/dev/isp/isp_freebsd.c:1373 >> #9 0xc0449104 in xpt_run_dev_sendq (bus=0xc71d65c0) at >> /usr/src/sys/cam/cam_xpt.c:3894 >> #10 0xc04495ce in xpt_action (start_ccb=0xc73bd400) at >> /usr/src/sys/cam/cam_xpt.c:3056 >> #11 0xc0466ee6 in targsendccb (softc=0xc744ee00, ccb=0xc73bd400, >> descr=0xc7b80020) at /usr/src/sys/cam/scsi/scsi_target.c:787 >> #12 0xc0467027 in targstart (periph=0xc71cc700, start_ccb=0xc73bd400) >> at /usr/src/sys/cam/scsi/scsi_target.c:654 >> #13 0xc044dd1d in xpt_run_dev_allocq (bus=0xc71d65c0) at >> /usr/src/sys/cam/cam_xpt.c:3765 >> #14 0xc044e0ad in xpt_schedule (perph=0xc71cc700, new_priority=1) at >> /usr/src/sys/cam/cam_xpt.c:3665 >> #15 0xc04684f4 in targwrite (dev=0xc7681000, uio=0xc6fe5c60, ioflag=0) >> at /usr/src/sys/cam/scsi/scsi_target.c:599 >> #16 0xc0586359 in giant_write (dev=0xc7681000, uio=0xc6fe5c60, >> ioflag=0) at /usr/src/sys/kern/kern_conf.c:434 >> #17 0xc054cbde in devfs_write_f (fp=0xc7631b94, uio=0xc6fe5c60, >> cred=0xc7681600, flags=0, td=0xc7889240) at >> /usr/src/sys/fs/devfs/devfs_vnops.c:1446 >> #18 0xc05ff917 in dofilewrite (td=0xc7889240, fd=4, fp=0xc7631b94, >> auio=0xc6fe5c60, offset=-1, flags=0) at file.h:257 >> #19 0xc05ffbf8 in kern_writev (td=0xc7889240, fd=4, auio=0xc6fe5c60) >> at /usr/src/sys/kern/sys_generic.c:402 >> #20 0xc05ffc6f in write (td=0xc7889240, uap=0xc6fe5cfc) at >> /usr/src/sys/kern/sys_generic.c:318 >> #21 0xc0825e75 in syscall (frame=0xc6fe5d38) at >> /usr/src/sys/i386/i386/trap.c:1101 >> #22 0xc080a240 in Xint0x80_syscall () at >> /usr/src/sys/i386/i386/exception.s:262 >> #23 0x00000033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> >> Platform is a pair of HP DL580-G3 servers, quad 2.8GHz Xeon CPU's with >> 4 gigs of ram in each (x86-32/i386, not x86-64/amd64). I've tried this >> with and without the device.hints options, all resulting in a core >> dump on the target and a hang on the initiator until the card in the >> target gets reset on reboot. >> >> Any thoughts would be great. I'd like to get a SQL server up on these >> FC cards. I understand I could use iSCSI, but the powers that be have >> requested FC. >> > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 02:21:11 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08D321065678 for ; Wed, 21 Apr 2010 02:21:11 +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 90C068FC21 for ; Wed, 21 Apr 2010 02:21:10 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o3L2LAcO054047 for ; Tue, 20 Apr 2010 19:21:10 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BCE612C.9080201@feral.com> Date: Tue, 20 Apr 2010 19:21:32 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BCE6988.1060302@fuujingroup.com> <4BCE6016.5020108@feral.com> <4BCE6E5F.7020000@fuujingroup.com> In-Reply-To: <4BCE6E5F.7020000@fuujingroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Tue, 20 Apr 2010 19:21:10 -0700 (PDT) Subject: Re: isp and scsi_target 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, 21 Apr 2010 02:21:11 -0000 Somebody else may be able to help quicker. I have to get a couple of things of my plate and then do a little recabling in my lab and see just what the current state of things are for me. To be frank, I have not tried with the user level target in quite some time. It used to just plain hang for me for a year or so. I think that got fixed recently, but I really then didn't go back and recheck with this kind of target mode stack. I'll try and make some progress tomorrow on getting up to speed on it again. From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 02:33:48 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D15CA106566B for ; Wed, 21 Apr 2010 02:33:48 +0000 (UTC) (envelope-from erich@fuujingroup.com) Received: from fluorine.fuujinnetworks.com (fluorine.fuujinnetworks.com [64.90.67.234]) by mx1.freebsd.org (Postfix) with ESMTP id ACB568FC15 for ; Wed, 21 Apr 2010 02:33:48 +0000 (UTC) Received: from [10.168.1.8] (copper.fuujinnetworks.com [64.90.67.254]) by fluorine.fuujinnetworks.com (Postfix) with ESMTPA id 54995439E38; Tue, 20 Apr 2010 21:34:14 -0500 (CDT) Message-ID: <4BCE7213.4080000@fuujingroup.com> Date: Tue, 20 Apr 2010 21:33:39 -0600 From: "Erich Jenkins, Fuujin Group Ltd" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Matthew Jacob References: <4BCE6988.1060302@fuujingroup.com> <4BCE6016.5020108@feral.com> <4BCE6E5F.7020000@fuujingroup.com> <4BCE612C.9080201@feral.com> In-Reply-To: <4BCE612C.9080201@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: isp and scsi_target 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, 21 Apr 2010 02:33:48 -0000 I appreciate the help, but I should mention that though the requirement is FC, there is nothing in the specification identifying a particular vendor. If there's another FC card anyone could recommend (LSI?) I'm happy to explore that as well. Erich M. Jenkins Fuujin Group Limited "You should never, never doubt what no one is sure about." -- Gene Wilder Matthew Jacob wrote: > Somebody else may be able to help quicker. I have to get a couple of > things of my plate and then do a little recabling in my lab and see just > what the current state of things are for me. > > To be frank, I have not tried with the user level target in quite some > time. It used to just plain hang for me for a year or so. I think that > got fixed recently, but I really then didn't go back and recheck with > this kind of target mode stack. > > I'll try and make some progress tomorrow on getting up to speed on it > again. > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 02:37:59 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2726106566C for ; Wed, 21 Apr 2010 02:37:59 +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 6C6258FC18 for ; Wed, 21 Apr 2010 02:37:59 +0000 (UTC) Received: from [192.168.0.102] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o3L2bwud054153 for ; Tue, 20 Apr 2010 19:37:58 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4BCE651D.4000406@feral.com> Date: Tue, 20 Apr 2010 19:38:21 -0700 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BCE6988.1060302@fuujingroup.com> <4BCE6016.5020108@feral.com> <4BCE6E5F.7020000@fuujingroup.com> <4BCE612C.9080201@feral.com> <4BCE7213.4080000@fuujingroup.com> In-Reply-To: <4BCE7213.4080000@fuujingroup.com> X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Tue, 20 Apr 2010 19:37:59 -0700 (PDT) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: isp and scsi_target 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, 21 Apr 2010 02:37:59 -0000 On 4/20/2010 8:33 PM, Erich Jenkins, Fuujin Group Ltd wrote: > I appreciate the help, but I should mention that though the > requirement is FC, there is nothing in the specification identifying a > particular vendor. If there's another FC card anyone could recommend > (LSI?) I'm happy to explore that as well. I don't think anyone has touched the LSI target mode code since I put it in some years back. I got it working for a prototype, and then the company that was funding it all laid everyone on the project off. That was, uh, 2007 I think. The isp stuff /should/ be working. I've been trying to get out of the storage ghetto for some time now, but I do feel some responsibility for it. I've been hoping smarter and younger people would take it over, but so far, no luck. From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 17:18:53 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21E23106566B for ; Wed, 21 Apr 2010 17:18:53 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id CAD368FC0A for ; Wed, 21 Apr 2010 17:18:52 +0000 (UTC) Received: from [127.0.0.1] (proxy8.corp.yahoo.com [216.145.48.13]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o3LH5ukb088788; Wed, 21 Apr 2010 10:05:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:cc:in-reply-to:references:content-type:date: message-id:mime-version:x-mailer:content-transfer-encoding; b=hLdhtD1SizPrjUAgbrYINpiyqTviSoGNTpS8bLQrvtFXCT5LqNgSJaOt9NjcxkzV From: Sean Bruno To: "Erich Jenkins, Fuujin Group Ltd" In-Reply-To: <4BCE6E5F.7020000@fuujingroup.com> References: <4BCE6988.1060302@fuujingroup.com> <4BCE6016.5020108@feral.com> <4BCE6E5F.7020000@fuujingroup.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 21 Apr 2010 10:05:56 -0700 Message-ID: <1271869556.2440.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Cc: "freebsd-scsi@freebsd.org" , Matthew Jacob Subject: Re: isp and scsi_target 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, 21 Apr 2010 17:18:53 -0000 I think I can be of assistance here. If you can give me an account on the box, I might be able to unblock you. Sean On Tue, 2010-04-20 at 20:17 -0700, Erich Jenkins, Fuujin Group Ltd wrote: > I can provide SSH access to the hardware if you like. > > > Erich M. Jenkins > Fuujin Group Limited > > "You should never, never doubt what no one is sure about." > -- Gene Wilder > > > Matthew Jacob wrote: > > What a mess. > > > > I need to look at this in detail. The stuff was working (sort of) in > > RELENG_8, but got very little testing otherwise. > > > > > > > > > >> We're trying to get an emulated disk to show up on 7.3-REL and not > >> having much luck. This is a point-to-point connection with a pair of > >> Qlogic cards (pciconf below). There is no FC switch in between the > >> machines, and both cards were defaulted prior to testing (factory BIOS > >> settings). The moment I rescan the bus on the initiator, the target > >> machine panics and dumps core. The initiator hangs until the FC card > >> on the initiator resets, then returns to the prompt (wedge??). > >> > >> Here's the card (same in both machines though different scsi bus) > >> > >> isp0@pci0:5:1:0: class=0x0c0400 card=0x00091077 chip=0x23001077 > >> rev=0x01 hdr=0x00 > >> vendor = 'QLogic Corporation' > >> device = 'QLA2300 SANblade 2300 64-bit FC-AL Adapter' > >> class = serial bus > >> subclass = Fibre Channel > >> > >> > >> I get tons of debugging output on the target machine when launching > >> scsi_target with the following command: > >> > >> test001# scsi_target -d 3:0:0 /usr/home/testuser/target0 > >> > >> Here's a snip-it of the debugging output on the target machine after > >> the above command (goes on for pages): > >> > >> scsi_target: sending ccb (0x332) > >> scsi_target: sending ccb (0x334) > >> scsi_target: sending ccb (0x332) > >> scsi_target: sending ccb (0x334) > >> scsi_target: main loop beginning > >> > >> Then this when the initiator rescans the bus just before it tanks: > >> > >> scsi_target: read ready > >> scsi_target: event -1 done > >> scsi_target: Working on ATIO 0x2825c200 > >> scsi_target: tcmd_handle atio 0x2825c200 ctio 0x2825e0c0 atioflags 0x8000 > >> > >> And this in the log on the initiator when it comes back up: > >> > >> isp0: bad pdb (110) @ handle 0x1 > >> isp0: 0: hdl 0x1 PROB al1 tgt 0 TGT 0x0000e8 => UNK 0x000000; WWNN > >> 0x200000e08b08f56d WWPN 0x210000e08b08f56d > >> > >> > >> Here's the relevant kernel info on the target: > >> > >> # ISP SCSI Controllers > >> device isp # Qlogic family > >> device ispfw # Firmware for QLogic HBAs > >> options ISP_TARGET_MODE # Qlogic family target mode > >> device targ > >> device targbh > >> options CAMDEBUG > >> options VFS_AIO > >> > >> /boot/device.hints on the target: > >> > >> hint.isp.0.fullduplex="1" > >> hint.isp.0.topology="nport-only" > >> hint.isp.0.role="target" > >> > >> Here's the relevant kernel info on the initiator: > >> > >> # ISP SCSI Controllers > >> device isp # Qlogic family > >> device ispfw # Firmware for QLogic HBAs > >> device targ > >> device targbh > >> options CAMDEBUG > >> options VFS_AIO > >> > >> /boot/device.hints on the initiator: > >> > >> hint.isp.0.fullduplex="1" > >> hint.isp.0.topology="nport-only" > >> hint.isp.0.role="initiator" > >> hint.isp.0.iid="4" > >> > >> > >> I'm seeing this in the syslog on the initiator: > >> > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > >> resid 36, status not marked) > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > >> resid 36, status not marked) > >> > >> > >> Here's the bt for the core dump after the panic which looks to be > >> pretty useless from my observation (I'd _love_ to be wrong!!): > >> > >> test001# kgdb kernel.debug /var/crash/vmcore.0 > >> > >> Unread portion of the kernel message buffer: > >> (targ0:isp0:0:0:0): targdone 0xc7b7b400 > >> (targ0:isp0:0:0:0): targread > >> (targ0:isp0:0:0:0): targread ccb 0xc7b7b400 (0x2825c200) > >> (targ0:isp0:0:0:0): targreturnccb 0xc7b7b400 > >> cam_debug: targfreeccb descr 0xc7b80060 and > >> cam_debug: freeing ccb 0xc7b7b400 > >> (targ0:isp0:0:0:0): write - uio_resid 4 > >> (targ0:isp0:0:0:0): Sending queued ccb 0x933 (0x2825e0c0) > >> (targ0:isp0:0:0:0): targstart 0xc73bd400 > >> (targ0:isp0:0:0:0): sendccb 0xc73bd400 > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 4; apic id = 04 > >> fault virtual address = 0x4 > >> fault code = supervisor read, page not present > >> instruction pointer = 0x20:0xc04f0a66 > >> stack pointer = 0x28:0xc6fe5900 > >> frame pointer = 0x28:0xc6fe5950 > >> code segment = base 0x0, limit 0xfffff, type 0x1b > >> = DPL 0, pres 1, def32 1, gran 1 > >> processor eflags = interrupt enabled, resume, IOPL = 0 > >> current process = 639 (scsi_target) > >> trap number = 12 > >> panic: page fault > >> cpuid = 4 > >> Uptime: 51s > >> Physical memory: 3767 MB > >> Dumping 102 MB: 87 71 55 39 23 7 > >> > >> Reading symbols from /boot/kernel/ispfw.ko...Reading symbols from > >> /boot/kernel/ispfw.ko.symbols...done. > >> done. > >> Loaded symbols for /boot/kernel/ispfw.ko > >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > >> /boot/kernel/acpi.ko.symbols...done. > >> done. > >> Loaded symbols for /boot/kernel/acpi.ko > >> #0 doadump () at pcpu.h:196 > >> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > >> (kgdb) bt > >> #0 doadump () at pcpu.h:196 > >> #1 0xc05c4e87 in boot (howto=260) at > >> /usr/src/sys/kern/kern_shutdown.c:418 > >> #2 0xc05c5159 in panic (fmt=Variable "fmt" is not available. > >> ) at /usr/src/sys/kern/kern_shutdown.c:574 > >> #3 0xc08258bc in trap_fatal (frame=0xc6fe58c0, eva=4) at > >> /usr/src/sys/i386/i386/trap.c:950 > >> #4 0xc0825b20 in trap_pfault (frame=0xc6fe58c0, usermode=0, eva=4) at > >> /usr/src/sys/i386/i386/trap.c:863 > >> #5 0xc08264d9 in trap (frame=0xc6fe58c0) at > >> /usr/src/sys/i386/i386/trap.c:541 > >> #6 0xc080a1db in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > >> #7 0xc04f0a66 in isp_pci_dmasetup (isp=0xc71de000, csio=0xc73bd400, > >> rq=0xc6fe59c4, nxtip=0xc6fe5a0c, optr=1) at > >> /usr/src/sys/dev/isp/isp_pci.c:2781 > >> #8 0xc04e96a1 in isp_action (sim=0xc7198e00, ccb=0xc73bd400) at > >> /usr/src/sys/dev/isp/isp_freebsd.c:1373 > >> #9 0xc0449104 in xpt_run_dev_sendq (bus=0xc71d65c0) at > >> /usr/src/sys/cam/cam_xpt.c:3894 > >> #10 0xc04495ce in xpt_action (start_ccb=0xc73bd400) at > >> /usr/src/sys/cam/cam_xpt.c:3056 > >> #11 0xc0466ee6 in targsendccb (softc=0xc744ee00, ccb=0xc73bd400, > >> descr=0xc7b80020) at /usr/src/sys/cam/scsi/scsi_target.c:787 > >> #12 0xc0467027 in targstart (periph=0xc71cc700, start_ccb=0xc73bd400) > >> at /usr/src/sys/cam/scsi/scsi_target.c:654 > >> #13 0xc044dd1d in xpt_run_dev_allocq (bus=0xc71d65c0) at > >> /usr/src/sys/cam/cam_xpt.c:3765 > >> #14 0xc044e0ad in xpt_schedule (perph=0xc71cc700, new_priority=1) at > >> /usr/src/sys/cam/cam_xpt.c:3665 > >> #15 0xc04684f4 in targwrite (dev=0xc7681000, uio=0xc6fe5c60, ioflag=0) > >> at /usr/src/sys/cam/scsi/scsi_target.c:599 > >> #16 0xc0586359 in giant_write (dev=0xc7681000, uio=0xc6fe5c60, > >> ioflag=0) at /usr/src/sys/kern/kern_conf.c:434 > >> #17 0xc054cbde in devfs_write_f (fp=0xc7631b94, uio=0xc6fe5c60, > >> cred=0xc7681600, flags=0, td=0xc7889240) at > >> /usr/src/sys/fs/devfs/devfs_vnops.c:1446 > >> #18 0xc05ff917 in dofilewrite (td=0xc7889240, fd=4, fp=0xc7631b94, > >> auio=0xc6fe5c60, offset=-1, flags=0) at file.h:257 > >> #19 0xc05ffbf8 in kern_writev (td=0xc7889240, fd=4, auio=0xc6fe5c60) > >> at /usr/src/sys/kern/sys_generic.c:402 > >> #20 0xc05ffc6f in write (td=0xc7889240, uap=0xc6fe5cfc) at > >> /usr/src/sys/kern/sys_generic.c:318 > >> #21 0xc0825e75 in syscall (frame=0xc6fe5d38) at > >> /usr/src/sys/i386/i386/trap.c:1101 > >> #22 0xc080a240 in Xint0x80_syscall () at > >> /usr/src/sys/i386/i386/exception.s:262 > >> #23 0x00000033 in ?? () > >> Previous frame inner to this frame (corrupt stack?) > >> (kgdb) > >> > >> Platform is a pair of HP DL580-G3 servers, quad 2.8GHz Xeon CPU's with > >> 4 gigs of ram in each (x86-32/i386, not x86-64/amd64). I've tried this > >> with and without the device.hints options, all resulting in a core > >> dump on the target and a hang on the initiator until the card in the > >> target gets reset on reboot. > >> > >> Any thoughts would be great. I'd like to get a SQL server up on these > >> FC cards. I understand I could use iSCSI, but the powers that be have > >> requested FC. > >> > > > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Wed Apr 21 20:06:08 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C117C106564A for ; Wed, 21 Apr 2010 20:06:08 +0000 (UTC) (envelope-from p.christias@noc.ntua.gr) Received: from diomedes.noc.ntua.gr (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0E78FC1C for ; Wed, 21 Apr 2010 20:06:07 +0000 (UTC) Received: from ajax.noc.ntua.gr (ajax6.noc.ntua.gr [IPv6:2001:648:2000:dc::1]) by diomedes.noc.ntua.gr (8.14.3/8.14.3) with ESMTP id o3LK65Om043105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Apr 2010 23:06:05 +0300 (EEST) (envelope-from p.christias@noc.ntua.gr) Received: from ajax.noc.ntua.gr (localhost [127.0.0.1]) by ajax.noc.ntua.gr (8.14.3/8.14.3) with ESMTP id o3LK64m9031792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Apr 2010 23:06:04 +0300 (EEST) (envelope-from p.christias@noc.ntua.gr) Received: (from christia@localhost) by ajax.noc.ntua.gr (8.14.3/8.14.3/Submit) id o3LK64M9031791; Wed, 21 Apr 2010 23:06:04 +0300 (EEST) (envelope-from p.christias@noc.ntua.gr) X-Authentication-Warning: ajax.noc.ntua.gr: christia set sender to p.christias@noc.ntua.gr using -f Date: Wed, 21 Apr 2010 23:06:04 +0300 From: Panagiotis Christias To: "Erich Jenkins, Fuujin Group Ltd" Message-ID: <20100421200603.GA31467@noc.ntua.gr> References: <4BCE6988.1060302@fuujingroup.com> <4BCE6016.5020108@feral.com> <4BCE6E5F.7020000@fuujingroup.com> <1271869556.2440.5.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1271869556.2440.5.camel@localhost.localdomain> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.3 at diomedes.noc.ntua.gr X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (diomedes.noc.ntua.gr [IPv6:2001:648:2000:de::220]); Wed, 21 Apr 2010 23:06:05 +0300 (EEST) Cc: "freebsd-scsi@freebsd.org" Subject: Re: isp and scsi_target 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, 21 Apr 2010 20:06:08 -0000 Hello, 7.3-RELEASE does not have the latest version of the isp/ispfw(4) driver. You should try 7-STABLE at least for the kernel (userland does not matter). Let me know of the results, I am interested too. Regards, Panagiotis On Wed, Apr 21, 2010 at 10:05:56AM -0700, Sean Bruno wrote: > I think I can be of assistance here. If you can give me an account on > the box, I might be able to unblock you. > > Sean > > On Tue, 2010-04-20 at 20:17 -0700, Erich Jenkins, Fuujin Group Ltd > wrote: > > I can provide SSH access to the hardware if you like. > > > > > > Erich M. Jenkins > > Fuujin Group Limited > > > > "You should never, never doubt what no one is sure about." > > -- Gene Wilder > > > > > > Matthew Jacob wrote: > > > What a mess. > > > > > > I need to look at this in detail. The stuff was working (sort of) in > > > RELENG_8, but got very little testing otherwise. > > > > > > > > > > > > > > >> We're trying to get an emulated disk to show up on 7.3-REL and not > > >> having much luck. This is a point-to-point connection with a pair of > > >> Qlogic cards (pciconf below). There is no FC switch in between the > > >> machines, and both cards were defaulted prior to testing (factory BIOS > > >> settings). The moment I rescan the bus on the initiator, the target > > >> machine panics and dumps core. The initiator hangs until the FC card > > >> on the initiator resets, then returns to the prompt (wedge??). > > >> > > >> Here's the card (same in both machines though different scsi bus) > > >> > > >> isp0@pci0:5:1:0: class=0x0c0400 card=0x00091077 chip=0x23001077 > > >> rev=0x01 hdr=0x00 > > >> vendor = 'QLogic Corporation' > > >> device = 'QLA2300 SANblade 2300 64-bit FC-AL Adapter' > > >> class = serial bus > > >> subclass = Fibre Channel > > >> > > >> > > >> I get tons of debugging output on the target machine when launching > > >> scsi_target with the following command: > > >> > > >> test001# scsi_target -d 3:0:0 /usr/home/testuser/target0 > > >> > > >> Here's a snip-it of the debugging output on the target machine after > > >> the above command (goes on for pages): > > >> > > >> scsi_target: sending ccb (0x332) > > >> scsi_target: sending ccb (0x334) > > >> scsi_target: sending ccb (0x332) > > >> scsi_target: sending ccb (0x334) > > >> scsi_target: main loop beginning > > >> > > >> Then this when the initiator rescans the bus just before it tanks: > > >> > > >> scsi_target: read ready > > >> scsi_target: event -1 done > > >> scsi_target: Working on ATIO 0x2825c200 > > >> scsi_target: tcmd_handle atio 0x2825c200 ctio 0x2825e0c0 atioflags 0x8000 > > >> > > >> And this in the log on the initiator when it comes back up: > > >> > > >> isp0: bad pdb (110) @ handle 0x1 > > >> isp0: 0: hdl 0x1 PROB al1 tgt 0 TGT 0x0000e8 => UNK 0x000000; WWNN > > >> 0x200000e08b08f56d WWPN 0x210000e08b08f56d > > >> > > >> > > >> Here's the relevant kernel info on the target: > > >> > > >> # ISP SCSI Controllers > > >> device isp # Qlogic family > > >> device ispfw # Firmware for QLogic HBAs > > >> options ISP_TARGET_MODE # Qlogic family target mode > > >> device targ > > >> device targbh > > >> options CAMDEBUG > > >> options VFS_AIO > > >> > > >> /boot/device.hints on the target: > > >> > > >> hint.isp.0.fullduplex="1" > > >> hint.isp.0.topology="nport-only" > > >> hint.isp.0.role="target" > > >> > > >> Here's the relevant kernel info on the initiator: > > >> > > >> # ISP SCSI Controllers > > >> device isp # Qlogic family > > >> device ispfw # Firmware for QLogic HBAs > > >> device targ > > >> device targbh > > >> options CAMDEBUG > > >> options VFS_AIO > > >> > > >> /boot/device.hints on the initiator: > > >> > > >> hint.isp.0.fullduplex="1" > > >> hint.isp.0.topology="nport-only" > > >> hint.isp.0.role="initiator" > > >> hint.isp.0.iid="4" > > >> > > >> > > >> I'm seeing this in the syslog on the initiator: > > >> > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.5 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.6 (count 36, > > >> resid 36, status not marked) > > >> Apr 20 22:21:28 test002 kernel: isp0: bad underrun for 0.7 (count 36, > > >> resid 36, status not marked) > > >> > > >> > > >> Here's the bt for the core dump after the panic which looks to be > > >> pretty useless from my observation (I'd _love_ to be wrong!!): > > >> > > >> test001# kgdb kernel.debug /var/crash/vmcore.0 > > >> > > >> Unread portion of the kernel message buffer: > > >> (targ0:isp0:0:0:0): targdone 0xc7b7b400 > > >> (targ0:isp0:0:0:0): targread > > >> (targ0:isp0:0:0:0): targread ccb 0xc7b7b400 (0x2825c200) > > >> (targ0:isp0:0:0:0): targreturnccb 0xc7b7b400 > > >> cam_debug: targfreeccb descr 0xc7b80060 and > > >> cam_debug: freeing ccb 0xc7b7b400 > > >> (targ0:isp0:0:0:0): write - uio_resid 4 > > >> (targ0:isp0:0:0:0): Sending queued ccb 0x933 (0x2825e0c0) > > >> (targ0:isp0:0:0:0): targstart 0xc73bd400 > > >> (targ0:isp0:0:0:0): sendccb 0xc73bd400 > > >> > > >> > > >> Fatal trap 12: page fault while in kernel mode > > >> cpuid = 4; apic id = 04 > > >> fault virtual address = 0x4 > > >> fault code = supervisor read, page not present > > >> instruction pointer = 0x20:0xc04f0a66 > > >> stack pointer = 0x28:0xc6fe5900 > > >> frame pointer = 0x28:0xc6fe5950 > > >> code segment = base 0x0, limit 0xfffff, type 0x1b > > >> = DPL 0, pres 1, def32 1, gran 1 > > >> processor eflags = interrupt enabled, resume, IOPL = 0 > > >> current process = 639 (scsi_target) > > >> trap number = 12 > > >> panic: page fault > > >> cpuid = 4 > > >> Uptime: 51s > > >> Physical memory: 3767 MB > > >> Dumping 102 MB: 87 71 55 39 23 7 > > >> > > >> Reading symbols from /boot/kernel/ispfw.ko...Reading symbols from > > >> /boot/kernel/ispfw.ko.symbols...done. > > >> done. > > >> Loaded symbols for /boot/kernel/ispfw.ko > > >> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from > > >> /boot/kernel/acpi.ko.symbols...done. > > >> done. > > >> Loaded symbols for /boot/kernel/acpi.ko > > >> #0 doadump () at pcpu.h:196 > > >> 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > > >> (kgdb) bt > > >> #0 doadump () at pcpu.h:196 > > >> #1 0xc05c4e87 in boot (howto=260) at > > >> /usr/src/sys/kern/kern_shutdown.c:418 > > >> #2 0xc05c5159 in panic (fmt=Variable "fmt" is not available. > > >> ) at /usr/src/sys/kern/kern_shutdown.c:574 > > >> #3 0xc08258bc in trap_fatal (frame=0xc6fe58c0, eva=4) at > > >> /usr/src/sys/i386/i386/trap.c:950 > > >> #4 0xc0825b20 in trap_pfault (frame=0xc6fe58c0, usermode=0, eva=4) at > > >> /usr/src/sys/i386/i386/trap.c:863 > > >> #5 0xc08264d9 in trap (frame=0xc6fe58c0) at > > >> /usr/src/sys/i386/i386/trap.c:541 > > >> #6 0xc080a1db in calltrap () at /usr/src/sys/i386/i386/exception.s:166 > > >> #7 0xc04f0a66 in isp_pci_dmasetup (isp=0xc71de000, csio=0xc73bd400, > > >> rq=0xc6fe59c4, nxtip=0xc6fe5a0c, optr=1) at > > >> /usr/src/sys/dev/isp/isp_pci.c:2781 > > >> #8 0xc04e96a1 in isp_action (sim=0xc7198e00, ccb=0xc73bd400) at > > >> /usr/src/sys/dev/isp/isp_freebsd.c:1373 > > >> #9 0xc0449104 in xpt_run_dev_sendq (bus=0xc71d65c0) at > > >> /usr/src/sys/cam/cam_xpt.c:3894 > > >> #10 0xc04495ce in xpt_action (start_ccb=0xc73bd400) at > > >> /usr/src/sys/cam/cam_xpt.c:3056 > > >> #11 0xc0466ee6 in targsendccb (softc=0xc744ee00, ccb=0xc73bd400, > > >> descr=0xc7b80020) at /usr/src/sys/cam/scsi/scsi_target.c:787 > > >> #12 0xc0467027 in targstart (periph=0xc71cc700, start_ccb=0xc73bd400) > > >> at /usr/src/sys/cam/scsi/scsi_target.c:654 > > >> #13 0xc044dd1d in xpt_run_dev_allocq (bus=0xc71d65c0) at > > >> /usr/src/sys/cam/cam_xpt.c:3765 > > >> #14 0xc044e0ad in xpt_schedule (perph=0xc71cc700, new_priority=1) at > > >> /usr/src/sys/cam/cam_xpt.c:3665 > > >> #15 0xc04684f4 in targwrite (dev=0xc7681000, uio=0xc6fe5c60, ioflag=0) > > >> at /usr/src/sys/cam/scsi/scsi_target.c:599 > > >> #16 0xc0586359 in giant_write (dev=0xc7681000, uio=0xc6fe5c60, > > >> ioflag=0) at /usr/src/sys/kern/kern_conf.c:434 > > >> #17 0xc054cbde in devfs_write_f (fp=0xc7631b94, uio=0xc6fe5c60, > > >> cred=0xc7681600, flags=0, td=0xc7889240) at > > >> /usr/src/sys/fs/devfs/devfs_vnops.c:1446 > > >> #18 0xc05ff917 in dofilewrite (td=0xc7889240, fd=4, fp=0xc7631b94, > > >> auio=0xc6fe5c60, offset=-1, flags=0) at file.h:257 > > >> #19 0xc05ffbf8 in kern_writev (td=0xc7889240, fd=4, auio=0xc6fe5c60) > > >> at /usr/src/sys/kern/sys_generic.c:402 > > >> #20 0xc05ffc6f in write (td=0xc7889240, uap=0xc6fe5cfc) at > > >> /usr/src/sys/kern/sys_generic.c:318 > > >> #21 0xc0825e75 in syscall (frame=0xc6fe5d38) at > > >> /usr/src/sys/i386/i386/trap.c:1101 > > >> #22 0xc080a240 in Xint0x80_syscall () at > > >> /usr/src/sys/i386/i386/exception.s:262 > > >> #23 0x00000033 in ?? () > > >> Previous frame inner to this frame (corrupt stack?) > > >> (kgdb) > > >> > > >> Platform is a pair of HP DL580-G3 servers, quad 2.8GHz Xeon CPU's with > > >> 4 gigs of ram in each (x86-32/i386, not x86-64/amd64). I've tried this > > >> with and without the device.hints options, all resulting in a core > > >> dump on the target and a hang on the initiator until the card in the > > >> target gets reset on reboot. > > >> > > >> Any thoughts would be great. I'd like to get a SQL server up on these > > >> FC cards. I understand I could use iSCSI, but the powers that be have > > >> requested FC. > > >> > > > > > > _______________________________________________ > > > freebsd-scsi@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-scsi@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" -- Panagiotis J. Christias Network Management Center P.Christias@noc.ntua.gr National Technical Univ. of Athens, GREECE From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 23 16:49:02 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA6491065790 for ; Fri, 23 Apr 2010 16:49:02 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1A58FC18 for ; Fri, 23 Apr 2010 16:49:01 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA10146 for ; Fri, 23 Apr 2010 19:32:40 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BD1CBA7.6020405@freebsd.org> Date: Fri, 23 Apr 2010 19:32:39 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4BCDEBF6.3030609@icyb.net.ua> In-Reply-To: <4BCDEBF6.3030609@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: cam.3: do not discourage use of cam_open_device 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, 23 Apr 2010 16:49:02 -0000 on 20/04/2010 21:01 Andriy Gapon said the following: > This is based on my understanding what Scott Long tried to explain me a while ago. > > Index: lib/libcam/cam.3 > =================================================================== > --- lib/libcam/cam.3 (revision 206902) > +++ lib/libcam/cam.3 (working copy) > @@ -190,12 +190,6 @@ > Once the device name and unit number > are determined, a lookup is performed to determine the passthrough device > that corresponds to the given device. > -.Fn cam_open_device > -is rather simple to use, but it is not really suitable for general use > -because its behavior is not necessarily deterministic. > -Programmers writing > -new applications should make the extra effort to use one of the other open > -routines documented below. > .Pp > .Fn cam_open_spec_device > opens the If no one tries to stop me I will commit this. > It seems that this warning about ambiguity came from pre-devfs days when e.g. cd0 > nodes in different directories could correspond to different actual SCSI > peripherals. It seems that there wasn't an ambiguity if an absolute device path > was given. > > Nowadays, cam_open_device seems to always do a proper job of finding a correct > pass device. > -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 23 18:44:14 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DEE41065670 for ; Fri, 23 Apr 2010 18:44:14 +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 DE0FB8FC14 for ; Fri, 23 Apr 2010 18:44:13 +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 o3NIiDNp006132; Fri, 23 Apr 2010 12:44:13 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id o3NIiDMi006131; Fri, 23 Apr 2010 12:44:13 -0600 (MDT) (envelope-from ken) Date: Fri, 23 Apr 2010 12:44:12 -0600 From: "Kenneth D. Merry" To: Andriy Gapon Message-ID: <20100423184412.GA5016@nargothrond.kdm.org> References: <4BCDEBF6.3030609@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCDEBF6.3030609@icyb.net.ua> User-Agent: Mutt/1.4.2i Cc: freebsd-scsi@freebsd.org Subject: Re: cam.3: do not discourage use of cam_open_device 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, 23 Apr 2010 18:44:14 -0000 On Tue, Apr 20, 2010 at 21:01:26 +0300, Andriy Gapon wrote: > > This is based on my understanding what Scott Long tried to explain me a while ago. > > Index: lib/libcam/cam.3 > =================================================================== > --- lib/libcam/cam.3 (revision 206902) > +++ lib/libcam/cam.3 (working copy) > @@ -190,12 +190,6 @@ > Once the device name and unit number > are determined, a lookup is performed to determine the passthrough device > that corresponds to the given device. > -.Fn cam_open_device > -is rather simple to use, but it is not really suitable for general use > -because its behavior is not necessarily deterministic. > -Programmers writing > -new applications should make the extra effort to use one of the other open > -routines documented below. > .Pp > .Fn cam_open_spec_device > opens the > > > It seems that this warning about ambiguity came from pre-devfs days when e.g. cd0 > nodes in different directories could correspond to different actual SCSI > peripherals. It seems that there wasn't an ambiguity if an absolute device path > was given. > > Nowadays, cam_open_device seems to always do a proper job of finding a correct > pass device. The warning had more to do with the ambiguity trying to make sense of device names than having different device nodes lying around. cam_get_device() (which is called by cam_open_device()) tries to do some things that will break on devices that start with n (unless it's a non-rewound tape device) or r. Right now we don't have any CAM peripheral drivers that start with those letters, so it works. It also won't do the right thing on devices with gpt partitions. Some of that can be fixed, though. So it's mostly deterministic, but it may not do exactly what you expect. It may be good to keep some statement in there pointing people to the other routines as being preferred because they're a little more deterministic. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-scsi@FreeBSD.ORG Fri Apr 23 20:00:56 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5CA2106566C for ; Fri, 23 Apr 2010 20:00:56 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B6B38FC0A for ; Fri, 23 Apr 2010 20:00:55 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA12344; Fri, 23 Apr 2010 23:00:54 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1O5P3V-000CZl-Id; Fri, 23 Apr 2010 23:00:53 +0300 Message-ID: <4BD1FC74.3090504@freebsd.org> Date: Fri, 23 Apr 2010 23:00:52 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: "Kenneth D. Merry" References: <4BCDEBF6.3030609@icyb.net.ua> <20100423184412.GA5016@nargothrond.kdm.org> In-Reply-To: <20100423184412.GA5016@nargothrond.kdm.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org Subject: Re: cam.3: do not discourage use of cam_open_device 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, 23 Apr 2010 20:00:56 -0000 on 23/04/2010 21:44 Kenneth D. Merry said the following: > On Tue, Apr 20, 2010 at 21:01:26 +0300, Andriy Gapon wrote: >> This is based on my understanding what Scott Long tried to explain me a while ago. >> >> Index: lib/libcam/cam.3 >> =================================================================== >> --- lib/libcam/cam.3 (revision 206902) >> +++ lib/libcam/cam.3 (working copy) >> @@ -190,12 +190,6 @@ >> Once the device name and unit number >> are determined, a lookup is performed to determine the passthrough device >> that corresponds to the given device. >> -.Fn cam_open_device >> -is rather simple to use, but it is not really suitable for general use >> -because its behavior is not necessarily deterministic. >> -Programmers writing >> -new applications should make the extra effort to use one of the other open >> -routines documented below. >> .Pp >> .Fn cam_open_spec_device >> opens the >> >> >> It seems that this warning about ambiguity came from pre-devfs days when e.g. cd0 >> nodes in different directories could correspond to different actual SCSI >> peripherals. It seems that there wasn't an ambiguity if an absolute device path >> was given. >> >> Nowadays, cam_open_device seems to always do a proper job of finding a correct >> pass device. > > The warning had more to do with the ambiguity trying to make sense of > device names than having different device nodes lying around. > > cam_get_device() (which is called by cam_open_device()) tries to do > some things that will break on devices that start with n (unless it's a > non-rewound tape device) or r. Right now we don't have any CAM peripheral > drivers that start with those letters, so it works. It also won't do the > right thing on devices with gpt partitions. Some of that can be fixed, > though. > > So it's mostly deterministic, but it may not do exactly what you expect. > > It may be good to keep some statement in there pointing people to the other > routines as being preferred because they're a little more deterministic. These are very valid concerns. I was aware that we ditched "r" (raw) devices quite a while ago, but wasn't sure about "n" kind as I have never dealt with tapes in my life. Perhaps we can just remove that code now? Also, from my point of view, it doesn't make any sense to support cam_open_device() calls on slices, partitions, etc. I mean, what is a passthough device for a slice of disk? Can you send SCSI commands to a slice? All these comes from my (limited) practical experience with some userland applications where people were afraid to use cam_open_device() because of the warning in question. So they went out of the way to "manually" establish mapping from an original device name to a corresponding passthough device. So, I'd like to let people know that it's totally OK to use cam_open_device() with "normal" device names. I don't care about the extra logic ("r", "n" prefixes; partition/slice suffixes). But that's only my point of view. And thank you for the explanation! -- Andriy Gapon From owner-freebsd-scsi@FreeBSD.ORG Sat Apr 24 16:30:31 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9382B1065672; Sat, 24 Apr 2010 16:30:31 +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 6AD7C8FC20; Sat, 24 Apr 2010 16:30:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3OGUVL8024519; Sat, 24 Apr 2010 16:30:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3OGUVpr024510; Sat, 24 Apr 2010 16:30:31 GMT (envelope-from linimon) Date: Sat, 24 Apr 2010 16:30:31 GMT Message-Id: <201004241630.o3OGUVpr024510@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-scsi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146014: [ciss] [panic] crash (panic/reboot) if lost/destroy mounted ciss volume 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, 24 Apr 2010 16:30:31 -0000 Old Synopsis: crash (panic/reboot) if lost/destroy mounted ciss volume New Synopsis: [ciss] [panic] crash (panic/reboot) if lost/destroy mounted ciss volume Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 24 16:30:03 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146014 From owner-freebsd-scsi@FreeBSD.ORG Sat Apr 24 16:37:45 2010 Return-Path: Delivered-To: freebsd-scsi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34BA5106566C; Sat, 24 Apr 2010 16:37:44 +0000 (UTC) (envelope-from scottl@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 02FB28FC12; Sat, 24 Apr 2010 16:37:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o3OGbhRf030840; Sat, 24 Apr 2010 16:37:43 GMT (envelope-from scottl@freefall.freebsd.org) Received: (from scottl@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o3OGbhcU030836; Sat, 24 Apr 2010 16:37:43 GMT (envelope-from scottl) Date: Sat, 24 Apr 2010 16:37:43 GMT Message-Id: <201004241637.o3OGbhcU030836@freefall.freebsd.org> To: freebsd-bug@kirpa.com, scottl@FreeBSD.org, freebsd-scsi@FreeBSD.org From: scottl@FreeBSD.org Cc: Subject: Re: kern/146014: [ciss] [panic] crash (panic/reboot) if lost/destroy mounted ciss volume 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, 24 Apr 2010 16:37:45 -0000 Synopsis: [ciss] [panic] crash (panic/reboot) if lost/destroy mounted ciss volume State-Changed-From-To: open->closed State-Changed-By: scottl State-Changed-When: Sat Apr 24 16:34:35 UTC 2010 State-Changed-Why: FreeBSDD UFS and the VM system do not handle lost-disk conditions on mounted filesystems. Fixing this is beyond the scope of the CISS driver or the SCSI subsystem. http://www.freebsd.org/cgi/query-pr.cgi?pr=146014