Date: Tue, 24 Dec 2024 04:55:56 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko Message-ID: <bug-267028-3630-9dSRN1gXsJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-267028-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-267028-3630@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=3D267028 --- Comment #288 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Mark Millard from comment #260) (In reply to satanist+freebsd from comment #259) I was mistaken about: mod =3D malloc(sizeof(struct modlist), M_LINKER, M_NOWAIT | M_ZERO); if (mod =3D=3D NULL) panic("no memory for module list"); mod->container =3D container; mod->name =3D modname; mod->version =3D version; TAILQ_INSERT_TAIL(&found_modules, mod, link); return (mod); if something similar to mod =3D=3D 0xfffff80000000007 resulted: It appears that an assignment to the likes of mod->container might well be allowed without a general protection trap at the time. The actual fault is from the likes of the strcmp being given name =3D=3D 0xe987f000fea5f0 in: {link =3D {tqe_next =3D 0xeef3f000e2c3f0, tqe_prev =3D 0xff54f000eef3f0}, c= ontainer =3D 0x322ff0003287f0, name =3D 0xe987f000fea5f0 <error: Cannot access memory at address 0xe987f000fea5f0>,=20 version =3D 15660016} from having dereferenced 0xfffff80000000007. However: mod->container =3D container; // 0x322ff0003287f0 mod->name =3D modname; // 0xe987f000fea5f0 mod->version =3D version; // 0xEEF3F0 does not seem likely for what that code would be assigning. So it still appears that the mod value from this code is later replaced with the junk 0xfffff80000000007 . --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-267028-3630-9dSRN1gXsJ>