Re: Large datasize - how to limit physical memory?
On Thu, Oct 06, 2016 at 11:39:49AM -0400, Ted Unangst wrote: > Raimo Niskanen wrote: > > On Wed, Oct 05, 2016 at 12:34:42PM -0400, Ted Unangst wrote: > > > If somebody writes a C program that demonstrates the problem, I'm happy to > > > take a look. I'm not installing erlang. > > > > It has been ages since I wrote a C program from scratch, but here goes: > > Thanks. That wasn't so bad, was it? :) No, I might even have kind of liked it ;-) > > > And the symptom would be that the ulimit -m limit is not immediately > > enforced. The question is if that is a problem? Or rather if I can use > > the ulimit -m limit to prevent a process from taking all memory since I > > need to set a large ulimit -d size to do clever address comparision tricks > > in the Erlang VM. > > Ah, indeed. So ulimit -m doesn't do anything any more. I'm not sure when it > stopped, but the man page reflects ancient history. Sorry about that. > Unfortunately, it's not easy to make PROT_NONE stop counting. After all, it > may have been mapped read/write, and modified, then mapped none, but we can't > discard the page. So a program may count on the content persisting after that manouver... Ugh! I am quite happy with PROT_NONE not counting, but are you saying that if you would start counting PROT_READ|PROT_WRITE you would have to also count PROT_NONE, which would make the trick of allocating a large PROT_NONE block just for its address space not usable. And the manual page is wrong in claiming that ulimit -m takes effect when the system gets low on memory? So the only memory limit that is enforced is ulimit -d? Bummer. What I guess we (VM tricksters) would really want is MAP_NORESERVE... -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
DHCP over vr(4) on bridge(4) through vether(4) no working?
Hello misc@ I have a home router where it seems that DHCP over vr(4) on bridge(4) through vether(4) does not work. Sorry about the lack of hard details, it was late last night, I was tired and need to figure out what details to look into now... The home router is an ALIX 2d13 which has 3 vr(4) interfaces on board and one athn(4) on mini-PCI. WAN is vr2, LAN is vr1 and WLAN is athn0. I had a setup working with dhcpd serving constant addresses based on MAC address to the LAN on vr0 and athn0 with one address range for vr0 and one for athn0. Now I need to start using the 5 GHz Wifi band so I asked the athn0 with "ifconfig athn0 chan" which channels it supported, tried to configure a 5 GHz one and got an IOCTL error so I guiss it was not acually supported. Then I bought an ASUS EA-N66 access point that can do 5 GHz and connected it to vr1. I did a bridge configuration according to the FAQ with bridge0 containing athn0, vr1 and vether0. vether0 got the IP address configuration that athn0 had before, dhcpd was reconfigured to serve vr0 and vether0 and that worked just fine. DHCP over athn0 passes through bridge0 and vether0 to dhcpd as well as directly from vr0 to dhcpd. But DHCP over vr1 through bridge0 and vether0 does not work. I had to configure a static address on the access point to get any further. I know that DHCP over vr0 that dhcpd serves directly works, and I know that it works when dhcpd serves athn0 directly, plus it works when dhcpd serves athn0 throught bridge0 and vether0. I tcpdumped vr1 (but now I was getting really tired) and saw 0.0.0.0.bootp -> 255.255.255.255.bootc packets that I think are DHCP broadcasts from a client. But when tcpdumping on vether0 I think I did not see them (lots of chatter), but possibly other strange packets. When letting a client connect over athn0, on the other hand, I think I saw these broadcast packets on vether0, and got log entries in /var/log/daemon about dhcpd giving out a license. Not so when letting a client connect over the access point and vr0. So my theory is that either have I missed some stupid little flag, or there is a bug in vr(4) when it passes packets over a bridge(4) to a vether(4) so encapsulation is misinterpreted and the IP broadcasts does not arrive in recognizable shape... Any hints on how to procede? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: DHCP over vr(4) on bridge(4) through vether(4) no working?
Raimo Niskanen @ 2016-10-07T09:46:06 +0200: > Hello misc@ > > I have a home router where it seems that DHCP over vr(4) on bridge(4) > through vether(4) does not work. > [...] > Any hints on how to procede? Just a shot in the dark, but maybe: http://marc.info/?l=openbsd-misc&m=147462832805431&w=2 http://undeadly.org/cgi?action=article&sid=20160725144108 Daniel
Re: DHCP over vr(4) on bridge(4) through vether(4) no working?
On Fri, Oct 07, 2016 at 10:42:40AM +0200, LÉVAI Dániel wrote: > Raimo Niskanen @ 2016-10-07T09:46:06 +0200: > > Hello misc@ > > > > I have a home router where it seems that DHCP over vr(4) on bridge(4) > > through vether(4) does not work. > > > [...] > > Any hints on how to procede? > > Just a shot in the dark, but maybe: > > http://marc.info/?l=openbsd-misc&m=147462832805431&w=2 > http://undeadly.org/cgi?action=article&sid=20160725144108 Nice shot, but a close miss. I have vr0-bridge0-vether0 and no dhclient running on neither vr0 nor vether0. The client runs on vr2. Also I see no log entrys in /var/log/daemon from dhcpd about getting a DHCPDISCOVER and sending a DHCPOFFER, which I get when the request comes in over athn0-bridge0-vether0... So it is the incoming that does not arrive. > > > Daniel -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: W^X issues running valgrind
On Thu, Oct 06, 2016 at 03:42:54PM +0200, Andreas Kusalananda Kähäri wrote: > On Thu, Oct 06, 2016 at 12:57:43PM +0100, Stuart Henderson wrote: > > On 2016/10/06 13:23, David Coppa wrote: > > > On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri > > > wrote: > > > > Hi, > > > > > > > > Let me know if this should be on ports rather than here. > > > > > > > > I'm following OpenBSD current on amd64, updating the system a couple of > > > > times a week, and I'm using valgrind from ports to check a C program for > > > > memory leaks. However, since recently (sorry, can't specify closer, > > > > within the last couple of months) I get a W^X violation when I try it. > > > > > > devel/valgrind is missing the USE_WXNEEDED=Yes marker. > > > > valgrind works by preloading an .so file and wrapping library functions > > to override with its own versions. > > > > You will at least need to link the program under test with -Wl,-z,wxneeded > > but you might need to do more than this. > > > > Adding USE_WXNEEDED=Yes to the valgrind port cuts down the error from > valgrind to just > > valgrind: mmap(0x108000, 4550656) failed in UME with error 12 (Cannot > allocate memory). > > ... and a notification of a W^X violation from the kernel as before. > Adding "-Wl,-z,wxneeded" when linking my application makes no > difference. I'm still trying to run it under /home with wxneeded added > to the mount flags as before. > > Is there anything else I could try? Adding wxallowed to the mount options of every single partition and adding -Wl,-z,wxneeded to every step of the compilation doesn't help either. It feels as if I'm missing something basic here. Andreas -- Andreas Kusalananda Kähäri Bioinformatics Developer NBIS, Uppsala University http://www.nbis.se/ [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: W^X issues running valgrind
On 2016-10-07, Andreas Kusalananda Kähäri wrote: > > Adding wxallowed to the mount options of every single partition and > adding -Wl,-z,wxneeded to every step of the compilation doesn't help > either. Scattering wxallowed flags on every partition is not going to do anything useful. Are your -Wl,-z,wxneeded changes working correctly? You need to be producing binaries with an OPENBSD_WXNEEDED section (visible with objdump -p). > It feels as if I'm missing something basic here. The basic thing is that somebody who is interested in running valgrind on OpenBSD needs to figure out how (and if it's possible) to use it now that we are doing W^X enforcement.
Re: Setting flags on /dev/audio
On Fri, Oct 07, 2016 at 08:11:46AM +1100, Tobias Brodel wrote: > On 10/06/16 22:44, ludovic coues wrote: > >misc strip attachment. Please send your diff inline or start a new thread > >on dev > Thanks forthe pointer Ludovic, > Hi, We moved significant parts of the audio and MIDI sub-system out of the kernel, so now programs have to use the sio_open(3) interface. The audio(4) interface is just a thin private layer to access the bare hardware internally. From this stand-point changes in audio(4) that are not used by the library make no sense.
OpenBSD vmx driver performance on VMware 5.5 and 6.0
Hi All We have OpenBSD running in VMware 5.5 for about 2 years and recently 6.0. So over multiple OpenBSD releases. It is stable and works, and we can use both em and vmx driver, but only get around 1.5 - 2.0 Gbit/s Example between two VMware ESXi 6.0 servers connected with dual 10G connections across Juniper EX switch root@skyfw-osl1-02:root# iperf -s Server listening on TCP port 5001 TCP window size: 16.0 KByte (default) [ 4] local 185.161.127.28 port 5001 connected with 185.161.127.29 port 8188 [ ID] Interval Transfer Bandwidth [ 4] 0.0-60.0 sec 13.1 GBytes 1.87 Gbits/sec client command: iperf -t 60 -i 5 -c What are other people getting from OpenBSD network drivers in VMware? Note: we also use OpenBSD as firewalls/gateways inside VMware and the performance is also less than expected for that. Note: same environment get almost full 10G wire speed from Ubuntu 14.04/16.04 etc. We are very interested in getting this performance up, so any ideas are welcome. Best regards Henrik -- Best regards/Mvh Henrik -- Henrik Lund Kramshøj, cand.scient CISSP Network Security Engineer, PatientSky Danmark ApS h...@patientsky.com +45 2678 1919
Re: quirks "unsigned package," "Can't find CONTENTS"
On Thu, Oct 6, 2016 at 11:48 PM, Foo74 wrote: > > Thanks for posting the response. Do you know what from the error message > shows that it was a -current build? I think I would have spent days figuring > that out. :) Replying to list as well- There were two clues. One was how uname -a reported the kernel as GENERIC.MP#2172 - that number on the end would tell someone more "in the know" that it wasn't the right build for either "release" or "current" The other hint was in the error itself, as Josh emailed this morning: "Just to briefly elaborate, the development branch (-current) recently had updates to signed package management, and to signify(1), and these developments are both still ongoing / evolving." Which makes me think- that name that says "GENERIC"- would be good to have the flavor in it.
Re: autoinstall (eg: disklabel -T) doesn't support templates that specify partition sizes in sectors?
On Thu, Oct 06, 2016, Erling Westenvik wrote: [I'm only replying because I ran into a problem in this area and posted a patch suggestion to the tech list; a different fix was applied after some discussion.] > templates, I was a little surprised to find that disklabel(8) apparently > does not support specifying partition sizes givin in sectors, only in ... > or megabytes. But I got curious as to why templates cannot be specified > in sectors? Just a guess: maybe because nobody needed it (so far)? apply_unit() in src/sbin/disklabel/editor.c might be something you want to look at and provide a patch? If a developer considers it interesting/important enough, it might get into the tree.
seamonkey package x86
Hi, has the seamonkey package been removed or has it special issues? I see it available on amd64 but not on x86... although seamonkey-enimgmail is present. I'd like to avoid building it myself if it is known to fail and also it is oen fo the "big" packages to build on a laptop. Thank you, Riccardo
Re: Large datasize - how to limit physical memory?
Raimo Niskanen wrote: > And the manual page is wrong in claiming that ulimit -m takes effect when > the system gets low on memory? > > So the only memory limit that is enforced is ulimit -d? yeah. i'll fix the manual. thanks for noticing. > Bummer. > > What I guess we (VM tricksters) would really want is MAP_NORESERVE... that's not very hard to add. uvm has a concept of maxprot, which is the maximum protections one can add to a page. userland doesn't really get any control over this however. there could be a flag that leaves maxprot as none, and then we wouldn't need to count that as memory.
Re: seamonkey package x86
On 2016-10-07, Riccardo Mottola wrote: > has the seamonkey package been removed or has it special issues? I see > it available on amd64 but not on x86... although seamonkey-enimgmail is > present. > I'd like to avoid building it myself if it is known to fail and also it > is oen fo the "big" packages to build on a laptop. It doesn't build, it requires 64-bit atomic operations and the usual way to request these on those i386 CPUs which support it (-march=i686) didn't work when I tried it.
Driver request: cdce with 'huawei ncm' support (Huawei 3372 and similar)
Hello,
OpenBSD 6.0 amd64
Device detected as umass (before "mode switch"), umsm and ugen (after).
After some manipulations with vendors/interfaces/protocols (on OpenBSD),
device is detected as cdce0, but dhclient is failed.
Serial ports (AT command ports) are detected and works fine.
AT^NDISDUP=1,1,"internet" is OK.
Manipulations:
--- /sys/dev/usb/usbdevs.orig Tue Oct 4 23:08:41 2016
+++ /sys/dev/usb/usbdevsTue Oct 4 23:09:16 2016
@@ -2212,6 +2212,7 @@
product HUAWEI E173S 0x1c05 HUAWEI Mobile E173s
product HUAWEI E173S_INIT 0x1c0b HUAWEI Mobile E173s Initial
product HUAWEI E3030x1f01 HUAWEI Mobile E303
+product HUAWEI HWM 0x1506 HUAWEI Mobile Modems
/* HUMAX products */
product HUMAX PVRSMART 0x138c PVR-SMART
--- /sys/dev/usb/umsm.c.origTue Oct 4 23:10:47 2016
+++ /sys/dev/usb/umsm.c Tue Oct 4 23:54:20 2016
@@ -266,6 +266,8 @@
{{ USB_VENDOR_CMOTECH, USB_PRODUCT_CMOTECH_CGU628 }, DEV_UMASS1},
{{ USB_VENDOR_CMOTECH, USB_PRODUCT_CMOTECH_CGU628_DISK }, 0},
{{ USB_VENDOR_CMOTECH, USB_PRODUCT_CMOTECH_CNU680 }, DEV_UMASS1},
+
+ {{ USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_HWM }, 0},
};
#define umsm_lookup(v, p) ((const struct umsm_type
*)usb_lookup(umsm_devs, v, p))
@@ -323,6 +325,17 @@
id->bInterfaceProtocol == 0x01) ||
(id->bInterfaceSubClass == 0x00 &&
id->bInterfaceProtocol == 0x00 {
+ return UMATCH_NONE;
+ } else if ((uaa->vendor == USB_VENDOR_HUAWEI &&
+ uaa->product == USB_PRODUCT_HUAWEI_HWM) &&
+ !(id->bInterfaceClass == UICLASS_VENDOR &&
+ (id->bInterfaceSubClass == 0x02 ||
+id->bInterfaceSubClass == 0x03) &&
+ (id->bInterfaceProtocol == 0x01 ||
+id->bInterfaceProtocol == 0x05 ||
+id->bInterfaceProtocol == 0x0a ||
+id->bInterfaceProtocol == 0x10 ||
+id->bInterfaceProtocol == 0x12))) {
return UMATCH_NONE;
} else
return UMATCH_VENDOR_IFACESUBCLASS;
--- /sys/dev/usb/if_cdce.c.orig Tue Oct 4 23:47:27 2016
+++ /sys/dev/usb/if_cdce.c Wed Oct 5 00:53:44 2016
@@ -141,6 +141,16 @@
UISUBCLASS_ETHERNET_NETWORKING_CONTROL_MODEL ||
id->bInterfaceSubClass == UISUBCLASS_MOBILE_DIRECT_LINE_MODEL))
return (UMATCH_IFACECLASS_GENERIC);
+
+ if (uaa->vendor == USB_VENDOR_HUAWEI &&
+ uaa->product == USB_PRODUCT_HUAWEI_HWM &&
+ id->bInterfaceClass == UICLASS_VENDOR &&
+ (id->bInterfaceSubClass == 0x02 ||
+ id->bInterfaceSubClass == 0x03) &&
+ (id->bInterfaceProtocol == 0x16 ||
+ id->bInterfaceProtocol == 0x46 ||
+ id->bInterfaceProtocol == 0x76))
+ return (UMATCH_IFACECLASS_IFACESUBCLASS_IFACEPROTO);
return (UMATCH_NONE);
}
On FreeBSD, after manipulations like this, the device is detected as
cdce0 & ue0: on cdce0
dhclient ue0 works fine.
My research in the source code has revealed some differences in
if_cdce.c file
https://github.com/freebsd/freebsd/blob/master/sys/dev/usb/net/if_cdce.c
FreeBSD version has many lines of code grouped by CDCE_HAVE_NCM option:
#if CDCE_HAVE_NCM
static usb_callback_t cdce_ncm_bulk_write_callback;
static usb_callback_t cdce_ncm_bulk_read_callback;
#endif
and many more like this
If I got it right, in Linux the same function is performed this way:
cdc_ncm
http://lxr.free-electrons.com/source/drivers/net/usb/cdc_ncm.c?v=3.13
or this way:
huawei_cdc_ncm
http://lxr.free-electrons.com/source/drivers/net/usb/huawei_cdc_ncm.c?v=3.13
I read
http://openbsd-archive.7691.n7.nabble.com/Driver-Request-Huawei-MU609-Cellular-Modem-td269924.html
It’s seems to be the same problem here.
I know about "ppp" mode (AT+CGDCONT=1,),
device works properly by this way, but the speed (in comparison to
FreeBSD/Ubuntu AT^NDISDUP mode) decreased by ~30% and latency decreased
by ~20%.
It would be great if a nice developer could add support for this kind of
devices.
Probably, E3272, E3276 and many other Huawei devices are the same...
Regards,
Youri
dmesg before modifications:
umsm0 at uhub0 port 2 configuration 1 interface 0 "HUAWEI_MOBILE
HUAWEI_MOBILE" rev 2.10/1.02 addr 2
umsm0 detached
umass0 at uhub0 port 2 configuration 1 interface 3 "HUAWEI_MOBILE
HUAWEI_MOBILE" rev 2.10/1.02 addr 2
umass0: using SCSI over Bulk-Only
scsibus2 at umass0: 2 targets, initiator 0
cd0 at scsibus2 targ 1 lun 0: SCSI2 5/cdrom
removable
umass1 at uhub0 port 2 configuration 1 interface 4 "HUAWEI_MOBILE
HUAWEI_MOBILE" rev 2.10/1.02 addr 2
umass1: using SCSI over Bulk-Only
scsibus3 at umass1: 2 targets, initiator 0
sd2 at scsibu
starting ssh-agent on ssh login
Hi Misc, This is a rather trivial question. What is the recommended way of starting ssh-agent when upon ssh login into the remote host. Namely I have a remote host which is used as a gateway to a bunch of machines whose ssh keys are password protected. I have AddKeysToAgent yes in my ~/.ssh/config file as well as xidle -program "/usr/bin/ssh-add -D" -timeout 300 & in my .xsession file. Everything works nice and neat when I am on my desktop but I want to replicate functionality when I ssh to a headless (no X) shell gateway. Thanks, Predrag
