Re: Crash in softnet on SGI

[Jesse Darrone]

So even using the sq0 interface it continues to crash the same way.

In the name of science, I've also checked the bus speed on my 3 other
Challenge S systems and they are all 25mhz (including the one R4400
system I have).  The others are R5000 150 and 180 mhz.

-Jesse

On Mon, Jul 18, 2016 at 9:43 AM, Jesse Darrone  wrote:
> Hmm, that's curious.  I do have 4 of these with slightly different
> configurations (even one that is tandem badged), so I could see if the
> bus speed is the same or different across all of them.  I realize it
> might not be all that valuable other than to satisfy some curiosity,
> but an interesting data-point nonetheless.
>
> As far as troubleshooting goes, I'll try and switch to the primary
> interface to see if it makes a difference (maybe we can rule something
> out?).  I was only using the secondary so I wouldn't need to employ an
> external transceiver.
>
> -Jesse
>
>
> On Mon, Jul 18, 2016 at 2:46 AM, Miod Vallat  wrote:
>>> It crashed again last night so I rebuilt the kernel with your patch.
>>> Both hpc0 and hpc1 now report 25 mhz.  I've attached the full dmesg
>>> below for reference.
>>
>> I was wondering if your system had a 33MHz GIO bus and was incorrectly
>> using the 25MHz settings. But since the diff now reports 25MHz, the
>> settings do not change and the diff doesn't change anything.
>>
>> I am a bit surprised, because here my R5000 Indy has a 33MHz GIO bus
>> while all the R4000/R4400 Indys have 25MHz GIO buses, so I would naively
>> expect your R5000 Challenge S system to also use a 33MHz flavour; but
>> there might be good reasons for things to be this way (also, maybe SGI
>> used 25MHz buses for the R5000 model initially, and only switched to
>> 33MHz months or years later).
>>
>> Back to square one...

Re: minor wording in man release.8

[Jason McIntyre]

On Fri, Jul 22, 2016 at 06:45:35PM +0200, Tim Kuijsten wrote:
> Index: release.8
> ===
> RCS file: /cvs/src/share/man/man8/release.8,v
> retrieving revision 1.70
> diff -u -p -r1.70 release.8
> --- release.8   31 Jul 2015 11:30:12 -  1.70
> +++ release.8   22 Jul 2016 16:43:58 -
> @@ -101,7 +101,8 @@ $ cd PORTSPATH && cvs up -r TAG -Pd
>  .Pp
>  Replace
>  .Va XSRCDIR
> -with the path to your X Window System sources.
> +with the path to your X Window System sources, typically
> +.Pa /usr/xenocara .
>  Replace
>  .Va PORTSPATH
>  with the path to your ports tree sources, typically
> 

i think this is reasonable. we do already document it in this file, but
the organisation is not so great. but if we do this, it allows us to
skip a bit of text earlier in the page.

hence i propose the diff below.
jmc

Index: release.8
===
RCS file: /cvs/src/share/man/man8/release.8,v
retrieving revision 1.73
diff -u -r1.73 release.8
--- release.8   26 Jun 2016 15:17:43 -  1.73
+++ release.8   22 Jul 2016 21:24:24 -
@@ -40,13 +40,7 @@
 .Pp
 The following sections describe each of the required steps in detail.
 .Pp
-Commands to be run as a user with write permissions on the source and
-ports trees
-.Pf ( Pa /usr/src
-and
-.Pa /usr/ports
-respectively)
-are preceded by a dollar sign
+Commands to be run as a user are preceded by a dollar sign
 .Pq Sq $ .
 Commands that must be run as the superuser are preceded by a hash mark
 .Pq Sq # .
@@ -101,7 +95,8 @@
 .Pp
 Replace
 .Va XSRCDIR
-with the path to your X Window System sources.
+with the path to your X Window System sources, typically
+.Pa /usr/xenocara .
 Replace
 .Va PORTSPATH
 with the path to your ports tree sources, typically

minor wording in man release.8

[Tim Kuijsten]

Index: release.8
===
RCS file: /cvs/src/share/man/man8/release.8,v
retrieving revision 1.70
diff -u -p -r1.70 release.8
--- release.8   31 Jul 2015 11:30:12 -  1.70
+++ release.8   22 Jul 2016 16:43:58 -
@@ -101,7 +101,8 @@ $ cd PORTSPATH && cvs up -r TAG -Pd
 .Pp
 Replace
 .Va XSRCDIR
-with the path to your X Window System sources.
+with the path to your X Window System sources, typically
+.Pa /usr/xenocara .
 Replace
 .Va PORTSPATH
 with the path to your ports tree sources, typically

Re: ddb on armv7 beaglebone black

[Jonathan Gray]

On Fri, Jul 22, 2016 at 05:30:13PM +0300, Lars Noodn wrote:
> I'm getting errors with clean installs of the latest armv7 snapshot
> (Build date: 1469162775 - Fri Jul 22 04:46:15 UTC 2016) on a
> beaglebone black.  It ends up at a ddb prompt quite late in the boot
> process.  I've tried re-installation a half dozen times or so, booting
> each time to an error, though every once in a while it has gone
> through to a login prompt but I cannot find the pattern yet. The
> device also now tries to boot from the SD now rather than the built-in
> flash, so if I leave the SD in, I get the installer every time and
> have to remove it to get the built-in flash.
> 
> /Lars

The changes there were recently backed out
http://marc.info/?l=openbsd-cvs=146918611604557=2

Give the next snapshot a try when it appears in a day or two.

> 
> ...
> starting early daemons: syslogd pflogd ntpd.
> starting RPC daemons:.
> savecore: no core dump
> checking quotas: done.
> clearing /tmp
> kern.securelevel: 0 -> 1
> creating runtime link editor directory cache.
> preserving editor files.
> 
> uvm_fault(0xc92e75f0, 0, 1, 0) -> e
> Fatal kernel mode data abort: 'Translation Fault (P)'
> trapframe: 0xcb331d80
> DFSR=0007, DFAR=, spsr=6013
> r0 =cb331e60, r1 =cb331e64, r2 =, r3 =c92772a0
> r4 =, r5 =cb331e64, r6 =c92772a0, r7 =
> r8 =cb331e60, r9 =c06a8b54, r10=c06a8b54, r11=cb331dfc
> r12=cb331e00, ssp=cb331dd4, slr=c050a058, pc =c0509bfc
> 
> Stopped at  in6_selectsrc+0x14: ldrbr12, [r4]
> ddb> ps
>TID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
>  85993  17072  17072  0  2   0ntpd
> *34450  17072  17072 83  70x100010ntpd
>  32541  73818  73818  0  2 0x3perl
>  96177  75510  17072 83  30x100090  poll  ntpd
>  75510  17072  17072 83  30x100090  poll  ntpd
>  17072  1  17072  0  30x80  poll  ntpd
>  60851   7308   7308 74  30x100090  bpf   pflogd
>   7308  1   7308  0  30x80  netio pflogd
>  58622  83495  83495 73  20x100090syslogd
>  83495  1  83495  0  30x100080  netio syslogd
>  49500  1  49500 77  30x100090  poll  dhclient
>  15366  1  15366  0  30x80  poll  dhclient
>  73818  1  73818  0  30x10008b  pause sh
>  33201  0  0  0  2 0x14200zerothread
>  38418  0  0  0  3 0x14200  aiodoned  aiodoned
>  49637  0  0  0  3 0x14200  syncerupdate
>  44514  0  0  0  3 0x14200  cleaner   cleaner
>  73832  0  0  0  3 0x14200  reaperreaper
>  67925  0  0  0  3 0x14200  pgdaemon  pagedaemon
>  76330  0  0  0  3 0x14200  bored crynlk
>   3071  0  0  0  3 0x14200  bored crypto
>  22994  0  0  0  3 0x14200  pftm  pfpurge
>  53492  0  0  0  3 0x14200  mmctsksdmmc1
>882  0  0  0  3 0x14200  mmctsksdmmc0
>  14526  0  0  0  3 0x14200  bored softnet
>  14171  0  0  0  3 0x14200  bored systqmp
>  10775  0  0  0  3 0x14200  bored systq
>  70072  0  0  0  3  0x40014200idle0
>  70962  0  0  0  3 0x14200  kmalloc   kmthread
>  1  0  1  0  30x82  wait  init
>  0 -1  0  0  3 0x10200  scheduler swapper
> ddb> trace
> in6_selectsrc+0xc
> scp=0xc0509bf4 rlv=0xc050a058 (in6_pcbselsrc+0x240)
> rsp=0xcb331e00 rfp=0xcb331e54
> r10=0xc06a8b54 r8=0xcb331e60 r7=0x r6=0xc92772a0
> r5=0xcb331e64 r4=0x
> in6_pcbselsrc+0xc
> scp=0xc0509e24 rlv=0xc050568c (in6_pcbconnect+0xf8)
> rsp=0xcb331e58 rfp=0xcb331ea8
> r10=0xc06a8b54 r9=0xc9277258 r8=0xcb331e6c r7=0xc921e9c4
> r6=0xc9277284 r5=0xc9277258 r4=0xcb331e64
> in6_pcbconnect+0xc
> scp=0xc05055a0 rlv=0xc047542c ($a+0x448)
> rsp=0xcb331eac rfp=0xcb331eec
> r10=0xc91bc5bc r8=0x0004 r7=0xc921e9c4 r6=0xc9223400
> r5=0xc90c3004 r4=0x
> tcp_usrreq+0x10
> scp=0xc0474e6c rlv=0xc03dd3fc (soconnect+0xb4)
> rsp=0xcb331ef0 rfp=0xcb331f1c
> r10=0xbffd8bf8 r9=0x0004 r8=0xc069a854 r7=0x
> r6=0xc9223400 r5=0x r4=0xc91bc5bc
> soconnect+0xc
> scp=0xc03e15ec rlv=0xc0537ffc (swi_handler+0x174)
> rsp=0xcb331f50 rfp=0xcb331fac
> r8=0x0062 r7=0xc921e9c4 r6=0xcb331fb0 r5=0x0003
> r4=0xcb331fb4
> swi_handler+0xc
> scp=0xc0537e94 rlv=0xc053a5b0 (swi_entry+0x28)
> rsp=0xcb331fb0 rfp=0xbffd8bc8
> r10=0xbffd8bf8 r9=0x49bcf6a0 r8=0x001c 

ddb on armv7 beaglebone black

[Lars Noodén]

I'm getting errors with clean installs of the latest armv7 snapshot
(Build date: 1469162775 - Fri Jul 22 04:46:15 UTC 2016) on a
beaglebone black.  It ends up at a ddb prompt quite late in the boot
process.  I've tried re-installation a half dozen times or so, booting
each time to an error, though every once in a while it has gone
through to a login prompt but I cannot find the pattern yet. The
device also now tries to boot from the SD now rather than the built-in
flash, so if I leave the SD in, I get the installer every time and
have to remove it to get the built-in flash.

/Lars

...
starting early daemons: syslogd pflogd ntpd.
starting RPC daemons:.
savecore: no core dump
checking quotas: done.
clearing /tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.

uvm_fault(0xc92e75f0, 0, 1, 0) -> e
Fatal kernel mode data abort: 'Translation Fault (P)'
trapframe: 0xcb331d80
DFSR=0007, DFAR=, spsr=6013
r0 =cb331e60, r1 =cb331e64, r2 =, r3 =c92772a0
r4 =, r5 =cb331e64, r6 =c92772a0, r7 =
r8 =cb331e60, r9 =c06a8b54, r10=c06a8b54, r11=cb331dfc
r12=cb331e00, ssp=cb331dd4, slr=c050a058, pc =c0509bfc

Stopped at  in6_selectsrc+0x14: ldrbr12, [r4]
ddb> ps
   TID   PPID   PGRPUID  S   FLAGS  WAIT  COMMAND
 85993  17072  17072  0  2   0ntpd
*34450  17072  17072 83  70x100010ntpd
 32541  73818  73818  0  2 0x3perl
 96177  75510  17072 83  30x100090  poll  ntpd
 75510  17072  17072 83  30x100090  poll  ntpd
 17072  1  17072  0  30x80  poll  ntpd
 60851   7308   7308 74  30x100090  bpf   pflogd
  7308  1   7308  0  30x80  netio pflogd
 58622  83495  83495 73  20x100090syslogd
 83495  1  83495  0  30x100080  netio syslogd
 49500  1  49500 77  30x100090  poll  dhclient
 15366  1  15366  0  30x80  poll  dhclient
 73818  1  73818  0  30x10008b  pause sh
 33201  0  0  0  2 0x14200zerothread
 38418  0  0  0  3 0x14200  aiodoned  aiodoned
 49637  0  0  0  3 0x14200  syncerupdate
 44514  0  0  0  3 0x14200  cleaner   cleaner
 73832  0  0  0  3 0x14200  reaperreaper
 67925  0  0  0  3 0x14200  pgdaemon  pagedaemon
 76330  0  0  0  3 0x14200  bored crynlk
  3071  0  0  0  3 0x14200  bored crypto
 22994  0  0  0  3 0x14200  pftm  pfpurge
 53492  0  0  0  3 0x14200  mmctsksdmmc1
   882  0  0  0  3 0x14200  mmctsksdmmc0
 14526  0  0  0  3 0x14200  bored softnet
 14171  0  0  0  3 0x14200  bored systqmp
 10775  0  0  0  3 0x14200  bored systq
 70072  0  0  0  3  0x40014200idle0
 70962  0  0  0  3 0x14200  kmalloc   kmthread
 1  0  1  0  30x82  wait  init
 0 -1  0  0  3 0x10200  scheduler swapper
ddb> trace
in6_selectsrc+0xc
scp=0xc0509bf4 rlv=0xc050a058 (in6_pcbselsrc+0x240)
rsp=0xcb331e00 rfp=0xcb331e54
r10=0xc06a8b54 r8=0xcb331e60 r7=0x r6=0xc92772a0
r5=0xcb331e64 r4=0x
in6_pcbselsrc+0xc
scp=0xc0509e24 rlv=0xc050568c (in6_pcbconnect+0xf8)
rsp=0xcb331e58 rfp=0xcb331ea8
r10=0xc06a8b54 r9=0xc9277258 r8=0xcb331e6c r7=0xc921e9c4
r6=0xc9277284 r5=0xc9277258 r4=0xcb331e64
in6_pcbconnect+0xc
scp=0xc05055a0 rlv=0xc047542c ($a+0x448)
rsp=0xcb331eac rfp=0xcb331eec
r10=0xc91bc5bc r8=0x0004 r7=0xc921e9c4 r6=0xc9223400
r5=0xc90c3004 r4=0x
tcp_usrreq+0x10
scp=0xc0474e6c rlv=0xc03dd3fc (soconnect+0xb4)
rsp=0xcb331ef0 rfp=0xcb331f1c
r10=0xbffd8bf8 r9=0x0004 r8=0xc069a854 r7=0x
r6=0xc9223400 r5=0x r4=0xc91bc5bc
soconnect+0xc
scp=0xc03e15ec rlv=0xc0537ffc (swi_handler+0x174)
rsp=0xcb331f50 rfp=0xcb331fac
r8=0x0062 r7=0xc921e9c4 r6=0xcb331fb0 r5=0x0003
r4=0xcb331fb4
swi_handler+0xc
scp=0xc0537e94 rlv=0xc053a5b0 (swi_entry+0x28)
rsp=0xcb331fb0 rfp=0xbffd8bc8
r10=0xbffd8bf8 r9=0x49bcf6a0 r8=0x001c r7=0x4f8cf7a0
r6=0x0004 r5=0x r4=0x49e40e80
ddb> dmesg
ranslation Fault (P)'
trapframe: 0xcb331d80
DFSR=0007, DFAR=, spsr=6013
r0 =cb331e60, r1 =cb331e64, r2 =, r3 =c92772a0
r4 =, r5 =cb331e64, r6 =c92772a0, r7 =
r8 =cb331e60, r9 =c06a8b54, r10=c06a8b54, r11=cb331dfc
r12=cb331e00, ssp=cb331dd4, slr=c050a058, pc =c0509bfc

Stopped at  

ipv6 issue on current snapshot

[Heiko]

Hello Developer Team,

in current snapshot since yesterday seems ipv6 to be broken. With cvs 2
days ago all is working fine.

I can't connect out. ping6 to all external ipv6 is broken. No error
message. Internal ping6 2a01:4f8:160:4346::157:76 is ok. Ping6 to
gateway fe80::1%re0 is also broken.

my hostname.re0:
inet 176.9.157.76  255.255.255.224
inet alias 88.198.37.253 255.255.255.248
inet alias 176.9.157.80.
!route add 88.198.37.249 88.198.37.253
inet6 2a01:4f8:160:4346::2 64
inet6 alias 2a01:4f8:160:4346::157:76 64
inet6 alias 2a01:4f8:160:4346::37:253 64
inet6 alias 2a01:4f8:160:4346::157:80 64
!route add -inet6 default fe80::1%re0

Regards
Heiko

Re: networking related freeze with -current

[Martin Pieuchot]

On 21/07/16(Thu) 17:22, Dimitris Papastamos wrote:
> On Thu, Jul 21, 2016 at 11:27:17AM +0100, Stuart Henderson wrote:
> > On 2016/07/21 11:16, Dimitris Papastamos wrote:
> > > Hi,
> > > 
> > > I use tinc-vpn on my laptop and noticed that when I reboot or halt
> > > the system, it freezes when it tries to stop the tinc daemon.
> > > 
> > > This is reproducible with today's current.
> > 
> > Would you notice if it was a panic rather than a freeze?
> 
> Ok, so I reproduced it and entered ddb.  I typed the trace
> output below.

Thanks for your help tracking this down.  The problem is that we try
to delete a route that is no longer in the tree and since the loop
didn't check for the return error we try indefinitely.

Diff below fixes that for me.


Index: net/route.c
===
RCS file: /cvs/src/sys/net/route.c,v
retrieving revision 1.312
diff -u -p -r1.312 route.c
--- net/route.c 19 Jul 2016 10:26:41 -  1.312
+++ net/route.c 22 Jul 2016 09:26:25 -
@@ -688,8 +688,9 @@ rtflushclone1(struct rtentry *rt, void *
return 0;
 
if (ISSET(rt->rt_flags, RTF_CLONED) && rtequal(rt->rt_parent, parent)) {
-   rtdeletemsg(rt, ifp, id);
-   error = EAGAIN;
+   error = rtdeletemsg(rt, ifp, id);
+   if (error == 0)
+   error = EAGAIN;
} else
error = 0;
 
@@ -1725,13 +1726,16 @@ int
 rt_if_remove_rtdelete(struct rtentry *rt, void *vifp, u_int id)
 {
struct ifnet*ifp = vifp;
+   int  error;
 
-   if (rt->rt_ifidx == ifp->if_index) {
-   rtdeletemsg(rt, ifp, id);
-   return (EAGAIN);
-   }
+   if (rt->rt_ifidx != ifp->if_index)
+   return (0);
+
+   if ((error = rtdeletemsg(rt, ifp, id)))
+   return (error);
+
+   return (EAGAIN);
 
-   return (0);
 }
 
 #ifndef SMALL_KERNEL
@@ -1785,7 +1789,10 @@ rt_if_linkstate_change(struct rtentry *r
 * new routes from a better source.
 */
if (ISSET(rt->rt_flags, RTF_CLONED|RTF_DYNAMIC)) {
-   rtdeletemsg(rt, ifp, id);
+   int error;
+
+   if ((error = rtdeletemsg(rt, ifp, id)))
+   return (error);
return (EAGAIN);
}
/* take route down */

Re: networking related freeze with -current

[Philip Guenther]

On Thu, 21 Jul 2016, Dimitris Papastamos wrote:
> On Thu, Jul 21, 2016 at 11:27:17AM +0100, Stuart Henderson wrote:
> > On 2016/07/21 11:16, Dimitris Papastamos wrote:
> > > Hi,
> > > 
> > > I use tinc-vpn on my laptop and noticed that when I reboot or halt
> > > the system, it freezes when it tries to stop the tinc daemon.
> > > 
> > > This is reproducible with today's current.
> > 
> > Would you notice if it was a panic rather than a freeze?
> 
> Ok, so I reproduced it and entered ddb.  I typed the trace
> output below.
>
> --- interrupt ---
> srp_enter() at srp_enter+0x5c
> art_table_walk() at art_table_walk+0x197

In ddb, can you snag the output of "show reg", or at least the %rax, %rsi, 
and %rdx values?


Philip Guenther