Re: Adaptec scsi driver OBSD 3.3 question

["Marco Peereboom" <slash@peereboom.us>]

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

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