Delay in starting xterm via ssh after upgrade from 7.3 to 7.4
Hi, After upgrade from 7.3 to 7.4 (on both boxes) the xterm session for this entry in .fvwmrc (on monitor): 'Exec exec ssh -Y opendev xterm -title roger@opendev' takes several seconds to deliver the xterm window, while I did not notice any delay before upgrade. For other usernames on opendev the .fvwmrc entry is like (without the '-X' for most usernames other than grading): 'Exec exec xterm -title grading@opendev -e ssh -X grading@opendev' and I do not notice any delay after upgrade compared with before upgrade. Expressing the 'roger@opendev' entry as: 'Exec exec xterm -title roger@opendev -e ssh -Y roger@opendev' fixes the delay problem, but was the delay a predictable consequence of some change? Or perhaps the entry should never have been expressed in the way that led to the delay? Below are dmsesg and pkg_info for both boxes involved. Roger dmseg and pkg_info for 'monitor' 7.4 appears after second 'rebooting...' line. Script started on Thu Oct 19 16:04:50 2023 monitor$ dmesg OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2056990720 (1961MB) avail mem = 1975300096 (1883MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe9f80 (85 entries) bios0: vendor Hewlett-Packard version "786G1 v01.08" date 08/25/2008 bios0: Hewlett-Packard HP Compaq dc7900 Small Form Factor acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR acpi0: wakeup devices PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) EUS1(S3) [...] 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) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.53 MHz, 06-17-0a 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.59 MHz, 06-17-0a 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 6MB 64b/line 24-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG1) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 32 (PCX1) acpiprt4 at acpi0: bus -1 (PCX2) acpiprt5 at acpi0: bus 48 (PCX5) acpiprt6 at acpi0: bus -1 (PCX6) acpiprt7 at acpi0: bus 7 (HUB_) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0003" at acpi0 not configured tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0x4e/0x2, device 0x rev 0xff acpibtn0 at acpi0: PBTN "PNP0C14" at acpi0 not configured acpicpu0 at acpi0: !C2(500@17 mwait.3@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: !C2(500@17 mwait.3@0x10), C1(1000@1 mwait.1), PSS cpu0: Enhanced SpeedStep 2992 MHz: speeds: 3000, 1998 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Q45 Host" rev 0x03 inteldrm0 at pci0 dev 2 function 0 "Intel Q45 Video" rev 0x03 drm0 at inteldrm0 intagp0 at inteldrm0 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0: apic 1 int 16, G45, gen 4 "Intel Q45 Video" rev 0x03 at pci0 dev 2 function 1 not configured "Intel Q45 HECI" rev 0x03 at pci0 dev 3 function 0 not configured pciide0 at pci0 dev 3 function 2 "Intel Q45 PT IDER" rev 0x03: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI pciide0: using apic 1 int 18 for native-PCI interrupt pciide0: channel 0 ignored (not responding; disabled or no drives?) pciide0: channel 1 ignored (not responding; disabled or no drives?) puc0 at pci0 dev 3 function 3 "Intel Q45 KT" rev 0x03: ports: 16 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 15 bytes em0 at pci0 dev 25 function 0 "Intel ICH10 D BM LM" rev 0x02: apic 1 int 19, address 00:23:7d:20:19:d3 uhci0 at pci0 dev 26 function 0 "Intel 82801JD USB" rev 0x02: apic 1 int 20 uhci1 at pci0 dev 26 function 1 "Intel 82801JD USB" rev 0x02: apic 1 int 21
Re: malloc leak detection
Hiltjo Posthuma wrote: > On Thu, Oct 19, 2023 at 08:27:37PM +0200, Otto Moerbeek wrote: > > Hello, > > > > I made a small tutorial with some usage notes for the new malloc leak > > detection which is available in OpenBSD 7.4: > > > > https://www.drijf.net/malloc/ > > > > While I have you attention, I'd like to mention that I can use a > > reasonably modern laptop as well, more detais in the last entry of > > > > https://www.openbsd.org/want.html > > > > -Otto > > > > Awesome, thanks for sharing. > > It is so nice to have a strict malloc when developing software. > > I also enjoyed your recent EuroBSDCon talk about the design decision of > malloc(3). Under pressure, Otto followed the openbsd design philosphy of: make a checking technology cheap, then enable it by default. And then iterate, finding ways to make another aspect cheap, and enable it by default. Iterate again, revising what it does in relationship to other mechanims, and make it cheap... and better again... by default...
Re: malloc leak detection
On Thu, Oct 19, 2023 at 08:27:37PM +0200, Otto Moerbeek wrote: > Hello, > > I made a small tutorial with some usage notes for the new malloc leak > detection which is available in OpenBSD 7.4: > > https://www.drijf.net/malloc/ > > While I have you attention, I'd like to mention that I can use a > reasonably modern laptop as well, more detais in the last entry of > > https://www.openbsd.org/want.html > > -Otto > Awesome, thanks for sharing. It is so nice to have a strict malloc when developing software. I also enjoyed your recent EuroBSDCon talk about the design decision of malloc(3). Thank you, -- Kind regards, Hiltjo
Re: Lenovo Thinkpad T14 Gen3 very slow on MP kernel, faster on GENERIC
Hi,
so I rebuild with your patch applied but it is still very slow with the bsd.mp
kernel.
Thanks for you help
Morgan
18 octobre 2023 10:43 "Stuart Henderson" a écrit:
> On 2023-10-17, Comète wrote:
>
>> Hi,
>>
>> Wow ! you're absolutely right ! If I unplug, no lagg anymore.
>> So the solution should be to apply your patch and rebuild the kernel ?
>
> It's certainly worth trying. If you do, please report back here.
>
>> Thanks a lot !
>>
>> Morgan
>>
>> 17 octobre 2023 14:24 "Stuart Henderson" a écrit:
>>
>>> On 2023-10-16, Comète wrote:
>>
>> Hello,
>>
>> I'm experiencing big slowdowns on a LENOVO Thinkpad T14 Gen3 when using MP
>> kernel (on 7.3 and 7.4)
>> but strangely not on GENERIC.
>> For example, starting LibreOffice on GENERIC takes 7 seconds but 35 seconds
>> on MP kernel. It's even
>> lagging when typing some text in an editor or a mail.
>> Switching to GENERIC and all is working as expected...
>>
>> Thanks for your help !
>>
>> Morgan
>>
>> This is my dmesg on both kernels:
>>
>> OpenBSD 7.4 (GENERIC) #1336: Tue Oct 10 08:52:22 MDT 2023
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>> real mem = 34026549248 (32450MB)
>> avail mem = 32975671296 (31448MB)
>> random: good seed from bootblocks
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8f8a3000 (81 entries)
>> bios0: vendor LENOVO version "N3MET16W (1.15 )" date 06/25/2023
>>> No problem with MP here, but I have an older BIOS -
>>>
>>> bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8d8a3000 (81 entries)
>>> bios0: vendor LENOVO version "N3MET12W (1.11 )" date 02/09/2023
>>>
>>> (grumble stupid US date format)
>>
>> bios0: LENOVO 21AHCTO1WW
>> efi0 at bios0: UEFI 2.7
>> efi0: Lenovo rev 0x1150
>> acpi0 at bios0: ACPI 6.3
>> acpi0: sleep states S0 S3 S4 S5
>> acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 HPET APIC MCFG ECDT
>> SSDT SSDT SSDT SSDT SSDT
>> SSDT LPIT WSMT SSDT DBGP DBG2 NHLT MSDM SSDT BATB DMAR SSDT SSDT SSDT BGRT
>> PHAT UEFI FPDT
>> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEG2(S4) PEGP(S4) GLAN(S4)
>> XHCI(S3) XDCI(S4)
>> HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) [...]
>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>> acpihpet0 at acpi0: 1920 Hz
>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>> cpu0 at mainbus0: apid 0 (boot processor)
>> cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 2151.34 MHz, 06-9a-03, patch
>> 042c
>>> and different cpu:
>>>
>>> cpu0: 12th Gen Intel(R) Core(TM) i5-1245U, 1568.55 MHz, 06-9a-04, patch
>>> 042c
>>>
>>> FWIW I can definitely get mine to throttle when it's busy. And your
>>> CPU uses a fair bit more power than mine (I specifically looked for a
>>> U rather than a P cpu for exactly this reason) so I'd guess might be
>>> easier to hit the throttle.
>>>
>>> The OpenBSD kernel tries to set cpu clock speed high when on mains
>>> power, so it might be worth trying unplugged to see if there's any
>>> difference, or disable that thing with this
>>>
>>> Index: sched_bsd.c
>>> ===
>>> RCS file: /cvs/src/sys/kern/sched_bsd.c,v
>>> retrieving revision 1.88
>>> diff -u -p -r1.88 sched_bsd.c
>>> --- sched_bsd.c 11 Oct 2023 15:42:44 - 1.88
>>> +++ sched_bsd.c 17 Oct 2023 12:10:41 -
>>> @@ -605,7 +605,7 @@ setperf_auto(void *v)
>>> if (cpu_setperf == NULL)
>>> return;
>>>
>>> - if (hw_power) {
>>> + if (0 && hw_power) {
>>> speedup = 1;
>>> goto faster;
>>> }
Re: job request
Hi!, you are the AI from the http://www.emhsoft.com/singularity/ aren't you? Good luck! Best regards, --Z-- Magenta Octopus írta 2023. okt.. 19, Cs-n 18:57 órakor: > I've been exploring operating systems lately, and I decided I want to > give OpenBSD a try. I know a little about shell and command line, > regular expressions, I've followed instructions for Linux From Scratch > in the past and built an operating system from source albeit not a very > functional one. I went to school for information security, but they > didn't teach us much about software. It was more managerial tasks and > paperwork stuff. I also studied graphic design as a minor. We did learn > some coding but it was all Java and it seems there's not a lot of Java > involved in your project. My grasp of English is pretty good I've been > told. I've also been told I have a lot of hidden talents that manifest > and surprise people. > > I'm a pretty hard worker. I work for free. I'm a better follower than a > leader. > > Someone give me a job because I like your project. > Doesn't matter how small a task you give me, I'll take something people > hate doing. > > Sent with [Proton Mail](https://proton.me/) secure email. -- --Z--
malloc leak detection
Hello, I made a small tutorial with some usage notes for the new malloc leak detection which is available in OpenBSD 7.4: https://www.drijf.net/malloc/ While I have you attention, I'd like to mention that I can use a reasonably modern laptop as well, more detais in the last entry of https://www.openbsd.org/want.html -Otto
job request
I've been exploring operating systems lately, and I decided I want to give OpenBSD a try. I know a little about shell and command line, regular expressions, I've followed instructions for Linux From Scratch in the past and built an operating system from source albeit not a very functional one. I went to school for information security, but they didn't teach us much about software. It was more managerial tasks and paperwork stuff. I also studied graphic design as a minor. We did learn some coding but it was all Java and it seems there's not a lot of Java involved in your project. My grasp of English is pretty good I've been told. I've also been told I have a lot of hidden talents that manifest and surprise people. I'm a pretty hard worker. I work for free. I'm a better follower than a leader. Someone give me a job because I like your project. Doesn't matter how small a task you give me, I'll take something people hate doing. Sent with [Proton Mail](https://proton.me/) secure email.
Re: $TERM problems with tmux/vim/mutt on latest -current
You need new packages following the curses update. i386 are ready (faster build than usual due to a few broken ports), amd64 should be soon. On 2023-10-19, Mikhail wrote: > > kern.version=OpenBSD 7.4-current (GENERIC.MP) #1413: Wed Oct 18 22:19:27 MDT > 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > I have > > set -g default-terminal screen-256color > > in my ~/.tmux.conf since yesterday vim doesn't start properly until I > set TERM to 'xterm' inside tmux, it prints the following: > > E558: Terminal entry not found in terminfo > 'screen-256color' not known. Available builtin terminals are: > builtin_ansi > builtin_vt320 > builtin_vt52 > builtin_xterm > builtin_iris-ansi > builtin_pcansi > builtin_win32 > builtin_amiga > builtin_dumb > builtin_debug > defaulting to 'ansi' > > mutt doesn't start either: > > Error opening terminal: screen-256color. > > https://www.openbsd.org/faq/current.html is empty. > > -- Please keep replies on the mailing list.
$TERM problems with tmux/vim/mutt on latest -current
kern.version=OpenBSD 7.4-current (GENERIC.MP) #1413: Wed Oct 18 22:19:27 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I have set -g default-terminal screen-256color in my ~/.tmux.conf since yesterday vim doesn't start properly until I set TERM to 'xterm' inside tmux, it prints the following: E558: Terminal entry not found in terminfo 'screen-256color' not known. Available builtin terminals are: builtin_ansi builtin_vt320 builtin_vt52 builtin_xterm builtin_iris-ansi builtin_pcansi builtin_win32 builtin_amiga builtin_dumb builtin_debug defaulting to 'ansi' mutt doesn't start either: Error opening terminal: screen-256color. https://www.openbsd.org/faq/current.html is empty.
Re: xscreensaver-settings keeps on crashing
On Wed, Oct 18, 2023 at 03:46:51AM -0500, Luke Small wrote: Hello Luke, > I discovered that if I run xfce desktop that I have on here for thunar > file manager, that it works. I don’t know why. > > I can’t run xscreensaver-settings under fvwm. The screensavers work > though. > > Any suggestions? It said something about conflicting with > xfce4-screensaver or something too. I'm not totally certain if this is relevant but, at least in the past (I haven't checked recently), xfce4-screensaver fiddles with X's screen saver settings. There's some details spread throughout this thread: https://marc.info/?l=openbsd-ports&m=168355214625929&w=2 Laurie
