NWDSERegisterForEvent and multiple processors
John Baird
without issues for several years. However, a customer has reported that
under NW 6.5 SP5, it abends the server when loading (or immediately
thereafter), whenever the second processor is activated. Unfortunately I
dont have a multi-processor server for testing. I'll attach part of the
abend.log entry below.
I just tried searching developer.novell.com for info on NLMs in a
multi-processor environment, but searches are abysmally slow at the moment.
Are there specific changes I need to make to an otherwise functional NLM to
allow it to run with multiple processors enabled?
TIA, John
Server LGICP-VULCAN-N5 halted Thursday, June 8, 2006 6:47:03.378 am
Abend 1 on P00: Server-5.70.05: Page Fault Processor Exception (Error code
00000000)
Registers:
CS = 0008 DS = 0068 ES = 0068 FS = 0068 GS = 007B SS = 0068
EAX = 00000000 EBX = FFFFFFCB ECX = FFFFFFFF EDX = 9BB8BA0A
ESI = 9BB8B878 EDI = FFFFFFCB EBP = 9BB8B792 ESP = 9BB8B718
EIP = 002DB89F FLAGS = 00010246
002DB89F F2AE REPNE SCASB
EIP in SERVER.NLM at code start +000D8F7Fh
Access Location: 0xFFFFFFCB
The violation occurred while processing the following instruction:
002DB89F F2AE REPNE SCASB
002DB8A1 B8FEFFFFFF MOV EAX, FFFFFFFE
002DB8A6 2BC1 SUB EAX, ECX
002DB8A8 E97BFAFFFF JMP 002DB328
002DB8AD 8B555A MOV EDX, [EBP+5A]
002DB8B0 85D2 TEST EDX, EDX
002DB8B2 7608 JBE 002DB8BC
002DB8B4 3B5562 CMP EDX, [EBP+62]
002DB8B7 7303 JNB 002DB8BC
002DB8B9 895562 MOV [EBP+62], EDX
Running process: makehome__P 1 Process
Thread Owned by NLM: MAKEHOME.NLM
Stack pointer: 9BB8B92C
OS Stack limit: 9BB84CC0
Scheduling priority: 67371008
Wait state: 5050090 Wait for interrupt
Stack: -0041003D (SERVER.NLM|(Data Start)+D71D)
--944F70E0 ?
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--04040000 ?
--879CD480 ?
-00500BF8 (SERVER.NLM|OSAS+0)
002198B3 (SERVER.NLM|SchedResumeDisabled+F)
--879CD480 ?
--11111111 ?
--00000246 (LOADER.NLM|KernelAddressSpace+246)
0021979D (SERVER.NLM|SchedThreadYield+325)
--00000246 (LOADER.NLM|KernelAddressSpace+246)
--9769EC91 ?
--9769EB8F ?
--00000246 (LOADER.NLM|KernelAddressSpace+246)
001067F3 (LOADER.NLM|kSpinLockDisable+13)
--00000246 (LOADER.NLM|KernelAddressSpace+246)
00204DAA (SERVER.NLM|kCVBroadcast+D6)
--00000246 (LOADER.NLM|KernelAddressSpace+246)
001067F3 (LOADER.NLM|kSpinLockDisable+13)
--00000246 (LOADER.NLM|KernelAddressSpace+246)
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--00000246 (LOADER.NLM|KernelAddressSpace+246)
--00000246 (LOADER.NLM|KernelAddressSpace+246)
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--0000000F (LOADER.NLM|KernelAddressSpace+F)
--00000001 (LOADER.NLM|KernelAddressSpace+1)
00295BAE (SERVER.NLM|EventReport+3B2)
--FE001F40 (LOADER.NLM|OSAllocMemory+1F40)
--000006A2 (LOADER.NLM|KernelAddressSpace+6A2)
--000000A0 (LOADER.NLM|KernelAddressSpace+A0)
--34561289 ?
-8BB2B700 (TCPIP.NLM|cbAlloc+854)
00226C45 (SERVER.NLM|kScheduleWorkToDoDirected+A5)
--9BB8BB76 ?
-8BB2B700 (TCPIP.NLM|cbAlloc+854)
--8BCD17E0 ?
--8BCD17E0 ?
--9BB8BA0A ?
--00000001 (LOADER.NLM|KernelAddressSpace+1)
8B5A8AEC (TCPIP.NLM|ICMPRegister+1260)
-8BB2B700 (TCPIP.NLM|cbAlloc+854)
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--745798D8 ?
--685798D8 ?
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--FBC83148 (LOADER.NLM|PerCpuDataArray+3148)
8B5EF630 (TCPIP.NLM|UDPReturnPacket+A)
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--00000021 (LOADER.NLM|KernelAddressSpace+21)
--000000A0 (LOADER.NLM|KernelAddressSpace+A0)
--000000A0 (LOADER.NLM|KernelAddressSpace+A0)
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--34561289 ?
--000000A0 (LOADER.NLM|KernelAddressSpace+A0)
--000000A0 (LOADER.NLM|KernelAddressSpace+A0)
--FE00B0A0 (LOADER.NLM|OSAllocMemory+B0A0)
--34561289 ?
--FE00B0A0 (LOADER.NLM|OSAllocMemory+B0A0)
--34561289 ?
--9BB8BA09 ?
--00000000 (LOADER.NLM|KernelAddressSpace+0)
002DC1BB (SERVER.NLM|OutputToString+13D3)
--9BB8BA09 ?
--9BB8B8DC ?
002DCA98 (SERVER.NLM|OutputToString+1CB0)
--9BB8B878 ?
--8BCD15A0 ?
--8BCD15A0 ?
-8BB2B700 (TCPIP.NLM|cbAlloc+854)
--00000001 (LOADER.NLM|KernelAddressSpace+1)
8B5A8AEC (TCPIP.NLM|ICMPRegister+1260)
-8BB2B700 (TCPIP.NLM|cbAlloc+854)
--00000001 (LOADER.NLM|KernelAddressSpace+1)
--745798D8 ?
--685798D8 ?
--00000000 (LOADER.NLM|KernelAddressSpace+0)
--FBC83148 (LOADER.NLM|PerCpuDataArray+3148)
8B5EF630 (TCPIP.NLM|UDPReturnPacket+A)
--86F2DA84 ?
--00000282 (LOADER.NLM|KernelAddressSpace+282)
--9BB8BB65 ?
8B5C398D (TCPIP.NLM|IPSendWithRoute+7AD)
--FE00B0A0 (LOADER.NLM|OSAllocMemory+B0A0)
--00000018 (LOADER.NLM|KernelAddressSpace+18)
--0000003B (LOADER.NLM|KernelAddressSpace+3B)
--00000019 (LOADER.NLM|KernelAddressSpace+19)
--FE00B0A0 (LOADER.NLM|OSAllocMemory+B0A0)
--00000018 (LOADER.NLM|KernelAddressSpace+18)
--00000042 (LOADER.NLM|KernelAddressSpace+42)
--00000019 (LOADER.NLM|KernelAddressSpace+19)
--00000019 (LOADER.NLM|KernelAddressSpace+19)
--00000007 (LOADER.NLM|KernelAddressSpace+7)
--00000001 (LOADER.NLM|KernelAddressSpace+1)
--9BB8BA08 ?
--000006A2 (LOADER.NLM|KernelAddressSpace+6A2)
--9BB8B8C8 ?
--000000A0 (LOADER.NLM|KernelAddressSpace+A0)
-00436FB0 (SERVER.NLM|systemConsoleScreenStructure+0)
Jeff Lawson
There is nothing that you should have to do to support multiple processors
in an old NLM. NetWare has had MP support for many years now so your NLM has
likely run on MP systems for a long time. It is possible that your NLM is
misbehaved in some way that you have gotten away with until now, or it may
be that there is some bug in SP5.
I can't tell what the cause of the abend is from the abend log. The next
step is probably to get a coredump so that the cause can be determined.
Jeff Lawson
NetWare Core OS
LibC Engineering
>>> On 6/14/2006 at 12:31 AM, in message
<e3Ojg.1185$tN4...@prv-forum2.provo.novell.com>, John
Guenter
you probably know well I guess - but if not here some info:
the MP feature is controlled with the XDCDATA you can link in. You can
just create a simple 'mp-enable' XDC which declares the whole NLM with all
functions as MP-safe; but you can also specify functions which you want to
have executed on processor 0 only; so if you think that one specific
function is not MP-safe then you can try to specify that for processor 0
only.
http://forge.novell.com/modules/xfref_library/detail.php?reference_id=803
AFAIK if you dont link in any XDC data your NLM will allways be executed on
processor 0.
HTH, Guenter.
"John Baird" <jo...@jrbsoftware.com> wrote in news:e3Ojg.1185$tN4.716@prv-
forum2.provo.novell.com:
John Baird
Thanks for that - I'll check it out. NLMs are not my speciality so I was
unaware (or had forgotten) about this. Jeff may be correct that the issue in
an unrelated but longstanding bug that I've gotten away with til now. I've
added a heap of debug code and sent a modified version to the customer, and
am awaiting feedback.
John
"Guenter" <devf...@novell.com> wrote in message
news:20%jg.2056$tN4...@prv-forum2.provo.novell.com...
Jeff Lawson
on P0, or on multiple processors. Since you are having trouble in event
callbacks setting XDC data will not help. When you have XDC data that
indicates an MP unsafe interface the loader provides entry points with those
symbol names that 'funnel' all calling threads to P0 and then calls your
actual code. Since you are passing your actual function pointers to
NWDSERegisterForEvent(), the loader has no chance to intervene with
funneling code.
Do you have any other reason to suspect MP issues? There are other ways to
insure that your callback only runs on P0. The OS event engine will not call
you back on P0, unless you give it a special flag. In that way old NLMs
won't break by being called back on non-zero processors. I cannot speak to
the DS events generated through this event engine.
Jeff
>>> On 6/14/2006 at 4:03 PM, in message
<DI%jg.2089$tN4...@prv-forum2.provo.novell.com>, John
John Baird
"Jeff Lawson" <JLA...@novell.com> wrote in message
news:44904051.E...@novell.com...
> XDC data controls whether or not your NLM's exported symbols are only
called
> on P0, or on multiple processors. Since you are having trouble in event
> callbacks setting XDC data will not help. When you have XDC data that
> indicates an MP unsafe interface the loader provides entry points with
those
> symbol names that 'funnel' all calling threads to P0 and then calls your
> actual code. Since you are passing your actual function pointers to
> NWDSERegisterForEvent(), the loader has no chance to intervene with
> funneling code.
>
> Do you have any other reason to suspect MP issues? There are other ways to
> insure that your callback only runs on P0. The OS event engine will not
call
> you back on P0, unless you give it a special flag. In that way old NLMs
> won't break by being called back on non-zero processors. I cannot speak to
> the DS events generated through this event engine.
Jeff
Thanks for the further information. My only reason for suspecting MP issues
was the customers claim that the NLM which they had been using without issue
for two years, abends the server when-ever the second processor is enabled.
I dont know of anyone running this NLM successfully with MP, but thats not
to say there isn't someone out there who is doing so.
I still have not received the debug output (which was intended to find where
in the startup code it was abending, or whether startup was completing and
it was abending on the first event) from the customer so have not made any
progress on the problem.
John
krasimir_h
You wrote: "The OS event engine will not call you back on P0, unless you
give it a special flag."
Could you tell me what is this special flag and how do you give it to the
OS event engine?
Does this mean that all callbacks registered with RegisterForForEvent will
get executed on P0?
Krasimir
Jeff Lawson
the value needed and then called RegisterForEvent() if you would start
getting call backs on multiple processors (that is if the event being
consumed was produced on all processors). The callback code in clib appears
to handle MP situations, so it would probably work.
It is available by calling RegisterForEventNotification(). This call is in
the LibC SDK in event.h, as well as the define for EVENT_CONSUMER_MT_SAFE
and a little comment blurb as to how to pass it in.
Events being reported to consumers that are not registered with this bit set
will only happen on P0.
Jeff Lawson
NetWare Core OS
LibC Engineering
>>> On 6/29/2006 at 9:11 AM, in message
<y4Sog.12456$tN4...@prv-forum2.provo.novell.com>,