From owner-freebsd-arm@freebsd.org Sun Sep 2 03:16:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C61DFE26E0 for ; Sun, 2 Sep 2018 03:16:05 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.cyclaero.com (ec2-18-195-62-44.eu-central-1.compute.amazonaws.com [18.195.62.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6BC8884FC for ; Sun, 2 Sep 2018 03:16:03 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mail.obsigna.com (unknown [191.182.171.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cyclaero.com (Postfix) with ESMTPSA id 7B41089 for ; Sun, 2 Sep 2018 05:15:56 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 6B6AA1350FA87 for ; Sun, 2 Sep 2018 00:15:51 -0300 (BRT) From: "Dr. Rolf Jansen" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Kernel Panic on BBB cause by ti_adc intr Message-Id: Date: Sun, 2 Sep 2018 00:15:50 -0300 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Sep 2018 03:16:05 -0000 I got signal sources connected to AIN0 and AIN1 of the BBB. The signals = are divided, clipped and clamped and are guaranteed to stay in the range = of 0 to 1.8 V. Generally, the circuitry does work and the ADC readings = match very well the expectations. Only, sometimes, usually when I power on some considerable load (e.g. a = hair dryer) connected to a different AC plug, but in the same room, the = BBB bails out, giving the stack backtrace shown below. It might well be, = that a power-on spike traverses the AC electricity supply, but there is = no way that the spike after clipping and clamping would exceed said = limits. My understanding of the stack backtrace is, that somehow an interrupt is = triggered by said spike, and then it hits a bug in the interrupt = handler. It seems that an exclusive sleep mutex is locked when it is not = expected to be. This happened on FreeBSD 12.0-ALPHA3 and today also on = -ALPHA4. Question: I don't need interrupt handling in my project, since the signal changes are slow, and the changes need to be read in defined time intervals. So, is it possible to deactivate the interrupt handler of the ti_adc? Presumably then the feature of the exclusive sleep mutex on ti_adc0 = would not be challenged and therefore may continue sleeping forever. Of = course, I want continue being able of timed reading of the ADC values. Any suggestions would be greatly appreciated, since a BBB which can be = DoS'ed by powering on a hair dryer is not as useful as it could be. Best regards Rolf Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ti_adc0 (ti_adc) r =3D 0 (0xc2277d08) locked @ = /usr/src/sys/arm/ti/ti_adc.c:508 stack backtrace: Fatal kernel mode data abort: 'Translation Fault (L1)' on read trapframe: 0xd2ebeca0 FSR=3D00000005, FAR=3D00000128, spsr=3D20000013 r0 =3D00000000, r1 =3D00000003, r2 =3D00000001, r3 =3D00000000 r4 =3D00000000, r5 =3D00000000, r6 =3D00000003, r7 =3D00000016 r8 =3D00000000, r9 =3Dc2280e00, r10=3D00000021, r11=3Dd2ebed60 r12=3Dc0ace03c, ssp=3Dd2ebed30, slr=3Dc067d61c, pc =3Dc00888c0 panic: Fatal abort cpuid =3D 0 time =3D 1535844155 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc05c7484 lr =3D 0xc0075d04 = (db_trace_self_wrapper+0x30) sp =3D 0xd2ebea80 fp =3D 0xd2ebeb98 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc0075d04 lr =3D 0xc029d60c (vpanic+0x16c) sp =3D 0xd2ebeba0 fp =3D 0xd2ebebc0 r4 =3D 0x00000100 r5 =3D 0x00000001 r6 =3D 0xc071bb22 r7 =3D 0xc0a8cfd8 vpanic() at vpanic+0x16c pc =3D 0xc029d60c lr =3D 0xc029d3ec (doadump) sp =3D 0xd2ebebc8 fp =3D 0xd2ebebcc r4 =3D 0xd2ebeca0 r5 =3D 0x00000013 r6 =3D 0x00000128 r7 =3D 0x00000005 r8 =3D 0x00000005 r9 =3D 0xd2ebeca0 r10 =3D 0x00000128 doadump() at doadump pc =3D 0xc029d3ec lr =3D 0xc05e9bb0 (abort_align) sp =3D 0xd2ebebd4 fp =3D 0xd2ebec00 r4 =3D 0xc029d3ec r5 =3D 0xd2ebebd4 abort_align() at abort_align pc =3D 0xc05e9bb0 lr =3D 0xc05e9740 (abort_handler+0x2e0) sp =3D 0xd2ebec08 fp =3D 0xd2ebec98 r4 =3D 0x00000013 r5 =3D 0x00000128 abort_handler() at abort_handler+0x2e0 pc =3D 0xc05e9740 lr =3D 0xc05c9dd4 (exception_exit) sp =3D 0xd2ebeca0 fp =3D 0xd2ebed60 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000003 r7 =3D 0x00000016 r8 =3D 0x00000000 r9 =3D 0xc2280e00 r10 =3D 0x00000021 exception_exit() at exception_exit pc =3D 0xc05c9dd4 lr =3D 0xc067d61c (ti_adc_intr+0x88) sp =3D 0xd2ebed30 fp =3D 0xd2ebed60 r0 =3D 0x00000000 r1 =3D 0x00000003 r2 =3D 0x00000001 r3 =3D 0x00000000 r4 =3D 0x00000000 r5 =3D 0x00000000 r6 =3D 0x00000003 r7 =3D 0x00000016 r8 =3D 0x00000000 r9 =3D 0xc2280e00 r10 =3D 0x00000021 r12 =3D 0xc0ace03c evdev_push_event() at evdev_push_event+0x4c pc =3D 0xc00888c0 lr =3D 0xc067d61c (ti_adc_intr+0x88) sp =3D 0xd2ebed68 fp =3D 0xd2ebedd0 r4 =3D 0xd2fce800 r5 =3D 0xc2277d00 r6 =3D 0x00000000 r7 =3D 0x00000421 r8 =3D 0xc2277d18 r9 =3D 0xc2280e00 ti_adc_intr() at ti_adc_intr+0x88 pc =3D 0xc067d61c lr =3D 0xc02662fc (ithread_loop+0x1f0) sp =3D 0xd2ebedd8 fp =3D 0xd2ebee20 r4 =3D 0xd2fce800 r5 =3D 0x00000000 r6 =3D 0xd2fce844 r7 =3D 0x00000000 r8 =3D 0xc0719541 r9 =3D 0xc2280e00 r10 =3D 0x00000000 ithread_loop() at ithread_loop+0x1f0 pc =3D 0xc02662fc lr =3D 0xc0262ef8 (fork_exit+0xa0)