Re: debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

2020-12-19 Thread Mark Millard 



On 2020-Dec-19, at 03:09, Hans Petter Selasky  wrote:

> Please test:
> 
> https://svnweb.freebsd.org/changeset/base/368799
> https://svnweb.freebsd.org/changeset/base/368801
> 
> --HPS

I grabbed a debug -r368803 kernel from artifacts (first arm64
snapshot available containing the above 2 updates):

https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368803/arm64/aarch64/kernel.txz

I used it to substitute in the updated debug kernel and booted
the same configuration.

It booted fine with no LOR or uma_zalloc_debug related console
output.

I've not tried my own non-debug build yet but that kind of
context had never given me a clue of these issues anyway. (I
am not expecting the above to change the non-debug "Root mount
waiting for: usbus0" for the uefi/ACPI USB3 SSD based boot
sequence.)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

2020-12-19 Thread Toomas Soome 


> On 19. Dec 2020, at 23:21, Graham Perrin  wrote:
> 
> With VirtualBox on an r368589 host I installed the latest (17th December) 
> snapshot of 13.0-CURRENT in a guest machine. I set the guest to EFI before 
> installation, and chose GPT (UEFI) during installation.
> 
> After installing KDE Plasma etc., the guest worked for a short while but then 
> failed to boot. Screenshots at ; scroll down to 
> 17:49:06 for a shot of a failure.
> 
> Is this maybe another case of bug 251866? 
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org”


Do You mean the screenshot with UEFI shell? You usually do drop to UEFI shell 
when firmware did decide it can not start your efi application. Other option 
is, we got failure and did exit loader.efi.

it may help if you attempt to start loader.efi manually from ESP, by entering: 
FS0:/efi/boot/bootx64.efi  — there may appear some messages...

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

2020-12-19 Thread Graham Perrin 

On 19/12/2020 23:20, Warner Losh wrote:



On Sat, Dec 19, 2020 at 2:21 PM Graham Perrin > wrote:


With VirtualBox on an r368589 host I installed the latest (17th
December) snapshot of 13.0-CURRENT in a guest machine. I set the
guest
to EFI before installation, and chose GPT (UEFI) during installation.

After installing KDE Plasma etc., the guest worked for a short
while but
then failed to boot. Screenshots at >;
scroll down to 17:49:06 for a shot of a failure.

Is this maybe another case of bug 251866?
>


Try the next snapshot... I just fixed this in -current... or so I 
claim. Please validate my claim. :)


Though unless there's a bunch of stuff where the boot loader fails and 
then loads the shell, maybe not...


You need to check you ESP to make sure there's a bootx64.efi in 
\efi\boot\ as well... that would also kick you into the shell...


Warner



Thanks, will the next snapshot be on/around 24th December? Or later, 
with the festive season?


In the meantime I added four shots to the album. With the boot 
maintenance manager of VirtualBox, I  
navigated to loader.efi, added it as a boot option (I lazily named it 
'loader.efi') then set it as primary  after 
which:


* normal resets or restarts of the VM do successfully boot

– and if I change the boot order to make 'EFI Hard Drive' primary and 
'loader.efi' last, boots fail (drop outs to the EFI shell).


 and  it appears 
that 'EFI Hard Drive' and 'EFI DVD/CDROM' have the same path. Surely 
wrong, I can think of nothing that might have caused this.


Graham

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

2020-12-19 Thread Warner Losh 
On Sat, Dec 19, 2020 at 2:21 PM Graham Perrin 
wrote:

> With VirtualBox on an r368589 host I installed the latest (17th
> December) snapshot of 13.0-CURRENT in a guest machine. I set the guest
> to EFI before installation, and chose GPT (UEFI) during installation.
>
> After installing KDE Plasma etc., the guest worked for a short while but
> then failed to boot. Screenshots at ;
> scroll down to 17:49:06 for a shot of a failure.
>
> Is this maybe another case of bug 251866?
> 
>

Try the next snapshot... I just fixed this in -current... or so I claim.
Please validate my claim. :)

Though unless there's a bunch of stuff where the boot loader fails and then
loads the shell, maybe not...

You need to check you ESP to make sure there's a bootx64.efi in \efi\boot\
as well... that would also kick you into the shell...

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot

2020-12-19 Thread Graham Perrin 
With VirtualBox on an r368589 host I installed the latest (17th 
December) snapshot of 13.0-CURRENT in a guest machine. I set the guest 
to EFI before installation, and chose GPT (UEFI) during installation.


After installing KDE Plasma etc., the guest worked for a short while but 
then failed to boot. Screenshots at ; 
scroll down to 17:49:06 for a shot of a failure.


Is this maybe another case of bug 251866? 



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: RISC-V root device question -> Panic

2020-12-19 Thread Mitchell Horne 
On Mon, Dec 14, 2020 at 6:03 PM Michael Dexter
 wrote:
>
> Mitchell,
>
> On 12/7/20 1:56 PM, Mitchell Horne wrote:
> > You can also override it using the QEMU commandline, which is simpler
> > since you won't need to recompile anything. Adding the following
> > argument should suffice:
>
> This works great but riscv 12-STABLE using last week's snapshot revision
> throws the panic output included below under QEMU and leaves nothing in
> /var/crash
>
> What expectations should I set for RISC-V STABLE and CURRENT?
>

Hi Michael, sorry for my delayed reply.

Development and testing has been almost entirely focused on CURRENT. I
believe riscv64 may have been functional on stable/12 at some point
(and we even made an effort to MFC changes there), but it is not used
anymore as far as I know. The expectations I would set going forward
are that 13.0 will be the first functional release for the
architecture (including stable/13 when it is branched), and stable/12
will remain unsupported.

Also, to follow up on earlier items in this thread, I have documented
how to generate a bootable RISC-V image containing an EFI partition
with loader.efi. If you encounter any issues with the instructions,
please let me know.
https://wiki.freebsd.org/riscv/QEMU#Generate_a_root_filesystem

Cheers,
Mitchell

> All the best,
>
> Michael
>
> t[0] == 0xffc0006c9d98
> t[1] == 0x40c5
> t[2] == 0x40c65000
> t[3] == 0x0001
> t[4] == 0x
> t[5] == 0x0001
> t[6] == 0x0001
> s[0] == 0xffd0b1600248
> s[1] == 0x40e49000
> s[2] == 0xf000
> s[3] == 0x00ff
> s[4] == 0x4100
> s[5] == 0x0001
> s[6] == 0xffc000aff988
> s[7] == 0x410a1000
> s[8] == 0x0280
> s[9] == 0x
> s[10] == 0x1000
> s[11] == 0xff73
> a[0] == 0x
> a[1] == 0xffd00297d560
> a[2] == 0x
> a[3] == 0x0021
> a[4] == 0x
> a[5] == 0x0021
> a[6] == 0x003f
> a[7] == 0xffc000aff900
> sepc == 0xffc0004ce414
> sstatus == 0x0120
> panic: Fatal page fault at 0xffc0004ce414: 0x65
> cpuid = 1
> time = 1607915275
> KDB: stack backtrace:
> #0 0xffc00023f2d4 at kdb_backtrace+0x50
> Uptime: 2d1h40m41s
> Automatic reboot in 15 seconds - press a key on the console to abort
> Rebooting...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

(251866) installers for FreeBSD fail to boot HP EliteBook 830 G7, 440 G7 …

2020-12-19 Thread Graham Perrin 

On 12/12/2020 19:18, Rebecca Cran wrote:

On 12/11/2020 8:03 PM, Graham Perrin wrote:

On 11/12/2020 18:26, Ludovit Koren wrote:


…
Probably 



This crash also happens on VMware Workstation 16 Pro with 13-CURRENT. 
I'm hoping to find some time to debug it.


Via :



> Drop EFI_STAGING_SIZE back down to 64M …

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: git tools for building in base?

2020-12-19 Thread Thomas Mueller 
> Yes. I was answering the first question asked about FreeBSD and git...

> The clincher for me was that git is better supported by third party tools
> and has gotten quite good at 'recovery from oops' which mercurial is still
> lacking in both areas. I too have used both, and I had to re clone my hg
> tree several times, but so far have never screwed up a git repo so bad I
> had to reclone... The history rewriting of git is more integrated and more
> polished than the equivalent in hg, as are the rebase workflows which
> really help have a cleaner history...

> Warner (Losh)

I have messed up a git repo and had to reclone, but can't compare to mercurial 
because I have not yet used mercurial.

Maybe I was inept with git.

I notice many more open-source projects use git than mercurial, maybe because 
of the reasons explained in your post.

I still see no timeline on when NetBSD will switch to mercurial, or if they 
could possibly change their mind in favor of git or otherwise.

OpenBSD looks to be still using CVS, while DragonFlyBSD uses git.

It looks like T2 project (t2sde.org) still uses subversion.

Tom

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RPi4 (8 GiByte) example: non-debug head -r368500 kernel fails to mount root where artifact debug kernel works fine (uefi/ACPI boot)

2020-12-19 Thread Mark Millard 
The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
v1.21 materials, directly booting from the USB3 SSD, no microsd card
involved.

Non-debug kernels built for cortex-A72 and for cortex-A53 both got the
behavior that leads mount root failure. (This tends to eliminate some types
of missing synchronization as a potential issue: in the past the cortex-a72
style of build caught a problem that cortex-a53 builds did not show. So my
original thought to cc hps may have been a waste.) Still, the below is
based on my usual cortex-a72 based kernel being used as the non-debug kernel
example.

The artifact debug kernel from:

https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz

does not get the problem.

The prior RPi4 context was back at head -r365932 or so and back then
the combination worked. The FreeBSD upgrade is recent.

In the failing contexts (i.e., non-debug contexts), the following
never shows up:

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REPLACED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2

and the message:

Root mount waiting for: usbus0

repeats indefinitely, unlike historically for my configuration.


Capturing and diffing boot -v output did not show much interesting
but here is the range with usbusN and the like (+: for artifact debug
kernel, -: for non-debug -mcpu=cortex-a72 kernel):

@@ -197,18 +198,18 @@
 vlan: initialized, using hash tables with chaining
 IPsec: Initialized Security Association Processing.
 tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768
-AcpiOsExecute: enqueue 1 pending tasks
 usbus0: 5.0Gbps Super Speed USB v3.0
 usbus1: 480Mbps High Speed USB v2.0
-Release APs...Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
-done
-Root mount waiting for: usbus0CPU  0: ARM Cortex-A72 r0p3 affinity:  0
- usbus1   Cache Type = <64 byte D-cacheline,64 byte 
I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
- CAM
- Instruction Set Attributes 0 = 
- Instruction Set Attributes 1 = <>
- Processor Features 0 = 
- Processor Features 1 = <>
+AcpiOsExecute: enqueue 1 pending tasks
+Release APs...done
+CPU  0: ARM Cortex-A72 r0p3 affinity:  0
+Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
+   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT 
ICache,64 byte ERG,64 byte CWG>
+Root mount waiting for: Instruction Set Attributes 0 = 
+ usbus0 Instruction Set Attributes 1 = <>
+ usbus1 Processor Features 0 = 
+ CAM Processor Features 1 = <>
+
   Memory Model Features 0 = 
   Memory Model Features 1 = <8bit VMID>
   Memory Model Features 2 = <32bit CCIDX,48bit VA>
@@ -219,12 +220,13 @@
 CPU  1: ARM Cortex-A72 r0p3 affinity:  1
 CPU  2: ARM Cortex-A72 r0p3 affinity:  2
 CPU  3: ARM Cortex-A72 r0p3 affinity:  3
+WARNING: WITNESS option enabled, expect reduced performance.
 regulator: shutting down unused regulators
 ugen1.1:  at usbus1
 ugen0.1:  at usbus0
 uhub0 on usbus1
-uhub0:  on usbus1
 uhub1 on usbus0
+uhub0:  on usbus1
 uhub1:  on usbus0
 uhub0: 1 port with 1 removable, self powered
 uhub1: 5 ports with 4 removable, self powered
@@ -233,15 +235,28 @@
 uhub2:  on usbus0
 Root mount waiting for: usbus0 CAM
 uhub2: 4 ports with 4 removable, self powered
-Root mount waiting for: usbus0 CAM
 ugen0.3:  at usbus0
 Root mount waiting for: usbus0 CAM
 Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
+ugen0.4:  at usbus0
+umass0 on uhub1
+umass0:  on usbus0
+umass0:  SCSI over Bulk-Only; quirks = 0x0100
+umass0:0:0: Attached to scbus0
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+GEOM: new disk da0
+pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
+pass0:  Fixed Direct Access SPC-4 SCSI device
+pass0: Serial Number REPLACED
+pass0: 400.000MB/s transfers
+da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
+da0:  Fixed Direct Access SPC-4 SCSI device
+da0: Serial Number REPLACED
+da0: 400.000MB/s transfers
+da0: 228936MB (468862128 512 byte sectors)
+da0: quirks=0x2
+da0: Delete methods: 

(I did not include more of the waiting-for messages for the
non-debug kernel ("-"). I see no reason to have later text
from the debug kernel case ("+").)

I do have a working u-boot 2020.10 based, microsd card first-stages
boot for the same USB3 SSD that mounts the same root file system
just fine. The kernel is a copy of the same non-debug kernel that
the the above used, but the used copy is on the microsd card for
this type of booting. (The u-boot is not ready to deal with
USB-based booting of 8 GiByte RPi4's.)

So

Re: debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

2020-12-19 Thread Hans Petter Selasky 

Please test:

https://svnweb.freebsd.org/changeset/base/368799
https://svnweb.freebsd.org/changeset/base/368801

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

2020-12-19 Thread Mark Millard 
[I managed to not cc the primary person that I intended but to cc the secondary 
person.
So this resend just adds jmg and removes hps.]

On 2020-Dec-18, at 22:27, Mark Millard  wrote:


> The following is from head -r368500's artifact kernel from:
> 
> https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz
> 
> but the same sort of material showed for -r368000 .
> (I was attempting a bisect for a different issue but
> the debug kernels did not fail for what I was looking
> for and all the debug versions that I tried reported
> similarly to the below.)
> 
> Note also the mixing in of "uma_zalloc_debug" activity
> after the initial LOR backtrace, ure0 still involved.
> 
> Autoloading module: if_ure.ko
> ure0 on uhub0
> ure0:  on 
> usbus0
> add host 127.0.0.1: gatelock order reversal: (sleepable after non-sleepable)
> 1st 0xa2b2cea0 ure0 (ure0, sleep mutex) @ 
> /usr/src/sys/dev/usb/usb_request.c:714
> 2nd 0x00dd6858 sysctl lock (sysctl lock, sleepable rm) @ /usway lo0 
> fib 0: route alrr/src/sys/kern/kern_sysctl.c:836
> lock order ure0 -> sysctl lock attempted at:
> #0 0x0056d068 at witness_checkorder+0xc54
> #1 0x004f8f08 at _rm_wlock_debug+0x88
> #2 0x0050ee2c at sysctl_add_oid+0x60
> #3 0x9e415780 at ure_attach_post+0x1a78
> #4 0x00391d6c at ue_attach_post_task+0x3c
> #5 0x003826e0 at usb_process+0x10c
> #6 0x004baa1c at fork_exit+0x7c
> #7 0x00816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-128eady in table
> " with the following non-sleepable locks held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
> /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0x0056d388 at witness_debugger+0x64
> #1 0x0056e518 at witness_warn+0x3ec
> #2 0x00778f9c at uma_zalloc_debug+0x2c
> #3 0x00778998 at uma_zalloc_arg+0x2c
> #4 0x004d534c at malloc+0xa0
> #5 0x0050ee80 at sysctl_add_oid+0xb4
> #6 0x9e415780 at ure_attach_post+0x1a78
> #7 0x00391d6c at ue_attach_post_task+0x3c
> #8 0x003826e0 at usb_process+0x10c
> #9 0x004baa1c at fork_exit+0x7c
> #10 0x00816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks 
> held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
> /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0x0056d388 at witness_debugger+0x64
> #1 0x0056e518 at witness_warn+0x3ec
> #2 0x00778f9c at uma_zalloc_debug+0x2c
> #3 0x00778998 at uma_zalloc_arg+0x2c
> #4 0x004d534c at malloc+0xa0
> #5 0x005f8c80 at strdup+0x2c
> #6 0x0050eeb8 at sysctl_add_oid+0xec
> #7 0x9e415780 at ure_attach_post+0x1a78
> #8 0x00391d6c at ue_attach_post_task+0x3c
> #9 0x003826e0 at usb_process+0x10c
> #10 0x004baa1c at fork_exit+0x7c
> #11 0x00816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks 
> held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
> /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0x0056d388 at witness_debugger+0x64
> #1 0x0056e518 at witness_warn+0x3ec
> #2 0x00778f9c at uma_zalloc_debug+0x2c
> #3 0x00778998 at uma_zalloc_arg+0x2c
> #4 0x004d534c at malloc+0xa0
> #5 0x005f8c80 at strdup+0x2c
> #6 0x0050eee4 at sysctl_add_oid+0x118
> #7 0x9e415780 at ure_attach_post+0x1a78
> #8 0x00391d6c at ue_attach_post_task+0x3c
> #9 0x003826e0 at usb_process+0x10c
> #10 0x004baa1c at fork_exit+0x7c
> #11 0x00816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-32" with the following non-sleepable locks 
> held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
> /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0x0056d388 at witness_debugger+0x64
> #1 0x0056e518 at witness_warn+0x3ec
> #2 0x00778f9c at uma_zalloc_debug+0x2c
> #3 0x00778998 at uma_zalloc_arg+0x2c
> #4 0x004d534c at malloc+0xa0
> #5 0x0050ef3c at sysctl_add_oid+0x170
> #6 0x9e415780 at ure_attach_post+0x1a78
> #7 0x00391d6c at ue_attach_post_task+0x3c
> #8 0x003826e0 at usb_process+0x10c
> #9 0x004baa1c at fork_exit+0x7c
> #10 0x00816544 at fork_trampoline+0x10
> miibus0:  on ure0
> rgephy0:  PHY 0 on miibus0
> add hrgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
> 1000baseT-FDX, 1000baseT-FDX-master, auto
> 0 fib 0: route already iue0:  on ure0
> 
> 
> 
> The context here is an RPi4 (aarch64 cortex-a72) with:
> 
> # uname -apKU
> FreeBSD RPi4B 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368500: Thu Dec 10 
> 07:52:39 UTC 2020 
>

debug head -r368500 kernel (for example) : "lock order reversal: (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more

2020-12-19 Thread Mark Millard 


The following is from head -r368500's artifact kernel from:

https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz

but the same sort of material showed for -r368000 .
(I was attempting a bisect for a different issue but
the debug kernels did not fail for what I was looking
for and all the debug versions that I tried reported
similarly to the below.)

Note also the mixing in of "uma_zalloc_debug" activity
after the initial LOR backtrace, ure0 still involved.

Autoloading module: if_ure.ko
ure0 on uhub0
ure0:  on usbus0
add host 127.0.0.1: gatelock order reversal: (sleepable after non-sleepable)
 1st 0xa2b2cea0 ure0 (ure0, sleep mutex) @ 
/usr/src/sys/dev/usb/usb_request.c:714
 2nd 0x00dd6858 sysctl lock (sysctl lock, sleepable rm) @ /usway lo0 
fib 0: route alrr/src/sys/kern/kern_sysctl.c:836
lock order ure0 -> sysctl lock attempted at:
#0 0x0056d068 at witness_checkorder+0xc54
#1 0x004f8f08 at _rm_wlock_debug+0x88
#2 0x0050ee2c at sysctl_add_oid+0x60
#3 0x9e415780 at ure_attach_post+0x1a78
#4 0x00391d6c at ue_attach_post_task+0x3c
#5 0x003826e0 at usb_process+0x10c
#6 0x004baa1c at fork_exit+0x7c
#7 0x00816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-128eady in table
" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
/usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0x0056d388 at witness_debugger+0x64
#1 0x0056e518 at witness_warn+0x3ec
#2 0x00778f9c at uma_zalloc_debug+0x2c
#3 0x00778998 at uma_zalloc_arg+0x2c
#4 0x004d534c at malloc+0xa0
#5 0x0050ee80 at sysctl_add_oid+0xb4
#6 0x9e415780 at ure_attach_post+0x1a78
#7 0x00391d6c at ue_attach_post_task+0x3c
#8 0x003826e0 at usb_process+0x10c
#9 0x004baa1c at fork_exit+0x7c
#10 0x00816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
/usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0x0056d388 at witness_debugger+0x64
#1 0x0056e518 at witness_warn+0x3ec
#2 0x00778f9c at uma_zalloc_debug+0x2c
#3 0x00778998 at uma_zalloc_arg+0x2c
#4 0x004d534c at malloc+0xa0
#5 0x005f8c80 at strdup+0x2c
#6 0x0050eeb8 at sysctl_add_oid+0xec
#7 0x9e415780 at ure_attach_post+0x1a78
#8 0x00391d6c at ue_attach_post_task+0x3c
#9 0x003826e0 at usb_process+0x10c
#10 0x004baa1c at fork_exit+0x7c
#11 0x00816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
/usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0x0056d388 at witness_debugger+0x64
#1 0x0056e518 at witness_warn+0x3ec
#2 0x00778f9c at uma_zalloc_debug+0x2c
#3 0x00778998 at uma_zalloc_arg+0x2c
#4 0x004d534c at malloc+0xa0
#5 0x005f8c80 at strdup+0x2c
#6 0x0050eee4 at sysctl_add_oid+0x118
#7 0x9e415780 at ure_attach_post+0x1a78
#8 0x00391d6c at ue_attach_post_task+0x3c
#9 0x003826e0 at usb_process+0x10c
#10 0x004baa1c at fork_exit+0x7c
#11 0x00816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-32" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xa2b2cea0) locked @ 
/usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0x0056d388 at witness_debugger+0x64
#1 0x0056e518 at witness_warn+0x3ec
#2 0x00778f9c at uma_zalloc_debug+0x2c
#3 0x00778998 at uma_zalloc_arg+0x2c
#4 0x004d534c at malloc+0xa0
#5 0x0050ef3c at sysctl_add_oid+0x170
#6 0x9e415780 at ure_attach_post+0x1a78
#7 0x00391d6c at ue_attach_post_task+0x3c
#8 0x003826e0 at usb_process+0x10c
#9 0x004baa1c at fork_exit+0x7c
#10 0x00816544 at fork_trampoline+0x10
miibus0:  on ure0
rgephy0:  PHY 0 on miibus0
add hrgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
1000baseT-FDX, 1000baseT-FDX-master, auto
0 fib 0: route already iue0:  on ure0



The context here is an RPi4 (aarch64 cortex-a72) with:

# uname -apKU
FreeBSD RPi4B 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368500: Thu Dec 10 07:52:39 
UTC 2020 
r...@freebsd-head-aarch64-build.jail.ci.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC
  arm64 aarch64 1300131 1300131

The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
v1.21 materials, directly booting from the USB3 SSD, no microsd card
involved.


Some context in case it contributes something for the above
(probably not) . . .

The reason for the bisect was: such boot attempts fail to mount
route with my non-debug head -r368500 kernel