[Bug 261005] hostname -d is not resolved domain information correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261005 Mark Linimon changed: What|Removed |Added Keywords||honeypot -- You are receiving this mail because: You are the assignee for the bug.
[Bug 173321] ports(7) man page -- no info on building with debugging info
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173321 Oleksandr Tymoshenko changed: What|Removed |Added Component|Documentation |Manual Pages CC||d...@freebsd.org Assignee|d...@freebsd.org |b...@freebsd.org Chris Davidson changed: What|Removed |Added CC||Christopher.davidson@gmail. ||com --- Comment #4 from Chris Davidson --- Hi, The latest -CURRENT, at the time of this message, has the option of WITH_DEBUG to enable debug capabilities in the ports(7) manual page. I think this meets the need of the request. If so, I would say it is ready for a closure. Kind Regards, Chris -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277671] 14-RELEASE/14-STABLE crash with heavy disk IO on AMD Asus x670e motherboard and Intel i225 (igc) breakage NIC non-functioning
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277671 --- Comment #5 from Cameron --- (In reply to Vasyl S. from comment #3) Maybe see if you can reproduce it by installing/running net-p2p/monero-cli I run it with these flags: monerod_enable="YES" monerod_flags="--max-concurrency=12" Maybe adjust the concurrency according to your CPU's specs? But if you reduce it, it's possible you may not be able to trigger the crash (I should probably experiment with this). I haven't been able to reproduce this with any other software yet... Not sure I want to use transmission on this box... but syncthing might work for me. I assume you mean net/syncthing ? Are you a syncing lot of data with it? I guess I want to try and at least partially replicate your workload to try to try and get the same results. (BTW, I'd never heard of syncthing before, but it sounds _really_ useful!) -- 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 #19 from Denis Ahrens --- can also confirm now that 12.4 is installing and running fine on a dual g5 powermac. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278579] nvi can malfunction if one types invalid UTF-8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278579 Bug ID: 278579 Summary: nvi can malfunction if one types invalid UTF-8 Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: r...@lcs.mit.edu If LANG is set to C.UTF-8, then typing illegal UTF-8 in nvi can cause v_event_get() to access elements in gp->i_event[] even though gp->i_cnt is zero -- that is, elements that have not been properly set. Here's how this can happen. v_event_get() calls gp->scr_event(), which is cl_event(). If the input is bad UTF-8, cl_event() sets evp->e_event to E_STRING, evp->e_len to zero, and returns zero (no error). v_event_get() calls v_event_append(), but since e_len is zero, nothing is put in gp->i_event[] and gp->i_cnt is not incremented. But the code goes on to use gp->i_event[gp->i_next], even though that element wasn't set. Another consequence is that v_event_get() calls QREM(1) before returning (line 670 of common/key.c), but since i_cnt was likely zero, QREM()'s decrement may wrap i_cnt to a huge unsigned. Since i_cnt can now incorrectly be > 0, v_key()'s next call to v_event_get() can incorrectly return whatever happened to be in gp->i_event[0], and if it's not valid, the abort() in v_event_err() may be called. You can see the abort() by setting LANG to C.UTF-8, running nvi, and typing a pair of characters with high bits set that aren't legal utf8. On my keyboard, I can type option-u option-i, which generates 0xf5 0xe9. Perhaps this can be fixed by 1) goto retry in v_event_get() if gp->scr_event() returns an E_STRING with e_len == 0, and 2) set clp->skip = 0 in cl_event() on Invalid input, to reset the UTF-8 parsing state. But I do not understand the code well enough to be sure. -- 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 Denis Ahrens changed: What|Removed |Added CC||de...@h3q.com --- Comment #18 from Denis Ahrens --- I can confirm this behaviour. I had a fine running FreeBSD 12 test disk which I nulled to try the latest stuff (14). But the 14 installer (RELEASE and STABLE from 18th of April) is so slow that it is impossible to use. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278574] usr.bin/pom: If the -t option is combined with a time zone with a different time zone than UTC, result doesn't match
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278574 Bug ID: 278574 Summary: usr.bin/pom: If the -t option is combined with a time zone with a different time zone than UTC, result doesn't match Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: tatsuki_mak...@hotmail.com When comparing the following commands, the results are off by 9 hours. env TZ=Asia/Tokyo pom env TZ=Asia/Tokyo pom `env TZ=Asia/Tokyo date '+-t %H.%M.%S'` The 9-hour time difference is the Asia/Tokyo time difference, which is 9 hours throughout the year. The cause of this problem is that caph_cache_tzdata() is not executed before caph_enter(). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277671] 14-RELEASE/14-STABLE crash with heavy disk IO on AMD Asus x670e motherboard and Intel i225 (igc) breakage NIC non-functioning
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277671 --- Comment #4 from Vasyl S. --- note: In my case it's CPU: Intel(R) N100 (806.40-MHz K8-class CPU), zfs mirror with two ada0: ACS-3 ATA SATA 3.x device (sata), FreeBSD 12 was running with no problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277671] 14-RELEASE/14-STABLE crash with heavy disk IO on AMD Asus x670e motherboard and Intel i225 (igc) breakage NIC non-functioning
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277671 Vasyl S. changed: What|Removed |Added CC||vasyl.samoi...@gmail.com --- Comment #3 from Vasyl S. --- I am experiencing the same behavior. 14-STABLE, root on ZFS. Can easily be replicated with heavy I/O, in my case it's syncthing and transmission-bt. Every time I download anything with transmission that will saturate disk I/O system will lock up and reboot itself. I even connected a monitor but no messages being printed out before lockup and reboot, so I don't see a kernel dump even being called upon. FreeBSD 14.0-STABLE #18 50f771371: Sat Apr 13 20:11:34 EEST 2024 -- You are receiving this mail because: You are the assignee for the bug.
