Date: Thu, 18 Jun 2020 09:23:17 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD Message-ID: <bug-204521-227-4voBm1v9SB@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-204521-227@https.bugs.freebsd.org/bugzilla/> References: <bug-204521-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=3D204521 --- Comment #231 from Gary Jennejohn <gljennjohn@gmail.com> --- (In reply to unitrunker from comment #228) This is pretty weird. Looking at my kernel. which has the same address for mmc_go_discovery() as your kernel, the panic is happening in a call to mems= et() in the first call to mmc_send_app_op_cond(). Apparently the compiler has optimized mmc_go_discovery() by inlining mmc_send_app_op_cond(), since that function is only used in mc_go_discovery= ().=20 This conclusion is supported by the fact that there is no entry for mmc_send_app_op_cond in the ELF header. The really strange thing is that memset() is being called to zero out a str= uct mmc_command cmd which is on the kernel stack. That should bever raise an error. It should also never result in a calltrap, because this is an in-ke= rnel call. I must admit that I can see no way that this error could happen. --=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-204521-227-4voBm1v9SB>