From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 5 17:15: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 B1EAB10656BF for ; Sun, 5 Sep 2010 17:15:07 +0000 (UTC) (envelope-from ivwcorporation.matevz@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4A9118FC16 for ; Sun, 5 Sep 2010 17:15:06 +0000 (UTC) Received: by wyb33 with SMTP id 33so4521933wyb.13 for ; Sun, 05 Sep 2010 10:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6MHeIgX2JOZcCTLwDOVY3GWSKX/AC/+FJJEzfCiUN+A=; b=qPAPewKy9cUapeVeUjxELYyVMZRdyAyvazjULnpxESj8axX9t5ops5wKb+wiuNUVsa 9JVVWJiXtuTUCgn105BScS2Zl6xMiBE7UYYcTg2uMciFdTyiIFHocD+65wKwiUDgkKPI NEu6mTvflfbDyK3S+0eEnX2HZuNSrqNTqxrPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=X9b77eeqGIE9/n2d65IEiyDxEKjLEtDIH8qrYBy2Rt5G365NwBG66sGly5WkjYXfxB U8HTPNjslWV7vsrmpc7hh9WOEWnchI7zfzq9zW1zEe4c1vWtNy/yFZnXUVNZ6+HrvVGZ WgWMf9J8Cyw1ajxWw9VfRK77fywdqNZxmaF7w= MIME-Version: 1.0 Received: by 10.227.143.12 with SMTP id s12mr319321wbu.125.1283705588119; Sun, 05 Sep 2010 09:53:08 -0700 (PDT) Received: by 10.216.225.198 with HTTP; Sun, 5 Sep 2010 09:53:08 -0700 (PDT) Date: Sun, 5 Sep 2010 18:53:08 +0200 Message-ID: From: =?UTF-8?B?TWF0ZXbFviBNYXJrb3ZpxI0=?= To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Working with tape drives X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 17:15:07 -0000 Hello! I have a DDS2 tape drive (with some spare tapes) and I want to write a simple C application, with which I will be able to write onto the tape (raw I/O), rewind the tape, seek any byte on the tape and read from it. I have FreeBSD 8. Can I just use standard C functions for dealing with files or should I use mt? If mt is the answer, then how should I read, seek and write to the tape? I want to keep my C application as simple as possible. If manipulating with tape drives cannot be done with just simple C I/O functions, then is it possible to create a wrapper to those functions? Thank you for your answers, Matevz Markovic From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 5 18:40: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 0FB5C10656B4 for ; Sun, 5 Sep 2010 18:40:14 +0000 (UTC) (envelope-from djmitche@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C8B8B8FC14 for ; Sun, 5 Sep 2010 18:40:13 +0000 (UTC) Received: by iwn34 with SMTP id 34so4002156iwn.13 for ; Sun, 05 Sep 2010 11:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=pXhEyut+Hme96fZteWJ3do9eYLoZlLi59CK3btWWZQ4=; b=VpVu/OrCmmOHcMzYUPrdTqgl0CkFJmGUhZpDUiHBkP8q0UnApahkcJmXrvN4xaoJVu N720DiKgeHixrEz1tMhC12Wm5bCDwE2q0qGfsaAyyj61IBfC5rv+qluxP5qPeTb1SwB2 kVAN/iCOMEiYcQYpT+hP9cJiZEcmYNes+XVTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=UqmT3O/z3WgSpfNq5R6u0q7yRXF/+nMB9Rc7xWhgzimFrPT6hiqG59WcwTSLPv0+G/ CXBPcOPntCAYZo3OB+2UKClLip6A7s0gfX/ACsoWZ6Lv9gIfNP92YUmxV3bZrAM2RRqr Q+eA1COM5DHjxwH8KpCEpij6tnAE7sfGlZwYE= MIME-Version: 1.0 Received: by 10.231.35.8 with SMTP id n8mr4876037ibd.78.1283710693816; Sun, 05 Sep 2010 11:18:13 -0700 (PDT) Sender: djmitche@gmail.com Received: by 10.231.200.93 with HTTP; Sun, 5 Sep 2010 11:18:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 5 Sep 2010 13:18:13 -0500 X-Google-Sender-Auth: 8xHhoi8dmH2oeEMoUEv3Oo9D028 Message-ID: From: "Dustin J. Mitchell" To: =?UTF-8?B?TWF0ZXbFviBNYXJrb3ZpxI0=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-scsi@freebsd.org Subject: Re: Working with tape drives X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 18:40:14 -0000 On Sun, Sep 5, 2010 at 11:53 AM, Matev=C5=BE Markovi=C4=8D wrote: > Can I just use standard C functions for dealing with files or should I us= e > mt? If mt is the answer, then how should I read, seek and write to the ta= pe? > I want to keep my C application as simple as possible. If manipulating wi= th > tape drives cannot be done with just simple C I/O functions, then is it > possible to create a wrapper to those functions? You'll want to use the POSIX mtio interface: http://www.gsp.com/cgi-bin/man.cgi?section=3D4&topic=3Dmtio Dustin --=20 Open Source Storage Engineer http://www.zmanda.com From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 5 20:57:58 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 9CD2910656A4 for ; Sun, 5 Sep 2010 20:57:58 +0000 (UTC) (envelope-from niklas@saers.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id F00848FC0A for ; Sun, 5 Sep 2010 20:57:57 +0000 (UTC) Received: by eyx24 with SMTP id 24so2097244eyx.13 for ; Sun, 05 Sep 2010 13:57:56 -0700 (PDT) Received: by 10.213.15.74 with SMTP id j10mr793069eba.74.1283720276708; Sun, 05 Sep 2010 13:57:56 -0700 (PDT) Received: from [192.168.0.199] (x1-6-00-24-01-67-20-00.k428.webspeed.dk [83.89.13.33]) by mx.google.com with ESMTPS id v8sm6874051eeh.20.2010.09.05.13.57.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 05 Sep 2010 13:57:55 -0700 (PDT) From: Niklas Saers To: Stephane LAPIE In-Reply-To: <4C80A52A.5080300@darkbsd.org> X-Mailer: iPad Mail (7B500) References: <4C80A52A.5080300@darkbsd.org> Message-Id: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 7B500) Date: Sun, 5 Sep 2010 22:58:21 +0200 Cc: "freebsd-scsi@freebsd.org" Subject: Re: mpt0 and removing disks X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 20:57:58 -0000 Hi Stephane, So should I understand it so that I cannot use the mpt-driver for = SAS-systems, or is it that I can't use SAS systems at all? If its the = first, could you recommend a JBOD controller that I should use instead? Cheers=20 Nik On 03/09/2010, at 09.35, Stephane LAPIE = wrote: > Hello, >=20 > I have refrained so far from building configurations based on = mpt-driver > based controllers (namely, the LSI SAS3081E-R controllers you = mention), > precisely because of similiar issues :/ >=20 > If you can look for "DELL SAS5/E Controller bug" in the > freebsd-hardware@ archives, John Baldwin and scottl@ answered this > question previously. >=20 > I experienced one difference, in that the pool would be frozen for = three > minutes before eventually recovering after having reset the whole > controller. Scott's explanation was basically that the framework was = not > handling SAS in an optimal fashion. >=20 >> The basic problem is that FreeBSD still sees all of this as parallel = SCSI, subject to rescans and resets and timeouts. It's fighting with = the SAS controller. I'll explain more below. >=20 >> Event 0x12 is "SAS Link status changed" >> Event 0x16 is "SAS Discovery Event" >>=20 >> Basically this means that the controller saw the link change and is = now trying to rediscover what is out there. >=20 > (The following explanations came as to why I got the same error = messages > as you while trying a camcontrol reset) >=20 >> We confused the controller by trying to reset the bus while it was = trying to do a discovery, and then we confused it even more because we = timed out trying to abort commands due to the reset. >=20 >> I'm working on code that will make FreeBSD more aware of how SAS = works. It's several months from being done, though. I'm not sure what = to have you try in the mean time. If you're brave, try stubbing out the = XPT_RESET_BUS, XPT_RESET_DEV, and XPT_ABORT code in mpt_cam.c >=20 > Sorry I can't give any further insight :/ >=20 > Cheers, >=20 > On 09/03/2010 03:42 PM, Niklas Saers wrote: >> Hi guys, >> We've just been delivered a system that I'm testing, consisting of: >> - SuperMicro CSE-847E16-R1400LPB (4U, PSU 2x1400W (1+1), SAS2 = expander) >> - SuperMicro X8DTL-iF LGA1366 Single >> - Intel Xeon E5620 2,4GHz, 12MB cache TRAY >> - 3x Hynix RAM 4 GB DDR3 1333 Reg. ECC >> - LSI SAS3081E-R, 8-port int. SAS - kit (CIe x8, 8-port SAS/SATA, 0, = 1, 1E, JBOD) >> - 3ware ML SFF-8087 til ML SFF-8087 0,6m (SAS cable, connect SFF-8087 = Controller) >> - 36x Samsung 2TB SATAII/5400 HD203WI (8.9ms, 32MB Cache, EcoGreen = F2) >>=20 >> The system will be a backup server running ZFS on FreeBSD 8.1, and = I'm more concerned with stability and volume size pr dollar than I am = about performance, hence the 2TB SATA drives. >>=20 >> Now, I've installed FreeBSD and set the disks up to 6x raidz1 with = six disks in each raidz1. Not necessarily the best configuration, but = that's not the issue for this discussion. The problem is that when I = pull a disk out (thus simulating it failing), the entire disk array = stops, and I cannot even do a 'reboot now', I have to cold boot the = machine to get it back online again. >>=20 >> This is me removing the disk that should be da0 while it's running: >>=20 >> mpt0: mpt_cam_event: 0x16 >> mpt0: mpt_cam_event: 0x12 >> mpt0: mpt_cam_event: 0x16 >> mpt0: mpt_cam_event: 0x16 >> mpt0: mpt_cam_event: 0x12 >> mpt0: mpt_cam_event: 0x16 >> mpt0: mpt_cam_event: 0x16 >> mpt0: mpt_cam_event: 0x12 >> mpt0: mpt_cam_event: 0x16 >> mpt0: request 0xffffff80005cbea0:40191 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: request 0xffffff80005d4f30:40192 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: attempting to abort req 0xffffff80005cbea0:40191 function 0 >> mpt0: request 0xffffff80005cb2d0:40193 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: request 0xffffff80005db3e0:40194 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005d9c40:40195 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005d1ae0:40196 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005dbb30:40197 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005da930:40198 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005d6e20:40199 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005d9610:40200 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: completing timedout/aborted req 0xffffff80005d9610:40200 >> mpt0: completing timedout/aborted req 0xffffff80005d6e20:40199 >> mpt0: completing timedout/aborted req 0xffffff80005da930:40198 >> mpt0: completing timedout/aborted req 0xffffff80005dbb30:40197 >> mpt0: completing timedout/aborted req 0xffffff80005d1ae0:40196 >> mpt0: completing timedout/aborted req 0xffffff80005d9c40:40195 >> mpt0: completing timedout/aborted req 0xffffff80005db3e0:40194 >> mpt0: completing timedout/aborted req 0xffffff80005cb2d0:40193 >> mpt0: completing timedout/aborted req 0xffffff80005d4f30:40192 >> mpt0: completing timedout/aborted req 0xffffff80005cbea0:40191 >> mpt0: abort of req 0xffffff80005cbea0:0 completed >> mpt0: request 0xffffff80005cf260:40250 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: request 0xffffff80005d2f20:40251 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: attempting to abort req 0xffffff80005cf260:40250 function 0 >> mpt0: request 0xffffff80005dc280:40252 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005d85c0:40253 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005dcd30:40254 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005cdbe0:40255 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005dcdc0:40256 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005d34c0:40257 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: request 0xffffff80005dca60:40258 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: request 0xffffff80005cd640:40259 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: completing timedout/aborted req 0xffffff80005cd640:40259 >> mpt0: completing timedout/aborted req 0xffffff80005dca60:40258 >> mpt0: completing timedout/aborted req 0xffffff80005d34c0:40257 >> mpt0: completing timedout/aborted req 0xffffff80005dcdc0:40256 >> mpt0: completing timedout/aborted req 0xffffff80005cdbe0:40255 >> mpt0: completing timedout/aborted req 0xffffff80005dcd30:40254 >> mpt0: completing timedout/aborted req 0xffffff80005d85c0:40253 >> mpt0: completing timedout/aborted req 0xffffff80005dc280:40252 >> mpt0: completing timedout/aborted req 0xffffff80005d2f20:40251 >> mpt0: completing timedout/aborted req 0xffffff80005cf260:40250 >> mpt0: abort of req 0xffffff80005cf260:0 completed >> mpt0: request 0xffffff80005dae40:40268 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: request 0xffffff80005db110:40269 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: attempting to abort req 0xffffff80005dae40:40268 function 0 >> mpt0: request 0xffffff80005d4750:40270 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: request 0xffffff80005d8a40:40271 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005d2e90:40272 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005d6eb0:40273 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005dad20:40274 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005ce720:40275 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005d62e0:40276 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005d3af0:40277 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: completing timedout/aborted req 0xffffff80005d3af0:40277 >> mpt0: completing timedout/aborted req 0xffffff80005d62e0:40276 >> mpt0: completing timedout/aborted req 0xffffff80005ce720:40275 >> mpt0: completing timedout/aborted req 0xffffff80005dad20:40274 >> mpt0: completing timedout/aborted req 0xffffff80005d6eb0:40273 >> mpt0: completing timedout/aborted req 0xffffff80005d2e90:40272 >> mpt0: completing timedout/aborted req 0xffffff80005d8a40:40271 >> mpt0: completing timedout/aborted req 0xffffff80005d4750:40270 >> mpt0: completing timedout/aborted req 0xffffff80005db110:40269 >> mpt0: completing timedout/aborted req 0xffffff80005dae40:40268 >> mpt0: abort of req 0xffffff80005dae40:0 completed >> mpt0: request 0xffffff80005d93d0:40279 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: request 0xffffff80005daff0:40280 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: attempting to abort req 0xffffff80005d93d0:40279 function 0 >> mpt0: request 0xffffff80005d2080:40281 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005cf020:40282 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005d3160:40283 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005d1930:40284 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005d2860:40285 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005ccdd0:40286 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: request 0xffffff80005da540:40287 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: request 0xffffff80005d1d20:40288 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: completing timedout/aborted req 0xffffff80005d1d20:40288 >> mpt0: completing timedout/aborted req 0xffffff80005da540:40287 >> mpt0: completing timedout/aborted req 0xffffff80005ccdd0:40286 >> mpt0: completing timedout/aborted req 0xffffff80005d2860:40285 >> mpt0: completing timedout/aborted req 0xffffff80005d1930:40284 >> mpt0: completing timedout/aborted req 0xffffff80005d3160:40283 >> mpt0: completing timedout/aborted req 0xffffff80005cf020:40282 >> mpt0: completing timedout/aborted req 0xffffff80005d2080:40281 >> mpt0: completing timedout/aborted req 0xffffff80005daff0:40280 >> mpt0: completing timedout/aborted req 0xffffff80005d93d0:40279 >> mpt0: abort of req 0xffffff80005d93d0:0 completed >> mpt0: request 0xffffff80005cd400:40290 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005d73c0:40291 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: attempting to abort req 0xffffff80005cd400:40290 function 0 >> mpt0: request 0xffffff80005d2e00:40292 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005ccf80:40293 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005cffe0:40294 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005d3550:40295 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005cc950:40296 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005d8260:40297 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: request 0xffffff80005ceba0:40298 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: request 0xffffff80005d1270:40299 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: completing timedout/aborted req 0xffffff80005d1270:40299 >> mpt0: completing timedout/aborted req 0xffffff80005ceba0:40298 >> mpt0: completing timedout/aborted req 0xffffff80005d8260:40297 >> mpt0: completing timedout/aborted req 0xffffff80005cc950:40296 >> mpt0: completing timedout/aborted req 0xffffff80005d3550:40295 >> mpt0: completing timedout/aborted req 0xffffff80005cffe0:40294 >> mpt0: completing timedout/aborted req 0xffffff80005ccf80:40293 >> mpt0: completing timedout/aborted req 0xffffff80005d2e00:40292 >> mpt0: completing timedout/aborted req 0xffffff80005d73c0:40291 >> mpt0: completing timedout/aborted req 0xffffff80005cd400:40290 >> mpt0: abort of req 0xffffff80005cd400:0 completed >> mpt0: request 0xffffff80005ce060:40301 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: request 0xffffff80005ce210:40302 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: attempting to abort req 0xffffff80005ce060:40301 function 0 >> mpt0: request 0xffffff80005d3a60:40303 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: request 0xffffff80005cde20:40304 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005cbc60:40305 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005db7d0:40306 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005cbe10:40307 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005cd7f0:40308 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: request 0xffffff80005d0850:40309 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005d1030:40310 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: completing timedout/aborted req 0xffffff80005d1030:40310 >> mpt0: completing timedout/aborted req 0xffffff80005d0850:40309 >> mpt0: completing timedout/aborted req 0xffffff80005cd7f0:40308 >> mpt0: completing timedout/aborted req 0xffffff80005cbe10:40307 >> mpt0: completing timedout/aborted req 0xffffff80005db7d0:40306 >> mpt0: completing timedout/aborted req 0xffffff80005cbc60:40305 >> mpt0: completing timedout/aborted req 0xffffff80005cde20:40304 >> mpt0: completing timedout/aborted req 0xffffff80005d3a60:40303 >> mpt0: completing timedout/aborted req 0xffffff80005ce210:40302 >> mpt0: completing timedout/aborted req 0xffffff80005ce060:40301 >> mpt0: abort of req 0xffffff80005ce060:0 completed >> mpt0: request 0xffffff80005cfd10:40312 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005d2350:40313 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: attempting to abort req 0xffffff80005cfd10:40312 function 0 >> mpt0: request 0xffffff80005cdd90:40314 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005dbce0:40315 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005d47e0:40316 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005ce450:40317 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005d7c30:40318 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005d2470:40319 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: request 0xffffff80005cb5a0:40320 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: request 0xffffff80005cc8c0:40321 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: completing timedout/aborted req 0xffffff80005cc8c0:40321 >> mpt0: completing timedout/aborted req 0xffffff80005cb5a0:40320 >> mpt0: completing timedout/aborted req 0xffffff80005d2470:40319 >> mpt0: completing timedout/aborted req 0xffffff80005d7c30:40318 >> mpt0: completing timedout/aborted req 0xffffff80005ce450:40317 >> mpt0: completing timedout/aborted req 0xffffff80005d47e0:40316 >> mpt0: completing timedout/aborted req 0xffffff80005dbce0:40315 >> mpt0: completing timedout/aborted req 0xffffff80005cdd90:40314 >> mpt0: completing timedout/aborted req 0xffffff80005d2350:40313 >> mpt0: completing timedout/aborted req 0xffffff80005cfd10:40312 >> mpt0: abort of req 0xffffff80005cfd10:0 completed >> mpt0: request 0xffffff80005db2c0:40323 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: request 0xffffff80005d3b80:40324 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: attempting to abort req 0xffffff80005db2c0:40323 function 0 >> mpt0: request 0xffffff80005d7f00:40325 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: request 0xffffff80005d4d80:40326 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005db470:40327 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005dc3a0:40328 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005d2980:40329 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005d72a0:40330 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: request 0xffffff80005d78d0:40331 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005d0f10:40332 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: completing timedout/aborted req 0xffffff80005d0f10:40332 >> mpt0: completing timedout/aborted req 0xffffff80005d78d0:40331 >> mpt0: completing timedout/aborted req 0xffffff80005d72a0:40330 >> mpt0: completing timedout/aborted req 0xffffff80005d2980:40329 >> mpt0: completing timedout/aborted req 0xffffff80005dc3a0:40328 >> mpt0: completing timedout/aborted req 0xffffff80005db470:40327 >> mpt0: completing timedout/aborted req 0xffffff80005d4d80:40326 >> mpt0: completing timedout/aborted req 0xffffff80005d7f00:40325 >> mpt0: completing timedout/aborted req 0xffffff80005d3b80:40324 >> mpt0: completing timedout/aborted req 0xffffff80005db2c0:40323 >> mpt0: abort of req 0xffffff80005db2c0:0 completed >> mpt0: request 0xffffff80005d5320:40334 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005cc050:40335 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: attempting to abort req 0xffffff80005d5320:40334 function 0 >> mpt0: request 0xffffff80005d2a10:40336 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005d7690:40337 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005d8770:40338 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005d6d00:40339 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005d92b0:40340 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005ce330:40341 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: request 0xffffff80005d84a0:40342 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: request 0xffffff80005d0220:40343 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: completing timedout/aborted req 0xffffff80005d0220:40343 >> mpt0: completing timedout/aborted req 0xffffff80005d84a0:40342 >> mpt0: completing timedout/aborted req 0xffffff80005ce330:40341 >> mpt0: completing timedout/aborted req 0xffffff80005d92b0:40340 >> mpt0: completing timedout/aborted req 0xffffff80005d6d00:40339 >> mpt0: completing timedout/aborted req 0xffffff80005d8770:40338 >> mpt0: completing timedout/aborted req 0xffffff80005d7690:40337 >> mpt0: completing timedout/aborted req 0xffffff80005d2a10:40336 >> mpt0: completing timedout/aborted req 0xffffff80005cc050:40335 >> mpt0: completing timedout/aborted req 0xffffff80005d5320:40334 >> mpt0: abort of req 0xffffff80005d5320:0 completed >> mpt0: request 0xffffff80005cc4d0:40345 timed out for ccb = 0xffffff0005f30800 (req->ccb 0xffffff0005f30800) >> mpt0: request 0xffffff80005cdac0:40346 timed out for ccb = 0xffffff0005c78800 (req->ccb 0xffffff0005c78800) >> mpt0: attempting to abort req 0xffffff80005cc4d0:40345 function 0 >> mpt0: request 0xffffff80005dc670:40347 timed out for ccb = 0xffffff0005c45000 (req->ccb 0xffffff0005c45000) >> mpt0: request 0xffffff80005dc940:40348 timed out for ccb = 0xffffff0170c5d000 (req->ccb 0xffffff0170c5d000) >> mpt0: request 0xffffff80005d1810:40349 timed out for ccb = 0xffffff0005c3e800 (req->ccb 0xffffff0005c3e800) >> mpt0: request 0xffffff80005cd520:40350 timed out for ccb = 0xffffff0170c54000 (req->ccb 0xffffff0170c54000) >> mpt0: request 0xffffff80005db6b0:40351 timed out for ccb = 0xffffff0005c79800 (req->ccb 0xffffff0005c79800) >> mpt0: request 0xffffff80005d1390:40352 timed out for ccb = 0xffffff0005f2f000 (req->ccb 0xffffff0005f2f000) >> mpt0: request 0xffffff80005d6520:40353 timed out for ccb = 0xffffff012db85000 (req->ccb 0xffffff012db85000) >> mpt0: request 0xffffff80005cf1d0:40354 timed out for ccb = 0xffffff0170c5d800 (req->ccb 0xffffff0170c5d800) >> mpt0: completing timedout/aborted req 0xffffff80005cf1d0:40354 >> mpt0: completing timedout/aborted req 0xffffff80005d6520:40353 >> mpt0: completing timedout/aborted req 0xffffff80005d1390:40352 >> mpt0: completing timedout/aborted req 0xffffff80005db6b0:40351 >> mpt0: completing timedout/aborted req 0xffffff80005cd520:40350 >> mpt0: completing timedout/aborted req 0xffffff80005d1810:40349 >> mpt0: completing timedout/aborted req 0xffffff80005dc940:40348 >> mpt0: completing timedout/aborted req 0xffffff80005dc670:40347 >> mpt0: completing timedout/aborted req 0xffffff80005cdac0:40346 >> mpt0: completing timedout/aborted req 0xffffff80005cc4d0:40345 >> mpt0: abort of req 0xffffff80005cc4d0:0 completed >>=20 >> And just in case, this is my zpool status just before that: >>=20 >> pool: tank >> state: ONLINE >> scrub: none requested >> config: >>=20 >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> da0 ONLINE 0 0 0 >> da1 ONLINE 0 0 0 >> da2 ONLINE 0 0 0 >> da3 ONLINE 0 0 0 >> da4 ONLINE 0 0 0 >> da5 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> da6 ONLINE 0 0 0 >> da7 ONLINE 0 0 0 >> da8 ONLINE 0 0 0 >> da9 ONLINE 0 0 0 >> da10 ONLINE 0 0 0 >> da11 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> da12 ONLINE 0 0 0 >> da13 ONLINE 0 0 0 >> da14 ONLINE 0 0 0 >> da15 ONLINE 0 0 0 >> da16 ONLINE 0 0 0 >> da17 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> da18 ONLINE 0 0 0 >> da19 ONLINE 0 0 0 >> da20 ONLINE 0 0 0 >> da21 ONLINE 0 0 0 >> da22 ONLINE 0 0 0 >> da23 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> da24 ONLINE 0 0 0 >> da25 ONLINE 0 0 0 >> da26 ONLINE 0 0 0 >> da27 ONLINE 0 0 0 >> da28 ONLINE 0 0 0 >> da29 ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> da30 ONLINE 0 0 0 >> da31 ONLINE 0 0 0 >> da32 ONLINE 0 0 0 >> da33 ONLINE 0 0 0 >> da34 ONLINE 0 0 0 >> da35 ONLINE 0 0 0 >>=20 >> errors: No known data errors >>=20 >> If I try to do for instance "camcontrol eject da0" first, I only get: = "Error received from stop unit command" >>=20 >> Any idea why the mpt-driver reacts this way when I pull out a disk = that is meant to be hot-swappable? Is it something in the driver? = Something in the hardware? Somthing known? Something that I've = misunderstood about being able to replace disks? >>=20 >> Cheers >>=20 >> Nik_______________________________________________ >> 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" >=20 > --=20 > Stephane LAPIE, EPITA SRS, Promo 2005 > "Even when they have digital readouts, I can't understand them." > --MegaTokyo >=20 From owner-freebsd-scsi@FreeBSD.ORG Sun Sep 5 23:17: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 7D1EC10656C3 for ; Sun, 5 Sep 2010 23:17:11 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4624B8FC16 for ; Sun, 5 Sep 2010 23:17:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 4662350BDB for ; Mon, 6 Sep 2010 00:17:10 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz8vP1f1xE8t for ; Mon, 6 Sep 2010 00:17:07 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id A02CF50BA4 for ; Mon, 6 Sep 2010 00:17:07 +0100 (BST) Message-ID: <4C8424F3.2010501@langille.org> Date: Sun, 05 Sep 2010 19:17:07 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4C78FF01.5020500@langille.org> In-Reply-To: <4C78FF01.5020500@langille.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: camcontrol rescan all - locks system X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 23:17:11 -0000 On 8/28/2010 8:20 AM, Dan Langille wrote: > Hi, > > Running FreeBSD 8.1 stable on this particular box. I ran a camcontrol > devlist and didn't see my external tape library listed. I powered it up > and ran a 'camcontrol rescan all'. Now the system is froxen. Not > crashed, but nearly frozen. It responds to pings. New ssh sessions are > not connecting. Existing ssh sessions take one command and do not > respond. The console takes my login id, but does not prompt for the > password. > > I could reboot, but I'm about to go out for a bit and figured I'd ask > here and see what happens in my absence. > > :) I tried this approach today. I did a 'camcontrol rescan 12' on one ssh session. In another, I saw this in /var/log/messages: Sep 5 19:11:45 kraken kernel: ahc0: Recovery Initiated Sep 5 19:11:45 kraken kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< Sep 5 19:11:45 kraken kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x15c Sep 5 19:11:45 kraken kernel: Card was paused Sep 5 19:11:45 kraken kernel: ACCUM = 0xf1, SINDEX = 0x20, DINDEX = 0xc0, ARG_2 = 0x3c Sep 5 19:11:45 kraken kernel: HCNT = 0x0 SCBPTR = 0x0 Sep 5 19:11:45 kraken kernel: SCSISIGI[0x34]:(BSYI|ATNI|MSGI) ERROR[0x0] SCSIBUSL[0xc0] Sep 5 19:11:45 kraken kernel: LASTPHASE[0x1]:(P_BUSFREE) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) Sep 5 19:11:45 kraken kernel: SBLKCTL[0x2]:(SELWIDE) SCSIRATE[0x88]:(WIDEXFER) SEQCTL[0x10]:(FASTMODE) Sep 5 19:11:45 kraken kernel: SEQ_FLAGS[0x40]:(NO_CDB_SENT) SSTAT0[0x5]:(DMADONE|SDONE) Sep 5 19:11:45 kraken kernel: SSTAT1[0x2]:(PHASECHG) SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x0] Sep 5 19:11:45 kraken kernel: SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) Sep 5 19:11:45 kraken kernel: SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) Sep 5 19:11:45 kraken kernel: DFSTATUS[0x6d]:(FIFOEMP|DFTHRESH|HDONE|FIFOQWDEMP|DFCACHETH) Sep 5 19:11:45 kraken kernel: STACK: 0x37 0x0 0x156 0x197 Sep 5 19:11:45 kraken kernel: SCB count = 254 Sep 5 19:11:45 kraken kernel: Kernel NEXTQSCB = 252 Sep 5 19:11:45 kraken kernel: Card NEXTQSCB = 242 Sep 5 19:11:45 kraken kernel: QINFIFO entries: 242 243 244 245 246 247 249 250 251 238 Sep 5 19:11:45 kraken kernel: Waiting Queue entries: Sep 5 19:11:45 kraken kernel: Disconnected Queue entries: Sep 5 19:11:45 kraken kernel: QOUTFIFO entries: Sep 5 19:11:45 kraken kernel: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Sep 5 19:11:45 kraken kernel: Sequencer SCB Info: Sep 5 19:11:45 kraken kernel: 0 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: SCB_TAG[0xf1] Sep 5 19:11:45 kraken kernel: 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:11:45 kraken kernel: Pending list: Sep 5 19:11:45 kraken kernel: 251 SCB_CONTROL[0x0] SCB_SCSIID[0xf7]:(TWIN_CHNLB|TWIN_TID) Sep 5 19:11:45 kraken kernel: SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 250 SCB_CONTROL[0x0] SCB_SCSIID[0xe7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 249 SCB_CONTROL[0x0] SCB_SCSIID[0xd7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 247 SCB_CONTROL[0x0] SCB_SCSIID[0xc7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 246 SCB_CONTROL[0x0] SCB_SCSIID[0xb7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 245 SCB_CONTROL[0x0] SCB_SCSIID[0xa7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 244 SCB_CONTROL[0x0] SCB_SCSIID[0x97]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 243 SCB_CONTROL[0x0] SCB_SCSIID[0x87]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 242 SCB_CONTROL[0x0] SCB_SCSIID[0x67] SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 241 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: 238 SCB_CONTROL[0x10]:(MK_MESSAGE) SCB_SCSIID[0x7] SCB_LUN[0x0] Sep 5 19:11:45 kraken kernel: Kernel Free SCB list: 240 239 248 253 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Sep 5 19:11:45 kraken kernel: Untagged Q(0): 238 Sep 5 19:11:45 kraken kernel: Untagged Q(5): 241 Sep 5 19:11:45 kraken kernel: Untagged Q(6): 242 Sep 5 19:11:45 kraken kernel: Untagged Q(8): 243 Sep 5 19:11:45 kraken kernel: Untagged Q(9): 244 Sep 5 19:11:45 kraken kernel: Untagged Q(10): 245 Sep 5 19:11:45 kraken kernel: Untagged Q(11): 246 Sep 5 19:11:45 kraken kernel: Untagged Q(12): 247 Sep 5 19:11:45 kraken kernel: Untagged Q(13): 249 Sep 5 19:11:45 kraken kernel: Untagged Q(14): 250 Sep 5 19:11:45 kraken kernel: Untagged Q(15): 251 Sep 5 19:11:45 kraken kernel: Sep 5 19:11:45 kraken kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> Sep 5 19:11:45 kraken kernel: (probe0:ahc0:0:0:0): SCB 0xee - timed out Sep 5 19:11:45 kraken kernel: sg[0] - Addr 0x5263f80 : Length 32 Sep 5 19:11:45 kraken kernel: (probe0:ahc0:0:0:0): Other SCB Timeout Sep 5 19:11:45 kraken kernel: ahc0: Timedout SCBs already complete. Interrupts may not be functioning. Then it seems to repeat: Sep 5 19:14:50 kraken kernel: ahc0: Recovery Initiated Sep 5 19:14:50 kraken kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< Sep 5 19:14:50 kraken kernel: ahc0: Dumping Card State while idle, at SEQADDR 0x15c Sep 5 19:14:50 kraken kernel: Card was paused Sep 5 19:14:50 kraken kernel: ACCUM = 0xf1, SINDEX = 0x20, DINDEX = 0xc0, ARG_2 = 0x3c Sep 5 19:14:50 kraken kernel: HCNT = 0x0 SCBPTR = 0x0 Sep 5 19:14:50 kraken kernel: SCSISIGI[0x34]:(BSYI|ATNI|MSGI) ERROR[0x0] SCSIBUSL[0x8] Sep 5 19:14:50 kraken kernel: LASTPHASE[0x1]:(P_BUSFREE) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) Sep 5 19:14:50 kraken kernel: SBLKCTL[0x2]:(SELWIDE) SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) Sep 5 19:14:50 kraken kernel: SEQ_FLAGS[0x40]:(NO_CDB_SENT) SSTAT0[0x5]:(DMADONE|SDONE) Sep 5 19:14:50 kraken kernel: SSTAT1[0x2]:(PHASECHG) SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x0] Sep 5 19:14:50 kraken kernel: SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) Sep 5 19:14:50 kraken kernel: SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x4]:(DIRECTION) Sep 5 19:14:50 kraken kernel: DFSTATUS[0x6d]:(FIFOEMP|DFTHRESH|HDONE|FIFOQWDEMP|DFCACHETH) Sep 5 19:14:50 kraken kernel: STACK: 0x37 0x37 0x156 0x197 Sep 5 19:14:50 kraken kernel: SCB count = 254 Sep 5 19:14:50 kraken kernel: Kernel NEXTQSCB = 252 Sep 5 19:14:50 kraken kernel: Card NEXTQSCB = 242 Sep 5 19:14:50 kraken kernel: QINFIFO entries: 242 243 244 245 246 247 249 250 251 238 Sep 5 19:14:50 kraken kernel: Waiting Queue entries: Sep 5 19:14:50 kraken kernel: Disconnected Queue entries: Sep 5 19:14:50 kraken kernel: QOUTFIFO entries: Sep 5 19:14:50 kraken kernel: Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Sep 5 19:14:50 kraken kernel: Sequencer SCB Info: Sep 5 19:14:50 kraken kernel: 0 SCB_CONTROL[0x50]:(MK_MESSAGE|DISCENB) SCB_SCSIID[0x57] Sep 5 19:14:50 kraken kernel: SCB_LUN[0x0] SCB_TAG[0xf1] Sep 5 19:14:50 kraken kernel: 1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: 15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff] Sep 5 19:14:50 kraken kernel: Pending list: Sep 5 19:14:50 kraken kernel: 238 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x7] SCB_LUN[0x80]:(SCB_XFERLEN_ODD) Sep 5 19:14:50 kraken kernel: 251 SCB_CONTROL[0x0] SCB_SCSIID[0xf7]:(TWIN_CHNLB|TWIN_TID) Sep 5 19:14:50 kraken kernel: SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 250 SCB_CONTROL[0x0] SCB_SCSIID[0xe7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 249 SCB_CONTROL[0x0] SCB_SCSIID[0xd7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 247 SCB_CONTROL[0x0] SCB_SCSIID[0xc7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 246 SCB_CONTROL[0x0] SCB_SCSIID[0xb7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 245 SCB_CONTROL[0x0] SCB_SCSIID[0xa7]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 244 SCB_CONTROL[0x0] SCB_SCSIID[0x97]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 243 SCB_CONTROL[0x0] SCB_SCSIID[0x87]:(TWIN_CHNLB) SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 242 SCB_CONTROL[0x0] SCB_SCSIID[0x67] SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: 241 SCB_CONTROL[0x50]:(MK_MESSAGE|DISCENB) SCB_SCSIID[0x57] Sep 5 19:14:50 kraken kernel: SCB_LUN[0x0] Sep 5 19:14:50 kraken kernel: Kernel Free SCB list: 240 239 248 253 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Sep 5 19:14:50 kraken kernel: Untagged Q(0): 238 Sep 5 19:14:50 kraken kernel: Untagged Q(5): 241 Sep 5 19:14:50 kraken kernel: Untagged Q(6): 242 Sep 5 19:14:50 kraken kernel: Untagged Q(8): 243 Sep 5 19:14:50 kraken kernel: Untagged Q(9): 244 Sep 5 19:14:50 kraken kernel: Untagged Q(10): 245 Sep 5 19:14:50 kraken kernel: Untagged Q(11): 246 Sep 5 19:14:50 kraken kernel: Untagged Q(12): 247 Sep 5 19:14:50 kraken kernel: Untagged Q(13): 249 Sep 5 19:14:50 kraken kernel: Untagged Q(14): 250 Sep 5 19:14:50 kraken kernel: Untagged Q(15): 251 Sep 5 19:14:50 kraken kernel: Sep 5 19:14:50 kraken kernel: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> Sep 5 19:14:50 kraken kernel: (probe8:ahc0:0:9:0): SCB 0xf4 - timed out Sep 5 19:14:50 kraken kernel: sg[0] - Addr 0xbfcc0f8 : Length 36 Sep 5 19:14:50 kraken kernel: (probe8:ahc0:0:9:0): Other SCB Timeout Sep 5 19:14:50 kraken kernel: (probe8:ahc0:0:9:0): No other SCB worth waiting for... Sep 5 19:14:50 kraken kernel: ahc0: Issued Channel A Bus Reset. 11 SCBs aborted Sep 5 19:14:50 kraken kernel: ahc0: Timedout SCBs already complete. Interrupts may not be functioning. etc... -- Dan Langille - http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 00:16:43 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 0F33710656A5 for ; Mon, 6 Sep 2010 00:16:43 +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 B89888FC14 for ; Mon, 6 Sep 2010 00:16:42 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o860GfhW003890 for ; Sun, 5 Sep 2010 17:16:41 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C8432EB.5080104@feral.com> Date: Sun, 05 Sep 2010 17:16:43 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4C78FF01.5020500@langille.org> <4C8424F3.2010501@langille.org> In-Reply-To: <4C8424F3.2010501@langille.org> 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.6 (ns1.feral.com [192.67.166.1]); Sun, 05 Sep 2010 17:16:42 -0700 (PDT) Subject: Re: camcontrol rescan all - locks system 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, 06 Sep 2010 00:16:43 -0000 On 9/5/2010 4:17 PM, Dan Langille wrote: > > I tried this approach today. I did a 'camcontrol rescan 12' on one ssh > session. In another, I saw this in /var/log/messages: \ This looks like an ahc issue, not a cam issue. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 00:40:39 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 7FB4410656C7 for ; Mon, 6 Sep 2010 00:40:39 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 545618FC12 for ; Mon, 6 Sep 2010 00:40:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 829BD50BA5 for ; Mon, 6 Sep 2010 01:40:38 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f0Z8SNEnGQZ for ; Mon, 6 Sep 2010 01:40:37 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id A646650BA4 for ; Mon, 6 Sep 2010 01:40:37 +0100 (BST) Message-ID: <4C843885.3000208@langille.org> Date: Sun, 05 Sep 2010 20:40:37 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4C78FF01.5020500@langille.org> <4C8424F3.2010501@langille.org> <4C8432EB.5080104@feral.com> In-Reply-To: <4C8432EB.5080104@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: camcontrol rescan all - locks system 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, 06 Sep 2010 00:40:39 -0000 On 9/5/2010 8:16 PM, Matthew Jacob wrote: > On 9/5/2010 4:17 PM, Dan Langille wrote: >> >> I tried this approach today. I did a 'camcontrol rescan 12' on one ssh >> session. In another, I saw this in /var/log/messages: \ > > This looks like an ahc issue, not a cam issue. I think you're saying the ahc is causing the issue. Perhaps I need to choose another SCSI card. -- Dan Langille - http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 01:21:24 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 38E8210656CA for ; Mon, 6 Sep 2010 01:21:24 +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 05BC78FC0A for ; Mon, 6 Sep 2010 01:21:23 +0000 (UTC) Received: from [192.168.1.2] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o861LMjg004174 for ; Sun, 5 Sep 2010 18:21:23 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C844215.2080508@feral.com> Date: Sun, 05 Sep 2010 18:21:25 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4C78FF01.5020500@langille.org> <4C8424F3.2010501@langille.org> <4C8432EB.5080104@feral.com> <4C843885.3000208@langille.org> In-Reply-To: <4C843885.3000208@langille.org> 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.6 (ns1.feral.com [192.67.166.1]); Sun, 05 Sep 2010 18:21:23 -0700 (PDT) Subject: Re: camcontrol rescan all - locks system 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, 06 Sep 2010 01:21:24 -0000 On 9/5/2010 5:40 PM, Dan Langille wrote: > On 9/5/2010 8:16 PM, Matthew Jacob wrote: >> On 9/5/2010 4:17 PM, Dan Langille wrote: >>> >>> I tried this approach today. I did a 'camcontrol rescan 12' on one ssh >>> session. In another, I saw this in /var/log/messages: \ >> >> This looks like an ahc issue, not a cam issue. > > I think you're saying the ahc is causing the issue. Perhaps I need to > choose another SCSI card. > You might try it if it's an easy thing to do. That would generate a lot of information. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 06:25: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 7B6571065696 for ; Mon, 6 Sep 2010 06:25:30 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4F85C8FC0C for ; Mon, 6 Sep 2010 06:25:28 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 5FCBF5427; Mon, 6 Sep 2010 08:25:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=selector1; bh=MdAj0tRgvodBRXn+3y6DlmqA0ZI=; b=P tRjS7NoLJlFazQOT5kPcTdEOkZWDv2qHMZs2qeqOI0Ag2sAe+ymBQnsZ7S3SH0UI OloDGSASDkA3JCujz3LY6gMSzSr7NuXnk+zeM0boIf8FGOHpMrmaQxlYb1tBeohN Z6CbBr+PUA1vHIQz1EtU76rDF/6jBWkhzjtY1XkPyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=selector1; b=ogfCAH77D4ABuikUFVbCuNYwI6c 5nHt3QHbVssdHER+N42/fZhVjeDl8uP9umgImkmjmjyqawwf9rWFqmY/glK+/sT8 j+r6cC13LNUW0qd8ba1x/HelhIDPXt58ru+i73H6wdxAJtjjgzFPnoiVP8/dn4pT OCmoiQTRolq1cXDU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbsd.org; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=selector1; t=1283754323; bh=rbI9hqj3+C1GpT+pqeRtGUi je9SWzCLOmP9yCe/NC/o=; b=MFBKfgs8ky8KQ685l6u4PVeMwMRtAzP/R70LsbP EbaLf0RWsGlHyStZyPZBp16nJ/lvh9Y+kZ6h9kmDJVdbbmNUlQAn3cKF3LWJg0ya KU4RZ4b4W5b8hBypECkwg1CUXpL0qodPjOgl4+Su2M4vm40ieLO1/gFfypVR0JqY 9BlQ= Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9h3nt+qaT1cB; Mon, 6 Sep 2010 08:25:23 +0200 (CEST) Received: from [192.168.162.153] (unknown [210.188.173.245]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 76C015420; Mon, 6 Sep 2010 08:25:22 +0200 (CEST) Message-ID: <4C848949.8000909@darkbsd.org> Date: Mon, 06 Sep 2010 15:25:13 +0900 From: Stephane LAPIE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Niklas Saers References: <4C80A52A.5080300@darkbsd.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB94AA71C98961361CFFE7CCE" Cc: "freebsd-scsi@freebsd.org" Subject: Re: mpt0 and removing disks 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, 06 Sep 2010 06:25:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB94AA71C98961361CFFE7CCE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nik, In my understanding, while far from perfect, mpt and SAS should be working with a few unresolved SCSI/SAS quirks (that should not be THAT crippling). I have been considering Areca JBOD controllers, but haven't had any opportunity of testing one or heard any account of it being tested and working under FreeBSD. Cheers, On 09/06/2010 05:58 AM, Niklas Saers wrote: > Hi Stephane, > So should I understand it so that I cannot use the mpt-driver for SAS-s= ystems, or is it that I can't use SAS systems at all? If its the first, c= ould you recommend a JBOD controller that I should use instead? >=20 > Cheers=20 >=20 > Nik >=20 > On 03/09/2010, at 09.35, Stephane LAPIE wr= ote: >=20 >> Hello, >> >> I have refrained so far from building configurations based on mpt-driv= er >> based controllers (namely, the LSI SAS3081E-R controllers you mention)= , >> precisely because of similiar issues :/ >> >> If you can look for "DELL SAS5/E Controller bug" in the >> freebsd-hardware@ archives, John Baldwin and scottl@ answered this >> question previously. >> >> I experienced one difference, in that the pool would be frozen for thr= ee >> minutes before eventually recovering after having reset the whole >> controller. Scott's explanation was basically that the framework was n= ot >> handling SAS in an optimal fashion. >> >>> The basic problem is that FreeBSD still sees all of this as parallel = SCSI, subject to rescans and resets and timeouts. It's fighting with the= SAS controller. I'll explain more below. >> >>> Event 0x12 is "SAS Link status changed" >>> Event 0x16 is "SAS Discovery Event" >>> >>> Basically this means that the controller saw the link change and is n= ow trying to rediscover what is out there. >> >> (The following explanations came as to why I got the same error messag= es >> as you while trying a camcontrol reset) >> >>> We confused the controller by trying to reset the bus while it was tr= ying to do a discovery, and then we confused it even more because we time= d out trying to abort commands due to the reset. >> >>> I'm working on code that will make FreeBSD more aware of how SAS work= s. It's several months from being done, though. I'm not sure what to ha= ve you try in the mean time. If you're brave, try stubbing out the XPT_R= ESET_BUS, XPT_RESET_DEV, and XPT_ABORT code in mpt_cam.c >> >> Sorry I can't give any further insight :/ >> >> Cheers, >> >> On 09/03/2010 03:42 PM, Niklas Saers wrote: >>> Hi guys, >>> We've just been delivered a system that I'm testing, consisting of: >>> - SuperMicro CSE-847E16-R1400LPB (4U, PSU 2x1400W (1+1), SAS2 expande= r) >>> - SuperMicro X8DTL-iF LGA1366 Single >>> - Intel Xeon E5620 2,4GHz, 12MB cache TRAY >>> - 3x Hynix RAM 4 GB DDR3 1333 Reg. ECC >>> - LSI SAS3081E-R, 8-port int. SAS - kit (CIe x8, 8-port SAS/SATA, 0, = 1, 1E, JBOD) >>> - 3ware ML SFF-8087 til ML SFF-8087 0,6m (SAS cable, connect SFF-8087= Controller) >>> - 36x Samsung 2TB SATAII/5400 HD203WI (8.9ms, 32MB Cache, EcoGreen F2= ) >>> >>> The system will be a backup server running ZFS on FreeBSD 8.1, and I'= m more concerned with stability and volume size pr dollar than I am about= performance, hence the 2TB SATA drives. >>> >>> Now, I've installed FreeBSD and set the disks up to 6x raidz1 with si= x disks in each raidz1. Not necessarily the best configuration, but that'= s not the issue for this discussion. The problem is that when I pull a di= sk out (thus simulating it failing), the entire disk array stops, and I c= annot even do a 'reboot now', I have to cold boot the machine to get it b= ack online again. >>> >>> This is me removing the disk that should be da0 while it's running: >>> >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x12 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x12 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: mpt_cam_event: 0x12 >>> mpt0: mpt_cam_event: 0x16 >>> mpt0: request 0xffffff80005cbea0:40191 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: request 0xffffff80005d4f30:40192 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: attempting to abort req 0xffffff80005cbea0:40191 function 0 >>> mpt0: request 0xffffff80005cb2d0:40193 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: request 0xffffff80005db3e0:40194 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005d9c40:40195 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005d1ae0:40196 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005dbb30:40197 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005da930:40198 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005d6e20:40199 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005d9610:40200 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: completing timedout/aborted req 0xffffff80005d9610:40200 >>> mpt0: completing timedout/aborted req 0xffffff80005d6e20:40199 >>> mpt0: completing timedout/aborted req 0xffffff80005da930:40198 >>> mpt0: completing timedout/aborted req 0xffffff80005dbb30:40197 >>> mpt0: completing timedout/aborted req 0xffffff80005d1ae0:40196 >>> mpt0: completing timedout/aborted req 0xffffff80005d9c40:40195 >>> mpt0: completing timedout/aborted req 0xffffff80005db3e0:40194 >>> mpt0: completing timedout/aborted req 0xffffff80005cb2d0:40193 >>> mpt0: completing timedout/aborted req 0xffffff80005d4f30:40192 >>> mpt0: completing timedout/aborted req 0xffffff80005cbea0:40191 >>> mpt0: abort of req 0xffffff80005cbea0:0 completed >>> mpt0: request 0xffffff80005cf260:40250 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: request 0xffffff80005d2f20:40251 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: attempting to abort req 0xffffff80005cf260:40250 function 0 >>> mpt0: request 0xffffff80005dc280:40252 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005d85c0:40253 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005dcd30:40254 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005cdbe0:40255 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005dcdc0:40256 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005d34c0:40257 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: request 0xffffff80005dca60:40258 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: request 0xffffff80005cd640:40259 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: completing timedout/aborted req 0xffffff80005cd640:40259 >>> mpt0: completing timedout/aborted req 0xffffff80005dca60:40258 >>> mpt0: completing timedout/aborted req 0xffffff80005d34c0:40257 >>> mpt0: completing timedout/aborted req 0xffffff80005dcdc0:40256 >>> mpt0: completing timedout/aborted req 0xffffff80005cdbe0:40255 >>> mpt0: completing timedout/aborted req 0xffffff80005dcd30:40254 >>> mpt0: completing timedout/aborted req 0xffffff80005d85c0:40253 >>> mpt0: completing timedout/aborted req 0xffffff80005dc280:40252 >>> mpt0: completing timedout/aborted req 0xffffff80005d2f20:40251 >>> mpt0: completing timedout/aborted req 0xffffff80005cf260:40250 >>> mpt0: abort of req 0xffffff80005cf260:0 completed >>> mpt0: request 0xffffff80005dae40:40268 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: request 0xffffff80005db110:40269 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: attempting to abort req 0xffffff80005dae40:40268 function 0 >>> mpt0: request 0xffffff80005d4750:40270 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: request 0xffffff80005d8a40:40271 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005d2e90:40272 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005d6eb0:40273 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005dad20:40274 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005ce720:40275 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005d62e0:40276 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005d3af0:40277 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: completing timedout/aborted req 0xffffff80005d3af0:40277 >>> mpt0: completing timedout/aborted req 0xffffff80005d62e0:40276 >>> mpt0: completing timedout/aborted req 0xffffff80005ce720:40275 >>> mpt0: completing timedout/aborted req 0xffffff80005dad20:40274 >>> mpt0: completing timedout/aborted req 0xffffff80005d6eb0:40273 >>> mpt0: completing timedout/aborted req 0xffffff80005d2e90:40272 >>> mpt0: completing timedout/aborted req 0xffffff80005d8a40:40271 >>> mpt0: completing timedout/aborted req 0xffffff80005d4750:40270 >>> mpt0: completing timedout/aborted req 0xffffff80005db110:40269 >>> mpt0: completing timedout/aborted req 0xffffff80005dae40:40268 >>> mpt0: abort of req 0xffffff80005dae40:0 completed >>> mpt0: request 0xffffff80005d93d0:40279 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: request 0xffffff80005daff0:40280 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: attempting to abort req 0xffffff80005d93d0:40279 function 0 >>> mpt0: request 0xffffff80005d2080:40281 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005cf020:40282 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005d3160:40283 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005d1930:40284 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005d2860:40285 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005ccdd0:40286 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: request 0xffffff80005da540:40287 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: request 0xffffff80005d1d20:40288 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: completing timedout/aborted req 0xffffff80005d1d20:40288 >>> mpt0: completing timedout/aborted req 0xffffff80005da540:40287 >>> mpt0: completing timedout/aborted req 0xffffff80005ccdd0:40286 >>> mpt0: completing timedout/aborted req 0xffffff80005d2860:40285 >>> mpt0: completing timedout/aborted req 0xffffff80005d1930:40284 >>> mpt0: completing timedout/aborted req 0xffffff80005d3160:40283 >>> mpt0: completing timedout/aborted req 0xffffff80005cf020:40282 >>> mpt0: completing timedout/aborted req 0xffffff80005d2080:40281 >>> mpt0: completing timedout/aborted req 0xffffff80005daff0:40280 >>> mpt0: completing timedout/aborted req 0xffffff80005d93d0:40279 >>> mpt0: abort of req 0xffffff80005d93d0:0 completed >>> mpt0: request 0xffffff80005cd400:40290 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005d73c0:40291 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: attempting to abort req 0xffffff80005cd400:40290 function 0 >>> mpt0: request 0xffffff80005d2e00:40292 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005ccf80:40293 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005cffe0:40294 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005d3550:40295 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005cc950:40296 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005d8260:40297 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: request 0xffffff80005ceba0:40298 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: request 0xffffff80005d1270:40299 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: completing timedout/aborted req 0xffffff80005d1270:40299 >>> mpt0: completing timedout/aborted req 0xffffff80005ceba0:40298 >>> mpt0: completing timedout/aborted req 0xffffff80005d8260:40297 >>> mpt0: completing timedout/aborted req 0xffffff80005cc950:40296 >>> mpt0: completing timedout/aborted req 0xffffff80005d3550:40295 >>> mpt0: completing timedout/aborted req 0xffffff80005cffe0:40294 >>> mpt0: completing timedout/aborted req 0xffffff80005ccf80:40293 >>> mpt0: completing timedout/aborted req 0xffffff80005d2e00:40292 >>> mpt0: completing timedout/aborted req 0xffffff80005d73c0:40291 >>> mpt0: completing timedout/aborted req 0xffffff80005cd400:40290 >>> mpt0: abort of req 0xffffff80005cd400:0 completed >>> mpt0: request 0xffffff80005ce060:40301 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: request 0xffffff80005ce210:40302 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: attempting to abort req 0xffffff80005ce060:40301 function 0 >>> mpt0: request 0xffffff80005d3a60:40303 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: request 0xffffff80005cde20:40304 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005cbc60:40305 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005db7d0:40306 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005cbe10:40307 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005cd7f0:40308 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: request 0xffffff80005d0850:40309 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005d1030:40310 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: completing timedout/aborted req 0xffffff80005d1030:40310 >>> mpt0: completing timedout/aborted req 0xffffff80005d0850:40309 >>> mpt0: completing timedout/aborted req 0xffffff80005cd7f0:40308 >>> mpt0: completing timedout/aborted req 0xffffff80005cbe10:40307 >>> mpt0: completing timedout/aborted req 0xffffff80005db7d0:40306 >>> mpt0: completing timedout/aborted req 0xffffff80005cbc60:40305 >>> mpt0: completing timedout/aborted req 0xffffff80005cde20:40304 >>> mpt0: completing timedout/aborted req 0xffffff80005d3a60:40303 >>> mpt0: completing timedout/aborted req 0xffffff80005ce210:40302 >>> mpt0: completing timedout/aborted req 0xffffff80005ce060:40301 >>> mpt0: abort of req 0xffffff80005ce060:0 completed >>> mpt0: request 0xffffff80005cfd10:40312 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005d2350:40313 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: attempting to abort req 0xffffff80005cfd10:40312 function 0 >>> mpt0: request 0xffffff80005cdd90:40314 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005dbce0:40315 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005d47e0:40316 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005ce450:40317 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005d7c30:40318 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005d2470:40319 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: request 0xffffff80005cb5a0:40320 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: request 0xffffff80005cc8c0:40321 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: completing timedout/aborted req 0xffffff80005cc8c0:40321 >>> mpt0: completing timedout/aborted req 0xffffff80005cb5a0:40320 >>> mpt0: completing timedout/aborted req 0xffffff80005d2470:40319 >>> mpt0: completing timedout/aborted req 0xffffff80005d7c30:40318 >>> mpt0: completing timedout/aborted req 0xffffff80005ce450:40317 >>> mpt0: completing timedout/aborted req 0xffffff80005d47e0:40316 >>> mpt0: completing timedout/aborted req 0xffffff80005dbce0:40315 >>> mpt0: completing timedout/aborted req 0xffffff80005cdd90:40314 >>> mpt0: completing timedout/aborted req 0xffffff80005d2350:40313 >>> mpt0: completing timedout/aborted req 0xffffff80005cfd10:40312 >>> mpt0: abort of req 0xffffff80005cfd10:0 completed >>> mpt0: request 0xffffff80005db2c0:40323 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: request 0xffffff80005d3b80:40324 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: attempting to abort req 0xffffff80005db2c0:40323 function 0 >>> mpt0: request 0xffffff80005d7f00:40325 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: request 0xffffff80005d4d80:40326 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005db470:40327 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005dc3a0:40328 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005d2980:40329 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005d72a0:40330 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: request 0xffffff80005d78d0:40331 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005d0f10:40332 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: completing timedout/aborted req 0xffffff80005d0f10:40332 >>> mpt0: completing timedout/aborted req 0xffffff80005d78d0:40331 >>> mpt0: completing timedout/aborted req 0xffffff80005d72a0:40330 >>> mpt0: completing timedout/aborted req 0xffffff80005d2980:40329 >>> mpt0: completing timedout/aborted req 0xffffff80005dc3a0:40328 >>> mpt0: completing timedout/aborted req 0xffffff80005db470:40327 >>> mpt0: completing timedout/aborted req 0xffffff80005d4d80:40326 >>> mpt0: completing timedout/aborted req 0xffffff80005d7f00:40325 >>> mpt0: completing timedout/aborted req 0xffffff80005d3b80:40324 >>> mpt0: completing timedout/aborted req 0xffffff80005db2c0:40323 >>> mpt0: abort of req 0xffffff80005db2c0:0 completed >>> mpt0: request 0xffffff80005d5320:40334 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005cc050:40335 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: attempting to abort req 0xffffff80005d5320:40334 function 0 >>> mpt0: request 0xffffff80005d2a10:40336 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005d7690:40337 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005d8770:40338 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005d6d00:40339 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005d92b0:40340 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005ce330:40341 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: request 0xffffff80005d84a0:40342 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: request 0xffffff80005d0220:40343 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: completing timedout/aborted req 0xffffff80005d0220:40343 >>> mpt0: completing timedout/aborted req 0xffffff80005d84a0:40342 >>> mpt0: completing timedout/aborted req 0xffffff80005ce330:40341 >>> mpt0: completing timedout/aborted req 0xffffff80005d92b0:40340 >>> mpt0: completing timedout/aborted req 0xffffff80005d6d00:40339 >>> mpt0: completing timedout/aborted req 0xffffff80005d8770:40338 >>> mpt0: completing timedout/aborted req 0xffffff80005d7690:40337 >>> mpt0: completing timedout/aborted req 0xffffff80005d2a10:40336 >>> mpt0: completing timedout/aborted req 0xffffff80005cc050:40335 >>> mpt0: completing timedout/aborted req 0xffffff80005d5320:40334 >>> mpt0: abort of req 0xffffff80005d5320:0 completed >>> mpt0: request 0xffffff80005cc4d0:40345 timed out for ccb 0xffffff0005= f30800 (req->ccb 0xffffff0005f30800) >>> mpt0: request 0xffffff80005cdac0:40346 timed out for ccb 0xffffff0005= c78800 (req->ccb 0xffffff0005c78800) >>> mpt0: attempting to abort req 0xffffff80005cc4d0:40345 function 0 >>> mpt0: request 0xffffff80005dc670:40347 timed out for ccb 0xffffff0005= c45000 (req->ccb 0xffffff0005c45000) >>> mpt0: request 0xffffff80005dc940:40348 timed out for ccb 0xffffff0170= c5d000 (req->ccb 0xffffff0170c5d000) >>> mpt0: request 0xffffff80005d1810:40349 timed out for ccb 0xffffff0005= c3e800 (req->ccb 0xffffff0005c3e800) >>> mpt0: request 0xffffff80005cd520:40350 timed out for ccb 0xffffff0170= c54000 (req->ccb 0xffffff0170c54000) >>> mpt0: request 0xffffff80005db6b0:40351 timed out for ccb 0xffffff0005= c79800 (req->ccb 0xffffff0005c79800) >>> mpt0: request 0xffffff80005d1390:40352 timed out for ccb 0xffffff0005= f2f000 (req->ccb 0xffffff0005f2f000) >>> mpt0: request 0xffffff80005d6520:40353 timed out for ccb 0xffffff012d= b85000 (req->ccb 0xffffff012db85000) >>> mpt0: request 0xffffff80005cf1d0:40354 timed out for ccb 0xffffff0170= c5d800 (req->ccb 0xffffff0170c5d800) >>> mpt0: completing timedout/aborted req 0xffffff80005cf1d0:40354 >>> mpt0: completing timedout/aborted req 0xffffff80005d6520:40353 >>> mpt0: completing timedout/aborted req 0xffffff80005d1390:40352 >>> mpt0: completing timedout/aborted req 0xffffff80005db6b0:40351 >>> mpt0: completing timedout/aborted req 0xffffff80005cd520:40350 >>> mpt0: completing timedout/aborted req 0xffffff80005d1810:40349 >>> mpt0: completing timedout/aborted req 0xffffff80005dc940:40348 >>> mpt0: completing timedout/aborted req 0xffffff80005dc670:40347 >>> mpt0: completing timedout/aborted req 0xffffff80005cdac0:40346 >>> mpt0: completing timedout/aborted req 0xffffff80005cc4d0:40345 >>> mpt0: abort of req 0xffffff80005cc4d0:0 completed >>> >>> And just in case, this is my zpool status just before that: >>> >>> pool: tank >>> state: ONLINE >>> scrub: none requested >>> config: >>> >>> NAME STATE READ WRITE CKSUM >>> tank ONLINE 0 0 0 >>> raidz1 ONLINE 0 0 0 >>> da0 ONLINE 0 0 0 >>> da1 ONLINE 0 0 0 >>> da2 ONLINE 0 0 0 >>> da3 ONLINE 0 0 0 >>> da4 ONLINE 0 0 0 >>> da5 ONLINE 0 0 0 >>> raidz1 ONLINE 0 0 0 >>> da6 ONLINE 0 0 0 >>> da7 ONLINE 0 0 0 >>> da8 ONLINE 0 0 0 >>> da9 ONLINE 0 0 0 >>> da10 ONLINE 0 0 0 >>> da11 ONLINE 0 0 0 >>> raidz1 ONLINE 0 0 0 >>> da12 ONLINE 0 0 0 >>> da13 ONLINE 0 0 0 >>> da14 ONLINE 0 0 0 >>> da15 ONLINE 0 0 0 >>> da16 ONLINE 0 0 0 >>> da17 ONLINE 0 0 0 >>> raidz1 ONLINE 0 0 0 >>> da18 ONLINE 0 0 0 >>> da19 ONLINE 0 0 0 >>> da20 ONLINE 0 0 0 >>> da21 ONLINE 0 0 0 >>> da22 ONLINE 0 0 0 >>> da23 ONLINE 0 0 0 >>> raidz1 ONLINE 0 0 0 >>> da24 ONLINE 0 0 0 >>> da25 ONLINE 0 0 0 >>> da26 ONLINE 0 0 0 >>> da27 ONLINE 0 0 0 >>> da28 ONLINE 0 0 0 >>> da29 ONLINE 0 0 0 >>> raidz1 ONLINE 0 0 0 >>> da30 ONLINE 0 0 0 >>> da31 ONLINE 0 0 0 >>> da32 ONLINE 0 0 0 >>> da33 ONLINE 0 0 0 >>> da34 ONLINE 0 0 0 >>> da35 ONLINE 0 0 0 >>> >>> errors: No known data errors >>> >>> If I try to do for instance "camcontrol eject da0" first, I only get:= "Error received from stop unit command" >>> >>> Any idea why the mpt-driver reacts this way when I pull out a disk th= at is meant to be hot-swappable? Is it something in the driver? Something= in the hardware? Somthing known? Something that I've misunderstood about= being able to replace disks? >>> >>> Cheers >>> >>> Nik_______________________________________________ >>> freebsd-scsi@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >>> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.or= g" >> >> --=20 >> Stephane LAPIE, EPITA SRS, Promo 2005 >> "Even when they have digital readouts, I can't understand them." >> --MegaTokyo >> --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enigB94AA71C98961361CFFE7CCE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyEiUkACgkQ24Ql8u6TF2PVRwCg2AlJepkG12x7Az16bHLHz6Hj iPQAn1nGj8w5DamsPIJr+VwL+ngpU4JF =i58i -----END PGP SIGNATURE----- --------------enigB94AA71C98961361CFFE7CCE-- From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 09:27: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 065B310656BE for ; Mon, 6 Sep 2010 09:27:56 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id BB3148FC21 for ; Mon, 6 Sep 2010 09:27:55 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 1E4911FFC36; Mon, 6 Sep 2010 09:12:35 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E82BC84525; Mon, 6 Sep 2010 11:12:34 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Stephane LAPIE References: <4C80A52A.5080300@darkbsd.org> <4C848949.8000909@darkbsd.org> Date: Mon, 06 Sep 2010 11:12:34 +0200 In-Reply-To: <4C848949.8000909@darkbsd.org> (Stephane LAPIE's message of "Mon, 06 Sep 2010 15:25:13 +0900") Message-ID: <8639tnutfh.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-scsi@freebsd.org" , Niklas Saers Subject: Re: mpt0 and removing disks 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, 06 Sep 2010 09:27:56 -0000 Stephane LAPIE writes: > In my understanding, while far from perfect, mpt and SAS should be > working with a few unresolved SCSI/SAS quirks (that should not be THAT > crippling). If you can provide some hints about how to fix those quirks, I (and Niklas) would be very grateful... Someone mentioned "stubbing out the XPT_RESET_BUS, XPT_RESET_DEV, and XPT_ABORT code in mpt_cam.c"; can you expand a little on that? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 09:47:38 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 2512A10656A4 for ; Mon, 6 Sep 2010 09:47:38 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0CC48FC08 for ; Mon, 6 Sep 2010 09:47:37 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id 3638C54E7; Mon, 6 Sep 2010 11:47:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; s=selector1; bh=rM67BmVoYCoJGWd4cpVx71sj/xU=; b=s kO3JkLEeNJxM/lT+sLsMH8P6ihYg52vzk59OjaUkPjUId/glW/RZLXRk885t6rz/ IBsbpvldFkNmXaJV+s0ltsLZxI1lem9FsYP1ZI2NZuR+Eka5JSw87SEFeZvwmedm Km7zK5glS87e4NzPMx4wcjeCAi2tVeKCo6rv1k5p3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=darkbsd.org; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type; q=dns; s=selector1; b=zcK+IdsnZvxDkQ40bTzj97BfsDP Tft2lLSUFVdiQJgSHTlyKXlVqbBPbRwrP9ozadkVoKNh4NjHUvsRrqpkOpnRl5J/ NDggPqyGIldV12IeXkTcVfnJA0h8JxM1SWo001ox964E6Xp0ZjNGsAF1VkWxpTUi kNFAAMzuYWhdKEZU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbsd.org; h= content-type:content-type:in-reply-to:references:subject:subject :mime-version:user-agent:from:from:date:date:message-id:received :received; s=selector1; t=1283766453; bh=wQqOEVp2jL8YuNgn8QHDlUg erFI0Vl6redlBsyMWJek=; b=iSd61Yvx6weCe4xMdSbrurKY8g33MnGgKEypZln mrnG0Y+ZRRO0hLKcWfcUFr4HQGVKb8V2hM6D6RDeDxC9Hw3sTZB9tiJkEUaOEz6f YUm0+t9ERDG2Bp5bkBx3m1qcgfwZTKZ7s0wV0SA0mQxrITLwU+nVipVVA2AzCPYb ozRU= Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FvGBVgA+poEX; Mon, 6 Sep 2010 11:47:33 +0200 (CEST) Received: from [192.168.162.153] (unknown [210.188.173.245]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id 79B2454E0; Mon, 6 Sep 2010 11:47:32 +0200 (CEST) Message-ID: <4C84B8AD.2070503@darkbsd.org> Date: Mon, 06 Sep 2010 18:47:25 +0900 From: Stephane LAPIE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <4C80A52A.5080300@darkbsd.org> <4C848949.8000909@darkbsd.org> <8639tnutfh.fsf@ds4.des.no> In-Reply-To: <8639tnutfh.fsf@ds4.des.no> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig23276BC3D0D81716007C359D" Cc: "freebsd-scsi@freebsd.org" , Niklas Saers Subject: Re: mpt0 and removing disks 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, 06 Sep 2010 09:47:38 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig23276BC3D0D81716007C359D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/06/2010 06:12 PM, Dag-Erling Sm=C3=B8rgrav wrote: > Stephane LAPIE writes: >> In my understanding, while far from perfect, mpt and SAS should be >> working with a few unresolved SCSI/SAS quirks (that should not be THAT= >> crippling). >=20 > If you can provide some hints about how to fix those quirks, I (and > Niklas) would be very grateful... Someone mentioned "stubbing out the > XPT_RESET_BUS, XPT_RESET_DEV, and XPT_ABORT code in mpt_cam.c"; can you= > expand a little on that? This is the problem : I have no actual solid experience coding anything related to SAS/SCSI in the FreeBSD kernel, and so I just don't know how to "fix" it myself for sure or produce anything stable. Just so there is no misunderstanding : I am not developping for FreeBSD, and while I have a "hacker-in-my-free-time"'s understanding, I can't provide clear steps or explanations on what to do to obtain a perfect result. I didn't have the time to look into the above code (and even if I could do this during my work hours, there is no way they would let me use this code in production since it would be a 3rd party patch, hence making it useless for me in a work-context), but what this certainly refers to is : "remove the SCSI handler code for MPT controllers for these event flags, so that the kernel doesn't mis-handle them and let the controller sort it out on his own". I don't have at this point a machine equipped with an MPT controller that I can use for development purposes and build FreeBSD on, so I can't test/elaborate any further. Cheers. --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enig23276BC3D0D81716007C359D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyEuK0ACgkQ24Ql8u6TF2MZrwCcDD6Z1mbErwCnuB+yP+R7GPgy YC0Anjd1Xh15FMdtBSK6M+7b2eGOqYkn =M8XK -----END PGP SIGNATURE----- --------------enig23276BC3D0D81716007C359D-- From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 11:07:03 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 D09A010656DA for ; Mon, 6 Sep 2010 11:07:03 +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 BEB6D8FC13 for ; Mon, 6 Sep 2010 11:07:03 +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 o86B73Kf011885 for ; Mon, 6 Sep 2010 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o86B73oj011883 for freebsd-scsi@FreeBSD.org; Mon, 6 Sep 2010 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Sep 2010 11:07:03 GMT Message-Id: <201009061107.o86B73oj011883@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, 06 Sep 2010 11:07:03 -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/149502 scsi [mpt] Latent buglet in debug print code o kern/148785 scsi [twa] [patch] twa driver doesn't pass proper max. io s o kern/148083 scsi [aac] Strange device reporting o kern/147704 scsi [mpt] sys/dev/mpt: new chip revision, partially unsupp o kern/146287 scsi [ciss] ciss(4) cannot see more than one SmartArray con o kern/145768 scsi [mpt] can't perform I/O on SAS based SAN disk in freeb o kern/144648 scsi [aac] Strange values of speed and bus width in dmesg o kern/144301 scsi [ciss] [hang] HP proliant server locks when using ciss o kern/142351 scsi [mpt] LSILogic driver performance problems o kern/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 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 42 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Sep 6 16:06:49 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 1531010656DA for ; Mon, 6 Sep 2010 16:06:49 +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 D2BCE8FC26 for ; Mon, 6 Sep 2010 16:06:48 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o86G6akP096711 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 6 Sep 2010 09:06:48 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4C851187.8030501@feral.com> Date: Mon, 06 Sep 2010 09:06:31 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4C80A52A.5080300@darkbsd.org> <4C848949.8000909@darkbsd.org> <8639tnutfh.fsf@ds4.des.no> <4C84B8AD.2070503@darkbsd.org> In-Reply-To: <4C84B8AD.2070503@darkbsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Mon, 06 Sep 2010 09:06:48 -0700 (PDT) Subject: Re: mpt0 and removing disks 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, 06 Sep 2010 16:06:49 -0000 I'll repeat what I've said before: mpt was not designed to support hotplugging. There is *some* support for it for the Fibre Channel HBAs, but I don't know if they even work. That doesn't mean it couldn't be changed for this. The problem here is that this would require a fair amount of work for what is now obsolete hardware. I doubt you can get too many people interested in this. As for 'warm plugging', that's doable. Make sure nothing is using the device you want to pull, give indication to pull it, and issue 'camcontrol rescan' after it is out and/or replaced with another drive. I wasn't paying attention to the early part of the thread, so I don't know if this is a procedural alternative. From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 8 08:49:10 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 90D491065673 for ; Wed, 8 Sep 2010 08:49:10 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 349D38FC14 for ; Wed, 8 Sep 2010 08:49:10 +0000 (UTC) Received: (qmail 26881 invoked by uid 0); 8 Sep 2010 08:27:32 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Sep 2010 08:27:32 -0000 Date: Wed, 8 Sep 2010 04:22:19 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.local To: freebsd-fs@freebsd.org, freebsd-scsi@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: 7.3 or 7-STABLE? 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, 08 Sep 2010 08:49:10 -0000 Hello, Quick question... I'm still having issues with an amd64 box and corruption on a largish (1.3T) filesystem. http://www.listware.net/201007/freebsd-fs/13111-72-ufs2-corruption.html - sorry for the crappy archive I've let the RAID controller run a few full verifies, and that comes back clean, the hardware is fine (pre-production it went through insanely long memtest runs, a week of build/installworld, etc.). Only after putting some real mail load on it did this start happening. For all I know, it could have been one bad panic that mangled things and fsck simply cannot fix it properly. That said, before even taking it down for a long rsync off to another host, newfs, then rsync back, I'd like to upgrade to 7.3 or 7-stable. The reason for choosing both -fs and -scsi is that I'd like some feedback from both groups on the two things I'm most suspicious of - UFS itself and the mfi driver. If neither has had any interesting changes in -stable, I'll go to 7.3 (at 7.2 now). If there are, then I might give -stable a shot... If the upgrade doesn't help, then I'll spend the time moving the data off, newfs'ing /spool and bringing the data back. If that doesn't work, then it's 8.1 (unless someone has a really compelling argument on making that step 1). If this were my box, I'd be putting more time into this, but the client is having numerous issues with cashflow, and I'm not looking to put out more hours than I may get paid for. Sad but true, and perhaps a lame excuse for sloppy administration... Thanks, Charles From owner-freebsd-scsi@FreeBSD.ORG Fri Sep 10 01:40: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 86F2B106566B for ; Fri, 10 Sep 2010 01:40:14 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id 539AF8FC14 for ; Fri, 10 Sep 2010 01:40:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 7F06B508BB for ; Fri, 10 Sep 2010 02:40:13 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOLVjT-7UMdM for ; Fri, 10 Sep 2010 02:40:12 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 18526508B4 for ; Fri, 10 Sep 2010 02:40:12 +0100 (BST) Message-ID: <4C898C7D.9090605@langille.org> Date: Thu, 09 Sep 2010 21:40:13 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org References: <4C78FF01.5020500@langille.org> <4C8424F3.2010501@langille.org> <4C8432EB.5080104@feral.com> <4C843885.3000208@langille.org> <4C844215.2080508@feral.com> In-Reply-To: <4C844215.2080508@feral.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: camcontrol rescan all - locks system 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, 10 Sep 2010 01:40:14 -0000 On 9/5/2010 9:21 PM, Matthew Jacob wrote: > On 9/5/2010 5:40 PM, Dan Langille wrote: >> On 9/5/2010 8:16 PM, Matthew Jacob wrote: >>> On 9/5/2010 4:17 PM, Dan Langille wrote: >>>> >>>> I tried this approach today. I did a 'camcontrol rescan 12' on one ssh >>>> session. In another, I saw this in /var/log/messages: \ >>> >>> This looks like an ahc issue, not a cam issue. >> >> I think you're saying the ahc is causing the issue. Perhaps I need to >> choose another SCSI card. >> > You might try it if it's an easy thing to do. That would generate a lot > of information. At present, I suspect the tape drive in the tape library is jammed, based on what I found on its console. I'll investigate that first, and then proceed. -- Dan Langille - http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Fri Sep 10 01:44:15 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 E468C1065670 for ; Fri, 10 Sep 2010 01:44:15 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id BBC298FC18 for ; Fri, 10 Sep 2010 01:44:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 4519D508BB for ; Fri, 10 Sep 2010 02:44:15 +0100 (BST) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2faMlo8Uk0C1 for ; Fri, 10 Sep 2010 02:44:14 +0100 (BST) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 7734F508B4 for ; Fri, 10 Sep 2010 02:44:14 +0100 (BST) Message-ID: <4C898D70.30701@langille.org> Date: Thu, 09 Sep 2010 21:44:16 -0400 From: Dan Langille Organization: The FreeBSD Diary User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Which SCSI card? 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, 10 Sep 2010 01:44:16 -0000 At present, this is the SCSI card I've been using with my old Digital tape library: ahc0: port 0x9800-0x98ff mem 0xfbaff000-0xfbafffff irq 21 at device 6.0 on pci1 Now, I seem to recall that the library is an LVD device (is that correct terminology?). The card seems to be acting up. What SCSI card would you recommend over that one? I'm on FreeBSD 8.1-stable. -- Dan Langille - http://langille.org/ From owner-freebsd-scsi@FreeBSD.ORG Fri Sep 10 08:41: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 5F92F1065670 for ; Fri, 10 Sep 2010 08:41:02 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id D81C38FC29 for ; Fri, 10 Sep 2010 08:41:01 +0000 (UTC) Received: (qmail invoked by alias); 10 Sep 2010 08:14:21 -0000 Received: from g227014207.adsl.alicedsl.de (EHLO mandree.no-ip.org) [92.227.14.207] by mail.gmx.net (mp044) with SMTP; 10 Sep 2010 10:14:21 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX19xb5E5IBhxP+CdoV1iURGP5CLK6m2rwH0r5BJM/x kdDQgZ3BUBcKF6 Received: from merlin.emma.line.org (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 6056194BD5 for ; Fri, 10 Sep 2010 10:14:20 +0200 (CEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-scsi@freebsd.org References: <4C898D70.30701@langille.org> Date: Fri, 10 Sep 2010 10:14:19 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Matthias Andree" Organization: Message-ID: In-Reply-To: <4C898D70.30701@langille.org> User-Agent: Opera Mail/10.61 (Linux) X-Y-GMX-Trusted: 0 Subject: Re: Which SCSI card? 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, 10 Sep 2010 08:41:02 -0000 Am 10.09.2010, 03:44 Uhr, schrieb Dan Langille: > At present, this is the SCSI card I've been using with my old Digital > tape library: > > ahc0: port 0x9800-0x98ff mem > 0xfbaff000-0xfbafffff irq 21 at device 6.0 on pci1 > > Now, I seem to recall that the library is an LVD device (is that correct > terminology?). Low Voltage Differential (as opposed to SE, single ended), yes, makes sense. > The card seems to be acting up. What SCSI card would you recommend over > that one? I'm on FreeBSD 8.1-stable. Haven't tried FreeBSD 8-STABLE there, but 7.1-RELEASE-p2 was fine with my Tekram DC-390U2W, using sym(4) driver - be sure to check which connectors you need though and if the PCI interface fits mechanically on your mainboard; the U2WE and U3* are 64/32-bit PCI. They will work in 32-bit slots unless capacitors or chips get in the way of the extra 64-bit contacts. With single-channel controllers without bridge chip, you can use at most two connectors at any one time, unless they have a SCSI bridge chip. With bridge or for dual-channel, it's more. For connector layout, see http://www.tekram.com.tw/ProductSpec.ASP?Product=DC-390U2_Series http://www.tekram.com.tw/ProductSpec.ASP?Product=DC-390U3D_U3W List of some Tekram controllers I know, those marked with asterisk (*) I've used with FreeBSD, those with a plus I've used with Linux - usually they also work with FreeBSD; those with ? I'm not sure about if I've used them. I bought a bunch of the DC390 series Tekrams cheap a couple of years ago because my Adaptec 2940AU and 2940UW Pro were also acting up... not sure if the Adaptecs suffer from capacitor wear or whatnot. Tekram model numbers with chips and partial feature: amd(4) driver, non-LVD: * DC390: AMD53C974 based SCSI 8 bit 10 MHz (10 MByte/s), amd(4) driver, last used with FreeBSD 4 DC390T: AMD53C974 based dual-channel version of DC390. Never seen or used one. sym(4) driver, non-LVD (DC310 has no BIOS): DC310: SYM53C810A (be sure to get an "A" version, the non-A is less efficient and uses ncr(4)) + DC310U: SYM53C860 based SCSI 8 bit 20 MHz without BIOS (20 MByte/s) * DC390U: SYM53C875 based SCSI 8 bit 20 MHz (20 MByte/s), used to cause driver issues with some wide devices on some OSes ? DC390F: SYM53C875 based SCSI 16bit 20 MHz (40 MByte/s) sym(4) LVD stuff: DC390U2B: SYM53C895 based SCSI 16 bit Ultra 2 (80 MByte/s) * DC390U2W: SYM53C895 + SYM53C141 bridge based SCSI 16 bit Ultra (80 MByte/s). DC390U2WE: SYM53C896. 64bit PCI. Seems to be dual-channel with 80 MByte/s per channel. DC390U3W: SYM53C1010, never used it, Ultra 160 SCSI, 64 bit PCI DC390U3D: dual-channel version of the U3W Possibly DawiControl 2980U2W might work and has hardware similar to one of the Tekram DC390U2* devices, but I'm not sure if sym(4) understands the BIOS/device settings. mpt(4) LVD stuff (Ultra 320) - I've never used those. DC390U4B: PCI-X 53C1020 based (mpt(4) driver), never used one DC390U4W: PCI-X 53C1030 based (mpt(4) driver), never used one Then there are DC315* and DC395* based host adaptors. They use a Tekram ASIC and trm(4) driver, I have zero clue if they work. HTH -- Matthias Andree From owner-freebsd-scsi@FreeBSD.ORG Fri Sep 10 15:28:15 2010 Return-Path: Delivered-To: scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BA3F1065673 for ; Fri, 10 Sep 2010 15:28:15 +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 3A3BA8FC08 for ; Fri, 10 Sep 2010 15:28:14 +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 o8AF4crW070097 for ; Fri, 10 Sep 2010 09:04:38 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id o8AF4caH070096 for scsi@freebsd.org; Fri, 10 Sep 2010 09:04:38 -0600 (MDT) (envelope-from ken) Date: Fri, 10 Sep 2010 09:04:38 -0600 From: "Kenneth D. Merry" To: scsi@freebsd.org Message-ID: <20100910150438.GA64519@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Cc: Subject: LSI 6Gb SAS driver committed 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, 10 Sep 2010 15:28:15 -0000 Hey folks, I have commited the mps driver (LSI Logic 6Gb SAS controller driver) to the FreeBSD perforce server (//depot/projects/mps/... and FreeBSD-current. The driver works with SAS and SATA drives, directly attached or attached through expanders. Basic error recovery works as well (i.e. timeouts and aborts). There are some known issues, including: - No support for integrated RAID (IR) arrays. - Devices tend to disappear and come back in one of my configurations. I also see some phantom devices, and events that don't make sense: mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 (da2:mps0:0:6:0): SCSI command timeout on device handle 0x0017 SMID 90 mps0: mpssas_abort_complete: abort request on handle 0x17 SMID 90 complete mps0: Unhandled event 0x0 (probe2:mps0:0:2:0): AutoSense failed mps0: Unhandled event 0x0 (da10:mps0:0:0:0): unsupportable block size 0 (da10:mps0:0:0:0): lost device (da10:mps0:0:0:0): removing device entry (da2:mps0:0:6:0): lost device (da2:mps0:0:6:0): removing device entry da2 at mps0 bus 0 scbus0 target 6 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 150.000MB/s transfers da2: Command Queueing enabled da2: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 - Sometimes you'll run into a device that fails part of the probe on boot, and you'll end up running into the run_interrupt_driven_config_hooks timeout. You see some aborts during probe, and then the 5 minute probe timeout kicks in and panics the kernel. For instance: (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 81 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 81 complete run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 214 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 214 complete run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 281 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 281 complete run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 348 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 348 complete run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 415 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 415 complete panic: run_interrupt_driven_config_hooks: waited too long cpuid = 0 KDB: enter: panic [ thread pid 0 tid 100000 ] Stopped at kdb_enter+0x3d: movq $0,0x4c70b0(%rip) db> - ioctl support isn't complete, and there is no userland utility. - There is no man page. The driver is in the tree at this point to allow people to test it out, report any problems, and hopefully contribute bug fixes. LSI has some developers working on this driver, and we hope to get them to put some of their work-in-progress in the FreeBSD Perforce repo. So, in view of that, if you make any changes to the driver, please make them in the FreeBSD Perforce repository first (in //depot/projects/mps/...) and then merge them into FreeBSD-current. Thanks to Scott Long for writing the driver, and to Yahoo and Spectra Logic for sponsoring the work. Ken -- Kenneth Merry ken@FreeBSD.ORG