kern/55774: Kernel panics if another PC is powered on with serial cable attached between two

[vezhlys%gmail.com@localhost]

>Number:         55774
>Category:       kern
>Synopsis:       Kernel panics if another PC is powered on with serial cable attached between two
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 01 23:45:00 +0000 2020
>Originator:     Andrius V
>Release:        9.99.74
>Organization:
>Environment:
NetBSD  9.99.74 NetBSD 9.99.74 (GENERIC_VEX2) #4: Sat Oct 31 21:10:35 EET 2020  andriusv@jarossd:/home/andriusv/workspace/netbsd-obj/sys/arch/i386/compile/GENERIC_VEX2 i386
>Description:
I noticed that my system's kernel always panics if NetBSD is booted using serial console (consdev com0; boot) and I boot another PC with serial cable attached between two. The simple steps to reproduce:
1) Boot NetBSD with serial console with another PC attached to it using serial cable. Confirm that it booted successfully.
2) (Optionally) disconnect from serial terminal (minicom or cu) and turn off this PC.
3) Boot it again (at this point kernel crashes almost immediately, while PC is still in BIOS setup).
4) Once OS is loaded, connect to NetBSD using serial, ddb will presented.

I reproduced the same issue between any of my computers, both i386 or amd64, including default kernel. Another PC's OS doesn't matter. Haven't tried with USB serial though, all COM ports were provided by the motherboard.

bt from i386:
breakpoint(c1421620,3f8,5,6,10000,c2d291f4,c2d2916c,c2b3e000,800,c646a686) at netbsd:breakpoint+0x4
comintr(c2d29040,db48c870,0,0,0,0,0,0,0,0) at netbsd:comintr+0x8c3
--- switch to interrupt stack ---
Xintr_legacy4() at netbsd:Xintr_legacy4+0xda
--- interrupt ---
pool_cache_get_paddr(c14c2680,2,0,db48c920,c0c097c7,c41db210,db48c944,cbf78c6,c420f4c0,5e7000) at netbsd:pool_cache_get_paddr+0xbd
uvm_analloc(c420f4c0,5e7000,1,c0bf1ffa,db48c9e4,c29d6a20,4,3,0,0) at netbsd:uvm_analloc+0x22
uvmfault_promote(db48c99c,db48c9d4,db48c9e4,1,169,c1101e80,0,80000001,c2ef6a00,10) at netbsd:uvmfault_promote+0x21c
uvm_fault_internal(c2de7ef8,5e7000,2,0,c2ea4200,2,5e7000,c2de7ef8,c2de7ef8,5e7000) at netbsd:uvm_fault_internal+0x13a3
trap() at netbsd:trap+0x654
--- trap (number 6) ---
copyout(c2de7ef8,dabff000,5e7000,2e8,c2ef76,db48ccac,c2de7ef8,2e8,8000,0) at netbsd:copyout+0x32
uiomove(dabff000,2e8,db48ccb4,db48cc0c,db48cc04,100,0,0,dabff000,2) at netbsd:uiomove+0x82
ubc_uiomove(c2ef6e00,db48ccb4,2e8,0,109,db48cc78,10,0,0,c2ef6e00) at netbsd:ubc_uiomove+0x123
ffs_read(db48cc78,201,0,c110199c,c2ef6e00,db48ccb4,10,c4196100,10,db48ccdc) at netbsd:ffs_read+0x12d
VOP_READ(c2ef6e00,db48ccb4,10,c4196100,0,5e7000,2e8,db48ccac,1,8000) at netbsd:VOP_READ+0x43
vn_rdwr(0,c2ef6e00,5e7000,2e8,8000,0,0,10,c4196100,0) at netbsd:vn_rdwr+0xd6
vmcmd_readvn(c32d7980,c3cbc2b8,db48cdbc,1,db48cd8c,0,db48cdbc,db48cda0,c32c7c40,
c32d7980) at netbsd:vmcmd_readvn+0x6b
execve_runproc(0,aba60754,aba60804,c0c39140,db48cdbc,c2ea2428,c2e9a424,ffffffff,
c2ea03c0,404) at netbsd:execve_runproc+0x380
execve1(c32d7980,1,aba60964,ffffffff,aba60754,aba60804,c0c39140,db48cf9c,c047a3ec,c32d7980) at netbsd:execve1+0x61
sys_execve(c32d7980,db48cf68,db48cf60,c0473d5b,c41db20c,3b,db48cf60,db48cf68,0,0) at netbsd:sys_execve+0x40
syscall() at netbsd:syscall+0x20c
--- syscall (number 59) ---
abab4607:

Regards,
Andrius V
>How-To-Repeat:

>Fix: