Re: octeon snapshots

[jungle boogie]

Thus said Pedro Caetano on Mon, 14 May 2018 22:40:40 +0100

Hi misc@,

I've been using a edge router lite for the past one and a half year as my
home router. (providing a few network services, besides that it has an
ipsec tunnel setup similar to dn42.net implementation)

I'm running a few daemons, mostly from base:
nsd, unbound, ntpd, bgpd, isakmpd, dhcpd, relayd, httpd, slowcgi, rtadvd
And a few from ports:
vnstatd, igmpproxy, arpwatch


In the last 30 days, a strange behaviour has been introduced on this device.

When the system is upgraded, either using bsd.rd or doing a binary upgrade,
*sometimes* the system livelocks.
One is able to login using the serial console, but shortly after a massive
slowdown occurs, rendering the system unusable.

Powercycling makes the box usable again. Sometimes not on the first try.

Unfortunately, I haven't been able to spot any interesting message on dmesg
and/or logfiles.

Please let me know what additional information is needed in order to debug
this.


Does it seem to take a certain number of days before the system slow 
down occurs, or can it happen after a few hours of uptime?

octeon snapshots

[Pedro Caetano]

Hi misc@,

I've been using a edge router lite for the past one and a half year as my
home router. (providing a few network services, besides that it has an
ipsec tunnel setup similar to dn42.net implementation)

I'm running a few daemons, mostly from base:
nsd, unbound, ntpd, bgpd, isakmpd, dhcpd, relayd, httpd, slowcgi, rtadvd
And a few from ports:
vnstatd, igmpproxy, arpwatch


In the last 30 days, a strange behaviour has been introduced on this device.

When the system is upgraded, either using bsd.rd or doing a binary upgrade,
*sometimes* the system livelocks.
One is able to login using the serial console, but shortly after a massive
slowdown occurs, rendering the system unusable.

Powercycling makes the box usable again. Sometimes not on the first try.

Unfortunately, I haven't been able to spot any interesting message on dmesg
and/or logfiles.

Please let me know what additional information is needed in order to debug
this.

Ping (from a workstation) has a strange behaviour when the router is
affected.
(for brevity sake duplicated host unreachable and network unreachable have
been redacted)



Thank you for any help,
Pedro Caetano




















































































































































































































*pcaetano@gpd-pocket ~ % ping 10.254.254.1PING 10.254.254.1 (10.254.254.1)
56(84) bytes of data.From 10.254.254.102 icmp_seq=1 Destination Host
Unreachable(...)64 bytes from 10.254.254.1 :
icmp_seq=539 ttl=255 time=1.63 ms64 bytes from 10.254.254.1
: icmp_seq=540 ttl=255 time=3.54 ms64 bytes from
10.254.254.1 : icmp_seq=541 ttl=255 time=1.73 ms64
bytes from 10.254.254.1 : icmp_seq=542 ttl=255
time=1.71 ms64 bytes from 10.254.254.1 : icmp_seq=543
ttl=255 time=1.96 ms64 bytes from 10.254.254.1 :
icmp_seq=544 ttl=255 time=1.69 ms64 bytes from 10.254.254.1
: icmp_seq=545 ttl=255 time=1.84 ms64 bytes from
10.254.254.1 : icmp_seq=546 ttl=255 time=4.01 ms64
bytes from 10.254.254.1 : icmp_seq=547 ttl=255
time=5.65 ms64 bytes from 10.254.254.1 : icmp_seq=548
ttl=255 time=5.54 ms64 bytes from 10.254.254.1 :
icmp_seq=549 ttl=255 time=7.11 ms64 bytes from 10.254.254.1
: icmp_seq=550 ttl=255 time=1.61 ms64 bytes from
10.254.254.1 : icmp_seq=551 ttl=255 time=1.66 ms64
bytes from 10.254.254.1 : icmp_seq=552 ttl=255
time=2.02 ms64 bytes from 10.254.254.1 : icmp_seq=553
ttl=255 time=84.5 ms64 bytes from 10.254.254.1 :
icmp_seq=554 ttl=255 time=2682 ms64 bytes from 10.254.254.1
: icmp_seq=555 ttl=255 time=3212 ms64 bytes from
10.254.254.1 : icmp_seq=556 ttl=255 time=2199 ms64
bytes from 10.254.254.1 : icmp_seq=557 ttl=255
time=1198 ms64 bytes from 10.254.254.1 : icmp_seq=558
ttl=255 time=172 ms64 bytes from 10.254.254.1 :
icmp_seq=559 ttl=255 time=468 ms64 bytes from 10.254.254.1
: icmp_seq=560 ttl=255 time=142 ms64 bytes from
10.254.254.1 : icmp_seq=561 ttl=255 time=2039 ms64
bytes from 10.254.254.1 : icmp_seq=562 ttl=255
time=1018 ms64 bytes from 10.254.254.1 : icmp_seq=563
ttl=255 time=277 ms64 bytes from 10.254.254.1 :
icmp_seq=565 ttl=255 time=3251 ms64 bytes from 10.254.254.1
: icmp_seq=566 ttl=255 time=2238 ms64 bytes from
10.254.254.1 : icmp_seq=567 ttl=255 time=1228 ms64
bytes from 10.254.254.1 : icmp_seq=568 ttl=255
time=216 ms64 bytes from 10.254.254.1 : icmp_seq=569
ttl=255 time=1.68 ms64 bytes from 10.254.254.1 :
icmp_seq=570 ttl=255 time=108 msFrom 10.254.254.102 icmp_seq=634
Destination Host Unreachable(...)From 10.254.254.102 icmp_seq=639
Destination Host Unreachable64 bytes from 10.254.254.1
: icmp_seq=571 ttl=255 time=71861 msFrom
10.254.254.102 icmp_seq=640 Destination Host Unreachable(...)From
10.254.254.102 icmp_seq=659 Destination Host Unreachable64 bytes from
10.254.254.1 : icmp_seq=572 ttl=255 time=116728 ms64
bytes from 10.254.254.1 : icmp_seq=573 ttl=255
time=115715 ms64 bytes from 10.254.254.1 :
icmp_seq=574 ttl=255 time=114701 ms64 bytes from 10.254.254.1
: icmp_seq=575 ttl=255 time=113688 ms64 bytes from
10.254.254.1 : icmp_seq=576 ttl=255 time=112675 ms64
bytes from 10.254.254.1 : icmp_seq=577 ttl=255
time=111662 ms64 bytes from 10.254.254.1 :
icmp_se

Re: Octeon snapshots

[Alexis de BRUYN]

On 12/09/15 12:58, Paul Irofti wrote:

[1]: https://www.mail-archive.com/tech%40openbsd.org/msg26048.html


You have to use the octeon native objcopy by building the cross
compiler:

   # cd /usr/src
   # make -f Makefile.cross TARGET=octeon cross-gcc

And then use the objcopy from

   /usr/cross/octeon/usr/mips64-unknown-openbsd5.8/bin/objcopy



Thank you Paul. bsd.rd is now booting.

--
Alexis de BRUYN

Re: Octeon snapshots

[Paul Irofti]

> [1]: https://www.mail-archive.com/tech%40openbsd.org/msg26048.html

You have to use the octeon native objcopy by building the cross
compiler:

  # cd /usr/src
  # make -f Makefile.cross TARGET=octeon cross-gcc

And then use the objcopy from

  /usr/cross/octeon/usr/mips64-unknown-openbsd5.8/bin/objcopy

Re: Octeon snapshots

[Alexis de BRUYN]

Hi Everybody,

Has anyone successfully installed on a D-Link DSR-500N (HW A1)?

I have tried again with the last snapshot, and I am still stuck [1].

Thanks,

[1]: https://www.mail-archive.com/tech%40openbsd.org/msg26048.html

On 12/06/15 05:54, Daniel Ouellet wrote:

On 12/5/15 8:01 PM, jungle Boogie wrote:

On 5 December 2015 at 01:36, Daniel Ouellet  wrote:

I very much appreciate it.



I appreciate this too, but I can't complete the install. I tried an
update and now an install.

Like the first time, I'm following the network boot instructions here:
ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon

I can get the bsd.rd file fine from my server and boot into the installer.

This is the problem:
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0]
Disk: sd0   geometry: 1946/255/63 [31266816 Sectors]
Offset: 0   Signature: 0xAA55
 Starting Ending LBA Info:
  #: id  C   H   S -  C   H   S [   start:size ]
---
*0: 0C  0   1   2 -  2  11   9 [  64:   32768 ] Win95 FAT32L
  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
  3: A6  2  11  10 -   1946  68  42 [   32832:31233984 ] OpenBSD
Use (W)hole disk, use the (O)penBSD area or (E)dit the MBR? [OpenBSD]
The auto-allocated layout for sd0 is:
#size   offset  fstype [fsize bsize  cpg]
   a:   464.9M32832  4.2BSD   2048 163841 # /
   b:   465.1M   984896swap
   c: 15267.0M0  unused
   d:   735.8M  1937472  4.2BSD   2048 163841 # /tmp
   e:  1080.7M  316  4.2BSD   2048 163841 # /var
   f:  1284.9M  5657696  4.2BSD   2048 163841 # /usr
   g:   742.9M  8289120  4.2BSD   2048 163841 # /usr/X11R6
   h:  2817.8M  9810624  4.2BSD   2048 163841 # /usr/local
   i:16.0M   64   MSDOS
   j:  1178.0M 15581408  4.2BSD   2048 163841 # /usr/src
   k:  1607.9M 17993856  4.2BSD   2048 163841 # /usr/obj
   l:  4872.9M 21286848  4.2BSD   2048 163841 # /home
Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
disklabel(27018): syscall 5 "cpath"
Abort trap


What's syscall 5 cpath and why does it cause an abort trap?

I've tried with two different thumb drives with the same abort trap message.

Thanks!


Well I can't say what you did or didn't do.

Below there is WAY more information then needed.

But I just did it again all the way and here are all the steps by steps
I did and here is what my layout is before I started:

# fdisk sd0
Disk: sd0   geometry: 1946/255/63 [31266816 Sectors]
Offset: 0   Signature: 0xAA55
 Starting Ending LBA Info:
  #: id  C   H   S -  C   H   S [   start:size ]
---
*0: 0C  0   1   2 -  2  11   9 [  64:   32768 ]
Win95 FAT32L
  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
  3: A6  2  11  10 -   1946  68  42 [   32832:31233984 ] OpenBSD

# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Cruzer Fit
duid: 55072c2137c3a4e7
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 1946
total sectors: 31266816
boundstart: 32832
boundend: 31266816
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
   a:  105958432832  4.2BSD   2048 163841 # /
   b:  1044229  1092416swap   # none
   c: 312668160  unused
   d:  2104480  2136672  4.2BSD   2048 163841 # /tmp
   e: 10474368  4241152  4.2BSD   2048 163841 # /var
   f:  2088448 14715520  4.2BSD   2048 163841 # /var/log
   g: 10474400 16803968  4.2BSD   2048 163841 # /usr
   h:  3988448 27278368  4.2BSD   2048 163841 # /home
   i:32768   64   MSDOS

And here are the step by step:

# mount_msdos /dev/sd0i /mnt
# cd /mnt
# ls -al
total 22664
drwxr-xr-x   1 root  wheel16384 Dec 31  1979 .
drwxr-xr-x  13 root  wheel  512 Dec  5 00:11 ..
-rwxr-xr-x   1 root  wheel  4020931 Nov 14 17:29 bsd
-rwxr-xr-x   1 root  wheel  7562057 Nov 14 17:29 bsd.rd

# ftp ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/bsd.rd
Connected to openbsd.sunsite.ualberta.ca.
220 openbsd.srv.ualberta.ca FTP server ready.
...
Retrieving pub/OpenBSD/snapshots/octeon/bsd*.*
local: bsd.m

Re: Octeon snapshots

[Daniel Ouellet]

On 12/5/15 8:01 PM, jungle Boogie wrote:
> On 5 December 2015 at 01:36, Daniel Ouellet  wrote:
>> I very much appreciate it.
> 
> 
> I appreciate this too, but I can't complete the install. I tried an
> update and now an install.
> 
> Like the first time, I'm following the network boot instructions here:
> ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon
> 
> I can get the bsd.rd file fine from my server and boot into the installer.
> 
> This is the problem:
> Available disks are: sd0.
> Which disk is the root disk? ('?' for details) [sd0]
> Disk: sd0   geometry: 1946/255/63 [31266816 Sectors]
> Offset: 0   Signature: 0xAA55
> Starting Ending LBA Info:
>  #: id  C   H   S -  C   H   S [   start:size ]
> ---
> *0: 0C  0   1   2 -  2  11   9 [  64:   32768 ] Win95 
> FAT32L
>  1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>  2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
>  3: A6  2  11  10 -   1946  68  42 [   32832:31233984 ] OpenBSD
> Use (W)hole disk, use the (O)penBSD area or (E)dit the MBR? [OpenBSD]
> The auto-allocated layout for sd0 is:
> #size   offset  fstype [fsize bsize  cpg]
>   a:   464.9M32832  4.2BSD   2048 163841 # /
>   b:   465.1M   984896swap
>   c: 15267.0M0  unused
>   d:   735.8M  1937472  4.2BSD   2048 163841 # /tmp
>   e:  1080.7M  316  4.2BSD   2048 163841 # /var
>   f:  1284.9M  5657696  4.2BSD   2048 163841 # /usr
>   g:   742.9M  8289120  4.2BSD   2048 163841 # /usr/X11R6
>   h:  2817.8M  9810624  4.2BSD   2048 163841 # /usr/local
>   i:16.0M   64   MSDOS
>   j:  1178.0M 15581408  4.2BSD   2048 163841 # /usr/src
>   k:  1607.9M 17993856  4.2BSD   2048 163841 # /usr/obj
>   l:  4872.9M 21286848  4.2BSD   2048 163841 # /home
> Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
> disklabel(27018): syscall 5 "cpath"
> Abort trap
> 
> 
> What's syscall 5 cpath and why does it cause an abort trap?
> 
> I've tried with two different thumb drives with the same abort trap message.
> 
> Thanks!

Well I can't say what you did or didn't do.

Below there is WAY more information then needed.

But I just did it again all the way and here are all the steps by steps
I did and here is what my layout is before I started:

# fdisk sd0
Disk: sd0   geometry: 1946/255/63 [31266816 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
*0: 0C  0   1   2 -  2  11   9 [  64:   32768 ]
Win95 FAT32L
 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 3: A6  2  11  10 -   1946  68  42 [   32832:31233984 ] OpenBSD

# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: Cruzer Fit
duid: 55072c2137c3a4e7
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 1946
total sectors: 31266816
boundstart: 32832
boundend: 31266816
drivedata: 0

16 partitions:
#size   offset  fstype [fsize bsize  cpg]
  a:  105958432832  4.2BSD   2048 163841 # /
  b:  1044229  1092416swap   # none
  c: 312668160  unused
  d:  2104480  2136672  4.2BSD   2048 163841 # /tmp
  e: 10474368  4241152  4.2BSD   2048 163841 # /var
  f:  2088448 14715520  4.2BSD   2048 163841 # /var/log
  g: 10474400 16803968  4.2BSD   2048 163841 # /usr
  h:  3988448 27278368  4.2BSD   2048 163841 # /home
  i:32768   64   MSDOS

And here are the step by step:

# mount_msdos /dev/sd0i /mnt
# cd /mnt
# ls -al
total 22664
drwxr-xr-x   1 root  wheel16384 Dec 31  1979 .
drwxr-xr-x  13 root  wheel  512 Dec  5 00:11 ..
-rwxr-xr-x   1 root  wheel  4020931 Nov 14 17:29 bsd
-rwxr-xr-x   1 root  wheel  7562057 Nov 14 17:29 bsd.rd

# ftp ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/bsd.rd
Connected to openbsd.sunsite.ualberta.ca.
220 openbsd.srv.ualberta.ca FTP server ready.
...
Retrieving pub/OpenBSD/snapshots/octeon/bsd*.*
local: bsd.mp remote: bsd.mp
150 Opening BINARY mode data connection for 'bsd.mp' (4057768 bytes).
100% |**|  3962 KB00:06
226 Transfer complete.
4057768 bytes rec

Re: Octeon snapshots

[jungle Boogie]

On 5 December 2015 at 01:36, Daniel Ouellet  wrote:
> I very much appreciate it.


I appreciate this too, but I can't complete the install. I tried an
update and now an install.

Like the first time, I'm following the network boot instructions here:
ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/octeon/INSTALL.octeon

I can get the bsd.rd file fine from my server and boot into the installer.

This is the problem:
Available disks are: sd0.
Which disk is the root disk? ('?' for details) [sd0]
Disk: sd0   geometry: 1946/255/63 [31266816 Sectors]
Offset: 0   Signature: 0xAA55
Starting Ending LBA Info:
 #: id  C   H   S -  C   H   S [   start:size ]
---
*0: 0C  0   1   2 -  2  11   9 [  64:   32768 ] Win95 FAT32L
 1: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 2: 00  0   0   0 -  0   0   0 [   0:   0 ] unused
 3: A6  2  11  10 -   1946  68  42 [   32832:31233984 ] OpenBSD
Use (W)hole disk, use the (O)penBSD area or (E)dit the MBR? [OpenBSD]
The auto-allocated layout for sd0 is:
#size   offset  fstype [fsize bsize  cpg]
  a:   464.9M32832  4.2BSD   2048 163841 # /
  b:   465.1M   984896swap
  c: 15267.0M0  unused
  d:   735.8M  1937472  4.2BSD   2048 163841 # /tmp
  e:  1080.7M  316  4.2BSD   2048 163841 # /var
  f:  1284.9M  5657696  4.2BSD   2048 163841 # /usr
  g:   742.9M  8289120  4.2BSD   2048 163841 # /usr/X11R6
  h:  2817.8M  9810624  4.2BSD   2048 163841 # /usr/local
  i:16.0M   64   MSDOS
  j:  1178.0M 15581408  4.2BSD   2048 163841 # /usr/src
  k:  1607.9M 17993856  4.2BSD   2048 163841 # /usr/obj
  l:  4872.9M 21286848  4.2BSD   2048 163841 # /home
Use (A)uto layout, (E)dit auto layout, or create (C)ustom layout? [a]
disklabel(27018): syscall 5 "cpath"
Abort trap


What's syscall 5 cpath and why does it cause an abort trap?

I've tried with two different thumb drives with the same abort trap message.

Thanks!






-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si

Re: Octeon snapshots

[Peter Kay]

On 5 December 2015 09:36:29 GMT+00:00, Daniel Ouellet  
wrote:
>On 11/13/15 12:02 PM, Daniel Ouellet wrote:
>To the kind sole.
>
>Not sure who did the new current updated release, but many thanks to
>who
>ever did it!
It cod not have come at a better time, it stopped me going 'oh roe is me, my 
Octeon does not work well'. I for one am r-eel-y grateful ;)

Re: Octeon snapshots

[Daniel Ouellet]

it's a nice box. Not the most powerful, but for most case it works well
so far.

I did a few tcpbench on it to see.

About 85 to 90Mb routing before the CPU is 100% in use and then well,
that's as much as you get.

If you do both ways at the same time, then it goes down to ~42 to 45.

I also try with GRE tunnel to see. The 85 - 90 got down to ~62Mb and
then full duplex goes down to 28 to 32.

Full pf running, doing nat as well, stand smtp, not sending, dhcp.

Anyway, these tests are NOT very exhausting, but just an idea and it's
not bad for the $85 I pay for the new unit and the very low power this
needs to work.

I was curious and i will test more. I was trying to see if the
EdgeRouter Pro works, so far, no success yet, or may be never, but I am
just to tired to figure it out now.

I can say for sure that it does WAY, WAY more then a Cisco 2651XM
router! (:>

Daniel


On 12/5/15 8:20 AM, Peter Kay wrote:
>  
> 
> On 5 December 2015 09:36:29 GMT+00:00, Daniel Ouellet  
> wrote:
>> On 11/13/15 12:02 PM, Daniel Ouellet wrote:
>> To the kind sole.
>>
>> Not sure who did the new current updated release, but many thanks to
>> who
>> ever did it!
> It cod not have come at a better time, it stopped me going 'oh roe is me, my 
> Octeon does not work well'. I for one am r-eel-y grateful ;)

Re: Octeon snapshots

[Daniel Ouellet]

On 11/13/15 12:02 PM, Daniel Ouellet wrote:
> I saw a commit today on this platform. The last snapshot is almost a
> month old.
> 
> 10/18/15  2:19:00 AM.
> 
> Just wonder if the snapshot might get some love.
> 
> If not, totally fine, just wonder.
> 
> I may just go buy myself a bigger USB drive to try to compile it on my
> Ubiquiti box and see how many days that might take. (;>

To the kind sole.

Not sure who did the new current updated release, but many thanks to who
ever did it!

I very much appreciate it.

Daniel

Re: Octeon snapshots

[jungle Boogie]

On 13 November 2015 at 09:02, Daniel Ouellet  wrote:
> I saw a commit today on this platform. The last snapshot is almost a
> month old.
>
> 10/18/152:19:00 AM.
>
> Just wonder if the snapshot might get some love.
>
> If not, totally fine, just wonder.


I would also gratefully appreciate an updated Octeon build. I'm happy
to have one post 5.8, but openbsd is a fast moving target and many
great changes have already occurred for -current.

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si

Octeon snapshots

[Daniel Ouellet]

I saw a commit today on this platform. The last snapshot is almost a
month old.

10/18/152:19:00 AM.

Just wonder if the snapshot might get some love.

If not, totally fine, just wonder.

I may just go buy myself a bigger USB drive to try to compile it on my
Ubiquiti box and see how many days that might take. (;>