es40-developers

[ES40-developers] FW: ES40 and TCPIP PING/SIZE=1785 failing (works up to 1784)

[Camiel V. <ca...@ca...>]

Hello developers,

Would any of you care to dive into this? Solving this problem might make the
ES40's networking functional at last.

Kind regards,

Camiel Vanderhoeven

-----Original Message-----
From: Volker Halle [mailto:Vol...@in...] 
To: Camiel Vanderhoeven
Subject: ES40 and TCPIP PING/SIZE=1785 failing (works up to 1784)

Camiel,

I wondered, why FTPing binary files did not work and tried a couple of PING
tests with the ES40 emulator. I seem to have stumbled over something:

If you use $ TCPIP PING/SIZE=n host to ping from the ES40 emulator to some
other node in the LAN by varying the ping packet size, everything works
fine, until you exceed n=1784. Then you can't get any successful ping
through !

If I look at an Ethereal packet trace for n=1784, I see one packet with 1514
bytes followed by another packet of 346 bytes on the wire.

For n=1785, I see the first packet with only 866 bytes, followed by a packet
of size 347, although the fragment offset for the 2nd packet correctly says
1480.

Trying to debug this should be much easier than trying to debug a hanging
FTP session...

Regards,

Volker Halle

 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4004 (20090413) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 

Re: [ES40-developers] FW: ES40 and TCPIP PING/SIZE=1785 failing (worksup to 1784)

[Hittner, D. T (IS) <dav...@ng...>]

Based on Volker's ethereal observations, I would guess that:

1) The NIC ring buffer processing is probably working OK, since it's
working up 1784, and had to have processed at least two ring buffers
correctly to get to that point.

2) It's likely, based on my SIMH VAX experience, that TCPIP is
performing a split buffer calculation on the ES40 that is returning
incorrect results, or isn't setting overflow/underflow flags correctly,
so it's branching incorrectly and thus setting the ring buffers wrong. I
couldn't get SIMH VAX network processing to work properly until a few
VAX instructions had been corrected as part of another patch; I didn't
have enough networking sources to debug it effectively.

Fortunately, Volker has found a reproducible breaking point!

A way to debug this might be to:

A) Set a breakpoint in the NIC transmission code when executing the PING
/PACKET_SIZE=1783 code, and see what is in the ring buffers.
B) Repeat with /PACKET_SIZE=1784, logging the ES40 instructions executed
during the (correct) transmission of the 1784 packet.
C) Repeat with /PACKET_SIZE=1785, logging the ES40 instructions executed
during the (incorrect) transmission of the 1785 packet.
D) Compare the two instruction streams and see where they deviate.

If they do, hand walk the operations just before and after the deviation
and see if you can spot the errata. If they don't differ, walk all of
the instructions :-( and see if they are setting values and
overflow/underflow processing correctly.

If you have the VMS sources for TCP/IP and/or the NIC drivers, you could
reduce the search by finding the packet splitting code for the ring
buffers and see what instructions need to be checked.

Alternatively, either the ES40 IDB or your local IDE might support
putting a watchpoint (when a data value is modified) on the ring buffer
data, so you can walk the instruction stream during the packet split and
fill.

Dave

> -----Original Message-----
> From: Camiel Vanderhoeven [mailto:ca...@ca...] 
> Sent: Monday, April 13, 2009 12:40 PM
> To: 'ES40 Developer Discussions'
> Subject: [ES40-developers] FW: ES40 and TCPIP PING/SIZE=1785 
> failing (worksup to 1784)
> 
> Hello developers,
> 
> Would any of you care to dive into this? Solving this problem 
> might make the ES40's networking functional at last.
> 
> Kind regards,
> 
> Camiel Vanderhoeven
> 
> -----Original Message-----
> From: Volker Halle [mailto:Vol...@in...]
> To: Camiel Vanderhoeven
> Subject: ES40 and TCPIP PING/SIZE=1785 failing (works up to 1784)
> 
> Camiel,
> 
> I wondered, why FTPing binary files did not work and tried a 
> couple of PING tests with the ES40 emulator. I seem to have 
> stumbled over something:
> 
> If you use $ TCPIP PING/SIZE=n host to ping from the ES40 
> emulator to some other node in the LAN by varying the ping 
> packet size, everything works fine, until you exceed n=1784. 
> Then you can't get any successful ping through !
> 
> If I look at an Ethereal packet trace for n=1784, I see one 
> packet with 1514 bytes followed by another packet of 346 
> bytes on the wire.
> 
> For n=1785, I see the first packet with only 866 bytes, 
> followed by a packet of size 347, although the fragment 
> offset for the 2nd packet correctly says 1480.
> 
> Trying to debug this should be much easier than trying to 
> debug a hanging FTP session...
> 
> Regards,
> 
> Volker Halle
> 
>  
> 
> __________ Information from ESET NOD32 Antivirus, version of 
> virus signature database 4004 (20090413) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>  
> 
> 
> --------------------------------------------------------------
> ----------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Es40-developers mailing list
> Es4...@li...
> https://lists.sourceforge.net/lists/listinfo/es40-developers
> 

[ES40-developers] latest cvs (4 weeks ago)

[Fausto S. <fa...@un...>]

Hello all,

I noticed Camiel updated cvs tree 4 weeks ago, so I created a 64bit version 
of es40 (under windows). This version is more stable than previous ones, I 
was able to install the bare openvms (without any other layered prods) 
without any problem.

I noticed a strange behaviour in one thing:

1) if I access the disk during the installation (i.e. to add a license) the 
installation fails with an access violation error.
2) the pagefile extension (during the first AUTOGEN phase) takes a lot of 
time and the installation suggests to create it manually disabling the "high 
watermark" (SET VOLUME/NOHIGH SYS$SYSTEM). Doing that the extension is very 
quick.
3) Installing the TCPIP prod I have an access violation error when replacing 
a module in DCLTABLES file.

I want to reinstall TCPIP using NOHIGH option, then test the DHCP.

I'll keep you informed about these tests.

Fausto 

Re: [ES40-developers] latest cvs (4 weeks ago)

[Hittner, D. T (IS) <dav...@ng...>]

Hi Fausto.

The ACCVIO errors during the OpenVMS install have been there since day
one.
A quick-and-dirty solution is to install OpenVMS on a disk image using
PersonalAlpha, and then start using ES40 with the pre-created disk
image.

Dave

-----Original Message-----
From: Fausto Saporito [mailto:fa...@un...] 
Sent: Saturday, April 18, 2009 3:35 AM
To: ES40 Developer Discussions
Subject: [ES40-developers] latest cvs (4 weeks ago)

Hello all,

I noticed Camiel updated cvs tree 4 weeks ago, so I created a 64bit
version 
of es40 (under windows). This version is more stable than previous ones,
I 
was able to install the bare openvms (without any other layered prods) 
without any problem.

I noticed a strange behaviour in one thing:

1) if I access the disk during the installation (i.e. to add a license)
the 
installation fails with an access violation error.
2) the pagefile extension (during the first AUTOGEN phase) takes a lot
of 
time and the installation suggests to create it manually disabling the
"high 
watermark" (SET VOLUME/NOHIGH SYS$SYSTEM). Doing that the extension is
very 
quick.
3) Installing the TCPIP prod I have an access violation error when
replacing 
a module in DCLTABLES file.

I want to reinstall TCPIP using NOHIGH option, then test the DHCP.

I'll keep you informed about these tests.

Fausto 


------------------------------------------------------------------------
------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Es40-developers mailing list
Es4...@li...
https://lists.sourceforge.net/lists/listinfo/es40-developers