screenshot with maim: Invalid number of channels provided to image.
Hello, when I run the maim program to take a screenshot, I get an error: odin$ maim -s Sr90.png Failed to detect a compositor, OpenGL hardware-accelleration disabled... Maim encountered an error: Invalid number of channels provided to image. odin$ I do not get any picture. Can anybody help, please? Thanks Ruda
add -powersave to hostname.if
My thought was just to add the line -powersave in the file, just like I had added it to an iconfig commandline. Hostname.if man pages don't specify anything about it that I can see. Was my thought a stupid thought? Ken
Re: user directory and wheel group
On Fri, Jun 15, 2018 at 2:42 PM, Stuart Henderson wrote: > One thing to be aware of is the not-very-well-known restriction that one > user can be in a maximum of 16 groups. If memory serves, this limitation derives from an nfs limitation. -- andrew fabbro and...@fabbro.org
Re: Different sound sources interfere with each other
May be the system becomes ... too busy to serve these actions simultaneously? It seemed to me that any task which made decent use of computer resources was able to cause that behavior. 18.06.2018 18:22, Maxim Tarasov пишет: Hi, I was able to find another trigger for this sound glitch: dd if=/dev/zero of=/tmp/test bs=1m count=256 rm /tmp/test Sound sometimes interrupts in the middle of dd(1) call, and always interrupts at the time of rm(1) call on files larger than 200 Mb. It looks like in case of dd/rm not only sound is affected, but mouse cursor controlled by USB mouse also stops responding. unlink(2) call seem to take a long time: $ dd if=/dev/zero of=test bs=1m count=1024 && ktrace rm test && kdump -R | grep unlink 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 2.265 secs (473858546 bytes/sec) 24666 rm 0.01 CALL unlink(0x7f7bb91b) 24666 rm 0.431070 RET unlink 0 Can anybody provide any pointers on how to debug this further or suggestions on what the problem might be? -- С уважением, Родин Максим
xscreensaver on lumina (6.3) does not work well
hi all . xscreensaver on lumina (snapshots) works well , but xscreensaver on lumina (6.3) does not work well . namely i cannnot restore screen by moving mouse or typing keyboard . and urtwn0 and run0 by snapshots works well , but urtwn0 by 6.3 did not get address from wifi router . --- regards
Re: Weird timing with hw.smt=0
Benjamin Baier wrote: > Anybody seen this, too? Can't be twice as fast _without_ hypertreading. Why not? Our scheduler doesn't know how to use HT correctly. And soon when we all realize how broken HT is, we won't be able to use it correctly in the super-restricted way it can be used.
Weird timing with hw.smt=0
Anybody seen this, too? Can't be twice as fast _without_ hypertreading. Greetings Ben $ sysctl hw.smt hw.smt=1 $ time sha256 -tt& time sha256 -tt& time sha256 -tt& time sha256 -tt& [1] 50365 [2] 71708 [3] 79327 [4] 63724 SHA256 time trial. Processing 10 1-byte blocks...SHA256 time trial. Processing 10 1-byte blocks...SHA256 time trial. Processing 10 1-byte blocks...SHA256 time trial. Processing 10 1-byte blocks...$ Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 16.57 seconds Speed = 60350030.175015 bytes/second 0m16.68s real 0m16.57s user 0m00.01s system Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 16.61 seconds Speed = 60204695.966285 bytes/second 0m16.69s real 0m16.61s user 0m00.01s system Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 16.60 seconds Speed = 60240963.855422 bytes/second 0m16.71s real 0m16.60s user 0m00.00s system Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 16.66 seconds Speed = 60024009.603842 bytes/second 0m16.72s real 0m16.67s user 0m00.00s system [4] + Done time sha256 -tt [3] - Done time sha256 -tt [2] Done time sha256 -tt [1] Done time sha256 -tt $ sysctl hw.smt=0 hw.smt: 1 -> 0 $ time sha256 -tt& time sha256 -tt& time sha256 -tt& time sha256 -tt& [1] 41881 [2] 73097 [3] 58187 [4] 17276 SHA256 time trial. Processing 10 1-byte blocks...SHA256 time trial. Processing 10 1-byte blocks...SHA256 time trial. Processing 10 1-byte blocks...SHA256 time trial. Processing 10 1-byte blocks...$ Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 8.79 seconds Speed = 113765642.775882 bytes/second 0m17.05s real 0m08.79s user 0m00.00s system Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 8.73 seconds Speed = 114547537.227950 bytes/second 0m17.23s real 0m08.73s user 0m00.00s system Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 8.83 seconds Speed = 113250283.125708 bytes/second 0m17.61s real 0m08.83s user 0m00.00s system Digest = 3f7daf2b36997b6eb269f63176e09fee8f6daa13202d87e020da63d262c6a4ca Time = 8.77 seconds Speed = 114025085.518814 bytes/second 0m17.68s real 0m08.77s user 0m00.01s system [4] + Done time sha256 -tt [3] - Done time sha256 -tt [2] Done time sha256 -tt [1] Done time sha256 -tt OpenBSD 6.3-current (GENERIC.MP) #25: Sun Jun 17 08:13:18 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8451125248 (8059MB) avail mem = 8117284864 (7741MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (64 entries) bios0: vendor LENOVO version "8DET69WW (1.39 )" date 07/18/2013 bios0: LENOVO 4287CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.31 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.91 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,PC
Re: rtadvd bug ?
Be careful not to break dhcpv6-pd. I suspect the problem is actually in make_prefix() in config.c which unconditionally sets onlink and autoconf. I stared at this for some time but can't figure out how to fix this. RFC 4861 has this which I don't think rtadvd is implementing correctly: Prefix Information These options specify the prefixes that are on-link and/or are used for stateless address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on-link destinations for the links to which they attach. If complete information is lacking, a host with multiple interfaces may not be able to choose the correct outgoing interface when sending traffic to its neighbors. On Sun, Jun 17, 2018 at 10:57:57PM +0200, Sebastian Benoit wrote: > Hi, > > Denis Fondras(open...@ledeuns.net) on 2018.06.17 21:45:37 +0200: > > On Mon, Jun 11, 2018 at 10:13:36AM +0200, Bastien Durel wrote: > > > Because it's lower than RTP_CONNECTED and I don't know what it is. The > > > /* local address routes (must be the highest) */ comment makes me think > > > it MAY be 127.0.0.0/8 or ::1/128 (useless for rtadvd then), but it may > > > be related to interface addresses; I did not check in the kernel code > > > how this flag is set. (hence the question marks) > > > > > > > RTP_LOCAL are local addresses, they won't pass the test at L367 of rtadvd.c > > anyway. > > > > Here is a diff if you want to try : > > > > Index: if.c > > === > > RCS file: /cvs/src/usr.sbin/rtadvd/if.c,v > > retrieving revision 1.46 > > diff -u -p -r1.46 if.c > > --- if.c12 Aug 2017 07:38:26 - 1.46 > > +++ if.c17 Jun 2018 19:37:55 - > > @@ -285,6 +285,14 @@ get_ifm_flags(char *buf) > > return (ifm->ifm_flags); > > } > > > > +u_char > > +get_priority(char *buf) > > +{ > > + struct rt_msghdr *rtm = (struct rt_msghdr *)buf; > > + > > + return (rtm->rtm_priority); > > +} > > + > > int > > get_prefixlen(char *buf) > > { > > Index: if.h > > === > > RCS file: /cvs/src/usr.sbin/rtadvd/if.h,v > > retrieving revision 1.14 > > diff -u -p -r1.14 if.h > > --- if.h10 Aug 2017 19:07:14 - 1.14 > > +++ if.h17 Jun 2018 19:37:55 - > > @@ -45,6 +45,7 @@ struct in6_addr *get_addr(char *); > > int get_rtm_ifindex(char *); > > int get_ifm_ifindex(char *); > > int get_ifam_ifindex(char *); > > +u_char get_priority(char *); > > int get_ifm_flags(char *); > > int get_prefixlen(char *); > > int prefixlen(u_char *, u_char *); > > Index: rtadvd.c > > === > > RCS file: /cvs/src/usr.sbin/rtadvd/rtadvd.c,v > > retrieving revision 1.91 > > diff -u -p -r1.91 rtadvd.c > > --- rtadvd.c22 Aug 2017 01:44:09 - 1.91 > > +++ rtadvd.c17 Jun 2018 19:37:55 - > > @@ -309,7 +309,7 @@ rtsock_cb(int fd, short event, void *arg > > { > > int n, type, ifindex = 0, oldifflags, plen; > > char *rtm; > > - u_char ifname[IF_NAMESIZE]; > > + u_char ifname[IF_NAMESIZE], prio; > > struct prefix *prefix; > > struct rainfo *rai; > > struct in6_addr *addr; > > @@ -362,6 +362,11 @@ rtsock_cb(int fd, short event, void *arg > > > > addr = get_addr(rtm); > > plen = get_prefixlen(rtm); > > + prio = get_priority(rtm); > > + > > + if (!(prio & RTP_CONNECTED)) > > + break; > > + > > > you have to do check > > if (rtm->rtm_flags & RTF_CONNECTED) > > The priority of a connected route depends on the interface priority, > see ifconfig(8) on the priority option and wifi and carp interfaces have a > different default prio than other interfacs. So the prio is not an indicator > for the type of the route. > > /Benno > > > /* sanity check for plen */ > > /* as RFC2373, prefixlen is at least 4 */ > > if (plen < 4 || plen > 127) { > > > > -- > -- I'm not entirely sure you are real.
Re: /etc/services for MQTT protocol
On Sun, 17 Jun 2018 17:59:56 +0200, gro...@grompf.net wrote: > Hello, > > Here's a tiny diff i used during my MQTT exploration while coupling > some Dyson(tm) stuff with my openbsd homeserver. > > a203 1 > mqtt1883/tcp# MQTT protocol > a285 1 > secure-mqtt 8883/tcp# Secure MQTT https://marc.info/?l=openbsd-tech&m=151520867321072&w=2 and I think there was also another argument about the ports being added to the baddynamic sysctls but I can't find it. Cheers, Daniel
Re: Different sound sources interfere with each other
Hi, I was able to find another trigger for this sound glitch: dd if=/dev/zero of=/tmp/test bs=1m count=256 rm /tmp/test Sound sometimes interrupts in the middle of dd(1) call, and always interrupts at the time of rm(1) call on files larger than 200 Mb. It looks like in case of dd/rm not only sound is affected, but mouse cursor controlled by USB mouse also stops responding. unlink(2) call seem to take a long time: $ dd if=/dev/zero of=test bs=1m count=1024 && ktrace rm test && kdump -R | grep unlink 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 2.265 secs (473858546 bytes/sec) 24666 rm 0.01 CALL unlink(0x7f7bb91b) 24666 rm 0.431070 RET unlink 0 Can anybody provide any pointers on how to debug this further or suggestions on what the problem might be?
Re: The wireless card TL-WN725N version 3 works fine
Not to put too finer point on it but the FAQ asks you to send the dmesg output as plain text in the body of an email to @dmesg, with some comments in the subject. External links are not very helpful. -- Patrick Harper paia...@fastmail.com On Fri, 15 Jun 2018, at 07:33, Guillaume DUALÉ wrote: > Hello, > Yes no problem, here is my dmesg : https://pastebin.com/iB4X5T9M > Regards, > Guillaume. > > Le ven. 15 juin 2018 à 15:24, Stephane HUC "PengouinBSD" < > b...@stephane-huc.net> a écrit : > > > Please, add your dmesg as explain into FAQ: > > > > https://www.openbsd.org/faq/faq4.html#SendDmesg > > > > ;) > > > > Le 06/15/18 à 15:12, Guillaume DUALÉ a écrit : > > > Hello, > > > I just bought this card : TP-LINK TL-WN725N(EU) Ver:3.0 > > > And it works fine ! > > > > > > In the man of the used driver «urtwn» : http://man.openbsd.org/urtwn > > only > > > the version 2 is listed. > > > So you can add this new version in the list. > > > > > > If you want I do tests, I can, just ask. > > > > > > Regards, > > > Guillaume. > > > > > > > -- > > ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<< > > > > Stephane HUC as PengouinBSD or CIOTBSD > > b...@stephane-huc.net > > > >
Re: How to search for "hostap" in man pages.
On Sat, 16 Jun 2018 16:57:08 -0700 Andrew Hewus Fresh wrote: [...] > $ apropos any=Hostap [...] Thanks! This does the job indeed. Karel