Re: C11 visibility in libc++
> Date: Sat, 7 Dec 2019 14:24:14 +1100 > From: Jonathan Gray > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > While we don't have C11's quick_exit() we do have timespec_get() and > struct timespec/aligned_alloc(). ok kettenis@ > Index: include/__config > === > RCS file: /cvs/src/lib/libcxx/include/__config,v > retrieving revision 1.6 > diff -u -p -r1.6 __config > --- include/__config 17 Jun 2019 22:28:51 - 1.6 > +++ include/__config 7 Dec 2019 03:10:51 - > @@ -341,6 +341,9 @@ > # if defined(__FreeBSD__) > #define _LIBCPP_HAS_QUICK_EXIT > #define _LIBCPP_HAS_C11_FEATURES > +# elif defined(__OpenBSD__) > +#define _LIBCPP_HAS_TIMESPEC_GET > +#define _LIBCPP_HAS_C11_FEATURES > # elif defined(__Fuchsia__) > #define _LIBCPP_HAS_QUICK_EXIT > #define _LIBCPP_HAS_TIMESPEC_GET > >
Re: first part of output splitting in bgpctl
On Fri, Dec 06, 2019 at 05:46:52PM +0100, Claudio Jeker wrote:
> The output processing in bgpctl is not very extensible. And output flags
> like ssv have to hacked into the output in a bad way.
>
> This is the first bit of a much bigger shuffling action to make the output
> handling more extensible. For now this just moves the header and body
> generation into two functions (show and show_head). The generic response
> handling and the end messages are now handled a bit different. The rest of
> the code was not yet modified to keep the diff small.
>
> OK?
OK denis@
You can also remove show_rib_summary_head() I guess.
> --
> :wq Claudio
>
> Index: bgpctl.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpctl/bgpctl.c,v
> retrieving revision 1.247
> diff -u -p -r1.247 bgpctl.c
> --- bgpctl.c 27 Nov 2019 01:23:30 - 1.247
> +++ bgpctl.c 6 Dec 2019 16:38:54 -
> @@ -49,10 +49,11 @@ enum neighbor_views {
> #define EOL0(flag) ((flag & F_CTL_SSV) ? ';' : '\n')
>
> int main(int, char *[]);
> -char *fmt_peer(const char *, const struct bgpd_addr *, int, int);
> +int show(struct imsg *, struct parse_result *);
> +char *fmt_peer(const char *, const struct bgpd_addr *, int);
> void show_summary_head(void);
> -int show_summary_msg(struct imsg *, int);
> -int show_summary_terse_msg(struct imsg *, int);
> +int show_summary_msg(struct imsg *);
> +int show_summary_terse_msg(struct imsg *);
> int show_neighbor_terse(struct imsg *);
> int show_neighbor_msg(struct imsg *, enum neighbor_views);
> void print_neighbor_capa_mp(struct peer *);
> @@ -76,10 +77,9 @@ const char *print_origin(u_int8_t, int
> const char * print_ovs(u_int8_t, int);
> void print_flags(u_int8_t, int);
> int show_rib_summary_msg(struct imsg *);
> -int show_rib_detail_msg(struct imsg *, int, int);
> +int show_rib_detail_msg(struct imsg *, int);
> void show_rib_brief(struct ctl_show_rib *, u_char *, size_t);
> -void show_rib_detail(struct ctl_show_rib *, u_char *, size_t, int,
> - int);
> +void show_rib_detail(struct ctl_show_rib *, u_char *, size_t, int);
> void show_attr(void *, u_int16_t, int);
> void show_communities(u_char *, size_t, int);
> void show_community(u_char *, u_int16_t);
> @@ -88,7 +88,6 @@ void show_ext_community(u_char *, u_in
> int show_rib_memory_msg(struct imsg *);
> void send_filterset(struct imsgbuf *, struct filter_set_head *);
> const char *get_errstr(u_int8_t, u_int8_t);
> -int show_result(struct imsg *);
> void show_mrt_dump_neighbors(struct mrt_rib *, struct mrt_peer *,
> void *);
> void show_mrt_dump(struct mrt_rib *, struct mrt_peer *, void *);
> @@ -99,11 +98,14 @@ const char*msg_type(u_int8_t);
> void network_bulk(struct parse_result *);
> const char *print_auth_method(enum auth_method);
> int match_aspath(void *, u_int16_t, struct filter_as *);
> +void show_head(struct parse_result *);
> +void show_result(u_int);
>
> struct imsgbuf *ibuf;
> struct mrt_parser show_mrt = { show_mrt_dump, show_mrt_state, show_mrt_msg };
> struct mrt_parser net_mrt = { network_mrt_dump, NULL, NULL };
> int tableid;
> +int nodescr;
>
> __dead void
> usage(void)
> @@ -119,7 +121,7 @@ int
> main(int argc, char *argv[])
> {
> struct sockaddr_un sun;
> - int fd, n, done, ch, nodescr = 0, verbose = 0;
> + int fd, n, done, ch, verbose = 0;
> struct imsg imsg;
> struct network_confignet;
> struct parse_result *res;
> @@ -180,8 +182,8 @@ main(int argc, char *argv[])
> show_mrt.arg = &ribreq;
> if (res->flags & F_CTL_NEIGHBORS)
> show_mrt.dump = show_mrt_dump_neighbors;
> - else if (!(res->flags & F_CTL_DETAIL))
> - show_rib_summary_head();
> + else
> + show_head(res);
> mrt_parse(res->mrtfd, &show_mrt, 1);
> exit(0);
> default:
> @@ -218,7 +220,6 @@ main(int argc, char *argv[])
> case SHOW:
> case SHOW_SUMMARY:
> imsg_compose(ibuf, IMSG_CTL_SHOW_NEIGHBOR, 0, 0, -1, NULL, 0);
> - show_summary_head();
> break;
> case SHOW_SUMMARY_TERSE:
> imsg_compose(ibuf, IMSG_CTL_SHOW_TERSE, 0, 0, -1, NULL, 0);
> @@ -241,20 +242,16 @@ main(int argc, char *argv[])
> } else
> imsg_compose(ibuf, IMSG_CTL_KROUTE_ADDR, res->rtableid,
> 0, -1, &res->addr, sizeof(res->addr));
> - show_fib_head();
> break;
>
Re: vmm disk unavailable after forceful vm termination
On 2019-11-01 12:40, Mike Larkin wrote: > On Fri, Nov 01, 2019 at 09:20:58AM -0400, Johan Huldtgren wrote: > > hello, > > > > I have vmd running on -current, in it I have an Ubuntu vm (18.04.3 LTS), > > every now and then the Ubuntu vm will hang hard, console is dead, only > > option is to restart it. Now at that point a graceful restart won't > > work, 'vmctl stop n' will run and return but nothing will happen. So > > the only option is 'vmctl stop -f n', this will kill the vm. However > > after that the vm will disapear from the list of vms > > > > Before killing: > > > > $ vmctl status > > ID PID VCPUS MAXMEM CURMEM TTYOWNERSTATE NAME > > 2 71924 12.0G1.1G ttyp2johan running plex.vm > > 1 18308 18.0G6.5G ttyp0johan running monitor.vm > > 3 - 11.0G - -johan stopped > > amd64-ports.vm > > 4 - 1512M - -johan stopped > > i386-ports.vm > > > > After killing: > > > > $ vmctl stop -f 2 > > stopping vm: forced to terminate vm 2 > > > > $ vmctl status > > ID PID VCPUS MAXMEM CURMEM TTYOWNERSTATE NAME > > 1 18308 18.0G6.5G ttyp0johan running monitor.vm > > 3 - 11.0G - -johan stopped > > amd64-ports.vm > > 4 - 1512M - -johan stopped > > i386-ports.vm > > > > The vm is now gone, I can't just start it with 'vmctl start n', > > but it's defined in vm.conf so let's try starting it by name: > > > > $ vmctl start plex.vm > > vmctl: start vm command failed: Operation already in progress > > > > ok.. so let's restart vmd. > > > > $ doas rcctl stop vmd > > vmd(ok) > > $ doas rcctl start vmd > > vmd(ok) > > > > but it's not actually running. > > > > $ vmctl status > > vmctl: connect: /var/run/vmd.sock: Connection refused > > > > Let's try starting manually with debug > > > > $ doas vmd -d > > startup > > warning: macro 'sets' not used > > can't open disk /ftp/vm/plex.img: Resource temporarily unavailable > > failed to start vm plex.vm > > parent: configuration failed > > priv exiting, pid 9509 > > control exiting, pid 63731 > > vmm exiting, pid 28106 > > > > So it seems the disk image is now in some state which won't let it be read > > again? > > > > $ ls -al /ftp/vm/plex.img > > -rw--- 1 root wheel 32212254720 Nov 1 08:07 /ftp/vm/plex.img > > > > $ doas file /ftp/vm/plex.img > > /ftp/vm/plex.img: x86 boot sector; partition 1: ID=0x83, active, starthead > > 32, startsector 2048, 62910464 sectors > > > > At this point the only solution is rebooting the host running vmd. > > After that everything will work just fine again until the next time > > this happens. I don't know if this is known or a bug, googling and > > scanning through marc.info I couldn't find any reports. I don't know > > if this is relevant but when I restarted this vm yesterday (along with > > hanging hard it sometimes just dies and is reported as stopped). I see > > this in /var/log/daemon > > > > Oct 31 07:58:25 absu vmd[17613]: plex.vm: started vm 2 successfully, tty > > /dev/ttyp2 > > Oct 31 07:58:29 absu vmd[71924]: vcpu_process_com_data: guest reading com1 > > when not ready > > Oct 31 07:58:35 absu vmd[71924]: vioblk_notifyq: unsupported command 0x8 > > Oct 31 07:58:52 absu vmd[71924]: vcpu_process_com_data: guest reading com1 > > when not ready > > > > Full dmesg of the vmd host below, let me know if I can provide any further > > details. > > > > thanks, > > > > .jh > > > > Sometimes vmd gets really stuck like this and even vmctl stop -f won't stop > it and rcctl stop vmd also fails. You probably have a vmd spinning at 100%, > kill that one manually and it should free things up. > > I know about the problem, but have not had a chance to fix it yet. > > -ml Just for the archives, this happened again and just as you stated there was a vmd process still spinning at 100% from the forcefully killed vm. killing it let me just restart the vm again without any of the other steps. thanks, .jh > > > --- > > > > OpenBSD 6.6-current (GENERIC.MP) #407: Mon Oct 28 00:42:58 MDT 2019 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 137318658048 (130957MB) > > avail mem = 133144268800 (126976MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7db4c000 (134 entries) > > bios0: vendor American Megatrends Inc. version "3703" date 04/24/2018 > > bios0: ASUSTeK COMPUTER INC. Z10PE-D16 Series > > acpi0 at bios0: ACPI 5.0 > > acpi0: sleep states S0 S4 S5 > > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG EINJ UEFI HPET MSCT SLIT SRAT > > WDDT SSDT SPMI SSDT SSDT PRAD DMAR HEST BERT ERST > > acpi0: wakeup devices IP2P(S3) EHC1(S4) BR1A(S4) BR1B(S4) BR2A(S4) BR2B(S4) > > BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) BR3D(S4) RP0
Re: uvideo(4) stream buffer malloc
It turned out that the last diff didn't work out so well.
Depending on the resolution it could happen that uvideo just could
allocate enough memory for the buffers, but xhci didn't had enough
left to allocate the ring buffers.
What worked out best for me is to limit the max. buffers to 8.
I still can capture 1920x1080 (H.264) with constantly 30fps with
this.
If I don't hear back about any concerns in the next few days,
I would commit the following diff.
Index: uvideo.h
===
RCS file: /cvs/src/sys/dev/usb/uvideo.h,v
retrieving revision 1.59
diff -u -p -u -p -r1.59 uvideo.h
--- uvideo.h7 Aug 2019 11:14:16 - 1.59
+++ uvideo.h2 Dec 2019 06:43:53 -
@@ -455,7 +455,7 @@ struct uvideo_frame_buffer {
uint32_t fmt_flags;
};
-#define UVIDEO_MAX_BUFFERS 32
+#define UVIDEO_MAX_BUFFERS 8
struct uvideo_mmap {
SIMPLEQ_ENTRY(uvideo_mmap) q_frames;
uint8_t *buf;
On Sat, Nov 23, 2019 at 09:13:05AM +0100, Marcus Glocker wrote:
> Some video apps like ffmpeg are quite aggressive in requesting stream
> buffers from the driver. E.g. when I want to record 1920x1080 with
> ffmpeg and my Logitech Webcam C930e, ffmpeg will request 256 buffers
> via VIDIOC_REQBUFS which we will limit to 32 first, but still will end
> up in a ~132MB (!) malloc request - Which finally fails.
>
> Instead of just hard aborting in that case, the following diff will try
> to decrease the buffers by a quarter until we are low enough to malloc
> the memory.
>
> This makes 1920x1080 work for me finally with 8 buffers, which is still
> high enough IMO.
>
> OK?
>
>
> Index: uvideo.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
> retrieving revision 1.205
> diff -u -p -u -p -r1.205 uvideo.c
> --- uvideo.c 14 Oct 2019 09:20:48 - 1.205
> +++ uvideo.c 23 Nov 2019 07:49:09 -
> @@ -3294,12 +3294,15 @@ uvideo_reqbufs(void *v, struct v4l2_requ
> sc->sc_mmap_count = 0;
> return (EINVAL);
> }
> - buf_size_total = sc->sc_mmap_count * buf_size;
> - buf_size_total = round_page(buf_size_total); /* page align buffer */
> - sc->sc_mmap_buffer = malloc(buf_size_total, M_DEVBUF, M_NOWAIT);
> + while (sc->sc_mmap_count > 0) {
> + buf_size_total = round_page(sc->sc_mmap_count * buf_size);
> + sc->sc_mmap_buffer = malloc(buf_size_total, M_DEVBUF, M_NOWAIT);
> + if (sc->sc_mmap_buffer != NULL)
> + break;
> + sc->sc_mmap_count = sc->sc_mmap_count / 4;
> + }
> if (sc->sc_mmap_buffer == NULL) {
> printf("%s: can't allocate mmap buffer!\n", DEVNAME(sc));
> - sc->sc_mmap_count = 0;
> return (EINVAL);
> }
> sc->sc_mmap_buffer_size = buf_size_total;
>
