TP-Link WN821N USB wireless NIC on OpenBSD/amd64 7.3
Hello, I have installed OpenBSD/amd64 7.3 on an old MacBook Air (2013). The onboard wifi doesn't work anymore, so I bought a TP-Link USB wifi dongle off Amazon (TP-Link WN821N, 300Mbps). OpenBSD seems to reecognize it (see attached dmesg, ifconfig), but it runs slow. I have a 1Gbps Internet connection and if I put my laptop right next to my access point, I get a max download speed of 0.9-1.0 Mbps when attempting to saturate the Internet connection. Other devices do not have the same problem. Is there a way I can get the NIC to speed up? Thank you. -- Anders 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 = 8509276160 (8115MB) avail mem = 8231964672 (7850MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8cd14000 (42 entries) bios0: vendor Apple Inc. version "119.0.0.0.0" date 12/18/2019 bios0: Apple Inc. MacBookAir6,2 efi0 at bios0: UEFI 1.1 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT DMAR MCFG acpi0: wakeup devices P0P2(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S3) ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3) 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) Core(TM) i5-4250U CPU @ 1.30GHz, 1200.01 MHz, 06-45-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,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, 3MB 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 100MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 1200.03 MHz, 06-45-01 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,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,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, 3MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 1200.02 MHz, 06-45-01 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,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,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, 3MB 64b/line 12-way L3 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-4250U CPU @ 1.30GHz, 1200.02 MHz, 06-45-01 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,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,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,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, 3MB 64b/line 12-way L3 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpiec0 at acpi0 acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-154 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P2) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus 2 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 4 (RP05) acpiprt6 at acpi0: bus 3 (RP06) acpisbs0 at acpi0: SBS0 model "bq20z451" serial 1 type LION oem "SMP" acpipci0 at acpi0 PCI0: 0x0004 0x0011 0x0001
Subscribe
Subscribe
Re: undocumented command switches -OR- fix documentation fully
Some more self-delineation so you know this is neither anonymous, nor privacy related. Completely formal and real outline of history, nothing to hide, draft outline follows: My (father's) personal, technical school, town and factory station call signs are internationally registered and also recorded in the US and CARTG international amateur radio contest winners (CQ magazine publications) years 1977-1982, with national constructors awards here too for the equipment used to win these world contests and recorded in the national historic record of amateur radio and electronics constructors progress for rationalisations and inventions implementation. We have also other internationally registered amateur radio call signs of people who worked in the facilities here and educated many students in the technical university here, including my graduation. He (father) and I can validate this personally as well, and he had been career long maintaining and repairing the said Digital/DEC, Teletype, Honeywell, IBM, LSI, HP, Siemens, Excellon etc undisclosed equipment and computers for the non-standard, CAD/CAM, drilling and milling, mounting and computerised functional testing services in the manufacturing of electronics and computers in the PCB and mounted electronics manufacturing facility. That I was attending as a kid and throughout my primary and middle school years, in the computer and electronics equipment repair laboratories and the radio club where I spent countless days on computers and machinery from teletypes with tape punch-readers to custom made modems for wireless digital long haul transmissions, and where I later worked on as the lead IT position after my language school and technical university graduation, and the factory complex privatisation in 2002 by the company I was working for as well (internationally) prior to that point. The computers were also internationally exported in the Eastern Bloc and clone 8bit and 16bit Western open and closed licensing during the iron curtain embargo 1980-1990 years. This is the Eastern European country I am talking about: https://en.wikipedia.org/wiki/John_Vincent_Atanasoff?useskin=vector#mw-content-text https://en.wikipedia.org/wiki/History_of_computer_hardware_in_Bulgaria?useskin=vector#mw-content-text These computers were made here apart from many others specialised electronics including then innovate 16-layer PCBs and mounted electronics for export to Japan, and compact scale slot variant industrial instances of the said computers : https://en.wikipedia.org/wiki/Pravetz_computers?useskin=vector#mw-content-text And I have my awards in contests too, diplomas and personal and professional experience with computers, broadcasting live TV before and internet hosting and commerce services after the in house ISP departments for the PCB facilities and multiple other companies that I built myself in lead IT positions, transforming these companies to computerised and digital and internet mode of operation and export, for my country and my region, and internationally in more than one European and Commonwealth country. There is nothing to hide and we're an entire generation of nation wide computer experienced people, from technical OSCAR winners in computer rendered cinematography where many US films are made (here), to a broad range services in the global IT outsourced and near-sourced facilities in automotive and precision instrumentation production and PetaFLOPs supercomputer and AI research facilities. Have you won any international telecommunications competitions and have you produced any computers in your track records with your moon-bounce? I'll send you improvements as time and applicability permits again (as I've done in the past), not even halfway to retirement here. In the meantime, try to not break the system beyond absolute recognition by third party imports if you want any feedback on it and keep up the tempo with work and practice high scrutiny, consistent retains of achieved objectives and missions in the software field too, show some interesting progress your end and make your region internationally renowned too. I've heard and read your "statement" so far by other helpers in the years past, it's repetitive and uninteresting, so make room for more stories and important feedback than canned replies, and personal tease-challenges are met with validation ready results as the project output does too. Back to OpenBSD miscellany talk, folks. The "wholly" ghost in electronics and computing is eagerly awaiting you. On 9/25/23, Christoff Humphries wrote: > It sounds like you'd be a perfect person to submit patches for the > project to improve upon. With someone of your background, I'm > certain they would be of high quality and welcomed. > > Unfortunately ideas and complaints aren't constructive, as they > lead to no real change. Ideas and complains WITH patches is a > different matter, and obviously not the subject of this mailing > list. > >
Re: undocumented command switches -OR- fix documentation fully
It sounds like you'd be a perfect person to submit patches for the project to improve upon. With someone of your background, I'm certain they would be of high quality and welcomed. Unfortunately ideas and complaints aren't constructive, as they lead to no real change. Ideas and complains WITH patches is a different matter, and obviously not the subject of this mailing list. Please harness your energy for greater good versus fighting on the Internet behind anonymity. Otherwise, no matter what your background or experience, it is just as meaningful as me claiming I punched an alligator over the moon. If you want to help, then help. Otherwise it is simply noise. It's that simple. --- Original Message --- On Monday, September 25th, 2023 at 10:34 PM, Eponymous Pseudonym wrote: > > > Well, let me introduce myself (again). I started personally with > electronics and real computing more than 40 years ago on 6502 around > Digital and Teletype and custom made telecommunications and high power > radio transceiver equipment in an industrial electronics manufacturing > facility for computers in the COMECON (Eastern Bloc) as a pre-school > practice as a third generation engineer. I am also a masters > engineering degree with double excellence and more than 25 years of > professional UNIX applied experience in computer hardware and internet > services provisioning in broadcast, electronics production and > manufacturing, and hosting and services with thousands of machines and > customers. I have read and written about and on UNIX in 4 natural and > many internationally standardised synthetic languages. You do not > know me, but now you do know a bit of this and that too. > > Speak about yourself when you say "we", because not everyone is your > level of progress. Obviously "we" are on the same system but not from > the same initial points of time and space, and some of "us" command > more systems and machinery for more serious utilisation. There is > always a lot more to learn, practice and experience, you're neither > completely saturated, nor completely wise until you say so. Thanks > for your attention to detail, I am off this thread now too. A lot has > happened, regardless of not witnessing it with your own eyes, and > there is a lot more to happen further. Have patience, persistence, > perseverance, practice, perfection. > > On 9/25/23, Rudolf Leitgeb rudolf.leit...@gmx.at wrote: > > > "professional conferences and scientific education" typically > > employ a quite vigorous process to vet their speakers. This has > > clearly not happened here ... > > > > Regarding "Who do you think you're talking to": this has basically > > devolved into a pointless dialog between the two of us, since there > > is all but thundering silence from the actual devs here. > > > > On Mon, 2023-09-25 at 21:59 +, Eponymous Pseudonym wrote: > > > > > Every one, Every where, All ways, You too. That's what professional > > > conferences and scientific education is for. Who do you think you're > > > talking to, the mailing list archive readers of a social club for > > > knitting for the elderly? That is correct too. Time will and does > > > demonstrate it perfectly. > > > > > > On 9/25/23, Rudolf Leitgeb rudolf.leit...@gmx.at wrote: > > > > > > > Are you trying to teach the OpenBSD devs how to write good > > > > software? > > > > > > > > Unix software? > > > > > > > > Really? > > > > > > > > REALLY ? > > > > > > > > On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote: > > > > > > > > > Standardisation, specification and documentation as a starting > > > > > point > > > > > for software creation is a normal, reliable and mandated > > > > > (formally) > > > > > methodology used everywhere from business to scientific, > > > > > industrial, > > > > > medical and military applications. It is not only normal but > > > > > expected > > > > > and even required that amateur free and open software follow the > > > > > same > > > > > processes and procedures as professional modelling and > > > > > implementation, > > > > > especially on historically significant long term projects that > > > > > are > > > > > also programming languages and interpreters. > > > > > > > > > > It's not a surprise to you, everything in UNIX is a compiler > > > > > construction reuse tooling and a small (and large) domain > > > > > specific > > > > > languages. That is the essence of the system. OpenBSD is a > > > > > descendant of UNIX, not a free walk in the green pastures of > > > > > experimental shareware. Now, let's get back to more productive > > > > > time > > > > > and space utilisation, kids, good ideas.. third party re-imports > > > > > are > > > > > waiting their normalisation and stabilisation to robust and > > > > > reliable > > > > > distillations of core "base and extended" system modular > > > > > componentry. > > > > > Re-read the long version of the previous post after some > > > > > specialised > > >
Re: undocumented command switches -OR- fix documentation fully
Well, let me introduce myself (again). I started personally with electronics and real computing more than 40 years ago on 6502 around Digital and Teletype and custom made telecommunications and high power radio transceiver equipment in an industrial electronics manufacturing facility for computers in the COMECON (Eastern Bloc) as a pre-school practice as a third generation engineer. I am also a masters engineering degree with double excellence and more than 25 years of professional UNIX applied experience in computer hardware and internet services provisioning in broadcast, electronics production and manufacturing, and hosting and services with thousands of machines and customers. I have read and written about and on UNIX in 4 natural and many internationally standardised synthetic languages. You do not know me, but now you do know a bit of this and that too. Speak about yourself when you say "we", because not everyone is your level of progress. Obviously "we" are on the same system but not from the same initial points of time and space, and some of "us" command more systems and machinery for more serious utilisation. There is always a lot more to learn, practice and experience, you're neither completely saturated, nor completely wise until you say so. Thanks for your attention to detail, I am off this thread now too. A lot has happened, regardless of not witnessing it with your own eyes, and there is a lot more to happen further. Have patience, persistence, perseverance, practice, perfection. On 9/25/23, Rudolf Leitgeb wrote: > "professional conferences and scientific education" typically > employ a quite vigorous process to vet their speakers. This has > clearly not happened here ... > > Regarding "Who do you think you're talking to": this has basically > devolved into a pointless dialog between the two of us, since there > is all but thundering silence from the actual devs here. > > On Mon, 2023-09-25 at 21:59 +, Eponymous Pseudonym wrote: >> Every one, Every where, All ways, You too. That's what professional >> conferences and scientific education is for. Who do you think you're >> talking to, the mailing list archive readers of a social club for >> knitting for the elderly? That is correct too. Time will and does >> demonstrate it perfectly. >> >> On 9/25/23, Rudolf Leitgeb wrote: >> > Are you trying to teach the OpenBSD devs how to write good >> > software? >> > >> > Unix software? >> > >> > Really? >> > >> > REALLY ? >> > >> > On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote: >> > > Standardisation, specification and documentation as a starting >> > > point >> > > for software creation is a normal, reliable and mandated >> > > (formally) >> > > methodology used everywhere from business to scientific, >> > > industrial, >> > > medical and military applications. It is not only normal but >> > > expected >> > > and even required that amateur free and open software follow the >> > > same >> > > processes and procedures as professional modelling and >> > > implementation, >> > > especially on historically significant long term projects that >> > > are >> > > also programming languages and interpreters. >> > > >> > > It's not a surprise to you, everything in UNIX is a compiler >> > > construction reuse tooling and a small (and large) domain >> > > specific >> > > languages. That is the essence of the system. OpenBSD is a >> > > descendant of UNIX, not a free walk in the green pastures of >> > > experimental shareware. Now, let's get back to more productive >> > > time >> > > and space utilisation, kids, good ideas.. third party re-imports >> > > are >> > > waiting their normalisation and stabilisation to robust and >> > > reliable >> > > distillations of core "base and extended" system modular >> > > componentry. >> > > Re-read the long version of the previous post after some >> > > specialised >> > > references again, and you will see and understand what I outlined >> > > clearly. >> > > >> https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles >> >> > > >> > > Thanks for the discussion and support, I've said my points and >> > > think >> > > we're in accord and agreement on all details referenced. >> > > >> > > On 9/25/23, Rudolf Leitgeb wrote: >> > > > If you document a switch, you are basically required to keep >> > > > that >> > > > functionality around forever. Given that the OpenBSD devs don't >> > > > like >> > > > these --options all that much, I don't see that happening. >> > > > Submitting >> > > > a patch won't change that. >> > > > >> > > > IMHO there's nothing wrong, if software can do more than its >> > > > documentation shows. It's not like it breaks documented >> > > > behavior. >> > > > >> > > > On
Re: undocumented command switches -OR- fix documentation fully
He's due a refund on his OS order. Prepare the manager, this guy wants to talk to them. --- Original Message --- On Monday, September 25th, 2023 at 10:08 PM, Rudolf Leitgeb wrote: > > > "professional conferences and scientific education" typically > employ a quite vigorous process to vet their speakers. This has > clearly not happened here ... > > Regarding "Who do you think you're talking to": this has basically > devolved into a pointless dialog between the two of us, since there > is all but thundering silence from the actual devs here. > > > > > On Mon, 2023-09-25 at 21:59 +, Eponymous Pseudonym wrote: > > > Every one, Every where, All ways, You too. That's what professional > > conferences and scientific education is for. Who do you think you're > > talking to, the mailing list archive readers of a social club for > > knitting for the elderly? That is correct too. Time will and does > > demonstrate it perfectly. > > > > On 9/25/23, Rudolf Leitgeb rudolf.leit...@gmx.at wrote: > > > > > Are you trying to teach the OpenBSD devs how to write good > > > software? > > > > > > Unix software? > > > > > > Really? > > > > > > REALLY ? > > > > > > On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote: > > > > > > > Standardisation, specification and documentation as a starting > > > > point > > > > for software creation is a normal, reliable and mandated > > > > (formally) > > > > methodology used everywhere from business to scientific, > > > > industrial, > > > > medical and military applications. It is not only normal but > > > > expected > > > > and even required that amateur free and open software follow the > > > > same > > > > processes and procedures as professional modelling and > > > > implementation, > > > > especially on historically significant long term projects that > > > > are > > > > also programming languages and interpreters. > > > > > > > > It's not a surprise to you, everything in UNIX is a compiler > > > > construction reuse tooling and a small (and large) domain > > > > specific > > > > languages. That is the essence of the system. OpenBSD is a > > > > descendant of UNIX, not a free walk in the green pastures of > > > > experimental shareware. Now, let's get back to more productive > > > > time > > > > and space utilisation, kids, good ideas.. third party re-imports > > > > are > > > > waiting their normalisation and stabilisation to robust and > > > > reliable > > > > distillations of core "base and extended" system modular > > > > componentry. > > > > Re-read the long version of the previous post after some > > > > specialised > > > > references again, and you will see and understand what I outlined > > > > clearly. > > > > https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text > > https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History > > https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles > > > > > > Thanks for the discussion and support, I've said my points and > > > > think > > > > we're in accord and agreement on all details referenced. > > > > > > > > On 9/25/23, Rudolf Leitgeb rudolf.leit...@gmx.at wrote: > > > > > > > > > If you document a switch, you are basically required to keep > > > > > that > > > > > functionality around forever. Given that the OpenBSD devs don't > > > > > like > > > > > these --options all that much, I don't see that happening. > > > > > Submitting > > > > > a patch won't change that. > > > > > > > > > > IMHO there's nothing wrong, if software can do more than its > > > > > documentation shows. It's not like it breaks documented > > > > > behavior. > > > > > > > > > > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: > > > > > > > > > > > Don't rant that long. > > > > > > > > > > > > Sometimes, documentation and code get out-of-synch for a lot > > > > > > of > > > > > > reasons. > > > > > > > > > > > > - trying out stuff and documenting later. > > > > > > - plain forgetting to update the documentation. > > > > > > - having some stuff for a transition period, and then killing > > > > > > it. > > > > > > > > > > > > Your point that stuff that stays around, should ideally be > > > > > > documented, > > > > > > is a good point. > > > > > > > > > > > > Now, you gotta realize that people have limited time to do > > > > > > everything. > > > > > > > > > > > > In general, patches are welcome. > > > > > > > > > > > > In my long tenure on various tools, I've learnt that > > > > > > documenting > > > > > > stuff is always always a good idea: if you get a new feature > > > > > > BUT > > > > > > you can't explain it cleanly, then you should go back to the > > > > > > drawing-board !
Re: undocumented command switches -OR- fix documentation fully
"professional conferences and scientific education" typically employ a quite vigorous process to vet their speakers. This has clearly not happened here ... Regarding "Who do you think you're talking to": this has basically devolved into a pointless dialog between the two of us, since there is all but thundering silence from the actual devs here. On Mon, 2023-09-25 at 21:59 +, Eponymous Pseudonym wrote: > Every one, Every where, All ways, You too. That's what professional > conferences and scientific education is for. Who do you think you're > talking to, the mailing list archive readers of a social club for > knitting for the elderly? That is correct too. Time will and does > demonstrate it perfectly. > > On 9/25/23, Rudolf Leitgeb wrote: > > Are you trying to teach the OpenBSD devs how to write good > > software? > > > > Unix software? > > > > Really? > > > > REALLY ? > > > > On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote: > > > Standardisation, specification and documentation as a starting > > > point > > > for software creation is a normal, reliable and mandated > > > (formally) > > > methodology used everywhere from business to scientific, > > > industrial, > > > medical and military applications. It is not only normal but > > > expected > > > and even required that amateur free and open software follow the > > > same > > > processes and procedures as professional modelling and > > > implementation, > > > especially on historically significant long term projects that > > > are > > > also programming languages and interpreters. > > > > > > It's not a surprise to you, everything in UNIX is a compiler > > > construction reuse tooling and a small (and large) domain > > > specific > > > languages. That is the essence of the system. OpenBSD is a > > > descendant of UNIX, not a free walk in the green pastures of > > > experimental shareware. Now, let's get back to more productive > > > time > > > and space utilisation, kids, good ideas.. third party re-imports > > > are > > > waiting their normalisation and stabilisation to robust and > > > reliable > > > distillations of core "base and extended" system modular > > > componentry. > > > Re-read the long version of the previous post after some > > > specialised > > > references again, and you will see and understand what I outlined > > > clearly. > > > > > https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text > https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History > https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles > > > > > > > Thanks for the discussion and support, I've said my points and > > > think > > > we're in accord and agreement on all details referenced. > > > > > > On 9/25/23, Rudolf Leitgeb wrote: > > > > If you document a switch, you are basically required to keep > > > > that > > > > functionality around forever. Given that the OpenBSD devs don't > > > > like > > > > these --options all that much, I don't see that happening. > > > > Submitting > > > > a patch won't change that. > > > > > > > > IMHO there's nothing wrong, if software can do more than its > > > > documentation shows. It's not like it breaks documented > > > > behavior. > > > > > > > > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: > > > > > Don't rant that long. > > > > > > > > > > Sometimes, documentation and code get out-of-synch for a lot > > > > > of > > > > > reasons. > > > > > > > > > > - trying out stuff and documenting later. > > > > > - plain forgetting to update the documentation. > > > > > - having some stuff for a transition period, and then killing > > > > > it. > > > > > > > > > > Your point that stuff that stays around, should ideally be > > > > > documented, > > > > > is a good point. > > > > > > > > > > Now, you gotta realize that people have limited time to do > > > > > everything. > > > > > > > > > > In general, patches are welcome. > > > > > > > > > > In my long tenure on various tools, I've learnt that > > > > > documenting > > > > > stuff is always always a good idea: if you get a new feature > > > > > BUT > > > > > you can't explain it cleanly, then you should go back to the > > > > > drawing-board !
Re: undocumented command switches -OR- fix documentation fully
Every one, Every where, All ways, You too. That's what professional conferences and scientific education is for. Who do you think you're talking to, the mailing list archive readers of a social club for knitting for the elderly? That is correct too. Time will and does demonstrate it perfectly. On 9/25/23, Rudolf Leitgeb wrote: > Are you trying to teach the OpenBSD devs how to write good software? > > Unix software? > > Really? > > REALLY ? > > On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote: >> Standardisation, specification and documentation as a starting point >> for software creation is a normal, reliable and mandated (formally) >> methodology used everywhere from business to scientific, industrial, >> medical and military applications. It is not only normal but >> expected >> and even required that amateur free and open software follow the same >> processes and procedures as professional modelling and >> implementation, >> especially on historically significant long term projects that are >> also programming languages and interpreters. >> >> It's not a surprise to you, everything in UNIX is a compiler >> construction reuse tooling and a small (and large) domain specific >> languages. That is the essence of the system. OpenBSD is a >> descendant of UNIX, not a free walk in the green pastures of >> experimental shareware. Now, let's get back to more productive time >> and space utilisation, kids, good ideas.. third party re-imports are >> waiting their normalisation and stabilisation to robust and reliable >> distillations of core "base and extended" system modular componentry. >> Re-read the long version of the previous post after some specialised >> references again, and you will see and understand what I outlined >> clearly. >> https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles >> >> Thanks for the discussion and support, I've said my points and think >> we're in accord and agreement on all details referenced. >> >> On 9/25/23, Rudolf Leitgeb wrote: >> > If you document a switch, you are basically required to keep that >> > functionality around forever. Given that the OpenBSD devs don't >> > like >> > these --options all that much, I don't see that happening. >> > Submitting >> > a patch won't change that. >> > >> > IMHO there's nothing wrong, if software can do more than its >> > documentation shows. It's not like it breaks documented behavior. >> > >> > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: >> > > Don't rant that long. >> > > >> > > Sometimes, documentation and code get out-of-synch for a lot of >> > > reasons. >> > > >> > > - trying out stuff and documenting later. >> > > - plain forgetting to update the documentation. >> > > - having some stuff for a transition period, and then killing it. >> > > >> > > Your point that stuff that stays around, should ideally be >> > > documented, >> > > is a good point. >> > > >> > > Now, you gotta realize that people have limited time to do >> > > everything. >> > > >> > > In general, patches are welcome. >> > > >> > > In my long tenure on various tools, I've learnt that documenting >> > > stuff is always always a good idea: if you get a new feature BUT >> > > you can't explain it cleanly, then you should go back to the >> > > drawing-board !
Re: undocumented command switches -OR- fix documentation fully
Are you trying to teach the OpenBSD devs how to write good software? Unix software? Really? REALLY ? On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote: > Standardisation, specification and documentation as a starting point > for software creation is a normal, reliable and mandated (formally) > methodology used everywhere from business to scientific, industrial, > medical and military applications. It is not only normal but > expected > and even required that amateur free and open software follow the same > processes and procedures as professional modelling and > implementation, > especially on historically significant long term projects that are > also programming languages and interpreters. > > It's not a surprise to you, everything in UNIX is a compiler > construction reuse tooling and a small (and large) domain specific > languages. That is the essence of the system. OpenBSD is a > descendant of UNIX, not a free walk in the green pastures of > experimental shareware. Now, let's get back to more productive time > and space utilisation, kids, good ideas.. third party re-imports are > waiting their normalisation and stabilisation to robust and reliable > distillations of core "base and extended" system modular componentry. > Re-read the long version of the previous post after some specialised > references again, and you will see and understand what I outlined > clearly. > > https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text > https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History > https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles > > Thanks for the discussion and support, I've said my points and think > we're in accord and agreement on all details referenced. > > On 9/25/23, Rudolf Leitgeb wrote: > > If you document a switch, you are basically required to keep that > > functionality around forever. Given that the OpenBSD devs don't > > like > > these --options all that much, I don't see that happening. > > Submitting > > a patch won't change that. > > > > IMHO there's nothing wrong, if software can do more than its > > documentation shows. It's not like it breaks documented behavior. > > > > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: > > > Don't rant that long. > > > > > > Sometimes, documentation and code get out-of-synch for a lot of > > > reasons. > > > > > > - trying out stuff and documenting later. > > > - plain forgetting to update the documentation. > > > - having some stuff for a transition period, and then killing it. > > > > > > Your point that stuff that stays around, should ideally be > > > documented, > > > is a good point. > > > > > > Now, you gotta realize that people have limited time to do > > > everything. > > > > > > In general, patches are welcome. > > > > > > In my long tenure on various tools, I've learnt that documenting > > > stuff is always always a good idea: if you get a new feature BUT > > > you can't explain it cleanly, then you should go back to the > > > drawing-board !
Re: undocumented command switches -OR- fix documentation fully
Standardisation, specification and documentation as a starting point for software creation is a normal, reliable and mandated (formally) methodology used everywhere from business to scientific, industrial, medical and military applications. It is not only normal but expected and even required that amateur free and open software follow the same processes and procedures as professional modelling and implementation, especially on historically significant long term projects that are also programming languages and interpreters. It's not a surprise to you, everything in UNIX is a compiler construction reuse tooling and a small (and large) domain specific languages. That is the essence of the system. OpenBSD is a descendant of UNIX, not a free walk in the green pastures of experimental shareware. Now, let's get back to more productive time and space utilisation, kids, good ideas.. third party re-imports are waiting their normalisation and stabilisation to robust and reliable distillations of core "base and extended" system modular componentry. Re-read the long version of the previous post after some specialised references again, and you will see and understand what I outlined clearly. https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles Thanks for the discussion and support, I've said my points and think we're in accord and agreement on all details referenced. On 9/25/23, Rudolf Leitgeb wrote: > If you document a switch, you are basically required to keep that > functionality around forever. Given that the OpenBSD devs don't like > these --options all that much, I don't see that happening. Submitting > a patch won't change that. > > IMHO there's nothing wrong, if software can do more than its > documentation shows. It's not like it breaks documented behavior. > > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: >> Don't rant that long. >> >> Sometimes, documentation and code get out-of-synch for a lot of >> reasons. >> >> - trying out stuff and documenting later. >> - plain forgetting to update the documentation. >> - having some stuff for a transition period, and then killing it. >> >> Your point that stuff that stays around, should ideally be >> documented, >> is a good point. >> >> Now, you gotta realize that people have limited time to do >> everything. >> >> In general, patches are welcome. >> >> In my long tenure on various tools, I've learnt that documenting >> stuff is always always a good idea: if you get a new feature BUT >> you can't explain it cleanly, then you should go back to the >> drawing-board !
Re: undocumented command switches -OR- fix documentation fully
If you document a switch, you are basically required to keep that functionality around forever. Given that the OpenBSD devs don't like these --options all that much, I don't see that happening. Submitting a patch won't change that. IMHO there's nothing wrong, if software can do more than its documentation shows. It's not like it breaks documented behavior. On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote: > Don't rant that long. > > Sometimes, documentation and code get out-of-synch for a lot of > reasons. > > - trying out stuff and documenting later. > - plain forgetting to update the documentation. > - having some stuff for a transition period, and then killing it. > > Your point that stuff that stays around, should ideally be > documented, > is a good point. > > Now, you gotta realize that people have limited time to do > everything. > > In general, patches are welcome. > > In my long tenure on various tools, I've learnt that documenting > stuff is always always a good idea: if you get a new feature BUT > you can't explain it cleanly, then you should go back to the > drawing-board ! >
Re: undocumented command switches -OR- fix documentation fully
Don't rant that long. Sometimes, documentation and code get out-of-synch for a lot of reasons. - trying out stuff and documenting later. - plain forgetting to update the documentation. - having some stuff for a transition period, and then killing it. Your point that stuff that stays around, should ideally be documented, is a good point. Now, you gotta realize that people have limited time to do everything. In general, patches are welcome. In my long tenure on various tools, I've learnt that documenting stuff is always always a good idea: if you get a new feature BUT you can't explain it cleanly, then you should go back to the drawing-board !
Re: undocumented command switches -OR- fix documentation fully
Right, the obvious point overlooked is.. having to poke in the program by chance, on hesitation.. to find out discrepancies, as a confirmation of suspected misalignment between the manual page and the actual program implementation. At individual user level, each time by many system operators on their own wits (and consumers of the program as an interpreter, for example scripts, compilers etc). Instead of just "using" the program and relying that the behaviour is predictable and.. somewhat "truthful" to the actual implementation specifics, by documentation / manual page reference (as expected). Or even consistent over time, and predictable by standards compliance and system specific (cohesive principles). So much for idealisation, the factual state is.. what you do not validate yourself is not validated (who do you trust with that), and it will and does fail you.. all the time, everywhere you look into it and use it thoroughly, continuously, for decades. It does fail you persistently and inevitably, despite working as tested by its implementers. Having to look into the source to confirm the manual page before running the program is a step that is optional, but when you take it and find discrepancies, or failure.. you question the changes leading to that, the changelog and which comes from where and how (also how often). The --version being supported and not documented is a minor point, a totally harmless one, but things that are undocumented will creep, these matters not being addressed do get wider lapses, and not only in a one off case. They become tolerated, the norm and a systemic failure (acceptance and oversight, even on re-evaluations). Yet, we've seen recently, developers have picked up on the call to action, needless to say (as usual), so consider this particular minute "resolved" as a one system operator cry could go that far, for one small point of a "long timed options" case of no such "long options" time. That's not the main point, however. This AWK, that is being constantly re-imported on a continual non-rhythmic pace into OpenBSD from the upstream, which is "neither _true_ (the heck that pretence means), nor the one". It comes from a third party "group" developing it on a "leisure moon(ing) stroll" (carelessly), receives less scrutiny and is sloppily changed routinely, by non-BSD and non-KNF aware GNU / Linux novices in the public (and they can't prove it's better than this criticism outlined). Also, no one can argue with the times and epochs, as things change.. quality and attention to detail degrade in later generation programmers, they are distracted and doing voluntary work on the side pro bono. No auto-type spell checkers and code analysis tools can fix this. Volunteer people are not university graduates any more in the Americas and elsewhere too (for the last 20+ years), and it's going to deteriorate further. Newer tools help, but don't solve it, and these tools do NOT work on (and target) our particular system, and its specifics and properties. That is the objective reality. Other than the obvious "problems" in this particular awk(1) continual reintroduction and "long and slow fix-ups of bugs and subtle behaviour issues" in system tree, it is simply not the OpenBSD quality, and we should be aware of that in public. There is no robust normalised UTF-8 implementation system wide either, and feature creep is set to prevail over quality of programming not only in the many and modernised awk-ren, as it shows in this case for a long(opt) long time so far. As for the compatibility with other systems, you know what to do and how to rationally address these, conformance and coverage of some "portability" is normal and expected (even). No arguments about it.. need to keep up the machine classes and important use cases and adjust the system and extended software according to these necessities. The actual disgusting point is being lied to in the program implementation compared to the program documentation, and it's a foreign problem reintroduced continually. It's not about the UTF-8 or new features all that much, and not about staying legacy and conservatively capsuled in time. Except that it's also part of the what gets ran and what gets proven, and replicated in other programs as custom / non-uniform or manually propagated discrepancies.. Then, there is supposed to be some "trust", that what goes in the system is - if not "robust" and "secure" - at least on that track, or "in long term strive for that and not just acceptance of defeat over this" (you know the speech). There are other larger bulk program being imported continually in the base system and getting exercised like this, and in times even exorcised and excised, it gets the views and attention but does it ever get "fixed" or "normalised" or even conceptually worked on ever for real, other than palliative accommodation? You know the answer. I do know it too, it does not get the real work until these are
Re: OpenBSD 7.2 fw stack trace on Dell R740
That might possibly be the one fixed by 7.2 errata 008, so if you don't already have that you at least want to syspatch. On 2023-09-25, Joerg Streckfuss wrote: > This is a cryptographically signed message in MIME format. > > --ms030306090501000403020005 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit > > > Dear list, > > today two of our firewalls crashed. after i was able to bring the first > firewall > back online, this one crashed again within a few minutes. this time i was > able > to take a stack-trace from the console: > > > OpenBSD/amd64 (fw1) (tty00) > > login: uvm_fault(0x823237a0, 0x0, 0, 1) -> e > fatal page fault in supervisor mode > trap type 6 code 0 rip 81c38d68 cs 8 rflags 10246 cr2 0 cpl 0 rsp > 80002b853590 > gsbase 0x80001d3dcff0 kgsbase 0x0 > panic: trap type 6, code=0, pc=81c38d68 > Starting stack trace... > panic(81f22fcf) at panic+0x12c > kerntrap(80002b8534e0) at kerntrap+0x114 > alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b > pf_state_export(fd80513f0bd4,fd877600a2a0) at pf_state_export+0x38 > pfsync_sendout() at pfsync_sendout+0x5e4 > pfsync_update_state(fd887b0ef6c0) at pfsync_update_state+0x15b > pf_test(18,1,82eed000,80002b853a08) at pf_test+0x117a > ip6_input_if(80002b853a08,80002b853a14,29,0,82eed000) at > ip6_input_if+0x1ae > ipv6_input(82eed000,fd8050cb7c00) at ipv6_input+0x39 > ether_input(82eed000,fd8050cb7c00) at ether_input+0x3b1 > carp_input(8193d050,fd8050cb7c00,5e000102) at carp_input+0x196 > ether_input(8193d050,fd8050cb7c00) at ether_input+0x1d9 > if_input_process(8193d050,80002b853be8) at if_input_process+0x6f > ifiq_process(8193aa00) at ifiq_process+0x69 > taskq_thread(80037180) at taskq_thread+0x100 > end trace frame: 0x0, count: 242 > End of stack trace. > > > Both Systems are OpenBSD 7.2 running on Dell PowerEdge R740 > > Is anyone able to interpret the stack trace? > > Regards, > > Joerg > > --ms030306090501000403020005 > Content-Type: application/pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > Content-Description: S/MIME Cryptographic Signature > > MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC > EP8wggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYT > AkRFMSswKQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYD > VQQLDBZULVN5c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFs > Um9vdCBDbGFzcyAyMB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNV > BAYTAkRFMUUwQwYDVQQKEzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVu > IEZvcnNjaHVuZ3NuZXR6ZXMgZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERG > Ti1WZXJlaW4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQAD > ggEPADCCAQoCggEBAMtg1/9moUHN0vqHl4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZs > FVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8FXRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0p > eQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+BaL2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0 > WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qLNupOkSk9s1FcragMvp0049ENF4N1 > xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz9AkH4wKGMUZrAcUQDBHHWekC > AwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUk+PYMiba1fFKpZFK4OpL > 4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYDVR0TAQH/BAgwBgEB > /wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGCLB4wCAYGZ4EM > AQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUvcmwvVGVs > ZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYBBQUH > MAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw > Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5j > ZXIwDQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4 > eTizDnS6dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/ > MOaZ/SLick0+hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3S > PXez7vTXTf/D6OWST1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc2 > 2CzeIs2LgtjZeOJVEqM7h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bP > ZYoaorVyGTkwggWsMIIElKADAgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYD > VQQGEwJERTFFMEMGA1UEChM8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hl > biBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRE > Rk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcN > MzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9l > cmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UE > CwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQTCCASIw > DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp1xCeOdfZojDbchwFfylf > S2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6WLkDh0YNMZj0cZGnl > m6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mITQ5HjUhfZZkQ >
OpenBSD 7.2 fw stack trace on Dell R740
Dear list, today two of our firewalls crashed. after i was able to bring the first firewall back online, this one crashed again within a few minutes. this time i was able to take a stack-trace from the console: OpenBSD/amd64 (fw1) (tty00) login: uvm_fault(0x823237a0, 0x0, 0, 1) -> e fatal page fault in supervisor mode trap type 6 code 0 rip 81c38d68 cs 8 rflags 10246 cr2 0 cpl 0 rsp 80002b853590 gsbase 0x80001d3dcff0 kgsbase 0x0 panic: trap type 6, code=0, pc=81c38d68 Starting stack trace... panic(81f22fcf) at panic+0x12c kerntrap(80002b8534e0) at kerntrap+0x114 alltraps_kern_meltdown() at alltraps_kern_meltdown+0x7b pf_state_export(fd80513f0bd4,fd877600a2a0) at pf_state_export+0x38 pfsync_sendout() at pfsync_sendout+0x5e4 pfsync_update_state(fd887b0ef6c0) at pfsync_update_state+0x15b pf_test(18,1,82eed000,80002b853a08) at pf_test+0x117a ip6_input_if(80002b853a08,80002b853a14,29,0,82eed000) at ip6_input_if+0x1ae ipv6_input(82eed000,fd8050cb7c00) at ipv6_input+0x39 ether_input(82eed000,fd8050cb7c00) at ether_input+0x3b1 carp_input(8193d050,fd8050cb7c00,5e000102) at carp_input+0x196 ether_input(8193d050,fd8050cb7c00) at ether_input+0x1d9 if_input_process(8193d050,80002b853be8) at if_input_process+0x6f ifiq_process(8193aa00) at ifiq_process+0x69 taskq_thread(80037180) at taskq_thread+0x100 end trace frame: 0x0, count: 242 End of stack trace. Both Systems are OpenBSD 7.2 running on Dell PowerEdge R740 Is anyone able to interpret the stack trace? Regards, Joerg smime.p7s Description: S/MIME Cryptographic Signature
Re: Unclear Memory Leakage since OpenBSD 7.3 upgrade (nginx and MariaDB; Not consistent)
On Mon, 2023-09-25 at 18:15 +0200, Rudolf Leitgeb wrote: > Either this, or the TLS 1.3 code was always buggy, but now > it was actually used per default. Yes, setting up nginx with enabled tlsv1.3 on 7.2 and earlier is also on the todo. Similarly, disabling tlsv1.3 and forcing tlsv1.3 on earlier versions. Still, the earlier versions i had been running seemed to support tlsv1.3, at least according to s_client. But the use as default might change things. > Question: is there a similar > commit in your DNS server? Do you use this DNS server with > anything like TLS? pdns itself is not leaking, the memory is hogged by mariadb. But (given everything runs via unix sockets) i am not using TLS in that stack at all. This is was initially nudged me a bit towards other functions that might be used from libressl (sha* or something used in auth maybe?). But this will need some more test-setups to run for some time; I will be able to setup automation for that in the coming weeks. With best regards, Tobias > On Sun, 2023-09-24 at 21:31 +0200, Tobias Fiebig wrote: > > > > > But yes, getting a specific commit there will be helpful. > > Sadly it turns out that it is the commit i feared it would be: > > > > > commit 7b24b93d67daa9c16d665129fd5d3e7dbc583e4f > > > Author: Maxim Dounin > > > Date: Fri Mar 24 02:57:43 2023 +0300 > > > > > > SSL: enabled TLSv1.3 by default. > > > > Feared, because it basically puts me back to start w.r.t. what the > > root > > cause might be; Could be anything that happened to TLSv1.3 code in > > either LibreSSL or Nginx. > -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl
Re: Unclear Memory Leakage since OpenBSD 7.3 upgrade (nginx and MariaDB; Not consistent)
Either this, or the TLS 1.3 code was always buggy, but now it was actually used per default. Question: is there a similar commit in your DNS server? Do you use this DNS server with anything like TLS? On Sun, 2023-09-24 at 21:31 +0200, Tobias Fiebig wrote: > > > But yes, getting a specific commit there will be helpful. > Sadly it turns out that it is the commit i feared it would be: > > > commit 7b24b93d67daa9c16d665129fd5d3e7dbc583e4f > > Author: Maxim Dounin > > Date: Fri Mar 24 02:57:43 2023 +0300 > > > > SSL: enabled TLSv1.3 by default. > > Feared, because it basically puts me back to start w.r.t. what the > root > cause might be; Could be anything that happened to TLSv1.3 code in > either LibreSSL or Nginx.
[m...@openbsd.org: Please test; midi(4): make midi{read,write}_filtops mp safe]
Hi,
I'm searching help with midi(4) testing. If someone could test this
diff, let me know.
- Forwarded message from Vitaliy Makkoveev -
Date: Sun, 24 Sep 2023 23:03:54 +0300
From: Vitaliy Makkoveev
To: t...@openbsd.org
Subject: Please test; midi(4): make midi{read,write}_filtops mp safe
Please test this diff, I have no midi(4) devices.
midi(4) already uses `audio_lock' mutex(9) for filterops, but they are
still kernel locked. Wipe out old selwakeup API and make them MP safe.
knote_locked(9) will not grab kernel lock, so call it directly from
interrupt handlers instead of scheduling software interrupts.
Index: sys/dev/midi.c
===
RCS file: /cvs/src/sys/dev/midi.c,v
retrieving revision 1.55
diff -u -p -r1.55 midi.c
--- sys/dev/midi.c 2 Jul 2022 08:50:41 - 1.55
+++ sys/dev/midi.c 24 Sep 2023 19:57:56 -
@@ -31,7 +31,6 @@
#include
#include
-#define IPL_SOFTMIDI IPL_SOFTNET
#define DEVNAME(sc)((sc)->dev.dv_xname)
intmidiopen(dev_t, int, int, struct proc *);
@@ -65,41 +64,38 @@ struct cfdriver midi_cd = {
void filt_midiwdetach(struct knote *);
int filt_midiwrite(struct knote *, long);
+int filt_midimodify(struct kevent *, struct knote *);
+int filt_midiprocess(struct knote *, struct kevent *);
const struct filterops midiwrite_filtops = {
- .f_flags= FILTEROP_ISFD,
+ .f_flags= FILTEROP_ISFD | FILTEROP_MPSAFE,
.f_attach = NULL,
.f_detach = filt_midiwdetach,
.f_event= filt_midiwrite,
+ .f_modify = filt_midimodify,
+ .f_process = filt_midiprocess,
};
void filt_midirdetach(struct knote *);
int filt_midiread(struct knote *, long);
const struct filterops midiread_filtops = {
- .f_flags= FILTEROP_ISFD,
+ .f_flags= FILTEROP_ISFD | FILTEROP_MPSAFE,
.f_attach = NULL,
.f_detach = filt_midirdetach,
.f_event= filt_midiread,
+ .f_modify = filt_midimodify,
+ .f_process = filt_midiprocess,
};
void
-midi_buf_wakeup(void *addr)
+midi_buf_wakeup(struct midi_buffer *buf)
{
- struct midi_buffer *buf = addr;
-
if (buf->blocking) {
wakeup(>blocking);
buf->blocking = 0;
}
- /*
-* As long as selwakeup() grabs the KERNEL_LOCK() make sure it is
-* already held here to avoid lock ordering problems with `audio_lock'
-*/
- KERNEL_ASSERT_LOCKED();
- mtx_enter(_lock);
- selwakeup(>sel);
- mtx_leave(_lock);
+ knote_locked(>klist, 0);
}
void
@@ -117,13 +113,7 @@ midi_iintr(void *addr, int data)
MIDIBUF_WRITE(mb, data);
- /*
-* As long as selwakeup() needs to be protected by the
-* KERNEL_LOCK() we have to delay the wakeup to another
-* context to keep the interrupt context KERNEL_LOCK()
-* free.
-*/
- softintr_schedule(sc->inbuf.softintr);
+ midi_buf_wakeup(mb);
}
int
@@ -226,14 +216,7 @@ void
midi_out_stop(struct midi_softc *sc)
{
sc->isbusy = 0;
-
- /*
-* As long as selwakeup() needs to be protected by the
-* KERNEL_LOCK() we have to delay the wakeup to another
-* context to keep the interrupt context KERNEL_LOCK()
-* free.
-*/
- softintr_schedule(sc->outbuf.softintr);
+ midi_buf_wakeup(>outbuf);
}
void
@@ -342,11 +325,11 @@ midikqfilter(dev_t dev, struct knote *kn
error = 0;
switch (kn->kn_filter) {
case EVFILT_READ:
- klist = >inbuf.sel.si_note;
+ klist = >inbuf.klist;
kn->kn_fop = _filtops;
break;
case EVFILT_WRITE:
- klist = >outbuf.sel.si_note;
+ klist = >outbuf.klist;
kn->kn_fop = _filtops;
break;
default:
@@ -355,9 +338,7 @@ midikqfilter(dev_t dev, struct knote *kn
}
kn->kn_hook = (void *)sc;
- mtx_enter(_lock);
- klist_insert_locked(klist, kn);
- mtx_leave(_lock);
+ klist_insert(klist, kn);
done:
device_unref(>dev);
return error;
@@ -368,24 +349,15 @@ filt_midirdetach(struct knote *kn)
{
struct midi_softc *sc = (struct midi_softc *)kn->kn_hook;
- mtx_enter(_lock);
- klist_remove_locked(>inbuf.sel.si_note, kn);
- mtx_leave(_lock);
+ klist_remove(>inbuf.klist, kn);
}
int
filt_midiread(struct knote *kn, long hint)
{
struct midi_softc *sc = (struct midi_softc *)kn->kn_hook;
- int retval;
-
- if ((hint & NOTE_SUBMIT) == 0)
- mtx_enter(_lock);
- retval = !MIDIBUF_ISEMPTY(>inbuf);
- if ((hint & NOTE_SUBMIT) == 0)
- mtx_leave(_lock);
- return (retval);
+ return (!MIDIBUF_ISEMPTY(>inbuf));
}
void
@@ -393,24
Re: Personal website about OpenBSD
Hello Chris, Thanks a lot for the suggestions they were unexpected and indeed are approciated.. I'm mainly sorry to had no time to publish the opensource project yet but I will do it soon considering also your points. NB: the page navigation of the cards happens by two arrows at the left and right of the list that will appear when previous and next pages exist. The card skin is inspired by my other project Puzzleu, to manage a photoblog (see https://puz.mydeeds.org/marti) so the adaptation to the textual world was not so immediate like you undelined through your comments. Again, many thanks! -- Daniele Bonini Sep 25, 2023 14:03:10 Christoff Humphries : > > --- Original Message --- > On Monday, September 25th, 2023 at 8:08 AM, Daniele B. wrote: > > >> >> >> >> Hello, >> >> Just want to introduce you my brand new website about OpenBSD: >> >> https://bsdload.com >> >> Waiting you there! >> >> >> -- Daniele Bonini > > Hi Daniele, > > I like the idea of the website a lot! A few suggestions > that would be more helpful for me (and past me): > > - The font size is too small (for me) for the cards. > - The expanded card font is great, but the information is > not verbose enough. It should explain what the files are > for and why they're listed. Not explain like I'm 10 years > old, but some explanation where the text doesn't assume > I have prior knowledge (otherwise why am I interested). > - The card format is cool but won't scale well. I > suggest using tags or other labels that can enable > quick filtering and perhaps a search in the future. > - Perhaps consider a format like https://book.hacktricks.xyz/ > or https://www.openbsdhandbook.com/ as you add more stuff > if you decide to lose the card format. Additional format > suggestions if not a tree book format could be something > like https://lolbas-project.github.io/ (windows), > https://gtfobins.github.io/ (GNU/Linux), or > https://www.loobins.io/ (macOS) but they're all for > individual datums of commands on systems used for > pentesting/hacking which may not be applicable but > the use of tags and search may be useful as you scale. > - Add a title or tag even, something to convey that it is > for OpenBSD. If I went to the website without seeing this > email I wouldn't know it. > > It's always great to see more tips, tricks, and tutorials! > > Great initiative! Bookmarking.
Re: Personal website about OpenBSD
--- Original Message --- On Monday, September 25th, 2023 at 8:08 AM, Daniele B. wrote: > > > > Hello, > > Just want to introduce you my brand new website about OpenBSD: > > https://bsdload.com > > Waiting you there! > > > -- Daniele Bonini Hi Daniele, I like the idea of the website a lot! A few suggestions that would be more helpful for me (and past me): - The font size is too small (for me) for the cards. - The expanded card font is great, but the information is not verbose enough. It should explain what the files are for and why they're listed. Not explain like I'm 10 years old, but some explanation where the text doesn't assume I have prior knowledge (otherwise why am I interested). - The card format is cool but won't scale well. I suggest using tags or other labels that can enable quick filtering and perhaps a search in the future. - Perhaps consider a format like https://book.hacktricks.xyz/ or https://www.openbsdhandbook.com/ as you add more stuff if you decide to lose the card format. Additional format suggestions if not a tree book format could be something like https://lolbas-project.github.io/ (windows), https://gtfobins.github.io/ (GNU/Linux), or https://www.loobins.io/ (macOS) but they're all for individual datums of commands on systems used for pentesting/hacking which may not be applicable but the use of tags and search may be useful as you scale. - Add a title or tag even, something to convey that it is for OpenBSD. If I went to the website without seeing this email I wouldn't know it. It's always great to see more tips, tricks, and tutorials! Great initiative! Bookmarking.
Re: httpd stopping
On 2023-09-23, Nick Holland wrote: > Hello, > Twice in the last couple weeks, I've had httpd fall over on me. > Only clue I've got is this in /var/log/messages: > > MASTER $ grep httpd daemon > Sep 23 05:24:06 node2 httpd[69989]: logger exiting, pid 69989 > Sep 23 05:24:06 node2 httpd[80972]: parent terminating, pid 80972 > Sep 23 05:24:06 node2 httpd[46871]: server exiting, pid 46871 > Sep 23 05:24:06 node2 httpd[34953]: server exiting, pid 34953 > > first time was after seven days of uptime, this time after > six days. (dmesg below) > > I've not seen httpd fall over like this before...where can > I look to provide better info on this problem? There are some known problems in httpd with fastcgi. This should get you coredumps: sysctl kern.nosuidcoredump=2 mkdir /var/crash/httpd or run it under gdb and poke around after a crash pkg_add gdb egdb /usr/sbin/httpd set args -vd run Either way you'll probably wany to rebuild it with DEBUG=-g to get debug symbols.
Personal website about OpenBSD
Hello, Just want to introduce you my brand new website about OpenBSD: https://bsdload.com Waiting you there! -- Daniele Bonini
