On Wed, Nov 17, 2021 at 02:25:44PM +0000, Taylor R Campbell wrote: > - Try suspending and resuming different subtrees of devices: > drvctl -S foo0 && drvctl -Q foo0
I found three problems: 1) drvctl -S com0; drvctl -Q com0 causes the serial console to become irresponsive. The device tree's branch in mainbus0/acpi0/com0 Once that is reached, I managed to get a panic by trying drvctl -Q wskbd0 vrelel: missing VOP_CLOSE(): vnode 0xffffb5d716fa1d80 flags 0x14<ISTTY,MPSAFE> tag VT_NON(0) type VCHR(4) mount 0xffffb5d874e9b000 typedata 0xffffb5d7186749c0 usecount 1 writecount 0 holdcount 0 size 0 writesize 0 numoutput 0 data 0x0 lock 0xffffb5d716fa1f40 state LOADED key(0xffffb5d874e9b000 0) lrulisthd 0xffffffff818adf10 panic: kernel diagnostic assertion "sn->sn_opencnt == 0" failed: file "/usr/src/sys/miscfs/specfs/spec_vnops.c", line 437 cpu1: Begin traceback... vpanic() at netbsd:vpanic+0x156 __x86_indirect_thunk_rax() at netbsd:__x86_indirect_thunk_rax spec_node_destroy() at netbsd:spec_node_destroy+0x1f2 vcache_free() at netbsd:vcache_free+0xea vrelel() at netbsd:vrelel+0x531 cnclose() at netbsd:cnclose+0x8e cdev_close() at netbsd:cdev_close+0x80 spec_close() at netbsd:spec_close+0x163 VOP_CLOSE() at netbsd:VOP_CLOSE+0x42 vn_close() at netbsd:vn_close+0x35 closef() at netbsd:closef+0x60 fd_free() at netbsd:fd_free+0x10b exit1() at netbsd:exit1+0x126 sys_exit() at netbsd:sys_exit+0x39 syscall() at netbsd:syscall+0x196 --- syscall (number 1) --- netbsd:syscall+0x196: cpu1: End traceback... 2) drvctl -S xhci0; drvctl -Q xhci0 causes the keyboard to get inresponsive. The device tree's branch is mainbus0/pci0/xhci0/usb1/uhub1/uhidev0/ukbd0/wskbd1 The keyboard is recovered by drvctl -d uhidev0; drvctl -a usbdevif -r uhub1 3) Nothing seems able to act on the screen, it always remain powered on when playing with drvctl -S. sysctl hw.acpi.sleep.state=3 powers it doen, thought. I am not sure what should work here. dmesg says: acpivga0: connected output devices: acpivga0: 0x0400 (acpiout15): Unknown Output Device, head 0 What is supposed to power down the screen? Is it mainbus0/acpi0/acipvga0/acpiout15 or mainbus0/pci0/genfb0/wsdisplay0 There is also a sysctl hw.acpi.acpiout15.brightness that has no effect. And for the ihidev problem, it seems it fails to configure properly: ihidev0 at iic0 addr 0x19ihidev0: autoconfiguration error: failed to get HidDescriptorAddress: AE_NOT_FOUND ihidev0: WARNING: power management not supported ihidev1 at iic2 addr 0x5ddwiic2: timed out reading remaining 29 ihidev1: WARNING: power management not supported -- Emmanuel Dreyfus m...@netbsd.org
