Re: ARM64 installation with new snapshots not possible any longer
Tried a snapshot from 12.07.2023 and can confirm it works. OpenBSD 7.3-current (GENERIC.MP) #2188: Mon Jul 10 14:25:11 MDT 2023 http://ftp.hostserver.de/archive/2023-07-12-0105/snapshots/arm64/miniroot73.img Zitat von Patrick Wildt : Root cause has been found, the next snap, whenever it will be out, will have the fixes! Sorry it took so long, reverting wasn‘t a solution as that would have broken another machine, and it took some time too find out what was wrong. Cheers, Patrick On 20. Jun 2023, at 12:35, develo...@robert-palm.de wrote: Quoting Mark Kettenis : Date: Tue, 20 Jun 2023 09:31:58 +0200 From: develo...@robert-palm.de Hi, I noticed that an ARM64 installation with latest snapshots is not possible any longer in hetzner cloud arm64 instances (ampere altra). Last snapshot working is https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img Later snapshots get stuck at "scsibus1 at softraid0: 256 targets". So it does not get to "root on rd0a swap on rd0b dump on rd0b" any more. Think there were 2 or 3 changes related to arm64 between (17-Jun-2023 06:36) and (18-Jun-2023 19:59) that might cause this. Please, can you have a look at it? The most likely candidate is: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/06/18 10:25:21 Modified files: sys/arch/arm64/dev: agintc.c Log message: Remove spurious comment. ok patrick@ Can you try reverting that change and see of the resulting kernel boots? Also, I'd like to understand why you're hitting this case. Can you show a dmesg from the last working kernel? Thanks for your fast reply. Please find the dmesg_log.txt attached. Is it possible you revert the change and create a new miniroot.img file for me ? Currently I am just using images. Need to figure out how to compile the sources and create the image to try the installation again.
Re: ARM64 installation with new snapshots not possible any longer
Root cause has been found, the next snap, whenever it will be out, will have the fixes! Sorry it took so long, reverting wasn‘t a solution as that would have broken another machine, and it took some time too find out what was wrong. Cheers, Patrick > > On 20. Jun 2023, at 12:35, develo...@robert-palm.de wrote: > > > Quoting Mark Kettenis : > >>> Date: Tue, 20 Jun 2023 09:31:58 +0200 >>> From: develo...@robert-palm.de >>> >>> Hi, >>> >>> I noticed that an ARM64 installation with latest snapshots is not >>> possible any longer in hetzner cloud arm64 instances (ampere altra). >>> >>> Last snapshot working is >>> https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img >>> >>> Later snapshots get stuck at "scsibus1 at softraid0: 256 targets". >>> >>> So it does not get to "root on rd0a swap on rd0b dump on rd0b" any more. >>> >>> Think there were 2 or 3 changes related to arm64 between (17-Jun-2023 >>> 06:36) and (18-Jun-2023 19:59) that might cause this. >>> >>> Please, can you have a look at it? >> >> The most likely candidate is: >> >> CVSROOT:/cvs >> Module name:src >> Changes by: kette...@cvs.openbsd.org2023/06/18 10:25:21 >> >> Modified files: >> sys/arch/arm64/dev: agintc.c >> >> Log message: >> Remove spurious comment. >> >> ok patrick@ >> >> Can you try reverting that change and see of the resulting kernel boots? >> >> Also, I'd like to understand why you're hitting this case. Can you >> show a dmesg from the last working kernel? > > Thanks for your fast reply. > > Please find the dmesg_log.txt attached. > > Is it possible you revert the change and create a new miniroot.img file for > me ? > > Currently I am just using images. Need to figure out how to compile the > sources and create the image to try the installation again. > > > > >
Re: ARM64 installation with new snapshots not possible any longer
On Sat, Jun 24, 2023 at 05:48:15PM +0200, Volker Schlecht wrote: > > > Date: Tue, 20 Jun 2023 09:31:58 +0200 > > > From: develo...@robert-palm.de > > > > > > Hi, > > > > > > I noticed that an ARM64 installation with latest snapshots is not > > > possible any longer in hetzner cloud arm64 instances (ampere altra). > > > > > > Last snapshot working is > > > https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img > [...] > > The most likely candidate is: > > > > CVSROOT:/cvs > > Module name:src > > Changes by: kette...@cvs.openbsd.org2023/06/18 10:25:21 > > Modified files: > > sys/arch/arm64/dev: agintc.c Log message: > > Remove spurious comment. > > ok patrick@ > > > > Can you try reverting that change and see of the resulting kernel boots? > > I hope that commit didn't have any functional consequences, so I built a > -current kernel with the previous diff reverted, and it boots fine now: > > CVSROOT: /cvs > Module name: src > Changes by: kette...@cvs.openbsd.org2023/06/17 16:10:19 > > Modified files: > sys/arch/arm64/dev: agintc.c > > Log message: > Flush the ITS after we disestablish an MSI. Fixes an issue seen on Ampere > eMAG with an AMD GPU with an HD audio function where azalia(4) doesn't > fully attach. > > ok patrick@ It should not have a functional consequence on the VM, but obviously it does make a difference because it stops booting. I have tried to come up with a diff that replaces INVALL with targeted INV, but those still lead to a hang. Since backing this diff out breaks another machine, a solution needs to be found, not a backout. I'll have a look.
Re: ARM64 installation with new snapshots not possible any longer
Zitat von Volker Schlecht : Date: Tue, 20 Jun 2023 09:31:58 +0200 From: develo...@robert-palm.de Hi, I noticed that an ARM64 installation with latest snapshots is not possible any longer in hetzner cloud arm64 instances (ampere altra). Last snapshot working is https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img [...] The most likely candidate is: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/06/18 10:25:21 Modified files: sys/arch/arm64/dev: agintc.c Log message: Remove spurious comment. ok patrick@ Can you try reverting that change and see of the resulting kernel boots? I hope that commit didn't have any functional consequences, so I built a -current kernel with the previous diff reverted, and it boots fine now: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/06/17 16:10:19 Modified files: sys/arch/arm64/dev: agintc.c Log message: Flush the ITS after we disestablish an MSI. Fixes an issue seen on Ampere eMAG with an AMD GPU with an HD audio function where azalia(4) doesn't fully attach. ok patrick@ Did a rollback in the OpenBSD CVS already take place or how to proceed? Happy to try it out again with a fresh snapshot.
Re: ARM64 installation with new snapshots not possible any longer
Date: Tue, 20 Jun 2023 09:31:58 +0200 From: develo...@robert-palm.de Hi, I noticed that an ARM64 installation with latest snapshots is not possible any longer in hetzner cloud arm64 instances (ampere altra). Last snapshot working is https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img [...] The most likely candidate is: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/06/18 10:25:21 Modified files: sys/arch/arm64/dev: agintc.c Log message: Remove spurious comment. ok patrick@ Can you try reverting that change and see of the resulting kernel boots? I hope that commit didn't have any functional consequences, so I built a -current kernel with the previous diff reverted, and it boots fine now: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/06/17 16:10:19 Modified files: sys/arch/arm64/dev: agintc.c Log message: Flush the ITS after we disestablish an MSI. Fixes an issue seen on Ampere eMAG with an AMD GPU with an HD audio function where azalia(4) doesn't fully attach. ok patrick@
Re: ARM64 installation with new snapshots not possible any longer
Quoting Mark Kettenis : Date: Tue, 20 Jun 2023 09:31:58 +0200 From: develo...@robert-palm.de Hi, I noticed that an ARM64 installation with latest snapshots is not possible any longer in hetzner cloud arm64 instances (ampere altra). Last snapshot working is https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img Later snapshots get stuck at "scsibus1 at softraid0: 256 targets". So it does not get to "root on rd0a swap on rd0b dump on rd0b" any more. Think there were 2 or 3 changes related to arm64 between (17-Jun-2023 06:36) and (18-Jun-2023 19:59) that might cause this. Please, can you have a look at it? The most likely candidate is: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/06/18 10:25:21 Modified files: sys/arch/arm64/dev: agintc.c Log message: Remove spurious comment. ok patrick@ Can you try reverting that change and see of the resulting kernel boots? Also, I'd like to understand why you're hitting this case. Can you show a dmesg from the last working kernel? Thanks for your fast reply. Please find the dmesg_log.txt attached. Is it possible you revert the change and create a new miniroot.img file for me ? Currently I am just using images. Need to figure out how to compile the sources and create the image to try the installation again. OpenBSD 7.3-current (GENERIC.MP) #2164: Sat Jun 17 00:13:31 MDT 2023 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 4185800704 (3991MB) avail mem = 3976462336 (3792MB) random: good seed from bootblocks mainbus0 at root: ACPI psci0 at mainbus0: PSCI 1.0, SMCCC 1.1 cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r3p1 cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache cpu0: 1024KB 64b/line 8-way L2 cache cpu0: DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR cpu1 at mainbus0 mpidr 1: ARM Neoverse N1 r3p1 cpu1: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache cpu1: 1024KB 64b/line 8-way L2 cache cpu1: DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR efi0 at mainbus0: UEFI 2.7 efi0: EDK II rev 0x1 smbios0 at efi0: SMBIOS 3.0.0 smbios0: vendor Hetzner version "2017" date 11/11/2017 smbios0: Hetzner vServer apm0 at mainbus0 agintc0 at mainbus0 shift 4:4 nirq 288 nredist 2 ipi: 0, 1, 2: "interrupt-controller" agintcmsi0 at agintc0 agtimer0 at mainbus0: 25000 kHz acpi0 at mainbus0: ACPI 5.1 acpi0: sleep states acpi0: tables DSDT FACP APIC GTDT MCFG SPCR DBG2 IORT BGRT acpi0: wakeup devices acpimcfg0 at acpi0 acpimcfg0: addr 0x401000, bus 0-255 acpiiort0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured pluart0 at acpi0 COM0 addr 0x900/0x1000 irq 33 pluart0: console "LNRO0015" at acpi0 not configured "LNRO0015" at acpi0 not configured "QEMU0002" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured "LNRO0005" at acpi0 not configured acpipci0 at acpi0 PCI0 pci0 at acpipci0 0:4:0: io address conflict 0x8200/0x8 "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured virtio0 at pci0 dev 1 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 viogpu0 at virtio0: 1024x768, 32bpp wsdisplay0 at viogpu0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) virtio0: msix shared ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: irq 37 pci1 at ppb0 bus 1 1:0:0: rom address conflict 0xfff8/0x8 virtio1 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio1: address 96:00:02:4c:1d:d2 virtio1: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: irq 37 pci2 at ppb1 bus 2 xhci0 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000d rev 0x01: msix,
Re: ARM64 installation with new snapshots not possible any longer
> Date: Tue, 20 Jun 2023 09:31:58 +0200 > From: develo...@robert-palm.de > > Hi, > > I noticed that an ARM64 installation with latest snapshots is not > possible any longer in hetzner cloud arm64 instances (ampere altra). > > Last snapshot working is > https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img > > Later snapshots get stuck at "scsibus1 at softraid0: 256 targets". > > So it does not get to "root on rd0a swap on rd0b dump on rd0b" any more. > > Think there were 2 or 3 changes related to arm64 between (17-Jun-2023 > 06:36) and (18-Jun-2023 19:59) that might cause this. > > Please, can you have a look at it? The most likely candidate is: CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/06/18 10:25:21 Modified files: sys/arch/arm64/dev: agintc.c Log message: Remove spurious comment. ok patrick@ Can you try reverting that change and see of the resulting kernel boots? Also, I'd like to understand why you're hitting this case. Can you show a dmesg from the last working kernel?
ARM64 installation with new snapshots not possible any longer
Hi, I noticed that an ARM64 installation with latest snapshots is not possible any longer in hetzner cloud arm64 instances (ampere altra). Last snapshot working is https://ftp.hostserver.de/archive/2023-06-18-0105/snapshots/arm64/miniroot73.img Later snapshots get stuck at "scsibus1 at softraid0: 256 targets". So it does not get to "root on rd0a swap on rd0b dump on rd0b" any more. Think there were 2 or 3 changes related to arm64 between (17-Jun-2023 06:36) and (18-Jun-2023 19:59) that might cause this. Please, can you have a look at it? Many thanks. Robert
