pkg/35009: TME sun3 emulator asserts when running two emulators with ethernet

[sigmfsk%aol.com@localhost]

>Number:         35009
>Category:       pkg
>Synopsis:       TME sun3 emulator asserts when running two emulators with 
>ethernet
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 07 17:25:00 +0000 2006
>Originator:     arthur townsend
>Release:        3.0
>Organization:
>Environment:
3.0 for i386
>Description:
Simultaneously start two instances of tmesh, each running its own NetBSD 3.0 
drive.  The tmesh started first will assert with:

tmesh> assertion "(bpf->tme_bsd_bpf_delay_release.tv_sec == 
the_bpf_header.bh_tstamp.tv_sec) || ((bpf->tme_bsd_bpf_delay_release.tv_sec + 
1) == the_bpf_header.bh_tstamp.tv_sec)" failed: file "bsd-bpf.c", line 700, 
function "_tme_bsd_bpf_read"
[1]   Abort trap (core dumped) tmesh starthome.153


when the tmesh source code is changed to print values instead of assert, it 
prints the following under the same circumstances:

tmesh> bpf assert:see host/bsd/bsd-bpf.c:
bpf->tme_bsd_bpf_delay_release.tv_sec = 1162884363
the_bpf_header.bh_tstamp.tv_sec = 1345653653
bpf->tme_bsd_bpf_delay_release.tv_sec + 1 = 1162884364
the_bpf_header.bh_tstamp.tv_sec = 1345653653

(the numbers aren't always the same, but are always around those values)

But after the print, ethernet doesn't work inside the emulator, so there's not 
much advantage in not asserting.

It is easiest to see the problem when running two tmeshes, each running NetBSD 
1.5.3.

Start the first tmesh - but not configure ie0 inside the emulator, then at a 
later time, whenever the second tmesh is started, the first will immediately 
get the assertion.

But if ie0 is configued inside the first emulator "ifconfig ie0 192.168.2.11 
netmask 255.255.255.0" before the second tmesh is started, the first will not 
assert when the second is started.

Note that both tmeshes don't have to be running on the same computer - just 
running in the same network.

And a third tmesh can be started with just the first tmesh configuring ie0 (the 
second doesn't need to configure ie0 before the third is started).
>How-To-Repeat:

>Fix:
A workaround is:
  when using ethernet with TME, only start a second tmesh after the first tmesh 
on the network has had its ie0 configured inside the NetBSD it is running.

The following patch to 
  host/bsd/bsd-bpf.c
helps remind the user of this by providing a hopefully descriptive message 
before asserting.


--- bsd-bpf.c.orig      2006-10-30 10:00:15.000000000 -0500
+++ bsd-bpf.c   2006-11-07 06:06:54.000000000 -0500
@@ -694,10 +694,19 @@
                  < the_bpf_header.bh_tstamp.tv_usec))) {
 
        /* set the sleep time: */
+
+        /* if asserting, print likely description first */
+       if (! ((bpf->tme_bsd_bpf_delay_release.tv_sec
+                == the_bpf_header.bh_tstamp.tv_sec)
+               || ((bpf->tme_bsd_bpf_delay_release.tv_sec + 1)
+                   == the_bpf_header.bh_tstamp.tv_sec))) {
+          printf("someone started a second tmesh without this tmesh first 
configuring ie0\n");
+        }
        assert ((bpf->tme_bsd_bpf_delay_release.tv_sec
                 == the_bpf_header.bh_tstamp.tv_sec)
                || ((bpf->tme_bsd_bpf_delay_release.tv_sec + 1)
                    == the_bpf_header.bh_tstamp.tv_sec));
+
        bpf->tme_bsd_bpf_delay_sleep
          = (((bpf->tme_bsd_bpf_delay_release.tv_sec
               == the_bpf_header.bh_tstamp.tv_sec)