Date: Wed, 20 Nov 2019 20:31:48 -0600 From: Kyle Evans <kevans@freebsd.org> To: bob prohaska <fbsd@www.zefox.net> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: rpi3 panic: data pending interrupt pushed through SDHCI framework Message-ID: <CACNAnaEgQq6mfsrmVFy_cP5ay3x5NYQNo97RkKLBCXUQJa_YCw@mail.gmail.com> In-Reply-To: <20191121021203.GA1837@www.zefox.net> References: <20191121021203.GA1837@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 20, 2019 at 8:12 PM bob prohaska <fbsd@www.zefox.net> wrote: > > While trying to compile www/chromium on a Pi3 running r354909 > the system reported a panic which is new, at least to me: > > panic: data pending interrupt pushed through SDHCI framework > cpuid = 3 > time = 1574299870 > KDB: stack backtrace: > db_trace_self() at db_trace_self_wrapper+0x28 > pc = 0xffff00000072978c lr = 0xffff000000106548 > sp = 0xffff00004026b4c0 fp = 0xffff00004026b6d0 > > db_trace_self_wrapper() at vpanic+0x18c > pc = 0xffff000000106548 lr = 0xffff000000400c58 > sp = 0xffff00004026b6e0 fp = 0xffff00004026b790 > > vpanic() at panic+0x44 > pc = 0xffff000000400c58 lr = 0xffff000000400a08 > sp = 0xffff00004026b7a0 fp = 0xffff00004026b820 > > panic() at bcm_sdhci_will_handle_transfer+0x64 > pc = 0xffff000000400a08 lr = 0xffff00000071a48c > sp = 0xffff00004026b830 fp = 0xffff00004026b840 > > bcm_sdhci_will_handle_transfer() at sdhci_generic_intr+0x69c > pc = 0xffff00000071a48c lr = 0xffff00000022f44c > sp = 0xffff00004026b850 fp = 0xffff00004026b8b0 > > sdhci_generic_intr() at ithread_loop+0x1e8 > pc = 0xffff00000022f44c lr = 0xffff0000003c44e8 > sp = 0xffff00004026b8c0 fp = 0xffff00004026b940 > > ithread_loop() at fork_exit+0x7c > pc = 0xffff0000003c44e8 lr = 0xffff0000003c0fac > sp = 0xffff00004026b950 fp = 0xffff00004026b980 > > fork_exit() at fork_trampoline+0x10 > pc = 0xffff0000003c0fac lr = 0xffff000000746994 > sp = 0xffff00004026b990 fp = 0x0000000000000000 > > KDB: enter: panic > [ thread pid 12 tid 100051 ] > Stopped at 0 > db> bt > Tracing pid 12 tid 100051 td 0xfffffd0000b9d000 > db_trace_self() at db_stack_trace+0xf8 > pc = 0xffff00000072978c lr = 0xffff00000010398c > sp = 0xffff00004026b090 fp = 0xffff00004026b0c0 > > db_stack_trace() at db_command+0x228 > pc = 0xffff00000010398c lr = 0xffff000000103604 > sp = 0xffff00004026b0d0 fp = 0xffff00004026b1b0 > > db_command() at db_command_loop+0x58 > pc = 0xffff000000103604 lr = 0xffff0000001033ac > sp = 0xffff00004026b1c0 fp = 0xffff00004026b1e0 > > db_command_loop() at db_trap+0xf4 > pc = 0xffff0000001033ac lr = 0xffff0000001066b0 > sp = 0xffff00004026b1f0 fp = 0xffff00004026b410 > > db_trap() at kdb_trap+0x1d8 > pc = 0xffff0000001066b0 lr = 0xffff0000004491f0 > sp = 0xffff00004026b420 fp = 0xffff00004026b4d0 > > kdb_trap() at do_el1h_sync+0xf4 > pc = 0xffff0000004491f0 lr = 0xffff000000746c08 > sp = 0xffff00004026b4e0 fp = 0xffff00004026b510 > > do_el1h_sync() at handle_el1h_sync+0x78 > pc = 0xffff000000746c08 lr = 0xffff00000072c078 > sp = 0xffff00004026b520 fp = 0xffff00004026b630 > > handle_el1h_sync() at kdb_enter+0x34 > pc = 0xffff00000072c078 lr = 0xffff00000044883c > sp = 0xffff00004026b640 fp = 0xffff00004026b6d0 > > kdb_enter() at vpanic+0x1a8 > pc = 0xffff00000044883c lr = 0xffff000000400c74 > sp = 0xffff00004026b6e0 fp = 0xffff00004026b790 > > vpanic() at panic+0x44 > pc = 0xffff000000400c74 lr = 0xffff000000400a08 > sp = 0xffff00004026b7a0 fp = 0xffff00004026b820 > > panic() at bcm_sdhci_will_handle_transfer+0x64 > pc = 0xffff000000400a08 lr = 0xffff00000071a48c > sp = 0xffff00004026b830 fp = 0xffff00004026b840 > > bcm_sdhci_will_handle_transfer() at sdhci_generic_intr+0x69c > pc = 0xffff00000071a48c lr = 0xffff00000022f44c > sp = 0xffff00004026b850 fp = 0xffff00004026b8b0 > > sdhci_generic_intr() at ithread_loop+0x1e8 > pc = 0xffff00000022f44c lr = 0xffff0000003c44e8 > sp = 0xffff00004026b8c0 fp = 0xffff00004026b940 > > ithread_loop() at fork_exit+0x7c > pc = 0xffff0000003c44e8 lr = 0xffff0000003c0fac > sp = 0xffff00004026b950 fp = 0xffff00004026b980 > > fork_exit() at fork_trampoline+0x10 > pc = 0xffff0000003c0fac lr = 0xffff000000746994 > sp = 0xffff00004026b990 fp = 0x0000000000000000 > Hi, This one is also mine, added in r354868: https://svnweb.freebsd.org/base/?revision=354868&view=revision --> this specific check is that we don't have any DMA segments at play during SDHCI_PLATFORM_WILL_HANDLE_TRANSFER, because this is indicative of something less-than-stellar -- it will be invoked only if the generic interrupt handler is handling DATA_AVAIL | SPACE_AVAIL. The way this is supposed to work, the driver starts DMA and disables DATA_AVAIL | SPACE_AVAIL interrupts. DMA interrupts then drive the transfer until we're out of DMA segments, at which point we check if we can go ahead and start up another transfer or if we need to just re-enable interrupts and wait for the controller to act. We should never be coming back in from the SDHCI interrupt path with loaded segments, which is what this one was trying to address: https://reviews.freebsd.org/D22430 That being said, I can see one path where we don't clean up after ourselves -- if we fail to load DMA segments mid-transfer, we set a command error and re-enable interrupts. it's not clear to me if SDHCI_PLATFORM_FINISH_TRANSFER will be invoked before that becomes a problem, but I suspect it should -- you would see some errors that make it sound like there's memory issues. I'll clean that up anyways. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEgQq6mfsrmVFy_cP5ay3x5NYQNo97RkKLBCXUQJa_YCw>