1394Diag Example: Howto handle Surprise removal

Hello,
I’m writing a WDM driver for our firewire device and I’m wondering howto
handle surprise removal. In the 1394 diag example from the ddk all
resource are freed upon surprise removal. The code shown below is taken
from that example. Expecially this part of code seems not to work for
my device, because t1394_SubmitIrpSynch fails with error code 0xC0000022
(Access Denied). Sending an remove-resource-irp to the firewire bus
driver seems not possible after disconnecting the device.
Maybee someone could explain what is going wrong here.
Thanks
Uwe Kirst

// remove any isoch resource data
while (TRUE) {

KeAcquireSpinLock(&deviceExtension->IsochResourceSpinLock, &Irql);

if (!IsListEmpty(&deviceExtension->IsochResourceData)) {

PISOCH_RESOURCE_DATA IsochResourceData;

IsochResourceData =
(PISOCH_RESOURCE_DATA)RemoveHeadList(&deviceExtension->IsochResourceData);

KeReleaseSpinLock(&deviceExtension->IsochResourceSpinLock,
Irql);

TRACE(TL_TRACE, (“Surprise Removal: IsochResourceData =
0x%x\n”, IsochResourceData));

if (IsochResourceData) {

PIRB pIrb;
NTSTATUS ntStatus;
PIRP ResourceIrp;
CCHAR StackSize;

TRACE(TL_TRACE, (“Surprise Removal: Freeing hResource =
0x%x\n”, IsochResourceData->hResource));

StackSize =
deviceExtension->StackDeviceObject->StackSize + 1;
ResourceIrp = IoAllocateIrp(StackSize, FALSE);

if (ResourceIrp == NULL) {

TRACE(TL_ERROR, (“Failed to allocate ResourceIrp!\n”));
TRAP;
}
else {

pIrb = ExAllocatePool(NonPagedPool, sizeof(IRB));

if (!pIrb) {

IoFreeIrp(ResourceIrp);

TRACE(TL_ERROR, (“Failed to allocate pIrb!\n”));
TRAP;
}
else {

RtlZeroMemory (pIrb, sizeof (IRB));
pIrb->FunctionNumber = REQUEST_ISOCH_FREE_RESOURCES;
pIrb->Flags = 0;
pIrb->u.IsochFreeResources.hResource =
IsochResourceData->hResource;

ntStatus =
t1394_SubmitIrpSynch(deviceExtension->StackDeviceObject, ResourceIrp, pIrb);

if (!NT_SUCCESS(ntStatus)) {

TRACE(TL_ERROR, (“SubmitIrpSync failed =
0x%x\n”, ntStatus));
TRAP;
}

ExFreePool(pIrb);
IoFreeIrp(ResourceIrp);
}
}
}
}
else {

KeReleaseSpinLock(&deviceExtension->IsochResourceSpinLock,
Irql);
break;
}
}

Hi Uwe,

Expecially this part of code seems not to work for
my device, because t1394_SubmitIrpSynch fails with error code
0xC0000022 (Access Denied).

Access Denied returned by REQUEST_ISOCH_FREE_RESOURCES means that there are
still isoch descriptors attached to the isoch resource handle. They must be
detached before the isoch resource handle itself is freed.

The original 1394diag driver is supposed to detach all pending isoch buffers
in a loop immediately preceding your code snippet. But possibly there are
race conditions with the isoch callback or the timeout handler which lead to
the situation that there are isoch descriptors not currently contained in
the ‘IsochDetachData’ list but not detached yet finally.

BTW: The 1394diag sample is not considered as a recommendable example for a
driver intended to be used in a production environment. Even by Microsoft
itself. See the rating of BillMcKenzie in the thread ‘1394 for Simple Data
Transfer’ in this list.

Only for my interest: What kind of FireWire device is it about?

Regards,
-Volker

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of uwe kirst
Sent: Friday, June 11, 2004 1:32 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] 1394Diag Example: Howto handle Surprise removal

Hello,
I’m writing a WDM driver for our firewire device and I’m
wondering howto
handle surprise removal. In the 1394 diag example from the ddk all
resource are freed upon surprise removal. The code shown below
is taken
from that example. Expecially this part of code seems not to work for
my device, because t1394_SubmitIrpSynch fails with error code
0xC0000022
(Access Denied). Sending an remove-resource-irp to the firewire bus
driver seems not possible after disconnecting the device.
Maybee someone could explain what is going wrong here.
Thanks
Uwe Kirst

// remove any isoch resource data
while (TRUE) {

KeAcquireSpinLock(&deviceExtension->IsochResourceSpinLock, &Irql);

if (!IsListEmpty(&deviceExtension->IsochResourceData)) {

PISOCH_RESOURCE_DATA IsochResourceData;

IsochResourceData =
(PISOCH_RESOURCE_DATA)RemoveHeadList(&deviceExtension->IsochRes
ourceData);

KeReleaseSpinLock(&deviceExtension->IsochResourceSpinLock,
Irql);

TRACE(TL_TRACE, (“Surprise Removal: IsochResourceData =
0x%x\n”, IsochResourceData));

if (IsochResourceData) {

PIRB pIrb;
NTSTATUS ntStatus;
PIRP ResourceIrp;
CCHAR StackSize;

TRACE(TL_TRACE, (“Surprise Removal: Freeing
hResource =
0x%x\n”, IsochResourceData->hResource));

StackSize =
deviceExtension->StackDeviceObject->StackSize + 1;
ResourceIrp = IoAllocateIrp(StackSize, FALSE);

if (ResourceIrp == NULL) {

TRACE(TL_ERROR, (“Failed to allocate
ResourceIrp!\n”));
TRAP;
}
else {

pIrb = ExAllocatePool(NonPagedPool, sizeof(IRB));

if (!pIrb) {

IoFreeIrp(ResourceIrp);

TRACE(TL_ERROR, (“Failed to allocate
pIrb!\n”));
TRAP;
}
else {

RtlZeroMemory (pIrb, sizeof (IRB));
pIrb->FunctionNumber =
REQUEST_ISOCH_FREE_RESOURCES;
pIrb->Flags = 0;
pIrb->u.IsochFreeResources.hResource =
IsochResourceData->hResource;

ntStatus =
t1394_SubmitIrpSynch(deviceExtension->StackDeviceObject,
ResourceIrp, pIrb);

if (!NT_SUCCESS(ntStatus)) {

TRACE(TL_ERROR, (“SubmitIrpSync failed =
0x%x\n”, ntStatus));
TRAP;
}

ExFreePool(pIrb);
IoFreeIrp(ResourceIrp);
}
}
}
}
else {

KeReleaseSpinLock(&deviceExtension->IsochResourceSpinLock,
Irql);
break;
}
}


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently
subscribed to ntdev as: xxxxx@baslerweb.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Moebius, V. wrote:

Hi Uwe,

>Expecially this part of code seems not to work for
>my device, because t1394_SubmitIrpSynch fails with error code
>0xC0000022 (Access Denied).
>
>

Access Denied returned by REQUEST_ISOCH_FREE_RESOURCES means that there are
still isoch descriptors attached to the isoch resource handle. They must be
detached before the isoch resource handle itself is freed.

The original 1394diag driver is supposed to detach all pending isoch buffers
in a loop immediately preceding your code snippet. But possibly there are
race conditions with the isoch callback or the timeout handler which lead to
the situation that there are isoch descriptors not currently contained in
the ‘IsochDetachData’ list but not detached yet finally.

BTW: The 1394diag sample is not considered as a recommendable example for a
driver intended to be used in a production environment. Even by Microsoft
itself. See the rating of BillMcKenzie in the thread ‘1394 for Simple Data
Transfer’ in this list.

Only for my interest: What kind of FireWire device is it about?

Regards,
-Volker

Hello Volker,
it’s and firewire audio device (see also http://www.synthax.de/). My
problem is that I do not have a better example. I had to make
significant changes before it basically worked. Thank you for your reply.
Regards,
Uwe

Yea, unfortunately there are no good 1394 sample drivers out there. I am
hopeful (but realistically doubtful) that Longhorn is going to see an
improvement in the 1394 space. I know there is a 1394 WDF sample in the new
WDF beta which is probably a promising sign.

I don’t really understand the state of the 1394 Windows world when you
consider this technology has been shipping in Windows for *** over 6
years***. One person could fix all of the bus and sample problems in a few
months time. The resources have to be justifiable at some level.

It would also be nice if someone from the 1394 team would comment publicly
on the state and future direction of 1394 as well. I did not see anything
on 1394 at this years WinHEC (save one presentation on 1394 debugging). I
find this strange given that 1394’s popularity on Windows platforms is
growing substantially.


Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.

“uwe kirst” wrote in message news:xxxxx@ntdev…
> Moebius, V. wrote:
>
> >Hi Uwe,
> >
> >
> >
> >>Expecially this part of code seems not to work for
> >>my device, because t1394_SubmitIrpSynch fails with error code
> >>0xC0000022 (Access Denied).
> >>
> >>
> >
> >Access Denied returned by REQUEST_ISOCH_FREE_RESOURCES means that there
are
> >still isoch descriptors attached to the isoch resource handle. They must
be
> >detached before the isoch resource handle itself is freed.
> >
> >The original 1394diag driver is supposed to detach all pending isoch
buffers
> >in a loop immediately preceding your code snippet. But possibly there are
> >race conditions with the isoch callback or the timeout handler which lead
to
> >the situation that there are isoch descriptors not currently contained in
> >the ‘IsochDetachData’ list but not detached yet finally.
> >
> >BTW: The 1394diag sample is not considered as a recommendable example for
a
> >driver intended to be used in a production environment. Even by Microsoft
> >itself. See the rating of BillMcKenzie in the thread ‘1394 for Simple
Data
> >Transfer’ in this list.
> >
> >Only for my interest: What kind of FireWire device is it about?
> >
> >Regards,
> >-Volker
> >
> >
> >
> Hello Volker,
> it’s and firewire audio device (see also http://www.synthax.de/). My
> problem is that I do not have a better example. I had to make
> significant changes before it basically worked. Thank you for your reply.
> Regards,
> Uwe
>
>

The bus is a market failure. Let’s face it.

It is used for nearly nothing except DV cameras and point-to-point
connections.

Compare this to USB.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Bill McKenzie”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Saturday, June 12, 2004 2:30 AM
Subject: Re:[ntdev] 1394Diag Example: Howto handle Surprise removal

> Yea, unfortunately there are no good 1394 sample drivers out there. I am
> hopeful (but realistically doubtful) that Longhorn is going to see an
> improvement in the 1394 space. I know there is a 1394 WDF sample in the new
> WDF beta which is probably a promising sign.
>
> I don’t really understand the state of the 1394 Windows world when you
> consider this technology has been shipping in Windows for over 6
> years
. One person could fix all of the bus and sample problems in a few
> months time. The resources have to be justifiable at some level.
>
> It would also be nice if someone from the 1394 team would comment publicly
> on the state and future direction of 1394 as well. I did not see anything
> on 1394 at this years WinHEC (save one presentation on 1394 debugging). I
> find this strange given that 1394’s popularity on Windows platforms is
> growing substantially.
>
> –
> Bill McKenzie
> Software Engineer - Prism 802.11 Wireless Solutions
> Conexant Systems, Inc.
>
>
> “uwe kirst” wrote in message news:xxxxx@ntdev…
> > Moebius, V. wrote:
> >
> > >Hi Uwe,
> > >
> > >
> > >
> > >>Expecially this part of code seems not to work for
> > >>my device, because t1394_SubmitIrpSynch fails with error code
> > >>0xC0000022 (Access Denied).
> > >>
> > >>
> > >
> > >Access Denied returned by REQUEST_ISOCH_FREE_RESOURCES means that there
> are
> > >still isoch descriptors attached to the isoch resource handle. They must
> be
> > >detached before the isoch resource handle itself is freed.
> > >
> > >The original 1394diag driver is supposed to detach all pending isoch
> buffers
> > >in a loop immediately preceding your code snippet. But possibly there are
> > >race conditions with the isoch callback or the timeout handler which lead
> to
> > >the situation that there are isoch descriptors not currently contained in
> > >the ‘IsochDetachData’ list but not detached yet finally.
> > >
> > >BTW: The 1394diag sample is not considered as a recommendable example for
> a
> > >driver intended to be used in a production environment. Even by Microsoft
> > >itself. See the rating of BillMcKenzie in the thread ‘1394 for Simple
> Data
> > >Transfer’ in this list.
> > >
> > >Only for my interest: What kind of FireWire device is it about?
> > >
> > >Regards,
> > >-Volker
> > >
> > >
> > >
> > Hello Volker,
> > it’s and firewire audio device (see also http://www.synthax.de/). My
> > problem is that I do not have a better example. I had to make
> > significant changes before it basically worked. Thank you for your reply.
> > Regards,
> > Uwe
> >
> >
>
>
>
> —
> 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

What are talking about? The chipsets finally dropped in price what a couple
of years ago? Now, I cannot hardly buy a PC without a 1394 host controller
in it. In fact, all of the PC’s I have purchased over the last three years
have had 1394 ports. Even one supreme el-cheapo model I bought at the local
scrounge for parts shops.

Make no mistake, having Intel creating the competing technology and most of
the PC chipsets has not helped 1394, but its use is just starting to pick
up. I have seen more 1394 questions here in the last 6 months than in all
the time up until then.


Bill McKenzie

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> The bus is a market failure. Let’s face it.
>
> It is used for nearly nothing except DV cameras and point-to-point
> connections.
>
> Compare this to USB.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Bill McKenzie”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, June 12, 2004 2:30 AM
> Subject: Re:[ntdev] 1394Diag Example: Howto handle Surprise removal
>
>
> > Yea, unfortunately there are no good 1394 sample drivers out there. I
am
> > hopeful (but realistically doubtful) that Longhorn is going to see an
> > improvement in the 1394 space. I know there is a 1394 WDF sample in the
new
> > WDF beta which is probably a promising sign.
> >
> > I don’t really understand the state of the 1394 Windows world when you
> > consider this technology has been shipping in Windows for over 6
> > years
. One person could fix all of the bus and sample problems in a
few
> > months time. The resources have to be justifiable at some level.
> >
> > It would also be nice if someone from the 1394 team would comment
publicly
> > on the state and future direction of 1394 as well. I did not see
anything
> > on 1394 at this years WinHEC (save one presentation on 1394 debugging).
I
> > find this strange given that 1394’s popularity on Windows platforms is
> > growing substantially.
> >
> > –
> > Bill McKenzie
> > Software Engineer - Prism 802.11 Wireless Solutions
> > Conexant Systems, Inc.
> >
> >
> > “uwe kirst” wrote in message news:xxxxx@ntdev…
> > > Moebius, V. wrote:
> > >
> > > >Hi Uwe,
> > > >
> > > >
> > > >
> > > >>Expecially this part of code seems not to work for
> > > >>my device, because t1394_SubmitIrpSynch fails with error code
> > > >>0xC0000022 (Access Denied).
> > > >>
> > > >>
> > > >
> > > >Access Denied returned by REQUEST_ISOCH_FREE_RESOURCES means that
there
> > are
> > > >still isoch descriptors attached to the isoch resource handle. They
must
> > be
> > > >detached before the isoch resource handle itself is freed.
> > > >
> > > >The original 1394diag driver is supposed to detach all pending isoch
> > buffers
> > > >in a loop immediately preceding your code snippet. But possibly there
are
> > > >race conditions with the isoch callback or the timeout handler which
lead
> > to
> > > >the situation that there are isoch descriptors not currently
contained in
> > > >the ‘IsochDetachData’ list but not detached yet finally.
> > > >
> > > >BTW: The 1394diag sample is not considered as a recommendable example
for
> > a
> > > >driver intended to be used in a production environment. Even by
Microsoft
> > > >itself. See the rating of BillMcKenzie in the thread ‘1394 for
Simple
> > Data
> > > >Transfer’ in this list.
> > > >
> > > >Only for my interest: What kind of FireWire device is it about?
> > > >
> > > >Regards,
> > > >-Volker
> > > >
> > > >
> > > >
> > > Hello Volker,
> > > it’s and firewire audio device (see also http://www.synthax.de/). My
> > > problem is that I do not have a better example. I had to make
> > > significant changes before it basically worked. Thank you for your
reply.
> > > Regards,
> > > Uwe
> > >
> > >
> >
> >
> >
> > —
> > 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
>
>

> It is used for nearly nothing except DV cameras and point-to-point

connections.

Yes, the most common 1394 product is probably DV cameras. Many external
disk drives use both USB and Firewire. 1394 has been elected as the
connectivity for HDTV products (TVs, set-top boxes, DVD players). Many
professional audio products now use 1394 to connect to the PC because of
the very low latency it can achieve.

Have a look at this list of products:
http://www.1394ta.org/About/products/

And this benchmark, comparing 1394a to USB 2.0:
http://www.extremetech.com/print_article/0,3428,a=25038,00.asp
(And that does not include 1394b which has double the bandwidth)

I agree Firewire did not lift as much as it could have done. A market
failure? Maybe. But like Bill said, it is picking up more and more
every day :slight_smile:

Mat

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bill McKenzie
Sent: Sunday, June 13, 2004 11:03 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:1394Diag Example: Howto handle Surprise removal

What are talking about? The chipsets finally dropped in price what a
couple
of years ago? Now, I cannot hardly buy a PC without a 1394 host
controller
in it. In fact, all of the PC’s I have purchased over the last three
years
have had 1394 ports. Even one supreme el-cheapo model I bought at the
local
scrounge for parts shops.

Make no mistake, having Intel creating the competing technology and most
of
the PC chipsets has not helped 1394, but its use is just starting to
pick
up. I have seen more 1394 questions here in the last 6 months than in
all
the time up until then.


Bill McKenzie

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> The bus is a market failure. Let’s face it.
>
> It is used for nearly nothing except DV cameras and point-to-point
> connections.
>
> Compare this to USB.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> ----- Original Message -----
> From: “Bill McKenzie”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Saturday, June 12, 2004 2:30 AM
> Subject: Re:[ntdev] 1394Diag Example: Howto handle Surprise removal
>
>
> > Yea, unfortunately there are no good 1394 sample drivers out there.
I
am
> > hopeful (but realistically doubtful) that Longhorn is going to see
an
> > improvement in the 1394 space. I know there is a 1394 WDF sample in
the
new
> > WDF beta which is probably a promising sign.
> >
> > I don’t really understand the state of the 1394 Windows world when
you
> > consider this technology has been shipping in Windows for over 6
> > years
. One person could fix all of the bus and sample problems
in a
few
> > months time. The resources have to be justifiable at some level.
> >
> > It would also be nice if someone from the 1394 team would comment
publicly
> > on the state and future direction of 1394 as well. I did not see
anything
> > on 1394 at this years WinHEC (save one presentation on 1394
debugging).
I
> > find this strange given that 1394’s popularity on Windows platforms
is
> > growing substantially.
> >
> > –
> > Bill McKenzie
> > Software Engineer - Prism 802.11 Wireless Solutions
> > Conexant Systems, Inc.
> >
> >
> > “uwe kirst” wrote in message news:xxxxx@ntdev…
> > > Moebius, V. wrote:
> > >
> > > >Hi Uwe,
> > > >
> > > >
> > > >
> > > >>Expecially this part of code seems not to work for
> > > >>my device, because t1394_SubmitIrpSynch fails with error code
> > > >>0xC0000022 (Access Denied).
> > > >>
> > > >>
> > > >
> > > >Access Denied returned by REQUEST_ISOCH_FREE_RESOURCES means that
there
> > are
> > > >still isoch descriptors attached to the isoch resource handle.
They
must
> > be
> > > >detached before the isoch resource handle itself is freed.
> > > >
> > > >The original 1394diag driver is supposed to detach all pending
isoch
> > buffers
> > > >in a loop immediately preceding your code snippet. But possibly
there
are
> > > >race conditions with the isoch callback or the timeout handler
which
lead
> > to
> > > >the situation that there are isoch descriptors not currently
contained in
> > > >the ‘IsochDetachData’ list but not detached yet finally.
> > > >
> > > >BTW: The 1394diag sample is not considered as a recommendable
example
for
> > a
> > > >driver intended to be used in a production environment. Even by
Microsoft
> > > >itself. See the rating of BillMcKenzie in the thread ‘1394 for
Simple
> > Data
> > > >Transfer’ in this list.
> > > >
> > > >Only for my interest: What kind of FireWire device is it about?
> > > >
> > > >Regards,
> > > >-Volker
> > > >
> > > >
> > > >
> > > Hello Volker,
> > > it’s and firewire audio device (see also http://www.synthax.de/).
My
> > > problem is that I do not have a better example. I had to make
> > > significant changes before it basically worked. Thank you for your
reply.
> > > Regards,
> > > Uwe
> > >
> > >
> >
> >
> >
> > —
> > 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@cvds.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> Yes, the most common 1394 product is probably DV cameras. Many external

disk drives use both USB and Firewire.

I would say - most.

1394 has been elected as the
connectivity for HDTV products (TVs, set-top boxes, DVD players).

Wow. This at least means that the bus will not die :slight_smile:

I agree Firewire did not lift as much as it could have done. A market
failure? Maybe. But like Bill said, it is picking up more and more
every day :slight_smile:

Maybe I was not correct. But this means that the chances for MS to fix the 1394
stack are better.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Yes, there are external drives that uses 1394 or usb and some has even both. And about setTopBox, PVR, and other gadgets I’m sitting on top also use 1394. But, Max’s opinion is partially correct,not because of USB, but because of sata. Once sata picks up, the storage for local connectivity-based disk might go rapidly in that direction, network based storage is altogether different, ipv6 should be all over to rescue. And just to streach my mind, there are embedded linux being used on lot of these that I happen to be involved, and they are mostly around DOCSIS area …
-pro

SATA is really just an IDE replacement. FW/USB drives satisfy a different
market requirement - mostly it is the easy plugin/unplug capability that
sells these drives, relatively rarely are they sold as permanent storage
upgrades in place of IDE or SATA drives. The real question is will SATA eat
the SCSI/FC market (at least on the low end) once it does command queuing.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@garlic.com [mailto:xxxxx@garlic.com]
Sent: Monday, June 14, 2004 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:1394Diag Example: Howto handle Surprise removal

Yes, there are external drives that uses 1394 or usb and some has even both.
And about setTopBox, PVR, and other gadgets I’m sitting on top also use
1394. But, Max’s opinion is partially correct,not because of USB, but
because of sata. Once sata picks up, the storage for local
connectivity-based disk might go rapidly in that direction, network based
storage is altogether different, ipv6 should be all over to rescue. And just
to streach my mind, there are embedded linux being used on lot of these that
I happen to be involved, and they are mostly around DOCSIS area …
-pro


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

>partially correct,not because of USB, but because of sata. Once sata picks up,
the storage for

SATA supports hot-plug?

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Well, I forgot to put E in front of sata. It is Esata I meant to say. And my opinion, in this case should be as honest as possible :). Intel board I used that has integrated controller chip to replace IDE, and bunch of HBA’s for ESATA…
-pro

SATA does support command queuing … check out marvel host controllers. …

SATA would most probably eat into the low end market… i think EMC’s AX100
based
products do support SATA.

ritesh

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Monday, June 14, 2004 9:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:1394Diag Example: Howto handle Surprise removal

SATA is really just an IDE replacement. FW/USB drives satisfy a different
market requirement - mostly it is the easy plugin/unplug capability that
sells these drives, relatively rarely are they sold as permanent storage
upgrades in place of IDE or SATA drives. The real question is will SATA eat
the SCSI/FC market (at least on the low end) once it does command queuing.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@garlic.com [mailto:xxxxx@garlic.com]
Sent: Monday, June 14, 2004 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:1394Diag Example: Howto handle Surprise removal

Yes, there are external drives that uses 1394 or usb and some has even both.
And about setTopBox, PVR, and other gadgets I’m sitting on top also use
1394. But, Max’s opinion is partially correct,not because of USB, but
because of sata. Once sata picks up, the storage for local
connectivity-based disk might go rapidly in that direction, network based
storage is altogether different, ipv6 should be all over to rescue. And just
to streach my mind, there are embedded linux being used on lot of these that
I happen to be involved, and they are mostly around DOCSIS area …
-pro


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.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@patni.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

SATA-II only. And currently most standard sata drives are sata-I. So really,
in the future SATA will support command queuing, which is what I think I
said.

=====================
Mark Roddy

-----Original Message-----
From: Ritesh Noronha [mailto:xxxxx@patni.com]
Sent: Monday, June 14, 2004 1:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:1394Diag Example: Howto handle Surprise removal

SATA does support command queuing … check out marvel host controllers. …

SATA would most probably eat into the low end market… i think EMC’s AX100
based products do support SATA.

ritesh

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Roddy, Mark
Sent: Monday, June 14, 2004 9:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Re:1394Diag Example: Howto handle Surprise removal

SATA is really just an IDE replacement. FW/USB drives satisfy a different
market requirement - mostly it is the easy plugin/unplug capability that
sells these drives, relatively rarely are they sold as permanent storage
upgrades in place of IDE or SATA drives. The real question is will SATA eat
the SCSI/FC market (at least on the low end) once it does command queuing.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@garlic.com [mailto:xxxxx@garlic.com]
Sent: Monday, June 14, 2004 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Re:1394Diag Example: Howto handle Surprise removal

Yes, there are external drives that uses 1394 or usb and some has even both.
And about setTopBox, PVR, and other gadgets I’m sitting on top also use
1394. But, Max’s opinion is partially correct,not because of USB, but
because of sata. Once sata picks up, the storage for local
connectivity-based disk might go rapidly in that direction, network based
storage is altogether different, ipv6 should be all over to rescue. And just
to streach my mind, there are embedded linux being used on lot of these that
I happen to be involved, and they are mostly around DOCSIS area …
-pro


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@stratus.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@patni.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@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com