i386 boot hangs: "init: can't open /dev/console: Device not configured"
Hi, mlarkin@ said someone needed to verify my i386/lapic.c changes on real hardware: https://marc.info/?l=openbsd-tech=166186787532304=2 So, like a chucklehead, I thought "how hard could it be?" and tried installing OpenBSD/i386 to an external drive and booting my amd64 laptop (Lenovo X1 Carbon 6th) from it. The install -- booted from a USB-attached CD-ROM, installed to a USB-3 external drive -- went fine. When I tried to boot after installation, however, I hit a snag. init(8) hung the boot. It kept printing: init: can't open /dev/console: Device not configured init: can't open /dev/console: Device not configured init: can't open /dev/console: Device not configured every fifteen or so seconds. Keyboard was unresponsive. A little searching led me to this reddit post from a few years ago: https://reddit.com/r/openbsd/comments/8zganh/new_amd64_install_says_cant_open_devconsole/ A commenter on that post suggests that disabling 'inteldrm' and/or 'radeondrm' during boot from config(8) might do the trick. It worked. With those drivers disabled, init(8) doesn't trip over /dev/console and the machine finishes booting, is stable, etc. Obviously I don't have accelerated graphics, but the machine is otherwise perfectly usable from the console and vterms. I have never seen this issue booting OpenBSD/amd64 on this (or any other) machine before. I have attached both the amd64 dmesg and the i386 dmesg below. Same machine, no changes to the BIOS between reboots. They are booting from different disks: amd64 boots from the internal NVMe drive, i386 boots from an external LaCiE drive over USB. The issue persists on the i386 side even after installing all missing firmware. OpenBSD 7.2-beta (GENERIC.MP) #0: Tue Aug 30 20:15:55 CDT 2022 s...@jetsam.attlocal.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17018175488 (16229MB) avail mem = 16354238464 (15596MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaa62d000 (63 entries) bios0: vendor LENOVO version "N23ET82W (1.57 )" date 07/21/2022 bios0: LENOVO 20KHCTO1WW acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT BATB SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM DMAR NHLT ASF! FPDT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0a cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0a cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz, 1795.82 MHz, 06-8e-0a cpu2:
Re: OpenBSD 7.1/amd64 on APU4D4 - system drops into ddb few times a week
Hello,
after 2 days uptime there was another crash.
OpenBSD 7.2-beta (GENERIC.MP) #712: Mon Aug 29 12:35:51 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
ddb{2}> show panic
*cpu2: uvm_fault(0x823e0440, 0x0, 0, 2) -> e
ddb{2}> trace
amdgpu_vram_mgr_reserve_range(8000226d3738,14,9) at amdgpu_vram_mgr_reserve
_range+0x101
esp46_input(8000226d3738,8000226d3744,32,2) at esp46_input+0xee
ip_deliver(8000226d3738,8000226d3744,32,2) at ip_deliver+0x137
ipintr() at ipintr+0x69
if_netisr(0) at if_netisr+0xea
taskq_thread(8002c080) at taskq_thread+0x100
end trace frame: 0x0, count: -6
ddb{2}> show register
rdi 0x80cf4478
rsi0
rbp 0x8000226d3630
rbx 0x4
rdx 0xd0ec__ALIGN_SIZE+0xc0ec
rcx 0x5
rax0
r8 0x10
r90x40bc0e0c79f31f6e
r100
r11 0x9a636d5cd973370a
r12 0x32
r13 0x14
r14 0x8000226d3738
r15 0x80cf4448
rip 0x81968321amdgpu_vram_mgr_reserve_range+0x101
cs 0x8
rflags 0x10246__ALIGN_SIZE+0xf246
rsp 0x8000226d3598
ss 0x10
amdgpu_vram_mgr_reserve_range+0x101:addb%al,0(%rax)
ddb{2}> ps
PID TID PPIDUID S FLAGS WAIT COMMAND
86171 333411 63955 74 3 0x1100092 bpf pflogd
63955 461469 1 0 30x80 netio pflogd
44926 303198 1 0 30x100083 ttyin getty
91823 366301 1 0 30x100098 kqreadcron
56167 242659 1 0 30x80 nanoslp apcupsd
56167 147809 1 0 3 0x488 sigwait apcupsd
56167 171020 1 0 3 0x480 nanoslp apcupsd
47439 46683 1 99 3 0x1100090 kqreadsndiod
51482 395614 1110 30x100090 kqreadsndiod
5163 480478 99386 95 3 0x1100092 kqreadsmtpd
76226 349104 99386103 3 0x1100092 kqreadsmtpd
53394 15461 99386 95 3 0x1100092 kqreadsmtpd
7344 376375 99386 95 30x100092 kqreadsmtpd
63235 309137 99386 95 3 0x1100092 kqreadsmtpd
48160 64945 99386 95 3 0x1100092 kqreadsmtpd
99386 38247 1 0 30x100080 kqreadsmtpd
41420 333984 1 77 3 0x1100090 kqreaddhcpd
17481 420686 1 0 30x88 kqreadsshd
18611 160721 77165 68 3 0x190 kqreadisakmpd
77165 391744 1 0 30x80 netio isakmpd
79254 85499 1 0 30x100080 kqreadntpd
10257 99703 79620 83 30x100092 kqreadntpd
79620 463938 1 83 3 0x1100092 kqreadntpd
91894 184130 24465 73 3 0x1100090 kqreadsyslogd
24465 244414 1 0 30x100082 netio syslogd
62105 141098 1 0 30x100080 kqreadresolvd
19257 376757 61629 77 30x100092 kqreaddhcpleased
76652 204506 61629 77 30x100092 kqreaddhcpleased
61629 486499 1 0 30x80 kqreaddhcpleased
90626 362267 9115 30x100092 kqreadslaacd
93187 97889 9115 30x100092 kqreadslaacd
9 477868 1 0 30x100080 kqreadslaacd
11780 22955 0 0 3 0x14200 bored smr
98305 221595 0 0 3 0x14200 pgzerozerothread
96593 391889 0 0 3 0x14200 aiodoned aiodoned
30232 412444 0 0 3 0x14200 syncerupdate
45741 353942 0 0 3 0x14200 cleaner cleaner
39902 310884 0 0 3 0x14200 reaperreaper
65354 212624 0 0 3 0x14200 pgdaemon pagedaemon
33348 495407 0 0 3 0x14200 mmctsksdmmc0
74730 412089 0 0 3 0x14200 usbtskusbtask
86868 405536 0 0 3 0x14200 usbatsk usbatsk
20735 139086 0 0 3 0x40014200 acpi0 acpi0
6266 77841 0 0 3 0x40014200idle3
61610 247494 0 0 3 0x40014200idle2
55796 232481 0 0 7 0x40014200idle1
91772 351464 0 0 3 0x14200 bored sensors
89632 25 0 0 3 0x14200 bored softnet
4662 418517 0 0 3 0x14200 bored softnet
22887 421630 0 0 7 0x14200softnet
*56210 145960 0 0 7 0x14200
Re: macppc panic: vref used where vget required
On 29/07/22(Fri) 14:22, Theo Buehler wrote:
> On Mon, Jul 11, 2022 at 01:05:19PM +0200, Martin Pieuchot wrote:
> > On 11/07/22(Mon) 07:50, Theo Buehler wrote:
> > > On Fri, Jun 03, 2022 at 03:02:36PM +0200, Theo Buehler wrote:
> > > > > Please do note that this change can introduce/expose other issues.
> > > >
> > > > It seems that this diff causes occasional hangs when building snapshots
> > > > on my mac M1 mini. This happened twice in 10 builds, both times in
> > > > xenocara. Unfortunately, both times the machine became entirely
> > > > unresponsive and as I don't have serial console, that's all the info I
> > > > have...
> > > >
> > > > This machine has been very reliable and built >50 snaps without any hang
> > > > over the last 2.5 months. I'm now trying snap builds in a loop without
> > > > the diff to make sure the machine doesn't hang due to another recent
> > > > kernel change.
> > > >
> > >
> > > A little bit of info on this. The first three lines were a bit garbled on
> > > the screen:
> > >
> > > panic: kernel diagnostic assertion "uvn->_oppa jai c: ke r
> > > el d iag no tic a s rt n " map ==UL L | | rw wr
> > > k
> > > ite held(amap->amap_lock)" failed: file "/ss/uvm/uvm_fault.c", line 846.
> > > ernel diagnostic assertion "!_kernel_lock_held
> > > Stopped at panic+0160: cmp w21, #0x0 ailed: file "/sys/kern/
> > > TIDPID UID PRFLAGS PFLAGS CPU COMMAND
> > > 411910 44540 210x11 0 3 make
> > > *436444 84241 210x13 0 6 sh
> > > 227952 53498 210x13 0 5 sh
> > > 258925 15765 210x101005 0 0 make
> > > 128459 9649 210x13 0 1 tradcpp
> > > 287213 64216 210x130x8 7 make
> > > 173587 461710000x10 0 2 tmux
> > > 126511 69919 0 0x14000 0x200 4 softnet
> > > db_enter() at panic+0x15c
> > > panic() at __assert+0x24
> > > uvm_fault() at uvm_fault_upper_lookup+0x258
> > > uvm_fault_upper() at uvm_fault+0xec
> > > uvm_fault() at udata_abort+0x128
> > > udata_abort() at do_el0_sync+0xdc
> > > do_el0_sync() at handle_el0_sync+0x74
> > > https://www.openbsd.org/ddb.html describes the minimum info required in
> > > bug
> > > reports. Insufficient info makes it difficult to find and fix bugs.
> > > ddb{6}> show panic
> > > *cpu0: kernel diagnostic assertion "uvn->u_obj.uo_refs == 0" failed: file
> > > "/sys/kern/uvn_vnode.c", line 231.
> > > cpu6: kernel diagnostic assertion "amap == NULL ||
> > > rw_write_held(amap->am_lock)" failed: file "/sys/uvm/uvm_fault", line
> > > 846.
> > > cpu3: kernel diagnostic assertion "!_kernel_lock_held()" failed: file
> > > "/sys/kern/kern_fork.c", line 678
> > > ddb{6}> mach ddbcpu 0
> > >
> > > After pressing enter here, the machine locked up completely.
> >
> > It's hard for me to tell what's going on. I believe the interesting
> > trace is the one from cpu0 that we don't have. Can you easily reproduce
> > this? I'm trying on amd64 without luck. I'd glad if you could gather
> > more infos.
>
> Sorry for the delay. I was only at home intermittently. I hit this three
> times:
>
> panic: kernel diagnostic assertion "uvn->u_obj.uo_refs == 0" failed: file
> "/sys/uvm/uvm_vnode.c", line 231
Yesterday gnezdo@ fixed a race in uvn_attach() that lead to the same
assert. Here's an rebased diff for the bug discussed in this thread,
could you try again and let us know? Thanks!
Index: uvm/uvm_vnode.c
===
RCS file: /cvs/src/sys/uvm/uvm_vnode.c,v
retrieving revision 1.127
diff -u -p -r1.127 uvm_vnode.c
--- uvm/uvm_vnode.c 31 Aug 2022 09:07:35 - 1.127
+++ uvm/uvm_vnode.c 1 Sep 2022 12:54:27 -
@@ -163,11 +163,8 @@ uvn_attach(struct vnode *vp, vm_prot_t a
*/
rw_enter(uvn->u_obj.vmobjlock, RW_WRITE);
if (uvn->u_flags & UVM_VNODE_VALID) { /* already active? */
+ KASSERT(uvn->u_obj.uo_refs > 0);
- /* regain vref if we were persisting */
- if (uvn->u_obj.uo_refs == 0) {
- vref(vp);
- }
uvn->u_obj.uo_refs++; /* bump uvn ref! */
rw_exit(uvn->u_obj.vmobjlock);
@@ -235,7 +232,7 @@ uvn_attach(struct vnode *vp, vm_prot_t a
KASSERT(uvn->u_obj.uo_refs == 0);
uvn->u_obj.uo_refs++;
oldflags = uvn->u_flags;
- uvn->u_flags = UVM_VNODE_VALID|UVM_VNODE_CANPERSIST;
+ uvn->u_flags = UVM_VNODE_VALID;
uvn->u_nio = 0;
uvn->u_size = used_vnode_size;
@@ -248,7 +245,7 @@ uvn_attach(struct vnode *vp, vm_prot_t a
/*
* add a reference to the vnode. this reference will stay as long
* as there is a valid mapping of the vnode. dropped when the
-* reference count goes to zero [and we
