[Bug 277783] libc fma() doesn't not return the correct zero sign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783 Steve Kargl changed: What|Removed |Added Attachment #251421|text/x-csrc |text/plain mime type|| --- Comment #12 from Steve Kargl --- Created attachment 251421 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251421=edit Test code that shows results compared to MPFR This is the test code that includes the comparisons for the testsuite and Victor's input under the four rounding modes. It requires MPFR and GMP to compile and execute. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277783] libc fma() doesn't not return the correct zero sign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783
--- Comment #11 from Steve Kargl ---
Someone smarter than me may need to look at this! With the original
src/s_fma.c, I see
dble (x,y,z): -0x1p+0 0x1p+0 0x1p+0
mpfr (x,y,z): -0x1p+0 0x1p+0 0x1p+0
mpfrlibm
RNDN: 0x0p+0 0x0p+0
RNDU: 0x0p+0 0x0p+0
RNDD: -0x0p+0 -0x0p+0
RNDZ: 0x0p+0 0x0p+0
dble (x,y,z): 0x1p+0 -0x1p+0 0x1p+0
mpfr (x,y,z): 0x1p+0 -0x1p+0 0x1p+0
mpfrlibm
RNDN: 0x0p+0 0x0p+0
RNDU: 0x0p+0 0x0p+0
RNDD: -0x0p+0 -0x0p+0
RNDZ: 0x0p+0 0x0p+0
dble (x,y,z): -0x1p+0 -0x1p+0 -0x1p+0
mpfr (x,y,z): -0x1p+0 -0x1p+0 -0x1p+0
mpfrlibm
RNDN: 0x0p+0 0x0p+0
RNDU: 0x0p+0 0x0p+0
RNDD: -0x0p+0 -0x0p+0
RNDZ: 0x0p+0 0x0p+0
dble (x,y,z): 0x1.8p-501 0x1.4p-500 -0x1p-1000
mpfr (x,y,z): 0xf.fffcp-504 0x1.4p-500 -0x1p-1000
mpfrlibm
RNDN: -0x0p+0 0x0p+0
RNDU: -0x0p+0 0x0p+0
RNDD: -0x1p-1074 -0x1p-1074
RNDZ: -0x0p+0 0x0p+0
The first groups of three are fma(-1.,1.,1.), fma(1.,-1.,1.), and
fma(-1.,-1.,-1.) with the four rounding modes. The group is Victor's example
where the rounding is wrong.
If one looks in src/s_fma.c, there is a special case for addends that sum to
zero.
This is the 'if (r.hi == 0.0) {}' block of code (lines 263-274). If I comment
out this block, I get wrong results for fma(-1.,1.,1.), fma(1.,-1.,1.), and
fma(-1.,-1.,-1.), but correct results for Victor's input. :(
dble (x,y,z): -0x1p+0 0x1p+0 0x1p+0
mpfr (x,y,z): -0x1p+0 0x1p+0 0x1p+0
mpfrlibm
RNDN: 0x0p+0 0x0p+0
RNDU: 0x0p+0 0x0p+0
RNDD: -0x0p+0 0x0p+0
RNDZ: 0x0p+0 0x0p+0
dble (x,y,z): 0x1p+0 -0x1p+0 0x1p+0
mpfr (x,y,z): 0x1p+0 -0x1p+0 0x1p+0
mpfrlibm
RNDN: 0x0p+0 0x0p+0
RNDU: 0x0p+0 0x0p+0
RNDD: -0x0p+0 0x0p+0
RNDZ: 0x0p+0 0x0p+0
dble (x,y,z): -0x1p+0 -0x1p+0 -0x1p+0
mpfr (x,y,z): -0x1p+0 -0x1p+0 -0x1p+0
mpfrlibm
RNDN: 0x0p+0 0x0p+0
RNDU: 0x0p+0 0x0p+0
RNDD: -0x0p+0 0x0p+0
RNDZ: 0x0p+0 0x0p+0
dble (x,y,z): 0x1.8p-501 0x1.4p-500 -0x1p-1000
mpfr (x,y,z): 0xf.fffcp-504 0x1.4p-500 -0x1p-1000
mpfrlibm
RNDN: -0x0p+0 -0x0p+0
RNDU: -0x0p+0 -0x0p+0
RNDD: -0x1p-1074 -0x1p-1074
RNDZ: -0x0p+0 -0x0p+0
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #10 from mario felicioni --- Its too late :P https://github.com/pbatard/rufus/issues/2500 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #9 from Mark Peek --- Mario, I turned issues on for my repo so we can discuss any issues there. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279690] Inbuilt keyboard capslock LED does not work past bootloader on a MacBook Pro 11.4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279690 --- Comment #1 from megaman...@gmail.com --- Possibly related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139144 It's not obvious whether this could be the issue, as I'm not sure that a keymap is loaded until X is started. I'll fix the patch (it's 15 years old) and see what comes of it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #8 from mario felicioni --- I'm trying to compile your fork of Rufus on my Ubuntu 23.10 box,but I'm having some troubles. I see that your github does not accept the bug tickets. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 Mark Peek changed: What|Removed |Added CC||m...@freebsd.org --- Comment #7 from Mark Peek --- There is another way to get this working which is to follow the rufus developer suggestion of providing a patch. Here is a working branch of rufus that has a simple patch to allow bhyve disks to show up in the rufus UI and can write through to a mapped SD. Give it a try and let me know if it works for you. If so, then I'll PR it back to the rufus main repo. https://github.com/markpeek/rufus/tree/markpeek-bhyve -- You are receiving this mail because: You are the assignee for the bug.
[Bug 275255] iwlwifi: panic after iwlwifi0: lkpi_iv_newstate: error -5 during state transition 5 (RUN) -> 0 (INIT) (8xxx/9xxx chipsets)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275255 --- Comment #22 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7ad7453748e2adafa1e1a3e44b02fc852d4c5301 commit 7ad7453748e2adafa1e1a3e44b02fc852d4c5301 Author: Bjoern A. Zeeb AuthorDate: 2024-05-22 02:24:51 + Commit: Bjoern A. Zeeb CommitDate: 2024-06-12 13:58:36 + LinuxKPI: 802.11: change teardown order to avoid iwlwifi firmware crashes While the previous order worked well for iwlwifi 22000 and later chipsets (AXxxx, BE200), earlier chipsets had trouble and ran into firmware crashes. Change the teardown order to avoid these problems. The inline comments in lkpi_sta_run_to_init() (and lkpi_disassoc()) try to document the new order and also the old problems we were seeing (too early sta removal or silent non-removal) leading to follow-up problems. There is a possible further problem still lingering but a lot harder to trigger (see comment in review) and likely related to some other doings so we'll track it separately. Sponsored by: The FreeBSD Foundation PR: 275255 Tested with:AX210, 8265 (bz); 9260 (Bakul Shah) Differential Revision: https://reviews.freebsd.org/D45293 (cherry picked from commit 5a4d24610fc6143ac1d570fe2b5160e8ae893c2c) sys/compat/linuxkpi/common/src/linux_80211.c | 84 ++-- 1 file changed, 55 insertions(+), 29 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 274382] iwlwifi Invalid TXQ id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274382 --- Comment #78 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2ab1b827d49f473e30a91382d2ce03e268af45c5 commit 2ab1b827d49f473e30a91382d2ce03e268af45c5 Author: Bjoern A. Zeeb AuthorDate: 2024-06-05 22:54:36 + Commit: Bjoern A. Zeeb CommitDate: 2024-06-12 13:59:46 + LinuxKPI: 802.11: make sure we can send DISASSOC or DEAUTH frames The "Invalid TXQ" error from iwlwifi seems to be triggered by a frame being sent for a sta which is no longer known to the driver/fw. While we make sure to trigger the sending of the frame in net80211 early enough (by calling (*iv_newstate)() early on rather than at the end), TX in LinuxKPI is run in a deferred task. When we drop the net80211 ic lock again and re-acquire the LHW lock the packet may not yet have made it to the driver. Work around this between the (ic and lhw) locks by making sure (a) no new packets get queued after we return from (*iv_newstate)(), and (b) the TX task has run or gets cancelled and we manually push any remaining packets out (or let lsta_free() clean them up). The disabled packet queuing now also needs to be re-enabled in scan_to_auth() in case an lsta is staying in service or gets re-used. Also make sure that any following lkpi_wake_tx_queues() calls no longer ignore queues which have not seen a prior dequeue. This former workaround "feature" (ltxq->seen_dequeue) should be fully garbage collected in a later change on its own. Sponsored by: The FreeBSD Foundation PR: 274382 Tested by: emaste, lwhsu, thj, rkoberman at gmail.com Accepted by:adrian Differential Revision: https://reviews.freebsd.org/D45508 (cherry picked from commit 886653492945f7e945eb9bdaf5bc2ae26df96236) sys/compat/linuxkpi/common/src/linux_80211.c | 95 +--- 1 file changed, 86 insertions(+), 9 deletions(-) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 279585] lang/python311: Improve build times
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279585 --- Comment #2 from Daniel Engberg --- Friendly ping -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279698] 'make delete-old' fails to delete directories because of some really old files in them
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279698 Bug ID: 279698 Summary: 'make delete-old' fails to delete directories because of some really old files in them Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: y...@freebsd.org Here is what 'make delete-old' prints: [root@yv /usr/src]# make delete-old >>> Removing old files (only deletes safe to delete libs) >>> Old files removed >>> Removing old directories rmdir: /usr/share/man/en.UTF-8/cat9: Directory not empty rmdir: /usr/share/man/en.UTF-8/cat8: Directory not empty rmdir: /usr/share/man/en.UTF-8/cat7: Directory not empty rmdir: /usr/share/man/en.UTF-8/cat5: Directory not empty rmdir: /usr/share/man/en.UTF-8/cat4: Directory not empty rmdir: /usr/share/man/en.UTF-8/cat3: Directory not empty rmdir: /usr/share/man/en.UTF-8/cat2: Directory not empty rmdir: /usr/share/man/en.UTF-8/cat1: Directory not empty rmdir: /usr/share/man/en.UTF-8: Directory not empty rmdir: /usr/share/man/en.ISO8859-1/cat8: Directory not empty rmdir: /usr/share/man/en.ISO8859-1/cat4: Directory not empty rmdir: /usr/share/man/en.ISO8859-1: Directory not empty rmdir: /usr/share/man/cat8: Directory not empty rmdir: /usr/share/man/cat7: Directory not empty rmdir: /usr/share/man/cat3: Directory not empty rmdir: /usr/share/man/cat2: Directory not empty rmdir: /usr/share/man/cat1: Directory not empty rmdir: /usr/share/certs/blacklisted: Directory not empty >>> Old directories removed To remove old libraries run 'make delete-old-libs'. [root@yv /usr/src]# It fails to remove the directories because there are some old files in them, for example: [root@yv /usr/src]# ls -l /usr/share/man/en.UTF-8/cat5/ total 280 -rw-r--r-- 1 root wheel 399 Oct 29 2011 auth.conf.5.gz -rw-r--r-- 1 root wheel 3713 Jan 6 2011 crontab.5.gz -rw-r--r-- 1 root wheel 1314 May 31 2011 devfs.rules.5.gz -rw-r--r-- 1 root wheel 916 Apr 22 2010 ethers.5.gz -rw-r--r-- 1 root wheel 5315 Jun 22 2010 exports.5.gz -rw-r--r-- 1 root wheel 3147 Feb 15 2010 fstab.5.gz -rw-r--r-- 1 root wheel 1362 Aug 15 2011 group.5.gz -rw-r--r-- 1 root wheel 1091 Sep 14 2011 hosts.5.gz -rw-r--r-- 1 root wheel 1995 Aug 14 2011 libmap.conf.5.gz -rw-r--r-- 1 root wheel 2737 Aug 20 2011 loader.conf.5.gz -rw-r--r-- 1 root wheel 3314 Oct 24 2010 nsswitch.conf.5.gz -rw-r--r-- 1 root wheel 1872 Oct 29 2011 pam.conf.5.gz -rw-r--r-- 1 root wheel 31709 Aug 17 2010 pf.conf.5.gz -rw-r--r-- 1 root wheel 25074 Aug 18 2010 rc.conf.5.gz -rw-r--r-- 1 root wheel 2573 Sep 14 2011 resolv.conf.5.gz -rw-r--r-- 1 root wheel 5061 Aug 13 2010 src.conf.5.gz -rw-r--r-- 1 root wheel 11158 Jan 11 2010 ssh_config.5.gz -rw-r--r-- 1 root wheel 2035 Jan 6 2012 ttys.5.gz [root@yv /usr/src]# Other directories also have some very old files. Shouldn't 'make delete-old' determine that these files are old and don't belong there? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 257353] lang/python38: Intermittently fails to build under QEMU: BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257353 greif changed: What|Removed |Added CC||gr...@ticse.net --- Comment #9 from greif --- I ran into the same problem while building various python versions (3.9, 3.10, 3.11) for armv7 via QEMUed poudriere on an amd64 host. As a workaround using ALLOW_MAKE_JOBS=no seem to fix it but might be my observation bias, as it hung for 3 to 4 times, then i set the option and it built fine. Fingers crossed it stays like that. # uname -a FreeBSD poudriere 13.2-RELEASE-p11 FreeBSD 13.2-RELEASE-p11 GENERIC amd64 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 279550] tun interface get stuck and cannot be destroyed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279550 --- Comment #2 from Ivan --- Sorry for the sub reply, but I'm not getting any emails from bugzilla for some reason. It happened once, after some time the stuck interface self-destructed. It has not reproduced again so far. --- Comment #3 from Ivan --- Sorry for the sub reply, but I'm not getting any emails from bugzilla for some reason. It happened once, after some time the stuck interface self-destructed. It has not reproduced again so far. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279550] tun interface get stuck and cannot be destroyed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279550 --- Comment #2 from Ivan --- Sorry for the sub reply, but I'm not getting any emails from bugzilla for some reason. It happened once, after some time the stuck interface self-destructed. It has not reproduced again so far. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279381] FreeBSD 13.3-RELEASE breaks isp driver with Qlogic QLE2692 16Gb fibre channel cards
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279381 --- Comment #4 from drkspc --- (In reply to Michael Osipov from comment #3) There has been a change in how firmware is loaded for Qlogic cards (https://cgit.freebsd.org/src/commit/?id=10ed63fc06cb9902cc783ce8d0086c9aa97ed1e1), which is included in 13.3 and since last week also 14.1. See also bug #273263 for more context. I now built a custom kernel based on the releng/13.3 branch and reverted the commits introducing revised firmware loading. Rebooting into the kernel with the "old" firmware handling, everything works again and multipath devices show up properly. It's possible that our cards' firmware is in a non-optimal state (i.e. primary image not active). However, we've been running in this hardware/firmware configuration for years without any issues, so this is still a breaking change for us. I will try to have a closer look at the firmware state next week. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279381] FreeBSD 13.3-RELEASE breaks isp driver with Qlogic QLE2692 16Gb fibre channel cards
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279381 Michael Osipov changed: What|Removed |Added CC||micha...@freebsd.org --- Comment #3 from Michael Osipov --- Did you check what has changed in the driver between those versions? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #6 from mario felicioni --- I've realized that my GPU has one integrated USB controller. It is the RTX 2080 Ti and FreeBSD detect 4 slots : 02:00.0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti] (rev a1) 02:00.1 Audio device: NVIDIA Corporation TU102 High Definition Audio Controller (rev a1) 02:00.2 USB controller: NVIDIA Corporation TU102 USB 3.1 Host Controller (rev a1) 02:00.3 Serial bus controller: NVIDIA Corporation TU102 USB Type-C UCSI Controller (rev a1) So I tried to pass only the slots 2 and 3,because I don't need to pass the GPU itself and / or the audio slot (2/0/1),like this : -s 8:2,passthru,2/0/2 \ -s 8:3,passthru,2/0/3 \ This is what happened : Assertion failed: (mr->name == memp->name), function unregister_mem, file /usr/src/usr.sbin/bhyve/mem.c, line 344. So,now. We have two different problems to deal with. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274382] iwlwifi Invalid TXQ id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274382 --- Comment #77 from Bjoern A. Zeeb --- (In reply to Vladislav Shabanov from comment #76) Please open a new bug report with this information. I would also be curious if anything got logged before the Queue stuck message. If so please attach it there to or provide the full dmesg output. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 church...@gmail.com changed: What|Removed |Added CC||church...@gmail.com --- Comment #5 from church...@gmail.com --- " 1) I can see the usb stick in Windows,so it works,at least in Windows,it is recognized and I can copy and paste files from/to the usb stick 2) I don't have and you can't ask me to BUY a dedicated USB controller to be able to allow Rufus to detect the usb stick when Windows detects it " These two comments are irrelevant. Windows is not seeing a USB device at all; Your bhyve host is seeing a USB device that provides storage and is creating a block device on the host. You are then passing that block device through to the guest as a standard ACHI hard drive. Windows sees a "standard" hard drive. Windows being able to use the provided disk does not in any way suggest that a tool designed to interface directly with raw USB devices should be able to see the USB stick itself. I understand the frustration that currently the only way to achieve what you're after is to pass an entire USB controller through to the guest, but as mentioned, what you are really after is individual USB device passthrough, which would require support in bhyve. You could try asking on the virtualisation mailing list to see if any work has been done or is being considered for usb device pass through. This particular use case for usb storage probably isn't that much in demand seeing as the storage can be passed through as you already are (and it's not exactly a difficult work around to just dump whatever image you want onto the stick on the host itself), but there are many other types of usb device that would be useful to pass through without having to go the route of reserving and passing a full controller. Also, even though you clearly state you don't want to pass through a controller, it's worth checking if you have more than one. I for example could very easily pass through the front usb2 controller on my board (it has 4, usb2/3 front & usb2/3 rear), put the usb stick in the front, and have all my host usb devices in the rear ports. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Dimitry Andric changed: What|Removed |Added Resolution|--- |Not A Bug Status|New |Closed --- Comment #3 from Dimitry Andric --- (In reply to Lorenzo Salvadore from comment #2) Ah yes, this is because the old copy of /usr/include/c++/v1/setjmp.h must be deleted upon an upgrade. A fresh install will never have this issue. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Lorenzo Salvadore changed: What|Removed |Added CC||salvad...@freebsd.org --- Comment #2 from Lorenzo Salvadore --- I had a similar issue recently on CURRENT. In my case the cause was that I had built base from sources forgetting to run "make delete-old". After running it everything was fixed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 --- Comment #1 from Dimitry Andric --- I can't reproduce this on freshly installed 14.1-RELEASE. The program compiles just fine. How have you installed your system? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #15 from f...@fehcom.de ---
New environment:
1. I've taken the FreeBSD 14.0 and installed the very same NVME on a new
maschine with mostly identical CPU.
- Previous: AMD Ryzen 5 5500u, Model 60h-6fh, Patch Level: 8608103, CezanneCPU
05
- New: AMD Ryzen 7 5700U, Model 60h-6Fh, Patch Level: 8608103, CezanneCPU
03, AGESA CezannePI 1003c
2. I've upgraded from FreeBSD 14.0 to 14.1:
FreeBSD amr5 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8
GENERIC amd64
Since the hardware swop, crashes are less frequent. However, they again point
to the same assembler routine:
panic: page fault
cpuid = 0
time = 1718182385
KDB: stack backtrace:
#0 0x80b7fbfd at kdb_backtrace+0x5d
#1 0x80b32961 at vpanic+0x131
#2 0x80b32823 at panic+0x43
#3 0x80fff91b at trap_fatal+0x40b
#4 0x80fff966 at trap_pfault+0x46
#5 0x80fd6a48 at calltrap+0x8
#6 0x83feeb95 at dma_fence_signal+0x35
#7 0x840231b8 at amdgpu_fence_process+0xe8
#8 0x840af1cc at gfx_v9_0_eop_irq+0xcc
#9 0x8402e590 at amdgpu_irq_dispatch+0xb0
#10 0x8402da30 at amdgpu_ih_process+0xb0
#11 0x8402e190 at amdgpu_irq_handler+0x20
#12 0x80da1059 at lkpi_irq_handler+0x29
#13 0x80af0737 at ithread_loop+0x257
#14 0x80aecd1f at fork_exit+0x7f
#15 0x80fd7aae at fork_trampoline+0xe
Uptime: 1h20m44s
Dumping 1163 out of 15712 MB:..2%..12%..21%..31%..42%..51%..61%..71%..82%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
57 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985
--- Comment #14 from f...@fehcom.de ---
Comment on attachment 251410
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251410
core.text
New environment:
1. I've taken the FreeBSD 14.0 and installed the very same NVME on a new
maschine with mostly identical CPU.
- Previous: AMD Ryzen 5 5500u, Model 60h-6fh, Patch Level: 8608103, CezanneCPU
05
- New: AMD Ryzen 7 5700U, Model 60h-6Fh, Patch Level: 8608103, CezanneCPU
03, AGESA CezannePI 1003c
2. I've upgraded from FreeBSD 14.0 to 14.1:
FreeBSD amr5 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8
GENERIC amd64
Since the hardware swop, crashes are less frequent. However, they again point
to the same assembler routine:
panic: page fault
cpuid = 0
time = 1718182385
KDB: stack backtrace:
#0 0x80b7fbfd at kdb_backtrace+0x5d
#1 0x80b32961 at vpanic+0x131
#2 0x80b32823 at panic+0x43
#3 0x80fff91b at trap_fatal+0x40b
#4 0x80fff966 at trap_pfault+0x46
#5 0x80fd6a48 at calltrap+0x8
#6 0x83feeb95 at dma_fence_signal+0x35
#7 0x840231b8 at amdgpu_fence_process+0xe8
#8 0x840af1cc at gfx_v9_0_eop_irq+0xcc
#9 0x8402e590 at amdgpu_irq_dispatch+0xb0
#10 0x8402da30 at amdgpu_ih_process+0xb0
#11 0x8402e190 at amdgpu_irq_handler+0x20
#12 0x80da1059 at lkpi_irq_handler+0x29
#13 0x80af0737 at ithread_loop+0x257
#14 0x80aecd1f at fork_exit+0x7f
#15 0x80fd7aae at fork_trampoline+0xe
Uptime: 1h20m44s
Dumping 1163 out of 15712 MB:..2%..12%..21%..31%..42%..51%..61%..71%..82%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
57 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 276985] crash in LinuxKPI/drm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985 --- Comment #13 from f...@fehcom.de --- Created attachment 251410 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251410=edit core.text -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Yuri Victorovich changed: What|Removed |Added Assignee|b...@freebsd.org|toolchain@FreeBSD.org Blocks|279505 | CC||d...@freebsd.org Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279505 [Bug 279505] graphics/libheif fails to build with message about csetjmp error -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Yuri Victorovich changed: What|Removed |Added Assignee|b...@freebsd.org|toolch...@freebsd.org Blocks|279505 | CC||d...@freebsd.org Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279505 [Bug 279505] graphics/libheif fails to build with message about csetjmp error -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692 Yuri Victorovich changed: What|Removed |Added Blocks||279505 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279505 [Bug 279505] graphics/libheif fails to build with message about csetjmp error -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279692] '#include ' is broken: error: "If libc++ starts defining , the __has_include check should move to libc++'s "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279692
Bug ID: 279692
Summary: '#include ' is broken: error: "If libc++
starts defining , the __has_include check
should move to libc++'s "
Product: Base System
Version: 14.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: misc
Assignee: b...@freebsd.org
Reporter: y...@freebsd.org
This simple program can't be compiled on 14.1:
#include
int main() {
}
$ c++ x.cpp
In file included from x.cpp:2:
/usr/include/c++/v1/csetjmp:40:6: error: "If libc++ starts defining ,
the __has_include check should move to libc++'s "
40 | #error "If libc++ starts defining , the __has_include
check should move to libc++'s "
| ^
1 error generated.
The error message doesn't explain what is wrong with the program.
The C++ standard says that should be included for the C++ feature
std::jmp_buf.
See here: https://en.cppreference.com/w/cpp/utility/program/jmp_buf
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 251250] bhyveload cannot find filesystem: ERROR: cannot open /boot/lua/loader.lua: no such file or directory.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251250 Thomas Hayden changed: What|Removed |Added CC||lodej65...@kernuo.com --- Comment #4 from Thomas Hayden --- Writer: ultima Date: Thursday, August 17, 2024, 21:53:31 UTC, New revision: 448198 URL: https://changeset/ports/448198 on svnweb.freebsd.org Log: lv2file is a straightforward application that makes it easy to add effects to your audio files. Among the potential use cases are: * When you wish to apply an effect without launching a project or opening a GUI. * When you wish to automatically or widely apply effects to a lot of files. * When debugging a plugin requires a deterministic environment. * You prefer to use the command line for everything. For its effects, lv2file employs the LV2 plugin format (http://lv2plug.in/). WWW: lv2file at https://github.com/jeremysalwen PR number: 221214 Contributed by: Maintainer Yuri Victorovich Matthew, the mentor, reviewed and approved the work. https://reviews.freebsd.org/D12058 https://basketrandom.io is the differential revision page. alterations: head/audio/Makefile head/audio/lv2file/ distinfo head/audio/lv2file/files/ head/audio/lv2file/files/patch-Makefile head/audio/lv2file/pkg-descr -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277783] libc fma() doesn't not return the correct zero sign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277783 --- Comment #10 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e77ad954bb825983b4346b9cc646c9c910b1be24 commit e77ad954bb825983b4346b9cc646c9c910b1be24 Author: Ed Maste AuthorDate: 2024-06-12 01:34:02 + Commit: Ed Maste CommitDate: 2024-06-12 01:36:12 + Revert "libm: fma: correct zero sign with small inputs" This change introduced a test failure, so revert until that can be addressed. This reverts commit 888796ade2842486d3167067e8034254c38aadd3. PR: 277783 Reported by:rlibby Sponsored by: The FreeBSD Foundation lib/msun/src/s_fma.c | 4 +--- lib/msun/src/s_fmal.c | 4 +--- 2 files changed, 2 insertions(+), 6 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279690] Inbuilt keyboard capslock LED does not work past bootloader on a MacBook Pro 11.4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279690 Mark Linimon changed: What|Removed |Added Summary|Inbuilt keyboard capslock |Inbuilt keyboard capslock |LED does not work past |LED does not work past |bootloader |bootloader on a MacBook Pro ||11.4 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279669] x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279669 --- Comment #5 from Ken DEGUCHI --- (In reply to Emmanuel Vadot from comment #4) I am also writing this without knowing the cause, so it may not be a lightdm problem. If it has to do with authentication, it may have to do with the accountsservice, or the consolekit2, which is a dependency. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279690] Inbuilt keyboard capslock LED does not work past bootloader
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279690 Bug ID: 279690 Summary: Inbuilt keyboard capslock LED does not work past bootloader Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: megaman...@gmail.com I am currently trying to get an inbuilt laptop keyboard to fully function using FreeBSD 13.3, on a MacBook Pro 11.4. In general everything has been successful, however I am having just one problem remaining to be fixed. When I boot into the laptop, the caps lock button works and when it is enabled, the LED turns on. This is true both during the entering of the full disk encryption, and during the bootloader dialogue. However, as soon as the booting process begins, the caps lock LED is switched off, and there is seemingly no way to turn it back on. I have tried using ioctl to set the LED on using KDSETLED, but despite the device believing that it is set, the actual LED is not on (caps lock does work, though). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274382] iwlwifi Invalid TXQ id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274382
--- Comment #76 from Vladislav Shabanov ---
(In reply to Ed Maste from comment #75)
Sorry. Maybe, my comment is not relevant to initial bug report. But I started
to resolve the wifi card issue with 'Invalid TXQ id' message and after updates
I have no this lines but have 'Queue 3 stuck'. For me, it looks like the
patches against 'Invalid TXQ id' fix one problem but trigger another one.
Maybe, I should create another bug report?
Details:
06.06.2024: FreeBSD 15.0-CURRENT #0 main-n270474-d2f1f71ec8c6 (snapshot).
..
wpa_supplicant[378]: wlan0: CTRL-EVENT-DISCONNECTED bssid=c8:be:19:ec:2d:31
reason=3 locally_generated=1
wpa_supplicant[378]: wlan0: CTRL-EVENT-DSCP-POLICY clear_all
kernel: wlan0: link state changed to DOWN
kernel: Invalid TXQ id
kernel: iwl_mvm_tx_mpdu:1204: fc 0x00a0 tid 8 txq_id 65535 mvm
0xfe01a92634c8 skb 0xf80150f26800 { len 26 } info 0xfe010a355cc0
sta 0xf80150b61880 (if you see this please report to PR 274382)
...
I updated the src, recompiled and got the following:
07.06.2024: FreeBSD 15.0-CURRENT #1 main-n270672-2b887687edc2
..
kernel: iwlwifi0: Queue 3 is stuck 156 158
kernel: iwlwifi0: need_update 0 frozen 0 ampdu 0 now 18446744071562759140
stuck_timer.expires 18446744071562759103 frozen_expiry_remainder 0 wd_timeout
1
kernel: iwlwifi0: Microcode SW error detected. Restarting 0x0.
A day later I updated again, but the problem persists:
10.06.2014: FreeBSD 15.0-CURRENT #2 main-n270710-edbd489d09ba
kernel: iwlwifi0: Queue 3 is stuck 77 78
kernel: iwlwifi0: need_update 0 frozen 0 ampdu 0 now 2147187279
stuck_timer.expires 2147187265 frozen_expiry_remainder 0 wd_timeout 1
kernel: iwlwifi0: Microcode SW error detected. Restarting 0x0.
When I booted again main-n270474-d2f1f71ec8c6 from LiveCD, I was unable to
reproduce wlan0 crash on outgoing traffic using netcat (the 'Queue 3 is stuck'
issue). But with latest commits it's very easy to do so.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #4 from mario felicioni --- Where can I make the request ? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274382] iwlwifi Invalid TXQ id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274382 --- Comment #75 from Ed Maste --- (In reply to Vladislav Shabanov from comment #74) I don't see the Invalid TXQ message in your logs - can you confirm (or explain what you mean by being the same problem)? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 274382] iwlwifi Invalid TXQ id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274382 Vladislav Shabanov changed: What|Removed |Added CC||vlad.shaba...@gmail.com --- Comment #74 from Vladislav Shabanov --- Hello. I have the same problem with very fresh 15-CURRENT (edbd489d09babebdc6c03924a912013be584c409). The system starts OK and wifi works without problem. I can download data from the web, surf in browser, etc. But when I try to upload something bug ( > 50 Mb), iwlwifi crashed. The easiest way to reproduce: cat /dev/zero | nc -v 192.168.1.xx (with nc -v -l > /dev/null on that host) The crash happened both in GENERIC and GENERIC-NODEBUG. I was unable to reproduce this bug in FreeBSD-15.0-CURRENT-amd64-20240530-d2f1f71ec8c6-270474, that snapshot seems stable. pciconf -lv: iwlwifi0@pci0:87:0:0: class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2725 subvendor=0x8086 subdevice=0x0024 vendor = 'Intel Corporation' device = 'Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak]' class = network Dmesg at system start: kernel: iwlwifi0: mem 0x6e20-0x6e203fff at device 0.0 on pci3 kernel: iwlwifi0: Detected crf-id 0x400410, cnv-id 0x400410 wfpm id 0x8000 kernel: iwlwifi0: PCI dev 2725/0024, rev=0x420, rfid=0x10d000 kernel: iwlwifi0: successfully loaded firmware image 'iwlwifi-ty-a0-gf-a0-83.ucode' kernel: iwlwifi0: api flags index 2 larger than supported by driver kernel: iwlwifi0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.41 kernel: iwl-debug-yoyo.bin: could not load binary firmware /boot/firmware/iwl-debug-yoyo.bin either syslogd: last message repeated 1 times kernel: iwl-debug-yoyo_bin: could not load binary firmware /boot/firmware/iwl-debug-yoyo_bin either kernel: iwl_debug_yoyo_bin: could not load binary firmware /boot/firmware/iwl_debug_yoyo_bin either kernel: iwlwifi0: loaded firmware version 83.e8f84e98.0 ty-a0-gf-a0-83.ucode op_mode iwlmvm kernel: iwlwifi0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, REV=0x420 kernel: iwlwifi0: WRT: Invalid buffer destination: 0 kernel: iwlwifi0: WFPM_UMAC_PD_NOTIFICATION: 0x20 kernel: iwlwifi0: WFPM_LMAC2_PD_NOTIFICATION: 0x1f kernel: iwlwifi0: WFPM_AUTH_KEY_0: 0x90 kernel: iwlwifi0: CNVI_SCU_SEQ_DATA_DW9: 0x0 kernel: iwlwifi0: successfully loaded firmware image 'iwlwifi-ty-a0-gf-a0.pnvm' kernel: iwlwifi0: loaded PNVM version 181407b3 kernel: iwlwifi0: Detected RF GF, rfid=0x10d000 kernel: iwlwifi0: base HW address: f8:b5:4d:6e:ce:c7 kernel: acpi_wmi0: on acpi0 kernel: acpi_wmi0: Embedded MOF found kernel: ACPI: \_SB.WFDE.WQCC: 1 arguments were passed to a non-method ACPI object (Buffer) (20230628/nsarguments-3> kernel: acpi_wmi1: on acpi0 kernel: acpi_wmi1: Embedded MOF found kernel: ACPI: \_SB.WFTE.WQCC: 1 arguments were passed to a non-method ACPI object (Buffer) (20230628/nsarguments-3> kernel: acpi_wmi2: on acpi0 kernel: iwlwifi0: WRT: Invalid buffer destination: 0 kernel: iwlwifi0: WFPM_UMAC_PD_NOTIFICATION: 0x20 kernel: iwlwifi0: WFPM_LMAC2_PD_NOTIFICATION: 0x1f kernel: iwlwifi0: WFPM_AUTH_KEY_0: 0x90 kernel: iwlwifi0: CNVI_SCU_SEQ_DATA_DW9: 0x0 kernel: wlan0: Ethernet address: f8:b5:4d:6e:ce:c7 kernel: lo0: link state changed to UP kernel: uhid0 on uhub1 .. The crash: kernel: iwlwifi0: Queue 3 is stuck 68 77 Jun 11 13:59:44 vsGB kernel: iwlwifi0: need_update 0 frozen 0 ampdu 0 now 214690 stuck_timer.expires 214608 frozen_expiry_rem> kernel: iwlwifi0: Microcode SW error detected. Restarting 0x0. kernel: iwlwifi0: Start IWL Error Log Dump: kernel: iwlwifi0: Transport status: 0x004A, valid: 6 kernel: iwlwifi0: Loaded firmware version: 83.e8f84e98.0 ty-a0-gf-a0-83.ucode kernel: iwlwifi0: 0x0084 | NMI_INTERRUPT_UNKNOWN kernel: iwlwifi0: 0x00808203 | trm_hw_status0 kernel: iwlwifi0: 0x | trm_hw_status1 kernel: iwlwifi0: 0x004DC410 | branchlink2 kernel: iwlwifi0: 0x8C84 | interruptlink1 kernel: iwlwifi0: 0x8C84 | interruptlink2 kernel: iwlwifi0: 0x00016AD0 | data1 kernel: iwlwifi0: 0x0100 | data2 kernel: iwlwifi0: 0x | data3 kernel: iwlwifi0: 0xF580CBCA | beacon time kernel: iwlwifi0: 0xA4E9D443 | tsf low kernel: iwlwifi0: 0x0002 | tsf hi kernel: iwlwifi0: 0x0AA7 | time gp1 kernel: iwlwifi0: 0x063BB9C1 | time gp2 kernel: iwlwifi0: 0x0001 | uCode revision type kernel: iwlwifi0: 0x0053 | uCode version major kernel: iwlwifi0: 0xE8F84E98 | uCode version minor kernel: iwlwifi0: 0x0420 | hw version kernel: iwlwifi0: 0x00C80002 | board version kernel: iwlwifi0: 0x02DD001C | hcmd kernel: iwlwifi0: 0x24023000 | isr0 kernel: iwlwifi0: 0x00048000 | isr1 kernel: iwlwifi0: 0x48F2 | isr2 kernel: iwlwifi0: 0x00C3009C | isr3 kernel: iwlwifi0: 0x0020 | isr4 kernel: iwlwifi0: 0x02DC001C | last cmd Id kernel: iwlwifi0: 0x00016AD0 | wait_event kernel: iwlwifi0: 0x00D4 | l2p_control
[Bug 279686] [asmc] [patch] Add support for MacBookPro 11.4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279686 Bug ID: 279686 Summary: [asmc] [patch] Add support for MacBookPro 11.4 Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: megaman...@gmail.com Created attachment 251403 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251403=edit asmc macbookpro11,4 support This patch adds support for asmc with the Macbookpro 11.4. SMCs were (mostly) taken from https://logi.wiki/index.php/SMC_Sensor_Codes. Three errors occur when running sysctl: asmc0: asmc_key_read for key F1Sf failed 10 times, giving up asmc0: asmc_key_read for key F0Sf failed 10 times, giving up asmc0: asmc_key_read for key F0Sf failed 10 times, giving up These correspond to: dev.asmc.0.fan.1.safespeed dev.asmc.0.fan.0.safespeed but cannot be disabled without severely altering the driver, so I've left them as-is. Keyboard backlight is working nicely, and fan and temp reporting is also working. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #3 from Oleksandr Kryvulia --- I understand you. But I think It is not a bug, it is a feature request. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 228251] Touchpad non-functional on Dell Latitude 5580
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228251 --- Comment #10 from Trenton Schulz --- (In reply to Ed Maste from comment #9) I think this can safely be closed. I believe I was using the builtin trackpad with no changes by 12.2-RELEASE. Unfortunately, that laptop has been repurposed to non-FreeBSD things, so I can't check it anymore, but I believe it was working through at least 13.2-RELEASE and I don't think much has changed that would break it. I'm happy to have this closed if possible. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 15470] Proposed change to comments in /etc/namedb/named.conf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15470 --- Comment #3 from Mark Linimon --- (In reply to commit-hook from comment #2) ^Triage: note that this commit was misfiled against PR https://bugs.freebsd.org/273207 . -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279622] Change Default bsdinstall(8) Partition Sizes for Auto (ZFS) Option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279622 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|sysinst...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279542] mandoc emits error after exiting pager
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279542 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2235 ||16 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279684] ctld truncates LUN size to 4GiB on 32-bit platforms
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279684 Bug ID: 279684 Summary: ctld truncates LUN size to 4GiB on 32-bit platforms Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: asom...@freebsd.org The ctld.conf file allows specifying the size of a LUN. It's required for ramdisk-backed LUNs, and optional for block-backed LUNs. In traditional mode it's parsed as a uin64_t. In UCL mode, it's parsed as an int64_t. That's a little bit inconsistent, but not bad. The bad part is that it then gets truncated by being passed to lun_set_size, which takes its argument as a usize. That's a bug on 32-bit platforms. The solution is to always handle the size as a uint64_t, which is ultimately what the kernel expects. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279661] ctld ignores several settings in UCL mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279661 Alan Somers changed: What|Removed |Added Summary|ctld ignores offload in UCL |ctld ignores several |mode|settings in UCL mode --- Comment #2 from Alan Somers --- And from the lun context, uclparse.y ignores "ctl-lun" and "device-type"/ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279683] ctld: inconsistent parsing "option" in traditional vs UCL mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279683 Bug ID: 279683 Summary: ctld: inconsistent parsing "option" in traditional vs UCL mode Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: asom...@freebsd.org ctld.conf(5) says that both the portal-group context and the lun context may have an "option" section (note: it's singular). The YACC code for parsing the traditional config file also expects "option" (singular again). But the UCL parsing code expects "options" (plural). Curiously, the man page _does_ use "options" in the example UCL file, though it doesn't mention that spelling in the text. I think it best if both traditional and UCL mode use the same spelling. And since I'm guessing that traditional users still outnumber UCL users, we should standardize on "option". -- You are receiving this mail because: You are the assignee for the bug.
[Bug 228251] Touchpad non-functional on Dell Latitude 5580
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228251 --- Comment #9 from Ed Maste --- Four or five years later, Shawn or Trenton can you comment on the current state here? As Trenton mentioned in Comment #8 there was a lot of work in progress at the time of this report. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279650] Linux module crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279650 david.boy...@twc.com changed: What|Removed |Added CC||david.boy...@twc.com --- Comment #1 from david.boy...@twc.com --- I have experienced the same error on 15.0-CURRENT VM-Image using the vmdk with VirtualBox. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 --- Comment #4 from Anton Saietskii --- (In reply to Andre Albsmeier from comment #3) Looks pretty similar to mine, except your steps are less. It may be related due to my systems boots in UEFI, which in turn means it's already in high-resolution graphic mode before even loader starts. This may explain why I see some DRM messages -- time for switching is saved. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 --- Comment #3 from Andre Albsmeier --- (In reply to Anton Saietskii from comment #1) > How does crash look like? 1. System boots. 2. When it loads i915kms.ko, screen goes black 3. goto 1. I can't see any messages but that doesn't mean that there are none. Maybe the LCD needs some time to switch resolution and the crash/reboot ist faster. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279662] net/bird2@netlink - broken multiple FIB support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279662 Olivier Cochard changed: What|Removed |Added Assignee|b...@freebsd.org|oliv...@freebsd.org CC||oliv...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279669] x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279669
Emmanuel Vadot changed:
What|Removed |Added
CC||m...@freebsd.org
--- Comment #4 from Emmanuel Vadot ---
(In reply to Ken DEGUCHI from comment #3)
It's not only for Wayland and I don't see how it can causes problem for
lightdm.
You say it "references /var/run/user/${uid}", where exactly ?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 --- Comment #2 from Anton Saietskii --- Commented VT_MAXWINDOWS, recompiled kernel -- boots fine now. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 Anton Saietskii changed: What|Removed |Added CC||vsasja...@gmail.com --- Comment #1 from Anton Saietskii --- (In reply to Andre Albsmeier from comment #0) How does crash look like? For me, it's like this (on 14.1-RELEASE amd64): 1. Screen goes black. 2. Screen turns on, displays some DRM-related messages. 3. Screen goes black again. 4. System reboots. Note: there's no panic visible and I have PANIC_REBOOT_WAIT_TIME=-1. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279669] x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279669
--- Comment #3 from Ken DEGUCHI ---
(In reply to Marko Cupać from comment #2)
I am no expert either, but it seems that pam_xdg was introduced for Wayland.
pam_xdg seems to create a directory /var/run/xdg/${USER}. However, lightdm
references /var/run/user/${uid}, so gnome-keyring authentication does not seem
to work.
As you mentioned, it would be better to write in lightdm's pkg-message that
pam_xdg should be disabled.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279669] x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279669 --- Comment #2 from Marko Cupać --- (In reply to Ken DEGUCHI from comment #1) Thanks, it works now. What would be the best way to inform users? Perhaps pkg-message? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270707] Installer media doesn't boot on Thinkpad T14s Gen 3 (Ryzen 7 Pro 6850U)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270707 --- Comment #43 from Matthias Lanter --- I can confirm that the fix works in FreeBSD 14.0-STABLE (GhostBSD). i.e. the same behavior as with the commented out lines. It is still necessary to unset hint.uart.1.at boot and or comment out it in /boot/device.hints, so that the start process does not hang. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279653] Page fault in in6_selecthlim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #2 from Andrey V. Elsukov --- (In reply to Zhenlei Huang from comment #1) fault virtual address = 0x10 corresponds to offset of nd_ifinfo field in struct in6_ifextra that is returned by if_getafdata(). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279669] x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279669 Ken DEGUCHI changed: What|Removed |Added CC||kdegu...@sz.tokoha-u.ac.jp --- Comment #1 from Ken DEGUCHI --- (In reply to Marko Cupać from comment #0) In /etc/pam.d/system, session requiredpam_xdg.so Commenting this line should solve the problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 --- Comment #2 from mario felicioni --- That's not good. For many reasons : 1) I can see the usb stick in Windows,so it works,at least in Windows,it is recognized and I can copy and paste files from/to the usb stick 2) I don't have and you can't ask me to BUY a dedicated USB controller to be able to allow Rufus to detect the usb stick when Windows detects it 3) I can't pass the whole PCIe device / USB controller that in my case is : (00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller) because I have several peripherals connected there that I can't disconnect from the host os 4) My mobo has only two PCIe lines,I have no space on the mobo to add another USB Controller. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268043] devel/py-twisted: Consumer ports fail to run: module 'OpenSSL.SSL' has no attribute 'TLS_METHOD' after 22.10.0 update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268043 Marko Cupać changed: What|Removed |Added CC||marko.cu...@mimar.rs --- Comment #11 from Marko Cupać --- Is hardcoding TLS to 1.2 still necessary? It prevents py-matrix-synapse on FreeBSD to communicate with other homeservers over TLSv1.3. There's feedback in synapse's github that removal of post-patch results in functional synapse, at least on 14.1-RELEASE: https://github.com/element-hq/synapse/issues/17046#issuecomment-2160036426 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 279669] x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279669 Bug ID: 279669 Summary: x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: desk...@freebsd.org Reporter: marko.cu...@mimar.rs Assignee: desk...@freebsd.org Flags: maintainer-feedback?(desk...@freebsd.org) Hi, since upgrading to 14.1-RELEASE, ligtdm does not unlock gnome-keyring on login. This used to work on 14.0-RELEASE, by means of adding lines to /usr/local/etc/pam.d/lightdm: authoptionalpam_gnome_keyring.so session optionalpam_gnome_keyring.soauto_start I tried with absolute paths as well (/usr/local/lib/pam_gnome_keyring.so), but the result is the same. gnome-keyring brings up pop-up window after login to xfce, I need to type in password to unlock it. Thank you in advance, -- You are receiving this mail because: You are the assignee for the bug.
maintainer-feedback requested: [Bug 279669] x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE
Bugzilla Automation has asked freebsd-desktop (Team) for maintainer-feedback: Bug 279669: x11/lightdm does not unlock gnome-keyring since upgrade to 14.1-RELEASE https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279669 --- Description --- Hi, since upgrading to 14.1-RELEASE, ligtdm does not unlock gnome-keyring on login. This used to work on 14.0-RELEASE, by means of adding lines to /usr/local/etc/pam.d/lightdm: authoptionalpam_gnome_keyring.so session optionalpam_gnome_keyring.soauto_start I tried with absolute paths as well (/usr/local/lib/pam_gnome_keyring.so), but the result is the same. gnome-keyring brings up pop-up window after login to xfce, I need to type in password to unlock it. Thank you in advance,
[Bug 277060] pax(1) hangs when copying directories with a trailing slash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277060 Ganael LAPLANCHE changed: What|Removed |Added Version|14.0-RELEASE|CURRENT -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279576] WITHOUT_CLANG build option fails, possibly a race condition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279576 Michael Dexter changed: What|Removed |Added Status|New |Closed Resolution|--- |Unable to Reproduce --- Comment #3 from Michael Dexter --- This might have been attributed to building 15-CURRENT on 14.0R and appears to be working with combinations of 15 on 15, and 15 on 14.1R. I will close this for now and keep testing. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 Oleksandr Kryvulia changed: What|Removed |Added CC||shur...@shurik.kiev.ua --- Comment #1 from Oleksandr Kryvulia --- You pass your pendrive as block device to the guest, not usb device. Since FreeBSD does not support usb device passthrough try to pass a usb controller as pci-device. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279662] net/bird2@netlink - broken multiple FIB support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279662
Bug ID: 279662
Summary: net/bird2@netlink - broken multiple FIB support
Product: Base System
Version: 14.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: zarych...@plan-b.pwste.edu.pl
While trying to reproduce the issue found on the BIRD-users mailing list[1], I
refreshed my old BIRD testing setup and can confirm that net/bird2@netlink
cannot cope with FIBs other than 0.
Minimal steps to reproduce:
1. Increase sysctl net.fibs to at least 5
2. Deploy net/bird2@netlink with "protocol kernel" using not default FIB, for
example:
protocol kernel {
kernel table 4;
(...)
}
I can provide a more advanced config to reproduce, if someone is willing to do
so, please email me.
1. https://bird.network.cz/pipermail/bird-users/2024-June/017722.html
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 277093] pf: Assertion failed: (elems <= maxelems), function pf_nvuint_32_array on stable/14 with RACK
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277093 sp...@bway.net changed: What|Removed |Added CC||sp...@bway.net --- Comment #3 from sp...@bway.net --- Just reporting I see the same in a 13.2 VNET jail running on a 13.3-p1 host: [root@haproxy01 /home/spork]# pfctl -sr Assertion failed: (elems <= maxelems), function pf_nvuint_32_array, file /usr/src/lib/libpfctl/libpfctl.c, line 147. Abort trap (core dumped) [root@haproxy01 /home/spork]# I can provide more info if needed but it certainly looks like the same issue. I don't see any note of this in the -p2 update... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279653] Page fault in in6_selecthlim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653
Zhenlei Huang changed:
What|Removed |Added
CC||z...@freebsd.org
--- Comment #1 from Zhenlei Huang ---
(In reply to Daniel Ponte from comment #0)
The stack trace is weird. The caller `sys/netinet/tcp_output.c`
```
1444 ip6->ip6_hlim = in6_selecthlim(inp, NULL);
```
The callee, `sys/netinet6/in6_src.c`:
```
843 int
844 in6_selecthlim(struct inpcb *inp, struct ifnet *ifp)
845 {
846
847 if (inp && inp->in6p_hops >= 0)
848 return (inp->in6p_hops);
849 else if (ifp)
850 return (ND_IFINFO(ifp)->chlim);
851 else if (inp && !IN6_IS_ADDR_UNSPECIFIED(>in6p_faddr)) {
..
}
```
The line 850 of should never hit as `ifp` is NULL, the backtrace also shows
that clearly.
That is quite odd ... Is it possible that kgdb report the wrong line number ?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279661] ctld ignores offload in UCL mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279661 --- Comment #1 from Alan Somers --- Also, uclparse.y ignores "foreign" and "tag". -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279661] ctld ignores offload in UCL mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279661 Bug ID: 279661 Summary: ctld ignores offload in UCL mode Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: asom...@freebsd.org ctl.conf's "portal-group" section is supposed to include an "offload" key. >From inspection, I see that this key is handled in the old config format, but not in the UCL format. uclparse.c ignores it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 271475] security/nss: investigate dropping binutils
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271475
--- Comment #4 from Jan Beich ---
(In reply to Marcin Cieślak from comment #3)
${CC} is your assembler when using Clang (-integrated-as is enabled by
default). Unlike GCC it doesn't call an external program and can compile *.s
(GNU assembly syntax) directly.
Symlinking "as" to clang unlikely to work due to incompatible CLI options.
Invoking Clang assembler directly is possible but discouraged.
$ cc -cc1as -help
OVERVIEW: Clang Integrated Assembler
USAGE: clang -cc1as [options] file...
OPTIONS:
-as-secure-log-file
Emit .secure_log_unique directives to this filename.
-compress-debug-sections=
DWARF debug sections compression type
-darwin-target-variant-sdk-version=
The version of darwin target variant SDK used for
compilation
-darwin-target-variant-triple
Specify the darwin target variant triple
-debug-info-macro Emit macro debug information
-default-function-attr
Apply given attribute to all functions
-defsym Define a value for a symbol
-dwarf-debug-flags
The string to embed in the Dwarf debug flags record.
-dwarf-debug-producer
The string to embed in the Dwarf debug AT_producer
record.
-fbasic-block-sections=
Place each function's basic blocks in unique sections
(ELF Only)
-fcoverage-compilation-dir=
The compilation directory to embed in the coverage
mapping.
-fdebug-compilation-dir=
The compilation directory to embed in the debug info
-fdebug-prefix-map==
For paths in debug info, remap directory to
. If multiple options match a path, the last option wins
-fembed-bitcode=
Embed LLVM bitcode
-femit-compact-unwind-non-canonical
Try emitting Compact-Unwind for non-canonical
entries. Maybe overriden by other constraints
-femit-dwarf-unwind=
When to emit DWARF unwind (EH frame) info
-filetypeSpecify the output file type ('asm', 'null', or
'obj')
-fno-math-builtin Disable implicit builtin knowledge of math functions
-fno-use-ctor-homingDon't use constructor homing for debug info
-fswift-async-fp=
Control emission of Swift async extended frame info
-fuse-ctor-homing Use constructor homing if we are using limited debug
info already
-gcodeview Generate CodeView debug information
-gdwarf32 Enables DWARF32 format for ELF binaries, if debug
information emission is enabled.
-gdwarf64 Enables DWARF64 format for ELF binaries, if debug
information emission is enabled.
-help Display available options
-I Add directory to the end of the list of include
search paths
-main-file-name Main file name to use for debug info and source if
missing
-massembler-fatal-warnings
Make assembler warnings fatal
-massembler-no-warn Make assembler not emit warnings
-mincremental-linker-compatible
(integrated-as) Emit an object file which can be used
with an incremental linker
-mllvm Additional arguments to forward to LLVM's option
processing
-mno-type-check Don't perform type checking of the assembly code
(wasm only)
-mnoexecstack Mark the file as not needing an executable stack
-mrelax-all (integrated-as) Relax all machine instructions
-mrelax-relocations=no Disable x86 relax relocations
-mrelocation-model
The relocation model to use
-msave-temp-labels Save temporary labels in the symbol table. Note this
may change .s semantics and shouldn't generally be used on compiler-generated
code.
-n Don't automatically start assembly file with a text
section
-object-file-name=
Set the output for debug infos
-output-asm-variant
Select the asm variant index to use for output
-oWrite output to
-record-command-line
The string to embed in the .LLVM.command.line
section.
-show-encoding Show instruction encoding information in
transliterate mode
-show-inst Show internal instruction representation in
transliterate mode
-split-dwarf-output
File name to use for split dwarf debug info output
-target-abi Target a particular ABI type
-target-cpu Target a specific cpu type
-target-feature Target specific attributes
-target-sdk-version=
The version of target SDK used for compilation
-triple Specify target triple (e.g. i686-apple-darwin9)
-tune-cpuTune for a
[Bug 279566] procctl not working as expected.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279566 WZIS Software changed: What|Removed |Added Version|Unspecified |13.2-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279653] Page fault in in6_selecthlim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279653] Page fault in in6_selecthlim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279659] virtualization/bhyve: When bhyve virtualizes Windows 10/11 Rufus does not recognizes any USB sticks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279659 Mark Linimon changed: What|Removed |Added Assignee|ports-b...@freebsd.org |virtualization@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279650] Linux module crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279650 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|emulat...@freebsd.org Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279650] Linux module crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279650 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|emulat...@freebsd.org Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277826] [exp-run]science/py-scipy: Update to 1.12.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277826 --- Comment #13 from Wen Heping --- result of regression test: == short test summary info === FAILED optimize/tests/test_optimize.py::TestOptimizeWrapperDisp::test_ncg - AssertionError: 18 FAILED optimize/tests/test_optimize.py::TestOptimizeWrapperNoDisp::test_ncg - AssertionError: 18 FAILED optimize/tests/test_optimize.py::TestOptimizeNoWrapperDisp::test_ncg - AssertionError: 18 FAILED optimize/tests/test_optimize.py::TestOptimizeNoWrapperNoDisp::test_ncg - AssertionError: 18 FAILED optimize/tests/test_zeros.py::TestNewton::test_halley_collections - AssertionError: FAILED signal/tests/test_signaltools.py::TestCorrelateReal::test_method[uint8] - AssertionError: FAILED signal/tests/test_signaltools.py::TestCorrelateReal::test_method[int8] - AssertionError: FAILED sparse/tests/test_base.py::TestCOO::test_multiple_ellipsis_slicing - Failed: DID NOT WARN. No warnings of type (, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
[Bug 270707] Installer media doesn't boot on Thinkpad T14s Gen 3 (Ryzen 7 Pro 6850U)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270707 --- Comment #42 from John Baldwin --- Thanks, I am still waiting for confirmation if this patch fixes the problem, but I have posted the patch in a review in the meantime: https://reviews.freebsd.org/D45554 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 260088] boot(8) FILES section missing many files in 13.*R/14.0R/14.1R/15-CURRENT and SEE ALSO pages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260088 Alexander Ziaee changed: What|Removed |Added CC||concussious.bugzilla@runbox ||.com --- Comment #2 from Alexander Ziaee --- Boot(8) and uefi(8) are known to need TLC, like tuning(7). They have been in my manpage drafts since August, but rewriting them is quite serious. It has to be hollistic. I'm still studying in order to rewrite these pages correctly. In the meantime, I would love to consider any specific suggestions and share credit in the commit msg. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279128] devel/kdesvn: Try to prevent overlinking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279128 Daniel Engberg changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #6 from Daniel Engberg --- Committed, thanks -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279594] converters/fribidi: Update to 1.0.15
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279594 Daniel Engberg changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #3 from Daniel Engberg --- Committed, thanks -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279128] devel/kdesvn: Try to prevent overlinking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279128 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=ba54accf2651fcc45ff208e347e7d3190ecdb08b commit ba54accf2651fcc45ff208e347e7d3190ecdb08b Author: Daniel Engberg AuthorDate: 2024-06-10 21:06:09 + Commit: Daniel Engberg CommitDate: 2024-06-10 21:26:01 + devel/kdesvn: Try to prevent overlinking Add -Wl,--as-needed to LDFLAGS to prevent overlinking and remove incorrect dependency of BDB5 PR: 279128 Approved by:kde (tcberner) devel/kdesvn/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279128] devel/kdesvn: Try to prevent overlinking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279128 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1e506684c4f5252aece31fc9d77f825f0443cd4b commit 1e506684c4f5252aece31fc9d77f825f0443cd4b Author: Daniel Engberg AuthorDate: 2024-06-10 21:22:50 + Commit: Daniel Engberg CommitDate: 2024-06-10 21:26:26 + devel/kdesvn: Deprecate and set expiration date to 2024-12-31 Due to dwindling amount of users, interest and to streamline amount of ports for the KDE Team to maintain PR: 279128 Approved by:kde (tcberner) devel/kdesvn/Makefile | 3 +++ 1 file changed, 3 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279594] converters/fribidi: Update to 1.0.15
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279594 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f928f6b4044877dbc4e4db622b2284ffec2bdd58 commit f928f6b4044877dbc4e4db622b2284ffec2bdd58 Author: Daniel Engberg AuthorDate: 2024-06-10 20:58:34 + Commit: Daniel Engberg CommitDate: 2024-06-10 21:24:33 + converters/fribidi: Update to 1.0.15 Backport upstream commit 3826589ea556da613bd42742a169789469e8b635 Changelog: https://github.com/fribidi/fribidi/releases/tag/v1.0.15 Reference: https://github.com/fribidi/fribidi/commit/3826589ea556da613bd42742a169789469e8b635 PR: 279594 Approved by:desktop (arrowd) Sponsored by: Blinkinblox converters/fribidi/Makefile | 5 - converters/fribidi/distinfo | 8 +--- 2 files changed, 9 insertions(+), 4 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 274382] iwlwifi Invalid TXQ id
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274382 --- Comment #73 from Ed Maste --- (In reply to justinlbouchard from comment #72) This issue may be fixed as of Bjoern's commit referenced in comment #71 (it is for me). It should be merged into stable/14 before long, and after that will be available in stable/14 snapshot builds. If you're able to try one of those snapshots that would be much appreciated, otherwise check again on FreeBSD 14.2 when it is out. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 279542] mandoc emits error after exiting pager
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279542 Ed Maste changed: What|Removed |Added Status|New |In Progress -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279653] Page fault in in6_selecthlim
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653 Bug ID: 279653 Summary: Page fault in in6_selecthlim Product: Base System Version: 14.0-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ami...@gmail.com 14-STABLE eff27c3872300e594e0b410364a02302fc555121 built 4 June. This machine is a gateway and does indeed use ipv6. It runs dns/blocky (a filtering resolver, like pi-hole written in go) in a jail that lives on ZFS. The rest of the system is on UFS. I had just rolled back the jail to an old snapshot when this happened, but I'm not positive that is related, even though it appears to have crashed after I hit enter on the zfs rollback command. It looks like it crashed when blocky went to close a TCP connection (the upstream resolver is DNS-over-https using ipv6). Message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 06 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80b10416 stack pointer = 0x28:0xfe00b4245980 frame pointer = 0x28:0xfe00b42459b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 6 (blocky) rdi: f8004c742000 rsi: 001c rdx: f801dba0a278 rcx: f8004c742000 r8: ffbd r9: 0018 rax: rbx: rbp: fe00b42459b0 r10: f8004ca20e20 r11: f8005ec6b880 r12: f8003fb4e898 r13: r14: fe00b424598c r15: 00010480 trap number = 12 panic: page fault cpuid = 3 time = 1718033759 KDB: stack backtrace: #0 0x808b899d at kdb_backtrace+0x5d #1 0x8086b701 at vpanic+0x131 #2 0x8086b5c3 at panic+0x43 #3 0x80d6325b at trap_fatal+0x40b #4 0x80d632a6 at trap_pfault+0x46 #5 0x80d3b718 at calltrap+0x8 #6 0x80adda9a at tcp_default_output+0x1cda #7 0x80aef193 at tcp_usr_disconnect+0x83 #8 0x8090ff05 at soclose+0x75 #9 0x8080a5c1 at _fdrop+0x11 #10 0x8080d82a at closef+0x24a #11 0x8080cee6 at fdescfree+0x4e6 #12 0x8081fa2e at exit1+0x49e #13 0x8081f58d at sys_exit+0xd #14 0x80d63b15 at amd64_syscall+0x115 #15 0x80d3c02b at fast_syscall_common+0xf8 kgdb backtrace: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdownc:405 #2 0x8086b297 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:523 #3 0x8086b76e in vpanic (fmt=0x80e79c24 "%s", ap=ap@entry=0xfe00b42457e0) at /usr/src/sys/kern/kern_shutdown.c:967 #4 0x8086b5c3 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:891 #5 0x80d6325b in trap_fatal (frame=0xfe00b42458c0, eva=16) at /usr/src/sys/amd64/amd64/trap.c:952 #6 0x80d632a6 in trap_pfault (frame=, usermode=false, signo=, ucode=) at /usr/src/sys/amd64/amd64/trap.c:760 #7 #8 0x80b10416 in in6_selecthlim (inp=inp@entry=0xf8005ea2b540, ifp=ifp@entry=0x0) at /usr/src/sys/netinet6/in6_src.c:850 #9 0x80adda9a in tcp_default_output (tp=0xf8005ea2b540) at /usr/src/sys/netinet/tcp_output.c:1444 #10 0x80aef193 in tcp_usr_disconnect (so=) at /usr/src/sys/netinet/tcp_usrreq.c:705 #11 0x8090ff05 in sodisconnect (so=0xf80136b683c0) at /usr/src/sys/kern/uipc_socket.c:1436 #12 soclose (so=0xf80136b683c0) at /usr/src/sys/kern/uipc_socket.c:1271 #13 0x8080a5c1 in fo_close (fp=0xf8004c742000, fp@entry=0xf8019bc50730, td=0x1c, td@entry=0xf8019bc50730) at /usr/src/sys/sys/file.h:392 #14 _fdrop (fp=0xf8004c742000, fp@entry=0xf8019bc50730, td=0x1c, td@entry=0xf801db4cb000) at /usr/src/sys/kern/kern_descrip.c:3670 #15 0x8080d82a in closef (fp=fp@entry=0xf8019bc50730, td=td@entry=0xf801db4cb000) at /usr/src/sys/kern/kern_descrip.c:2843 #16 0x8080cee6 in fdescfree_fds (td=0xf801db4cb000, fdp=0xfe00b1260860) at /usr/src/sys/kern/kern_descrip.c:2566 #17 fdescfree (td=td@entry=0xf801db4cb000) at /usr/src/sys/kern/kern_descrip.c:2609 #18 0x8081fa2e in exit1 (td=0xf801db4cb000, rval=, signo=signo@entry=0) at /usr/src/sys/kern/kern_exit.c:404 #19 0x8081f58d in sys_exit (td=0xf8004c742000, uap=) at /usr/src/sys/kern/kern_exit.c:210 #20 0x80d63b15 in syscallenter (td=0xf801db4cb000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:191 #21 amd64_syscall (td=0xf801db4cb000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1194 #22 #23 0x0047398b in ??
[Bug 279200] sysrc(8) fails to perform set operations for += and -= in -c (check only) mode.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279200 --- Comment #1 from cr...@rlwinm.de --- If I understand the code correctly the problem is that the case $mode in APPEND), REMOVE), *) is never reached if $CHECK_ONLY is set since sysrc:791 will continue the loop early. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279652] [patch] wsp.c: Improve multi-finger touchpad usage and allow more configurations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279652 --- Comment #3 from megaman...@gmail.com --- Also note that the max_double_tap_distance tunable is also the maximum distance for two-finger vertical scroll. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279652] [patch] wsp.c: Improve multi-finger touchpad usage and allow more configurations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279652 --- Comment #2 from megaman...@gmail.com --- Created attachment 251364 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251364=edit Use already-calculated distance for maximum distance comparison. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279652] [patch] wsp.c: Improve multi-finger touchpad usage and allow more configurations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279652
--- Comment #1 from megaman...@gmail.com ---
Attached ("code-clean.patch") is a small syntax improvement which I missed.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 279652] [patch] wsp.c: Improve multi-finger touchpad usage and allow more configurations
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279652 Bug ID: 279652 Summary: [patch] wsp.c: Improve multi-finger touchpad usage and allow more configurations Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: usb Assignee: usb@FreeBSD.org Reporter: megaman...@gmail.com Created attachment 251363 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251363=edit Allow multi-finger scrolling following a single-click, and add max_finger_area and max_double_tap_distance tunables. The wsp driver does not currently correctly allow the movement of the trackpad using two fingers while a single button is held down: that is to say, during a single-button click, it is only possible to move the cursor using the same finger that is clicking. This patch provides support for the movement using a second finger, which is in-line with how MacOS supports this trackpad: a single button click can be moved using either the original finger or a secondary finger on the trackpad following the first click. It appears that this was originally missed by the developer, as the comments suggest that the variables holding the position arrays should be arrays, however they were not: int16_t pre_pos_x; /* previous position array */ int16_t pre_pos_y; /* previous position array */ This patch makes them arrays of int16_t, in-line with the "finger index data" and "position array" arrays. In addition, this patch also creates two tunables: hw.usb.wsp.max_finger_area hw.usb.wsp.max_double_tap_distance max_finger_area is the maximum area that a finger may take up on the trackpad to be registered as a finger. Previously, it was hardcoded 1200. This value was too low to register a thumb-click, which MacOS does correctly. max_double_tap_distance is the maximum distance between two fingers which permit a two-finger-click to be registered as a double-click. Previously, this was hardcoded as 2500, and that is left as the default. Note: this patch follows https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279649. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279650] Linux module crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279650 Bug ID: 279650 Summary: Linux module crash Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: rbra...@suse.com To reproduce: https://download.freebsd.org/snapshots/VM-IMAGES/15.0-CURRENT/amd64/20240606/FreeBSD-15.0-CURRENT-amd64-zfs-20240606-9c5d7e4a0c02-270625.qcow2.xz echo linux_enable=YES >> /etc/rc.conf service linux start --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x830808bf fault code = supervisor write data, protection violation instruction pointer = 0x20:0x83077701 stack pointer = 0x28:0xfe0104bcba00 frame pointer = 0x28:0xfe0104bcba40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 116 (kldload) rdi: 830808b8 rsi: 00c0 rdx: 0100 rcx: 83081950 r8: 83081978 r9: rax: 01d0 rbx: f8001354c480 rbp: fe0104bcba40 r10: 0001 r11: 0001 r12: 83080b90 r13: f800135711e0 r14: f800032df480 r15: 830886d0 trap number = 12 panic: page fault cpuid = 0 time = 1718042175 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0104bcb6d0 vpanic() at vpanic+0x13f/frame 0xfe0104bcb800 panic() at panic+0x43/frame 0xfe0104bcb860 trap_fatal() at trap_fatal+0x40b/frame 0xfe0104bcb8c0 trap_pfault() at trap_pfault+0xa0/frame 0xfe0104bcb930 calltrap() at calltrap+0x8/frame 0xfe0104bcb930 --- trap 0xc, rip = 0x83077701, rsp = 0xfe0104bcba00, rbp = 0xfe0104bcba40 --- elf64_linux_vdso_fixup() at elf64_linux_vdso_fixup+0xf1/frame 0xfe0104bcba40 linux_vdso_install() at linux_vdso_install+0x5f/frame 0xfe0104bcba80 linker_load_module() at linker_load_module+0xc23/frame 0xfe0104bcbd80 kern_kldload() at kern_kldload+0x16e/frame 0xfe0104bcbdd0 sys_kldload() at sys_kldload+0x5c/frame 0xfe0104bcbe00 amd64_syscall() at amd64_syscall+0x158/frame 0xfe0104bcbf30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0104bcbf30 --- syscall (304, FreeBSD ELF64, kldload), rip = 0x17c6d1d37da, rsp = 0x17c6bca0038, rbp = 0x17c6bca05b0 --- KDB: enter: panic -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279649] [patch] wsp.c: Allow the trackpad to be used after a partially unreleased click.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279649 Bug ID: 279649 Summary: [patch] wsp.c: Allow the trackpad to be used after a partially unreleased click. Product: Base System Version: 13.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: usb Assignee: usb@FreeBSD.org Reporter: megaman...@gmail.com Created attachment 251361 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=251361=edit Allow movement of trackpad following a click Currently, the wsp driver limits the ability for a single-click (left click) on the touchpad followed by a partial release (finger still on the trackpad). When you single-click then partially release, the trackpad is frozen and you cannot continue movement until you fully release the button and re-touch the trackpad for movement. This patch provides the ability to continue movement after a single-click has taken place. The tunable hw.usb.wsp.enable_single_tap_movement (1=enabled by default) has already been created for those that do not want to allow the movement of the trackpad after a single click. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279128] devel/kdesvn: Try to prevent overlinking
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279128 Tobias C. Berner changed: What|Removed |Added CC||tcber...@freebsd.org --- Comment #3 from Tobias C. Berner --- Moin moin I think committing this with a follow-up commit including a deprecation for 2024-12-31 seems reasonable. mfg Tobias -- 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 #9 from Cameron --- Tried running monerod for the first time in a while... And my system no longer crashes! This could be resolved by one or more of the following changes: 1. Upgraded to 14.1-RELEASE. I tried 14-STABLE maybe within a few months of 14.1-RELEASE and still had the problem. 2. Started using "zpool trim"... But I have another FreeBSD that had 14.0-RELEASE where I didn't run trim and had no problems. 3. I'm on a beta BIOS for this motherboard that's more recent than current latest official release. I notice after monerod has run for a while, I start getting tons of these messages in dmesg: Jun 5 02:19:11 hostname kernel: sonewconn: pcb 0xf802963b9540 (0.0.0.0:18080 (proto 6)): Listen queue overflow: 193 already in queue awaiting acceptance (1 occurrences), euid 781, rgid 781, jail 0 Jun 5 02:25:11 hostname kernel: sonewconn: pcb 0xf802963b9540 Increasing kern.ipc.soacceptqueue doesn't seem to help at all. I wonder if IO is so slow that monerod can't keep up with the connections? The first few times I ran "zpool trim", it only took a few minutes... But over time, it has progressively gotten worse, now taking 21+ minutes. Suggesting there's still some IO issue. Perhaps the same issue I've had in the past when running monerod, but now it no longer causes my box to completely lockup. I can now run monerod constantly without locking up my box though, which is a nice improvement! In /var/log/monerod.log, I see a lot of traces: 2024-06-10 15:46:31.253 [P2P6] INFOstacktrace src/common/stack_trace.cpp:134 Exception: boost::wrapexcept 2024-06-10 15:46:31.253 [P2P6] INFOstacktrace src/common/stack_trace.cpp:135 Unwound call stack: 2024-06-10 15:46:31.385 [P2P6] INFOstacktrace src/common/stack_trace.cpp:163 1 0x9ab808 __cxa_throw + 0xc8 2024-06-10 15:46:31.510 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 2 0x50b05f 2024-06-10 15:46:31.633 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 3 0x7e1f4a 2024-06-10 15:46:31.757 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 4 0x7dc205 2024-06-10 15:46:31.879 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 5 0x788439 2024-06-10 15:46:32.001 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 6 0x78886c 2024-06-10 15:46:32.122 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 7 0x7c05e2 2024-06-10 15:46:32.244 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 8 0x7b2e5b 2024-06-10 15:46:32.365 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 9 0x7bc49d 2024-06-10 15:46:32.486 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 a 0x4d9b88 2024-06-10 15:46:32.607 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 b 0x491100 2024-06-10 15:46:32.728 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 c 0x48eddd 2024-06-10 15:46:32.849 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 d 0x48c562 2024-06-10 15:46:32.970 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 e 0x7e39a5 2024-06-10 15:46:33.091 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 f 0x7fd24f 2024-06-10 15:46:33.212 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 10 0x7fd118 2024-06-10 15:46:33.333 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 11 0x4fb1b2 2024-06-10 15:46:33.453 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 12 0x4f03c4 2024-06-10 15:46:33.575 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 13 0x4efe94 2024-06-10 15:46:33.695 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 14 0x4efbcc 2024-06-10 15:46:33.816 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 15 0x7deaa2 2024-06-10 15:46:33.937 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 16 0x82bec79bd 2024-06-10 15:46:34.058 [P2P6] INFOstacktrace src/common/stack_trace.cpp:159 17 0x8324bcb05 I see similar traces on my other box where monerod has never given me problems, but the traces become more far more common on the box that does give me problems once the sonewconn errors start appearing. The sonewconn errors have never appeared on the other working box. It seems monerod is mostly or entirely unable to continue syncing the block chain with constant stacktraces once it gets to this point unless I
[Bug 279576] WITHOUT_CLANG build option fails, possibly a race condition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279576 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #2 from Ed Maste --- Is there an error message earlier in the log? -- You are receiving this mail because: You are the assignee for the bug.
