SunBlade 100 will not boot from HDD (6.8 and newer)
Reporting an issue that is causing my SunBlade 100 (ultrasparc64) workstation to be unable too boot. I've identified the release this problem was first introduced 6.8, however the problem remains unresolved in 6.9 and seems to be in even worse state in 7.0 and -current. Net booting appears to be functional, and I can install from a netbooted ram disk without issue in any version (6.8, 6.9, 7.0, -current). Booting from the hard drive after installation is not working since 6.8. The system installs and appears to be working correctly in versions 6.3, 6.4, 6.5, 6.6 and 6.7. Specifically, it appears to me that the workstation hardware is working correctly, and a software bug was introduced between release 6.7 and 6.8 that is causing the issue. Attached is a 6.8 kernel panic (I can provide this for 6.9 as well but not for 7.0 or -current because the kernel doesn't even load on those versions at all). For example on -current all that I get on boot is this: Rebooting with command: boot Boot Device: disk File and args: OpenBSD IEEE 1275 Bootblock 2.1 ..>> OpenBSD BOOT 1.21 Trying BSD... / Evaluating: Flushbuf error read header: short read (only 0 of 64) -- Ted Bullock Sun Blade 100 (UltraSPARC-IIe), No Keyboard Copyright 2005 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.17.1, 512 MB memory installed, Serial #51939433. Ethernet address 0:3:ba:18:88:69, Host ID: 83188869. Rebooting with command: boot Boot device: disk File and args: OpenBSD IEEE 1275 Bootblock 2.1 ..>> OpenBSD BOOT 1.20 Trying bsd... Booting /pci@1f,0/ide@d/disk@0,0:a/bsd 9952008@0x100+1272@0x197db08+189092@0x1c0+4005212@0x1c2e2a4 symbols @ 0xfec72400 477408+165+640344+442535 start=0x100 [ using 1561480 bytes of bsd ELF symbol table ] console is /pci@1f,0/isa@7/serial@0,3f8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.8 (GENERIC) #477: Sun Oct 4 20:36:17 MDT 2020 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC real mem = 536870912 (512MB) avail mem = 509935616 (486MB) random: boothowto does not indicate good seed mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root: Sun Blade 100 (UltraSPARC-IIe) cpu0 at mainbus0: SUNW,UltraSPARC-IIe (rev 1.4) @ 502 MHz cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 256K external (64 b/l) psycho0 at mainbus0: pci108e,a001, impl 0, version 0, ign 7c0 psycho0: bus range 0-1, PCI bus 0 psycho0: dvma map c000-dfff pci0 at psycho0 ebus0 at pci0 dev 12 function 0 "Sun RIO EBus" rev 0x01 "flashprom" at ebus0 addr 0-f not configured clock1 at ebus0 addr 0-1fff: mk48t59 ebus1 at pci0 dev 7 function 0 "Acer Labs M1533 ISA" rev 0x00 "dma" at ebus1 addr 0- ivec 0x2a not configured power0 at ebus1 addr 800-82f ivec 0x20 com0 at ebus1 addr 3f8-3ff ivec 0x2b: ns16550a, 16 byte fifo com0: console com1 at ebus1 addr 2e8-2ef ivec 0x2b: ns16550a, 16 byte fifo alipm0 at pci0 dev 3 function 0 "Acer Labs M7101 Power" rev 0x00: 223KHz clock iic0 at alipm0 "max1617" at alipm0 addr 0x18 skipped due to alipm0 bugs "scm001" at alipm0 addr 0x20 skipped due to alipm0 bugs spdmem0 at iic0 addr 0x50: 256MB SDRAM ECC PC133CL2 spdmem1 at iic0 addr 0x51: 256MB SDRAM ECC PC133CL2 gem0 at pci0 dev 12 function 1 "Sun ERI" rev 0x01: ivec 0x7c6, address 00:03:ba:18:88:69 ukphy0 at gem0 phy 1: Generic IEEE 802.3u media interface, rev. 1: OUI 0x0010dd, model 0x0002 "Sun FireWire" rev 0x01 at pci0 dev 12 function 2 not configured ohci0 at pci0 dev 12 function 3 "Sun USB" rev 0x01: ivec 0x7e4, version 1.0, legacy support autri0 at pci0 dev 8 function 0 "Acer Labs M5451 Audio" rev 0x01: ivec 0x7e3 ac97: codec id 0x41445348 (Analog Devices AD1881A) ac97: codec features headphone, Analog Devices Phat Stereo audio0 at autri0 midi0 at autri0: <4DWAVE MIDI UART> pciide0 at pci0 dev 13 function 0 "Acer Labs M5229 UDMA IDE" rev 0xc3: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7cc for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 19092MB, 39102336 sectors atapiscsi0 at pciide0 channel 0 drive 1 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: removable wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 cd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4 pciide0: channel 1 disabled (no drives) ppb0 at pci0 dev 5 function 0 "DEC 21152" rev 0x03 pci1 at ppb0 bus 1 machfb0 at pci0 dev 19 function 0 "ATI Rage XL" rev 0x27 machfb0: ATY,RageXL, 1152x900 wsdisplay0 at machfb0 mux 1 wsdisplay0: screen 0 added (std, sun emulation) usb0 at ohci0: USB revision 1.0 uhub0 at usb0 configuration 1 interface 0 "Sun OHCI root hub" rev 1.00/1.00 addr 1 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets bootpath: /pci@1f,0/ide@d,0/disk@0,0 root on wd0a
Re: OpenBSD 7.0 installer bug
On Tue, Nov 02, 2021 at 01:36:14PM +, Klemens Nanni wrote: > On Sun, Oct 24, 2021 at 02:06:56PM +, Klemens Nanni wrote: > > On Sun, Oct 24, 2021 at 08:04:26AM -0600, Theo de Raadt wrote: > > > Theo Buehler wrote: > > > > > > > On Sun, Oct 24, 2021 at 12:37:47PM +, Klemens Nanni wrote: > > > > > On Thu, Oct 21, 2021 at 10:29:02AM +, Klemens Nanni wrote: > > > > > > On Thu, Oct 21, 2021 at 04:06:53AM -0600, Theo de Raadt wrote: > > > > > > > Can people handle typing these passwords blindly? I suspect yes. > > > > > > > > > > > > > > Then this seems like a reasonable solution. > > > > > > > > > > > > Other systems do the redacted typing thing, so you see instead > > > > > > of > > > > > > what you actually typed; I think we're used to that and blindly > > > > > > typing > > > > > > is not much different... prompts like doas(1) do it as well. > > > > > > > > > > > > I didn't test autoinstall(8) and thought that was a problem since > > > > > > this > > > > > > diff changes the WEP/WPA passphrase questions from one to two > > > > > > answers if > > > > > > you will, but now I remembered that this obviously isn't a problem > > > > > > for > > > > > > the user password question either. > > > > > > > > > > > > Anyone willing to test this for me or even OK it? > > > > > > I can't do wifi installations here/now but am pretty confident that > > > > > > this > > > > > > does the right thing. > > > > > > > > > > New diff against -CURRENT. > > > > > > > > > > I'll commit this diff once I get positive feedback/an OK or tested it > > > > > myself. > > > > > > > > I'm not a fan. WiFi passwords tend to be on the longer side and > > > > nontrivial to type (they're also not things you tend to know by heart). > > > > I would not expect to be able to type my WiFi password blindly. > > > > > > So then we need a non-! parsing function, which doesn't disable echo. > > > > I guess so. Not a big deal, I just tried the simple way and not write > > any new install.sub code. Will post a diff later. > > Introduce ask_passphrase() and use it solely for the WPA/WEP questions. > > It is an adapted copy of ask_password() with ask_pass() inlined modulo > the `stty echo' handling. > > OK? I have no committed the *correct* diff, not the previous draft with obvious typos.
Re: Ldomctl generates defective config after OBSD 6.3 on T1000.
I will look at the pdf while I am away. I will not be able to test the diff til I get back next week. On Tue, 2 Nov 2021 at 14:46, Mark Kettenis wrote: > > From: Andrew Grillet > > Date: Tue, 2 Nov 2021 14:14:13 + > > > > These were attached to the email I sent last week - that is, the entire > > contents of the directories in > > which I defined the ldom.conf file and the results of compiling it. I > have > > attached the file again. > > > > In each case, this was on a fresh install of the OS, and with a fresh > copy > > of the factory-default config. > > > > >> > After this, my device tree is empty. > > >> > > >> I'm not sure what you mean by that. > > >> You mean you end up in OBP but there are no devices you can boot > from? > > >> > > Yes, this. > > The PCI address appears to be wrong - it is @780, when it should be @7c0. > > > > If you have a tool to examine the binaries in the directory, I would > like a > > copy, and any documentation > > of what the contents means. > > There is sysutils/mdprint in ports. > > There is > > https://sun4v.github.io/downloads/hypervisor-api-3.0draft7.pdf > > in particular chaper 8. But the documentation is somewhat incomplete. > > > Quickly scanning your files, I found one difference related to PCIe. > Might be worth trying the attached diff. > > Index: usr.sbin/ldomctl/config.c > === > RCS file: /cvs/src/usr.sbin/ldomctl/config.c,v > retrieving revision 1.42 > diff -u -p -r1.42 config.c > --- usr.sbin/ldomctl/config.c 31 Jan 2021 05:14:24 - 1.42 > +++ usr.sbin/ldomctl/config.c 2 Nov 2021 14:41:58 - > @@ -704,7 +704,8 @@ hvmd_init_device(struct md *md, struct m > device = xzalloc(sizeof(*device)); > md_get_prop_val(md, node, "gid", >gid); > md_get_prop_val(md, node, "cfghandle", >cfghandle); > - md_get_prop_val(md, node, "rcid", >rcid); > + if (!md_get_prop_val(md, node, "rcid", >rcid)) > + device->rcid = -1; > device->resource_id = resource_id; > if (strcmp(node->name->str, "pcie_bus") == 0) > pcie_busses[resource_id] = device; > @@ -1072,7 +1073,8 @@ hvmd_finalize_device(struct md *md, stru > md_add_prop_val(md, node, "resource_id", device->resource_id); > md_add_prop_val(md, node, "cfghandle", device->cfghandle); > md_add_prop_val(md, node, "gid", device->gid); > - md_add_prop_val(md, node, "rcid", device->rcid); > + if (device->rcid != -1) > + md_add_prop_val(md, node, "rcid", device->rcid); > device->hv_node = node; > } > >
Re: Ldomctl generates defective config after OBSD 6.3 on T1000.
> From: Andrew Grillet > Date: Tue, 2 Nov 2021 14:14:13 + > > These were attached to the email I sent last week - that is, the entire > contents of the directories in > which I defined the ldom.conf file and the results of compiling it. I have > attached the file again. > > In each case, this was on a fresh install of the OS, and with a fresh copy > of the factory-default config. > > >> > After this, my device tree is empty. > >> > >> I'm not sure what you mean by that. > >> You mean you end up in OBP but there are no devices you can boot from? > >> > Yes, this. > The PCI address appears to be wrong - it is @780, when it should be @7c0. > > If you have a tool to examine the binaries in the directory, I would like a > copy, and any documentation > of what the contents means. There is sysutils/mdprint in ports. There is https://sun4v.github.io/downloads/hypervisor-api-3.0draft7.pdf in particular chaper 8. But the documentation is somewhat incomplete. Quickly scanning your files, I found one difference related to PCIe. Might be worth trying the attached diff. Index: usr.sbin/ldomctl/config.c === RCS file: /cvs/src/usr.sbin/ldomctl/config.c,v retrieving revision 1.42 diff -u -p -r1.42 config.c --- usr.sbin/ldomctl/config.c 31 Jan 2021 05:14:24 - 1.42 +++ usr.sbin/ldomctl/config.c 2 Nov 2021 14:41:58 - @@ -704,7 +704,8 @@ hvmd_init_device(struct md *md, struct m device = xzalloc(sizeof(*device)); md_get_prop_val(md, node, "gid", >gid); md_get_prop_val(md, node, "cfghandle", >cfghandle); - md_get_prop_val(md, node, "rcid", >rcid); + if (!md_get_prop_val(md, node, "rcid", >rcid)) + device->rcid = -1; device->resource_id = resource_id; if (strcmp(node->name->str, "pcie_bus") == 0) pcie_busses[resource_id] = device; @@ -1072,7 +1073,8 @@ hvmd_finalize_device(struct md *md, stru md_add_prop_val(md, node, "resource_id", device->resource_id); md_add_prop_val(md, node, "cfghandle", device->cfghandle); md_add_prop_val(md, node, "gid", device->gid); - md_add_prop_val(md, node, "rcid", device->rcid); + if (device->rcid != -1) + md_add_prop_val(md, node, "rcid", device->rcid); device->hv_node = node; }
Re: raspberry pi 4 model b: xhci0: host system error
On Tue, Nov 02, 2021 at 11:44:25AM +0100, Mark Kettenis wrote: > > Date: Tue, 2 Nov 2021 00:05:49 + > > From: Klemens Nanni > > > > On Mon, Nov 01, 2021 at 10:40:33PM +, Stuart Henderson wrote: > > > On 2021/11/01 22:33, Klemens Nanni wrote: > > > 7.0-release is definitely known. EDK2-based definitely works. Older U-Boot > > > should work. > > > > > > > U-Boot 2021.10 (Oct 23 2021 - 05:09:34 -0600) > > > > > > Not sure the state of -current builds but I think that is probably a few > > > hours too early. Try updating the loader on your boot partition to > > > share/u-boot/rpi_arm64/u-boot.bin from u-boot-aarch64-2021.10p1 > > > > This image differs from the one contained in the snapshot and I tried it > > but with no avail: same "host system error". > > > > I'll look further into it. > > So my u-boot "fix" didn't work. I'll probably look into fixing the > kernel properly. But if you want to see if reverting more u-boot > commits helps, go ahead. After reading through openbsd-arm after sthen's suggestion I only tried u-boot.bin from 6.9-release* and that lets 7.0-current xhci(4) attach. * U-Boot 2021.01 (Apr 16 2021 - 15:39:01 +1000)
Re: Ldomctl generates defective config after OBSD 6.3 on T1000.
> From: Andrew Grillet
> Date: Tue, 2 Nov 2021 13:13:16 +
>
> Hi,
>
> I have found my notes, and OBSD 6.4 ldomctl definitely does not produce a
> workable config on a T1000.
What really needs to be done is compare the files generated by 6.3
ldomctl and the 6.4 ldomctl (or 7.0 ldomctl) such that we have a clue
what your particular firmware version barfs on.
If you can bundle up the files and send them to me, I can take a look
if I can find some time.
> On Mon, 1 Nov 2021 at 18:39, Andrew Grillet wrote:
>
> > HI
> >
> > I know for sure 6.5 does not work. I think 6.4 also did not work, because
> > I thought it was a hardware
> > issue at the time, and 6.5 came round before I got a machine up again, but
> > I did not write anything down.
> >
> > I can't say which versions of ldomctl are involved, because there is no
> > "version" option, no version
> > in the man page, and help does not say which version it is. I can't think
> > of any other way to identify
> > the version.
> >
> > I think it is safe to say 6.3 is good, 6.4 is bad, but if you really can't
> > spot the problem, I can test - but not until after
> > 7th November.
> >
> > Andrew
> >
> >
> > On Mon, 1 Nov 2021, 15:11 Klemens Nanni, wrote:
> >
> >> On Wed, Oct 27, 2021 at 04:22:27PM +0100, Andrew Grillet wrote:
> >> > Thanks ...
> >> >
> >> > Oracle Advanced Lights Out Manager CMT v1.7.9
> >> > Sun-Fire-T2000 System Firmware 6.7.10 2010/07/14 16:35
> >> > Host flash versions:
> >> >OBP 4.30.4.b 2010/07/09 13:48
> >> >Hypervisor 1.7.3.c 2010/07/09 15:14
> >> >POST 4.30.4.b 2010/07/09 14:24
> >> > AFAIK, this is the latest available publicly.
> >> >
> >> > I had to recreate the factory default each time.
> >> > Now I have the system running, I am quite reluctant to go back and mess
> >> it
> >> > up.
> >> > If you look in my zip, you will see two config directories. These were
> >> each
> >> > built with a fresh factory-default and the exact same ldom.conf (its
> >> there
> >> > for
> >> > you to check if I messed up!)
> >> >
> >> > The process is:
> >> > 1) do a factory reset
> >> > 2) download the one you wish to test
> >> > 3) attempt to boot.
> >> >
> >> > The bsd63 one will boot and run fine.
> >> > The oct2021 version will give :
> >> > %<--
> >> >
> >> > {0} ok boot
> >> >
> >> > SC Alert: Host System has Reset
> >> >
> >> > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
> >> >
> >> > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
> >> >
> >> > ERROR: /pci@780: Invalid hypervisor argument(s). function: b5
> >> >
> >> >
> >> > Sun Fire(TM) T1000, No Keyboard
> >> > Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights
> >> reserved.
> >> > OpenBoot 4.30.4.d, 2048 MB memory available, Serial #77558134.
> >> > Ethernet address 0:14:4f:9f:71:76, Host ID: 849f7176.
> >> >
> >> > Boot device: net File and args:
> >> > ERROR: boot-read fail
> >> >
> >> > Evaluating:
> >> >
> >> > Can't locate boot device
> >> >
> >> > %<--
> >> > After this, my device tree is empty.
> >>
> >> I'm not sure what you mean by that.
> >> You mean you end up in OBP but there are no devices you can boot from?
> >>
> >> > Resetting to factory-default recovers the device tree, and the system
> >> will
> >> > boot.
> >> >
> >> > (Note this is from the T1000, but the T2000 results were the same apart
> >> > from some differences in
> >> > ID numbers and white space AFAICR).
> >> >
> >> > I can continue to test on the T1000
> >>
> >> Can you bisect OpenBSD releases, i.e. ldomctl versions, on this box?
> >>
> >> Apparently configurations generated with 6.3 work while those out of 6.9
> >> don't, so it'd be helpful to a closer timeframe, then I can look at
> >> ldomctl changes between the last good and first bad versions.
> >>
> >
>
Re: OpenBSD 7.0 installer bug
On Sun, Oct 24, 2021 at 02:06:56PM +, Klemens Nanni wrote:
> On Sun, Oct 24, 2021 at 08:04:26AM -0600, Theo de Raadt wrote:
> > Theo Buehler wrote:
> >
> > > On Sun, Oct 24, 2021 at 12:37:47PM +, Klemens Nanni wrote:
> > > > On Thu, Oct 21, 2021 at 10:29:02AM +, Klemens Nanni wrote:
> > > > > On Thu, Oct 21, 2021 at 04:06:53AM -0600, Theo de Raadt wrote:
> > > > > > Can people handle typing these passwords blindly? I suspect yes.
> > > > > >
> > > > > > Then this seems like a reasonable solution.
> > > > >
> > > > > Other systems do the redacted typing thing, so you see instead of
> > > > > what you actually typed; I think we're used to that and blindly
> > > > > typing
> > > > > is not much different... prompts like doas(1) do it as well.
> > > > >
> > > > > I didn't test autoinstall(8) and thought that was a problem since this
> > > > > diff changes the WEP/WPA passphrase questions from one to two answers
> > > > > if
> > > > > you will, but now I remembered that this obviously isn't a problem for
> > > > > the user password question either.
> > > > >
> > > > > Anyone willing to test this for me or even OK it?
> > > > > I can't do wifi installations here/now but am pretty confident that
> > > > > this
> > > > > does the right thing.
> > > >
> > > > New diff against -CURRENT.
> > > >
> > > > I'll commit this diff once I get positive feedback/an OK or tested it
> > > > myself.
> > >
> > > I'm not a fan. WiFi passwords tend to be on the longer side and
> > > nontrivial to type (they're also not things you tend to know by heart).
> > > I would not expect to be able to type my WiFi password blindly.
> >
> > So then we need a non-! parsing function, which doesn't disable echo.
>
> I guess so. Not a big deal, I just tried the simple way and not write
> any new install.sub code. Will post a diff later.
Introduce ask_passphrase() and use it solely for the WPA/WEP questions.
It is an adapted copy of ask_password() with ask_pass() inlined modulo
the `stty echo' handling.
OK?
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1183
diff -u -p -r1.1183 install.sub
--- install.sub 24 Oct 2021 12:32:42 - 1.1183
+++ install.sub 2 Nov 2021 13:26:18 -
@@ -885,6 +885,27 @@ ask_password() {
done
}
+# Ask for a passphrase once showing prompt $1. Ensure input is not empty
+# save it in $_passphrase.
+ask_passphrase() {
+ local _q=$1
+
+ if $AI; then
+ echo -n "$_q "
+ _autorespond "$_q"
+ echo ''
+ _passphrase=$resp
+ return
+ fi
+
+ while :; do
+ IFS= read -r _passphase?"$_q (will echo)"
+
+ [[ -n $_passphrase ]] && break
+
+ echo "Empty passphrase, try again."
+ done
+}
#
--
# Support functions for donetconfig()
@@ -1245,19 +1266,19 @@ ieee80211_config() {
quote join "$_nwid" >>$_hn
break
;;
- ?-[Ww]) ask_until "WEP key? (will echo)"
+ ?-[Ww]) ask_password "WEP key?" echo
# Make sure ifconfig accepts the key.
- if _err=$(ifconfig $_if join "$_nwid" nwkey
"$resp" 2>&1) &&
+ if _err=$(ifconfig $_if join "$_nwid" nwkey
"$_passphrase" 2>&1) &&
[[ -z $_err ]]; then
- quote join "$_nwid" nwkey "$resp" >>$_hn
+ quote join "$_nwid" nwkey
"$_passphrase" >>$_hn
break
fi
echo "$_err"
;;
- 1-[Pp]) ask_until "WPA passphrase? (will echo)"
+ 1-[Pp]) ask_passphrase "WPA passphrase?"
# Make sure ifconfig accepts the key.
- if ifconfig $_if join "$_nwid" wpakey "$resp";
then
- quote join "$_nwid" wpakey "$resp"
>>$_hn
+ if ifconfig $_if join "$_nwid" wpakey
"$_passphrase"; then
+ quote join "$_nwid" wpakey
"$_passphrase" >>$_hn
break
fi
;;
Re: Installing inkscape or gimp causes conflicts with gcc-libs [OpenBSD 7.0]
On 2021/11/02 13:03, bug.ig...@aleeas.com wrote: > I'm on a fresh install of OpenBSD 7.0 amd64. I've tried with mirrors set to > "https://mirrors.dotsrc.org/pub/OpenBSD; and > "https://ftp.jaist.ac.jp/pub/OpenBSD; - results are same. > inkscape-1.0.2p0:ImageMagick-6.9.12.19: ok > inkscape-1.0.2p0:potrace-1.16: ok > Can't install gcc-libs-8.4.0p9 because of conflicts (gcc-libs-11.2.0p0) > Can't install gcc-libs-8.4.0p9 because of conflicts (gcc-libs-11.2.0p0) > Can't install blas-3.8.0p0: can't resolve gcc-libs-8.4.0p9 > Can't install lapack-3.8.0p1: can't resolve blas-3.8.0p0,gcc-libs-8.4.0p9 > Can't install cblas-1.0p7: can't resolve blas-3.8.0p0,gcc-libs-8.4.0p9 > Can't install py3-numpy-1.16.5p2: can't resolve > lapack-3.8.0p1,gcc-libs-8.4.0p9,cblas-1.0p7 You will need to uninstall gcc-libs-11 and any ports depending on it. The standard ports compiler used for things which require GCC (notably most ports using Fortran) is currently 8.x and it conflicts with the libraries for GCC 11.
Re: Ldomctl generates defective config after OBSD 6.3 on T1000.
Hi,
I have found my notes, and OBSD 6.4 ldomctl definitely does not produce a
workable config on a T1000.
Andrew
On Mon, 1 Nov 2021 at 18:39, Andrew Grillet wrote:
> HI
>
> I know for sure 6.5 does not work. I think 6.4 also did not work, because
> I thought it was a hardware
> issue at the time, and 6.5 came round before I got a machine up again, but
> I did not write anything down.
>
> I can't say which versions of ldomctl are involved, because there is no
> "version" option, no version
> in the man page, and help does not say which version it is. I can't think
> of any other way to identify
> the version.
>
> I think it is safe to say 6.3 is good, 6.4 is bad, but if you really can't
> spot the problem, I can test - but not until after
> 7th November.
>
> Andrew
>
>
> On Mon, 1 Nov 2021, 15:11 Klemens Nanni, wrote:
>
>> On Wed, Oct 27, 2021 at 04:22:27PM +0100, Andrew Grillet wrote:
>> > Thanks ...
>> >
>> > Oracle Advanced Lights Out Manager CMT v1.7.9
>> > Sun-Fire-T2000 System Firmware 6.7.10 2010/07/14 16:35
>> > Host flash versions:
>> >OBP 4.30.4.b 2010/07/09 13:48
>> >Hypervisor 1.7.3.c 2010/07/09 15:14
>> >POST 4.30.4.b 2010/07/09 14:24
>> > AFAIK, this is the latest available publicly.
>> >
>> > I had to recreate the factory default each time.
>> > Now I have the system running, I am quite reluctant to go back and mess
>> it
>> > up.
>> > If you look in my zip, you will see two config directories. These were
>> each
>> > built with a fresh factory-default and the exact same ldom.conf (its
>> there
>> > for
>> > you to check if I messed up!)
>> >
>> > The process is:
>> > 1) do a factory reset
>> > 2) download the one you wish to test
>> > 3) attempt to boot.
>> >
>> > The bsd63 one will boot and run fine.
>> > The oct2021 version will give :
>> > %<--
>> >
>> > {0} ok boot
>> >
>> > SC Alert: Host System has Reset
>> >
>> > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
>> >
>> > ERROR: /pci@780: Invalid hypervisor argument(s). function: b4
>> >
>> > ERROR: /pci@780: Invalid hypervisor argument(s). function: b5
>> >
>> >
>> > Sun Fire(TM) T1000, No Keyboard
>> > Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights
>> reserved.
>> > OpenBoot 4.30.4.d, 2048 MB memory available, Serial #77558134.
>> > Ethernet address 0:14:4f:9f:71:76, Host ID: 849f7176.
>> >
>> > Boot device: net File and args:
>> > ERROR: boot-read fail
>> >
>> > Evaluating:
>> >
>> > Can't locate boot device
>> >
>> > %<--
>> > After this, my device tree is empty.
>>
>> I'm not sure what you mean by that.
>> You mean you end up in OBP but there are no devices you can boot from?
>>
>> > Resetting to factory-default recovers the device tree, and the system
>> will
>> > boot.
>> >
>> > (Note this is from the T1000, but the T2000 results were the same apart
>> > from some differences in
>> > ID numbers and white space AFAICR).
>> >
>> > I can continue to test on the T1000
>>
>> Can you bisect OpenBSD releases, i.e. ldomctl versions, on this box?
>>
>> Apparently configurations generated with 6.3 work while those out of 6.9
>> don't, so it'd be helpful to a closer timeframe, then I can look at
>> ldomctl changes between the last good and first bad versions.
>>
>
Re: raspberry pi 4 model b: xhci0: host system error
> Date: Tue, 2 Nov 2021 00:05:49 + > From: Klemens Nanni > > On Mon, Nov 01, 2021 at 10:40:33PM +, Stuart Henderson wrote: > > On 2021/11/01 22:33, Klemens Nanni wrote: > > 7.0-release is definitely known. EDK2-based definitely works. Older U-Boot > > should work. > > > > > U-Boot 2021.10 (Oct 23 2021 - 05:09:34 -0600) > > > > Not sure the state of -current builds but I think that is probably a few > > hours too early. Try updating the loader on your boot partition to > > share/u-boot/rpi_arm64/u-boot.bin from u-boot-aarch64-2021.10p1 > > This image differs from the one contained in the snapshot and I tried it > but with no avail: same "host system error". > > I'll look further into it. So my u-boot "fix" didn't work. I'll probably look into fixing the kernel properly. But if you want to see if reverting more u-boot commits helps, go ahead.
drmfreeze
Please read the preceding post before this. The information below is the second post made by me pertaining to thread 'drmfreeze'. It is the first? post made to determine when the amdgpu firmware introduced this bug. With the 6,6 amdgpu-firmware-20190312.tgz installed with kernel OpenBSD 7.0-current (GENERIC.MP) #52: Mon Oct 25 10:15:58 MDT 2020 no drm related display freeze occurred during an 'uptime' of: 7:31PM up 5 days, 12:08, 9 users, load averages: 0.01, 0.00, 0.00 So; the installed snapshot and packages were updated. The amdgpu firmware was also changed to the 6.7 amdgpu-firmware-20190312.tgz firmware which is 4 bytes less than the 6.6 version of the identically named file. The 'uptime', kernel, (and subsequent drm related freeze), information are shown below. At approximately 4:25PM the AMD host's display screen froze. Another host was used to access the frozen host via ssh and the next commands were executed. $ uptime 4:46PM up 2:03, 10 users, load averages: 0.00, 0.00, 0.00 $ head -n 2 /var/run/dmesg.boot OpenBSD 7.0-current (GENERIC.MP) #60: Sun Oct 31 13:27:05 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP $ dmesg OpenBSD 7.0-current (GENERIC.MP) #60: Sun Oct 31 13:27:05 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 68647477248 (65467MB) avail mem = 66551013376 (63467MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe8980 (59 entries) bios0: vendor American Megatrends Inc. version "F2" date 03/14/2018 bios0: Gigabyte Technology Co., Ltd. X470 AORUS ULTRA GAMING acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG HPET SSDT UEFI BGRT IVRS SSDT SSDT WSMT acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) GPPF(S4) GP17(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 7 2700X Eight-Core Processor, 3700.62 MHz, 17-08-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Ryzen 7 2700X Eight-Core Processor, 3700.02 MHz, 17-08-02 cpu3:
