Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On 6/11/20 10:19, Mark Johnston wrote: > On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote: >> On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote: >>> ... >>> This should fix noexec for modules. >>> >>> diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c >>> index 81db4d7ca85..cb84fc95691 100644 >>> --- a/sys/x86/x86/mp_x86.c >>> +++ b/sys/x86/x86/mp_x86.c >>> >> >> Thanks! Patch applied with no problems; I will plan on rebooting to >> head & rebuilding & smoke-testing once I get some more work-stuff done. > > I was able to verify that the patch fixes my instance of the panic. I can confirm that the patch also fixed my panic too. Thanks! Cheers, signature.asc Description: OpenPGP digital signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 01:19:33PM -0400, Mark Johnston wrote: > On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote: > > On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote: > > > ... > > > This should fix noexec for modules. > > > > > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > > > index 81db4d7ca85..cb84fc95691 100644 > > > --- a/sys/x86/x86/mp_x86.c > > > +++ b/sys/x86/x86/mp_x86.c > > > > > > > Thanks! Patch applied with no problems; I will plan on rebooting to > > head & rebuilding & smoke-testing once I get some more work-stuff done. > > I was able to verify that the patch fixes my instance of the panic. Works for my laptop, as well: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r362045M/362046: Thu Jun 11 10:57:18 PDT 2020 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300097 1300097 Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote: > > ... > > This should fix noexec for modules. > > > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > > index 81db4d7ca85..cb84fc95691 100644 > > --- a/sys/x86/x86/mp_x86.c > > +++ b/sys/x86/x86/mp_x86.c > > > > Thanks! Patch applied with no problems; I will plan on rebooting to > head & rebuilding & smoke-testing once I get some more work-stuff done. I was able to verify that the patch fixes my instance of the panic. ___ 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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote: > ... > This should fix noexec for modules. > > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c > index 81db4d7ca85..cb84fc95691 100644 > --- a/sys/x86/x86/mp_x86.c > +++ b/sys/x86/x86/mp_x86.c > Thanks! Patch applied with no problems; I will plan on rebooting to head & rebuilding & smoke-testing once I get some more work-stuff done. Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 09:33:31AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote:
> > ...
> > > Unfortunately, I ran out of time to do further experiments for now; I'll
> > > need to do some work-related things for a while, but thought that this
> > > might at least provide some useful information.
> > >
> > > Here is what I commented out:
> > >
> > > g1-55(12.1-S)[2] grep KIB boot/loader.conf
> > > # KIB coretemp_load="YES"
> > > # KIB iwn5000fw_load="YES"
> > > # KIB linux_load="YES"
> > > # KIB nvidia-modeset_load="YES"
> > > # KIB cuse_load="YES"
> > > # KIB geom_eli_load="YES"
> > > # KIB filemon_load="YES"
> >
> > Thanks. I'm able to reproduce a somewhat similar problem in bhyve: if I
> > preload iwn5000fw.ko, a r362045 kernel fails to boot very early with
> >
> > ---<>---
> > ACPI: Failed to map RSDT
> > APIC: Could not find any APICs.
> > panic: running without device atpic requires a local APIC
>
> Ah -- excellent (that you are able to pretty much reproduce this). And
> it explains why my build machine wasn't affected: it doesn't use
> wireless drivers at all.
>
> > Reverting r362035 allows the kernel to boot again, but so does adding a
> > few printf() calls to the pmap and ACPI code.
>
> Kinky. :-}
This should fix noexec for modules.
diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
index 81db4d7ca85..cb84fc95691 100644
--- a/sys/x86/x86/mp_x86.c
+++ b/sys/x86/x86/mp_x86.c
@@ -1698,7 +1698,7 @@ smp_targeted_tlb_shootdown(cpuset_t mask, u_int vector,
pmap_t pmap,
int cpu;
/* It is not necessary to signal other CPUs while in the debugger. */
- if (kdb_active || KERNEL_PANICKED()) {
+ if (kdb_active || KERNEL_PANICKED() || !smp_started) {
curcpu_cb(pmap, addr1, addr2);
return;
}
@@ -1759,13 +1759,10 @@ void
smp_masked_invltlb(cpuset_t mask, pmap_t pmap, smp_invl_cb_t curcpu_cb)
{
- if (smp_started) {
- smp_targeted_tlb_shootdown(mask, IPI_INVLTLB, pmap, 0, 0,
- curcpu_cb);
+ smp_targeted_tlb_shootdown(mask, IPI_INVLTLB, pmap, 0, 0, curcpu_cb);
#ifdef COUNT_XINVLTLB_HITS
- ipi_global++;
+ ipi_global++;
#endif
- }
}
void
@@ -1773,13 +1770,10 @@ smp_masked_invlpg(cpuset_t mask, vm_offset_t addr,
pmap_t pmap,
smp_invl_cb_t curcpu_cb)
{
- if (smp_started) {
- smp_targeted_tlb_shootdown(mask, IPI_INVLPG, pmap, addr, 0,
- curcpu_cb);
+ smp_targeted_tlb_shootdown(mask, IPI_INVLPG, pmap, addr, 0, curcpu_cb);
#ifdef COUNT_XINVLTLB_HITS
- ipi_page++;
+ ipi_page++;
#endif
- }
}
void
@@ -1787,24 +1781,20 @@ smp_masked_invlpg_range(cpuset_t mask, vm_offset_t
addr1, vm_offset_t addr2,
pmap_t pmap, smp_invl_cb_t curcpu_cb)
{
- if (smp_started) {
- smp_targeted_tlb_shootdown(mask, IPI_INVLRNG, pmap,
- addr1, addr2, curcpu_cb);
+ smp_targeted_tlb_shootdown(mask, IPI_INVLRNG, pmap, addr1, addr2,
+ curcpu_cb);
#ifdef COUNT_XINVLTLB_HITS
- ipi_range++;
- ipi_range_size += (addr2 - addr1) / PAGE_SIZE;
+ ipi_range++;
+ ipi_range_size += (addr2 - addr1) / PAGE_SIZE;
#endif
- }
}
void
smp_cache_flush(smp_invl_cb_t curcpu_cb)
{
- if (smp_started) {
- smp_targeted_tlb_shootdown(all_cpus, IPI_INVLCACHE, NULL,
- 0, 0, curcpu_cb);
- }
+ smp_targeted_tlb_shootdown(all_cpus, IPI_INVLCACHE, NULL, 0, 0,
+ curcpu_cb);
}
/*
___
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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote: > ... > > Unfortunately, I ran out of time to do further experiments for now; I'll > > need to do some work-related things for a while, but thought that this > > might at least provide some useful information. > > > > Here is what I commented out: > > > > g1-55(12.1-S)[2] grep KIB boot/loader.conf > > # KIB coretemp_load="YES" > > # KIB iwn5000fw_load="YES" > > # KIB linux_load="YES" > > # KIB nvidia-modeset_load="YES" > > # KIB cuse_load="YES" > > # KIB geom_eli_load="YES" > > # KIB filemon_load="YES" > > Thanks. I'm able to reproduce a somewhat similar problem in bhyve: if I > preload iwn5000fw.ko, a r362045 kernel fails to boot very early with > > ---<>--- > ACPI: Failed to map RSDT > APIC: Could not find any APICs. > panic: running without device atpic requires a local APIC Ah -- excellent (that you are able to pretty much reproduce this). And it explains why my build machine wasn't affected: it doesn't use wireless drivers at all. > Reverting r362035 allows the kernel to boot again, but so does adding a > few printf() calls to the pmap and ACPI code. Kinky. :-} Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote: > On Thu, Jun 11, 2020 at 09:11:56AM -0700, David Wolfskill wrote: > > On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote: > > > ... > > > Can you boot into single-user, without loading linux/cuse/nvidia modules. > > > Even, do not load any module at all, and keeping root ro. > > > > > > If boot succeed, then try to load modules one by one and see which causes > > > panic. > > > > I commented out each of the "*_load" directives in /boot/loader.conf; > > rebooted; escaped to loader (from the boot menu); used "lsmod" to verify > > that nothing was loaded at that time, then issued "boot -s" -- which did > > succeed. > > > > Unfortunately, I ran out of time to do further experiments for now; I'll > > need to do some work-related things for a while, but thought that this > > might at least provide some useful information. > > > > Here is what I commented out: > > > > g1-55(12.1-S)[2] grep KIB boot/loader.conf > > # KIB coretemp_load="YES" > > # KIB iwn5000fw_load="YES" > > # KIB linux_load="YES" > > # KIB nvidia-modeset_load="YES" > > # KIB cuse_load="YES" > > # KIB geom_eli_load="YES" > > # KIB filemon_load="YES" > > Thanks. I'm able to reproduce a somewhat similar problem in bhyve: if I > preload iwn5000fw.ko, a r362045 kernel fails to boot very early with > > ---<>--- > ACPI: Failed to map RSDT > APIC: Could not find any APICs. > panic: running without device atpic requires a local APIC > > Reverting r362035 allows the kernel to boot again, but so does adding a > few printf() calls to the pmap and ACPI code. I have some private report that this is caused by r362031. Can you confirm that reverting it helps ? If yes, please show me the output of sysctl vm.pmap. ___ 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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 09:11:56AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote: > > ... > > Can you boot into single-user, without loading linux/cuse/nvidia modules. > > Even, do not load any module at all, and keeping root ro. > > > > If boot succeed, then try to load modules one by one and see which causes > > panic. > > I commented out each of the "*_load" directives in /boot/loader.conf; > rebooted; escaped to loader (from the boot menu); used "lsmod" to verify > that nothing was loaded at that time, then issued "boot -s" -- which did > succeed. > > Unfortunately, I ran out of time to do further experiments for now; I'll > need to do some work-related things for a while, but thought that this > might at least provide some useful information. > > Here is what I commented out: > > g1-55(12.1-S)[2] grep KIB boot/loader.conf > # KIB coretemp_load="YES" > # KIB iwn5000fw_load="YES" > # KIB linux_load="YES" > # KIB nvidia-modeset_load="YES" > # KIB cuse_load="YES" > # KIB geom_eli_load="YES" > # KIB filemon_load="YES" Thanks. I'm able to reproduce a somewhat similar problem in bhyve: if I preload iwn5000fw.ko, a r362045 kernel fails to boot very early with ---<>--- ACPI: Failed to map RSDT APIC: Could not find any APICs. panic: running without device atpic requires a local APIC Reverting r362035 allows the kernel to boot again, but so does adding a few printf() calls to the pmap and ACPI code. ___ 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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote: > ... > Can you boot into single-user, without loading linux/cuse/nvidia modules. > Even, do not load any module at all, and keeping root ro. > > If boot succeed, then try to load modules one by one and see which causes > panic. I commented out each of the "*_load" directives in /boot/loader.conf; rebooted; escaped to loader (from the boot menu); used "lsmod" to verify that nothing was loaded at that time, then issued "boot -s" -- which did succeed. Unfortunately, I ran out of time to do further experiments for now; I'll need to do some work-related things for a while, but thought that this might at least provide some useful information. Here is what I commented out: g1-55(12.1-S)[2] grep KIB boot/loader.conf # KIB coretemp_load="YES" # KIB iwn5000fw_load="YES" # KIB linux_load="YES" # KIB nvidia-modeset_load="YES" # KIB cuse_load="YES" # KIB geom_eli_load="YES" # KIB filemon_load="YES" :-) Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 08:44:56AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 04:46:58PM +0300, Konstantin Belousov wrote: > > ... > > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I > > > can certainly clean out /usr/obj/* & start a new build (just before I > > > head out for a bike ride). > > > > That, and also rebuild all third-party modules you use. Definitely nvidia. > > I always do, via "PORTS_MODULES=x11/nvidia-driver" in /etc/src.conf. > > Anyway: After "rm -fr /usr/obj/*", I started a fresh build, went on the > bike ride, came back, and the build/install had completed without issue. > > I rebooted, and ... the resulting panic looked identical to me; I have > copied the new screenshots to the same places. Can you boot into single-user, without loading linux/cuse/nvidia modules. Even, do not load any module at all, and keeping root ro. If boot succeed, then try to load modules one by one and see which causes panic. ___ 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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 10:42:59AM -0400, Mark Johnston wrote: > ... > Since you are preloading some iwm firmware file, it might be worth > trying to revert r362035. I don't really see how the change could > result in this panic, though. It's iwn (vs. iwm), but sure, I'll try that as time permits -- I need to check in at work and do work-related stuff for a bit. (And since I use the laptop for accessing just about everything, I'll need to wait a bit on trying that.) Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 04:46:58PM +0300, Konstantin Belousov wrote: > ... > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I > > can certainly clean out /usr/obj/* & start a new build (just before I > > head out for a bike ride). > > That, and also rebuild all third-party modules you use. Definitely nvidia. I always do, via "PORTS_MODULES=x11/nvidia-driver" in /etc/src.conf. Anyway: After "rm -fr /usr/obj/*", I started a fresh build, went on the bike ride, came back, and the build/install had completed without issue. I rebooted, and ... the resulting panic looked identical to me; I have copied the new screenshots to the same places. Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
Op 11-06-2020 om 15:21 schreef Konstantin Belousov: On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote: Build machine (mini-tower) performed the update (r362008 -> r362045) without issue, but my laptop panicked quite early on -- before the dump device was configured. I have taken and placed a couple of screen shots in http://www.catwhisker.org/~david/FreeBSD/head/r362045/ Looking at the displayed backtrace, I see: --- trap 0xc ... futex_xchgl_reslover() elf_reloc_internal() link_elf_reloc_local() link_elf_link_preload_finish() linker_preload() mi_startup() Any clues? I'm hapy to poke at it or try patches. Booting from kernel.old (r362008) still works: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #46 r362008M/362008: Wed Jun 10 04:19:33 PDT 2020 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300097 1300097 The link times out. There is not much to access in futex_xchgl_resolver() except for the data segment. Without full panic message and disassemble of your instance of futex_xchgl_resolver() it is not possible to ee what is going on. Just in case, can you try clean build, if you did -DNO_CLEAN ? Just a me too. I updated from 362042 to 362053 I get this panic very early. (hand typed so could contain some typo's) FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc1-0-gf79cd71e145 VT(vgs): resolution 640x480 kernel trap 12 with interupts disabled panic: vm_fault_lookup: fault on nofault entry, addr: 0x83a3d000 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x83a65830 vpanic() at vpanic+0x182/frame 0x83a65880 panic() ata panic+0x43/frame 0x83a658e00 vm_fault() at vm_fault+0x1ab5/frame 0x83a659f0 vm_fault_trap() at vam_fault_trap+0x6-/frame 0x83a65a30 trap_pfault at trap_pfault+0x19c/frame 0x83a65a80 trap() at trap+0x271/frame 0x8365b90 calltrap() at calltrap+0x8/frame 0x83a65b90 --- trap 0xc, rip = 0x83a3d470, rsp = 0x83a65c68, rbp = 0x83a65cb0 --- opensolaris_utsname_init() at opensolaris_utsname_init/frame 0x83a65cb0btext() at btext+0x2c KDB: enter : panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x37: movq $0,0x1fc1686(%rip) db> ___ 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
Op 11-06-2020 om 15:21 schreef Konstantin Belousov: On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote: Build machine (mini-tower) performed the update (r362008 -> r362045) without issue, but my laptop panicked quite early on -- before the dump device was configured. I have taken and placed a couple of screen shots in http://www.catwhisker.org/~david/FreeBSD/head/r362045/ Looking at the displayed backtrace, I see: --- trap 0xc ... futex_xchgl_reslover() elf_reloc_internal() link_elf_reloc_local() link_elf_link_preload_finish() linker_preload() mi_startup() Any clues? I'm hapy to poke at it or try patches. Booting from kernel.old (r362008) still works: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #46 r362008M/362008: Wed Jun 10 04:19:33 PDT 2020 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300097 1300097 The link times out. There is not much to access in futex_xchgl_resolver() except for the data segment. Without full panic message and disassemble of your instance of futex_xchgl_resolver() it is not possible to ee what is going on. Just in case, can you try clean build, if you did -DNO_CLEAN ? Just a me too. I updated from 362042 -> 362053 I get this panic very early. (hand typed so could contain some typo's) FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc1-0-gf79cd71e145 VT(vgs): resolution 640x480 kernel trap 12 with interupts disabled panic: vm_fault_lookup: fault on nofault entry, addr: 0x83a3d000 cpuid = 0 time = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x83a65830 vpanic() at vpanic+0x182/frame 0x83a65880 panic() ata panic+0x43/frame 0x83a658e00 vm_fault() at vm_fault+0x1ab5/frame 0x83a659f0 vm_fault_trap() at vam_fault_trap+0x6-/frame 0x83a65a30 trap_pfault at trap_pfault+0x19c/frame 0x83a65a80 trap() at trap+0x271/frame 0x8365b90 calltrap() at calltrap+0x8/frame 0x83a65b90 --- trap 0xc, rip = 0x83a3d470, rsp = 0x83a65c68, rbp = 0x83a65cb0 --- opensolaris_utsname_init() at opensolaris_utsname_init/frame 0x83a65cb0btext() at btext+0x2c KDB: enter : panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x37: movq $0,0x1fc1686(%rip) db> ___ 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@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 06:29:24AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote: > > ... > > The link times out. > > Sigh. Sorry about that; I have copied the images to > freefall:~dhw/head/r362045/ . > > > There is not much to access in futex_xchgl_resolver() except for the > > data segment. Without full panic message and disassemble of your instance > > of futex_xchgl_resolver() it is not possible to ee what is going on. > > > > Just in case, can you try clean build, if you did -DNO_CLEAN ? > > > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I > can certainly clean out /usr/obj/* & start a new build (just before I > head out for a bike ride). Since you are preloading some iwm firmware file, it might be worth trying to revert r362035. I don't really see how the change could result in this panic, though. ___ 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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 06:29:24AM -0700, David Wolfskill wrote: > On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote: > > ... > > The link times out. > > Sigh. Sorry about that; I have copied the images to > freefall:~dhw/head/r362045/ . > > > There is not much to access in futex_xchgl_resolver() except for the > > data segment. Without full panic message and disassemble of your instance > > of futex_xchgl_resolver() it is not possible to ee what is going on. > > > > Just in case, can you try clean build, if you did -DNO_CLEAN ? > > > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I > can certainly clean out /usr/obj/* & start a new build (just before I > head out for a bike ride). That, and also rebuild all third-party modules you use. Definitely nvidia. ___ 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: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote: > ... > The link times out. Sigh. Sorry about that; I have copied the images to freefall:~dhw/head/r362045/ . > There is not much to access in futex_xchgl_resolver() except for the > data segment. Without full panic message and disassemble of your instance > of futex_xchgl_resolver() it is not possible to ee what is going on. > > Just in case, can you try clean build, if you did -DNO_CLEAN ? > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I can certainly clean out /usr/obj/* & start a new build (just before I head out for a bike ride). Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote: > Build machine (mini-tower) performed the update (r362008 -> r362045) > without issue, but my laptop panicked quite early on -- before the dump > device was configured. > > I have taken and placed a couple of screen shots in > http://www.catwhisker.org/~david/FreeBSD/head/r362045/ > > Looking at the displayed backtrace, I see: > > --- trap 0xc ... > futex_xchgl_reslover() > elf_reloc_internal() > link_elf_reloc_local() > link_elf_link_preload_finish() > linker_preload() > mi_startup() > > Any clues? I'm hapy to poke at it or try patches. > > Booting from kernel.old (r362008) still works: > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #46 > r362008M/362008: Wed Jun 10 04:19:33 PDT 2020 > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1300097 1300097 The link times out. There is not much to access in futex_xchgl_resolver() except for the data segment. Without full panic message and disassemble of your instance of futex_xchgl_resolver() it is not possible to ee what is going on. Just in case, can you try clean build, if you did -DNO_CLEAN ? ___ 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"
Panic "vm_fault_lookup: fault on nofault entry" amd64 r362008 -> r362045
Build machine (mini-tower) performed the update (r362008 -> r362045) without issue, but my laptop panicked quite early on -- before the dump device was configured. I have taken and placed a couple of screen shots in http://www.catwhisker.org/~david/FreeBSD/head/r362045/ Looking at the displayed backtrace, I see: --- trap 0xc ... futex_xchgl_reslover() elf_reloc_internal() link_elf_reloc_local() link_elf_link_preload_finish() linker_preload() mi_startup() Any clues? I'm hapy to poke at it or try patches. Booting from kernel.old (r362008) still works: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #46 r362008M/362008: Wed Jun 10 04:19:33 PDT 2020 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300097 1300097 Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Someone who suggests he can "pardon himself" calls for "LAW & ORDER" -- right. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
