[Bug 281177] 13.2 works, 13.3 and 14.x installers panic on older qlogic isp card
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281177 --- Comment #13 from Vladimir Druzenko --- (In reply to Kenneth D. Merry from comment #12) I'll try to test boot from 14.2-BETA1 tomorrow. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281177] 13.2 works, 13.3 and 14.x installers panic on older qlogic isp card
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281177 --- Comment #12 from Kenneth D. Merry --- (In reply to Mark Johnston from comment #11) The fixes I made (that are in 14.2) shouldn't change the default behavior with any cards. You have to set a loader tunable to do that. Joerg's original changes also didn't change the driver behavior in that it still loads firmware from ispfw (if present) by default on 8Gb and older cards. Joerg did update the 8Gb 25XX firmware, but that firmware change happened before 14.1. I think to diagnose Vladimir's problem we'll need dmesg output, stack trace, etc. to narrow it down. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282612] vmstat, memory, sum of all of the virtual pages: 4096 vs 1024 bytes per page?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282612 --- Comment #2 from tzxzan+cqw8r63qtf...@sharklasers.com --- The FreeBSD documentations always talk about a page size of 4096 bytes. The 'vmstat' manual page also refers to (some) pages, obviously not the same, as for 'vmstat' the pages size is 1024. The FreeBSD 'vmstat' manual page could be more clear here, like the NetBSD manual page: ... (reported in units of 1024 bytes) ... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282474] bell: unable to enable bell
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282474 Yusuf Yaman changed: What|Removed |Added Status|Open|Closed Resolution|--- |Works As Intended --- Comment #9 from Yusuf Yaman --- I have added "kern.vt.enable_bell=1" to /etc/sysctl.conf instead and it started to work while speaker_load="YES" is set on /boot/loader.conf. Also disabled syscons bell in /etc/sysctl.conf. I didn't notice much difference in vt's bell after the patch but you may have noticed it. I think this report can be closed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 273664] ovpn(4) DCO module doesn't support "multihome" option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273664 --- Comment #6 from Marek Zarychta --- FWIW: support or this feature was committed to the Linux version of DCO on Mar 16, 2021 by Antonio Quartulli[1] 1. https://github.com/OpenVPN/ovpn-dco/commit/2c6b64cef48fef7b9652109f440686593ae83343 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282605] panic: tcp_do_segment: sent too much
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605 Mark Johnston changed: What|Removed |Added Status|New |Open CC||gleb...@freebsd.org, ||ma...@freebsd.org, ||rsch...@freebsd.org, ||tue...@freebsd.org Assignee|b...@freebsd.org|transp...@freebsd.org --- Comment #1 from Mark Johnston --- There have been a couple of TCP commits since your revision - is it possible that this is already fixed? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282563] stable/14 build with clang19
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282563 Mark Johnston changed: What|Removed |Added Resolution|--- |Not A Bug Status|New |Closed CC||ma...@freebsd.org --- Comment #3 from Mark Johnston --- (In reply to Jordan Ostreff from comment #2) That is correct. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282587] [quota] Cannot set quota from chrooted environment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282587 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org Status|New |Open --- Comment #1 from Mark Johnston --- Could you please share the patch? I don't see any reason not to try to fix the problem, unless the solution particularly disruptive somehow. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277601] [nanoBSD] enabled entropy_boot_file leads to warning/error from dd during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277601 em...@posteo.de changed: What|Removed |Added Attachment #249541|0 |1 is obsolete|| --- Comment #3 from em...@posteo.de --- Created attachment 255014 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255014&action=edit nanoBSD: disable entropy caching and early hostuuid (In reply to Jose Luis Duran from comment #2) Thanks for the pointer, I added it to the patch to be consistent - /var/db/entropy is empty at boot time, anyways. No need for cron to save anything. I'm not sure about the exact boot order here, but maybe it is possible to use some external drive for the entropy to mitigate the wear? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277601] [nanoBSD] enabled entropy_boot_file leads to warning/error from dd during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277601 --- Comment #4 from Jose Luis Duran --- (In reply to embhd from comment #3) Yes! RANDOM_PURE_TPM and EFIRNG come to mind, but I haven't tested either of them lately. I'll try to set up a lab over the weekend to test this, as well as other NanoBSD-related bugs. I've moved on to building NanoBSD-like images using Poudriere directly, so bear with me. At any rate, I wouldn't hold my breath on this PR. Thank you! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 154955] [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=154955
sp...@itl.ua changed:
What|Removed |Added
CC||sp...@itl.ua
--- Comment #3 from sp...@itl.ua ---
(In reply to Alexander from comment #0)
The same issue on my Lenovo Ideapad S110 with 13.3-RELEASE.
My fix (quick one, needs to be integrated somehow into proper place):
#include
#include
#include
#include
#define I8042_COMMAND_REG 0x64
int main() {
open("/dev/io", O_WRONLY);
outb(I8042_COMMAND_REG, 0xae);
return 0;
}
Thank you (over years) for the link which has conveyed to the fix.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 282614] ${LOCALBASE}/etc/periodic.conf is ignored
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282614
Bug ID: 282614
Summary: ${LOCALBASE}/etc/periodic.conf is ignored
Product: Base System
Version: 14.2-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: conf
Assignee: b...@freebsd.org
Reporter: free...@oldach.net
Fresh install from
FreeBSD-14.2-PRERELEASE-amd64-20241031-25ad37c9532b-269367-disc1.iso:
toor@t:/ # cd /usr/local
toor@t:/usr/local/etc # mkdir -p etc/periodic/test
toor@t:/usr/local/etc # cat >etc/periodic/test/test
[Bug 277601] [nanoBSD] enabled entropy_boot_file leads to warning/error from dd during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277601 em...@posteo.de changed: What|Removed |Added Attachment #255014|0 |1 is obsolete|| --- Comment #5 from em...@posteo.de --- Created attachment 255015 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255015&action=edit nanoBSD: disable entropy caching and early hostuuid -- You are receiving this mail because: You are the assignee for the bug.
[Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269133 --- Comment #67 from Hauke Fath --- (In reply to Hauke Fath from comment #66) As an aside, in a plain (non-vlan) setup, the broadcom NIC "negociated" 1 GBit with an Nvidia 2010 switch on a 1/10/15 GBit port set to 'auto'. The port had to be set to 25 GBit before the NIC accepted the speed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282612] vmstat, memory, sum of all of the virtual pages: 4096 vs 1024 bytes per page?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282612 Bug ID: 282612 Summary: vmstat, memory, sum of all of the virtual pages: 4096 vs 1024 bytes per page? Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: tzxzan+cqw8r63qtf...@sharklasers.com CC: d...@freebsd.org https://man.freebsd.org/cgi/man.cgi?query=vmstat&apropos=0&sektion=0&manpath=FreeBSD+14.1-RELEASE+and+Ports&arch=default&format=ascii --- ... memory Information about the usage of virtual and real memory. Mapped virtual memory is a sum of all of the virtual pages be- longing to mapped virtual memory objects. Note that the entire memory object's size is considered mapped even if only a subset of the object's pages are currently mapped. This statistic is not related to the active page queue which is used to track real memory. avm mapped virtual memory (previously called active in vmstat output) fre size of the free list ... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282612] vmstat, memory, sum of all of the virtual pages: 4096 vs 1024 bytes per page?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282612 --- Comment #1 from tzxzan+cqw8r63qtf...@sharklasers.com --- https://man.netbsd.org/vmstat.1 --- ... memory Information about the usage of virtual and real memory. Virtual pages (reported in units of 1024 bytes) are considered active if they belong to processes which are running or have run in the last 20 seconds. avm active virtual pages fre size of the free list ... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282474] bell: unable to enable bell
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282474 --- Comment #11 from Ed Maste --- (In reply to Yusuf Yaman from comment #10) I would expect the bell to be usable in any vty, but haven't tested. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282474] bell: unable to enable bell
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282474 --- Comment #10 from Yusuf Yaman --- Is it intended that vt bell ring only work on ttyv0 but not in others? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282474] bell: unable to enable bell
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282474 --- Comment #7 from Yusuf Yaman --- pc speakers that i had ordered did arrive just now, i tested the `vt` bell and it works. I didn't apply the patch that changes the bell pitch. i had to set "kern.vt.enable_bell=1" in /boot/loader.conf. Strangely the `vt` bell doesn't work when "speaker_load=YES" is set in /boot/loader.conf. I didn't test new commit yet: vt: Fix frequency calcuation for bell 2416be588ea113cc06b924ed85861ed3bc391fe0 I am on 14.1-RELEASE, As far as i can see, the commit changes only one line in sys/dev/vt/vt_core.c. So I think i can patch the src code and see the new change. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282605] panic: tcp_do_segment: sent too much
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282605 Bug ID: 282605 Summary: panic: tcp_do_segment: sent too much Product: Base System Version: 15.0-CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ddan...@nvidia.com Sending stress TCP with offloaded NAT-T configuration panic: tcp_do_segment: sent too much BT #0 __curthread () at /usr/kernel_git/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=textdump@entry=1) at /usr/kernel_git/sys/kern/kern_shutdown.c:404 #2 0x80b3b7a0 in kern_reboot (howto=260) at /usr/kernel_git/sys/kern/kern_shutdown.c:524 #3 0x80b3bcd7 in vpanic (fmt=0x81172d6e "%s: sent too much", ap=ap@entry=0xfe010a82db20) at /usr/kernel_git/sys/kern/kern_shutdown.c:979 #4 0x80b3bb03 in panic (fmt=) at /usr/kernel_git/sys/kern/kern_shutdown.c:892 #5 0x80d34372 in tcp_do_segment (tp=0xf803402baa80, tp@entry=, m=, m@entry=, th=0xf802fd295e84, th@entry=, drop_hdrlen=64, drop_hdrlen@entry=, tlen=0, tlen@entry=, iptos=, iptos@entry=) at /usr/kernel_git/sys/netinet/tcp_input.c:1548 #6 0x80d30d98 in tcp_input_with_port (mp=, offp=, proto=, port=port@entry=0) at /usr/kernel_git/sys/netinet/tcp_input.c:1158 #7 0x80d31a5b in tcp_input (mp=, offp=, proto=) at /usr/kernel_git/sys/netinet/tcp_input.c:1502 #8 0x80d1e3af in ip_input (m=0x0, m@entry=) at /usr/kernel_git/sys/netinet/ip_input.c:857 #9 0x80c98b7b in netisr_process_workstream_proto (nwsp=0x823c0a00, proto=1) at /usr/kernel_git/sys/net/netisr.c:927 #10 swi_net (arg=0x823c0a00) at /usr/kernel_git/sys/net/netisr.c:974 #11 0x80af3b56 in intr_event_execute_handlers (ie=0xf800035ee600, p=) at /usr/kernel_git/sys/kern/kern_intr.c:1183 #12 ithread_execute_handlers (ie=0xf800035ee600, p=) at /usr/kernel_git/sys/kern/kern_intr.c:1196 #13 ithread_loop (arg=arg@entry=0xf800033cdf60) at /usr/kernel_git/sys/kern/kern_intr.c:1289 #14 0x80aeff52 in fork_exit (callout=0x80af38f0 , arg=0xf800033cdf60, frame=0xfe010a82df40) at /usr/kernel_git/sys/kern/kern_fork.c:1151 #15 SHA ID of the kernel: 2ce493e1693b55a330079ac5fce8beb66e26ddeb -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277269] [nanoBSD] setting NANO_PMAKE in defaults.sh renders setting NANO_NCPU in config useless
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277269 Jose Luis Duran changed: What|Removed |Added Status|New |In Progress CC||jldu...@freebsd.org Assignee|b...@freebsd.org|jldu...@freebsd.org --- Comment #1 from Jose Luis Duran --- Good catch! Let's divide this PR in two parts: 1. Fix the usage string. 2. Fix parallel make. Attached are the two proposed patches. The reason I want to avoid your approach for No. 2, if possible, is that NANO_PMAKE is older than NANO_NCPU. Nobody knows what NANO_PMAKE string other users might have, and your proposed change could "break" their build system. If you don't mind testing, I would highly appreciate it. Thank you for reporting it! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282474] bell: unable to enable bell
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282474
--- Comment #8 from Yusuf Yaman ---
I have made change below but now the vt bell doesn't ring anymore. That's
releng/14.1 source code branch and that's the only change i have made.
# git diff .
diff --git a/sys/dev/vt/vt_core.c b/sys/dev/vt/vt_core.c
index 797af56e5..4c02a9ec8 100644
--- a/sys/dev/vt/vt_core.c
+++ b/sys/dev/vt/vt_core.c
@@ -119,7 +119,7 @@ static const struct terminal_class vt_termclass = {
/* Bell pitch/duration. */
#defineVT_BELLDURATION (SBT_1S / 20)
-#defineVT_BELLPITCH(1193182 / 800) /* Approx 1491Hz */
+#defineVT_BELLPITCH800
#defineVT_UNIT(vw) ((vw)->vw_device->vd_unit * VT_MAXWINDOWS + \
(vw)->vw_number)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 281685] ASAN intercepting SHA256 and MD5 causes issues with OpenSSL's EVP
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281685 Mark Johnston changed: What|Removed |Added Assignee|b...@freebsd.org|toolch...@freebsd.org CC||d...@freebsd.org --- Comment #4 from Mark Johnston --- (In reply to Rafael Grether from comment #3) As far as I can see, this patch isn't in 14.2 (though it is in stable/14). It's not in stable/13 either. It seems low-risk enough that we could include it in 14.2, but it's getting a bit late in the release cycle. Dimitry, do you have an opinion on what to do here? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 281177] 13.2 works, 13.3 and 14.x installers panic on older qlogic isp card
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281177 Mark Johnston changed: What|Removed |Added CC||k...@freebsd.org, ||ma...@freebsd.org Status|New |Open --- Comment #11 from Mark Johnston --- (In reply to Vladimir Druzenko from comment #10) If this is a regression relative to 14.1, then the problem is likely different from the original bug report. It's possibly a regression from one of these commits: https://cgit.freebsd.org/src/commit/?id=ff9458b30fc3b8748f65eca792be7b6e64c639bf https://cgit.freebsd.org/src/commit/?id=44ca5d40f36704ffa2fa55f8f1403c824400b3ba Ken, do you have any idea what might be going on here? I also wonder if the original bug is still reproducible after those two commits? That is, do we still panic on boot on the latest stable/13 or stable/14? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282620] NFSv4 user mapping not working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282620 --- Comment #1 from Julio Merino --- Created attachment 255020 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255020&action=edit Sample patch I don't yet know what the actual root cause is, but this patch hides the issue for me. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282620] NFSv4 user mapping not working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282620
Bug ID: 282620
Summary: NFSv4 user mapping not working
Product: Base System
Version: 14.2-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: j...@freebsd.org
I've set up a Kerberos domain (the KDC is on a pfSense box) and an NFSv4 server
which is on a Synology NAS.
I'm mounting the remote share on my FreeBSD 14.2-STABLE client with an entry in
fstab like this:
nas:/volume1/homes /shared nfs rw,nfsv4,gssname=host,sec=krb5p,pnfs 0 0
I have gssd and nfsuserd running, but when I list the contents of the
directory, I get:
$ ls -l /shared
total 0
drwxr-xr-x 1 nobody nogroup 0 Sep 27 21:11 admin
drwxr-xr-x 1 nobody nogroup 0 Nov 5 19:58 jmmv
drwxr-xr-x 1 nobody nogroup 0 Oct 8 16:59 manager
The "jmmv" directory should show up as owned by "jmmv", but it shows up as
"nobody".
When I start nfsuserd with -verbose set, I get:
nfsuserd: domain=meroh.net usermax=200 usertimeout=60
The domain meroh.net is the correct domain for the machine, and the Kerberos
domain name is MEROH.NET.
I've added logging statements to nfsuserd and can see that the GETUSER requests
from the kernel carry j...@meroh.net in them, which seems good, but still
things don't work.
In playing with the code, I modified the nfsuserd code with this:
--
--- a/usr.sbin/nfsuserd/nfsuserd.c
+++ b/usr.sbin/nfsuserd/nfsuserd.c
@@ -377,8 +377,15 @@ main(int argc, char *argv[])
setgrent();
while (i < nid.nid_usermax && (grp = getgrent())) {
nid.nid_gid = grp->gr_gid;
- nid.nid_name = grp->gr_name;
- nid.nid_namelen = strlen(grp->gr_name);
+ char buf[1024];
+ snprintf(buf, sizeof(buf), "%s@%s", grp->gr_name, dnsname);
+ char *ptr = strchr(buf, '@');
+ while (*ptr != '\0') {
+ *ptr = toupper(*ptr);
+ ptr++;
+ }
+ nid.nid_name = buf;
+ nid.nid_namelen = strlen(nid.nid_name);
nid.nid_ngroup = 0;
nid.nid_grps = NULL;
nid.nid_flag = NFSID_ADDGID;
@@ -416,8 +423,15 @@ main(int argc, char *argv[])
continue;
check_dups[i - start_uidpos] = pwd->pw_uid;
nid.nid_uid = pwd->pw_uid;
- nid.nid_name = pwd->pw_name;
- nid.nid_namelen = strlen(pwd->pw_name);
+ char buf[1024];
+ snprintf(buf, sizeof(buf), "%s@%s", pwd->pw_name, dnsname);
+ char *ptr = strchr(buf, '@');
+ while (*ptr != '\0') {
+ *ptr = toupper(*ptr);
+ ptr++;
+ }
+ nid.nid_name = buf;
+ nid.nid_namelen = strlen(nid.nid_name);
if (manage_gids != 0) {
/* Get the group list for this user. */
ngroup = NGROUPS;
--
And got the usernames to work properly _after_ mount. This is insufficient when
the cache expires though because the above is only for the daemon
initialization, but seems to show that there is some inconsistency between what
nfsuserd thinks the domain should be expressed and what the kernel expects.
Note that, in the above, the toupper is important as well.
I do not know yet if this is a failure of my configuration or a bug in nfsuserd
/ the kernel.
Could you assist / confirm?
--
You are receiving this mail because:
You are the assignee for the bug.
