Date: Wed, 20 Nov 2019 21:06:27 -0600 From: Kyle Evans <kevans@freebsd.org> Cc: bob prohaska <fbsd@www.zefox.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: rpi3 panic: data pending interrupt pushed through SDHCI framework Message-ID: <CACNAnaGWAabG=590yRbnV56%2BfumPh1Hk63aTmUxCRvX-nJ9ewA@mail.gmail.com> In-Reply-To: <CACNAnaEgQq6mfsrmVFy_cP5ay3x5NYQNo97RkKLBCXUQJa_YCw@mail.gmail.com> References: <20191121021203.GA1837@www.zefox.net> <CACNAnaEgQq6mfsrmVFy_cP5ay3x5NYQNo97RkKLBCXUQJa_YCw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 20, 2019 at 8:31 PM Kyle Evans <kevans@freebsd.org> wrote: > > 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. > I rolled back the suspicious change in question from the range in your previous post that also fit the bill for a bugzilla PR that came in last night -- r354933 should have the latest hotness.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaGWAabG=590yRbnV56%2BfumPh1Hk63aTmUxCRvX-nJ9ewA>