adding a syscall to openbsd
Hi all, I am trying to figure out how to add a syscall to openbsd 6.8. I am following "OpenBSD Kernel Internals - The Hitchhiker's Guide" by Vladimir Kirillov. (https://atmnis.com/~proger/openkyiv/openkyiv2009_proger_sys.pdf). I could successfully add my syscall and call it by using syscall(CALL_NR) from a basic C program. However, in that document it says that I should also rebuild libc. How do I do that? I tried by doing cd /usr/src/lib/libc and make but when I do make install I get an error: ran lib: /usr/lib/libc.a: no archive map to update. libc.a seems to be updated with the newest version, however libc.so.96.0 is still old. Thanks :-) Alessandro
Re: TouchPad, right clicking, and cwm
On Fri, Apr 16, 2021 at 12:08:56AM +0200, Ulf Brosziewski wrote: Could you remove the "ClickPad" option from the configuration file and try two-finger clicks again? The combination of that option with the "ClickFinger" mechanism is broken, and you probably don't need it if you don't use "soft-button areas". Thanks! That did the trick. Three-finger clicks should work - if your hardware detects the number of fingers reliably. Unfortunately, it doesn't, and right-clicking is more important than middle-clicking, so now my file looks like: Section "InputClass" Identifier "touchpad" Driver "synaptics" MatchIsTouchpad "on" Option "VertEdgeScroll" "off" Option "VertTwoFingerScroll" "on" Option "ClickFinger2" "3" Option "ClickFinger3" "2" EndSection If it's not practical to fix the bug with the "ClickPad" option, I would suggest adding a note to the synaptics(4) manpage under "ClickPad support", perhaps something along the lines of: The use of the option ClickPad in combination with Option ClickFinger2 and/or ClickFinger3 is currently not fully supported and may lead to unexpected behaviour. In particular, enabling the Option ClickPad may cause ClickFinger functionality to stop working.
Re: TouchPad, right clicking, and cwm
Unfortunately, that "trick" is no general solution because turning the "ClickPad" option off makes click-and-drag operations with two fingers impossible. If you don't use that "gesture", or perform it with one finger only, the setup might work for you. I think the issue won't be fixed, for various reasons: synaptics(4) is legacy, there is no active development. It cannot handle that setup coherently because a reasonable treatment of the "ClickFinger" method requires full multitouch data. Only a subset of our hardware drivers provide MT support, and even if these data are available, they aren't passed to userland drivers in OpenBSD. Only wsmouse(4) makes use of them, but it doesn't offer that "click method" for touchpads - hardly anyone has asked for it. On 4/16/21 6:56 PM, tetrahe...@danwin1210.me wrote: > On Fri, Apr 16, 2021 at 12:08:56AM +0200, Ulf Brosziewski wrote: >> Could you remove the "ClickPad" option from the configuration file and >> try two-finger clicks again? >> >> The combination of that option with the "ClickFinger" mechanism is broken, >> and you probably don't need it if you don't use "soft-button areas". > > Thanks! That did the trick. > >> Three-finger clicks should work - if your hardware detects the number of >> fingers reliably. > > Unfortunately, it doesn't, and right-clicking is more important than > middle-clicking, so now my file looks like: > > Section "InputClass" > Identifier "touchpad" > Driver "synaptics" > MatchIsTouchpad "on" > Option "VertEdgeScroll" "off" > Option "VertTwoFingerScroll" "on" > Option "ClickFinger2" "3" > Option "ClickFinger3" "2" > EndSection > > If it's not practical to fix the bug with the "ClickPad" option, I would > suggest adding a note to the synaptics(4) manpage under "ClickPad support", > perhaps something along the lines of: > > The use of the option ClickPad in combination with Option ClickFinger2 and/or > ClickFinger3 is currently not fully supported and may lead to unexpected > behaviour. In particular, enabling the Option ClickPad may cause ClickFinger > functionality to stop working.
Re: 6.9 #469 amd64 Thinkpad T495s (Ryzen) X sluggish
On Fri, Apr 16, 2021 at 02:03:49PM +0200, Marco Scholz wrote: > Bon jour misc! > I did a sysupgrade today and X/ mouse performance is really sluggish on > my Thinkpad T495s (AMD Ryzen). Running smooth now. No more problems here.
6.9 #469 amd64 Thinkpad T495s (Ryzen) X sluggish
Bon jour misc! I did a sysupgrade today and X/ mouse performance is really sluggish on my Thinkpad T495s (AMD Ryzen). dmesg below. Regards, Marco. OpenBSD 6.9 (GENERIC.MP) #464: Wed Apr 14 00:10:34 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6334730240 (6041MB) avail mem = 6127362048 (5843MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc025000 (63 entries) bios0: vendor LENOVO version "R13ET27W(1.01 )" date 04/18/2019 bios0: LENOVO 20QJ000AUS acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT MSDM SLIC BATB HPET APIC MCFG SBST WSMT VFCT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI acpi0: wakeup devices GPP0(S3) GPP1(S3) GPP2(S3) GPP3(S3) GPP4(S3) L850(S3) GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.42 MHz, 17-18-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.06 MHz, 17-18-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: disabling user TSC (skew=-2611984169) cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.06 MHz, 17-18-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: disabling user TSC (skew=-2611984116) cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.06 MHz, 17-18-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu3: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu3: disabling user TSC (skew=-2611984147) cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx, 2096.06 MHz, 17-18-01 cpu4:
Re: Another potential awk or xargs bug?
On Fri, Apr 16, 2021 at 02:26:27AM -0700, Jordan Geoghegan wrote:
>
>
> On 4/15/21 7:49 AM, Otto Moerbeek wrote:
> > On Thu, Apr 15, 2021 at 04:29:17PM +0200, Christian Weisgerber wrote:
> >
> >> Jordan Geoghegan:
> >>
> >>> --- /tmp/bad.txt Wed Apr 14 21:06:51 2021
> >>> +++ /tmp/good.txt Wed Apr 14 21:06:41 2021
> >> I'll note that no characters have been lost between the two files.
> >> Only the order is different.
> >>
> >>> The only thing that changed between these runs was me using either xargs
> >>> -P 1 or -P 2.
> >> What do you expect? You run two processes in parallel that write
> >> to the same file. Obviously their output will be interspersed in
> >> unpredictable order.
> >>
> >> You seem to imagine that awk's output is line-buffered. But when
> >> it writes to a pipe or file, its output is block-buffered. This
> >> is default stdio behavior. Output is written in block-size increments
> >> (16 kB in practice) without regard to lines. So, yes, you can end
> >> up with a fragment from a line written by process #1, followed by
> >> lines from process #2, followed by the remainder of the line from
> >> #1, etc.
> >>
> >> --
> >> Christian "naddy" Weisgerber na...@mips.inka.de
> >>
> > Right, a fflush() call after the printf makes the issue go away, but
> > only since awk is being nice and issues a single write call for that
> > single printf. Since awk afaik does not give such a guarantee, it is
> > better to have each parallel invocation write to a separate file and
> > then cat them together after all the awk runs are done.
> >
> > -Otto
>
> Hello Christian and Otto,
>
> Thank you for setting me straight. The block vs line buffering issue should
> have been obvious to me. What got me confused was that this solution worked
> well, for a long time - until it didn't. One would assume that it would
> consistently mangle output...
Buffering issues depend on the (size of) the data being written. I
think it is pretty consistent: if the bugs appears it always does in
the same way.
>
> While fflush does seem to fix the issue, I wanted to explore your suggestion
> Otto of writing to a temporary file from within awk.
>
> Is something like the following a sane approach to safely generating
> temporary files from within awk?:
>
> BEGIN{ cmd = "mktemp -q /tmp/workdir/tmp.XXX" ; if( ( cmd | getline
> result ) > 0 ) TMPFILE = result ; else exit 1 }
>
> Unless I'm missing something obvious, It seems there is no way to capture
> both the stdout and return code of an external command from within awk. My
> workaround solution to error check the call to mktemp here is to abort if
> mktemp returns no data. Is this sane?
>
> Regards,
>
> Jordan
I think that would work, but maybe it is nicer to wrap the code in a
shell script that generates tmp file names, passes the names to awk
and then do the catting of the result files in the shell script? To
run the cat command you need to know the names of the files anayway.
-Otto
Re: Another potential awk or xargs bug?
On 4/15/21 7:49 AM, Otto Moerbeek wrote:
> On Thu, Apr 15, 2021 at 04:29:17PM +0200, Christian Weisgerber wrote:
>
>> Jordan Geoghegan:
>>
>>> --- /tmp/bad.txt Wed Apr 14 21:06:51 2021
>>> +++ /tmp/good.txt Wed Apr 14 21:06:41 2021
>> I'll note that no characters have been lost between the two files.
>> Only the order is different.
>>
>>> The only thing that changed between these runs was me using either xargs -P
>>> 1 or -P 2.
>> What do you expect? You run two processes in parallel that write
>> to the same file. Obviously their output will be interspersed in
>> unpredictable order.
>>
>> You seem to imagine that awk's output is line-buffered. But when
>> it writes to a pipe or file, its output is block-buffered. This
>> is default stdio behavior. Output is written in block-size increments
>> (16 kB in practice) without regard to lines. So, yes, you can end
>> up with a fragment from a line written by process #1, followed by
>> lines from process #2, followed by the remainder of the line from
>> #1, etc.
>>
>> --
>> Christian "naddy" Weisgerber na...@mips.inka.de
>>
> Right, a fflush() call after the printf makes the issue go away, but
> only since awk is being nice and issues a single write call for that
> single printf. Since awk afaik does not give such a guarantee, it is
> better to have each parallel invocation write to a separate file and
> then cat them together after all the awk runs are done.
>
> -Otto
Hello Christian and Otto,
Thank you for setting me straight. The block vs line buffering issue should
have been obvious to me. What got me confused was that this solution worked
well, for a long time - until it didn't. One would assume that it would
consistently mangle output...
While fflush does seem to fix the issue, I wanted to explore your suggestion
Otto of writing to a temporary file from within awk.
Is something like the following a sane approach to safely generating temporary
files from within awk?:
BEGIN{ cmd = "mktemp -q /tmp/workdir/tmp.XXX" ; if( ( cmd | getline result
) > 0 ) TMPFILE = result ; else exit 1 }
Unless I'm missing something obvious, It seems there is no way to capture both
the stdout and return code of an external command from within awk. My
workaround solution to error check the call to mktemp here is to abort if
mktemp returns no data. Is this sane?
Regards,
Jordan
