[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adaptec scsi driver OBSD 3.3 question
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?
> -----Original Message-----
> From: J.D. Bronson [mailto:email@example.com]
> Sent: Saturday, May 03, 2003 12:00
> To: firstname.lastname@example.org; email@example.com
> 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