I think when powered off, the pc controller has enough juice from the
cabling to propagate the signal down its other ports. I have also seen
mobos where the 1394 was wired directly to the power plane and were
active even when the PC was off (funny enough, the fan still ran too).
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto Moreira
Sent: Saturday, March 05, 2005 5:41 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] “Flagging” an IRP between filter drivers
Even when the machine is turned off ? My FireZip comes off a
cable in my Dell machine, and if I boot my Athlon with the Dell
turned off, the FireZip happily comes alive and I get a nice
drive letter for it. In fact, it seems to be “the early bird
gets the worm” rule, whichever machine boots first gets the
drive.
Alberto.
----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”
Sent: Saturday, March 05, 2005 1:29 PM
Subject: RE: [ntdev] “Flagging” an IRP between filter drivers
Yes, this is expected. Firewire is a topology bus. The
controller is
just a node on the bus. It can have cycles on it as well :).
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alberto
Moreira
Sent: Saturday, March 05, 2005 6:20 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] “Flagging” an IRP between filter drivers
Guys,
I bumped into a peculiar piece of functionality, well, it may be
old hat for you Firewire dudes, but to me it came as a surprise.
I have an HP Athlon 3400 machine and a Dell 500Mhz connected
through a Firewire cable. On the Dell machine, I have a FireZip
Drive connected to another port on the same 1394 card. Well, my
Athlon machine can see the Firewire Zip drive in the Dell
system: Device Manager lists it, and if the wind blows in the
right direction I can even get the Athlon to give it a drive
letter and actually access it . Is this normal behavior for the
Firewire hardware ?
Alberto.
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Saturday, March 05, 2005 9:05 AM
Subject: Re: [ntdev] “Flagging” an IRP between filter drivers
> FsContext2 is usually in use by lower-most DO in the stack.
> Filters must
> not use it.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Mark Roddy”
> To: “Windows System Software Devs Interest List”
>
> Sent: Saturday, March 05, 2005 4:17 PM
> Subject: RE: [ntdev] “Flagging” an IRP between filter drivers
>
>
>> Depending on the particular device stack you might be able to
>> use the irp
>> FileObject.FsContext2 field as a marker. There is no general
>> guarantee that
>> an IRP has a FileObject or that the FsContext2 field is not
>> in use by
>> somebody else. Otherwise you can build a communication path
>> between your two
>> filter drivers (for example using a private interface
>> obtained through
>> IRP_MN_QUERY_INTERFACE) and have a table maintained in the
>> top filter.
>>
>> =====================
>> Mark Roddy
>> Windows .NET/XP/2000 Consulting
>> Hollis Technology Solutions 603-321-1032
>> www.hollistech.com
>>
>> > -----Original Message-----
>> > From: xxxxx@lists.osr.com
>> > [mailto:xxxxx@lists.osr.com] On Behalf Of
>> > David Lavo
>> > Sent: Saturday, March 05, 2005 7:36 AM
>> > To: Windows System Software Devs Interest List
>> > Subject: [ntdev] “Flagging” an IRP between filter drivers
>> >
>> > Hi everyone,
>> >
>> > I’ve got both an upper and a lower filter installed on a
>> > particular class of devices for metering purposes. When an
>> > IRP travels the entire device stack it will be double
>> > counted; when an IRP is handled by the FDO, or when the
>> > lower
>> > filter sees a driver-generated IRP, then the IRP is counted
>> > only once (which is what I want).
>> >
>> > Is there any easy way to avoid this double counting of a
>> > full-stack IRP, perhaps by flagging the IRP in some way?
>> > (Such as the upper filter telling the lower filter “I’ve
>> > seen
>> > this IRP already”.) Or, is there any easy and approved way
>> > for the lower filter to examine all the stack locations to
>> > see if the upper filter has seen an IRP?
>> >
>> > Thanks for any help on this,
>> >
>> > David
>> >
>> > —
>> > Questions? First check the Kernel Driver FAQ at
>> > http://www.osronline.com/article.cfm?id=256
>> >
>> > You are currently subscribed to ntdev as:
>> > xxxxx@hollistech.com To unsubscribe send a blank email to
>> > xxxxx@lists.osr.com
>> >
>>
>>
>>
>>
>> —
>> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>>
>> You are currently subscribed to ntdev as:
>> xxxxx@storagecraft.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@windows.microsoft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com