Re: Concise passage in OpenBSD documentation about motivation
On 7/18/23 13:26, Ibsen S Ripsbusker wrote: Dear colleagues, About 20 years ago I read in some OpenBSD documentation, likely the installation instructions, that we want people to copy our OpenBSD even if to use it even in proprietary products, because the alternative is that incompetent people write their own software instead of copying and then the users suffer. I found this particular passage to be very well written. Does someone know where I might find this wonderful passage? With great honor, Ibsen Dang, that sounds familiar. I think I found it: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/faq1.html?rev=1.147=text/html#ReallyFree I definitely say something similar regularly, but it looks like the original text here was from Theo, himself. I've been similarly inspired and found the example memorable. :) Nick.
Re: Concise passage in OpenBSD documentation about motivation
90% of the developers make bad code, yes. Either because of their lack of experience, their choice of tools, or because of requirements set by managers who just follow the latest trends without having any knowledge of programming themselves. The remaining 10% are highly skilled developers providing the best user experience, the OpenBSD, Go, Zig, and Suckless teams are among those developers. Thierry (the guy who made TempleOS by himself) was one of them too, but he's no longer alive. And Dennis (known for Unix, C, and Plan9), but he too is dead. And some other hidden gems too, all of these people have one thing in common: they all keep their codebases as simple and clean as possible. On 2023年07月18日 17:26, Ibsen S Ripsbusker wrote: > Dear colleagues, > > About 20 years ago I read in some OpenBSD documentation, likely the > installation instructions, that we want people to copy our OpenBSD even > if to use it even in proprietary products, because the alternative is > that incompetent people write their own software instead of copying and > then the users suffer. I found this particular passage to be very well > written. Does someone know where I might find this wonderful passage? > > With great honor, > > Ibsen > -- lain. Did you know that? 90% of all emails sent on a daily basis are being sent in plain text, and it's super easy to intercept emails as they flow over the internet? Never send passwords, tokens, personal information, or other volunerable information without proper PGP encryption! If you're writing your emails unencrypted, please consider sending PGP encrypted emails for security reasons. You can find my PGP public key at: https://fair.moe/lain.asc Every good email client is able to send encrypted emails. If yours can't, then you should consider switching to a secure email client, because yours just sucks. My recommendations are Claws Mail or NeoMutt. For instructions on how to encrypt your emails: https://unixsheikh.com/tutorials/gnupg-tutorial.html
Re: Allwinner D1 riscv64 mango pi SBC
I'm going to reach out to a few folks who I see are doing riscv64 specific development. I realize they might not want to take on yet another h/w design. g.day On July 18, 2023 3:14:18 PM MDT, Mike Larkin wrote: >On Tue, Jul 18, 2023 at 02:02:45PM -0600, deich...@placebonol.com wrote: >> Hi Mike >> >> I've volunteered to coordinate a purchase of Mango Pi to get them into >> OpenBSD developers working on riscv64 platform. >> >> It has been awhile but I used to facilitate getting h/w into OpenBSD >> developers hands on a semi-regular basis. >> >> diana >> >> > >Great. I don't know who would be interested, so I'd wait to let them speak >up before ordering anything. > >-ml > >> >> On July 16, 2023 1:13:02 PM MDT, "Peter J. Philipp" >> wrote: >> >On Sun, Jul 16, 2023 at 06:25:50PM +, Mike Larkin wrote: >> >> On Sun, Jul 16, 2023 at 11:56:51AM +0200, Peter J. Philipp wrote: >> >> > Hi *, >> >> > >> >> > I'm back for the moment. I was wondering who has a Allwinner D1 >> >> > riscv64 SBC? >> >> > This is the Mango Pi SBC. >> >> > >> >> > I have one which has linux on it currently but I'm trying to boot >> >> > OpenBSD on >> >> > it. But I'm fairly lazy and haven't done much with this lately. I can >> >> > get >> >> > to the riscv64 loader but when it loads the kernel, it goes blind. So >> >> > there >> >> > is more than just getting the GPIO pins configured which I think I have >> >> > been >> >> > able to adjust. >> >> > >> >> > I use a QEMU-based riscv64 emulation to compile kernels which is slow >> >> > but this >> >> > SBC isn't much faster either (1000 Mhz it claims). >> >> > >> >> > I use this u-boot directive to get into the boot loader: >> >> > >> >> > setenv bootobsd 'load mmc 0:1 0x4FA0 >> >> > /boot/dtbs/5.19.0-1009-allwinner/allwinner/sun20i-d1-nezha-memory.dtb ; >> >> > load mmc 0:f 0x4008 /EFI/OpenBSD/BOOTRISCV64.EFI ; bootefi >> >> > 0x4008 0x4FA0' >> >> > >> >> > followed by a: >> >> > >> >> > run bootobsd >> >> > >> >> > I am unsure how to save this though in the u-boot itself. Any hints >> >> > would be >> >> > appreciated. >> >> > >> >> > I think we need a specific riscv mailing list for this sort of stuff >> >> > perhaps >> >> > it's too technical for misc. Regarding to the nostradamus stuff of >> >> > someone >> >> > from chicago (Re: A couple of Questions) , check out "1st wave" and >> >> > "cade foster" on youtube (reruns), this will feed you more ideas. my >> >> > personal >> >> > opinion is that time travel of information is possible, contributing to >> >> > major >> >> > headaches when events get changed (for the prometheus seers). >> >> > >> >> > Back to "reality" I'm looking for a group of people to help getting the >> >> > mango >> >> > pi working. I'm hampered by pride to ask knowledged people and these >> >> > people >> >> > have their own directions and I don't want to bother their efforts. >> >> > The more >> >> > we are the more we could possibly get something done. >> >> > >> >> >> >> The best way to get that done is to get hardware in the hands of >> >> developer(s). >> >> Wishing on misc@ is likely not going to get anyone interested. Check the >> >> commit >> >> logs for people working in this area, reach out to them, and see if they >> >> are >> >> interested in helping. >> >> >> >> -ml >> > >> >Hi Mike, >> > >> >Thanks. This will take a bit, I'm in talks to get a new job soon, which >> >will >> >put extra money in my pocket. Then I may be able to get a handful of these >> >perhaps. Do you still keep tabs on Shivam, Mars, Brian, and Wenyan? Are >> >they >> >still interested in riscv64 after the initial port with yours and Dales >> >guidance? I think I paid something like 30 EUR for a Mango Pi from >> >AliExpress >> >buying 4 would work but I can only do this when I have secured the job. >> > >> >Best Regards, >> >-peter >> > >> >-- >> >Over thirty years experience on Unix-like Operating Systems starting with >> >QNX. >> >
Re: Concise passage in OpenBSD documentation about motivation
Am 18.07.2023 19:26 schrieb Ibsen S Ripsbusker: Dear colleagues, About 20 years ago I read in some OpenBSD documentation, likely the installation instructions, that we want people to copy our OpenBSD even if to use it even in proprietary products, because the alternative is that incompetent people write their own software instead of copying and then the users suffer. I found this particular passage to be very well written. Does someone know where I might find this wonderful passage? Maybe you recall lyrics from 4.2 release (or remotely 3.6) here? http://www.openbsd.org/lyrics.html#42 -- pb
Re: Ryzen 9 (7x000) users: do you experience hangs?
Is it something in the water? Mike Larkin writes: > On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: > > This is completely unrelated to the question we asked. Please I mentioned that. Twice. Beginning with the very first words: > > Not really. But. Then summarising with: > > I don't know if that could help or even if it's related, but it can ^^^ (Emphasis added) The symptoms are somewhat similar, and there is a glaring common denominator. That is all. Although it seemed doubtful, just in case another data point could be helpful I hoped to provide enough information without drowning the list in noise so that people more familiar with the matter such as yourself could assess whether a deluge of data was warranted. Don't worry. I won't do that again. Matthew
Re: xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests
On On 2023-07-18, Stuart Henderson wrote: > On 2023-07-18, Morgan Aldridge wrote: > > I'm maintaining an OpenBSD X11 window manager (WM) port, but try to > > keep my primary workstation on -stable, so do most of my development > > there and test in Xephyr. I test & submit patches from an OpenBSD > > -current VM running under vmm(4), but since vmm(4) doesn't emulate > > video hardware, I haven't been run-testing there. > > > > I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but > > they both use an existing X display. After studying xenodm(1), > > Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages, > > plus tons of experimenting, the solution was actually quite simple. > > > > TL; DR > > > > I could find much on the Internet, list archives, etc., regarding this > > specific situation, so here's my solution for a [slow] X11 virtual > > display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH > > tunnel: > > > > doas rcctl enable xenodm > > doas rcctl set xenodm flags \ > > "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'" > > doas rcctl start xenodm > > doas pkg_add x11vnc > > doas rcctl enable x11vnc > > doas rcctl start x11vnc > > > > Hope someone else finds this useful down the road, > > I recommend putting x11vnc in the bin and using tigervnc if it works for > your configuration... Thanks! TigerVNC's x0vncserver(1) seems to work similarly to x11vnc(1)'s default rc.d flags when executed as follows: x0vncserver -SecurityTypes None -localhost This doesn't require a password (WARNING!), but does require an SSH tunnel to access. Is certainly snappier too! Easy enough to copy /etc/rc.d/x11vnc (before uninstalling) and update the 'daemon' & 'daemon_flags' values as follows: daemon="/usr/local/bin/x0vncserver" daemon_flags="-SecurityTypes None -localhost" I'm pretty sure 'rc_bg=YES' & 'rc_reload=NO' would need to be retained. Morgan
Re: xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests
Thanks, will test. Will be useful. On 7/18/23 20:09, Morgan Aldridge wrote: I'm maintaining an OpenBSD X11 window manager (WM) port, but try to keep my primary workstation on -stable, so do most of my development there and test in Xephyr. I test & submit patches from an OpenBSD -current VM running under vmm(4), but since vmm(4) doesn't emulate video hardware, I haven't been run-testing there. I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but they both use an existing X display. After studying xenodm(1), Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages, plus tons of experimenting, the solution was actually quite simple. TL; DR I could find much on the Internet, list archives, etc., regarding this specific situation, so here's my solution for a [slow] X11 virtual display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH tunnel: doas rcctl enable xenodm doas rcctl set xenodm flags \ "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'" doas rcctl start xenodm doas pkg_add x11vnc doas rcctl enable x11vnc doas rcctl start x11vnc Hope someone else finds this useful down the road, Morgan
Re: Ryzen 9 (7x000) users: do you experience hangs?
Just a personal anecdote that might be worth something. On both my AMD chipsets motherboards ( x570/x670E Proart Wifi ) ; I was getting microstutters and odd hangs occasionally for the last year or so, reboots would often power off rather than power cycle - which I mostly wrote off as odditiy with the Mobo . I had a PSU blow (less than 2 years in) on that build - which I put down to Winter Peak power being hot in NZ ( I measure 247V off the grid through the UPS). It was a beQuiet 12 Pro 1000W - RMA'd and replaced with a 1300W beQuiet Pro ; Which went BANG ! after two days - after isolating circuit/removing it from the UPS I went through another 2 beQuiet Pro 1300W within a week with same Bang! (Fet exploding) after a couple of days of working. 4th one switched to a Corsair and it's been fine since. Turns out there is some issue with that particular Power Supply Brand and compatibility with AMD Chipsets - which is not a thing I was expecting to find. -Joel On Wed, 19 Jul 2023 at 09:27, Kastus Shchuka wrote: > On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: > > Not really. But. > > > > I have an APU2 which runs two VMs that do practically nothing, > > although the box itself is used actively. The VMs consistently, and > > without warning, hang in a way which matches the description "nothing > > new can be execed" although I recall being able to log in on the > > console. I noticed shortly after I installed the VMs in around May > > but I haven't got very far diagnosing it because it's a low priority. > > However there is a common denominator: AMD > > > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > > cpu0: 512KB 64b/line 16-way L2 cache > > cpu0: smt 0, core 0, package 0 > > > > Times two. > > > > As you say the existing processes seem to work fine right up until > > sshd is nearly (but not quite?) ready to fork: > > > > . > > . > > . > > debug1: SSH2_MSG_EXT_INFO received > > debug1: kex_input_ext_info: server-sig-algs= sk-ssh-ed25...@openssh.com > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521, > sk-ecdsa-sha2-nistp...@openssh.com, > webauthn-sk-ecdsa-sha2-nistp...@openssh.com > ,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512> > > debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > > > Ordinarily it would next attempt authentication. Does sshd fork and > > drop privileges to do that? > > > > I don't know if that could help or even if it's related, but it can > > be reproduced with confidence. I can poke the box or its VMs any > > way that could shake some data loose. > > > > Matthew > > > > Is AMD errata referenced from https://inks.tedunangst.com/l/4996 any > relevant? > (errata #1474 in > https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf) > > -Kastus > >
Re: xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests
On Tue, Jul 18, 2023 at 04:09:21PM -0400, Morgan Aldridge wrote: > I'm maintaining an OpenBSD X11 window manager (WM) port, but try to > keep my primary workstation on -stable, so do most of my development > there and test in Xephyr. I test & submit patches from an OpenBSD > -current VM running under vmm(4), but since vmm(4) doesn't emulate > video hardware, I haven't been run-testing there. > > I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but > they both use an existing X display. After studying xenodm(1), > Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages, > plus tons of experimenting, the solution was actually quite simple. > > TL; DR > > I could find much on the Internet, list archives, etc., regarding this > specific situation, so here's my solution for a [slow] X11 virtual > display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH > tunnel: > > doas rcctl enable xenodm > doas rcctl set xenodm flags \ > "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'" > doas rcctl start xenodm > doas pkg_add x11vnc > doas rcctl enable x11vnc > doas rcctl start x11vnc > > Hope someone else finds this useful down the road, > > Morgan > Thanks. Always good to have information like this on the list for later searchers. There are other ways too (like sthen@ replied subsequently).
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 01:19:14PM -0700, Kastus Shchuka wrote: > On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: > > Not really. But. > > > > I have an APU2 which runs two VMs that do practically nothing, > > although the box itself is used actively. The VMs consistently, and > > without warning, hang in a way which matches the description "nothing > > new can be execed" although I recall being able to log in on the > > console. I noticed shortly after I installed the VMs in around May > > but I haven't got very far diagnosing it because it's a low priority. > > However there is a common denominator: AMD > > > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > > cpu0: 512KB 64b/line 16-way L2 cache > > cpu0: smt 0, core 0, package 0 > > > > Times two. > > > > As you say the existing processes seem to work fine right up until > > sshd is nearly (but not quite?) ready to fork: > > > > . > > . > > . > > debug1: SSH2_MSG_EXT_INFO received > > debug1: kex_input_ext_info: > > server-sig-algs= > > debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > > > Ordinarily it would next attempt authentication. Does sshd fork and > > drop privileges to do that? > > > > I don't know if that could help or even if it's related, but it can > > be reproduced with confidence. I can poke the box or its VMs any > > way that could shake some data loose. > > > > Matthew > > > > Is AMD errata referenced from https://inks.tedunangst.com/l/4996 any relevant? > (errata #1474 in https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf) > > -Kastus > no
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: > Not really. But. > > I have an APU2 which runs two VMs that do practically nothing, > although the box itself is used actively. The VMs consistently, and > without warning, hang in a way which matches the description "nothing > new can be execed" although I recall being able to log in on the > console. I noticed shortly after I installed the VMs in around May > but I haven't got very far diagnosing it because it's a low priority. > However there is a common denominator: AMD > > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > > Times two. > > As you say the existing processes seem to work fine right up until > sshd is nearly (but not quite?) ready to fork: > > . > . > . > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: > server-sig-algs= > debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> > debug1: SSH2_MSG_SERVICE_ACCEPT received > > Ordinarily it would next attempt authentication. Does sshd fork and > drop privileges to do that? > > I don't know if that could help or even if it's related, but it can > be reproduced with confidence. I can poke the box or its VMs any > way that could shake some data loose. > > Matthew > Is AMD errata referenced from https://inks.tedunangst.com/l/4996 any relevant? (errata #1474 in https://www.amd.com/system/files/TechDocs/56323-PUB_1.01.pdf) -Kastus
Re: Allwinner D1 riscv64 mango pi SBC
On Tue, Jul 18, 2023 at 02:02:45PM -0600, deich...@placebonol.com wrote: > Hi Mike > > I've volunteered to coordinate a purchase of Mango Pi to get them into > OpenBSD developers working on riscv64 platform. > > It has been awhile but I used to facilitate getting h/w into OpenBSD > developers hands on a semi-regular basis. > > diana > > Great. I don't know who would be interested, so I'd wait to let them speak up before ordering anything. -ml > > On July 16, 2023 1:13:02 PM MDT, "Peter J. Philipp" > wrote: > >On Sun, Jul 16, 2023 at 06:25:50PM +, Mike Larkin wrote: > >> On Sun, Jul 16, 2023 at 11:56:51AM +0200, Peter J. Philipp wrote: > >> > Hi *, > >> > > >> > I'm back for the moment. I was wondering who has a Allwinner D1 riscv64 > >> > SBC? > >> > This is the Mango Pi SBC. > >> > > >> > I have one which has linux on it currently but I'm trying to boot > >> > OpenBSD on > >> > it. But I'm fairly lazy and haven't done much with this lately. I can > >> > get > >> > to the riscv64 loader but when it loads the kernel, it goes blind. So > >> > there > >> > is more than just getting the GPIO pins configured which I think I have > >> > been > >> > able to adjust. > >> > > >> > I use a QEMU-based riscv64 emulation to compile kernels which is slow > >> > but this > >> > SBC isn't much faster either (1000 Mhz it claims). > >> > > >> > I use this u-boot directive to get into the boot loader: > >> > > >> > setenv bootobsd 'load mmc 0:1 0x4FA0 > >> > /boot/dtbs/5.19.0-1009-allwinner/allwinner/sun20i-d1-nezha-memory.dtb ; > >> > load mmc 0:f 0x4008 /EFI/OpenBSD/BOOTRISCV64.EFI ; bootefi > >> > 0x4008 0x4FA0' > >> > > >> > followed by a: > >> > > >> > run bootobsd > >> > > >> > I am unsure how to save this though in the u-boot itself. Any hints > >> > would be > >> > appreciated. > >> > > >> > I think we need a specific riscv mailing list for this sort of stuff > >> > perhaps > >> > it's too technical for misc. Regarding to the nostradamus stuff of > >> > someone > >> > from chicago (Re: A couple of Questions) , check out "1st wave" and > >> > "cade foster" on youtube (reruns), this will feed you more ideas. my > >> > personal > >> > opinion is that time travel of information is possible, contributing to > >> > major > >> > headaches when events get changed (for the prometheus seers). > >> > > >> > Back to "reality" I'm looking for a group of people to help getting the > >> > mango > >> > pi working. I'm hampered by pride to ask knowledged people and these > >> > people > >> > have their own directions and I don't want to bother their efforts. The > >> > more > >> > we are the more we could possibly get something done. > >> > > >> > >> The best way to get that done is to get hardware in the hands of > >> developer(s). > >> Wishing on misc@ is likely not going to get anyone interested. Check the > >> commit > >> logs for people working in this area, reach out to them, and see if they > >> are > >> interested in helping. > >> > >> -ml > > > >Hi Mike, > > > >Thanks. This will take a bit, I'm in talks to get a new job soon, which will > >put extra money in my pocket. Then I may be able to get a handful of these > >perhaps. Do you still keep tabs on Shivam, Mars, Brian, and Wenyan? Are > >they > >still interested in riscv64 after the initial port with yours and Dales > >guidance? I think I paid something like 30 EUR for a Mango Pi from > >AliExpress > >buying 4 would work but I can only do this when I have secured the job. > > > >Best Regards, > >-peter > > > >-- > >Over thirty years experience on Unix-like Operating Systems starting with > >QNX. > >
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 08:09:11PM +0100, cho...@jtan.com wrote: This is completely unrelated to the question we asked. Please don't hijack the thread. > Not really. But. > > I have an APU2 which runs two VMs that do practically nothing, > although the box itself is used actively. The VMs consistently, and > without warning, hang in a way which matches the description "nothing > new can be execed" although I recall being able to log in on the > console. I noticed shortly after I installed the VMs in around May > but I haven't got very far diagnosing it because it's a low priority. > However there is a common denominator: AMD > > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache > cpu0: 512KB 64b/line 16-way L2 cache > cpu0: smt 0, core 0, package 0 > > Times two. > > As you say the existing processes seem to work fine right up until > sshd is nearly (but not quite?) ready to fork: > > . > . > . > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: > server-sig-algs= > debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> > debug1: SSH2_MSG_SERVICE_ACCEPT received > > Ordinarily it would next attempt authentication. Does sshd fork and > drop privileges to do that? > > I don't know if that could help or even if it's related, but it can > be reproduced with confidence. I can poke the box or its VMs any > way that could shake some data loose. > > Matthew >
Re: PF rate limiting options valid for UDP?
On 2023-07-18, mabi wrote: > Hello, > > From the following documentation, I am trying to figure out which PF tracking > options are also valid for UDP but unfortunately it is not quite clear to me: > > https://man.openbsd.org/pf.conf.5#Stateful_Tracking_Options > > My goal would be to do add rate limiting options to a PF UDP pass rule in > order to limit DDoS/DoS attacks on port 53. > > Interesting would be especially the "max-src-states" option. Is this option > also valid for UDP? > > Is it also possible to use the "overload" option with UDP in order to add > source IPs into a table of attackers which I will then block? PF's state-tracking options are only for TCP. (Blocking an IP based on number of connections from easily spoofed UDP is a good way to let third parties prevent your machine from communicating with IPs that may well get in the way i.e. trigger a "self DoS"). You may be interested in looking into L7 methods of mitigating problems from high rates of DNS queries - for example dnsdist allows a lot of flexibility in this area.
Re: xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests
On 2023-07-18, Morgan Aldridge wrote: > I'm maintaining an OpenBSD X11 window manager (WM) port, but try to > keep my primary workstation on -stable, so do most of my development > there and test in Xephyr. I test & submit patches from an OpenBSD > -current VM running under vmm(4), but since vmm(4) doesn't emulate > video hardware, I haven't been run-testing there. > > I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but > they both use an existing X display. After studying xenodm(1), > Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages, > plus tons of experimenting, the solution was actually quite simple. > > TL; DR > > I could find much on the Internet, list archives, etc., regarding this > specific situation, so here's my solution for a [slow] X11 virtual > display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH > tunnel: > > doas rcctl enable xenodm > doas rcctl set xenodm flags \ > "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'" > doas rcctl start xenodm > doas pkg_add x11vnc > doas rcctl enable x11vnc > doas rcctl start x11vnc > > Hope someone else finds this useful down the road, I recommend putting x11vnc in the bin and using tigervnc if it works for your configuration...
xenodm + Xvfb + x11vnc = virtual display for vmm(4) OpenBSD guests
I'm maintaining an OpenBSD X11 window manager (WM) port, but try to keep my primary workstation on -stable, so do most of my development there and test in Xephyr. I test & submit patches from an OpenBSD -current VM running under vmm(4), but since vmm(4) doesn't emulate video hardware, I haven't been run-testing there. I'm already comfortable with x11vnc under OpenBSD, plus Xephyr, but they both use an existing X display. After studying xenodm(1), Xvfb(1), x11vnc(1), and a bunch of other X(1)-related manual pages, plus tons of experimenting, the solution was actually quite simple. TL; DR I could find much on the Internet, list archives, etc., regarding this specific situation, so here's my solution for a [slow] X11 virtual display on a vmm(4) OpenBSD guest, accessible via VNC over an SSH tunnel: doas rcctl enable xenodm doas rcctl set xenodm flags \ "-server ':0 local /usr/X11R6/bin/Xvfb :0 -screen 1024x768x24 -shmem'" doas rcctl start xenodm doas pkg_add x11vnc doas rcctl enable x11vnc doas rcctl start x11vnc Hope someone else finds this useful down the road, Morgan
Re: Allwinner D1 riscv64 mango pi SBC
Hi Mike I've volunteered to coordinate a purchase of Mango Pi to get them into OpenBSD developers working on riscv64 platform. It has been awhile but I used to facilitate getting h/w into OpenBSD developers hands on a semi-regular basis. diana On July 16, 2023 1:13:02 PM MDT, "Peter J. Philipp" wrote: >On Sun, Jul 16, 2023 at 06:25:50PM +, Mike Larkin wrote: >> On Sun, Jul 16, 2023 at 11:56:51AM +0200, Peter J. Philipp wrote: >> > Hi *, >> > >> > I'm back for the moment. I was wondering who has a Allwinner D1 riscv64 >> > SBC? >> > This is the Mango Pi SBC. >> > >> > I have one which has linux on it currently but I'm trying to boot OpenBSD >> > on >> > it. But I'm fairly lazy and haven't done much with this lately. I can get >> > to the riscv64 loader but when it loads the kernel, it goes blind. So >> > there >> > is more than just getting the GPIO pins configured which I think I have >> > been >> > able to adjust. >> > >> > I use a QEMU-based riscv64 emulation to compile kernels which is slow but >> > this >> > SBC isn't much faster either (1000 Mhz it claims). >> > >> > I use this u-boot directive to get into the boot loader: >> > >> > setenv bootobsd 'load mmc 0:1 0x4FA0 >> > /boot/dtbs/5.19.0-1009-allwinner/allwinner/sun20i-d1-nezha-memory.dtb ; >> > load mmc 0:f 0x4008 /EFI/OpenBSD/BOOTRISCV64.EFI ; bootefi 0x4008 >> > 0x4FA0' >> > >> > followed by a: >> > >> > run bootobsd >> > >> > I am unsure how to save this though in the u-boot itself. Any hints would >> > be >> > appreciated. >> > >> > I think we need a specific riscv mailing list for this sort of stuff >> > perhaps >> > it's too technical for misc. Regarding to the nostradamus stuff of someone >> > from chicago (Re: A couple of Questions) , check out "1st wave" and >> > "cade foster" on youtube (reruns), this will feed you more ideas. my >> > personal >> > opinion is that time travel of information is possible, contributing to >> > major >> > headaches when events get changed (for the prometheus seers). >> > >> > Back to "reality" I'm looking for a group of people to help getting the >> > mango >> > pi working. I'm hampered by pride to ask knowledged people and these >> > people >> > have their own directions and I don't want to bother their efforts. The >> > more >> > we are the more we could possibly get something done. >> > >> >> The best way to get that done is to get hardware in the hands of >> developer(s). >> Wishing on misc@ is likely not going to get anyone interested. Check the >> commit >> logs for people working in this area, reach out to them, and see if they are >> interested in helping. >> >> -ml > >Hi Mike, > >Thanks. This will take a bit, I'm in talks to get a new job soon, which will >put extra money in my pocket. Then I may be able to get a handful of these >perhaps. Do you still keep tabs on Shivam, Mars, Brian, and Wenyan? Are they >still interested in riscv64 after the initial port with yours and Dales >guidance? I think I paid something like 30 EUR for a Mango Pi from AliExpress >buying 4 would work but I can only do this when I have secured the job. > >Best Regards, >-peter > >-- >Over thirty years experience on Unix-like Operating Systems starting with QNX. >
Re: Ryzen 9 (7x000) users: do you experience hangs?
Not really. But. I have an APU2 which runs two VMs that do practically nothing, although the box itself is used actively. The VMs consistently, and without warning, hang in a way which matches the description "nothing new can be execed" although I recall being able to log in on the console. I noticed shortly after I installed the VMs in around May but I haven't got very far diagnosing it because it's a low priority. However there is a common denominator: AMD cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.02 MHz, 14-02-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,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 Times two. As you say the existing processes seem to work fine right up until sshd is nearly (but not quite?) ready to fork: . . . debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: kex_input_ext_info: publickey-hostbo...@openssh.com=<0> debug1: SSH2_MSG_SERVICE_ACCEPT received Ordinarily it would next attempt authentication. Does sshd fork and drop privileges to do that? I don't know if that could help or even if it's related, but it can be reproduced with confidence. I can poke the box or its VMs any way that could shake some data loose. Matthew
Re: Ryzen 9 (7x000) users: do you experience hangs?
On Tue, Jul 18, 2023 at 09:43:51AM +0100, Laurence Tratt wrote: > A small number of us with AMD Ryzen 9 (i.e. chips in the 7x000 range) > machines have been experiencing regular (often daily), or semi-regular > hangs, but without any obvious cause. > > What we don't know is if we're the unlucky few, or whether this might be a > wider issue. So, to see if there is some sort of pattern going on (e.g. are > certain motherboards / BIOSes correlated with hangs or not?), I'd like to > poll Ryzen 9 OpenBSD users. At a minimum we'd need to know: > > CPU model (e.g. "7900x") > Motherboard (e.g. "MSI PRO670-X") > Have you experienced crashes? (Yes/No) If "Yes": > what frequency (e.g. "daily/weekly/no obvious pattern")? > are there are obvious causes (e.g. "happens when I run program X")? > have you found any mitigations (e.g. "updated BIOS")? > Ideally a dmesg too > > We're as interested in Ryzen 9 users who aren't experiencing hangs as who > are! Please feel free to reply to the list, or to me individually, and I'll > collate the information and see if there are any patterns or not. > > > Laurie > -- > Personalhttps://tratt.net/laurie/ > Software Development Team https://soft-dev.org/ >https://github.com/ltratt https://twitter.com/laurencetratt > A bit of color commentary here... Laurie and I and a few other folks have been trying to debug the hangs that some people are seeing on these machines. He and I have identical hardware and he sees regular hangs, and I rarely see any (I think in the span of 7 months I've seen maybe 2 or 3 total). I've been using this machine in anger as a daily driver and I can't make it break and other people can't even make it a day without a hang. We've tried to debug the issue and narrow down what device(s) might be causing the problem, or what workload, etc, but nothing is pointing in any specific direction. We've also seen reports of "long slow death" crashes where existing processes continue to work for some time but nothing new can be execed, and eventually even the existing processes freeze. To me that sounds like a lock issue but it never happens on my machine and only infreqently elsewhere, so I can't really debug it. We'd like to know if others have similar machines and if they are stable or not. -ml
Concise passage in OpenBSD documentation about motivation
Dear colleagues, About 20 years ago I read in some OpenBSD documentation, likely the installation instructions, that we want people to copy our OpenBSD even if to use it even in proprietary products, because the alternative is that incompetent people write their own software instead of copying and then the users suffer. I found this particular passage to be very well written. Does someone know where I might find this wonderful passage? With great honor, Ibsen
PF rate limiting options valid for UDP?
Hello, >From the following documentation, I am trying to figure out which PF tracking >options are also valid for UDP but unfortunately it is not quite clear to me: https://man.openbsd.org/pf.conf.5#Stateful_Tracking_Options My goal would be to do add rate limiting options to a PF UDP pass rule in order to limit DDoS/DoS attacks on port 53. Interesting would be especially the "max-src-states" option. Is this option also valid for UDP? Is it also possible to use the "overload" option with UDP in order to add source IPs into a table of attackers which I will then block? That would be for an OpenBSD 7.3 firewall. Best regards, Mabi
Re: anything like top but for USB?
On 2023-07-16, Hannu Vuolasaho wrote: > Is there a tool to show statististics of USB devices? Like how much > there is free bandwidth, which endpoints are hogging bandwidth and so > on? You might get some parts of the information you want from wireshark, though nothing as simple as a top-like display.
Ryzen 9 (7x000) users: do you experience hangs?
A small number of us with AMD Ryzen 9 (i.e. chips in the 7x000 range) machines have been experiencing regular (often daily), or semi-regular hangs, but without any obvious cause. What we don't know is if we're the unlucky few, or whether this might be a wider issue. So, to see if there is some sort of pattern going on (e.g. are certain motherboards / BIOSes correlated with hangs or not?), I'd like to poll Ryzen 9 OpenBSD users. At a minimum we'd need to know: CPU model (e.g. "7900x") Motherboard (e.g. "MSI PRO670-X") Have you experienced crashes? (Yes/No) If "Yes": what frequency (e.g. "daily/weekly/no obvious pattern")? are there are obvious causes (e.g. "happens when I run program X")? have you found any mitigations (e.g. "updated BIOS")? Ideally a dmesg too We're as interested in Ryzen 9 users who aren't experiencing hangs as who are! Please feel free to reply to the list, or to me individually, and I'll collate the information and see if there are any patterns or not. Laurie -- Personalhttps://tratt.net/laurie/ Software Development Team https://soft-dev.org/ https://github.com/ltratt https://twitter.com/laurencetratt
