From owner-freebsd-scsi Wed Sep 23 04:15:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA05475 for freebsd-scsi-outgoing; Wed, 23 Sep 1998 04:15:33 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA05288 for ; Wed, 23 Sep 1998 04:13:51 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id NAA23202; Wed, 23 Sep 1998 13:12:29 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA02914; Wed, 23 Sep 1998 13:12:23 +0200 (MET DST) Message-ID: <19980923131222.21236@follo.net> Date: Wed, 23 Sep 1998 13:12:22 +0200 From: Eivind Eklund To: shimon@simon-shapiro.org Cc: scsi@FreeBSD.ORG Subject: Re: DPT boot References: <19980923003214.35208@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Simon Shapiro on Tue, Sep 22, 1998 at 11:06:48PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 22, 1998 at 11:06:48PM -0400, Simon Shapiro wrote: > Eivind Eklund, On 22-Sep-98 you wrote: > > Any clues? Anything I should test? (I can hook up a pretty complete > > debugging environment here, including doing remote kernel debugging if > > necessary - at the moment I also have 'scratch' disks I can use for > > testing, though not having this controller operational means I my main > > workstation is not usable, so I'd prefer to avoid tests that take a > > long time). > > I assume this controller works on the pre-CAM driver... :-) Yes, perfectly. The only problem is that the DPT is attempting to outsmart the BIOS, but once it is in FreeBSD, everything works perfectly. > > Oh, and while this was happening, the DPT kept a steady light #3 (as > > counted from the connector-less end of the DPT). > > On a 3224 it is bus transfer from adapter, or adapter reset (depends on how > you look at it, and assuming first LED is 1). First LED is 1, and I counted from the end of the board that hasn't got a connector to the outside world (ie, not the end where the PCI-bus and the disk-connectors are, but the end with the little black plastic thing that support the board. The end I'm talking about is where usual PCI boards are no more (due to being smaller) :-) > If it is a transfer LED, then the DMA engine is stuck. If it is a reset, > that means the controller was reset and never released. In either case I > would suspect the initialization code does not work correctly. I have > some work-work emergencies to handle right now, but will start debugging > this driver any day soon. OK, great. Tell me if you want me to do anything. If you start wiping disks, a pre-alpha version of my testbox building scripts are at http://www.freebsd.org/~eivind/testbox-0.1.tar.gz Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message