> Hello,
it seems that Microsoft not only removed the 1394b support but also the
irm support in xp sp2 (the contender bit is not set).
has anyone similar experince?
Uwe Kirst
Has this really been confirmed. This is something that I need to know
about and I can’t find any information on it. If anyone knows an
official source of information I would appreciate hearing about it. I
will also be doing my own sp2 test in the next day or 2.
I have to look after a proprietary device that connects to a PC
through 1394a. I am fortunate because I have the freedom of assuming
that the PC is dedicated to our product only and can essentially do
anything I want on the PC. If this problem is confirmed can I get
around it in the short term by replacing xp-sp2 1394 drivers with
earlier drivers (I’ve used this procedure in the past to get around
the Win2000 sp1 to sp2 issue described recently until the problem was
diagnosed and my driver fixed)?
However, it is very easy for a device to implement IRM. The requirements are
to expose the registers for the remaining bandwidth and the allocated
channels and to supervise the lock operations on them. You also need to
reset them to the original values when a bus reset is detected. That’s
about all there is to it…
Implementing IRM is not quite as trivial as mentioned here. It
requires updating the firmware running on the product. Creating the
update is a reasonably expensive task for a small company and
distributing to everyone in the field and getting them to update their
units is not a proposition I look forward to.
Robert Newton
Robert Newton wrote:
I have to look after a proprietary device that connects to a PC
through 1394a. I am fortunate because I have the freedom of assuming
that the PC is dedicated to our product only and can essentially do
anything I want on the PC. If this problem is confirmed can I get
around it in the short term by replacing xp-sp2 1394 drivers with
earlier drivers (I’ve used this procedure in the past to get around
the Win2000 sp1 to sp2 issue described recently until the problem was
diagnosed and my driver fixed)?
yes, please look at:
http://www.rme-audio.com/english/techinfo/fw800sp2.htm
Uwe
From: uwe kirst
>Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: Re: [ntdev] 1394 +sp2
>Date: Fri, 20 Aug 2004 17:29:48 +0200
>
>Hello,
>I’m now thinking wether to implement or not a IRM in my firewire
>device.
>
>If I would implement everything that is needed for an IRM (Bandwidth
>available register, Channels available register, Topologiy map,
>Speed map and so on)
>would XP SP2 in that case use all the information it gets from my
>IRM?
>I mean, would for example report XP the bus speed it gets from my
>IRM? (GetMaxSpeedBetweenDevice; GetLocalHostInfo6) instead of
>looking at it’s own Self ID packets?
>I’m asking this explicit because that would be a workaround for the
>S100 limit of SP2 if the speed map of my IRM shows speed S400
>instead of S800.
>(A S400 speed limit is much more exceptable than a S100 limit)
>
>Uwe Kirst
>
[snip]
I would doubt it, because whoever will be the bus manager (you) will create the topology and speed maps based on the arrival of self ID packets from all the nodes. Since the MS node PHY reports 100 Mbps…outta luck AFAIK. The PHY link speed would need to change on the MS node for the self ID packets to change and hence for the speed map to change (I’m guessing, away from the specs now).
Infuriating…isn’t it? Especially the way they slid the IRM change in after RC2 (build 2149). SP2 RC2 build 2149 did not have the IRM issue, but I guess it did have the s800->s100 issue.
Philip Lukidis
Free yourself from those irritating pop-up ads with MSN Premium: Join now and get the first two months FREE*
See inline replies.
thanks,
Philip Lukidis
----- Original Message -----
From: “Robert Newton”
To: “Windows System Software Devs Interest List”
Sent: Friday, August 20, 2004 12:55 PM
Subject: Re[2]: [ntdev] 1394 +sp2
> > Hello,
> >
> > it seems that Microsoft not only removed the 1394b support but also the
> > irm support in xp sp2 (the contender bit is not set).
> > has anyone similar experince?
> >
> > Uwe Kirst
> >
>
> Has this really been confirmed. This is something that I need to know
> about and I can’t find any information on it. If anyone knows an
> official source of information I would appreciate hearing about it. I
> will also be doing my own sp2 test in the next day or 2.
>
Over here I can confirm that the contender bit is not set in the self ID
packets from my OHCI 1394 card, whereas they were previously under SP1a.
The config rom does have the irmc (and bmc) bit set, funnily enough! Given
what has happened to the 1394b speed map, I wouldn’t expect there to be any
official sources of information for this.
> I have to look after a proprietary device that connects to a PC
> through 1394a. I am fortunate because I have the freedom of assuming
> that the PC is dedicated to our product only and can essentially do
> anything I want on the PC. If this problem is confirmed can I get
> around it in the short term by replacing xp-sp2 1394 drivers with
> earlier drivers (I’ve used this procedure in the past to get around
> the Win2000 sp1 to sp2 issue described recently until the problem was
> diagnosed and my driver fixed)?
>
I’ve tried using the SP1a drivers on an RTM 2180 SP2 machine (sp1a->RTM
2180), and they work “fine”, in that the host node can become the IRM. Of
course, I don’t know what the deeper effects of this replacement may be. I
don’t have the same luxury of a dedicated machine.
> > However, it is very easy for a device to implement IRM. The requirements
are
> > to expose the registers for the remaining bandwidth and the allocated
> > channels and to supervise the lock operations on them. You also need to
> > reset them to the original values when a bus reset is detected. That’s
> > about all there is to it…
>
> Implementing IRM is not quite as trivial as mentioned here. It
> requires updating the firmware running on the product. Creating the
> update is a reasonably expensive task for a small company and
> distributing to everyone in the field and getting them to update their
> units is not a proposition I look forward to.
>
Yes, I alluded to that in one of my previous replies. But I really have no
choice in the matter. 
>
> Robert Newton
>
thanks,
Philip Lukidis
The old (Win98’s) 1394 stack worked as the following:
- if the local host was elected IRM - then allocate bandwidth/channel
operations were passed by 1394bus down to the port driver, which usually
implemented them using the hardware registers.
- otherwise, 1394bus remoted the allocate bandwidth/channel operations as
lock requests to the remote IRM. The logic was very similar to the XP’s
InterlockedOr routine.
Possibly the second path is still working in XP SP2.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Friday, August 20, 2004 7:29 PM
Subject: Re: [ntdev] 1394 +sp2
> Hello,
> I’m now thinking wether to implement or not a IRM in my firewire device.
>
> If I would implement everything that is needed for an IRM (Bandwidth
> available register, Channels available register, Topologiy map, Speed
> map and so on)
> would XP SP2 in that case use all the information it gets from my IRM?
> I mean, would for example report XP the bus speed it gets from my IRM?
> (GetMaxSpeedBetweenDevice; GetLocalHostInfo6) instead of looking at it’s
> own Self ID packets?
> I’m asking this explicit because that would be a workaround for the S100
> limit of SP2 if the speed map of my IRM shows speed S400 instead of S800.
> (A S400 speed limit is much more exceptable than a S100 limit)
>
> Uwe Kirst
>
>
> Maxim S. Shatskih wrote:
>
> >>You are almost right, that will prevent products that are not IRM-capable
> >>from functioning, but only if there are no other products on the bus that
> >>are IRM-capable. But you knew that 
> >>
> >>
> >
> >The miniDV camcorders (like Canon ZR) were already IRM-capable as early as
in
> >1999.
> >
> >Maxim Shatskih, Windows DDK MVP
> >StorageCraft Corporation
> >xxxxx@storagecraft.com
> >http://www.storagecraft.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@gmx.de
> >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
Hello,
ok, I made a mistake, I mixed up Busmanager and IRM. But anyway, the
hardware will allways report the correct speed, because it’s a
hw-function. Self ID-Packets are created by hardware. Therefore a MS
note will report the correct speed, even in case of S800. The problem is
that MS interprets S800 as S100, although Self-ID-packet 8 correctly
specifies the speed with the three-bit code 0x3 = S800. Packet 8 had
been already defined in the ‘1394a supplement’, and is therefore not an
innovation of 1394b.
Concerning the IRM issue I think you can just ignore the fact that the
IRM bit is not set in the Self-ID packet. Thats what we are doing at the
moment. Seems to work.
At least windows reports the allocated resources as expected (It seems
that they have has just forgotten to set the IRM Bit, thats all).
Philip Lukidis wrote:
I would doubt it, because whoever will be the bus manager (you) will
create the topology and speed maps based on the arrival of self ID
packets from all the nodes. Since the MS node PHY reports 100
Mbps…outta luck AFAIK. The PHY link speed would need to change on
the MS node for the self ID packets to change and hence for the speed
map to change (I’m guessing, away from the specs now).
Infuriating…isn’t it? Especially the way they slid the IRM change
in after RC2 (build 2149). SP2 RC2 build 2149 did not have the IRM
issue, but I guess it did have the s800->s100 issue.
Yes thats thru.
Philip Lukidis
Uwe Kirst
Maxim S. Shatskih wrote:
The old (Win98’s) 1394 stack worked as the following:
- if the local host was elected IRM - then allocate bandwidth/channel
operations were passed by 1394bus down to the port driver, which usually
implemented them using the hardware registers.
- otherwise, 1394bus remoted the allocate bandwidth/channel operations as
lock requests to the remote IRM. The logic was very similar to the XP’s
InterlockedOr routine.
Possibly the second path is still working in XP SP2.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Hello,
and what about the Bus manager? Will Windows use the speed map of my
device and ignore the speed coding within it’s own self ID packets (At
least for the isochronouse transfers)?
Uwe Kirst
> and what about the Bus manager? Will Windows use the speed map of my
device and ignore the speed coding within it’s own self ID packets (At
least for the isochronouse transfers)?
From what I know, 1394bus have built the speed/topology maps in software, based
on the information from selfID packets gathered between “bus reset” and “selfID
complete” interrupts from the hardware.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Monday, August 23, 2004 3:43 AM
Subject: Re: [ntdev] 1394 +sp2
> Hello,
> ok, I made a mistake, I mixed up Busmanager and IRM. But anyway, the
> hardware will allways report the correct speed, because it’s a
> hw-function. Self ID-Packets are created by hardware. Therefore a MS
> note will report the correct speed, even in case of S800. The problem is
> that MS interprets S800 as S100, although Self-ID-packet 8 correctly
> specifies the speed with the three-bit code 0x3 = S800. Packet 8 had
> been already defined in the ‘1394a supplement’, and is therefore not an
> innovation of 1394b.
>
Oh, sorry, I misunderstood and thought the self ID packets actually sent
from the host indicated a PHY speed of 100 Mbps. I guess that the PHY
register 3 max_speed field is read only (as with my hardware) meaning that
self ID packets always report S800. Out of curiosity, what does the
link_spd field of the bus_info_block report? This could be smaller than the
PHY reported speed.
> Concerning the IRM issue I think you can just ignore the fact that the
> IRM bit is not set in the Self-ID packet. Thats what we are doing at the
> moment. Seems to work.
> At least windows reports the allocated resources as expected (It seems
> that they have has just forgotten to set the IRM Bit, thats all).
>
I’m not sure what you mean and which scenario you are talking about. Could
you please elaborate?
[snip]
thanks,
Philip Lukidis
FIRST off, I apologize to the group if this message was received twice. I
have been having trouble posting to NTDEV (a gap time of ~1 day!), probably
because my OSR email and NTDEV email are different. I have re-registered on
OSROnline with my NTDEV email. Apologies to the group for using a hotmail
email, I just don’t want my company email harvested and to receive some
SPAM.
Original message follows.
my apologies for message duplication,
Philip Lukidis
----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Monday, August 23, 2004 3:43 AM
Subject: Re: [ntdev] 1394 +sp2
> Hello,
> ok, I made a mistake, I mixed up Busmanager and IRM. But anyway, the
> hardware will allways report the correct speed, because it’s a
> hw-function. Self ID-Packets are created by hardware. Therefore a MS
> note will report the correct speed, even in case of S800. The problem is
> that MS interprets S800 as S100, although Self-ID-packet 8 correctly
> specifies the speed with the three-bit code 0x3 = S800. Packet 8 had
> been already defined in the ‘1394a supplement’, and is therefore not an
> innovation of 1394b.
>
Oh, sorry, I misunderstood and thought the self ID packets actually sent
from the host indicated a PHY speed of 100 Mbps. I guess that the PHY
register 3 max_speed field is read only (as with my hardware) meaning that
self ID packets always report S800. Out of curiosity, what does the
link_spd field of the bus_info_block report? This could be smaller than the
PHY reported speed.
> Concerning the IRM issue I think you can just ignore the fact that the
> IRM bit is not set in the Self-ID packet. Thats what we are doing at the
> moment. Seems to work.
> At least windows reports the allocated resources as expected (It seems
> that they have has just forgotten to set the IRM Bit, thats all).
>
I’m not sure what you mean and which scenario you are talking about. Could
you please elaborate?
[snip]
thanks,
Philip Lukidis
Philip Lukidis wrote:
>Concerning the IRM issue I think you can just ignore the fact that the
>IRM bit is not set in the Self-ID packet. Thats what we are doing at the
>moment. Seems to work.
>At least windows reports the allocated resources as expected (It seems
>that they have has just forgotten to set the IRM Bit, thats all).
>
>
>
I’m not sure what you mean and which scenario you are talking about. Could
you please elaborate?
Our firewire device tries to allocate isoch resources (channel +
bandwith) for the direction device to MS node (resources for the other
direction are allocated by the MS node). Because the contender bit is
not set on any node, we are simply using the root node (the MS node).
That works, because MS seems to use it too.
Uwe Kirst
----- Original Message -----
From: “uwe kirst”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, August 24, 2004 4:23 AM
Subject: Re: [ntdev] 1394 +sp2
> Philip Lukidis wrote:
>
> >>Concerning the IRM issue I think you can just ignore the fact that the
> >>IRM bit is not set in the Self-ID packet. Thats what we are doing at the
> >>moment. Seems to work.
> >>At least windows reports the allocated resources as expected (It seems
> >>that they have has just forgotten to set the IRM Bit, thats all).
> >>
> >>
> >>
> >I’m not sure what you mean and which scenario you are talking about.
Could
> >you please elaborate?
> >
> >
> Our firewire device tries to allocate isoch resources (channel +
> bandwith) for the direction device to MS node (resources for the other
> direction are allocated by the MS node). Because the contender bit is
> not set on any node, we are simply using the root node (the MS node).
> That works, because MS seems to use it too.
>
> Uwe Kirst
>
>
Thank you kindly for your help.
Philip Lukidis
Sorry for the late note on this subject but I have been away for the
last week.
Our device (1394a) functions correctly with XP-sp2. It allocates and
uses isoch resources (bandwidth, channels etc) and our device does not
implement IRM so Windows must be continuing to implement this.
I don’t have a bus analyzer and so have never directly observed the
contender bit and can’t comment on it. I did, however, note previously
that windows would not work to ensure that it became root node when
necessary (root
needs to be cycle master for isoch communication) as the 1394a spec
says it should. I have always had
to manually, on bus reset, check the capabilities of the root node and
do a force root and bus reset if the previous reset ended up with an
incapable node as root (easy to happen if a repeater is put in the cable).
Any others have experience with this?
Robert Newton
Hello,
are you sure that your device allocates the resources (it could also be
that your windows driver allocates them instead)?
Uwe
Robert Newton wrote:
Sorry for the late note on this subject but I have been away for the
last week.
Our device (1394a) functions correctly with XP-sp2. It allocates and
uses isoch resources (bandwidth, channels etc) and our device does not
implement IRM so Windows must be continuing to implement this.
I don’t have a bus analyzer and so have never directly observed the
contender bit and can’t comment on it. I did, however, note previously
that windows would not work to ensure that it became root node when
necessary (root
needs to be cycle master for isoch communication) as the 1394a spec
says it should. I have always had
to manually, on bus reset, check the capabilities of the root node and
do a force root and bus reset if the previous reset ended up with an
incapable node as root (easy to happen if a repeater is put in the cable).
Any others have experience with this?
Robert Newton
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@gmx.de
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Hello,
are you sure that your device allocates the resources (it could also be
that your windows driver allocates them instead)?
Uwe
Ahhh! In fact the driver allocates the resources for the device. Are
you saying that that the 1394 drivers do not implement IRM registers
accessible from the bus?
Robert Newton
Robert Newton wrote:
>Hello,
>are you sure that your device allocates the resources (it could also be
>that your windows driver allocates them instead)?
>Uwe
>
>
Ahhh! In fact the driver allocates the resources for the device. Are
you saying that that the 1394 drivers do not implement IRM registers
accessible from the bus?
Robert Newton
It seems that they implement the IRM registers though the contender bit
says that they are not implemented. In fact the IRM registers are
implemented in hardware but Microsoft seems to use them to store the
resources allocated by drivers.
Another question: You mentioned that there are repeaters that claim for
root. Can you tell me a manufacturer and a model? I want to try it out.
Uwe Kirst
> Another question: You mentioned that there are repeaters that claim for
root. Can you tell me a manufacturer and a model? I want to try it out.
Uwe Kirst
I believe that it was the Orangelink repeater. However, I don’t think
it has anything to do with the repeater itself.
On initial bus reset
all nodes are
treated equally in the establishment of bus topology. Root is
generally determined by the bus layout with nodes near the middle of
the layout most likely to become root.
A particular node can be forced to become root through a PHY
configuration packet that sets the node’s force root bit. This causes
that node to delay its participation in the self id process. The added
delay works to ensure that a particular node becomes root (I don’t
know whether you can force a repeater to become root - why would you
want to?).
Following bus reset, the IRM (or bus manager if present) is supposed
to examine the capabilities of the root node. If the node is not cycle
master capable (necessary for isoch communication) the IRM (or bus
manager) will examine the capabilities of all other nodes and,
selecting a cycle master capable node, set that nodes force-root bit
and follow this with another bus reset.
I found that I had to do this work manually in my driver to ensure
that the PC became root instead of a repeater in the cable. This was
from the early days of Win2K. I don’t know if this still holds true
with the latest 1394 drivers.
Robert Newton