Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Sep 1998 13:50:02 -0400 (EDT)
From:      Simon Shapiro <shimon@simon-shapiro.org>
To:        Eivind Eklund <eivind@yes.no>
Cc:        scsi@FreeBSD.ORG
Subject:   Re: DPT boot
Message-ID:  <XFMail.980923135002.shimon@simon-shapiro.org>
In-Reply-To: <19980923131222.21236@follo.net>

next in thread | previous in thread | raw e-mail | index | archive | help

Eivind Eklund, On 23-Sep-98 you wrote:
>  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.

I talked to someone who knows at DPT;  This is a knwon problem on certain
motherboards.  I suspect that due to age, etc., they will not fix this
minor problem anytime soon.  Anyway, this is a BIOS geometry, if I remember
correctly.

> > >  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) :-)

Yup.  This is the Data Transfer From Adaper LED.  It means a DMA trasfer
starts and then the card hangs.  Either Justin is correct and you walked on
a firmware bug, or the new driver is missing something in the
initialization, that was done correctly in the precambian days.  I will
look at it, once Justin has saturated his changes to the driver.

> > 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

I am going to test on Bras, and ONLY on brass.  IF anyone (Justin?) needs
access to it, just say so. Once Brass is passing regression, I will test on
Nomis.  Then Sendero, then performance...


Sincerely Yours,                 Shimon@Simon-Shapiro.ORG
                                             770.265.7340
Simon Shapiro

Unwritten code has no bugs and executes at twice the speed of mouth


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980923135002.shimon>