Re: how do I use the make universe machines?
On Tue, 5 Jun 2018 20:12:18 -0500 "Benjamin Kaduk" said On Wed, Jun 06, 2018 at 12:47:17AM +, Rick Macklem wrote: > I've heard mention of "make universe" machines multiple times, > but have no idea how to use them? > Is there doc on this? > > Thanks, rick > ps: I'll admit I haven't looked at the developer's guide in a long time. I think https://www.freebsd.org/internal/machines.html sounds like the page you're looking for. (universe is just a top-level make target like buildworld, but will take a while on non-beefy hardware.) -Ben I was surprised to discover there was no mention in /usr/src/UPDATING, nor /usr/src/README. So in case anyone might be wondering; /usr/src/Makefile # universe- *Really* build *everything* (buildworld and # all kernels on all architectures). # tinderbox - Same as universe, but presents a list of failed build # targets and exits with an error if there were any. following, an excerpt by Allan Jude (FreeBSD developer && bsdnow.tv): Testing is Tricky and Rigorous, so FreeBSD Came Out with the Universe Build Further complicating things, ZFS has its own upstream repo with its own rules and testing requirements: e.g., a pull request has to be in a ZFS-running operating system like FreeBSD or Linux and used in production for a minimum of three months before actually being committed. “The ZFS repo has to be in production quality at all times,” Allan elaborated. “FreeBSD itself has a test suite, a set of regression tests, and then continuous integration with Jenkins.” The trick there is the multiple platform conundrum. You make a commit, the code is seemingly perfect, but then you realize you only know how it runs on your x86 hardware. Maybe its functionality on ARM is a different story. “We have this concept called the Universe Build where you build FreeBSD for every different processor environment that’s supported,” Allan shared. That way no matter how well it works on your system, you also know it’ll work for everyone else. As is to be expected, Allan told us the Universe Build can take a while to develop to perfection — “especially if you don’t have all the hardware, but the FreeBSD Foundation provides servers to the developers of the project.” So thankfully, they’ve got access to really big servers, some 36 cores, and a boat load of RAM. “If you had to do a Universe Build on your laptop, it might take a day and a half,” Allan added, with a laugh. --Chris ___ 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: how do I use the make universe machines?
On Wed, Jun 06, 2018 at 12:47:17AM +, Rick Macklem wrote: > I've heard mention of "make universe" machines multiple times, > but have no idea how to use them? > Is there doc on this? > > Thanks, rick > ps: I'll admit I haven't looked at the developer's guide in a long time. I think https://www.freebsd.org/internal/machines.html sounds like the page you're looking for. (universe is just a top-level make target like buildworld, but will take a while on non-beefy hardware.) -Ben ___ 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"
how do I use the make universe machines?
I've heard mention of "make universe" machines multiple times, but have no idea how to use them? Is there doc on this? Thanks, rick ps: I'll admit I haven't looked at the developer's guide in a long time. ___ 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Tue, 5 Jun 2018 16:11:35 +0300 Konstantin Belousov wrote: > On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote: > > > > > > On Mon, 4 Jun 2018 14:06:55 +0300 > > Konstantin Belousov wrote: > > > > > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote: > > > > > > > > > > > > On Sun, 3 Jun 2018 23:53:40 +0300 > > > > Konstantin Belousov wrote: > > > > > > > > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sun, 3 Jun 2018 18:04:23 +0300 > > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 3 Jun 2018 16:21:10 +0300 > > > > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael > > > > > > > > > Gmelin wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > After upgrading CURRENT to r333992 (from something > > > > > > > > > > at least a year old, quite some changes in > > > > > > > > > > mp_machdep.c since), this machine crashes on boot: > > > > > > > > > > > > > > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project. > > > > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, > > > > > > > > > > 1991, 1992, 1993, 1994 The Regents of the > > > > > > > > > > University of California. All rights reserved. > > > > > > > > > > FreeBSD is a registered trademark of The FreeBSD > > > > > > > > > > Foundation. FreeBSD 12.0-CURRENT #1 r333992: Tue > > > > > > > > > > May 22 00:31:04 CEST 2018 > > > > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy > > > > > > > > > > amd64 FreeBSD clang version 6.0.0 > > > > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM > > > > > > > > > > 6.0.0) WARNING: WITNESS option enabled, expect > > > > > > > > > > reduced performance. VT(vga): resolution 640x480 > > > > > > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz > > > > > > > > > > (1396.80-MHz K8-class CPU) Origin="GenuineIntel" > > > > > > > > > > Id=0x40651 Family=0x6 Model=0x45 Stepping=1 > > > > > > > > > > Features=0xbfebfbff > > > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > > > > > > > > Features2=0x4ddaebbf > > > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND> > > > > > > > > > > AMD > > > > > > > > > > Features=0x2c100800 > > > > > > > > > > AMD Features2=0x21 Structured Extended > > > > > > > > > > Features=0x2603 > > > > > > > > > > XSAVE Features=0x1 VT-x: (disabled in > > > > > > > > > > BIOS) PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state > > > > > > > > > > invariant, performance statistics real memory = > > > > > > > > > > 4301258752 (4102 MB) avail memory = 1907572736 > > > > > > > > > > (1819 MB) Event timer "LAPIC" quality 600 ACPI APIC > > > > > > > > > > Table: > > > > > > > > > COREBOOT> > > > > > > > > > What does this mean ? Did you flashed > > > > > > > > > coreboot ? > > > > > > > > > > > > > > > > This machine comes with it by default (my model was > > > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So > > > > > > > > I didn't flash anything (didn't feel like bricking it). > > > > > > > > > > > > > > > > > > > > > > > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > > > > > cpuid = 0; apic id = 00 > > > > > > > > > > fault virtual address= 0xf8000100 > > > > > > > > > > fault code = supervisor write data, > > > > > > > > > > protection violation instruction pointer = > > > > > > > > > > 0x20:Ox8102955f stack pointer= > > > > > > > > > > 0x28:0x82a79be0 frame pointer= > > > > > > > > > > 0x28:0x82a79c10 code segment = > > > > > > > > > > base Ox0, limit Oxf, type Ox1b = DPL 0, pres 1, > > > > > > > > > > long 1, def32 0, gran 1 processor eflags = > > > > > > > > > > resume, IOPL = 0 current process = 0 () > > > > > > > > > > [ thread pid 0 tid 0 ] > > > > > > > > > > Stopped at native_start_all_aps+0x08f: > > > > > > > > > > movq %rax,(%rsi) > > > > > > > > > Look up the source line number for this address. > > > > > > > > > > > > > > > > > > > > > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in > > > > > > > > rdmsr), called by native_start_all_aps. Any additional > > > > > > > > hints how I can track it down? > > > > > > > Why did you decided that this is rdmsr_safe() ? First, > > > > > > > native_start_all_aps() does not call rdmsr, second the ddb > > > > > > > report clearly indicates that the fault occured acessing > > > > > > > DMAP in native_start_all_aps(). > > > > > > > > > > > > > > Just look up the sou
intel graphics regression? between r332432 and r333982
I'm looking for help to make graphics work on Dell Precision 3520. This did work in r332432: http://freebsd.1045724.x6.nabble.com/Dell-Precision-3520-laptop-help-with-dual-graphics-card-td6249818.html I now updated to: # uname -a FreeBSD z.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r333982: Thu May 24 21:24:22 BST 2018 r...@z.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 and I cannot get graphics anymore. Some details: # pciconf -lv | grep -A3 vga vgapci1@pci0:0:2:0: class=0x03 card=0x07a91028 chip=0x191b8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'HD Graphics 530' class = display -- vgapci0@pci0:1:0:0: class=0x030200 card=0x07a91028 chip=0x13b410de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'GM107GLM [Quadro M620 Mobile]' class = display Somebody in questions@ suggested https://github.com/ahacking/freebsd-gpu-off to disable one of the 2 devices. Not sure if this worked as expected. I now have: # cat /usr/local/etc/gpu-off.conf export methods="\_SB.PCI0.PEG0.PEGP._OFF" I built graphics/drm-next-kmod and added kld_list="/boot/modules/i915kms.ko" to /etc/rc.conf. However, on boot I see: KLD drm.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/modules/drm.ko - unsupported file type KLD i915kms.ko: depends on drmn - not available or version mismatch linker_load_file: /boot/modules/i915kms.ko - unsupported file type I can still load these modules manually: root@z:~ # kldload drm root@z:~ # kldload i915kms info: [drm] Initialized drm 1.1.0 20060810 root@z:~ # kldstat Id Refs AddressSize Name 1 44 0x8020 23fad18 kernel 21 0x825fc000 29bc8if_iwm.ko 31 0x82626000 1bb438 iwm8265fw.ko 41 0x831fa000 be5c geom_bde.ko 61 0x83206000 210 acpi_call.ko 71 0x83207000 2388 ums.ko 81 0x8320a000 1780 uhid.ko 91 0x8320c000 10c70drm.ko 101 0x8321d000 7d0e0i915kms.ko 111 0x8329b000 40eb0drm2.ko 124 0x832dc000 1ef0 iicbus.ko 131 0x832de000 ec0 iic.ko 141 0x832df000 1570 iicbb.ko Still, starting X I get in /var/log/Xorg.0.log [ 429.258] (EE) open /dev/dri/card0: No such file or directory Give me a hint Anton ___ 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: swapping is completely broken in -CURRENT r334649?
On Wed, Jun 06, 2018 at 12:22:08AM +0300, Lev Serebryakov wrote: > On 05.06.2018 19:17, Gary Jennejohn wrote: > > > > I complained about this also and alc@ gave me this hint: > > sysctl vm.pageout_update_period=0 > > Really, situation is worse than stated in subject, because processes > are being killed AFTER memory pressure, when here are a lot of free > memory already! > > It looks like very serious bug. The issue was identified earlier this week and is being worked on. It's a regression from r329882 which appears only on certain hardware. You can probably work around it by setting vm.pageout_oom_seq to a large value (try 1000 for instance), though this will make the "true" OOM killer take longer to kick in. The problem is unrelated to the pageout_update_period. ___ 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: swapping is completely broken in -CURRENT r334649?
On 05.06.2018 19:17, Gary Jennejohn wrote: > I complained about this also and alc@ gave me this hint: > sysctl vm.pageout_update_period=0 Really, situation is worse than stated in subject, because processes are being killed AFTER memory pressure, when here are a lot of free memory already! It looks like very serious bug. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: swapping is completely broken in -CURRENT r334649?
On 05.06.2018 19:17, Gary Jennejohn wrote: >> I have 16G of free swap (out of 16G configured), but programs are >> killed due to "out of swap space" >> > > I complained about this also and alc@ gave me this hint: > sysctl vm.pageout_update_period=0 > > I don't whether it will help, but you can give it a try. Looks like it helps a little. Very resource-hungry operation have been completed, but after ~10 minutes, when compilation have been finished, and swap is clear again, system starts to kill processes. WTF?! -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: error building libpmc_events.c
Replying to my own mail for more details, and ccing potential commiters On 06/04/2018 17:34, Claude Buisson wrote: Hi, During a buildworld of head on amd64, from 332518 to 334590, the build stops with: --- all_subdir_lib/libpmc --- ===> lib/libpmc (all) --- libpmc_events.c --- ./pmu-events/jevents "x86" /home/src/lib/libpmc/pmu-events/arch libpmc_events.c sh: ./pmu-events/jevents: not found *** [libpmc_events.c] Error code 127 ... This was during the lib32 build: jevents is not built in this context The same error has been described by kevans@ on svn-src-all@ as a consequence of svn 334226 (by bdrewery), pmu-events having since been moved in svn r334242 (by mmacy) CBu ___ 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: swapping is completely broken in -CURRENT r334649?
On Tue, 5 Jun 2018 18:55:52 +0300 Lev Serebryakov wrote: > I have 16G of free swap (out of 16G configured), but programs are > killed due to "out of swap space" > I complained about this also and alc@ gave me this hint: sysctl vm.pageout_update_period=0 I don't whether it will help, but you can give it a try. -- 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"
swapping is completely broken in -CURRENT r334649?
I have 16G of free swap (out of 16G configured), but programs are killed due to "out of swap space"… -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]
In message , Li-Wen Hsu writes: > --79b474056de4bc0b > Content-Type: text/plain; charset="UTF-8" > > On Tue, Jun 5, 2018 at 08:10 Cy Schubert wrote: > > > In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark > > Millard write > > s: > > > >From ci.freebsd.org for a -r334626 + builds: > > > > > > --- brk_test.full --- > > > cc -target aarch64-unknown-freebsd12.0 > > --sysroot=/usr/obj/usr/src/arm64.aarch > > > 64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -g > > -std=iso9899 > > > :1999 -fstack-protector-strong -Wsystem-headers -Werror -Wall > > -Wno-format-y2k > > > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > > -Wno-string-plus-int -W > > > no-unused-const-variable -Wno-tautological-compare -Wno-unused-value > > -Wno-par > > > entheses-equality -Wno-unused-function -Wno-enum-conversion > > -Wno-unused-local > > > -typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum > > -Wno-knr- > > > promoted-parameter -Qunused-arguments -o brk_test.full brk_test.o > > -lprivat > > > eatf-c > > > /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: > > brk > > > >>> referenced by brk_test.c:52 > > (/usr/src/lib/libc/tests/sys/brk_test.c:52) > > > >>> brk_test.o:(atfu_brk_basic_body) > > > > > > /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: > > sbrk > > > >>> referenced by brk_test.c:55 > > (/usr/src/lib/libc/tests/sys/brk_test.c:55) > > > >>> brk_test.o:(atfu_brk_basic_body) > > > > > > . . . (and many more) . . . > > > > Do a clean build or remove the libc directory from /usr/obj, then do > > your build. > > > Each build on ci.freebsd.org is a clean build from scratch. I overlooked that it was ci.freebsd.org. This is a different issue than on amd64. -- 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Mon, Jun 04, 2018 at 11:17:56PM +0200, Michael Gmelin wrote: > > > On Mon, 4 Jun 2018 14:06:55 +0300 > Konstantin Belousov wrote: > > > On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote: > > > > > > > > > On Sun, 3 Jun 2018 23:53:40 +0300 > > > Konstantin Belousov wrote: > > > > > > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote: > > > > > > > > > > > > > > > On Sun, 3 Jun 2018 18:04:23 +0300 > > > > > Konstantin Belousov wrote: > > > > > > > > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Sun, 3 Jun 2018 16:21:10 +0300 > > > > > > > Konstantin Belousov wrote: > > > > > > > > > > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin > > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > After upgrading CURRENT to r333992 (from something at > > > > > > > > > least a year old, quite some changes in mp_machdep.c > > > > > > > > > since), this machine crashes on boot: > > > > > > > > > > > > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project. > > > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, > > > > > > > > > 1992, 1993, 1994 The Regents of the University of > > > > > > > > > California. All rights reserved. FreeBSD is a registered > > > > > > > > > trademark of The FreeBSD Foundation. FreeBSD > > > > > > > > > 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018 > > > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy > > > > > > > > > amd64 FreeBSD clang version 6.0.0 > > > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) > > > > > > > > > WARNING: WITNESS option enabled, expect reduced > > > > > > > > > performance. VT(vga): resolution 640x480 CPU: Intel(R) > > > > > > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU) > > > > > > > > > Origin="GenuineIntel" Id=0x40651 Family=0x6 > > > > > > > > > Model=0x45 Stepping=1 > > > > > > > > > Features=0xbfebfbff > > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > > > > > > > > Features2=0x4ddaebbf > > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND> > > > > > > > > > AMD Features=0x2c100800 > > > > > > > > > AMD Features2=0x21 Structured Extended > > > > > > > > > Features=0x2603 > > > > > > > > > XSAVE Features=0x1 VT-x: (disabled in BIOS) > > > > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, > > > > > > > > > performance statistics real memory = 4301258752 (4102 > > > > > > > > > MB) avail memory = 1907572736 (1819 MB) Event timer > > > > > > > > > "LAPIC" quality 600 ACPI APIC Table: > > > > > > > > COREBOOT> > > > > > > > > What does this mean ? Did you flashed coreboot ? > > > > > > > > > > > > > > This machine comes with it by default (my model was > > > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So I > > > > > > > didn't flash anything (didn't feel like bricking it). > > > > > > > > > > > > > > > > > > > > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > > > > > cpuid = 0; apic id = 00 > > > > > > > > > fault virtual address= 0xf8000100 > > > > > > > > > fault code = supervisor write data, > > > > > > > > > protection violation instruction pointer = > > > > > > > > > 0x20:Ox8102955f stack pointer= > > > > > > > > > 0x28:0x82a79be0 frame pointer= > > > > > > > > > 0x28:0x82a79c10 code segment = base > > > > > > > > > Ox0, limit Oxf, type Ox1b = DPL 0, pres 1, long 1, > > > > > > > > > def32 0, gran 1 processor eflags = resume, IOPL > > > > > > > > > = 0 current process = 0 () > > > > > > > > > [ thread pid 0 tid 0 ] > > > > > > > > > Stopped at native_start_all_aps+0x08f: movq > > > > > > > > > %rax,(%rsi) > > > > > > > > Look up the source line number for this address. > > > > > > > > > > > > > > > > > > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in > > > > > > > rdmsr), called by native_start_all_aps. Any additional > > > > > > > hints how I can track it down? > > > > > > Why did you decided that this is rdmsr_safe() ? First, > > > > > > native_start_all_aps() does not call rdmsr, second the ddb > > > > > > report clearly indicates that the fault occured acessing DMAP > > > > > > in native_start_all_aps(). > > > > > > > > > > > > Just look up the source line by the address > > > > > > native_start_all_aps+0x08f. > > > > > > > > > > Okay, according to kgbd this should be here: > > > > > > > > > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369 > > > > > > > > > > 364 > > > > > 365/* Create the initial 1GB replicated page tables */ > > > > > 366for
Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]
On Tue, Jun 5, 2018 at 08:10 Cy Schubert wrote: > In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark > Millard write > s: > > >From ci.freebsd.org for a -r334626 + builds: > > > > --- brk_test.full --- > > cc -target aarch64-unknown-freebsd12.0 > --sysroot=/usr/obj/usr/src/arm64.aarch > > 64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -g > -std=iso9899 > > :1999 -fstack-protector-strong -Wsystem-headers -Werror -Wall > -Wno-format-y2k > > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body > -Wno-string-plus-int -W > > no-unused-const-variable -Wno-tautological-compare -Wno-unused-value > -Wno-par > > entheses-equality -Wno-unused-function -Wno-enum-conversion > -Wno-unused-local > > -typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum > -Wno-knr- > > promoted-parameter -Qunused-arguments -o brk_test.full brk_test.o > -lprivat > > eatf-c > > /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: > brk > > >>> referenced by brk_test.c:52 > (/usr/src/lib/libc/tests/sys/brk_test.c:52) > > >>> brk_test.o:(atfu_brk_basic_body) > > > > /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: > sbrk > > >>> referenced by brk_test.c:55 > (/usr/src/lib/libc/tests/sys/brk_test.c:55) > > >>> brk_test.o:(atfu_brk_basic_body) > > > > . . . (and many more) . . . > > Do a clean build or remove the libc directory from /usr/obj, then do > your build. Each build on ci.freebsd.org is a clean build from scratch. Li-Wen > -- Li-Wen Hsu https://lwhsu.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: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]
On 2018-Jun-5, at 5:09 AM, Cy Schubert wrote: > In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark > Millard write > s: >>> From ci.freebsd.org for a -r334626 + builds: >> >> --- brk_test.full --- >> cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch >> 64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -g -std=iso9899 >> :1999 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k >> -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -W >> no-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-par >> entheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local >> -typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr- >> promoted-parameter -Qunused-arguments -o brk_test.full brk_test.o -lprivat >> eatf-c >> /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: brk > referenced by brk_test.c:52 (/usr/src/lib/libc/tests/sys/brk_test.c:52) > brk_test.o:(atfu_brk_basic_body) >> >> /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: sbrk > referenced by brk_test.c:55 (/usr/src/lib/libc/tests/sys/brk_test.c:55) > brk_test.o:(atfu_brk_basic_body) >> >> . . . (and many more) . . . > > Do a clean build or remove the libc directory from /usr/obj, then do > your build. You missed the first line "From ci.freebsd.org . . .": It was not my build, it was a ci.freebsd.org build of FreeBSD-head-aarch64-build . It was specifically #7944 (of -r334628 ) and later. The latest #7951 (of -r334651 ) is still broken the same way. #7943 (of -r334625 ) was the last good build. === 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: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]
In message <1731a84f-4278-43f5-b498-c3501081e...@yahoo.com>, Mark Millard write s: > >From ci.freebsd.org for a -r334626 + builds: > > --- brk_test.full --- > cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch > 64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -g -std=iso9899 > :1999 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k > -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -W > no-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-par > entheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local > -typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr- > promoted-parameter -Qunused-arguments -o brk_test.full brk_test.o -lprivat > eatf-c > /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: brk > >>> referenced by brk_test.c:52 (/usr/src/lib/libc/tests/sys/brk_test.c:52) > >>> brk_test.o:(atfu_brk_basic_body) > > /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: sbrk > >>> referenced by brk_test.c:55 (/usr/src/lib/libc/tests/sys/brk_test.c:55) > >>> brk_test.o:(atfu_brk_basic_body) > > . . . (and many more) . . . Do a clean build or remove the libc directory from /usr/obj, then do your build. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) -- 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: uchcom update
On 05/22/2018 09:44 AM, Andriy Gapon wrote: Yesterday I committed some changes to uchcom (so far, only in CURRENT). Commits are r333997 - r334002. If you have a CH340/341 based USB<->RS232 adapter and it works for you, could you please test that it still does? If you tried your adapter in the past and it did not work, there is a chance it might start working now. Could you please test that as well? ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (96mA) ugen5.4.0: uchcom0: It's not made it any worse. I'm not using this adapter by choice - it's a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state that these are possibly the worst chips ever. Is that still the prevailing opinion? Ian -- ___ 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: [RFC] Deprecation and removal of the drm2 driver
Implementing a callback in 140 different files for the sake of a handful of out of tree drivers and people not reading updating is pretty prohibitive. 11 may be more your cup of tea. On Mon, Jun 4, 2018 at 22:27 Adrian Chadd wrote: > Hi, > > If there's an API that isn't being used then great, I'll go find it > and fix up pieces in my spare time to use it. But the last drive by > cut/paste didn't do that; it just changed the code in place. :-) > > > > -adrian > ___ 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"
