[Bug 279122] /boot/kernel/kernel: "not stripped"
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279122 --- Comment #2 from VinÃcius Zavam --- (In reply to Warner Losh from comment #1) thank you for the feedback about it, much appreciated. now, quick question: would it make sense to have an 'opt-in' flag added into the installer (with proper warnings related to it)? I assume certain conditions would also make sense to offer that additional flag - e.g.: should the 'kernel-dbg.txz' be chosen as one of the DISTFILES, simply do not offer to strip anything. of course: I'm considering that when I want to get something tested or debugged/troubleshooted myself, I just spin up a machine with as many default settings as possible (that includes the non-stripped kernel as we offer today) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279398] Environment variable pointing to cross-compiler is not properly set in tools/build/make.py
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279398 Mark Linimon changed: What|Removed |Added Component|Spam|misc Assignee|bugmeis...@freebsd.org |b...@freebsd.org Product|Other |Base System Version|unspecified |Unspecified --- Comment #1 from Mark Linimon --- ^Triage: attempt to rescue this PR from the junkpile. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279403] typedef redeclaration in base include becoming an issue for DTrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279403
Bug ID: 279403
Summary: typedef redeclaration in base include becoming an
issue for DTrace
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: antran...@freebsd.am
root@srv0:~ # cat test.d
#include
tcp:::accept-established
{
}
root@srv0:~ # dtrace -C -s test.d
dtrace: failed to compile script test.d: line 1: typedef redeclared: __uint8_t
root@srv0:~ # dtrace -H -C -s test.d
/usr/include/sys/socket.h
. /usr/include/sys/cdefs.h
. /usr/include/sys/_types.h
.. /usr/include/machine/_types.h
... /usr/include/x86/_types.h
/usr/include/machine/_limits.h
. /usr/include/x86/_limits.h
. /usr/include/sys/_iovec.h
. /usr/include/machine/_align.h
.. /usr/include/x86/_align.h
. /usr/include/sys/_sockaddr_storage.h
dtrace: failed to compile script test.d: line 1: typedef redeclared: __uint8_t
root@srv0:~ #
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 271826] FreeBSD is disastrously slow on a PowerMac G5, freezing at every command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271826 --- Comment #26 from Denis Ahrens --- I tested the kernel from Mitch and sad news is that the problem is still there. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259833] Typo in rcorder(8)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259833 Benedict Reuschling changed: What|Removed |Added CC||b...@freebsd.org Resolution|--- |FIXED Status|New |Closed --- Comment #1 from Benedict Reuschling --- This has been fixed in 47972d6dc4cb18cf2faf15181b9bdf482b92400d, but I forgot to close this PR. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271826] FreeBSD is disastrously slow on a PowerMac G5, freezing at every command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271826 --- Comment #27 from Justin Hibbits --- (In reply to Denis Ahrens from comment #26) Other big changes that are PPC970 relevant are in the pmap logic. If you take a look at the git log of sys/powerpc/aim/mmu_oea64.c and sys/powerpc/aim/moea64_native.c, you can try to revert (git revert, or a spiritual revert if there are conflicts) some of them and see what impacts. Some options: e2d6c417 (superpages) a79540111 (micro-optimizations of PVO-PTE logic) bc94b7009 (re-merge ISA3 HPT with moea64 native HPT) -- this one *will* have conflicts. Another shot in the dark is e44ed9d34 (atomics) This is all just a guess based on trimming through `git diff origin/releng/12.4..origin/releng/13.1 sys/powerpc`. There may be other issues, but these are the first I see as possibilities. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271826] FreeBSD is disastrously slow on a PowerMac G5, freezing at every command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271826 b...@desync.com changed: What|Removed |Added CC||b...@desync.com --- Comment #28 from b...@desync.com --- Created attachment 251098 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251098&action=edit timebase sync hack I'm not sure my symptoms exactly match what's described here, but it seems like timebase sync may be broken on G5. ofwcons freezes for about a minute every so often, the fans go full blast at the same time because powermac_thermal is hung. The system is usually (always?) responsive over ssh while this is happening. Anyway, the attached hack seems to help in my case, as least. Only tested on the later PCIe dual and quad G5s. I'm not sure timebase sync is even supported on PCI-X powermacs (definitely not on my Xserve G5 with weird sync via I2C). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279403] typedef redeclaration in base include becoming an issue for DTrace
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279403 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org Status|New |Open --- Comment #1 from Mark Johnston --- Has this example ever worked on FreeBSD? The problem isn't with duplicate typedefs; those are errors in C as well. In dt_parser.c we have: 1451 /* 1452 * If we are nested inside of a C include file, add the declaration to 1453 * the C definition module; otherwise use the D definition module. 1454 */ 1455 if (yypcb->pcb_idepth != 0) 1456 dmp = dtp->dt_cdefs; 1457 else 1458 dmp = dtp->dt_ddefs; When we hit the error, we're actually using ddefs instead of cdefs, which is incorrect according to the comment. How is pcb_idepth set? It's adjusted when we see line control directives emitted by the processor, but it looks like our version of the D lexer isn't handling this properly somehow. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279413] NTPD: Leap-Seconds.list IPv6 alone cannot be obtained and error occurs.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279413 Bug ID: 279413 Summary: NTPD: Leap-Seconds.list IPv6 alone cannot be obtained and error occurs. Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: tak...@airport.fm bug #275419 Errors occur only in IPv6 after updating. "HPiers.obspm.fr" Error that occurs because this host does not communicate with IPv6. No errors occur under dual stack with IPv4. adhoc # sysrc ntp_leapfile_sources=https://data.iana.org/time-zones/tzdb/leap-seconds.list -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279415] requesting git tags for patch releases in (kernel) source repository
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279415 Bug ID: 279415 Summary: requesting git tags for patch releases in (kernel) source repository Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: nicholas.h.bri...@gmail.com There are times it would be pretty handy to be able to "git diff" (or "git shortlog") between patch releases in, for example, the releng/14.0 branch. It seems as though it wouldn't be hard for the release engineering team to apply a tag to the git repository after they have committed sources for a new patch release. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279416] requesting git tags for patch releases in (kernel) source repository
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279416 Bug ID: 279416 Summary: requesting git tags for patch releases in (kernel) source repository Product: Base System Version: 14.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: nicholas.h.bri...@gmail.com There are times it would be pretty handy to be able to "git diff" (or "git shortlog") between patch releases in, for example, the releng/14.0 branch. It seems as though it wouldn't be hard for the release engineering team to apply a tag to the git repository after they have committed sources for a new patch release. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279416] requesting git tags for patch releases in (kernel) source repository
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279416 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|r...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279415] requesting git tags for patch releases in (kernel) source repository
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279415 Mark Linimon changed: What|Removed |Added Status|New |Closed Resolution|--- |DUPLICATE --- Comment #1 from Mark Linimon --- *** This bug has been marked as a duplicate of bug 279416 *** -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279415] requesting git tags for patch releases in (kernel) source repository
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279415 --- Comment #2 from Nick Briggs --- Sorry - browser/bugzilla reported an error submitting the bug report when I guess it did in fact submit it. Thanks for cleaning up. -- You are receiving this mail because: You are the assignee for the bug.
