SS was introduced before XP SP2, but that doesn’t matter. It ships in the latest usb core which we ship downlevel.
Yes, it is really that difficult to get working, it is a tremendous PIA in terms of state synchronization. Most 3rd party drivers either don’t care or are too afraid to touch already fragile power code that barely works.
As for the msft bth stack supporting C3, that would require a radio that can SS and resume on connection requests. That requires a radio with sideband power b/c usb trickle current is not enough to power the radio. The original bth release didn’t support it, but I prototyped it and got it working right before I left that team. I know it is implemented now, but I don’t know if that made it into XP SP2 or not.
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Thursday, April 06, 2006 1:32 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
Thank you for the helpful information!
?
When was Selective Suspend introduced - XP SP2? I’m wondering why so many 3rd drivers don’t support Selective Suspend.
Is it really that difficult to get working, is Selective Suspend a?relatively new feature,?or is it that these 3rd party driver writers don’t want to put the effort to change their drivers?because they don’t have to?
?
Also, is it true that the MIcrosoft bluetooth stack usb driver doesn’t support C3 under XP? How about Vista?
?
thanks
----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Thursday, April 06, 2006 7:52 AM
Subject: RE: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
A KMDF port is rather straight forward.? I would start with pnp and power routines, then do the i/o queues.? It would take me less then 2 days, but I have gotten feedback from folks not working on KMDF that a port of a very large driver took less then 1 week.
To combine everything in one driver, you must mark your PDOs as RawOK.? Then you don’t even need an INF, but in your case you should install a NULL INF in the ports class so that the ports class installer can assign you a COM name when the device is installed.? Come to think of it, a raw PDO is not that great an idea for a virtual com port b/c it can be started before any install occurs, which means you are started w/out a COM port name assigned to you and the PDO can run forever w/out an install occurring.? Writing the serial port FDO driver using KMDF and keeping them separate guarantees that an install occurred on your PDO and that a name was assigned before any start.
d
– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Wednesday, April 05, 2006 11:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
thanks for the straight-forward feedback. How long do you think it would take to port this driver to KMDF? I’d also want to combine the two drivers into one - I forgot what the term was when the children use the parent as their driver too (null?)…
thanks
----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Wednesday, April 05, 2006 10:38 PM
Subject: RE: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
Putting one child in charge is a bad idea. What if the user decides to disable the master child device? Will you shuffle to another “master” PDO? You basically put all the functionality that should be in the bus FDO into one of its PDOs. If I were you, I would take the time to push all traffic through the FDO where the FDO is arbiter for access to the endpoint(s). Take the time to do it right now, otherwise you are going to hit a bunch of issues.
USB SS is a whole other ball of wax. For that you definitely need to do PPO stuff right and in the expected fashion (and not push it into a PDO of the bus). USB SS has a ton of inherit race conditions (like once you start powering down you have to go down all the way before powering up), being a bus driver only makes it N times harder. I *strongly* suggest you use KMDF if you go down this route. At least all the races have been tested and hammered out. Using KMDF will solve all of your PPO issues as well. I know you have vested a lot of time already in the driver, but you are just hitting the tip of the iceburg WRT to power.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Wednesday, April 05, 2006 10:30 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
thanks for the quick reply.
Where does the busenum sample you mention live? I looked in the 2600.1106 code and there is a busenum.c in the toaster sample for the bus, but it the comments say the the power handler for the fdo should be copied from the function driver sample, toaster.sys Maybe that’s what you meant? I assume you mean I need to add it for the FDO power handler?
Even though I have more than one (master) child, I only allow one child to do actual USB trafficing. The other children put their r/w IRPs on the queue for the master. And any data read from the device is read by that one child device and dumped into the appropriate circular buffer for that child and I have a thread that completes pending read IRPs that can be satisfied. (It was not my choice to share the same endpoints for all the com ports – that was dictated by the usb device.) So, I could have that particular child’s power handling stop pulling IRPs off the IRP queue, stop the polling USB IRP, and power the device down if possible.
Could I have that one master child do a PoCallDriver specifying the parent’s PDO as the 1st parameter. What this is asking is can I force the D state propagation from the child to the parent this way? My reasoning (which could be all wrong - it’s a guess possibly leading to a bluescreen) is this would send the D irp down to the PDO created by the usb hub driver (or whatever OS driver is beneath by parent driver)and that would magically work? Or not (bluescreen).
Could this work? Would I crash and burn? Please feel free to correct me if I’m totally wrong on this, but I’d appreciate to understand why…
I need to eventually support selective suspend as well - I’m hoping the child driver can handle that because only one child is doing the actual usb trafficing and I don’t have to coordinate between all the children. I hope it’s not going to be an issue in which I have to put code in the parent driver for that as well, but the way this email thread is going, it sounds like it will have to be.
thanks!
----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Wednesday, April 05, 2006 9:03 PM
Subject: RE: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
Power policy ownership is not enforced by the OS, it is purely a stack specific setting. You can have a child ben the PPO for the parent, but which child? You said you have more then one.
In the end, you need to have pwr management code in the parent driver. The power manager code does not propagate D state power irps from the child to the parent, it only sends S state power irps down the hierarchy. The PPO code in the bus driver should not be difficult, you can lift the code that is in the busenum sample. Just map S->D state irps and do the right thing with the S irp until the D irp is completed.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Wednesday, April 05, 2006 8:40 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
hi
I could finally spend some time on this (swamped with other stuff) and if I install the usb bulk ddk sample for the driver instead of my drivers, the USB analyzer shows what looks like good behavior – resets, power off, power on, and exchange of configuration information after coming out of standby. (I need to try running the sample exe to however to make 100% sure - at least a read not complete immediately with STATUS_DEVICE_NOT_CONNECTED.)
As you may remember, normally my drivers are a bus driver (the toaster bus ddk sample) that loads when the usb device is plugged in, and this bus driver creates child PDOs representing the virtual com ports.
Is there a way to make the driver for the children be the power policy owner for the usb device in this case?
I think my problem is that I assumed that the driver for the children (which actually does the usb communication - submitting IRPs/URBs to the bus pdo instead of the child pdo) could be the power policy owner for the board.
If the OS thinks the bus driver is the power policy owner, then since the toaster bus sample doesn’t handle power management D state changes, probably nothing is changing the D state for the device.
I don’t know if it is possible to make the child driver the power policy owner of the USB device? I know that the power IRPs don’t propagate down their way to the bus parent because they stop at the child PDO. So, the OS sends the power IRP down the child stack first. The, after that’s done, down the bus stack. (I know I read somewhere that the function driver doesn’t necessarily have to the power policy owner, but I guess that only is the case if the IRP makes is passed down between the two drivers - which doesn’t happen in this case.)
I was thinking about changing the PoCallDriver calls to specify the bus PDO instead of the child PDO (like I do for the USB request I submit), but that would be jumping power mgt stacks. Also, that wouldn’t prevent the Power Manager from submitting the power IRPs to the bus’ stack afterwards and those wouldn’t do anything.
I hate to have to add a bunch of power mgt code in the bus driver if I can avoid it. Any suggestions?
thanks in advance
----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Friday, March 24, 2006 5:40 PM
Subject: RE: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
I would hazard a guess that you have a firmware problem and that your device needs more time then the spec allows to resume from a low power state.
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, March 24, 2006 4:05 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
FYI - the experiment I just ran: Trying to reconfigure the device before restarting the polling IRP failed with STATUS_DEVICE_NOT_CONNECTED as well.
No configuration requests going from XP to the device.
----- Original Message -----
From: S. Drasnin
To: Windows System Software Devs Interest List
Sent: Friday, March 24, 2006 3:52 PM
Subject: Re: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
Yes, I was restarting the polling again in the device power completion routine. I have a KdPrint that shows I’m getting there.
I will move the stop polling from the query to the actual set.
I have a KdPrint statement in the code that cancels the IRP (it completes with STATUS_CANCELLED) so I know it’s getting there.
This code is called in my IRP_MJ_POWER handler for powerTye = DevicePowerState.
I agree that I’d be much better off under KMDF, but that’s not an option.
Do you have any other ideas of what could be wrong?
I was wondering what was happening to the controller in the embedded device. Doesn’t it do some timeout because it’s not getting a bus activity from the controller (master) on the XP side?
I have a USB analyzer hooked up and I don’t see my read request on the bulk out line even going out from XP to the device (Usb 1.1 device). I guess that’s not surprising. I don’t see anything that indicates that perhaps the other USB system drivers are asking for something that the device isn’t giving it either. Here’s what the trace shows:
- Power On -
- Reset (10.0 ms)
- High speed Detection Handshake (status = timeout)
- Suspended
- Reset
- High speed detection handshake (status = timeout)
I will try setting up the configuration of the USB device before I restart the polling, just to see if I can communicate with the device on endpoint 0. If you can think of some other experiment to try, please let me know.
thanks
----- Original Message -----
From: Doron Holan
To: Windows System Software Devs Interest List
Sent: Friday, March 24, 2006 2:40 PM
Subject: RE: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
You should stop polling in the IRP_MN_SET_POWER/Dx irp. There is no guarantee that you will always see a query power irp when the machine is going into low power. When you start polling again, are you doing this in the completion routine from the IRP_MN_SET_POWER/D0 irp? If not, you must do all processing of reentry into D0 on the IRP’s way back up the stack.
I would suggest that you investigate using KMDF for your driver. All of this is taken care of for you; KMDF also has polling built in, so you have to start/stop it in the right callback and you are done…but I am guessing that you can’t use KMDF per previous posts…
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of S. Drasnin
Sent: Friday, March 24, 2006 1:58 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] STATUS_DEVICE_NOT_CONNECTED after exiting standby
hi
I have a USB device (external board) that has a separate power supply and is connected to my PC via a USB cable and I’m adding power management handling code.
Before I enter standby (in IRP_MN_QUERY_POWER handler), my driver cancels a polling IRP that is responsible for reading data from the USB device. On return from standby (in IRP_MN_SET_POWER handler), I restart up the polling IRP. The first time it is re-issued after coming out of standby, it completes with STATUS_DEVICE_NOT_CONNECTED.
Is this a problem with my driver? (Note I’m not re-issuing any configuration commands since I assume the device remains powered.)
Also, I don’t actually have any open handles to the driver. The only USB activity initiated on the driver side is the polling read.
Is there something that is required to be handled by the device (either in software or hardware) because the controllers on the XP side probably got powered down in standby?
thanks in advance
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
