Date: Tue, 12 Apr 2022 22:57:43 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 262894] Kernel Panic (page fault) with 13.1-BETA2 in g_eli & httpd Message-ID: <bug-262894-227-PXYaUKgKNS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262894-227@https.bugs.freebsd.org/bugzilla/> References: <bug-262894-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262894 --- Comment #21 from Mark Johnston <markj@FreeBSD.org> --- (In reply to Krautmaster from comment #20) Did this most recent crash happen with the patch from comment 5 applied? (In reply to Krautmaster from comment #19) You could simply run "dumpon /dev/<dump device name>" to configure it once.= =20 Use "dumpon -l" to verify that it reports the right device. Also you shoul= dn't configure a pool on the disk, just pass the raw disk device to dumpon. If you're willing to give me remote access, please mail me. Finally, I think your kernel does not have debugging assertions enabled. I= f it is possible to get a stock kernel build with "options INVARIANTS" enabled, please try testing it. The fault address should correspond to the buffer returned by aesni_cipher_alloc(). I'd guess that it's returned by crypto_contiguous_subsegment() and there's some kind of overflow condition occurring with the page array offset or length, but I can't see where. The= re is some fishy code, e.g., in g_disk_advance(): bp->bio_ma_offset +=3D off; bp->bio_ma_offset %=3D PAGE_SIZE; but this is only a problem for large (> 2GB) offsets, which shouldn't happe= n... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262894-227-PXYaUKgKNS>