Weird file(1) behaviour with multiple matching tests
Hi all, I'm trying to understand how file(1) behaves, when there are multiple matches, but I'm not skilled enough to understand the source code and the man page describes a different behaviour than what I'm seeing. man file(1) says "The first test which succeeds causes the file type to be printed.", however, this does not seem to be true: $ cat ~/.magic 0 string foo foo file 0 string foorfoor file $ cat foo foor $ file foo foo: foor file $ vim ~/.magic && cat ~/.magic 0 string foorfoor file 0 string foo foo file $ file foo foo: foor file Have I misunderstood the definition of "The first test"? I assumed this meant "the test with the lowest line number". Is this the expected behaviour? It seems to me like others misunderstood this before me; for example: With the default magic-file (/etc/magic), I cannot get this line's message to be printed: 0 search/1#!/usr/bin/env\ lua Lua script text executable Instead this happens: $ cat foo $ file foo foo: a lua script text executable Which seems to be the result of this test: 0 string #!/usr/bin/env a >15 string >\0 %s script text executable Greetings, Richard Ulmer
Re: Issues with Teclast F7 Plus
On Fri, Dec 25, 2020 at 12:34:36AM -0500, James Hastings wrote:
> On 13 Dec 2020, 13:27:48 +, Joel Carnat wrote:
> > Hello,
> >
> > I just got a Teclast F7 Plus laptop and installed OpenBSD 6.8-current on
> > it. Most things works except apm and touchpad
> >
> > Using zzz or ZZZ, it seems suspend/hibernation start but are never
> > achieved. The backlight keyboard and power led are still on. On Linux,
> > keyboard goes black and power led slowly blinks.
> > Plus, there is no way to resume the laptop. I have to force a poweroff
> > using the power button.
> >
> > Regarding the touchpad, it doesn't work ; neither with wsmoused(8) nor
> > in Xorg. It seems to be identified and attached to pms0. Looking at a
> > Linux dmesg, it references I2C:
> > [5.462957] kernel: input: HTIX5288:00 0911:5288 Touchpad as
> > /devices/pci:00/:00:17.3/i2c_designware.7/i2c-8/i2c-HTIX5288:00/0018:0911:5288.0001/input/input11
> > So I guess OpenBSD should rather attach it to imt(4)?
>
>
> This diff should activate I2C touchpad on your laptop:
thanks, committed
>
> Index: dev/pci/dwiic_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 dwiic_pci.c
> --- dev/pci/dwiic_pci.c 7 Oct 2020 11:17:59 - 1.14
> +++ dev/pci/dwiic_pci.c 23 Dec 2020 00:02:50 -
> @@ -117,6 +117,14 @@ const struct pci_matchid dwiic_pci_ids[]
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_6 },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_7 },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_8 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_1 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_2 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_3 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_4 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_5 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_6 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_7 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_8 },
> };
>
> int
>
>
Re: Issues with Teclast F7 Plus
On Fri, 2020-12-25 at 00:34 -0500, James Hastings wrote:
> On 13 Dec 2020, 13:27:48 +, Joel Carnat wrote:
> > Hello,
> >
> > I just got a Teclast F7 Plus laptop and installed OpenBSD 6.8-
> > current on
> > it. Most things works except apm and touchpad
> >
> > Using zzz or ZZZ, it seems suspend/hibernation start but are never
> > achieved. The backlight keyboard and power led are still on. On
> > Linux,
> > keyboard goes black and power led slowly blinks.
> > Plus, there is no way to resume the laptop. I have to force a
> > poweroff
> > using the power button.
> >
> > Regarding the touchpad, it doesn't work ; neither with wsmoused(8)
> > nor
> > in Xorg. It seems to be identified and attached to pms0. Looking at
> > a
> > Linux dmesg, it references I2C:
> > [ 5.462957] kernel: input: HTIX5288:00 0911:5288 Touchpad as
> > /devices/pci:00/:00:17.3/i2c_designware.7/i2c-8/i2c-
> > HTIX5288:00/0018:0911:5288.0001/input/input11
> > So I guess OpenBSD should rather attach it to imt(4)?
>
>
> This diff should activate I2C touchpad on your laptop:
>
> Index: dev/pci/dwiic_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 dwiic_pci.c
> --- dev/pci/dwiic_pci.c 7 Oct 2020 11:17:59 - 1.14
> +++ dev/pci/dwiic_pci.c 23 Dec 2020 00:02:50 -
> @@ -117,6 +117,14 @@ const struct pci_matchid dwiic_pci_ids[]
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_6 },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_7 },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_APOLLOLAKE_I2C_8 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_1 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_2 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_3 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_4 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_5 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_6 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_7 },
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_8 },
> };
>
> int
>
Thanks a lot! It does activate the touchpad properly.
It seems multitouch does not work. But single tap and properties can be
managed via wsconsctl.
Not sure why but the patch didn't apply on my fresh copy of the
sources. Here's the diff applied to sources as of today.
I've also attached the new dmesg if of any interest.
OpenBSD 6.8-current (TECLAST) #0: Fri Dec 25 17:52:48 CET 2020
r...@teclast.tumfatig.lan:/usr/src/sys/arch/amd64/compile/TECLAST
real mem = 8385544192 (7997MB)
avail mem = 8116199424 (7740MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x79ce9000 (74 entries)
bios0: vendor American Megatrends Inc. version "S8K1_A1 tPAD 3.01" date
11/02/2020
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MSDM MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT
SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 DMAR WDAT WSMT
acpi0: wakeup devices LID0(S3) HDAS(S3) XHC_(S3) XDCI(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 4499.94 MHz, 06-7a-01
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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 4MB 64b/line 16-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 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (RP01)
acpiprt2 at acpi0: bus -1 (RP02)
acpiprt3 at acpi0: bus 1 (RP03)
acpiprt4 at acpi0: bus 2 (RP04)
acpiprt5 at acpi0: bus 3 (RP05)
acpiprt6 at acpi0: bus -1 (RP06)
acpiec0 at acpi0
acpi0: GPE 0x26 already enabled
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 serial
acpibtn0 at acpi0: LID0
"INT34C1" at acpi0 not configured
"NXP1001" at acpi0 not configured
"IMPJ0003" at acpi0 not configured
"HTIX5288" at acpi0 not
Re: Hardware Random Number Generators (RNG)
Hi, An interesting video for this: https://www.youtube.com/watch?v=gp_90-3R0pE I think OpenBSD gets entropy from many sources - thisn't very much documented as far as I could see - such as time between interrupts, application memory allocation. In general a multi-threaded environment run by a clock running interrupts provides a good entropy that way. There surely is much more that feeds into the entropy. You can have a look at getentropy() and arc4random(). Further it appears a simple usb device can't have that much entropy. Further arc4random polls out chunks of random to the various applications so as long as you're not running a constrained environment there's probably no issue (as long as you have several application threads running simultaneously). Notice the random seed is regenerated at boot and shutdown so as long you've run once a certain amount of time and rebooted the computer once, it's got to a state where random generator shouldn't predictable since it bootstraps the entropy for next startup at shut-down every time. Side note, for a server the source of entropy is plenty, network data are completely asynchronous so mixing them up with internal states probably make a very job. I'd like to be able to help reading from your device, I haven't done that before sorry. Jean-François Le 10/07/2020 à 00:21, ken.hendrick...@l3harris.com a écrit : I wrote: How do I use a hardware random number generator to continuously seed /dev/random with new truly random numbers? --- Theo de Raadt wrote: We consider these devices boring, because the kernel does a good enough job creating random. randomness only has a bootstrap problem. And these devices don't solve the bootstrap problem. I'm thinking of headless servers, where randomness can ONLY come from the network. There is no keyboard, no mouse, etc. I'm also thinking of first boot after install, when keys are generated. I think that is what you mean by the bootstrap problem. Thanks, Ken PS I'm also thinking of very old hardware, without RDRAND in the CPU. Not to mention that you can't necessarily trust RDRAND! CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.
