Re: tmux server recent snapshot amd64 100% CPU freeze
On Mon, Jul 17, 2023 at 12:54:05PM +, Jacqueline Jolicoeur wrote: > Hi, > > I thought I would mention I seem to be able to reproduce a tmux lock up > where the tmux server component runs at 100% CPU. I am unable to attach > to it at that point. > > The command I run in order to reproduce this is: > > Enter the tmux command prompt. > > C-b and : > > Run this command. > > movew -r > > It stays locked with the movew command still on screen. I end up having > to kill the server process. I have noticed tmux locking up with my original tmux.conf when closing windows, likely because of renumber-windows on: set-option -g default-terminal "tmux-256color" set-option -g history-limit 3000 set-option -g renumber-windows on set-option -ag window-status-current-style bold set-option -ag window-status-current-style fg=black set-option -ag window-status-current-style bg=blue set-option -ag status-style bg=cyan set-option -g escape-time 50 I have since switched to a more simplistic config that hasn't run into the lock up, but I can still trigger it with movew -r as described above: set-option -g escape-time 50 set-option -g base-index 1 set-option -g pane-base-index 1 > > This started to occur in OpenBSD amd64 snapshots around July 13. > > I am running my OpenBSD amd64 with sysctl vm.malloc_conf=S > > ~/.tmux.conf > > set -g status-keys vi > set -g status-right "%F %R" > set -g status-style "bg=black,fg=white" > setw -g mode-keys vi > > Thanks. >
Re: tmux server recent snapshot amd64 100% CPU freeze
On Monday, July 17, 2023, Jacqueline Jolicoeur wrote: > Hi, > > I thought I would mention I seem to be able to reproduce a tmux lock up > where the tmux server component runs at 100% CPU. I am unable to attach > to it at that point. > > The command I run in order to reproduce this is: > > Enter the tmux command prompt. > > C-b and : > > Run this command. > > movew -r > > It stays locked with the movew command still on screen. I end up having > to kill the server process. > > This started to occur in OpenBSD amd64 snapshots around July 13. > > I am running my OpenBSD amd64 with sysctl vm.malloc_conf=S > > ~/.tmux.conf > > set -g status-keys vi > set -g status-right "%F %R" > set -g status-style "bg=black,fg=white" > setw -g mode-keys vi > > Thanks. > > -- Kind regards, Mike
Re: anything like top but for USB?
On Sun, Jul 16, 2023 at 09:31:51PM +0300, 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? I haven't seen any replies to this, so I figure I'd take a swing at sending you a few pointers I have handy. > Ideally it could be like top but for USB or a page on systat or > something like that. I do not know of such a tool (tl;dr: this is the entirety of the email, if this is all you care about, feel free to trash this email) > Are there technical reasons or am I just bad at searching? The OpenBSD USB stack is -- as I've come to discover -- delightfully spartan^Hminimalist. It supports synchronous bulk transfers via ugen, and some specific hardware via bespoke drivers, but not a heck of a lot else. Through my debugging in trying to get a userland library to place nice, I've made friends with using tcpdump(8) to capure USB traffic (see: man for tcpdump(8), look up -i, it makes mention of usb interfaces). Two notes here that may be varying degrees of helpful: 1. If you wanted to build such a tool, it may be possible to sniff traffic from the kernel by using pcap's USB support. This may give you enough information to understand the traffic on your US Bus. (saying USB Bus seems redundant don't you think?) 2. The OpenBSD USB subsystem is not what I'd call highly optimized. It gets the job done, and is generally reliable and predictable, but assumptions from other OSs break down -- especially with software designed and tested with another OS in mind. OpenBSD's USB stack has quirks, to be sure, and porting userland code that makes exotic use of the USB stack is a fucking headache. This isn't meant to criticize the OS, just to provide a bit of nuance to the actual reply, which is that performance bottlenecks may not even live where one would expect in the abstract. If I was so motiated (I haven't been so moitivated yet, to be clear :) ) and wanted to understand when I'm hitting transfer limits in USB my first approach would be to take a capture and graph the traffic, looking for flat lines (as flat lines are not generally from nature). My goal would be to understand why it's flat. The nature of the flat line may lie with the hardware, kernelspace, userland libraries or with software optmized for other operating systems. It may even be with underlying I/O writing results to (a slow?) disk or a (flaky?) network endpoint -- maybe even both? (slow i/o because of a flaky network + nfs) Sorry I can't be of help, but I wish you well. I would invite you to take a more holistic view of the system. I'd be interested if you discover anything helpful here. I haven't needed to optimize throughput, but I'm eager to understand the OpenBSD USB stack better. Take this with a grain of salt, I don't know what I'm talking about :) Fondly, paultag -- :wq
Re: High ACPI CPU load
On Sat, Jul 15, 2023, at 5:38 PM, Julian Huhn wrote: > On Sat, Jul 15, 2023 at 06:05:06PM +, Mike Larkin wrote: >>On Sat, Jul 15, 2023 at 04:34:20PM +0200, Julian Huhn wrote: >>> Since I got many DMARC rejection mails and therefore don't know how many >>> people this mail reached at all, once again with less restrictive DMARC >>> settings. >>> >>> On Sat, Jul 15, 2023 at 02:28:56PM +0200, Julian Huhn wrote: >>> > Moin! >>> > >>> > A few weeks ago, I put a new system into operation, where I notice a >>> > permanently high CPU load. With the help of top it appears that >>> > permanently the process acpi0 is executed. >>> > >>> > Is this a bug? >>> > >>> > I'm happy to help with more logs, if you tell me what you need. >>> > >>> > --Huhn >>> > >> >>This is a stuck GPE. This board in particular is a known issue; search >>the lists. >> >>mbuhl@ suggested a few months back that I get one of these machines to fix >>the issue, but when I started looking at it, the simplest fix was to just >>install a new bios. Since this is likely one of these super cheap 4 port >>igc(4) aliexpress "firewall PCs", you may need to search a bit to find a >>compatible bios since most of these don't have a real brand site associated >>with them. >> >>FWIW, the machines with "techvision" bios (like yours) exhibit this issue. >>Mine had techvision bios (and the same problem) before I flashed it to the >>image described below. >> >>You need to find this bios: >> >>bios0: vendor American Megatrends International, LLC. version "JK4LV107" date >>04/17/2023 > > I just found this Reddit Post [0], describing a related issue with this > kind of board. There's also a download link [1] in the comments for the > bios update. As soon as I found some time I will install the update. > Thanks! > >>That one works on my machine, with exactly the same config as yours. No >>more ACPI GPE storm. >> >>I don't have the link anymore for where I found the BIOS image, but I >>think it was on servethehome in one of the long threads about these >>machines. You need to do some digging. >> >>While the root cause may be due to us lacking some driver for the device >>owning that GPE, or our lack of activating GPEs based on attached >>hardware, the 5-minute bios update fix was a good enough fix for me and >>I moved on to other things. >> >>The other lesson I learned is that you get what you pay for; buying $100 >>PCs from aliexpress means you're just going to be paying for it somewhere >>else. In this case, dealing with shoddy engineering and unsupported boards. >> >>-ml >> >>> > > [0] > https://www.reddit.com/r/PFSENSE/comments/14vv90w/topton_5105_n6005_owners_any_issues_running_on/ > [1] > https://pan.x86pi.cn/BIOS%E6%9B%B4%E6%96%B0/1.Intel%E8%BF%B7%E4%BD%A0%E4%B8%BB%E6%9C%BA%E7%B3%BB%E5%88%97BIOS/N5105%20V3-V5%20%E5%BE%AE%E7%A0%81%E6%9B%B4%E6%96%B023-04-18 I can confirm that the linked BIOS update resolves the stuck GPE on my board. I ended up using unetbootin to get the ISO in a state that my board was willing to boot and flash. I appear to have lost the ability to redirect the BIOS via serial console with this update, but as noted, you get what you pay for. Thanks all. Brian
Hardware Available for Port Maintenance (Maryland, USA)
Re: Allwinner D1 riscv64 mango pi SBC
On Mon, Jul 17, 2023 at 05:18:34PM +0200, Peter J. Philipp wrote: > On Mon, Jul 17, 2023 at 08:41:56AM -0600, deich...@placebonol.com wrote: > > Hi Peter > > > > I don't have a lot of spare money lately, last week extensive car repair > > and the home air conditioner failed last week, however I can contribute > > funds for quantity 1 and maybe 2 Mango Pi. Perhaps some one else can help > > too. > > > > diana > > OK you got me Diana, I'll pledge 60 EUR, I have some reserves. That should > be enough for 2 Mango Pi's. So we have 3-4 Mango Pi's. Anyone else willing > to put in some money? I don't know how to go about this best, should I > pay my pledge to openbsdfoundation with the explicit request that this should > go toward these? Or how would we escrow this? Does OpenBSD have the means > of ordering from AliExpress? Alright 60 EUR paid to the OpenBSD foundation. Bob Beck or Ken Westerback can confirm this perhaps. It didn't allow a comment to indicate that this is for Mango Pi's specifically so I'm hoping the OpenBSD organisation can work it out. Best Regards, -peter > I still have an outstanding pledge to OpenBSD of 5 EUR, which I'll pay when > or if OpenBSD 7.4 gets ED448 support. I'm really hoping it will go in before > the release so that I can adjust my software accordingly for this year (my > release is in November/December). > > Best Regards, > -peter > > > 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. > > > > > -- > Over thirty years experience on Unix-like Operating Systems starting with QNX. > -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: Allwinner D1 riscv64 mango pi SBC
On Mon, Jul 17, 2023 at 08:41:56AM -0600, deich...@placebonol.com wrote: > Hi Peter > > I don't have a lot of spare money lately, last week extensive car repair and > the home air conditioner failed last week, however I can contribute funds for > quantity 1 and maybe 2 Mango Pi. Perhaps some one else can help too. > > diana OK you got me Diana, I'll pledge 60 EUR, I have some reserves. That should be enough for 2 Mango Pi's. So we have 3-4 Mango Pi's. Anyone else willing to put in some money? I don't know how to go about this best, should I pay my pledge to openbsdfoundation with the explicit request that this should go toward these? Or how would we escrow this? Does OpenBSD have the means of ordering from AliExpress? I still have an outstanding pledge to OpenBSD of 5 EUR, which I'll pay when or if OpenBSD 7.4 gets ED448 support. I'm really hoping it will go in before the release so that I can adjust my software accordingly for this year (my release is in November/December). Best Regards, -peter > 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. > > -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: Allwinner D1 riscv64 mango pi SBC
Hi Peter I don't have a lot of spare money lately, last week extensive car repair and the home air conditioner failed last week, however I can contribute funds for quantity 1 and maybe 2 Mango Pi. Perhaps some one else can help too. 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: Terminally Multi-Perplexed
Thank you Otto, I went ahead and reached out to him directly. Just saw a similar report come in to the mailing list so wanted to give that update. On Fri, Jul 14, 2023 at 07:11:22PM +0200, Otto Moerbeek wrote: On Thu, Jul 13, 2023 at 09:01:13PM +, Ares wrote: Howdy, I've experienced occasional but reproducible zombie process creation when ^D'ing a tmux pane. This is on amd64 current and have noticed the behavior since #1279. To reproduce I simply start tmux without any additional flags and then create and ^D about 10-20 panes. Eventually one should hang just after the ^D print and require a tmux server restart. I should also mention that I mfs mount /tmp since that is where tmux saves some of its session files and according to what little I was able to gleem from the ktrace it may be relevant. Obligatory log and configuration files below, let me know if I missed a useful one, and thank you: Hi, Don't know if nicm (the tmux maintainer) reads misc@. I you don't get any reply after a few days see https://github.com/tmux/tmux/wiki/FAQ for other ways to report tmux bugs. -Otto --
tmux server recent snapshot amd64 100% CPU freeze
Hi, I thought I would mention I seem to be able to reproduce a tmux lock up where the tmux server component runs at 100% CPU. I am unable to attach to it at that point. The command I run in order to reproduce this is: Enter the tmux command prompt. C-b and : Run this command. movew -r It stays locked with the movew command still on screen. I end up having to kill the server process. This started to occur in OpenBSD amd64 snapshots around July 13. I am running my OpenBSD amd64 with sysctl vm.malloc_conf=S ~/.tmux.conf set -g status-keys vi set -g status-right "%F %R" set -g status-style "bg=black,fg=white" setw -g mode-keys vi Thanks.
Re: installboot: no OpenBSD partition
After some more investigation and especially after stumbling upon a mail from Otto Moerbeek from 2020, I found that the problem was a missing 'i' partition in the disklabel. installboot(8) needs the 'i' partition in the disklabel to find the EFI partition, otherwise it will try to fall back to MBR. After manually adding the 'i' partition, everything went find. Here is the updated disklabel: # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: KINGSTON SA400S3 duid: 09a9344c23abff6c flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 14593 total sectors: 234441648 boundstart: 1024 boundend: 234441615 16 partitions: # size offset fstype [fsize bsize cpg] a: 230692352 1024 4.2BSD 2048 16384 12960 # / b: 3748239 230693376 swap # none c: 234441648 0 unused i: 960 64 MSDOS installboot(8) works as expected now: # installboot -v sd0 Using / as root installing bootstrap on /dev/rsd0c using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot copying /usr/mdec/BOOTIA32.EFI to /tmp/installboot.AfBA3OfNsR/efi/BOOT/BOOTIA32.EFI copying /usr/mdec/BOOTX64.EFI to /tmp/installboot.AfBA3OfNsR/efi/BOOT/BOOTX64.EFI Best regards, Jona On 16/07/2023 17:28, Jona Joachim wrote: Hi, I have trouble with installboot on a small embedded amd64 system. I get the following error during sysupgrade and also when I run installboot manually: installboot: no OpenBSD partition. You can find the output of installboot, fdisk and disklabel below. I also attached a full dmesg. I initially installed with 7.2 and I just upgraded to 7.3. This should be a GPT install but installboot seems to find an MBR, maybe this is the source of the problem. If possible, I would like to be able to fix this problem without reinstalling the system. Do you have some idea what's going on? Best regards, Jona # installboot -v sd0 /usr/mdec/biosboot /usr/mdec/boot Using / as root installing bootstrap on /dev/rsd0c using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot copying /usr/mdec/boot to //boot looking for superblock at 65536 found valid ffs2 superblock //boot is 6 blocks x 16384 bytes fs block shift 2; part offset 1024; inode block 56, offset 2928 expecting 64-bit fs blocks (incr 4) master boot record (MBR) at sector 0 partition 0: type 0xEE offset 1 size 4294967295 installboot: no OpenBSD partition # fdisk sd0 Disk: sd0 Usable LBA: 34 to 234441614 [234441648 Sectors] #: type [ start: size ] 0: EFI Sys [ 64: 960 ] 1: OpenBSD [ 1024: 234440591 ] # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: KINGSTON SA400S3 duid: 09a9344c23abff6c flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 14593 total sectors: 234441648 boundstart: 1024 boundend: 234441615 16 partitions: # size offset fstype [fsize bsize cpg] a: 230692352 1024 4.2BSD 2048 16384 12960 # / b: 3748239 230693376 swap # none c: 234441648 0 unused
Re: 7.3 on Zotac O1520 makes it unbootable
On 2023-06-18 09:03:02, Harald Dunkel wrote:
Hi folks,
if I install 7.3 on a Zotac O1520 on its internal SATA disk (MBR or UEFI),
then the system gets stuck during BIOS self test on the following reboots.
Without removing the disk I cannot even enter BIOS or select a boot media.
Surely OpenBSD is not to blame here. But its a pity. I'd loved to use it as
a cool desktop PC running a cool OS.
I haven't had a chance to get the usual dmesg output yet, but I wonder if
somebody has an idea by looking at the technical data on
https://www.zotac.com/product/mini_pcs/oi520
?
BTW, there are no BIOS updates.
This seems to be related to fdisk. If I partition the disk
on Linux to create sd0{a..d}, then OpenBSD boots fine. Surely
a BIOS problem.
Regards
Harri
