[Bug 272787] Add asmc support for MacBookPro10,1, MacMini6,2, and MacBookPro8,3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272787 --- Comment #6 from Jason W. Bacon --- (In reply to ed crowe from comment #4) Thanks, updating to case ASMC_ALSL_INT2A: /* * This suppresses console and log messages for the ambient * light sensor for models known to generate this interrupt. */ if (strcmp(sc->sc_model->smc_model, "MacBookPro5,5") == 0 || strcmp(sc->sc_model->smc_model, "MacBookPro6,2") == 0 || strcmp(sc->sc_model->smc_model, "MacBookPro8,3") == 0) break; has silenced the log messages. I'll give some thought to a pull request, but I'd like to improve on the rest of the patch first. Most of the values of dev.asmc look reasonable, but I don't even know what some of them represent, or if they're relevant to this model, e.g. dev.asmc.0.temp.TCTD: 0 dev.asmc.0.fan.1.safespeed: -1 dev.asmc.0.light.control: 0 I'll see if I can dig up some info on this. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283123] loading i915kms causes black screen on Lenovo X1 carbon gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283123 --- Comment #2 from Pat Maddox --- Yeah if you look at https://pkg-status.freebsd.org/ you can see that the 14 packages are still being build with 141 jails. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283123] loading i915kms causes black screen on Lenovo X1 carbon gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283123 --- Comment #1 from Pat Maddox --- Have you built the package yourself using a 14.2 kernel? My understanding is that the official package repos are still currently building with 14.1, and will for another... 3 months? So right now when kmods fail to load on 14.2, you probably have to build them yourself. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283137] pf: states corruption since 93c80b79ad65c leading to kernel panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283137 Bug ID: 283137 Summary: pf: states corruption since 93c80b79ad65c leading to kernel panic Product: Base System Version: 14.2-STABLE Hardware: Any URL: https://github.com/opnsense/src/issues/230 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: fra...@opnsense.org Hi, OPNsense users report a pf state corruption since the deployment of 93c80b79ad65 which ends up in at least one kernel panic, but due to the nature of the situation it could actually be multiple. The issue seems quite prevalent on production systems and may crash a system after just a couple of minutes of runtime. One user provided a kernel dump. I'm attaching the info for triage here: (kgdb) bt #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57 #1 doadump (textdump=textdump@entry=0) at /usr/src/sys/kern/kern_shutdown.c:405 #2 0x8049c36a in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:591 #3 0x8049c16d in db_command (last_cmdp=, cmd_table=, dopager=false) at /usr/src/sys/ddb/db_command.c:504 #4 0x8049c2b6 in db_command_script (command=command@entry=0x81bbf6d3 "dump") at /usr/src/sys/ddb/db_command.c:569 #5 0x804a1528 in db_script_exec (scriptname=, warnifnotfound=warnifnotfound@entry=0) at /usr/src/sys/ddb/db_script.c:302 #6 0x804a1435 in db_script_kdbenter (eventname=) at /usr/src/sys/ddb/db_script.c:325 #7 0x8049f4f1 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:267 #8 0x80c09868 in kdb_trap (type=type@entry=3, code=code@entry=0, tf=tf@entry=0xfe00e206e2e0) at /usr/src/sys/kern/subr_kdb.c:790 #9 0x810e0419 in trap (frame=0xfe00e206e2e0) at /usr/src/sys/amd64/amd64/trap.c:608 #10 #11 kdb_enter (why=, msg=) at /usr/src/sys/kern/subr_kdb.c:556 #12 0x80bb91d2 in vpanic (fmt=0x823f5cbd "Bad link elm %p prev->next != elm", ap=ap@entry=0xfe00e206e510) at /usr/src/sys/kern/kern_shutdown.c:955 #13 0x80bb9283 in panic (fmt=0x81d82c18 "") at /usr/src/sys/kern/kern_shutdown.c:891 #14 0x823c1dd0 in pf_state_key_detach (s=s@entry=0xf803cc297b00, idx=idx@entry=0) at /usr/src/sys/netpfil/pf/pf.c:1456 #15 0x823ad0ef in pf_detach_state (s=s@entry=0xf803cc297b00) at /usr/src/sys/netpfil/pf/pf.c:1442 #16 0x823ac6d9 in pf_state_key_attach (skw=0xf803cc2c4420, sks=0x0, s=0xf803cc297b00) at /usr/src/sys/netpfil/pf/pf.c:1355 #17 pf_state_insert (kif=, orig_kif=orig_kif@entry=0xf80002150600, skw=0xf803cc2c4420, sks=, s=s@entry=0xf803cc297b00) at /usr/src/sys/netpfil/pf/pf.c:1535 #18 0x823ba740 in pf_create_state (r=0xf80227b7e000, nr=0xf80189e7a800, a=, pd=0xfe00e206eb00, nsn=0x0, nk=0x12, sk=, m=0xf8001dc64800, off=20, sport=4843, dport=59668, rewrite=0xfe00e206ea0c, kif=0xf80002150600, sm=0xfe00e206ec18, tag=-1, bproto_sum=25520, bip_sum=979, hdrlen=8, match_rules=) at /usr/src/sys/netpfil/pf/pf.c:5025 #19 pf_test_rule (rm=rm@entry=0xfe00e206ebf0, sm=sm@entry=0xfe00e206ec18, kif=kif@entry=0xf80002150600, m=0xf8001dc64800, off=20, pd=pd@entry=0xfe00e206eb00, am=0xfe00e206ebd8, rsm=0xfe00e206ebc8, inp=0x0) at /usr/src/sys/netpfil/pf/pf.c:4800 #20 0x823b4471 in pf_test (dir=dir@entry=1, pflags=, ifp=0xf80001906000, m0=m0@entry=0xfe00e206ed08, inp=, default_actions=default_actions@entry=0x0) at /usr/src/sys/netpfil/pf/pf.c:8269 #21 0x823dc177 in pf_check_in (m=0xfe00e206ed08, ifp=0x12, flags=-502865312, ruleset=, inp=0x80c10af0 ) at /usr/src/sys/netpfil/pf/pf_ioctl.c:6575 #22 0x80d19e98 in pfil_mbuf_common (pch=, m=0xfe00e206ed08, m@entry=0xfe00e206ec48, ifp=0xf80001906000, flags=65536, inp=inp@entry=0x0) at /usr/src/sys/net/pfil.c:212 #23 pfil_mbuf_in (head=, m=m@entry=0xfe00e206ed08, ifp=0xf80001906000, inp=inp@entry=0x0) at /usr/src/sys/net/pfil.c:230 #24 0x80d9c59a in ip_tryforward (m=0xf8001dc64800) at /usr/src/sys/netinet/ip_fastfwd.c:312 #25 0x80d9fa9c in ip_input (m=0xf8001dc64800) at /usr/src/sys/netinet/ip_input.c:621 #26 0x80d1682b in netisr_process_workstream_proto (nwsp=0xfe003a5eca40, proto=1) at /usr/src/sys/net/netisr.c:927 #27 swi_net (arg=0xfe003a5eca40) at /usr/src/sys/net/netisr.c:974 #28 0x80b6ffc6 in intr_event_execute_handlers (ie=0xf80001a59100, p=) at /usr/src/sys/kern/kern_intr.c:1205 #29 ithread_execute_handlers (ie=0xf80001a59100, p=) at /usr/src/sys/kern/kern_intr.c:1218 #30 ithread_loop (arg=arg@entry=0xf80001a7a620) at /usr/src/sys/kern/kern_intr.c:1306 #31 0x80b6c402 in fork_exit (callout=0xf
[Bug 283116] ntpd doesn't sync with any NTP servers on IPv6-Only host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283116 --- Comment #1 from Dmitrij <4e5dfbsdb...@nexus.tel> --- All mentioned hosts are running at kern.securelevel=2 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283123] loading i915kms causes black screen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283123 Bug ID: 283123 Summary: loading i915kms causes black screen Product: Base System Version: 14.2-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: conf Assignee: b...@freebsd.org Reporter: m...@weis.xyz After upgrading form 14.1 to 14.2, when loading i915kms (from rc.conf or after removing form rc.conf through kldload) turns the screen black. I also tried to reinstall all packages with pkg-static upgrade -f (same result) Hardware: - Lenovo X1 carbon gen 8 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283123] loading i915kms causes black screen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283123 Michael changed: What|Removed |Added Component|conf|kern -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283123] loading i915kms causes black screen on Lenovo X1 carbon gen 8
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283123 Mark Linimon changed: What|Removed |Added Summary|loading i915kms causes |loading i915kms causes |black screen|black screen on Lenovo X1 ||carbon gen 8 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283125] [oci] add Open Container Initiative registries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283125 Bug ID: 283125 Summary: [oci] add Open Container Initiative registries Product: Base System Version: 14.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: d...@freebsd.org Now that 14.2-RELEASE publishes base images via the usual downloads website links, users are requesting these be made available on the more common public container registry platforms, such as docker.io github container registry etc. Something similar to `podman pull freebsd14-minimal:14.2-RELEASE` but this requires a few more moving parts than we have today. This requires a bit of coordination, and discussion: - naming is important - ensuring chain of trust for users & releng teams - what secteam guarantees / expectations are and how to communicate them - what should happen when patches/errata are released I will open this up with re@ and secteam@ and keep this updated. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283125] [oci] add Open Container Initiative registries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283125 Dave Cottlehuber changed: What|Removed |Added Assignee|b...@freebsd.org|d...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282713] Process enters in STOP state and doesn't respond to any signal.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282713
--- Comment #15 from Rupesh Pilania ---
Slowly other applications will get stuck at same lock.
db> ps
107399 s application
107400 D umtxqb 0x80fdb060 application
107401 s application
107402 s application
107403 s application
107417 s application
107420 s application
107432 s application
107449 s application
107452 s application
107454 s application
107460 Ss usem0xf803b208b100 application
db> show lock 0x80fdb060
class: sleep mutex
name: umtxql
flags: {DEF, DUPOK}
state: {UNOWNED}
witness gives
umtxql (type: sleep mutex, depth: 0, active refs: 1024) -- last acquired @
kern/kern_umtx.c:511
/*
* Lock a chain.
*/
static inline void
umtxq_lock(struct umtx_key *key)
{
struct umtxq_chain *uc;
uc = umtxq_getchain(key);
mtx_lock(&uc->uc_lock);
}
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 282978] sockstat doesn't use a wide enough field for the inp_gencnt column
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282978 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=fbd3448614fbd7bd92e7d34c3bfd2592a07391e3 commit fbd3448614fbd7bd92e7d34c3bfd2592a07391e3 Author: Mark Johnston AuthorDate: 2024-12-04 01:12:39 + Commit: Mark Johnston CommitDate: 2024-12-04 16:22:50 + sockstat: Ensure that there is always a space between columns PR: 282978 Reviewed by:asomers MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D47840 usr.bin/sockstat/sockstat.c | 56 ++--- 1 file changed, 33 insertions(+), 23 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282994] Repeated kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282994 --- Comment #12 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f3b7dbdad53b31492757417fc1336ed74ec80fd8 commit f3b7dbdad53b31492757417fc1336ed74ec80fd8 Author: Mark Johnston AuthorDate: 2024-12-04 01:04:33 + Commit: Mark Johnston CommitDate: 2024-12-04 16:22:50 + shm: Handle swap pager allocation failures shm_alloc() can fail if swap reservation fails (i.e., vm.overcommit is non-zero) or racct is imposing some limits on swap usage. PR: 282994 MFC after: 2 weeks Reviewed by:olce, kib Differential Revision: https://reviews.freebsd.org/D47839 sys/kern/kern_umtx.c | 8 +- sys/kern/uipc_shm.c | 80 2 files changed, 57 insertions(+), 31 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270404] comsat is willing to try to read and display any file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270404 --- Comment #8 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bb9678f1ff6881b036220045adb58047332cfb0d commit bb9678f1ff6881b036220045adb58047332cfb0d Author: Ed Maste AuthorDate: 2024-11-28 16:54:48 + Commit: Ed Maste CommitDate: 2024-12-04 18:38:31 + comsat: Use initgroups and setgid not just setuid PR: 270404 Reviewed by:jlduran Obtained from: NetBSD Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D47828 (cherry picked from commit d4dd9e22c13896e6b5e2a6fc78dad4f8496cc14d) libexec/comsat/comsat.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282978] sockstat doesn't use a wide enough field for the inp_gencnt column
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282978 Mark Johnston changed: What|Removed |Added Status|Open|In Progress Assignee|b...@freebsd.org|ma...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 282994] Repeated kernel panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282994 Mark Johnston changed: What|Removed |Added Status|Open|In Progress Assignee|b...@freebsd.org|ma...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 181636] mtree(8): mtree -U does not fix ownership of symbolic links
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=181636 Jose Luis Duran changed: What|Removed |Added CC||jldu...@freebsd.org --- Comment #4 from Jose Luis Duran --- Created attachment 255615 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255615&action=edit Change modification time for symlinks The bug is no longer present as reported, however the modification times are not changed. The fix might be as simple as utimes(2) -> lutimes(2), but it has to be upstreamed (and accepted) first: # mkdir /tmp/mtree # cd /tmp/mtree # mkdir dir # touch file # ln -s dir dirlink # ln -s file filelink # chown -R 206:30 . # ls -aln total 27 drwxr-xr-x 3 206 30 6 Dec 4 12:00 . drwxrwxrwt 4 0 0 4 Dec 4 12:00 .. drwxr-xr-x 2 206 30 2 Dec 4 12:00 dir lrwxr-xr-x 1 206 30 3 Dec 4 12:00 dirlink -> dir -rw-r--r-- 1 206 30 0 Dec 4 12:00 file lrwxr-xr-x 1 206 30 4 Dec 4 12:00 filelink -> file # cat ../mtree.file # user: on # machine: banyan.cs.ait.ac.th # tree: /home/java/on/Mtree/dir # date: Thu Aug 29 09:58:26 2013 # . /set type=file uid=4096 gid=30 mode=0755 nlink=1 flags=none . type=dir gid=5030 nlink=3 time=1377745075.0 dirlink type=link gid=5030 time=1377745073.0 link=dir filegid=5030 mode=0644 size=0 time=1377743843.0 filelinktype=link uid=206 time=1377743896.0 link=file # ./dir dir type=dir gid=5030 nlink=2 time=1377745068.0 # ./dir .. # mtree -F freebsd9 -U -f ../mtree.file mtree: Adding -i to -U for FreeBSD compatibility mtree: Adding -t to -U for FreeBSD compatibility ...(omitted for brevity) # ls -aln total 27 drwxr-xr-x 3 4096 5030 6 Aug 28 2013 . drwxrwxrwt 4 006 Dec 4 12:00 .. drwxr-xr-x 2 4096 5030 2 Aug 28 2013 dir lrwxr-xr-x 1 4096 5030 3 Dec 4 12:00 dirlink -> dir -rw-r--r-- 1 4096 5030 0 Aug 28 2013 file lrwxr-xr-x 1 206 30 4 Dec 4 12:00 filelink -> file -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283116] ntpd doesn't sync with any NTP servers on IPv6-Only host
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283116 --- Comment #2 from Dmitrij <4e5dfbsdb...@nexus.tel> --- Tried to run ntpd with --ipv6 (for about an hour), result is the same: ipv6 NTP traffic is present, but ntpd maintain unsynced state. -- You are receiving this mail because: You are the assignee for the bug.
