Re: ffs details

[Otto Moerbeek]

On Wed, Feb 26, 2020 at 03:02:02AM +0100, whistlez...@riseup.net wrote:

> Hi, I need some details about ffs, I read the kernel source but my c
> knowledge is very basic. I understood all about the superblock but my
> problem is understand how the files are allocated on the disk.
> Anyone could give me more details about files allocation ?
> Thank you.
> 

Did you read the ffs paper
https://people.eecs.berkeley.edu/~brewer/cs262/FFS.pdf

Some things have changes a bit (like rotational optimization) but the
general ideas hold.

-Otto

Re: close(2) return value handling

[Theo de Raadt]

Matthias  wrote:

> Just curious why you never check the return value of the close(2) system
> call for errors.

It never fails in a way that matters.

The program must be properly written for the fd to be alive, so EBADF
doesn't occur.

EINTR doesn't occur, and if it did, nowhere is it cleanly specified
what you do, do you call it again?  Not clear. 

And if it were to fail with EIO, there is nothing you can do.  If
that happens, your underlying IO subsyste is so screwed up your dmesg
is probably starting to spew error messages.

Basically it is pointless.

close(2) return value handling

[Matthias]

Hi.

Just curious why you never check the return value of the close(2) system
call for errors.

Thanks.

Re: ffs details

[Philip Guenther]

On Tue, Feb 25, 2020 at 6:03 PM  wrote:

> Hi, I need some details about ffs, I read the kernel source but my c
> knowledge is very basic. I understood all about the superblock but my
> problem is understand how the files are allocated on the disk.
> Anyone could give me more details about files allocation ?
>

You should start from the paper that described the design and
implementation:
https://www.cs.berkeley.edu/~brewer/cs262/FFS.pdf

as linked to from https://en.wikipedia.org/wiki/Unix_File_System

Kirk McKusick has continued to revise and improve FFS; many of those
changes have been included in OpenBSD.  Check his biography and his
personal website for links to papers and presentations.


Philip Guenther

ffs details

[whistlez-ml]

Hi, I need some details about ffs, I read the kernel source but my c
knowledge is very basic. I understood all about the superblock but my
problem is understand how the files are allocated on the disk.
Anyone could give me more details about files allocation ?
Thank you.

Re: "not MAP_STACK" message in dmesg / system message buffer

[Theo de Raadt]

Theo de Raadt  wrote:

> Andre Smagin  wrote:
> 
> > Hello.
> > 
> > While prototyping something in C, I made a mistake with
> > pre-processor macros, which I narrowed down to this:
> > 
> > int
> > main()
> > {
> > char *test[10][2097152] = { { 0 } };
> > }
> > 
> > Running it results in
> > $ ./a.out
> > Segmentation fault (core dumped) 
> > 
> > and it also logs it in dmesg as
> > 
> > Feb 25 20:05:49 hamlet /bsd: [a.out]52048/372328 sp=7f7ff5fd4150 inside 
> > 7f7fff7d5000-7f7d5000: not MAP_STACK
> > Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside 
> > 7f7fff7e7000-7f7e6000: not MAP_STACK
> > Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside 
> > 7f7fff7db000-7f7db000: not MAP_STACK
> > 
> > I have not seen a segfaulting program being logged in system
> > message buffer before. Is it expected behaviour?
> > Just curious, the message was a bit confusing.
> > 
> > The system is amd64-current.
> 
> Your stack allocation is too large.  When it was being zero'd you ran out
> the range and hit address space which may not be stack.

More comments:

the MAP_STACK check happens early on kernel entry (syscall or fault),
we don't know if the page exists or not in both cases.. so this triggers first

Eventually this message will go away, and people will have to figure out
the reason for SIGSEGV on their own.

Re: "not MAP_STACK" message in dmesg / system message buffer

[Theo de Raadt]

Andre Smagin  wrote:

> Hello.
> 
> While prototyping something in C, I made a mistake with
> pre-processor macros, which I narrowed down to this:
> 
> int
> main()
> {
>   char *test[10][2097152] = { { 0 } };
> }
> 
> Running it results in
> $ ./a.out
> Segmentation fault (core dumped) 
> 
> and it also logs it in dmesg as
> 
> Feb 25 20:05:49 hamlet /bsd: [a.out]52048/372328 sp=7f7ff5fd4150 inside 
> 7f7fff7d5000-7f7d5000: not MAP_STACK
> Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside 
> 7f7fff7e7000-7f7e6000: not MAP_STACK
> Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside 
> 7f7fff7db000-7f7db000: not MAP_STACK
> 
> I have not seen a segfaulting program being logged in system
> message buffer before. Is it expected behaviour?
> Just curious, the message was a bit confusing.
> 
> The system is amd64-current.

Your stack allocation is too large.  When it was being zero'd you ran out
the range and hit address space which may not be stack.

"not MAP_STACK" message in dmesg / system message buffer

[Andre Smagin]

Hello.

While prototyping something in C, I made a mistake with
pre-processor macros, which I narrowed down to this:

int
main()
{
char *test[10][2097152] = { { 0 } };
}

Running it results in
$ ./a.out
Segmentation fault (core dumped) 

and it also logs it in dmesg as

Feb 25 20:05:49 hamlet /bsd: [a.out]52048/372328 sp=7f7ff5fd4150 inside 
7f7fff7d5000-7f7d5000: not MAP_STACK
Feb 25 20:06:49 hamlet /bsd: [a.out]94530/186499 sp=7f7ff5fe58c0 inside 
7f7fff7e7000-7f7e6000: not MAP_STACK
Feb 25 20:07:09 hamlet /bsd: [a.out]9523/344960 sp=7f7ff5fd9fd0 inside 
7f7fff7db000-7f7db000: not MAP_STACK

I have not seen a segfaulting program being logged in system
message buffer before. Is it expected behaviour?
Just curious, the message was a bit confusing.

The system is amd64-current.

--
Andre

Re: openbsd.org - certain https URLs downgraded to http in redirection

[Constantine A. Murenin]

On Tue, 25 Feb 2020 at 04:35, Vincenzo Nicosia  wrote:

> On Tue, Feb 25, 2020 at 07:57:24AM -, Stuart Henderson wrote:
>
> [cut]
>
> > > Want https? great. use it.  There are times when it's handy to NOT
> > > be obsessed with https (i.e., clock is hosed on your computer).
> > >
> > > So ... unless some developer I really respect (which is just about
> > > all of them1) tells me to change this, I'm not planning on
> > > changing the behavior of the machines.
> >
> > I did object to http->https redirects in the past, but now the web is
> > unusable without working https anyway and the "INSECURE openbsd.org"
> > shown on some browsers *is* a bit of an eyesore ...
> >
>
> IMHO, the fact that corporates (Google) want to dictate what is secure
> and what is not, is not sufficient to force everybody on https, at all
> times. I personally don't give a toss of what Chrome thinks of a
> website and its security (maybe because I have never used Chrome or
> because I quit google searches more than 10 years ago...).
>
> There are many cases where the overhead introduced by https is really
> not worth the extra bit of confidentiality you get. And we are talking
> here of manpages (that are installed in your system anyway) and of
> system sources (that are available for download at any time, even from
> an HTTPS mirror)...
>
> Sorry for the rant, but if I type "http://bring.me.there; I don't want
> to find myself at "https://we.brought.you.somewhere.else;. I am not a
> chimp. I know what I type in my URL box. I know what I expect. And I
> want to be able to serve content via HTTP/1.0 if I need so.
>

Exactly.

Folks often forget, or are blissfully unaware, that Google Search itself
still does work over both HTTP (without the S) as well as over the legacy
TLSv1.0 HTTPS, so, the propaganda efforts and the destructive webmaster
advice given by the Google Chrome and Mozilla teams to suppress the
minorities from being able to access the websites is hypocritical, to say
the least.  /Do as I say, not as I do./

The HTTP and TLSv1.0 traffic is mostly bots, some folks say?  Surprise —
many bots are still controlled by good people, used to do various useful
things, so, you're still blocking actual people from a minority class from
having access to your website.  Not to mention the older phones and tablets
with hundreds of megabytes of RAM and gigabytes of storage space that were
abandoned by their creators and don't support TLSv1.2 and/or all the newest
ciphers that are deemed to be the best practice today.  The sad part is
that the non-profits of today (e.g., Mozilla and Wikipedia) are effectively
brokering the planned obsolescence of all these devices on behalf of the
respective vendors.

C.

Re: Determining which patches a snapshot contains

[Theo de Raadt]

Jonathan Schleifer  wrote:

> Fair enough - I can understand you don't want to give any guarantees for 
> snapshots.
> 
> I guess it's fair to assume that snapshots are only built from full commits 
> and not partial commits? In this case then, I guess I should be fine.

The snapshot promise does not let you make that assumption.

Re: Determining which patches a snapshot contains

[Jonathan Schleifer]

Fair enough - I can understand you don't want to give any guarantees for 
snapshots.

I guess it's fair to assume that snapshots are only built from full commits and 
not partial commits? In this case then, I guess I should be fine.

-- 
Jonathan

> Am 25.02.2020 um 20:35 schrieb Theo de Raadt :
> 
> You are asking questions beyond the promises we make about snapshots.
> 
> Sorry, no answer to your question.  Sorry if you think that is unfair.
> 
> Jonathan Schleifer  wrote:
> 
>> Hi!
>> 
>> I'm wondering: If I upgrade to snapshots/sparc64/base66.tgz that is listed 
>> on ftp as
>> base66.tgz 24-Feb-2020 20:01 
>>   175147678
>> Will it include 
>> ?
>> 
>> I saw that the patch added two new strings, and those seem to match (this is 
>> after upgrading):
>> 
>> # strings /usr/sbin/smtpd | grep 'has bad uid' 
>> warn: smtpd: file %s has bad uid %d
>> # strings /usr/sbin/smtpd | grep 'has bad gid' 
>> warn: smtpd: file %s has bad gid %d
>> 
>> As well as the change to using the full path to makemap:
>> # strings /usr/sbin/smtpctl | grep makemap
>> makemap
>> makemap
>> makemap
>> usage: makemap [-U] [-d dbtype] [-o dbfile] [-t type] file
>> /usr/sbin/makemap
>> 
>> So does this mean the patch is included, or were some parts of the patch 
>> already applied earlier and this is still incomplete? It looks like 
>> https://github.com/openbsd/src/commit/0228dab008714e5c4cb4c4fdb7e20836742f6fc9
>>  contains all changes at once, so should I be good?
>> 
>> Thanks.
>> 
>> -- 
>> Jonathan
>> 

Re: size of size_t (diff angle)

[Anders Andersson]

On Tue, Feb 25, 2020 at 12:14 PM  wrote:
>
> Haai,
>
> The definition of size_t keeps biting me.
>
> Some background: in nnx, me's been using the equiv of caddr_t for
> counts. This works well; yet, while writing against existing code that
> uses size_t, an issue has surfaced.
>
> First of all, let us reflect upon the definition of size_t in C99.
>
> > size_t
> > which is the unsigned integer type of the result of the sizeof
> > operator;
>
> That's not very specific. It kind-of implies that SIZE_MAX (defined
> later in the standard) is the largest possible offset, but not
> necessarily the largest possible address. This reeks of i86 real mode
> semantics, obsolete (for general-purpose machines) already when the
> PDP-11 was new.

I think it's pretty clear, size_t is for the size of objects, not for
offsets or pointers. The C standard frowns upon mixing up pointers and
integers, to much grief from low-level developers.



> Is SIZE_MAX guaranteed to *not* be greater than the highest address?

I'm almost certain that C99 offers no such guarantees, since a pointer
to a float does not have to be the same size as a pointer to int, for
example. Maybe if you're being a little more specific. There are some
exceptions for void * and char *.

In fact, the standard only *recommends* that implementations keep
SIZE_MAX as small as possible but not smaller. Since it is only a
recommendation, it can be inferred that the standard acknowledges that
an implementation with SIZE_MAX > highest address is valid.

"The types used for size_t and ptrdiff_t should not have an integer
conversion rank greater than that of signed long int unless the
implementation supports objects large enough to make this necessary."

Or my interpretation: "Just because there is now a new and fancy
64-bit long long in C99 doesn't mean that you should make size_t a
long long just because you can, because it's pointless if your
compiler/target only has a 32-bit address space."

Re: inteldrm changes cause high temperature / fan speeds

[Tero Koskinen]

Hi,

Alex Karle wrote on 25.2.2020 6.51:

Hi Tero,

Apologies if this breaks the threading -- I wasn't subscribed to misc@
at the time the original was sent.

Have you (or any others) dug any deeper into this? 


My problem was more or less "solved" when the power supply from
my Optiplex died. Instead of fixing the supply, I simply recycled
the device and bought PC Engines APU2.

I still have another slightly newer Optiplex (running Linux), but
not sure when I will have time to test the latest OpenBSD on it
(might take many months).

Yours,
 Tero

PPTP NAT passthrough

[Szél Gábor]

Dear @misc

Our customer need more parallel outgoing PPTP session.
I know PPTP is no security VPN, but our client not have any options. 
(our customer remote partner accept only PPTP VPN ...)


OpenBSD PF can't use parallel PPTP session. First session is NAT-ed, but 
second session is broken.

I know OpenBSD not supported PPTP NAT passthrough.

I found two, very old PPTP proxy for openbsd:

 * https://github.com/crvv/pptp-proxy
   This is ftp-proxy fork(?)
 * https://sourceforge.net/projects/frickin/

frickin 1.x working only fix remote PPTP address, not good for me.
frickin 2.x (beta) not compiled on oBSD 6.6.

pptp-proxy is compiled, and started, but not working.
We tested very simple pf.conf (NAT, and some rules)

pass in quick log on $int_if proto gre from any to ! $int_if:0 rdr-to 
127.0.0.1
pass in quick log on $int_if proto tcp from any to ! $int_if:0 port 1723 
rdr-to 127.0.0.1 port 2317


pptp-proxy is accepted session, but not working.
(in tcpdump only 2 outgoing, 1 inbound packet found)

Does anyone know a working solution for PPTP NAT passthrough?

In openbsd based securityrouter.org firewall a found PPTP-Proxy support:
https://securityrouter.org/wiki/Comparison
But I don't know what to use.

--
Üdvözlettel,
Szél Gábor

WanTax Kft.

tel.: +36 20 3838 171
fax: +36 82 357 585
email: gabor.s...@wantax.hu
web: http://wantax.hu
web: http://halozatom.hu

Re: What TERM fixes Emacs?

[Raymond, David]

On my X1 Carbon running openbsd 6.6, the console works fine with the
non-X version of emacs except that the meta key is not set.  One can
emulate the meta key by typing escape followed by x, but this is a
pain.  Maybe there is some mechanism for setting the alt key to meta
in emacs on consoles, but I use X11 so I haven't needed to pursue
this.

Same story on the virtual console window on a vga monitor attached to
a desktop with 6.6.

Dave Raymond

PS - You might take a look at this comment for freebsd:

https://forums.freebsd.org/threads/alt-as-meta-key-in-emacs-within-virtual-console.40275/

On 2/24/20, Emilia  wrote:
> It is impossible to use Emacs on OpenBSD Terminal (no X).
>
> Look at this screenshots:
>
> On Linux / macOs -- this same version of Emacs and org-mode would
> display this file with colors etc.
>
> OpenBSD can't even show the mode line.
>
> How do I fix this?
>
> Em


-- 
David J. Raymond
david.raym...@nmt.edu
http://physics.nmt.edu/~raymond

Re: Determining which patches a snapshot contains

[Theo de Raadt]

You are asking questions beyond the promises we make about snapshots.

Sorry, no answer to your question.  Sorry if you think that is unfair.

Jonathan Schleifer  wrote:

> Hi!
> 
> I'm wondering: If I upgrade to snapshots/sparc64/base66.tgz that is listed on 
> ftp as
> base66.tgz 24-Feb-2020 20:01  
>  175147678
> Will it include 
> ?
> 
> I saw that the patch added two new strings, and those seem to match (this is 
> after upgrading):
> 
> # strings /usr/sbin/smtpd | grep 'has bad uid' 
> warn: smtpd: file %s has bad uid %d
> # strings /usr/sbin/smtpd | grep 'has bad gid' 
> warn: smtpd: file %s has bad gid %d
> 
> As well as the change to using the full path to makemap:
> # strings /usr/sbin/smtpctl | grep makemap
> makemap
> makemap
> makemap
> usage: makemap [-U] [-d dbtype] [-o dbfile] [-t type] file
> /usr/sbin/makemap
> 
> So does this mean the patch is included, or were some parts of the patch 
> already applied earlier and this is still incomplete? It looks like 
> https://github.com/openbsd/src/commit/0228dab008714e5c4cb4c4fdb7e20836742f6fc9
>  contains all changes at once, so should I be good?
> 
> Thanks.
> 
> -- 
> Jonathan
> 

Re: openbsd.org - certain https URLs downgraded to http in redirection

[Greg Hewgill]

February 25, 2020 11:32 PM, "Vincenzo Nicosia"  wrote:

> There are many cases where the overhead introduced by https is really
> not worth the extra bit of confidentiality you get.

It's not just about confidentiality - https also ensures integrity, and
prevents nefarious network operators (ie. your ISP) from altering your
requested web pages to insert ads or other malware. This happens more often
than you might expect.

Fortunately, the wide adoption of https has made these sorts of evil content
alteration less appealing.

Re: Pf memory pool limits don't have immediate effects when loading a ruleset above the previous limit

[Benjamin Girard]

For some reason I cannot reproduce the problem all the time as I rebooted my vm 
and now i properly get a valid error message:

fw# pfctl -f /etc/pf.conf
pfctl: Current pool size exceeds requested tables limit 2000

And I can just update the limit without the need to remove and re-add the 
tables.
And on another machine with 6.6 i hit the same bug as below saying "Cannot 
allocate memory" and i'm not able to raise the limit if i don't remove the 
tables from my pf.conf

Can anybody reproduce it?

Thanks,
Ben

From: owner-m...@openbsd.org  on behalf of Benjamin 
Girard 
Sent: 22 February 2020 13:33
To: misc@openbsd.org 
Subject: Pf memory pool limits don't have immediate effects when loading a 
ruleset above the previous limit

Hi misc,


So I'm running 6.6 with latest syspatch as of today.

I'm trying to load the default ruleset that comes with 6.6 with an extra file 
taht contains more than 1000 tables which is the default hard limit, my only 
change is to include that extra file.
Since i've more than 1000 tables I also set the tables limit to 2000:

fw# cat /etc/pf.conf

set limit tables 2000
include "/etc/pf.d/pf.tables"

set skip on lo
block return# block stateless traffic
pass# establish keep-state


fw# wc -l /etc/pf.d/pf.tables
3252 /etc/pf.d/pf.tables

fw# grep table /etc/pf.d/pf.tables  | wc -l
1084

Unfortunately I cannot load my ruleset as the memory cannot be allocated from 
line 1503 of my table file:
fw# pfctl -f /etc/pf.conf
/etc/pf.d/pf.tables:1503: cannot define table some_table1: Cannot allocate 
memory
/etc/pf.d/pf.tables:1506: cannot define table some_table2: Cannot allocate 
memory
/etc/pf.d/pf.tables:1509: cannot define table some_table3: Cannot allocate 
memory
---

It appears that I have to first load the ruleset without including all the 
tables in order to have the limit properly set then only I can include my 
tables file.

It also appears that in my case 2000 limit is not enough, even though I've only 
1084 tables but 2168 is enough.
my tables files looks like this:
table  {
  1.1.1.1 2.2.2. 3.3.3.3
}
and 2168 is all the lines except the table line:
fw# grep -v table /etc/pf.d/pf.tables | wc -l
2168

So it's not the actual number of tables.

Am i misunderstanding the documentation somehow or are these some kind of bugs?


Thanks,
Ben

Re: What TERM fixes Emacs?

[Chris Cappuccio]

Emilia [emi...@sonic.net] wrote:
> Stuart, 
> 
> Apologies for breaking netiquette w/ sending images.
> 
> Could you please point me to what "pccon" is?  I found references to
> pccon in pcvt - but it is unclear to me how I can use pcvt either. 
> 

export TERM=pccon perhaps?

Re: What TERM fixes Emacs?

[Stuart Henderson]

On 2020/02/25 07:19, Emilia wrote:
> Stuart,
> 
> Apologies for breaking netiquette w/ sending images.
> 
>  
> 
> Could you please point me to what "pccon" is?  I found references to pccon in 
> pcvt - but it is
> unclear to me how I can use pcvt either.
> 
> 
> Thank you!

pccon is the termcap(5) entry that best matches the console used by
OpenBSD on PCs, there are a few variants (see /etc/termcap) but just plain
"pccon" is usually fine.

You can set it in the shell environment (export TERM=pccon) then run emacs,
which is good for a quick test, if that generally provides better results
you can modify /etc/ttys (change the "vt220" entries to "pccon", then
reboot or send init(8) a signal to reload it - "man init", see the
"Line status (on, off, [...]" paragraph).

Re: What TERM fixes Emacs?

[Emilia]

Stuart, 

Apologies for breaking netiquette w/ sending images.

Could you please point me to what "pccon" is?  I found references to
pccon in pcvt - but it is unclear to me how I can use pcvt either. 

Thank you! 

On 2020-02-24 23:16, Stuart Henderson wrote:

> On 2020-02-25, Emilia  wrote: 
> 
>> It is impossible to use Emacs on OpenBSD Terminal (no X). 
>> 
>> Look at this screenshots: 
>> 
>> On Linux / macOs -- this same version of Emacs and org-mode would
>> display this file with colors etc. 
>> 
>> OpenBSD can't even show the mode line. 
>> 
>> How do I fix this?
> 
> Try pccon.
> 
>> --=_f69ee5e0e3f3ba5b74bb1250e9e8a612
>> Content-ID: <15826084275e54b02bbe0d7530097...@sonic.net>
>> Content-Disposition: inline;
>> filename=c-3.gif;
>> size=67545
>> Content-Transfer-Encoding: base64
>> Content-Type: image/gif;
>> name=c-3.gif
>> 
>> R0lGODlhkwEuAfcAAAQBAA0DAQkEDBMEARoGARwJAhYJCQoGHAkGGBcLGhsS
>> GSQLASkOASQIAywSAigUCDcZAygSHSYOGj0hBgYFIwkGIgsJJAwLLAgGKxMN
> ..
> 
> Please don't send image attachments to the OpenBSD lists (and in general
> most techmical mailing lists)

Re: High CPU usage with docker on alpine linux vmm

[aisha]

It doesn't seem like adding apmd and changing to 2000Hz made any 
difference.

tsc is still unstable and containerd is till using >70% CPU.

Hoping that vmd/vmm can soon run linux systems.

Thanks a lot for the work so far.

---
Aisha
blog.aisha.cc

On 2020-02-25 02:26, Mike Larkin wrote:

On Mon, Feb 24, 2020 at 09:56:31PM -0500, aisha wrote:

Hi all,

 I am running obsd -current and was trying to get alpine vmm to work, 
more

specifically to learn docker.

I'm noticing a very high CPU usage when I get docker running, which is
without any containers

Steps to reproduce:

1) Install alpine in a vmm

2) Install docker and start (first need to enable community repo)

apk add docker

rc-service docker start

Expected: Docker starts, life goes on

Reality:  Docker starts, CPU usage in vmm goes to ~75-90%, containerd 
is
using all the memory. Also, tsc is marked as unstable in dmesg for 
alpine


[ 0.00] tsc: Fast TSC calibration failed
[ 0.03] tsc: Using PIT calibration value
[ 0.03] tsc: Detected 18090.273 MHz processor
[ 0.02] clocksource: tsc-early: mask: 0x 
max_cycles:

0x104c2d0d539a, max_idle_ns: 440795933422 ns
[ 0.311645] clocksource: Switched to clocksource tsc-early
[ 0.510259] clocksource: timekeeping watchdog on CPU0: Marking 
clocksource

'tsc-early' as unstable because the skew is too large:
[ 0.510259] clocksource: 'tsc-early' cs_now: 5174087c0cc cs_last:
516d7de6c74 mask: 
[ 0.510259] tsc: Marking TSC unstable due to clocksource watchdog
[ 0.510654] TSC found unstable after boot, most likely due to broken 
BIOS.

Use 'tsc=unstable'.

This is a pretty crippling bug, as I am unable to do a lot more things 
on my
VM or on my actual machine, given that my plan was to run multiple 
VMs,

which has now been lost in the midst of clock errors and syncings.

Would love to know how anyone has managed to get this to work.



You might try a 2000HZ host machine and also force apm -H before 
running VMs.


For HZ, see param.c

-ml



Cheers,
Aisha


OpenBSD 6.6-current (GENERIC.MP) #653: Thu Feb 20 21:40:37 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34059407360 (32481MB)
avail mem = 33014579200 (31485MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb500 (59 entries)
bios0: vendor Intel Corp. version 
"S1200RP.86B.03.03.0003.121820151104" date

12/18/2015
bios0: Intel Corporation S1200RP
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S1 S3 S5
acpi0: tables DSDT FACP APIC SPMI FPDT MCFG WDDT HPET SSDT BOOT SSDT 
SSDT

SSDT SSDT SSDT SSDT DMAR HEST BERT ERST EINJ
acpi0: wakeup devices PEG0(S3) PEGP(S3) PEG1(S3) PEGP(S3) PEG2(S3) 
PEGP(S3)
RP01(S3) PXSX(S3) RP02(S3) PXSX(S3) RP03(S3) PXSX(S3) RP04(S3) 
PXSX(S3)

RP05(S3) PXSX(S3) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3193.05 MHz, 06-3c-03
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.62 MHz, 06-3c-03
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3192.62 MHz, 06-3c-03
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 

size of size_t (diff angle)

[zeurkous]

Haai,

The definition of size_t keeps biting me.

Some background: in nnx, me's been using the equiv of caddr_t for
counts. This works well; yet, while writing against existing code that
uses size_t, an issue has surfaced.

First of all, let us reflect upon the definition of size_t in C99.

> size_t
> which is the unsigned integer type of the result of the sizeof
> operator;

That's not very specific. It kind-of implies that SIZE_MAX (defined
later in the standard) is the largest possible offset, but not
necessarily the largest possible address. This reeks of i86 real mode
semantics, obsolete (for general-purpose machines) already when the
PDP-11 was new.

POSIX is even less helpful:

> size_t
> Used for sizes of objects.

(Let me note in passing that medisapproves of the significant overlap
between C99 and POSIX, and the shameless disregard, in both, of the
byte-oriented nature of UNIX and C).

So, as meknows of no better place to ask (take that as a compliment
folks!), mehas the following question *cue drums*:

Is SIZE_MAX guaranteed to *not* be greater than the highest address?

Me'd be grateful for any insight anyone can offer.

Thanks in advance,

Baai,

--zeurkous.

-- 
Friggin' Machines!

Determining which patches a snapshot contains

[Jonathan Schleifer]

Hi!

I'm wondering: If I upgrade to snapshots/sparc64/base66.tgz that is listed on 
ftp as
base66.tgz 24-Feb-2020 20:01   
175147678
Will it include 
?

I saw that the patch added two new strings, and those seem to match (this is 
after upgrading):

# strings /usr/sbin/smtpd | grep 'has bad uid' 
warn: smtpd: file %s has bad uid %d
# strings /usr/sbin/smtpd | grep 'has bad gid' 
warn: smtpd: file %s has bad gid %d

As well as the change to using the full path to makemap:
# strings /usr/sbin/smtpctl | grep makemap
makemap
makemap
makemap
usage: makemap [-U] [-d dbtype] [-o dbfile] [-t type] file
/usr/sbin/makemap

So does this mean the patch is included, or were some parts of the patch 
already applied earlier and this is still incomplete? It looks like 
https://github.com/openbsd/src/commit/0228dab008714e5c4cb4c4fdb7e20836742f6fc9 
contains all changes at once, so should I be good?

Thanks.

-- 
Jonathan

Re: openbsd.org - certain https URLs downgraded to http in redirection

[Vincenzo Nicosia]

On Tue, Feb 25, 2020 at 07:57:24AM -, Stuart Henderson wrote:

[cut]

> > Want https? great. use it.  There are times when it's handy to NOT
> > be obsessed with https (i.e., clock is hosed on your computer).  
> >
> > So ... unless some developer I really respect (which is just about
> > all of them1) tells me to change this, I'm not planning on
> > changing the behavior of the machines.
> 
> I did object to http->https redirects in the past, but now the web is
> unusable without working https anyway and the "INSECURE openbsd.org"
> shown on some browsers *is* a bit of an eyesore ...
> 

IMHO, the fact that corporates (Google) want to dictate what is secure
and what is not, is not sufficient to force everybody on https, at all
times. I personally don't give a toss of what Chrome thinks of a
website and its security (maybe because I have never used Chrome or
because I quit google searches more than 10 years ago...).

There are many cases where the overhead introduced by https is really
not worth the extra bit of confidentiality you get. And we are talking
here of manpages (that are installed in your system anyway) and of
system sources (that are available for download at any time, even from
an HTTPS mirror)...

Sorry for the rant, but if I type "http://bring.me.there; I don't want
to find myself at "https://we.brought.you.somewhere.else;. I am not a
chimp. I know what I type in my URL box. I know what I expect. And I
want to be able to serve content via HTTP/1.0 if I need so.