Re: squid replacement
> On Oct 20, 2023, at 11:35, Lyndon Nerenberg (VE7TFX/VE6BBM) > wrote: > > Does anyone know of another HTTP proxy that supports squid-style > ACLs? That's a big part of why we chose it in the first place. We > restrict which hosts can connect to the proxy, and further restrict > which hosts they can connect to upstream. We don't need (or want) > caching -- just connection pass through. Just which hosts and ports? No caching? Kinda sounds like a pf.conf solution. . . Maybe with relay to relay everything through a firewall? Sean
Limiting RAM on boot to emulate low-memory situation
Is it possible to decrease amount of available RAM at boot time? I'm about to migrate some VPS system to a significantly cheaper option that comes with less RAM and I need to evaluate how existing system will behave. Sadly, I can't reconfigure RAM in VPS config. Cheers, Chris
Re: Crash on TOSHIBA PORTEGE Z30-A laptop
On Fri, Oct 20, 2023 at 1:23 PM wrote: > I've recently installed OpenBSD 7.4 on this laptop. > > However, I'm experiencing random crashes. These occur at various times, > including during kernel loading (before running /etc/rc), > > or later while I'm using the system. > > > I've included the contents of /var/run/dmesg.boot below and attached the > screens with the ddb output command. > ... > bios0: vendor TOSHIBA version "Version 4.30" date 04/26/2018 > The screenshots show that the fault happens during a wifi interrupt that catches the ACPI thread processing a very deeply nested AML code. I suspect it's actually running out of kernel stack space as a result. Everything below is based on that hypothesis. So, the first thing to try is to see if there's a BIOS update newer than the 2018 rev it currently has. They may have optimized the AML code, or at least made it less deeply nested. Another possibility is to see if there's a device you can disable that would result in that AML not being called. If there's anything that you aren't using then disable it in the BIOS and hope. The last possibility would be to build a kernel which allocates more pages per thread for its kernel stack by bumping the UPAGES #define in /usr/src/sys/arch/amd64/include/param.h and building a new kernel. It's really only the ACPI thread that needs this, but we don't currently have code to control that on a per-thread basis. Philip Guenther
squid replacement
We've been running squid on OpenBSD for years, but it seems these days that any time it tries to proxy a file > 1MB, it just dies. This makes it impossible to do thinks like mirror the OpenBSD distributions. Does anyone know of another HTTP proxy that supports squid-style ACLs? That's a big part of why we chose it in the first place. We restrict which hosts can connect to the proxy, and further restrict which hosts they can connect to upstream. We don't need (or want) caching -- just connection pass through. I've been looking for a while but haven't found anything with equivalent ACL support. Anybody out there have suggestions for a likely candidate? Thanks, --lyndon
kate no longer start after upgrade to 7.4
I just upgraded my OpenBSD 7.3 amd64 to 7.4. I used the usual procedure, the one in the upgrade FAQ. After the upgrade kate (KDE texteditor) no longer works! If I execute "kate -v" here it is the output: kate:/usr/X11R6/lib/libX11.so.17.1: /usr/X11R6/lib/libX11.so.18.0 : WARNING: symbol(_XkeyTable) size mismatch, relink your program Cannot mix incompatible Qt library (5.9.7) with this library (5.15.10) Abort trap (core dumped) I tried "pkg_add -u" more times and there is no error. The only warning was "Obsolete package: freetype-1.3.1p4 (no longer maintained upstream)", so I have done "pkg_delete freetype", but kate wasn't working before I deleted it too. pkg_check find no problem. What else I can do? Thanks
Re: job request
Hi, Magenta Octopus wrote on Thu, Oct 19, 2023 at 04:57:11PM +: > Someone give me a job because I like your project. Round here, the following are considered critical skills: 1. Being able to decide yourself what interests you. 2. Finding tasks that are worth doing. 3. Judging yourself whether your skills are sufficient to attempt working on any particular task you discover. 4. Reading code, listening to advice, and learning on the job. To help with item 2, watching the OpenBSD mailing lists makes sense because potential issues are often mentioned there. Using the system yourself also makes sense because you might discover issues that way. To save management overhead, OpenBSD does not maintain a global bugtracker. TODO lists only exists for a few sub-projects, for example https://portroach.openbsd.org/ https://cvsweb.bsd.lv/mandoc/TODO and there may be a few more. Be aware that picking entries from any TODO list makes it even more important to get the items 2 and 3 above right. Starting with small bugfixes in code and/or documentation is usually a good idea. Java ports also exist for OpenBSD, but unless i'm quite mistaken, those ports are rather complicated beasts; i certainly don't know anything about them. Good luck and have fun, Ingo
Re: PineView not using the whole screen
Crystal Kolipe wrote: > https://marc.info/?l=openbsd-tech=162922414816784 Thanks for this one, Crystal: I just solved changing keyboard. Indeed I had two usb keyboards with me and I passed from a Dell KB113T to a Dell KB212B this latter is running correctly using only one keyboard device. The difference between the two keyboards is just the sleep button of the first one. Note1: both usb keyboards listed above are chinese models for who likes these mind games. Note2: I also tried passing by a usb hub or not with the same keyboards having the same results. N.B: In the past, when I was still using my ATEN KVM (with the related OpenBSD USB ghost keyboard driver for it) I have been attacked a coupled of times by *injection of keys*. Unfortunately I do not know now if we are talking about the same usb driver in subject of the marc.info post you passed us. If you are interested to test further about it.. I need just to do a new *unboxing* of the ATEN KVM and I can give you more feedback about this situation. Surely, from that moment I gave up with the ATEN KVM.. (the *SECURE* ones as the model suggest, but indeed it depends on the driver I can imagine..). I hope you can investigate and stress test more on these such usb keyboard drivers, just reading this mark.info post I have my hair slidly popping up -- Daniele Bonini
Re: PineView not using the whole screen
On Fri, Oct 20, 2023 at 05:00:47PM +0200, Daniele B. wrote: > > > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > > wskbd1: connecting to wsdisplay0 > > wskbd2: connecting to wsdisplay0 > > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > Just to add, that these are my settings too, from a life and these don't > depend from 7.4. > I also wonders the same when it is about the two keyboards. https://marc.info/?l=openbsd-tech=162922414816784
Re: PineView not using the whole screen
On Fri, Oct 20, 2023 at 04:46:32PM +0200, Jan Stary wrote: > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe69cb (27 entries) > bios0: vendor Intel Corp. version "MWPNT10N.86A.0069.2010.0913.1432" date > 09/13/2010 > bios0: Intel Corporation D525MW These are very old boards, we had one which was decomissioned some time ago but previously ran OpenBSD from release 5.0 up to some time around 6.2. I remember always seeing the same issue with only the top left 1280 x 800 portion of a 1920 x 1080 display used when it was on the console but I never bothered to investigate it further because the machine was mostly used headless. In X11 the it worked fine, (if slowly), using the whole 1920 x 1080 resolution. So this is not exclusively a new problem with this motherboard. Also, ours exhibited a strange bug with the USB subsystem in that the mouse stopped working every time the machine was powered off and on, and had to be physically disconnected and re-connected to be recognised again. No other USB peripherals suffered the same problem, and the mouse worked fine on other test machines.
PineView not using the whole screen
> wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > wskbd1: connecting to wsdisplay0 > wskbd2: connecting to wsdisplay0 > wsdisplay0: screen 1-5 added (std, vt100 emulation) Just to add, that these are my settings too, from a life and these don't depend from 7.4. I also wonders the same when it is about the two keyboards. -- Daniele Bonini
PineView not using the whole screen
This is current/amd64 on a PC (dmesg and X log below). It seems that both X and the console only use a portion of the available screen, in the upper left corner. Please see the lame jpegs (sorry): the console http://stare.cz/.tmp/fs4.jpeg the xenodm login screen http://stare.cz/.tmp/fs3.jpeg a maximalized xterm with a tmux session http://stare.cz/.tmp/fs2.jpeg a maximalized firefox window http://stare.cz/.tmp/fs1.jpeg (Maximalized means cwm's ctrl+alt+f, but it's the same with other window managers.) What's strange is that X somehow "knows" the actual size, as the xconsole box is in the actual lower right corner. The booting sequence (white on blue) uses the whole screen, until inteldrm0: 1280x800, 32bpp where the monitor "blinks", and starting with wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 the booting kernel only uses that portion of the scren. That makes me *suspect* it's a inteldrm problem. (It is also puzzling that the booting sequence ends with inteldrm0: 1280x800, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 wskbd1: connecting to wsdisplay0 wskbd2: connecting to wsdisplay0 wsdisplay0: screen 1-5 added (std, vt100 emulation) Needless to say, I only have one keyboard attached. Are there some devices being perhaps emulated as wskbds?) The X log starts with [27.357] (WW) checkDevMem: failed to open /dev/xf86 and /dev/mem (Operation not permitted) Check that you have set 'machdep.allowaperture=1' in /etc/sysctl.conf and reboot your machine refer to xf86(4) for details so I rebooted with machdep.allowaperture=1 but that doesn't seem to have changed anything. X log for that is also below, the diff being mostly + (--) checkDevMem: using aperture driver /dev/xf86 + (II) AIGLX: Suspending AIGLX clients for VT switch Disabling inteldrm in the kernel (dmesg also below) makes the booting kernel use the whole screen the whole time, but xenodm does not even start with vga as opposed to inteldrm (is that expected)? -inteldrm0 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 -drm0 at inteldrm0 -intagp0 at inteldrm0 -agp0 at intagp0: aperture at 0xe000, size 0x1000 -inteldrm0: apic 8 int 16, PINEVIEW, gen 3 +vga1 at pci0 dev 2 function 0 "Intel Pineview Video" rev 0x02 +wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) +wsdisplay0: screen 1-5 added (80x25, vt100 emulation) -wskbd0 at pckbd0: console keyboard +wskbd0 at pckbd0: console keyboard, using wsdisplay0 -inteldrm0: 1280x800, 32bpp -wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 -wsdisplay0: screen 1-5 added (std, vt100 emulation) How can I further debug this? Jan dmesg: OpenBSD 7.4-current (GENERIC.MP) #1411: Tue Oct 17 21:56:20 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8554905600 (8158MB) avail mem = 8275869696 (7892MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe69cb (27 entries) bios0: vendor Intel Corp. version "MWPNT10N.86A.0069.2010.0913.1432" date 09/13/2010 bios0: Intel Corporation D525MW acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT acpi0: wakeup devices SLPB(S4) UAR1(S4) UAR2(S4) P32_(S4) ILAN(S4) PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) UHC1(S3) UHC2(S3) UHC3(S3) UHC4(S3) EHCI(S3) AZAL(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.19 MHz, 06-1c-0a, patch 0107 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu0: 512KB 64b/line 8-way L2 cache mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.27 MHz, 06-1c-0a, patch 0107 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu1: 512KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.24 MHz, 06-1c-0a, patch 0107 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,MELTDOWN cpu2: 512KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Atom(TM) CPU D525 @ 1.80GHz, 1800.34 MHz, 06-1c-0a, patch 0107 cpu3:
[ANN] portable cwm 7.4
Hello, today I'm proud to release portable cwm 7.4. Portable cwm is a minor modification of the cwm version in OpenBSD CVS with a portable Makefile and a few compatibility features. It has been built successfully on OpenBSD, NetBSD, FreeBSD, macOS and Linux. This port requires pkg-config, Xft, Xinerama and Xrandr. The included Makefile should work with both GNU make and BSD make. This version actively tracks changes in the OpenBSD CVS repository. Releases are roughly coordinated with OpenBSD releases. The source can be found at https://github.com/leahneukirchen/cwm A changelog can be found at https://github.com/leahneukirchen/cwm/blob/linux/README https://leahneukirchen.org/releases/cwm-7.4.tar.gz https://leahneukirchen.org/releases/cwm-7.4.tar.gz.asc https://leahneukirchen.org/releases/cwm-7.4.tar.gz.sig Releases are also signed with signify(1) using https://leahneukirchen.org/releases/cwm.pub namely: RWTdOib0PoIM0pmDAPnV2S9/AMRqTOVfTY/KAkFemdH13cqBDHdduTas -- Leah Neukirchenhttps://leahneukirchen.org/ b4f275143c8c716d7df1cfbb230f888c72aa861708e144d1749858f1cc6fcac0 cwm-7.4.tar.gz 5ace4c9615c9ebc1063d7ec365da19b1801b1d59f32da7f86041de56c8fa5b6e cwm-7.4.tar.gz.asc c7bcf700d08a149f15e1d9a5fab2bf03b04fb001126e877c512cc0b4a8874e08 cwm-7.4.tar.gz.sig
