KERNEL_ASSERT_LOCKED with unlocked sendmsg and sendto + udp6
Hi, with the patch that unlocks sendmsg and sendto, I get the following KERNEL_ASSERT_LOCKED (transcribed from a photo of the screen) when I start avahi_daemon: panic: kernel diagnostic assertion "_kernel_lock_held()" failed: file "/usr/src/sys/net/if.c", line 1382 Stopped at db_enter+0x12: popq %r11 [PS output omitted, avahi_daemon is the active process on the CPU where the assertion hit] [I've also omitted panic() from the traceback and replaced pointer parameters with XYZ and the like] ifa_ifwithaddr(ABC,0) at ifa_ifwithaddr+0xed in6_pcbselsrc(DEF,GHI,16) at in6_pcbselsrc+0x180 udp6_output(JKL,22d1,0,0) at udp6_output+0x293 sosend(MNO,PQR,STU,107,e,VWX) at sosend+0x351 sendit(YZA,BCD,EFG,HIJ,JKL) at sendit+0x3fb sys_sendmsg(MNO,1c0,PQR) at sys_sendmsg+0x15a syscall(STU) at syscall+0x32a Xsyscall_untramp(6,0,0,0,0,1c) at Xsyscall_untramp+0xe4 end of kernel If I revert the changes to syscall.master that marked sys_sendmsg and sys_sendto as SY_NOLOCK, obviously the assertion doesn't get hit. avahi_daemon is the only program I've seen this with. Chrome and a bunch of others seem fine, including things that use the libc DNS resolver (I've configured an unbound listening on ::1 as my DNS in /etc/resolv.conf, which causes UDP traffic over IPv6 as well). I'll upload the screen photo tomorrow, but I think I've transcribed the relevant information from the stack trace that DDB showed. -- Gregor
Make uftdi(4) support aftermarket FTDI devices
Hi people, some time back, FTDI released a driver for their USB RS232 adaptors that changed the USB device ID of aftermarket devices to 0x, so that they wouldn't work on any machine, even with the older FTDI drivers, from then on ([0] has further info on that). The fix for that is relatively simple: Add USB device ID 0x to our uftdi(4). The patch below the signature does just that. I've added 0x as USB_PRODUCT_FTDI_FT232_1 and moved the previous _FT232_1 to the vacant _FT232_2 slot to preserve the device ID ordering. [0]: http://hackaday.com/2014/10/22/w/ -- Gregor -- Index: dev/usb/uftdi.c === RCS file: /mnt/media/cvs/src/sys/dev/usb/uftdi.c,v retrieving revision 1.74 diff -u -p -r1.74 uftdi.c --- dev/usb/uftdi.c 18 Jun 2015 09:47:16 - 1.74 +++ dev/usb/uftdi.c 21 Feb 2016 16:33:51 - @@ -232,6 +232,7 @@ static const struct usb_devno uftdi_devs { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FISCO }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232RL }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_1 }, + { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_2 }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_3 }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_4 }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_5 }, Index: dev/usb/usbdevs === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.662 diff -u -p -r1.662 usbdevs --- dev/usb/usbdevs 8 Jan 2016 09:31:32 - 1.662 +++ dev/usb/usbdevs 21 Feb 2016 16:19:45 - @@ -1761,7 +1761,8 @@ product FOXCONN PIRELLI_DP_L100xe003 Pi product FREECOM DVD0xfc01 Connector for DVD drive /* Future Technology Devices products */ -product FTDI FT232_1 0x0232 Serial +product FTDI FT232_1 0x Serial +product FTDI FT232_2 0x0232 Serial product FTDI SERIAL_8U232AM0x6001 8U232AM Serial product FTDI SERIAL_8U232AM4 0x6004 8U232AM Serial product FTDI FT232_3 0x6006 Serial Index: dev/usb/usbdevs.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v retrieving revision 1.674 diff -u -p -r1.674 usbdevs.h --- dev/usb/usbdevs.h 8 Jan 2016 09:31:57 - 1.674 +++ dev/usb/usbdevs.h 21 Feb 2016 16:19:59 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs.h,v 1.674 2016/01/08 09:31:57 mpi Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -1768,7 +1768,8 @@ #defineUSB_PRODUCT_FREECOM_DVD 0xfc01 /* Connector for DVD drive */ /* Future Technology Devices products */ -#defineUSB_PRODUCT_FTDI_FT232_10x0232 /* Serial */ +#defineUSB_PRODUCT_FTDI_FT232_10x /* Serial */ +#defineUSB_PRODUCT_FTDI_FT232_20x0232 /* Serial */ #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM 0x6001 /* 8U232AM Serial */ #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM40x6004 /* 8U232AM Serial */ #defineUSB_PRODUCT_FTDI_FT232_30x6006 /* Serial */ Index: dev/usb/usbdevs_data.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v retrieving revision 1.668 diff -u -p -r1.668 usbdevs_data.h --- dev/usb/usbdevs_data.h 8 Jan 2016 09:31:57 - 1.668 +++ dev/usb/usbdevs_data.h 21 Feb 2016 16:19:59 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs_data.h,v 1.668 2016/01/08 09:31:57 mpi Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -3171,6 +3171,10 @@ const struct usb_known_product usb_known }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_1, + "Serial", + }, + { + USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_2, "Serial", }, {
Re: Make uftdi(4) support aftermarket FTDI devices
On Sun, Feb 21, 2016 at 12:41:06PM -0700, Theo de Raadt wrote: > It makes no sense to renumber the FT232_1 entry. That is just creating > churn. > > As to the 0x entry, I'm wondering whether it should be named something > like the following, as a historical reminder: > > +product FTDI FT232_JERKS 0xSerial > [...] Nice idea. I've added the "bricked" device as FT232_JERKS, with a slightly longer description that hints at the reasoning behind the name: Index: dev/usb/uftdi.c === RCS file: /mnt/media/cvs/src/sys/dev/usb/uftdi.c,v retrieving revision 1.74 diff -u -p -r1.74 uftdi.c --- dev/usb/uftdi.c 18 Jun 2015 09:47:16 - 1.74 +++ dev/usb/uftdi.c 21 Feb 2016 22:10:28 - @@ -236,6 +236,7 @@ static const struct usb_devno uftdi_devs { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_4 }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_5 }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_6 }, + { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_JERKS }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT4232H }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FTX }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_GAMMASCOUT }, Index: dev/usb/usbdevs === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.662 diff -u -p -r1.662 usbdevs --- dev/usb/usbdevs 8 Jan 2016 09:31:32 - 1.662 +++ dev/usb/usbdevs 21 Feb 2016 22:12:57 - @@ -1761,6 +1761,7 @@ product FOXCONN PIRELLI_DP_L100xe003 Pi product FREECOM DVD0xfc01 Connector for DVD drive /* Future Technology Devices products */ +product FTDI FT232_JERKS 0x Serial (\"bricked\" by Windows driver) product FTDI FT232_1 0x0232 Serial product FTDI SERIAL_8U232AM0x6001 8U232AM Serial product FTDI SERIAL_8U232AM4 0x6004 8U232AM Serial Index: dev/usb/usbdevs.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v retrieving revision 1.674 diff -u -p -r1.674 usbdevs.h --- dev/usb/usbdevs.h 8 Jan 2016 09:31:57 - 1.674 +++ dev/usb/usbdevs.h 21 Feb 2016 22:13:04 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs.h,v 1.674 2016/01/08 09:31:57 mpi Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -1768,6 +1768,7 @@ #defineUSB_PRODUCT_FREECOM_DVD 0xfc01 /* Connector for DVD drive */ /* Future Technology Devices products */ +#defineUSB_PRODUCT_FTDI_FT232_JERKS0x /* Serial (\"bricked\" by Windows driver) */ #defineUSB_PRODUCT_FTDI_FT232_10x0232 /* Serial */ #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM 0x6001 /* 8U232AM Serial */ #defineUSB_PRODUCT_FTDI_SERIAL_8U232AM40x6004 /* 8U232AM Serial */ Index: dev/usb/usbdevs_data.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v retrieving revision 1.668 diff -u -p -r1.668 usbdevs_data.h --- dev/usb/usbdevs_data.h 8 Jan 2016 09:31:57 - 1.668 +++ dev/usb/usbdevs_data.h 21 Feb 2016 22:13:04 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs_data.h,v 1.668 2016/01/08 09:31:57 mpi Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -3168,6 +3168,10 @@ const struct usb_known_product usb_known { USB_VENDOR_FREECOM, USB_PRODUCT_FREECOM_DVD, "Connector for DVD drive", + }, + { + USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_JERKS, + "Serial (\"bricked\" by Windows driver)", }, { USB_VENDOR_FTDI, USB_PRODUCT_FTDI_FT232_1,
Re: Make uftdi(4) support aftermarket FTDI devices
On Sun, Feb 21, 2016 at 10:56:43PM +0200, li...@wrant.com wrote: > [...] > Others followed suit too, HL_340 bricked clones here. Not sure how to > resolve the 0x mapping uniformly. Have to invent a separate twerp > category. > [...] USB product IDs only need to be unique under the vendor ID. It's perfectly fine for vendor 0x and vendor 0x to have devices with ID 0x1234. > [...] > I can't even remember what they were using originally when they used > to work, electrically the device is fine. Just got reprogrammed to > comply with the FTDI clones in the 0x device ID. > [...] That's why simply adding the product ID is enough. Once they do that to more than one device with different drivers, things are going to become interesting, but I don't think that's going to happen after the initial backlash. -- Gregor
Document inet4/prefix in hostname.if(5)
Hi, /etc/hostname.if supports IPv4 addresses with a CIDR prefix length: inet 10.0.0.1/16 which is not documented in hostname.if(5). The attached patch fixes that. I'm not sure whether describing '/prefixlen' before 'netmask' is a good idea, but it matches the order things have to be specified in and 'netmask' is the next paragraph after '/prefixlen' -- Gregor Index: hostname.if.5 === RCS file: /mnt/media/cvs/src/share/man/man5/hostname.if.5,v retrieving revision 1.64 diff -u -p -r1.64 hostname.if.5 --- hostname.if.5 6 Jun 2015 13:13:07 - 1.64 +++ hostname.if.5 1 May 2016 17:17:22 - @@ -82,7 +82,9 @@ Regular IPv4 network setup: .Bd -ragged -offset indent .Li inet .Op Li alias -.Va addr +.Sm +.Va addr Op / Va prefixlen +.Sm .Va netmask .Va broadcast_addr .Va options @@ -117,6 +119,7 @@ inet alias 10.0.1.13 255.255.255.255 10. inet alias 10.0.1.14 255.255.255.255 NONE inet alias 10.0.1.15 255.255.255.255 inet alias 10.0.1.16 0x +inet alias 10.0.1.17/29 # This is an example comment line. inet6 alias fec0::1 64 inet6 alias fec0::2 64 anycast @@ -152,6 +155,12 @@ If no address is specified, the and .Va dest_addr options are invalid and will be ignored. +.Sm +.It / Va prefixlen +.Sm +The optional CIDR prefix length for the interface, e.g., +/29. +If both a netmask and a prefix length are specified, the netmask is used. .It Va netmask The optional network mask for the interface, e.g., 255.255.255.0.
Re: Document inet4/prefix in hostname.if(5)
On Mon, May 02, 2016 at 01:25:22PM +0100, Jason McIntyre wrote: > On Mon, May 02, 2016 at 01:27:50PM +0200, Henning Brauer wrote: > > [...] > > technically, hostname.if doesn't support ip/len notation. It is a > > notation that the hostname parser doesn't grok and just passes on to > > ifconfig. That is the modus operandi for almost everything actually > > - except the classic "inet [addr] [mask] [bcast]" notation. This > > "dual" approach, parsing by netstart vs just passing on to ifconfig, > > is the source of this slightly confusing behaviour. > > > > yep. and someone went to the trouble of trying to make that all nice > and clear, at the top of hostname.if(5). so i don;t see that anything > needs to be done, doc-fix-wise. > [...] Fair enough, I retract my patch then :) -- Gregor
Re: Patch for man to ignore trailing spaces in man.conf
Hi Mayukh, On Sun, May 22, 2016 at 11:17:18PM -0700, Mayukh Bose wrote: > [...] > Here's my patch to fix this: > [...] Ironically, your patch about whitespace handling has mangled whitespace. Can you send it again? Maybe your MUA tried sending it as some sort of formatted text instead of plain text. -- Gregor
Re: multi-pool malloc wip diff
Hi, On Mon, Aug 22, 2016 at 08:21:08AM +0200, Otto Moerbeek wrote: > [...] > New diff posted in http://www.drijf.net/openbsd/malloc. > > The intention is that this is close to commitable. But while a > straight merge of most recent diff with the current src, a bug > might have crept in. So beware etc. > [...] After applying this to a clean /usr/src/lib/libc, I get cc -O2 -pipe -g -Wall -g -Werror -Wshadow -Werror-implicit-function-declaration -Wsign-compare -I/usr/src/lib/librthread -include namespace.h -I/usr/src/lib/librthread/../libc/arch/amd64 -I/usr/src/lib/librthread/../libc/include -c rthread.c -o rthread.o cc1: warnings being treated as errors rthread.c: In function '_rthread_init': rthread.c:212: warning: assignment from incompatible pointer type rthread.c:213: warning: assignment from incompatible pointer type when building librthread. libc builds fine but stuff like firefox and chrome die with chrome(97224) in unknown error: free() called before allocation Abort trap (core dumped) and stack traces that look like this: (gdb) bt #0 0x0c27475c9aaa in thrkill () at :2 #1 0x0c27475e6589 in *_libc_abort () at /usr/src/lib/libc/stdlib/abort.c:52 #2 0x0c27475b8239 in wrterror (d=0x0, msg=0xc274773b2d8 "free() called before allocation", p=0x0) at /usr/src/lib/libc/stdlib/malloc.c:307 #3 0x0c27475b9746 in free (ptr=Variable "ptr" is not available.) at /usr/src/lib/libc/stdlib/malloc.c:1390 #4 0x0c2760446c70 in pthread_attr_destroy (attrp=0x7f7c3850) at /usr/src/lib/librthread/rthread_attr.c:64 [... other stuff omitted from here on ...] Is the diff (I chose malloc-20160822.dif) missing a librthread change? -- Gregor -- For those who like this sort of thing, this is the sort of thing they like. -- Abraham Lincoln
Re: multi-pool malloc wip diff
On Mon, Aug 22, 2016 at 05:03:34PM +0200, Otto Moerbeek wrote: > On Mon, Aug 22, 2016 at 05:00:12PM +0200, Otto Moerbeek wrote: > > > Hmm, indeed, looking into it. > > Fixed diff now online, > [...] With that one, Firefox and Chromium work fine. There's a problem with Gimp though: $ gimp gimp(51103) in free(): error: bogus pointer (double free?) 0x127da3e84400 gimp(51103) in malloc(): error: recursive call GLib (gthread-posix.c): Unexpected error from C library during 'malloc': Resource deadlock avoided. Aborting. This doesn't happen when starting Gimp for the first time, so the process to reproduce it (on my machine at least) is: - install gimp - move ~/.gimp-2.8 out of the way if it exists to make sure it's a clean start - launch gimp - (gimp works fine now) - close gimp, start it again - the above error message appears during startup while starting the extension "extension-script-fu" and gimp doesn't continue starting How can I debug this further? At first glance, I don't really see a way for malloc to be called recursively :/ -- Gregor
Re: Futexes for OpenBSD
On Fri, Sep 02, 2016 at 03:36:50PM +0200, Michal Mazurek wrote: > Here is a working futex implementation for OpenBSD. This diff touches > the kernel and librthread. > > * get rid of tickets from rthreads, they were getting in the way and are > unused anyway > * replace all struct _spinlock with int > * use futexes instead of spinlocks everywhere within librthread > * librthread no longer calls sched_yield(), nor does it spin > > Any comments? > [...] There's a tiny bit missing from the patch: Index: libc/Symbols.list === RCS file: /mnt/media/cvs/src/lib/libc/Symbols.list,v retrieving revision 1.49 diff -u -p -r1.49 Symbols.list --- libc/Symbols.list 1 Sep 2016 10:41:02 - 1.49 +++ libc/Symbols.list 3 Sep 2016 09:54:58 - @@ -272,6 +272,7 @@ fstatat fstatfs fsync ftruncate +futex futimens futimes getdents Index: libc/sys/Makefile.inc === RCS file: /mnt/media/cvs/src/lib/libc/sys/Makefile.inc,v retrieving revision 1.146 diff -u -p -r1.146 Makefile.inc --- libc/sys/Makefile.inc 4 Jul 2016 18:01:44 - 1.146 +++ libc/sys/Makefile.inc 3 Sep 2016 09:53:03 - @@ -87,6 +87,7 @@ DASM= ${ASM:.o=.do} # syscalls that CANNOT FAIL. They can return whatever value they want, # they just never want to set errno. ASM_NOERR=__get_tcb.o __set_tcb.o __threxit.o __thrsleep.o __thrwakeup.o \ + futex.o \ getdtablecount.o getegid.o geteuid.o getgid.o getlogin_r.o \ getpgrp.o getpid.o getppid.o getrtable.o getthrid.o getuid.o \ issetugid.o \ Otherwise, the calls to futex() in librthread can't be resolved. I'm currently building Firefox to see how it works out. -- Gregor -- Honesty is the best policy, but insanity is a better defense.
video(1): Use read(2) to read file specified with -i
Hi, video(1) fails to read files that were previously recorded with -o somefile, unless -g (to select read(2) as the input method) is also specified: $ video -o foo ^C $ video -i foo video: ioctl VIDIOC_REQBUFS: Bad file descriptor $ video -g -i foo [ plays the file ] mmap-mode doesn't work here because it uses a few v4l2-specific ioctls to talk to the video device. The patch below fixes that by always using read(2) when the -i option is used. -- Gregor Index: video.1 === RCS file: /mnt/media/cvs/xenocara/app/video/video.1,v retrieving revision 1.13 diff -u -p -r1.13 video.1 --- video.1 4 Jun 2016 07:44:32 - 1.13 +++ video.1 14 Sep 2016 19:47:52 - @@ -113,6 +113,10 @@ If is .Ql - , frames will be read from standard input. +This will use +.Xr read 2 +to grab frames instead of +.Xr mmap 2 . .It Fl O Ar output File to which frames will be written. If Index: video.c === RCS file: /mnt/media/cvs/xenocara/app/video/video.c,v retrieving revision 1.19 diff -u -p -r1.19 video.c --- video.c 6 Jun 2016 19:31:22 - 1.19 +++ video.c 14 Sep 2016 19:46:39 - @@ -1805,6 +1805,7 @@ main(int argc, char *argv[]) err++; } else { vid.mode = (vid.mode & ~M_IN_DEV) | M_IN_FILE; + vid.mmap_on = 0; /* mmap mode does not work for files */ snprintf(vid.iofile, sizeof(vid.iofile), optarg); }
Re: video(1): Use read(2) to read file specified with -i
On Thu, Sep 15, 2016 at 02:57:16PM +0200, Jeremie Courreges-Anglas wrote: > [...] > I think this is the right way to work around the problem and make > video(1) more user-friendly. However, I doubt that the manpage bits are > relevant. So I'd like to commit only the .c diff. > > Thoughts? > [...] Fine with me. On second thought, adding the manpage bits was overkill. -- Gregor
video(1): Don't limit maximum frame size to display size
Hi, this is another patch to video(1). It removes the logic that forces the video grab frame size to be <= the size of the Xv adaptor. This allows me to grab and view frames that are 1280x1024 on my 1440x900 screen. Xv properly scales and stretches the window content, so there's nothing that gets cut off from the video feed. The camera I have here has the following resolutions: 160x120: 30 176x144: 30 320x240: 30 352x288: 30 640x480: 30 1280x1024: 9 Without this patch, the maximum resolution I can grab and view at the same time is 640x480, which is a bit too tiny. I haven't noticed any downsides of the patch, but I've only tested it with my laptop and not other graphics cards, so I'm not sure how Xv handles frames larger than the display size there. -- Gregor Index: video.c === RCS file: /mnt/media/cvs/xenocara/app/video/video.c,v retrieving revision 1.19 diff -u -p -r1.19 video.c --- video.c 6 Jun 2016 19:31:22 - 1.19 +++ video.c 18 Sep 2016 14:00:06 - @@ -1162,13 +1162,6 @@ choose_size(struct video *vid) else if (vid->width && !vid->height) vid->height = vid->width * 3 / 4; - if (vid->mode & M_OUT_XV) { - if (vid->width > x->max_width) - vid->width = x->max_width; - if (vid->height > x->max_height) - vid->height = x->max_height; - } - if (vid->mode & M_IN_DEV) { i = 0; while (i < d->nsizes &&
Re: video(1): Don't limit maximum frame size to display size
Hi, > [...] > This seems to work fine with inteldrm, a 1280x800 display and > [...] Good to hear I didn't break anything :) > [...] > No idea either... if you wanted to reduce the risk of breakage, I > guess you could limit the resolution only if -O is not passed. > [...] I've read up on Xv a bit and I think it's okay to just give it larger images, so this kind of precaution doesn't seem necessary. -- Gregor
Quirks for pkcbc?
Hi people, the patch below the signature makes the touchpad on my new laptop work. pms(4) didnt' attach previously because the AUX slot on the keyboard was not enabled. Since the patch isn't a proper solution, I was wondering whether there's a quirks mechanism for pckbc, similar to what e.g. some of the USB HID drivers do for things like joysticks with weird button mappings. -- Gregor Index: dev/ic/pckbc.c === RCS file: /mnt/media/cvs/src/sys/dev/ic/pckbc.c,v retrieving revision 1.49 diff -u -p -r1.49 pckbc.c --- dev/ic/pckbc.c 24 May 2015 10:57:47 - 1.49 +++ dev/ic/pckbc.c 23 Oct 2016 21:19:56 - @@ -378,6 +378,8 @@ pckbc_attach(struct pckbc_softc *sc, int bus_space_write_1(iot, ioh_d, 0, 0x5a); /* a random value */ res = pckbc_poll_data1(iot, ioh_d, ioh_c, PCKBC_AUX_SLOT, 1); + t->t_flags |= PCKBC_NEED_AUXWRITE; + if (ISSET(t->t_flags, PCKBC_NEED_AUXWRITE)) { /* * The following code is necessary to find the aux port on the
Re: Quirks for pkcbc?
On Sun, Oct 23, 2016 at 03:42:59PM -0600, Theo de Raadt wrote: > [...] > I ask you to figure out logical conditions under which this should > happen, or if some interaction is wrong. > [...] Understood. I'll try tracking down the exact circumstances of the issue and come back with a better diff. -- Gregor signature.asc Description: PGP signature
Re: The end of nd6_output()
Hi, On Mon, Jun 06, 2016 at 07:16:20PM +0200, Martin Pieuchot wrote: > [...] > + if (rt->rt_gateway->sa_family != AF_LINK) { > + printf("%s: something odd happens\n", __func__); > + m_freem(m); > + return (EINVAL); > + } > [...] I noticed that since a week or two ago, this printfs gets triggered on my laptops and relatively quickly floods my dmesg. One is running a snapshot from two weeks ago, the other one runs a snapshot from about a month ago. On both, I have IPv6 routes that look like this: Routing tables Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultfe80::203:2dff:fe20:cf85%trunk0 UG 0 22 -56 trunk0 ::/96 ::1UGRS 0 0 32768 8 lo0 ::/104 ::1UGRS 0 0 32768 8 lo0 ::1::1UHhl 14 9118 32768 1 lo0 ::127.0.0.0/104::1UGRS 0 0 32768 8 lo0 ::224.0.0.0/100::1UGRS 0 0 32768 8 lo0 ::255.0.0.0/104::1UGRS 0 0 32768 8 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2001:470:7193:10::/64 2001:470:7193:10:82fa:5bff:fe33:76b3 UCn 2 19 - 4 trunk0 2001:470:7193:10::100:03:2d:20:cf:85 UHLc 0 7682 - 4 trunk0 2001:470:7193:10:187d:de60:2580:663b link#7 UHLc 0 19 - 4 trunk0 2001:470:7193:10:82fa:5bff:fe33:76b3 80:fa:5b:33:76:b3 UHLl 0 819 - 1 trunk0 2001:470:7193:10:f093:17b2:7503:d4cf 80:fa:5b:33:76:b3 UHLl 0 133 - 1 trunk0 2001:470:74bb::/64 2001:470:74bb::1 UCn0 0 - 4 tap0 2001:470:74bb::1 fe:e1:ba:d0:35:0a UHLl 0 0 - 1 tap0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 fd97:1c82:9447::/64fd97:1c82:9447::1 UCn1 0 - 4 tap0 fd97:1c82:9447:: fd97:1c82:9447:: UHLc 0 7408 - 4 tap0 fd97:1c82:9447::1 fe:e1:ba:d0:35:0a UHLl 0 4 - 1 tap0 fe80::/10 ::1UGRS 0 2 32768 8 lo0 fec0::/10 ::1UGRS 0 0 32768 8 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 fe80::%tap0/64 fe80::fce1:baff:fed0:350a%tap0 UCn0 0 - 4 tap0 fe80::fce1:baff:fed0:350a%tap0 fe:e1:ba:d0:35:0a UHLl 0 0 - 1 tap0 fe80::%trunk0/64 fe80::82fa:5bff:fe33:76b3%trunk0 UCn 13 - 4 trunk0 fe80::203:2dff:fe20:cf85%trunk000:03:2d:20:cf:85 UHLch 1 436623 - 4 trunk0 fe80::82fa:5bff:fe33:76b3%trunk0 80:fa:5b:33:76:b3 UHLl 0 130445 - 1 trunk0 ff01::/16 ::1UGRS 2 4 32768 8 lo0 ff01::%lo0/32 ::1Um 0 1 32768 4 lo0 ff01::%tap0/32 fe80::fce1:baff:fed0:350a%tap0 Um 0 2 - 4 tap0 ff01::%trunk0/32 fe80::82fa:5bff:fe33:76b3%trunk0 Um 08 - 4 trunk0 ff02::/16 ::1UGRS 2 4 32768 8 lo0 ff02::%lo0/32 ::1Um 0 1 32768 4 lo0 ff02::%tap0/32 fe80::fce1:baff:fed0:350a%tap0 Um 0 2 - 4 tap0 ff02::%trunk0/32 fe80::82fa:5bff:fe33:76b3%trunk0 Um 19 - 4 trunk0 tap0 is managed and configured by a tinc daemon. I do have a BGP daemon running on both laptops that adds routes that go over tap0, but at the moment the only active sessions are IPv4. How can I go about finding out what
Re: The end of nd6_output()
Hi Martin, On Fri, Nov 04, 2016 at 11:44:14AM +0100, Martin Pieuchot wrote: > > That's the problem. The entry is flagged as RTF_LLINFO but contains an > IPv6 address. > > Do you see any other errors in /log/messages? > Only nd6_rtrequest: bad gateway value: tap0 immediately before the printf gets triggered. I tried reproducing the problem in a cleaner environment, since the one I'm seeing this in is a bit convoluted. tap0 is usually managed by tinc. Immediately after starting it, everything looks fine: $ route -n show -inet6 | grep tap0 2001:470:74bb::/64 2001:470:74bb::1 UCn 0 0 - 4 tap0 2001:470:74bb::1 fe:e1:ba:d4:0f:e3 UHLl 0 0 - 1 tap0 fd97:1c82:9447::/64fd97:1c82:9447::1 UCn 0 0 - 4 tap0 fd97:1c82:9447::1 fe:e1:ba:d4:0f:e3 UHLl 0 0 - 1 tap0 fe80::%tap0/64 fe80::fce1:baff:fed4:fe3%tap0 UCn 0 0 - 4 tap0 fe80::fce1:baff:fed4:fe3%tap0 fe:e1:ba:d4:0f:e3 UHLl 0 0 - 1 tap0 ff01::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 02 - 4 tap0 ff02::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 02 - 4 tap0 $ ifconfig tap0 tap0: flags=8843 mtu 1500 lladdr fe:e1:ba:d4:0f:e3 index 14 priority 15 llprio 3 groups: tap tinc unobtanium status: active inet 172.22.127.2 netmask 0xff00 broadcast 172.22.127.255 inet6 fe80::fce1:baff:fed4:fe3%tap0 prefixlen 64 scopeid 0xe inet6 2001:470:74bb::1 prefixlen 64 deprecated pltime 0 vltime infty inet6 fd97:1c82:9447::1 prefixlen 64 deprecated pltime 0 vltime infty Pinging across the tunnel (the other side has fd97:1c82:9447:: as one of its addresses on the tunnel) doesn't work: $ ping6 -n -c1 fd97:1c82:9447:: PING fd97:1c82:9447:: (fd97:1c82:9447::): 56 data bytes --- fd97:1c82:9447:: ping statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss and causes the 'bad gateway value' message to appear, followed by a few 'something odd happens'. Now the routing table looks like this: $ route -n show -inet6 | grep tap0 2001:470:74bb::/64 2001:470:74bb::1 UCn0 0 - 4 tap0 2001:470:74bb::1 fe:e1:ba:d4:0f:e3 UHLl 0 0 - 1 tap0 fd97:1c82:9447::/64fd97:1c82:9447::1 UCn1 0 - 4 tap0 fd97:1c82:9447:: fe:e1:ba:d0:26:57 UHLc 1 2 - 4 tap0 ^ fd97:1c82:9447::1 fe:e1:ba:d4:0f:e3 UHLl 0 0 - 1 tap0 fe80::%tap0/64 fe80::fce1:baff:fed4:fe3%tap0 UCn1 3 - 4 tap0 fe80::fce1:baff:fed0:2657%tap0 fe:e1:ba:d0:26:57 UHLc 0 10 - 4 tap0 fe80::fce1:baff:fed4:fe3%tap0 fe:e1:ba:d4:0f:e3 UHLl 0 3 - 1 tap0 ff01::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 0 2 - 4 tap0 ff02::%tap0/32 fe80::fce1:baff:fed4:fe3%tap0 Um 0 3 - 4 tap0 This is what shows up on tap0 when I do the ping6: $ doas tcpdump -ni tap0 ip6 tcpdump: listening on tap0, link-type EN10MB 19:23:45.315411 fe80::fce1:baff:fed9:9d3f > ff02::1:ff00:0: icmp6: neighbor sol: who has fd97:1c82:9447:: 19:23:45.373281 fe80::fce1:baff:fed0:2657 > fe80::fce1:baff:fed9:9d3f: icmp6: neighbor adv: tgt is fd97:1c82:9447:: 19:23:45.373477 fd00::82fa:5bff:fe33:76b3 > fd97:1c82:9447::: icmp6: echo request I can't reproduce the problem when I configure a tap device similar to how tinc does it and use `cat /dev/tap0 >/dev/null` to keep the device open, which leads me to assume that the neighbour advertisement received from fe80::fce1:baff:fed9:9d3f leads to this weird new route. If I can do anything else to be of assistance, please let me know. -- Gregor
Re: The end of nd6_output()
Hi, On Mon, Nov 07, 2016 at 09:12:12AM +0100, Martin Pieuchot wrote: > [...] > Could you capture the route changes via "# route monitor"? I'd like > to know if the 'bad gateway value' message is triggered by userland > or the kernel. > [...] I can't reproduce the problem anymore. If it does turn up again, I'll collect the output of route monitor. In the mean time, thanks a bunch for your help :) -- Gregor
Re: The end of nd6_output()
Hi, On Mon, Nov 07, 2016 at 03:55:29PM +0100, Gregor Best wrote: > [...] > I can't reproduce the problem anymore. If it does turn up again, I'll > collect the output of route monitor. In the mean time, thanks a bunch > for your help :) > [...] It happened again, this time in a slightly more convoluted scenario with bgpd adding and removing routes. I grabbed the output of route monitor from the time the tap0 interface was started, so it's quite big :( I've uploaded two versions, one with IPv4-addresses removed [0], one with the addresses still in, in case I messed something up [1]. The routing table looks like this (routes added by bgpd disappeared because the session died after the broken route was added): $ route -n show -inet6 Routing tables Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface defaultfe80::2a0:57ff:fe24:807d%trunk0 UG 1 46 -56 trunk0 ::/96 ::1UGRS 0 0 32768 8 lo0 ::/104 ::1UGRS 0 0 32768 8 lo0 ::1::1UHhl 14 568 32768 1 lo0 ::127.0.0.0/104::1UGRS 0 0 32768 8 lo0 ::224.0.0.0/100::1UGRS 0 0 32768 8 lo0 ::255.0.0.0/104::1UGRS 0 0 32768 8 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2001:470:74bb::/64 2001:470:74bb::1 UCn0 0 - 4 tap0 2001:470:74bb::1 fe:e1:ba:d0:a8:dd UHLl 0 0 - 1 tap0 2001:4dd0:af15:7478::/64 2001:4dd0:af15:7478:82fa:5bff:fe33:76b3 UCn 00 - 4 trunk0 2001:4dd0:af15:7478:82fa:5bff:fe33:76b3 80:fa:5b:33:76:b3 UHLl 00 - 1 trunk0 2001:4dd0:af15:7478:dc02:682d:13cf:94ec 80:fa:5b:33:76:b3 UHLl 0 33 - 1 trunk0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 fd97:1c82:9447::/64fd97:1c82:9447::1 UCn1 2 - 4 tap0 fd97:1c82:9447:: fd97:1c82:9447:: UHLc 0 890 - 4 tap0 fd97:1c82:9447::1 fe:e1:ba:d0:a8:dd UHLl 0 15 - 1 tap0 fe80::/10 ::1UGRS 0 2 32768 8 lo0 fec0::/10 ::1UGRS 0 0 32768 8 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 fe80::%tap0/64 fe80::fce1:baff:fed0:a8dd%tap0 UCn0 0 - 4 tap0 fe80::fce1:baff:fed0:a8dd%tap0 fe:e1:ba:d0:a8:dd UHLl 0 0 - 1 tap0 fe80::%trunk0/64 fe80::82fa:5bff:fe33:76b3%trunk0 UCn 12 - 4 trunk0 fe80::2a0:57ff:fe24:807d%trunk000:a0:57:24:80:7d UHLch 1 328 - 4 trunk0 fe80::82fa:5bff:fe33:76b3%trunk0 80:fa:5b:33:76:b3 UHLl 0 51 - 1 trunk0 ff01::/16 ::1UGRS 2 4 32768 8 lo0 ff01::%lo0/32 ::1Um 0 1 32768 4 lo0 ff01::%tap0/32 fe80::fce1:baff:fed0:a8dd%tap0 Um 0 2 - 4 tap0 ff01::%trunk0/32 fe80::82fa:5bff:fe33:76b3%trunk0 Um 02 - 4 trunk0 ff02::/16 ::1UGRS 2 4 32768 8 lo0 ff02::%lo0/32 ::1Um 0 1 32768 4 lo0 ff02::%tap0/32 fe80::fce1:baff:fed0:a8dd%tap0 Um 0 2 - 4 tap0 ff02::%trunk0/32 fe80::82fa:5bff:fe33:76b3%trunk0 Um 13 - 4 trunk0 As before, if you need any more info or pcaps or anything, I'd be more than happy to assist. [0]: http://unobtanium.de/static/rtmsg-v6only.txt [1]: http://unobtanium.de/static/rtmsg-complete.txt -- Gregor signature.asc Description: PGP signature
Re: handle non-standard 11n APs better
On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote: > [...] > E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800 > > The diff below makes OpenBSD clients work in 11n mode on such networks > by relaxing our "supported MCS" 11n feature check. > [...] To go along with the 33c3 motto: "Works for me". Thanks a lot :) -- Gregor
Re: handle non-standard 11n APs better
On Tue, Dec 27, 2016 at 01:00:54AM +0100, Gregor Best wrote: > On Mon, Dec 26, 2016 at 08:44:47PM +0100, Stefan Sperling wrote: > > [...] > > E.g. at 33C3 there are APs with: RxMCS 0xf8f8f800 > > > > The diff below makes OpenBSD clients work in 11n mode on such networks > > by relaxing our "supported MCS" 11n feature check. > > [...] > > To go along with the 33c3 motto: "Works for me". Thanks a lot :) > [...] Looks like I spoke a bit too soon. The card associates and can receive IPv6 router advertisements, but that seems to be it. I don't receive replies to DHCP requests and statically configuring an address doesn't yield a working connection either. A PCAP file I captured with tcpdump -y IEEE802_11 -ni iwm0 -w /tmp/nw.pcap is at [0]. The output of ifconfig and a dmesg follows. The kernel is one built from a CVS checkout from 0100 this morning. Is this related to an AP with weird 11n handling at all? -- Gregor $ ifconfig iwm0 iwm0: flags=208843 mtu 1500 lladdr e4:a4:71:e1:45:79 index 2 priority 4 llprio 3 groups: wlan media: IEEE802.11 autoselect (OFDM18 mode 11a) status: active ieee80211: nwid 33C3-open chan 48 bssid 04:bd:88:62:96:91 65% inet6 fe80::e6a4:71ff:fee1:4579%iwm0 prefixlen 64 scopeid 0x2 inet6 2001:67c:20a1:1192:e6a4:71ff:fee1:4579 prefixlen 64 autoconf pltime 0 vltime 3600 inet6 2001:67c:20a1:1192:8831:5f1e:f152:8cf3 prefixlen 64 deprecated autoconf autoconfprivacy pltime 0 vltime 3161 inet6 2001:67c:20a1:1192:2c51:2f3:5efe:5361 prefixlen 64 autoconf autoconfprivacy pltime 0 vltime 3464 $ dmesg OpenBSD 6.0-current (GENERIC.MP) #54: Tue Dec 27 00:55:34 CET 2016 g...@sputnik.unobtanium.de:/usr/obj/sys/arch/amd64/compile/GENERIC.MP real mem = 17078013952 (16286MB) avail mem = 16554639360 (15787MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x87ed7000 (44 entries) bios0: vendor American Megatrends Inc. version "5.11" date 08/29/2016 bios0: Notebook N24_25JU acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT DBGP DBG2 SSDT UEFI SSDT BGRT DMAR TPM2 ASF! acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP17(S4) PXSX(S4) RP18(S4) PXSX(S4) RP19(S4) PXSX(S4) RP20(S4) PXSX(S4) RP01(S4) [...] 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) Core(TM) i5-6200U CPU @ 2.30GHz, 2694.51 MHz 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT 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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2693.75 MHz cpu3: 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,AD
Re: important audio simplifications to test and review
On Thu, Jun 11, 2015 at 09:20:54AM +0200, Alexandre Ratchov wrote: > [...] > To test this diff, simply run your regular audio stuff and let us > know if you notice any difference. I'd suggest to keep a copy of > the old kernel in order to be able to compare easily. > [...] I've been listening to music all day and am currently watching a movie with this, no regressions so far. This is with $ dmesg | grep -E '(audio|azalia)' azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi azalia0: codecs: Conexant CX20561 audio0 at azalia0 -- Gregor Best -- Opinions are like assholes -- everyone's got one, but nobody wants to look at the other guy's. -- Hal Hickman
Fix for segfault in find(1)
Hi people, there's a tiny bug in find that causes a segmentation fault in find. The following C program can be used to replicate a pathological directory structure: #include #include #include int main(void) { char s[256]; int i; memset(s, 'x', sizeof s); s[255] = 0; for (i = 0; i < 200; i++) { mkdir(s, 0777); chdir(s); } return 0; } Calling find /path/to/structure -exec true '{}' ';' on the directory structure created by the program causes a segmentation fault in brace_subst(). The following patch fixes that by using the return value of realloc() instead of stashing it away and continuing with the old value. -- Gregor Index: misc.c === RCS file: /mnt/media/cvs/src/usr.bin/find/misc.c,v retrieving revision 1.12 diff -u -p -u -r1.12 misc.c --- misc.c 18 May 2014 08:10:00 - 1.12 +++ misc.c 14 Jul 2015 15:41:20 - @@ -66,6 +66,7 @@ brace_subst(char *orig, char **store, ch if (!(newstore = realloc(*store, newlen))) err(1, NULL); *store = newstore; + p = newstore; len = newlen; } memmove(p, path, plen);
Re: Fix for segfault in find(1)
On Tue, Jul 14, 2015 at 09:57:45AM -0600, Todd C. Miller wrote: > [...] > Shouldn't this be: > > p = (p - *store) + newstore; > [...] Of course, that makes way more sense. An amended patch is attached. -- Gregor Index: misc.c === RCS file: /mnt/media/cvs/src/usr.bin/find/misc.c,v retrieving revision 1.12 diff -u -p -u -r1.12 misc.c --- misc.c 18 May 2014 08:10:00 - 1.12 +++ misc.c 14 Jul 2015 16:07:28 - @@ -65,6 +65,7 @@ brace_subst(char *orig, char **store, ch if (!(newstore = realloc(*store, newlen))) err(1, NULL); + p = (p - *store) + newstore; *store = newstore; len = newlen; }
[patch] update unbound forwards with dhclient nameservers
Hello, the following is a patch that adds an option called `update_unbound' to dhclient.conf. With this option enabled, dhclient will call unbound-control forwards instead of rewriting /etc/resolv.conf. My usage scenario is that I'm running unbound on my laptop as a local resolver. /etc/resolv.conf is configured to only use 127.0.0.1 as the nameserver. I use this because I have a few VPN connections that have custom DNS namespaces, which I manage with Unbound's forward zones. Since sometimes I am in networks that have a split horizon DNS (e.g. University, hackerspace, etc...), I can't use a statically configured fallback forward zone for all my requests. Manually calling using unbound-control to change the forward DNS became too annoying, so I wrote this patch. Does the patch make sense in OpenBSD or should I keep it as a local change? -- Gregor Best -- Index: clparse.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v retrieving revision 1.92 diff -u -p -r1.92 clparse.c --- clparse.c 18 May 2015 17:51:21 - 1.92 +++ clparse.c 9 Jul 2015 15:00:05 - @@ -75,6 +75,7 @@ read_client_conf(void) config->backoff_cutoff = 15; config->initial_interval = 3; config->bootp_policy = ACCEPT; + config->update_unbound = 0; config->requested_options [config->requested_option_count++] = DHO_SUBNET_MASK; config->requested_options @@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile) case TOK_NEXT_SERVER: if (parse_ip_addr(cfile, &config->next_server)) parse_semi(cfile); + break; + case TOK_UPDATE_UNBOUND: + config->update_unbound = 1; + parse_semi(cfile); break; default: parse_warn("expecting a statement."); Index: conflex.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v retrieving revision 1.32 diff -u -p -r1.32 conflex.c --- conflex.c 18 May 2015 17:51:21 - 1.32 +++ conflex.c 9 Jul 2015 14:54:56 - @@ -341,7 +341,8 @@ static const struct keywords { { "send", TOK_SEND }, { "server-name",TOK_SERVER_NAME }, { "supersede", TOK_SUPERSEDE }, - { "timeout",TOK_TIMEOUT } + { "timeout",TOK_TIMEOUT }, + { "update_unbound", TOK_UPDATE_UNBOUND } }; intkw_cmp(const void *k, const void *e); Index: dhclient.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v retrieving revision 1.361 diff -u -p -r1.361 dhclient.c --- dhclient.c 18 May 2015 14:59:42 - 1.361 +++ dhclient.c 9 Jul 2015 15:52:41 - @@ -97,6 +97,7 @@ intres_hnok(const char *dn); voidfork_privchld(int, int); voidget_ifname(char *); +voidupdate_unbound_forwards(struct option_data *); char *resolv_conf_contents(struct option_data *, struct option_data *); voidwrite_resolv_conf(u_int8_t *, size_t); @@ -903,8 +904,12 @@ bind_lease(void) goto newlease; } - client->new->resolv_conf = resolv_conf_contents( - &options[DHO_DOMAIN_NAME], &options[DHO_DOMAIN_NAME_SERVERS]); + if (config->update_unbound) { + update_unbound_forwards(&options[DHO_DOMAIN_NAME_SERVERS]); + } else { + client->new->resolv_conf = resolv_conf_contents( + &options[DHO_DOMAIN_NAME], &options[DHO_DOMAIN_NAME_SERVERS]); + } /* Replace the old active lease with the new one. */ client->active = client->new; @@ -2042,6 +2047,88 @@ get_ifname(char *arg) close(s); } else if (strlcpy(ifi->name, arg, IFNAMSIZ) >= IFNAMSIZ) error("Interface name too long"); +} + +/* + * Update unbound forwarder list + */ +void +update_unbound_forwards(struct option_data *nameservers) +{ + char *ns; + int rslt; + + if (!nameservers->len) { + return; + } + + ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0); + + rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS, + 0, 0, -1, ns, strlen(ns) + 1); + + if (rslt == -1) { + warning("update_unbound_forwards: imsg_compose: %s", + strerror(errno)); + } + + flush_unpriv_ibuf("update_unbound_forwards"); +} + +void +priv_upda
Re: [patch] update unbound forwards with dhclient nameservers
On Sun, Jul 19, 2015 at 03:31:33PM +, Florian Obser wrote: > [...] > Oh god, yes please. I always wanted to write this diff myself ;) > More comments in the diff below. > [...] Great to read. I've attached an updated patch. -- Gregor Best Index: clparse.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v retrieving revision 1.92 diff -u -p -r1.92 clparse.c --- clparse.c 18 May 2015 17:51:21 - 1.92 +++ clparse.c 9 Jul 2015 15:00:05 - @@ -75,6 +75,7 @@ read_client_conf(void) config->backoff_cutoff = 15; config->initial_interval = 3; config->bootp_policy = ACCEPT; + config->update_unbound = 0; config->requested_options [config->requested_option_count++] = DHO_SUBNET_MASK; config->requested_options @@ -269,6 +270,10 @@ parse_client_statement(FILE *cfile) case TOK_NEXT_SERVER: if (parse_ip_addr(cfile, &config->next_server)) parse_semi(cfile); + break; + case TOK_UPDATE_UNBOUND: + config->update_unbound = 1; + parse_semi(cfile); break; default: parse_warn("expecting a statement."); Index: conflex.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v retrieving revision 1.32 diff -u -p -r1.32 conflex.c --- conflex.c 18 May 2015 17:51:21 - 1.32 +++ conflex.c 19 Jul 2015 17:31:13 - @@ -341,7 +341,8 @@ static const struct keywords { { "send", TOK_SEND }, { "server-name",TOK_SERVER_NAME }, { "supersede", TOK_SUPERSEDE }, - { "timeout",TOK_TIMEOUT } + { "timeout",TOK_TIMEOUT }, + { "update-unbound", TOK_UPDATE_UNBOUND } }; intkw_cmp(const void *k, const void *e); Index: dhclient.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v retrieving revision 1.361 diff -u -p -r1.361 dhclient.c --- dhclient.c 18 May 2015 14:59:42 - 1.361 +++ dhclient.c 19 Jul 2015 17:48:11 - @@ -97,6 +97,7 @@ intres_hnok(const char *dn); voidfork_privchld(int, int); voidget_ifname(char *); +voidupdate_unbound_forwards(struct option_data *); char *resolv_conf_contents(struct option_data *, struct option_data *); voidwrite_resolv_conf(u_int8_t *, size_t); @@ -903,8 +904,12 @@ bind_lease(void) goto newlease; } - client->new->resolv_conf = resolv_conf_contents( - &options[DHO_DOMAIN_NAME], &options[DHO_DOMAIN_NAME_SERVERS]); + if (config->update_unbound) { + update_unbound_forwards(&options[DHO_DOMAIN_NAME_SERVERS]); + } else { + client->new->resolv_conf = resolv_conf_contents( + &options[DHO_DOMAIN_NAME], &options[DHO_DOMAIN_NAME_SERVERS]); + } /* Replace the old active lease with the new one. */ client->active = client->new; @@ -2042,6 +2047,89 @@ get_ifname(char *arg) close(s); } else if (strlcpy(ifi->name, arg, IFNAMSIZ) >= IFNAMSIZ) error("Interface name too long"); +} + +/* + * Update unbound forwarder list + */ +void +update_unbound_forwards(struct option_data *nameservers) +{ + char *ns; + int rslt; + + if (!nameservers->len) { + return; + } + + ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0); + + rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS, + 0, 0, -1, ns, strlen(ns) + 1); + + if (rslt == -1) { + warning("update_unbound_forwards: imsg_compose: %s", + strerror(errno)); + } + + flush_unpriv_ibuf("update_unbound_forwards"); +} + +void +priv_update_unbound_forwards(struct imsg *imsg) +{ + char *args[MAXNS + 3]; /* `unbound-control', `forward', final NULL */ + char *ns, *p, **srv; + int rslt, i = 0; + size_t sz; + pid_t child; + + if (imsg->hdr.len < IMSG_HEADER_SIZE) { + warning("short IMSG_UPDATE_UNBOUND_FORWARDS"); + return; + } + + ns = imsg->data; + sz = imsg->hdr.len - IMSG_HEADER_SIZE; + ns[sz] = '\0'; /* Make sure we're terminated properly */ + + /* Construct unbound-control arguments */ + memset(args, 0, sizeof(args)); +
Re: [patch] update unbound forwards with dhclient nameservers
On Sun, Jul 19, 2015 at 07:03:59PM +0100, Stuart Henderson wrote: > [...] > I'm uncertain about whether dhclient should do this at all, it seems > to be the opposite of the direction dhclient has been going in > recently, > [...] I've had a similar intuition at first, but it's one less thing to run versus the "monitor lease file" approach and it only calls one static external command with relatively fixed parameters instead of what the removed `script' option did. In the end, it's a matter of personal taste, I think. > [...] > but if it is added, it probably wants to be disabled for the ramdisk. > [...] I've attached an updated patch, in case this is still interesting to someone. Do I need to add anything other than `#ifdef SMALL' in the appropriate places? -- Gregor Best -- Index: clparse.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/clparse.c,v retrieving revision 1.92 diff -u -p -r1.92 clparse.c --- clparse.c 18 May 2015 17:51:21 - 1.92 +++ clparse.c 19 Jul 2015 18:44:12 - @@ -75,6 +75,9 @@ read_client_conf(void) config->backoff_cutoff = 15; config->initial_interval = 3; config->bootp_policy = ACCEPT; +#ifndef SMALL + config->update_unbound = 0; +#endif config->requested_options [config->requested_option_count++] = DHO_SUBNET_MASK; config->requested_options @@ -270,6 +273,12 @@ parse_client_statement(FILE *cfile) if (parse_ip_addr(cfile, &config->next_server)) parse_semi(cfile); break; +#ifndef SMALL + case TOK_UPDATE_UNBOUND: + config->update_unbound = 1; + parse_semi(cfile); + break; +#endif default: parse_warn("expecting a statement."); if (token != ';') Index: conflex.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/conflex.c,v retrieving revision 1.32 diff -u -p -r1.32 conflex.c --- conflex.c 18 May 2015 17:51:21 - 1.32 +++ conflex.c 19 Jul 2015 18:48:00 - @@ -341,7 +341,10 @@ static const struct keywords { { "send", TOK_SEND }, { "server-name",TOK_SERVER_NAME }, { "supersede", TOK_SUPERSEDE }, - { "timeout",TOK_TIMEOUT } + { "timeout",TOK_TIMEOUT }, +#ifndef SMALL + { "update-unbound", TOK_UPDATE_UNBOUND } +#endif }; intkw_cmp(const void *k, const void *e); Index: dhclient.c === RCS file: /mnt/media/cvs/src/sbin/dhclient/dhclient.c,v retrieving revision 1.361 diff -u -p -r1.361 dhclient.c --- dhclient.c 18 May 2015 14:59:42 - 1.361 +++ dhclient.c 19 Jul 2015 18:45:28 - @@ -97,6 +97,9 @@ intres_hnok(const char *dn); voidfork_privchld(int, int); voidget_ifname(char *); +#ifndef SMALL +voidupdate_unbound_forwards(struct option_data *); +#endif char *resolv_conf_contents(struct option_data *, struct option_data *); voidwrite_resolv_conf(u_int8_t *, size_t); @@ -903,8 +906,15 @@ bind_lease(void) goto newlease; } - client->new->resolv_conf = resolv_conf_contents( - &options[DHO_DOMAIN_NAME], &options[DHO_DOMAIN_NAME_SERVERS]); +#ifndef SMALL + if (config->update_unbound) { + update_unbound_forwards(&options[DHO_DOMAIN_NAME_SERVERS]); + } else +#endif + { + client->new->resolv_conf = resolv_conf_contents( + &options[DHO_DOMAIN_NAME], &options[DHO_DOMAIN_NAME_SERVERS]); + } /* Replace the old active lease with the new one. */ client->active = client->new; @@ -2043,6 +2053,91 @@ get_ifname(char *arg) } else if (strlcpy(ifi->name, arg, IFNAMSIZ) >= IFNAMSIZ) error("Interface name too long"); } + +#ifndef SMALL +/* + * Update unbound forwarder list + */ +void +update_unbound_forwards(struct option_data *nameservers) +{ + char *ns; + int rslt; + + if (!nameservers->len) { + return; + } + + ns = pretty_print_option(DHO_DOMAIN_NAME_SERVERS, nameservers, 0); + + rslt = imsg_compose(unpriv_ibuf, IMSG_UPDATE_UNBOUND_FORWARDS, + 0, 0, -1, ns, strlen(ns) + 1); + + if (rslt == -1) { + warning("update_unbound_forwards: imsg_compose: %s", + strerror(errno)); + }
Re: doas authentication type
On Wed, Aug 26, 2015 at 08:42:31AM +0200, Renaud Allard wrote: > [...] > + fprintf(stderr, "usage: doas [-ans] [-C config] [-u user] command > [args]\n"); > [...] The usage string should probably be "usage: doas [-ns] [-a style] [-C config] [-u user] command [args]" and the new option should appear in doas(1). -- Gregor
[patch] fdisk: show value range for partition offset/size
Hi people, the following patch changes the prompt for the 'Partition size' and 'Partition offset' prompts in fdisk to show the range of allowed values and display the raw value as well when showing an error for out of bounds values. Index: misc.c === RCS file: /mnt/media/cvs/src/sbin/fdisk/misc.c,v retrieving revision 1.52 diff -u -p -u -r1.52 misc.c --- misc.c 27 Aug 2015 20:58:27 - 1.52 +++ misc.c 5 Sep 2015 14:22:13 - @@ -213,7 +213,7 @@ getuint64(char *prompt, u_int64_t oval, secpercyl = disk.sectors * disk.heads; do { - printf("%s: [%llu] ", prompt, oval); + printf("%s [0 - %llu]: [%llu] ", prompt, maxval, oval); if (fgets(buf, sizeof(buf), stdin) == NULL) errx(1, "eof"); @@ -302,8 +302,8 @@ getuint64(char *prompt, u_int64_t oval, } if (saveerr == ERANGE || d > maxval || d < 0 || d < d2) { - printf("%s is out of range: %c%s%c\n", prompt, operator, - p, unit); + printf("%s is out of range: %c%s%c (%lld)\n", prompt, operator, + p, unit, (int64_t)d); } else if (*endptr != '\0') { printf("%s is invalid: %c%s%c\n", prompt, operator, p, unit); -- Gregor
Black screen with inteldrm and recent snapshots
Hi people, I just updated to a recent snapshot and once inteldrm attaches to my vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 the screen turns blank. Disabling inteldrm with boot -c prevents that, but then of course X won't start. I have already tried reverting the "Enable MSI on devices that support it"-commit, but that doesn't seem to be the culprit. The next one seems to be the "update inteldrm"-commit. How can I debug this? -- Gregor dmesg follows: OpenBSD 5.8-current (GENERIC.MP) #117: Fri Sep 25 12:37:29 CEST 2015 g...@hydrogen.unobtanium.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6314201088 (6021MB) avail mem = 6118731776 (5835MB) User Kernel Config UKC> disable inteldrm 213 inteldrm* disabled UKC> boot Unknown command, try help UKC> exit Continuing... mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 6474B84 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.34 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 265MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.00 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4645" serial 597 type LION oem "Panasonic" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2401, 2400, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:21:86:a1:1f:2b uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi azalia0: codecs: Conexant CX20561 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 82801I PCIE" rev 0x03: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R, MoW, address 00:22:fa:d0:2f:a0 ppb2 at pci0 dev 28 function 3 "Intel 82801I PCIE" rev 0x03: msi pci3 at ppb2 bus 5 ppb3 at pci0 dev 28 functi
Re: Black screen with inteldrm and recent snapshots
On Fri, Sep 25, 2015 at 01:32:07PM +0200, Mark Kettenis wrote: > [...] > I'm already onto that one. For some reason the G45/GM45 chipset goes > down a codepath that does a null-pointer dereference. > [...] If there's any way I can help, please let me know. -- Gregor
Re: tame userland diff
On Thu, Oct 01, 2015 at 06:55:21AM -0600, Theo de Raadt wrote: > For those who are curious, this is the tame diff which is currently > in snapshots. Yes, we are asking for testing and feedback. > [...] I'm getting ntpd(): syscall 97 with the patch applied. Kernel and ntpd sources are from a CVS checkout I did yesterday. I've ktrace'd ntpd, the trace file is at http://unobtanium.de/static/ktrace-ntpd.out -- Gregor
Re: tame userland diff
On Fri, Oct 02, 2015 at 01:49:13PM +0200, Tim Kuijsten wrote: > [...] > that's a 403.. Whoops, fixed. -- Gregor -- Kirkland, Illinois, law forbids bees to fly over the village or through any of its streets.
Pledge "id" for identd
Hi people, identd's parent process needs to pledge "id" so it can call setgroups and friends later. -- Gregor Index: identd.c === RCS file: /mnt/media/cvs/src/usr.sbin/identd/identd.c,v retrieving revision 1.32 diff -u -p -u -r1.32 identd.c --- identd.c16 Oct 2015 05:55:23 - 1.32 +++ identd.c21 Oct 2015 19:50:23 - @@ -314,7 +314,7 @@ main(int argc, char *argv[]) lerr(1, "signal(SIGPIPE)"); if (parent) { - if (pledge("stdio proc getpw rpath", NULL) == -1) + if (pledge("id stdio proc getpw rpath", NULL) == -1) err(1, "pledge"); SIMPLEQ_INIT(&sc.parent.replies);
smtpd: pledge, chmod and deliver_maildir
Hi people, I've noticed smtpd's deliver_maildir getting killed on syscall 15 (chmod) with the latest snapshot. I've rebuilt and core dumped it as described by Sebastien and this is the backtrace I got: #0 0x1d7e8175149a in chmod () at :2 #1 0x1d7c72744ffe in mkdirs (path=0x7f7dd0d0 "/home/gbe/Maildir", mode=448) at /usr/src/usr.sbin/smtpd/smtpd/../util.c:223 #2 0x1d7c727471d0 in delivery_maildir_open (deliver=0x7f7dd0d0) at /usr/src/usr.sbin/smtpd/smtpd/../delivery_maildir.c:99 #3 0x1d7c7273dd1e in parent_imsg (p=0x1d7e87f6a000, imsg=Variable "imsg" is not available.) at /usr/src/usr.sbin/smtpd/smtpd/../smtpd.c:1003 #4 0x1d7c7273afeb in imsg_dispatch (p=0x1d7e87f6a000, imsg=0x7f7df270) at /usr/src/usr.sbin/smtpd/smtpd/../smtpd.c:1283 #5 0x1d7c7271ed3c in mproc_dispatch (fd=Variable "fd" is not available. ) at /usr/src/usr.sbin/smtpd/smtpd/../mproc.c:213 #6 0x1d7ec1d22008 in event_base_loop (base=0x1d7ee286d800, flags=Variable "flags" is not available.) at /usr/src/lib/libevent/event.c:350 #7 0x1d7c7273bf64 in main (argc=Variable "argc" is not available.) at /usr/src/usr.sbin/smtpd/smtpd/../smtpd.c:697 smtpd's output looks like this when this happens: [... noise omitted ...] delivery: TempFail for 361bd1ee4342b3f8: from=, to=, user=gbe, method=maildir, delay=0s, stat=Error (terminated; signal 6) debug: mda: session 757ea75d406dfe65 done [... noise omitted ...] (this is with "abort" added to all pledges) The weird thing is that as far as I can see the process handling the delivery seems to correctly pledge wpath. If I remove the pledge from smtpd.c, line 693, everything works fine. Any hints on how to debug this further? I can provide core files if needed. -- Gregor
Re: smtpd: pledge, chmod and deliver_maildir
Nice to see rubber duck debugging working. The attached patch seems to be enough -- Gregor -- Index: smtpd.c === RCS file: /home/cvs/src/usr.sbin/smtpd/smtpd.c,v retrieving revision 1.250 diff -u -p -u -r1.250 smtpd.c --- smtpd.c 17 Oct 2015 16:03:20 - 1.250 +++ smtpd.c 21 Oct 2015 20:35:35 - @@ -690,7 +690,7 @@ main(int argc, char *argv[]) purge_task(); - if (pledge("stdio rpath wpath cpath flock tmppath " + if (pledge("fattr stdio rpath wpath cpath flock tmppath " "getpw sendfd proc exec id inet unix", NULL) == -1) err(1, "pledge");
Re: inteldrm(4) diff that needs testing
Hi Mark, On Sat, Oct 24, 2015 at 11:48:01PM +0200, Mark Kettenis wrote: > [...] > This diff needs to be tested on a wide range of hardware. So if you > have a machine with inteldrm(4), please give it a shot. I'm > particularly interested in testing on an x40. > [...] I got a UVM fault with the following trace: vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1uvm_fault(0x81932280, 0x28, 0, 2) -> e kernel: page fault trap, code=0 Stopped at pci_mapreg_map+0x1a8: movq%rbx,0(%rdx) ddb{0}> pci_mapreg_map() at pci_mapreg_map+0x1a8 agp_i810_attach() at agp_i810_attach+0x177 config_attach() at config_attach+0x1bc vga_pci_attach() at vga_pci_attach+0x17b config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x467 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc mainbus_attach() at mainbus_attach+0x174 config_attach() at config_attach+0x1bc cpu_configure() at cpu_configure+0x1b main() at main+0x410 end trace frame: 0x0, count: -12 ddb{0}> rebooting... The full dmesg is this: OpenBSD 5.8-current (GENERIC.MP) #132: Sun Oct 25 13:28:17 CET 2015 g...@hydrogen.unobtanium.de:/sys/arch/amd64/compile/GENERIC.MP real mem = 6314201088 (6021MB) avail mem = 6118703104 (5835MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 6474B84 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.40 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 266MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (applicatioL2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@57 mwait.3@0x30), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4645" serial 597 type LION oem "Panasonic" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2401, 2400, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 vga1 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 intagp0 at vga1uvm_fault(0x81932280, 0x28, 0, 2) -> e kernel: page fault trap, code=0 Stopped at pci_mapreg_map+0x1a8: movq%rbx,0(%rdx) ddb{0}> pci_mapreg_map() at pci_mapreg_map+0x1a8 agp_i810_attach() at agp_i810_attach+0x177 config_attach() at config_attach+0x1bc vga_pci_attach() at vga_pci_attach+0x17b config_attach() at config_attach+0x1bc pci_probe_device() at pci_probe_device+0x467 pci_enumerate_bus() at pci_enumerate_bus+0xe9 config_attach() at config_attach+0x1bc mainbus_attach() at mainbus_attach+0x174 config_attach() at config_attach+0x1bc cpu_configure() at cpu_configure+0x1b main() at main+0x410 end trace frame: 0x0, count: -12 ddb{0}> rebooting... -- Gregor
mbuf statistics, tracking of drops
Hi people, while reading around in /sys/kern/uipc_mbuf.c to try to track down a problem with my iwm(4) that seems to correlate with mbuf allocation failures, I noticed that the MBSTAT_DROPS counter and its friends MBSTAT_{WAIT,DRAIN} don't seem to get increased anywhere in /sys. Does the patch below the signature make sense for counting MBSTAT_DROPS? I've got a similar patch for MBSTAT_WAIT, but it's pretty ugly because as far as I can see, there's no real way to notice when pool_get sleeps except for "Try pool_get with M_NOWAIT first and if that returns NULL, try again with M_WAITOK". -- Gregor Index: /sys/kern/uipc_mbuf.c === RCS file: /home/cvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.250 diff -u -p -r1.250 uipc_mbuf.c --- /sys/kern/uipc_mbuf.c 12 Oct 2017 09:14:16 - 1.250 +++ /sys/kern/uipc_mbuf.c 11 Nov 2017 12:03:39 - @@ -233,14 +233,14 @@ m_get(int nowait, int type) KDASSERT(type < MT_NTYPES); m = pool_get(&mbpool, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT); - if (m == NULL) - return (NULL); s = splnet(); counters = counters_enter(&cr, mbstat); + if (m == NULL) { + counters[MBSTAT_DROPS]++; + goto out; + } counters[type]++; - counters_leave(&cr, mbstat); - splx(s); m->m_type = type; m->m_next = NULL; @@ -248,6 +248,10 @@ m_get(int nowait, int type) m->m_data = m->m_dat; m->m_flags = 0; +out: + counters_leave(&cr, mbstat); + splx(s); + return (m); } @@ -266,16 +270,23 @@ m_gethdr(int nowait, int type) KDASSERT(type < MT_NTYPES); m = pool_get(&mbpool, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT); - if (m == NULL) - return (NULL); s = splnet(); counters = counters_enter(&cr, mbstat); + if (m == NULL) { + counters[MBSTAT_DROPS]++; + goto out; + } counters[type]++; + + m->m_type = type; + +out: counters_leave(&cr, mbstat); splx(s); - m->m_type = type; + if (m == NULL) + return NULL; return (m_inithdr(m)); } @@ -349,7 +360,10 @@ m_clget(struct mbuf *m, int how, u_int p { struct mbuf *m0 = NULL; struct pool *pp; + struct counters_ref cr; + uint64_t *counters; caddr_t buf; + int s; pp = m_clpool(pktlen); #ifdef DIAGNOSTIC @@ -364,9 +378,16 @@ m_clget(struct mbuf *m, int how, u_int p m = m0; } + buf = pool_get(pp, how == M_WAIT ? PR_WAITOK : PR_NOWAIT); + if (buf == NULL) { m_freem(m0); + s = splnet(); + counters = counters_enter(&cr, mbstat); + counters[MBSTAT_DROPS]++; + counters_leave(&cr, mbstat); + splx(s); return (NULL); }
Re: mbuf statistics, tracking of drops
Hi Martin, On Sun, Nov 12, 2017 at 03:40:59PM +0100, Martin Pieuchot wrote: > [...] > It does, some comments below. > [...] Wonderful. > [...] > This would be an approximation because it might happen that after > returning NULL the second pool_get(9) won't sleep. However I think > it's the way to go because m_get(9) calls that can wait are generally > not performance critical. > [...] I had not considered that the second pool_get might not block at all. On the other hand `netstat -m` says "requests for memory delayed" for that counter, so returning immediately on the second try not counting as a delay is OK, I think. > [...] > Please do not expand the splx(). Only the counter need it. Simply put > the NULL check after the splx(). > [...] I'm not sure I understand. If I move the NULL check after the splx(), counters_leave() will already have been called so increasing the counter value has no effect anymore. The only additional things running under splnet will be a few assignments, so I think moving the splx() a bit further down does not hurt too much. Alternatively, I've attached a slightly different suggestion which doesn't expand the scope of the splx() but duplicates a bit of code. Does that make more sense? -- Gregor Index: uipc_mbuf.c === RCS file: /home/cvs/src/sys/kern/uipc_mbuf.c,v retrieving revision 1.250 diff -u -p -r1.250 uipc_mbuf.c --- uipc_mbuf.c 12 Oct 2017 09:14:16 - 1.250 +++ uipc_mbuf.c 12 Nov 2017 22:09:00 - @@ -233,11 +233,15 @@ m_get(int nowait, int type) KDASSERT(type < MT_NTYPES); m = pool_get(&mbpool, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT); - if (m == NULL) - return (NULL); s = splnet(); counters = counters_enter(&cr, mbstat); + if (m == NULL) { + counters[MBSTAT_DROPS]++; + counters_leave(&cr, mbstat); + splx(s); + return NULL; + } counters[type]++; counters_leave(&cr, mbstat); splx(s); @@ -266,11 +270,15 @@ m_gethdr(int nowait, int type) KDASSERT(type < MT_NTYPES); m = pool_get(&mbpool, nowait == M_WAIT ? PR_WAITOK : PR_NOWAIT); - if (m == NULL) - return (NULL); s = splnet(); counters = counters_enter(&cr, mbstat); + if (m == NULL) { + counters[MBSTAT_DROPS]++; + counters_leave(&cr, mbstat); + splx(s); + return NULL; + } counters[type]++; counters_leave(&cr, mbstat); splx(s); @@ -349,7 +357,10 @@ m_clget(struct mbuf *m, int how, u_int p { struct mbuf *m0 = NULL; struct pool *pp; + struct counters_ref cr; + uint64_t *counters; caddr_t buf; + int s; pp = m_clpool(pktlen); #ifdef DIAGNOSTIC @@ -364,9 +375,16 @@ m_clget(struct mbuf *m, int how, u_int p m = m0; } + buf = pool_get(pp, how == M_WAIT ? PR_WAITOK : PR_NOWAIT); + if (buf == NULL) { m_freem(m0); + s = splnet(); + counters = counters_enter(&cr, mbstat); + counters[MBSTAT_DROPS]++; + counters_leave(&cr, mbstat); + splx(s); return (NULL); }
Re: mbuf statistics, tracking of drops
Hi, On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote: > [...] > pools maintain count of how many times they failed to provide an > allocation. you can watch this with vmstat -m or systat pool. > however, we could use that to populate mb_drops too. > [...] That's certainly smarter than my idea. -- Gregor
Re: mbuf statistics, tracking of drops
On Thu, Nov 16, 2017 at 11:13:04AM +1000, David Gwynne wrote: > > > On 16 Nov 2017, at 7:23 am, Gregor Best wrote: > > > > Hi, > > > > On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote: > >> [...] > >> pools maintain count of how many times they failed to provide an > >> allocation. you can watch this with vmstat -m or systat pool. > >> however, we could use that to populate mb_drops too. > >> [...] > > > > That's certainly smarter than my idea. > > does it work though? > Now that I think about it, not quite, or at least not without reaching around into the pools innards to lock them while reading the statistics to get a consistent view. The problem is that the MBSTAT_DROPS part of the `counters` data structure never gets modified, so we'd still need to loop over all pools in sysctl_mbstat, since this is not just about mbpool but also about the pools for payload data. On the other hand, going back to my initial proposal would mean essentially duplicating functionality the pools already provide, so that's at least a bit unelegant. Especially since it adds at least one splnet/splx dance. Another option would be to just say "screw it" and count the failed allocations without acquiring any locks on the pools, maybe via atomic operations. Sounds a bit too complicated though. At the moment, and after a night's sleep, I think my initial proposal is the most straightforward way to do this. That, or getting rid of the confusing counters in `netstat -m` that stay at 0 all the time... -- Gregor
Re: inteldrm(4) diff that needs testing
On Sun, Oct 25, 2015 at 08:20:50AM -0700, Philip Guenther wrote: > [...] > This looks like the result of applying the diff but not running config > [...] Thanks for the clue bat. It's working fine on a Thinkpad T400. -- Gregor
Re: em(4) watchdog timeouts
On Mon, Nov 02, 2015 at 08:11:30PM +0100, Mark Kettenis wrote: > Can those that are experiencing watchdog timeouts check if the diff > below gets rid of them? > [...] Looks good so far. I've run a few light tests and the usual load that caused the timeouts before, haven't seen any yet. For the record, this is with em0 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:03:2d:20:cf:84 em1 at pci2 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:03:2d:20:cf:85 em2 at pci3 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:03:2d:20:cf:86 em3 at pci4 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:03:2d:20:cf:87 on i386 (GENERIC.MP). -- Gregor
Re: em(4) watchdog timeouts
On Sun, Nov 08, 2015 at 06:57:23PM +0100, Gregor Best wrote: > [...] > If it helps debugging this, I can give SSH access to the router, > provided that reboots don't happen between 18:00 and 02:00 German time > too often, since that's when we have larger amounts of visitors in our > hackerspace. > [...] Forgot to mention, the SSH access includes a push button monkey with a console cable at hand (me) in case something goes wrong. -- Gregor
Re: em(4) watchdog timeouts
On Mon, Nov 02, 2015 at 09:29:20PM +0100, Gregor Best wrote: > [...] > Looks good so far. I've run a few light tests and the usual load that > caused the timeouts before, haven't seen any yet. > [...] I just checked back on the router and it seems that the patch doesn't help after all :( The number of watchdog timeouts went down, but they are still there, about 35 in the last two days with network (and other) load on the router almost nonexistant. If it helps debugging this, I can give SSH access to the router, provided that reboots don't happen between 18:00 and 02:00 German time too often, since that's when we have larger amounts of visitors in our hackerspace. -- Gregor
Re: em(4) watchdog timeouts
I've done some further testing and I think I've narrowed it down to the "Unlocking em(4) a bit further"-patch [0]. With the patch reverted, I haven't seen any watchdog timeouts yet. I'm currently running the router with the patch reverted to make sure the timeouts don't happen again. [0]: https://www.marc.info/?l=openbsd-tech&m=144347723907388&w=4 -- Gregor
Pledge for Vi and Ex
Hi people, inspired by someone on Hackernews talking about how hard it would be to properly pledge an editor, here's a patch to pledge Vi and Ex. I'd like to go a bit deeper than this patch though: In addition to the -S option which enables "secure mode", Vi and Ex have a -R switch, which enables read-only mode. Currently, read-only mode can be overridden with the `:w!` command or with `:set noro`, so it's more of a "set the initial mode to be read-only" switch. I'd like to make this switch a permanent "never ever write a file that's not in /tmp or /var/tmp"-mode. Would a patch that does this get accepted? Related: - pledge("tmppath") currently allows writing and what not to files in /tmp. Would it make sense to expand this to /var/tmp? On normal OpenBSD systems, these are the same directory anyway and Vi for example stores its recovery files in /var/tmp. - If you pledge("tmppath"), you can only open(2) files in /tmp if you supply the O_CREAT flag. Is this intentional? Opening existing files (even reopening files I've just created with O_CREAT) without the O_CREAT flag for writing requires pledge("wpath"), which I'd like to avoid for the hypothetical "Don't write anywhere" mode. Would a patch removing this restriction be accepted? -- Gregor Index: common/main.c === RCS file: /mnt/media/cvs/src/usr.bin/vi/common/main.c,v retrieving revision 1.26 diff -u -p -u -r1.26 main.c --- common/main.c 20 Nov 2014 08:50:53 - 1.26 +++ common/main.c 11 Nov 2015 13:01:34 - @@ -17,6 +17,7 @@ #include #include +#include #include #include #include @@ -229,6 +230,14 @@ editor(GS *gp, int argc, char *argv[]) } if (LF_ISSET(SC_EX) && F_ISSET(gp, G_SCRIPTED)) silent = 1; + + if (secure) { + if (pledge("stdio rpath wpath cpath fattr flock tty", NULL)) + err(1, "pledge"); + } else { + if (pledge("stdio rpath wpath cpath fattr flock tty proc exec", NULL)) + err(1, "pledge"); + } /* * Build and initialize the first/current screen. This is a bit
Re: em(4) watchdog timeouts
Hi Alexis, On Wed, Nov 11, 2015 at 08:11:15PM +, Alexis VACHETTE wrote: > [...] > Even with heavy network load ? > [...] So far, yes. I've saturated the device for about 45 Minutes with something like this (the other end is my laptop): ## on the router $ dd if=/dev/zero bs=8k | nc 172.31.64.174 55000 ## on my laptop $ nc -l 55000 | dd of=/dev/null bs=8k (with two or three streams in parallel). There were about 6k interrupts per second and bandwidth was about 250Mbps, which seems to be the maximum the tiny CPU in this router can do. No watchdog timeouts appeared, where previously something relatively low bandwidth (the SSDs in router and laptop suck) like this caused one every 20 or 30 seconds: ## on the router $ pax -w /home | nc 172.31.64.174 55000 I'll keep an eye on things, but so far it looks good. Regular usage works out so far as well. If you need me to run some special workload for you, I'd be more than happy to do that. -- Gregor
Re: em(4) watchdog timeouts
On Mon, Nov 16, 2015 at 12:05:12AM +1000, David Gwynne wrote: > On Fri, Nov 13, 2015 at 10:18:51AM -0500, Sonic wrote: > > On Wed, Nov 11, 2015 at 9:20 AM, Gregor Best wrote: > > > I've done some further testing and I think I've narrowed it down to the > > > "Unlocking em(4) a bit further"-patch [0]. > > could you try this? its not written with the wdog stuff in mind, > but it does touch that stuff so it might help. > [...] Just tried it, sadly it doesn't seem to help :/ To be sure, I enabled debug on the routers em's, but apart from the watchdog timeout, there's nothing in there. -- Gregor
Re: vi: default to tab for filename completion
On Mon, Nov 23, 2015 at 01:36:00AM -0700, Anthony J. Bentley wrote: > [...] In addition to this, my ~/.exrc also sets cedit to tab. Would this make sense here as well? Currently it's disabled by default, but IMHO it's a useful feature for longer editing sessions. -- Gregor
Re: vi: don't escape backspace with backslash
On Mon, Nov 23, 2015 at 01:31:11AM -0700, Anthony J. Bentley wrote: > [...] > I've passed this diff around privately before and gotten a tepid > response, but it was pointed out to me that it would fit better on tech@. > [...] Yes, please. -- Gregor
Re: vmm update
Hi Mike, on amd64 with a snapshot from today, I'm getting (transcribed): kernel: page fault trap, code=0 ddb{1}> trace vm_writepage() at vm_writepage+0x158 VOP_IOCTL() at VOP_IOCTL+0x44 vn_ioctl() at vn_ioctl+0x77 sys_ioctl() at sys_ioctl+0x196 syscall() at syscall+0x368 --- syscall (number 54) --- when I try to start a VM with vmmctl start "foo" memory 64M interfaces 1 disk `pwd`/test.img kernel /bsd.rd That address is line 502 of arch/amd64/amd64/vmm.c. I played around a bit with printfs, it looks like vm->vm_map has a weird value. The printfs didn't output anything, but the fault moved to one that essentially did printf("%p\n", vm->vm_map->pmap); A full dmesg for reference is attached below the signature. What can I do to debug this further? -- Gregor OpenBSD 5.8-current (GENERIC.MP) #147: Wed Nov 25 21:21:13 CET 2015 g...@hydrogen.unobtanium.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6314201088 (6021MB) avail mem = 6118686720 (5835MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 6474B84 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 798.16 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 266MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 798.00 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus 13 (EXP4) acpiprt7 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C3(100@162 mwait.3@0x50), !C2(500@1 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB3, USB5, EHC0, EHC1 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model "42T4645" serial 597 type LION oem "Panasonic" acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 798 MHz: speeds: 2401, 2400, 1600, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel GM45 Host" rev 0x07 inteldrm0 at pci0 dev 2 function 0 "Intel GM45 Video" rev 0x07 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0: msi inteldrm0: 1440x900 wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel GM45 Video" rev 0x07 at pci0 dev 2 function 1 not configured "Intel GM45 HECI" rev 0x07 at pci0 dev 3 function 0 not configured em0 at pci0 dev 25 function 0 "Intel ICH9 IGP M AMT" rev 0x03: msi, address 00:21:86:a1:1f:2b uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x03: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x03: apic 1 int 21 uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x03: apic 1 int 22 ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x03: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 82801I HD Audio" rev 0x03: msi azalia0: codecs: Conexant CX20561 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x03: msi pci1 at ppb0
Pledge `dns' in httpd(8)
Hi people, httpd needs to pledge `dns' for name resolution to work while loading the configuration: # cat /tmp/test.conf server "default" { listen on imnotlocal port 80 } # httpd -dnvf /tmp/test.conf Abort trap # dmesg | tail -n1 httpd(18331): syscall 97 "dns" The issue is that `imnotlocal' is not a hostname that can be looked up without DNS requests. `localhost' and entries in /etc/hosts work fine for example. The attached patch adds `dns' to the pledge list in httpd.c. -- Gregor Index: httpd.c === RCS file: /mnt/media/cvs/src/usr.sbin/httpd/httpd.c,v retrieving revision 1.50 diff -u -p -r1.50 httpd.c --- httpd.c 23 Nov 2015 20:56:14 - 1.50 +++ httpd.c 2 Dec 2015 21:11:49 - @@ -251,7 +251,8 @@ main(int argc, char *argv[]) setproctitle("parent"); log_procinit("parent"); - if (pledge("stdio rpath wpath cpath inet proc ioctl sendfd", + /* dns is required for load_config */ + if (pledge("stdio rpath wpath cpath inet proc ioctl dns sendfd", NULL) == -1) fatal("pledge");
[vi/ex] Tilde expansion without forking off a shell
Hi people, the following patch allows vi (and ex) to do tilde expansion without forking off a shell. The algorithm is similar to the one in mg, modulo adaptions for the way vi handles line buffers and such. This allows editing files like `~/foobar` in secure (-S) mode, where fork and exec are disabled. There is a slight difference in behaviour compared to vi without this patch, which is that the old vi allowed disabling tilde expansion by setting the `shellmeta` option to something that does not contain a `~`. This can be re-added if it's needed though. I sent the same patch to Anthony a few weeks back, but I assume he hasn't gotten to taking a look at it yet. -- Gregor Index: common/options.c === RCS file: /mnt/media/cvs/src/usr.bin/vi/common/options.c,v retrieving revision 1.19 diff -u -p -r1.19 options.c --- common/options.c24 Nov 2015 10:28:14 - 1.19 +++ common/options.c9 Dec 2015 17:26:18 - @@ -362,7 +362,7 @@ opts_init(SCR *sp, int *oargs) (void)snprintf(b1, sizeof(b1), "shell=%s", (s = getenv("SHELL")) == NULL ? _PATH_BSHELL : s); OI(O_SHELL, b1); - OI(O_SHELLMETA, "shellmeta=~{[*?$`'\"\\"); + OI(O_SHELLMETA, "shellmeta={[*?$`'\"\\"); OI(O_SHIFTWIDTH, "shiftwidth=8"); OI(O_SIDESCROLL, "sidescroll=16"); OI(O_TABSTOP, "tabstop=8"); Index: ex/ex_argv.c === RCS file: /mnt/media/cvs/src/usr.bin/vi/ex/ex_argv.c,v retrieving revision 1.17 diff -u -p -r1.17 ex_argv.c --- ex/ex_argv.c7 Dec 2015 20:39:19 - 1.17 +++ ex/ex_argv.c9 Dec 2015 17:27:57 - @@ -11,6 +11,7 @@ #include "config.h" +#include #include #include @@ -19,6 +20,7 @@ #include #include #include +#include #include #include #include @@ -288,6 +290,58 @@ argv_exp3(SCR *sp, EXCMD *excp, char *cm return (0); } +/* Logic and code similar to mg: + * - expand tilde at beginning of file name + * - if ./~foo exists, don't expand + * - expand only one tilde + * - if file name matches ~foo/bar and foo is a user, replace ~foo by users' home dir + * - else replace ~ with current users home dir + */ +int +expand_tilde(SCR *sp, char *cmd, char **p, char **bpp, size_t *blen, size_t *len) { + size_t tlen, off, ulen; + struct stat statbuf; + struct passwd *pw; + char un[LOGIN_NAME_MAX]; + char *tmp; + + if (cmd[0] != '~' || stat(cmd, &statbuf) == 0) + goto out; + + if ((tmp = strchr(cmd, '/')) == NULL) + tmp = cmd + strlen(cmd); /* point to end of string */ + + ulen = tmp - &cmd[1]; + if (ulen >= sizeof(un)) { + goto out; + } + if (ulen == 0) { + if ((tmp = getlogin()) == NULL) + goto out; + (void) strlcpy(un, tmp, sizeof(un)); + } else { + memcpy(un, &cmd[1], ulen); + un[ulen] = '\0'; + } + + if ((pw = getpwnam(un)) == NULL) + goto out; /* XXX: print a warning message? */ + + tlen = strlen(pw->pw_dir); + *len += tlen; + off = *p - *bpp; + ADD_SPACE_GOTO(sp, *bpp, *blen, *len); + *p = *bpp + off; + memcpy(*p, pw->pw_dir, tlen); + *p += tlen; + + return ulen + 1; + +out: +alloc_err: /* ADD_SPACE_GOTO jumps here */ + return 0; +} + /* * argv_fexp -- * Do file name and bang command expansion. @@ -299,6 +353,10 @@ argv_fexp(SCR *sp, EXCMD *excp, char *cm EX_PRIVATE *exp; char *bp, *t; size_t blen, len, off, tlen; + + tlen = expand_tilde(sp, cmd, &p, bpp, blenp, lenp); + cmd += tlen; + cmdlen -= tlen; /* Replace file name characters. */ for (bp = *bpp, blen = *blenp, len = *lenp; cmdlen > 0; --cmdlen, ++cmd)
Re: initial 11n support for iwn (n, not m)
Hi Stefan, On Wed, Dec 16, 2015 at 03:35:22PM +0100, Stefan Sperling wrote: > This diff adds 11n MCS 0-7 with A-MPDU and A-MSDU Rx to the iwn(4) > driver. > [...] Whoo! Thanks a lot for your hard work :) > [...] > Please post here or let me know in private which hardware you're. > testing on Thanks. > [...] Works for me on: iwn0 at pci2 dev 0 function 0 "Intel WiFi Link 5100" rev 0x00: msi, MIMO 1T2R, MoW, address 00:22:fa:d0:2f:a0 I have done some speed testing, but with inconclusive results. I used a Macbook Pro with OS X as the other side, testing was done with iperf, both machines connected to the same WiFi: $ iperf -i 2 -c 192.168.178.54 Client connecting to 192.168.178.54, TCP port 5001 TCP window size: 17.0 KByte (default) [ 3] local 192.168.178.49 port 30131 connected with 192.168.178.54 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 2.0 sec 768 KBytes 3.15 Mbits/sec [ 3] 2.0- 4.0 sec 640 KBytes 2.62 Mbits/sec [ 3] 4.0- 6.0 sec 640 KBytes 2.62 Mbits/sec [ 3] 6.0- 8.0 sec 512 KBytes 2.10 Mbits/sec [ 3] 8.0-10.0 sec 640 KBytes 2.62 Mbits/sec [ 3] 0.0-10.3 sec 3.25 MBytes 2.64 Mbits/sec I assume the low bandwidth is due to the two thick walls separating my laptops and the access point. Everything else seems to be fine though. I'll retry the speed measurement in a few days when I'm home for christmas. > Note that if you'd like to test monitor mode you'll need to apply this > to a -current source tree from today. > [...] Haven't tested monitor mode so far, except for the IFF_PROMISC that comes with the device being a trunkport. Works fine as far as I can see. -- Gregor -- BLISS is ignorance.
Re: initial 11n support for iwn (n, not m)
Hi Stefan, On Sun, Dec 20, 2015 at 07:59:19PM +0100, Stefan Sperling wrote: > On Sat, Dec 19, 2015 at 01:08:26PM +0100, Stefan Sperling wrote: > > On Fri, Dec 18, 2015 at 05:40:39PM -0500, David Hill wrote: > > > With sthen@'s patch I can associate, dhcp, and use net. > > > > Here's an updated iwn diff with a better approach for Stuart's fix. > > > > Thanks for helping, Stuart, and to everyone who sent beacons which > > allowed us to narrow this problem down to protection settings being > > set up the wrong way in iwn_run(). > > And another update (hopefully) fixing some reported issues, with some > uncommitted net80211 changes included. > > I haven't put these diffs in yet because I'm still hearing about regressions > in some form or another. Sometimes it's unclear what people are running, > so I hope this version will linger for a bit and get tested. > Thanks for all the help so far from more people than I expected! I've been running a kernel with this patch for a few hours and I'm seeing a few fatal firmware errors in my dmesg: iwn0: fatal firmware error firmware error log: error type = "SYSASSERT" (0x0005) program counter = 0x0001DFB0 source line = 0x01FB error data = 0x01FB000A branch link = 0x0001DF940001DF94 interrupt link = 0x0916 time= 55706156 driver status: tx ring 0: qid=0 cur=2 queued=0 tx ring 1: qid=1 cur=0 queued=0 tx ring 2: qid=2 cur=0 queued=0 tx ring 3: qid=3 cur=0 queued=0 tx ring 4: qid=4 cur=30 queued=0 tx ring 5: qid=5 cur=0 queued=0 tx ring 6: qid=6 cur=0 queued=0 tx ring 7: qid=7 cur=0 queued=0 tx ring 8: qid=8 cur=0 queued=0 tx ring 9: qid=9 cur=0 queued=0 tx ring 10: qid=10 cur=0 queued=0 tx ring 11: qid=11 cur=0 queued=0 tx ring 12: qid=12 cur=0 queued=0 tx ring 13: qid=13 cur=0 queued=0 tx ring 14: qid=14 cur=0 queued=0 tx ring 15: qid=15 cur=0 queued=0 tx ring 16: qid=16 cur=0 queued=0 tx ring 17: qid=17 cur=0 queued=0 tx ring 18: qid=18 cur=0 queued=0 tx ring 19: qid=19 cur=0 queued=0 rx ring: cur=46 802.11 state 4 These seem to happen infrequently (the last one was 3 hours ago), and I've just noticed them so I don't have a pcap yet. I'm dumping right now to see if it turns up again. Apart from the firmware errors, bandwidth is okay (3 Mbit/sec, but I'm not the only person in this WLAN) and scanning/attaching seems to work fine. dmesg follows after the signature. -- Gregor OpenBSD 5.9-beta (GENERIC.MP) #153: Sun Dec 20 20:09:37 CET 2015 g...@hydrogen.unobtanium.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6314201088 (6021MB) avail mem = 6118682624 (5835MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries) bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012 bios0: LENOVO 6474B84 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) UART(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.42 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu0: 3MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 266MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz, 2394.01 MHz 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu1: 3MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xe000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus -1 (EXP2) acpiprt5 at acpi0: bus 5 (EXP3) acpiprt6 at acpi0: bus
Re: Make em(4) more mpsafe again
On Fri, Jan 01, 2016 at 12:08:53AM +1000, David Gwynne wrote: > [...] > tests? ok? > [...] I'll test it tonight in my hackerspace. There's never a better time for testing network patches than new years eve, since people will be drunk enough to ignore occasional glitches when I restart the router :) -- Gregor
Re: Make em(4) more mpsafe again
Hi David and tech@, I just tried the patch on a December 28 snapshot and got a watchdog timeout while running iperf. Just the snapshot without the patch survives iperf without a timeout. The device in question is this one: em0 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi, address 00:03:2d:20:cf:84 This is on i386. Do you need a full dmesg with/without the patch? Is there anything else I can do to aid in debugging? I'd also be more than happy to provide a shell on the router and stand by with a console cable to aid in debugging. -- Gregor
Patch: correct sysctl parameter in /sbin/route
Hi people, according to sysctl(3), AF_ROUTE is incorrect as a second level name for the CTL_NET sysctl. The attached patch corrects this. Since PF_ROUTE is defined to AF_ROUTE, there are no functional changes, but the style stays consistent this way. I have also noticed that sysctl(3) does not document the NET_RT_TABLE fifth-level name for CTL_NET/PF_ROUTE. Is this intentional or should I write another patch correcting that? Sincerely, Gregor Best Index: route.c === RCS file: /usr/src/cvs/src/sbin/route/route.c,v retrieving revision 1.167 diff -u -p -r1.167 route.c --- route.c 8 May 2014 09:28:08 - 1.167 +++ route.c 17 Jun 2014 13:20:08 - @@ -1678,7 +1678,7 @@ gettable(const char *s) errx(1, "invalid table id: %s", errstr); mib[0] = CTL_NET; - mib[1] = AF_ROUTE; + mib[1] = PF_ROUTE; mib[2] = 0; mib[3] = 0; mib[4] = NET_RT_TABLE;
[Patch] Update the ifconfig(8) manpage
Hi people, the attached patch fixes two minor issues with the ifconfig(8) manpage. The first part makes the operation of the `delete' option without an argument a bit more obvious. The second is a simple fix for the range of the `priority' option. -- Gregor Best Index: ifconfig.8 === RCS file: /usr/src/cvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.242 diff -u -p -u -r1.242 ifconfig.8 --- ifconfig.8 23 Jun 2014 18:55:29 - 1.242 +++ ifconfig.8 30 Jun 2014 17:28:08 - @@ -185,6 +185,9 @@ Disable driver-dependent debugging code. .It Cm delete Remove the specified network address, including any netmask or destination address configured with this address. +If no address is specified, the inet(4) address of the interface is assumed +if it exists. +If the interface has no inet(4) address, this option is a no-op. .It Cm description Ar value Specify a description of the interface. This can be used to label interfaces in situations where they may @@ -403,7 +406,7 @@ Set the interface routing priority to This will influence the default routing priority of new static routes added to the kernel. .Ar n -is in the range of 0 to 16 with smaller numbers being better. +is in the range of 0 to 15 with smaller numbers being better. .It Cm rdomain Ar rdomainid Attach the interface to the routing domain with the specified .Ar rdomainid .
bgpctl: enlarge columns for 4-byte ASN display
Hi people, I'm running OpenBGPD with a few peers that have large 4-byte AS numbers. Displaying the table of peers with `bgpctl show` shows the stats just fine, but the length of the AS number shifts the content of the statistics confusingly far to the right, such as in the following example: $ bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd peer 1 64734.12580316466 0 00:07:04364 peer 2 64734.12578251293 0 00:40:06365 peer 3 64828 17545 13466 0 3d17h35m325 The attached patch makes the 'AS' column 4 characters larger, with the following result: $ bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd peer 164734.12580317468 0 00:07:51364 peer 264734.12578252295 0 00:40:53365 peer 3 64828 17547 13467 0 3d17h36m325 -- Gregor Best Index: bgpctl.c === RCS file: /mnt/media/cvs/src/usr.sbin/bgpctl/bgpctl.c,v retrieving revision 1.174 diff -u -p -u -r1.174 bgpctl.c --- bgpctl.c18 Mar 2014 13:47:14 - 1.174 +++ bgpctl.c26 Jul 2014 13:49:17 - @@ -508,7 +508,7 @@ fmt_peer(const char *descr, const struct void show_summary_head(void) { - printf("%-20s %8s %10s %10s %5s %-8s %s\n", "Neighbor", "AS", + printf("%-20s %12s %10s %10s %5s %-8s %s\n", "Neighbor", "AS", "MsgRcvd", "MsgSent", "OutQ", "Up/Down", "State/PrfRcvd"); } @@ -525,7 +525,7 @@ show_summary_msg(struct imsg *imsg, int p->conf.remote_masklen, nodescr); if (strlen(s) >= 20) s[20] = 0; - printf("%-20s %8s %10llu %10llu %5u %-8s ", + printf("%-20s %12s %10llu %10llu %5u %-8s ", s, log_as(p->conf.remote_as), p->stats.msg_rcvd_open + p->stats.msg_rcvd_notification + p->stats.msg_rcvd_update + p->stats.msg_rcvd_keepalive +
Re: bgpctl: enlarge columns for 4-byte ASN display
On Sun, Jul 27, 2014 at 11:15:41AM +0200, Claudio Jeker wrote: > Not a big fan since this makes the bgpctl show output no longer fit 80 > chars and so will wrap lines on default terminals. > [...] Agreed, that's not good. > While it is OK to > increase the size it should be taken away from other fields in some whay. > An option would be to drop the OutQ since that field has only limited > value IMO. > [...] Right. I dare say on most links the OutQ column is 0 most of the time anyway, or the link has problems that are visible in other ways as well. > [...] > PS: you only need 11 chars and not 12 for AS-DOT notation > [...] Whoops, off by one. The attached patch addresses the issues you pointed out by removing the OutQ field and increasing the AS column width by 3 characters. The output fits into 77 characters now. -- Gregor Best Index: bgpctl.c === RCS file: /mnt/media/cvs/src/usr.sbin/bgpctl/bgpctl.c,v retrieving revision 1.174 diff -u -p -u -r1.174 bgpctl.c --- bgpctl.c18 Mar 2014 13:47:14 - 1.174 +++ bgpctl.c27 Jul 2014 09:53:18 - @@ -508,8 +508,8 @@ fmt_peer(const char *descr, const struct void show_summary_head(void) { - printf("%-20s %8s %10s %10s %5s %-8s %s\n", "Neighbor", "AS", - "MsgRcvd", "MsgSent", "OutQ", "Up/Down", "State/PrfRcvd"); + printf("%-20s %11s %10s %10s %-8s %s\n", "Neighbor", "AS", + "MsgRcvd", "MsgSent", "Up/Down", "State/PrfRcvd"); } int @@ -525,7 +525,7 @@ show_summary_msg(struct imsg *imsg, int p->conf.remote_masklen, nodescr); if (strlen(s) >= 20) s[20] = 0; - printf("%-20s %8s %10llu %10llu %5u %-8s ", + printf("%-20s %11s %10llu %10llu %-8s ", s, log_as(p->conf.remote_as), p->stats.msg_rcvd_open + p->stats.msg_rcvd_notification + p->stats.msg_rcvd_update + p->stats.msg_rcvd_keepalive + @@ -533,7 +533,6 @@ show_summary_msg(struct imsg *imsg, int p->stats.msg_sent_open + p->stats.msg_sent_notification + p->stats.msg_sent_update + p->stats.msg_sent_keepalive + p->stats.msg_sent_rrefresh, - p->wbuf.queued, fmt_timeframe(p->stats.last_updown)); if (p->state == STATE_ESTABLISHED) { printf("%6u", p->stats.prefix_cnt);
Re: bgpctl: enlarge columns for 4-byte ASN display
On Sun, Jul 27, 2014 at 03:36:06PM +0100, Stuart Henderson wrote: > On 2014/07/27 11:15, Claudio Jeker wrote: > > Not a big fan since this makes the bgpctl show output no longer fit 80 > > chars and so will wrap lines on default terminals. While it is OK to > > increase the size it should be taken away from other fields in some whay. > > An option would be to drop the OutQ since that field has only limited > > value IMO. > > oh, I would miss not having OutQ, it's totally useless when things are > working correctly, but I have had a couple of situations (one with openbgp, > one with *cough* bay BCN "some time ago"...) where this has been helpful. > It gives quite a clear pointer to problems transmitting to that particular > peer without having to look in netstat output and work out which peer is > which (some physical layer problems, MTU problems etc). > > I think the most usable display would be to have neighbor and AS "share" > a column, with priority to AS... i.e. > > somepeer12345 16419 89603 0 09:42:06100/8000 > somepeer-with-long-name 567816049401367282 0 13:39:28100/8000 > otherpeer16584484 16420 89606 0 1d00h58m Active > otherpeer-with-long- 1658448516049401367282 0 13:40:17100/8000 > The attached patch does just that. Maximum line length is now 80 characters (excluding the trailing newline), and the "Neighbor" and "AS" columns now take a combined maximum of 29 characters, including the blank separating peer name and AS. The result looks like this: $ bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd other-peer-with-l 16581.44851 0 0 0 NeverConnect other-peer 1658.44841 0 0 0 NeverActive some-peer-with-long-name 5678 0 0 0 NeverActive some-peer 12345 0 0 0 NeverActive Where before it was $ bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd other-peer-with-long 16581.44851 0 0 0 NeverConnect other-peer 1658.44841 0 0 0 NeverActive some-peer-with-long- 5678 0 0 0 NeverActive some-peer 12345 0 0 0 NeverConnect -- Gregor Best Index: bgpctl.c === RCS file: /mnt/media/cvs/src/usr.sbin/bgpctl/bgpctl.c,v retrieving revision 1.174 diff -u -p -u -r1.174 bgpctl.c --- bgpctl.c18 Mar 2014 13:47:14 - 1.174 +++ bgpctl.c27 Jul 2014 15:20:59 - @@ -517,16 +517,26 @@ show_summary_msg(struct imsg *imsg, int { struct peer *p; char*s; + const char *a; + char*pa; + size_t alen; switch (imsg->hdr.type) { case IMSG_CTL_SHOW_NEIGHBOR: p = imsg->data; s = fmt_peer(p->conf.descr, &p->conf.remote_addr, p->conf.remote_masklen, nodescr); - if (strlen(s) >= 20) - s[20] = 0; - printf("%-20s %8s %10llu %10llu %5u %-8s ", - s, log_as(p->conf.remote_as), + + a = log_as(p->conf.remote_as); + alen = strlen(a); + + if (asprintf(&pa, "%-28s", s) == -1) + err(1, NULL); + if (strlen(pa) > 28 - alen) + pa[28 - alen] = 0; + + printf("%s %s %10llu %10llu %5u %-8s ", + pa, a, p->stats.msg_rcvd_open + p->stats.msg_rcvd_notification + p->stats.msg_rcvd_update + p->stats.msg_rcvd_keepalive + p->stats.msg_rcvd_rrefresh, @@ -544,6 +554,7 @@ show_summary_msg(struct imsg *imsg, int else printf("%s", statenames[p->state]); printf("\n"); + free(pa); free(s); break; case IMSG_CTL_END:
Re: bgpctl: enlarge columns for 4-byte ASN display
Ping? Are there remaining issues with the patch or should I leave you guys alone until the release stress is over? -- Gregor Best
Re: bgpctl: enlarge columns for 4-byte ASN display
Ping. -- Gregor Best
Re: bgpctl: enlarge columns for 4-byte ASN display
On Sun, Jul 27, 2014 at 10:06:12PM +0100, Stuart Henderson wrote: > [...] > Nice, I like that a lot. What do you think Claudio? > [...] Ping. Are there remaining issues with the patch? -- Gregor Best
Add support for Arduino Leonardo to umodem(4)
Hi, Arduino Leonardos emulate a CDC ACM modem for their serial port. The following patch adds explicit matching for those in umodem_match, because apparently the emulation done by the Leonardo is not complete enough to make umodem attach automatically. I've tested a kernel with this patch for a few days now, but only with a baudrate of 115200, which seems to work fine. -- Gregor Best Index: dev/usb/umodem.c === RCS file: /mnt/media/cvs/src/sys/dev/usb/umodem.c,v retrieving revision 1.57 diff -u -p -u -r1.57 umodem.c --- dev/usb/umodem.c12 Jul 2014 20:26:33 - 1.57 +++ dev/usb/umodem.c13 Feb 2015 19:36:39 - @@ -250,6 +250,10 @@ umodem_match(struct device *parent, void id->bInterfaceNumber == 0) ret = UMATCH_VENDOR_PRODUCT; + if (UGETW(dd->idVendor) == USB_VENDOR_ARDUINO && + UGETW(dd->idProduct) == USB_PRODUCT_ARDUINO_LEONARDO) + ret = UMATCH_VENDOR_PRODUCT; + if (ret == UMATCH_NONE && id->bInterfaceClass == UICLASS_CDC && id->bInterfaceSubClass == UISUBCLASS_ABSTRACT_CONTROL_MODEL && Index: dev/usb/usbdevs === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.644 diff -u -p -u -r1.644 usbdevs --- dev/usb/usbdevs 9 Jan 2015 20:41:48 - 1.644 +++ dev/usb/usbdevs 13 Feb 2015 19:36:40 - @@ -54,6 +54,7 @@ vendor PLANEX40x0053 Planex Communicat vendor UNKNOWN20x0105 Unknown vendor vendor EGALAX2 0x0123 eGalax vendor UNKNOWN60x01e1 Unknown vendor +vendor ARDUINO 0x2341 Arduino LLC vendor HUMAX 0x02ad HUMAX vendor BWCT0x03da Bernd Walter Computer Technology vendor AOX 0x03e8 AOX @@ -977,6 +978,9 @@ product APPLE ISIGHT0x8502 iSight /* Araneus Information Systems products */ product ARANEUS ALEA 0x0001 True Random Number Generator + +/* Arduino LLC products */ +product ARDUINO LEONARDO 0x8036 Arduino Lenoardo /* Arkmicro products */ product ARKMICRO ARK3116 0x0232 ARK3116 Serial Index: dev/usb/usbdevs.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v retrieving revision 1.656 diff -u -p -u -r1.656 usbdevs.h --- dev/usb/usbdevs.h 9 Jan 2015 20:42:40 - 1.656 +++ dev/usb/usbdevs.h 13 Feb 2015 19:36:44 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs.h,v 1.656 2015/01/09 20:42:40 kettenis Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -61,6 +61,7 @@ #defineUSB_VENDOR_UNKNOWN2 0x0105 /* Unknown vendor */ #defineUSB_VENDOR_EGALAX2 0x0123 /* eGalax */ #defineUSB_VENDOR_UNKNOWN6 0x01e1 /* Unknown vendor */ +#defineUSB_VENDOR_ARDUINO 0x2341 /* Arduino LLC */ #defineUSB_VENDOR_HUMAX0x02ad /* HUMAX */ #defineUSB_VENDOR_BWCT 0x03da /* Bernd Walter Computer Technology */ #defineUSB_VENDOR_AOX 0x03e8 /* AOX */ @@ -984,6 +985,9 @@ /* Araneus Information Systems products */ #defineUSB_PRODUCT_ARANEUS_ALEA0x0001 /* True Random Number Generator */ + +/* Arduino LLC products */ +#defineUSB_PRODUCT_ARDUINO_LEONARDO0x8036 /* Arduino Lenoardo */ /* Arkmicro products */ #defineUSB_PRODUCT_ARKMICRO_ARK31160x0232 /* ARK3116 Serial */ Index: dev/usb/usbdevs_data.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v retrieving revision 1.650 diff -u -p -u -r1.650 usbdevs_data.h --- dev/usb/usbdevs_data.h 9 Jan 2015 20:42:40 - 1.650 +++ dev/usb/usbdevs_data.h 13 Feb 2015 19:36:44 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs_data.h,v 1.650 2015/01/09 20:42:40 kettenis Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -962,6 +962,10 @@ const struct usb_known_product usb_known "True Random Number Generator", }, { + USB_VENDOR_ARDUINO, USB_PRODUCT_ARDUINO_LEONARDO, + "Arduino Lenoardo", + }, + { USB_VENDOR_ARKMICRO, USB_PRODUCT_ARKMICRO_ARK3116, "ARK3116 Serial", }, @@ -11248,6 +11252,10 @@ const struct usb_known_vendor usb_known_ { USB_VENDOR_UNKNOWN6, "Unknown vendor", + }, + { + USB_VENDOR_ARDUINO, + "Arduino LLC", }, { USB_VENDOR_HUMAX,
Re: Add support for Arduino Leonardo to umodem(4)
On Mon, Feb 16, 2015 at 02:20:06PM +, Stuart Henderson wrote: > [...] > It's Arduino SA isn't it? The rest looks good to me. > [...] The controller reports itself as made by 'Arduino LLC' in the usbdevs output, but according to http://www.linux-usb.org/usb.ids, you're right. I think going with the established name is a better idea. I've attached an amended patch. -- Gregor Best Index: dev/usb/umodem.c === RCS file: /mnt/media/cvs/src/sys/dev/usb/umodem.c,v retrieving revision 1.57 diff -u -p -u -r1.57 umodem.c --- dev/usb/umodem.c12 Jul 2014 20:26:33 - 1.57 +++ dev/usb/umodem.c13 Feb 2015 19:36:39 - @@ -250,6 +250,10 @@ umodem_match(struct device *parent, void id->bInterfaceNumber == 0) ret = UMATCH_VENDOR_PRODUCT; + if (UGETW(dd->idVendor) == USB_VENDOR_ARDUINO && + UGETW(dd->idProduct) == USB_PRODUCT_ARDUINO_LEONARDO) + ret = UMATCH_VENDOR_PRODUCT; + if (ret == UMATCH_NONE && id->bInterfaceClass == UICLASS_CDC && id->bInterfaceSubClass == UISUBCLASS_ABSTRACT_CONTROL_MODEL && Index: dev/usb/usbdevs === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.644 diff -u -p -u -r1.644 usbdevs --- dev/usb/usbdevs 9 Jan 2015 20:41:48 - 1.644 +++ dev/usb/usbdevs 13 Feb 2015 19:36:40 - @@ -54,6 +54,7 @@ vendor PLANEX40x0053 Planex Communicat vendor UNKNOWN20x0105 Unknown vendor vendor EGALAX2 0x0123 eGalax vendor UNKNOWN60x01e1 Unknown vendor +vendor ARDUINO 0x2341 Arduino SA vendor HUMAX 0x02ad HUMAX vendor BWCT0x03da Bernd Walter Computer Technology vendor AOX 0x03e8 AOX @@ -977,6 +978,9 @@ product APPLE ISIGHT0x8502 iSight /* Araneus Information Systems products */ product ARANEUS ALEA 0x0001 True Random Number Generator + +/* Arduino SA products */ +product ARDUINO LEONARDO 0x8036 Arduino Lenoardo /* Arkmicro products */ product ARKMICRO ARK3116 0x0232 ARK3116 Serial Index: dev/usb/usbdevs.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs.h,v retrieving revision 1.656 diff -u -p -u -r1.656 usbdevs.h --- dev/usb/usbdevs.h 9 Jan 2015 20:42:40 - 1.656 +++ dev/usb/usbdevs.h 13 Feb 2015 19:36:44 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs.h,v 1.656 2015/01/09 20:42:40 kettenis Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -61,6 +61,7 @@ #defineUSB_VENDOR_UNKNOWN2 0x0105 /* Unknown vendor */ #defineUSB_VENDOR_EGALAX2 0x0123 /* eGalax */ #defineUSB_VENDOR_UNKNOWN6 0x01e1 /* Unknown vendor */ +#defineUSB_VENDOR_ARDUINO 0x2341 /* Arduino SA */ #defineUSB_VENDOR_HUMAX0x02ad /* HUMAX */ #defineUSB_VENDOR_BWCT 0x03da /* Bernd Walter Computer Technology */ #defineUSB_VENDOR_AOX 0x03e8 /* AOX */ @@ -984,6 +985,9 @@ /* Araneus Information Systems products */ #defineUSB_PRODUCT_ARANEUS_ALEA0x0001 /* True Random Number Generator */ + +/* Arduino SA products */ +#defineUSB_PRODUCT_ARDUINO_LEONARDO0x8036 /* Arduino Lenoardo */ /* Arkmicro products */ #defineUSB_PRODUCT_ARKMICRO_ARK31160x0232 /* ARK3116 Serial */ Index: dev/usb/usbdevs_data.h === RCS file: /mnt/media/cvs/src/sys/dev/usb/usbdevs_data.h,v retrieving revision 1.650 diff -u -p -u -r1.650 usbdevs_data.h --- dev/usb/usbdevs_data.h 9 Jan 2015 20:42:40 - 1.650 +++ dev/usb/usbdevs_data.h 13 Feb 2015 19:36:44 - @@ -1,4 +1,4 @@ -/* $OpenBSD: usbdevs_data.h,v 1.650 2015/01/09 20:42:40 kettenis Exp $ */ +/* $OpenBSD$ */ /* * THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. @@ -962,6 +962,10 @@ const struct usb_known_product usb_known "True Random Number Generator", }, { + USB_VENDOR_ARDUINO, USB_PRODUCT_ARDUINO_LEONARDO, + "Arduino Lenoardo", + }, + { USB_VENDOR_ARKMICRO, USB_PRODUCT_ARKMICRO_ARK3116, "ARK3116 Serial", }, @@ -11248,6 +11252,10 @@ const struct usb_known_vendor usb_known_ { USB_VENDOR_UNKNOWN6, "Unknown vendor", + }, + { + USB_VENDOR_ARDUINO, + "Arduino SA", }, { USB_VENDOR_HUMAX,
Hangs with Fuse
Hi Sylvestre, while playing around with sshfs, I noticed a peculiar behaviour. If I mount it somewhere and run something like find /mnt/fuse -type f -name '*.core' on it, everything seems to work fine until the network connection is interrupted. The system then hangs, with only the keyboard LEDs like the caps lock indicator working (i.e. pressing caps lock turns the LED on and off, but nothing else seems to work). The simplest way to reproduce this is via something like the following: sshfs user@somehost:/foo /mnt/fuse while true; do find /mnt/fuse -type f; done & while sleep 1; date; done While that is running, the date is printed once every second. After interrupting the network connection, for example by pulling the cable, the date continues to get printed for a few second and then stops. Is there a way to properly debug this? Are there "typical spots" in fuse where adding one or two printfs() might yield further insight? Thanks in advance, Gregor Best
Re: Hangs with Fuse
Hi Sylvestre, > [...] > Did you use the last snapshots ? If yes you need to recompile your > libfuse and your kernel to get the last changes. > [...] thanks for the clue bat. Not upgrading libfuse was indeed the problem. -- Gregor Best
Re: top(1) interactive commands after SIGWINCH
On Mon, Jan 13, 2014 at 05:04:28PM +, Stuart Henderson wrote: > If anyone is interested in looking at a signal problem in top, > here's a small but annoying bug.. > > - run top in an xterm > - resize the window > - try to use an interactive command that takes an argument, e.g. "s" > or "g" (doesn't happen with commands like "S" or "H" that work immediately) > > Often, pressing the command key just refreshes the screen, it takes > multiple attempts for the command to take effect (sometimes just a > couple, sometimes loads of attempts). > [...] The patch below seems to fix that for me. resizeterm() does a putchar(KEY_RESIZE), part of which then gets interpreted as a command parameter in rundisplay(). I'm not too sure on the cast to char, but since isascii() makes sure the value passed is below 0177, i figured that would be okay. -- Gregor Best --- top.c.old Mon Jan 13 20:49:28 2014 +++ top.c Mon Jan 13 20:49:11 2014 @@ -39,6 +39,7 @@ #include #include #include +#include /* includes specific to top */ #include "display.h" /* interface to display package */ @@ -548,7 +549,7 @@ static char tempbuf[TEMPBUFSIZE]; sigset_t mask; char ch, *iptr; - int change, i; + int change, i, cch; struct pollfd pfd[1]; uid_t uid, huid; static char command_chars[] = "\f qh?en#sdkriIuSopCHg+P1"; @@ -612,14 +613,12 @@ * now read it and convert to * command strchr */ - while (1) { - len = read(STDIN_FILENO, &ch, 1); - if (len == -1 && errno == EINTR) - continue; - if (len == 0) - exit(1); - break; - } + cch = getch(); + /* If the terminal is resized, curses does putchar(KEY_RESIZE) */ + if (!isascii(cch)) + return 0; + ch = (char) cch; + if ((iptr = strchr(command_chars, ch)) == NULL) { /* illegal command */ new_message(MT_standout, " Command not understood");
Re: top(1) interactive commands after SIGWINCH
On Mon, Jan 13, 2014 at 12:41:19PM -0800, Philip Guenther wrote: > [...] > I think you meant "ungetch(KEY_RESIZE)", > [...] You're right. > [...] > seems to fix the problem in my testing. > [...] Works for me too. -- Gregor Best
Re: missing ports.tar.gz in snapshot
On Thu, Mar 06, 2014 at 07:56:14AM -0700, Theo de Raadt wrote: > [...] > I'd like to ask. Does anyone find it useful? It is not in sync with the > packages beside it. > [...] In the past, I found the tarball quite useful to jump start the ports tree on my local machine. I'd extract it and then use CVS to update it to the repository, because that's usually a lot faster than doing the entire checkout from CVS. I could live with the tarball gone though. -- Gregor Best
Re: inteldrm suspend/resume regression (Was: Suspend/resume in Gnome)
On Fri, Mar 07, 2014 at 05:00:43PM -0700, Theo de Raadt wrote: > Any feedback? > [...] A current CVS checkout + cold=2 suspends fine and hangs on resume. By "hang", I mean the display stays black and the little halfmoon LED continues blinking instead of turning off. I suppose that means the kernel is busy printing a shitton of "TSLEEP" and takes a _very_ long time to come up again. Sadly, I don't have a serial console on my laptop, so I can't verify that. For the record, I have vga1 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x0c Is there anything I can do to further assist? Thanks a lot by the way for the explanation of DVACT_RESUME vs. DVACT_WAKEUP. -- Gregor Best
Re: inteldrm/radeondrm suspend/resume diff
On Thu, Mar 13, 2014 at 10:31:18AM +0100, Mark Kettenis wrote: > > [...] > > P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4) > > and radeondrm(4) on my t400. > > Here's a slightly better diff that should eleminate a (largely > theoretical) deadlock. If you didn't test yet, try this version > instead. > [...] Suspend (to RAM) and resume works fine here with vga1 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x0c Couldn't test hibernate yet because my system has root on a softraid crypto device and the swap is outside the crypto area. -- Gregor Best
Re: inteldrm/radeondrm suspend/resume diff
On Thu, Mar 13, 2014 at 11:16:42AM +0100, Gregor Best wrote: > [...] > Couldn't test hibernate yet because my system has root on a softraid > crypto device and the swap is outside the crypto area. > [...] David gave me a hint on how to hardwire my kernel for swap on sd0b. With that, hibernate works slowly, but it works. The full hibernate + resume cycle takes about one or two minutes, which I guess is fine. I'm not sure whether hibernation working is a direct consequence of this diff, but I think that's OK since the diff didn't break it either. -- Gregor Best
Scheduler improvements
Hi people, attached is a patch that basically rewrites the CPU scheduler. It replaces the multilevel feedback queue currently employed with an earliest effective deadline first approach, similar to the BrainFuck Scheduler for Linux. My main motivation for rewriting the scheduler was mplayer getting killed all the time because it went over its share of CPU resources, something which can not happen with the patch I wrote. The algorithms employed simply assigns a (soft) deadline to each process, which is calculated based solely on nice value and selects the next process to execute based on the earliest deadline in the runqueue. If more than one deadline is missed, the first one encountered in FIFO order (FIFO with respect to insertion into the runqueue) with a deadline smaller than current time is selected. This prevents processes from yielding a small time before their timeslice expires to fool the scheduler into leaving them in their respective priority queue, thus preventing multiple processes from teaming up to starve others of CPU runtime. I did a few benchmarks to test the difference between the original and my patched scheduler to see whether there was any improvements. The tool I used was sysbench (with both CPU and Threads benchmarks). There are a few graphs of the tests at http://gurkenfunk.de/projects/openbsd-eevdf, but it looks as if my patches improve latency on workloads with high CPU usage, little I/O and a relatively large amount of threads. I'm not aiming for a "yeah, nice, we'll merge it" on this, but rather for suggestions whether it's worth anyones time to pursue this further. Oh, also, with the patch, the scheduler code is 225 lines shorter and IMHO a bit easier to understand. -- Gregor Best ? sys/.git ? sys/.gitignore ? sys/vim.core ? sys/arch/alpha/stand/installboot/installboot.8.manlint ? sys/arch/alpha/stand/setnetbootinfo/setnetbootinfo.8.manlint ? sys/arch/amd64/amd64/.acpi_machdep.c.swp ? sys/arch/amd64/include/.cpu.h.swp ? sys/arch/armish/stand/boot/boot.8.manlint ? sys/arch/aviion/stand/a2coff/a2coff.8.manlint ? sys/arch/hppa/stand/boot/boot.8.manlint ? sys/arch/hppa/stand/mkboot/mkboot.8.manlint ? sys/arch/hppa64/stand/boot/boot.8.manlint ? sys/arch/hppa64/stand/mkboot/mkboot.8.manlint ? sys/arch/i386/stand/biosboot/biosboot.8.manlint ? sys/arch/i386/stand/boot/boot.8.manlint ? sys/arch/i386/stand/cdboot/cdboot.8.manlint ? sys/arch/i386/stand/installboot/installboot.8.manlint ? sys/arch/i386/stand/pxeboot/pxeboot.8.manlint ? sys/arch/landisk/stand/boot/boot.8.manlint ? sys/arch/landisk/stand/mbr/mbr.8.manlint ? sys/arch/landisk/stand/xxboot/xxboot.8.manlint ? sys/arch/mvme68k/stand/installboot/installboot.8.manlint ? sys/arch/mvme88k/stand/installboot/installboot.8.manlint ? sys/arch/sgi/stand/sgivol/sgivol.8.manlint ? sys/arch/socppc/stand/boot/boot.8.manlint ? sys/arch/socppc/stand/mkboot/mkboot.8.manlint ? sys/arch/sparc/stand/installboot/installboot.8.manlint ? sys/arch/sparc64/stand/installboot/installboot.8.manlint ? sys/arch/zaurus/stand/zboot/boot.8.manlint ? sys/dev/microcode/atmel/atu-at76c503-i3863-ext ? sys/dev/microcode/atmel/atu-at76c503-i3863-int ? sys/dev/microcode/atmel/atu-at76c503-rfmd-acc-ext ? sys/dev/microcode/atmel/atu-at76c503-rfmd-acc-int ? sys/dev/microcode/atmel/atu-at76c505-rfmd-ext ? sys/dev/microcode/atmel/atu-at76c505-rfmd-int ? sys/dev/microcode/atmel/atu-intersil-ext ? sys/dev/microcode/atmel/atu-intersil-int ? sys/dev/microcode/atmel/atu-rfmd-ext ? sys/dev/microcode/atmel/atu-rfmd-int ? sys/dev/microcode/atmel/atu-rfmd2958-ext ? sys/dev/microcode/atmel/atu-rfmd2958-int ? sys/dev/microcode/atmel/atu-rfmd2958smc-ext ? sys/dev/microcode/atmel/atu-rfmd2958smc-int ? sys/dev/microcode/atmel/build ? sys/dev/microcode/bnx/bnx-b06 ? sys/dev/microcode/bnx/bnx-b09 ? sys/dev/microcode/bnx/bnx-rv2p ? sys/dev/microcode/bnx/bnx-xi-rv2p ? sys/dev/microcode/bnx/bnx-xi90-rv2p ? sys/dev/microcode/bnx/build ? sys/dev/microcode/cirruslogic/build ? sys/dev/microcode/cirruslogic/cs4280 ? sys/dev/microcode/fxp/build ? sys/dev/microcode/fxp/fxp-d101a ? sys/dev/microcode/fxp/fxp-d101b0 ? sys/dev/microcode/fxp/fxp-d101ma ? sys/dev/microcode/fxp/fxp-d101s ? sys/dev/microcode/fxp/fxp-d102 ? sys/dev/microcode/fxp/fxp-d102c ? sys/dev/microcode/fxp/fxp-d102e ? sys/dev/microcode/kue/build ? sys/dev/microcode/kue/kue ? sys/dev/microcode/myx/build ? sys/dev/microcode/myx/myx-eth_z8e ? sys/dev/microcode/myx/myx-ethp_z8e ? sys/dev/microcode/ral/build ? sys/dev/microcode/ral/ral-rt2561 ? sys/dev/microcode/ral/ral-rt2561s ? sys/dev/microcode/ral/ral-rt2661 ? sys/dev/microcode/ral/ral-rt2860 ? sys/dev/microcode/rum/build ? sys/dev/microcode/rum/rum-rt2573 ? sys/dev/microcode/rum/run-rt2870 ? sys/dev/microcode/rum/run-rt3071 ? sys/dev/microcode/tht/build ? sys/dev/microcode/tht/tht ? sys/dev/microcode/tigon/build ? sys/dev/microcode/tigon/tigon1 ? sys/dev/microcode/tigon/tigon2 ? sys/dev/microcode/tusb3410/build ? sys/dev/microcode/tusb3410/tus
Re: Scheduler improvements
On Wed, Oct 12, 2011 at 05:51:33PM +, Miod Vallat wrote: > > Hi people, > > [...] > > > I'm not aiming for a "yeah, nice, we'll merge it" on this, but rather > > for suggestions whether it's worth anyones time to pursue this further. > > This is interesting, there might be a good outcome of this diff > eventually. However as of now: > - you have removed the bunch of code which tries to make sure processes > do not hop between cpus unless there is a gain in doing so, on MP > kernels. Did you try your diff on a MP kernel? [...] Yes. Almost all builds I have done so far were MP kernels, which I run almost all the time (I switch to un-patched kernels for benchmarks only). I'll do a benchmark with an SP build though to check whether there are any negative impacts. > - non-tabbed indent is evil. And makes the diff harder to read. [...] I will clean that up. > - I see many locks removed in there, and moving information to the proc > structure does not explain all of them. This gives a bad gut feeling > about the behaviour of this on MP kernels. A really bad gut feeling. [...] Works fine with two cores, but I can see where that feeling comes from. I'll add some more explanations to my changes. > - you have changed the roundrobin duration from (hz / 10 to (hz / 100). > However, this computation yields zero on platforms where hz < 100, > which is not a good idea. The only assumptions you can make about hz > is that 50 <= hz <= 1024. [...] Good point. I'll change that. > - you removed the enforcement of RLIMIT_CPU. No way. Over my dead body. > - I also don't really like switching from NQS run queues to a single > one. I understand you need this to be able to compare the deadlines > with only one queue walk, but this can become expensive with many > processes in the runqueue... [...] Right. I'm planning to move this to a real priority queue via some sort of heap, so lookups and insertions can be done in O(log n) instead of O(n). > - your priority computation are unexplained magic. What does 20 mean? > Shouldn't at least one of them be derived from `hz'? Why << 1 versus > << 5? Are you sure the values you are computed are always within the > bounds you are expecting? Why isn't there any comment about these > computations? [...] Deriving them from hz didn't cross my mind but you are right of course. I chose the << 5 because that makes for a relatively linear increase in the deadlines while not overflowing the value of .tv_usec. I'll add some explanations though. > > Miod > Thanks a lot for your time and suggestions. -- Gregor Best [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Scheduler improvements
Hi people, after a (very) long time of silence on this, here's another go at it. This time, I basically started from scratch and used a bit of code by Christiano Haesberth which had been posted to tech@ a while ago to detect CPU topology on amd64 and take that into account when moving processes between CPUs. This version has one single queue per CPU, getting rid of a) the one single system wide runqueue and b) the queue for expired processes. This simplifies things a bit and performs just as well as my previous versions (the only difference is the order in which expired procs get selected for running on a CPU). One advantage is that process selection is in O(log n) of the number of processes on the CPU and depends neither on the total number of processes nor the number of expired processes in the runqueue. The factors for the cost of moving a process between hardware threads, cpu dies and cpu packages are guesses now, I think those will have to be tuned further. Sadly, I haven't had access to a multiprocessor machine with a more diverse architecture than "a bunch of cores on the same die". I tested this on some more machines than before; a Core i5, an i7 and my Core 2 Duo and on all machines (perceived) interactivity was improved. The simplest benchmark I used was playing back a 1080p version of Big Buck Bunny with mplayer. All machines I tested on had Intel graphics cards, one GM965 (on the Core2Duo) and the others were Sandy Bridge devices. On all of them, playback was smoother with the i7 being most visible. With the default scheduler, watching the movie was a big pain due to heavy frame-dropping, with my patch, the movie was watchable (with frame dropping only (barely) noticable in scenes with much movement). As before, I'm looking forward to anything you have to comment, especially cool benchmark ideas or the like. -- Gregor Best Index: arch/amd64/amd64/identcpu.c === RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v retrieving revision 1.39 diff -u -r1.39 identcpu.c --- arch/amd64/amd64/identcpu.c 19 Sep 2012 20:19:31 - 1.39 +++ arch/amd64/amd64/identcpu.c 4 Oct 2012 21:27:55 - @@ -202,6 +202,8 @@ void via_nano_setup(struct cpu_info *ci); +void cpu_topology(struct cpu_info *ci); + void via_nano_setup(struct cpu_info *ci) { @@ -470,4 +472,123 @@ sensordev_install(&ci->ci_sensordev); #endif } + + cpu_topology(ci); +} + +/* + * Base 2 logarithm of an int. returns 0 for 0 (yeye, I know). + */ +static int +log2(unsigned int i) +{ + int ret = 0; + + while (i >>= 1) + ret++; + + return (ret); +} + +static int +mask_width(u_int x) +{ + int bit; + int mask; + int powerof2; + + powerof2 = ((x - 1) & x) == 0; + mask = (x << (1 - powerof2)) - 1; + + /* fls */ + if (mask == 0) + return (0); + for (bit = 1; mask != 1; bit++) + mask = (unsigned int)mask >> 1; + + return (bit); +} + +/* + * Build up cpu topology for given cpu, must run on the core itself. + */ +void +cpu_topology(struct cpu_info *ci) +{ + u_int32_t eax, ebx, ecx, edx; + u_int32_t apicid, max_apicid, max_coreid; + u_int32_t smt_bits, core_bits, pkg_bits; + u_int32_t smt_mask, core_mask, pkg_mask; + + /* We need at least apicid at CPUID 1 */ + CPUID(0, eax, ebx, ecx, edx); + if (eax < 1) + goto no_topology; + + /* Initial apicid */ + CPUID(1, eax, ebx, ecx, edx); + apicid = (ebx >> 24) & 0xff; + + if (strcmp(cpu_vendor, "AuthenticAMD") == 0) { + /* We need at least apicid at CPUID 0x8008 */ + CPUID(0x8000, eax, ebx, ecx, edx); + if (eax < 0x8008) + goto no_topology; + + CPUID(0x8008, eax, ebx, ecx, edx); + core_bits = (ecx >> 12) & 0xf; + if (core_bits == 0) + goto no_topology; + /* So coreidsize 2 gives 3, 3 gives 7... */ + core_mask = (1 << core_bits) - 1; + /* Core id is the least significant considering mask */ + ci->ci_core_id = apicid & core_mask; + /* Pkg id is the upper remaining bits */ + ci->ci_pkg_id = apicid & ~core_mask; + ci->ci_pkg_id >>= core_bits; + } else if (strcmp(cpu_vendor, "GenuineIntel") == 0) { + /* We only support leaf 1/4 detection */ + CPUID(0, eax, ebx, ecx, edx); + if (eax < 4) + goto no_topology; + /* Get max_apicid */ + CPUID(1, eax, ebx, ecx, edx); + max_apicid = (ebx >> 16) & 0xff; + /* Get
Re: Scheduler improvements
Hi Alexandre, > [...] > This change is unclear for me; AFAIU, it removes the mechanism > which makes processes wake up with a priority depending on what > they are blocked on. > [...] Where do you see that? The code I removed/changed simply calulated the queue from which to remove `p` and removed it from there (similar for insertion). That needed to be changed to modify the RB tree used as a new runqueue. > [...] > For instance processes waking up from poll(2) or audio read/write > won't be prioritized any longer. If so, this would hurt audio and > other interactive processes but would improve cpu-intesive > bloatware. > [...] They weren't prioritised with the old version of this code either. > [...] > this change is unrelated to the rest isn't it? > [...] Yes, it is. I changed it because 100ms time slices felt a bit too large, but the rest of the patch will of course work without this bit. Thanks for taking your time to look at this :) -- Gregor Best
Re: Scheduler improvements
> [...] > I don't think changing the idle loop like this is ok. You want to > continue checking whether the runqueue is empty in between > cpu_idle_enter() and cpu_idle_leave(). > [...] Fair point. I'll change that :) -- Gregor Best
Re: Scheduler improvements
On Mon, Oct 08, 2012 at 06:28:53PM +0200, Alexandre Ratchov wrote: > [...] > AFAIU, when a process waits for an event (with tsleep(9)), it > provides the priority of the event it's waiting for (eg an audio > interrupt). When the event occurs, the process is put in the > runnable queue calculated from the priority. This way, interactive > processes (i.e. waiting for external events) are prioritized during > the event processing. > [...] I haven't noticed any degradation in performance with media-stuff (quite the contrary, actually), but you have a point. I'll change the deadline-calculation to also take the sleep priority into account. Thanks for the explanation :) -- Gregor Best [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Scheduler improvements
On Mon, Oct 08, 2012 at 07:42:13PM +0200, Marc Espie wrote: > [...] > Your diff doesn't pass userland compiles. > You're adding a dependency on tree.h in proc.h. > > In kernel land on amd64, that's okay, since machine/param.h will pull > machine/cpu.h which pulls sys/sched.h which now pulls sys/tree.h, > > but it definitely doesn't fly in userland... my build crashed & burned > in libc... > > assuming that's okay (not usually a kernel guy), you can go include > sys/tree.h directly in proc.h... > [...] I think wrapping all the things that need sys/tree.h in #ifdef KERNEL should do the trick since they don't really make sense in userland anyway. > Please, please, please, don't vanish into the woods for the next 6 months. > [...] Since I now have way more space time on my hands than before, that should not be an issue anymore, don't worry :) > Try splitting up your diff and working them into pieces kernel hackers can > work with... > [...] I will. Actually, the diff is a bunch of seperate git commits on my machine, so that shouldn't be too hard to do. -- Gregor Best
Scheduler improvements, take 1001
(By popular request as a new thread). Hi people, I've tried splitting my scheduler patch into smaller fragments, and here's the result. I changed a few things people mentioned over the last few days, such as the following: 1) sys/proc.h now includes sys/tree.h, which should make libc builds work again. 2) deadline generation now takes process priorities into account, as suggested by ratchov@. The way it's done now, processes can use their sleep priority as a way to lower their nice value for short periods of time. I didn't notice any real changes, but I'd love to hear from people with more demanding applications. 3) schedstate_percpu is private to the kernel now, as I couldn't find a single occurrence of `struct schedstate_percpu` outside of /usr/src/sys and it seemed cleaner not to expose kernel data to userland in such a broad way. The patches will follow as single emails. -- Gregor Best
Re: Scheduler improvements, take 1001, Patch 1/5
diff --git a/kern/sched_bsd.c b/kern/sched_bsd.c index 172bb8f..c7121dc 100644 --- a/kern/sched_bsd.c +++ b/kern/sched_bsd.c @@ -77,12 +77,12 @@ scheduler_start(void) timeout_set(&schedcpu_to, schedcpu, &schedcpu_to); - rrticks_init = hz / 10; + rrticks_init = hz / 20; schedcpu(&schedcpu_to); } /* - * Force switch among equal priority processes every 100ms. + * Force switch among equal priority processes every 50ms. */ void roundrobin(struct cpu_info *ci) -- 1.7.6
Re: Scheduler improvements, take 1001, Patch 1/5
diff --git a/kern/kern_clock.c b/kern/kern_clock.c index 843965b..f598afc 100644 --- a/kern/kern_clock.c +++ b/kern/kern_clock.c @@ -233,7 +233,7 @@ hardclock(struct clockframe *frame) if (stathz == 0) statclock(frame); - if (--ci->ci_schedstate.spc_rrticks <= 0) + if (p && (--(p->p_rrticks) <= 0)) roundrobin(ci); /* diff --git a/kern/kern_proc.c b/kern/kern_proc.c index ad861c8..e0d5536 100644 --- a/kern/kern_proc.c +++ b/kern/kern_proc.c @@ -398,8 +398,6 @@ proc_printit(struct proc *p, const char *modif, int (*pr)(const char *, ...)) p->p_comm, p->p_pid, pst, p->p_flag, P_BITS); (*pr)("pri=%u, usrpri=%u, nice=%d\n", p->p_priority, p->p_usrpri, p->p_p->ps_nice); - (*pr)("forw=%p, list=%p,%p\n", - TAILQ_NEXT(p, p_runq), p->p_list.le_next, p->p_list.le_prev); (*pr)("process=%p user=%p, vmspace=%p\n", p->p_p, p->p_addr, p->p_vmspace); (*pr)("estcpu=%u, cpticks=%d, pctcpu=%u.%u, swtime=%u\n", diff --git a/kern/kern_sched.c b/kern/kern_sched.c index 253226a..79eb28c 100644 --- a/kern/kern_sched.c +++ b/kern/kern_sched.c @@ -24,11 +24,22 @@ #include #include #include +#include #include #include +static int +sched_cmp_proc(struct proc *a, struct proc *b) { + if (a == b) + return 0; + if (timercmp(&(a->p_deadline), &(b->p_deadline), <)) + return -1; + return 1; +} + +RB_GENERATE_STATIC(prochead, proc, p_runq, sched_cmp_proc); void sched_kthreads_create(void *); @@ -79,10 +90,8 @@ void sched_init_cpu(struct cpu_info *ci) { struct schedstate_percpu *spc = &ci->ci_schedstate; - int i; - for (i = 0; i < SCHED_NQS; i++) - TAILQ_INIT(&spc->spc_qs[i]); + RB_INIT(&spc->spc_runq); spc->spc_idleproc = NULL; @@ -158,18 +167,19 @@ sched_idle(void *v) cpuset_add(&sched_idle_cpus, ci); cpu_idle_enter(); - while (spc->spc_whichqs == 0) { + + while (curcpu_is_idle()) { if (spc->spc_schedflags & SPCF_SHOULDHALT && - (spc->spc_schedflags & SPCF_HALTED) == 0) { +(spc->spc_schedflags & SPCF_HALTED) == 0) { cpuset_del(&sched_idle_cpus, ci); SCHED_LOCK(s); - atomic_setbits_int(&spc->spc_schedflags, - spc->spc_whichqs ? 0 : SPCF_HALTED); + atomic_setbits_int(&spc->spc_schedflags, SPCF_HALTED); SCHED_UNLOCK(s); wakeup(spc); } cpu_idle_cycle(); } + cpu_idle_leave(); cpuset_del(&sched_idle_cpus, ci); } @@ -222,14 +232,13 @@ void setrunqueue(struct proc *p) { struct schedstate_percpu *spc; - int queue = p->p_priority >> 2; SCHED_ASSERT_LOCKED(); spc = &p->p_cpu->ci_schedstate; spc->spc_nrun++; - TAILQ_INSERT_TAIL(&spc->spc_qs[queue], p, p_runq); - spc->spc_whichqs |= (1 << queue); + KASSERT(!RB_FIND(prochead, &spc->spc_runq, p)); + RB_INSERT(prochead, &spc->spc_runq, p); cpuset_add(&sched_queued_cpus, p->p_cpu); if (cpuset_isset(&sched_idle_cpus, p->p_cpu)) @@ -240,38 +249,29 @@ void remrunqueue(struct proc *p) { struct schedstate_percpu *spc; - int queue = p->p_priority >> 2; SCHED_ASSERT_LOCKED(); spc = &p->p_cpu->ci_schedstate; spc->spc_nrun--; - TAILQ_REMOVE(&spc->spc_qs[queue], p, p_runq); - if (TAILQ_EMPTY(&spc->spc_qs[queue])) { - spc->spc_whichqs &= ~(1 << queue); - if (spc->spc_whichqs == 0) - cpuset_del(&sched_queued_cpus, p->p_cpu); - } + KASSERT(RB_REMOVE(prochead, &spc->spc_runq, p)); + if (RB_EMPTY(&spc->spc_runq)) + cpuset_del(&sched_queued_cpus, p->p_cpu); } struct proc * sched_chooseproc(void) { struct schedstate_percpu *spc = &curcpu()->ci_schedstate; - struct proc *p; - int queue; + struct proc *p, *p_tmp = NULL; SCHED_ASSERT_LOCKED(); if (spc->spc_schedflags & SPCF_SHOULDHALT) { - if (spc->spc_whichqs) { - for (queue = 0; queue < SCHED_NQS; queue++) { - TAILQ_FOREACH(p, &spc->spc_qs[queue], p_runq) { - remrunqueue(p); - p->p_cpu = sched_choosecpu(p); - setrunqueue(p); - } - } + RB_FOREACH_SAFE(p, prochead, &spc->spc_runq, p_tmp) { + remrunqueue(p);
Re: Scheduler improvements, take 1001, Patch 5/5
diff --git a/sys/sched.h b/sys/sched.h index fb01f21..1784ee2 100644 --- a/sys/sched.h +++ b/sys/sched.h @@ -69,8 +69,10 @@ #ifndef_SYS_SCHED_H_ #define_SYS_SCHED_H_ +#ifdef _KERNEL #include #include +#endif /* * Posix defines a which may want to include @@ -88,11 +90,9 @@ #define CP_IDLE4 #define CPUSTATES 5 -#defineSCHED_NQS 32 /* 32 run queues. */ - +#ifdef _KERNEL /* * Per-CPU scheduler state. - * XXX - expose to userland for now. */ struct schedstate_percpu { struct timeval spc_runtime; /* time curproc started running */ @@ -107,15 +107,13 @@ struct schedstate_percpu { u_int spc_nrun; /* procs on the run queues */ fixpt_t spc_ldavg; /* shortest load avg. for this cpu */ - RB_HEAD(prochead, proc) spc_runq; - #ifdef notyet struct proc *spc_reaper;/* dead proc reaper */ #endif LIST_HEAD(,proc) spc_deadproc; -}; -#ifdef _KERNEL + RB_HEAD(prochead, proc) spc_runq; +}; /* spc_flags */ #define SPCF_SEENRR 0x0001 /* process has seen roundrobin() */ -- 1.7.6
Re: Scheduler improvements, take 1001, Patch 4/5
diff --git a/arch/amd64/include/cpu.h b/arch/amd64/include/cpu.h index 12e48d6..99501a1 100644 --- a/arch/amd64/include/cpu.h +++ b/arch/amd64/include/cpu.h @@ -102,9 +102,11 @@ struct cpu_info { u_int32_t ci_cflushsz; u_int64_t ci_tsc_freq; +#define ARCH_HAVE_CPU_TOPOLOGY u_int32_t ci_smt_id; u_int32_t ci_core_id; u_int32_t ci_pkg_id; + struct cpu_functions *ci_func; void (*cpu_setup)(struct cpu_info *); void (*ci_info)(struct cpu_info *); diff --git a/kern/kern_sched.c b/kern/kern_sched.c index 79eb28c..072ef38 100644 --- a/kern/kern_sched.c +++ b/kern/kern_sched.c @@ -496,6 +496,10 @@ int sched_cost_load = 1; int sched_cost_priority = 1; int sched_cost_runnable = 3; int sched_cost_resident = 1; +#ifdef ARCH_HAVE_CPU_TOPOLOGY +int sched_cost_diffcore = 2; /* cost for moving to a different core */ +int sched_cost_diffpkg = 3; /* cost for moving to a different package */ +#endif int sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p) @@ -536,6 +540,13 @@ sched_proc_to_cpu_cost(struct cpu_info *ci, struct proc *p) cost -= l2resident * sched_cost_resident; } +#ifdef ARCH_HAVE_CPU_TOPOLOGY + if (p->p_cpu->ci_pkg_id != ci->ci_pkg_id) + cost *= sched_cost_diffpkg; + else if (p->p_cpu->ci_core_id != ci->ci_core_id) + cost *= sched_cost_diffcore; +#endif + return (cost); } -- 1.7.6
Re: Scheduler improvements, take 1001, Patch 3/5
diff --git a/arch/amd64/amd64/identcpu.c b/arch/amd64/amd64/identcpu.c index c597bb0..982c2bb 100644 --- a/arch/amd64/amd64/identcpu.c +++ b/arch/amd64/amd64/identcpu.c @@ -210,6 +210,8 @@ void (*setperf_setup)(struct cpu_info *); void via_nano_setup(struct cpu_info *ci); +void cpu_topology(struct cpu_info *ci); + void via_nano_setup(struct cpu_info *ci) { @@ -479,4 +481,123 @@ identifycpu(struct cpu_info *ci) sensordev_install(&ci->ci_sensordev); #endif } + + cpu_topology(ci); +} + +/* + * Base 2 logarithm of an int. returns 0 for 0 (yeye, I know). + */ +static int +log2(unsigned int i) +{ + int ret = 0; + + while (i >>= 1) + ret++; + + return (ret); +} + +static int +mask_width(u_int x) +{ + int bit; + int mask; + int powerof2; + + powerof2 = ((x - 1) & x) == 0; + mask = (x << (1 - powerof2)) - 1; + + /* fls */ + if (mask == 0) + return (0); + for (bit = 1; mask != 1; bit++) + mask = (unsigned int)mask >> 1; + + return (bit); +} + +/* + * Build up cpu topology for given cpu, must run on the core itself. + */ +void +cpu_topology(struct cpu_info *ci) +{ + u_int32_t eax, ebx, ecx, edx; + u_int32_t apicid, max_apicid, max_coreid; + u_int32_t smt_bits, core_bits, pkg_bits; + u_int32_t smt_mask, core_mask, pkg_mask; + + /* We need at least apicid at CPUID 1 */ + CPUID(0, eax, ebx, ecx, edx); + if (eax < 1) + goto no_topology; + + /* Initial apicid */ + CPUID(1, eax, ebx, ecx, edx); + apicid = (ebx >> 24) & 0xff; + + if (strcmp(cpu_vendor, "AuthenticAMD") == 0) { + /* We need at least apicid at CPUID 0x8008 */ + CPUID(0x8000, eax, ebx, ecx, edx); + if (eax < 0x8008) + goto no_topology; + + CPUID(0x8008, eax, ebx, ecx, edx); + core_bits = (ecx >> 12) & 0xf; + if (core_bits == 0) + goto no_topology; + /* So coreidsize 2 gives 3, 3 gives 7... */ + core_mask = (1 << core_bits) - 1; + /* Core id is the least significant considering mask */ + ci->ci_core_id = apicid & core_mask; + /* Pkg id is the upper remaining bits */ + ci->ci_pkg_id = apicid & ~core_mask; + ci->ci_pkg_id >>= core_bits; + } else if (strcmp(cpu_vendor, "GenuineIntel") == 0) { + /* We only support leaf 1/4 detection */ + CPUID(0, eax, ebx, ecx, edx); + if (eax < 4) + goto no_topology; + /* Get max_apicid */ + CPUID(1, eax, ebx, ecx, edx); + max_apicid = (ebx >> 16) & 0xff; + /* Get max_coreid */ + CPUID2(4, 0, eax, ebx, ecx, edx); + max_coreid = ((eax >> 26) & 0x3f) + 1; + /* SMT */ + smt_bits = mask_width(max_apicid / max_coreid); + smt_mask = (1 << smt_bits) - 1; + /* Core */ + core_bits = log2(max_coreid); + core_mask = (1 << (core_bits + smt_bits)) - 1; + core_mask ^= smt_mask; + /* Pkg */ + pkg_bits = core_bits + smt_bits; + pkg_mask = -1 << core_bits; + + ci->ci_smt_id = apicid & smt_mask; + ci->ci_core_id = (apicid & core_mask) >> smt_bits; + ci->ci_pkg_id = (apicid & pkg_mask) >> pkg_bits; + } else + goto no_topology; +#ifdef DEBUG + printf("cpu%d: smt %u, core %u, pkg %u " + "(apicid 0x%x, max_apicid 0x%x, max_coreid 0x%x, smt_bits 0x%x, smt_mask 0x%x, " + "core_bits 0x%x, core_mask 0x%x, pkg_bits 0x%x, pkg_mask 0x%x)\n", + ci->ci_cpuid, ci->ci_smt_id, ci->ci_core_id, ci->ci_pkg_id, + apicid, max_apicid, max_coreid, smt_bits, smt_mask, core_bits, + core_mask, pkg_bits, pkg_mask); +#else + printf("cpu%d: smt %u, core %u, package %u\n", ci->ci_cpuid, + ci->ci_smt_id, ci->ci_core_id, ci->ci_pkg_id); + +#endif + return; + /* We can't map, so consider ci_core_id as ci_cpuid */ +no_topology: + ci->ci_smt_id = 0; + ci->ci_core_id = ci->ci_cpuid; + ci->ci_pkg_id = 0; } diff --git a/arch/amd64/include/cpu.h b/arch/amd64/include/cpu.h index 9ce437a..12e48d6 100644 --- a/arch/amd64/include/cpu.h +++ b/arch/amd64/include/cpu.h @@ -102,6 +102,9 @@ struct cpu_info { u_int32_t ci_cflushsz; u_int64_t ci_tsc_freq; + u_int32_t ci_smt_id; + u_int32_t ci_core_id; + u_int32_t ci_pkg_id; struct cpu_functions *ci_func; void (*cpu_setup)(struct cpu_info *); void (*ci_info)(struct cpu_info *); diff --git a/arch/amd64/include/specialr
Re: Scheduler improvements, take 1001, Patch 1/5
As requested, I'll write down a few comments on each patch. So, here goes: This is the initial commit, it replaces the multiple FIFO queues that were used before with one RB-tree per CPU as a runqueue. The RB-tree is used because it offers operations such as min(), insert() and remove() in O(log n). I remove the NICE_WEIGHT define because it's meaningless with this patch, as there's only one runqueue. sys/proc.h now includes sys/tree.h, but that does not seem to be a problem when building the userland. Libc builds fine now for example. -- Gregor Best
Re: Scheduler improvements, take 1001, Patch 2/5
This patch simply halves the timeslice processes get until they are preempted. This patch is standalone and the rest of the patches does not depend on it, but I figured I'd throw it in anyway. -- Gregor Best
Re: Scheduler improvements, take 1001, Patch 3/5
This patch simply imports Christiano's code for detecting CPU topology, as posted on tech@ a while (more than two months) ago. I took it verbatim and didn't change anything yet. -- Gregor Best
Re: Scheduler improvements, take 1001, Patch 4/5
This patch uses the previous one to take CPU topology into account when calculating the cost of moving a process between CPUs. This is only done on amd64 at the moment, and the cost factors are guesses right now, but it's a start. -- Gregor Best
Re: Scheduler improvements, take 1001, Patch 5/5
This patch moves struct schedstate_percpu to kernel land, which I think is cleaner than exposing structures for scheduler state to userland, especially since grepping for 'schedstate' in /usr/src yielded no results outside of /usr/src/sys. I have not seen negative impact from this, but I haven't yet run a full userland build (it's running at the moment but the machine I'm building on is a bit slower than my laptop). -- Gregor Best
Re: Scheduler improvements, take 1001, Patch 2/5
On Sun, Oct 14, 2012 at 11:05:36AM +0200, David Coppa wrote: > On Tue, Oct 9, 2012 at 6:21 PM, Gregor Best wrote: > > This patch simply halves the timeslice processes get until they are > > preempted. This patch is standalone and the rest of the patches does not > > depend on it, but I figured I'd throw it in anyway. > > > > -- > > Gregor Best > > > > Didn't get this patch. Is it me or the patch is missing? > The patch was the message my mail was in reply to. There's no Patch 2/5 subject line because I forgot to change that after sending out Patch 1/5. -- Gregor Best
Re: WPA Enterprise on OpenBSD
I just rolled an update to the wpa_supplicant port that updates it to 2.0 and includes your patch. I'm trying it out right now but it seems to work flawlessly. Thanks a lot for the work :) -- Gregor Best
Re: WPA Enterprise on OpenBSD
On Mon, Jan 28, 2013 at 11:29:21AM +0100, Mark Kettenis wrote: > [...] > Looks like you and Gregor duplicated some effort. Anyway, this looks > fine with to me. I'll submit my diff upstream later today. > [...] That's okay, my diff to the port only contains a version bump to 2.0 and the WPA enterprise patch. I guess using Stuart's effort would be better. -- Gregor Best
Re: Fuse (and sshfs) support for OpenBSD
Hi, > [...] > I will spend the next days working on the NetBSD librefuse, I will try > to get it working with my kernel code and will come back here when I > have something that works. > [...] Are there any news on this? If you need a hand testing stuff and tracking down bugs, I'd be very happy to help. -- Gregor Best pgps3nCas5Iq2.pgp Description: PGP signature
Re: Somewhat important ACPI diff
On Tue, May 21, 2013 at 10:15:02AM +0400, Vadim Zhukov wrote: > [...] > ThinkPad X201i, fine here for an half a day (running since the time you > posted the diff). dmesg doesn't have any borked stuff, suspend/resume works > fine, both for short and long periods. > [...] Likewise with my Thinkpad R61i. -- Gregor Best