WM5 IM driver suspend/resume hang after AKU2 update

I wrote a NDIS IM driver based on the PASSTHRU sample in the PB5.0. It
works well on my Qtek9000 and QtekS200 except one issue that
NdisAllocatePacket can hang after standby/resume. So I did the AKU2 update
as soon as they are available. However I was surprised by the outcome.
Before the AKU2 update, a standby/resume will cause a complete tear down and
rebind of the NDIS stack and after that things recover nicely. This is true
even I return NDIS_STATUS_SUCCESS in ProtocolPNPHandler with
NetEventSetPower. However after AKU2 update, if I return NDIS_STATUS_SUCCESS
in ProtocolPNPHandler with NetEventSetPower things seems to be simpler.
Standby/resume only cause the lower WLAN miniport to go to D3 and then back
to D0. There is no NDIS stack tear down and rebuild anymore. If I return
NDIS_STATUS_NOT_SUPPORTED in ProtocolPNPHandler on NetEventSetPower then I
get the complete tear down and rebuild behavior back. This is all seems to
be reasonable however in either case the whole network stack hangs up after
resume. There is no NDIS calls into the IM driver anymore and apps which
uses IpHlpAPI will hangup as well. In short the whole NDIS stack is dead and
anything that touches the stack will also die. However one case still do
other things on the device such as open/read a text file. What I do in the
ProtocolPNPHandler are just setting some simple flags and the call is
returned without locks held. There is one more thing, with the complete
stack teardown and rebuild, I also get a D0->D0 notification after the
D3->D0 notification after resume. All the D0->D3, D3->D0 and D0->D0 seems to
happen on device resume. When going to standby everything happens instantly
and I cannot see D0->D3 being logged immediately. I am not sure whether
D0->D3 notification happens on the moment the standby happens but I guess it
happens on resume due to the aggressive power saving stratergy on PPC and on
PPC CPU actually stops on standby. During this standby/resume event all my
fucntions are returned without locks held and this code works before AKU2
update. Now the question is why NDIS hangs up with AKU2? Has anyone
experiencing similar problems or having some insight into the problem?
Thanks in advance!


Jicun

Maxim
Sun May 21 10:28:29 CDT 2006

> in ProtocolPNPHandler with NetEventSetPower things seems to be simpler.
> Standby/resume only cause the lower WLAN miniport to go to D3 and then
>back
> to D0. There is no NDIS stack tear down and rebuild anymore. If I return
> NDIS_STATUS_NOT_SUPPORTED in ProtocolPNPHandler on
>NetEventSetPower then I
> get the complete tear down and rebuild behavior back. This is all seems to
> be reasonable however in either case the whole network stack hangs up after
> resume.

Yes, exactly so, this is a well-known bug in WinCE 4.2 since at least late
2004. The workaround is to disable the power management handlers on the
protocol edge of your IM, thus forcing full rebind on resume. This works.

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

jzh
Tue May 23 00:54:06 CDT 2006

Maxim,
Thanks for the reply. The sad thing is even I disable the power
management handlers by returning NDIS_STATUS_NOT_SUPPORTED I still get a
hanging device with AKU2 installed. I have no idea what can be wrong on my
side.

Jicun

bemacdev
Tue May 23 06:54:01 CDT 2006

Jicun,

This post isn't going to help I'm afraid but I get exactly the same problem
too. I've read lots of postings about the well known IM suspend problem on CE
and its corresponding fix (returning NOT_SUPPORTED) but I've never managed to
get it to work on PPC2003 or WM5 either.

I've posted a similar request on the PocketPC newsgroup hoping to get a
reply from a person at Microsoft. I thought it was a Microsoft managed
newsgroup so being an MSDN customer I thought I might have got a reply.
Nothing yet though.

I was wondering what the cause might be if other people have got this
working. Binding maybe?

Andy


"jzh" wrote:

> Maxim,
> Thanks for the reply. The sad thing is even I disable the power
> management handlers by returning NDIS_STATUS_NOT_SUPPORTED I still get a
> hanging device with AKU2 installed. I have no idea what can be wrong on my
> side.
>
> Jicun
>
>
>

jzh
Tue May 23 09:22:00 CDT 2006

Andy,
I am really not sure about the cause. The binding I got after resume is
perfectly normal. I queried MAC/LinkSpeed/Medium etc. on the lower wlan
miniport and got full valid replies. So I cannot see anything wrong with the
binding.
I have also contacted a nice MS fellow, he told me that there is no
guarantee that an ISV taking the Passthru sample from PB5 and modified it in
some way will work on WM5 devices. Because CE5!=WM5. Only the HW OEM can
guarantee what will work on the final product. So basically as an ISV taking
the IM driver approach, we are on our own. According to this, my working IM
driver for PPC2003 and WM5 before AKU2 update are pure luck.


Jicun