SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU's?

NTDEV
1

I’m working on a specialized scsi miniport and am trying to resolve a
little issue.

It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to the
miniport for execution, SCSIPORT stops issuing SRB’s to ALL other LU’s.
SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver when they
retry after the initial SRB returns an error. Is this correct, or should I
keep hunting for what’s really happening?

My real problem is I have this user mode app that is constantly chatting
with the miniport through passthrough requests, to a private target id.
When a normal device get’s an error, the class drivers retry the request
with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no longer
chat with the driver about what’s happening.

I’ve even moved my private targets to a different PathId, with no apparent
change. It also seem like SRB_IO_CONTROL’s also get held when the SRB with
SRB_FLAGS_DISABLE_DISCONNECT is being processed??

It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in the
SRB’s to my private target, but without a driver above SCSIPORT (or a
filter on passthough requests) I haven’t found a way around this.

Any ideas on how to let a miniport keep processing multiple LU’s all the
time? This has to work under NT4/W2K/WinXP. I would prefer not to have a
device on the side of the minport processing IOCTL’s, as the information
coming down from the app sometimes effects SRB completion, so I need to be
in a valid miniport context.

Thanks.

  • Jan

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

You might want to take a look at this related link.

Disk Performance May Degrade Over Time (Q263939)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q263939

Niraj

-----Original Message-----
From: Jan Bottorff [mailto:xxxxx@pmatrix.com]
Sent: Monday, December 17, 2001 4:21 PM
To: NT Developers Interest List
Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

I’m working on a specialized scsi miniport and am trying to resolve a
little issue.

It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to the
miniport for execution, SCSIPORT stops issuing SRB’s to ALL other LU’s.
SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver when they
retry after the initial SRB returns an error. Is this correct, or should I
keep hunting for what’s really happening?

My real problem is I have this user mode app that is constantly chatting
with the miniport through passthrough requests, to a private target id.
When a normal device get’s an error, the class drivers retry the request
with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no longer
chat with the driver about what’s happening.

I’ve even moved my private targets to a different PathId, with no apparent
change. It also seem like SRB_IO_CONTROL’s also get held when the SRB with
SRB_FLAGS_DISABLE_DISCONNECT is being processed??

It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in the
SRB’s to my private target, but without a driver above SCSIPORT (or a
filter on passthough requests) I haven’t found a way around this.

Any ideas on how to let a miniport keep processing multiple LU’s all the
time? This has to work under NT4/W2K/WinXP. I would prefer not to have a
device on the side of the minport processing IOCTL’s, as the information
coming down from the app sometimes effects SRB completion, so I need to be
in a valid miniport context.

Thanks.

  • Jan

You are currently subscribed to ntdev as: xxxxx@netapp.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

> It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to the

miniport for execution, SCSIPORT stops issuing SRB’s to ALL other LU’s.

Exactly so. This is very logical.

No-disconnect request occupies the physical SCSI bus till completion. No other request can be initiated on the SCSI bus while
no-disconnect is active.
Since MS’s miniports are assumed to immediately start the physical SCSI operation in their HwStartIo, then SCSIPORT has this
heuristics.

change. It also seem like SRB_IO_CONTROL’s also get held when the SRB with
SRB_FLAGS_DISABLE_DISCONNECT is being processed??

Any SRBs are held.

It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in the
SRB’s to my private target

You will need to call NextRequest notification to retrieve your control SRB in your miniport.
But what if the next SRB to StartIo will be not a control one, but a real one?

Any ideas on how to let a miniport keep processing multiple LU’s all the
time? This has to work under NT4/W2K/WinXP.

Our SCSI port library can help.

Max

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

Jan,

You have the source for classpnp in the ddk, look up the usage of
ErrorCount in the fdo extension. Once this monotonically incrementing
value hits 4, multiple requests per lu are barred, once it hits 8
disconnect is barred. THIS VALUE NEVER GOES DOWN. IMHO this is a HUGE
HIDEOUS BUG-BUG in classpnp. Once you check into this particular roach
motel you can’t check out.

So the trick is to not get here, or if you do get here to undo what
classpnp is doing. To not get here you need to identify the error cases
that cause classpnp to bump ErrorCount, and to not produce those errors.
This is tricky, as timeouts, for example, are hard to avoid if they
really are happening. A better approach is to turn the
SRB_FLAGS_DISABLE_DISCONNECT and perhaps the
SRB_FLAGS_DISABLE_SYNCH_TRANSFER bits, (and other related bits, see the
source code,) off in the srbflags by implementing a filter driver above
scsiport. There is no one approach to this that will work here for nt4
and w2k as scsiport is pretty much different for the two, although
neither is a big deal, and the nt4 one borders on trivial. So you write
one filter for the nt4 scsiport and another for w2k/xp. Or you go buy
max’s scsiport replacement, or write your own. Or ask microsoft to think
about the robustness implications of the way they manage ErrorCount, as
it really is a bug.

Why is this really a bug? Glad you asked. Consider the case where you
hot plug a disk or adjust the scsi cables on an external storage unit.
The bus gets a ‘little upset’ for a while: it has a transitory failure.
Meanwhile the stupid error counter gets to eight, and from now on until
you reboot the machine, that scsi bus is operating in what we, when we
hit this bug, quaintly termed ‘sludge mode’. Golly, how difficult would
it be to implement a second counter, the SequentialGoodCounter, that
would reset ErrorCount to zero when it hits it’s threshold?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, December 17, 2001 7:21 PM
To: NT Developers Interest List
Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

I’m working on a specialized scsi miniport and am trying to resolve a
little issue.

It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is
sent to the
miniport for execution, SCSIPORT stops issuing SRB’s to ALL
other LU’s.
SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver
when they
retry after the initial SRB returns an error. Is this
correct, or should I
keep hunting for what’s really happening?

My real problem is I have this user mode app that is
constantly chatting
with the miniport through passthrough requests, to a private
target id.
When a normal device get’s an error, the class drivers retry
the request
with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app
can no longer
chat with the driver about what’s happening.

I’ve even moved my private targets to a different PathId,
with no apparent
change. It also seem like SRB_IO_CONTROL’s also get held when
the SRB with
SRB_FLAGS_DISABLE_DISCONNECT is being processed??

It looks like I could potentially set
SRB_FLAGS_BYPASS_FROZEN_QUEUE in the
SRB’s to my private target, but without a driver above SCSIPORT (or a
filter on passthough requests) I haven’t found a way around this.

Any ideas on how to let a miniport keep processing multiple
LU’s all the
time? This has to work under NT4/W2K/WinXP. I would prefer
not to have a
device on the side of the minport processing IOCTL’s, as the
information
coming down from the app sometimes effects SRB completion, so
I need to be
in a valid miniport context.

Thanks.

  • Jan

You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

5

>You have the source for classpnp in the ddk, look up the usage of

ErrorCount in the fdo extension. Once this monotonically incrementing
value hits 4, multiple requests per lu are barred, once it hits 8
disconnect is barred. THIS VALUE NEVER GOES DOWN. IMHO this is a HUGE
HIDEOUS BUG-BUG in classpnp. Once you check into this particular roach
motel you can’t check out.

I read the MS document suggested by Niraj, and yes that is just hideous.
Seems like the more I know about things the less l like it.

. A better approach is to turn the
SRB_FLAGS_DISABLE_DISCONNECT and perhaps the
SRB_FLAGS_DISABLE_SYNCH_TRANSFER bits, (and other related bits, see the
source code,) off in the srbflags by implementing a filter driver above
scsiport.

This is the current plan. I was just in disbelief for a while about how
silly the class and scsiport drivers were.

I was pondering if the device object that must be hanging off the miniport
driver object could just have a filter function inserted in the dispatch
routine slot for IRP_MJ_INTERNAL_DEVICE_CONTROL. DeviceTree suggests this
might be the case. Guess I’ll have a fun night with the debugger…

Consider the case where you
hot plug a disk or adjust the scsi cables on an external storage unit.
The bus gets a ‘little upset’ for a while: it has a transitory failure.
Meanwhile the stupid error counter gets to eight, and from now on until
you reboot the machine, that scsi bus is operating in what we, when we
hit this bug, quaintly termed ‘sludge mode’. Golly, how difficult would
it be to implement a second counter, the SequentialGoodCounter, that
would reset ErrorCount to zero when it hits it’s threshold?

Seems pretty clear it’s a major problem. Makes you wonder how MS does
testing. I always thought, “abuse the hardware” was required testing for
drivers.

  • Jan

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

6

We told you that this would happen; read past posts about what is wrong
with Antons method of hacking a miniport to do what it is not suppose to
do!

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Monday, December 17, 2001 4:21 PM
To: NT Developers Interest List
Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

I’m working on a specialized scsi miniport and am trying to resolve a
little issue.

It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
the
miniport for execution, SCSIPORT stops issuing SRB’s to ALL other LU’s.
SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver when they
retry after the initial SRB returns an error. Is this correct, or should
I
keep hunting for what’s really happening?

My real problem is I have this user mode app that is constantly chatting

with the miniport through passthrough requests, to a private target id.
When a normal device get’s an error, the class drivers retry the request

with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no longer

chat with the driver about what’s happening.

I’ve even moved my private targets to a different PathId, with no
apparent
change. It also seem like SRB_IO_CONTROL’s also get held when the SRB
with
SRB_FLAGS_DISABLE_DISCONNECT is being processed??

It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in
the
SRB’s to my private target, but without a driver above SCSIPORT (or a
filter on passthough requests) I haven’t found a way around this.

Any ideas on how to let a miniport keep processing multiple LU’s all the

time? This has to work under NT4/W2K/WinXP. I would prefer not to have a

device on the side of the minport processing IOCTL’s, as the information

coming down from the app sometimes effects SRB completion, so I need to
be
in a valid miniport context.

Thanks.

  • Jan

You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

7

It is amazing… No one wanted to listen to us Max :slight_smile:

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, December 17, 2001 4:59 PM
To: NT Developers Interest List
Subject: [ntdev] Re: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
the miniport for execution, SCSIPORT stops issuing SRB’s to ALL other
LU’s.

Exactly so. This is very logical.

No-disconnect request occupies the physical SCSI bus till completion. No
other request can be initiated on the SCSI bus while no-disconnect is
active. Since MS’s miniports are assumed to immediately start the
physical SCSI operation in their HwStartIo, then SCSIPORT has this
heuristics.

change. It also seem like SRB_IO_CONTROL’s also get held when the SRB
with SRB_FLAGS_DISABLE_DISCONNECT is being processed??

Any SRBs are held.

It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in

the SRB’s to my private target

You will need to call NextRequest notification to retrieve your control
SRB in your miniport. But what if the next SRB to StartIo will be not a
control one, but a real one?

Any ideas on how to let a miniport keep processing multiple LU’s all
the time? This has to work under NT4/W2K/WinXP.

Our SCSI port library can help.

Max

You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

8

Jamey, if you do not know an answer, do not bother to post

----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Tuesday, December 11, 2001 7:36 AM
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

> We told you that this would happen; read past posts about what is wrong
> with Antons method of hacking a miniport to do what it is not suppose to
> do!
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> Sent: Monday, December 17, 2001 4:21 PM
> To: NT Developers Interest List
> Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
>
>
> I’m working on a specialized scsi miniport and am trying to resolve a
> little issue.
>
> It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
> the
> miniport for execution, SCSIPORT stops issuing SRB’s to ALL other LU’s.
> SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver when they
> retry after the initial SRB returns an error. Is this correct, or should
> I
> keep hunting for what’s really happening?
>
> My real problem is I have this user mode app that is constantly chatting
>
> with the miniport through passthrough requests, to a private target id.
> When a normal device get’s an error, the class drivers retry the request
>
> with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no longer
>
> chat with the driver about what’s happening.
>
> I’ve even moved my private targets to a different PathId, with no
> apparent
> change. It also seem like SRB_IO_CONTROL’s also get held when the SRB
> with
> SRB_FLAGS_DISABLE_DISCONNECT is being processed??
>
> It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in
> the
> SRB’s to my private target, but without a driver above SCSIPORT (or a
> filter on passthough requests) I haven’t found a way around this.
>
> Any ideas on how to let a miniport keep processing multiple LU’s all the
>
> time? This has to work under NT4/W2K/WinXP. I would prefer not to have a
>
> device on the side of the minport processing IOCTL’s, as the information
>
> coming down from the app sometimes effects SRB completion, so I need to
> be
> in a valid miniport context.
>
> Thanks.
>
> - Jan
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@setengineering.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

9

We have explained the issue in the past. I did tell the poster to review
past messages. There is no reason to go through the huge explanation
again.

Have a bad night?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gera Kazakov
Sent: Tuesday, December 18, 2001 7:06 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

Jamey, if you do not know an answer, do not bother to post

----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Tuesday, December 11, 2001 7:36 AM
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

> We told you that this would happen; read past posts about what is
> wrong with Antons method of hacking a miniport to do what it is not
> suppose to do!
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> Sent: Monday, December 17, 2001 4:21 PM
> To: NT Developers Interest List
> Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
>
>
> I’m working on a specialized scsi miniport and am trying to resolve a
> little issue.
>
> It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
> the miniport for execution, SCSIPORT stops issuing SRB’s to ALL other
> LU’s. SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver
> when they retry after the initial SRB returns an error. Is this
> correct, or should I
> keep hunting for what’s really happening?
>
> My real problem is I have this user mode app that is constantly
> chatting
>
> with the miniport through passthrough requests, to a private target
> id. When a normal device get’s an error, the class drivers retry the
> request
>
> with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no
> longer
>
> chat with the driver about what’s happening.
>
> I’ve even moved my private targets to a different PathId, with no
> apparent change. It also seem like SRB_IO_CONTROL’s also get held when

> the SRB with
> SRB_FLAGS_DISABLE_DISCONNECT is being processed??
>
> It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in

> the SRB’s to my private target, but without a driver above SCSIPORT
> (or a filter on passthough requests) I haven’t found a way around
> this.
>
> Any ideas on how to let a miniport keep processing multiple LU’s all
> the
>
> time? This has to work under NT4/W2K/WinXP. I would prefer not to have

> a
>
> device on the side of the minport processing IOCTL’s, as the
> information
>
> coming down from the app sometimes effects SRB completion, so I need
> to be in a valid miniport context.
>
> Thanks.
>
> - Jan
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@setengineering.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

10

BTW: I am having a bad morning; sorry if my short post was offensive.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gera Kazakov
Sent: Tuesday, December 18, 2001 7:06 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

Jamey, if you do not know an answer, do not bother to post

----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Tuesday, December 11, 2001 7:36 AM
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

> We told you that this would happen; read past posts about what is
> wrong with Antons method of hacking a miniport to do what it is not
> suppose to do!
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> Sent: Monday, December 17, 2001 4:21 PM
> To: NT Developers Interest List
> Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
>
>
> I’m working on a specialized scsi miniport and am trying to resolve a
> little issue.
>
> It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
> the miniport for execution, SCSIPORT stops issuing SRB’s to ALL other
> LU’s. SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver
> when they retry after the initial SRB returns an error. Is this
> correct, or should I
> keep hunting for what’s really happening?
>
> My real problem is I have this user mode app that is constantly
> chatting
>
> with the miniport through passthrough requests, to a private target
> id. When a normal device get’s an error, the class drivers retry the
> request
>
> with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no
> longer
>
> chat with the driver about what’s happening.
>
> I’ve even moved my private targets to a different PathId, with no
> apparent change. It also seem like SRB_IO_CONTROL’s also get held when

> the SRB with
> SRB_FLAGS_DISABLE_DISCONNECT is being processed??
>
> It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in

> the SRB’s to my private target, but without a driver above SCSIPORT
> (or a filter on passthough requests) I haven’t found a way around
> this.
>
> Any ideas on how to let a miniport keep processing multiple LU’s all
> the
>
> time? This has to work under NT4/W2K/WinXP. I would prefer not to have

> a
>
> device on the side of the minport processing IOCTL’s, as the
> information
>
> coming down from the app sometimes effects SRB completion, so I need
> to be in a valid miniport context.
>
> Thanks.
>
> - Jan
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@setengineering.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

11

Or he needs a cup of coffeee, or he thinks he’s the List cop, or he’s just
an arrogant son of a bitch.

Gary G. Little
Broadband Storage, Inc.
xxxxx@broadstor.com
xxxxx@inland.net
(949) 7372731

-----Original Message-----
From: Jamey Kirby [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, December 11, 2001 7:23 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

We have explained the issue in the past. I did tell the poster to review
past messages. There is no reason to go through the huge explanation
again.

Have a bad night?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gera Kazakov
Sent: Tuesday, December 18, 2001 7:06 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

Jamey, if you do not know an answer, do not bother to post

----- Original Message -----
From: “Jamey Kirby”
To: “NT Developers Interest List”
Sent: Tuesday, December 11, 2001 7:36 AM
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

> We told you that this would happen; read past posts about what is
> wrong with Antons method of hacking a miniport to do what it is not
> suppose to do!
>
> Jamey
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> Sent: Monday, December 17, 2001 4:21 PM
> To: NT Developers Interest List
> Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
>
>
> I’m working on a specialized scsi miniport and am trying to resolve a
> little issue.
>
> It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
> the miniport for execution, SCSIPORT stops issuing SRB’s to ALL other
> LU’s. SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver
> when they retry after the initial SRB returns an error. Is this
> correct, or should I
> keep hunting for what’s really happening?
>
> My real problem is I have this user mode app that is constantly
> chatting
>
> with the miniport through passthrough requests, to a private target
> id. When a normal device get’s an error, the class drivers retry the
> request
>
> with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no
> longer
>
> chat with the driver about what’s happening.
>
> I’ve even moved my private targets to a different PathId, with no
> apparent change. It also seem like SRB_IO_CONTROL’s also get held when

> the SRB with
> SRB_FLAGS_DISABLE_DISCONNECT is being processed??
>
> It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in

> the SRB’s to my private target, but without a driver above SCSIPORT
> (or a filter on passthough requests) I haven’t found a way around
> this.
>
> Any ideas on how to let a miniport keep processing multiple LU’s all
> the
>
> time? This has to work under NT4/W2K/WinXP. I would prefer not to have

> a
>
> device on the side of the minport processing IOCTL’s, as the
> information
>
> coming down from the app sometimes effects SRB completion, so I need
> to be in a valid miniport context.
>
> Thanks.
>
> - Jan
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@setengineering.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: xxxxx@broadstor.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

12

This is a question with NO answer except “SCSIPORT is such, live with it - or do not use SCSIPORT at all”.

Max

----- Original Message -----
From: “Gera Kazakov”
To: “NT Developers Interest List”
Sent: Tuesday, December 18, 2001 6:05 PM
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

> Jamey, if you do not know an answer, do not bother to post
>
> ----- Original Message -----
> From: “Jamey Kirby”
> To: “NT Developers Interest List”
> Sent: Tuesday, December 11, 2001 7:36 AM
> Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
>
>
> > We told you that this would happen; read past posts about what is wrong
> > with Antons method of hacking a miniport to do what it is not suppose to
> > do!
> >
> > Jamey
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> > Sent: Monday, December 17, 2001 4:21 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
> >
> >
> > I’m working on a specialized scsi miniport and am trying to resolve a
> > little issue.
> >
> > It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
> > the
> > miniport for execution, SCSIPORT stops issuing SRB’s to ALL other LU’s.
> > SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver when they
> > retry after the initial SRB returns an error. Is this correct, or should
> > I
> > keep hunting for what’s really happening?
> >
> > My real problem is I have this user mode app that is constantly chatting
> >
> > with the miniport through passthrough requests, to a private target id.
> > When a normal device get’s an error, the class drivers retry the request
> >
> > with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no longer
> >
> > chat with the driver about what’s happening.
> >
> > I’ve even moved my private targets to a different PathId, with no
> > apparent
> > change. It also seem like SRB_IO_CONTROL’s also get held when the SRB
> > with
> > SRB_FLAGS_DISABLE_DISCONNECT is being processed??
> >
> > It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in
> > the
> > SRB’s to my private target, but without a driver above SCSIPORT (or a
> > filter on passthough requests) I haven’t found a way around this.
> >
> > Any ideas on how to let a miniport keep processing multiple LU’s all the
> >
> > time? This has to work under NT4/W2K/WinXP. I would prefer not to have a
> >
> > device on the side of the minport processing IOCTL’s, as the information
> >
> > coming down from the app sometimes effects SRB completion, so I need to
> > be
> > in a valid miniport context.
> >
> > Thanks.
> >
> > - Jan
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@setengineering.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

13

Except that you can put a filter above scsiport and live with it by avoiding
the problem.

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Tuesday, December 18, 2001 11:29 AM
To: NT Developers Interest List
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

This is a question with NO answer except “SCSIPORT is such, live with it -
or do not use SCSIPORT at all”.

Max

----- Original Message -----
From: “Gera Kazakov”
To: “NT Developers Interest List”
Sent: Tuesday, December 18, 2001 6:05 PM
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

> Jamey, if you do not know an answer, do not bother to post
>
> ----- Original Message -----
> From: “Jamey Kirby”
> To: “NT Developers Interest List”
> Sent: Tuesday, December 11, 2001 7:36 AM
> Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
>
>
> > We told you that this would happen; read past posts about what is
> > wrong with Antons method of hacking a miniport to do what it is not
> > suppose to do!
> >
> > Jamey
> >
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> > Sent: Monday, December 17, 2001 4:21 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
> >
> >
> > I’m working on a specialized scsi miniport and am trying to resolve
> > a little issue.
> >
> > It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent
> > to the miniport for execution, SCSIPORT stops issuing SRB’s to ALL
> > other LU’s. SRB_FLAGS_DISABLE_DISCONNECT often is set by the class
> > driver when they retry after the initial SRB returns an error. Is
> > this correct, or should I
> > keep hunting for what’s really happening?
> >
> > My real problem is I have this user mode app that is constantly
> > chatting
> >
> > with the miniport through passthrough requests, to a private target
> > id. When a normal device get’s an error, the class drivers retry the
> > request
> >
> > with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no
> > longer
> >
> > chat with the driver about what’s happening.
> >
> > I’ve even moved my private targets to a different PathId, with no
> > apparent change. It also seem like SRB_IO_CONTROL’s also get held
> > when the SRB with
> > SRB_FLAGS_DISABLE_DISCONNECT is being processed??
> >
> > It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE
> > in the SRB’s to my private target, but without a driver above
> > SCSIPORT (or a filter on passthough requests) I haven’t found a way
> > around this.
> >
> > Any ideas on how to let a miniport keep processing multiple LU’s all
> > the
> >
> > time? This has to work under NT4/W2K/WinXP. I would prefer not to
> > have a
> >
> > device on the side of the minport processing IOCTL’s, as the
> > information
> >
> > coming down from the app sometimes effects SRB completion, so I need
> > to be in a valid miniport context.
> >
> > Thanks.
> >
> > - Jan
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@setengineering.com To unsubscribe send a blank email to
> > leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>

—
You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

14

Accordingly to Q263939, this ‘feature’ belongs to classpnp.sys and disk.sys,
not just to scsiport. Don’t you expect to face this problem even if you talk
directly to classpnp/disk from, say, your own home grown port?

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Tuesday, December 18, 2001 9:29 AM
Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?

> This is a question with NO answer except “SCSIPORT is such, live with it - or do not use SCSIPORT at all”.
>
> Max
>
> ----- Original Message -----
> From: “Gera Kazakov”
> To: “NT Developers Interest List”
> Sent: Tuesday, December 18, 2001 6:05 PM
> Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
>
>
> > Jamey, if you do not know an answer, do not bother to post
> >
> > ----- Original Message -----
> > From: “Jamey Kirby”
> > To: “NT Developers Interest List”
> > Sent: Tuesday, December 11, 2001 7:36 AM
> > Subject: [ntdev] RE: SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
> >
> >
> > > We told you that this would happen; read past posts about what is wrong
> > > with Antons method of hacking a miniport to do what it is not suppose to
> > > do!
> > >
> > > Jamey
> > >
> > >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> > > Sent: Monday, December 17, 2001 4:21 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] SRB_FLAGS_DISABLE_DISCONNECT holds ALL LU’s?
> > >
> > >
> > > I’m working on a specialized scsi miniport and am trying to resolve a
> > > little issue.
> > >
> > > It seems like when a SRB with SRB_FLAGS_DISABLE_DISCONNECT is sent to
> > > the
> > > miniport for execution, SCSIPORT stops issuing SRB’s to ALL other LU’s.
> > > SRB_FLAGS_DISABLE_DISCONNECT often is set by the class driver when they
> > > retry after the initial SRB returns an error. Is this correct, or should
> > > I
> > > keep hunting for what’s really happening?
> > >
> > > My real problem is I have this user mode app that is constantly chatting
> > >
> > > with the miniport through passthrough requests, to a private target id.
> > > When a normal device get’s an error, the class drivers retry the request
> > >
> > > with the SRB_FLAGS_DISABLE_DISCONNECT flag set, and my app can no longer
> > >
> > > chat with the driver about what’s happening.
> > >
> > > I’ve even moved my private targets to a different PathId, with no
> > > apparent
> > > change. It also seem like SRB_IO_CONTROL’s also get held when the SRB
> > > with
> > > SRB_FLAGS_DISABLE_DISCONNECT is being processed??
> > >
> > > It looks like I could potentially set SRB_FLAGS_BYPASS_FROZEN_QUEUE in
> > > the
> > > SRB’s to my private target, but without a driver above SCSIPORT (or a
> > > filter on passthough requests) I haven’t found a way around this.
> > >
> > > Any ideas on how to let a miniport keep processing multiple LU’s all the
> > >
> > > time? This has to work under NT4/W2K/WinXP. I would prefer not to have a
> > >
> > > device on the side of the minport processing IOCTL’s, as the information
> > >
> > > coming down from the app sometimes effects SRB completion, so I need to
> > > be
> > > in a valid miniport context.
> > >
> > > Thanks.
> > >
> > > - Jan
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com To
> > > unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@setengineering.com
> > > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@setengineering.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

15

>This is a question with NO answer except "SCSIPORT is such, live with it -

or do not use SCSIPORT at all".

Filtering out SRB_FLAGS_DISABLE_DISCONNECT seems to do the trick, so at
the moment don’t see why a miniport will not work.

  • Jan

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com