ATI Radeon drm just works
Hi, my PC with ATI Radeon HD 6450 rev 0x00 graphic card works just fine. Thanks for your work, developpers! Kenji
Re: 6.4-release tset(1) really slow, what have I missed?
On 2018-12-02 22:12, Adam Thompson wrote: > I'm unsure if my test is valid, but I switched to i8254 (confirmed successful > via sysctl), and tset(1) continues to pause for an unnaturally long time. > But then I rebooted and re-tested the same sysctl vaules, and this time > tset(1) took 1sec, as expected. WTF... > > Well, putting that into sysctl.conf seems to be a reasonable workaround for > now. I also enabled timestepwarnings, and they are occurring, although I > don't yet know how often. I understand why I got inconsistent results... I had two different hosts open in the two windows I was using. Thank goodness they were both just personal systems! I'll re-test tomorrow morning when I'm more awake! -Adam
Re: 6.4-release tset(1) really slow, what have I missed?
On 2018-12-02 20:50, Philip Guenther wrote:
> On Sun, Dec 2, 2018 at 2:15 PM Adam Thompson wrote:
>
>> I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
>> one thing there that's different from everywhere else I've used 6.4.
>>
>> tset(1) takes approximately 12-15 seconds to execute, (almost) every
>> time.
>>
>> On a DigitalOcean VPS running 6.3-STABLE (via openup) tset sensibly
>> takes about 1 or 2 seconds:
>> athom...@mail.athompso.net:~$ time tset -s
>> TERM=xterm;
>> 0m01.01s real 0m00.00s user 0m00.01s system
>> athom...@mail.athompso.net:~$ uname -r
>> 6.3
>>
>> On the OVH VPS running 6.4-STABLE (via openup), the same command takes
>> 15 seconds:
>> athom...@mail2.athompso.net:~$ time tset -s
>> TERM=xterm;
>> 0m15.19s real 0m00.00s user 0m00.01s system
>> athom...@mail2.athompso.net:~$ uname -r
>> 6.4
>>
>> That's from two SSH sessions from the same client with the same
>> parameters.
>>
>> I've captured ktrace(1) output, which shows tset(1) doing, well,
>> nothing:
>> ...
>> 57429/443422 tset 0.035908 CALL
>> kbind(0x7f7f7678,24,0xecf2201fc1aab9ca)
>> 57429/443422 tset 0.035933 RET kbind 0
>> 57429/443422 tset 0.035950 CALL
>> nanosleep(0x7f7f7760,0x7f7f7750)
>> 57429/443422 tset 0.035967 STRU struct timespec { 1 }
>> 57429/443422 tset 15.809238 STRU struct timespec { 0 }
>> 57429/443422 tset 15.809272 RET nanosleep 0
>> 57429/443422 tset 15.809303 CALL
>> kbind(0x7f7f76c8,24,0xecf2201fc1aab9ca)
>> 57429/443422 tset 15.809380 RET kbind 0
>> ...
>>
>> I don't think this is a bug in 6.4, it's clearly environment-specific...
>> but I have no idea what on earth could be causing it.
>
> It requested a sleep of 1 second and 15 seconds passed. That's a kernel
> timetracking issue, so the output of "sysctl kern.timecounter" would be a
> good place to start. Is this is an MP kernel using the CPU TSC, but on a VM
> where the virtual CPU's TSCs aren't in sync?
>
> Philip Guenther
Thanks for the pointer! I noticed, once, that the system clock was way
off, but I assumed that was one of the boots where I didn't have
networking at startup so ntpd(8) -s failed to operate as expected. Bad
kernel timekeeping would also produce that result, though.
Anyway:
athom...@mail2.athompso.net:~$ sysctl kern.timecounter
kern.timecounter.tick=1
kern.timecounter.timestepwarnings=0
kern.timecounter.hardware=acpitimer
kern.timecounter.choice=i8254(0) acpitimer0(1000) dummy(-100)
and it's an SP kernel running on one vCPU. No way of knowing what's
happening under the hood, other than that it's OpenStack Nova, which
IIRC means KVM virtualization. Note the lack of advertised TSC support.
I'm unsure if my test is valid, but I switched to i8254 (confirmed
successful via sysctl), and tset(1) continues to pause for an
unnaturally long time. But then I rebooted and re-tested the same
sysctl vaules, and this time tset(1) took 1sec, as expected. WTF...
Well, putting that into sysctl.conf seems to be a reasonable workaround
for now. I also enabled timestepwarnings, and they are occurring,
although I don't yet know how often.
Is this likely to be a big enough problem that I should ditch this VPS
platform for now?
dmesg output, to verify SP kernel with no TSC:
OpenBSD 6.4 (GENERIC) #1: Mon Nov 26 09:32:17 CET 2018
r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 4177379328 (3983MB)
avail mem = 4041621504 (3854MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf6890 (10 entries)
bios0: vendor SeaBIOS version "2:1.10.2-58953eb7" date 04/01/2014
bios0: OpenStack Foundation OpenStack Nova
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel Core Processor (Haswell, no TSX, IBRS), 2394.81 MHz,
06-3c-01
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,ARAT,XSAVEOPT,MELTDOWN
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
...etc...
Thanks,
-Adam
Re: statethreads crashes in ld on 6.4
On Sun, Dec 2, 2018 at 7:51 PM Edgar Pettijohn wrote: > Sorry just saw it came with some examples. Testing with the `lookupdns' > program > ended with a Bus error (core dumped). Here is gdb output: > > Core was generated by `lookupdns'. > Program terminated with signal SIGBUS, Bus error. > #0 _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99 > 99 1: movq%r11,0(%rsp) > (gdb) bt > #0 _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99 > Backtrace stopped: Cannot access memory at address 0xb044815db732800f > Crashing on _longjmp() would suggest it's not happy with OpenBSD's setjmp/longjmp XOR cookies, but those have been in for a while. If statethreads were working for Claus with 6.3 then he's hitting something different. Philip
Re: statethreads crashes in ld on 6.4
Sorry just saw it came with some examples. Testing with the `lookupdns' program ended with a Bus error (core dumped). Here is gdb output: Core was generated by `lookupdns'. Program terminated with signal SIGBUS, Bus error. #0 _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99 99 1: movq%r11,0(%rsp) (gdb) bt #0 _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99 Backtrace stopped: Cannot access memory at address 0xb044815db732800f
Re: statethreads crashes in ld on 6.4
I downloaded state threads from sourceforge and had to make the following change to get it to build. I didn't test further than just compiling though. Not sure what you would need to change to get your `autotools' makefiles to work. --- ./st-1.9/Makefile Thu Oct 1 17:55:03 2009 +++ MakefileSun Dec 2 21:35:22 2018 @@ -200,6 +200,7 @@ SFLAGS = -fPIC LDFLAGS = -shared -soname=$(SONAME) -lc OTHER_FLAGS = -Wall +LD = gcc -rdynamic -Wl,-rpath ifeq ($(shell test -f /usr/include/sys/event.h && echo yes), yes) DEFINES += -DMD_HAVE_KQUEUE endif
Re: 6.4-release tset(1) really slow, what have I missed?
On Sun, Dec 2, 2018 at 2:15 PM Adam Thompson wrote:
> I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
> one thing there that's different from everywhere else I've used 6.4.
>
> tset(1) takes approximately 12-15 seconds to execute, (almost) every
> time.
>
> On a DigitalOcean VPS running 6.3-STABLE (via openup) tset sensibly
> takes about 1 or 2 seconds:
>athom...@mail.athompso.net:~$ time tset -s
>TERM=xterm;
>0m01.01s real 0m00.00s user 0m00.01s system
>athom...@mail.athompso.net:~$ uname -r
>6.3
>
> On the OVH VPS running 6.4-STABLE (via openup), the same command takes
> 15 seconds:
>athom...@mail2.athompso.net:~$ time tset -s
>TERM=xterm;
>0m15.19s real 0m00.00s user 0m00.01s system
>athom...@mail2.athompso.net:~$ uname -r
>6.4
>
>
> That's from two SSH sessions from the same client with the same
> parameters.
>
> I've captured ktrace(1) output, which shows tset(1) doing, well,
> nothing:
> ...
> 57429/443422 tset 0.035908 CALL
> kbind(0x7f7f7678,24,0xecf2201fc1aab9ca)
> 57429/443422 tset 0.035933 RET kbind 0
> 57429/443422 tset 0.035950 CALL
> nanosleep(0x7f7f7760,0x7f7f7750)
> 57429/443422 tset 0.035967 STRU struct timespec { 1 }
> 57429/443422 tset 15.809238 STRU struct timespec { 0 }
> 57429/443422 tset 15.809272 RET nanosleep 0
> 57429/443422 tset 15.809303 CALL
> kbind(0x7f7f76c8,24,0xecf2201fc1aab9ca)
> 57429/443422 tset 15.809380 RET kbind 0
> ...
>
> I don't think this is a bug in 6.4, it's clearly environment-specific...
> but I have no idea what on earth could be causing it.
>
It requested a sleep of 1 second and 15 seconds passed. That's a kernel
timetracking issue, so the output of "sysctl kern.timecounter" would be a
good place to start. Is this is an MP kernel using the CPU TSC, but on a
VM where the virtual CPU's TSCs aren't in sync?
Philip Guenther
Re: statethreads crashes in ld on 6.4
On Sat, Dec 1, 2018 at 6:34 AM Claus Assmann wrote: > statethreads (http://state-threads.sourceforge.net/) crashes on > OpenBSD 6.4/amd64 (release) with an error in ld (see below); it > works fine on previous OpenBSD versions. Do I have to set some > "special" cc/ld options to make this work? That'll depend on what the problem turns out to be, of course... > Or are patches to > statehreads required (there doesn't seem to be a port for it, > otherwise I would try that)? > Not that I know of. > #0 0x0c0b0980db08 in _dl_bind (object=0xc0a85cff400, index=) >from /usr/libexec/ld.so > (gdb) > Since ld.so is relinked on each boot, just an address doesn't really show what died. The disassembly up to that address would help. More important is knowing what signal killed the process. ktracing it and seeing what the syscalls leading up to signal were (and what extra info was in the signal) tells a lot. Philip Guenther
6.4-release tset(1) really slow, what have I missed?
I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
one thing there that's different from everywhere else I've used 6.4.
tset(1) takes approximately 12-15 seconds to execute, (almost) every
time.
On a DigitalOcean VPS running 6.3-STABLE (via openup) tset sensibly
takes about 1 or 2 seconds:
athom...@mail.athompso.net:~$ time tset -s
TERM=xterm;
0m01.01s real 0m00.00s user 0m00.01s system
athom...@mail.athompso.net:~$ uname -r
6.3
On the OVH VPS running 6.4-STABLE (via openup), the same command takes
15 seconds:
athom...@mail2.athompso.net:~$ time tset -s
TERM=xterm;
0m15.19s real 0m00.00s user 0m00.01s system
athom...@mail2.athompso.net:~$ uname -r
6.4
That's from two SSH sessions from the same client with the same
parameters.
I've captured ktrace(1) output, which shows tset(1) doing, well,
nothing:
...
57429/443422 tset 0.035908 CALL
kbind(0x7f7f7678,24,0xecf2201fc1aab9ca)
57429/443422 tset 0.035933 RET kbind 0
57429/443422 tset 0.035950 CALL
nanosleep(0x7f7f7760,0x7f7f7750)
57429/443422 tset 0.035967 STRU struct timespec { 1 }
57429/443422 tset 15.809238 STRU struct timespec { 0 }
57429/443422 tset 15.809272 RET nanosleep 0
57429/443422 tset 15.809303 CALL
kbind(0x7f7f76c8,24,0xecf2201fc1aab9ca)
57429/443422 tset 15.809380 RET kbind 0
...
I don't think this is a bug in 6.4, it's clearly environment-specific...
but I have no idea what on earth could be causing it.
(dmesg, etc. omitted in this first message, since it's so ridiculously
specific.)
Oh, and to make it even weirder, it doesn't ALWAYS happen. It ran
quickly twice earlier today, but never again.
Normally I'd say "it's DNS", and I thought it was due to the slow login
times, but ktrace(1) says otherwise.
Any ideas?
Thanks,
-Adam
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
вс, 2 дек. 2018 г. в 22:59, stephane l1 : > > does the conflicts come because I have already installed the package Qt5.9.6 > (so release version) ? Regarding conflicts - yes, you'll need to use "pkg_add -r" (replace mode) to install alternative (FLAVORed) version of package. This is documented in ports(7), packages(7) and pkg_add(1). Regarding "not signed", you can set TRUSTED_PKG_PATH before running pkg_add, or add -Dunsigned. Using "make install" in port directory does this for you, but it won't use "pkg_add -r", though. -- WBR, Vadim Zhukov
Fwd: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
does the conflicts come because I have already installed the package Qt5.9.6 (so release version) ?
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
Hi thanks Vadim I have made it this afternoon,qtbase seems to be built,with FLAVOR=debug (I See a qtbasexx.tgz in /usr/ports/packages/amd64/all) but it fails on installation of the module (I have tryed too a pkg_add of .tgz but it says it is not signed) Le dim. 2 déc. 2018 à 20:51, Vadim Zhukov a écrit : > вс, 2 дек. 2018 г. в 16:31, stephane l1 : > > > > Hi, > > Shall I make FLAVOR=debug make in each Makefile of the modules of Qt in > the port ? > > Basically, yes. You can play with shell, of course, to run those in a > single command, though. > > Please note that debug FLAVOR isn't linked to bulk builds, so it _may_ > fail due to some unexpected condition on your system that differs from > mine. And make sure you have enough room for building... And I really, > really do not recommend doing it on HDD, only on SSD. :) > > >> > >> ok thanks I will try to compile from the ports too.. > >> Yes it was just a Qt problem in qversiontagging.h. > >> ok it would be more simple to use the ports thanks > >> > >> Le dim. 2 déc. 2018 à 14:02, Vadim Zhukov a écrit > : > >>> > >>> Well, I was talking about compiling from ports. > >>> > >>> If you try to compile Qt from sources on your own you're, well, on > >>> your own. find /usr/ports/x11/qt5 -name '*.patch' should give you a > >>> clue how much on your own you are. :) > >>> вс, 2 дек. 2018 г. в 15:03, stephane l1 : > >>> > > >>> > Hi, > >>> > > >>> > I have tryed with FLAVOR = debug make in the .pro and I have still > this error : > >>> > > >>> > /usr/bin/ld: libQt5Core.so.5.9.6: undefined versioned symbol name > qt_version_tag@Qt_5.8 > >>> > /usr/bin/ld: failed to set dynamic section sizes: Bad value > >>> > clang++: error: linker command failed with exit code 1 (use -v to > see invocation) > >>> > > >>> > > >>> > Le dim. 2 déc. 2018 à 12:14, Vadim Zhukov a > écrit : > >>> >> > >>> >> You'd better use "FLAVOR=debug make" inside x11/qt5 directory to > build > >>> >> components you're interested in. > >>> >> вс, 2 дек. 2018 г. в 03:06, stephane l1 : > >>> >> > > >>> >> > Hi, > >>> >> > I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 > with the > >>> >> > mkspecs of the package release Qt5.9.6 and the platform > openbsd-clang but I > >>> >> > have linking error on the first lib libQt5Core on > version-tag@Qt_5_8 ? > >>> >> > Have I forgotten something to configure ? > >>> >> > > >>> >> > Thanks > >>> >> > best regards > >>> >> > > >>> >> > Stéphane L . from france > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> WBR, > >>> >> Vadim Zhukov > >>> > >>> > >>> > >>> -- > >>> WBR, > >>> Vadim Zhukov > > > > -- > WBR, > Vadim Zhukov >
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
вс, 2 дек. 2018 г. в 16:31, stephane l1 : > > Hi, > Shall I make FLAVOR=debug make in each Makefile of the modules of Qt in the > port ? Basically, yes. You can play with shell, of course, to run those in a single command, though. Please note that debug FLAVOR isn't linked to bulk builds, so it _may_ fail due to some unexpected condition on your system that differs from mine. And make sure you have enough room for building... And I really, really do not recommend doing it on HDD, only on SSD. :) >> >> ok thanks I will try to compile from the ports too.. >> Yes it was just a Qt problem in qversiontagging.h. >> ok it would be more simple to use the ports thanks >> >> Le dim. 2 déc. 2018 à 14:02, Vadim Zhukov a écrit : >>> >>> Well, I was talking about compiling from ports. >>> >>> If you try to compile Qt from sources on your own you're, well, on >>> your own. find /usr/ports/x11/qt5 -name '*.patch' should give you a >>> clue how much on your own you are. :) >>> вс, 2 дек. 2018 г. в 15:03, stephane l1 : >>> > >>> > Hi, >>> > >>> > I have tryed with FLAVOR = debug make in the .pro and I have still this >>> > error : >>> > >>> > /usr/bin/ld: libQt5Core.so.5.9.6: undefined versioned symbol name >>> > qt_version_tag@Qt_5.8 >>> > /usr/bin/ld: failed to set dynamic section sizes: Bad value >>> > clang++: error: linker command failed with exit code 1 (use -v to see >>> > invocation) >>> > >>> > >>> > Le dim. 2 déc. 2018 à 12:14, Vadim Zhukov a écrit : >>> >> >>> >> You'd better use "FLAVOR=debug make" inside x11/qt5 directory to build >>> >> components you're interested in. >>> >> вс, 2 дек. 2018 г. в 03:06, stephane l1 : >>> >> > >>> >> > Hi, >>> >> > I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 with >>> >> > the >>> >> > mkspecs of the package release Qt5.9.6 and the platform openbsd-clang >>> >> > but I >>> >> > have linking error on the first lib libQt5Core on version-tag@Qt_5_8 ? >>> >> > Have I forgotten something to configure ? >>> >> > >>> >> > Thanks >>> >> > best regards >>> >> > >>> >> > Stéphane L . from france >>> >> >>> >> >>> >> >>> >> -- >>> >> WBR, >>> >> Vadim Zhukov >>> >>> >>> >>> -- >>> WBR, >>> Vadim Zhukov -- WBR, Vadim Zhukov
iked : pf.conf rule for outgoing traffic
Hi, I need help to write a correct rule in pf.conf. I want : A -> B --> web The appearing IP of A is the B's one on the web. I managed to configure iked on A and B using default pubkeys according to Stuart Henderson advices. iked.conf on A : ikev2 active ipcomp esp \ from 192.168.100.0/16 to 0.0.0.0/0 \ peer "xx.xx.xx.xx" \ srcid "m...@moria.lan" \ dstid "B-hostname.tld" \ tag IKED iked.conf on B : ikev2 "warrior" passive esp \ from 0.0.0.0/0 to 0.0.0.0/0 \ local xx.xx.xx.xx peer any \ srcid "B-hostname.tld" \ tag IKED Auth works as expected : # iked -vvd ... sa_state: VALID -> ESTABLISHED from xx.xx.xx.xx:4500 to 192.168.100.122:4500 policy 'policy1' ... But I can't reach internet from A through B. Here is the pf.conf on B (at least a small part of it) pass out on egress \ from any to any tagged IKED \ nat-to (egress) I guess the issue is in my pf.conf. What do you think ? Any advice? Regards. -- thuban
Re: does 'xset(1) dpms 20' activate xidle(1) after 20sec?
Hello, alexan...@beard.se (Alexander Hall), 2018.11.28 (Wed) 23:24 (CET): > On Wed, Nov 28, 2018 at 10:56:13AM +0100, Marcus MERIGHI wrote: > > j...@openbsd.org (joshua stein), 2018.11.27 (Tue) 18:12 (CET): > > > On Tue, 27 Nov 2018 at 14:32:50 +0100, Marcus Merighi wrote: > > > > does 'xset(1) dpms 20' activate xidle(1) after 20 seconds? > > > > How to repeat: > > > > $ xset dpms 20 > > > > $ xidle -timeout 180 & > > > > With this I am locked out after 20 seconds, not 180. > > > > > > The DPMS event activates the X screensaver which generates an X > > > event that xidle is listening for. xidle then runs its specified > > > program (or defaults to xlock). > > > > Thanks for confirming and the explanation of the cause! > > > > I know you are having piles of experience with OpenBSD on all sorts of > > fancy hardware... what do you do for dimming the display and locking? > > This is what I use to give myself a three second grace period between the > screen going blank and the lock kicking in. The scroll lock led was for > fun and cosmetics. > $ egrep '^xidle|^xlock' .Xresources > xidle.*.timeout: 300 > xidle.*.delay: 9 > xlock.*.lockdelay: 3 > xlock.*.startCmd: xset dpms 3; sleep 3; xset led named "Scroll Lock" > xlock.*.endCmd: xset -dpms; xset -led named "Scroll Lock" > I start xidle in my ~.xsession especially "startCmd" with "xset dpms" was a precious hint! xlock(1) always woke up my DPMS dimmed display, and it remained lit. Not anymore, thank you! But I had to return to xautolock(1), since xidle(1) does not play well with my "xset dpms 20", as stated in the Subject:. I dug through the code of xidle(1), but see no way of telling if it is "xset dpms" running or the XScreenSaver(3) doing its thing. But I found the reason why some DEBUG printf()s did not show up, below. Thanks! Marcus Index: xidle.c === RCS file: /cvs/xenocara/app/xidle/xidle.c,v retrieving revision 1.6 diff -u -p -u -r1.6 xidle.c --- xidle.c 6 Sep 2018 07:21:34 - 1.6 +++ xidle.c 29 Nov 2018 11:10:03 - @@ -366,7 +366,9 @@ main(int argc, char **argv) if (fd < 0) err(1, _PATH_DEVNULL); dup2(fd, STDIN_FILENO); +#ifndef DEBUG dup2(fd, STDOUT_FILENO); +#endif dup2(fd, STDERR_FILENO); if (fd > 2) close(fd);
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
Hi, Shall I make FLAVOR=debug make in each Makefile of the modules of Qt in the port ? Le dim. 2 déc. 2018 à 14:20, stephane l1 a écrit : > ok thanks I will try to compile from the ports too.. > Yes it was just a Qt problem in qversiontagging.h. > ok it would be more simple to use the ports thanks > > Le dim. 2 déc. 2018 à 14:02, Vadim Zhukov a écrit : > >> Well, I was talking about compiling from ports. >> >> If you try to compile Qt from sources on your own you're, well, on >> your own. find /usr/ports/x11/qt5 -name '*.patch' should give you a >> clue how much on your own you are. :) >> вс, 2 дек. 2018 г. в 15:03, stephane l1 : >> > >> > Hi, >> > >> > I have tryed with FLAVOR = debug make in the .pro and I have still this >> error : >> > >> > /usr/bin/ld: libQt5Core.so.5.9.6: undefined versioned symbol name >> qt_version_tag@Qt_5.8 >> > /usr/bin/ld: failed to set dynamic section sizes: Bad value >> > clang++: error: linker command failed with exit code 1 (use -v to see >> invocation) >> > >> > >> > Le dim. 2 déc. 2018 à 12:14, Vadim Zhukov a écrit >> : >> >> >> >> You'd better use "FLAVOR=debug make" inside x11/qt5 directory to build >> >> components you're interested in. >> >> вс, 2 дек. 2018 г. в 03:06, stephane l1 : >> >> > >> >> > Hi, >> >> > I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 >> with the >> >> > mkspecs of the package release Qt5.9.6 and the platform >> openbsd-clang but I >> >> > have linking error on the first lib libQt5Core on version-tag@Qt_5_8 >> ? >> >> > Have I forgotten something to configure ? >> >> > >> >> > Thanks >> >> > best regards >> >> > >> >> > Stéphane L . from france >> >> >> >> >> >> >> >> -- >> >> WBR, >> >> Vadim Zhukov >> >> >> >> -- >> WBR, >> Vadim Zhukov >> >
Re: Key-based FDE /w UEFI fails => SUCCESS
Am 02.12.18 um 13:26 schrieb Stefan Wollny: > Am 30.11.18 um 16:38 schrieb Joel Sing: >> On Thursday 29 November 2018 20:38:23 Stefan Wollny wrote: [ ..] > SUCCESS! > > With this boot params the system came up as expected. > > THANK YOU once again for caring and your precious time! Much appreciated. > > Let me know if I shall do some tests prior to taking the machine to > production. > > Best, > STEFAN > Just an additional note: After having successfully reinstalled from by backup rebooting again required to set 'boot sr0a:/bsd'. Maybe this is somehow related to this https://marc.info/?l=openbsd-misc=154341622617488=2 and/or this https://marc.info/?l=openbsd-misc=154332857825943=2 ???
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
ok thanks I will try to compile from the ports too.. Yes it was just a Qt problem in qversiontagging.h. ok it would be more simple to use the ports thanks Le dim. 2 déc. 2018 à 14:02, Vadim Zhukov a écrit : > Well, I was talking about compiling from ports. > > If you try to compile Qt from sources on your own you're, well, on > your own. find /usr/ports/x11/qt5 -name '*.patch' should give you a > clue how much on your own you are. :) > вс, 2 дек. 2018 г. в 15:03, stephane l1 : > > > > Hi, > > > > I have tryed with FLAVOR = debug make in the .pro and I have still this > error : > > > > /usr/bin/ld: libQt5Core.so.5.9.6: undefined versioned symbol name > qt_version_tag@Qt_5.8 > > /usr/bin/ld: failed to set dynamic section sizes: Bad value > > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) > > > > > > Le dim. 2 déc. 2018 à 12:14, Vadim Zhukov a écrit : > >> > >> You'd better use "FLAVOR=debug make" inside x11/qt5 directory to build > >> components you're interested in. > >> вс, 2 дек. 2018 г. в 03:06, stephane l1 : > >> > > >> > Hi, > >> > I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 > with the > >> > mkspecs of the package release Qt5.9.6 and the platform openbsd-clang > but I > >> > have linking error on the first lib libQt5Core on version-tag@Qt_5_8 > ? > >> > Have I forgotten something to configure ? > >> > > >> > Thanks > >> > best regards > >> > > >> > Stéphane L . from france > >> > >> > >> > >> -- > >> WBR, > >> Vadim Zhukov > > > > -- > WBR, > Vadim Zhukov >
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
Well, I was talking about compiling from ports. If you try to compile Qt from sources on your own you're, well, on your own. find /usr/ports/x11/qt5 -name '*.patch' should give you a clue how much on your own you are. :) вс, 2 дек. 2018 г. в 15:03, stephane l1 : > > Hi, > > I have tryed with FLAVOR = debug make in the .pro and I have still this error > : > > /usr/bin/ld: libQt5Core.so.5.9.6: undefined versioned symbol name > qt_version_tag@Qt_5.8 > /usr/bin/ld: failed to set dynamic section sizes: Bad value > clang++: error: linker command failed with exit code 1 (use -v to see > invocation) > > > Le dim. 2 déc. 2018 à 12:14, Vadim Zhukov a écrit : >> >> You'd better use "FLAVOR=debug make" inside x11/qt5 directory to build >> components you're interested in. >> вс, 2 дек. 2018 г. в 03:06, stephane l1 : >> > >> > Hi, >> > I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 with the >> > mkspecs of the package release Qt5.9.6 and the platform openbsd-clang but I >> > have linking error on the first lib libQt5Core on version-tag@Qt_5_8 ? >> > Have I forgotten something to configure ? >> > >> > Thanks >> > best regards >> > >> > Stéphane L . from france >> >> >> >> -- >> WBR, >> Vadim Zhukov -- WBR, Vadim Zhukov
Re: Key-based FDE /w UEFI fails => SUCCESS
Am 30.11.18 um 16:38 schrieb Joel Sing: > On Thursday 29 November 2018 20:38:23 Stefan Wollny wrote: >> Hi there! >> >> I need help / advice with a fresh install onto a Thinkpad T450s which I >> recently bought on eBay. >> >> The system starts with UEFI enabled and was running fine with a rather >> small SSD without FDE. dmesg from some recent posts may be found. >> >> I followed the steps as given in the FAQ >> (http://www.openbsd.org/faq/faq14.html#softraid) with a new, larger SSD >> and the key disk both initialized with >> 'fdisk -iy -g -b 960 sd0' (and '... sd2' for the key disk). >> >> On both disks I created a 'a'-partion with type RAID as zero'd the first >> blocks. >> >> softraid is activated with 'bioctl -c C -k sd2a -l sd0a softraid0'. >> >> The installation was without noticable deviation to a non-FDE installation. >> >> The layout is identical to an other FDE-secured laptop which starts with >> BIOS: >> sd0a / >> sd0b swap >> sd0d /tmp >> sd0e /var >> sd0f /usr >> sd0g /usr/local >> sd0h /home >> (As this is a 1TB-SSD each partition has lots of capacity...) >> >> Yet after rebooting the first time I get the following: >> >> probing: pc0 mem[352K 204K 3256M 4832M] >> disk: hd0 hd1 sr0* >> OpenBSD/amd64 BOOTS64 3.40 >> >> open(hd0a:/etc/boot.con f): Invalid argument >> boot> >> cannot open hd0a:/etc/random.seed: Invalid argument >> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument >> failed(22). will try /bsd >> boot> >> cannot open hd0a:/etc/random.seed: Invalid argument >> booting hd0a:/bsd: open hd0a:/bsd: Invalid argument >> failed(22). will try /bsd >> Turning timeout off. >> boot> >> >> At this point I am lost. Tried to google for any information that makes >> sense but only found very old posts (from 2011 and older) which didn't >> provide hints on how to proceed. >> >> Anybody with a clue? > > The 'sr0*' in the above output shows that the boot loader found the softraid > volume and believes that it is bootable. What should have happened is that > the > boot loader identified that the disk you booted from is part of the softraid > volume and switched to sr0 as the boot device - for some reason it did not > and > continued to try to boot from hd0 instead. > > You should be able to boot by manually specifying: > > boot sr0a:/bsd > > at the boot> prompt. > > If that works we'll have to track down the reason why the automatic switching > of the boot device failed (line 146 of sys/arch/amd64/stand/libsa/dev_i386.c > and the code that leads up to it). > SUCCESS! With this boot params the system came up as expected. THANK YOU once again for caring and your precious time! Much appreciated. Let me know if I shall do some tests prior to taking the machine to production. Best, STEFAN
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
Hi, I have tryed with FLAVOR = debug make in the .pro and I have still this error : /usr/bin/ld: libQt5Core.so.5.9.6: undefined versioned symbol name qt_version_tag@Qt_5.8 /usr/bin/ld: failed to set dynamic section sizes: Bad value clang++: error: linker command failed with exit code 1 (use -v to see invocation) Le dim. 2 déc. 2018 à 12:14, Vadim Zhukov a écrit : > You'd better use "FLAVOR=debug make" inside x11/qt5 directory to build > components you're interested in. > вс, 2 дек. 2018 г. в 03:06, stephane l1 : > > > > Hi, > > I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 with > the > > mkspecs of the package release Qt5.9.6 and the platform openbsd-clang > but I > > have linking error on the first lib libQt5Core on version-tag@Qt_5_8 ? > > Have I forgotten something to configure ? > > > > Thanks > > best regards > > > > Stéphane L . from france > > > > -- > WBR, > Vadim Zhukov >
Re: how to compile a debug version of Qt5.9.6 on OpenBSD 6.4 ?
You'd better use "FLAVOR=debug make" inside x11/qt5 directory to build components you're interested in. вс, 2 дек. 2018 г. в 03:06, stephane l1 : > > Hi, > I have tried to compile a debug version of Qt5.9.6 on OpenBSD 6.4 with the > mkspecs of the package release Qt5.9.6 and the platform openbsd-clang but I > have linking error on the first lib libQt5Core on version-tag@Qt_5_8 ? > Have I forgotten something to configure ? > > Thanks > best regards > > Stéphane L . from france -- WBR, Vadim Zhukov
Re: Qsynth midi latency not low enough... what to do?
On Sat, Dec 01, 2018 at 01:19:00PM -0600, Adam Thompson wrote: > PROBLEM STATEMENT: driving FluidSynth from a MIDI controller produces ~1/4sec > delay between keypress and sound. > [...] > Is sndio(4) suitable for real-time(-ish) performance? Or do I need > a (OS) platform that does ASIO or JACK? (I mostly play by ear so > I'm targeting <<0.1sec latency.) Yes, sndiod is usable (actually designed for) low-latency usage. You need to change the sndiod buffer size to whatever your system can handle (depends on CPU, audio interface). I'd recommend to set in /etc/rc.conf.local sndiod_flags=-z240 Let us know how it works. If it works, you could try -z120, that's what I use on my machines. -z240 sets the block size to 240 samples, at 48000Hz sample frequency, this corresponds to 48000Hz / 240 = 5ms block. The total end-to-end latency is typically 3 blocks, so I'd get 5ms * 3 = 15ms. FWIW, for music, you shouldn't exceed few tenths of ms of latency. > > Dmesg follows, just in case anyone spots anything useful in there… > > Hardware setup, broadly: > * Dell Latitude E6430 laptop > - booting in EFI mode to work around a weird bootloader bug > * onboard azalia(4) audio (for now) using onboard speakers (for now) > * Roland A500PRO MIDI controller, connected via USB > * M-audio Uno USB-MIDI, nothing connected to it yet > * No-name USB 5.1ch Audio DAC from Amazon, nothing connected to it yet > - (leaving the M-audio umidi and the "ABC" uaudio devices disconnected > makes no difference) > The "ABC" USB devices are unlikely to work with small blocks, but there are fixes comming soon (hopefully).
