Re: plasma-desktop installation failed due to problem with icon theme package
On 2024/04/21 16:53, Thomas Nemeth wrote:
> Le dimanche 21 avril 2024, 12:53:08 CEST Stuart Henderson a écrit :
> > On 2024/04/20 14:15, Thomas Nemeth wrote:
> > > bios0: ASUSTeK Computer INC. B202
> > > ...
> > > cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class)
> > > 1.61 GHz, 06-1c-02, patch 0218
> [...]
> > > I also tried OpenBSD on a raspi4.
> >
> > fwiw, for OpenBSD, raspi4 is likely to be a lot more usable than this
> > eeepc.
>
> I'm not aware of an empiric way of comparing OpenBSD performance on
> both. Under Linux there's the "bogomips" entry in the /proc/cpuinfo
> file but I couldn't find something equivalent for OpenBSD.
>
>
> > Hmm. Maybe pkg_delete the partials and re-add.
>
> pkg_delete doesn't want to remove it because it's not fully installed:
>
> root:~# pkg_delete papirus-icon-theme
> Can't find papirus-icon-theme
> Problem finding papirus-icon-theme
No, run pkg_delete on the partial, i.e. pkg_delete partial-papirus-icon-theme
Re: plasma-desktop installation failed due to problem with icon theme package
On 2024/04/20 14:15, Thomas Nemeth wrote:
> Le samedi 20 avril 2024, 12:27:05 CEST Stuart Henderson a écrit :
> > On 2024/04/20 11:26, Thomas Nemeth wrote:
> > > Machine : i386
> >
> > Unrelated to this problem, but do you really need i386? It's not
> > recommended on machins which can run amd64 (and I guess if you're trying
> > to run Plasma you probably don't gave _that_ old a machine).
>
> Yes I did :)
>
> I'm experimenting stuff. I'm playing with several OSes on an
> eeePC B202 :
>
> bios0: ASUSTeK Computer INC. B202
> ...
> cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz ("GenuineIntel" 686-class) 1.61
> GHz, 06-1c-02, patch 0218
ah yes, that's probably about the last Atom before they got 64-bit
support.
> I don't have much hope performance-wise of course. I just want to see
> how much I can do with that machine and compare its performcances with
> others OSes (Linux of course, Plan9, Haiku...).
>
> I previously used that eeePC as a wifi access point and that was nice.
>
> I also tried OpenBSD on a raspi4.
fwiw, for OpenBSD, raspi4 is likely to be a lot more usable than this eeepc.
> > Try pkg_check to see if it will repair your package db..
>
> $ doas pkg_check
> Packing-list sanity: ok
> partial-papirus-icon-theme-20231201.2 is missing dependencies: gtk4-
> update-icon-cache-4.12.5
> not a problem, since this is a partial- package
> partial-papirus-icon-theme-20231201.1 is missing dependencies: gtk4-
> update-icon-cache-4.12.5
> not a problem, since this is a partial- package
> partial-papirus-icon-theme-20231201 is missing dependencies: gtk4-update-
> icon-cache-4.12.5
> not a problem, since this is a partial- package
> Direct dependencies: ok
> Reverse dependencies: ok
> Files from packages: ok
> --- partial-papirus-icon-theme-20231201 ---
> checksum for /usr/local/share/icons/Papirus/32x32/apps/vscode-
> exploration.svg does not match
> --- partial-papirus-icon-theme-20231201.2 ---
> checksum for /usr/local/share/icons/Papirus/32x32/apps/vscode-
> exploration.svg does not match
Hmm. Maybe pkg_delete the partials and re-add.
Re: plasma-desktop installation failed due to problem with icon theme package
On 2024/04/20 11:26, Thomas Nemeth wrote: > > Synopsis: Plasma-desktop can't get installed because an icon theme > package seems to be corrupted > > Category: system > > Environment: > System : OpenBSD 7.5 > Details : OpenBSD 7.5 (GENERIC.MP) #192: Wed Mar 20 16:49:13 > MDT 2024 > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/ > compile/GENERIC.MP > > Architecture: OpenBSD.i386 > Machine : i386 Unrelated to this problem, but do you really need i386? It's not recommended on machins which can run amd64 (and I guess if you're trying to run Plasma you probably don't gave _that_ old a machine). > > Description: > Hello ! > > I tried to install plasma-desktop on my system. However it stopped > after a lot of complaining that all the packages depending in > kcoreaddons could not be installed. Indeed that package depends on > an icon theme package that fails to install. > > Here is an output of what's displayed : > [...] > /usr/local/share/icons/Papirus/32x32/apps/media-downloader.svg > from papirus-icon-theme-20231201 (same checksum) > /usr/local/share/icons/Papirus/32x32/apps/microsoft-365.svg from > papirus-icon-theme-20231201 (same checksum) > /usr/local/share/icons/Papirus/32x32/apps/mlgui.svg from papirus- > icon-theme-20231201 (different checksum) > /usr/local/share/icons/ePapirus/16x16/places/folder-nordic.svg > from papirus-icon-theme-20231201 (same checksum) > It seems to be a missing package registration > Repair ? [y/N/a] > > Can't install kcoreaddons-5.115.0: can't resolve papirus-icon- > theme-20231201 > Can't install kcoreaddons-5.115.0: can't resolve papirus-icon- > theme-20231201 > Can't install kauth-5.115.0: can't resolve kcoreaddons-5.115.0 > Can't install kconfigwidgets-5.115.0: can't resolve > kcoreaddons-5.115.0,kauth-5.115.0 > [...] > Couldn't install breeze-5.27.10 frameworkintegration-5.115.0 kaccounts- > integration-23.08.4 kaccounts-providers-23.08.4 kactivities-stats-5.115.0 > kauth-5.115.0 kbookmarks-5.115.0 kcmutils-5.115.0 kconfigwidgets-5.115.0 > kcoreaddons-5.115.0 kcrash-5.115.0 kdeclarative-5.115.0 > kdecoration-5.27.10 kded-5.115.0 kdelibs4support-5.115.0p0 > kdesignerplugin-5.115.0 kemoticons-5.115.0 kf5-baloo-5.115.0v0 kf5- > kactivities-5.115.0 kf5-kfilemetadata-5.115.0 kf5-kwallet-5.115.0 kf5- > qqc2-desktop-style-5.115.0 kglobalaccel-5.115.0 kiconthemes-5.115.0 > kinit-5.115.0 kio-5.115.0 kjobwidgets-5.115.0 knewstuff-5.115.0 > knotifications-5.115.0 knotifyconfig-5.115.0 kpackage-5.115.0 > kparts-5.115.0 kpeople-5.115.0 kpipewire-5.27.10 krunner-5.115.0 > kscreenlocker-5.27.10 kservice-5.115.0 ktexteditor-5.115.0 > ktextwidgets-5.115.0 kwin-5.27.10p0 kxmlgui-5.115.0 libksysguard-5.27.10p1 > papirus-icon-theme-20231201 plasma-desktop-5.27.10p0 plasma- > framework-5.115.0 plasma-workspace-5.27.10p1 > > > Of course I tried the repair option before... But that didn't do > a thing. > > > How-To-Repeat: > $ doas pkg_add plasma-desktop > > > Fix: > N/A at the moment (at least for me). > > > Try pkg_check to see if it will repair your package db..
Re: Unable to use latest version ( 7.5) Autoinstall
On 2024/04/18 22:03, markmarq...@sapo.pt wrote: > > Sorry for the late reply ... > When I wrote that ".. the first installation started with 6.9 ..." , i was > merely trying to > pinpoint in time my first install with OpenBSD .. > which were executed via the (A)utoinstall option ... > > > When I was unable to do (A)utoInstall I was trying to execute a complete new > fresh install > > Nonetheless what is the response file ?? > In the install docs I was unable to find it... See autoinstall(8). It is not used for a regular install.
Re: 7.5 regression - relayd - websockets - WS session setup ok, but no payload from server
This is most likely a result of increased sanity checks for headers
done last autumn.
Does anything show in debug logs? (relayd -dv)
On 2024/04/09 01:02, Ollie Strickland wrote:
> bugs@ - post upgrade to 7.5, I have lost websockets functionality via relayd
> for app Vaultwarden. Websockets is used in package - vaultwarden-1.30.5 - in
> an advanced feature that pushes data to client browsers and mobile apps in
> real time.
>
> Note - the application has basic functionality without websockets via polling
> of the server, so at a cursory glance the app appears to work fine. So, use
> step (6) to test websockets.
>
> Steps to reproduce:
> 1 - pkg_add vaultwarden-1.30.5
> 2 - rcctl enable vaultwarden && rcctl start vaultwarden
> 3 - configure relayd with below config
> 4 - point web browser to the host and register for a new vaultwarden user
> account
> 5 - open a second browser session incognito / private
> 6 - in the first browser, create a new secure note - when websockets is
> working the data should show up in near real time in the other browser
> 7 - watch WS activity in the dev console, and note that although the WS
> session is established successfully, no payload data is ever received from
> the server - this set of screenshots shows proper operation without relayd in
> the first screenshot, and then failure of WS with relayd in the second
> screenshot - https://imgur.com/a/msvyXbX
> 8 - note that if you turn relayd off and use pf to send inbound web traffic
> to Vaultwarden's Rocket server on port 8000, then websockets works
>
> Ollie Strickland
> -
>
> relayd.conf:
> -
> table { 127.0.0.1 }
>
> # protocol definition for vaultwarden with tls
> http protocol vaultwarden-https {
>
> # forward connections to vaultwarden rocket
> match request path "/*" forward to
>
> # add headers vaultwarden may need
> match request header append "Host" value "$HOST"
> match request header append "X-Real-IP" value "$REMOTE_ADDR"
> match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
> match request header append "X-Forwarded-By" value
> "$SERVER_ADDR:$SERVER_PORT"
> match request header append "CF-Connecting-IP" value "$REMOTE_ADDR"
>
> # various TCP options
> tcp { nodelay, sack, backlog 128 }
>
> # tls config
> tls keypair vault.example.com
> tls { no tlsv1.0, ciphers HIGH }
>
> # allow websockets
> http websockets
> }
>
> # relay definition for vaultwarden - forward inbound 443 tls on the egress
> interface to rocket on default port 8000
> relay vaultwarden-https-relay {
> listen on egress port 443 tls
> protocol vaultwarden-https
> forward to port 8000
> }
> -
>
> dmesg:
> -
> OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024
>
> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4278042624 (4079MB)
> avail mem = 4128661504 (3937MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S3 S4 S5
> acpi0: tables DSDT FACP APIC HPET MCFG WAET
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD EPYC-Milan Processor, 3250.37 MHz, 19-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,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,SSBD,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVES
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
> 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 1000MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD EPYC-Milan Processor, 3250.49 MHz, 19-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,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,SSBD,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVES
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
> 64b/line 8-way L2 cache, 32MB 64b/line 16-way L3 cache
> cpu1: smt 1, core 0, package 0
> ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
>
Re: pkg_add doesn't set the Host header in CONNECT requests
Diff looks good to me - I'm a bit surprised Apache httpd needs this on
proxy CONNECT requests though, other proxies that I've used are happy
without.
On 2024/04/07 16:46, KUWAZAWA Takuya wrote:
> >Synopsis:pkg_add doesn't set the Host header in CONNECT requests
> >Category:user
> >Environment:
> System : OpenBSD 7.4
> Details : OpenBSD 7.4 (GENERIC) #3: Wed Feb 28 06:23:08 MST 2024
>
> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
>
> pkg_add doesn't work when http_proxy is set.
> The proxy server says that client sent HTTP/1.1 request without hostname.
>
> >How-To-Repeat:
>
> # pkg_add apache-httpd
> # perl -pi.old -e '/mod_proxy(_http|_connect)?\.so/ && s/^#//'
> /etc/apache2/httpd2.conf
> # perl -pi -e '/^LogLevel/ && s/warn/debug/' /etc/apache2/httpd2.conf
> # echo 'ProxyRequests On' >> /etc/apache2/httpd2.conf
> # apachectl2 start
>
> # export http_proxy=http://localhost:80/
> # pkg_add bash
> https://cdn.openbsd.org/pub/OpenBSD/7.4/packages-stable/amd64/: TLS handshake
> failure: handshake failed: unexpected EOF
> https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/: TLS handshake
> failure: handshake failed: unexpected EOF
> https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/: empty
>
> # tail -n 1 /var/www/logs/access_log
> 127.0.0.1 - - [06/Apr/2024:22:40:26 +0900] "CONNECT cdn.openbsd.org:443
> HTTP/1.1" 400 226
> # tail -n 1 /var/www/logs/error_log
> [Sat Apr 06 22:40:26.215271 2024] [core:debug] [pid 32509] protocol.c(1043):
> [client 127.0.0.1:39864] AH00569: client sent HTTP/1.1 request without
> hostname (see RFC2616 section 14.23): /
>
> >Fix:
>
> I added the Host header as follows.
>
> --- usr.bin/ftp/fetch.c.orig Thu Jun 29 02:35:06 2023
> +++ usr.bin/ftp/fetch.c Sat Apr 6 22:44:46 2024
> @@ -1724,11 +1724,13 @@
>
> if (cookie) {
> l = asprintf(, "CONNECT %s:%s HTTP/1.1\r\n"
> + "Host: %s:%s\r\n"
> "Proxy-Authorization: Basic %s\r\n%s\r\n\r\n",
> - host, port, cookie, HTTP_USER_AGENT);
> + host, port, host, port, cookie, HTTP_USER_AGENT);
> } else {
> - l = asprintf(, "CONNECT %s:%s HTTP/1.1\r\n%s\r\n\r\n",
> - host, port, HTTP_USER_AGENT);
> + l = asprintf(, "CONNECT %s:%s HTTP/1.1\r\n"
> + "Host: %s:%s\r\n%s\r\n\r\n",
> + host, port, host, port, HTTP_USER_AGENT);
> }
>
> if (l == -1)
>
Re: Can't install amd64 `install.iso` since 7.0
Try installing from network rather than files on cd0. On 2024/04/05 21:14, veganaiZe wrote: > When attempting to Install OpenBSD (at least) 7.3, 7.4, 7.5 on amd64 virtual > machine in VirtualBox 6.1 on Windows 8.1 (64-bit), with mostly default > options (except for)... > > > 1. [I]nstall > 2. Hostname: foo > > > Eventually, it claims it can't verify the signatures so I have to type `yes` > in order for it to proceed -- and then it fails (image attached). > > P.S. It sure would be nice if the system paused / hung instead of > auto-rebooting so that I could actually read the (panic?) message. > > Thanks!
Re: 404 on download links
Should show up soon if it's not there already. Different steps of the release happen at different times and can get a bit out of sync sometimes (actual release day for 7.5 is tomorrow). On 2024/04/03 23:40, Rory wrote: > Hi, > > Under 'Downloading OpenBSD' all download links lead to 404 for me. > > https://www.openbsd.org/faq/faq4.html#Download > > For example : > > https://cdn.openbsd.org/pub/OpenBSD/7.5/amd64/install75.img > > Sorry if this is the 500th email you've gotten on this, I will download 7.4. > > Kind regards, > Rory > Houston, TX
Re: FW: ls -l Segmentation fault
On 2024/03/26 19:10, Peter Fraser wrote: > I did check https://www.openbsd.org/anoncvs.html > > It still points to https://www.openbsd.org/anoncvs.html Oh, in the example commands, I see. The actual list of mirrors is below - will fix. > -Original Message----- > From: Stuart Henderson > Sent: Tuesday, March 26, 2024 3:07 PM > To: Peter Fraser > Cc: bugs@openbsd.org > Subject: Re: FW: ls -l Segmentation fault > > On 2024/03/26 18:49, Peter Fraser wrote: > > > > I tried to get the source, but I get no response out of > > > > cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -rOPENBSD_7_4 -P src > > That server is no more; see https://www.openbsd.org/anoncvs.html > > You can do a partial checkout if you prefer, e.g. > > cvs -qd anon...@obsdacvs.cs.toronto.edu:/cvs checkout -rOPENBSD_7_4 -P > src/bin/ls >
Re: FW: ls -l Segmentation fault
On 2024/03/26 18:49, Peter Fraser wrote: > > I tried to get the source, but I get no response out of > > cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -rOPENBSD_7_4 -P src That server is no more; see https://www.openbsd.org/anoncvs.html You can do a partial checkout if you prefer, e.g. cvs -qd anon...@obsdacvs.cs.toronto.edu:/cvs checkout -rOPENBSD_7_4 -P src/bin/ls
Re: ls -l Segmentation fault
ls is statically linked, could you build from src with "make DEBUG=-g" and obtain a fresh backtrace? On 2024/03/26 17:59, Peter Fraser wrote: > I never expected it was the number files, I give the number to show that it > was some what of general error that populated lost+found > > Using lldb > > (lldb) run -l > run -l > Process 89184 launched: '/bin/ls' (x86_64) > total 2176 > cx 1 34078976wheel58, 7079544 Dec 31 1969 #04963796 > Process 89184 stopped > * thread #1, stop reason = signal SIGSEGV > frame #0: 0x0ae35b5aef18 ls`___lldb_unnamed_symbol508 + 1432 > ls`___lldb_unnamed_symbol508: > -> 0xae35b5aef18 <+1432>: movl 0x10(%r11), %ecx > 0xae35b5aef1c <+1436>: leaq -0x42c8b(%rip), %rax > 0xae35b5aef23 <+1443>: cmpq $0xb, %rcx > 0xae35b5aef27 <+1447>: ja 0xae35b5aef34 ; <+1460> > Process 89184 stopped > * thread #1: tid = 185603, 0x0ae35b5aef18 ls`___lldb_unnamed_symbol508 + > 1432, stop reason = signal SIGSEGV > (lldb) thread backtrace > thread backtrace > * thread #1, stop reason = signal SIGSEGV > * frame #0: 0x0ae35b5aef18 ls`___lldb_unnamed_symbol508 + 1432 > frame #1: 0x0ae35b5ae93a ls`___lldb_unnamed_symbol507 + 90 > frame #2: 0x0ae35b578111 ls`___lldb_unnamed_symbol26 + 993 > frame #3: 0x0ae35b577ac9 ls`___lldb_unnamed_symbol22 + 1353 > frame #4: 0x0ae35b57745f ls`___lldb_unnamed_symbol20 + 495 > frame #5: 0x0ae35b57721f ls`___lldb_unnamed_symbol19 + 1887 > frame #6: 0x0ae35b5764c2 ls`___lldb_unnamed_symbol5 + 338 > (lldb) > > -Original Message- > From: Omar Polo > Sent: Tuesday, March 26, 2024 1:37 PM > To: Peter Fraser > Cc: bugs@openbsd.org > Subject: Re: ls -l Segmentation fault > > [moving to bugs@] > > On 2024/03/26 17:15:28 +, Peter Fraser wrote: > > For some reason I don't know my partition /var/www got screwed up and there > > was a long list in /var/www/lost+found. > > > > Since I populate /var/www by using rsync from another computer, and I > > expect didn't notice the existence of lost+found for a long time. > > > > "ls" on the directory works but "ls -l" faults with > > > > ls -l > > total 2176 > > cx 1 34078976wheel58, 7079544 Dec 31 1969 #04963796 > > Segmentation fault (core dumped) > > > > The directory has 1324 files in it. > > > > I have included the core dump of "ls" > > > > If you try to tar the files in the directory, you get very strange message, > > but the files are ignored and the is not faults. > > I still have them if anyone wants to examine them. If not, I will try to > > delete them. > > the corefile alone is not going to be of much help due to the random libc > relinking; can you show the backtrace? lldb in base should work, otherwise > use egdb from the gdb package. > > $ ls -l > [assuming it crashes] > $ egdb ls ls.core > [useless copyright stuff elided] > (gdb) bt > > and paste the output in a mail. re-compiling ls with debug symbols (cd > /usr/src/bin/ls && make DEBUG='-g' && doas make DEBUG='-g' install) could be > useful too. > > For what is worth, I have a maildir with 14k files and haven't noticed > crashes, so the number of entries it's probably not the culprit. > > > Thanks, >
Re: pcidevs_data.h relies on pcireg.h despite not including it.
On 2024/03/25 05:12, Gibson Pilconis wrote: > Hi. > > I'm working on a project that supports OpenBSD and I noticed that > pcidevs_data.h uses > structures defined in pcireg.h but doesn't include the file. As a result, > pcireg.h has to be > included before pcidevs_data.h or else the compiler will throw an error. > > I'm not sure if this is considered a bug or not, but I couldn't find any > documentation of it > and I could easily see it confusing newer developers. If adding an include to > the header isn't > an option, perhaps adding in a comment informing developers they need to > import pcireg.h would > prove useful. pcidevs_data.h is almost never included directly, the only file in the OpenBSD kernel tree using it is pci_subr.c. So it seems this is probably not really needed?
Re: uaudio: Rode NT-USB Mini interface detection issues
On 2024/03/22 15:19, vazub wrote: > >Synopsis:uaudio: Rode NT-USB Mini interface detection issues > >Category:kernel > >Environment: > System : OpenBSD 7.5 > Details : OpenBSD 7.5 (GENERIC.MP) #75: Wed Mar 13 05:45:48 MDT 2024 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > The aforementioned device does not appear to be set up properly (see > dmesg output). Namely, the listing of channels shows zeroes - channels: 0 > play, 0 rec, 0 ctls. > Apparently, this results in interface not working properly with sndio - there > is no sound output with the headphones connected to the mic, and additionally > fiddling with sndiod/ctl settings, as laid out in the FAQ, does not seem to > help. dmesg from a kernel built with UAUDIO_DEBUG (e.g. "#define UAUDIO_DEBUG" in sys/dev/usb/uaudio.c would be one way to do this) might give some more clues, as might output from "lsusb -v -d 19f7:" (run as root after installing usbutils). > Additional context: > - audio recording is enabled > - changing server.device has no effect > - all the outputs are not muted (see dump below) > obsd# sndioctl -d > 011:input[0].level=0..255 (124) > 012:input[1].level=0..255 (124) > 013:input[0].mute=0..1 (0) > 014:input[1].mute=0..1 (0) > 007:output[0].level=0..255 (126) > 008:output[1].level=0..255 (126) > 009:output[0].mute=0..1 (0) > 010:output[1].mute=0..1 (0) > 001:server.device=0 > 002:server.device=1 > 003:server.device=2 > 004:server.device=3 > 006:firefox0.level=0..127 (127) > 005:pulseau0.level=0..127 (127) > > Also, if that info is of any value here, the same interface is detected and > works as expected in the latest FreeBSD (14.x) and NetBSD (-current) versions. > > >How-To-Repeat: > 1. Attach Rode NT-USB Mini to either USB 2.0, USB 3.1 Gen-1/Gen-2 > (Type-A) port > 2. Run "dmesg" > 3. See the following output: > uhidev3 at uhub0 port 19 configuration 1 interface 3 "R\M-XDE > Microphones R\M-XDE NT-USB Mini" rev 2.00/2.36 addr 5 > uhidev3: iclass 3/0, 8 report ids > uhid0 at uhidev3 reportid 1: input=9, output=0, feature=0 > uhid1 at uhidev3 reportid 2: input=0, output=9, feature=0 > uhid2 at uhidev3 reportid 3: input=28, output=0, feature=0 > uhid3 at uhidev3 reportid 4: input=0, output=28, feature=0 > uhid4 at uhidev3 reportid 5: input=14, output=0, feature=0 > uhid5 at uhidev3 reportid 6: input=0, output=14, feature=0 > uhid6 at uhidev3 reportid 7: input=27, output=0, feature=0 > uhid7 at uhidev3 reportid 8: input=0, output=27, feature=0 > uaudio1 at uhub0 port 19 configuration 1 interface 1 "R\M-XDE > Microphones R\M-XDE NT-USB Mini" rev 2.00/2.36 addr 5 > uaudio1: class v0, full-speed, sync, channels: 0 play, 0 rec, 0 ctls > audio2 at uaudio1 > uaudio2 at uhub0 port 19 configuration 1 interface 2 "R\M-XDE > Microphones R\M-XDE NT-USB Mini" rev 2.00/2.36 addr 5 > uaudio2: class v0, full-speed, sync, channels: 0 play, 0 rec, 0 ctls > audio3 at uaudio2 > ugen1 at uhub0 port 19 configuration 1 "R\M-XDE Microphones R\M-XDE > NT-USB Mini" rev 2.00/2.36 addr 5 > > >Fix: > Not known. > > > dmesg: > OpenBSD 7.5 (GENERIC.MP) #75: Wed Mar 13 05:45:48 MDT 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17053016064 (16263MB) > avail mem = 16514981888 (15749MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xcde22000 (25 entries) > bios0: vendor American Megatrends Inc. version "P4.30" date 12/03/2020 > bios0: ASRock X470 Gaming-ITX/ac > efi0 at bios0: UEFI 2.7 > efi0: American Megatrends rev 0x50011 > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT FIDT MCFG AAFT HPET SSDT VFCT TPM2 > SSDT CRAT CDIT BGRT SSDT SSDT WSMT APIC SSDT FPDT > 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 > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf000, bus 0-127 > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 5 2600 Six-Core Processor, 3400.00 MHz, 17-08-02, patch > 0800820d > cpu0: >
Re: Possible bulk build failed for amd64
On 2024/03/13 14:38, Mike Rotondo via bugs wrote: > To: bugs@openbsd.org > Subject: Possible bulk build failed for amd64 > From: mike > Cc: mike > Reply-To: mike > > >Synopsis: Possible bulk build failed for amd64 > >Category: Unknown > >Environment: > System : OpenBSD 7.4 > Details : OpenBSD 7.4 (GENERIC.MP) #3: Wed Feb 28 06:23:33 MST 2024 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > I believe that "An amd64 bulk build failed and got uploaded before > that was noticed." ; as described here > https://www.reddit.com/r/openbsd/comments/16paek7/cant_install_package_that_is_in_the_repo/ That refers to a short-term problem back in september, long since fixed > GTK4 and related packages will not update. > > ### TERMINAL OUTPUT START ### > hostname# pkg_add -u gtk4-update-icon-cache > Can't find gtk4-update-icon-cache > Problem finding gtk4-update-icon-cache > quirks-6.160 signed on 2024-03-06T19:04:54Z Which mirror do you use (either in $PKG_PATH or /etc/installurl)? What is the output from pkg_add -u?
Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
On 2024/03/08 22:35, Mark Kettenis wrote: > > Date: Fri, 8 Mar 2024 20:29:35 + > > From: Stuart Henderson > > > > On 2024/03/08 14:34, Kenneth Westerback wrote: > > > I see the same/similar behaviour on my M1 MacMini. i.e. when sceen blanks > > > it won't come back until I reboot. > > > > > > Monitor is connected via HDMI. Happy to provide more details/info/tests if > > > same deemed useful. > > > > Just tried xset s off, which I think _may_ be helping. > > I haven't done a ton of testing myself. Mostly just having machines > sit idle in xenodm. There were some reports that quickly changing the > display brightness causes similar firmware hangs. So I wonder if > doing something more complicated in X would trigger the issue. > > I think tobhe@ has spent a bit more time on his m2 macbook air. But > maybe he doesn't have the automatic screen blanking enabled. I added 'xset s off' on top of the existing 'xset -dpms' 2 hours ago and the display is still on, so I think that's a winner. It didn't _always_ stay off after blanking, but did most of the time.
Re: arm64 mbp M2 pro, screen blanks and won't restore after inactivity in X
On 2024/03/08 14:34, Kenneth Westerback wrote: > I see the same/similar behaviour on my M1 MacMini. i.e. when sceen blanks > it won't come back until I reboot. > > Monitor is connected via HDMI. Happy to provide more details/info/tests if > same deemed useful. Just tried xset s off, which I think _may_ be helping.
Re: Stopped at smu7_powergate_uvd+0x23
On 2024/03/08 15:35, Avon Robertson wrote: > Ideally, my kernel build will need to be in sync with the install75.img > files on the troublesome machine? So, to reduce the chances of out of > sync errors, I will build a kernel and create a release to install with > a USB flash drive on the troublesome machine. No need to build a full release, just a kernel will be fine. Checkout the tree, then cd /sys/arch/amd64/compile/GENERIC.MP make obj make config make -j8 make install -j8 is to use 8 cores, which looking at dmesg should be reasonable on your machine and would speed up the build (Currently there might be chance to get fixes in before 7.5 release, but the window for that is very narrow so the sooner the better)
Re: Gajim msyscall error
On 2024/03/03 15:21, Stuart Henderson wrote:
> On 2024/03/03 07:59, Theo de Raadt wrote:
> > Does it work if this is modified to just ask for "libc.so"?
>
> Yes. Conservative approach just doing this for libc:
oh, we need to update the installed list-of-changes file too,
and diff updated to include 3.11 as well. I don't think I'll bother
with patching the legacy versions.
any OKs?
Index: 3.10/Makefile
===
RCS file: /cvs/ports/lang/python/3.10/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- 3.10/Makefile 14 Nov 2023 12:33:56 - 1.37
+++ 3.10/Makefile 3 Mar 2024 15:24:58 -
@@ -4,7 +4,7 @@
# Python itself.
FULL_VERSION = 3.10.13
-REVISION = 0
+REVISION = 1
SHARED_LIBS = python3.10 0.0
VERSION_SPEC = >=3.10,<3.11
PORTROACH =limit:^3\.10
Index: 3.10/files/CHANGES.OpenBSD
===
RCS file: /cvs/ports/lang/python/3.10/files/CHANGES.OpenBSD,v
retrieving revision 1.13
diff -u -p -r1.13 CHANGES.OpenBSD
--- 3.10/files/CHANGES.OpenBSD 24 Apr 2023 11:15:43 - 1.13
+++ 3.10/files/CHANGES.OpenBSD 3 Mar 2024 15:24:58 -
@@ -19,5 +19,9 @@ compiler as passed to ports builds is /u
6. Use closefrom(2) instead of looping through all the file descriptors
and calling close(2) on them.
+7. ctypes' find_library is modified to pass "libc.so" to dlopen() rather
+than attempting to resolve a version number by parsing ldconfig -r output,
+which results in loading an incorrect version in some cases.
+
These changes are available in the OpenBSD CVS repository
<http://www.openbsd.org/anoncvs.html> in ports/lang/python/3.10.
Index: 3.10/patches/patch-Lib_ctypes_util_py
===
RCS file: 3.10/patches/patch-Lib_ctypes_util_py
diff -N 3.10/patches/patch-Lib_ctypes_util_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ 3.10/patches/patch-Lib_ctypes_util_py 3 Mar 2024 15:24:58 -
@@ -0,0 +1,20 @@
+allow dlopen() to search for libc rather than parsing ldconfig -r to
+decide on a version number.
+
+(would this make sense for all libraries? I'm not sure exactly what
+parameters this might be called with, whether it's just a bare name or
+could have a path/version in it).
+
+Index: Lib/ctypes/util.py
+--- Lib/ctypes/util.py.orig
Lib/ctypes/util.py
+@@ -204,6 +204,9 @@ elif os.name == "posix":
+ return nums or [sys.maxsize]
+
+ def find_library(name):
++if sys.platform.startswith("openbsd") and name == "c":
++return "libc.so"
++
+ ename = re.escape(name)
+ expr = r':-l%s\.\S+ => \S*/(lib%s\.\S+)' % (ename, ename)
+ expr = os.fsencode(expr)
Index: 3.11/Makefile
===
RCS file: /cvs/ports/lang/python/3.11/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- 3.11/Makefile 12 Feb 2024 00:53:52 - 1.14
+++ 3.11/Makefile 3 Mar 2024 15:24:58 -
@@ -4,6 +4,7 @@
# Python itself.
FULL_VERSION = 3.11.8
+REVISION = 0
SHARED_LIBS = python3.11 0.0
VERSION_SPEC = >=3.11,<3.12
PORTROACH =limit:^3\.11
Index: 3.11/files/CHANGES.OpenBSD
===
RCS file: /cvs/ports/lang/python/3.11/files/CHANGES.OpenBSD,v
retrieving revision 1.4
diff -u -p -r1.4 CHANGES.OpenBSD
--- 3.11/files/CHANGES.OpenBSD 24 Apr 2023 11:18:57 - 1.4
+++ 3.11/files/CHANGES.OpenBSD 3 Mar 2024 15:24:58 -
@@ -19,5 +19,9 @@ compiler as passed to ports builds is /u
6. Use closefrom(2) instead of looping through all the file descriptors
and calling close(2) on them.
+7. ctypes' find_library is modified to pass "libc.so" to dlopen() rather
+than attempting to resolve a version number by parsing ldconfig -r output,
+which results in loading an incorrect version in some cases.
+
These changes are available in the OpenBSD CVS repository
<http://www.openbsd.org/anoncvs.html> in ports/lang/python/3.11.
Index: 3.11/patches/patch-Lib_ctypes_util_py
===
RCS file: 3.11/patches/patch-Lib_ctypes_util_py
diff -N 3.11/patches/patch-Lib_ctypes_util_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ 3.11/patches/patch-Lib_ctypes_util_py 3 Mar 2024 15:24:58 -
@@ -0,0 +1,20 @@
+allow dlopen() to search for libc rather than parsing ldconfig -r to
+decide on a version number.
+
+(would this make sense for all libraries? I'm not sure exactly what
+parameters this might be called with, whether it's just a bare name or
+could have a path/version in it).
+
+Index: Lib/ctypes/util.py
+--- Lib/cty
Re: Gajim msyscall error
On 2024/03/03 07:59, Theo de Raadt wrote:
> Does it work if this is modified to just ask for "libc.so"?
Yes. Conservative approach just doing this for libc:
Index: Makefile
===
RCS file: /cvs/ports/lang/python/3.10/Makefile,v
retrieving revision 1.37
diff -u -p -r1.37 Makefile
--- Makefile14 Nov 2023 12:33:56 - 1.37
+++ Makefile3 Mar 2024 15:20:11 -
@@ -4,7 +4,7 @@
# Python itself.
FULL_VERSION = 3.10.13
-REVISION = 0
+REVISION = 1
SHARED_LIBS = python3.10 0.0
VERSION_SPEC = >=3.10,<3.11
PORTROACH =limit:^3\.10
Index: patches/patch-Lib_ctypes_util_py
===
RCS file: patches/patch-Lib_ctypes_util_py
diff -N patches/patch-Lib_ctypes_util_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Lib_ctypes_util_py3 Mar 2024 15:20:11 -
@@ -0,0 +1,20 @@
+allow dlopen() to search for libc rather than parsing ldconfig -r to
+decide on a version number.
+
+(would this make sense for all libraries? I'm not sure exactly what
+parameters this might be called with, whether it's just a bare name or
+could have a path/version in it).
+
+Index: Lib/ctypes/util.py
+--- Lib/ctypes/util.py.orig
Lib/ctypes/util.py
+@@ -204,6 +204,9 @@ elif os.name == "posix":
+ return nums or [sys.maxsize]
+
+ def find_library(name):
++if sys.platform.startswith("openbsd") and name == "c":
++return "libc.so"
++
+ ename = re.escape(name)
+ expr = r':-l%s\.\S+ => \S*/(lib%s\.\S+)' % (ename, ename)
+ expr = os.fsencode(expr)
Re: Gajim msyscall error
On 2024/03/03 14:29, Stuart Henderson wrote:
> On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> > On Sun, Mar 03, 2024 at 11:58:51AM +0000, Stuart Henderson wrote:
> > > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > > Is this a situation where two libc's are being loaded into the address
> > > > space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
> > >
> > > It seems the most likely cause. Console output from running with
> > > LD_DEBUG set in the environment would probably confirm (and would be
> > > more useful than kdump).
> >
> > See end of this mail.
> >
> > > I can't replicate it here on a system with new libc (I only tried
> > > starting gajim and poking in the UI, not connecting to any servers).
> >
> > ftr, I don't even get to the UI.
>
> Ah, I can replicate if I ldconfig -R.
>
> > > I'm a bit surprised why a mixture of libs would happen there at all
> > > (unless something had been rebuilt locally) but don't see another reason
> > > to hit the msyscall error.
> >
> > Nothing has been locally rebuilt.
> >
> > LD_DEBUG indeed shows that libc.so.98.0 is loaded and libc.so.99.0 is
> > attempted to load.
>
>
> > dlsym: gtk_get_minor_version in /usr/local/lib/libgtk-3.so.2201.0:
> > 0x17287b9f300
> > dlsym: gtk_get_micro_version in /usr/local/lib/libgtk-3.so.2201.0:
> > 0x17287b9f330
> > dlsym: pango_version_string in /usr/local/lib/libpango-1.0.so.3801.4:
> > 0x172ed038d60
> > dlopen: loading: libc.so.99.0
> > msyscall 1732a806000 a8000 error
>
> Coming from ...
>
> Breakpoint 1.1, dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at
> /usr/src/libexec/ld.so/dlfcn.c:64
> 64if (flags & ~OK_FLAGS) {
> (gdb) bt
> #0 dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at
> /usr/src/libexec/ld.so/dlfcn.c:64
> #1 0x098b93dc7d01 in py_dl_open () from
> /usr/local/lib/python3.10/lib-dynload/_ctypes.cpython-310.so
> #2 0x098bb0dc1bc1 in cfunction_call () from
> /usr/local/lib/libpython3.10.so.0.0
> #3 0x098bb0d6a132 in _PyObject_MakeTpCall () from
> /usr/local/lib/libpython3.10.so.0.0
>
>
> so something is doing dlopen("libc.so.99.0", RTLD_NOW) ...
>
> (gdb) py-bt
> Traceback (most recent call first):
>
> File "/usr/local/lib/python3.10/ctypes/__init__.py", line 374, in __init__
> self._handle = _dlopen(self._name, mode)
> File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 147, in
> _set_proc_title
> libc = CDLL(find_library('c'))
> File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 168, in
> run
> _set_proc_title()
> File "/usr/local/bin/gajim", line 8, in
> sys.exit(run())
>
> aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
> (without a specific version number). ld.so is picking the latest and
> loading it, but libc.so.98.0 was already loaded, so we hit msyscall
> error.
oh, it's not ld.so which is picking the latest version, it's python's
ctypes code, which parses the output of "ldconfig -r" to decide.
I don't think there's anything we can sanely do in ld.so to work
around this.
Re: Gajim msyscall error
On 2024/03/03 13:19, Lucas Gabriel Vuotto wrote:
> On Sun, Mar 03, 2024 at 11:58:51AM +0000, Stuart Henderson wrote:
> > On 2024/03/02 14:46, Theo de Raadt wrote:
> > > Is this a situation where two libc's are being loaded into the address
> > > space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc.
> >
> > It seems the most likely cause. Console output from running with
> > LD_DEBUG set in the environment would probably confirm (and would be
> > more useful than kdump).
>
> See end of this mail.
>
> > I can't replicate it here on a system with new libc (I only tried
> > starting gajim and poking in the UI, not connecting to any servers).
>
> ftr, I don't even get to the UI.
Ah, I can replicate if I ldconfig -R.
> > I'm a bit surprised why a mixture of libs would happen there at all
> > (unless something had been rebuilt locally) but don't see another reason
> > to hit the msyscall error.
>
> Nothing has been locally rebuilt.
>
> LD_DEBUG indeed shows that libc.so.98.0 is loaded and libc.so.99.0 is
> attempted to load.
> dlsym: gtk_get_minor_version in /usr/local/lib/libgtk-3.so.2201.0:
> 0x17287b9f300
> dlsym: gtk_get_micro_version in /usr/local/lib/libgtk-3.so.2201.0:
> 0x17287b9f330
> dlsym: pango_version_string in /usr/local/lib/libpango-1.0.so.3801.4:
> 0x172ed038d60
> dlopen: loading: libc.so.99.0
> msyscall 1732a806000 a8000 error
Coming from ...
Breakpoint 1.1, dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at
/usr/src/libexec/ld.so/dlfcn.c:64
64 if (flags & ~OK_FLAGS) {
(gdb) bt
#0 dlopen (libname=0x98b61cf06e0 "libc.so.99.0", flags=2) at
/usr/src/libexec/ld.so/dlfcn.c:64
#1 0x098b93dc7d01 in py_dl_open () from
/usr/local/lib/python3.10/lib-dynload/_ctypes.cpython-310.so
#2 0x098bb0dc1bc1 in cfunction_call () from
/usr/local/lib/libpython3.10.so.0.0
#3 0x098bb0d6a132 in _PyObject_MakeTpCall () from
/usr/local/lib/libpython3.10.so.0.0
so something is doing dlopen("libc.so.99.0", RTLD_NOW) ...
(gdb) py-bt
Traceback (most recent call first):
File "/usr/local/lib/python3.10/ctypes/__init__.py", line 374, in __init__
self._handle = _dlopen(self._name, mode)
File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 147, in
_set_proc_title
libc = CDLL(find_library('c'))
File "/usr/local/lib/python3.10/site-packages/gajim/main.py", line 168, in run
_set_proc_title()
File "/usr/local/bin/gajim", line 8, in
sys.exit(run())
aha: gajim is calling setproctitle via ctypes, which dlopen()'s libc.so
(without a specific version number). ld.so is picking the latest and
loading it, but libc.so.98.0 was already loaded, so we hit msyscall
error.
If you need to run it now you can workaround in this instance by editing
/usr/local/lib/python3.10/site-packages/gajim/main.py:
144 def _set_proc_title() -> None:
145 sysname = platform.system()
146 if sysname in ('Linux', 'FreeBSD', 'OpenBSD', 'NetBSD'):
147 libc = CDLL(find_library('c'))
e.g. remove OpenBSD from the "if sysname" line.
Re: Gajim msyscall error
On 2024/03/02 14:46, Theo de Raadt wrote: > Is this a situation where two libc's are being loaded into the address > space? And the 2nd one is refused for pinsyscalls & msyscall, etc etc. It seems the most likely cause. Console output from running with LD_DEBUG set in the environment would probably confirm (and would be more useful than kdump). I can't replicate it here on a system with new libc (I only tried starting gajim and poking in the UI, not connecting to any servers). > We solved that for most programs. Something special about python? Not sure. I assume it's because external Python modules are dlopen()'d and perhaps there could be some edge case in the "only load one libc" code in ld.so. I'm a bit surprised why a mixture of libs would happen there at all (unless something had been rebuilt locally) but don't see another reason to hit the msyscall error. > Stuart Henderson wrote: > > > On 2024/03/02 20:32, Lucas Gabriel Vuotto wrote: > > > gajim is reporting a msyscall error on launch since today's snapshot. > > > > This is likely to be fixed by updating to packages built against the new > > libc version when they're available. > > > > > OpenBSD 7.5 (GENERIC.MP) #46: Fri Mar 1 19:36:05 MST 2024 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > 99921 python3.10 CALL munmap(0xfbdb9aea778,0x6e8) > > > 99921 python3.10 RET munmap 0 > > > 99921 python3.10 CALL > > > pinsyscalls(0xfbdbb503000,0xa8000,0xfbdb71b7000,0x14b) > > > 99921 python3.10 RET pinsyscalls -1 errno 1 Operation not permitted > > > 99921 python3.10 CALL msyscall(0xfbdbb503000,0xa8000) > > > 99921 python3.10 RET msyscall -1 errno 1 Operation not permitted > > > 99921 python3.10 CALL write(2,0xfbe2e754020,0x21) > > > 99921 python3.10 GIO fd 2 wrote 33 bytes > > >"msyscall fbdbb503000 a8000 error > > >" > > > 99921 python3.10 RET write 33/0x21 > > > 99921 python3.10 CALL close(9) > > > 99921 python3.10 RET close 0 > > > 99921 python3.10 CALL > > > mmap(0,0x1000,0x3,0x1002,-1,0) > > > 99921 python3.10 RET mmap 17308774350848/0xfbe0358c000 > > > 99921 python3.10 CALL issetugid() > > > 99921 python3.10 PSIG SIGSEGV SIG_DFL code=SEGV_ACCERR > > > addr=0xfbdbb54cfcb trapno=0 > > > > > > I can share the full ktrace. egdb only shows a ?? traceback. Should I > > > try building the debug package for it? Last time I tried it with Gajim > > > it didn't provide much information as lot of things happened in > > > libraries. > > > > > > Lucas > > > > > >
Re: Gajim msyscall error
On 2024/03/02 20:32, Lucas Gabriel Vuotto wrote: > gajim is reporting a msyscall error on launch since today's snapshot. This is likely to be fixed by updating to packages built against the new libc version when they're available. > OpenBSD 7.5 (GENERIC.MP) #46: Fri Mar 1 19:36:05 MST 2024 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > 99921 python3.10 CALL munmap(0xfbdb9aea778,0x6e8) > 99921 python3.10 RET munmap 0 > 99921 python3.10 CALL pinsyscalls(0xfbdbb503000,0xa8000,0xfbdb71b7000,0x14b) > 99921 python3.10 RET pinsyscalls -1 errno 1 Operation not permitted > 99921 python3.10 CALL msyscall(0xfbdbb503000,0xa8000) > 99921 python3.10 RET msyscall -1 errno 1 Operation not permitted > 99921 python3.10 CALL write(2,0xfbe2e754020,0x21) > 99921 python3.10 GIO fd 2 wrote 33 bytes >"msyscall fbdbb503000 a8000 error >" > 99921 python3.10 RET write 33/0x21 > 99921 python3.10 CALL close(9) > 99921 python3.10 RET close 0 > 99921 python3.10 CALL > mmap(0,0x1000,0x3,0x1002,-1,0) > 99921 python3.10 RET mmap 17308774350848/0xfbe0358c000 > 99921 python3.10 CALL issetugid() > 99921 python3.10 PSIG SIGSEGV SIG_DFL code=SEGV_ACCERR addr=0xfbdbb54cfcb > trapno=0 > > I can share the full ktrace. egdb only shows a ?? traceback. Should I > try building the debug package for it? Last time I tried it with Gajim > it didn't provide much information as lot of things happened in > libraries. > > Lucas >
Re: panic: kernel diagnostic assertion "p->p_wchan == NULL" failed
Please try to re-type at least the most important bits from a screenshot so readers can quickly see which subsystems are involved. splassert: assertwaitok: want 0 have 4 assertion p->wchan == NULL failed, kern_sched.c line 373 active procs: openvpn wg_handshake softnet0 trace includes rw_enter, sleep_finish, noise_remote_ready, wg_qstart, ifq_serialize, hfsc_deferred On 2024/02/28 10:12, Marko Cupać wrote: > Hi, > > I have fairly busy CARP pair which serves as a hub for ~30 spokes which > tunnel to it over combination of GRE/IPSEC, tunnel mode ipsec and > wireguard. It also serves as host-to-site VPN concentrator for npppd, > openvpn and wireguard clients. Besides firewalling, pf also does prio > and queue, as well as pflow. There's also read-only snmpd for querying > interface statistics from another snmpd_exporter / prometheus / grafana > host. > > Yesterday one of the two crashed (7.4, syspatched up to 011_ssh). I have > attached photo (sorry I had no access to serial console). > > I'd be glad to provide more information. > > Below's dmesg. > > OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17027289088 (16238MB) > avail mem = 16491524096 (15727MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x788c5000 (241 entries) > bios0: vendor HP version "P89" date 11/23/2021 > bios0: HP ProLiant DL360 Gen9 > efi0 at bios0: UEFI 2.4 > efi0: HP rev 0x25c00 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S5 > acpi0: tables DSDT FACP UEFI MCEJ SSDT HEST BERT ERST EINJ BGRT HPET PMCT > WDDT APIC MCFG SLIT SRAT SPMI RASF SPCR MSCT BDAT PCCT DMAR SSDT SSDT SSDT > acpi0: wakeup devices PEX4(S4) BR05(S4) BR03(S4) BR07(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.01 MHz, 06-4f-01, patch > 0b40 > 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 10MB 64b/line 20-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.02 MHz, 06-4f-01, patch > 0b40 > 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 10MB 64b/line 20-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.07 MHz, 06-4f-01, patch > 0b40 > 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 10MB 64b/line 20-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.06 MHz, 06-4f-01, patch > 0b40 > cpu3: >
Re: Kernel crash on Thinkpad X1 Carbon
On 2024/02/23 10:44, open...@huttu.net wrote: > >Description: > Trying to power off the system, the kernel crashes. I was trying to > debug why 4/8 cores are offline. I can answer the second bit - i7-1165G7 has 4 cores not 8 - the others are smt (hyperthreading) pseudo-cores which are disabled by default.
Re: unveil on MFS
On 2024/02/19 23:00, hahahahacker2009 wrote: > I cannot reproduce the problem with your code If I mount an MFS /usr/obj *over the top* of an existing FFS /usr/obj then I can reproduce it, but not with MFS mounted on /mnt, /mnt/1, /usr/obj/1
Re: "kbd -l" -> wskbd_displayioctl_sc uvm_fault
On 2024/02/16 16:04, Miod Vallat wrote: > > Diff does fix the crash - > > > > # kbd -l > > tables available for pc-xt/pc-at keyboard: > > encoding > > Do you have machdep.forceukbd=1 somewhere in /etc/sysctl.conf? Ah, yes! And there's no USB keyboard now, I added that when the disk was in a real machine before I moved it to a VM.
Re: "kbd -l" -> wskbd_displayioctl_sc uvm_fault
On 2024/02/15 14:53, Stuart Henderson wrote: > On 2024/02/13 08:44, Miod Vallat wrote: > > > Does this help? > > > > > > diff --git sys/dev/wscons/wskbd.c sys/dev/wscons/wskbd.c > > > index 7631cd5f701..dd65f61ce63 100644 > > > --- sys/dev/wscons/wskbd.c > > > +++ sys/dev/wscons/wskbd.c > > > @@ -1229,7 +1229,10 @@ getkeyrepeat: > > > > > > case WSKBDIO_GETENCODINGS: > > > uedp = (struct wskbd_encoding_data *)data; > > > - for (count = 0; sc->id->t_keymap.keydesc[count].name; count++) > > > + for (count = 0; > > > + sc->id->t_keymap.keydesc != NULL && > > > + sc->id->t_keymap.keydesc[count].name; > > > + count++) > > > ; > > > if (uedp->nencodings > count) > > > uedp->nencodings = count; > > > > > > > This ought to fix the panic Stuart is getting. > > > > However I don't understand how t_keymap.keydesc can be a NULL pointer > > (yet it obviousl was); it is initialized at wskbd attachment time with > > valid data. > > > > Stuart, did you issue specific wsconsctl or wsconscfg operations in this > > VM prior to running 'kbd -l'? What are the contents of > > /etc/wsconsctl.conf, if it exists? > > wsconsctl.conf has this: > > keyboard.map+="keycode 57 = Control_L" It still crashes with that commented-out. > I haven't tried the diff yet, I need to clear out the sessions open on > that machine first (and make sure as many daemons as possible are shut > down, it usually suffers quite badly from fs problems after crashes). Diff does fix the crash - # kbd -l tables available for pc-xt/pc-at keyboard: encoding #
Re: iwx obtains IP via DHCP but no traffic
On 2024/02/16 10:13, Stefan Sperling wrote:
> Tne driver uses the lowest basic rate anncounced by the AP:
>
> const struct iwx_rate *
> iwx_tx_fill_cmd(struct iwx_softc *sc, struct iwx_node *in,
> struct ieee80211_frame *wh, uint16_t *flags, uint32_t *rate_n_flags)
> {
> [...]
> int min_ridx = iwx_rval2ridx(ieee80211_min_basic_rate(ic));
>
> This rate will be used for broadcast frames, which include DHCP requests.
..so one reason to disable lower rates might be on networks with higher
expected levels of broadcast(/multicast)
> One reason to keep 6 Mbps disabled would be many APs on the same channel,
> so many that their collective beacons sent at 6 Mbps use up all available
> air time, leaving no time for actual data. But unless you're running something
> like a CCC congress this limitation won't apply ;)
Besides the airtime saving in very dense environments, another reason
would be in a less dense environment (but still with multiple APs on the
same channel), to discourage STAs from remaining associated with a more
distant AP - say a STA is right at the edge of range of an AP, but near
another AP on the same channel - even if the first AP's transmissions
don't cause co-channel interference (say, the power is fairly low to
avoid this), the *STA's* transmissions can do.
So probably not so useful on a typical home setup where you'd usually
have no more than a coupke of APs and none co-channel, it could make
sense for say a medium-density office environment (especially on 2GHz).
https://divdyn.com/disable-lower-legacy-data-rates/ seems quite a good
write-up.
Also: regardless of whether it really makes sense for a given network,
sometimes a network operator will do this anyway and as a user you have
no control over it - and based on Kirill's description this seems a
regression since 7.4?
Re: "kbd -l" -> wskbd_displayioctl_sc uvm_fault
On 2024/02/13 08:44, Miod Vallat wrote: > > Does this help? > > > > diff --git sys/dev/wscons/wskbd.c sys/dev/wscons/wskbd.c > > index 7631cd5f701..dd65f61ce63 100644 > > --- sys/dev/wscons/wskbd.c > > +++ sys/dev/wscons/wskbd.c > > @@ -1229,7 +1229,10 @@ getkeyrepeat: > > > > case WSKBDIO_GETENCODINGS: > > uedp = (struct wskbd_encoding_data *)data; > > - for (count = 0; sc->id->t_keymap.keydesc[count].name; count++) > > + for (count = 0; > > +sc->id->t_keymap.keydesc != NULL && > > +sc->id->t_keymap.keydesc[count].name; > > +count++) > > ; > > if (uedp->nencodings > count) > > uedp->nencodings = count; > > > > This ought to fix the panic Stuart is getting. > > However I don't understand how t_keymap.keydesc can be a NULL pointer > (yet it obviousl was); it is initialized at wskbd attachment time with > valid data. > > Stuart, did you issue specific wsconsctl or wsconscfg operations in this > VM prior to running 'kbd -l'? What are the contents of > /etc/wsconsctl.conf, if it exists? wsconsctl.conf has this: keyboard.map+="keycode 57 = Control_L" I haven't tried the diff yet, I need to clear out the sessions open on that machine first (and make sure as many daemons as possible are shut down, it usually suffers quite badly from fs problems after crashes).
Re: Super Slow Bug
On 2024/02/08 19:50, Dragonking wrote: > I dont feel like adding all the context because it spans two reddit posts, that's not a great attitude to have when you're asking for help :( > whoever gets this email sorry but here the reddit posts are: > https://www.reddit.com/r/openbsd/comments/1afi7f6/cpu_cores_not_evenly_distributing_load/ > https://www.reddit.com/r/openbsd/comments/1akc4no/openbsd_read_and_write_speeds_terribly_slow/ The reddit posts are not really helpful but basically it's "machine is very slow, same whether X is running or not". > bios0: vendor American Megatrends International, LLC. version "FA617NS.410" > date 06/15/2023 > bios0: ASUSTeK COMPUTER INC. ASUS TUF Gaming A16 FA617NS_FA617NS > efi0 at bios0: UEFI 2.8 > efi0: American Megatrends rev 0x50018 First off, there's a newer BIOS available (414), I would try updating and see if that improves things. Observations: - cpu0 spending nearly all time in intr (so it is not surprising that there's high cpu time waiting for the kernel lock i.e. "spin" on other cpus) load averages: 0.58, 1.36, 1.24openbased.hsd1.fl.comcast.net 19:40:02 163 processes: 147 idle, 16 on processor up 0 days 00:12:44 CPU00 states: 0.0% user, 0.0% nice, 0.1% sys, 7.4% spin, 92.3% intr, 0.2% idle CPU02 states: 1.2% user, 0.0% nice, 3.7% sys, 30.8% spin, 0.0% intr, 64.4% idle CPU04 states: 0.9% user, 0.0% nice, 3.3% sys, 24.7% spin, 0.0% intr, 71.1% idle CPU06 states: 0.9% user, 0.0% nice, 2.5% sys, 21.5% spin, 0.0% intr, 75.1% idle CPU08 states: 0.7% user, 0.0% nice, 1.6% sys, 15.3% spin, 0.0% intr, 82.4% idle CPU10 states: 0.6% user, 0.0% nice, 1.2% sys, 12.4% spin, 0.0% intr, 85.7% idle CPU12 states: 0.6% user, 0.0% nice, 1.1% sys, 11.3% spin, 0.0% intr, 87.1% idle CPU14 states: 0.6% user, 0.0% nice, 1.1% sys, 8.9% spin, 0.0% intr, 89.4% idle - the interrupt rate on amdgpio seems suspicious? interrupt total rate irq96/amdgpio0 703592 920 irq97/dwiic0 260 irq144/amdgpu0 9030 11 irq103/nvme041866 54 irq114/re0 32297 42 irq107/nvme1 1120 irq145/amdgpu1 310 irq110/xhci1 35604 irq176/azalia2 10 irq111/xhci2 230 irq146/pckbc0 80 irq0/clock2363936 3094 irq0/ipi 547358 716 Total 3701840 4845
"kbd -l" -> wskbd_displayioctl_sc uvm_fault
I hit this after running "kbd -l". On this machine (VM) the keyboard is
not responsive in DDB so I can't get any more from it.
uvm_fault(0xfd8073ad8a10, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at wskbd_displayioctl_sc+0x1b9:cmpl$0,0(%rcx,%rsi,8)
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
243085 96740667 0x1802 04 perl
513689 69079667 0x1802 05 check_dns
* 62677 84076 0 0x803 03K kbd
wskbd_displayioctl_sc(801f8600,c0105715,80003171a990,2,800032003aa8,0)
at wskbd_displayioctl_sc+0x1b9
wskbd_do_ioctl_sc(801f8600,c0105715,80003171a990,2,800032003aa8,0)
at wskbd_do_ioctl_sc+0xba
wskbdioctl(4300,c0105715,80003171a990,2,800032003aa8) at wskbdioctl+0x4e
VOP_IOCTL(fd8134b59dc0,c0105715,80003171a990,2,fd8034ef8e58,800032003aa8)
at VOP_IOCTL+0x5d
vn_ioctl(fd807961ce20,c0105715,80003171a990,800032003aa8) at
vn_ioctl+0x79
sys_ioctl(800032003aa8,80003171aa90,80003171aaf0) at sys_ioctl+0x2af
syscall(80003171ab80) at syscall+0x5e3
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x70d9d6640370, count: 7
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{3}>
OpenBSD 7.4-current (GENERIC.MP) #1636: Sun Jan 28 23:10:14 MST 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8572985344 (8175MB)
avail mem = 8292384768 (7908MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5a00 (10 entries)
bios0: vendor SeaBIOS version "rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org"
date 04/01/2014
bios0: QEMU Standard PC (Q35 + ICH9, 2009)
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3920.28 MHz, 19-50-00
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,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu0: 512KB 64b/line 16-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 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3920.39 MHz, 19-50-00
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,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu1: 512KB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3921.95 MHz, 19-50-00
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,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,CPCTR,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBRS,IBPB,STIBP,SSBD,IBPB,IBRS,STIBP,SSBD,VIRTSSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache
cpu2: 512KB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Ryzen 5 PRO 5650G with Radeon Graphics, 3923.05 MHz, 19-50-00
cpu3:
Re: odd pf divert-packet problem
On 2024/02/08 09:19, Peter J. Philipp wrote: > > On 2/7/24 20:15, Janne Johansson wrote: > > > pass in log quick on wg1 inet proto udp from 192.168.178.1 to any port = > > > 5060 sc > > > rub (reassemble tcp) divert-packet port 2 > > The mix of udp and tcp reassembly seems interesting there. > > Yeah it does, but it is added on both stern (which works) > and superpod (which doesn't). Since this is not such a big > problem I'm gonna rest on it, and perhaps move the > divert'ing entirely to stern. The reason being is that the > incoming SIP packets are not fragmented, as they are not > really (or ever) big enough. So my phone setup works on > SDP'ing outgoing SIP packets. I think that's a red herring. "reassemble tcp" is poorly named and does not actually deal with reassembling fragmented packets, see the paragraphs following this in pf.conf(5) - reassemble tcp Statefully normalises TCP connections. reassemble tcp performs the following normalisations: the things done by "reassemble tcp" *only* apply to TCP packets. > In other works there is no way to remove the reassemble tcp > scrub option as it's not in my rules to begin with. It is added automatically for divert-packet rules. I would start by adding "match log(matches)" to the top of pf.conf and monitor the pflog0 interface to make sure packets are matched by the intended rules. (tcpdump -neipflog0)
Re: OpenBSD 7.4/amd64 on APU4D4 - kernel panic
On 2024/01/28 15:14, Radek wrote: > In this case UPS is handled by uhid but I need it to be handeled by ugen. > How can I make it work without rebuilding the kernel? > Disabling unidev in /etc/bsd.re-config doesn't work in this case. "uhidev" not "unidev", > On Sat, 27 Jan 2024 18:48:48 + > Stuart Henderson wrote: > > > On 2024/01/27 10:36, Radek wrote: > > > but it doesn't work for another APC UPS hardware > > > > > uhidev0 at uhub0 port 3 configuration 1 interface 0 "American Power > > > Conversion Smart-UPS 2200 FW:UPS 09.3 / ID=18" rev 2.00/1.06 addr 2 > > > > ... > > > > > > > On 2024-01-19 13:21, Stuart Henderson wrote: > > > > > > ...actually, maybe it needs to be "disable uhidev". > > > > ^^ > > > > > Radek >
Re: OpenBSD 7.4/amd64 on APU4D4 - kernel panic
On 2024/01/27 10:36, Radek wrote: > but it doesn't work for another APC UPS hardware > uhidev0 at uhub0 port 3 configuration 1 interface 0 "American Power > Conversion Smart-UPS 2200 FW:UPS 09.3 / ID=18" rev 2.00/1.06 addr 2 ... > > > On 2024-01-19 13:21, Stuart Henderson wrote: > > > > ...actually, maybe it needs to be "disable uhidev". ^^
Re: Trouble with console on UART
On 2024/01/28 00:20, stephane Tranchemer wrote: > Got it ! > > I had a hunch so I modified all the tty0X the same way as tty00 to see if > someone answers: > > tty00 "/usr/libexec/getty std.115200" vt220on secure > > and I got a tty at next reboot. > However I find myself on tty04, so it would mean that com4 goes invariably to > tty04 even if this port is the only com port I do have on my system as show > by dmesg? > I would have expected to have it on tty00. on amd64/i386, 00 to 03 are reserved for serial ports at specific known addresses (0x3f8, 0x3e8, 0x2f8, 0x2e8). dynamically attached ports have higher numbers.
Re: String of emojis and IRC color codes crashes tmux
On 2024/01/24 15:58, George Koehler wrote: > On Wed, 24 Jan 2024 09:20:41 + > Stuart Henderson wrote: > > > On 2024/01/23 23:12, Luiz de Milon wrote: > > > When the following file is `cat`ed in tmux, the server > > > crashes. This also messes up the rendering in weechat, so I > > > believe the bug may be in ncurses rather than tmux. > > > > That seems likely - I can reproduce it in 7.4 but not -current (which > > has newer curses). > > This is a tmux bug; nicm fixed it in tmux/screen-write.c r1.224 > 2023/10/30 "Do not allow UTF-8 characters that are too long, GitHub > issue 3729." This fix is in -current but not 7.4. > > A simple reproducer is > $ perl -CS -e 'print chr(0x1f1e6) x 6' > > or any utf-8 string of 6 characters from U+1F1E6 to U+1F1FF > (regional indicator symbol letters A to Z). > > https://github.com/tmux/tmux/issues/3729 > Oh, looks like the tmux issue is the thing fixed in syspatch 7.4-005. That wouldn't account for weechat though.
Re: String of emojis and IRC color codes crashes tmux
On 2024/01/23 23:12, Luiz de Milon wrote:
> To: bugs@openbsd.org
> Subject: String of emojis and IRC color codes crashes tmux
> From: hiriga...@riseup.net
> Cc: hiriga...@riseup.net
> Reply-To: hiriga...@riseup.net
>
> >Synopsis: String of emojis and IRC color codes crashes
> tmux (and has issues with ncurses)
> >Category: library
> >Environment:
> System : OpenBSD 7.4
> Details : OpenBSD 7.4 (GENERIC.MP) #1396: Sun Oct 8
> 09:20:40 MDT 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> Architecture: OpenBSD.amd64
> Machine : amd64
> >Description:
> When the following file is `cat`ed in tmux, the server
> crashes. This also messes up the rendering in weechat, so I
> believe the bug may be in ncurses rather than tmux.
That seems likely - I can reproduce it in 7.4 but not -current (which
has newer curses).
> ~ $ hexdump -C this-crashes
> f0 9f 87 a8 f0 9f 87 b2 f0 9f 87 b6 f0 9f 87
> af ||
> 0010 f0 9f 87 b2 f0 9f 87 a7 0a |.|
> 0019
> ~ $ hexdump -C this-does-not
> f0 9f 87 b2 f0 9f 87 b6 f0 9f 87 af f0 9f 87
> b2 ||
> 0010 f0 9f 87 a7 0a |.|
> 0015
Here's a uuencoded version to make it easier if someone else wants to
replicate.
begin 644 this-crashes
9\)^'J/"?A[+PGX>V\)^'K_"?A[+PGX>G"@``
`
end
> Here's a ktrace output of the server, up to the crash. I
> input `cat this-crashes` and pressed enter, and then
> tmux exited with "server exited unexpectedly" and after
> that, i have to `reset` because my terminal stops behaving
> correctly. (it seems like it gets fixed to a certain length,
> i get long lines ending with % after it crashes, after any
> command, such as ls. ls -l also does not align properly,
> etc. etc.)
>
>
> 23866 tmux STRU struct kevent { ident=5,
> filter=EVFILT_READ, flags=0x1, fflags=0<>, data=1,
> udata=0xd88d19387b8 }
> 23866 tmux RET kevent 1
> 23866 tmux CALL clock_gettime(CLOCK_MONOTONIC,0x7c8f3fea64e0)
> 23866 tmux STRU struct timespec { 2158618.909373185 }
> 23866 tmux RET clock_gettime 0
> 23866 tmux CALL ioctl(5,FIONREAD,0x7c8f3fea641c)
> 23866 tmux RET ioctl 0
> 23866 tmux CALL read(5,0xd88c139aa00,0x1)
> 23866 tmux GIO fd 5 read 1 bytes
> "c"
> 23866 tmux RET read 1
> 23866 tmux CALL gettimeofday(0x7c8f3fea64d0,0)
> 23866 tmux STRU struct timeval { 1706063732<"Jan 24
> 02:35:32 2024">.173102 }
> 23866 tmux RET gettimeofday 0
> 23866 tmux CALL gettimeofday(0x7c8f3fea6410,0)
> 23866 tmux STRU struct timeval { 1706063732<"Jan 24
> 02:35:32 2024">.173107 }
> 23866 tmux RET gettimeofday 0
> 23866 tmux CALL gettimeofday(0xd88d19385f0,0)
> 23866 tmux STRU struct timeval { 1706063732<"Jan 24
> 02:35:32 2024">.173112 }
> 23866 tmux RET gettimeofday 0
> 23866 tmux CALL kbind(0x7c8f3fea61b8,24,0xdcc9ee19dd2aa3fc)
> 23866 tmux RET kbind 0
> 23866 tmux CALL kbind(0x7c8f3fea6178,24,0xdcc9ee19dd2aa3fc)
> 23866 tmux RET kbind 0
> 23866 tmux CALL clock_gettime(CLOCK_MONOTONIC,0x7c8f3fea64e0)
> 23866 tmux STRU struct timespec { 2158618.909505995 }
> 23866 tmux RET clock_gettime 0
> 23866 tmux CALL clock_gettime(CLOCK_MONOTONIC,0x7c8f3fea64e0)
> 23866 tmux STRU struct timespec { 2158618.909509964 }
> 23866 tmux RET clock_gettime 0
> 23866 tmux CALL
> kevent(4,0xd88c1389000,1,0xd88c1376800,64,0x7c8f3fea6438)
> 23866 tmux STRU struct timespec { 10.790533000 }
> 23866 tmux STRU struct kevent { ident=8,
> filter=EVFILT_WRITE, flags=0x11,
> fflags=0<>, data=0, udata=0xd88a5e6b508 }
> 23866 tmux STRU struct kevent { ident=8,
> filter=EVFILT_WRITE, flags=0x11,
> fflags=0<>, data=8192, udata=0xd88a5e6b508 }
> 23866 tmux RET kevent 1
> 23866 tmux CALL clock_gettime(CLOCK_MONOTONIC,0x7c8f3fea64e0)
> 23866 tmux STRU struct timespec { 2158618.909524839 }
> 23866 tmux RET clock_gettime 0
> 23866 tmux CALL kbind(0x7c8f3fea6398,24,0xdcc9ee19dd2aa3fc)
> 23866 tmux RET kbind 0
> 23866 tmux CALL write(8,0xd88c139a300,0x1)
> 23866 tmux GIO fd 8 wrote 1 bytes
> "c"
> 23866 tmux RET write 1
> 23866 tmux CALL gettimeofday(0x7c8f3fea64d0,0)
> 23866 tmux STRU struct timeval { 1706063732<"Jan 24
> 02:35:32 2024">.173576 }
> 23866 tmux RET gettimeofday 0
> 23866 tmux CALL clock_gettime(CLOCK_MONOTONIC,0x7c8f3fea64e0)
> 23866 tmux STRU struct timespec { 2158618.909899176 }
> 23866 tmux RET clock_gettime 0
> 23866 tmux CALL clock_gettime(CLOCK_MONOTONIC,0x7c8f3fea64e0)
> 23866 tmux STRU struct timespec { 2158618.909904195 }
> 23866 tmux RET clock_gettime 0
> 23866 tmux CALL kevent(4,0,0,0xd88c1376800,64,0x7c8f3fea6438)
> 23866 tmux STRU struct timespec { 10.790139000 }
> 23866 tmux STRU
Re: pf.conf: modifier :0 doesn't work for IPv6 addresses
On 2024/01/19 20:05, Peter Hessler wrote: > Thinking out loud, ignore addresses with scopeid (link-local), and > deprecated, then pick the zero-th address. For places where "(iface:0)" is actually used, which I think is mainly translation rules, we pretty much always _only_ want to use addresses with global scope (neither ULA nor link-local nor deprecated). For translation rules, if ULA was wanted then I'd expect to specify the address directly. (And PF doesn't really cope with link-locals anyway afaik). For just "(iface)" with no modifier (which is more useful as a from/to address in filters/matches rather than a translation address) I think we need to include all of those.
Re: OpenBSD 7.4/amd64 on APU4D4 - kernel panic
On 2024/01/19 13:15, Stuart Henderson wrote:
> On 2024/01/19 13:27, Radek wrote:
> > I'm not using any USB keyboard but I need USB port to manage APC UPS
> > connected by USB cable (apcupsd).
>
> Yes exactly.
...actually, maybe it needs to be "disable uhidev".
Point is that if you don't need other uhid devices to be handled
by kernel drivers, you can disable the driver, and they'll fallback
to being handled by ugen - same as is done more selectively by the
patch.
And by not using the patch, you can use a standard downloaded
kernel avoiding the need to rebuild on a relatively slow
machine - and, assuming you want to move back onto normal releases
later, you'll then be able to use syspatch.
> > On Fri, 19 Jan 2024 11:05:13 +
> > Stuart Henderson wrote:
> >
> > > On 2024/01/19 08:32, Radek wrote:
> > > > > It looks like you are running 7.4 release with a self compiled
> > > > > kernel.
> > > > True, is it GENERIC kernel compiled with usb APC UPS support, the rest
> > > > is untouched.
> > > > [root@@krz74~:]grep APC /usr/src/sys/dev/usb/usb_quirks.c
> > > > { USB_VENDOR_APC, USB_PRODUCT_APC_UPS, ANY, { UQ_BAD_HID }},
> > > > { USB_VENDOR_APC, USB_PRODUCT_APC_UPS5G, ANY, { UQ_BAD_HID }},
> > >
> > > btw, for this case (headless machine so no real need for a USB
> > > keyboard), you may be able to simply "disable uhid" in bsd.re-config(5)
> > > and avoid the need to recompile kernels.
> > >
> >
> >
> > Radek
> >
>
Re: OpenBSD 7.4/amd64 on APU4D4 - kernel panic
On 2024/01/19 13:27, Radek wrote:
> I'm not using any USB keyboard but I need USB port to manage APC UPS
> connected by USB cable (apcupsd).
Yes exactly.
> On Fri, 19 Jan 2024 11:05:13 +
> Stuart Henderson wrote:
>
> > On 2024/01/19 08:32, Radek wrote:
> > > > It looks like you are running 7.4 release with a self compiled
> > > > kernel.
> > > True, is it GENERIC kernel compiled with usb APC UPS support, the rest is
> > > untouched.
> > > [root@@krz74~:]grep APC /usr/src/sys/dev/usb/usb_quirks.c
> > > { USB_VENDOR_APC, USB_PRODUCT_APC_UPS, ANY, { UQ_BAD_HID }},
> > > { USB_VENDOR_APC, USB_PRODUCT_APC_UPS5G, ANY, { UQ_BAD_HID }},
> >
> > btw, for this case (headless machine so no real need for a USB
> > keyboard), you may be able to simply "disable uhid" in bsd.re-config(5)
> > and avoid the need to recompile kernels.
> >
>
>
> Radek
>
Re: OpenBSD 7.4/amd64 on APU4D4 - kernel panic
On 2024/01/19 08:32, Radek wrote:
> > It looks like you are running 7.4 release with a self compiled
> > kernel.
> True, is it GENERIC kernel compiled with usb APC UPS support, the rest is
> untouched.
> [root@@krz74~:]grep APC /usr/src/sys/dev/usb/usb_quirks.c
> { USB_VENDOR_APC, USB_PRODUCT_APC_UPS, ANY, { UQ_BAD_HID }},
> { USB_VENDOR_APC, USB_PRODUCT_APC_UPS5G, ANY, { UQ_BAD_HID }},
btw, for this case (headless machine so no real need for a USB
keyboard), you may be able to simply "disable uhid" in bsd.re-config(5)
and avoid the need to recompile kernels.
Re: rw_enter: netlock locking against myself, 7.4+errata007, hyper-v hvn((4)
On 2024/01/02 23:49, Stuart Henderson wrote:
> On 2024/01/02 20:02, Vitaliy Makkoveev wrote:
> > On Tue, Jan 02, 2024 at 03:45:10PM +0000, Stuart Henderson wrote:
> > > Badly OCR'd and manually quickly corrected screen capture below
> > > (tesseract doesn't do _at all_ well with digits and the spleen font),
> > > originals at
> > >
> > > https://junkpile.org/hv-panic-202401-1.png
> > > https://junkpile.org/hv-panic-202401-2.png
> > > https://junkpile.org/hv-panic-202401-3.png
> > >
> > > This is a VM running under hyper-v running 7.4+errata007 (i.e. it _does_
> > > have the "A network buffer that had to be split at certain length could
> > > crash the kernel" fix).
> > >
> > > Running postfix, librenms (PHP etc calling snmp tools quite a lot),
> > > rrdcached.
> > >
> > > Nothing unusual happening at the time of crash. Uptime prior to this
> > > was 3 weeks 3 days after it was updated to 7.4. (Before that, uptime
> > > on 7.3 was 5 months +).
> > >
> > > The only slightly unusual thing about this install is that there are two
> > > hvn(4) virtual nics.
> > >
> >
> > Does this help?
>
> Given that it took a month to crash, how long do you think I'd need to
> run before I could say whether it helps?
Oh well; it very much didn't help :-)
Uncorrected OCR, followed by dmesg.
starting RPC daemons: .
savecore: no core dump
checking quotas: done.
clearing tmp
kern.securelevel: 0 -> 1
creating runtime link editor directory cache.
preserving editor files.
starting netuork daemons: sshd snmpd tftpd sndiod.
starting package daenons: nginx mysqld smokepinguum fault (Oxtffrfrrte2so1c4s,
Ox
20, 0, 1) ->e€
kernel: page fault trap, code-0
Stopped at mtx_enter_try+0x42: movl — OxB(érdi), vedi
TID PID UID —-PRFLAGS~—PFLAGS- CPU COMMAND
ntx_enter_try(18) at mtx_enter_try+0x4Z
ntx_enter (18) at mtx_enter+0x35,
task_add(0,8008f728) at task_add+0x3b
hy_event_intr(8008d000) at hy_event_intr+Ox1e3
hy_intrO at hy_intr+Oxia
Xresume_hyperv_upcall© at Xresume_hypery_upcal+0x2?
acpicpu_idle() at acpicpu_idle+0xz81
sched_idle(frfrrfffrazdadff0) at sched_idle+0xz62z
end trace frame: x0, count: 7
https://uwuopenbsd .org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{O>
Now putting filesystems back together...
OpenBSD 7.4-stable (GENERIC.MP) #0: Wed Jan 3 13:23:38 GMT 2024
sthen@xxx:/home/sthen/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6064898048 (5783MB)
avail mem = 5861355520 (5589MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf8ec0 (216 entries)
bios0: vendor American Megatrends Inc. version "090006" date 04/28/2016
bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihve0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz, 3192.58 MHz, 06-55-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,AVX512CD,AVX512BW,AVX512VL,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XSAVES,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
16-way L2 cache, 24MB 64b/line 11-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz, 3192.57 MHz, 06-55-04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,AVX512CD,AVX512BW,AVX512VL,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XSAVES,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
16-way L2 cache, 24MB 64b/line 11-way L3 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com1 at acpi0 UAR2
Re: rw_enter: netlock locking against myself, 7.4+errata007, hyper-v hvn((4)
On 2024/01/02 20:02, Vitaliy Makkoveev wrote:
> On Tue, Jan 02, 2024 at 03:45:10PM +0000, Stuart Henderson wrote:
> > Badly OCR'd and manually quickly corrected screen capture below
> > (tesseract doesn't do _at all_ well with digits and the spleen font),
> > originals at
> >
> > https://junkpile.org/hv-panic-202401-1.png
> > https://junkpile.org/hv-panic-202401-2.png
> > https://junkpile.org/hv-panic-202401-3.png
> >
> > This is a VM running under hyper-v running 7.4+errata007 (i.e. it _does_
> > have the "A network buffer that had to be split at certain length could
> > crash the kernel" fix).
> >
> > Running postfix, librenms (PHP etc calling snmp tools quite a lot),
> > rrdcached.
> >
> > Nothing unusual happening at the time of crash. Uptime prior to this
> > was 3 weeks 3 days after it was updated to 7.4. (Before that, uptime
> > on 7.3 was 5 months +).
> >
> > The only slightly unusual thing about this install is that there are two
> > hvn(4) virtual nics.
> >
>
> Does this help?
Given that it took a month to crash, how long do you think I'd need to
run before I could say whether it helps?
> ===
> RCS file: /cvs/src/sys/dev/pv/hypervic.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 hypervic.c
> --- sys/dev/pv/hypervic.c 23 Sep 2023 13:01:12 - 1.20
> +++ sys/dev/pv/hypervic.c 2 Jan 2024 17:00:24 -
> @@ -203,13 +203,18 @@ hv_attach_icdevs(struct hv_softc *sc)
>
> dv->dv_ch = ch;
>
> - /*
> - * These services are not performance critical and
> - * do not need batched reading. Furthermore, some
> - * services such as KVP can only handle one message
> - * from the host at a time.
> - */
> - dv->dv_ch->ch_flags &= ~CHF_BATCHED;
> + if (dv->dv_handler == hv_kvp) {
> + /* XXXSMP: always run through task */
> + dv->dv_ch->ch_flags |= CHF_BATCHED;
> + } else {
> + /*
> + * These services are not performance critical and
> + * do not need batched reading. Furthermore, some
> + * services such as KVP can only handle one message
> + * from the host at a time.
> + */
> + dv->dv_ch->ch_flags &= ~CHF_BATCHED;
> + }
>
> if (dv->dv_attach && dv->dv_attach(dv) != 0)
> continue;
>
rw_enter: netlock locking against myself, 7.4+errata007, hyper-v hvn((4)
Badly OCR'd and manually quickly corrected screen capture below
(tesseract doesn't do _at all_ well with digits and the spleen font),
originals at
https://junkpile.org/hv-panic-202401-1.png
https://junkpile.org/hv-panic-202401-2.png
https://junkpile.org/hv-panic-202401-3.png
This is a VM running under hyper-v running 7.4+errata007 (i.e. it _does_
have the "A network buffer that had to be split at certain length could
crash the kernel" fix).
Running postfix, librenms (PHP etc calling snmp tools quite a lot),
rrdcached.
Nothing unusual happening at the time of crash. Uptime prior to this
was 3 weeks 3 days after it was updated to 7.4. (Before that, uptime
on 7.3 was 5 months +).
The only slightly unusual thing about this install is that there are two
hvn(4) virtual nics.
hvs1: short read: 48
panic: rw_enter: netlock locking against myself
Stopped at db_enter+0x14: popq %rbp
TID PID UID —-PRFLAGS =~ PFLAGS CPU. COMMAND
*388963 11506 755 0x2 0 0 snmpbulkualk
320140 61046 0 0x14000 0x200 1 reaper
db_enter() at db_enter+0x14
panic(820ebaaa) at panic+0xc3
rw_enter(824bd2d0,2) at rw_enter+0x252
hv_kvp(8248d738) at hv_kvp+0x705
hv_event_intr(8008d000) at hv_event_intr+0x1ab
hv_intr() at hv_intr+0x1a
Xresume_hyperv_upcall() at Xresume_hyperv_upcall+0x27
Xspllower() at Xspllower+0x1d
task_add (80036200,801533c0) at task_add+0x83
if_enqueue_ifq(80153060,ffd80f6642900) at if_enqueue_ifq+0x6f
ether_output(80153060,fffd80f6642900,fd80c8ef5c78,fd811e6414d8)
at ether_output+0x82
if_output_tso(80153060,fff800025395d08,fd80c8ef5c78,fd811e6414d8,5dc)
at if_output_tso+0xe1
ip_output(fd80f6642900,0,fd80c8ef5c68,0,0,fd80c8ef5bf0,1da98542b9d8f733)
at ip_output+0x817
udp_output(fd80c8ef5bf0,fd80b468b400,fd80ac452c00,0) at
udp_output+0x3be
end trace frame: 0x800025395ee0, count: 0
https://www.openbsd.org/ddb.html describes the minimum info required in bug
eports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}> mach ddbcpu 1
Stopped at x86_ipi_db+0x16: leave
x86_ipi_db(80002250dff0) at xB6_ipi_db+Ox16
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipiQ) at Xresume_lapic_ipi+0x27
-kernel_lock() at _kernel_lock+0xc2
reaper (80002473c008) at reaper+0x133
end trace frame: 0x0, count: 10
ddb{1}> mach ddbepu 2
Invalid cpu 2
Oh, the output side of DDB messages are in the dmesg after boot
too:
OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023
r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6064898048 (5783MB)
avail mem = 5861367808 (5589MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf8ec0 (216 entries)
bios0: vendor American Megatrends Inc. version "090006" date 04/28/2016
bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihve0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz, 3192.55 MHz, 06-55-04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,AVX512CD,AVX512BW,AVX512VL,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XSAVES,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
16-way L2 cache, 24MB 64b/line 11-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz, 3192.56 MHz, 06-55-04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,CLFLUSHOPT,AVX512CD,AVX512BW,AVX512VL,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,XSAVEC,XSAVES,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line
16-way L2 cache, 24MB 64b/line 11-way L3 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0
acpicmos0 at acpi0
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
"VMBus" at acpi0 not configured
Re: OpenBSD installer partitioning has a problem!
On 2023/12/19 09:59, Henryk Paluch wrote: > - however it means that additional GPT partitions (starting from 9) are > simply NOT accessible from OpenBSD. not *entirely*, you could add a disklabel entry pointing at the part if disk holding such a partition using one of the non-spoofed letters. still, multi-boot systems with openbsd and this many other OS on a single drive are not that common, and as has been mentioned, increasing the number of disklabel partitions is not simple, so cost:benefit ratio is not great.
Re: Firefox Not Launching - XPCOMGlueLoad error for file /usr/local/lib/firefox/libmozwayland.so.132.0: File not found
There is a working amd64 package from the previous bulk build at https://spacehopper.org/mirrors/firefox-120.0.1.tgz It is just from a backup of the normal packages not a local build, so you should expect the signature will verify. You should be able to install by downloading and "pkg_add -D installed firefox-120.0.1.tgz". On 2023/12/11 08:21, Claudio Miranda wrote: > Hello, > > I just updated all my packages on both my OpenBSD 7.4-current systems > (also updated to the latest snapshot) and I notice that Firefox is not > launching. It spits out the following error when I launch it from the > terminal. > > XPCOMGlueLoad error for file /usr/local/lib/firefox/libmozwayland.so.132.0: > File not found > Couldn't load XPCOM. > > I'm running MATE Desktop on both systems. I do have the Wayland > package installed, but I'm not using it as default. Still using > Xenocara. > > Below you'll find the dmesg on each OpenBSD system. If there's > anything else you need, feel free to let me know and I'll provide it. > Thanks! > > Dell Precision T1600: > OpenBSD 7.4-current (GENERIC.MP) #1476: Sun Dec 10 23:28:15 MST 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17114832896 (16321MB) > avail mem = 16576491520 (15808MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf24a0 (83 entries) > bios0: vendor Dell Inc. version "A21" date 07/05/2018 > bios0: Dell Inc. Precision T1600 > efi0 at bios0: UEFI 2.0 > acpi0 at bios0: ACPI 4.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC TCPA SSDT MCFG HPET BOOT SSDT SSDT DMAR SLIC > acpi0: wakeup devices PS2K(S3) EHC1(S3) EHC2(S3) HDEF(S4) GLAN(S4) > RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) > PXSX(S4) RP05(S4) PXSX(S4) RP06(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) Xeon(R) CPU E31225 @ 3.10GHz, 3093.10 MHz, 06-2a-07, > patch 002f > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.13 MHz, 06-2a-07, > patch 002f > 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.29 MHz, 06-2a-07, > patch 002f > 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.33 MHz, 06-2a-07, > patch 002f > cpu3: > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache > cpu3: smt 0, core 3, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 2 (RP01) > acpiprt2 at acpi0: bus -1 (RP02) > acpiprt3 at acpi0:
Re: PF doesn't apply filter rule with max on relays
Seems like you might want to use "return" on your block rule.
--
Sent from a phone, apologies for poor formatting.
On 10 December 2023 20:15:36 Luca Di Gregorio wrote:
Hi, in my /etc/pf.conf I have the line:
set skip on lo
That is why the rules of my previous email don't work.
If I comment
# set skip on lo
the rules work, but the ... keep state (max 1) drops the SYN of the second
connection,
so the session in relayd is not closed immediately.
Does anyone know if, with any other option in the specific rule of PF,
is possible to reject the SYN, with a TCP RST?
Anyway, I miss the possibility to set, in /etc/relayd.conf, the max number
of active relays to a specific host.
If I'm not wrong, other relays (HAProxy) have this option available.
Il giorno dom 10 dic 2023 alle ore 12:25 Luca Di Gregorio
ha scritto:
# uname -a
OpenBSD XXX.my.domain 7.4 GENERIC#0 amd64
I need to allow only one connection to an application from relayd.
# cat /etc/relayd.conf
table { lo }
http protocol xxx_https {
tls keypair yyy.zzz.org
tcp nodelay
}
relay xxx {
listen on 0.0.0.0 port 10004 tls
protocol xxx_https
forward to port 10104 check icmp
}
I don't see in man relayd.conf any option to set the max number of relays
to a host in a table.
So, I tried to put the limit on PF
# pfctl -s rules:
...
block drop in inet proto tcp from 127.0.0.1 to 127.0.0.1 port = 10104
pass in inet proto tcp from 127.0.0.1 to 127.0.0.1 port = 10104 flags S/SA
keep state (max 1)
...
But, with this configuration, the second (and the third, and the fourth,
...) connection to port 10004
is forwarded to 10104 without any filter applied by PF.
Am I missing something, or is it a bug of PF?
Re: tmux requests ANSI answer-back but doesn't consume reply from rxvt
Upstream has fixed it but not made a new release yet. https://github.com/exg/rxvt-unicode/commit/417b540d6dba67d440e3617bc2cf6d7cea1ed968 -- Sent from a phone, apologies for poor formatting. On 10 December 2023 07:54:22 Nicholas Marriott wrote: We do detect rxvt-unicode already so it would be fairly simple to add a feature flag to disable sending these sequences to it (add to tty-features.c and apply for rxvt-unicode in tty-keys.c). This might be a good idea since they have not fixed it. On Sun, 10 Dec 2023, 07:34 Nicholas Marriott, wrote: Hi IIRC the problem is not that rxvt-unicode sends BEL instead of ST, it is that it truncates it to one byte, so it only sends \033 rather than \033\\ for ST. Always sending BEL should work because tmux will accept either (although, as you say, convention is to copy the terminator used on the received sequence). On Sat, 9 Dec 2023, 21:57 Stefan Hagen, wrote: Tim Chase wrote (2023-12-09 21:47 CET): > When connecting from an rxvt terminal on my FreeBSD daily-driver > to my OpenBSD 7.4 server, tmux sends the CSI requesting color > information. But when rxvt replies, tmux ignores the reply and the > resulting answer dumps answer-back garbage into my session as if I > typed it. At a prompt, it's largely just an annoyance since I can > control+u to clear it; but if if the session is pointed at some TUI > program, the answer-back garbage can really mess with the session. > > If I'm within rxvt on FreeBSD (also v9.31), and I create a new > session or attempt to attach to an existing one (regardless of what > $TERM was set when the tmux session was started), I get the answer-back > garbage. If I use xterm or suckless `st`, or the rxvt from OpenBSD's > packages used locally it doesn't happen. > > The full conversation thread is here[1] and according to /u/sdk-dev > who was able to reproduce and narrow down the changes, they say > that it broke in this change[2] where these two lines[3] were moved > outside of some checks. > > As best we can tell, tmux is failing to consume the answer-back it > requests. Hi, I've updated my answer on reddit quite a few times, so you probably haven't seen the latest version. The bug here is with rxvt-unicode. The xterm specification describes OSC requests to be either terminated with the ST \033\\ or with the BEL \007 terminator. The response from the terminal should then match the terminator of the request. rxvt-unicode is failing to do so and always terminates with BEL. Tmux is doing this correctly. It sends ST and expects ST. The specification describes ST as the newer and preferred terminator, which was probably the reason why it was decided in OpenBSD to switch rxvt-unicode to ST instead of switching tmux to BEL. I don't know if rxvt is still developed somewhere, so FreeBSD could adopt our patch. https://cvsweb.openbsd.org/ports/x11/rxvt-unicode/patches/patch-src_command_C?rev=1.6=text/x-cvsweb-markup Do we want some special handling for rxvt-unicode in tmux? I'm not knowledable enough in this area to have an opinion. Best regards, Stefan aka /u/sdk-dev > Thanks, > -tkc > > [1] > https://www.reddit.com/r/openbsd/comments/18cxwdy/tmux_causing_ansi_colorresponse_garbage_on/ > > [2] > /* $OpenBSD: tty.c,v 1.434 2023/09/02 20:03:10 nicm Exp $ */ > https://github.com/openbsd/src/commit/903d1285474e6a1a8bfdc71e5c97f8037e5d801a#diff-f63cc050113818ea4ebd794e00daec9960f613b4dbd2039bed3d532c7ea8096dR373 > > [3] > https://github.com/openbsd/src/blob/master/usr.bin/tmux/tty.c#L373-L374
Re: tmux requests ANSI answer-back but doesn't consume reply from rxvt
We have a patch in our rxvt-unicode port for this, it sounded like upstream might fix it in a future release -- Sent from a phone, apologies for poor formatting. On 9 December 2023 21:57:23 Stefan Hagen wrote: Tim Chase wrote (2023-12-09 21:47 CET): When connecting from an rxvt terminal on my FreeBSD daily-driver to my OpenBSD 7.4 server, tmux sends the CSI requesting color information. But when rxvt replies, tmux ignores the reply and the resulting answer dumps answer-back garbage into my session as if I typed it. At a prompt, it's largely just an annoyance since I can control+u to clear it; but if if the session is pointed at some TUI program, the answer-back garbage can really mess with the session. If I'm within rxvt on FreeBSD (also v9.31), and I create a new session or attempt to attach to an existing one (regardless of what $TERM was set when the tmux session was started), I get the answer-back garbage. If I use xterm or suckless `st`, or the rxvt from OpenBSD's packages used locally it doesn't happen. The full conversation thread is here[1] and according to /u/sdk-dev who was able to reproduce and narrow down the changes, they say that it broke in this change[2] where these two lines[3] were moved outside of some checks. As best we can tell, tmux is failing to consume the answer-back it requests. Hi, I've updated my answer on reddit quite a few times, so you probably haven't seen the latest version. The bug here is with rxvt-unicode. The xterm specification describes OSC requests to be either terminated with the ST \033\\ or with the BEL \007 terminator. The response from the terminal should then match the terminator of the request. rxvt-unicode is failing to do so and always terminates with BEL. Tmux is doing this correctly. It sends ST and expects ST. The specification describes ST as the newer and preferred terminator, which was probably the reason why it was decided in OpenBSD to switch rxvt-unicode to ST instead of switching tmux to BEL. I don't know if rxvt is still developed somewhere, so FreeBSD could adopt our patch. https://cvsweb.openbsd.org/ports/x11/rxvt-unicode/patches/patch-src_command_C?rev=1.6=text/x-cvsweb-markup Do we want some special handling for rxvt-unicode in tmux? I'm not knowledable enough in this area to have an opinion. Best regards, Stefan aka /u/sdk-dev Thanks, -tkc [1] https://www.reddit.com/r/openbsd/comments/18cxwdy/tmux_causing_ansi_colorresponse_garbage_on/ [2] /* $OpenBSD: tty.c,v 1.434 2023/09/02 20:03:10 nicm Exp $ */ https://github.com/openbsd/src/commit/903d1285474e6a1a8bfdc71e5c97f8037e5d801a#diff-f63cc050113818ea4ebd794e00daec9960f613b4dbd2039bed3d532c7ea8096dR373 [3] https://github.com/openbsd/src/blob/master/usr.bin/tmux/tty.c#L373-L374
Re: netstart fails to parse complex wpa2 passphrases
On 2023/11/25 16:00, Thomas Nemeth wrote: > join mywifi wpakey 'B22c-2&0%snOy7!l+6vmpH#QT2BN1RPdeImAb0/ btw: it's hard to guess at the real complexity of your SSID, but it's used as a salt for the WPA paasword, so if it isn't already, it's a good idea to make this fairly complex too.
Re: AX211 wifi firmware load issue
On 2023/11/23 19:38, Stefan Sperling wrote: > It is possible that our driver is trying to use an incompatible > firmware image on this particular device. Which firmware file name > is loaded by the iwlwifi driver on a recent Linux distribution? > Are we loading the same one? Seems the first liveusb image that I picked up (Debian 12.2.0) isn't bleeding edge enough. Apparently it is actually an AX101.
Re: AX211 wifi firmware load issue
and here are kernel messages with IWX_DEBUG defined iwx0: L1 Disabled - LTR Enabled iwx0: ucode type 0 section 0 iwx0: ucode type 0 section 1 iwx0: ucode type 0 section 2 iwx0: ucode type 0 section 3 iwx0: ucode type 0 section 4 iwx0: ucode type 0 section 5 iwx0: ucode type 0 section 6 iwx0: ucode type 0 section 7 iwx0: ucode type 0 section 8 iwx0: ucode type 0 section 9 iwx0: ucode type 0 section 10 iwx0: ucode type 0 section 11 iwx0: ucode type 0 section 12 iwx0: ucode type 0 section 13 iwx0: ucode type 0 section 14 iwx0: ucode type 0 section 15 iwx0: ucode type 0 section 16 iwx0: ucode type 0 section 17 iwx0: ucode type 0 section 18 iwx0: ucode type 0 section 19 iwx0: ucode type 0 section 20 iwx0: ucode type 0 section 21 iwx0: ucode type 0 section 22 iwx0: ucode type 0 section 23 iwx0: ucode type 0 section 24 iwx0: ucode type 0 section 25 iwx0: ucode type 0 section 26 iwx0: ucode type 0 section 27 iwx0: ucode type 0 section 28 iwx0: ucode type 0 section 29 iwx0: ucode type 0 section 30 iwx0: ucode type 0 section 31 iwx0: ucode type 0 section 32 iwx0: ucode type 0 section 33 iwx0: ucode type 0 section 34 iwx0: ucode type 0 section 35 iwx0: ucode type 0 section 36 iwx0: ucode type 0 section 37 iwx0: ucode type 0 section 38 iwx0: ucode type 0 section 39 iwx0: ucode type 0 section 40 iwx0: ucode type 0 section 41 iwx0: ucode type 0 section 42 iwx0: ucode type 0 section 43 iwx0: ucode type 0 section 44 iwx0: ucode type 0 section 45 iwx0: ucode type 0 section 46 iwx0: ucode type 0 section 47 iwx0: ucode type 0 section 48 iwx0: ucode type 0 section 49 iwx0: ucode type 0 section 50 iwx0: ucode type 0 section 51 iwx0: ucode type 0 section 52 iwx0: ucode type 0 section 53 iwx0: ucode type 0 section 54 iwx0: ucode type 0 section 55 iwx0: ucode type 0 section 56 iwx0: L1 Disabled - LTR Enabled iwx_init_fw_sec: firmware LMAC section 0 at 0x40335000 size 1656 iwx_init_fw_sec: firmware LMAC section 1 at 0x40777000 size 32768 iwx_init_fw_sec: firmware LMAC section 2 at 0x4077f000 size 32768 iwx_init_fw_sec: firmware LMAC section 3 at 0x40787000 size 32768 iwx_init_fw_sec: firmware LMAC section 4 at 0x4078f000 size 32760 iwx_init_fw_sec: firmware LMAC section 5 at 0x40797000 size 32768 iwx_init_fw_sec: firmware LMAC section 6 at 0x4079f000 size 32768 iwx_init_fw_sec: firmware LMAC section 7 at 0x407a7000 size 32768 iwx_init_fw_sec: firmware LMAC section 8 at 0x407af000 size 32768 iwx_init_fw_sec: firmware LMAC section 9 at 0x407b7000 size 32768 iwx_init_fw_sec: firmware LMAC section 10 at 0x407bf000 size 32768 iwx_init_fw_sec: firmware LMAC section 11 at 0x407c7000 size 32768 iwx_init_fw_sec: firmware LMAC section 12 at 0x407cf000 size 32768 iwx_init_fw_sec: firmware LMAC section 13 at 0x40334000 size 560 iwx_init_fw_sec: firmware LMAC section 14 at 0x407d7000 size 21696 iwx_init_fw_sec: firmware UMAC section 0 at 0x40333000 size 1656 iwx_init_fw_sec: firmware UMAC section 1 at 0x407dd000 size 32768 iwx_init_fw_sec: firmware UMAC section 2 at 0x407e5000 size 32768 iwx_init_fw_sec: firmware UMAC section 3 at 0x407ed000 size 32768 iwx_init_fw_sec: firmware UMAC section 4 at 0x407f5000 size 32768 iwx_init_fw_sec: firmware UMAC section 5 at 0x407fd000 size 32768 iwx_init_fw_sec: firmware UMAC section 6 at 0x40805000 size 32768 iwx_init_fw_sec: firmware UMAC section 7 at 0x4080d000 size 32768 iwx_init_fw_sec: firmware UMAC section 8 at 0x40815000 size 32768 iwx_init_fw_sec: firmware UMAC section 9 at 0x4081d000 size 32768 iwx_init_fw_sec: firmware UMAC section 10 at 0x40825000 size 32768 iwx_init_fw_sec: firmware UMAC section 11 at 0x4082d000 size 32768 iwx_init_fw_sec: firmware UMAC section 12 at 0x40835000 size 32768 iwx_init_fw_sec: firmware UMAC section 13 at 0x4083d000 size 14408 iwx_init_fw_sec: firmware UMAC section 14 at 0x40841000 size 4616 iwx_init_fw_sec: firmware UMAC section 15 at 0x40843000 size 24756 iwx_init_fw_sec: firmware paging section 0 at 0x40332000 size 1656 iwx_init_fw_sec: firmware paging section 1 at 0x4084a000 size 32768 iwx_init_fw_sec: firmware paging section 2 at 0x40852000 size 32768 iwx_init_fw_sec: firmware paging section 3 at 0x4085a000 size 32768 iwx_init_fw_sec: firmware paging section 4 at 0x40862000 size 32768 iwx_init_fw_sec: firmware paging section 5 at 0x4086a000 size 32768 iwx_init_fw_sec: firmware paging section 6 at 0x40872000 size 32768 iwx_init_fw_sec: firmware paging section 7 at 0x4087a000 size 32768 iwx_init_fw_sec: firmware paging section 8 at 0x40882000 size 32768 iwx_init_fw_sec: firmware paging section 9 at 0x4088a000 size 32768 iwx_init_fw_sec: firmware paging section 10 at 0x40892000 size 32768 iwx_init_fw_sec: firmware paging section 11 at 0x4089a000 size 32768 iwx_init_fw_sec: firmware paging section 12 at 0x408a2000 size 32768 iwx_init_fw_sec: firmware paging section 13 at 0x408aa000 size 32768 iwx_init_fw_sec: firmware paging section 14 at 0x408b2000 size 32768 iwx_init_fw_sec: firmware paging section 15 at 0x408ba000 size 32768 iwx_init_fw_sec: firmware paging
Re: nmap sendto in send_ip_packet_sd: sendto => Permission denied
On 2023/11/16 21:35, Rafael Sadowski wrote: > I stumbled across the following. Maybe only our nmap port is broken. > > $ doas nmap -vvv -sU -sT google.de > Starting Nmap 7.91 ( https://nmap.org ) at 2023-11-16 21:28 CET > Warning: Hostname google.de resolves to 2 IPs. Using 142.250.74.195. > Initiating Ping Scan at 21:28 > Scanning google.de (142.250.74.195) [4 ports] > sendto in send_ip_packet_sd: sendto(4, packet, 40, 0, 142.250.74.195, 16) => > Permission denied > Offending packet: TCP 10.0.23.5:58160 > 142.250.74.195:80 A ttl=39 id=51533 > iplen=40 seq=0 win=1024 > Completed Ping Scan at 21:28, 0.01s elapsed (1 total hosts) > Initiating Parallel DNS resolution of 1 host. at 21:28 > Completed Parallel DNS resolution of 1 host. at 21:28, 0.00s elapsed > DNS resolution of 1 IPs took 0.01s. Mode: Async [#: 1, OK: 1, NX: 0, DR: 0, > SF: 0, TR: 1, CN: 0] > Initiating UDP Scan at 21:28 > Scanning google.de (142.250.74.195) [1000 ports] > zsh: abort (core dumped) doas nmap -vvv -sU -sT google.d see deraadt's answer about the actual crash, but the "permission denied" probably comes from PF
Re: vxlan(4) custom destination UDP port seems not working
On 2023/11/15 05:59, Theo de Raadt wrote: > Otto Moerbeek wrote: > > > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > > > # uname -a > > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 > > > > > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 > > > # ifconfig vxlan0 inet 192.168.5.1/30 > > > # ifconfig vxlan0 up > > > > > > # ifconfig vxlan0: I can't see the dest UDP port 8472 anywhere > > > vxlan0: flags=8843 mtu 1500 > > > lladdr fe:e1:ba:d9:e4:0b > > > index 18 llprio 3 > > > encap: vnetid 5 parent none txprio 0 rxprio outer > > > groups: vxlan > > > tunnel: inet SOURCE_IP --> DEST_IP ttl 1 nodf > > > Addresses (max cache: 100, timeout: 240): > > > inet 192.168.5.1 netmask 0xfffc broadcast 192.168.5.3 > > > > > > # ping 192.168.5.2 > > > > > > In tcpdump, I see that arp packets are sent to UDP port 4789, not 8472: > > > SOURCE_IP.4789 > DEST_IP.4789: VXLAN vni 5: arp who-has 192.168.5.2 tell > > > 192.168.5.1 [ttl 1] > > > > > > Is this a bug? > > > > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > > ports. > > Is there any reason to allow people to use non-standard ports? Equipment that > does this is rare. pre-RFC implementations used 8472
Re: vxlan(4) custom destination UDP port seems not working
On 2023/11/15 13:03, Otto Moerbeek wrote: > On Wed, Nov 15, 2023 at 12:42:46PM +0100, Luca Di Gregorio wrote: > > > # uname -a > > OpenBSD X.my.domain 7.4 GENERIC#0 amd64 ... > > # ifconfig vxlan0 tunnel SOURCE_IP DEST_IP:8472 vnetid 5 ... > It helps to read the vxlan(4) manpage, specifcially the paragraph abouts > ports. according to EXAMPLES - : Prior to the assignment of UDP port 4789 by IANA, some early VXLAN : implementations used port 8472. A non-standard port can be specified : with the tunnel destination address: ^^^ : : # ifconfig vxlan0 tunnel 192.168.1.100 239.1.1.100:8472 which is as set, but it contradicts the ioctl doc - :if the destination address is unspecified. A non-standard UDP :port for VXLAN packets can be specified by the port in the :source address, otherwise use 0 to request the default. The ^^ :addresses may only be configured while the interface is down. so at least there's a doc bug
Re: Memory Leak on 7.4 (Stable) with nginx 1.24.0 related to TLS1.3
On 2023/11/11 15:19, Stuart Henderson wrote:
> Excellent, that is very helpful.
>
> Here's a simpler nginx.conf to reproduce. Note that the leak goes away
> if you don't use Connection: Upgrade.
>
> Simple test tool:
>
> pkg_add http_load
> echo http://127.0.0.1:8123/ > /tmp/urls
> http_load -rate 100 -seconds 10 /tmp/urls
>
>
>
> worker_processes 4;
> worker_rlimit_nofile 1024;
> events {
> worker_connections 800;
> }
>
> http {
> server {
> listen 127.0.0.1:8123;
> server_name localhost;
> root /var/www/htdocs;
>
> location / {
> proxy_pass https://sym.spacehopper.org/;
err actually don't use that one, pick something local :-)
> proxy_http_version 1.1;
>
> proxy_set_header Connection "Upgrade";
>
> #proxy_ssl_protocols TLSv1.2;
> proxy_ssl_protocols TLSv1.3;
> }
> }
> }
>
>
>
> On 2023/11/11 14:20, Tobias Fiebig wrote:
> >
> > Moin,I ran through the experiments i had suggested. As you assumed, this is
> > indeed related to outbound TLS1.3 connections, specifically:
> >
> > +-+
> > | Config (syspatched OpenBSD 7.4) | Memleak? |
> > +-+---+
> > | From pkg, TLS1.3 for in and outbound| Yes |
> > | From pkg, no TLS1.3 for inbound | Yes |
> > | From pkg, no TLS1.3 for outbound| No|
> > | | |
> > | From ports, TLS1.3 for in and outbound, sub_http module | Yes |
> > | From ports, no TLS1.3 for inbound, sub_http module | Yes |
> > | From ports, no TLS1.3 for outbound, sub_http module | No|
> > | | |
> > | Selfbuild, TLS1.3 for in and outbound, sub_http module | Yes |
> > | Selfbuild, no TLS1.3 for inbound, sub_http module | Yes |
> > | Selfbuild, no TLS1.3 for outbound, sub_http module | No|
> > +-+---+
> >
> > I found a minimal configuration that reliably triggers the issue for a
> > standard nginx-1.24.0p0 from packages. You can find it here:
> > https://rincewind.home.aperture-labs.org/~tfiebig/malloc/reproduction/
> >
> > The leak occurs just a few seconds after starting exec.py to send a
> > constant request rate of ~10 concurrent requests, i.e., the difference
> > in memory consumption becomes visible in two machines that are (apart
> > from using TLS1.3 for outbound proxy connections) identical.
> >
> > The leak seems to occur linearly for the absolute number of requests
> > (1k requests ~= 20mb of memory).
> >
> > I also see a notably higher CPU utilization if TLS1.3 is enabled for
> > outbound connections (~3-5x) given the same load. For example, when
> > running 100k requests against the test systems, i got (This may be due
> > to lacking CPU instructions for algorithms used in TLS1.3, though;
> > still figured it might be good to note):
> >
> > https://rincewind.home.aperture-labs.org/~tfiebig/malloc/cpu_utilization_tls13.png
> >
> > With the req/s being like this:
> >
> > Non-leaking hosts:
> > #1 o74n1240-self-revp-noprx13.dus01.as59645.net:
> > Got 10 in 309 seconds (323.62/s)
> > #1 o74n1240-pkg-revp-noprx13.dus01.as59645.net:
> > Got 10 in 310 seconds (322.58/s)
> > #1 o74n1240-ports-revp-noprx13.dus01.as59645.net:
> > Got 10 in 312 seconds (320.51/s)
> >
> > Leaking hosts:
> > #1 o74n1240-self-revp-def.dus01.as59645.net:
> > Got 10 in 346 seconds (289.02/s)
> > #1 o74n1240-ports-revp-nohttp13.dus01.as59645.net:
> > Got 10 in 348 seconds (287.36/s)
> > #1 o74n1240-self-revp-nohttp13.dus01.as59645.net:
> > Got 10 in 348 seconds (287.36/s)
> > #1 o74n1240-ports-revp-def.dus01.as59645.net:
> > Got 10 in 351 seconds (284.90/s)
> > #1 o74n1240-pkg-revp-nohttp13.dus01.as59645.net:
> > Got 10 in 377 seconds (265.25/s)
> > #1 o74n1240-pkg-revp-def.dus01.as59645.net:
> > Got 10 in 382 seconds (261.78/s)
> >
> > After this run, the leaking instances were at ~2.9GB, while the non-
> > leaking ones were at ~0.8GB active memory.
> >
> > Do you have any suggestions what else i could test to better identify
> > what is causing this? If the config i referenced does not reproduce
> > this for you, i can also provide access to these test machines
> > (ephemeral boxes; No prod on there. ;-))
> >
> > With best regards,
> > Tobias
>
Re: Memory Leak on 7.4 (Stable) with nginx 1.24.0 related to TLS1.3
Excellent, that is very helpful.
Here's a simpler nginx.conf to reproduce. Note that the leak goes away
if you don't use Connection: Upgrade.
Simple test tool:
pkg_add http_load
echo http://127.0.0.1:8123/ > /tmp/urls
http_load -rate 100 -seconds 10 /tmp/urls
worker_processes 4;
worker_rlimit_nofile 1024;
events {
worker_connections 800;
}
http {
server {
listen 127.0.0.1:8123;
server_name localhost;
root /var/www/htdocs;
location / {
proxy_pass https://sym.spacehopper.org/;
proxy_http_version 1.1;
proxy_set_header Connection "Upgrade";
#proxy_ssl_protocols TLSv1.2;
proxy_ssl_protocols TLSv1.3;
}
}
}
On 2023/11/11 14:20, Tobias Fiebig wrote:
>
> Moin,I ran through the experiments i had suggested. As you assumed, this is
> indeed related to outbound TLS1.3 connections, specifically:
>
> +-+
> | Config (syspatched OpenBSD 7.4) | Memleak? |
> +-+---+
> | From pkg, TLS1.3 for in and outbound| Yes |
> | From pkg, no TLS1.3 for inbound | Yes |
> | From pkg, no TLS1.3 for outbound| No|
> | | |
> | From ports, TLS1.3 for in and outbound, sub_http module | Yes |
> | From ports, no TLS1.3 for inbound, sub_http module | Yes |
> | From ports, no TLS1.3 for outbound, sub_http module | No|
> | | |
> | Selfbuild, TLS1.3 for in and outbound, sub_http module | Yes |
> | Selfbuild, no TLS1.3 for inbound, sub_http module | Yes |
> | Selfbuild, no TLS1.3 for outbound, sub_http module | No|
> +-+---+
>
> I found a minimal configuration that reliably triggers the issue for a
> standard nginx-1.24.0p0 from packages. You can find it here:
> https://rincewind.home.aperture-labs.org/~tfiebig/malloc/reproduction/
>
> The leak occurs just a few seconds after starting exec.py to send a
> constant request rate of ~10 concurrent requests, i.e., the difference
> in memory consumption becomes visible in two machines that are (apart
> from using TLS1.3 for outbound proxy connections) identical.
>
> The leak seems to occur linearly for the absolute number of requests
> (1k requests ~= 20mb of memory).
>
> I also see a notably higher CPU utilization if TLS1.3 is enabled for
> outbound connections (~3-5x) given the same load. For example, when
> running 100k requests against the test systems, i got (This may be due
> to lacking CPU instructions for algorithms used in TLS1.3, though;
> still figured it might be good to note):
>
> https://rincewind.home.aperture-labs.org/~tfiebig/malloc/cpu_utilization_tls13.png
>
> With the req/s being like this:
>
> Non-leaking hosts:
> #1 o74n1240-self-revp-noprx13.dus01.as59645.net:
> Got 10 in 309 seconds (323.62/s)
> #1 o74n1240-pkg-revp-noprx13.dus01.as59645.net:
> Got 10 in 310 seconds (322.58/s)
> #1 o74n1240-ports-revp-noprx13.dus01.as59645.net:
> Got 10 in 312 seconds (320.51/s)
>
> Leaking hosts:
> #1 o74n1240-self-revp-def.dus01.as59645.net:
> Got 10 in 346 seconds (289.02/s)
> #1 o74n1240-ports-revp-nohttp13.dus01.as59645.net:
> Got 10 in 348 seconds (287.36/s)
> #1 o74n1240-self-revp-nohttp13.dus01.as59645.net:
> Got 10 in 348 seconds (287.36/s)
> #1 o74n1240-ports-revp-def.dus01.as59645.net:
> Got 10 in 351 seconds (284.90/s)
> #1 o74n1240-pkg-revp-nohttp13.dus01.as59645.net:
> Got 10 in 377 seconds (265.25/s)
> #1 o74n1240-pkg-revp-def.dus01.as59645.net:
> Got 10 in 382 seconds (261.78/s)
>
> After this run, the leaking instances were at ~2.9GB, while the non-
> leaking ones were at ~0.8GB active memory.
>
> Do you have any suggestions what else i could test to better identify
> what is causing this? If the config i referenced does not reproduce
> this for you, i can also provide access to these test machines
> (ephemeral boxes; No prod on there. ;-))
>
> With best regards,
> Tobias
Re: Memory Leak on 7.4 (Stable) with nginx 1.24.0 related to TLS1.3
On 2023/11/10 14:09, Tobias Fiebig wrote: > Moin, > i have been running into memleaks with nginx 1.24.0 for some time; > Nginx is self-build (as i need the http_sub module); It is configures > with: ./configure --with-http_sub_module --with-http_ssl_module --with- > http_stub_status_module --prefix=/usr/local --conf- > path=/etc/nginx/nginx.conf --user=www --group=www So you didn't mention http_sub_module before, which precludes directly using packages from 7.4, but can you try building from the port so that the only change compared to what anyone else is running is enabling the additional module? (You can use 'FLAVOR="no_passenger no_lua no_njs" make package' to reduce the number of build dependencies). > This did not occur with nginx before 1.24.0; I went through all nginx > commits between 1.24.0 and the last non-leaking version, and the change > is indeed when Nginx made TLS1.3 default on. AFAIK a couple of people have tried to reproduce this and not been able to. I really think you are going to need to isolate _what_ triggers the issue and provide some config so that others can replicate it... > The workload is a transparent proxy/web-fronting, i.e., lots of > outbound TLS connections as well. When you look at the graphs (url > below), it seems like leakage 'growth' tracks ~ to the number of > connections nginx receives. Can you try to isolate whether it's on the inbound or outbound side? AFAIK you can disable 1.3 on the proxy side with proxy_ssl_protocols so that is probably worth a try. (I am using proxy_pass with https, though the bulk of my proxy_pass is just http backend, and the one with https backend only does TLS1.2). > As i currently assume that this is related to libressl, i did some > traces of nginx (MALLOC_OPTIONS 2,3,D and -i -tu) for 2 hours each > (usually enough for memory consumption to ~ double with avg. load. > > I do not really know enough to debug this any further at the moment; Is > there anything else i could do to further circle in on the cause of > this (and ideally figure out whether it is a libressl or nginx issue)? > > Some data (graphs, ktraces) here: > https://rincewind.home.aperture-labs.org/~tfiebig/malloc/ For continuity for the list archives, previous thread was here https://marc.info/?l=openbsd-misc=169571937015656=2 There was never an answer to my last email there, though the graphs give some idea of the memory allocation rate, though it's quite different between some of the restarts - 7-8 Nov around 5GB - 8-9 Nov around 12GB - 9-10 Nov around 10GB though it doesn't really increase until a while after the process started. Is there any more context to those graphs? Config changes? Different access patterns?
Re: installer should work around ocsp failure
On 2023/10/27 13:15, Theo de Raadt wrote: > > It occurred to me later maybe the clock was off? > > Oh now people want a ntp client on the installer??!?! Don't we already have a tempprary time sync in the installer from ftplist for exactly this situation?
Re: terminal is cleared when logging as root
On 2023/10/24 08:21, Nicholas Marriott wrote: > I can't see what is different in tset, both old and new should just > send is2 and that hasn't changed as far as I can tell. > > Can someone show me the output of this from before the ncurses update > (maybe 7.4-release): > > /usr/bin/tset -sQ '-munknown:?vt220' vt220 2>&1|cat -v With older curses, this calls ioctl TIOCGETA on stderr and fails. 81046 tset CALL ioctl(2,TIOCGETA,0x798691d3a00) 81046 tset RET ioctl -1 errno 25 Inappropriate ioctl for device It will run under script instead though: $ /usr/bin/tset -sQ '-munknown:?vt220' vt220^M^M ^M^[[3g^[H^[H^[H^[H^[H^[H ^[H^[H^M^MTERM=vt220;^M
Re: pflogd doesn't stop properly on -current
On 2023/10/05 19:04, Mikhail wrote:
> I have also 7.3-release with syspatches - it prints
> pflogd(ok)
> on rcctl -f stop pflogd, and no pflogd processes around after that.
>
>
> $ sysctl kern.version
> kern.version=OpenBSD 7.4 (GENERIC.MP) #1394: Wed Oct 4 10:25:33 MDT 2023
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> $ ps axu | grep pflog
> $
>
> $ doas rcctl -f start pflogd
> pflogd(ok)
>
> $ ps axu | grep pflog
> root 81507 0.0 0.0 656 1384 ?? SU 6:54PM0:00.00 pflogd:
> [priv] (pflogd)
> _pflogd 65294 0.0 0.0 696 1564 ?? Spc 6:54PM0:00.00 pflogd:
> [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
>
> $ doas rcctl -f stop pflogd
> pflogd(killed)
>
> $ ps axu | grep pflog
> _pflogd 65294 0.0 0.0 696 1572 ?? Spc 6:54PM0:00.00 pflogd:
> [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd)
>
Seems pflogd sometimes (but possibly not always?) doesn't exit after
getting SIGTERM..
$ pgrep -lf pflog
62308 pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog
58610 pflogd: [priv]
58610 pflogd PSIG SIGTERM caught handler=0x591da8a9ce0 mask=0<>
58610 pflogd RET read RESTART
58610 pflogd CALL kill(62308,SIGTERM)
58610 pflogd RET kill 0
58610 pflogd CALL sigreturn(0x7894e6a19590)
62308 pflogd PSIG SIGTERM caught handler=0x8e6b1e70cf0 mask=0<>
58610 pflogd RET sigreturn JUSTRETURN
62308 pflogd RET read RESTART
58610 pflogd CALL read(3,0x7894e6a19a98,0x4)
62308 pflogd CALL sigreturn(0x7ec0882c1910)
62308 pflogd RET sigreturn JUSTRETURN
62308 pflogd CALL read(4,0x8e912ad4000,0x8000)
No output shown if I run pflogd in the foreground (-D) and signal
it either.
Backing out the last pflogd commit ("switch pflogd from using a bpf
read timeout to a wait timeout") restores previous behaviour.
Re: PXE install of OpenBSD 7.3 (amd64) fails on Protectli VP4650 & VP2420, with 'igc' Intel I225-V 2.5Gbps NICs
On 2023/10/02 18:24, Alexander Bluhm wrote: > On Sun, Oct 01, 2023 at 06:25:41PM -0700, Ian R. wrote: > > ?? The 'bsd' file it's looking for definitely does exist on my pxeboot > > server, in the tftpd root dirirectory where it's supposed to be. I've > > It is supposed to be in an IP address subdirectory. At least that's > how my setup looks like. > > 18512 ?? Ip 4:24.00 /usr/sbin/tftpd -4 -i /var/spool/tftp/ > > bluhm@testmaster:.../~$ ls -la /var/spool/tftp/10.0.1.49/ The IP address subdirectory comes from using tftpd -i, it's not needed for a default setup.
Re: PXE install of OpenBSD 7.3 (amd64) fails on Protectli VP4650 & VP2420, with 'igc' Intel I225-V 2.5Gbps NICs
On 2023/10/01 18:25, Ian R. wrote: > My best guess is that OpenBSD's BOOTX64.EFI is lacking > support for the 'igc' Intel I225-V 2.5Gbps NICs It doesn't directly help you, but the boot loader doesn't have any NIC-specific code, it calls into EFI to make network connections. > Here are dmesg lines about the 'igc' network interfaces > on the Protectli VP4650 (after doing the successful OpenBSD > install from a USB disk): You didn't include a full dmesg (always a good idea when reporting a problem) so we can't ID which version you have, but the 1-line info for the latest firmware for VP4650 says "CSM UEFI Network fix" so if you don't have that already, I'd try updating first.
Re: pf nat-to doesn't match a crafted packet
On 2023/08/28 18:30, Peter J. Philipp wrote: > Here is my icmp rulesets: > > root@stern# grep icmp /etc/pf.conf a partial pf.conf fragment is hardly ever enough to debug a ruleset problem. if a packet doesn't match any rule then it hits the implicit "pass flags any no state" rule 0.
Re: ER: improve wireguard logging, please?
On 2023/08/13 08:46, Harald Dunkel wrote: > Hi Stuart, > > On 2023-08-11 11:39:24, Stuart Henderson wrote: > > On 2023/08/11 08:47, Harald Dunkel wrote: > > > > > > For forensic measures in case of an incident it is crucial to > > > have the peers public key. This string is constant over time > > > (unless it is not rotated for security). The first 16 or 10 > > > chars should do., e.g. > > > > > > % grep 3QUz9EgDY4 /var/log/messages > > > : > > > Aug 9 15:22:02 mygate /bsd: wg0: Sending handshake initiation to peer 17 > > > (3QUz9EgDY4) > > > Aug 9 15:22:07 mygate /bsd: wg0: Handshake for peer 17 (3QUz9EgDY4) did > > > not complete after 5 seconds, retrying (try 19) > > > > Is that just meant as an example, or do you have a diff? If you have a > > diff, please send it, because from a quick read it seems doing that is > > non-trivial (logging the peer description would be simpler, but whether > > it's pubkey or descr, I'm pretty sure it requires taking a lock to > > access this information, and that makes it a fairly complex change to > > review). > > > > This was just a mock, of course. I don't want to request complex changes, > just something better suitable than "peer 17". While it may _seem_ simple, the peer number is easily available at the various points debug logging is done, but information like key (or description) is not and must be looked up. The code doing lookup needs to ensure that it isn't being changed concurrently (wg packet processing for one peer is often likely to run on one cpu while things change on another - for example if a peer is removed from configuration). Maybe it's possible to copy the pubkey (or a truncation thereof) somewhere more accessible (I guess it might be ok to access from the softc, I don't think the key can change once a peer is created), but there may be a good reason why that wasn't already done. (this is beyond what I'm comfortable with in C). >I have seen the public key > as some kind of not modifiable identifier for a VPN connection. Adding > the description to the log file wouldn't help, since there is just a > single description for a wireguard connection with multiple peers (if > I understood ifconfig(8) correctly). I mean the per-peer description not the interface description. (It's easy to add a naive implementation to log that, but such a naive implementation will break in some situations, perhaps badly - crashes or worse). The log messages you're talking about are meant for debug not normal operation, and there are a lot of them. If locks _are_ needed then reasoning about lock behaviour for each of them would make it complex to implement and review changes for them - and of course adding more locks will make things slower. IIUC the whole protocol is designed so that e.g. peer public key lookups like this don't need to be done very often, and that locks can be kept to a minimum. So no surprise it's using a simple approach to logging. > I am talking about the setup for a road-warrior VPN gateway. The road- > warriors are supposed to have their own IP address, but they use the > same subnet and routing. (offtopic but i really hate that "road warrior" term. yeuch yeuch yeuch!). > > It would be much easier to log the public key and peer number when the > > peer is created, but then you'll need to keep more logs. > > > > Some peers are connected 24/7 for weeks. disk is cheap :)
Re: ER: improve wireguard logging, please?
On 2023/08/11 08:47, Harald Dunkel wrote: > Hi folks, > > would it be possible to improve wireguard logging in OpenBSD? > A message like > > Receiving handshake initiation from peer 17 > > in /var/log/messages of 2 weeks ago isn't really helpful. Peer > 17 might have become peer 8 over time, for example. > > For forensic measures in case of an incident it is crucial to > have the peers public key. This string is constant over time > (unless it is not rotated for security). The first 16 or 10 > chars should do., e.g. > > % grep 3QUz9EgDY4 /var/log/messages > : > Aug 9 15:22:02 mygate /bsd: wg0: Sending handshake initiation to peer 17 > (3QUz9EgDY4) > Aug 9 15:22:07 mygate /bsd: wg0: Handshake for peer 17 (3QUz9EgDY4) did not > complete after 5 seconds, retrying (try 19) Is that just meant as an example, or do you have a diff? If you have a diff, please send it, because from a quick read it seems doing that is non-trivial (logging the peer description would be simpler, but whether it's pubkey or descr, I'm pretty sure it requires taking a lock to access this information, and that makes it a fairly complex change to review). It would be much easier to log the public key and peer number when the peer is created, but then you'll need to keep more logs. If you're doing analysis of wg debug logs, you'll also have a problem with how the messages get split up in syslog sometimes, and making the lines longer isn't going to help that /bsd: wg0: Receiving handshake re /bsd: sponse from peer 0 /bsd: wg0: Send /bsd: ing kee /bsd: pali /bsd: ve p /bsd: ack /bsd: et to /bsd: pee /bsd: r 0
Re: Allow libpcap to read files with some additional link-layer type values
On 2023/08/02 13:12, Guy Harris wrote: > Thanks. > > (By the way, when testing this on a 7.3 virtual machine, I saw the problem > that I suspect this change to sys/net/if_loop.c: > > revision 1.97 > date: 2023/07/21 22:24:41; author: bluhm; state: Exp; lines: +10 -1; > commitid: zlUMTFeyu4Tpey4p; > Do not dump corrupted packets on loopback bpf. > > lo(4) used to dump to bpf only for output. It seems that when > if_bpf_mtap() was introduced, this changed and lo(4) dumps an > additional truncated packet. The default bpf_mtap_ether() is not > suitable for lo(4). > > Install a dummy lo_bpf_mtap() to suppress bpf on input. > > OK mvs@ > > fixes - the captures I did on lo0 had two copies of each packet, the first of > which has no DLT_LOOP header, the second of which does. That change should > perhaps be backported to the 7.x branch if a 7.4 release is likely to happen. Thanks for the confirmation on that. That fix will be in 7.4; other than post-release patch branches (7.2-stable, 7.3-stable, etc; mainly used for fairly serious or widely seen issues) we just have a single repo branch and version numbering is a simple +0.1 each time, nothing special about an x.0 release. > Given that a link-layer type value of 12 means DLT_RAW on macOS and on BSDs > other then OpenBSD, reading the capture file with tcpdump on those OSes means > that the *first* packet is correctly dissected and the *second* packet is > reported as damaged; DLT_ collisions such as that are the reason why I > introduced the notion of LINKTYPE_ values, to be used in pcap and now pcapng > files, and changed libpcap so that it writes DLT_RAW captures with a > link-layer type value of 101 and, when reading captures, maps a link-layer > type value of 101 in the file to DLT_RAW.)
Re: Allow libpcap to read files with some additional link-layer type values
On 2023/08/02 10:12, Alexandr Nedvedicky wrote: > Hello, > > thank you for detailed explanation and diff. I went through it > and agree with your change. > > I also gave it a quick try to see if OpenBSD's tcpdump linked > with patched libpcap is able to read captured packets > which come from earlier capture, the one which was saved > by OpenBSD's tcpdump _without_ patched libpcap. I was using lo0 > for test. Everything worked as expected. I could test with > loopback only. > > this change is OK sashan@ > > thanks and > regards > sashan > I think it's reasonable to do this too, OK sthen@
Re: snmpd snmpe AgentX disappeared unexpected
On 2023/07/27 11:31, Marko Cupać wrote: > Hi, > > snmpd crashed on my 7.2 amd64, I'm sending snmpd.conf, log excerpt and > dmesg. Could this be a bug or I'm misconfiguring something? Thank you > in advance. Try updating, there were a number of fixes post-7.2. You may be able to update just snmpd from 7.3 src.
patch crash related to remove_special_lines
I ran into a segfault with patch(1) in a port, here's a test case with a
minimal reproducer.
$ echo foo > test
$ perl -e 'print "--- test.orig\n+++ test\n@@ -1,1 +1,2 @@\n foo\n+" . 'x' x
32768 . "\n\\ No newline at end of file\n"' > test.patch
$ patch < test.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|--- test.orig
|+++ test
--
Patching file test using Plan A...
Segmentation fault (core dumped)
$ egdb -q /usr/src/usr.bin/patch/obj/patch patch.core
Reading symbols from /usr/src/usr.bin/patch/obj/patch...
[New process 276205]
Core was generated by `patch'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0f18920a76e0 in another_hunk () at /usr/src/usr.bin/patch/pch.c:1008
1008s[p_len[filldst - 1]] =
0;
(gdb) list
1003p_line[filldst] = s;
1004p_len[filldst++] = strlen(s);
1005if (fillsrc > p_ptrn_lines) {
1006if (remove_special_line()) {
1007p_len[filldst - 1] -= 1;
1008s[p_len[filldst - 1]] =
0;
1009}
1010}
1011break;
1012default:
(gdb) quit
$
Re: could there be a breach of license in efiboot?
On 2023/07/10 05:22, Peter J. Philipp wrote: > Redistributions in binary form must reproduce the above copyright > notice, this list of conditions and the following disclaimer in > the documentation and/or other materials provided with the > distribution. > This should be included on all the efiboot distributions on install disks. IANAL, but I don't get anything from that text suggesting that it has to be included _on_ the install image, just "provided with". Seems to me that the source tree, which includes that list, is provided with the distribution. > Here is another license: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/stand/efi/include/efi.h?rev=1.1=text/plain > > /*++ > > Copyright (c) 1999 - 2002 Intel Corporation. All rights reserved > This software and associated documentation (if any) is furnished > under a license and may only be used or copied in accordance > with the terms of the license. Except as permitted by such > license, no part of this software or documentation may be > reproduced, stored in a retrieval system, or transmitted in any > form or by any means without the express written consent of > Intel Corporation. This refers to "a license" but doesn't state it, they're talking about the same one mentioned above aren't they? (I'm not sure efi.h really has anything copyrightable in anyway though?)
Re: 'scsi_xfer pool exhausted' console spam, system unresponsive
Are you monitoring memory usage too? My first instinct is that 2GB feels a bit low so I'd want to get some stats on that. (I have reported these on i386 ports builders from time to time too, I can't do much about memory use there though..) -- Sent from a phone, apologies for poor formatting. On 5 July 2023 16:09:06 Lucas wrote: Synopsis: 'scsi_xfer pool exhausted' console spam, system unresponsive Category: Environment: System : OpenBSD 7.3 Details : 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 Architecture: OpenBSD.amd64 Machine : amd64 Description: This machine runs a got (gameoftrees) mirror. Every 15 minutes, it contacts the main mirror with 'got fetch' (small network and disk I/O) and then runs 'git gc' (expensive disk I/O, am told by op@ and stsp@). After some unknown time running, this tasks will make the CPU spike (graphs in [0] and [1]) until eventually the system becomes unresponsive. 2 of the 3 times it happened, the console was being spammed with 'scsi_xfer pool exhausted' messages. Of potential importance is that this is Hetzner CAX11 VPS in their new region, Hillsboro. [0]: https://glacier.lgv5.net/tmp/lemon-20230626.png [1]: https://glacier.lgv5.net/tmp/lemon-20230705.png How-To-Repeat: No clue. Happens every 1-3 weeks I think. Fix: No clue. Can try out patches. 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 = 2080227328 (1983MB) avail mem = 1997840384 (1905MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf59d0 (10 entries) bios0: vendor Hetzner version "2017" date 11/11/2017 bios0: Hetzner vServer acpi0 at bios0: ACPI 3.0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC HPET MCFG WAET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC Processor, 2445.58 MHz, 17-31-00 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,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC Processor, 2445.66 MHz, 17-31-00 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,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 96:00:01:e4:f0:79 virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 xhci0 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000d rev 0x01: apic 0 int
Re: dvmrpd reports "routeroute decision engine terminated; signal 11"
On 2023/07/03 14:52, Why 42? The lists account. wrote: > > Hi All, > > FYI, after patching the kernel (See: discussion from June 7th entitled > "dvmrpd start causes kernel panic: assertion failed") I am able to run > the dvmrpd multicast routing daemon and indeed it seems to be doing > something, I see messages logged regarding multicast IP address groups > or ranges that are in use, or at least configured. > > Strangely though, the daemon occasionally logs these messages: > ... > kmr_shutdown: interface em0 > waiting for children to terminate > route decision engine terminated; signal 11 > fatal in dvmrpe: msgbuf_write: Broken pipe > > It's unclear to me if this is normal operation or not, but signal 11 > (segmentation violation?) certainly doesn't look typical ... > > Should a signal 11 result in a core file being dumped? I don't find any > in any of the likely places e.g. the starting directory. > > Thanks for any tips! > > Cheers, > Robb. > mkdir -m 700 /var/crash/dvmrpd sysctl kern.nosuidcoredump=3
Re: Xorg totally freezes after a while while using picom or playing 2d or 3d games
On 2023/07/02 06:52, chris greek wrote: > Xorg totally freezes after a while while using picom or playing 2d or 3d > games > If i don't use picom it doesn't seem to have a problem but i tried playing > a 2d game and also freezed. > I have an R7 240 with 2Gbytes of Ram , my pc has 8 Gbytes of ram > I don't know what is the problem but it always happens > The xorg freezes and i can't do anything if change into a console and don't > kill Xorg it completely freezes the pc and can't switch to a console > anymore. It may be panicking and entering ddb. See if it reboots if you blindly type "boot r". Send a dmesg as well.
Re: ftp(1) will never attempt to set the modification date of any file retrieved by http[s]
On 2023/06/28 12:19, Theo Buehler wrote:
> > Good catch. It's the only header where we forget to skip leading
> > blanks.
>
> This was overlooked in fetch.c r1.209
ah I was wondering about that, because it definitely used to work.
> ok tb
and from me.
> >
> > I can reproduce and confirm that this does indeed fix the parsing and
> > make ftp set the mtime accordingly to Last-Modified.
> >
> > > diff --git i/usr.bin/ftp/fetch.c w/usr.bin/ftp/fetch.c
> > > index 0ba7ad4d099..b6d6f4d775a 100644
> > > --- i/usr.bin/ftp/fetch.c
> > > +++ w/usr.bin/ftp/fetch.c
> > > @@ -984,6 +984,7 @@ noslash:
> > > } else if (strncasecmp(cp, LAST_MODIFIED,
> > > sizeof(LAST_MODIFIED) - 1) == 0) {
> > > cp += sizeof(LAST_MODIFIED) - 1;
> > > + cp += strspn(cp, " \t");
> > > cp[strcspn(cp, "\t")] = '\0';
> > > if (strptime(cp, "%a, %d %h %Y %T %Z", ) == NULL)
> > > server_timestamps = 0;
> >
> >
>
Re: kernel reordering happily consumes invalid objects
On 2023/06/14 04:12, Schech, C. W. ("Connor") wrote:
> There's no check of the checksums for all the object files that the
> /rc task consumes
>
> This can be trivially fixed by generating them in, say
>
> In /sys/conf/newvars.sh, add the line:
>
> +sha512 -h /var/db/obj.${id}.sha512 *.o lorder
>
> above the segment starting with:
>
> cat >vers.c <
> [...]
>
> then the right checksums always persist in /var/db on release or
> between builds, labelled with the {id}
>
> in /etc/rc or kernel_reorder, before invoking the kernel reordering
> routine, make a guard statement that checks that all the object
> checksums are OK, i.e.,
How do you know the .o files from the build are ok in the first place?
If you don't trust your hardware to keep the installed copy safe, why
would the build be any different?
> Also consider moving the relinking to "only at shutdown", so no other
> jobs are running concurrently in case that causes a random kernel
> fault due to extreme load on faulty hardware, and to make the boot
> time as fast as possible, since the relinked kernel isn't used until
> the boot after AFAIK.
Consideration was already made to the timing of when this is run.
Shutdown doesn't always happen. It can sometimes happen triggered by
a UPS running low on battery, in which case writing out a new kernel
is about the worst thing you can be doing at the time. There's no
"one size fits all" and there are problems with the current timing too,
but it's the least worst option for many cases (and can be disabled and
run manually if it's a big problem for your use).
> Also conside not using a link kit and just scrambling kernel A with
> lorder C into kernel B with lorder D without carrying around any
> object code (by default) in the environment that persists anywhere.
reorder_kernel is also there to support syspatch. (even just the hash
check also needs to take syspatch into account).
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
On 2023/06/13 11:57, Matthias Schmidt wrote: > $ pkg_info -vv screen | head -30 > Information for inst:screen-4.9.0 > [...] > Size: 1244302 > Signature: screen-4.9.0,10,c.97.0,curses.14.0,util.16.0 > Packing-list: > @comment $OpenBSD: PLIST,v 1.24 2019/08/15 21:01:49 naddy Exp $ > @name screen-4.9.0 > @url file:./screen-4.9.0.tgz > @version 10 I'm at a loss to explain how you've got screen-4.9.0 linked against libc.so.97.0 with @version 10 but with @comment still in the PLIST. The only way I can see is building locally with parts of an old and parts of a new ports tree. However that happened, I think it is beyond what pkg_add -u can be expected to deal with.
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
On 2023/06/12 18:52, Sebastien Marie wrote: > note that instead of using pkg_delete, you could use: `pkg_add -Dinstalled > -u' > to force reinstalling already installed packages. if it gets to this point for anyone else, we would like to see the state of /var/db/pkg and try to figure out why things aren't getting updated specifically on amd64 if you have a bunch of packages left with "@version 9" in the +CONTENTS file for that package, then it probably didn't get updated correctly for some reason or other
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
On 2023/06/12 19:21, Peter N. M. Hansteen wrote: > On Mon, Jun 12, 2023 at 05:50:13PM +0100, Stuart Henderson wrote: > > On 2023/06/12 18:34, Peter N. M. Hansteen wrote: > > > On Mon, Jun 12, 2023 at 05:08:20PM +0100, Stuart Henderson wrote: > > > > Ah, the next thing I would have suggested in that cause would have > > > > been pkg_add -vvvu run under typescript, which might have given us a > > > > clue why it wasn't updated (the system package version, recorded in > > > > @version lines in /var/db/pkg/*/+CONTENTS, was raised - so pkg_add -u > > > > _should_ have updated them all). > > > > > > > > > > possibly better late than never, there are still packages that are > > > failing, so > > > here is the typescript from just now - > > > > > > https://nxdomain.no/~peter/2023-06-12_pkg_add_vvvu_output_zaida.bsdly.net.txt > > > > > > All the best, > > > Peter > > > > ah interesting :) > > > > in which other package/s have you seen a problem, and can you send me a > > 'head -30 /var/db/pkg/$pkgname/+CONTENTS' for them please? > > > > Oh, absolutely. Firefox: > > [Mon Jun 12 19:17:23] peter@zaida:~$ head -30 > /var/db/pkg/firefox-114.0.1/+CONTENTS > @name firefox-114.0.1 > @url > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/firefox-114.0.1.tgz > @version 10 Thanks - the "@version 10" shows that this was updated. Here are some of the known problem ports for IBT enforcement: various mozillas the various chromium derivatives + anything using v8 ffmpeg libreoffice chromium itself is also a problem but there is currently a workaround in the kernel via a process name check on "chrome" We have an annotation we can use during ports build to mark binaries to disable enforcement, this will get added to some ports with known problems (but I think it maybe a bit problematic when it's a _library_ which doesn't yet work with IBT enforcement - in that case AIUI we'll need to annotate all binaries using that library..) > @signer openbsd-73-pkg > @digital-signature signify2:2023-06-11T20:27:37Z:external > @option manual-installation > @comment pkgpath=www/mozilla-firefox ftp=yes > @arch amd64 > +DESC > @sha LtQcl2Xn0LDK5kWxuGklXoRyDX/N+y0oXu1piOVnnhE= > @size 601 > @conflict firefox3-* > @conflict firefox35-* > @conflict firefox36-* > @conflict mozilla-firebird-* > @conflict mozilla-firefox-* > @pkgpath www/firefox3 > @pkgpath www/firefox35 > @pkgpath www/firefox36 > @pkgpath www/firefox4 > @pkgpath www/mozilla-firefox,-main > @depend devel/desktop-file-utils:desktop-file-utils-*:desktop-file-utils-0.26 > @depend devel/nspr:nspr->=4.35:nspr-4.35 > @depend security/nss:nss->=3.84:nss-3.90 > @depend textproc/icu4c,-main:icu4c-*:icu4c-73.1v0 > @depend x11/gtk+3,-main:gtk+3-*:gtk+3-3.24.38 > @depend x11/gtk+4,-guic:gtk4-update-icon-cache-*:gtk4-update-icon-cache-4.10.4 > @wantlib X11-xcb.2.0 > @wantlib X11.18.0 > @wantlib Xcomposite.4.0 > > thunderbird: > > [Mon Jun 12 19:17:45] peter@zaida:~$ head -30 > /var/db/pkg/thunderbird-102.12.0/+CONTENTS > @name thunderbird-102.12.0 > @url > https://cloudflare.cdn.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/thunderbird-102.12.0.tgz > @version 10 > @signer openbsd-73-pkg > @digital-signature signify2:2023-06-11T20:33:35Z:external > @option manual-installation > @comment pkgpath=mail/mozilla-thunderbird ftp=yes > @arch amd64 > +DESC > @sha uGHKT1MHnjf7Tl3oCctE0gRbeeA8UBZ1gWTuc0Fx6L8= > @size 748 > @conflict mozilla-thunderbird-<74.0 > @conflict lightning-<74.0v0 > @pkgpath mail/mozilla-thunderbird,-main > @pkgpath mail/mozilla-thunderbird,-lightning > @depend devel/desktop-file-utils:desktop-file-utils-*:desktop-file-utils-0.26 > @depend devel/libffi:libffi-*:libffi-3.4.4 > @depend devel/nspr:nspr->=4.35:nspr-4.35 > @depend security/nss:nss->=3.84:nss-3.90 > @depend security/rnp:rnp-*:rnp-0.16.3 > @depend x11/gtk+3,-main:gtk+3-*:gtk+3-3.24.38 > @depend x11/gtk+4,-guic:gtk4-update-icon-cache-*:gtk4-update-icon-cache-4.10.4 > @wantlib X11-xcb.2.0 > @wantlib X11.18.0 > @wantlib Xcomposite.4.0 > @wantlib Xcursor.5.0 > @wantlib Xdamage.4.0 > @wantlib Xext.13.0 > @wantlib Xfixes.6.1 > @wantlib Xi.12.2 > > There may well be others, but those are ones I use rather frequently. > > - Peter > > -- > Peter N. M. Hansteen, member of the first RFC 1149 implementation team > https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ > "Remember to set the evil bit on all malicious network traffic" > delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. >
Re: On 2013-06-12 snapshot xfce4 session dies immediately after xenodm login
On 2023/06/12 16:54, Peter N. M. Hansteen wrote: > On Mon, Jun 12, 2023 at 04:47:41PM +0200, Sebastien Marie wrote: > > > (gdb) > > > > > > with some instruction I might be able to extract more information. > > > > > > > failing in _start is odd. it look like the binary wasn't build with > > cf-protection=branch, and the compiler has it since few weeks now (since > > 2023-04-26 exactly). > > > > Could you check the signature date of your package ? > > > > $ grep @digital-signature /var/db/pkg/xfce4-session-*/+CONTENTS > > @digital-signature signify2:2023-06-10T10:18:49Z:external > > [Mon Jun 12 16:49:33] peter@zaida:~$ grep @digital-signature > /var/db/pkg/xfce4-session-*/+CONTENTS > @digital-signature signify2:2023-04-16T09:46:52Z:external Please run pkg_add -u and see if it fixes it.
Re: OpenBSD in QEMU KVM: High QEMU CPU usage when OpenBSD is 100% idle
On 2023/05/27 15:35, Mike Larkin wrote: > On Sat, May 27, 2023 at 10:29:37AM +0200, Claudio Jeker wrote: > > On Sat, May 27, 2023 at 09:16:23AM +0100, Stuart Henderson wrote: > > > On 2023/05/27 06:36, br...@mailbox.org wrote: > > > > > > > > > > > > On Sat, 27 May 2023, Mike Larkin wrote: > > > > > > > > > probably IPI traffic then. not sure what else to say. If a few % host > > > > > overhead > > > > > is too much fot you with a 16 vCPU VM, I'd suggest reducing that. > > > > > > > > > > What is your workload for a 16 vcpu openbsd VM anyway? > > > > > > > > I would like to use the OpenBSD VM as my main workstation. I also need > > > > to > > > > use Linux for some graphic intensive stuff, so the ideal OpenBSD on host > > > > with vmm for Linux is not an option unfortunately. I guess I could > > > > accept > > > > that CPU usage price, but of course not having to pay it would be > > > > better. > > > > > > OpenBSD doesn't do brilliantly with that many CPUs yet. Things are > > > getting better but I think you're likely to find many workloads are a > > > bit less laggy with half that. > > > > Also a few % CPU on the host can be caused by the interrupts caused by the > > clocks on every CPU. It may be that we do not select a cheap clock source > > like TSC and the result is much more overhead on the host. > > > > -- > > :wq Claudio > > > > yes I did not think of that; thanks Claudio! > > OP: what is your sysctl kern.timecounter ? on kvm I would expect pvclock to be preferred if the driver thinks it's stable, otherwise probably acpihpet. fwiw mine looks like this. $ sysctl kern.timecounter kern.timecounter.tick=1 kern.timecounter.timestepwarnings=0 kern.timecounter.hardware=acpihpet0 kern.timecounter.choice=i8254(0) pvclock0(500) acpihpet0(1000) acpitimer0(1000)
Re: OpenBSD in QEMU KVM: High QEMU CPU usage when OpenBSD is 100% idle
On 2023/05/27 06:36, br...@mailbox.org wrote: > > > On Sat, 27 May 2023, Mike Larkin wrote: > > > probably IPI traffic then. not sure what else to say. If a few % host > > overhead > > is too much fot you with a 16 vCPU VM, I'd suggest reducing that. > > > > What is your workload for a 16 vcpu openbsd VM anyway? > > I would like to use the OpenBSD VM as my main workstation. I also need to > use Linux for some graphic intensive stuff, so the ideal OpenBSD on host > with vmm for Linux is not an option unfortunately. I guess I could accept > that CPU usage price, but of course not having to pay it would be better. OpenBSD doesn't do brilliantly with that many CPUs yet. Things are getting better but I think you're likely to find many workloads are a bit less laggy with half that.
Re: pfctl problem with osfp parser
On 2023/05/25 17:40, Alexandr Nedvedicky wrote:
> Hello,
>
> I took a look at signatures:
> > https://tools.netsa.cert.org/p0f/p0f.fp.2012032901 signatures file (pf.os),
>
> This change is not about updating parser it looks like it will
> also require to update matching stuff in kernel. I have not looked
> at all details yet.
as well as PF, this database is used by tcpdump (-o).
quirks were added in p0f v2.x (p0f upstream is now at version 3.x which
has a completely different database).
(p0f 2.x is in ports)
> below is fingerprint entry format as found in etc/pf.os we have
> in current:
>
> # Fingerprint entry format:
> #
> # :ttt:D:ss:OOO...:OS:Version:Subtype:Details
> #
> # - window size (can be *, %nnn, Snn or Tnn). The special values
> #"S" and "T" which are a multiple of MSS or a multiple of MTU
> #respectively.
> # ttt - initial TTL
> # D- don't fragment bit (0 - not set, 1 - set)
> # ss - overall SYN packet size
> # OOO - option value and order specification (see below)
> # OS - OS genre (Linux, Solaris, Windows)
> # Version - OS Version (2.0.27 on x86, etc)
> # Subtype - OS subtype or patchlevel (SP3, lo0)
> # details - Generic OS details
>
> and here is a format description from link above
>
> # Fingerprint entry format:
> #
> # :ttt:D:ss:OOO...:QQ:OS:Details
> #
> # - window size (can be * or %nnn or Sxx or Txx)
> # "Snn" (multiple of MSS) and "Tnn" (multiple of MTU) are allowed.
> # ttt - initial TTL
> # D- don't fragment bit (0 - not set, 1 - set)
> # ss - overall SYN packet size (* has a special meaning)
> # OOO - option value and order specification (see below)
> # QQ - quirks list (see below)
> # OS - OS genre (Linux, Solaris, Windows)
> # details - OS description (2.0.27 on x86, etc)
>
>
> # Quirks section is usually an empty list ('.') of oddities or bugs of this
> # particular stack. List items are not separated in any way. Possible values:
> #
> # P - options past EOL,
> # Z - zero IP ID,
> # I - IP options specified,
> # U - urg pointer non-zero,
> # X - unused (x2) field non-zero,
> # A - ACK number non-zero,
> # T - non-zero second timestamp,
> # F - unusual flags (PUSH, URG, etc),
> # D - data payload,
> # ! - broken options segment.
>
>
> quirks are new and I think we will also have to update code in kernel too.
>
> I'm afraid it's more than just fixing the parser.
>
> regards
> sashan
>
> On Mon, May 22, 2023 at 06:50:34PM +0300, wrote:
> > Apologize in advance for my bad english :) I am trying to use this
> > https://tools.netsa.cert.org/p0f/p0f.fp.2012032901 signatures file (pf.os),
> > as far as I understand, it is newer than the one that comes with the OS
> > (and maybe you will update it too). "too short OS description" error
> > appears when trying to apply rules (pfctl -f /etc/pf.conf).
> >
> > I think the problem is somewhere in parser, judging by the description in
> > the file at the link I provided:
> >
> > # If OS genre starts with '*', p0f will not show distance, link type
> > # and timestamp data. It is useful for userland TCP/IP stacks of
> > # network scanners and so on, where many settings are randomized or
> > # bogus.
> > #
> > # If OS genre starts with @, it denotes an approximate hit for a group
> > # of operating systems (signature reporting still enabled in this case).
> > # Use this feature at the end of this file to catch cases for which
> > # you don't have a precise match, but can tell it's Windows or FreeBSD
> > # or whatnot by looking at, say, flag layout alone.
> > #
> > # If OS genre starts with - (which can prefix @ or *), the entry is
> > # not considered to be a real operating system (but userland stack
> > # instead). It is important to mark all scanners and so on with -,
> > # so that they are not used for masquerade detection (also add this
> > # prefix for signatures of application-induced behavior, such as
> > # increased window size with Opera browser).
> >
> > Attaching the dump of ktrace. OpenBSD version: 7.3
>
>
Re: Is it possible to use torrent to distribute OpenBSD?
On 2023/05/23 00:05, Abel Abraham Camarillo Ojeda wrote: > In some countries ISPs limit aggressively the throughput of single tcp > connections and sometimes this isn't done on purpose but can happen due to problems in their equipment. > and torrents are the only mean available to get more than 20% > your billed speed not the only way, you can run parallel http downloads from servers that handle "range" requests. see e.g. aria2
Re: group owner segmentation
On 2023/05/21 12:49, panpansh wrote: > Hi, trying this: > > chmod o-rx /usr/bin/ftp; groupadd g_fetch; usermod -G g_fetch _pkgfetch; > chown root:g_fetch /usr/bin/ftp > > # pkg_add: can't exec /usr/bin/ftp: permission denied at > /usr/libdata/perl5/OpenBSD/PackageRepository.pm line 869 > > # offcourse setting _pkgfetch as group owner of /usr/bin/ftp raise no error > executing pkg_add. But its restrictive and not the goal > . You don't mention what the goal is. But it's possible that it might be better solved by using PF "user" and/or "group" rules, which will also restrict network access from programs other than ftp (since there are a couple of other programs in base which would allow doing basically the same thing).
Re: Can't sync local usb mounted mirror with openrsync
On 2023/05/16 22:38, Julian Huhn wrote: > I have an external hard drive that I want to use as a storage > location for a local mirror. The initial synchronization of the > mirror went through successfully with openrsync, but each new run > hangs either with no error or with the following error message: > > openrsync: error: poll: hangup > openrsync: error: io_write_nonblocking > openrsync: error: io_write_nonblocking > openrsync: error: rsync_uploader > openrsync: error: rsync_receiver > > The problem is reproducible for all tested mirrors from the official > list: https://www.openbsd.org/ftp.html#rsync Even if it had worked, please don't use openrsync for that, it speaks an old protocol version which requires the mirror to transfer full file list in one go. Use the original rsync from packages.
Re: Some programs appear to cause system to leak memory, fill ram
On 2023/05/16 09:12, Rudolf Leitgeb wrote: > Lots of people (including myself) come from linux background and use > OpenBSD for specific security sensitive tasks. Since OpenBSD, like > every other desktop OS these days, has some strategy to deal > with OOM conditions, the term "OOM killer" is perfectly clear > regardless of what the actual implementation in OpenBSD is called. > > On Mon, 2023-05-15 at 21:32 +0100, Stuart Henderson wrote: > > On 2023/05/15 19:55, bugreport555 wrote: > > > Ok, I tested it in various ways and tried to force OOM killer to > > > step in but it never did and all worked fine. > > > > OOM killer? This isn't Linux. > > > The strategy is that the sysadmin should configure datasize limits so that processes hit memory allocation failures if they try to overreach. Defaults are setup with typical use-cases and machines in mind but you might know better and adjust. The kernel doesn't cope particularly well if you actually run out of memory. Long delays, deadlocks, panics are likely. Yes bugs, but they are difficult ones, and the above strategy (i.e. use the system's built in protection mechanisms for userland processes) is not a bad one. (I understand that even on Linux with "OOM killer" it is often still advisable to reboot when possible after triggering it.)
Re: Some programs appear to cause system to leak memory, fill ram
On 2023/05/15 19:55, bugreport555 wrote: > Ok, I tested it in various ways and tried to force OOM killer to step in but > it never did and all worked fine. OOM killer? This isn't Linux.
Re: OpenBSD 7.3/amd64 on APU4D4 - system drops into ddb
On 2023/05/15 16:29, Radek wrote:
> Hello,
> continuing the previous topic [1] my APU4D4 router randomly drops into ddb
> when runnig 7.3/amd64. At some crashes my serial console is not responding
> too.
> I attached dmesg and ddb console output of my last crash.
> Maybe there is a hardware issue...
>
> 1. https://marc.info/?t=16609992761=1=2
>
> ddb{0}> show panic
> the kernel did not panic
Do you have a log of what was output on the console when the system
entered DDB?
Re: Intel Ethernet (?Synopsys based) on Filet3 Elkhart Lake unconfigured on recent snapshot
On 2023/05/02 19:03, Ted Ri wrote: > According to Compulab the Fitlet3 onboard Ethernet uses Marvell 88E1512 phys. > The data sheet from Marvell is here: > > https://www.marvell.com/content/dam/marvell/en/public-collateral/phys-transceivers/marvell-phys-transceivers-alaska-88e151x-datasheet.pdf The PHY is likely already supported or very close to something already supported, it's the network interface itself that isn't.
Re: intel t14 gen3: microphone recording does not work
On 2023/04/25 19:40, Klemens Nanni wrote:
> Speakers work fine, 'aucat -o rec.wav' produces non-zero data,
> but 'aucat -i rec.wav' keeps quiet ('mpv song73.ogg' plays).
>
> https://www.openbsd.org/faq/faq13.html#enablerec did not help me,
> there is nothing muted and I did not find a knob to tweak to make it work.
Do you mean the internal mic array? I believe it will need sof-firmware
that we don't have support for.
Re: lock order reversal: drmwq and wakeref.mutex
On 2023/04/24 16:05, Klemens Nanni wrote: > On Mon, Apr 24, 2023 at 04:58:08PM +0100, Stuart Henderson wrote: > > On 2023/04/24 15:50, Klemens Nanni wrote: > > > cpu0: 12th Gen Intel(R) Core(TM) i7-1270P, 2095.31 MHz, 06-9a-03 > > > > ah you got one of the warm CPU versions then :) > > what does that mean? there are U and P versions of the intel 12g laptop CPUs, P are faster but I found a few comments that they can run a little on the toasty side.
Re: lock order reversal: drmwq and wakeref.mutex
On 2023/04/24 15:50, Klemens Nanni wrote: > cpu0: 12th Gen Intel(R) Core(TM) i7-1270P, 2095.31 MHz, 06-9a-03 ah you got one of the warm CPU versions then :)
Re: intel T14 gen 3, picom triggers page fault trap in dpt_insert_entries
On 2023/04/24 15:00, Stuart Henderson wrote:
> > Looking over the local changes to i915_scatterlist.h the segment size
> > could be larger, I'm not sure if that would help.
>
> I will try that and report back after lunch.
Doesn't help.
>
> > Index: dev/pci/drm/i915/i915_scatterlist.h
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_scatterlist.h,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 i915_scatterlist.h
> > --- dev/pci/drm/i915/i915_scatterlist.h 1 Jan 2023 01:34:54 -
> > 1.3
> > +++ dev/pci/drm/i915/i915_scatterlist.h 24 Apr 2023 13:15:46 -
> > @@ -153,7 +153,7 @@ static inline unsigned int i915_sg_segme
> > #else
> > static inline unsigned int i915_sg_segment_size(struct device *dev)
> > {
> > - return PAGE_SIZE;
> > + return round_down(UINT_MAX, PAGE_SIZE);
> > }
> > #endif
> >
> >
> > > dpt_bind_vma(81a1cc00,0,fd83b9afd178,0,400) at
> > > dpt_bind_vma+0x64
> > > i915_vma_bind(81ce4ec0,0,400,0,fd83b9afd178) at
> > > i915_vma_bind+0x319
> > > i915_vma_pin_ww(81ce4ec0,800033b78db0,0,20,400) at
> > > i915_vma_pin_ww+0x454
> > > intel_plane_pin_fb(81cc9000) at intel_plane_pin_fb+0x25c
> > > intel_prepare_plane_fb(814c7400,81cc9000) at
> > > intel_prepare_plane_fb+0x127
> > > drm_atomic_helper_prepare_planes(8044c078,81cda000) at
> > > drm_atomic_helper_prepare_planes+0x5b
> > > intel_atomic_commit(8044c078,81cda000,1) at
> > > intel_atomic_commit+0xda
> > > drm_atomic_helper_page_flip(814c2800,81e41200,81d55300,1,800033b79048)
> > > at drm_atomic_helper_page_flip+0x77
> > > drm_mode_page_flip_ioctl(8044c078,800033b793e0,8195bc00)
> > > at drm_mode_page_flip_ioctl+0x466
> > > drm_do_ioctl(8044c078,100,c01864b0,800033b793e0) at
> > > drm_do_ioctl+0x29e
> > > drmioctl(15700,c01864b0,800033b793e0,3,800033bba5c8) at
> > > drmioctl+0xdc
> > > VOP_IOCTL(fd845bb870f0,c01864b0,800033b793e0,3,fd845efad750,800033bba5c8)
> > > at VOP_IOCTL+0x60
> > > vn_ioctl(fd845bd084c0,c01864b0,800033b793e0,800033bba5c8) at
> > > vn_ioctl+0x79
> >
>
Re: intel T14 gen 3, picom triggers page fault trap in dpt_insert_entries
On 2023/04/24 23:53, Jonathan Gray wrote:
> On Mon, Apr 24, 2023 at 01:49:32PM +0100, Stuart Henderson wrote:
> > Running picom (with no special config or command line flags) on intel
> > T14 gen 3 fairly easily triggers a crash in drm. If it doesn't fail the
> > first time, exiting and restarting a few times pretty much always
> > triggers it.
> >
> > Full proc listing below after dmesg, Xorg is the only active process
> > at the time.
> >
> > xcompmgr hasn't yet triggered it.
> >
> >
> > uvm_fault(0x824b4570, 0x81e73014, 0, 1) -> e
> > kernel: page fault trap, code=0
> > Stopped at dpt_insert_entries+0xbc:movl0x34(%r8),%r10d
> > TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
> >
> > *459624 48440 350x12 04K Xorg
> >
> > dpt_insert_entries(81a1cc00,fd83b9afd178,0,0) at
> > dpt_insert_entries+0xbc
>
> this is line 34 of /sys/dev/pci/drm/i915/i915_scatterlist.h
>
> 23 static __always_inline struct sgt_iter {
> 24 struct scatterlist *sgp;
> 25 union {
> 26 unsigned long pfn;
> 27 dma_addr_t dma;
> 28 };
> 29 unsigned int curr;
> 30 unsigned int max;
> 31 } __sgt_iter(struct scatterlist *sgl, bool dma) {
> 32 struct sgt_iter s = { .sgp = sgl };
> 33
> 34 if (dma && s.sgp && sg_dma_len(s.sgp) == 0) {
> 35 s.sgp = NULL;
> 36 } else if (s.sgp) {
>
> sgl is pointing to something that isn't there?
>
> I have an intel t14 gen 3 but can't reproduce this.
> Running fvwm from xenocara and starting picom from xterm 20 times or so,
> ^C after each.
I'm using i3, though I used to have picom in .xsession which was started
very early - certainly before the wm loaded - and that was crashing too.
Currently this is twin display (internal + an HDMI display connected to
a USB-C dock, attached via DP-3) though I first ran into with just the
internal display. (Took me a little while to get to a state where I
could type into ddb).
> Looking over the local changes to i915_scatterlist.h the segment size
> could be larger, I'm not sure if that would help.
I will try that and report back after lunch.
> Index: dev/pci/drm/i915/i915_scatterlist.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_scatterlist.h,v
> retrieving revision 1.3
> diff -u -p -r1.3 i915_scatterlist.h
> --- dev/pci/drm/i915/i915_scatterlist.h 1 Jan 2023 01:34:54 -
> 1.3
> +++ dev/pci/drm/i915/i915_scatterlist.h 24 Apr 2023 13:15:46 -
> @@ -153,7 +153,7 @@ static inline unsigned int i915_sg_segme
> #else
> static inline unsigned int i915_sg_segment_size(struct device *dev)
> {
> - return PAGE_SIZE;
> + return round_down(UINT_MAX, PAGE_SIZE);
> }
> #endif
>
>
> > dpt_bind_vma(81a1cc00,0,fd83b9afd178,0,400) at dpt_bind_vma+0x64
> > i915_vma_bind(81ce4ec0,0,400,0,fd83b9afd178) at
> > i915_vma_bind+0x319
> > i915_vma_pin_ww(81ce4ec0,800033b78db0,0,20,400) at
> > i915_vma_pin_ww+0x454
> > intel_plane_pin_fb(81cc9000) at intel_plane_pin_fb+0x25c
> > intel_prepare_plane_fb(814c7400,81cc9000) at
> > intel_prepare_plane_fb+0x127
> > drm_atomic_helper_prepare_planes(8044c078,81cda000) at
> > drm_atomic_helper_prepare_planes+0x5b
> > intel_atomic_commit(8044c078,81cda000,1) at
> > intel_atomic_commit+0xda
> > drm_atomic_helper_page_flip(814c2800,81e41200,81d55300,1,800033b79048)
> > at drm_atomic_helper_page_flip+0x77
> > drm_mode_page_flip_ioctl(8044c078,800033b793e0,8195bc00)
> > at drm_mode_page_flip_ioctl+0x466
> > drm_do_ioctl(8044c078,100,c01864b0,800033b793e0) at
> > drm_do_ioctl+0x29e
> > drmioctl(15700,c01864b0,800033b793e0,3,800033bba5c8) at
> > drmioctl+0xdc
> > VOP_IOCTL(fd845bb870f0,c01864b0,800033b793e0,3,fd845efad750,800033bba5c8)
> > at VOP_IOCTL+0x60
> > vn_ioctl(fd845bd084c0,c01864b0,800033b793e0,800033bba5c8) at
> > vn_ioctl+0x79
>
intel T14 gen 3, picom triggers page fault trap in dpt_insert_entries
Running picom (with no special config or command line flags) on intel T14 gen 3 fairly easily triggers a crash in drm. If it doesn't fail the first time, exiting and restarting a few times pretty much always triggers it. Full proc listing below after dmesg, Xorg is the only active process at the time. xcompmgr hasn't yet triggered it. uvm_fault(0x824b4570, 0x81e73014, 0, 1) -> e kernel: page fault trap, code=0 Stopped at dpt_insert_entries+0xbc:movl0x34(%r8),%r10d TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *459624 48440 350x12 04K Xorg dpt_insert_entries(81a1cc00,fd83b9afd178,0,0) at dpt_insert_entries+0xbc dpt_bind_vma(81a1cc00,0,fd83b9afd178,0,400) at dpt_bind_vma+0x64 i915_vma_bind(81ce4ec0,0,400,0,fd83b9afd178) at i915_vma_bind+0x319 i915_vma_pin_ww(81ce4ec0,800033b78db0,0,20,400) at i915_vma_pin_ww+0x454 intel_plane_pin_fb(81cc9000) at intel_plane_pin_fb+0x25c intel_prepare_plane_fb(814c7400,81cc9000) at intel_prepare_plane_fb+0x127 drm_atomic_helper_prepare_planes(8044c078,81cda000) at drm_atomic_helper_prepare_planes+0x5b intel_atomic_commit(8044c078,81cda000,1) at intel_atomic_commit+0xda drm_atomic_helper_page_flip(814c2800,81e41200,81d55300,1,800033b79048) at drm_atomic_helper_page_flip+0x77 drm_mode_page_flip_ioctl(8044c078,800033b793e0,8195bc00) at drm_mode_page_flip_ioctl+0x466 drm_do_ioctl(8044c078,100,c01864b0,800033b793e0) at drm_do_ioctl+0x29e drmioctl(15700,c01864b0,800033b793e0,3,800033bba5c8) at drmioctl+0xdc VOP_IOCTL(fd845bb870f0,c01864b0,800033b793e0,3,fd845efad750,800033bba5c8) at VOP_IOCTL+0x60 vn_ioctl(fd845bd084c0,c01864b0,800033b793e0,800033bba5c8) at vn_ioctl+0x79 OpenBSD 7.3-current (GENERIC.MP) #2: Mon Apr 24 08:24:39 BST 2023 st...@lundy.spacehopper.org:/sys/arch/amd64/compile/GENERIC.MP real mem = 16814370816 (16035MB) avail mem = 16285147136 (15530MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8d8a3000 (81 entries) bios0: vendor LENOVO version "N3MET12W (1.11 )" date 02/09/2023 bios0: LENOVO 21AJS4GY00 efi0 at bios0: UEFI 2.7 efi0: Lenovo rev 0x1110 acpi0 at bios0: ACPI 6.3 acpi0: sleep states S0 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 PHAT UEFI FPDT ASF! BGRT 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) i5-1245U, 1720.17 MHz, 06-9a-04 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,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: 12th Gen Intel(R) Core(TM) i5-1245U, 1893.04 MHz, 06-9a-04 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 10-way L2 cache, 12MB 64b/line 12-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 8 (application processor) cpu2: 12th Gen Intel(R) Core(TM) i5-1245U, 1561.10 MHz, 06-9a-04 cpu2:
Re: Sierra Wireless MC7750 attaches as ugen(4) on OpenBSD 7.3 #1125 2023-March-25
On 2023/04/06 09:13, Gerhard Roth wrote:
> 2) query the list of modes with "AT!UDUSBCOMP=?". Example result:
>
> 0 - reserved NOT SUPPORTED
> 1 - DM AT SUPPORTED
> 2 - reserved NOT SUPPORTED
> 3 - reserved NOT SUPPORTED
> 4 - reserved NOT SUPPORTED
> 5 - reserved NOT SUPPORTED
> 6 - DM NMEA ATQMI SUPPORTED
> 7 - DM NMEA ATRMNET1 RMNET2 RMNET3SUPPORTED
> 8 - DM NMEA ATMBIMSUPPORTED
> 9 - MBIM SUPPORTED
> 10 - NMEA MBIMSUPPORTED
> 11 - DM MBIMSUPPORTED
> 12 - DM NMEA MBIM SUPPORTED
> 13 - Config1: comp6Config2: comp8 NOT SUPPORTED
> 14 - Config1: comp6Config2: comp9 SUPPORTED
> 15 - Config1: comp6Config2: comp10NOT SUPPORTED
> 16 - Config1: comp6Config2: comp11NOT SUPPORTED
> 17 - Config1: comp6Config2: comp12NOT SUPPORTED
> 18 - Config1: comp7Config2: comp8 NOT SUPPORTED
> 19 - Config1: comp7Config2: comp9 SUPPORTED
> 20 - Config1: comp7Config2: comp10NOT SUPPORTED
> 21 - Config1: comp7Config2: comp11NOT SUPPORTED
> 22 - Config1: comp7Config2: comp12NOT SUPPORTED
>
> There is no guarantee that the table doesn't change. And every
> device has a differnt set of supported modes.
>
> 3) select the desired mode with "AT!UDUSBCOMP=X"
Take care with this. You can put the modem in a mode where you no
longer have an AT interface to be able to reset it (there maybe
a different way to reset it via USB commands rather than AT commands,
but that won't be straightforward from OpenBSD).
> 4) wait for the device to reset itself
>
> >
> > Index: umsm.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/umsm.c,v
> > retrieving revision 1.125
> > diff -u -p -r1.125 umsm.c
> > --- umsm.c 2 Apr 2023 23:57:57 - 1.125
> > +++ umsm.c 6 Apr 2023 08:40:30 -
> > @@ -271,6 +271,7 @@ static const struct umsm_type umsm_devs[
> > {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_340U}, 0},
> > {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_AIRCARD_770S}, 0},
> > {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7455}, 0},
> > + {{ USB_VENDOR_SIERRA, USB_PRODUCT_SIERRA_MC7700}, 0},
> >
> > {{ USB_VENDOR_SIMCOM, USB_PRODUCT_SIMCOM_SIM5320}, 0},
> > {{ USB_VENDOR_SIMCOM, USB_PRODUCT_SIMCOM_SIM7600E}, 0},
> >
>
Re: Support for Banana PI BPI-M5 confusion on ftp.openbsd.org vs www.openbsd.org
On 2023/03/02 15:48, kod code wrote: > Hello, > > at > https://ftp.openbsd.org/pub/OpenBSD/7.2/arm64/INSTALL.arm64 > under > "OpenBSD System Requirements and Supported Devices:" > ... > "Amlogic G12B/SM1" > the Banana PI BPI-M5 isn't listed. That's from 7.2 release time, the webpage was updated later. > Whereas at > https://www.openbsd.org/arm64.html > under > "OpenBSD/arm64 runs on the following hardware:" > ... > "Amlogic G12B/SM1" > it can be found. > > Please inform me, which page is accurate. I don't think there was any additional code adding support since 7.2 so it should work there as well as in -current. See https://marc.info/?l=openbsd-arm=16775528577=2 for info about the boot loader.
Re: Debugging a 7.2-current segfault that started around #3033
On 2023/02/20 10:46, Stephan Somogyi wrote: > On aarch64 on a RPi3, somewhere between 7.2-current GENERIC.MP#2028 and > GENERIC.MP#2033, and the package snapshots that happened around the #2033 > time,something changed that causes persistent segfaulting while executing a > perl script that's been unchanged for a year. The kernel build numbers aren't really helpful in identifying when these snapshots were built; dates would be better First off, assuming you're now on a system which is after the perl update, make sure you updated all packages and don't have old XS modules lying around; you should get no results from grep '@wantlib perl.22.0' /var/db/pkg/*/+CONTENTS (Or if you've built your own Perl native extensions from outside of packages then they'll want rebuilding) > The segfault happens when python3 scripts are invoked from within the perl > script. I'm invoking the python3 scripts via system(); when I then SIGINT > via Ctrl-C, the traceback is from within python3.10, suggesting that > something that python is sub-launching might be causing the problem, but my > understanding of python internals is basically zero. > > If I manually invoke either of the python scripts with identical > parameters, everything works, so it's not an innate problem with those > scripts or their interaction with python3.10; it's something about how > they're being invoked from perl. > > I've tried building minimal repro case perl scripts and am so far > unsuccessful; everything works without segfaulting. > > I've done enough isolation work now that I'm running into my limits of > knowledge and was curious whether this recent behavior rings a bell with > anyone here. Grasping at straws, but could this have anything to do with > the xonly work? > > Thanks for any suggestions for how to better identify the root cause and > thus generate a more useful bug report. A backtrace from the segfault might give some clues (pkg_add gdb and use the 'egdb' binary; the version of gdb that is in base is not really useful in most cases any more)
