Re: 14-CURRENT Kernel Panic due to USB hub?

I have had no luck with 20211118 (4082b189d2c).  I was only able to get 
it two boot twice and in those two instances it just locks up during the 
network setup step.  The majority of the time it just panics when 
booting off the ISO image.  I tried about 13 times.  All my attempts are 
logged at 
http://venus.morante.net/downloads/unibia/screenshots/freebsd/R281-T91/14-CURRENT-4082b189d2c/

Here's an example (of the panic part only):

Release APs...done
random: unblocking device.
panic: vm_fault_lookup: fault on nofault entry, addr: 0xffff00010a0c5000
cpuid = 178
time = 2
KDB: stack backtrace:
db_trace_self() at db_trace_self
KDB: enter: panic
[ thread pid 0 tid 100694 ]
Stopped at      kdb_enter+0x44: undefined       f901411f
db> bt
Tracing pid 0 tid 100694 td 0xffffa0000882c000
db_trace_self() at db_trace_self
db>

Just for fun I tried the same snapshot in a virtual machine (using ESXi 
for ARM) on the same hardware and same machine.  That booted and 
installed just fine.

On 11/20/2021 4:03 PM, Daniel Morante via freebsd-arm wrote:
> May or may not be related, but here's a bt after a panic while running 
> poudriere for a few hours.  I still have hw.usb.disable_enumeration=1 
> set.  I'm going to do a new install with the latest snapshot later 
> today.  I'll post a bt of that without hw.usb.disable_enumeration once 
> I get it.
>
> db> bt
> Tracing pid 0 tid 101633 td 0xffffa008230c6580
> db_trace_self() at db_trace_self
> db_stack_trace() at db_stack_trace+0x11c
> db_command() at db_command+0x310
> db_command_loop() at db_command_loop+0x54
> db_trap() at db_trap+0xf8
> kdb_trap() at kdb_trap+0x1c0
> handle_el1h_sync() at handle_el1h_sync+0x78
> --- exception, esr 0xf2000000
> kdb_enter() at kdb_enter+0x44
> vpanic() at vpanic+0x1c0
> panic() at panic+0x44
> deadlkres() at deadlkres+0x2c0
> fork_exit() at fork_exit+0x74
> fork_trampoline() at fork_trampoline+0x14
>
> I'll find a
>
> On 11/12/2021 5:52 AM, Hans Petter Selasky wrote:
>> On 11/12/21 00:43, Daniel Morante via freebsd-arm wrote:
>>> ugen0.2: <Generic 4-Port USB 3.0 Hub> at usbus0 (disconnected)
>>> uhub5: at uhub0, port 1, addr 1 (disconnected)
>>> uhub5: detached
>>> ugen0.2: <Generic 4-Port USB 3.0 Hub> at usbus0
>>> uhub5 numa-domain 0 on uhub0
>>> uhub5: <Interrupt In Interface> on usbus0
>>> uhub5: 4 ports with 4 removable, self powered
>>>
>>> I suspect these problems are caused by the above detaching/reattaching.
>>
>> Can you type "bt" in the panic prompt?
>>
>> --HPS
>>