Your inherited driver is breaking the scsiport design rules. Probably (and
this is a total guess on my part,) if this is a non-pnp driver, the software
defect you described will, in itself, do no harm. However there is no reason
I can think of that you would avoid using the scsiport version of the device
resource (access range) configuration routines. You might want to consider
fixing this problem.
Have you tried running the .net DDK driver verifier on your miniport? Are
you planning on having this miniport WHQL certified?
=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com
-----Original Message-----
From: McDowell, Steve [mailto:xxxxx@softek.fujitsu.com]
Sent: Thursday, June 26, 2003 4:27 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Failed assertion in checked SCSIPORT -
This is inherited code, not something I wrote, just something I’m trying to
understand.
My driver is managing its own hardware interfaces independent of scsiport
for what’s essentially a proprietary HBA. Driver works fine, been in
production for a very long time.
Loaded checked build to find some -other- problem, and this assertion came
up.
My only questions are these: am I breaking something in ScsiPort by not
defining AccessRanges? Could I be breaking other HBA code that’s trying to
co-exist? What’s the downside of leaving this code alone?
-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Thursday, June 26, 2003 1:04 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Failed assertion in checked SCSIPORT -
You are setting NumberOfAccessRanges to zero in the HW_INITIALIZATION_DATA
structure that you pass to scsiport in your call to ScsiPortInitialize? This
is wrong and has nothing to do with interrupt vs polling, it has to do with
how many control registers and buffers on your hardware you need to access.
How are you going to poll the device if you can’t communicate with it? The
assertion is valid.
=====================
Mark Roddy
Hollis Technology Solutions
www.hollistech.com
xxxxx@hollistech.com
-----Original Message-----
From: McDowell, Steve [mailto:xxxxx@softek.fujitsu.com]
Sent: Thursday, June 26, 2003 3:43 PM
To: NT Developers Interest List
Subject: [ntdev] Failed assertion in checked SCSIPORT -
I have a SCSI miniport that works on a polling model (not interrupt driven),
so I don’t define ‘AccessRanges’.
Using the checked build of scsiport, I fail this assertion for each of my
devices:
*** Assertion failed: Context->AccessRanges != NULL
*** Source File: D:\nt\private\ntos\dd\storage\scsiport\init.c, line
1192
Question: how benign is this? Do I need to dummy something up? Or will the
this work w/ no scsiport side effects? Seems to, but before I ship, I’d like
a warmer feeling.
Thanks in advance -
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@softek.fujitsu.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com