Re: FreeBSD has a politics problem
Hi, On Sun, 18 Mar 2018 06:43:47 +0100 "Meixner, Johannes" wrote: > You must have never been to Southern Germany or Austria. and Alaska. Erich ___ 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"
network performance over 1GBps links degraded
I have two computers, both with 1Gbps interfaces plugged into a 1Gb switch. One computer is running FreeBSD HEAD and the other some version of Linux. Under FreeBSD I have re0 and under Linux I don't know what the hardware is. Both interfaces are using a MTU of 4088 because that's the maximum my re0 supports. I tend to copy files from one to the other using ftp fairly frequently. I noticed that the transfer speed has dropped to only about 12MBps. I'm used to seeing about 27MBps during the ftp transfers. I also observed the drop in transfer speed between FreeBSD and a Windows 10 computer. Formerly, I was seeing about 30MBps. Windows 10 also has MTU 4088 set. I tested with a FreeBSD kernel from March 7 and one from March 17, but both show the miserable performance. Unfortunately, I don't have any older kernels backed up. I can't say exactly when the performance degraded, but possibly there was some change to the kernel on or before March 7 which caused it. Has anyone else seen this? There were several changes to the networking stack lately. I wonder whether anyone has an idea what could be the cause of the performance degredation, and what sysctls I could set to get the old performance back. -- Gary Jennejohn ___ 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: network performance over 1GBps links degraded
Gary Jennejohn wrote: > I have two computers, both with 1Gbps interfaces plugged into a > 1Gb switch. One computer is running FreeBSD HEAD and the other > some version of Linux. Under FreeBSD I have re0 and under Linux > I don't know what the hardware is. > > I noticed that the transfer speed has dropped to only about > 12MBps. I'm used to seeing about 27MBps during the ftp > transfers. Do you see "re0: watchdog timeout" errors? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 -- Alex Dupre ___ 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: network performance over 1GBps links degraded
On Sun, 18 Mar 2018 11:48:32 +0100 Alex Dupre wrote: > Gary Jennejohn wrote: > > I have two computers, both with 1Gbps interfaces plugged into a > > 1Gb switch. One computer is running FreeBSD HEAD and the other > > some version of Linux. Under FreeBSD I have re0 and under Linux > > I don't know what the hardware is. > > > > I noticed that the transfer speed has dropped to only about > > 12MBps. I'm used to seeing about 27MBps during the ftp > > transfers. > > Do you see "re0: watchdog timeout" errors? > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 > Thanks, but I just copied some 30GB between the FreeBSD and Windows 10 computer and didn't see a single error message. I tried r330300, but the behavior didn't change. Maybe I should go even further back in time. One possibilty is the new BIOS I installed on my Ryzen (FreeBSD) box. I checked that the settings are all optimized, but who knows what Asus changed? -- Gary Jennejohn ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Charlie Li changed: What|Removed |Added CC||freebsd-current@FreeBSD.org -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: network performance over 1GBps links degraded
On Sun, 18 Mar 2018 12:21:54 +0100 Gary Jennejohn wrote: > On Sun, 18 Mar 2018 11:48:32 +0100 > Alex Dupre wrote: > > > Gary Jennejohn wrote: > > > I have two computers, both with 1Gbps interfaces plugged into a > > > 1Gb switch. One computer is running FreeBSD HEAD and the other > > > some version of Linux. Under FreeBSD I have re0 and under Linux > > > I don't know what the hardware is. > > > > > > I noticed that the transfer speed has dropped to only about > > > 12MBps. I'm used to seeing about 27MBps during the ftp > > > transfers. > > > > Do you see "re0: watchdog timeout" errors? > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724 > > > > Thanks, but I just copied some 30GB between the FreeBSD and Windows > 10 computer and didn't see a single error message. > > I tried r330300, but the behavior didn't change. Maybe I should go even > further back in time. > > One possibilty is the new BIOS I installed on my Ryzen (FreeBSD) box. > I checked that the settings are all optimized, but who knows what Asus > changed? > So, Stefan Esser (se@) hit me with a clue bat and asked what ifconfig shows for the speed. Well, it's 100baseTX. Not too surprising that it maxes out at 12MBps. Up until recently the speed was always automatically set to 1000baseTX. AFAIK nothing has changed in regards to the hardware (contollers, switches, etc.). Anyway, I'll try setting mediaopts in rc.conf and see what happens. -- Gary Jennejohn ___ 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"
/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main
Fyi, I started seeing this error today during buildworld compile. FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15 16:30:40 EDT 2018 root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 1200060 # svnlite info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 331135 Node Kind: directory Schedule: normal Last Changed Author: markj Last Changed Rev: 331135 Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018) - --- all_subdir_lib/libcasper --- --- all_subdir_lib/libcasper/services/cap_sysctl --- /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74) /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_create referenced by cap_sysctl.c:64 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_add_string referenced by cap_sysctl.c:65 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_add_string referenced by cap_sysctl.c:66 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_add_number referenced by cap_sysctl.c:67 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_add_null referenced by cap_sysctl.c:69 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_add_number referenced by cap_sysctl.c:71 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_add_binary referenced by cap_sysctl.c:73 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: cap_xfer_nvlist referenced by cap_sysctl.c:74 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_get_number referenced by cap_sysctl.c:77 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_get_number referenced by cap_sysctl.c:78 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_destroy referenced by cap_sysctl.c:79 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_get_number referenced by cap_sysctl.c:84 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_get_binary referenced by cap_sysctl.c:86 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_destroy referenced by cap_sysctl.c:91 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: service_register referenced by cap_sysctl.c:295 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:295) /tmp/cap_sysctl-cfa2f8.o:(init_casper_service) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_next referenced by cap_sysctl.c:209 (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:209) /tmp/cap_sysctl-cfa2f8.o:(sysctl_limit) /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: nvlist_get_number referenced by cap_sysctl.c:212 (/usr/src/lib
Re: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main
Am Sun, 18 Mar 2018 13:19:08 -0400 (EDT) AN schrieb: > Fyi, I started seeing this error today during buildworld compile. > > FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15 > 16:30:40 EDT 2018 > root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 1200060 > > # svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 331135 > Node Kind: directory > Schedule: normal > Last Changed Author: markj > Last Changed Rev: 331135 > Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018) > - > > --- all_subdir_lib/libcasper --- > --- all_subdir_lib/libcasper/services/cap_sysctl --- > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main > >>> referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74) > >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start) > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_create > >>> referenced by cap_sysctl.c:64 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_string > >>> referenced by cap_sysctl.c:65 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_string > >>> referenced by cap_sysctl.c:66 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_number > >>> referenced by cap_sysctl.c:67 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_null > >>> referenced by cap_sysctl.c:69 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_number > >>> referenced by cap_sysctl.c:71 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_binary > >>> referenced by cap_sysctl.c:73 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > cap_xfer_nvlist > >>> referenced by cap_sysctl.c:74 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_number > >>> referenced by cap_sysctl.c:77 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_number > >>> referenced by cap_sysctl.c:78 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_destroy > >>> referenced by cap_sysctl.c:79 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_number > >>> referenced by cap_sysctl.c:84 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_binary > >>> referenced by cap_sysctl.c:86 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_destroy > >>> referenced by cap_sysctl.c:91 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91) > >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > service_register > >>> referenced by cap_sysctl.c:295 > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:295) > >>>
Re: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main
Thank you for reporting - I'm checking it. Do you use option MK_CASPER=no ? On 18 March 2018 at 18:19, AN wrote: > Fyi, I started seeing this error today during buildworld compile. > > FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15 > 16:30:40 EDT 2018 root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL > amd64 1200060 > > # svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 331135 > Node Kind: directory > Schedule: normal > Last Changed Author: markj > Last Changed Rev: 331135 > Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018) > - > > --- all_subdir_lib/libcasper --- > --- all_subdir_lib/libcasper/services/cap_sysctl --- > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74) /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start) > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_create referenced by cap_sysctl.c:64 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_string referenced by cap_sysctl.c:65 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_string referenced by cap_sysctl.c:66 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_number referenced by cap_sysctl.c:67 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_null referenced by cap_sysctl.c:69 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_number referenced by cap_sysctl.c:71 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_add_binary referenced by cap_sysctl.c:73 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > cap_xfer_nvlist referenced by cap_sysctl.c:74 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_number referenced by cap_sysctl.c:77 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_number referenced by cap_sysctl.c:78 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_destroy referenced by cap_sysctl.c:79 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_number referenced by cap_sysctl.c:84 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_get_binary referenced by cap_sysctl.c:86 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > nvlist_destroy referenced by cap_sysctl.c:91 > > (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91) /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) > > > /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: > service_
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Conrad Meyer changed: What|Removed |Added CC|freebsd-current@FreeBSD.org |c...@freebsd.org --- Comment #3 from Conrad Meyer --- Please do not CC huge mailing lists on bugs. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 Charlie Li changed: What|Removed |Added CC||freebsd-current@FreeBSD.org --- Comment #5 from Charlie Li --- In that case I do have WITH_ZONEINFO_LEAPSECONDS_SUPPORT set in src.conf. This setting also breaks databases/postgresql-server but it's a known quantity there. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 w.schwarzenf...@utanet.at changed: What|Removed |Added CC|freebsd-current@FreeBSD.org |w.schwarzenf...@utanet.at -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 226700] sysutils/e2fsprogs: 1.44.0, test failure on 12-CURRENT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226700 --- Comment #6 from Charlie Li --- Also could someone remove current@ again? I accidentally used a cached page to comment and didn't pay attention to the CC list. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main
I think r331137 fix the problem. Thanks, Mariusz On 18 March 2018 at 18:29, O. Hartmann wrote: > Am Sun, 18 Mar 2018 13:19:08 -0400 (EDT) > AN schrieb: > >> Fyi, I started seeing this error today during buildworld compile. >> >> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #15 r331021: Thu Mar 15 >> 16:30:40 EDT 2018 >> root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 1200060 >> >> # svnlite info >> Path: . >> Working Copy Root Path: /usr/src >> URL: svn://svn.freebsd.org/base/head >> Relative URL: ^/head >> Repository Root: svn://svn.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 331135 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: markj >> Last Changed Rev: 331135 >> Last Changed Date: 2018-03-18 13:03:26 -0400 (Sun, 18 Mar 2018) >> - >> >> --- all_subdir_lib/libcasper --- >> --- all_subdir_lib/libcasper/services/cap_sysctl --- >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main >> >>> referenced by crt1.c:74 (/usr/src/lib/csu/amd64/crt1.c:74) >> >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/crt1.o:(_start) >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_create >> >>> referenced by cap_sysctl.c:64 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:64) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_add_string >> >>> referenced by cap_sysctl.c:65 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:65) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_add_string >> >>> referenced by cap_sysctl.c:66 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:66) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_add_number >> >>> referenced by cap_sysctl.c:67 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:67) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_add_null >> >>> referenced by cap_sysctl.c:69 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:69) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_add_number >> >>> referenced by cap_sysctl.c:71 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:71) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_add_binary >> >>> referenced by cap_sysctl.c:73 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:73) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> cap_xfer_nvlist >> >>> referenced by cap_sysctl.c:74 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:74) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_get_number >> >>> referenced by cap_sysctl.c:77 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:77) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_get_number >> >>> referenced by cap_sysctl.c:78 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:78) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_destroy >> >>> referenced by cap_sysctl.c:79 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:79) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_get_number >> >>> referenced by cap_sysctl.c:84 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:84) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_get_binary >> >>> referenced by cap_sysctl.c:86 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:86) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> nvlist_destroy >> >>> referenced by cap_sysctl.c:91 >> (/usr/src/lib/libcasper/services/cap_sysctl/cap_sysctl.c:91) >> >>> /tmp/cap_sysctl-cfa2f8.o:(cap_sysctlbyname) >> >> /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: >> service_register >> >>> r
Re: Strange ARC/Swap/CPU on yesterday's -CURRENT
On Sun, Mar 11, 2018 at 10:43:58AM -1000, Jeff Roberson wrote: > Also, if you could try going back to r328953 or r326346 and let me know if > the problem exists in either. That would be very helpful. If anyone is Not sure this is relevant, but r326343 is able to run a j4 buildworld to completion on an RPi3 with 3 gigs of microSD-based swap. There are periods of seeming distress at times (lots of swread, pfault state in top along with high %idle) in top, but the compilation completes. In contrast, r328953 could not complete buildworld using -j4. Buildworld would stop, usually reporting c++ killed, apparently for want of swap, even though swap usage never exceeded about 30% accoring to top. The machine employs UFS filesystems, the kernel config can be seen at http://www.zefox.net/~fbsd/rpi3/kernel_config/ZEFOX Thanks for reading, I hope it's useful. bob prohaska ___ 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"
pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead
FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #12 r331138: Sun Mar 18 15:09:37 EDT 2018 root@BSD_12:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 I recently started to see strange behavior on 2 different machines and was wondering if anyone else has run into it. Within the last few days, I have been experiencing a reproduceable problem with sound. It happens in VLC and also in Virtualbox watching video in a browser. I get the following log entry: Mar 18 18:10:26 BSD_12 kernel: pcm1: chn_write(): pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead and then sound is dead in all applications. Any ideas what to do? I tried the following: rebuilt world and kernel several times rebuilt libvorbis rebuilt ffmpeg rebuilt vlc rebuilt Vbox and kmod The only thing I can think of as a possible issue is an update to libvorbis recently, cc'ing ports just in case. Is there a way to restart the audio subsystem without rebooting the machine? Is there anymore info I can provide to troubleshoot? # dmesg | grep pcm pcm0: at nid 3 on hdaa0 pcm1: at nid 20,22,21,23 and 24,26 on hdaa1 pcm2: at nid 27 and 25 on hdaa1 pcm1: chn_write(): pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead # pciconf -lv hostb0@pci0:0:0:0: class=0x06 card=0x7a341462 chip=0x14501022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Family 17h (Models 00h-0fh) Root Complex' class = bridge subclass = HOST-PCI hdac0@pci0:34:0:1: class=0x040300 card=0xaa681545 chip=0xaa681002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Cedar HDMI Audio [Radeon HD 5400/6300/7300 Series]' class = multimedia subclass = HDA hdac1@pci0:36:0:3: class=0x040300 card=0xda341462 chip=0x14571022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'Family 17h (Models 00h-0fh) HD Audio Controller' class = multimedia subclass = HDA Thanks in advance for any advice. ___ 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: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead
On 03/18/18 18:52, Theron Tarigo wrote: On 03/18/18 18:35, AN wrote: Is there a way to restart the audio subsystem without rebooting the machine? Building kernel with sound and snd_* as loadable modules should enable this to be accomplished with kldunload/kldload. In my experience though all sound device files must be closed before unloading these modules to avoid some lockup issues. ___ 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: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead
On 03/18/18 18:35, AN wrote: Is there a way to restart the audio subsystem without rebooting the machine? Building kernel with sound and snd_* as loadable modules should enable this to be accomplished with kldunload/kldload. In my experience though all sound device files must be closed before unloading these modules to avoid some lockup issues. ___ 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: pcm1:virtual:dsp1.vp0: play interrupt timeout, channel dead
In message <764e2df5-613d-a131-5d7d-6df545995...@gmail.com>, Theron Tarigo writ es: > On 03/18/18 18:35, AN wrote: > > Is there a way to restart the audio subsystem without rebooting the > > machine? > Building kernel with sound and snd_* as loadable modules should enable > this to be accomplished with kldunload/kldload. In my experience though > all sound device files must be closed before unloading these modules to > avoid some lockup issues. The other thing you might want to check out is if you multiboot your laptop that any non-FreeBSD operating system may put hardware into an inconsistent state. For example, my Acer laptop loses sound if I boot Windows then boot FreeBSD. The workaround is either adjust the HDA inputs/outputs through sysctl or simply power cycle the laptop. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: Strange ARC/Swap/CPU on yesterday's -CURRENT
bob prohaska fbsd at www.zefox.net wrote on Sun Mar 18 21:09:42 UTC 2018 : > On Sun, Mar 11, 2018 at 10:43:58AM -1000, Jeff Roberson wrote: > > > Also, if you could try going back to r328953 or r326346 and let me know if > > the problem exists in either. That would be very helpful. If anyone is > > Not sure this is relevant, but r326343 is able to run a j4 buildworld > to completion on an RPi3 with 3 gigs of microSD-based swap. There are > periods of seeming distress at times (lots of swread, pfault state > in top along with high %idle) in top, but the compilation completes. > > In contrast, r328953 could not complete buildworld using -j4. Buildworld > would stop, usually reporting c++ killed, apparently for want of swap, > even though swap usage never exceeded about 30% accoring to top. > > The machine employs UFS filesystems, . . . Sounds like -r326346 would be an interesting kernel to test (the next check-in on head after -r326343, one of Jeff's check-ins). -r328953 was just before Jeff's: Author: jeff Date: Tue Feb 6 22:10:07 2018 New Revision: 328954 URL: https://svnweb.freebsd.org/changeset/base/328954 Log: Use per-domain locks for vm page queue free. Move paging control from global to per-domain state. Protect reservations with the free lock from the domain that they belong to. Refactor to make vm domains more of a first class object. So, if -r328953 behaves oddly and -r326343 does not, then the question is if -r326346 makes the difference: Author: jeff Date: Tue Nov 28 23:18:35 2017 New Revision: 326346 URL: https://svnweb.freebsd.org/changeset/base/326346 Log: Move domain iterators into the page layer where domain selection should take place. This makes the majority of the phys layer explicitly domain specific. (Unfortunately my FreeBSD time is currently greatly limited.) It is also interesting that your test context is UFS. O. Hartmann has reported problems for UFS in a more modern version: -r330608 . === 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: Strange ARC/Swap/CPU on yesterday's -CURRENT
On Sun, Mar 18, 2018 at 05:54:30PM -0700, Mark Millard wrote: > bob prohaska fbsd at www.zefox.net wrote on > Sun Mar 18 21:09:42 UTC 2018 : > > > On Sun, Mar 11, 2018 at 10:43:58AM -1000, Jeff Roberson wrote: > > > > > Also, if you could try going back to r328953 or r326346 and let me know > > > if > > > the problem exists in either. That would be very helpful. If anyone is > > > > Not sure this is relevant, but r326343 is able to run a j4 buildworld > > to completion on an RPi3 with 3 gigs of microSD-based swap. There are > > periods of seeming distress at times (lots of swread, pfault state > > in top along with high %idle) in top, but the compilation completes. > > > > In contrast, r328953 could not complete buildworld using -j4. Buildworld > > would stop, usually reporting c++ killed, apparently for want of swap, > > even though swap usage never exceeded about 30% accoring to top. > > > > The machine employs UFS filesystems, . . . > > > Sounds like -r326346 would be an interesting kernel to test (the > next check-in on head after -r326343, one of Jeff's check-ins). > > -r328953 was just before Jeff's: > My intent was to try 326346. Somehow 326343 arrived in its place. Do architectures affect revision numbers? I thought not, but... > Author: jeff > Date: Tue Feb 6 22:10:07 2018 > New Revision: 328954 > URL: > https://svnweb.freebsd.org/changeset/base/328954 > > > Log: > Use per-domain locks for vm page queue free. Move paging control from > global to per-domain state. Protect reservations with the free lock > from the domain that they belong to. Refactor to make vm domains more > of a first class object. > > > > So, if -r328953 behaves oddly and -r326343 does not, then the > question is if -r326346 makes the difference: > > Author: jeff > Date: Tue Nov 28 23:18:35 2017 > New Revision: 326346 > URL: > https://svnweb.freebsd.org/changeset/base/326346 > > > Log: > Move domain iterators into the page layer where domain selection should take > place. This makes the majority of the phys layer explicitly domain > specific. > > > (Unfortunately my FreeBSD time is currently greatly limited.) > > It is also interesting that your test context is UFS. O. Hartmann > has reported problems for UFS in a more modern version: -r330608 . > When "out of swap" problems appeared I cobbled up a custom kernel, in the hope that a smaller kernel might help. It has since developed that the custom kernel can't boot, but GENERIC still boots. The system is now running a j4 buildworld on r331153 with a GENERIC kernel to see if maybe the problem has already been fixed in a way that was obscured by the customization. The kernel config is at http://www.zefox.net/~fbsd/rpi3/kernel_config/ZEFOX Thanks for reading, bob prohaska ___ 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"
