Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
On Fri, Feb 25, 2022 at 06:36:35PM -, Stuart Henderson wrote: > On 2022-02-25, Robert Nagy wrote: > > Maybe we need a default vmd class? What do you guys think? > > I definitely think it makes sense. Not sure whether it should just go in > etc.amd64 or the others too (vmd only exists on amd64 so far, but if it's > ever added e.g. to arm64 then adding it in the other files would avoid > having to remember to add it later..) > > Maybe the same 16G limit as bgpd by default.. > > I am in support of this change as well. Thanks everyone.
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
On Fri, Feb 25, 2022 at 01:46:00PM -0500, Ted Unangst wrote:
> On 2022-02-25, Robert Nagy wrote:
> > Maybe we need a default vmd class? What do you guys think?
>
> Regardless of what the limit is, this seems like a daemon where people
> will bump into the limit. Perhaps a reminder is in order too?
>
ok mlarkin on this one. thanks
>
> Index: vm.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/vm.c,v
> retrieving revision 1.67
> diff -u -p -r1.67 vm.c
> --- vm.c 30 Dec 2021 08:12:23 - 1.67
> +++ vm.c 25 Feb 2022 18:42:39 -
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
> ret = alloc_guest_mem(vcp);
>
> if (ret) {
> + struct rlimit lim;
> + const char *msg = "could not allocate guest memory - exiting";
> + if (getrlimit(RLIMIT_DATA, ) == 0)
> + msg = "could not allocate guest memory (data limit is
> %llu) - exiting";
> errno = ret;
> - fatal("could not allocate guest memory - exiting");
> + fatal(msg, lim.rlim_cur);
> }
>
> ret = vmm_create_vm(vcp);
>
Re: privileged instruction fault trap for pf_tabladdr_setup
Update: Reinstalling the OS and reapplying all patches cleared this issue. I can't explain why security fix 3 previously horked this system. dn On 2/23/22 7:04 PM, David Newman wrote: OpenBSD 7.0 GENERIC#3 i386, running as a VM on VMware vSphere 5.5 After applying a security fix through syspatch, this system failed on reboot with the error: kernel: privileged instruction fault trap, code=0 Stopped at: pf_tabladdr_setup: Links to trace and ps info below. Thanks in advance for clues on reviving this machine. There are other fault trap threads in the misc archive, but I found none about pf_tabladdr_setup. Some other threads suggesting underlying hardware problems. This is certainly possible but there are other VMs running OK on this host, and the host logs don't indicate any disk or memory trouble. FWIW I used this machine for years, at least back into the OpenBSD 5.x days, and have upgraded all along without issue. Here is the ddb trace: ddb> trace pf_tabladdr_setup(d0e95da8,d1dfaf58) at pf_tabladdr_setup pfioctl(4900,ccc84404,d1b26000,3,d19b1980) at pfioctl+0x4028 spec_ioctl(f3ac7734) at spec_ioctl+0x4c VOP_IOCTL(d19919e4,ccc84404,d1b26000,d19b1980) at VOP_IOCTL+0x53 vn_ioctl(d19bbc60,ccc84404,d1b26000,d19b1980) at vn_ioctl+0x4f sys_ioctl(d19b1980,f3ac78f0,f3ac78e8) at sys_ioctl+0x240 syscall(f3ac7930) at syscall+0x2cd Xsyscall_untramp() at Xsyscall_untramp+0xa9 end of kernel Unfortunately I can't copy/paste the output of 'ps' but I've posted screen captures of trace and ps here: https://ibb.co/WP4R58D https://ibb.co/9ZCNdd5 Thanks again. dn
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
On 2022-02-25, Robert Nagy wrote:
> Maybe we need a default vmd class? What do you guys think?
Regardless of what the limit is, this seems like a daemon where people
will bump into the limit. Perhaps a reminder is in order too?
Index: vm.c
===
RCS file: /cvs/src/usr.sbin/vmd/vm.c,v
retrieving revision 1.67
diff -u -p -r1.67 vm.c
--- vm.c30 Dec 2021 08:12:23 - 1.67
+++ vm.c25 Feb 2022 18:42:39 -
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
ret = alloc_guest_mem(vcp);
if (ret) {
+ struct rlimit lim;
+ const char *msg = "could not allocate guest memory - exiting";
+ if (getrlimit(RLIMIT_DATA, ) == 0)
+ msg = "could not allocate guest memory (data limit is
%llu) - exiting";
errno = ret;
- fatal("could not allocate guest memory - exiting");
+ fatal(msg, lim.rlim_cur);
}
ret = vmm_create_vm(vcp);
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
On 2022-02-25, Robert Nagy wrote: > Maybe we need a default vmd class? What do you guys think? I definitely think it makes sense. Not sure whether it should just go in etc.amd64 or the others too (vmd only exists on amd64 so far, but if it's ever added e.g. to arm64 then adding it in the other files would avoid having to remember to add it later..) Maybe the same 16G limit as bgpd by default..
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
Maybe we need a default vmd class? What do you guys think?
On 25/02/22 15:34 +0100, Paul de Weerd wrote:
> Hi all,
>
> In commit Eg1WuG7hzCoCPdcz, robert@ changed the ulimit for the daemon
> class in /etc/login.conf for amd64 from 'infinity' to 4096M (see [0]
> and [1]).
>
> This change broke my vmd setup, and I had to dig around to understand
> what happened. Sharing here in hopes of preventing others from
> wasting their time like I did.
>
>
> I have a VM that is configured with 4GB of RAM:
>
> [weerd@pom] $ grep -B2 4G /etc/vm.conf
> vm "builder" {
> owner weerd
> memory 4G
>
> After upgrading to a newer snapshot (and sysmerge'ing login.conf), vmd
> crashes when this VM gets started:
>
> pom vmd[98555]: builder: could not allocate guest memory - exiting: Cannot
> allocate memory
> pom vmd[71874]: vmm: read vcp id
> pom vmd[10670]: priv exiting, pid 10670
> pom vmd[73889]: control exiting, pid 73889
>
> (resource limits doing exactly what they're supposed to do here!)
>
> It took me longer than I care to admit to realize that this would be
> caused by the newly reduced datasize limit imposed by Robert's change.
> I fixed this by adding a dedicated login.conf stanza for vmd:
>
> [weerd@pom] $ tail -n7 /etc/login.conf
> ##
> # Local changes
> #
> # vmd runs VMs with 4GB, so it needs an increased datasize limit:
> vmd:\
> :datasize=5120M:\
> :tc=daemon:
>
> Alternatively, I could've stuck that bit in /etc/login.conf.d/vmd
> which would've had the same effect. But with that change everything
> is working just fine again. When you run into a similar issue, make
> sure not to just revert back to "infinite" - find a suitable limit for
> whatever piece of software you have and adjust accordingly.
>
> Cheers,
>
> Paul
>
> [0]: https://marc.info/?l=openbsd-cvs=164542553811748=2
> [1]:
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/etc.amd64/login.conf.diff?r1=1.21=1.22
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
>
--
Regards,
Robert Nagy
Re: OpenBSD pppoe and Bell Fibe
Hi Stuart, You got it right off the bat. I removed mtu config, replaced NONE with 0.0.0.1 and removed the dest line. Booted up and voila, a workable WAN IP address using pppoe passthrough. It seems like the realtek card may be holding back performance as I'm only pulling in 800Mbps or perhaps it is the APU but I have doubts there. My comparison is using my laptop to test pppoe credentials and fully saturating the internet connection; as well as using the router that came with the ISP's service (Home Hub 4000). In any case, all is working and thank you very much for your help! Time to find an Intel 10Gb PCIe card. Brodey Dover On Sun, 20 Feb 2022 at 12:46, Stuart Henderson wrote: > I would recommend trying it like my example, there is a race condition > when you list the destination address separately. > > -- > Sent from a phone, apologies for poor formatting. > > > On 20 February 2022 16:50:35 Brodey Dover wrote: > >> You make a very good point about attaching the configuration :-). >> >> inet 0.0.0.0 255.255.255.255 NONE mtu 1500 >> pppoedev re0 authproto pap >> authname 'username' authkey 'password' up >> dest 0.0.0.1 >> !/sbin/route add default -ifp pppoe0 0.0.0.1 >> >> That should help. >> >> Thank you, >> >> >> >> On Sun, 20 Feb 2022 at 06:06, Stuart Henderson >> wrote: >> >>> On 2022-02-19, Brodey Dover wrote: >>> > Hello all, >>> > >>> > I've configured hostname.pppoe0 and hostname.re0 as per the pppoe >>> manpage >>> > for OpenBSD (I'm running 7) and I'm unable to successfully leverage >>> the >>> > Bell HomeHub 4000's pppoe passthrough. I've verified that passthrough >>> does >>> > work with my Windows 7 laptop, however, I just can't get pppoe to >>> move past >>> > the initialization stage. >>> >>> Might help to show your config. >>> >>> My typical config in hostname.pppoe0 is something like this >>> >>> inet 0.0.0.0 255.255.255.255 0.0.0.1 pppoedev em1 authproto chap >>> authname "user@realm" authkey "password" up >>> >>> > The PADI gets sent, but ultimately it'll timeout. After adjusting to >>> the >>> > second config in the man page where mut1508 is set to the physical >>> device, >>> >>> That is a special case and is very unlikely to ever be _required_ by an >>> ISP and often won't work. Normally you're better off starting with the >>> default MTU to get things working initially, then try that later if >>> needed >>> as a refinement (but remember that it's there in case things stop working >>> later; sometimes internal changes in the ISP network will stop it from >>> working later).. >>> >>> > pppoe0: ipcp parse opt values: address 10.11.1.81 [not agreed] send >>> > conf-nak >>> >>> The other side proposed this address (possibly for the address of their >>> end of the connection?) and your side rejected it. >>> >>> -- >>> Please keep replies on the mailing list. >>> >>> >
login.conf daemon datasize limit effects on VMs with 4GB+ RAM
Hi all,
In commit Eg1WuG7hzCoCPdcz, robert@ changed the ulimit for the daemon
class in /etc/login.conf for amd64 from 'infinity' to 4096M (see [0]
and [1]).
This change broke my vmd setup, and I had to dig around to understand
what happened. Sharing here in hopes of preventing others from
wasting their time like I did.
I have a VM that is configured with 4GB of RAM:
[weerd@pom] $ grep -B2 4G /etc/vm.conf
vm "builder" {
owner weerd
memory 4G
After upgrading to a newer snapshot (and sysmerge'ing login.conf), vmd
crashes when this VM gets started:
pom vmd[98555]: builder: could not allocate guest memory - exiting: Cannot
allocate memory
pom vmd[71874]: vmm: read vcp id
pom vmd[10670]: priv exiting, pid 10670
pom vmd[73889]: control exiting, pid 73889
(resource limits doing exactly what they're supposed to do here!)
It took me longer than I care to admit to realize that this would be
caused by the newly reduced datasize limit imposed by Robert's change.
I fixed this by adding a dedicated login.conf stanza for vmd:
[weerd@pom] $ tail -n7 /etc/login.conf
##
# Local changes
#
# vmd runs VMs with 4GB, so it needs an increased datasize limit:
vmd:\
:datasize=5120M:\
:tc=daemon:
Alternatively, I could've stuck that bit in /etc/login.conf.d/vmd
which would've had the same effect. But with that change everything
is working just fine again. When you run into a similar issue, make
sure not to just revert back to "infinite" - find a suitable limit for
whatever piece of software you have and adjust accordingly.
Cheers,
Paul
[0]: https://marc.info/?l=openbsd-cvs=164542553811748=2
[1]:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/etc.amd64/login.conf.diff?r1=1.21=1.22
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
