Networking

[James Tabor]

Hi,
Here is some networking dumps, I have a rtl8029 with io D000 and irq B,

(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
ne2000!NICIndicatePacket: Indicating (64) bytes.
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(io/irp.c:877) Thread with dead IRPs!Assertion FALSE failed at io/irp.c:878
Entered debugger on embedded INT3 at 0x0008:0x800058e3.
kdb:> bt
Eip:
<ntoskrnl.exe:58e4 (ke/i386/brkpoint.c:31 (DbgBreakPoint))>
Frames:
<ntoskrnl.exe:4c63e (io/irp.c:881 (IoCancelThreadIo))>
<ntoskrnl.exe:7f603 (ps/kill.c:308 (PspExitThread))>
<ntoskrnl.exe:7f9ca (ps/kill.c:500 (NtTerminateProcess))>
<ntoskrnl.exe:36d2 (/tmp/cctdxNWF.s:180 (KiSystemService))>
<kernel32.dll:27e20 (process/proc.c:593 (ExitProcess))>
<ping.EXE:11f6>
<ping.EXE:1238>
<kernel32.dll:289b1 (process/create.c:331 (BaseProcessStart))>
<deadbeef>
kdb:> cont
ne2000!NICIndicatePacket: Indicating (142) bytes.
ne2000!NICIndicatePacket: Indicating (142) bytes.
LAN WORKER BUSY 9e3e0390 80e10c18
ne2000!NICIndicatePacket: Indicating (142) bytes.
LAN WORKER BUSY 9e3e0390 80e12738
ne2000!NICIndicatePacket: Indicating (142) bytes.
LAN WORKER BUSY 9e3e0390 80e187f8
ne2000!NICIndicatePacket: Indicating (64) bytes.
LAN WORKER BUSY 9e3e0390 80e1ecb8
ne2000!NICIndicatePacket: Indicating (64) bytes.
LAN WORKER BUSY 9e3e0390 80e2cd28
ne2000!NICIndicatePacket: Indicating (142) bytes.
LAN WORKER BUSY 9e3e0390 80e73c80
ne2000!NICIndicatePacket: Indicating (142) bytes.
LAN WORKER BUSY 9e3e0390 80ef4b30
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0
(io/irp.c:877) Thread with dead IRPs!Assertion FALSE failed at io/irp.c:878
Entered debugger on embedded INT3 at 0x0008:0x800058e3.
kdb:> bt
Eip:
<ntoskrnl.exe:58e4 (ke/i386/brkpoint.c:31 (DbgBreakPoint))>
Frames:
<ntoskrnl.exe:4c63e (io/irp.c:881 (IoCancelThreadIo))>
<ntoskrnl.exe:7f603 (ps/kill.c:308 (PspExitThread))>
<ntoskrnl.exe:7f9ca (ps/kill.c:500 (NtTerminateProcess))>
<ntoskrnl.exe:36d2 (/tmp/cctdxNWF.s:180 (KiSystemService))>
<kernel32.dll:27e20 (process/proc.c:593 (ExitProcess))>
<ping.EXE:11f6>
<ping.EXE:1238>
<kernel32.dll:289b1 (process/create.c:331 (BaseProcessStart))>
<deadbeef>
kdb:> cont
ne2000!NICIndicatePacket: Indicating (64) bytes.
(dispatch.c:166)(dispatch) Select: 0
ne2000!NICIndicatePacket: Indicating (142) bytes.
ne2000!NICIndicatePacket: Indicating (142) bytes.
LAN WORKER BUSY 9e3e0390 812618f8
(dispatch.c:166)(dispatch) Select: 0
(dispatch.c:166)(dispatch) Select: 0

[WaxDragon]

You are very likely seeing the same problems I am.  If you have tcpip
debugging on, you may see messages like this:

(tcpip/main.c:559)(TiDispatch) Called. IRP is at (0x809189A8).
(tcpip/main.c:575)(TiDispatch) TCP_QUERY_INFORMATION_EX
(tcpip/dispatch.c:1248)(DispTdiQueryInformationEx) Called.
(tcpip/dispatch.c:1351)(DispTdiQueryInformationEx) InputBufferLength
36 OutputBufferLength 0
(tcpip/info.c:143)(InfoTdiQueryInformationEx) InfoEx Req: 100 100 0!0000:0
(tcpip/info.c:84)(InfoTdiQueryListEntities) About to copy 3 TDIEntityIDs to user
(tcpip/info.c:186)(InfoTdiQueryInformationEx) Status: c0000023
(tcpip/dispatch.c:1396)(DispTdiQueryInformationEx) Leaving. Status =
(0xC0000023)
(tcpip/dispatch.c:1399)(DispTdiQueryInformationEx) Leaving. Status =
(0xC0000023)
(tcpip/main.c:602)(TiDispatch) Leaving. Status = (0xC0000023).
(tcpip/irp.c:21)(IRPFinish) Called: Irp 809189a8, Status c0000023 Event 80b9cdac


On 5/9/05, James Tabor
<jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net> wrote:
>   Hi,
>  Here is some networking dumps, I have a rtl8029 with io D000 and irq B,
<snip>

I've emailed arty the details of what I have already.  c0000023 is
STATUS_BUFFER_TOO_SMALL.

WD

-- 
"<arty> the tree was touched a lot recently"

[James Tabor]

Hi WD!
WaxDragon wrote:
>   You are very likely seeing the same problems I am.  If
> you have tcpip
>  debugging on, you may see messages like this:
>   
Wow, its funny, ping.exe both of them still resident in memory. I executed them
minutes before the kernel debugs. Strange stuff!?! 8^o dazed and in awe, wow can
you see the nice colors!
James

[Hartmut Birr]

James Tabor wrote:

>   Hi WD!
>  WaxDragon wrote:
>
> >   You are very likely seeing the same problems I
> > am.  If you have tcpip
> >  debugging on, you may see messages like this:
> >  
>  Wow, its funny, ping.exe both of them still resident in memory. I
>  executed them
>  minutes before the kernel debugs. Strange stuff!?! 8^o dazed and in
>  awe, wow can
>  you see the nice colors!
>  James 
That's a result of rev 15069. If a irp is created by
IoBuildDeviceIoControlRequest or IoBuildSynchronousFsdRequest, it must
be always completed by IoCompleteRequest. The changes from rev. 15069
bypass a part of IoCompleteRequest if the irp was canceled. The irp is
still on the threads irp list. A terminated threads waits some time for
completion of all irps on the thread list. If not all irps are removed,
ros does  bucheck. While the waiting time,  you can see ping in memory.

- Hartmut

[Alex Ionescu]

WaxDragon wrote:

>  
> I've emailed arty the details of what I have already.  c0000023 is
> STATUS_BUFFER_TOO_SMALL.
>
> WD
>
>   
>  
Art and I have found the problem. Art was failing the IRP with 
STATUS_BUFFER_TOOS_AMALL and expecting the I/O Manager to fill in 
UserIosb->Information, so that the usermode application could then 
request the correct number of bytes. Since this does not happen on 
NT/ROS (the source of much heated discussion :P), it fails after my 
patches. After some analysis of 3rd-party drivers and some reading, the 
solutions are either:

1) return STATUS_BUFFER_OVERFLOW which is a 'warning', so the IO manager 
will write the stuff back. But this would break compatibility with apsp 
which use TDI directly to query this information
2) do like I have seen other 3rd-part drivers do, which is to wrap in 
SEH somethign along: *Irp->UserIosb = Irp->IoStatus; and then return 
STATUS_BUFFER_OVERFLOW. After testing, I can confirm method #2...Art 
will be fixing this.

I want to mention this in case anyone is aware of any other of our 
drivers which does this trick and hopes the I/O manager will return the 
UserIosb (it did befor emy changes). I'll grep the tree for any 
STATUS_BUFFER_OVERFLOW in /drivers myself.

Best regards,
Alex Ionescu

[Alex Ionescu]

Alex Ionescu wrote:

>   WaxDragon wrote:
>
>
>  2) do like I have seen other 3rd-part drivers do, which is to wrap in 
>  SEH somethign along: *Irp->UserIosb = Irp->IoStatus; and then return 
>  STATUS_BUFFER_OVERFLOW.  
My bad, this shoudl be STATUS_BUFFER_TOO_SMALL.

>   After testing, I can confirm method #2...Art will be
> fixing this. 
Best regards,
Alex Ionescu