Re: -current panic on boot on RPI3

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Michael Cheponis <michael.cheponis%gmail.com@localhost> writes:

> Although likely a long-shot: can you try on a different RPi3?
>
> I have 3 of them, and I want all machines to boot from USB - but with even
> low-level FW updated, only 2 of them work that way (they all should work
> that way).  I want to make sure I have 2 spares on  hand for my application.
> ------
> Also, I keep one RPi3 up, and I run an ancient kernel (-current .17)
> because I was unsuccessful with any new kernels, so I stopped building for
> that machine.  Some would run for a few weeks before crashing; but this
> machine must work 24/7  (I should probably run 9.2).   I stopped trying new
> kernels maybe six months ago.   I suppose I should try again with a newer
> kernel.

I was several RPIs that run 24x7x365 but with nothing later than
9.x_STABLE...  I do have several spare RPI3 and will certainly try one
or more of them..  I can also build a newer tree from -current.  I was
working on device drivers in -current when I noted the mentioned panic.


> On Mon, Oct 18, 2021 at 3:42 AM Brad Spencer <brad%anduin.eldar.org@localhost> wrote:
>
>> Kimmo Suominen <kim%netbsd.org@localhost> writes:
>>
>> > On Fri, Oct 01, 2021 at 05:03:01PM -0400, Brad Spencer wrote:
>> >>
>> >> I did a build of -current from source taken on 2021-09-30 and had it
>> >> panic on my RPI 3.
>> >>
>> >> Just wondering if this a known problem.  The panic is as follows:
>> >>
>> >> [   1.2878232] kernel diagnostic assertion "l->l_stat == LSONPROC"
>> failed: file "/usr/src/sys/kern/kern_sleepq.c", line 227
>> >> [   1.2978253] cpu1: Begin traceback...
>> >> [   1.3478291] netbsd:vpanic+0x16c
>> >> [   1.3978354] netbsd:cv_enter+0xfc
>> >> [   1.4078352] netbsd:cv_wait+0x44
>> >> [   1.4078352] 0x809aeeac: netbsd:xc_wait+0xa0
>> >> [   1.4178637] 0x809aeee4: netbsd:pic_establish_intr+0x2a0
>> >> [   1.4178637] 0x809aef14: netbsd:intr_establish_xname+0xa4
>> >> [   1.4278385] 0x809aef2c: netbsd:intr_establish+0x20
>> >> [   1.4278385] 0x809aef54: netbsd:bcm2836mp_intr_init+0x4c
>> >> [   1.4378399] 0x809aef6c: netbsd:arm_fdt_cpu_hatch+0x34
>> >> [   1.4378399] 0x809aef94: netbsd:cpu_hatch+0x1bc
>> >> [   1.4478405] cpu1: End traceback...
>> >
>> > This looks like it could be related to PR 56264:
>> > https://gnats.netbsd.org/56264
>> >
>> > There is a workaround listed in that ticket, but you should already have
>> > it as it was committed on 2021-09-01.  But it might be worth checking if
>> > you have src/sys/arch/arm/broadcom/bcm2835_intr.c r1.39 or later.
>> >
>> > Cheers,
>> > + Kimmo
>>
>> Thanks...  I have version 1.41 of bcm2835_intr.c.  I noted that that the
>> panic occurs with evbarm6, evbarm7 and aarch64 on the RPI3.  I also
>> found that compiling a kernel with only single processor support
>> prevents the panic (disable MULTIPROCESSOR).  I won't be able to test
>> further for a couple of days, but I can try any suggestions anyone might
>> have when I become more available again.  Running SP is a little
>> annoying and probably not reasonable for the long term unless the
>> general thought is that the RPI3 is too long in the tooth to be well
>> supported.  I still suspect that there are a lot of them out there, but
>> that is mostly just my opinion.




-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org