An OSMEvent is something that is returned to our driver by the Adaptec
code. We haven't seen this before, so are not too sure how to handle it.
I am still waiting for the traceinfo output.


-----Original Message-----
From: Robert Hem [mailto:community-noreply@qnx.com] 
Sent: Monday, August 11, 2008 3:43 PM
To: qnx4-community
Subject: Re: RE: RE: Fsys.aha8scsi issues with Adaptec 29160LP Ultra 160
Controller 

I've discussed this a bit with my cohorts.  We've never seen any
OSMEvent()s before either.  Like I said in my original post, we've been
using the Fsys.aha8scsi driver for years.  With a number of different
RAID controllers (Adaptec, Chapporel(sp), Infotrend and the new ARC-6060
w/ the previous firmware version).  They have all worked just fine.  No
errors what so ever.  In fact we were pretty exited about the
performance of the ARC-6060 in the evaluations we did (and hopefully can
be again).  Around 60 MB/sec sustained read performance.  ~50-55 MB/sec
write, and ~45 MB/sec random access/multi threaded access, sustained.

As far as talking to raw SCSI drives go, frankly, we gave up on that
years ago.  Whenever we'd try hooking one up, we'd alway run into
seemingly phantom disk block errors, especially when
performance/throughput was pushed to the limit.  Consequently, whenever
the need to talk to single disks has arisen (removable backups, etc.),
we've turned LUN support on in the driver and had the RAID controller
act as the middle guy talking to the individual drives.  With each drive
configured as a separate LUN on the controller.  But, I digress...

Pardon my ignorance, but what is an OSMEvent?  Perhaps if we had some
idea what OSMEvent()s are being logged, we could figure out a way around
it??  Maybe disable something in the RAID controller configuration, or
something along those lines.

Another bit of evidence that something changed in the ARC-6060 with the
newer firmware,  the BIOS would never recognize the ARC-6060 w/ the
older firmware as a synchronous U160 device, it always showed up as a
generic async SCSI drive/device.  We had to turn off int 11 bio support
to get it into U160 mode on the QNX side with the correct drive
geometry.  Needless to say, booting off it was a lost cause.  With the
new firmware the BIOS recognizes it correctly, no tweaking necessary to
get the geometry, etc. correct on the QNX side, and we've even been able
to boot off it.  And, run successfully when the OSMEvent()s don't show
up.

We're so close, but yet so far :-(

Any idea why using -D80 NEVER works, yet -DCF (the wrong device ID)
seems to work most of the time?  There's got tp be some funky timing
going on here.

-Rob

> The driver performs an auto configuration when it starts.  We have
never
> seen a device cause the CHIM to generate an OSMEvent after it is up.
> Unfortunately there aren't any command line options that could change
> the behavior.
> 
> 
> -----Original Message-----
> From: Robert Hem [mailto:community-noreply@qnx.com] 
> Sent: Monday, August 11, 2008 1:06 PM
> To: qnx4-community
> Subject: Re: RE: Fsys.aha8scsi issues with Adaptec 29160LP Ultra 160
> Controller 
> 
> > Looks like the Adaptec CHIM code is reporting an auto configuration
> > required event.  The driver doesn't seem to do anything with it.
> Maybe
> > the RAID box is resetting the bus?  Do you see the problem with a
> > standard SCSI drive?
> 
> Yeah, that's probably what's happening, but I'm going to have to get
> back to you on that.  I have to dig up a SCSI drive to try it with.
The
> RAID controller has a SCSI host interface, but a SATA drive interface.
> 
> Are there any command line options that could be set to get the driver
> to maybe ignore auto configuration requirements?
> 
> We're really between a rock and a hard place here.  Twenty-four new
> systems, that we...