From owner-freebsd-scsi  Sun Mar 19  6: 6:57 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3])
	by hub.freebsd.org (Postfix) with ESMTP id 6986037B5BC
	for <freebsd-scsi@freebsd.org>; Sun, 19 Mar 2000 06:06:54 -0800 (PST)
	(envelope-from daemon@bigeye.rhein-neckar.de)
Received: from bigeye.rhein-neckar.de (uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id PAA17862
	for freebsd-scsi@freebsd.org; Sun, 19 Mar 2000 15:06:52 +0100 (CET)
	(envelope-from daemon@bigeye.rhein-neckar.de)
Received: (from daemon@localhost)
	by bigeye.rhein-neckar.de (8.9.3/8.9.3) id NAA53350
	for freebsd-scsi@freebsd.org; Sun, 19 Mar 2000 13:56:26 +0100 (CET)
	(envelope-from daemon)
From: naddy@mips.rhein-neckar.de (Christian Weisgerber)
Subject: Re: controller
Date: 19 Mar 2000 13:56:26 +0100
Message-ID: <8b2ipq$1k2o$1@bigeye.rhein-neckar.de>
References: <Pine.BSF.4.21.0003182027550.32633-100000@picnic.mat.net>
To: freebsd-scsi@freebsd.org
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Chuck Robey <chuckr@picnic.mat.net> wrote:

> I've decided to get myself a couple of the new IBM 18G LVD scsi drives, to
> push away the storage demon (demon, NOT daemon!) a couple more
> years.  Seeing as I'm going LVD in a big way, I can't hold on to my
> current controller, an NCR875.  Anyone got an idea what's the best current
> mfr/model for a reasonably good LVD controller?

Any of the various manufacturers using NCR^WSym^WLSI chips.
Personally I'd pick up a Tekram 390U2W. Equivalent adapters are
available from at least Symbios Logic and Dawicontriol. Tekram also
has a dual channel adapter in the pipe, according to their CeBIT
display. Symbios already ships one.

Tekram mentions FreeBSD support on the box and they also offer
FreeBSD drivers, although you simply want to use the sym one for
their 390F and 390U2W adapters.

> I just want the model name, I'll worry about finding the deal myself
> (unless you have it right at hand).

I'd happily point you to a store, but I suspect we're on different
continents.

-- 
Christian "naddy" Weisgerber                  naddy@mips.rhein-neckar.de



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Mar 20  0:13:52 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1])
	by hub.freebsd.org (Postfix) with ESMTP id 45FB637B53C
	for <freebsd-scsi@FreeBSD.ORG>; Mon, 20 Mar 2000 00:13:44 -0800 (PST)
	(envelope-from ngr@symbionics.co.uk)
Received: from symnt3.Cadence.COM (symnt3.Cadence.COM [194.32.101.100])
	by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id AAA04622
	for <freebsd-scsi@FreeBSD.ORG>; Mon, 20 Mar 2000 00:13:42 -0800 (PST)
Received: by symnt3.cadence.com with Internet Mail Service (5.5.2650.21)
	id <G0RSYBZT>; Mon, 20 Mar 2000 08:13:14 -0000
Message-ID: <1E485299309FD211A2100090271E27A401AF067B@symnt3.cadence.com>
From: Nigel Roles <ngr@symbionics.co.uk>
To: freebsd-scsi@FreeBSD.ORG
Subject: RE: controller
Date: Mon, 20 Mar 2000 08:13:13 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Received: By mailgate.Cadence.COM as AAA04622 at Mon Mar 20 00:13:42 2000
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I would second that. The Tekram 390U2W has the auto-sensing terminator
switching
so you can mix LVDS and SE on the same bus without the whole lot reverting
to
SE. This can be useful for internal cabling. This is not the same as auto
termination (deciding whether to connect terminators at the host adaptor)
which
all cards do.

In dual channel, Symbios has the SYM22910 which has the awesome SYM53C896 on
it.
However, there is no 50 pin connector, and no auto LVDS/SE switching.

The Adaptec controller suggested (...160) is an Ultra/160M controller, also
described ramdomly as Ultra3 by box shifters. This does Ultra 2 wide, but
transfers data on both edges so achieving 160MBps burst.

There is no need to buy this unless you have Quantum 10K Atlas IV drives,
the
only ones to support it so far.

Symbios also sell a SYM22915 with their Ultra-160/M chip (53C1010) on board.

I'd be interested to know which dual channel controller Tekram are doing.

-----Original Message-----
From: naddy@mips.rhein-neckar.de [mailto:naddy@mips.rhein-neckar.de]
Sent: 19 March 2000 12:56
To: freebsd-scsi@FreeBSD.ORG
Subject: Re: controller


Chuck Robey <chuckr@picnic.mat.net> wrote:

> I've decided to get myself a couple of the new IBM 18G LVD scsi drives, to
> push away the storage demon (demon, NOT daemon!) a couple more
> years.  Seeing as I'm going LVD in a big way, I can't hold on to my
> current controller, an NCR875.  Anyone got an idea what's the best current
> mfr/model for a reasonably good LVD controller?

Any of the various manufacturers using NCR^WSym^WLSI chips.
Personally I'd pick up a Tekram 390U2W. Equivalent adapters are
available from at least Symbios Logic and Dawicontriol. Tekram also
has a dual channel adapter in the pipe, according to their CeBIT
display. Symbios already ships one.

Tekram mentions FreeBSD support on the box and they also offer
FreeBSD drivers, although you simply want to use the sym one for
their 390F and 390U2W adapters.

> I just want the model name, I'll worry about finding the deal myself
> (unless you have it right at hand).

I'd happily point you to a store, but I suspect we're on different
continents.

-- 
Christian "naddy" Weisgerber                  naddy@mips.rhein-neckar.de



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Mar 20  1:30:56 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5])
	by hub.freebsd.org (Postfix) with ESMTP
	id DA04E37B8F5; Mon, 20 Mar 2000 01:30:34 -0800 (PST)
	(envelope-from n_hibma@calcaphon.com)
Received: from henny.calcaphon.com (henny.calcaphon.com [10.0.0.36])
	by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id JAA58620;
	Mon, 20 Mar 2000 09:33:47 GMT
	(envelope-from n_hibma@calcaphon.com)
Date: Mon, 20 Mar 2000 09:28:25 +0000 (GMT)
From: Nick Hibma <n_hibma@calcaphon.com>
X-Sender: n_hibma@localhost
Reply-To: Nick Hibma <n_hibma@calcaphon.com>
To: Sean Kelly <smkelly@zombie.org>
Cc: FreeBSD SCSI Mailing List <scsi@FreeBSD.org>
Subject: Re: SCSI Emulation
In-Reply-To: <20000320004813.A41535@edgemaster.zombie.org>
Message-ID: <Pine.BSF.4.20.0003200908380.17504-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> I am currently working on a project which will require IDE CD-ROMs to be
> accessable as a SCSI device.  I know there is no support as of this time
> in FreeBSD, but was curious if anybody is working in this area.

Yes, I am. I've been doing a converter for SCSI to UFI in order to
support USB floppies. A next thing will be to support ATAPI devices
under CAM through USB (SuperDisk by Imation and other Shuttle E-USB
based products).

The reason why I am not using the code in dev/ata is that it is very
much ATA centric with no good distinction between the controller control
and the command protocol. It is IMHO easier to mangle SCSI into ATAPI
compliancy.

This question is however more appropriate for -scsi or -hackers
(CC:-ed, -questions BCC:-ed).

Nick
-- 
n_hibma@webweaving.org
n_hibma@freebsd.org                                          USB project
http://www.etla.net/~n_hibma/




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Mar 20  3:30:48 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3])
	by hub.freebsd.org (Postfix) with ESMTP id D1DFA37B6C3
	for <freebsd-scsi@freebsd.org>; Mon, 20 Mar 2000 03:30:39 -0800 (PST)
	(envelope-from daemon@bigeye.rhein-neckar.de)
Received: from bigeye.rhein-neckar.de (uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id MAA08688
	for freebsd-scsi@freebsd.org; Mon, 20 Mar 2000 12:30:35 +0100 (CET)
	(envelope-from daemon@bigeye.rhein-neckar.de)
Received: (from daemon@localhost)
	by bigeye.rhein-neckar.de (8.9.3/8.9.3) id MAA97225
	for freebsd-scsi@freebsd.org; Mon, 20 Mar 2000 12:27:40 +0100 (CET)
	(envelope-from daemon)
From: naddy@mips.rhein-neckar.de (Christian Weisgerber)
Subject: Re: controller
Date: 20 Mar 2000 12:27:40 +0100
Message-ID: <8b51vc$2utr$1@bigeye.rhein-neckar.de>
References: <1E485299309FD211A2100090271E27A401AF067B@symnt3.cadence.com>
To: freebsd-scsi@freebsd.org
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Nigel Roles <ngr@symbionics.co.uk> wrote:

> I'd be interested to know which dual channel controller Tekram are doing.

The three announced cards that I don't see advertised in the local
mail order stores yet:

Single channel:
  DC-390U3W  53C1010, int: 1x68 LVD, 1x68 UW, 1x50, ext: 1x68 HD

Dual channel:
  DC-390U2D  53C896,  int: 2x68 LVD/SE, 1x50, ext: 2xVHDCI
  DC-390U3D  53C1010, int: 2x68 LVD/SE, 1x50, ext: 2xVHDCI

The -U3x models obviously support "Ultra-3" 160MB/s transfers.
All cards ships with cables, LVD terminators, external 50-pin
adapter.

-- 
Christian "naddy" Weisgerber                  naddy@mips.rhein-neckar.de



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Mar 20  6:30:23 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from procsys.com (PPP-190-89.bng.vsnl.net.in [203.197.190.89])
	by hub.freebsd.org (Postfix) with SMTP id D860E37B8D1
	for <scsi@FreeBSD.ORG>; Mon, 20 Mar 2000 06:30:05 -0800 (PST)
	(envelope-from nanda@procsys.com)
Received: from procsys.com ([192.168.1.70]) by procsys.com with SMTP; Mon, 20 Mar 2000 20:02:27 +0800
Message-ID: <38D636F4.591FDA7@procsys.com>
Date: Mon, 20 Mar 2000 20:04:28 +0530
From: "Nandakumar.p.k" <nanda@procsys.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "scsi@FreeBSD.ORG" <scsi@FreeBSD.ORG>
Subject: Making a PCI HBA driver a loadable module
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Hi,

Can i a make a PCI HBA driver loadable in FreeBSD 3.4 ? If it is not
supported directly can i make the driver a loadable module and register
with the CAM XPT when the module gets control as part of loading ?

I want this feature desperately since during my initial testing, i will
waste a lot of time rebooting the machine.

Regards,
Nandan





To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Mar 20 15:40:19 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from front6.grolier.fr (front6.grolier.fr [194.158.96.56])
	by hub.freebsd.org (Postfix) with ESMTP id 0B8B037BA2D
	for <scsi@FreeBSD.org>; Mon, 20 Mar 2000 15:40:03 -0800 (PST)
	(envelope-from groudier@club-internet.fr)
Received: from ppp-169-192.villette.club-internet.fr (ppp-169-192.villette.club-internet.fr [195.36.169.192])
	by front6.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id AAA26064
	for <scsi@FreeBSD.org>; Tue, 21 Mar 2000 00:39:27 +0100 (MET)
Date: Tue, 21 Mar 2000 01:11:38 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
X-Sender: groudier@linux.local
To: scsi@FreeBSD.org
Subject: bus_dmamap_load() and boundaries
Message-ID: <Pine.LNX.4.10.10003210050130.284-100000@linux.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


Hello,

Due to errata, some SYMBIOS chip revisions require scatter entries not to
cross 16 MB boundaries. I can tell bus_dma_tag_create() about a
`boundary', but this parameter does not seem to apply to bus physical
scattered chunks returned by bus_dmamap_load(). This parameter seem to
only apply to memory allocated using bus_dmamem_alloc().

Is this the expected behaviour or am I missing something?

In my opinion, the `boundary' passed to bus_dma_tag_create() should apply
to scattered entries returned by bus_dmamap_load(), otherwise it does not
seem this useful to me.

G=E9rard.






To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Mar 21  8:43: 2 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from usgate01.e-mail.com (usgate01.e-mail.com [204.146.55.141])
	by hub.freebsd.org (Postfix) with ESMTP id 96D5337BA07
	for <freebsd-scsi@freebsd.org>; Tue, 21 Mar 2000 08:43:00 -0800 (PST)
	(envelope-from Adam_Woodbeck@keykertusa.com)
Received: Received: by usgate.e-mail.com with SMTP id QAA68290
 	        for <freebsd-scsi@freebsd.org>; Tue, 21 Mar 2000 16:38:58 GMT
Received: by SCH.ADVANTIS.COM (Soft-Switch LMS 3.2) with snapi via USCCRG01
          id 0039010010574537; Tue, 21 Mar 2000 11:38:58 -0500
From: "Adam Woodbeck (KEYKERTUSA)" <Adam_Woodbeck@keykertusa.com>
To: <freebsd-scsi@freebsd.org>
Subject: Help using an Adaptec 29160 SCSI adapter with FreeBSD
Message-ID: <0039010010574537000002L172*@MHS>
Date: Tue, 21 Mar 2000 11:38:58 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Please excuse my ignorance but I'm having a problem getting my Adaptec =
29160
U160 SCSI adapter working with FreeBSD 3.4.  Does FreeBSD 3.4 have supp=
ort for
this controller?

In my kernel I've compiled the following infomation in regards to the S=
CSI hard
drive and controller:

    controller      ahc0    # AHA2940 and onboard AIC7xxx devices
    controller      scbus0  # SCSI bus (required)
    device          da0 # Direct Access (disks)

I didn't see anything in LINT that pertained specifically to the Adapte=
c 29160
controller so I tried the closest thing I could find, the ahc0 controll=
er.  The
dmesg output does not mention a thing about the SCSI controller or the =
hard
drive.  The SCSI ID of the controller is 7 and the SCSI ID of the hard =
drive is
1.  I'm familiar with the way SCSI works but I'm not well versed.  The
controller and the hard drive are brand new, out of the box.  All I've =
done so
far is set the SCSI ID on the hard drive.  The hard drive reads not to =
terminate
it unless using 68 SE.  Thanks for the help.

Adam
=


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Mar 21  8:59:28 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from mba.dgsys.com (mba.dgsys.com [204.97.65.69])
	by hub.freebsd.org (Postfix) with ESMTP id 3BDD337BC0E
	for <scsi@freebsd.org>; Tue, 21 Mar 2000 08:59:16 -0800 (PST)
	(envelope-from jagnew@mba.dgsys.com)
Received: (from jagnew@localhost)
	by mba.dgsys.com (8.9.3/8.8.8) id MAA34866
	for scsi@freebsd.org; Tue, 21 Mar 2000 12:01:40 -0500 (EST)
	(envelope-from jagnew)
From: "H. Jared Agnew" <jagnew@mba.dgsys.com>
Message-Id: <200003211701.MAA34866@mba.dgsys.com>
Subject: External RAID
To: scsi@freebsd.org
Date: Tue, 21 Mar 2000 12:01:40 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


  I am currently in ownership of 5 IBM Ultra2 wide scsi drives.  I have
been given the task of implementing a raid configuration that will utilize 
these drives.  I have looked at the following companies, cmd, mylex, infotrend,
and chaparell.  I narrowed down the search to infotrend and chaparell because
they offer ultra2 wide to ultra2 wide, 80Mb/s transfer.  I contacted a reseller
of the chaparell line and he informed me that none of the external scsi to
scsi raid controlers that he had seen, offered the full through put, save the
chapparel model 5412.  I was wondering if anyone else had found this to be the
case.

  I like the infotrend sentinelRAID 1000 as it allows an upgrade path
for redundant controlers.  If anyone has a second would you respond with any
advise (or experiences) concerning a ultra2 wide to ultra2 wide external RAID
controler.  IE, what do you use, did you run in to a great many problems, do
you get the performance you thought you would?  Any help would be greatly
apreciated.

  Also if SCSI was the wrong list to mail to I am very sorry.

  H. J. Agnew
  hjagnew@mba-consulting.com



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Mar 21  9:32:27 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from gryzmak.lodz.pdi.net (gryzmak.lodz.pdi.net [195.116.162.1])
	by hub.freebsd.org (Postfix) with ESMTP id A351037BE97
	for <freebsd-scsi@freebsd.org>; Tue, 21 Mar 2000 09:32:11 -0800 (PST)
	(envelope-from MarekG@konsys.com.pl)
Received: from firmowy.konsys.com.pl (pppa96.lodz.tpnet.pl [194.204.167.96])
	by gryzmak.lodz.pdi.net (8.9.3/8.9.1/rchk1.20+bspm1.13+PDi2.5/W) with ESMTP id SAA10416
	for <freebsd-scsi@freebsd.org>; Tue, 21 Mar 2000 18:31:39 +0100
Received: by FIRMOWY with Internet Mail Service (5.5.2650.21)
	id <HL3161QX>; Tue, 21 Mar 2000 18:30:52 +0100
Message-ID: <D1AF7AFDD0D5D311BA99009027A6C172D43A@FIRMOWY>
From: =?iso-8859-2?Q?Marek_Gr=EAtkiewicz?= <MarekG@konsys.com.pl>
To: freebsd-scsi@freebsd.org
Subject: New Intel RAID U2-1
Date: Tue, 21 Mar 2000 18:30:51 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BF935B.3438C170"
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF935B.3438C170
Content-Type: text/plain;
	charset="iso-8859-2"

Is there someone who try to install new INTEL Server RAID Controller U2-1 (
SRCU21,Talo) ?

Marek Gretkiewicz

marekg@konsys.com.pl <mailto:marekg@konsys.com.pl> 


------_=_NextPart_001_01BF935B.3438C170
Content-Type: text/html;
	charset="iso-8859-2"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-2">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2>
<P>Is there someone who try to install new INTEL Server RAID Controller U2-1 ( 
SRCU21,Talo) ?</P>
<P>Marek Gretkiewicz</P>
<P><A 
href="mailto:marekg@konsys.com.pl">marekg@konsys.com.pl</A></P></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01BF935B.3438C170--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Mar 21 10:24:54 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id 95B7E37BD24
	for <freebsd-scsi@FreeBSD.ORG>; Tue, 21 Mar 2000 10:24:44 -0800 (PST)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id LAA40082;
	Tue, 21 Mar 2000 11:24:36 -0700 (MST)
	(envelope-from ken)
Date: Tue, 21 Mar 2000 11:24:35 -0700
From: "Kenneth D. Merry" <ken@kdm.org>
To: "Adam Woodbeck (KEYKERTUSA)" <Adam_Woodbeck@keykertusa.com>
Cc: freebsd-scsi@FreeBSD.ORG
Subject: Re: Help using an Adaptec 29160 SCSI adapter with FreeBSD
Message-ID: <20000321112435.A40066@panzer.kdm.org>
References: <0039010010574537000002L172*@MHS>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <0039010010574537000002L172*@MHS>; from Adam_Woodbeck@keykertusa.com on Tue, Mar 21, 2000 at 11:38:58AM -0500
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Tue, Mar 21, 2000 at 11:38:58 -0500, Adam Woodbeck (KEYKERTUSA) wrote:
> Please excuse my ignorance but I'm having a problem getting my Adaptec 29160
> U160 SCSI adapter working with FreeBSD 3.4.  Does FreeBSD 3.4 have support for
> this controller?

Nope.  You'll need to use 4.0, or a -current snapshot from after about
January 6th or 7th to get support for the card.

It'll only run at Ultra2 speeds right now, Justin is still working on
Ultra160 support.

Ken
-- 
Kenneth Merry
ken@kdm.org


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Mar 21 10:48:59 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from relay1.pair.com (relay1.pair.com [209.68.1.20])
	by hub.freebsd.org (Postfix) with SMTP id 9010437BC3D
	for <freebsd-scsi@FreeBSD.ORG>; Tue, 21 Mar 2000 10:48:42 -0800 (PST)
	(envelope-from boad@boaddrink.com)
Received: (qmail 18417 invoked from network); 21 Mar 2000 18:46:37 -0000
Received: from unknown (HELO nibbles) (63.72.154.131)
  by relay1.pair.com with SMTP; 21 Mar 2000 18:46:37 -0000
X-pair-Authenticated: 63.72.154.131
From: "Boad" <boad@boaddrink.com>
To: <freebsd-scsi@FreeBSD.ORG>
Cc: <ken@kdm.org>
Subject: RE: Help using an Adaptec 29160 SCSI adapter with FreeBSD
Date: Tue, 21 Mar 2000 13:37:13 -0500
Message-ID: <NDBBILJPCLIIJOBNCIADGEFLCCAA.boad@boaddrink.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20000321112435.A40066@panzer.kdm.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>Nope.  You'll need to use 4.0, or a -current snapshot from after about
>January 6th or 7th to get support for the card.

I've tried the drivers on 4.0 CURRENT and the drivers do recognize the card,
and mostly work, but I've received a whole bunch of errors from the
card/driver.

Basically, I had problems when it actually started writing the files to the
disk.  It fscks it all properly, but after a few writes of the files, I get
errors like:

  ahc0:A:0 no active SCB for reconnecting target = issuing BUS DEVICE RESET
SAVED_TCL == 0x0, ARG_1 == 0x26, SEQ_FLAGS == 0x40
  ahc0: Bus Device Reset on A:0. 59 SCBs aborted

  (da0):ahc0:0:0:0): SCB 0x26 - timed out while idle, SEQADDR == 0xb
  (da0:ahc0:0:0:0): Queing a BDR SCB
  ahc0: WARNING no command for scb 38 (cmdcmplt)


I'm guessing that it's a problem with the driver.  The hardware seems to
check out.  Here's my system specs (relevant only):

BIOS and System Info:
  Adaptec 29160 Bios v2.55.0
  SCSI card on IRQ 10
  VIDEO on IRQ 11


FreeBSD boot msg (parts deleted for space):
  -ahc0 irq 10 device 2 on pci3
  -uhc0 aic 7892 Wide Channel A, SCSI ID = 7, 16/255 SCBs
  -fxp0 on IRQ 11 pci 1
  -pci0 <unknown card> (vendor = 0x8086, dev = 0x2413) at 31.3 IRQ 9

  -da0 at ach0 bus 0 target 0 lun 0
  -da0: <IBM DMBS18M 0250>: Fixed Direct Access SCSI-3 device
  -da0: 80.000 MB/s transfers (40.000 Mhz, offset 31, 16bit), Tagged
Queueing Enabled
  -da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)



I would appreciate any help... I've already started swapping out my 29160
for a 2940, so it's not of dire importance, but it's always nice to know
=:^).  If anybody needs more info I'll be glad to supply it.  BTW, I'm sorry
if this is the wrong list to post to, but list/questions didn't have a clue.

Thanks,
Andrew Riley



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Mar 21 14:25:27 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from mass.cdrom.com (mg130-183.ricochet.net [204.179.130.183])
	by hub.freebsd.org (Postfix) with ESMTP id E06F437BBB3
	for <freebsd-scsi@freebsd.org>; Tue, 21 Mar 2000 14:25:17 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Received: from mass.cdrom.com (localhost [127.0.0.1])
	by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA01298;
	Tue, 21 Mar 2000 14:27:32 -0800 (PST)
	(envelope-from msmith@mass.cdrom.com)
Message-Id: <200003212227.OAA01298@mass.cdrom.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: =?iso-8859-2?Q?Marek_Gr=EAtkiewicz?= <MarekG@konsys.com.pl>
Cc: freebsd-scsi@freebsd.org
Subject: Re: New Intel RAID U2-1 
In-reply-to: Your message of "Tue, 21 Mar 2000 18:30:51 +0100."
             <D1AF7AFDD0D5D311BA99009027A6C172D43A@FIRMOWY> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 21 Mar 2000 14:27:31 -0800
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> Is there someone who try to install new INTEL Server RAID Controller U2-1 (
> SRCU21,Talo) ?

As far as I can tell, this is a new design (not a relabel of someone 
else's controller), and we don't support it.  If you want to send me a 
sample unit and documentation, I'll add it to the list. 8)

-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Mar 21 22:43:54 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140])
	by hub.freebsd.org (Postfix) with ESMTP id E8B5737C0B2
	for <scsi@freebsd.org>; Tue, 21 Mar 2000 22:43:42 -0800 (PST)
	(envelope-from chris@cheddar.netmonger.net)
Received: (from chris@localhost)
	by cheddar.netmonger.net (8.8.8/8.8.8) id BAA00171;
	Wed, 22 Mar 2000 01:43:36 -0500 (EST)
Message-ID: <20000322014336.A29353@netmonger.net>
Date: Wed, 22 Mar 2000 01:43:36 -0500
From: Christopher Masto <chris@netmonger.net>
To: n_hibma@calcaphon.com, usb-bsd@egroups.com, scsi@freebsd.org
Subject: More info on USB Zip problems
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91.1i
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I've reverted to source from 18-Mar-2000, just after the umass driver
went in, but before the vfs changes, and I no longer get a panic
on accessing my Zip drives.  It still doesn't work right, though:

chris@lion-around:~$ sudo camcontrol rescan 0
Re-scan of bus 0 was successful
chris@lion-around:~$ sudo camcontrol devlist -v
scbus0 on umass0 bus 0:
<IOMEGA ZIP 100 10.V>              at scbus0 target 0 lun 0 (da0,pass0)
<  >                               at scbus0 target 3 lun 0 ()
scbus-1 on xpt0 bus 0:
<  >                               at scbus-1 target -1 lun -1 (xpt0)
chris@lion-around:~$ cat < /dev/da0          
zsh: invalid argument: /dev/da0
chris@lion-around:~$ sudo camcontrol tur da0 -v
Unit is not ready
CAM status is 0x10

Exactly the same thing happens with the Zip 250.  Here's the usbdevs -v
output:

Controller /dev/usb0:
addr 1: self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 0x0100
 port 1 addr 2: self powered, config 1, USB Zip 100(0x0031), Iomega(0x059b), rev 0x0100
 port 2 addr 3: low speed, power 100 mA, config 1, Microsoft IntelliMouse. Explorer(0x001e), Microsoft(0x045e), rev 0x0103

I've turned up the debugging, but this being the first SCSI-like thing
I've traced, it's going to take a lot of reading before I understand
it.  Perhaps those with experience here will see what's amiss.  This
is from /var/run/dmesg.boot, with everything turned on and plugged in,
and a disk in before booting, usb and umass loaded as klds.

(noperiph:umass0:0:-1:-1): xpt_compile_path
(noperiph:umass0:0:-1:-1): xpt_setup_ccb
(noperiph:umass0:0:-1:-1): xpt_action
umass-:0:-1:-1:XPT_PATH_INQ:.
(noperiph:umass0:0:-1:-1): xpt_done
(noperiph:umass0:0:-1:-1): xpt_release_path
(xpt0:umass0:0:-1:-1): xpt_compile_path
(xpt0:umass0:0:-1:-1): xpt_setup_ccb
(xpt0:umass0:0:-1:-1): xpt_action
umass-:0:-1:-1:XPT_PATH_INQ:.
(xpt0:umass0:0:-1:-1): xpt_done
(xpt0:umass0:0:-1:-1): xpt_finishconfig
(xpt0:umass0:0:-1:-1): xpt_action
(xpt0:umass0:0:-1:-1): xpt_scan_bus
(xpt0:umass0:0:-1:-1): xpt_setup_ccb
(xpt0:umass0:0:-1:-1): xpt_action
umass-:0:-1:-1:XPT_PATH_INQ:.
(xpt0:umass0:0:-1:-1): xpt_done
(xpt0:umass0:0:0:0): xpt_compile_path
(xpt0:umass0:0:0:0): xpt_setup_ccb
(xpt0:umass0:0:0:0): xpt_action
(xpt0:umass0:0:0:0): xpt_scan_lun
(xpt0:umass0:0:0:0): xpt_setup_ccb
(xpt0:umass0:0:0:0): xpt_action
umass0:0:0:0:XPT_PATH_INQ:.
(xpt0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): xpt_compile_path
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): xpt_action
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): xpt_action
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): xpt_action
umass0:0:0:0:XPT_PATH_INQ:.
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): xpt_schedule
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): probestart
(probe0:umass0:0:0:0): xpt_action
(probe0:umass0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 
(xpt0:umass0:0:1:0): xpt_compile_path
(xpt0:umass0:0:1:0): xpt_setup_ccb
(xpt0:umass0:0:1:0): xpt_action
(xpt0:umass0:0:1:0): xpt_scan_lun
(xpt0:umass0:0:1:0): xpt_setup_ccb
(xpt0:umass0:0:1:0): xpt_action
umass-:0:1:0:func_code 0x0004: Invalid target
(xpt0:umass0:0:1:0): xpt_done
(xpt0:umass0:0:1:0): xpt_done
(xpt0:umass0:0:2:0): xpt_compile_path
(xpt0:umass0:0:2:0): xpt_setup_ccb
(xpt0:umass0:0:2:0): xpt_action
(xpt0:umass0:0:2:0): xpt_scan_lun
(xpt0:umass0:0:2:0): xpt_setup_ccb
(xpt0:umass0:0:2:0): xpt_action
umass-:0:2:0:func_code 0x0004: Invalid target
(xpt0:umass0:0:2:0): xpt_done
(xpt0:umass0:0:2:0): xpt_done
(xpt0:umass0:0:1:0): camisr(xpt0:umass0:0:1:0): xpt_scan_bus
(xpt0:umass0:0:1:0): xpt_setup_ccb
(xpt0:umass0:0:1:0): xpt_action
(xpt0:umass0:0:1:0): xpt_free_path
(xpt0:umass0:0:1:0): xpt_release_path
(xpt0:umass0:0:2:0): camisr(xpt0:umass0:0:2:0): xpt_scan_bus
(xpt0:umass0:0:2:0): xpt_setup_ccb
(xpt0:umass0:0:2:0): xpt_action
(xpt0:umass0:0:2:0): xpt_free_path
(xpt0:umass0:0:2:0): xpt_release_path
umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense
umass0: CBW 42: cmd = 6b (0x120000002400), data = 36 bytes, dir = in
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, NORMAL_COMPLETION
umass0: 0x 0080000175000000494f4d4547412020 buffer=0xc0b1c284, buflen=36
umass0: 0x 5a495020313030202020202020202020
umass0: 0x 31302e56
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, NORMAL_COMPLETION
umass0: CSW 42: sig = 0x53425355 (valid), tag = 42, res = 0, status = 0x00 (good)
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): camisr(probe0:umass0:0:0:0): probedone
(probe0:umass0:0:0:0): xpt_schedule
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): probestart
(probe0:umass0:0:0:0): xpt_action
(probe0:umass0:0:0:0): INQUIRY. CDB: 12 0 0 0 79 0 
umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/121b data/18b sense
umass0: CBW 43: cmd = 6b (0x120000007900), data = 121 bytes, dir = in
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, NORMAL_COMPLETION
umass0: 0x 0080000175000000494f4d4547412020 buffer=0xc0b1c284, buflen=121
umass0: 0x 5a495020313030202020202020202020
umass0: 0x 31302e5630362f32322f393900000000 ...
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, NORMAL_COMPLETION
umass0: CSW 43: sig = 0x53425355 (valid), tag = 43, res = 0, status = 0x00 (good)
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): camisr(probe0:umass0:0:0:0): probedone
(probe0:umass0:0:0:0): xpt_schedule
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): probestart
(probe0:umass0:0:0:0): xpt_action
(probe0:umass0:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 
umass0:0:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense
umass0: CBW 44: cmd = 6b (0x12018000ff00), data = 255 bytes, dir = in
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, NORMAL_COMPLETION
umass0: 0x 00000000000000000000000000000000 buffer=0xc0b4c000, buflen=255
umass0: 0x 00000000000000000000000000000000
umass0: 0x 00000000000000000000000000000000 ...
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, STALLED
umass0: Failed to read CSW, STALLED, retrying
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 5 (BBB CSW bulk-in clear stall), xfer=0xc0b11280, NORMAL_COMPLETION
umass0: Handling BBB state 6 (BBB CSW, 2nd attempt), xfer=0xc0b11300, NORMAL_COMPLETION
umass0: CSW 44: sig = 0x53425355 (valid), tag = 44, res = 255, status = 0x01 (failed)
umass0: Command Failed, res = 255
umass0: Fetching 18/32b sense data
umass0: CBW 45: cmd = 16b (0x030000001200...), data = 18 bytes, dir = in
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, STALLED
umass0: Data-in 18b failed, STALLED
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 3 (BBB Data bulk-in/-out clear stall), xfer=0xc0b11400, NORMAL_COMPLETION
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, STALLED
umass0: Failed to read CSW, STALLED, retrying
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 5 (BBB CSW bulk-in clear stall), xfer=0xc0b11280, NORMAL_COMPLETION
umass0: Handling BBB state 6 (BBB CSW, 2nd attempt), xfer=0xc0b11300, STALLED
umass0: Failed to read CSW, STALLED
umass0: Bulk Reset
umass0: Handling BBB state 7 (BBB Reset), xfer=0xc0b11200, NORMAL_COMPLETION
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 8 (BBB bulk-in clear stall), xfer=0xc0b11180, NORMAL_COMPLETION
umass0: Clear endpoint 0x01 stall
umass0: Handling BBB state 9 (BBB bulk-out clear stall), xfer=0xc0b11100, NORMAL_COMPLETION
umass0: Autosense failed, status 3
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): camisr(probe0:umass0:0:0:0): probedone
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): xpt_action
umass0:0:0:0:XPT_GET_TRAN_SETTINGS:.
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): xpt_action
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): xpt_action
umass0:0:0:0:XPT_PATH_INQ:.
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): xpt_action
umass0:0:0:0:XPT_GET_TRAN_SETTINGS:.
(probe0:umass0:0:0:0): xpt_done
umass0:0:0:0:XPT_SET_TRAN_SETTINGS:.
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): xpt_schedule
(probe0:umass0:0:0:0): xpt_setup_ccb
(probe0:umass0:0:0:0): probestart
(probe0:umass0:0:0:0): xpt_action
(probe0:umass0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
umass0:0:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense
umass0: CBW 46: cmd = 6b (0x000000000000), data = 0 bytes, dir = out
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
umass0: no data phase
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, NORMAL_COMPLETION
umass0: CSW 46: sig = 0x53425355 (valid), tag = 46, res = 0, status = 0x01 (failed)
umass0: Command Failed, res = 0
umass0: Fetching 32/32b sense data
umass0: CBW 47: cmd = 16b (0x030000002000...), data = 32 bytes, dir = in
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, STALLED
umass0: Data-in 32b failed, STALLED
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 3 (BBB Data bulk-in/-out clear stall), xfer=0xc0b11400, NORMAL_COMPLETION
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, STALLED
umass0: Failed to read CSW, STALLED, retrying
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 5 (BBB CSW bulk-in clear stall), xfer=0xc0b11280, NORMAL_COMPLETION
umass0: Handling BBB state 6 (BBB CSW, 2nd attempt), xfer=0xc0b11300, STALLED
umass0: Failed to read CSW, STALLED
umass0: Bulk Reset
umass0: Handling BBB state 7 (BBB Reset), xfer=0xc0b11200, NORMAL_COMPLETION
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 8 (BBB bulk-in clear stall), xfer=0xc0b11180, NORMAL_COMPLETION
umass0: Clear endpoint 0x01 stall
umass0: Handling BBB state 9 (BBB bulk-out clear stall), xfer=0xc0b11100, NORMAL_COMPLETION
umass0: Autosense failed, status 3
(probe0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): camisr(probe0:umass0:0:0:0): probedone
(xpt0:umass0:0:0:0): xpt_done
(probe0:umass0:0:0:0): xpt_free_path
(probe0:umass0:0:0:0): xpt_release_path
(xpt0:umass0:0:0:0): camisr(xpt0:umass0:0:0:0): xpt_scan_bus
(xpt0:umass0:0:0:0): xpt_setup_ccb
(xpt0:umass0:0:0:0): xpt_action
(xpt0:umass0:0:0:0): xpt_free_path
(xpt0:umass0:0:0:0): xpt_release_path
(xpt0:umass0:0:-1:-1): xpt_done
(xpt0:umass0:0:-1:-1): camisr(xpt0:umass0:0:-1:-1): xpt_finishconfig
(xpt0:umass0:0:-1:-1): xpt_free_path
(xpt0:umass0:0:-1:-1): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_compile_path
(noperiph:xpt0:0:-1:-1): xpt_setup_ccb
(noperiph:xpt0:0:-1:-1): xpt_action
(noperiph:umass0:0:0:0): xpt_compile_path
(noperiph:umass0:0:0:0): xpt_setup_ccb
(noperiph:umass0:0:0:0): xpt_action
(da0:umass0:0:0:0): xpt_compile_path
Creating DISK da0
(da0:umass0:0:0:0): xpt_setup_ccb
(da0:umass0:0:0:0): xpt_action
(da0:umass0:0:0:0): xpt_schedule
(da0:umass0:0:0:0): xpt_setup_ccb
(da0:umass0:0:0:0): xpt_action
(da0:umass0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 
umass0:0:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense
umass0: CBW 48: cmd = 10b (0x250000000000...), data = 8 bytes, dir = in
(noperiph:umass0:0:0:0): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_free_path
(noperiph:xpt0:0:-1:-1): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_compile_path
(noperiph:xpt0:0:-1:-1): xpt_setup_ccb
(noperiph:xpt0:0:-1:-1): xpt_action
(noperiph:umass0:0:0:0): xpt_compile_path
(noperiph:umass0:0:0:0): xpt_setup_ccb
(noperiph:umass0:0:0:0): xpt_action
(noperiph:umass0:0:0:0): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_free_path
(noperiph:xpt0:0:-1:-1): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_compile_path
(noperiph:xpt0:0:-1:-1): xpt_setup_ccb
(noperiph:xpt0:0:-1:-1): xpt_action
(noperiph:umass0:0:0:0): xpt_compile_path
(noperiph:umass0:0:0:0): xpt_setup_ccb
(noperiph:umass0:0:0:0): xpt_action
(noperiph:umass0:0:0:0): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_free_path
(noperiph:xpt0:0:-1:-1): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_compile_path
(noperiph:xpt0:0:-1:-1): xpt_setup_ccb
(noperiph:xpt0:0:-1:-1): xpt_action
(noperiph:umass0:0:0:0): xpt_compile_path
(noperiph:umass0:0:0:0): xpt_setup_ccb
(noperiph:umass0:0:0:0): xpt_action
(noperiph:umass0:0:0:0): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_free_path
(noperiph:xpt0:0:-1:-1): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_compile_path
(noperiph:xpt0:0:-1:-1): xpt_setup_ccb
(noperiph:xpt0:0:-1:-1): xpt_action
(noperiph:umass0:0:0:0): xpt_compile_path
(noperiph:umass0:0:0:0): xpt_setup_ccb
(noperiph:umass0:0:0:0): xpt_action
(noperiph:umass0:0:0:0): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_free_path
(noperiph:xpt0:0:-1:-1): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_compile_path
(noperiph:xpt0:0:-1:-1): xpt_setup_ccb
(noperiph:xpt0:0:-1:-1): xpt_action
(noperiph:umass0:0:0:0): xpt_compile_path
(noperiph:umass0:0:0:0): xpt_setup_ccb
(noperiph:umass0:0:0:0): xpt_action
(pass0:umass0:0:0:0): xpt_compile_path
(pass0:umass0:0:0:0): xpt_setup_ccb
(pass0:umass0:0:0:0): xpt_action
pass0 at umass0 bus 0 target 0 lun 0
pass0: <IOMEGA ZIP 100 10.V> Removable Direct Access SCSI-0 device 
(pass0:umass0:0:0:0): xpt_setup_ccb
(pass0:umass0:0:0:0): xpt_action
umass0:0:0:0:XPT_GET_TRAN_SETTINGS:.
(pass0:umass0:0:0:0): xpt_done
(pass0:umass0:0:0:0): xpt_setup_ccb
(pass0:umass0:0:0:0): xpt_action
umass0:0:0:0:XPT_PATH_INQ:.
(pass0:umass0:0:0:0): xpt_done
pass0: 650KB/s transfers
(noperiph:umass0:0:0:0): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_free_path
(noperiph:xpt0:0:-1:-1): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_compile_path
(noperiph:xpt0:0:-1:-1): xpt_setup_ccb
(noperiph:xpt0:0:-1:-1): xpt_action
(noperiph:umass0:0:0:0): xpt_compile_path
(noperiph:umass0:0:0:0): xpt_setup_ccb
(noperiph:umass0:0:0:0): xpt_action
(noperiph:umass0:0:0:0): xpt_release_path
(noperiph:xpt0:0:-1:-1): xpt_free_path
(noperiph:xpt0:0:-1:-1): xpt_release_path
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
Mounting root from ufs:/dev/wd0s1a
wd0s1: type 0xa5, start 0, end = 40026671, size 40026672 : OK
start_init: trying /sbin/init
umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, NORMAL_COMPLETION
umass0: 0x 00000000dec0adde buffer=0xc0b18810, buflen=8
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, STALLED
umass0: Failed to read CSW, STALLED, retrying
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 5 (BBB CSW bulk-in clear stall), xfer=0xc0b11280, NORMAL_COMPLETION
umass0: Handling BBB state 6 (BBB CSW, 2nd attempt), xfer=0xc0b11300, NORMAL_COMPLETION
umass0: CSW 48: sig = 0x53425355 (valid), tag = 48, res = 8, status = 0x01 (failed)
umass0: Command Failed, res = 8
umass0: Fetching 32/32b sense data
umass0: CBW 49: cmd = 16b (0x030000002000...), data = 32 bytes, dir = in
umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, STALLED
umass0: Data-in 32b failed, STALLED
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 3 (BBB Data bulk-in/-out clear stall), xfer=0xc0b11400, NORMAL_COMPLETION
umass0: Handling BBB state 4 (BBB CSW, 1st attempt), xfer=0xc0b11380, STALLED
umass0: Failed to read CSW, STALLED, retrying
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 5 (BBB CSW bulk-in clear stall), xfer=0xc0b11280, NORMAL_COMPLETION
umass0: Handling BBB state 6 (BBB CSW, 2nd attempt), xfer=0xc0b11300, STALLED
umass0: Failed to read CSW, STALLED
umass0: Bulk Reset
umass0: Handling BBB state 7 (BBB Reset), xfer=0xc0b11200, NORMAL_COMPLETION
umass0: Clear endpoint 0x82 stall
umass0: Handling BBB state 8 (BBB bulk-in clear stall), xfer=0xc0b11180, NORMAL_COMPLETION
umass0: Clear endpoint 0x01 stall
umass0: Handling BBB state 9 (BBB bulk-out clear stall), xfer=0xc0b11100, NORMAL_COMPLETION
umass0: Autosense failed, status 3
(da0:umass0:0:0:0): xpt_done
(da0:umass0:0:0:0): camisr

I just got these today, so I can't say whether they worked with the
previous umass driver.

I'm keeping the 250 at least, and someone may be purchasing the 100 to
keep it available for debugging.  Whatever I can do to help, I will do.
-- 
Christopher Masto         Senior Network Monkey      NetMonger Communications
chris@netmonger.net        info@netmonger.net        http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Mar 22  1:43:17 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from bluebottle.calcaphon.com (calcaphon.demon.co.uk [193.237.19.5])
	by hub.freebsd.org (Postfix) with ESMTP id F339837BA53
	for <scsi@freebsd.org>; Wed, 22 Mar 2000 01:42:49 -0800 (PST)
	(envelope-from n_hibma@calcaphon.com)
Received: from henny.calcaphon.com (henny.calcaphon.com [10.0.0.36])
	by bluebottle.calcaphon.com (8.9.3/8.9.1) with ESMTP id JAA42532;
	Wed, 22 Mar 2000 09:43:52 GMT
	(envelope-from n_hibma@calcaphon.com)
Date: Wed, 22 Mar 2000 09:38:00 +0000 (GMT)
From: Nick Hibma <n_hibma@calcaphon.com>
X-Sender: n_hibma@localhost
Reply-To: Nick Hibma <n_hibma@calcaphon.com>
To: Christopher Masto <chris@netmonger.net>
Cc: usb-bsd@egroups.com, scsi@freebsd.org
Subject: Re: More info on USB Zip problems
In-Reply-To: <20000322014336.A29353@netmonger.net>
Message-ID: <Pine.BSF.4.20.0003220931190.2871-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> <IOMEGA ZIP 100 10.V>              at scbus0 target 0 lun 0 (da0,pass0)
                  ^^^^

You have the new bridge. Blast. I should get one of those then.

> umass-:0:1:0:func_code 0x0004: Invalid target

These are harmless.

> umass0: Fetching 18/32b sense data
> umass0: CBW 45: cmd = 16b (0x030000001200...), data = 18 bytes, dir = in
> umass0: Handling BBB state 1 (BBB CBW), xfer=0xc0b11780, NORMAL_COMPLETION
> umass0: Handling BBB state 2 (BBB Data), xfer=0xc0b11480, STALLED
> umass0: Data-in 18b failed, STALLED

Not good. It fails to return sense data.

> umass0: Bulk Reset

Oh oh...

> umass0: Autosense failed, status 3

Bad drive, BAD drive...[slap]

> pass0: <IOMEGA ZIP 100 10.V> Removable Direct Access SCSI-0 device 

Inquiry seems to have gotten there.


Weird. I'll have a look at it this evening.

Thanks for the verbose output!

Nick

--
n_hibma@webweaving.org
n_hibma@freebsd.org                                          USB project
http://www.etla.net/~n_hibma/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Mar 22 10:28:18 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130])
	by hub.freebsd.org (Postfix) with ESMTP id 0217337C390
	for <scsi@FreeBSD.org>; Wed, 22 Mar 2000 10:28:15 -0800 (PST)
	(envelope-from gibbs@narnia.plutotech.com)
Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.3/8.7.3) id LAA09815; Wed, 22 Mar 2000 11:14:47 -0700 (MST)
Date: Wed, 22 Mar 2000 11:14:47 -0700 (MST)
From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
Message-Id: <200003221814.LAA09815@narnia.plutotech.com>
To: G?rard Roudier <groudier@club-internet.fr>
Cc: scsi@FreeBSD.org
Subject: Re: bus_dmamap_load() and boundaries
X-Newsgroups: pluto.freebsd.scsi
In-Reply-To: <Pine.LNX.4.10.10003210050130.284-100000@linux.local>
User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386))
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

In article <Pine.LNX.4.10.10003210050130.284-100000@linux.local> you wrote:
> 
> Hello,
> 
> Due to errata, some SYMBIOS chip revisions require scatter entries not to
> cross 16 MB boundaries. I can tell bus_dma_tag_create() about a
> `boundary', but this parameter does not seem to apply to bus physical
> scattered chunks returned by bus_dmamap_load(). This parameter seem to
> only apply to memory allocated using bus_dmamem_alloc().
> 
> Is this the expected behaviour or am I missing something?

Boundary support in bus_dmamap_load() just hasn't been implemented yet.
It shouldn't be too hard to add.

--
Justin


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Mar 22 14: 8:15 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from front1.grolier.fr (front1.grolier.fr [194.158.96.51])
	by hub.freebsd.org (Postfix) with ESMTP id 9224F37C272
	for <scsi@FreeBSD.org>; Wed, 22 Mar 2000 14:07:32 -0800 (PST)
	(envelope-from groudier@club-internet.fr)
Received: from ppp-223-139.villette.club-internet.fr (ppp-223-139.villette.club-internet.fr [195.36.223.139])
	by front1.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA01528
	for <scsi@FreeBSD.org>; Wed, 22 Mar 2000 23:07:29 +0100 (MET)
Date: Wed, 22 Mar 2000 23:39:46 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
X-Sender: groudier@linux.local
To: scsi@FreeBSD.org
Subject: New `sym' driver experimental version
Message-ID: <Pine.LNX.4.10.10003222333040.347-100000@linux.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


This new driver version (sym-1.4.0-20000322) uses the DMA=20
mapping interface introduced in FreeBSD-4.0. The driver is=20
now full up-to-date for FreeBSD-5.0.

ftp://ftp.tux.org/pub/roudier/drivers/freebsd/experimental/sym-1.4.0-200003=
22.tar.gz
(Modulo mistakes in the URL:))

Another significant change in this driver version applies=20
to the checking of the data direction. The driver is now=20
able to check against the expected data direction in any=20
circumstances (even from SCRIPTS) and will not hang either
if direction is wrong at the start of the IO, or if for=20
some weird reason, the direction changes during the IO.

Even if the code looks just perfect to me :), some additionnal=20
testings are needed prior to committing this new driver=20
version to the kernel repository.

sym-1.4.0-20000322 is still an experimental driver version.
I have tried it under 4.0, but the driver should also be ok=20
for -current (5.0 development).

Thanks, in advance, for trying this new driver version and=20
reporting me problems, if any.

G=E9rard.=20



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Mar 22 14:35:12 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252])
	by hub.freebsd.org (Postfix) with ESMTP id 4252237C597
	for <scsi@freebsd.org>; Wed, 22 Mar 2000 14:35:03 -0800 (PST)
	(envelope-from roberto@keltia.freenix.fr)
Received: (from uucp@localhost)
	by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id XAA27278
	for scsi@freebsd.org; Wed, 22 Mar 2000 23:34:16 +0100 (CET)
	(envelope-from roberto@keltia.freenix.fr)
Received: by keltia.freenix.fr (Postfix, from userid 101)
	id B767A8869; Wed, 22 Mar 2000 22:04:14 +0100 (CET)
Date: Wed, 22 Mar 2000 22:04:10 +0100
From: Ollivier Robert <roberto@keltia.freenix.fr>
To: scsi@freebsd.org
Subject: Re: More info on USB Zip problems
Message-ID: <20000322220410.A12608@keltia.freenix.fr>
Mail-Followup-To: scsi@freebsd.org
References: <20000322014336.A29353@netmonger.net> <Pine.BSF.4.20.0003220931190.2871-100000@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.BSF.4.20.0003220931190.2871-100000@localhost>; from n_hibma@calcaphon.com on Wed, Mar 22, 2000 at 09:38:00AM +0000
X-Operating-System: FreeBSD 4.0-CURRENT/ELF AMD-K6/200 & 2x PPro/200 SMP
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

According to Nick Hibma:
> Thanks for the verbose output!

I can now report a success with the USB floppy on my VAIO. Thanks a lot Nick!

uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xfca0-0xfcbf irq 9 at device 7.2 on pci0
usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
[... plug the floppy in the USB port ...]
umass0: Y-E DATA FlashBuster-U, rev 1.00/1.14, addr 2
da0 at umass0 bus 0 target 0 lun 0
da0: <Y-E DATA USB-FDU 1.14> Removable Direct Access SCSI-0 device 
da0: 20KB/s transfers
da0: 1MB (2880 512 byte sectors: 2H 18S/T 80C)
[... mount as MS-DOS disk ...]
da0s1: slice starts beyond end of the disk: rejecting it
da0s2: slice starts beyond end of the disk: rejecting it
da0s3: slice starts beyond end of the disk: rejecting it
da0s4: slice starts beyond end of the disk: rejecting it
[... disconnection ...]
uhub0: port error, restarting port 1
umass0: at uhub0 port 1 (addr 2) disconnected
(da0:umass0:0:0:0): lost device
(da0:umass0:0:0:0): removing device entry

I was able to mount the disk, see its content and all that.
-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #78: Sun Feb 27 15:32:39 CET 2000



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Mar 23 14:47:23 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54])
	by hub.freebsd.org (Postfix) with ESMTP id 80DC137C67B
	for <scsi@FreeBSD.ORG>; Thu, 23 Mar 2000 14:46:45 -0800 (PST)
	(envelope-from groudier@club-internet.fr)
Received: from ppp-162-250.villette.club-internet.fr (ppp-162-250.villette.club-internet.fr [195.36.162.250])
	by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id XAA12357;
	Thu, 23 Mar 2000 23:46:22 +0100 (MET)
Date: Fri, 24 Mar 2000 00:18:43 +0100 (CET)
From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
X-Sender: groudier@linux.local
To: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
Cc: scsi@FreeBSD.ORG
Subject: Re: bus_dmamap_load() and boundaries
In-Reply-To: <200003221814.LAA09815@narnia.plutotech.com>
Message-ID: <Pine.LNX.4.10.10003232337220.2139-100000@linux.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org



On Wed, 22 Mar 2000, Justin T. Gibbs wrote:

> In article <Pine.LNX.4.10.10003210050130.284-100000@linux.local> you wrot=
e:
> >=20
> > Hello,
> >=20
> > Due to errata, some SYMBIOS chip revisions require scatter entries not =
to
> > cross 16 MB boundaries. I can tell bus_dma_tag_create() about a
> > `boundary', but this parameter does not seem to apply to bus physical
> > scattered chunks returned by bus_dmamap_load(). This parameter seem to
> > only apply to memory allocated using bus_dmamem_alloc().
> >=20
> > Is this the expected behaviour or am I missing something?
>=20
> Boundary support in bus_dmamap_load() just hasn't been implemented yet.

Ok. Thanks for the reply.

> It shouldn't be too hard to add.

Indeed. But, for now, latest `sym' handles this situation by itself. Btw,
on i386 the additon of boundary checking inside the scattering loop
increases register pressure and resulted machine code is pathetic. I would
also suggest to add the option of not actually trying coalescing physical
adjacent pages if boundary is just page aligned, and implement 3 different
loops:

1) Scatter with page boundary
2) Scatter with coalescing but no boundary checking (current)
3) Scatter with coalescing and  boundary checking.

(1) is about 10 instructions per loop on i386
(2) should still be reasonnable
(3) should take more than 30 instructions per loop with great register=20
    pressure on i386.

(May-be I am just nitpicking there :) )

I have another suggestion. BSD systems provide a single virtual buffer to
SIMs. In result, actual IOs are smaller that they could be if providing
a list of virtual buffer was possible, since IO coalescing would be a lot
simpler to implement from upper layers.
My suggestion is to support some new extended bus_dmamap_load service that
accept a scattered list of virtual buffers as input, as CAM specification
seem to allow. Enhancement of upper layers could come later. (By the way,
as you know, for example, Linux SCSI drivers are provided by such
scatterlists of virtual buffers).

With modern hard disks that are very fast, providing too small IOs in
average could get very sub-optimal. My opinion is that coalescing IOs when
possible is much more important for performances than sorting them with
Ultra-160 (and why with not future Ultra 320) hard disks. Note that
maintaining lists of sorted IOs helps for IO coalescing.

G=E9rard.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Mar 23 16:26:26 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from naiad.eclipse.net.uk (naiad.eclipse.net.uk [195.188.32.29])
	by hub.freebsd.org (Postfix) with ESMTP
	id 99ACB37B5BE; Thu, 23 Mar 2000 16:26:20 -0800 (PST)
	(envelope-from sthen@naiad.eclipse.net.uk)
Received: by naiad.eclipse.net.uk (Postfix, from userid 475)
	id E3C7013533; Fri, 24 Mar 2000 00:26:30 +0000 (GMT)
Date: Fri, 24 Mar 2000 00:26:30 +0000
From: Stuart Henderson <sthen@naiad.eclipse.net.uk>
To: "Jason J. Horton" <jason@intercom.com>
Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Subject: Re: Hardware Raid controllers
Message-ID: <20000324002630.A46923@naiad.eclipse.net.uk>
References: <38DA319C.4AC963CC@stripe.dk> <20000323093640.E9661@simkin.com> <20000323135208.K95709@PacHell.TelcoSucks.org> <38DA9CFB.D3C526C2@intercom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.1.2i
In-Reply-To: <38DA9CFB.D3C526C2@intercom.com>; from jason@intercom.com on Thu, Mar 23, 2000 at 05:38:51PM -0500
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

On Thu, Mar 23, 2000 at 05:38:51PM -0500, Jason J. Horton wrote:
> Does anyone know if the HP NetRAID series of cards is supported?
> I am having a hard time finding any information about these cards
> on the HP site, let alone tech info like chipset.

They're badged megaraid cards, here is one onboard
a LH4r,

sym0: <895> port 0xa000-0xa0ff mem 0xe8100000-0xe8100fff,0xe8101000-0xe81010ff irq 11 at device 7.0 on pci1
sym0: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking
sym0: open drain IRQ line driver, using on-chip SRAM
amr0: <AMI MegaRAID> mem 0xf0000000-0xf7ffffff irq 10 at device 2.1 on pci0
amr0: firmware \^E\^BD  bios \^D\^AB   16MB memory

^^^ note junk chars in identification strings, HP have a
habit of changing identifying markings wherever they can -
they even do this to their hard drives. (I've had mostly
IBM drives from UK distributors recently, in case anyone
cares, they're *much* better than the seagates which they
were supplying a couple of months ago).

amrd0: <MegaRAID logical drive> on amr0
amrd0: 8677MB (17770496 sectors) RAID 0 (optimal)

Passthrough doesn't function with this device on
4.0-current-20000214 so I can't give any camcontrol inq
infos.  *I have not tried this card on a RAID volume
set!* this one currently has only a single drive on it
but is configured through the RAID controller (i.e. it
isn't just using the 895 chips thru sym0).

The box this is sitting in is usually load avg 1.5 or
so. Not much of an indication but it has been doing
something fairly active for the last few weeks without
falling.

> Wondering if this card would be a good RAID1 card for
> our HP NetServer LPr's...

Have not had chance to try the PCI card yet since the
only ones we have are in NT machines. I suspect they'll
work okay. But then, I don't see any reason not to use
one of the known-supported cards like a generic AMI or
a Mylex pci dac unless you have a netraid card lying
around anyway (in which case I guess there'd be no point
in asking on-list ;-)

> can you boot off of a RAID1 vinum setup yet?

I don't know. Perhaps someone on the scsi list will
- and since it's more relevant there than to -isp I've
changed the CC.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Mar 23 17:27: 3 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from mail.dbitech.bc.ca (i.caniserv.com [139.142.95.1])
	by hub.freebsd.org (Postfix) with SMTP id 0892837C6AD
	for <freebsd-scsi@freebsd.org>; Thu, 23 Mar 2000 17:26:36 -0800 (PST)
	(envelope-from darcy@ok-connect.com)
Received: (qmail 26881 invoked from network); 24 Mar 2000 01:26:27 -0000
Received: from ccliii.caniserv.com (HELO dbitech) (darcyb@139.142.95.253)
  by 139.142.95.10 with SMTP; 24 Mar 2000 01:26:27 -0000
Message-Id: <3.0.32.20000323172824.020a7df0@mail.ok-connect.com>
X-Sender: darcyb@mail.ok-connect.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 23 Mar 2000 17:28:24 +0000
To: freebsd-scsi@freebsd.org
From: Darcy Buskermolen <darcy@ok-connect.com>
Subject: DTP SmartRAID IV 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I've been having a persistance problem with my DPT card here is a snippit
of the dmesg output..

Jan 30 02:08:42 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870a744 - timed out
Jan 30 02:08:42 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870a45c - timed out
Feb  6 02:09:08 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870a45c - timed out
Feb  6 02:09:09 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870ac98 - timed out
Feb 11 02:09:07 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870a45c - timed out
Feb 11 02:09:07 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870ac98 - timed out
Feb 16 02:09:53 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870ac98 - timed out
Feb 16 02:09:53 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870a45c - timed out
Feb 21 02:09:11 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870ac98 - timed out
Feb 21 02:09:35 dsksrv /kernel: (da0:dpt0:0:0:0): CCB 0xf870a45c - timed out


What ends up happening, is at this point the machine stopps accepting
TCP/UDP packets, however ICMP pings still work. The only resolution is to
reboot the machine and HOPE it comes up, fsck takes anyware form 1 minute
to 30 minutes, even though that particular RAID 5 array has 0 bytes on it..
(It's 4 36GB HD's in a RAID 5 array).

Since I unmounted this FS I havn't had any problems with 0 change in load,
any Ideas ?



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Mar 23 17:41: 1 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from caspian.plutotech.com (caspian.plutotech.com [206.168.67.80])
	by hub.freebsd.org (Postfix) with ESMTP id E9FFE37BE1B
	for <scsi@FreeBSD.ORG>; Thu, 23 Mar 2000 17:40:57 -0800 (PST)
	(envelope-from gibbs@caspian.plutotech.com)
Received: from caspian.plutotech.com (localhost [127.0.0.1])
	by caspian.plutotech.com (8.9.3/8.9.1) with ESMTP id SAA44379;
	Thu, 23 Mar 2000 18:41:49 -0700 (MST)
	(envelope-from gibbs@caspian.plutotech.com)
Message-Id: <200003240141.SAA44379@caspian.plutotech.com>
X-Mailer: exmh version 2.1.1 10/15/1999
To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, scsi@FreeBSD.ORG
Subject: Re: bus_dmamap_load() and boundaries 
In-Reply-To: Your message of "Fri, 24 Mar 2000 00:18:43 +0100."
             <Pine.LNX.4.10.10003232337220.2139-100000@linux.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Date: Thu, 23 Mar 2000 18:41:49 -0700
From: "Justin T. Gibbs" <gibbs@FreeBSD.org>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>> Boundary support in bus_dmamap_load() just hasn't been implemented yet=
=2E
>
>Ok. Thanks for the reply.
>
>> It shouldn't be too hard to add.
>
>Indeed. But, for now, latest `sym' handles this situation by itself. Btw=
,
>on i386 the additon of boundary checking inside the scattering loop
>increases register pressure and resulted machine code is pathetic.

Hmm.  Not that I've tested it, but the boundary checking that I added
increased the size of of the entire busdma_machdep.o file by 64 bytes.
I'm no x86 guru, but I can't believe that too much register spilling
occurred with only 64 bytes worth of instruction space increase.  Here's
the code:

                if (sg->ds_len =3D=3D 0) {
                        sg->ds_addr =3D paddr;
                        sg->ds_len =3D size;
                } else if (paddr =3D=3D nextpaddr
=3D=3D>                     && (((paddr - 1) ^ (paddr - 1 + size))
=3D=3D>                       & ~(dmat->boundary - 1)) =3D=3D 0) {
                        sg->ds_len +=3D size;
                } else {
                        /* Go to the next segment */

Of course this does nothing for alignment checking which should
also be fixed.  I'd have to think a bit to come up with something
efficient for boundaries < PAGE_SIZE.

>I would
>also suggest to add the option of not actually trying coalescing physica=
l
>adjacent pages if boundary is just page aligned, and implement 3 differe=
nt
>loops:
>
>1) Scatter with page boundary
>2) Scatter with coalescing but no boundary checking (current)
>3) Scatter with coalescing and  boundary checking.
>
>(1) is about 10 instructions per loop on i386

Isn't this the same as specifying a maxseg size of PAGE_SIZE?
Unfortunately it looks like I failed to honor the maxseg size
parameter in this code.  Oops.

>(2) should still be reasonnable
>(3) should take more than 30 instructions per loop with great register =

>    pressure on i386.
>
>(May-be I am just nitpicking there :) )

It seems to me that having the hardware fetch an extra S/G segment
over the PCI bus must be less efficient than the CPU overhead to
coalless contiguous segments.  Maybe I'm wrong though.

>I have another suggestion. BSD systems provide a single virtual buffer t=
o
>SIMs. In result, actual IOs are smaller that they could be if providing
>a list of virtual buffer was possible, since IO coalescing would be a lo=
t
>simpler to implement from upper layers.

This is likely to happen sometime this year.  struct buf is going away
and we have talked for several years about having some type of chained
I/O.

>My suggestion is to support some new extended bus_dmamap_load service th=
at
>accept a scattered list of virtual buffers as input, as CAM specificatio=
n
>seem to allow. Enhancement of upper layers could come later. (By the way=
,
>as you know, for example, Linux SCSI drivers are provided by such
>scatterlists of virtual buffers).

If we follow the NetBSD way, there will be bus_dmamap_load interfaces
for most popular I/O structures (UIO, mbuf, etc.).  Bus DMA just hasn't
been fully developed yet.

>With modern hard disks that are very fast, providing too small IOs in
>average could get very sub-optimal. My opinion is that coalescing IOs wh=
en
>possible is much more important for performances than sorting them with
>Ultra-160 (and why with not future Ultra 320) hard disks. Note that
>maintaining lists of sorted IOs helps for IO coalescing.

Getting larger I/Os should be as simple as changing the clustering
parameters in the filesystem clustering code.  Unfortunately, too
many interfaces are tied to struct buf and that will have to be
fixed before I/O sizes can be increased much.

--
Justin




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Mar 23 20:50:12 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from skippyii.compar.com (mail.compar.com [216.208.38.130])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4D9E237B5CD; Thu, 23 Mar 2000 20:49:54 -0800 (PST)
	(envelope-from matt@gsicomp.on.ca)
Received: from matt (HSE-Kitchener-ppp84482.sympatico.ca [216.209.96.51])
	by skippyii.compar.com (8.9.3/8.9.1) with SMTP id XAA13460;
	Thu, 23 Mar 2000 23:54:19 -0500 (EST)
	(envelope-from matt@gsicomp.on.ca)
Message-ID: <001401bf954c$5fd5bf40$1200a8c0@gsicomp.on.ca>
From: "Matthew Emmerton" <matt@gsicomp.on.ca>
To: <freebsd-scsi@freebsd.org>, <freebsd-smp@freebsd.org>
Subject: Problems with 3.4-RELEASE SMP + AIC7870
Date: Thu, 23 Mar 2000 23:49:13 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


I'm running a 3.4-RELEASE SMP system, equipped with 2xP133 and an onboard
AIC7870 PCI SCSI controller, and recently have been plagued by a whack of
SCB errors.

dmesg (relevant parts only)
---------------------------
FreeBSD 3.4-RELEASE #0: Sun Jan 16 18:14:14 EST 2000
    root@gabby.gsicomp.on.ca:/usr/src-3.4/sys/compile/GABBY.20000116.01
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium/P54C (586-class CPU)
  Origin = "GenuineIntel"  Id = 0x52c  Stepping = 12
  Features=0x3bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC>
real memory  = 50331648 (49152K bytes)
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  0, version: 0x00030010, at 0xfee00000
 cpu1 (AP):  apic id:  1, version: 0x00030010, at 0xfee00000
 io0 (APIC): apic id:  2, version: 0x000f0011, at 0xfec00000
Preloaded elf kernel "kernel" at 0xc02d4000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc02d409c.
ahc0: <Adaptec aic7870 SCSI adapter> rev 0x03 int a irq 11 on pci0.11.0
ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs
Intel Pentium detected, installing workaround for F00F bug
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via pin 2
IP packet filtering initialized, divert enabled, rule-based forwarding
disabled, logging disabled
Waiting 15 seconds for SCSI devices to settle
da0 at ahc0 bus 0 target 0 lun 0
da0: <SEAGATE ST32430N 0510> Fixed Direct Access SCSI-2 device
da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled
da0: 2049MB (4197405 512 byte sectors: 64H 32S/T 2049C)
cd0 at ahc0 bus 0 target 4 lun 0
cd0: <PIONEER CD-ROM DR-U06S 1.05> Removable CD-ROM SCSI-2 device
cd0: 10.000MB/s transfers (10.000MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present

This configuration was rock-solid for it's "normal" workload, but whenever I
attempted to do something that bashed the disk (such as building gcc), I
would get errors like these:

/kernel:  swap_pager: indefinate wait buffer: device 0x30411, blkno: 8688,
size 8192
/kernel: (probe0:ahc0:0:0:0): SCB 0xa - timed out in message out phase,
SEQADDR == 0x151

The system would then freeze.

Then things got worse.  To supplement my existing 2 GB Seagate SCSI-2 drive,
I dropped in a 1 GB Fujitsu SCSI-2 drive.  (It's running in SCSI-1 mode for
debugging purposes.)

da1 at ahc0 bus 0 target 2 lun 0
da1: <FUJITSU M2694ES-512 8134> Fixed Direct Access SCSI-CCS device
da1: 3.300MB/s transfers
da1: 1033MB (2117025 512 byte sectors: 64H 32S/T 1033C)

Now, I consistently get (on an almost daily basis) messages like the
following:

/kernel: Timedout SCB handled by another timeout

and the system locks for 10-15 seconds, and then goes along it's merry way;
in addition, the errors reported above now occur with greater frequency.

Scanning the archives, I came upon these threads:

http://www.freebsd.org/cgi/getmsg.gsi?fetch=66633+69631+/usr/local/www/db/te
xt/1998/freebsd-scsi/19980308.freebsd-scsi
http://www.freebsd.org/cgi/getmsg.gsi?fetch=123866+125897+/usr/local/www/db/
text/1998/freebsd-scsi/19980531.freebsd-scsi

which suggested UP mode, which seemed to work just fine.  However, my
thought was the "problem" that was seen 1.5 years ago, presumably using some
hybrid 2.2-stable + CAM codebase, would have been fixed by now.  (And yes,
I've checked my cables and termination.)

If something thinks that there definitely is a timing problem or something
with the SMP + AIC code, I'd be willing to hack away at it - mind you,
"remote gdb" is a totally foreign concept to me.

Thanks,

--
Matthew Emmerton
GSI Computer Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Fri Mar 24  9: 1:45 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from kaon.intercom.com (kaon.intercom.com [198.143.3.30])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9E0E737B5D0; Fri, 24 Mar 2000 09:01:40 -0800 (PST)
	(envelope-from jason@intercom.com)
Received: from shagalicious.com ([206.98.165.250] helo=intercom.com)
	by kaon.intercom.com with esmtp (Exim 3.13 #1)
	id 12YXSr-0001Th-00; Fri, 24 Mar 2000 12:01:37 -0500
Message-ID: <38DBA0C5.DB9C4EDB@intercom.com>
Date: Fri, 24 Mar 2000 12:07:17 -0500
From: "Jason J. Horton" <jason@intercom.com>
Organization: Intercom Online Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.0.36 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Stuart Henderson <sthen@naiad.eclipse.net.uk>
Cc: freebsd-questions@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
Subject: Re: Hardware Raid controllers
References: <38DA319C.4AC963CC@stripe.dk> <20000323093640.E9661@simkin.com> <20000323135208.K95709@PacHell.TelcoSucks.org> <38DA9CFB.D3C526C2@intercom.com> <20000324002630.A46923@naiad.eclipse.net.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> Have not had chance to try the PCI card yet since the
> only ones we have are in NT machines. I suspect they'll
> work okay. But then, I don't see any reason not to use
> one of the known-supported cards like a generic AMI or
> a Mylex pci dac unless you have a netraid card lying
> around anyway (in which case I guess there'd be no point
> in asking on-list ;-)

My thought on using the NetRAID is that the system I will be using
(HP NetServer LPr) is HP, and the NetRAID card may integrate into
the system better. If I use a Compaq or Mylex card, I dont know if
I need to pull out the hotswap buffer backplane or anything weird
like that. I will save the futzing around with hardware for my generic
custom built PC servers, not my new name brand toy.

Thanks for the info. Now all I have to do is hunt down product
specs on thier site (Thier Korean and Russian sites have had more
informative data than thier USA site.)

-- 
	-Jason J. Horton <jason@intercom.com>
	 Fat Man in a Little Coat
	 Intercom Online Inc. 
	 212.376.7440 ext 21 | http://www.intercom.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Fri Mar 24 12:31:57 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from mauibuilt.com (mauibuilt.com [205.166.249.50])
	by hub.freebsd.org (Postfix) with ESMTP id 66AF937B74E
	for <freebsd-scsi@freebsd.org>; Fri, 24 Mar 2000 12:31:51 -0800 (PST)
	(envelope-from freebsd@mauibuilt.com)
Received: (from freebsd@localhost)
	by mauibuilt.com (8.9.3/8.9.3) id KAA10500
	for freebsd-scsi@freebsd.org; Fri, 24 Mar 2000 10:34:56 -1000 (HST)
	(envelope-from freebsd)
From: FreeBSD MAIL <freebsd@mauibuilt.com>
Message-Id: <200003242034.KAA10500@mauibuilt.com>
Subject: 
To: freebsd-scsi@freebsd.org
Date: Fri, 24 Mar 2000 10:34:55 -1000 (HST)
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

subscribe freebsd-scsi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Fri Mar 24 20:51:14 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from mauibuilt.com (mauibuilt.com [205.166.249.50])
	by hub.freebsd.org (Postfix) with ESMTP id 37D0137B590
	for <freebsd-scsi@freebsd.org>; Fri, 24 Mar 2000 20:51:06 -0800 (PST)
	(envelope-from freebsd@mauibuilt.com)
Received: (from freebsd@localhost)
	by mauibuilt.com (8.9.3/8.9.3) id SAA12248
	for freebsd-scsi@freebsd.org; Fri, 24 Mar 2000 18:54:33 -1000 (HST)
	(envelope-from freebsd)
From: FreeBSD MAIL <freebsd@mauibuilt.com>
Message-Id: <200003250454.SAA12248@mauibuilt.com>
Subject: ahc0: Signaled a Target Abort
To: freebsd-hackers@freebsd.org
Date: Thu, 23 Mar 2000 21:48:42 -1000 (HST)
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I am trying to get a adaptec 3940 AUW controller to work with an
Asus Athlon motherboard (newer AMD 751 chipset) and I have tried
3.3-R 3-4R and 4.0-R and all boot untill it says,...
 
Waiting 15 Seconds for SCSI devices to settle
ahc0: Signaled a Target Abort  (this is after about 15 seconds)
 
 
I have no Idea what it is.. I have tried the card in every PCI slot with every
other PCI card removed.. I have played with the only PCI setting in the mother
board BIOS and I have upgraded teh 3940's bios to the latest 2.11 release.
 
This board and drives work fine in an older P-200 system...
 
if anyone has any ideas please let me know..
 
Thanks in advance for any reply...
 
 
Mahalo
 
Richard Puga
puga@mauibuilt.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sat Mar 25 15: 8:59 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66])
	by hub.freebsd.org (Postfix) with ESMTP
	id A0E8437B8AA; Sat, 25 Mar 2000 15:08:52 -0800 (PST)
	(envelope-from dgilbert@office.tor.velocet.net)
Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226])
	by sabre.velocet.net (Postfix) with ESMTP
	id C9CB2137FB3; Sat, 25 Mar 2000 18:08:50 -0500 (EST)
Received: (from dgilbert@localhost)
	by office.tor.velocet.net (8.9.3/8.9.3) id SAA09328;
	Sat, 25 Mar 2000 18:08:50 -0500 (EST)
	(envelope-from dgilbert)
From: David Gilbert <dgilbert@velocet.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14557.18178.239025.747850@trooper.velocet.net>
Date: Sat, 25 Mar 2000 18:08:50 -0500 (EST)
To: freebsd-current@freebsd.org, freebsd-scsi@freebsd.org
Subject: MegaRAID jiggles clock?
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

I'm wondering if the AMI MegaRAID controller/driver might be the
reason that I'm getting a large number of clock resets from ntpd.
About every half hour, ntpd seems to feel the need to reset the clock
on the server by about 1/3 of a second.  The server has a moderate NFS 
load (going out through 12 dc interfaces) and an AMI MegaRAID 1400
controller with 8 disks in a RAID-5 config.

I have other servers with 12 dc ports, and havn't seen any
particularly bad time performance from them, which is why I'm
suspicious of the megaraid.  This machine is also using a motherboard
common to many of our other machines.  None of our other servers (we
have a "ring" of 5 time servers to which all our internal hosts
connect) or clients appear to have any issues.

I have considered setting the option on ntpd to only adjust time by
adjusting the frequency ... to see if this is just a bogon clock chip
or somesuch.

ideas?

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
=========================================================GLO================


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sat Mar 25 15:39:19 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6])
	by hub.freebsd.org (Postfix) with ESMTP
	id D794937B50B; Sat, 25 Mar 2000 15:39:10 -0800 (PST)
	(envelope-from toasty@celery.dragondata.com)
Received: (from toasty@localhost)
	by celery.dragondata.com (8.9.3/8.9.3) id RAA55426;
	Sat, 25 Mar 2000 17:39:02 -0600 (CST)
	(envelope-from toasty)
From: Kevin Day <toasty@dragondata.com>
Message-Id: <200003252339.RAA55426@celery.dragondata.com>
Subject: Re: MegaRAID jiggles clock?
To: dgilbert@velocet.ca (David Gilbert)
Date: Sat, 25 Mar 2000 17:39:01 -0600 (CST)
Cc: freebsd-current@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG
In-Reply-To: <14557.18178.239025.747850@trooper.velocet.net> from "David Gilbert" at Mar 25, 2000 06:08:50 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> 
> I'm wondering if the AMI MegaRAID controller/driver might be the
> reason that I'm getting a large number of clock resets from ntpd.
> About every half hour, ntpd seems to feel the need to reset the clock
> on the server by about 1/3 of a second.  The server has a moderate NFS 
> load (going out through 12 dc interfaces) and an AMI MegaRAID 1400
> controller with 8 disks in a RAID-5 config.
> 
> I have other servers with 12 dc ports, and havn't seen any
> particularly bad time performance from them, which is why I'm
> suspicious of the megaraid.  This machine is also using a motherboard
> common to many of our other machines.  None of our other servers (we
> have a "ring" of 5 time servers to which all our internal hosts
> connect) or clients appear to have any issues.
> 
> I have considered setting the option on ntpd to only adjust time by
> adjusting the frequency ... to see if this is just a bogon clock chip
> or somesuch.
> 
> ideas?
> 
> Dave.
> 

Granted, this is an old 4.0-current machine(from around September), but....
I've seen heavy NFS server load affect the clocks on all three of my NFS
servers. The heavier the load, the faster the clock seems to run.

Mar 25 10:00:01 nfs ntpdate[75363]: adjust time server 192.160.127.90 offset -0.028636
Mar 25 11:00:02 nfs ntpdate[75406]: adjust time server 192.160.127.90 offset -0.033046
Mar 25 12:00:01 nfs ntpdate[75448]: adjust time server 192.160.127.90 offset -0.031371
Mar 25 13:00:01 nfs ntpdate[75490]: adjust time server 192.160.127.90 offset -0.030030
Mar 25 14:00:01 nfs ntpdate[75532]: adjust time server 192.160.127.90 offset -0.031346
Mar 25 15:00:00 nfs ntpdate[75573]: adjust time server 192.160.127.90 offset -0.030992
Mar 25 16:00:00 nfs ntpdate[75616]: adjust time server 192.160.127.90 offset -0.031654
Mar 25 17:00:00 nfs ntpdate[75657]: adjust time server 192.160.127.90 offset -0.031354

Because my NFS load isn't consistant throughout the day, xntpd seems to
really freak out about trying to keep it balanced. 

Relevant info:


Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 337194185 Hz
CPU: AMD-K6(tm) 3D processor (337.19-MHz 586-class CPU)
  Origin = "AuthenticAMD"  Id = 0x580  Stepping = 0
  Features=0x8001bf<FPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX>
  AMD Features=0x80000800<SYSCALL,3DNow!>
real memory  = 134217728 (131072K bytes)
avail memory = 126246912 (123288K bytes)
vinum: loaded
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <AcerLabs M1541 (Aladdin-V) PCI host bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <AcerLabs M5243 PCI-PCI bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
isab0: <AcerLabs M1533 portable PCI-ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
fxp0: <Intel EtherExpress Pro 10/100B Ethernet> irq 11 at device 14.0 on pci0
fxp0: Ethernet address 00:90:27:34:c1:ec
ata-pci0: <AcerLabs Aladdin IDE controller> irq 0 at device 15.0 on pci0
ata-pci0: Busmastering DMA supported
ata0 at 0x01f0 irq 14 on ata-pci0
ata1 at 0x0170 irq 15 on ata-pci0
vga-pci0: <ATI model 4750 graphics accelerator> at device 16.0 on pci0
pn0: <82c169 PNIC 10/100BaseTX> irq 10 at device 18.0 on pci0
pn0: Ethernet address: 00:a0:cc:3e:c6:3d
pn0: autoneg complete, link status good (full-duplex, 100Mbps)
ahc0: <Adaptec 2940A Ultra SCSI adapter> irq 9 at device 20.0 on pci0
ahc0: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs
ata0: master: setting up UDMA2 mode on Aladdin chip OK


-- Kevin



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sat Mar 25 15:46:31 2000
Delivered-To: freebsd-scsi@freebsd.org
Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0564C37B533; Sat, 25 Mar 2000 15:46:25 -0800 (PST)
	(envelope-from dgilbert@office.tor.velocet.net)
Received: from office.tor.velocet.net (trooper.velocet.net [216.126.82.226])
	by sabre.velocet.net (Postfix) with ESMTP
	id 2D0F3137FB5; Sat, 25 Mar 2000 18:45:46 -0500 (EST)
Received: (from dgilbert@localhost)
	by office.tor.velocet.net (8.9.3/8.9.3) id SAA12320;
	Sat, 25 Mar 2000 18:45:46 -0500 (EST)
	(envelope-from dgilbert)
From: David Gilbert <dgilbert@velocet.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14557.20394.91811.148485@trooper.velocet.net>
Date: Sat, 25 Mar 2000 18:45:46 -0500 (EST)
To: Kevin Day <toasty@dragondata.com>
Cc: dgilbert@velocet.ca (David Gilbert), freebsd-current@FreeBSD.ORG,
	freebsd-scsi@FreeBSD.ORG
Subject: Re: MegaRAID jiggles clock?
In-Reply-To: <200003252339.RAA55426@celery.dragondata.com>
References: <14557.18178.239025.747850@trooper.velocet.net>
	<200003252339.RAA55426@celery.dragondata.com>
X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs  Lucid
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>>>>> "Kevin" == Kevin Day <toasty@dragondata.com> writes:

[about clock jiggling]

Kevin> Granted, this is an old 4.0-current machine(from around
Kevin> September), but....  I've seen heavy NFS server load affect the
Kevin> clocks on all three of my NFS servers. The heavier the load,
Kevin> the faster the clock seems to run.

Kevin> Mar 25 10:00:01 nfs ntpdate[75363]: adjust time server
Kevin> 192.160.127.90 offset -0.028636

Mmm.... but that adjustment is 10x smaller than mine:

Mar 25 16:53:29 raid1 xntpd[19242]: time reset (step) -0.340983 s

Dave.

-- 
============================================================================
|David Gilbert, Velocet Communications.       | Two things can only be     |
|Mail:       dgilbert@velocet.net             |  equal if and only if they |
|http://www.velocet.net/~dgilbert             |   are precisely opposite.  |
=========================================================GLO================


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message