Re: firefox+web.skype.com+microphone (on OpenBSD)?

[Stuart Longland]

On 23/1/21 5:37 am, Gregory Edigarov wrote:
> So it is just a matter of curiosity. What skype is missing on OpenBSD?

Users?  My guess is they think the user base for Skype on OpenBSD is
almost zero, so they don't see it being a platform worth supporting.

Part of the reason being that Skype never has worked properly on
OpenBSD, so users of Skype thus use Linux, Windows and MacOS X instead.
 An inescapable echo chamber of their own making due to the proprietary
nature of their service.

Part also could be that they need to be compatible with "embedded" Skype
clients that people purchased years ago, and thus are stuck with the
CODECs and protocols those devices support.  With no support for these
CODECs in the browsers, they either have to embed proprietary browser
extensions or transcode server-side.

I'll note that I haven't used Skype in almost 10 years now.  It was a
proprietary native desktop application then, there was none of this
"web-based" stuff.  That said, I've witnessed it fail to work properly
for family members on Android many times.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: OpenBSD VM creation problem

[Hakan E. Duran]

Dear Markus,

On 21/01/23 05:04AM, Markus Wernig wrote:
>  ...
> Not sure if this is the same problem, but I did have similar trouble with
> qemu and OpenBSD in the past. I had to disable mpbios and acpimadt in the
> kernel to make it work. See boot_config(8).

You are a life saver. Thank you so much for so quickly and surgically
solving my problem!

Best regards!

Hakan

Bootloader on USB stick fails with "root device not found"

[tetrahedra]

As per this discussion I am trying to set up the bootloader on an 
external USB stick to boot my FDE-encrypted disk:

https://marc.info/?l=openbsd-misc=158196161321272=2

When booting from the USB stick (which contains a full install), I 
follow the softraid.4 man page example and do:

boot> boot sr0a:/bsd

When booting, the boot stops immediately after "scsibus4 at softraid0: 
256 targets" with the error message "panic: root device (..) not found"


If I boot from the standard bootloader on the FDE encrypted disk itself, 
everything boots fine.


Has something changed since the earlier discussion, is it no longer 
possible to use a USB stick to boot an encrypted partition?

Re: amdgpu unstable atm

[rgc]

On Sat, Jan 23, 2021 at 08:49:13PM +0900, rgc wrote:
> On Fri, Jan 22, 2021 at 08:33:37PM +0900, rgc wrote:
> > misc@
> > 
> > sharing some information for the devs
> > 
> > just did a sysupgrade of a -current amd64 machine
> > X (only, sent me back to login screen of xenodm) crashed 2x already
> > running only dwm and firefox-esr
> > 
> > machine is:
> > hw.vendor=ASUSTeK COMPUTER INC.
> > hw.product=Zephyrus G GU502DU_GA502DU
> > 
> > iGPU is:
> > amdgpu0: PICASSO 10 CU rev 0x01
> > 
> > dmesg error:
> > [drm] *ERROR* ring sdma0 timeout, signaled seq=402, emitted seq=402
> > [drm] *ERROR* Process information: process  pid 0 thread Xorg pid 50457
> > [drm] *ERROR* ring gfx timeout, but soft recovered
> > [drm] *ERROR* Error in DP aux read transaction, not writing source specific 
> > data
> > [drm] *ERROR* ring sdma0 timeout, signaled seq=1197, emitted seq=1197
> > [drm] *ERROR* Process information: process  pid 0 thread  pid 0
> > [drm] *ERROR* Error in DP aux read transaction, not writing source specific 
> > data
> > 
> > others:
> > amdgpu-firmware-20201218 firmware binary images for amdgpu(4) driver
> > 
> > kern.version=OpenBSD 6.8-current (GENERIC.MP) #286: Thu Jan 21 09:31:59 MST 
> > 2021
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > 
> > ~ rgc
> > 
> 
> no crashes yet with:
> 
> kern.version=OpenBSD 6.8-current (GENERIC.MP) #288: Fri Jan 22 13:36:58 MST 
> 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> ~ rgc
> 

misc@

kept the machine running overnight
stterm and firefox-esr (static websites) running. looked good.

this morning i went to github to cleanup some personal projects
after a few minutes, firefox-esr stopped responding.
can not switch to stterm on another pane (ALT-1)

network connectivity was still OK.
last messages on dmesg:

wsdisplay0: screen 1-5 added (std, vt100 emulation)
[drm] *ERROR* Error in DP aux read transaction, not writing source specific data
[drm] *ERROR* Error in DP aux read transaction, not writing source specific data

remotely, i tried killing process one by one. firefox-esr, xenodm, lastly X 
itself.
got a blank screen on the Asus, but i could get the console. started xenodm and
now working again.

~ rgc

Problem in gstreamer1-plugins-good-1.18.3

[Anindya Mukherjee]

Hi, it seems that gstreamer1-plugins-good-1.18.3 has an issue in file:
/usr/local/lib/gstreamer-1.0/libgstossaudio.so. Attemting to load it
causes the following error:
gst-plugin-scanner:/usr/local/lib/gstreamer-1.0/libgstossaudio.so:
undefined symbol '_oss_ioctl'

Running the most current snapshot with updated packages.
kern.version=OpenBSD 6.8-current (GENERIC.MP) #291: Sat Jan 23 12:54:25
MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Thanks,
Anindya

Re: New variant of rtl8168h supported?

[Jonathan Gray]

On Sat, Jan 23, 2021 at 08:53:44AM -0600, John Batteen wrote:
> Just working in chronological order, this patch from j...@jsg.id.au was 
> sufficient to make it work.  I have not tried the subsequent patch from 
> b...@comstyle.com, though I can if you want.
> 
> re1 at pci4 dev 0 function 0 vendor "Realtek", unknown product 0x8161 rev 
> 0x15: RTL8168H/8111H (0x5400), msi, address d8:07:b6:54:d7:98
> 
> Thanks!!
> 
> John

Thanks, committed with the id added to pcidevs.

Re: FDE disk setup instructions are misleading when installing from USB

[Bryan Wright]

> On Jan 23, 2021, at 09:34, tetrahe...@danwin1210.me wrote:
> 
> On Fri, Jan 22, 2021 at 04:44:31PM -0800, Bryan Wright wrote:
>> 
>> 
>>> but to set up FDE I had to reference the official FAQ
>> 
>> Referring to the official documentation is a key distinction between 
>> successful OpenBSD use and that of many other systems; the early that gets 
>> hammered home the better, right?  It’s practically unGoogleable, if that’s a 
>> word.
>> 
>> It can be super frustrating at times, but half blindly following a guide or 
>> entering some unexplained command from Stackoverflow, while being much 
>> easier, has got to be among the most dangerous patterns we can adopt.  Using 
>> OpenBSD has been a very humbling experience, but I’ve learned so, so much by 
>> being forced to adopt better practices.
> 
> For the record, I started by reading the FAQ from start to finish, before I 
> installed anything.
> 
> Unfortunately it's a little difficult to connect to reality (or even 
> remember) much of what one reads when one does this.
> 
> "Does this obscure technical reference apply to my situation? I don't know, I 
> haven't worked with anything related to it yet!"
> 
> To make matters worse, there are an awful lot of details that are not 
> realistic to get out of the official documentation... I would have had to 
> read a significant percentage of all the manpages, and a lot of mailing list 
> traffic, in order to arrive at the same steps provided in how-tos like 
> .
> 
> Could I have done that? Sure. Would spending 40-80 hours reading 
> documentation just to get a laptop set up, when I don't know whether I'm 
> going to use it for more than experimental purposes, have been a good use of 
> my time? Certainly not.
> 
> I have no quarrel with OpenBSD requiring new users to immediately dive into 
> parts of the system that other operating systems try as hard as possible to 
> hide... but for practical reasons it does seem necessary to do a little 
> hand-holding along the way.
> 
> I am therefore extremely grateful to Cullum Smith and the other "OpenBSD on a 
> laptop" howtos for making it feasible to get this far.

Yeah, absolutely.  I won’t pretend I didn’t read all the same sources you 
mentioned. I hope I didn’t come across as proud or stuffy; I’m a nobody, and I 
could use a lot of hand holding myself.  I totally hear you. 

I don’t speak for the developers, but it’s been stated many times that they 
make the system for themselves, and if we can use it, great. Growing the number 
of new users would be much easier than multiplying the number of competent, 
contributing developers, and it can turn into us feeling like they owe us 
things they never signed up for. There is plenty of help, for sure, but hand 
holding is not likely to be a priority any time soon.  That’s just how it is, 
and I can’t fault anyone for it.  

Perhaps someone will make some changes to the installer or documentation. But, 
I can tell you, a diff,  or at least a proposed specific solution, will always 
go a lot further than pointing out a potential problem, simply because there 
are relatively few developers and they all have things they are busy with. 
I’m not sure what the best solution would be, but if you’ve got an idea, you 
should definitely submit it.

I hope it all works out for you and that any perceived faults or difficulties 
won’t keep you from finding all the advantages of OpenBSD. 

Re: FDE disk setup instructions are misleading when installing from USB

[tetrahedra]

On Fri, Jan 22, 2021 at 04:44:31PM -0800, Bryan Wright wrote:




but to set up FDE I had to reference the official FAQ


Referring to the official documentation is a key distinction between successful 
OpenBSD use and that of many other systems; the early that gets hammered home 
the better, right?  It’s practically unGoogleable, if that’s a word.

It can be super frustrating at times, but half blindly following a 
guide or entering some unexplained command from Stackoverflow, while 
being much easier, has got to be among the most dangerous patterns we 
can adopt.  Using OpenBSD has been a very humbling experience, but I’ve 
learned so, so much by being forced to adopt better practices.


For the record, I started by reading the FAQ from start to finish, 
before I installed anything.


Unfortunately it's a little difficult to connect to reality (or even 
remember) much of what one reads when one does this.


"Does this obscure technical reference apply to my situation? I don't 
know, I haven't worked with anything related to it yet!"


To make matters worse, there are an awful lot of details that are not 
realistic to get out of the official documentation... I would have had 
to read a significant percentage of all the manpages, and a lot of 
mailing list traffic, in order to arrive at the same steps provided in 
how-tos like .


Could I have done that? Sure. Would spending 40-80 hours reading 
documentation just to get a laptop set up, when I don't know whether I'm 
going to use it for more than experimental purposes, have been a good 
use of my time? Certainly not.


I have no quarrel with OpenBSD requiring new users to immediately dive 
into parts of the system that other operating systems try as hard as 
possible to hide... but for practical reasons it does seem necessary to 
do a little hand-holding along the way.


I am therefore extremely grateful to Cullum Smith and the other "OpenBSD 
on a laptop" howtos for making it feasible to get this far.

Re: New variant of rtl8168h supported?

[John Batteen]

Just working in chronological order, this patch from j...@jsg.id.au was 
sufficient to make it work.  I have not tried the subsequent patch from 
b...@comstyle.com, though I can if you want.

re1 at pci4 dev 0 function 0 vendor "Realtek", unknown product 0x8161 rev 0x15: 
RTL8168H/8111H (0x5400), msi, address d8:07:b6:54:d7:98

Thanks!!

John

On 1/22/21 7:46 PM, Jonathan Gray wrote:

On Fri, Jan 22, 2021 at 06:58:05PM -0600, John Batteen wrote:

Hi misc,

I just bought a TP-link TG-3468, and the chip says 8168h on it, but it is not 
recognized by 6.8-current.  Is this chip truly unsupported or just unrecognized?

Thanks,

John

The line from dmesg is:
vendor "Realtek", unknown product 0x8161 (class network subclass ethernet, rev 
0x15) at pci4 dev 0 function 0 not configured


It looks like adding the new id should be enough here.

Can you try a kernel with this?

Index: sys/dev/pci/if_re_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_re_pci.c,v
retrieving revision 1.53
diff -u -p -r1.53 if_re_pci.c
--- sys/dev/pci/if_re_pci.c 17 Jun 2020 10:48:44 -  1.53
+++ sys/dev/pci/if_re_pci.c 23 Jan 2021 01:42:48 -
@@ -57,12 +57,15 @@ struct re_pci_softc {
bus_size_t sc_iosize;
  };
  
+#define PCI_PRODUCT_REALTEK_RT8168_2 0x8161

+
  const struct pci_matchid re_pci_devices[] = {
{ PCI_VENDOR_COREGA, PCI_PRODUCT_COREGA_CGLAPCIGT },
{ PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE528T },
{ PCI_VENDOR_DLINK, PCI_PRODUCT_DLINK_DGE530T_C1 },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8101E },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8168 },
+   { PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8168_2 },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169 },
{ PCI_VENDOR_REALTEK, PCI_PRODUCT_REALTEK_RT8169SC },
{ PCI_VENDOR_TTTECH, PCI_PRODUCT_TTTECH_MC322 },

Re: Alpine hangs on send in fresh install of 6.8

[Peter J. Philipp]

On Sat, Jan 23, 2021 at 08:33:11AM -0700, aus...@computershop.ca wrote:
> 
> Anyone out there still using Alpine mail client with 6.8?
> 
> Used Alpine for 20 years or more, and recently set up a new mail server.
> Old one used to be on a 5.3 OpenBSD version.
> 
> New one works fine in every respect for reading and saving incoming messages, 
> going to subfolders, but after composing a message it hangs as soon as I give
> the ^X to send it. Have to close the X-window to get rid of the session, and
> then kill the hanging task PID with a kill -9 
> 
> The basic "Mail" email client works fine -- and I am using it here,
> but it doesn't have the conveniences I am used to. 
> 
> Any suggestions appreciated.  
> 
> -- Austin

Hi Austin,

Here is how I would go about debugging this.  ktrace, it's a powerful tool.
ktrace -i alpine it and do what you normally do and then kill -9.  When
that's done use kdump to trace back where the SIGKILL signal killed it.  It's
usually at the end.  So if you do kdump | less and press 'G' no quotes it will
go right to the end.  From there scroll up, to see where it may be hanging.
You could be useing kdump -TR as well to see relative time since start of
the program...

One warning through ktrace will fill up a file called ktrace.out relatively
quickly.  A ktrace -C ensures that all ktraces are stopped in the system if
you suspect it's still ongoing.  To check that kdump -l perhaps or just 
ls -l ktrace.out.

You will be faced with every system call made by alpine including forks and
execution of other programs, so if you send mail it's possible that you see
the sendmail wrapper binary and any other binaries that are executed.  Do have
a good look at the ktrace and kdump manpages before doing my advice though.

Another warning is not to share that data, which makes it difficult to debug
if you don't know this set of programs.  It's private data and noone should 
have an insight of what your mailbox looks like.  So it's difficult...

Another advice I have is perhaps keep an eye on dmesg, perhaps you're hitting
a constraint somewhere?

Best Regards,

-peter

Re: amdgpu unstable atm

[rgc]

On Fri, Jan 22, 2021 at 08:33:37PM +0900, rgc wrote:
> misc@
> 
> sharing some information for the devs
> 
> just did a sysupgrade of a -current amd64 machine
> X (only, sent me back to login screen of xenodm) crashed 2x already
> running only dwm and firefox-esr
> 
> machine is:
> hw.vendor=ASUSTeK COMPUTER INC.
> hw.product=Zephyrus G GU502DU_GA502DU
> 
> iGPU is:
> amdgpu0: PICASSO 10 CU rev 0x01
> 
> dmesg error:
> [drm] *ERROR* ring sdma0 timeout, signaled seq=402, emitted seq=402
> [drm] *ERROR* Process information: process  pid 0 thread Xorg pid 50457
> [drm] *ERROR* ring gfx timeout, but soft recovered
> [drm] *ERROR* Error in DP aux read transaction, not writing source specific 
> data
> [drm] *ERROR* ring sdma0 timeout, signaled seq=1197, emitted seq=1197
> [drm] *ERROR* Process information: process  pid 0 thread  pid 0
> [drm] *ERROR* Error in DP aux read transaction, not writing source specific 
> data
> 
> others:
> amdgpu-firmware-20201218 firmware binary images for amdgpu(4) driver
> 
> kern.version=OpenBSD 6.8-current (GENERIC.MP) #286: Thu Jan 21 09:31:59 MST 
> 2021
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
> ~ rgc
> 

no crashes yet with:

kern.version=OpenBSD 6.8-current (GENERIC.MP) #288: Fri Jan 22 13:36:58 MST 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

~ rgc

Alpine hangs on send in fresh install of 6.8

[austin]

Anyone out there still using Alpine mail client with 6.8?

Used Alpine for 20 years or more, and recently set up a new mail server.
Old one used to be on a 5.3 OpenBSD version.

New one works fine in every respect for reading and saving incoming messages, 
going to subfolders, but after composing a message it hangs as soon as I give
the ^X to send it. Have to close the X-window to get rid of the session, and
then kill the hanging task PID with a kill -9 

The basic "Mail" email client works fine -- and I am using it here,
but it doesn't have the conveniences I am used to. 

Any suggestions appreciated.  

-- Austin

UEFI GOP mode, OVMF/TianoCore and QEMU vga std: extremely high resolution choice by default

[pandame]

Hi all,

I have recently attempted to install OpenBSD on QEMU, using UEFI boot
and OVMF/TianoCore. I configured OVMF to have a resolution of 1440x900,
which mapped to GOP mode 18.

boot(8) kept this resolution. When booting, efifb then uses the largest
possible resolution that is exposed by the QEMU "std" video driver via
OVMF, which is a very high resolution that is at most appropriate for
people equipped with 4K monitors.

I can override this with machine gop 18 (or whatever resolution is
desired).

I have traced this back to sys/arch/amd64/stand/efiboot/efiboot.c lines
855-868: When no GOP mode is specified, gopmode == -1.  In this case,
the code probes for the largest possible resolution available and sets
it as the resolution passed on boot. The machine gop 18 command forces
the gopmode variable and bypasses this auto-detection.

However, I do not understand the reason that this auto-detection code
was added for. Why is the GOP mode forwarded from UEFI not used
directly? Why bother with finding the greatest possible resolution and
then using that? Isn't it the job of UEFI to find this out for you?

Thank you for your time. Apologies if this was already answered on the
mailing lists and I failed to find the pertinent conversation(s).

Cheers,

Mark 'pandame' Rogers

Re: FDE disk setup instructions are misleading when installing from USB

[Stuart Henderson]

On 2021-01-22, Bryan Wright  wrote:
> Simply changing the example, though, won’t fix the problem of a user not 
> paying sufficient attention to protect themselves from themselves. 

The real fix for this would be to add proper support to the installer,
at least for the simpler case of FDE (mirrors would be handy too but
the UI would be more complex and I bet FDE covers what most people
use softraid for).

opensmtpd: mta server-cert-check result="failure"

[Grégoire Jadi]

Hi misc@,

I send this mail just in case someone else encounter the issue.

On OpenBSD 6.8-stable, opensmtpd fails to upgrade to TLSv1.2 when
relaying mail to a host with a self-signed certificate.

- In maillog the error is:

mta tls ciphers=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256
mta server-cert-check result="failure".

- Check with openssl:

openssl s_client -connect smtp.example.com:25 -starttls smtp

-> Verify return code: 20 (unable to get local issuer certificate)


Whereas the same command on OpenBSD 6.8-current returns:

-> Verify return code: 18 (self signed certificate)

Upgrading to OpenBSD 6.8-current fixes the issue.


Note that this is only an issue when enforcing tls verification in
smtpd.conf.  Otherwise, in my case, I ended-up being greylisted.

Thank you all for your work.

Best,

-- 
gjadi
PGP : AF26 E9C2 A1C8 8D32 A868  4386 1373 5477 2B65 1894

Re: Understanding memory statistics

[Otto Moerbeek]

On Sat, Jan 23, 2021 at 04:40:06AM +, Anindya Mukherjee wrote:

> Thanks for the explanation! I noticed during my earlier investigation
> that the source of the data size is struct vmspace::vm_dused. This is
> updated mostly in uvm_mapanon and uvm_map. The second function seems to
> be a more general case. I think during my file mapping the second
> function is called and the part where vm_dused is updated is skipped.
> I'm setting up a VM on my machine with a debug kernel (this should be an
> interesting exercise) to do some exploratory kernel debugging, just to
> understand the process. So far this seems to make sense. I never doubted
> the system is doing the "right" thing :)
> 
> I also had some questions about the page and the buffer caches. So far I
> gathered the following facts (please correct me if I am wrong):
> 
> OpenBSD has separate page and buffer caches, i.e., no UBC.
> Q: Is this done for security reasons or due to some complication? Just
> curious.

page cache is a misnomer, it does not exist.

UBC is the concept that file i/o via mmapped files and the read/write
systemc calls use the same mechanism for caching the files in memory.
One of the consequences is that if a file is both mmapped and being
written to via write(2), that change is also visible in the mmapped
view immediately. Vice-versa the same.

We do not have that unification, a long time ago an attempt was done
(you can still find that in cvs) but that was reverted since it caused
all kinds of probems the author wasn't able to solve in reasonable
time. So My guess it would be we do not have it because of
complexity/nobody did and finished the work.

So the machanism we have is a buffer cache (which in the end uses
pages) used by the read and write system calls. Plus we have the
mmapping mechanism used for both file mapping and anonymous mappings
(mappings not corresponding to any file, like program data).

> 
> The Inactive pages seem to back the page cache. I ran my file mapping
> code a few times mapping/releasing a large file (about 300 MB) with
> systat running in the uvm view, and saw the page counts for Active and
> Inactive swing back and forth, keeping the total fixed.
> 
> Then I ran md5 on another 100 MB file, and this time the Cache number in
> top grew by about 100 MB, with some brief disk activity (I'm on SSD so
> things are zippy). I next ran my file mapping program on it. This time
> the Active pages grew by about 100 MB, raising the total by the same
> amount. When the program ended, those pages moved to Inactive, keeping
> the total fixed. There was no disk activity during this and Cache
> remained unchanged.
> 
> This seems to indicate that the data for the new file was copied from
> the buffer cache to the page cache during the mapping, and both copies
> were maintained.

Mmapped file activity would indeed show in Active or Inactive pages
(which one depends on how much access is done to the pages) while I/O
via read or write shows up in Cache indeed. But I would not know from
the top of my head if pages in the Buffer Cache from a file are
explicitly copied to new pages when the same files is mmapped or just
cause some changes on the page admin level so that the mapping refers
to pages that are already in mem via the Buffer Cache. Thinking about
it it would involve some form of unification, so likely some mem to
mem copying is going on. It shows my experience is mostly userland
memory management

-Otto

> 
> Regards,
> Anindya
> 
> From: Otto Moerbeek 
> Sent: January 22, 2021 12:01 AM
> To: Anindya Mukherjee 
> Cc: misc@openbsd.org 
> Subject: Re: Understanding memory statistics 
>  
> On Thu, Jan 21, 2021 at 10:38:59PM +, Anindya Mukherjee wrote:
> 
> > Hi,
> > 
> > Just to follow up, I was playing with allocating memory from a test
> > program in various ways in order to produce a situation when SIZE is
> > less than RES. The following program causes this to happen. If I mmap a
> > large file, the SIZE remains tiny, indicating that the mapped region is
> > not counted as part of text + data + stack. Then when I go ahead and
> > touch all the memory, SIZE remains tiny but RES grows to the size of the
> > file. Very interesting.
> 
> So SIZE does not include mappings backed by a file system object, but
> RES does. RES only grows once the pages are touched, this is demand
> paging in action (anon pages act the same way).
> 
> Nice. I already suspected would be something like that, but never took
> the time to find out by experimenting or code study.
> 
> Now the next quesion is if SIZE *should* include non-anonymous
> pages. getrlimit(2) explicitly says RLIMIT_DATA (which is limiting
> SIZE) only includes anonymous data. So that hints SIZE indeed should not
> include those anon pages. 
> 
> To back this up:
> 
> ps(1) lists several size related stats:
> 
> Desc    Keyw    Function    Value
> Data dsiz    dsize   p_vm_dsize
> Resident 1  rss p_rssize