Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On Fri, Aug 31, 2018 at 12:21:02AM -0400, Michael Butler wrote: > On 8/29/18 7:40 PM, John Baldwin wrote: > > On 8/29/18 4:20 PM, Ian FREISLICH wrote: > >> Hi > >> > >> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP > >> at line 84. My system is UP so I'm not compiling an SMP kernel. > >> > >> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared > >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? > >> interrupt_sorted = mallocarray(num_io_irqs, > >> sizeof(*interrupt_sorted), > >> ^~~~ > >> interrupt_sources > >> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' > >> declared here > >> static struct intsrc **interrupt_sources; > >> ^ > >> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared > >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? > >> interrupt_sorted = mallocarray(num_io_irqs, > >> sizeof(*interrupt_sorted), > > > > Probably just needs #ifdef SMP around the mallocarray(). I'll test > > locallyon a UP kernel config. > > > > I see another problem after using Ian's workaround of moving the #ifdef > SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) > machine with only 512MB of RAM: > > Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed > Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed What is the kernel revision for "now". What was the previous revision where the kstack allocation failures did not happen. Also, what is the workload ? ___ 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: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
On 8/29/18 7:40 PM, John Baldwin wrote: > On 8/29/18 4:20 PM, Ian FREISLICH wrote: >> Hi >> >> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP >> at line 84. My system is UP so I'm not compiling an SMP kernel. >> >> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), >> ^~~~ >> interrupt_sources >> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' >> declared here >> static struct intsrc **interrupt_sources; >> ^ >> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), > > Probably just needs #ifdef SMP around the mallocarray(). I'll test locallyon > a UP kernel config. > I see another problem after using Ian's workaround of moving the #ifdef SMP; it seems I now run out of kernel stack on an i386 (Pentium-III) machine with only 512MB of RAM: Aug 29 23:29:19 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:26 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:30 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:38 sarah kernel: vm_thread_new: kstack allocation failed Aug 29 23:29:40 sarah kernel: vm_thread_new: kstack allocation failed imb ___ 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: r336921 broke booting on MBP 2017, EFIRT related
On Thu, Aug 30, 2018 at 12:22:36PM +0300, Yuri Pankov wrote: > Sorry, I accidentally took the discussion off-list, where Konstantin > provided some more patches. I'm attaching the one that finally worked > for me. It also adds some diagnostic prints which require bootverbose > to be enabled. This patch requires some more work to make it committable. Do not try to build it with efirt device in the kernel config, only efirt.ko works, but it can be preloaded from loader. ___ 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: 12-ALPHA3: (NanoBSD): ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by "libpcap.so.8"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Thu, 30 Aug 2018 10:44:25 -0500 Kyle Evans schrieb: > On Thu, Aug 30, 2018 at 10:41 AM O. Hartmann wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Running a NanoBSD with lots of "WITHOUT_" tags reducing the size, it seems > > that with > > one of those excluded build/install opts I also exclude a crucial library, > > namely > > "libibverbs.so.1", since ipfwpcap seems to require it: > > > > [...] > > root@host-puking-alot:~ # ipfwpcap > > ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by > > "libpcap.so.8" > > > > [...] > > > > Checking via ldd on "libpcap.so.8" reveals strange things: > > > > [...] > > root@host-puking-alot:~ # ldd /lib/libpcap.so.8 > > /lib/libpcap.so.8: > > libibverbs.so.1 => not found (0) > > libmlx5.so.1 => not found (0) > > libc.so.7 => /lib/libc.so.7 (0x80024a000) > > [...] > > > > So, I do not have any Mellanox device, therefore I do not build nor install > > drivers > > and or modules (refering to the libmlx5.so.1). > > > > You set WITHOUT_OFED=yes, right? That's a default now, so that'll stop > the dependency on ofed/ bits in libpcap. This is still breakage that > needs to be fixed, but that should workaround it for you. Yes, indeed I do. So, it is a well-known breakage? Good to know. Sometimes I get confused by OFED and Mellanox stuff - somehow there is no link between those to designators ;-) Thanks anyway, I'll enable via "WITH_OFED" the build and will see ... > > Thanks, > > Kyle Evans Regards, O. Hartmann - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4gUOAAKCRDS528fyFhY lNX1Af951ILatznC0l0NXH9Kpe83XnFjovVm7/IE+3kkGiXxk+lZvwNyTpER4JCo bq0x5ZixbjjpeRo0B/7zuRu5LXWVAf9NuXeGq6d92dMU6BxOXf+/iQtKZ82v6fby dP9vItUlk/QFgmsaBvYdedbhBkO2AkR1u29YdrJybIBqpn/FhTWD =JYf+ -END PGP SIGNATURE- ___ 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: 12-ALPHA3: (NanoBSD): ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by "libpcap.so.8"
On Thu, Aug 30, 2018 at 10:41 AM O. Hartmann wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Running a NanoBSD with lots of "WITHOUT_" tags reducing the size, it seems > that with one > of those excluded build/install opts I also exclude a crucial library, namely > "libibverbs.so.1", since ipfwpcap seems to require it: > > [...] > root@host-puking-alot:~ # ipfwpcap > ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by > "libpcap.so.8" > > [...] > > Checking via ldd on "libpcap.so.8" reveals strange things: > > [...] > root@host-puking-alot:~ # ldd /lib/libpcap.so.8 > /lib/libpcap.so.8: > libibverbs.so.1 => not found (0) > libmlx5.so.1 => not found (0) > libc.so.7 => /lib/libc.so.7 (0x80024a000) > [...] > > So, I do not have any Mellanox device, therefore I do not build nor install > drivers > and or modules (refering to the libmlx5.so.1). > You set WITHOUT_OFED=yes, right? That's a default now, so that'll stop the dependency on ofed/ bits in libpcap. This is still breakage that needs to be fixed, but that should workaround it for you. Thanks, Kyle Evans ___ 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"
12-ALPHA3: (NanoBSD): ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by "libpcap.so.8"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Running a NanoBSD with lots of "WITHOUT_" tags reducing the size, it seems that with one of those excluded build/install opts I also exclude a crucial library, namely "libibverbs.so.1", since ipfwpcap seems to require it: [...] root@host-puking-alot:~ # ipfwpcap ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by "libpcap.so.8" [...] Checking via ldd on "libpcap.so.8" reveals strange things: [...] root@host-puking-alot:~ # ldd /lib/libpcap.so.8 /lib/libpcap.so.8: libibverbs.so.1 => not found (0) libmlx5.so.1 => not found (0) libc.so.7 => /lib/libc.so.7 (0x80024a000) [...] So, I do not have any Mellanox device, therefore I do not build nor install drivers and or modules (refering to the libmlx5.so.1). The kernel is completely monolithic on that appliance in question - I do not allow the loading of kernel modules. I guess this is a bug or do I miss something here? Kind regards, oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4gQEQAKCRDS528fyFhY lCpuAf9AaMHdaAeAdkUjcZEihbQJSwXXHtubx9DHFE0jZXoQHEwCgMy9WFNuV+nj HXluOTCKvleEX1nGH1QgdO2GBGUsAgCdRzR2Iw7iHpQUfQ1cMHGijADLjeLSI6/4 GufHiu3K6ZYIsB1YWUPP/6SEduhYUAVACQpkNI7vMtdDOxQ0B4l2 =thgR -END PGP SIGNATURE- ___ 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: old top and new -current: missing arcstat sysctl
On Tue, Aug 28, 2018 at 08:40:15AM +0200, Alexander Leidinger wrote: > Hi, > > top reports missing sysctl kstat.zfs.misc.arcstats.other_size for > 12.0-alpha3 with a top from an old-ish -current. > > Is/will this be handled via a compat-11 sysctl (my kernel is without > compat-xx), or did this slip through? This should be fixed by r338395. ___ 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: r336921 broke booting on MBP 2017, EFIRT related
Rainer Hurling wrote:
Am 29.08.18 um 16:12 schrieb Kyle Evans:
On Wed, Aug 29, 2018 at 6:53 AM Yuri Pankov wrote:
Yuri Pankov wrote:
Konstantin Belousov wrote:
On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote:
Hi,
I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1,
20180802) fail to boot on MBP 2017:
kbd0 at kbdmux0
netmap: loaded module
nexus0
Fatal trap 12: page fault while in kernel mode
cpuid = 2: apic id = 02
fault virtual address = 0x74c64a50
fault code = supervisor read data, page not present
instruction pointer= 0x20: 0x7abece31
stack pointer = 0x28: 0x82b2f7c0
frame pointer = 0x28: 0x82b2f810
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process= 0 (swapper)
[ thread pid 0 tid 10 ]
Stopped at 0x7abece31:calll *0x18(%rax)
db>
Sadly, there's no support for internal keyboard yet (it's connected via
SPI), and external USB one stops working.
A (not so quick) bisect is pointing at r336921, which enabled EFIRT.
Some questions here:
- is this something that can/should be fixed?
- can we print some "enabling EFIRT" message to the console to make
guesses about the problem source a bit easier?
It is not in 'enabling'. Looking at the faulting VA, I believe that
it occurs inside the BIOS code.
Disable efirt by removing the kernel option, then try to load the module
at runtime. Does it still fault ? Also, get the efi mem map for the
machine and look at which region the faulting address and the faulting
instruction belong.
kldload'ing the efirt module gets the same fault. Several top lines of
backtrace:
kernphys() at 0x7abece31
efi_get_time() at efi_get_time+0xd9
efirtc_probe() at efirtc_probe+0x17
For the efi mem map, if I'm understanding it correctly, there's the
following:
...
BootServicesData 7421d000 0a8b UC WC WT WB
...
RuntimeServicesCode 7ab9f000 0070 UC WC WT WB
...
Hi,
I guess this patch might do it:
https://people.freebsd.org/~kevans/efi-bootmap.diff
Linux commit messages depict a tale in which they used to also only
map RUNTIME entries, but they were effectively forced to back down on
that because of buggy firmware that does exactly what you've described
and they later reintroduced the restrictive mapping for i386-only
where they'd not found such bugs.
Thanks,
Kyle Evans
Hi Kyle,
After Yuri had no success with the patches of kib, I tried your patch on
a DELL Latitude E6520 with BIOS version A21.
Sorry, I accidentally took the discussion off-list, where Konstantin
provided some more patches. I'm attaching the one that finally worked
for me. It also adds some diagnostic prints which require bootverbose
to be enabled.
diff --git a/sys/amd64/amd64/efirt_machdep.c b/sys/amd64/amd64/efirt_machdep.c
index da7783043a2..80ffa66f5ec 100644
--- a/sys/amd64/amd64/efirt_machdep.c
+++ b/sys/amd64/amd64/efirt_machdep.c
@@ -55,6 +55,7 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
+#include
#include
#include
#include
@@ -266,6 +267,7 @@ efi_arch_enter(void)
curpmap = PCPU_GET(curpmap);
PMAP_LOCK_ASSERT(curpmap, MA_OWNED);
+ curthread->td_md.md_efirt_dis_pf = vm_fault_disable_pagefaults();
/*
* IPI TLB shootdown handler invltlb_pcid_handler() reloads
@@ -300,6 +302,7 @@ efi_arch_leave(void)
curpmap->pm_pcids[PCPU_GET(cpuid)].pm_pcid : 0));
if (!pmap_pcid_enabled)
invltlb();
+ vm_fault_enable_pagefaults(curthread->td_md.md_efirt_dis_pf);
}
/* XXX debug stuff */
diff --git a/sys/amd64/amd64/efirt_support.S b/sys/amd64/amd64/efirt_support.S
new file mode 100644
index 000..82e5646e645
--- /dev/null
+++ b/sys/amd64/amd64/efirt_support.S
@@ -0,0 +1,105 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2018 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Konstantin Belousov
+ * under sponsorship from the FreeBSD Foundation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL
Re: r336921 broke booting on MBP 2017, EFIRT related
Am 29.08.18 um 16:12 schrieb Kyle Evans: > On Wed, Aug 29, 2018 at 6:53 AM Yuri Pankov wrote: >> >> Yuri Pankov wrote: >>> Konstantin Belousov wrote: On Wed, Aug 29, 2018 at 12:37:52PM +0300, Yuri Pankov wrote: > Hi, > > I've noticed that all recent snapshots (ALPHA3, ALPHA2, ALPHA1, > 20180802) fail to boot on MBP 2017: > > kbd0 at kbdmux0 > netmap: loaded module > nexus0 > > Fatal trap 12: page fault while in kernel mode > cpuid = 2: apic id = 02 > fault virtual address = 0x74c64a50 > fault code = supervisor read data, page not present > instruction pointer= 0x20: 0x7abece31 > stack pointer = 0x28: 0x82b2f7c0 > frame pointer = 0x28: 0x82b2f810 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process= 0 (swapper) > [ thread pid 0 tid 10 ] > Stopped at 0x7abece31:calll *0x18(%rax) > db> > > Sadly, there's no support for internal keyboard yet (it's connected via > SPI), and external USB one stops working. > > A (not so quick) bisect is pointing at r336921, which enabled EFIRT. > > Some questions here: > - is this something that can/should be fixed? > - can we print some "enabling EFIRT" message to the console to make > guesses about the problem source a bit easier? It is not in 'enabling'. Looking at the faulting VA, I believe that it occurs inside the BIOS code. Disable efirt by removing the kernel option, then try to load the module at runtime. Does it still fault ? Also, get the efi mem map for the machine and look at which region the faulting address and the faulting instruction belong. >>> >>> kldload'ing the efirt module gets the same fault. Several top lines of >>> backtrace: >>> >>> kernphys() at 0x7abece31 >>> efi_get_time() at efi_get_time+0xd9 >>> efirtc_probe() at efirtc_probe+0x17 >> >> For the efi mem map, if I'm understanding it correctly, there's the >> following: >> >> ... >> BootServicesData 7421d000 0a8b UC WC WT WB >> ... >> RuntimeServicesCode 7ab9f000 0070 UC WC WT WB >> ... >> > > Hi, > > I guess this patch might do it: > https://people.freebsd.org/~kevans/efi-bootmap.diff > > Linux commit messages depict a tale in which they used to also only > map RUNTIME entries, but they were effectively forced to back down on > that because of buggy firmware that does exactly what you've described > and they later reintroduced the restrictive mapping for i386-only > where they'd not found such bugs. > > Thanks, > > Kyle Evans Hi Kyle, After Yuri had no success with the patches of kib, I tried your patch on a DELL Latitude E6520 with BIOS version A21. Kernel config file contains OPTIONS EFIRT, efi.rt.disabled is commented out in /boot/loader.conf. Unfortunately, it also does not work. My trap message is this: [..snip..] netmap: loaded module kbd1 at kbdmux0 nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 390.77 Tue Jul. 10 21:54:30 PDT 2018 nexus0 Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address = 0xce09ee60 fault code = supervisor read data, page not present instruction pointer= 0x20: 0xcf58334d stack pointer = 0x28: 0x83252920 frame pointer = 0x28: 0x832529a0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 0 (swapper) trap number= 12 panic: page fault cpuid = 0 time = 1 Uptime: 1s Automatic reboot in 15 seconds ... Regards, Rainer Hurling ___ 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"
