syslogd dumps core on amd64 cuurent - working now
I rebuilt world and it is working now ___ 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"
syslogd dumps core on amd64 cuurent
Todays change to syslogd.c causes it to dump core on starting:
(syslogd)5014}/etc/rc.d/syslogd stop
Stopping syslogd.
Waiting for PIDS: 731.
(syslogd)5015}make install
install -s -o root -g wheel -m 555 syslogd /usr/sbin/syslogd
install -o root -g wheel -m 444 syslog.conf.5.gz /usr/share/man/man5/
install -o root -g wheel -m 444 syslogd.8.gz /usr/share/man/man8/
(syslogd)5016}/etc/rc.d/syslogd start
Starting syslogd.
syslogd: child pid 21052 exited on signal 4 (core dumped)
/etc/rc.d/syslogd: WARNING: failed to start syslogd
(syslogd)5017}
the change was to the file syslogd.c :
--- syslogd.c 2016-11-26 19:14:55.086134000 -0800
+++ syslogd.c.new 2016-11-26 07:58:53.382705000 -0800
@@ -1835,6 +1835,7 @@
free((char *)f);
}
Files = NULL;
+ *nextp = NULL;
/* open the configuration file */
if ((cf = fopen(ConfFile, "r")) == NULL) {
___
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: NFSv4 performance degradation with 12.0-CURRENT client
Alan Somers wrote: [stuff snipped] >Mounting nullfs with the nocache option, ad kib suggested, fixed the >problem. Also, applying kib's patch and then mounting nullfs with >default options also fixed the problem. Here is the nfsstat output >for "ls -al" when using kib's patch. Notice the client has far fewer >opens: I did a quick test which confirmed that the opens get closed when the "nocache" option is used on the nullfs mount as well. Kostik, I think your patch is a good idea and you can consider it reviewed by me if you'd like. I also did a quick test wth unionfs and it did not accumulate opens, so it doesn't seem to suffer from this problem. (It does have issues, as noted by the BUGS section of the mount_unionfs man page.) rick ___ 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: NFSv4 performance degradation with 12.0-CURRENT client
Konstantin Belousov wrote:
[stuff snipped]
>I thought that the issue was in tracking any opens and mmaps, but from this
>reply it is not that clear. Do you need callback when all opens and mmaps
>have ended, or only opens and mmaps for write ? If later, we already have
>a suitable mechanism VOP_ADD_WRITECOUNT().
Not quite. The NFSv4 client needs to Close the NFSv4 Open after all I/O on
the file has been done. This applies to both reads and writes.
Since mmap'd files can generate I/O after the VOP_CLOSE(), the NFSv4 client
can't do the NFSv4 Close in VOP_CLOSE().
Since it can't do it then, it waits until VOP_INACTIVE() to do the NFSv4 Close.
This might be improved by:
- A flag that indicates that an open file descriptor has been mmap()d, which
VOP_CLOSE() could check to decide if it can do the NFSv4 Close.
(ie. It could do the NFSv4 Close if the file descriptor hasn't been mmap()d.)
- If the system knows when mmap()d I/O is done (the process has terminated?),
it could do a VOP_MMAP_IO_DONE() and the NFSv4 client would do the NFSv4 Close
in it.
--> I don't know if this is feasible and I suspect if it could be done, that
it would
usually happen just before VOP_INACTIVE(). { This case of nullfs
caching was an
exception, I think? }
Does this clarify it? rick
___
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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 01:55:14PM -0800, Adrian Chadd wrote: > ok, hm. then i don' know offhand, not without putting in printf debugging. :) I am not expert in this code, I am need you patches for printf debugging. > On 26 November 2016 at 13:51, Slawa Olhovchenkov wrote: > > On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > > > >> Ok. So boot verbose and let's see what it says. > > > > See first message: it's already verbose boot. > > Yes, only 3 lines. > > > >> > >> On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > >> > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > >> > > >> >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > >> >> > >> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > >> >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > >> >> locality stuff. > >> > > >> > I am use r308809 of HEAD. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
ok, hm. then i don' know offhand, not without putting in printf debugging. :) -a On 26 November 2016 at 13:51, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > >> Ok. So boot verbose and let's see what it says. > > See first message: it's already verbose boot. > Yes, only 3 lines. > >> >> On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: >> > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: >> > >> >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . >> >> >> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and >> >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other >> >> locality stuff. >> > >> > I am use r308809 of HEAD. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > Ok. So boot verbose and let's see what it says. See first message: it's already verbose boot. Yes, only 3 lines. > > On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > > > >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > >> > >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > >> locality stuff. > > > > I am use r308809 of HEAD. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
Ok. So boot verbose and let's see what it says. -adrian On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . >> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other >> locality stuff. > > I am use r308809 of HEAD. ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > > I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > locality stuff. I am use r308809 of HEAD. ___ 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 with some recent changes (between r309016 and r309184)
Is this known? The traceback: panic: vm_page_assert_xbusied: page 0xf807fae225b0 not exclusive busy @ /usr/src/sys/vm/vm_pager.c:263 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0a528ea620 vpanic() at vpanic+0x186/frame 0xfe0a528ea6a0 kassert_panic() at kassert_panic+0x126/frame 0xfe0a528ea710 vm_pager_assert_in() at vm_pager_assert_in+0x6f/frame 0xfe0a528ea740 vm_pager_get_pages_async() at vm_pager_get_pages_async+0x26/frame 0xfe0a528ea780 vn_sendfile() at vn_sendfile+0xc85/frame 0xfe0a528ea9e0 sys_sendfile() at sys_sendfile+0x11a/frame 0xfe0a528eaa70 amd64_syscall() at amd64_syscall+0x2f9/frame 0xfe0a528eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0a528eabf0 --- syscall (393, FreeBSD ELF64, sys_sendfile), rip = 0x8040eb47a, rsp = 0x7fffea58, rbp = 0x7fffeb00 --- KDB: enter: panic Cheers, signature.asc Description: OpenPGP digital signature
boot fails on Table SSDT at 0x...
Hi curr...@freebsd.org I was running FreeBSD lapr.js.berklix.net 12.0-CURRENT FreeBSD 12.0-CURRENT #12753: Tue Nov 22 23:31:24 CET 2016 j...@lapr.js.berklix.net:/data/release/12.0-CURRENT/usr/src/sys/amd64/compile/LAPR.small amd64 I updated to .ctm_status src-cur 12757 .svn_revision 309126 did a make world, built a new custom kernel with same config as before & now laptop boot fails after Table SSDT at 0x... ACPI: No SRAT table found I took a pic of frozen screen, & I have svn here, I need to research & provide more info to whoever ? so this just initial info to whoever's working in the area. Debug suggestions & syntax welcome. I'll build a generic kernel next. If I may be slow responding, sorry, DSL modem problems here too, hence getting an initial error report out while I can. Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
The ACPI SRAT parsing code - sys/x86/acpica/srat.c . I'd start by enabling bootverbose - adds one echo (SLIT.Localities and the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other locality stuff. -adrian On 26 November 2016 at 09:37, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 09:35:08AM -0800, Adrian Chadd wrote: > >> It may be something to do with memory topology parsing. Maybe we need >> some more debugging there to try and catch it. > > What debug you need? > >> On 26 November 2016 at 01:21, Slawa Olhovchenkov wrote: >> > I am try to enable NUMA in bios and can't boot FreeBSD. >> > Boot stoped after next messages: >> > >> > === >> > Booting... >> > KDB: debugger backends: ddb >> > KDB: current backend: ddb >> > === >> > >> > This is verbose boot. >> > No reaction to ~^B, NMI. >> > >> > Same for head and 10.3-RELEASE. >> > >> > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. >> > >> > On slight different hardware >> > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) >> > 10.3 boot ok w/ BIOS NUMA enabled. >> > >> > ___ >> > 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 09:35:08AM -0800, Adrian Chadd wrote: > It may be something to do with memory topology parsing. Maybe we need > some more debugging there to try and catch it. What debug you need? > On 26 November 2016 at 01:21, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > ___ > > 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: Enabling NUMA in BIOS stop booting FreeBSD
It may be something to do with memory topology parsing. Maybe we need some more debugging there to try and catch it. -a On 26 November 2016 at 01:21, Slawa Olhovchenkov wrote: > I am try to enable NUMA in bios and can't boot FreeBSD. > Boot stoped after next messages: > > === > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > === > > This is verbose boot. > No reaction to ~^B, NMI. > > Same for head and 10.3-RELEASE. > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > On slight different hardware > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > 10.3 boot ok w/ BIOS NUMA enabled. > > ___ > 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 07:07:20PM +0300, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > Boot stoped after next messages: > > > > > > === > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > So at least the hammer_time() has a chance to initialize the console. > > Do you have serial console ? Set the loader tunable debug.late_console > > Via ipmi sol > > > to 1 and see if any NMI reaction appear. > > I am try this late. > > > > === > > > > > > This is verbose boot. > > > No reaction to ~^B, NMI. > > > > > > Same for head and 10.3-RELEASE. > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > No > > > What if you try to frob it ? > > > > > > > > On slight different hardware > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > so you can start bisect the code from there. > > > > I am not expert in this code. I am think code halted in later getmemsize() (or before it), I am don't see any messages from init_ops.parse_memmap()/native_parse_memmap(). ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > So at least the hammer_time() has a chance to initialize the console. > Do you have serial console ? Set the loader tunable debug.late_console Via ipmi sol > to 1 and see if any NMI reaction appear. I am try this late. > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? No > What if you try to frob it ? > > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > I think the only way to debug this is to add printf() lines to hammer_time() > to see where does it break. Note that amd64_kdb_init() call succeeded, > so you can start bisect the code from there. > I am not expert in this 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > So at least the hammer_time() has a chance to initialize the console. > Do you have serial console ? Set the loader tunable debug.late_console > to 1 and see if any NMI reaction appear. Err, sorry. Set it to 0. > > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > What if you try to frob it ? > > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > I think the only way to debug this is to add printf() lines to hammer_time() > to see where does it break. Note that amd64_kdb_init() call succeeded, > so you can start bisect the code from there. > ___ 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: Enabling NUMA in BIOS stop booting FreeBSD
On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > I am try to enable NUMA in bios and can't boot FreeBSD. > Boot stoped after next messages: > > === > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb So at least the hammer_time() has a chance to initialize the console. Do you have serial console ? Set the loader tunable debug.late_console to 1 and see if any NMI reaction appear. > === > > This is verbose boot. > No reaction to ~^B, NMI. > > Same for head and 10.3-RELEASE. > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? What if you try to frob it ? > > On slight different hardware > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > 10.3 boot ok w/ BIOS NUMA enabled. I think the only way to debug this is to add printf() lines to hammer_time() to see where does it break. Note that amd64_kdb_init() call succeeded, so you can start bisect the code from there. ___ 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"
Enabling NUMA in BIOS stop booting FreeBSD
I am try to enable NUMA in bios and can't boot FreeBSD. Boot stoped after next messages: === Booting... KDB: debugger backends: ddb KDB: current backend: ddb === This is verbose boot. No reaction to ~^B, NMI. Same for head and 10.3-RELEASE. Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. On slight different hardware (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) 10.3 boot ok w/ BIOS NUMA enabled. ___ 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"
