From owner-freebsd-scsi@FreeBSD.ORG Mon Mar 14 11:01:30 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D45416A4DA for ; Mon, 14 Mar 2005 11:01:30 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24E7743D46 for ; Mon, 14 Mar 2005 11:01:30 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j2EB1UmN090427 for ; Mon, 14 Mar 2005 11:01:30 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j2EB1TVP090421 for freebsd-scsi@freebsd.org; Mon, 14 Mar 2005 11:01:29 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 14 Mar 2005 11:01:29 GMT Message-Id: <200503141101.j2EB1TVP090421@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2005 11:01:30 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2000/08/18] kern/20689 scsi Newbusified version of ncr driver does no f [2001/05/03] kern/27059 scsi (symbios) SCSI subsystem hangs under heav o [2001/06/29] kern/28508 scsi problems with backup to Tandberg SLR40 st o [2002/06/17] kern/39388 scsi ncr/sym drivers fail with 53c810 and more o [2002/07/22] kern/40895 scsi wierd kernel / device driver bug f [2002/09/15] kern/42796 scsi NCR/SYM 53C825 driver detects scsi cdrom f [2002/11/25] kern/45713 scsi If you use the amr driver, it is impossib f [2002/12/09] kern/46152 scsi Panic in adw dumping to tape f [2003/05/16] kern/52331 scsi 4.7 to 4.8-REL upgrade: SCSI disks on sym f [2003/09/14] kern/56759 scsi [hang] System freezes when writing CD Adv f [2003/09/14] kern/56760 scsi [hang] system hangs at boot with adaptec f [2003/09/14] kern/56871 scsi dd can't write variable length data block f [2003/09/18] kern/56973 scsi SCSI errors from on-board Adaptec (AIC7xx s [2003/09/30] kern/57398 scsi Current fails to install on mly(4) based o [2003/12/26] kern/60598 scsi wire down of scsi devices conflicts with a [2004/01/10] kern/61165 scsi [panic] kernel page fault after calling c o [2004/09/15] kern/71778 scsi 5.3 BETA3 doesnt see Adaptec 2015S FW Rev o [2004/12/02] kern/74607 scsi FreeBSD 5.3 install CD crashes on SCSI de o [2004/12/29] kern/75603 scsi 5.3 kernel crash 19 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/12/06] kern/23314 scsi aic driver fails to detect Adaptec 1520B o [2001/08/15] kern/29727 scsi [amr] [patch] amr_enquiry3 structure in a o [2002/02/23] kern/35234 scsi World access to /dev/pass? (for scanner) o [2002/06/02] kern/38828 scsi [feature request] DPT PM2012B/90 doesn't o [2002/10/29] kern/44587 scsi dev/dpt/dpt.h is missing defines required o [2003/10/01] kern/57468 scsi [patch] Quirk for Quantum LPS540S o [2003/10/01] kern/57469 scsi [patch] Quirk for Conner CP3500 o [2004/09/22] kern/72010 scsi [patch] mt -f /dev/rsa0.ctl comp off, or 8 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 15 08:02:33 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC63F16A4CE; Tue, 15 Mar 2005 08:02:33 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CA1743D46; Tue, 15 Mar 2005 08:02:33 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DB70V-0005xD-5c; Tue, 15 Mar 2005 10:02:27 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Scott Long In-reply-to: Your message of Fri, 25 Feb 2005 07:47:55 -0700 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Mar 2005 10:02:27 +0200 From: Danny Braniss Message-ID: cc: hackers@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2005 08:02:34 -0000 things are looking much better 2day, got tag queuing to work, and now it's much faster. Q: how can the driver tell the cam to enable queing (ie: camcontrol tag 0:0:0 -Nn), and Q: is there a rule of thumb as to how many tag'ed? thanks, danny PS: soon there will be a new beta, any news with the old one? From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 15 13:46:47 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BD6916A4CE; Tue, 15 Mar 2005 13:46:47 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B861143D1D; Tue, 15 Mar 2005 13:46:44 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2FDkgiW018273; Tue, 15 Mar 2005 06:46:43 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4236E6AB.1060405@samsco.org> Date: Tue, 15 Mar 2005 06:44:11 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: hackers@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2005 13:46:47 -0000 Danny Braniss wrote: > things are looking much better 2day, got tag queuing to work, and now it's > much faster. > Q: how can the driver tell the cam to enable queing (ie: camcontrol tag 0:0:0 > -Nn), and case XPT_PATH_INQ: cpi->hba_inquiry = PI_TAG_ABLE > Q: is there a rule of thumb as to how many tag'ed? When you call cam_sim_alloc(), there are arguments for how many concurrent tagged and untagged transactions the driver can handle. I don't know how tags work in iscsi, so I can't say what a good number is here. Note that tag management is left completely up to the driver; CAM will tell you whether or not to use a tag for a particular CCB, but it's up to the driver to assign and track the tag number. > > thanks, > danny > PS: soon there will be a new beta, any news with the old one? > > Sorry, I haven't had much time to review the old one yet. Sounds like you're making really good progress, though. Scott From owner-freebsd-scsi@FreeBSD.ORG Tue Mar 15 15:22:35 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D11F16A4CE; Tue, 15 Mar 2005 15:22:35 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F5BE43D54; Tue, 15 Mar 2005 15:22:35 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.1) id j2FFMJDF090608; Tue, 15 Mar 2005 09:22:19 -0600 (CST) (envelope-from dan) Date: Tue, 15 Mar 2005 09:22:19 -0600 From: Dan Nelson To: Scott Long Message-ID: <20050315152219.GD67769@dan.emsphone.com> References: <4236E6AB.1060405@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4236E6AB.1060405@samsco.org> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: hackers@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2005 15:22:35 -0000 In the last episode (Mar 15), Scott Long said: > Danny Braniss wrote: > >things are looking much better 2day, got tag queuing to work, and > >now it's much faster. Q: how can the driver tell the cam to enable > >queing (ie: camcontrol tag 0:0:0 -Nn), and > > case XPT_PATH_INQ: > cpi->hba_inquiry = PI_TAG_ABLE > > >Q: is there a rule of thumb as to how many tag'ed? > > When you call cam_sim_alloc(), there are arguments for how many > concurrent tagged and untagged transactions the driver can handle. I > don't know how tags work in iscsi, so I can't say what a good number > is here. Note that tag management is left completely up to the > driver; CAM will tell you whether or not to use a tag for a > particular CCB, but it's up to the driver to assign and track the tag > number. I would guess that tags would be even more useful for iscsi than direct-attached scsi, due to the extra latency. The more the better. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 16 12:37:14 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 289B316A4CE; Wed, 16 Mar 2005 12:37:14 +0000 (GMT) Received: from ei.bzerk.org (ei.xs4all.nl [213.84.67.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAF1A43D5C; Wed, 16 Mar 2005 12:37:12 +0000 (GMT) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.13.1/8.13.1) with ESMTP id j2GCg0FZ013613; Wed, 16 Mar 2005 13:42:00 +0100 (CET) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.13.1/8.13.1/Submit) id j2GCfx5i013612; Wed, 16 Mar 2005 13:41:59 +0100 (CET) (envelope-from mail25@bzerk.org) Date: Wed, 16 Mar 2005 13:41:59 +0100 From: Ruben de Groot To: Danny Braniss Message-ID: <20050316124159.GA13465@ei.bzerk.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Status: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, FROM_ENDS_IN_NUMS autolearn=failed version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on ei.bzerk.org cc: hackers@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 12:37:14 -0000 On Tue, Mar 08, 2005 at 09:06:19AM +0200, Danny Braniss typed: > well, i guess all is ok, since im not getting much feedback :-) Actually, I've been on a holliday and wasn't able to do testing until yesterday. When I try to connect to the target (an Equallogic PS200E) the system panics (trace see below). This is 5.4-PRE running under vmware. I had a panic with 5.3-RELEASE as well (but no trace). Anything I can do to help, I have some spare time. greetings, Ruben FreeBSD 5.4-PRERELEASE (DBG) #0: Wed Mar 16 01:28:18 UTC 2005 x226220# kldload iscsi iscsi_kld_start: iscsi start ic_action: called ic_action: func_code=0x4 flags=0x0 status=0x0 target=-1 lun=-1 retry_count=0 ti0 _inq: called ic_init: cam subsystem initialized x226220# iscontrol -v -t 172.17.24.100 iscsi_ioctl: called iscsi_ioctl: dev=4 cmd=1 i_create_session: called 0] i_create_session: sessionID=0 ism_start: called ism_proc: called proc_in: called proc_out: called 0] ism_proc: idone=0 odone=0 iscsi_close: called iscsi_ioctl: called iscsi_ioctl: dev=0 cmd=2 isc_start_receiver: called isc_soc: called so_getbhs: called iscsi_ioctl: called iscsi_ioctl: dev=0 cmd=5 i_setopt: opt.targetAddr='172.17.24.100' iscsi_ioctl: called iscsi_ioctl: dev=0 cmd=10 i_send: called kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc063787a stack pointer = 0x10:0xc92a0b3c frame pointer = 0x10:0xc92a0b3c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 450 (iscontrol) [thread pid 450 tid 100068 ] Stopped at turnstile_head+0x6: movl 0(%eax),%eax db> trace Tracing pid 450 tid 100068 td 0xc141dc80 turnstile_head(0,c156e080,c1714ae0,c16d7d00,c92a0b6c) at turnstile_head+0x6 _mtx_unlock_sleep(c1714b30,0,c1712f40,e5) at _mtx_unlock_sleep+0x40 _mtx_unlock_flags(c1714b30,0,c1712f40,e5,5) at _mtx_unlock_flags+0x2e i_send(c16d7d00,c156f200,c141dc80,c1706c00,1) at i_send+0x149 iscsi_ioctl(c16d7d00,8050690a,c156f200,3,c141dc80) at iscsi_ioctl+0x17e spec_ioctl(c92a0c08,c92a0cb4,c0677506,c92a0c08,c08cbc60) at spec_ioctl+0xb5 spec_vnoperate(c92a0c08) at spec_vnoperate+0x13 vn_ioctl(c152b990,8050690a,c156f200,c156e400,c141dc80) at vn_ioctl+0x20a ioctl(c141dc80,c92a0d14,3,c,10296) at ioctl+0x40f syscall(2f,2f,2f,804d000,bfbfec00) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280c413b, esp = 0xbfbfeb9c, ebp- db> From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 16 22:40:04 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1802616A4CE for ; Wed, 16 Mar 2005 22:40:04 +0000 (GMT) Received: from ratchet.nebcorp.com (ratchet.nebcorp.com [205.217.153.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F3FD43D1D for ; Wed, 16 Mar 2005 22:40:03 +0000 (GMT) (envelope-from djh@nebcorp.com) Received: by ratchet.nebcorp.com (Postfix, from userid 1014) id 9564CD9838; Wed, 16 Mar 2005 14:40:02 -0800 (PST) Date: Wed, 16 Mar 2005 16:40:02 -0600 From: Danny Howard To: freebsd-scsi@freebsd.org Message-ID: <20050316224002.GK44253@ratchet.nebcorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Loop: djhoward@uiuc.edu Subject: LSILogic MegaRAID and "camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dannyman@toldme.com, freebsd-scsi@freebsd.org List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 22:40:04 -0000 Hello, I have a variety of systems that I inherited, with a variety of hardware RAIDs. Most systems are 4.8-4.10. I want to be able to monitor the various RAIDs reliably so that I can fix failures faster, but it is a bear. META QUESTION: Can anyone wiser in the ways of SCSI offer a clue? Is there a "best practices" approach to monitoring hardware RAIDs on FreeBSD? Or suggestions and advice on formulating such an approach? On a Very Important Machine (VIM) I have: amrd0: on amr0 amrd0: 140012MB (286744576 sectors) RAID 5 (optimal) SMP: AP CPU #3 Launched! pass0 at amr0 bus 0 target 6 lun 0 pass0: Fixed Processor SCSI-2 device Mounting root from ufs:/dev/amrd0s1a So, I cast about on the net and found amrcontrol at http://people.freebsd.org/~emoore/MegaRAID_SCSI/ but it can not see my controller when I run it. The VIM is quite new, and amrcontrol is two years old, so, this doesn't seem unreasonable. I'd be happy just to probe the dmesg part that says: amrd0: on amr0 amrd0: 140012MB (286744576 sectors) RAID 5 (optimal) I take "optimal" to mean "okay" and if it ever said something else, I know I have some emergency maintenance to do, and can fail the VIM. So, I tried camcontrol. I am a little wary of issuing SCSI commands to exotic devices because maybe sometimes those devices get an exotic SCSI command and freak out? Well, anyways, I try: 0-17:27 root@xxx ~# camcontrol inquiry amrd0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or amrd0 doesn't exist 1-17:28 root@xxx ~# camcontrol inquiry amr0 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or amr0 doesn't exist 1-17:29 root@xxx ~# camcontrol inquiry 0:6:0 pass0: Fixed Processor SCSI-2 device pass0: Serial Number 1 camcontrol: error getting transfer settings 1-17:29 root@xxx ~# camcontrol inquiry pass0 pass0: Fixed Processor SCSI-2 device pass0: Serial Number 1 camcontrol: error getting transfer settings I have chased down a post or three that implies that I may have to do some MAKEDEV due to some revision conflicts along the way, but I'm not super keen on running MAKEDEV on a VIM unless I know it will really help. I mean, I HAVE the devs: 0-17:29 root@xxx ~# ls /dev/amr* /dev/amrd0 /dev/amrd0s1b /dev/amrd0s1e /dev/amrd0s1h /dev/amrd0s4 /dev/amrd0s1 /dev/amrd0s1c /dev/amrd0s1f /dev/amrd0s2 /deo/amrd0s1a /dev/amrd0s1d /dev/amrd0s1g /dev/amrd0s3 0-17:30 root@xxx ~# ls /dev/pass* /dev/pass0 /dev/pass1 /dev/pass2 /dev/pass3 1-17:29 root@xxx ~# uname -a -reeBSD xxx.xxx.net 4.10-RELEASE-p3 FreeBSD 4.10-RELEASE-p3 #1: Fri Nov 5 12:00:38 EST 2004 root@xxx.xxx.net:/local0/world/obj/local0/world/src/sys/XXX i386 1-17:32 root@xxx ~# ls -l /dev/pass0 /dev/amrd0 `which camcontrol` crw-r----- 1 root wheel 133, 0x00010002 Nov 4 11:03 /dev/amrd0 crw------- 1 root operator 31, 0 Nov 4 11:09 /dev/pass0 -r-xr-xr-x 1 root wheel 140800 Nov 5 11:16 /sbin/camcontrol* Thanks, -danny From owner-freebsd-scsi@FreeBSD.ORG Wed Mar 16 22:54:40 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D40EE16A4CE for ; Wed, 16 Mar 2005 22:54:40 +0000 (GMT) Received: from cobalt.antimatter.net (cobalt.antimatter.net [69.55.224.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EDF343D2D for ; Wed, 16 Mar 2005 22:54:40 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from glenn-mobile.antimatter.net (cpe-66-27-92-132.san.res.rr.com [66.27.92.132]) (authenticated bits=0)j2GMscYv032759 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Mar 2005 14:54:39 -0800 Message-Id: <6.1.0.6.2.20050316144830.0652f240@cobalt.antimatter.net> X-Sender: lists@cobalt.antimatter.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Wed, 16 Mar 2005 14:54:26 -0800 To: dannyman@toldme.com, freebsd-scsi@freebsd.org From: Glenn Dawson In-Reply-To: <20050316224002.GK44253@ratchet.nebcorp.com> References: <20050316224002.GK44253@ratchet.nebcorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: LSILogic MegaRAID and "camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 22:54:41 -0000 At 02:40 PM 3/16/2005, you wrote: >Hello, > >I have a variety of systems that I inherited, with a variety of hardware >RAIDs. Most systems are 4.8-4.10. I want to be able to monitor the >various RAIDs reliably so that I can fix failures faster, but it is a >bear. > >META QUESTION: Can anyone wiser in the ways of SCSI offer a clue? Is > there a "best practices" approach to > monitoring hardware > RAIDs on FreeBSD? Or suggestions and advice on > formulating such an approach? LSI has a command line utility here: http://www.lsilogic.com/downloads/downloads.do?product=2414&download_type=all it's written for linux, but it might work under FreeBSD with linux emulation enabled. I haven't tried it yet, but I can later tonight. I'll post my findings to the list. -Glenn >On a Very Important Machine (VIM) I have: >amrd0: on amr0 >amrd0: 140012MB (286744576 sectors) RAID 5 (optimal) >SMP: AP CPU #3 Launched! >pass0 at amr0 bus 0 target 6 lun 0 >pass0: Fixed Processor SCSI-2 device >Mounting root from ufs:/dev/amrd0s1a > >So, I cast about on the net and found amrcontrol at >http://people.freebsd.org/~emoore/MegaRAID_SCSI/ but it can not see my >controller when I run it. The VIM is quite new, and amrcontrol is two >years old, so, this doesn't seem unreasonable. > >I'd be happy just to probe the dmesg part that says: >amrd0: on amr0 >amrd0: 140012MB (286744576 sectors) RAID 5 (optimal) > >I take "optimal" to mean "okay" and if it ever said something else, I >know I have some emergency maintenance to do, and can fail the VIM. > >So, I tried camcontrol. I am a little wary of issuing SCSI commands to >exotic devices because maybe sometimes those devices get an exotic SCSI >command and freak out? Well, anyways, I try: > >0-17:27 root@xxx ~# camcontrol inquiry amrd0 >camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed >cam_lookup_pass: No such file or directory >cam_lookup_pass: either the pass driver isn't in your kernel >cam_lookup_pass: or amrd0 doesn't exist >1-17:28 root@xxx ~# camcontrol inquiry amr0 >camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed >cam_lookup_pass: No such file or directory >cam_lookup_pass: either the pass driver isn't in your kernel >cam_lookup_pass: or amr0 doesn't exist >1-17:29 root@xxx ~# camcontrol inquiry 0:6:0 >pass0: Fixed Processor SCSI-2 device >pass0: Serial Number 1 >camcontrol: error getting transfer settings >1-17:29 root@xxx ~# camcontrol inquiry pass0 >pass0: Fixed Processor SCSI-2 device >pass0: Serial Number 1 >camcontrol: error getting transfer settings > >I have chased down a post or three that implies that I may have to do >some MAKEDEV due to some revision conflicts along the way, but I'm not >super keen on running MAKEDEV on a VIM unless I know it will really >help. I mean, I HAVE the devs: > >0-17:29 root@xxx ~# ls /dev/amr* >/dev/amrd0 /dev/amrd0s1b /dev/amrd0s1e /dev/amrd0s1h /dev/amrd0s4 >/dev/amrd0s1 /dev/amrd0s1c /dev/amrd0s1f /dev/amrd0s2 >/deo/amrd0s1a /dev/amrd0s1d /dev/amrd0s1g /dev/amrd0s3 >0-17:30 root@xxx ~# ls /dev/pass* >/dev/pass0 /dev/pass1 /dev/pass2 /dev/pass3 >1-17:29 root@xxx ~# uname -a >-reeBSD xxx.xxx.net 4.10-RELEASE-p3 FreeBSD 4.10-RELEASE-p3 #1: Fri Nov 5 >12:00:38 EST 2004 >root@xxx.xxx.net:/local0/world/obj/local0/world/src/sys/XXX i386 >1-17:32 root@xxx ~# ls -l /dev/pass0 /dev/amrd0 `which camcontrol` >crw-r----- 1 root wheel 133, 0x00010002 Nov 4 11:03 /dev/amrd0 >crw------- 1 root operator 31, 0 Nov 4 11:09 /dev/pass0 >-r-xr-xr-x 1 root wheel 140800 Nov 5 11:16 /sbin/camcontrol* > >Thanks, >-danny >_______________________________________________ >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 Mar 16 23:29:15 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE07F16A4CE for ; Wed, 16 Mar 2005 23:29:14 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E576543D53 for ; Wed, 16 Mar 2005 23:29:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2GNT2sI028129; Wed, 16 Mar 2005 16:29:02 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4238C0B5.3020509@samsco.org> Date: Wed, 16 Mar 2005 16:26:45 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dannyman@toldme.com, freebsd-scsi@freebsd.org References: <20050316224002.GK44253@ratchet.nebcorp.com> In-Reply-To: <20050316224002.GK44253@ratchet.nebcorp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Subject: Re: LSILogic MegaRAID and "camcontrol: cam_lookup_pass:CAMGETPASSTHRU ioctl failed" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2005 23:29:15 -0000 Danny Howard wrote: > Hello, > > I have a variety of systems that I inherited, with a variety of hardware > RAIDs. Most systems are 4.8-4.10. I want to be able to monitor the > various RAIDs reliably so that I can fix failures faster, but it is a > bear. > > META QUESTION: Can anyone wiser in the ways of SCSI offer a clue? Is > there a "best practices" approach to monitoring hardware > RAIDs on FreeBSD? Or suggestions and advice on > formulating such an approach? There is no universal way to manage RAID devices, especially between different vendors. This is something that the big OEMs have been wishing for for years (I know since I was involved in one of those failed wishes), but has never happened. Most vendors consider their management interface to be highly proprietary or non-portable, so getting source code or specs is practically impossible unless you have the money to make it worth their while. The only think that is close to a universal management tool is the atacontrol in FreeBSD that can configure and monitor several brands of software RAID. This offers no benefit to your MegaRAID hardware, however. > > On a Very Important Machine (VIM) I have: > amrd0: on amr0 > amrd0: 140012MB (286744576 sectors) RAID 5 (optimal) > SMP: AP CPU #3 Launched! > pass0 at amr0 bus 0 target 6 lun 0 > pass0: Fixed Processor SCSI-2 device > Mounting root from ufs:/dev/amrd0s1a > > So, I cast about on the net and found amrcontrol at > http://people.freebsd.org/~emoore/MegaRAID_SCSI/ but it can not see my > controller when I run it. The VIM is quite new, and amrcontrol is two > years old, so, this doesn't seem unreasonable. THe package that you are refering to was a highly experimental and unsupported porting effort that only had a limited lifetime. I'm not surprised that is doesn't work. However, LSI is starting to provide more official FreeBSD support, and it's quite possible that more appropriate software might be available from their website now. I haven't checked recently, though, and if it's not there then I can't answer any questions of when it might be there in the future. Sorry! > > I'd be happy just to probe the dmesg part that says: > amrd0: on amr0 > amrd0: 140012MB (286744576 sectors) RAID 5 (optimal) > > I take "optimal" to mean "okay" and if it ever said something else, I > know I have some emergency maintenance to do, and can fail the VIM. > > So, I tried camcontrol. I am a little wary of issuing SCSI commands to > exotic devices because maybe sometimes those devices get an exotic SCSI > command and freak out? Well, anyways, I try: The amrd0 devices are NOT scsi devices. They are low-level block devices that present themselves as disks to the system. The only thing in your system that camcontrol will be able to talk to is the SES backplane that was probed (the pass0 device that you mentioned earlier). Scott From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 17 04:25:21 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 238AE16A4CE for ; Thu, 17 Mar 2005 04:25:21 +0000 (GMT) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78CAA43D2D for ; Thu, 17 Mar 2005 04:25:20 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) (192.168.1.2) by mail.ambrisko.com with ESMTP; 16 Mar 2005 20:25:20 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.12.11/8.12.9) with ESMTP id j2H4PF5g043486; Wed, 16 Mar 2005 20:25:16 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.12.11/8.12.11/Submit) id j2H4PFwq043485; Wed, 16 Mar 2005 20:25:15 -0800 (PST) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200503170425.j2H4PFwq043485@ambrisko.com> In-Reply-To: <6.1.0.6.2.20050316144830.0652f240@cobalt.antimatter.net> To: Glenn Dawson Date: Wed, 16 Mar 2005 20:25:15 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: dannyman@toldme.com cc: freebsd-scsi@freebsd.org Subject: Re: LSILogic MegaRAID and "camcontrol: cam_lookup_pass:CAMGETPASSTHRU ioctl failed" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2005 04:25:21 -0000 Glenn Dawson writes: | At 02:40 PM 3/16/2005, you wrote: | >Hello, | > | >I have a variety of systems that I inherited, with a variety of hardware | >RAIDs. Most systems are 4.8-4.10. I want to be able to monitor the | >various RAIDs reliably so that I can fix failures faster, but it is a | >bear. | > | >META QUESTION: Can anyone wiser in the ways of SCSI offer a clue? Is | > there a "best practices" approach to | > monitoring hardware | > RAIDs on FreeBSD? Or suggestions and advice on | > formulating such an approach? | | LSI has a command line utility here: | http://www.lsilogic.com/downloads/downloads.do?product=2414&download_type=all | | it's written for linux, but it might work under FreeBSD with linux | emulation enabled. | I haven't tried it yet, but I can later tonight. I'll post my findings to | the list. No they won't work since there is no Linux compatibility shim for the ioctl's. Also the MegaMonitor utilities leaks shared memory under Linux and dies. Fixes from LSI are slow to come by. The updated version of the Linux tools do tend to work better. Running the ancient FreeBSD MegaMonitor does bad things to your system. It may work once or twice but can start breaking other programs on the system. Doug A. From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 17 08:33:11 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4E8216A4CE for ; Thu, 17 Mar 2005 08:33:11 +0000 (GMT) Received: from pophost.wldelft.nl (sunray.wldelft.nl [145.9.132.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9709443D39 for ; Thu, 17 Mar 2005 08:33:10 +0000 (GMT) (envelope-from leroy.vanlogchem@wldelft.nl) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id JAA14870 for freebsd-scsi@freebsd.org; Thu, 17 Mar 2005 09:33:09 +0100 (MET) Received: from [145.9.150.200] (beasty [145.9.150.200]) by pophost.wldelft.nl (8.9.3/8.9.3) with ESMTP id JAA14728 for ; Thu, 17 Mar 2005 09:33:07 +0100 (MET) Message-ID: <423940C2.9090202@wldelft.nl> Date: Thu, 17 Mar 2005 09:33:06 +0100 From: Leroy van Logchem User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 5.3-RELEASE-p5 reboots, ahd(4) debug messages on reboot X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2005 08:33:12 -0000 ---- Sorry for the previous linewrapped question ---- Hello, Our fileserver with a raid cabinet attached reboots about every two weeks. What could be causing this? OS Version: FreeBSD 5.3-RELEASE-p5 Server brand: Supermicro 6018-P8 Server purpose: Hosting files using Samba 3 and NFS with 400 clients. SCSI cabinet: 2U EonStore A08-G1410. A RAID5+1 being exported as single U160 device to the HBA. Boot messages after crash: -------------------------- Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-RELEASE-p5 #1: Wed Feb 2 11:48:23 CET 2005 root@testfiler.wldelft.nl:/usr/obj/usr/src/sys/GENERIC MPTable: < Kings Canyon> Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2799.70-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073217536 (1023 MB) avail memory = 1043804160 (995 MB) ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic2: Assuming intbase of 48 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at device 28.0 (no driver attached) pcib2: at device 29.0 on pci1 pci2: on pcib2 em0: port 0x3000-0x303f mem 0xfc200000-0xfc21ffff irq 54 at device 3.0 on pci2 em0: Ethernet address: 00:30:48:2a:53:be em0: Speed:N/A Duplex:N/A em1: port 0x3040-0x307f mem 0xfc220000-0xfc23ffff irq 55 at device 3.1 on pci2 em1: Ethernet address: 00:30:48:2a:53:bf em1: Speed:N/A Duplex:N/A pci1: at device 30.0 (no driver attached) pcib3: at device 31.0 on pci1 pci3: on pcib3 ahd0: port 0x4000-0x40ff,0x4400-0x44ff mem 0xfc300000-0xfc301fff irq 28 at device 2.0 on pci3 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs ahd1: port 0x4800-0x48ff,0x4c00-0x4cff mem 0xfc302000-0xfc303fff irq 29 at device 2.1 on pci3 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 pci4: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x2060-0x206f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) cpu0 on motherboard orm0: at iomem 0xe0000-0xe3fff,0xc8000-0xc8fff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sc0: at flags 0x100 on isa0sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 2799696480 Hz quality 800 Timecounters tick every 10.000 msec acd0: CDROM at ata1-master UDMA33 Waiting 15 seconds for SCSI devices to settle ahd0: Invalid Sequencer interrupt occurred. >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahd0: Dumping Card State at program address 0x23b Mode 0x0 Card was paused INTSTAT[0x0] SELOID[0x0] SELID[0x10] HS_MAILBOX[0x0] INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] SAVED_MODE[0x11] DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE) SCSISIGI[0x0]:(P_DATAOUT) SCSIPHASE[0x0] SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE) SCSISEQ0[0x0] SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI) SEQCTL0[0x0] SEQINTCTL[0x6]:(INTMASK1|INTMASK2) SEQ_FLAGS[0x0] SEQ_FLAGS2[0x0] QFREEZE_COUNT[0x3] KERNEL_QFREEZE_COUNT[0x3] MK_MESSAGE_SCB[0xff00] MK_MESSAGE_SCSIID[0xff] SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] PERRDIAG[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) LQISTAT0[0x0] LQISTAT1[0x0] LQISTAT2[0x0] LQOSTAT0[0x0] LQOSTAT1[0x0] LQOSTAT2[0x0] SCB Count = 16 CMDS_PENDING = 0 LASTSCB 0xffff CURRSCB 0xf NEXTSCB 0xff00 qinstart = 39 qinfifonext = 39 QINFIFO: WAITING_TID_QUEUES: Pending list: Total 0 Kernel Free SCB list: 15 14 9 1 2 3 4 5 6 7 8 10 11 12 13 0 Sequencer Complete DMA-inprog list: Sequencer Complete list: Sequencer DMA-Up and Complete list: Sequencer On QFreeze and Complete list: ahd0: FIFO0 Free, LONGJMP == 0x8000, SCB 0xe SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) ahd0: FIFO1 Free, LONGJMP == 0x8063, SCB 0xf SEQIMODE[0x3f]:(ENCFG4TCMD|ENCFG4ICMD|ENCFG4TSTAT|ENCFG4ISTAT|ENCFG4DATA|ENSAVEPTRS) SEQINTSRC[0x0] DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL) SG_CACHE_SHADOW[0x2]:(LAST_SEG) SG_STATE[0x0] DFFSXFRCTL[0x0] SOFFCNT[0x0] MDFFSTAT[0x5]:(FIFOFREE|DLZERO) SHADDR = 0x00, SHCNT = 0x0 HADDR = 0x00, HCNT = 0x0 CCSGCTL[0x10]:(SG_CACHE_AVAIL) LQIN: 0x8 0x0 0x0 0xe 0x0 0x1 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ahd0: LQISTATE = 0x0, LQOSTATE = 0x0, OPTIONMODE = 0x42 ahd0: OS_SPACE_CNT = 0x20 MAXCMDCNT = 0x1 ahd0: SAVED_SCSIID = 0x0 SAVED_LUN = 0x0 SIMODE0[0xc]:(ENOVERRUN|ENIOERR) CCSCBCTL[0x4]:(CCSCBDIR) ahd0: REG0 == 0xd501, SINDEX = 0x10e, DINDEX = 0x102ses0 at ahd0 bus 0 target 6 lun 0 ses0: Fixed Processor SCSI-2 device ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x2 0x2 0x0 0x0 0x0 da2 at ahd1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled da2: 1429284MB (2927173632 512 byte sectors: 255H 63S/T 182208C) da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687372 512 byte sectors: 255H 63S/T 4462C) Mounting root from ufs:/dev/da0s1a Pciconf -l: ----------- hostb0@pci0:0:0: class=0x060000 card=0x358015d9 chip=0x254c8086 rev=0x01 hdr=0x00 none0@pci0:0:1: class=0xff0000 card=0x358015d9 chip=0x25418086 rev=0x01 hdr=0x00 pcib1@pci0:2:0: class=0x060400 card=0x00000000 chip=0x25438086 rev=0x01 hdr=0x01 uhci0@pci0:29:0: class=0x0c0300 card=0x358015d9 chip=0x24828086 rev=0x02 hdr=0x00 uhci1@pci0:29:1: class=0x0c0300 card=0x358015d9 chip=0x24848086 rev=0x02 hdr=0x00 uhci2@pci0:29:2: class=0x0c0300 card=0x358015d9 chip=0x24878086 rev=0x02 hdr=0x00 pcib4@pci0:30:0: class=0x060400 card=0x00000000 chip=0x244e8086 rev=0x42 hdr=0x01 isab0@pci0:31:0: class=0x060100 card=0x00000000 chip=0x24808086 rev=0x02 hdr=0x00 atapci0@pci0:31:1: class=0x01018a card=0x358015d9 chip=0x248b8086 rev=0x02 hdr=0x00 none1@pci0:31:3: class=0x0c0500 card=0x358015d9 chip=0x24838086 rev=0x02 hdr=0x00 none2@pci1:28:0: class=0x080020 card=0x358015d9 chip=0x14618086 rev=0x04 hdr=0x00 pcib2@pci1:29:0: class=0x060400 card=0x00000050 chip=0x14608086 rev=0x04 hdr=0x01 none3@pci1:30:0: class=0x080020 card=0x358015d9 chip=0x14618086 rev=0x04 hdr=0x00 pcib3@pci1:31:0: class=0x060400 card=0x00000050 chip=0x14608086 rev=0x04 hdr=0x01 em0@pci2:3:0: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 em1@pci2:3:1: class=0x020000 card=0x10118086 chip=0x10108086 rev=0x01 hdr=0x00 ahd0@pci3:2:0: class=0x010000 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 ahd1@pci3:2:1: class=0x010000 card=0x005e9005 chip=0x801d9005 rev=0x10 hdr=0x00 none4@pci4:1:0: class=0x030000 card=0x00081002 chip=0x47521002 rev=0x27 hdr=0x00 Camcontrol: ----------- # camcontrol devlist -v scbus0 on ahd0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 6 lun 0 (ses0,pass2) < > at scbus0 target -1 lun -1 () scbus1 on ahd1 bus 0: at scbus1 target 2 lun 0 (pass3,da2) < > at scbus1 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) # camcontrol inquiry da0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number 3JA7JCF100007440AJ5K pass0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled # camcontrol inquiry da1 pass1: Fixed Direct Access SCSI-3 device pass1: Serial Number 3JA7JARS00007439A214 pass1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled # camcontrol inquiry da2 pass3: Fixed Direct Access SCSI-3 device pass3: Serial Number 00000028E4A83F00 pass3: 160.000MB/s transfers (80.000MHz, offset 62, 16bit), Tagged Queueing Enabled df -hi output: -------------- Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/da2s1d 1.4T 1.2T 60G 95% 1956236 12969074 13% /part1 Kernel configuation: -------------------- GENERIC with these extras: options KDB options KDB_UNATTENDED options CAMDEBUG Thanks, Leroy PS: PR kern/71778 can be closed. See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/71778 From owner-freebsd-scsi@FreeBSD.ORG Thu Mar 17 17:43:01 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECCD716A4CE for ; Thu, 17 Mar 2005 17:43:01 +0000 (GMT) Received: from pigeon.infotechfl.com (mailrelay.infotechfl.com [209.251.147.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id E638B43D1F for ; Thu, 17 Mar 2005 17:42:52 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from [172.20.0.75] (gmulder.infotechfl.com [172.20.0.75]) by pigeon.infotechfl.com (8.11.6/8.11.6) with ESMTP id j2HDnf211597 for ; Thu, 17 Mar 2005 08:49:41 -0500 Message-ID: <42398AF7.3090708@infotechfl.com> Date: Thu, 17 Mar 2005 08:49:43 -0500 From: Gary Mulder User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <200503170425.j2H4PFwq043485@ambrisko.com> In-Reply-To: <200503170425.j2H4PFwq043485@ambrisko.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: LSILogic MegaRAID and "camcontrol:cam_lookup_pass:CAMGETPASSTHRU ioctl failed" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2005 17:43:02 -0000 From personal experience the MegaRAID monitoring software has crashed two of our FreeBSD 4.9 systems, before we unistalled it. As these systems age past two years drives are starting to fail and given that I can't monitor the state of the RAID arrays from FreeBSD I'm not purchasing any more MegaRAID controller based systems. Furthermore, although I haven't been able to definitively isolate it, I suspect that some mysterious hangs on some of our more heavily loaded database systems are due to the MegaRAID controller not gracefully handling failed drives, even when hot spares are available. I have zero diagnostic information as FreeBSD just stops responding (no console keyboard response, nothing...). I suspect this is due to the fact that my root partition is on the MegaRAID controller. This is also with the latest firmware installed on the MegaRAID controllers. So, what are people's experiences with the Adaptec 2200S U320 controller under FreeBSD 4.x and 5.x? Gary Doug Ambrisko wrote: > No they won't work since there is no Linux compatibility shim for the > ioctl's. Also the MegaMonitor utilities leaks shared memory under > Linux and dies. Fixes from LSI are slow to come by. > > The updated version of the Linux tools do tend to work better. Running the > ancient FreeBSD MegaMonitor does bad things to your system. It may > work once or twice but can start breaking other programs on the system. > > Doug A. From owner-freebsd-scsi@FreeBSD.ORG Fri Mar 18 00:20:15 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C33216A4CE for ; Fri, 18 Mar 2005 00:20:15 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC1B43D49 for ; Fri, 18 Mar 2005 00:20:12 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2I0JkrP034633; Thu, 17 Mar 2005 17:19:51 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423A1E22.4090204@samsco.org> Date: Thu, 17 Mar 2005 17:17:38 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Mulder References: <200503170425.j2H4PFwq043485@ambrisko.com> <42398AF7.3090708@infotechfl.com> In-Reply-To: <42398AF7.3090708@infotechfl.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-scsi@freebsd.org Subject: Re: LSILogic MegaRAID and"camcontrol:cam_lookup_pass:CAMGETPASSTHRU ioctl failed" X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 00:20:15 -0000 Gary Mulder wrote: > From personal experience the MegaRAID monitoring software has crashed > two of our FreeBSD 4.9 systems, before we unistalled it. > > As these systems age past two years drives are starting to fail and > given that I can't monitor the state of the RAID arrays from FreeBSD I'm > not purchasing any more MegaRAID controller based systems. > > Furthermore, although I haven't been able to definitively isolate it, I > suspect that some mysterious hangs on some of our more heavily loaded > database systems are due to the MegaRAID controller not gracefully > handling failed drives, even when hot spares are available. > > I have zero diagnostic information as FreeBSD just stops responding (no > console keyboard response, nothing...). I suspect this is due to the > fact that my root partition is on the MegaRAID controller. This is also > with the latest firmware installed on the MegaRAID controllers. > > So, what are people's experiences with the Adaptec 2200S U320 controller > under FreeBSD 4.x and 5.x? The 2200S works ok in both. Most people that I talk to are much happier with the 2200 than the 2120. Both the Linux aaccli (found on the Adaptec CD) and the FreeBSD aaccli (found in ports) work, though the linux one is more up to date and allows you to do things like flash the firmware. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 10:56:13 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6269316A4CE; Sat, 19 Mar 2005 10:56:13 +0000 (GMT) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 405B443D48; Sat, 19 Mar 2005 10:56:13 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 76FFB970AF; Sat, 19 Mar 2005 02:56:12 -0800 (PST) Message-Id: <3.0.1.32.20050319025617.00a909c0@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Sat, 19 Mar 2005 02:56:17 -0800 To: hackers@freebsd.org, freebsd-scsi@freebsd.org, freebsd-amd64@freebsd.org From: ray@redshift.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Support for Tyan Thunder K8SR w/ Adaptec 7902 under AMD64 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 10:56:13 -0000 Hi List(s), I ran into some issues with FreeBSD 5.3 crashing on heavy read/writes while using a Tyan Thunder K8SR motherboard with SCSI support. Here is a screen shot of the lock up: http://www.redshift.com/~ray/amd/ I wrote to Tyan and one of their tech's replied with the note below: "I've looked on the Adaptec website and I can't find any "listing that states that the Adaptec 7902 supports any "version of FreeBSD. We haven't test this OS with any of "the boards that have this chipset so we could not "make any comments about what you are seeing directly." I returned the server to our hardware vendor and they said that it was a defective motherboard and that they were able to load up 40 other machines with FreeBSD 5.3 fine. They are sending another server to me for testing. In the meantime, I was trying to confirm the Adaptec 7902 chipset used on the Tyan board is fully supported in FreeBSD AMD64. Does anyone know off hand? I checked i386 and did not see anything directly stating 7902. Unfortunately, I do not have an AMD machine here at the moment, so I can't check the Kernel config file. Does anyone know off hand? Thanks! Ray From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 10:57:48 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D3516A4CE; Sat, 19 Mar 2005 10:57:48 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5295A43D48; Sat, 19 Mar 2005 10:57:48 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DCbeH-0003QG-Mh; Sat, 19 Mar 2005 12:57:41 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Scott Long In-reply-to: Your message of Tue, 15 Mar 2005 06:44:11 -0700 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Mar 2005 12:57:41 +0200 From: Danny Braniss Message-ID: cc: Sam Leffler cc: net@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 10:57:48 -0000 with tags enabled, iSCSI is much faster, but it also causes a deadlock :-( this is what i run: newfs -U / cd / restore rf /home/file.dump on the same motherboard, a dual Xeon, with smp disabled all is OK with smp enabled restore gets stuck usualy waiting on biord. the iscsi driver shows that all requests have been done, the sniffing shows the same(ie all request have been done). so this leads me to think that there is some race condition that i'm not aware of in a SMP system, where xpt_done(ccb) is called while another process is calling biowait. another lead is that after restore gets stuck, the system slowly gets 'stalled'. any insight is most welcome!, i'm also stuck. danny From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 11:59:14 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87C6416A4CE; Sat, 19 Mar 2005 11:59:14 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F7B43D54; Sat, 19 Mar 2005 11:59:14 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DCcbo-000ABI-Fu; Sat, 19 Mar 2005 13:59:12 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: scsi@freebsd.org In-Reply-To: Message from Danny Braniss Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Mar 2005 13:59:12 +0200 From: Danny Braniss Message-ID: cc: Sam Leffler cc: net@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 11:59:14 -0000 > with tags enabled, iSCSI is much faster, but it also causes a deadlock :-( > this is what i run: > newfs -U / > cd / > restore rf /home/file.dump > > on the same motherboard, a dual Xeon, with smp disabled all is OK > with smp enabled restore gets stuck usualy waiting on biord. > the iscsi driver shows that all requests have been done, the sniffing > shows the same(ie all request have been done). > > so this leads me to think that there is some race condition that i'm not > aware of in a SMP system, where xpt_done(ccb) is called while > another process is calling biowait. > > another lead is that after restore gets stuck, the system slowly gets > 'stalled'. > > any insight is most welcome!, i'm also stuck. ahh, hate talking to myself :-) grabbing Giant before calling xpt_done solved it, so the problem is most probably in the CAM ... danny From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 15:10:32 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57D1C16A4CE; Sat, 19 Mar 2005 15:10:32 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9CC943D2F; Sat, 19 Mar 2005 15:10:31 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2JF9dgk044551; Sat, 19 Mar 2005 08:09:39 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423C4037.3090801@samsco.org> Date: Sat, 19 Mar 2005 08:07:35 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Sam Leffler cc: net@freebsd.org cc: scsi@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 15:10:32 -0000 Danny Braniss wrote: >>with tags enabled, iSCSI is much faster, but it also causes a deadlock :-( >>this is what i run: >> newfs -U / >> cd / >> restore rf /home/file.dump >> >>on the same motherboard, a dual Xeon, with smp disabled all is OK >>with smp enabled restore gets stuck usualy waiting on biord. >>the iscsi driver shows that all requests have been done, the sniffing >>shows the same(ie all request have been done). >> >>so this leads me to think that there is some race condition that i'm not >>aware of in a SMP system, where xpt_done(ccb) is called while >>another process is calling biowait. >> >>another lead is that after restore gets stuck, the system slowly gets >>'stalled'. >> >>any insight is most welcome!, i'm also stuck. > > > ahh, hate talking to myself :-) > > grabbing Giant before calling xpt_done solved it, so the problem is > most probably in the CAM ... > > danny > > > No, you need to grab Giant when calling xpt_done(). I even put an assertion into CAM to make sure of that. Are you running with WITNESS and/or INVARIANTS enabled? Those would have caught this problem. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 15:51:46 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A7F916A4CE; Sat, 19 Mar 2005 15:51:46 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 136DD43D3F; Sat, 19 Mar 2005 15:51:46 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j2JFpjKU008045; Sat, 19 Mar 2005 07:51:45 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j2JFpjhs008044; Sat, 19 Mar 2005 07:51:45 -0800 (PST) (envelope-from sgk) Date: Sat, 19 Mar 2005 07:51:45 -0800 From: Steve Kargl To: ray@redshift.com Message-ID: <20050319155145.GA8021@troutmask.apl.washington.edu> References: <3.0.1.32.20050319025617.00a909c0@pop.redshift.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.1.32.20050319025617.00a909c0@pop.redshift.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-scsi@freebsd.org cc: hackers@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: Support for Tyan Thunder K8SR w/ Adaptec 7902 under AMD64 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 15:51:46 -0000 On Sat, Mar 19, 2005 at 02:56:17AM -0800, ray@redshift.com wrote: > > Tyan board is fully supported in FreeBSD AMD64. Does anyone know off > hand? I checked i386 and did not see anything directly stating 7902. > Unfortunately, I do not have an AMD machine here at the moment, so > I can't check the Kernel config file. > > Does anyone know off hand? > Yes, the 7902 chip is supported by the ahd driver. I have a K8SR motherboard and scsi works just fine. You probably want to install a 5.4 snapshot or 5.4 release when its available. -- Steve From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 15:59:38 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D291516A4CE; Sat, 19 Mar 2005 15:59:38 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 672B243D1D; Sat, 19 Mar 2005 15:59:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2JFwXn4044800; Sat, 19 Mar 2005 08:58:33 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423C4BAE.3010202@samsco.org> Date: Sat, 19 Mar 2005 08:56:30 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: <423C4037.3090801@samsco.org> In-Reply-To: <423C4037.3090801@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Sam Leffler cc: scsi@freebsd.org cc: net@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 15:59:39 -0000 Scott Long wrote: > Danny Braniss wrote: > >>> with tags enabled, iSCSI is much faster, but it also causes a >>> deadlock :-( >>> this is what i run: >>> newfs -U / >>> cd / >>> restore rf /home/file.dump >>> >>> on the same motherboard, a dual Xeon, with smp disabled all is OK >>> with smp enabled restore gets stuck usualy waiting on biord. >>> the iscsi driver shows that all requests have been done, the sniffing >>> shows the same(ie all request have been done). >>> >>> so this leads me to think that there is some race condition that i'm not >>> aware of in a SMP system, where xpt_done(ccb) is called while >>> another process is calling biowait. >>> >>> another lead is that after restore gets stuck, the system slowly gets >>> 'stalled'. >>> >>> any insight is most welcome!, i'm also stuck. >> >> >> >> ahh, hate talking to myself :-) >> >> grabbing Giant before calling xpt_done solved it, so the problem is >> most probably in the CAM ... >> >> danny >> >> >> > > No, you need to grab Giant when calling xpt_done(). I even put an > assertion into CAM to make sure of that. Are you running with WITNESS > and/or INVARIANTS enabled? Those would have caught this problem. > > Scott Oops, I forgot to mention that I recently addressed this in 6-CURRENT. Now, much of the rest of cam API still requires Giant to be held, but xpt_done() does not. This only applies to 6-CURRENT, and I doubt that it will be backported to 5-STABLE. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 18:06:23 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B61A16A4CE; Sat, 19 Mar 2005 18:06:23 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75A9F43D1F; Sat, 19 Mar 2005 18:06:22 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DCiL6-000MUy-6n; Sat, 19 Mar 2005 20:06:20 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Scott Long In-reply-to: Your message of Sat, 19 Mar 2005 08:56:30 -0700 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Mar 2005 20:06:20 +0200 From: Danny Braniss Message-ID: cc: Sam Leffler cc: scsi@freebsd.org cc: net@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 18:06:23 -0000 > Scott Long wrote: > > Danny Braniss wrote: > > > >>> with tags enabled, iSCSI is much faster, but it also causes a > >>> deadlock :-( > >>> this is what i run: > >>> newfs -U / > >>> cd / > >>> restore rf /home/file.dump > >>> > >>> on the same motherboard, a dual Xeon, with smp disabled all is OK > >>> with smp enabled restore gets stuck usualy waiting on biord. > >>> the iscsi driver shows that all requests have been done, the sniffing > >>> shows the same(ie all request have been done). > >>> > >>> so this leads me to think that there is some race condition that i'm not > >>> aware of in a SMP system, where xpt_done(ccb) is called while > >>> another process is calling biowait. > >>> > >>> another lead is that after restore gets stuck, the system slowly gets > >>> 'stalled'. > >>> > >>> any insight is most welcome!, i'm also stuck. > >> > >> > >> > >> ahh, hate talking to myself :-) > >> > >> grabbing Giant before calling xpt_done solved it, so the problem is > >> most probably in the CAM ... > >> > >> danny > >> > >> > >> > > > > No, you need to grab Giant when calling xpt_done(). I even put an > > assertion into CAM to make sure of that. Are you running with WITNESS > > and/or INVARIANTS enabled? Those would have caught this problem. > > they are off :-(, would have saved me some time. > > Scott > > Oops, I forgot to mention that I recently addressed this in 6-CURRENT. > Now, much of the rest of cam API still requires Giant to be held, but > xpt_done() does not. This only applies to 6-CURRENT, and I doubt that > it will be backported to 5-STABLE. > > Scott so what you are saying is that in 5.x it's a must to grab Giant before calling xpt_done, and not in 6? danny From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 18:47:46 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F26C16A4CE; Sat, 19 Mar 2005 18:47:46 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DB4E43D1F; Sat, 19 Mar 2005 18:47:43 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j2JIjrTZ045386; Sat, 19 Mar 2005 11:45:53 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <423C7387.8010804@samsco.org> Date: Sat, 19 Mar 2005 11:46:31 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: Sam Leffler cc: scsi@freebsd.org cc: net@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 18:47:46 -0000 Danny Braniss wrote: >>Scott Long wrote: >> >>>Danny Braniss wrote: >>> >>> >>>>>with tags enabled, iSCSI is much faster, but it also causes a >>>>>deadlock :-( >>>>>this is what i run: >>>>> newfs -U / >>>>> cd / >>>>> restore rf /home/file.dump >>>>> >>>>>on the same motherboard, a dual Xeon, with smp disabled all is OK >>>>>with smp enabled restore gets stuck usualy waiting on biord. >>>>>the iscsi driver shows that all requests have been done, the sniffing >>>>>shows the same(ie all request have been done). >>>>> >>>>>so this leads me to think that there is some race condition that i'm not >>>>>aware of in a SMP system, where xpt_done(ccb) is called while >>>>>another process is calling biowait. >>>>> >>>>>another lead is that after restore gets stuck, the system slowly gets >>>>>'stalled'. >>>>> >>>>>any insight is most welcome!, i'm also stuck. >>>> >>>> >>>> >>>>ahh, hate talking to myself :-) >>>> >>>>grabbing Giant before calling xpt_done solved it, so the problem is >>>>most probably in the CAM ... >>>> >>>>danny >>>> >>>> >>>> >>> >>>No, you need to grab Giant when calling xpt_done(). I even put an >>>assertion into CAM to make sure of that. Are you running with WITNESS >>>and/or INVARIANTS enabled? Those would have caught this problem. >>> > > they are off :-(, would have saved me some time. > >>>Scott >> >>Oops, I forgot to mention that I recently addressed this in 6-CURRENT. >>Now, much of the rest of cam API still requires Giant to be held, but >>xpt_done() does not. This only applies to 6-CURRENT, and I doubt that >>it will be backported to 5-STABLE. >> >>Scott > > > so what you are saying is that in 5.x it's a must to grab Giant before calling > xpt_done, and not in 6? > > danny > > > Correct. Again, turning on WITNESS and INVARIANTS is a very good thing to do during development. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat Mar 19 19:24:34 2005 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E5F616A4CE; Sat, 19 Mar 2005 19:24:34 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1620F43D48; Sat, 19 Mar 2005 19:24:33 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j2JJO0ik095921; Sat, 19 Mar 2005 21:24:00 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <423C7C60.8010709@he.iki.fi> Date: Sat, 19 Mar 2005 21:24:16 +0200 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Braniss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Sam Leffler cc: scsi@freebsd.org cc: net@freebsd.org Subject: Re: iSCSI initiator driver beta version, testers wanted X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2005 19:24:34 -0000 Danny Braniss wrote: >with tags enabled, iSCSI is much faster, but it also causes a deadlock :-( >this is what i run: > newfs -U / > cd / > restore rf /home/file.dump > > What are you using / what's recommended as iSCSI server? Pete