Re: wireshark illegal instruction on older systems

[Peter Kay]

It's a MOVSD SSE instruction. Tshark is ok. I can cope with that or tcpdump
if need be, but here's the output :

Starting program: /usr/local/bin/wireshark
warning: Lowest section in /usr/local/lib/libicudata.so.9.0 is .hash at
0154

Program received signal SIGILL, Illegal instruction.
0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
/usr/local/lib/qt5/./libQt5Gui.so.1.1

(gdb) bt
#0  0x06d685fb in _GLOBAL__sub_I_qguiapplication.cpp () from
/usr/local/lib/qt5/./libQt5Gui.so.1.1
#1  0x06d3ddba in ?? () from /usr/local/lib/qt5/./libQt5Gui.so.1.1
#2  0x03ff4931 in _dl_call_init_recurse (object=0x23ff6084,
initfirst=-2136632992) at /usr/src/libexec/ld.so/loader.c:671
#3  0x06d2e40b in _init () from /usr/local/lib/qt5/./libQt5Gui.so.1.1
#4  0x03ff49d1 in _dl_call_init_recurse (object=0x80a5aa00, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:693
#5  0x03ff4971 in _dl_call_init_recurse (object=0x87a66a00, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:679
#6  0x03ff4971 in _dl_call_init_recurse (object=0x80a5a200, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:679
#7  0x03ff4971 in _dl_call_init_recurse (object=0x8162ac00, initfirst=0) at
/usr/src/libexec/ld.so/loader.c:679
#8  0x03ff4a1a in _dl_call_init (object=0x8162ac00) at /usr/src/libexec/
ld.so/loader.c:666
#9  0x03ff580a in _dl_boot (argv=0xcf7bdf84, envp=0xcf7bdf8c,
dyn_loff=67059712, dl_data=0xcf7bdf3c)
at /usr/src/libexec/ld.so/loader.c:595
#10 0x03ff44b5 in _dl_start () at /usr/src/libexec/ld.so/i386/ldasm.S:68
#11 0xcf7bdf84 in ?? ()
#12 0xcf7bdf8c in ?? ()
#13 0x03ff4000 in ?? ()
#14 0xcf7bdf3c in ?? ()
#15 0xcf7bdf80 in ?? ()
#16 0xcf7bdf3c in ?? ()
#17 0x in ?? ()

(gdb) disas 0x06d685fb
Dump of assembler code for function _GLOBAL__sub_I_qguiapplication.cpp:
0x06d685d0 <_GLOBAL__sub_I_qguiapplication.cpp+0>:  push   %edi
0x06d685d1 <_GLOBAL__sub_I_qguiapplication.cpp+1>:  push   %esi
0x06d685d2 <_GLOBAL__sub_I_qguiapplication.cpp+2>:  push   %ebx
0x06d685d3 <_GLOBAL__sub_I_qguiapplication.cpp+3>:  call   0x6d3e13c
<__x86.get_pc_thunk.bx>
0x06d685d8 <_GLOBAL__sub_I_qguiapplication.cpp+8>:  add
 $0x200a22c0,%ebx
0x06d685de <_GLOBAL__sub_I_qguiapplication.cpp+14>: sub$0x10,%esp
0x06d685e1 <_GLOBAL__sub_I_qguiapplication.cpp+17>: call   0x6d3c7a0
<_init+58272>
0x06d685e6 <_GLOBAL__sub_I_qguiapplication.cpp+22>: fstpl  0x8(%esp)
0x06d685ea <_GLOBAL__sub_I_qguiapplication.cpp+26>: lea
 0x5770(%ebx),%esi
0x06d685f0 <_GLOBAL__sub_I_qguiapplication.cpp+32>: call   0x6d3c7a0
<_init+58272>
0x06d685f5 <_GLOBAL__sub_I_qguiapplication.cpp+37>: mov
 0x4328(%ebx),%eax
0x06d685fb <_GLOBAL__sub_I_qguiapplication.cpp+43>: movsd
 0x8(%esp),%xmm0
0x06d68601 <_GLOBAL__sub_I_qguiapplication.cpp+49>: mov
 0x4414(%ebx),%edi
0x06d68607 <_GLOBAL__sub_I_qguiapplication.cpp+55>: sub$0x4,%esp
0x06d6860a <_GLOBAL__sub_I_qguiapplication.cpp+58>: fstpl  (%eax)
0x06d6860c <_GLOBAL__sub_I_qguiapplication.cpp+60>: movsd
 %xmm0,0x8(%eax)
0x06d68611 <_GLOBAL__sub_I_qguiapplication.cpp+65>: mov
 0x4554(%ebx),%eax
0x06d68617 <_GLOBAL__sub_I_qguiapplication.cpp+71>: mov%edi,(%eax)
0x06d68619 <_GLOBAL__sub_I_qguiapplication.cpp+73>: push   %esi
0x06d6861a <_GLOBAL__sub_I_qguiapplication.cpp+74>: push   %eax
0x06d6861b <_GLOBAL__sub_I_qguiapplication.cpp+75>: lea
 0xdff3c658(%ebx),%eax
0x06d68621 <_GLOBAL__sub_I_qguiapplication.cpp+81>: push   %eax
0x06d68622 <_GLOBAL__sub_I_qguiapplication.cpp+82>: call   0x6d37100
<_init+36096>
0x06d68627 <_GLOBAL__sub_I_qguiapplication.cpp+87>: mov
 0x446c(%ebx),%eax
0x06d6862d <_GLOBAL__sub_I_qguiapplication.cpp+93>: add$0xc,%esp
0x06d68630 <_GLOBAL__sub_I_qguiapplication.cpp+96>: mov%edi,(%eax)
0x06d68632 <_GLOBAL__sub_I_qguiapplication.cpp+98>: push   %esi
0x06d68633 <_GLOBAL__sub_I_qguiapplication.cpp+99>: push   %eax
0x06d68634 <_GLOBAL__sub_I_qguiapplication.cpp+100>:lea
 0xdff4af78(%ebx),%eax
0x06d6863a <_GLOBAL__sub_I_qguiapplication.cpp+106>:push   %eax
0x06d6863b <_GLOBAL__sub_I_qguiapplication.cpp+107>:call   0x6d37100
<_init+36096>
0x06d68640 <_GLOBAL__sub_I_qguiapplication.cpp+112>:mov
 0x4178(%ebx),%eax
0x06d68646 <_GLOBAL__sub_I_qguiapplication.cpp+118>:add$0xc,%esp
0x06d68649 <_GLOBAL__sub_I_qguiapplication.cpp+121>:mov%edi,(%eax)
0x06d6864b <_GLOBAL__sub_I_qguiapplication.cpp+123>:push   %esi
0x06d6864c <_GLOBAL__sub_I_qguiapplication.cpp+124>:push   %eax


On 15 March 2016 at 00:30, Michael McConville  wrote:

> Peter Kay wrote:
> > Wireshark, running on -current, is dumping core ('illegal
> > instruction') on two separate pentium ii systems here. It's fine on a
> > Core2Duo running i386.
> >
> > I'm presuming it's using pentium 3 or later instructions/SSE2 etc. Has
> > anyone else seen this before I look at it?
>
> Can you run it in GDB and trigger the crash? That seems like the easiest
> way to get the offending 

wireshark illegal instruction on older systems

[Peter Kay]

Wireshark, running on -current, is dumping core ('illegal instruction') on
two separate pentium ii systems here. It's fine on a Core2Duo running i386.

I'm presuming it's using pentium 3 or later instructions/SSE2 etc. Has
anyone else seen this before I look at it?

PK

Re: wireshark illegal instruction on older systems

[Michael McConville]

Peter Kay wrote:
> Wireshark, running on -current, is dumping core ('illegal
> instruction') on two separate pentium ii systems here. It's fine on a
> Core2Duo running i386.
> 
> I'm presuming it's using pentium 3 or later instructions/SSE2 etc. Has
> anyone else seen this before I look at it?

Can you run it in GDB and trigger the crash? That seems like the easiest
way to get the offending instruction.

I know we had to handle something like this in lang/go recently. There
was a discussion on ports@.

Re: spamd.conf(5) wording

[Jason McIntyre]

On Sun, Mar 13, 2016 at 03:24:53PM +0100, hans wrote:
> Two bits seem unclear in spamd.conf(5),
> at least to a non-native speaker.
> 
> 
>  # Strings follow getcap(3) convention escapes, other than you
>  # can have a bare colon (:) inside a quoted string and it
>  # will deal with it.
> 
> "Other that _that_ you can have a bare colon"?
> 

you mean "than that" right? ;) that would be correct, but i've just
changed "other than" to "except". seems simpler.

> 
>  # Lists specified with the :white: capability apply to the previous
>  # list with a :black: capability.
> 
> Should that be "lists"? Or does a :white: list only apply
> to the one :black: "list" immediately preceding it?
> 
>   Jan
> 

the doc is pretty clear that it is list singular, so i haven;t touched
it. but if you want to test it, and find that it's wrong, mail me and
i'll fix it.

jmc

Re: Silly typo in docs

[Murk Fletcher]

I see what you mean and you're right, it can go both ways. But my initial
reaction was to expect a plural. Maybe we could drop the "some" as well
then? So that it reads:

"New users frequently want to know whether OpenBSD is superior to other
free UNIX-like operating systems."

Thank you!

--Murk

On Mon, Mar 14, 2016 at 9:58 PM, Donald Allen 
wrote:

> On Mon, Mar 14, 2016 at 4:30 PM, Murk Fletcher 
> wrote:
> > Hi!
> >
> > Is it just me or should http://www.openbsd.org/faq/faq1.html#WhyUse have
> > "other free UNIX-like operating system" in plural?
>
> The sentence describes users who ask "Is OpenBSD better than X?",
> where X is a specific Unix-like system. You seem to be parsing it as
> users who ask "Is OpenBSD better than X, Y, and Z", where X, Y, and Z
> are each Unix-like systems. I think either way is grammatically
> correct and which is used depends on the meaning intended by the
> writer. The writer apparently intended to describe the first
> situation. I don't think it's a typo.
>
> Don

Re: Silly typo in docs

[Donald Allen]

On Mon, Mar 14, 2016 at 4:30 PM, Murk Fletcher  wrote:
> Hi!
>
> Is it just me or should http://www.openbsd.org/faq/faq1.html#WhyUse have
> "other free UNIX-like operating system" in plural?

The sentence describes users who ask "Is OpenBSD better than X?",
where X is a specific Unix-like system. You seem to be parsing it as
users who ask "Is OpenBSD better than X, Y, and Z", where X, Y, and Z
are each Unix-like systems. I think either way is grammatically
correct and which is used depends on the meaning intended by the
writer. The writer apparently intended to describe the first
situation. I don't think it's a typo.

Don

Silly typo in docs

[Murk Fletcher]

Hi!

Is it just me or should http://www.openbsd.org/faq/faq1.html#WhyUse have
"other free UNIX-like operating system" in plural?

Thanks.

--Murk

Re: OpenBSD on AMD Embedded G-Series T40E APU?

[Noth]

As of today, a new firmware is available on PC Engines' website that 
enables iPXE & SD card booting. Last feature missing is ECC Ram, 
hopefully we won't have to wait too long for that. I've flashed my 
APU2B4, seems to work fine.


Cheers,

Noth

Re: Raspberrypi 3 was released

[Patrick Wildt]

On Mon, Mar 14, 2016 at 09:07:37AM +, Roderick wrote:
> What about AMD Opteron A-Series? Does OpenBSD run on it?
> 
> http://www.amd.com/en-us/products/server/opteron-a-series
> 
> Rodrigo.
> 

The raspberry pi 3 has its good and bad sides.  It's easy to use,
everywhere available and rather cheap.  Yes, there's the ODROID-C2
which is similarly cheap and better, but the raspberry pi might
actually be easier to support.

First of all, the blobs.  Every ARM machine has some kind of blob.  Some
are hidden, like stored on a flash.  Some are visible, e. g. stored on
the SD card.  The raspberry pi is of the latter.  Its blobs have to be
stored on the SD card so that it can boot.  The Cubox-i is similar, it
also needs a blob on the SD card.  The difference though is that the
cubox blobs can be compiled from some u-boot repository on github.  The
raspberry pi blobs are not open source.

Still, both have blobs that run as part of the boot stage, and are not
driver blobs that have to be run on the CPU, like a kernel module.
Though, the raspberry pi blobs are a bit special.  They actually run on
the GPU, not the CPU, and take care of the boot stage.  This means that
the GPU is booted first, from a blob stored on the SD card, which then
loads the kernel from the SD card into memory, and then starts the CPU.

That's not nice.  There's no IOMMU, though we can't secure ourselves
against malicious memory access from the GPU.  But I'm not sure that's
much worse than other machines, where the blob isn't visible.

The USB Controller is crap, but it's the same as the octeon, so we got a
driver for that.  HDMI is controlled by the GPU.  For a simple
framebuffer the GPU provides an interface to ask for framebuffer memory.
This means it's comparatively easy to actually have HDMI output: you
just ask the GPU's API to kindly provide it.

Making OpenBSD run on the raspberry pi is feasible, though (without
adding hacks) it's only feasible with proper device tree support, which
is a work in progress at the moment.

The AMD machine is quite nice actually.  As it's based on a Cortex-A57,
which is backwards compatible to 32-bit armv7, it might be possible to
run OpenBSD/ARMv7 on it.

For that we will need some kind of mechanism to boot a 32-bit kernel.
The machine, as far as I know, boots using UEFI.  So maybe we'll need
an efiboot for ARMv8, which can boot an ARMv7 kernel.  Or maybe one can
use u-boot as a payload for EFI?  No idea.  Also one needs to port the
10 GbE ethernet controller driver, or write a new one.  The one in linux
is dual-licensed, so in theory it could be pulled over.

Oh, and that machine is kind of expensive.  But there'll be $300 USD
96boards (enterprise edition) available this year, which is much cheaper
than the original devkit from AMD.

That's my brain dump, hopefully that clears some things up.

Patrick

Re: Raspberrypi 3 was released

[Karel Gardas]

On Mon, Mar 14, 2016 at 10:07 AM, Roderick  wrote:
> What about AMD Opteron A-Series? Does OpenBSD run on it?
>
> http://www.amd.com/en-us/products/server/opteron-a-series

No and unfortunately reference doc is still under NDA. Also no answer
here: https://community.amd.com/thread/196120

I'm not sure about broadcom in RPi3, but I've tried to get doc from
AMCC for their X-Gene and from Cavium for their ThunderX but no
success so far. The only meaningful thing (i.e. performance higher
than A53 which is also in RPi3) with doc released is Nvidia's
Tegra-X1.

If you are a fan of ARMv8 and you'd like to see this moving forward,
perhaps you can give a try to  drahn_arm64 branch in bitrig project
git tree... IMHO thing which may be closest to OpenBSD tree...

Re: Raspberrypi 3 was released

[Roderick]

What about AMD Opteron A-Series? Does OpenBSD run on it?

http://www.amd.com/en-us/products/server/opteron-a-series

Rodrigo.