Hi again,
During my last testing I could further limit the time frame where the
change was introduced:
I got a "working" IP22 kernel for my CVS sandbox updated to "21 Jun 2014
05:38:28" and a "non-working" kernel when updating to "23 Jun 2014
18:54:33" (both pre 5.6).
BTW, the OpenBSD 6.0 release kernel is also "non-working".
"working" means: kernel successfully completes reverse ARP and boots to
multi-user.
"non-working" means: kernel panics with "panic: reverse arp not answered
by rarpd(8) or dhcpd(8)" though the RARP requests are actually answered.
Between the dates mentioned above the following files were changed:
```
# cvs update -d -R -C -D "23 Jun 2014 18:54:33" 2>&1 | grep -v '^cvs'
P arch/i386/conf/GENERIC
P dev/acpi/acpi.c
P dev/acpi/dsdt.c
P kern/kern_malloc.c
P kern/kern_sig.c
P msdosfs/msdosfs_vfsops.c
P net/if.c
P netinet/udp_usrreq.c
P uvm/uvm_km.c
```
I started with reverting the patch to `net/if.c` and the resulting
kernel is now "working".
The differences for this file between the mentioned dates are:
```
# cvs diff -N -c -D "21 Jun 2014 05:38:28" -D "23 Jun 2014 18:54:33"
net/if.c
Index: net/if.c
===================================================================
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.290
retrieving revision 1.291
diff -u -p -c -r1.290 -r1.291
cvs server: conflicting specifications of output style
*** net/if.c 7 Jun 2014 11:04:14 -0000 1.290
--- net/if.c 23 Jun 2014 18:51:15 -0000 1.291
***************
*** 1,4 ****
! /* $OpenBSD: if.c,v 1.290 2014/06/07 11:04:14 henning Exp $ */
/* $NetBSD: if.c,v 1.35 1996/05/07 05:26:04 thorpej Exp $ */
/*
--- 1,4 ----
! /* $OpenBSD: if.c,v 1.291 2014/06/23 18:51:15 henning Exp $ */
/* $NetBSD: if.c,v 1.35 1996/05/07 05:26:04 thorpej Exp $ */
/*
*************** if_attach(struct ifnet *ifp)
*** 422,427 ****
--- 422,430 ----
TAILQ_INSERT_BEFORE(before, ifp, if_list);
#else
TAILQ_INSERT_TAIL(&ifnet, ifp, if_list);
+ #endif
+ #ifdef INET6
+ ifp->if_xflags |= IFXF_NOINET6;
#endif
m_clinitifp(ifp);
```
Does anyone have an idea, why this (possibly in combination with other
code) would break reverse ARP on a SGI Indy w/R4400?
By removing the above three lines from `net/if.c` in my 5.6 CVS sandbox
updated to the date "Fri Dec 19 17:14:39 2014 UTC" (`net/if.c` =>
r1.309) I could get a post 5.6 IP22 kernel that successfully completes
reverse ARP. The next patch ([1]) to this file removes those three lines
anyhow but adds other code and the resulting kernel again stops working:
[1]:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/if.c.diff?r1=1.309&r2=1.310
```
[...]
Initial setup done, switching console.
[ using 327064 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.
http://www.OpenBSD.org
OpenBSD 5.7-beta (GENERIC-IP22) #1: Sat Sep 3 16:50:38 MDT 2016
r...@octane2.domain.tld:/sd2a/5.6/src/sys/arch/sgi/compile/GENERIC-IP22
real mem = 201326592 (192MB)
rsvd mem = 802816 (1MB)
avail mem = 193757184 (184MB)
warning: no entropy supplied by boot loader
mainbus0 at root: Indy
cpu0 at mainbus0: MIPS R4400 CPU rev 3.0 150 MHz, R4010 FPC rev 0.0
cpu0: cache L1-I 16KB D 16KB direct, L2 1024KB direct
[...]
boot device: sq0
nfs_boot: using interface sq0, with revarp & bootparams
panic: reverse arp not answered by rarpd(8) or dhcpd(8)
Stopped at Debugger+0x4: jr ra
Debugger+0x8: nop
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb> show panic
reverse arp not answered by rarpd(8) or dhcpd(8)
ddb> trace
Debugger+0x4 (2a039afd05d0ead8,900000001fbd9880,900000001fbd9830,713)
ra 0xfff
fffff888b4750 sp 0xffffffff88007d60, sz 0
panic+0x100 (2a039afd05d0ead8,1,ffffffff88b6f4d8,ffffffff88bf9530) ra
0xffffff
ff889aa9a8 sp 0xffffffff88007d60, sz 112
nfs_boot_init+0x5f8
(2a039afd05d0ead8,1,ffffffff88b6f4d8,ffffffff88bf9530) ra 0
xffffffff889c1150 sp 0xffffffff88007dd0, sz 240
nfs_mountroot+0x68
(2a039afd05d0ead8,1,ffffffff88b6f4d8,ffffffff88bf9530) ra 0
xffffffff8887d5a0 sp 0xffffffff88007ec0, sz 208
main+0xd68 (2a039afd05d0ead8,1,ffffffff88b6f4d8,ffffffff88bf9530) ra
0xfffffff
f88800098 sp 0xffffffff88007f90, sz 48
kernel_text+0x98 (2a039afd05d0ead8,1,ffffffff88b6f4d8,ffffffff88bf9530)
ra 0x0
sp 0xffffffff88007fc0, sz 0
User-level: pid 0
ddb>
```
Bye
Frank
On 09/02/2016 03:03 PM, Frank Scheiner wrote:
Hi all,
Small update from my side: I'm currently trying to determine the exact
patch or patch set that is responsible for the described problem.
[...]
