Re: email attachments in firefox
Well I think if this would be the case maybe chromium should be in the core OS image not in ports or Firefox removed from ports, right? But I don't think is the case. Chromium might have better architecture regarding security, but for many privacy is as important as security or maybe even more if what we are defending from are very hard to exploit vulnerabilities, that would need to target an OS OpenBSD which is not that widespread. Chromium as far as I know in the past from people that analysed it's traffic was making async calls to google DNS. Not sure if is longer the case, but if it wasn't maybe a project like Iridium wouldn't exist. https://github.com/iridium-browser/tracker/wiki/Differences-between-Iridium-and-Chromium Regards, --- Oriol Demaria Systems Administrator 2FFED630C16E4FF8 On 24/08/2020 13:50, Mihai Popescu wrote: But sometimes, the file selection will offer the content of /tmp and you have no way of making it something else. Many times when Firefox jumped in discussions, it was said a clear statement: use Chromium. You are safer and supported. You choose something else, you are on your own <- multiple times said, again and again. signature.asc Description: OpenPGP digital signature
How did it happen?
I understand that root might be required to open privileged ports, but then how commands are run as root when you exploit opensmtpd vulnerability? In case someone hasn't seen patch right now your system. Regards. -- Oriol Demaria 0x58415679
Re: Desktop full text search
Recoll looks good. So I have found 70k files just in my work repos. I have been using find and grep -R. But obviously not enough. My mail is in maildir format and I use mu4e on emacs, it has all the email indexed and performing a search is pretty quick. Testing omindex and quest from xapian-omega seems to work and pretty fast to find stuff. Will have a look at the other options proposed. Thanks! --- Oriol Demaria 2FFED630C16E4FF8 On 19/09/2019 06:09, _...@thomaslevine.com wrote: Recoll is the best I have found. I porting recoll three years ago but never submitted it. It should be easier to port now, as my patches are supposedly upstreamed or otherwise made obselete. https://thomaslevine.com/scm/openbsd-configuration/dir?ci=c7b4651cb41d5d30=openbsd/usr/ports/mystuff/textproc/recoll https://www.freelists.org/post/recoll-user/OpenBSD-port,1 isearch and namazu are in ports. I like them even theory, but recoll supports more file formats.
Re: Desktop full text search
Something more general. Code is mostly puppet, perl, python, and some other stuff. And files like PDF, text, need to index them and find something quick from terminal. Might have a look at this, I see that we have it on ports: https://www.ibm.com/developerworks/library/os-xapianomega/ --- Oriol Demaria 2FFED630C16E4FF8 On 18/09/2019 17:45, Edgar Pettijohn wrote: On Sep 18, 2019 10:37 AM, Oriol Demaria wrote: So finding some code between large amounts of repos can be tricky. I don't use Gnome or KDE so I was wondering what do people use for this. Been looking at the ports and I see Xapian and others. Any advice on a nice setup? Regards, -- Oriol Demaria 2FFED630C16E4FF8 Not sure exactly what you need but cscope may be a candidate. http://cscope.sourceforge.net/
Desktop full text search
So finding some code between large amounts of repos can be tricky. I don't use Gnome or KDE so I was wondering what do people use for this. Been looking at the ports and I see Xapian and others. Any advice on a nice setup? Regards, -- Oriol Demaria 2FFED630C16E4FF8
Re: VM CPU usage with TSC timecounter
Running more tests, seems a bit random either with acpihpet0 or tsc, you are right. So please disregard, I have associated the wrong thing. Happens either with debian or the alpine, and either timecounter. Sometimes vm process maxes out, sometimes it's ok. Thanks! --- Oriol Demaria 2FFED630C16E4FF8 On 29/08/2019 22:53, Mike Larkin wrote: On Thu, Aug 29, 2019 at 10:29:40PM +0100, Oriol Demaria wrote: I have been following the patching of the TSC. So I don't have problems on the Ryzen now using TSC with the mouse and so on, but I have a problem with the vms. The CPU maxes out on the Ryzen 5 (on Intel is fine) when I run a vm (debian). But when I change the timecounter back to acpihpet0 and restart vmd, the CPU usage is normal again. Does anyone else has this problem? Regards. -- Oriol Demaria 2FFED630C16E4FF8 40400 _vmd 100 8195M 505M idle fsleep1:35 1.46% vmd Not here. That's an ubuntu19 vm on Ryzen 7. Does this happen all the time or is it random? We do have a longstanding well known bug where a VM can get stuck and spin to 100%, that's unrelated to TSC though. -ml
VM CPU usage with TSC timecounter
I have been following the patching of the TSC. So I don't have problems on the Ryzen now using TSC with the mouse and so on, but I have a problem with the vms. The CPU maxes out on the Ryzen 5 (on Intel is fine) when I run a vm (debian). But when I change the timecounter back to acpihpet0 and restart vmd, the CPU usage is normal again. Does anyone else has this problem? Regards. -- Oriol Demaria 2FFED630C16E4FF8
Re: AMDGPU in current issue
Been using since yesterday a custom kernel with amdgpu, on a Ryzen 5 PRO
2500U, as I saw many commits. For me now the display is now usable and
stable, still minor issues, so I can use the laptop with external
monitor.
In exchange I tried to hibernate, which was working with the UEFI vesa
driver, and seems that doesn't work (tried only once) and suspend still
not working.
I will keep using the amdgpu driver from now unless I see major issues,
because being able to use two screens is important.
Regards.
Jonathan Gray writes:
> On Fri, Aug 02, 2019 at 03:11:54AM -0500, Charlie Burnett wrote:
>> Hey-
>> I'd been messing around with the AMDGPU on current (which I'm aware is very
>> experimental) and had very few issues with it using a Vega 56 GPU. I
>> recently swapped to another Vega GPU (Radeon VII) and have issues with the
>> display not showing anything. Still boots fine, in that I can still enter
>> commands (i.e. reboot) so it has to be a display issue. I tried searching
>> for the diff where the firmware was added which I'm certain I saw (for Vega
>> 20) but can't seem to find it in the commit history. Anyone have a fix for
>> it, and if not, who should I talk to if I wanted to help get it working? I
>> saw most of the AMDGPU commits have been by @jonathangray if he would be
>> the best option.
>> Thanks!
>
> vega20 firmware was added when ports/sysutils/firmware/amdgpu was
> updated to 20190312.
>
> vega20 is marked as experimental in the version of drm we have, but we
> don't currently check the flag on probe like linux does.
>
> The following diff will prevent amdgpu from matching on devices
> in the amdgpu_pciidlist table with the AMD_EXP_HW_SUPPORT flag
> (currently these are all vega20 ids).
>
> Index: sys/dev/pci/drm/include/drm/drm_drv.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/include/drm/drm_drv.h,v
> retrieving revision 1.2
> diff -u -p -r1.2 drm_drv.h
> --- sys/dev/pci/drm/include/drm/drm_drv.h 25 Jul 2019 05:48:16 -
> 1.2
> +++ sys/dev/pci/drm/include/drm/drm_drv.h 2 Aug 2019 03:29:58 -
> @@ -291,5 +291,7 @@ static inline bool drm_drv_uses_atomic_m
> int drm_dev_register(struct drm_device *, unsigned long);
> void drm_dev_unregister(struct drm_device *);
> int drm_getpciinfo(struct drm_device *, void *, struct drm_file *);
> +const struct drm_pcidev *drm_find_description(int, int,
> +const struct drm_pcidev *);
>
> #endif
> Index: sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 amdgpu_kms.c
> --- sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 4 Jul 2019 03:39:07 -
> 1.3
> +++ sys/dev/pci/drm/amd/amdgpu/amdgpu_kms.c 2 Aug 2019 03:35:35 -
> @@ -1337,10 +1337,23 @@ int amdgpu_debugfs_firmware_init(struct
> int
> amdgpu_probe(struct device *parent, void *match, void *aux)
> {
> + struct pci_attach_args *pa = aux;
> + const struct drm_pcidev *id_entry;
> + unsigned long flags = 0;
> +
> if (amdgpu_fatal_error)
> return 0;
> - if (drm_pciprobe(aux, amdgpu_pciidlist))
> - return 20;
> +
> + id_entry = drm_find_description(PCI_VENDOR(pa->pa_id),
> + PCI_PRODUCT(pa->pa_id), amdgpu_pciidlist);
> + if (id_entry != NULL) {
> + flags = id_entry->driver_data;
> + if (flags & AMD_EXP_HW_SUPPORT)
> + return 0;
> + else
> + return 20;
> + }
> +
> return 0;
> }
>
--
Oriol Demaria
2FFED630C16E4FF8
Re: exFAT devices not detected
Working again with today's snapshot. Regards, --- Oriol Demaria 2FFED630C16E4FF8 On 31/05/2019 15:42, Oriol Demaria wrote: I tested this before, even I have some hotplugd script to mount this devices, but since some days ago exFAT formatted devices are not detected and won't even appear on dmesg. Does anyone seen this behaviour too? Thanks.
exFAT devices not detected
I tested this before, even I have some hotplugd script to mount this devices, but since some days ago exFAT formatted devices are not detected and won't even appear on dmesg. Does anyone seen this behaviour too? Thanks. -- Oriol Demaria 2FFED630C16E4FF8
Re: Lenovo w/ AMD Ryzen CPU
On 29/05/2019 01:52, Jonathan Gray wrote: If anyone wants to have a Ryzen thinkpad work in the short term the current A series A285/A485 and similar generation E series require less work. Suspend/resume doesn't work right on them currently. They mostly ship with RTL8822BE wireless which there is no support for but this can be replaced with an Intel 8265 which is in the bios whitelist and is supported by iwm(4). I don't think there is a whitelist at all on this system regarding wireless cards. It's a work laptop and is very common that we have to replace the wireless cards on laptops. We had a spare broadcom which won't work either on FOSS but it was detected and boots without problems while I was waiting for the AC 8265. Probably atheros cards would be other option, the Intel would cost now like 25€ online.
Re: amdgpu report on rx460
On 23/05/2019 18:26, Peter Piwowarski wrote: On Thu, 23 May 2019 12:32:05 +0100 Oriol Demaria wrote: I saw the commit yesterday, tried recompiling the kernel but the Vega 8 seems that was not detected. I have a question, does suspend work for you? Silly question, but are you sure you enabled the driver in kernel configuration? It's not switched on in GENERIC yet. Not silly question, it wasn't enabled. I compiled a kernel from today source with it and tested. Suspend/resume works with qualifications here. Without amdgpu (i.e. on GENERIC.MP, displaying with efifb) it never brings any displays up on resume (but otherwise seems to resume correctly). With amdgpu, two of the three display outputs are brought back up correctly, but one is not; the card has an HDMI, a DVI-D, and a DisplayPort output, with displays connected to all three, but the DisplayPort output seems to come back up in some invalid mode or other. Unfortunately all I know is that the monitor claims it's unhappy with the mode it's asked to display, since it doesn't say on-screen what the invalid parameters are. The first time I tried suspend/resume (in the amdgpu kernel) the machine did not resume at all, but I haven't been able to reproduce that. Hibernate doesn't work in the amdgpu kernel; I got a uvm_fault once, and a second time the machine went catatonic and wouldn't boot again (I had to remove its backup coin cell to clear it). Summarizing, hibernate works with framebuffer. Amdgpu driver detects additional screens but is unstable, the graphics card seems to hang occassionally and then you have to reboot. Real pity because it would make my life easier. Suspend doesn't work at all with either UEFI fb or amdgpu. Sent a bug report. Will try new kernel as I see some more commits that may fix issues. Thanks! Representative dmesg including a suspend/resume cycle, first from GENERIC.MP and then (after a warm reboot) from the amdgpu kernel (not very interesting, I think): OpenBSD 6.5-current (GENERIC.MP) #0: Wed May 22 00:24:09 EDT 2019 pe...@shoebox-kvm-openbsd-current.foo:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17111023616 (16318MB) avail mem = 16582344704 (15814MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe8980 (56 entries) bios0: vendor American Megatrends Inc. version "F25" date 01/16/2019 bios0: Gigabyte Technology Co., Ltd. AB350M-Gaming 3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG HPET SSDT UEFI IVRS SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) GPPF(S4) GP17(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2994.86 MHz, 17-01-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, 16MB 64b/line 16-way L3 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 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz, 17-01-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, 16MB 64b/line 16-way L3 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: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz, 17-01-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,SSE
Re: amdgpu report on rx460
I saw the commit yesterday, tried recompiling the kernel but the Vega 8 seems that was not detected. I have a question, does suspend work for you? --- Oriol Demaria 2FFED630C16E4FF8 On 23/05/2019 03:56, Peter Piwowarski wrote: I've tried the new amdgpu driver on my RX460 (4G VRAM), and it seems to work reasonably. KMS picks up the appropriate console resolution, and X appears to work. There is some strange behavior with xrandr when setting rotation on one of my displays (1920x1200->1200x1920) that I don't quite understand; its idea of the mouse pointer's position seems to be confused. Changing virtual desktop size by disabling displays outright doesn't seem to cause any problems. I can play with it more and report further if that information would be helpful. OpenGL seems to work, but not entirely correctly. I only had time today to test glxgears (fine) and 0ad (some obvious artifacts, and doesn't quite reach 60fps at 1920x1200 as it should be able to, presumably has something to do with the powerplay error visible in dmesg; images available on request. I also see display corruption in my xterms after exiting, which is resolved by restarting X). dmesg quickly fills up with stub messages upon starting X, but I assume that's known. :) If there's anything I can test on this hardware to assist development, I'm happy to do so. dmesg without X, post fw_update: OpenBSD 6.5-current (GENERIC.AMDGPU.MP) #0: Wed May 22 19:51:55 EDT 2019 pe...@shoebox-kvm-openbsd-current.foo:/usr/src/sys/arch/amd64/compile/GENERIC.AMDGPU.MP real mem = 17111023616 (16318MB) avail mem = 16579829760 (15811MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0xe8980 (56 entries) bios0: vendor American Megatrends Inc. version "F25" date 01/16/2019 bios0: Gigabyte Technology Co., Ltd. AB350M-Gaming 3 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG HPET SSDT UEFI IVRS SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) GPPF(S4) GP17(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 1700 Eight-Core Processor, 2994.87 MHz, 17-01-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, 16MB 64b/line 16-way L3 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 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz, 17-01-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, 16MB 64b/line 16-way L3 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: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 1700 Eight-Core Processor, 2994.38 MHz, 17-01-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, 16MB 64b/line 16-way L3 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: smt 0, co
Re: Thinkpad A285 mouse issues
Actually both things fix the issue. Seems to be better just changing the timecounter, rather than running on just one core. I noticed by the way that when I run sysupgrade, or upgrade as before the SP kernel is the one installed. And I have to change manually and reboot. Also I noticed that when I run dmesg both kernels output data. Can't recall if this was the usual behavior. So, are there any advise against running with acpihpet0 timecounter instead of tsc? I'm attaching my dmesg. timecounters: sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=acpihpet0 kern.timecounter.choice=i8254(0) tsc(2000) acpihpet0(1000) acpitimer0(1000) dummy(-100) Regards, --- Oriol Demaria 2FFED630C16E4FF8 On 10/05/2019 01:15, Jonathan Gray wrote: On Thu, May 09, 2019 at 04:17:40PM +0100, Oriol Demaria wrote: I have this laptop and I'm having issues with this laptop. Wireless has to be replaced and basically have to wait till the graphics card is properly supported, right now is running X with the UEFI framebuffer. So this issues are expected. But I'm having a very annoying bug on X. The mouse stops working, specially Firefox seems to be a problem, but other apps too (perhaps I notice more here as others I mainly use the keyboard). When I run xprop to try to figure out something I get the error "Can't grab the mouse" and won't run. Seems that some event holds the mouse, and prevents you from "clicking". Changed the touchpad to synaptics to see if it makes difference, seems to improve a bit, but still the problem comes back. The other mouse devices are using ws driver. Has someone got a workaround for this? Similar experience? Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0 Thanks in advance. Relevant part of the xorg log file: [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" (type: KEYBOARD, id 6) [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0 [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse touchpad" [ 18193.925] (II) LoadModule: "synaptics" [ 18193.927] (II) Loading /usr/X11R6/lib/modules/input/synaptics_drv.so [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation" [ 18193.929]compiled for 1.19.7, module version = 1.9.1 [ 18193.929]Module class: X.Org XInput Driver [ 18193.929]ABI class: X.Org XInput driver, version 24.1 [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0' [ 18193.929] (**) /dev/wsmouse0: always reports core events [ 18193.929] (**) Option "Device" "/dev/wsmouse0" [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676 resolution 45 [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760 resolution 69 [ 18194.832] (**) /dev/wsmouse0: always reports core events [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0" (type: TOUCHPAD, id 7) [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now constant deceleration 2.5 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now 1.75 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is now 0.035 [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4 [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse [ 18195.340] (II) LoadModule: "ws" [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so [ 18195.342] (II) Module ws: vendor="X.Org Foundation" [ 18195.342]compiled for 1.19.7, module version = 1.3.0 [ 18195.342]Module class: X.Org XInput Driver [ 18195.342]ABI class: X.Org XInput driver, version 24.1 [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse' [ 18195.343] (**) /dev/wsmouse: always reports core events [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0 [ 18195.343] (**) Option "Device" "/dev/wsmouse" [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7 [ 18195.343] (**) ws: /dev/wsmouse: associated screen: 0 [ 18195.372] (II) ws: /dev/wsmouse: minimum x position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum x position: 1919 [ 18195.372] (II) ws: /dev/wsmouse: minimum y position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum y position: 1079 [ 18195.372] (==) ws: /dev/wsmouse: Buttons: 7 [ 18195.404] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5 [ 18195.404] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type: MOUSE, id 8) [ 18195.436] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration profile 0 [ 18195.436] (**
Thinkpad A285 mouse issues
I have this laptop and I'm having issues with this laptop. Wireless has to be replaced and basically have to wait till the graphics card is properly supported, right now is running X with the UEFI framebuffer. So this issues are expected. But I'm having a very annoying bug on X. The mouse stops working, specially Firefox seems to be a problem, but other apps too (perhaps I notice more here as others I mainly use the keyboard). When I run xprop to try to figure out something I get the error "Can't grab the mouse" and won't run. Seems that some event holds the mouse, and prevents you from "clicking". Changed the touchpad to synaptics to see if it makes difference, seems to improve a bit, but still the problem comes back. The other mouse devices are using ws driver. Has someone got a workaround for this? Similar experience? Thanks in advance. Relevant part of the xorg log file: [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" (type: KEYBOARD, id 6) [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0 [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse touchpad" [ 18193.925] (II) LoadModule: "synaptics" [ 18193.927] (II) Loading /usr/X11R6/lib/modules/input/synaptics_drv.so [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation" [ 18193.929]compiled for 1.19.7, module version = 1.9.1 [ 18193.929]Module class: X.Org XInput Driver [ 18193.929]ABI class: X.Org XInput driver, version 24.1 [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0' [ 18193.929] (**) /dev/wsmouse0: always reports core events [ 18193.929] (**) Option "Device" "/dev/wsmouse0" [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676 resolution 45 [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760 resolution 69 [ 18194.832] (**) /dev/wsmouse0: always reports core events [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0" (type: TOUCHPAD, id 7) [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now constant deceleration 2.5 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now 1.75 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is now 0.035 [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4 [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse [ 18195.340] (II) LoadModule: "ws" [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so [ 18195.342] (II) Module ws: vendor="X.Org Foundation" [ 18195.342]compiled for 1.19.7, module version = 1.3.0 [ 18195.342]Module class: X.Org XInput Driver [ 18195.342]ABI class: X.Org XInput driver, version 24.1 [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse' [ 18195.343] (**) /dev/wsmouse: always reports core events [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0 [ 18195.343] (**) Option "Device" "/dev/wsmouse" [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7 [ 18195.343] (**) ws: /dev/wsmouse: associated screen: 0 [ 18195.372] (II) ws: /dev/wsmouse: minimum x position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum x position: 1919 [ 18195.372] (II) ws: /dev/wsmouse: minimum y position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum y position: 1079 [ 18195.372] (==) ws: /dev/wsmouse: Buttons: 7 [ 18195.404] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5 [ 18195.404] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type: MOUSE, id 8) [ 18195.436] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration profile 0 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration factor: 2.000 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration threshold: 4 wsconsctl | grep mouse mouse.type=synaptics mouse.rawmode=0 mouse.scale=1266,5676,1094,4760,0,45,69 mouse.tp.tapping=0 mouse.tp.scaling=0.160 mouse.tp.swapsides=0 mouse.tp.disable=0 mouse.tp.edges=0.0,5.0,10.0,5.0 mouse1.type=ps2 mouse2.type=usb -- Oriol Demaria 2FFED630C16E4FF8
Re: OpenBSD current & Firefox
So seems that going back to default configuration fixed for a bit ublock. But adding lists seems to break it (I really don't have time to debug this further). Trying now with umatrix instead and seems to work without any issues. Just in case someone has the same problem. Regards, --- Oriol Demaria 2FFED630C16E4FF8 On 04/12/2018 14:16, Oriol Demaria wrote: So over the weekend I noticed that Ublock Origin is not working for me anymore on firefox since the last upgrade. I have tried to debug with ktrace to figure out why. Checked the list, but found only someone having issues with pledge over some unusual configuration. Has anyone else had this problem? Any advice on debugging this issue? Thanks in advance.
OpenBSD current & Firefox
So over the weekend I noticed that Ublock Origin is not working for me anymore on firefox since the last upgrade. I have tried to debug with ktrace to figure out why. Checked the list, but found only someone having issues with pledge over some unusual configuration. Has anyone else had this problem? Any advice on debugging this issue? Thanks in advance. -- Oriol Demaria 2FFED630C16E4FF8
Re: Issue with numbers of pty
Yes, that was the issue. Thank you very much :) Stuart Henderson <s...@spacehopper.org> writes: > On 2016-06-30, Oriol Demaria <sysad...@the-grid.xyz> wrote: >> Trying tmuxinator here I have noticed that I ran out of pty, according >> to man pty(4) there is a kernel parameter specifiying the max >> number. I'm running a snapshot from last Friday, and I don't seem to >> have kern.tty.maxptys. > > You probably just ran out of device nodes, the default (62) is a bit small > for some uses (often exhibited as not being able to open new xterms), but you > can create more like this: > > cd /dev > sh MAKEDEV pty1 > > If you need even more, you can do pty2,...pty15, you get 62 for each number > (0 is /dev/ptyp[0-9a-zA-Z], 1 is ptyq*, etc). -- Oriol Demaria 0x58415679
Issue with numbers of pty
Trying tmuxinator here I have noticed that I ran out of pty, according to man pty(4) there is a kernel parameter specifiying the max number. I'm running a snapshot from last Friday, and I don't seem to have kern.tty.maxptys. Is this a documentation error? Or that setting is not the one to look for? Thanks in advance. -- Oriol Demaria 0x58415679
Re: GitLab on OpenBSD
I do run Gitlab on OpenBSD stable, so I'm still with 8.1, as further need go 1.5 and it's not there. Also I use PostgreSQL as DB. There are a few things that you need to do: * git home user directory in /var/www/git, as web server is chrooted * git user needs bash as shell * in the bundle operation in the --without statement add always as it won't compile if it's there. * comment out shell_path from the init script * put the correct path of the shell for scripts bin/web and bin/background_jobs If you have experience with web servers and so on you should be able to configure the rest. Regards, Stefan Kempf <sisnk...@gmail.com> writes: > Predrag Punosevac wrote: >> Hi Misc, >> >> A question for Ruby gurus among OpenBSD users. Is it possible to run >> GitLab on OpenBSD? I see some reports of people running GitLab on >> FreeBSD > > Not a ruby guru, but yes it can be done in principle. However, I just > gave it a quick try and don't use it in production though. > > You'll have to do the manual setup though. These are the instructions I > used: > > https://gitlab.com/gitlab-org/gitlab-ce/blob/8-1-stable/doc/install/installation.md > > All required packages should be in ports. For sidekiq, you might this > fix: > https://github.com/mperham/sidekiq/commit/a6ea55d16fb0060b8ee0a322bede1951cff51fba > > And you may need to tweak the syntax in the gitlab > lib/support/init.d/gitlab/gitlab shellscript (and the scripts is calls) > or change it to use bash. > >> https://github.com/gitlabhq/gitlab-recipes/blob/master/install/freebsd/freebsd-10.md >> >> >> Best, >> Predrag -- Oriol Demaria 0x58415679
Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/
I agree, but no one mentioned DANE, I think that's the future and the way to go. With DANE in theory you wouldn't need a CA. I think it's an excellent way to establish authenticity of your content. Problem is that no browser supports it by default, and DNSsec use is marginal. Regards, Giancarlo Razzolini writes: > Em 10-12-2015 20:03, Christian Weisgerber escreveu: >> The true elephant in the room is that I can't get the current OpenBSD >> source tree securely. (Well, _I_ can if push comes to shove, but >> the general user community can't.) CVSync? No integrity or >> authenticity. AnonCVS over SSH? Nope, no integrity or authenticity >> because the mirror itself got the tree over CVSync. Assuming you >> trust the mirror in the first place. > > I agree with you. We don't want TLS to hide the fact that we are > accessing the openbsd site. We want TLS to get a little extra confidence > that what we are seeing on our screen is what the OpenBSD devs wanted us > to see. Someone mentioned signify keys also. Nowadays if I want to be > (kind of) sure I got everything right, I need to download the files from > different mirrors, using different internet connections, using vpn's and > tor, etc. > > The TLS could be implemented on a non mandatory way, you don't need to > redirect HTTP connections to HTTPS ones. But it would be nice to have > the option, at least. > > Cheers, > Giancarlo Razzolini -- Oriol Demaria 0x58415679
Re: Why regen for host ssh key if fail first time?
The 16/01/2015 17:30, Dmitry Orlov wrote:
Hi :)
In last snapshot (ISO). All ssh* configs are default
OpenBSD 5.7-beta (GENERIC) #731: Fri Jan 16 01:37:07 MST 2015
Welcome to OpenBSD: The proactively secure Unix-like operating system.
Please use the sendbug(1) utility to report bugs in the system.
Before reporting a bug, please try to reproduce it with the latest
version of the code. With bug reports, please try to ensure that
enough information to reproduce the problem is enclosed, and if a
known fix for it exists, include that as well.
# rm -v /etc/ssh/*key*
rm: unknown option -- v
usage: rm [-dfiPRr] file ...
# rm /etc/ssh/*key*
# ls /etc/ssh/
ssh_config sshd_config
# ssh-keygen -A
ssh-keygen: generating new host keys: RSA1 write key failed
ssh-keygen: generating new host keys: RSA write key failed
ssh-keygen: generating new host keys: DSA write key failed
ssh-keygen: generating new host keys: ECDSA write key failed
ssh-keygen: generating new host keys: ED25519 write key failed
# ssh-keygen -A
#
I reproduced the error, it happens the same to me, but it actually
generates the keys, but you get that error. I did a trace. I'm rather
new in OpenBSD, looks like it could be related with mprotect(2), but not
sure. Maybe you should submit the bug:
2620 ssh-keygen CALL mprotect(0x5913d95f000,0x2000,0x3PROT_READ|PROT_WRITE)
2620 ssh-keygen RET mprotect 0
2620 ssh-keygen CALL mprotect(0x5913d95f000,0x2000,0x1PROT_READ)
2620 ssh-keygen RET mprotect 0
2620 ssh-keygen CALL sigprocmask(SIG_SETMASK,0)
2620 ssh-keygen RET sigprocmask ~0x10100SIGKILL|SIGSTOP
2620 ssh-keygen CALL fstat(3,0x7f7d2360)
2620 ssh-keygen STRU struct stat { dev=1104, ino=182877, mode=-rw-r- ,
nlink=1, uid=0root, gid=0wheel, rdev=0, atime=1421529614Jan 17
21:20:14 2015.111741058, mtime=1421529614Jan 17 21:20:14 2015.111741058,
ctime=1421529614Jan 17 21:20:14 2015.111741058, size=0, blocks=0,
blksize=16384, flags=0x0, gen=0xa991ad63 }
2620 ssh-keygen RET fstat 0
2620 ssh-keygen CALL
mmap(0,0x4000,0x3PROT_READ|PROT_WRITE,0x1002MAP_PRIVATE|MAP_ANON,-1,0)
2620 ssh-keygen RET mmap 6134226927616/0x5943c6ac000
2620 ssh-keygen CALL write(2,0x5913d737da1,0x11)
2620 ssh-keygen GIO fd 2 wrote 17 bytes
write key failed
2620 ssh-keygen RET write 17/0x11
2620 ssh-keygen CALL write(3,0x5943c6ac000,0x17c)
2620 ssh-keygen GIO fd 3 wrote 380 bytes
ssh-rsa ---DELETED---
2620 ssh-keygen RET write 380/0x17c
2620 ssh-keygen CALL close(3)
Regards,
--
Oriol Demaria
0x58415679
