Re: cipe win32 pre6 bsod|
"Damion K. Wilson" <dkw,AT,rcm,DOT,bm>|
Mon, 12 Feb 2001 16:50:30 +0100|
I spent a month on it and got nowhere. The service has a sleep() and some
other horrible modifications to try and alleviate the problem. All to no
The driver acts as a "tap" device. Packets sent out on the network are
matched up to usermode read requests on the serial device side. Packets
written to the serial device side are "delivered" to the network side (as
though they came from the wire).
The virtual memory spaces are different in a usermode thread and kernelmode
so the memory used for the packet transfer has to be "mapped" into kernel
space. There are a number of ways to do this, but, as documented, the best
way for this application is "buffered I/O". What that means is that, when a
read or write request is issued, the buffer passed in the call is copied
into a kernel mode area and the addressed passed to the driver's handler
function is that of the temporary buffer. On exiting the function, the
process is reversed. This technique means that you don't have to lock
usermode pages in memory while the thread is inactive (waiting for the
driver to return a result).
In our case, either the memory used in kernel mode is not "correct" or,
after a read, the memory containing the retrieved packet becomes "invalid".
At this point either the service will crash or the driver will (taking the
OS with it). If the service crashes, restarting it may work for a little
while, but eventually the driver will die. And, like I said, this scenario
doesn't always happen. I have an NT testbed box which this has never
Remedies. My current line of thought leads me to abandoning the buffered
I/O approach and locking the page in memory. This may be slower, but it
won't be catastrophically so. If you have the DDK setup on your machine,
try building the package yourself and poke around. The nasty bits are
I won't be working on this for a month or so as I'm reimplementing our
Damion K. Wilson
*********** REPLY SEPARATOR ***********
On 2/9/01 at 3:32 PM straycat,AT,zen,DOT,eds,DOT,org wrote:
>> No, don't try pre5. That'll do the same thing.
>Sure enough. :(
>> I'm having some problems with spinlocking or something during the
>> of packets from usermode to kernelmode and/or vice versa. It doesn't
>> happen and on some installations it doesn't happen at all (In fact, it's
>> infrequent enough that I can't establish enough of a pattern to debug
>> I'm having extreme difficulty tracking down why this happens.
>Would the dword dumps from the blue screen help you any? Is there
>I can do to help?
>> Instead, use the old, Beta 11 version. It uses a polling, shared memory
>> approach to packet passing and doesn't have the IRQL problem. I'm using
>> in production at remote office locations and it never has any problems.
>> only caveat is that it is a little slower (because it's polled)
>Well, I got the same bluescreen but I suspect Windoze didn't do the right
>thing when I uninstalled the adapter. Indeed, that wasn't easy and I'm
>even sure how I was able to do so. Something in the remove adapter script
>isn't expanding the system path correctly and so I get an error about
>locate /cipsrvr.dnr" and "script must end with EXIT" Is there a manual
>uninstall I can do to wipe the system clean of old cipe's and start fresh
>Unfortunately, I cannot just write off CIPE-Win32 in favor of the Linux
>because the VoIP software on Linux is lacking and I doubt my friend is
>to invest in another computer just to do CIPE. I'd like to see this work.
>What can I do to help?
>> Damion K. Wilson
>> *********** REPLY SEPARATOR ***********
>> On 2/8/01 at 5:28 PM straycat,AT,zen,DOT,eds,DOT,org wrote:
>> >Hi Damon,
>> >I installed CIPE-Win32 pre6, configured it, rebooted, etc, etc
>> >First, the service hangs at startup or so the NT eventviewer says. I
>> never trusted that app to be any more useful than someone pointing their
>> finger at me
>> >and laughing. So I set the service to Manual. That solved that. No
>> >Okay, well, I ignored that b/c traffic is going through the CIPE
>> >I'm using CIPE to set up a VPN for H.323 VoIP but right now, I'm just
>> evaluating it in a lab environment. So about halfway through a call, I
>> a BSOD.
>> >Now, of course, even though my System settings say write the contents
>> %SystemRoot%\MEMORY.DMP, that never happened.
>> >I didn't transcribe the whole BSOD, but here's what I did right down:
>> >*** STOP: 0x0000000A (0xF7641000, 0x00000002, 0x00000001, 0xFC554C1)
>> >IRQL_NOT_LESS_OR_EQUAL *** Address fc554c41 has base at fc553000 -
>> >I also wrote down the dword dumps for cipdriver.sys. If you want that,
>> let me know.
>> >This is NT4 SP3 (Build 1381).
>> >I'm going to try out the pre5 release and see if I have any different
>> >BTW, the other end of the CIPE tunnel is a Linux 2.2.5-15 (RH6.0) box
>> running CIPE 1.4.5.