From owner-freebsd-current@freebsd.org Tue Jan 12 18:45:52 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F3FEC4E2A19 for ; Tue, 12 Jan 2021 18:45:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DFffR504Vz4Vlw for ; Tue, 12 Jan 2021 18:45:51 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1610477150; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=EYI2MLnOOnTecNUlgeEsduJ0lpG8X1cbKCS4aL2r1chmL4Hpz03qTnr1+asBUZcE7gbEmwzpKN9Ud wEYKwts8LKN9ECAIugO84016rB0/JGEsiTdGBx+fFhsKpcjsOIXMBjfyhuB9YOvt3eRMK7vAVTi/Dv gcyoGFKNb3YnSmDW5tmBZo00Xg5SqhPAKKykW6Pw6UhA5VN6uurcioWoqHFMvTGsb3bYSeRL2/UhwM TFsvsrR0fICPzQCcmgx9xDNSYcRH/g7VwF7+lssQVkC4Uj+wt8sAo0H58poyA7DQIfuRzZvWcRK1aG ip9TO0du2TPjZwldcASFOn4yuwmgR3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=fbpz1r593hkeVQeE/qfMe0I9lJUsDbYvuIX8qbfzuHY=; b=Yzw1uVB6O/qN5XN4l6XTuPza6cheUB6O3sKe8MU2Rz+l338WGPyMgkSON7J8g4o6Ig+Ot17XfmvSz NIb+fT8Md/BgTdJaM5Vb7BXvG/wuiLBnpuHz7j5Em7PVdbcl1NtiOF/4WyDMruXQghCMRGT4lKAkN8 UmpHUTPyBauyi3q1geG16Nf2QzPTqtIiqwinsV3okRORLB/NuaZbHmY+szPfIDfcvL0xdpanGbm77d BXpevrwwOaTGM4DQXqVyVUxDYajTQ2hu547yRlgyfFcgyvC+SXDjnmBX/hfn5DYkLDBialPLtH6hhC lAO1E9Jkdf8UxPwgPOi9x5hsHcoGQ3A== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; X-MHO-RoutePath: aGlwcGll X-MHO-User: 61f3f4b2-5506-11eb-9e76-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 61f3f4b2-5506-11eb-9e76-df46ed8f892f; Tue, 12 Jan 2021 18:45:49 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 10CIjkUq058508; Tue, 12 Jan 2021 11:45:46 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <7fee78a371dad15e1a7b66eecfa5190e510d930f.camel@freebsd.org> Subject: Re: Panic after updating From: Ian Lepore To: Hans Petter Selasky , Jakob Alvermark , FreeBSD Current Date: Tue, 12 Jan 2021 11:45:46 -0700 In-Reply-To: References: <87512669-f0b9-eb2f-1103-170a29384ea8@alvermark.net> <34a9dafd-9690-1b33-abf8-017ad31cf2ab@alvermark.net> <60e4db60-c816-463e-0e08-a33c674ad4da@alvermark.net> <75784796-b513-5573-abc4-8c445d03c007@selasky.org> <5724744d-7710-4c3c-416b-01314cb196d4@selasky.org> <1bab5b76-eb56-671f-d52d-db1812c9be22@alvermark.net> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DFffR504Vz4Vlw X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 18:45:52 -0000 On Tue, 2021-01-12 at 18:10 +0100, Hans Petter Selasky wrote: > On 1/12/21 2:46 PM, Hans Petter Selasky wrote: > > On 1/12/21 2:40 PM, Jakob Alvermark wrote: > > > > > > On 1/12/21 2:16 PM, Hans Petter Selasky wrote: > > > > On 1/12/21 1:43 PM, Jakob Alvermark wrote: > > > > > > > > > > On 1/12/21 12:54 PM, Hans Petter Selasky wrote: > > > > > > On 1/12/21 12:32 PM, Jakob Alvermark wrote: > > > > > > > Alright, after a new bisect run I got a different result, > > > > > > > so I > > > > > > > most likely did something wrong the first time. > > > > > > > > > > > > > > ff3468ac94597efdcbc56f372528dfc98b114dac is the first bad > > > > > > > commit > > > > > > > commit ff3468ac94597efdcbc56f372528dfc98b114dac > > > > > > > Author: Ian Lepore > > > > > > > Date: Sat Dec 12 18:34:15 2020 +0000 > > > > > > > > > > > > > > Provide userland notification of gpio pin changes > > > > > > > ("userland > > > > > > > gpio interrupts"). > > > > > > > > > > > > > > > > > > > > > Maybe more likely this is causing the panic? > > > > > > > > > > > > Doesn't make sense :-( > > > > > > > > > > > > Can you try to fetch the latest 13-current as of now and > > > > > > re-build > > > > > > the kernel? I noticed some issues myself which got fixed. > > > > > > > > > > > > > > > I did that, still panics the same way. > > > > > > > > > > But, the commit above is about gpio, and I do have > > > > > 'bytgpio_load="YES"' in my /boot/loader.conf > > > > > > > > > > If I boot the kernel without that it works. > > > > > > > > > > 'kldload bytgpio' panics the machine. > > > > > > > > > > > > > Could you screenshot the panic backtrace after kldload of > > > > bytegpio ? > > > > > > Sure: > > > > > > panic: vm_fault_lookup: fault on nofault entry, addr: > > > 0xfffffe00c96c2000 > > > cpuid = 1 > > > time = 1610458544 > > > KDB: stack backtrace: > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > > > 0xfffffe00c7306140 > > > vpanic() at vpanic+0x181/frame 0xfffffe00c7306190 > > > panic() at panic+0x43/frame 0xfffffe00c73061f0 > > > vm_fault() at vm_fault+0x142d/frame 0xfffffe00c73062f0 > > > vm_fault_trap() at vm_fault_trap+0xb1/frame 0xfffffe00c7306340 > > > trap_pfault() at trap_pfault+0x1f6/frame 0xfffffe00c73063a0 > > > trap() at trap+0x280/frame 0xfffffe00c73064b0 > > > calltrap() at calltrap+0x8/frame 0xfffffe00c73064b0 > > > --- trap 0xc, rip = 0xffffffff80c27d08, rsp = 0xfffffe00c7306580, > > > rbp > > > = 0xfffffe00c7306580 --- > > > lock_init() at lock_init+0xf8/frame 0xfffffe00c7306580 > > > _mtx_init() at _mtx_init+0x70/frame 0xfffffe00c73065a0 > > > gpioc_attach() at gpioc_attach+0x139/frame 0xfffffe00c7306620 > > > device_attach() at device_attach+0x3dd/frame 0xfffffe00c7306670 > > > bus_generic_attach() at bus_generic_attach+0x4b/frame > > > 0xfffffe00c73066a0 > > > gpiobus_attach_bus() at gpiobus_attach_bus+0x44/frame > > > 0xfffffe00c73066c0 > > > bytgpio_attach() at bytgpio_attach+0x1f7/frame 0xfffffe00c7306710 > > > device_attach() at device_attach+0x3dd/frame 0xfffffe00c7306760 > > > device_probe_and_attach() at device_probe_and_attach+0x41/frame > > > 0xfffffe00c7306790 > > > acpi_driver_added() at acpi_driver_added+0xaa/frame > > > 0xfffffe00c73067c0 > > > devclass_driver_added() at devclass_driver_added+0x3c/frame > > > 0xfffffe00c7306800 > > > devclass_add_driver() at devclass_add_driver+0x13d/frame > > > 0xfffffe00c7306840 > > > module_register_init() at module_register_init+0xa7/frame > > > 0xfffffe00c7306870 > > > linker_load_module() at linker_load_module+0xbca/frame > > > 0xfffffe00c7306b80 > > > kern_kldload() at kern_kldload+0xbb/frame 0xfffffe00c7306bd0 > > > sys_kldload() at sys_kldload+0x5b/frame 0xfffffe00c7306c00 > > > amd64_syscall() at amd64_syscall+0x111/frame 0xfffffe00c7306d30 > > > fast_syscall_common() at fast_syscall_common+0xf8/frame > > > 0xfffffe00c7306d30 > > > --- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x80037715a, > > > rsp > > > = 0x7fffffffe698, rbp = 0x7fffffffec10 --- > > > KDB: enter: panic > > > > > > > Adding Ian. > > > > Looks like an off-by-one there. > > Can you try to apply this patch manually: > > > diff --git a/sys/dev/gpio/gpioc.c b/sys/dev/gpio/gpioc.c > > index 727b07a7058..29d795bb54b 100644 > > --- a/sys/dev/gpio/gpioc.c > > +++ b/sys/dev/gpio/gpioc.c > > @@ -582,7 +582,7 @@ gpioc_attach(device_t dev) > > return (err); > > sc->sc_pin_intr = malloc(sizeof(struct gpioc_pin_intr) * > > sc->sc_npins, > > M_GPIOC, M_WAITOK | M_ZERO); > > - for (int i = 0; i <= sc->sc_npins; i++) { > > + for (int i = 0; i != sc->sc_npins; i++) { > > sc->sc_pin_intr[i].pin = malloc(sizeof(struct > > gpiobus_pin), > > M_GPIOC, M_WAITOK | M_ZERO); > > sc->sc_pin_intr[i].sc = sc; > > @@ -616,7 +616,7 @@ gpioc_detach(device_t dev) > > if (sc->sc_ctl_dev) > > destroy_dev(sc->sc_ctl_dev); > > > > - for (int i = 0; i <= sc->sc_npins; i++) { > > + for (int i = 0; i != sc->sc_npins; i++) { > > mtx_destroy(&sc->sc_pin_intr[i].mtx); > > free(&sc->sc_pin_intr[i].pin, M_GPIOC); > > } > > --HPS > If that is the problem, I'd rather see it fixed by using the idiomatic i < sc->sc_npins rather than the non-standard != test. (But I don't feel strongly enough about it to learn how to use git and commit the fix myself.) -- Ian