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

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 w

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

[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-

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

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 t

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

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

Re: git tools for building in base?

> 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

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

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'

Re: RISC-V root device question -> Panic

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 wor

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

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 b

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

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 e

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

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 in

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

> 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 Plas

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

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 updat