[ofw] assert on ipoib_port.c @ 3629

Wed Nov 12 09:17:04 PST 2008

OK, here is what I now found:

1) The machine has iSCSI initiator installed.

2) the call stack of the problem is this:

RetAddr           : Args to Child
: Call Site
fffff800`0111c692 : fffff800`0111c770 fffffadf`8ed2c1f0
fffffadf`8ed2c1c0 00000000`00000002 : nt!DbgBreakPoint
fffffadf`8f121f6c : fffffadf`9a2be228 fffffadf`9c511020
00000000`00000000 fffffadf`9c511010 : nt!RtlAssert+0xf3
fffffadf`8f120f13 : fffffadf`9a2b9000 fffffadf`99b44098
fffffadf`99b451b8 00000000`00000100 : ipoib!__send_mgr_filter_dhcp+0xf3c
[q:\projinf4\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3627]
fffffadf`8f11ecdf : fffffadf`9a2b9000 fffffadf`99b43078
fffffadf`99b44040 00000000`00000000 : ipoib!__send_mgr_filter_udp+0xba3
[q:\projinf4\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3468]
fffffadf`8f11cee6 : fffffadf`9a2b9000 fffffadf`99b810e8
fffffadf`99b43040 00000000`00000000 : ipoib!__send_mgr_filter_ip+0x96f
[q:\projinf4\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3255]
fffffadf`8f124e8a : fffffadf`9a2b9000 fffffadf`99b810e8
fffffadf`99b810b0 00000000`00000000 : ipoib!__send_mgr_filter+0x106
[q:\projinf4\trunk\ulp\ipoib\kernel\ipoib_port.c @ 2846]
fffffadf`8f1262ad : fffffadf`9a2b9000 fffffadf`99b810e8
fffffadf`99b810b0 00000000`0000000e : ipoib!__build_send_desc+0x5ba
[q:\projinf4\trunk\ulp\ipoib\kernel\ipoib_port.c @ 3954]
fffffadf`8f0fc8e4 : fffffadf`9a2b9000 fffffadf`8ed2cde0
00000000`00000001 fffffadf`99b81000 : ipoib!ipoib_port_send+0xd9d
[q:\projinf4\trunk\ulp\ipoib\kernel\ipoib_port.c @ 4170]
fffffadf`8fd75b97 : fffffadf`9a2bc010 fffffadf`8ed2cde0
fffffadf`00000001 00000000`00000000 : ipoib!ipoib_send_packets+0x244
[q:\projinf4\trunk\ulp\ipoib\kernel\ipoib_driver.c @ 1897]
fffff800`0080c0a9 : 00000000`c000009a fffffadf`8fd833ad
fffffadf`99f76eb0 fffffadf`8fd3598a : NDIS!ndisMProcessSGList+0x8e
fffffadf`8fd75903 : fffffadf`99b29000 fffffadf`9a2be060
fffffadf`9c511010 00000000`000002c0 :
hal!HalBuildScatterGatherList+0x2b9
fffffadf`8fd35618 : fffffadf`9a2be228 fffffadf`99f76eb0
fffffadf`99f76e40 fffffadf`9a2be228 : NDIS!ndisMAllocSGList+0x17c
fffffadf`8ef679f1 : fffffadf`99f7ed90 fffffadf`99f76eb0
fffffadf`99f7ed90 00000000`00000000 : NDIS!ndisMSendX+0x21e
fffffadf`8ef677de : 00000000`00000000 00000000`00000000
00000000`00000000 fffffadf`99f7ed90 : tcpip!ARPSendBCast+0x499
fffffadf`8ef6835c : 00000000`00000000 00000000`00000103
00000000`00000000 00000000`ffffffff : tcpip!ARPTransmit+0x359
fffffadf`8efba697 : 00000000`00000003 fffffadf`99b887c0
fffffadf`99f76eb0 00000000`00000001 : tcpip!SendIPPacket+0x273
fffffadf`8ef8dbbc : fffffadf`99b43078 fffffadf`ffffffff
fffffadf`99f76eb0 fffffadf`99b43078 : tcpip!SendIPBCast+0x1bfd
fffffadf`8ef6add6 : fffffadf`99b2f010 fffffadf`99b440ac
00000000`8303040b fffffadf`9c3c6180 : tcpip!IPTransmit+0x395b
fffffadf`8ef6a9a3 : 00000000`00000100 00000000`c0000141
fffffadf`8ef6ab20 00000000`c0000141 : tcpip!UDPSend+0x74f
fffffadf`8ef6b098 : fffffadf`99b44078 fffffadf`8ed2dcf0
fffffadf`00000100 fffffadf`99b45170 : tcpip!TdiSendDatagram+0x196
fffffadf`8ef81342 : fffffadf`8ed2d701 fffffadf`00000040
fffffadf`99b45170 fffffadf`99b45010 : tcpip!UDPSendDatagram+0x68
fffffadf`8eed206e : fffffadf`99b45a00 fffffadf`99b45a00
fffffadf`99b457e0 fffffadf`99b457e0 :
tcpip!TCPDispatchInternalDeviceControl+0x256
fffffadf`8eeeac74 : fffffadf`99b45a00 fffffadf`8ed2d8d0
fffffadf`00000100 fffffadf`8ed2daf0 : afd!AfdFastDatagramSend+0x3e5
fffff800`0127ff36 : fffff683`ffbb9900 00000000`00000002
fffffadf`8ed2dab0 fffffadf`8ed2daf8 : afd!AfdFastIoDeviceControl+0xe0e
fffff800`0127fc16 : 00000000`00000100 00000000`000001a0
00000000`00000000 00000000`00000000 : nt!IopXxxControlFile+0x5a4
fffff800`0102e3fd : fffff6fb`7dbed078 00000000`00000000
fffffadf`99b2c3b0 00000000`00a7e930 : nt!NtDeviceIoControlFile+0x56
00000000`77ef0a5a : 000007ff`771b40aa 00000000`00000004
000007ff`6d24e5dc 00000000`000c0000 : nt!KiSystemServiceCopyEnd+0x3
000007ff`771b40aa : 00000000`00000004 000007ff`6d24e5dc
00000000`000c0000 00000000`00a7eb18 : ntdll!NtDeviceIoControlFile+0xa
000007ff`7731424f : 00000000`000e4ecd 00000000`00a7edc0
00000000`010a4040 00000000`000e4ec8 : mswsock!WSPSendTo+0x6f9
00000001`00036cee : 00000000`000e4ed0 00000000`000e4ed0
00000000`00a7febf 00000000`00a7efbc : WS2_32!sendto+0x185
00000001`00037174 : 00000000`000001a4 00000000`8303040b
00000000`00004401 00000000`00000036 :
iscsiexe!DhcpSendInformOrDiscover+0x26e
00000001`00033f32 : 00000000`00000002 00000000`000003e8
00000000`8303040b 00000000`00a7ff50 : iscsiexe!DhcpFindDHCPServers+0x144
00000000`77d6b6da : 00000000`002abe90 00000000`00000000
00000000`00000000 00000000`00a7ffa8 :
iscsiexe!FindDHCPServersThreadRoutine+0x72
00000000`00000000 : 00000000`00000000 00000000`00000000
00000000`00000000 00000000`00000000 : kernel32!BaseThreadStart+0x3a

This also points to iscsi as the root cause of this packet.

In any case we can prepare a fix, or just ignore it for now. (There
doesn't seem to be any damage, except that the packet is dropped).

Thanks
Tzachi

> -----Original Message-----
> From: Smith, Stan [mailto:stan.smith at intel.com]
> Sent: Wednesday, November 12, 2008 7:06 PM
> To: Tzachi Dar; Alex Estrin; ofw at lists.openfabrics.org
> Subject: RE: [ofw] assert on ipoib_port.c @ 3629
>
> Tzachi Dar wrote:
> > I'll try your suggestion, and let you know if it works or not.
> >
> > In any case, if I was not clear enough, this happens when
> the machine
> > is going up and not down, so I don't think that halt was
> called there.
>
> Can you provide more environmental details?
> So far I have rebooted 35 WinOF RC5 installed systems
> (win2k3/8/XP/Vista[x86,x64,ia64]) and not witnessed this
> problem? Yes - some systems were running a debug ipoib.sys.
> How do you reproduce it?
> What switches are in your fabric?
>
> Thanks,
>
> Stan.
>
>
> >
> > Thanks
> > Tzachi
> >
> >> -----Original Message-----
> >> From: Alex Estrin [mailto:alex.estrin at qlogic.com]
> >> Sent: Tuesday, November 11, 2008 11:03 PM
> >> To: Tzachi Dar; ofw at lists.openfabrics.org
> >> Subject: RE: [ofw] assert on ipoib_port.c @ 3629
> >>
> >> Tzachi,
> >>
> >>>
> >>> While rebooting a machine with our latest code I have
> received the
> >>> assert above:
> >>
> >> I think network can issue DHCPDISCOVER when adapter
> indicates connect
> >> status change: Please see ipoib_port.c @ lines
> 4573-4579.(rev. 1748).
> >> Reporting NDIS_STATUS_MEDIA_DISCONNECT/CONNECT to the
> Netowrk while
> >> port is destroying probably a bad idea.
> >> WDK doc chapter "Indicating Connection Status" says: "...
> >> Additional requirements for indicating media connection status
> >> changes for miniport drivers are as follows: ...
> >> Halting
> >> A miniport driver must not indicate any media connection status
> >> changes when NDIS calls MiniportHalt. "
> >>
> >> I wonder if network will try to send that bogus request on reboot
> >> with lines 4573-4579 removed.
> >>
> >> Thanks,
> >> Alex.
> >>
> > _______________________________________________
> > ofw mailing list
> > ofw at lists.openfabrics.org
> > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofw/attachments/20081112/bfe3d893/attachment.html>