From nobody Wed Feb 16 10:57:56 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F32F1951644; Wed, 16 Feb 2022 10:58:01 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JzFL075VYz4t2l; Wed, 16 Feb 2022 10:58:00 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645009081; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v5vAakIgF4myeqYFpyl2xyoA1v/5efj3P4NZvZCVgso=; b=YpCbdJ7UF9BBJPFpbGB6eNNKdn0NhQ2PHUoMHykU1TGc0rYmq5GDQsjR9izhbVGEeVra63 CV3y4RKYm26J9p5FDChQ1HMfCo3B4SLfkcmh5hMWnUtDBmb72JIzWn4K/ZT134p8qnkjvv onui9KIfmijae3Qm3gk+CzR+rDDC1HxaNwOyjK7XvSCT5Eb9AsKYbqfY3Dz+TRv56GWRFm tId9FgVKXK/3+fK/tRgzuQjvdr9mlxYmuRzNS7gd23jzwgxPfcwuAHwXbTETAFidNN3PuX M63OiOjHObZQcwllrGohE86cCc4/ZyQY2Zt85cvr4jOOcXdxbieSZPJZ3nw0kg== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id BA7436B58; Wed, 16 Feb 2022 10:58:00 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 814233E215; Wed, 16 Feb 2022 11:57:57 +0100 (CET) From: Kristof Provost To: qroxana Cc: freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: Kernel panic for if_epair Date: Wed, 16 Feb 2022 11:57:56 +0100 X-Mailer: MailMate (1.14r5852) Message-ID: In-Reply-To: References: List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1645009081; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=v5vAakIgF4myeqYFpyl2xyoA1v/5efj3P4NZvZCVgso=; b=yZUoFJahAm15WUho5MtbuX9JIARxeciHYMlCr3WzrUlXGAuIQnsBuVtX0MynHF8SxPjDTa Hv28SrMtj4Mo9V5huHsBknNY2XuLbqtykzZumHLjnkut5zhV2wWuJvKCYKIKeS1lXTWQkW lemGKt4Wf3zbVQo6/tfFwITc+H9F6Jd4X1q4I/qSZRCSPpyU4OBmkzQIbx+BIZyd3p8FLU 3T+Vk+UDBdtM+dls6BO53Hm78Q4uI8gqODEoHvUrhYUEyLjR+py+zvJ4PrUassvaeveXGj ylX9YuV35/kOQq/jH21h92cSWHWX3W1W3ztiCH4SH8sMkDhlMEkPNRGzUb4KLg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1645009081; a=rsa-sha256; cv=none; b=RTko03DgcKrCD4ohKSRTcyhbLlI9HHmiSZOjTUA5t/bwLi0gd+/umDBEVLWzJl8WYWmjM2 jvsTJtEeAxlgn2TM7KzwbUvX8OXE6dASrNpui9nMD6cIFTQ9Tl10FSveTLJX5MrHUp2U5H BxEzXerqNHT4Hh8xUQm4Yo9i/jTzo2n4NQZtODkUDI34Cz0k8geISXoC53o6Aukystc2VO Kjq//6/SRTvHu5SKxp1J594M+2bOc1Udpjao3K6JQSTf2ZS3PCNgRKA2Rq2YxqhBjMsHMz rcxAcenYHHzodkwRhWR/SRd3LoEAi3QXvTiJzD7FEZRzbnH1cwKDZoSUcJ9FAA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 16 Feb 2022, at 11:31, qroxana wrote: > It's running 14.0-CURRENT armv7 main-n252983-d21e71efce39 > > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex epairidx (epairidx) r =3D 0 (0xe2fe9160) locked @= /usr/src/sys/net/if_epair.c:165 > stack backtrace: > #0 0xc03558f8 at witness_debugger+0x7c > #1 0xc0356b3c at witness_warn+0x3fc > #2 0xc05eb3c8 at abort_handler+0x1d8 > #3 0xc05ca8e0 at exception_exit+0 > #4 0xc0475928 at udp_input+0x1c0 > #5 0xc0441884 at ip_input+0xa18 > #6 0xc041426c at netisr_dispatch_src+0x100 > #7 0xc040b9a0 at ether_demux+0x1c8 > #8 0xc040d22c at ether_nh_input+0x514 > #9 0xc041426c at netisr_dispatch_src+0x100 > #10 0xc040be94 at ether_input+0x8c > #11 0xe2fd8130 at $a.8+0x128 > #12 0xc02a1ee0 at ithread_loop+0x268 > #13 0xc029e088 at fork_exit+0xa0 > #14 0xc05ca870 at swi_exit+0 > Fatal kernel mode data abort: 'Alignment Fault' on read > trapframe: 0xe2a0baf0 > FSR=3D00000001, FAR=3De3f02a56, spsr=3D20000013 > r0 =3D00000000, r1 =3D00000001, r2 =3D00000001, r3 =3D00000a0a > r4 =3D00000000, r5 =3De3f02a6a, r6 =3De3f02a56, r7 =3D00000044 > r8 =3D00000044, r9 =3Dc0af955c, r10=3D00000014, r11=3De2a0bc10 > r12=3D00000000, ssp=3De2a0bb80, slr=3Dc0441884, pc =3Dc0475928 > > panic: Fatal abort That backtrace suggests an alignment fault in udp_input(), not an issue w= ith if_epair. There=E2=80=99s not even any mention of if_epair in that backtrace, but I= suppose it=E2=80=99s remotely possible that it=E2=80=99s in epair_intr()= , calling epair_sintr() in #11. That would explain why the epair lock is = held, at least. Note that the epair code has been substantially reworked recently so if y= ou retry with a recent (post 24f0bfbad57b9c3cb9b543a60b2ba00e4812c286) bu= ild you won=E2=80=99t see the epair lock mentioned (assuming you can repr= oduce the panic), but again, it doesn=E2=80=99t look to be involved here = anyway. Kristof