daily CVS update output
Updating src tree: P src/common/lib/libc/gen/ptree.c P src/common/lib/libc/gen/radixtree.c P src/distrib/notes/hp300/upgrade P src/doc/3RDPARTY P src/external/mit/xorg/bin/xdm/config/Xresources.in P src/games/phantasia/misc.c P src/games/trek/dcrept.c P src/games/trek/setwarp.c P src/lib/libc/stdio/vfscanf.c P src/lib/libc/stdlib/div.3 P src/lib/libp2k/p2k.c P src/lib/libresolv/dst_api.c P src/sbin/atactl/atactl.8 P src/sbin/iscsid/iscsid_targets.c P src/sbin/mount_nilfs/mount_nilfs.8 P src/sbin/nvmectl/bignum.c P src/share/man/man4/lagg.4 P src/sys/altq/altq_rmclass.h P src/sys/arch/acorn32/stand/boot32/boot32.c P src/sys/arch/amd64/amd64/genassym.cf P src/sys/arch/amd64/amd64/vector.S P src/sys/arch/amd64/conf/XEN3_DOM0 P src/sys/arch/amiga/dev/grf.c P src/sys/arch/amiga/dev/grfioctl.h P src/sys/arch/amiga/dev/if_es.c P src/sys/arch/arc/arc/platform.c P src/sys/arch/arc/dev/pccons.c P src/sys/arch/arm/arm32/bus_dma.c P src/sys/arch/arm/include/disklabel.h P src/sys/arch/arm/iomd/vidc20config.c P src/sys/arch/atari/atari/atari_init.c P src/sys/arch/atari/atari/bus.c P src/sys/arch/atari/atari/disksubr.c P src/sys/arch/atari/dev/grfioctl.h P src/sys/arch/evbarm/conf/GUMSTIX P src/sys/arch/evbarm/ixm1200/ixm1200_start.S P src/sys/arch/hpcsh/dev/hd64461/hd64461video.c P src/sys/arch/i386/i386/genassym.cf P src/sys/arch/i386/i386/vector.S P src/sys/arch/m68k/fpe/fpu_sqrt.c P src/sys/arch/mips/ralink/ralink_eth.c P src/sys/arch/mipsco/mipsco/disksubr.c P src/sys/arch/ofppc/ofppc/disksubr.c P src/sys/arch/or1k/include/disklabel.h P src/sys/arch/powerpc/fpu/fpu_sqrt.c P src/sys/arch/powerpc/include/booke/e500reg.h P src/sys/arch/riscv/include/disklabel.h P src/sys/arch/sh3/sh3/vm_machdep.c P src/sys/arch/sparc/dev/kbd_pckbport.c P src/sys/arch/sparc/fpu/fpu_sqrt.c P src/sys/arch/sparc64/dev/ebus_mainbus.c P src/sys/arch/vax/vax/bus_dma.c P src/sys/arch/x68k/x68k/bus.c P src/sys/arch/x86/include/intr.h P src/sys/arch/x86/pci/msipic.c P src/sys/arch/x86/pci/pci_machdep.c P src/sys/arch/x86/x86/fpu.c P src/sys/arch/xen/x86/pintr.c P src/sys/arch/xen/x86/xen_intr.c P src/sys/arch/xen/xen/evtchn.c P src/sys/arch/xen/xen/xen_acpi_machdep.c P src/sys/compat/netbsd32/netbsd32_module.c P src/sys/dev/fdt/fdt_port.h P src/sys/dev/hdaudio/hdafg.c P src/sys/dev/hpc/files.hpcapm P src/sys/dev/i2c/sgp40.c P src/sys/dev/i2c/sht4xreg.h P src/sys/dev/ic/mfi.c P src/sys/dev/ic/rtl8169.c P src/sys/dev/ic/smc91cxx.c P src/sys/dev/ic/wdc.c P src/sys/dev/ic/z8530reg.h P src/sys/dev/ir/irframe_tty.c P src/sys/dev/isa/gusreg.h P src/sys/dev/isapnp/files.isapnp P src/sys/dev/microcode/aic7xxx/aicasm.c P src/sys/dev/microcode/aic7xxx/aicasm_symbol.c P src/sys/dev/microcode/aic7xxx/aicasm_symbol.h P src/sys/dev/microcode/tools/array2bin.c P src/sys/dev/pci/if_ntwoc_pci.c P src/sys/dev/pci/if_sip.c P src/sys/dev/pci/qat/qat_c2xxx.c P src/sys/dev/usb/xhci.c P src/sys/fs/v7fs/v7fs.h P src/sys/kern/kern_event.c P src/sys/kern/subr_pool.c P src/sys/kern/sys_module.c P src/sys/net/if_llatbl.c P src/sys/net/lagg/if_laggproto.h P src/sys/netinet/ip_icmp.h P src/sys/netinet/sctp_indata.c P src/sys/netinet/sctp_pcb.c P src/sys/netinet/sctp_pcb.h P src/sys/netinet/tcp_input.c P src/sys/netipsec/ipsec_input.c P src/sys/netipsec/key.c P src/sys/nfs/nfs_vnops.c P src/sys/sys/disklabel_acorn.h P src/sys/ufs/ffs/ffs_subr.c P src/tests/bin/dd/t_dd.sh P src/tests/dev/audio/audiotest.c P src/tests/kernel/t_umount.sh P src/tests/kernel/t_zombie.c P src/tests/lib/libc/locale/t_digittoint.c P src/tests/lib/libc/locale/t_wctype.c P src/tests/lib/libc/sys/t_fork.c P src/tests/lib/libc/sys/t_ptrace.c P src/tests/lib/libc/sys/t_ptrace_wait.h P src/tests/rump/rumpkern/t_modlinkset.c P src/tests/usr.bin/printf/printf.sh P src/usr.bin/finger/util.c P src/usr.bin/m4/eval.c P src/usr.sbin/ac/ac.c P src/usr.sbin/acpitools/acpidump/acpi.c P src/usr.sbin/altq/libaltq/qop_hfsc.c P src/usr.sbin/mopd/mopcopy/mopcopy.c P src/usr.sbin/sysinst/partitions.h Updating xsrc tree: P xsrc/external/mit/xdm/dist/greeter/Login.c Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 42411544 May 25 03:08 ls-lRA.gz
Re: WDCTL_RST failed for drive 0 / wd0: IDENTIFY failed (SATA autodetection issue after installation)
I first saw this issue on a system trying to install and run 9.92, and adding the suggested AHCISATA_EXTRA_DELAY and disabling TPM seemed to fix it for me. But then I tried 9.99.96 and saw the same problems and the fixes had no effect. However I may have stumbled onto something that could be one of the causes, although I haven’t completely tested it yet. While trying to install 9.99.96 in a Virtual Machine (on Linux using KVM) I noticed that after installing to a qcow2 disk any attempt to boot the disk results in not being about to find the boot device. However, the boot log shows the disks were located and in the case of GPT partitioning all the wedges were found and identified correctly. Responding to the prompt for a boot device with “dk1” where the system was installed, allows the system to come up and run. This makes me suspect that there may be some timing issue with disk identification in the boot code - maybe there’s something not being detected and passed to the kernel correctly for successful boot? So far all I’ve tested is an installation with UEFI boot and GPT partitions. I don’t remember if I saw the problem on real hardware using a BIOS boot though and don’t know if I ever tried doing an installation with MBR instead of GPT. BTW, this (for me) could just be an issue with KVM on Linux and have nothing at all to do with NetBSD, but so far I haven’t seen anything similar with other installations I’ve done under KVM. At this point I’ve successfully installed and run 3 different Linux systems, FreeBSD, MSDOS, FreeDOS, Solaris and Windows 95, 98, XP and 10. The only one showing a problem so far has been 9.99.96 of NetBSD, and an 8.0 version of NetBSD installs and runs OK as well. Tried NetBSD 9.92 and it had problems, but don’t recall offhand what they were at the moment. -bob
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2022.05.24.15.51.10 bouyer src/sys/arch/xen/x86/pintr.c,v 1.23 2022.05.24.15.55.19 bouyer src/sys/arch/amd64/amd64/genassym.cf,v 1.86 2022.05.24.15.55.19 bouyer src/sys/arch/amd64/amd64/vector.S,v 1.78 2022.05.24.15.55.19 bouyer src/sys/arch/i386/i386/genassym.cf,v 1.123 2022.05.24.15.55.19 bouyer src/sys/arch/i386/i386/vector.S,v 1.88 2022.05.24.15.55.19 bouyer src/sys/arch/x86/include/intr.h,v 1.65 2022.05.24.15.55.19 bouyer src/sys/arch/xen/xen/evtchn.c,v 1.98 2022.05.24.16.01.25 bouyer src/sys/arch/amd64/conf/XEN3_DOM0,v 1.195 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2022.05.html#2022.05.24.16.01.25
Re: WDCTL_RST failed for drive 0 / wd0: IDENTIFY failed (SATA autodetection issue after installation)
Hi Rin, thank you for your quick response. I can first confirm that the controller installed in the system is ahcisata(4). I have two different model variants where the problem occurs - on one very reliably at every boot, and on the other almost after every cold start (and only two of four disks affected on the latter). I will build and test the kernel with AHCISATA_EXTRA_DELAY and give feedback in a timely manner. Many greetings Matthias Am 24.05.2022 um 18:23 schrieb Rin Okuyama: Hi, The recent change for probe timing should only affect ahcisata(4). Is your SATA controller ahcisata(4)? If so, (1) please try kernel built with: --- options AHCISATA_EXTRA_DELAY --- If it works around the problem, (2) please send us full dmesg of your machine. Then, we can add your controller to the quirk list. At once it is registered to the list, AHCISATA_EXTRA_DELAY option is no longer required. Thanks, rin On 2022/05/25 0:49, Matthias Petermann wrote: A small addendum: disabling the Intel Platform Trust technology in the BIOS did not help me (had read this in another post of the linked thread). However, by plugging in additional USB devices (a mouse) I apparently caused the necessary delay, which the disk would have needed in the first case to execute the WDCTL_RST without errors. This "workaround" is a shaky one though, an extremely close call. I don't even want to think about what I would do to a production server if this happened to me on a reboot. Kind regards Matthias Am 24.05.2022 um 17:31 schrieb Matthias Petermann: Hello all, with one of the newer builds of 9.99 (unfortunately I can't narrow it down more) I have a problem on a NUC5 with a Seagate Firecuda SATA hard drive (hybrid HDD/SSD). As long as I boot from the USB stick (for installation, as well as later for booting the kernel with root redirected to the wd0) the hard drive wd0 is recognized correctly and works without problems. When I boot directly from the wd0 hard drive, I get through the boot loader fine, which also still loads the kernel correctly into memory. However, when running the initialization or hardware detection, there is then a problem with the initialization of wd0: ``` WDCTL_RST failed for drive 0 wd0: IDENTIFY failed ``` The error pattern seems to be not quite rare and probably the closest to it is this post: http://mail-index.netbsd.org/current-users/2022/03/01/msg042073.html Recent changes to the SATA autodetection timing are mentioned there. This would fit my experience, since I had the problem neither with 9.1 (build from 02/16/2021) nor with older 9.99 versions. Does anyone know more specifics about this timing thing, as well as known workarounds if there are any? I have several NUC5s with exactly this model of hard drive running stably for several years - it would be a shame if I now have to replace them for such a reason. Many greetings Matthias
Re: WDCTL_RST failed for drive 0 / wd0: IDENTIFY failed (SATA autodetection issue after installation)
Hi, The recent change for probe timing should only affect ahcisata(4). Is your SATA controller ahcisata(4)? If so, (1) please try kernel built with: --- options AHCISATA_EXTRA_DELAY --- If it works around the problem, (2) please send us full dmesg of your machine. Then, we can add your controller to the quirk list. At once it is registered to the list, AHCISATA_EXTRA_DELAY option is no longer required. Thanks, rin On 2022/05/25 0:49, Matthias Petermann wrote: A small addendum: disabling the Intel Platform Trust technology in the BIOS did not help me (had read this in another post of the linked thread). However, by plugging in additional USB devices (a mouse) I apparently caused the necessary delay, which the disk would have needed in the first case to execute the WDCTL_RST without errors. This "workaround" is a shaky one though, an extremely close call. I don't even want to think about what I would do to a production server if this happened to me on a reboot. Kind regards Matthias Am 24.05.2022 um 17:31 schrieb Matthias Petermann: Hello all, with one of the newer builds of 9.99 (unfortunately I can't narrow it down more) I have a problem on a NUC5 with a Seagate Firecuda SATA hard drive (hybrid HDD/SSD). As long as I boot from the USB stick (for installation, as well as later for booting the kernel with root redirected to the wd0) the hard drive wd0 is recognized correctly and works without problems. When I boot directly from the wd0 hard drive, I get through the boot loader fine, which also still loads the kernel correctly into memory. However, when running the initialization or hardware detection, there is then a problem with the initialization of wd0: ``` WDCTL_RST failed for drive 0 wd0: IDENTIFY failed ``` The error pattern seems to be not quite rare and probably the closest to it is this post: http://mail-index.netbsd.org/current-users/2022/03/01/msg042073.html Recent changes to the SATA autodetection timing are mentioned there. This would fit my experience, since I had the problem neither with 9.1 (build from 02/16/2021) nor with older 9.99 versions. Does anyone know more specifics about this timing thing, as well as known workarounds if there are any? I have several NUC5s with exactly this model of hard drive running stably for several years - it would be a shame if I now have to replace them for such a reason. Many greetings Matthias
Re: WDCTL_RST failed for drive 0 / wd0: IDENTIFY failed (SATA autodetection issue after installation)
A small addendum: disabling the Intel Platform Trust technology in the BIOS did not help me (had read this in another post of the linked thread). However, by plugging in additional USB devices (a mouse) I apparently caused the necessary delay, which the disk would have needed in the first case to execute the WDCTL_RST without errors. This "workaround" is a shaky one though, an extremely close call. I don't even want to think about what I would do to a production server if this happened to me on a reboot. Kind regards Matthias Am 24.05.2022 um 17:31 schrieb Matthias Petermann: Hello all, with one of the newer builds of 9.99 (unfortunately I can't narrow it down more) I have a problem on a NUC5 with a Seagate Firecuda SATA hard drive (hybrid HDD/SSD). As long as I boot from the USB stick (for installation, as well as later for booting the kernel with root redirected to the wd0) the hard drive wd0 is recognized correctly and works without problems. When I boot directly from the wd0 hard drive, I get through the boot loader fine, which also still loads the kernel correctly into memory. However, when running the initialization or hardware detection, there is then a problem with the initialization of wd0: ``` WDCTL_RST failed for drive 0 wd0: IDENTIFY failed ``` The error pattern seems to be not quite rare and probably the closest to it is this post: http://mail-index.netbsd.org/current-users/2022/03/01/msg042073.html Recent changes to the SATA autodetection timing are mentioned there. This would fit my experience, since I had the problem neither with 9.1 (build from 02/16/2021) nor with older 9.99 versions. Does anyone know more specifics about this timing thing, as well as known workarounds if there are any? I have several NUC5s with exactly this model of hard drive running stably for several years - it would be a shame if I now have to replace them for such a reason. Many greetings Matthias
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2022.05.24.14.11.15.
An extract from the build.sh output follows:
--- kern-LEGACY ---
#create LEGACY/sysmon.d
CC=/tmp/build/2022.05.24.14.11.15-i386/tools/bin/i486--netbsdelf-gcc
/tmp/build/2022.05.24.14.11.15-i386/tools/bin/nbmkdep -f sysmon.d.tmp --
-msoft-float -mno-mmx -mno-sse -mno-avx -mindirect-branch=thunk
-mindirect-branch-register -ffreestanding -fno-zero-initialized-in-bss
-fno-delete-null-pointer-checks -O2 -fno-omit-frame-pointer -fstack-protector
-Wstack-protector --param ssp-buffer-size=1 -fstack-usage
-Wstack-usage=3584 -fno-strict-aliasing -fno-common -std=gnu99 -Werror
-Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes
-Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual
-Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes -Wextra
-Wno-unused-parameter -Wold-style-definition -Wno-sign-compare -Walloca
-Wno-address-of-packed-member
--sysroot=/tmp/build/2022.05.24.14.11.15-i386/destdir -Di386 -I.
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/mit/xen-include-public/dist/
-I/t
mp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/libnv/dist
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/acpica/dist
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/../common/lib/libx86emu
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/../common/lib/libc/misc
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/../common/include
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/arch
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys -nostdinc -DCOMPAT_UTILS
-D__XEN_INTERFACE_VERSION__="0x3020a" -DDIAGNOSTIC -DCOMPAT_44 -D_KERNEL
-D_KERNEL_OPT -std=gnu99
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/lib/libkern/../../../common/lib/libc/quad
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/lib/libkern/../../../common/lib/libc/string
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/string
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/lib/libkern/../../../common/lib/libc/arch/i386/atomic
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/lib/libk
ern/../../../common/lib/libc/hash/sha3 -D_FORTIFY_SOURCE=2
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/isc/atheros_hal/dist
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/isc/atheros_hal/ic
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/drm2/include
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/drm2/include/drm
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/common/include
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/drm2/dist/include
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/drm2/dist/include/drm
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/drm2/dist/include/uapi
-D__KERNEL__ -DCONFIG_X86 -DCONFIG_X86_PAT -DCONFIG_BACKLIGHT_CLASS_DEVICE=0
-DCONFIG_BACKLIGHT_CLASS_DEVICE_MODULE=0 -DCONFIG_DRM_FBDEV_EMULATION=1
-DCONFIG_DRM_FBDEV_OVERALLOC=100 -DCONFIG_FB=0 -DCONFIG_LOCKDEP=0
-DCONFIG_PCI=1 -I/tmp/build/2022.05.24.14.11.15-i386/src/sys/../common/include
-I/tmp/build/2022.05.24.14.11.
15-i386/src/sys/external/bsd/acpica/dist/include
-I/tmp/build/2022.05.24.14.11.15-i386/src/sys/external/bsd/libnv/dist
/tmp/build/2022.05.24.14.11.15-i386/src/sys/dev/sysmon/sysmon.c
--- kern-XEN3PAE_DOM0 ---
/tmp/build/2022.05.24.14.11.15-i386/src/sys/arch/xen/x86/pintr.c: In
function 'xen_map_msix_pirq':
/tmp/build/2022.05.24.14.11.15-i386/src/sys/arch/xen/x86/pintr.c:239:78:
error: format '%lx' expects argument of type 'long unsigned int', but argument
7 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=]
239 | aprint_debug("xen_map_msix_pirq bus %d devfn 0x%x (%d %d) count %d
base 0x%lx",
|
~~^
|
|
|
long unsigned int
|
%llx
The following commits were made between the last successful build and
the failed build:
2022.05.24.14.00.23 bouyer src/sys/arch/x86/pci/msipic.c,v 1.27
2022.05.24.14.00.23 bouyer src/sys/arch/x86/pci/pci_machdep.c,v 1.91
2022.05.24.14.00.23 bouyer src/sys/arch/xen/x86/pintr.c,v 1.22
2022.05.24.14.00.23 bouyer src/sys/arch/xen/x86/xen_intr.c,v 1.30
2022.05.24.14.11.15 fcambus src/doc/3RDPARTY,v 1.1859
Logs can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2022.05.html#2022.05.24.14.11.15
WDCTL_RST failed for drive 0 / wd0: IDENTIFY failed (SATA autodetection issue after installation)
Hello all, with one of the newer builds of 9.99 (unfortunately I can't narrow it down more) I have a problem on a NUC5 with a Seagate Firecuda SATA hard drive (hybrid HDD/SSD). As long as I boot from the USB stick (for installation, as well as later for booting the kernel with root redirected to the wd0) the hard drive wd0 is recognized correctly and works without problems. When I boot directly from the wd0 hard drive, I get through the boot loader fine, which also still loads the kernel correctly into memory. However, when running the initialization or hardware detection, there is then a problem with the initialization of wd0: ``` WDCTL_RST failed for drive 0 wd0: IDENTIFY failed ``` The error pattern seems to be not quite rare and probably the closest to it is this post: http://mail-index.netbsd.org/current-users/2022/03/01/msg042073.html Recent changes to the SATA autodetection timing are mentioned there. This would fit my experience, since I had the problem neither with 9.1 (build from 02/16/2021) nor with older 9.99 versions. Does anyone know more specifics about this timing thing, as well as known workarounds if there are any? I have several NUC5s with exactly this model of hard drive running stably for several years - it would be a shame if I now have to replace them for such a reason. Many greetings Matthias
Re: File system corruption due to UFS2 extended attributes
Chuck Silvers writes: > The introduction in NetBSD's implementation of UFS2 of the extended > attribute code from FreeBSD has introduced a compatibility problem > with previous releases of NetBSD. The explanation of this problem is > a bit involved and requires knowing some history, so please bear with me > as I explain. Your analysis and approach make sense to me, even though it's regrettable that it is necessary. I guess UFS needs zfs-style feature flags What about compatibility with FreeBSD? - What happens if someone takes a FreeBSD UFS2 filesystem and mounts it under NetBDS 9? - What happens if someone tries to mount a NetBSD <=9 UFS2 filesystem on FreeBSD? A 10 UFS2 filesystem w/o ea? with? Or is it already the case that FreeBSD and NetBSD do not interoperate with UFS2? And same questions for the other active BSD variants, which I think is mostly OpenBSD and Dragonfly these days but I have lost track. signature.asc Description: PGP signature
Fun amd64 panic
Here's one if anyone wants to try this on a physically local machine. amd64, current from today, a simple "atf-run": [ 119.516347] uhub8: at uhub1 port 6 (addr 1) disconnected [21.00] cpu10 at mainbus0 apid 9 [ 1.03] cpu10: AMD784.0900672] cpu0: Begin traceback... [ 21784.090067] vpanic() at netbsd:vpanic+0x183 [ 21784.090067] panic() at netbsd:panic+0x3c [ 21784.090067] bus_dmamap_sync() at netbsd:bus_dmamap_synG with Radeon Graphics , id 0xa50f00 [ 1.03] cpu1 21784.0900672] rge_intr() at netbsd:rge_intr+0x16f [ 21784.90] acpi0: X/RSDT: OemId [ 21784.0900672] Xhandle_ioapic_edge16() at netbsd:Xhandle_ioapi acpi0: autoconfiguration error: invalid PCI address for D003 x86_stihlt() at netbsd:x86_stihlt+0x6 [ 21784.090067] acpicpu for D006 [ 1.03] acpi0: MCFG: segment 0, bus 0-127, addr72] idle_loop() at netbsd:idle_loop+0x14c [ 21784.090067] cpu0: int 9 [ 1.03] acpi0: fixed power button present [ 1.00] dump [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, ...
