Re: port lang/python27 does not build in 14.0-CURRENT w/ poudriere
Enji Cooper wrote:
Hmm… All lang/python27 requiring ports should be marked BROKEN and
removed — upstream stopped supporting 2.7 3.5 years ago (04/01/2020) :/.
We can't entirely do that yet. Unfortunately, moinmoin, original mailman
and the CSM for UEFI-EDK2 (used in bhyve) still staunchly require this.
It was the case that Chrom{e,ium} and qt-webengine still had Python 2
build bits but they've since migrated off.
--
Charlie Li
…nope, still don't have an exit line.
OpenPGP_signature
Description: OpenPGP digital signature
Re: current status of zfs block_cloning on CURRENT?
Charlie Li wrote: Pete Wright wrote: i've seen a few threads about the block_cloning feature causing data corruption issues on CURRENT and have been keen to avoid enabling it until the dust settles. i was under the impression that we either reverted or disabled block_cloning on CURRENT, but when i ran "zpool upgrade" on a pool today it reported block_cloning was enabled. this is on a system i rebuilt yesterday. The dust has settled. Barely... i was hoping to get some clarity on the effect of having this feature enabled, is this enough to trigger the data corruption bug or does something on the zfs filesystem itself have to be enabled to trigger this? The initial problem with block_cloning [0][1] was fixed in commits e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption problem [2][3] was fixed in commit 63ee747febbf024be0aace61161241b53245449e. All were committed between 15-17 April. [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 [1] https://github.com/openzfs/zfs/pull/14739 [2] https://github.com/openzfs/zfs/issues/14753 [3] https://github.com/openzfs/zfs/pull/14761 Given mjg@'s thread reporting further crashes/panics, you may want to keep the sysctl disabled if you upgraded the pool already. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: current status of zfs block_cloning on CURRENT?
Pete Wright wrote: i've seen a few threads about the block_cloning feature causing data corruption issues on CURRENT and have been keen to avoid enabling it until the dust settles. i was under the impression that we either reverted or disabled block_cloning on CURRENT, but when i ran "zpool upgrade" on a pool today it reported block_cloning was enabled. this is on a system i rebuilt yesterday. The dust has settled. i was hoping to get some clarity on the effect of having this feature enabled, is this enough to trigger the data corruption bug or does something on the zfs filesystem itself have to be enabled to trigger this? The initial problem with block_cloning [0][1] was fixed in commits e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption problem [2][3] was fixed in commit 63ee747febbf024be0aace61161241b53245449e. All were committed between 15-17 April. [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 [1] https://github.com/openzfs/zfs/pull/14739 [2] https://github.com/openzfs/zfs/issues/14753 [3] https://github.com/openzfs/zfs/pull/14761 -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Mark Millard wrote: FYI: in my original report for a context that has never had block_cloning enabled, I reported BOTH missing files and file content corruption in the poudriere-devel bulk build testing. This predates: https://people.freebsd.org/~pjd/patches/brt_revert.patch but had the changes from: https://github.com/openzfs/zfs/pull/14739/files The files were missing from packages installed to be used during a port's build. No other types of examples of missing files happened. (But only 11 ports failed.) I also don't have block_cloning enabled. "Missing files" prior to brt_revert may actually be present, but as the corruption also messes with the file(1) signature, some tools like ldconfig report them as missing. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Pawel Jakub Dawidek wrote: On 4/14/23 09:23, Charlie Li wrote: Pawel Jakub Dawidek wrote: Here is the change that reverts most of the modifications and disables cloning new blocks. It does retain ability to free existing cloned blocks and keeps block_cloning feature around, so upgraded pools can be imported and existing cloned blocks freed. It does not handle replaying ZIL with block-cloning logs, so make sure you import pools that were cleanly exported. I'd appreciate if someone who can reproduce those corruptions could try it. https://github.com/pjd/openzfs/commit/f2cfbcf76a733c44e25cba8c649162ef68047103 Does not apply to sys/contrib/openzfs tip, conflicts in module/os/freebsd/zfs/zfs_vnops_os.c and module/zfs/dmu.c. This should work: https://people.freebsd.org/~pjd/patches/brt_revert.patch This results in missing files rather than corruption. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Pawel Jakub Dawidek wrote: Here is the change that reverts most of the modifications and disables cloning new blocks. It does retain ability to free existing cloned blocks and keeps block_cloning feature around, so upgraded pools can be imported and existing cloned blocks freed. It does not handle replaying ZIL with block-cloning logs, so make sure you import pools that were cleanly exported. I'd appreciate if someone who can reproduce those corruptions could try it. https://github.com/pjd/openzfs/commit/f2cfbcf76a733c44e25cba8c649162ef68047103 Does not apply to sys/contrib/openzfs tip, conflicts in module/os/freebsd/zfs/zfs_vnops_os.c and module/zfs/dmu.c. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Pawel Jakub Dawidek wrote: On 4/14/23 07:52, Charlie Li wrote: Pawel Jakub Dawidek wrote: thank you for your testing and patience so far. I'm working on a patch to revert block cloning without affecting people who already upgraded their pools. Testing with mjg@ earlier today revealed that block_cloning was not the cause of poudriere bulk build (and similar cp(1)/install(1)-based) corruption, although may have exacerbated it. Can you please elaborate how were you testing and what exactly did you exclude? mjg@ prepared https://gitlab.com/vishwin/freebsd-src/-/commit/b41f187ba329621cda1e8e67a0786f07b1221a3c which only removes block_cloning, rebuilding kernel only (buildworld fails) for me to test poudriere bulk -c builds with. I used a world from https://gitlab.com/vishwin/freebsd-src/-/tree/zfs-revert which consists of reverting the merge commit plus a few other conflicts, but keeping vop_fplookup_vexec. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Pawel Jakub Dawidek wrote: thank you for your testing and patience so far. I'm working on a patch to revert block cloning without affecting people who already upgraded their pools. Testing with mjg@ earlier today revealed that block_cloning was not the cause of poudriere bulk build (and similar cp(1)/install(1)-based) corruption, although may have exacerbated it. I'd also greatly appreciate if you could provide a procedure for me to reproduce the corruption, ideally without the internet access, as I'll be on the plane(s) for the next ~24h. Due to non-deterministic conditions, there...kind of isn't one. Best is probably just poudriere bulk builds. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Shawn Webb wrote: Does the ZFS project have some sort of automated testing to catch data-gobbling, pool killing bugs? It seems like this would have been caught with some CI/CD stress testing automation scripts. I can't speak about how the OpenZFS project does things, but this particular corruption does not have any deterministic characteristics both pre- and post-condition, so would be hard to automate testing. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Danilo Egea Gondolfo wrote: I'm having a funny issue here and I'm wondering if it is related. When building one of my ports I will, eventually, not always, get a file full of zeros as a result. The build will create copies of crispy-setup and, every once in a while, one of them will be a blob of zeros: I'm running the recent ZFS update but I never upgraded my pool: This is exactly it. The copy operation within the same dataset will sometimes turn up corruption and randomly, so not the same file(s) get hit. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 2a58b312b62f - main - zfs: merge openzfs/zfs@431083f75
Paweł Jakub Dawidek wrote: Can you please try this patch: <https://github.com/openzfs/zfs/pull/14739> Unfortunately I don’t see how this can happen with block cloning disabled. This patch made no difference in poudriere; corruption still rolled in. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git: 61194e9852e6 - main - Add kqueue1() syscall
Konstantin Belousov wrote: The branch main has been updated by kib: URL: https://cgit.FreeBSD.org/src/commit/?id=61194e9852e641d1533cd04a5679d6042ff975d3 commit 61194e9852e641d1533cd04a5679d6042ff975d3 Author: Konstantin Belousov AuthorDate: 2023-03-25 23:39:02 + Commit: Konstantin Belousov CommitDate: 2023-03-27 23:39:26 + Add kqueue1() syscall It takes the flags argument. Immediate use is to provide the KQUEUE_CLOEXEC flag for kqueue(2). This commit series causes x11/libinput to hit an assert (which also silently crashes X on launch): Assertion failed: (libinput->refcount > 0), function libinput_unref, file ../src/libinput.c, line 1957. devel/libepoll-shim, x11/libinput's prime dependency, has its own kqueue1() implementation, which is used when the system does not already have one. Reverting this series and rebuilding devel/libepoll-shim to use its included implementation allows x11/libinput to work again. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
x11/libinput assertion error
Somewhere between -CURRENT 0e71f4f77c016b4087106e7c58b958667df8e1b2 and a02d9cad77c1207eb809ba49fc1595c8ebb2da26, xorg-server crashes on launch. It happens right when loading xf86-input-libinput, for which the error only mentions a segfault at 0x0b. Switching to xf86-input-evdev (and removing xf86-input-libinput) allows X to start, but this is not optimal. Further investigation revealed that even libinput-list-devices(1) crashes, although with a clear-cut assertion error: Assertion failed: (libinput->refcount > 0), function libinput_unref, file ../src/libinput.c, line 1957. All of the ports involved have remained the same, albeit rebuilt after the intervening ABI bump. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: Lots of port failures today?
Mateusz Guzik wrote: On 8/18/22, Mateusz Guzik wrote: On 8/18/22, Larry Rosenman wrote: https://home.lerctr.org:/build.html?mastername=live-host_ports&build=2022-08-18_13h12m51s circa 97ecdc00ac5 on main Ideas? try with 9ac6eda6c6a36db6bffa01be7faea24f8bb92a0f reverted I'm pretty sure it will be fixed with URL: https://cgit.FreeBSD.org/src/commit/?id=545db925c3d5408e71e21432895770cd49fd2cf3 Seems to be fixed with this commit, at least for graphics/jpeg-turbo, whose configure failed with something about platform not supporting SIMD. -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: Problem compiling firefox
Filippo Moretti wrote: /usr/local/bin/clang++13 -std=gnu++17 --target=wasm32-wasi --sysroot=/usr/local/share/wasi-sysroot -o rlbox.wasm -Wl,--export-all -Wl,--stack-first -Wl,-z,stack-size=262144 -Wl,--no-entry -Wl,--growable-table ogg_alloc.wasm ogg_bitwise.wasm ogg_framing.wasm xmlparse.wasm xmlrole.wasm xmltok.wasm wasm2c_sandbox_wrapper.wasm mozHunspellRLBoxSandbox.wasm affentry.wasm affixmgr.wasm csutil.wasm hashmgr.wasm hunspell.wasm phonet.wasm replist.wasm suggestmgr.wasm GraphiteExtra.wasm CmapCache.wasm Code.wasm Collider.wasm Decompressor.wasm Face.wasm FeatureMap.wasm FileFace.wasm Font.wasm GlyphCache.wasm GlyphFace.wasm Intervals.wasm Justifier.wasm NameTable.wasm Pass.wasm Position.wasm Segment.wasm Silf.wasm Slot.wasm Sparse.wasm TtfUtil.wasm UtfCodec.wasm call_machine.wasm gr_char_info.wasm gr_face.wasm gr_features.wasm gr_font.wasm gr_logging.wasm gr_segment.wasm gr_slot.wasm json.wasm RLBoxWOFF2Sandbox.wasm table_tags.wasm variable_length.wasm woff2_common.wasm woff2_dec.wasm woff2_out.wasm -lwasi-emulated-process-clocks wasm-ld: error: cannot open /usr/local/llvm13/lib/clang/13.0.1/lib/wasi/libclang_rt.builtins-wasm32.a: No such file or directory clang-13: error: linker command failed with exit code 1 (use -v to see invocation) Caused by a version mismatch after devel/llvm13 update, try this: https://reviews.freebsd.org/D34206 -- Charlie Li …nope, still don't have an exit line. OpenPGP_signature Description: OpenPGP digital signature
Re: git tools for building in base?
Ulrich Spörlein wrote: > I don't fully recall, but I think that the hg conversion was slow and > the disk space needed was quite a bit more than git. > One of Mercurial's biggest design principles is immutable history (with history rewriting disabled by default), so increased disk space compared to git is reasonable. > So in summary, I guess it can be summed up as: > - there was no svn-all-fast-export for hg back then > - even bitbucket switched from hg to git Bitbucket dropping Mercurial support was more a business decision, although more ancillary tooling for git existing and developer appetite certainly played factors there. > - history rewriting is easier in git, see e.g. this file for the stuff > that's required to make the cvs2svn things a bit nicer: > https://github.com/freebsd/git_conv/blob/master/fix_bogus_tags.sh > > Granted, now that the heavy lifting is done, one could probably do a > git2hg transition, as the history is now pretty sane and should be > compatible to the hg model. > Mercurial's branches are more similar to subversion than git. The hg analogue to git's branches are bookmarks, for which even they are optional since hg has its heads concept. > But lack of anyone (to my knowledge?) providing a hg copy of FreeBSD all > these years tells me that there's simply no demand for it. > I use hg-beta for ports. Also used it for src up until git-beta came online. Not sure what I will do once ports is converted to git, however. My mercurial use stems from two sources: committers' need to preserve copy/move history (though this will probably go away with git) and horrendous performance with the ports tree in git. Horrendous as in, for example, takes about five minutes just to run git-status(1) on a ports tree stored on a hard drive with UFS (-uno doesn't help) whilst locking up the entire system I/O for the duration. The I/O lockups have since subsided but as of six months ago the slow enumeration has persisted. For some reason, mercurial is far more efficient in this regard. -- Charlie Li …nope, still don't have an exit line. (This email address is for mailing list use; replace local-part with vishwin for off-list communication if possible) OpenPGP_signature Description: OpenPGP digital signature
Re: Kernel regression in head, now unusable for package building
Konstantin Belousov wrote: > On Mon, Apr 08, 2019 at 12:10:23AM +0200, Antoine Brodin wrote: >> There seems to be a kernel regression in head, that happened >> somewhere between r343921 and r345991. >> When launching "poudriere bulk -a", the ssh session is terminated >> when poudriere attempts to clone/start builders (tmpfs mounts, file >> copying...), the jails don't start and the consequence is that we >> can't build any package. > Are there any more details about the issue ? It is not clear, does the > machine survives the event, i.e. did kernel paniced, what are the console > messages, any more details that you can provide. > I just ran into this both on a remote machine and the laptop I'm typing on right now. At least the reference jail does start and run, as any subsequent poudriere-bulk(8) invocations detect it. The entire login session is killed in the process, and the only clue of anything I can find (at least in the syslog) is that ntpd exits with Hangup: Apr 8 14:12:27 ardmore ntpd[74109]: ntpd exiting on signal 1 (Hangup) This seems to happen randomly, but still quite often. Restarting ntpd can help, though ntpd can still exit and kill the login again. Without ntpd running, running poudriere-bulk(8) is guaranteed to kill the login. -- Charlie Li …nope, still don't have an exit line. (This email address is for mailing list use; replace local-part with vishwin for off-list communication if possible) signature.asc Description: OpenPGP digital signature
Re: GNU binutils 2.17.50 retirement planning
On 23/11/2018 11:23, Ed Maste wrote: > Retiring GNU as requires further investigation and effort as we have > some assembly files (for amd64 at least) which cannot be assembled by > Clang's integrated assembler. If Clang gains support for the required > functionality we'll switch to using IAS for all assembly files, and if > not we could rewrite the few assembly files to work with IAS. > I've been using the port binutils as for quite some time on amd64 (with WITHOUT_BINUTILS and WITHOUT_BINUTILS_BOOTSTRAP) with success by specifying XAS, although some Makefile logic in stand/i386/btx specify a hard-coded /usr/bin/as without bootstrapped binutils, necessitating a symlink. I temporarily re-enabled binutils bootstrap in trying to figure out the r339898 regression with retpoline, so things may have changed in light of r340681. If it is true that the only assembly files that clang IAS cannot assemble are for amd64 and i386, has there been any research into nasm and yasm at least? nasm is specified as a build dependency in certain multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code. Both are licensed under some BSD licence variant. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 23/11/2018 00:02, Ben Widawsky wrote: > Thanks both of you. Here's another shot at roughly the same thing I asked the > first reporter to try (that patch was wrong). If it doesn't work, can you > please > post the dmesg? > This patch works on my machine as well. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 21/11/2018 11:21, Charlie Li wrote: > On 20/11/2018 14:37, Ben Widawsky wrote: >> On 18-11-20 11:28:56, Ben Widawsky wrote: >>> On 18-11-20 14:09:08, Jung-uk Kim wrote: >>>> I am pretty sure r340644 caused the regression. >>>> >>> >>> Seems like a good bet. Could you please add the full dmesg as well as an >>> ACPI >>> dump and the output of `sysctl dev.acpi_ec.` Thanks. > Going to try backing out r340644 in my tree. > This revision is indeed the culprit. No more log spam and battery info querying works after backing out. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 20/11/2018 14:37, Ben Widawsky wrote: > On 18-11-20 11:28:56, Ben Widawsky wrote: >> On 18-11-20 14:09:08, Jung-uk Kim wrote: >>> On 18. 11. 20., Charlie Li wrote: >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >>>> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >>>> (ID=3) has no handler (20181031/exfldio-428) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >>>> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) >>>> >>> I am pretty sure r340644 caused the regression. >>> >>> https://svnweb.freebsd.org/changeset/base/340644 >>> >>> Jung-uk Kim >> >> Seems like a good bet. Could you please add the full dmesg as well as an ACPI >> dump and the output of `sysctl dev.acpi_ec.` Thanks. The full dmesg is flooded. sysctl dev.acpi_ec: dev.acpi_ec.0.%parent: acpi0 dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%location: handle=\_SB_.PCI0.LPC_.EC__ dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x25, ECDT dev.acpi_ec.%parent: > > Just for a quick eyeball, this looks suspicious. You could also try this: > I had to remove another line due to -Wunused-variable. In any case, the log spam continues unabated and battery status querying continues to fail. Going to try backing out r340644 in my tree. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) diff -r 531cf2dab058 sys/dev/acpica/acpi_ec.c --- a/sys/dev/acpica/acpi_ec.c Mon Nov 19 17:31:36 2018 -0500 +++ b/sys/dev/acpica/acpi_ec.c Wed Nov 21 10:52:58 2018 -0500 @@ -338,7 +338,6 @@ ACPI_HANDLE h; ACPI_OBJECT *obj; ACPI_STATUS status; -device_t peer; char desc[64]; int ecdt; int ret; @@ -422,6 +421,7 @@ /* Store the values we got from the namespace for attach. */ acpi_set_private(dev, params); +#if 0 /* * Check for a duplicate probe. This can happen when a probe via ECDT * succeeded already. If this is a duplicate, disable this device. @@ -431,6 +431,7 @@ ret = 0; else device_disable(dev); +#endif if (buf.Pointer) AcpiOsFree(buf.Pointer); signature.asc Description: OpenPGP digital signature
ACPI Error: No handler for Region [ECOR]
Somewhere between r340491 and r340650, probably starting from r340595, my ThinkPad W550s started spewing these messages repeatedly in the system log since boot: Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl (ID=3) has no handler (20181031/exfldio-428) Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) As a result, I am now unable to query battery information at the very least. r340490 is my last built revision with this working. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 05/11/2018 21:51, Konstantin Belousov wrote: > For you, but not for me. > Turns out I omitted the fact that I have WITH_RETPOLINE enabled, which caused all this. emaste@ reported in PR 26 and committed r340650. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
svn commit: r339898 - head/lib/libc/amd64/sys
36 37 .section .note.GNU-stack,"",%progbits (lldb) n Process 22663 stopped * thread #1, name = 'make', stop reason = step over frame #0: 0x002ebdad make`_fini at crtn.S:35 32 33 .section .fini,"ax",@progbits 34 addq$8,%rsp -> 35 ret 36 37 .section .note.GNU-stack,"",%progbits (lldb) n Process 22663 stopped * thread #1, name = 'make', stop reason = step over frame #0: 0x002ebdbc make -> 0x2ebdbc: jmp0x2ebd92 ; _init + 6 0x2ebdc1: pushq $0x0 0x2ebdc6: jmp0x2ebd80 ; __do_global_ctors_aux + 48 0x2ebdcb: int3 (lldb) n Process 22663 stopped * thread #1, name = 'make', stop reason = instruction step over frame #0: 0x002ebd92 make`_init + 6 make`_init: -> 0x2ebd92 <+6>: movsl (%rsi), %es:(%rdi) (lldb) n Process 22663 stopped * thread #1, name = 'make', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x002ebd92 make`_init + 6 make`_init: -> 0x2ebd92 <+6>: movsl (%rsi), %es:(%rdi) (lldb) n Process 22663 exited with status = -1 (0x) (lldb) -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 03/11/2018 11:29, Konstantin Belousov wrote: > Some minimal amount of facts instead of guesses would be much more useful. > Yeah, being sleep deprived and hurried (on my end) certainly doesn't help. > What is the instruction which faulted ? Disassemble the text at 0x2f5664. > Regardless of what is the instruction, show either the output from > 'x86info -f' on the machine, or cpu identification lines from the > _verbose_ boot dmesg. > It appears that 0x2f5664 does not exist: Disassembly of section .init: 002f565c <_init>: 2f565c: 48 83 ec 08 sub$0x8,%rsp 2f5660: e8 fb 3c f3 ff callq 229360 2f5665: e8 b6 ff ff ff callq 2f5620 <__do_global_ctors_aux> 2f566a: 48 83 c4 08 add$0x8,%rsp 2f566e: c3 retq CPU ident: CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306d4 Family=0x6 Model=0x3d Stepping=4 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21c27ab Structured Extended Features3=0x9c00 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics > make is statically linked, do dynamically linked program fault ? > After some more checks, only the statically linked programs crash. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 01/11/2018 15:43, Charlie Li wrote: > On 01/11/2018 12:04, Brooks Davis wrote: >> Is this failure with devel/llvm70? It's currently missing the patch >> required to make this work. https://reviews.freebsd.org/D17709 contains >> this patch among others. I'll see about getting it applied. >> > Yes, devel/llvm70. Will build with your port commit at my next opportunity. > After building world and kernel r340097, kernel runs fine, but every userspace program in world crashes with Illegal instruction. They all crash in exactly the same way. Example backtrace from bmake, running from objdir (first discovered after updating a poudriere jail and attempting to even start it): Reading symbols from /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done. done. [New LWP 100097] Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make --help'. Program terminated with signal SIGILL, Illegal instruction. #0 0x002f5664 in _init () (gdb) bt #0 0x002f5664 in _init () #1 0x002290fe in _start (ap=, cleanup=) at /usr/src/lib/csu/amd64/crt1.c:66 Given the line number referenced in crt1.c, I'm guessing this condition may have existed since at least r339351. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 01/11/2018 12:04, Brooks Davis wrote: > Is this failure with devel/llvm70? It's currently missing the patch > required to make this work. https://reviews.freebsd.org/D17709 contains > this patch among others. I'll see about getting it applied. > Yes, devel/llvm70. Will build with your port commit at my next opportunity. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 29/10/2018 20:11, Konstantin Belousov wrote: > Author: kib > Date: Tue Oct 30 00:11:30 2018 > New Revision: 339898 > URL: https://svnweb.freebsd.org/changeset/base/339898 > > Log: > Convert amd64_get/set_fs/gsbase to ifunc. > > Note that this is the first use of ifuncs in our userspace. > > Sponsored by: The FreeBSD Foundation > MFC after: 1 month > > Deleted: > head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.c > head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.h > Modified: > head/lib/libc/amd64/sys/Makefile.inc > head/lib/libc/amd64/sys/amd64_get_fsbase.c > head/lib/libc/amd64/sys/amd64_get_gsbase.c > head/lib/libc/amd64/sys/amd64_set_fsbase.c > head/lib/libc/amd64/sys/amd64_set_gsbase.c > Using LLVM 7 to build world, fails: --- amd64_get_fsbase.o --- /usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c:60:1: error: ifunc resolver function must have no parameters --- amd64_get_gsbase.o --- /usr/src/lib/libc/amd64/sys/amd64_get_gsbase.c:60:1: error: ifunc resolver function must have no parameters DEFINE_UIFUNC(, int, amd64_get_gsbase, (void **), static) ^ /usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: note: expanded from macro 'DEFINE_UIFUNC' --- amd64_get_fsbase.o --- DEFINE_UIFUNC(, int, amd64_get_fsbase, (void **), static) ^ /usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: note: expanded from macro 'DEFINE_UIFUNC' --- amd64_get_gsbase.o --- qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ ^ --- amd64_get_fsbase.o --- qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ ^ 1 error generated. --- amd64_get_gsbase.o --- 1 error generated. *** [amd64_get_gsbase.o] Error code 1 make[4]: stopped in /usr/src/lib/libc CI appears green after this commit, so I'm inclined to pin this on yet another instance of LLVM 7 being stricter than LLVM 6. Backing out this revision allows the build to continue (successfully). -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: unknown -z value: common-page-size=4096
On 29/09/2018 07:36, Dimitry Andric wrote: > You can apply this changeset from the clang700-import branch: > > https://svnweb.freebsd.org/changeset/base/337325 > Ah, I definitely missed this revision. I ended up working around the error by manually removing the offending bit from kern.pre.mk, which has the same effect of this changeset. > or just use the clang700-import branch wholesale. :-) > I would, but I also update and build head irregularly and prefer to build and run the newest code as they are committed. That, and I'm a bit lazy to run svn merge when I update :-) -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
unknown -z value: common-page-size=4096
I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64 base starting with r338990, and among other issues, ld.lld70 refuses to link the kernel: Building /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE/kernel.full --- kernel.full --- linking kernel.full ld.lld: error: unknown -z value: common-page-size=4096 ld.lld: error: unknown -z value: ifunc-noplt *** [kernel.full] Error code 1 make[2]: stopped in /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE (ARDMORE is basically GENERIC-NODEBUG, not that it matters) The ifunc-noplt is a known issue, it obviously didn't make it upstream in time for LLVM 7.0.0, and thus we carry the feature downstream. The crux of this link error though, emaste@ quipped in PR 230604 that LLD prior to 7.0.0 accepted but ignored unknown options, but now at least 7.0.0 disallows unknown options entirely. Which brings up the -z common-page-size=4096: has LLD been ignoring this part the whole time, and is it of any meaningful use anymore (it seemed to mean something with bfd)? -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: /usr/bin/ld: error: undefined symbol: main [r337834 -> r337903]
On 16/08/2018 12:26, Brad Davis wrote: > On Thu, Aug 16, 2018, at 10:13 AM, Xin LI wrote: >> This was caused by r337852, but I didn't investigated further. >> >> The problem is that we have a source file called 'moduli.c' in >> crypto/openssh/ while the build target was moduli, and bmake seen >> 'moduli' in source tree as older than moduli.c, and decided to rebuild >> it from source, while the two files are unrelated. > > Hi Xin, > > I don't see how that could be the case as I didn't move the file around, I > just moved how it gets installed. > > I have done many many builds with this change in and haven't seen this > problem.. > I've found this one intermittent at best. I'll run a buildworld on anything newer than r337852, get the linker error, update to even the next newer revision that changes completely unrelated files, build succeeds. Case in point, r337835 to r337863 failed, but r337863 to r337865 succeeded. This is all with META_MODE, so could be a bug with that. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: make distribution fails, A failure has been detected in another branch of the parallel make
On 27/07/2018 14:08, Martin Wilke wrote: > r336743 CONFSGRP should be CONFSGROUP ? > That line doesn't seem to make any difference. Probably a jemalloc interaction? Emitted when attempting to update a -CURRENT arm64.aarch64 cross-build jail: ===> sbin/dump (installconfig) --- _CONFSINS_null --- install -C -o root -g operator -m 664 /dev/null /usr/local/poudriere/jails/aarch64-current/etc/dumpdates : jemalloc_rtree.c:205: Failed assertion: "!dependent || leaf != NULL" Abort trap (core dumped) *** [_CONFSINS_null] Error code 134 make[4]: stopped in /usr/local/poudriere/jails/aarch64-current/usr/src/sbin/dump 1 error Looking at my amd64.amd64 logs again, the failed assertion message does indeed appear there as well. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: make distribution fails, A failure has been detected in another branch of the parallel make
On 27/07/2018 13:21, Martin Wilke wrote: > I just upgraded a jail in poudriere with latest head, > https://dpaste.de/bfTT/raw <https://dpaste.de/bfTT/raw>. > I was about to inquire about this myself. Can additionally confirm this has been happening since at least r336735. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: kernel -current build failures
On 23/05/2018 19:21, Michael Butler wrote:
> On a device with bluetooth (as in GENERIC modules) ..
>
> --- ng_ether.o ---
> /usr/src/sys/netgraph/ng_ether.c:871:2: error: no member named
> 'tqh_first' in 'struct ifnethead'; did you mean 'stqh_first'?
> TAILQ_FOREACH(ifp, &V_ifnet, if_link) {
> ^
> /usr/src/sys/sys/queue.h:724:15: note: expanded from macro 'TAILQ_FOREACH'
> for ((var) = TAILQ_FIRST((head)); \
> ^
> /usr/src/sys/sys/queue.h:721:36: note: expanded from macro 'TAILQ_FIRST'
> #define TAILQ_FIRST(head) ((head)->tqh_first)
> ^
>
Looks like this is fixed in r334123.
--
Charlie Li
Can't think of a witty .sigline today…
(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)
signature.asc
Description: OpenPGP digital signature
Re: /lib/casper: read error: Invalid argument
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14/01/2018 06:10, Hartmann, O. wrote: > I tried to investigate with the USB image created 10th January > 2018 from ISO downloads and it showed, that /boot/ was obviously > intact, but files in /usr/sbin, /usr/bin were zero in size, also > some libs in /usr/lib and /lib. While /boot/ seemingly being > already installed while other portions failed, I knew from the past > that I had to replace all /boot, /bin, /sbin, /usr/sbin, /usr/bin, > /lib, /usr/lib , /usr/libexec and /libexec from the recent USB > image. I did so via "pax -v -rw -pe", but I had to "chflags noschg" > some files/libraries on the target to get them overwritten. I > simply did a > > chflags noschg * > > to every folder/subfolder and "pax'ed" the destination then. So > far. I'm able to boot into single user again, but when it comes to > the shell and /bin/sh is supposed to be executed, I get the > strange message: > > /lib/casper/: read error: Invalid argument > > and the prompt is jumping back to ensure the PASSWORD (console is > password protected). > Something like this happened to me once, albeit a libc.so symbol mismatch after a hard crash that corrupted that and some more system files. So far you're on the right track with copying files off the image, though I extracted the relevant files/directory structures from the base.txz that bsdinstall uses. > Something is hindering to start the compiler somehow and it is > related to /lib/casper/: read error: Invalid argument? > > What is wrong here? How to fix this? > Don't reboot out of the USB image. Stay there and chroot into your mounted root filesystem, then run make installworld. - -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCgAdFiEE/RdyC3Asy49czZEGtQ4IJhNZSS0FAlpbRZ0ACgkQtQ4IJhNZ SS0aAxAAplLJ9NCLgttDDRLANK+ql15E5AE6pV1Y8jdLM7CunUzgMsyg/1hhy8ZK 2TG/0mEE7+jsxYjW5Wu9uBjsGaRuwY4dAO7TNdkbn3DMzJsrbBCfkXKGjeFKHwQu CB2fZRwfH6hdR0CxMeth9ftPHn8mbEqwl5YC4SLXBzixgi8Hpjj5J2Gne2nIur7q yhXdChon+k50zl+WxAeCNXTkKK7QKEANh56D/6VgTEyR1POFJqKBywLKm07tePUC 4Yqo4IPQsJsfQFCJ5V7o87PWqIpfsb/gPJkEsT81MKT0/XWRHXtHvzA0Ero7dMDS WbGFblyPg7GRzNRC7FLfqPmcOW6Qc3JFr2KA6b5IVoV3IhCor1o+mEV8tkZY2iPz scCImjPqr+QWoSt2Hv0QUc8i3L40pc4OAxslC8lCOKZrePA/nIowfRS8oJmhgKrL 9gJDQxPQGAn0fYKoY3n+oI95YfIn9MBE6hmpUKfXSRqh+s6xX5sMnf2tqm7Swiul Tjp05MbhBQn/Yxmwxa8Lnk6U3jtumza8qS8SXX3b039+8ADd4Y9L6l0IVk7+cG2i uNXxbl9o5jqoUyRgEvGAGzohGGUzzpz4k/wHht1gWeEmww4WJ2VN6eL8FFepWi2v o5rOeFbnuSzqOOslA6rQ6mkwDKPRoIVNFWEkQO1FR9MjyhKk7+4= =YOoR -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"
