Re: Adaptec scsi driver OBSD 3.3 question

["J.D. Bronson" <jeff@xpec.com>]

At 12:16 PM 05/03/2003, Marco Peereboom wrote:
>The code is not verbose enough and it won't tell you what it did.
>
>Add a printf after /* Using memory mapping ... */ saying memory mapping
>enabled or something.
>The code will try to go back to IO mappings when it didn't work though.
>
>What I don't get is why is this such a big deal for you?
>What's wrong with IO mapping instead of memory mapping?
>
>/marco

Marco - its no big deal...I just had good luck with using it before in my 
other OS :)

I will try this test. thanks.



> > -----Original Message-----
> > From: J.D. Bronson [mailto:jeff@xpec.com]
> > Sent: Saturday, May 03, 2003 12:00
> > To: slash@peereboom.us; tech@openbsd.org
> > Subject: RE: Adaptec scsi driver OBSD 3.3 question
> >
> >
> > At 11:53 AM 05/03/2003, Marco Peereboom wrote:
> > >2-5 seconds? Let's think about that.
> > >
> > >Let's say our hypothetical SCSI card has a single drive
> > attached to it.
> > >
> > >According to the spec a Selection Time Out (STO) asserts busy for at
> > >least 250ms. An STO happens when the initiator asserts BUSY,
> > SELECT and
> > >ATTENTION with an unused target id. This happens for example
> > when the
> > >OS issues an INQUIRY command to ALL target ID's during boot.
> > So in our
> > >little example we have 1 drive and thus 14 STO's. That makes
> > it roughly
> > >3.5 seconds. An INQUIRY is an "expensive" command because the drive
> > >needs to collect a whole bunch of data. In normal circumstances the
> > >drive will disconnect from the bus; collect the data;
> > reconnect to the
> > >initiator and return the data. Depending on the drive this
> > can take up
> > >to a few hundred mili seconds (the newer U320 models can
> > really take a
> > >while). This also assumes that everything actually is
> > functioning as it
> > >should. So just executing the scan takes lets say 4 seconds.
> > With your
> > >numbers you only have a 1 second window of opportunity for
> > something to
> > >get corrected. That is not a whole lot in SCSI land where
> > smart devices
> > >go off and "do something". This assumes also no LUN support and does
> > >not mention all the OS administrative commands it issues during
> > >boot(READ CAPICITY,
> > >READ(10) etc).
> > >
> > >Attached is a SCSI trace of me powering on a box with a
> > drive attached
> > >to a SCSI card. You'll see several INQUIRY's (0x12) but only
> > the last
> > >one in the sequence is relevant for this discussion. (ok, so
> > I powered
> > >up the box and went into the BIOS; regular POST causes all kinds of
> > >crap on the bus). This is also a very old drive (I believe
> > 95-ish) that
> > >does not take as long on an INQUIRY as newer ones. It is
> > interesting to
> > >note that a STO takes quite a bit longer than 250ms because of setup
> > >time and bus free time.
> >
> > WOW! that was more info than I ever expected :)
> > Ok...so I leave that value alone....but what about AHC_ALLOW_MEMIO ?
> >
> > Just for a test, I added that into myconfig file for kernel build as:
> >
> > option    AHC_ALLOW_MEMIO
> >
> > ...the kernel built and I did see it going by during the
> > build process. So am I to assume it is now active?
> >
> > The machine booted just fine.
> >
> > is there a command I can do to see if it is using MEM IO now?
> > (presuming I
> > did this right in the first place)
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > J.D. Bronson
> > Aurora Health Care
> > Information Services
> > Milwaukee, Wisconsin USA
> > Main Office: 414.978.3000
> >




-- 
J.D. Bronson
Aurora Health Care
Information Services
Milwaukee, Wisconsin USA
Main Office: 414.978.3000