[Bug 283683] [PATCH] dev/acpica/acpi_cmbat.c: Add battery trip point (_BTP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283683
Bug ID: 283683
Summary: [PATCH] dev/acpica/acpi_cmbat.c: Add battery trip
point (_BTP)
Product: Base System
Version: 15.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: georg.lastn...@web.de
Created attachment 256226
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256226&action=edit
diff for sys/dev/acpica/acpi_cmbat.c
[PATCH]
Affected file: sys/dev/acpica/acpi_cmbat.c
This patch implements _BTP (battery trip point).
This is basically for laptop users.
You set a warning level, e.g. 20%. Then devd will notify you when the battery
reaches 20%.
Quoting the ACPI specification version 6.5 section 10.2.2.14 ("_BTP"):
"This object is used to set a trip point to generate an SCI whenever the
Battery Remaining Capacity reaches or crosses the value specified in the _BTP
object."
I have another explanation here:
https://github.com/random532/FreeBSD_Battery_Trip_Point
The _BTP method is optional, so not every battery supports it.
-- What I did (aka design choices):
1. The cmbat driver has a unique device_attach() routine. It loops multipe
times until the battery controller is ready.
So once that process is finished (aka the battery is registered), I feel like
that is a good place to add all the optional acpi methods. For now, the only
optional method that is supported would be _BTP. I add a function
acpi_initialize_btp() and a handler function acpi_cmbat_btp_sysctl().
2. I chose a sysctl for the trip point. It is possible to use /dev/acpi and
acpiconf for this, which at first glance is more consistent with the current
design. However, the trip point is read-write. The current battery reporting is
read-only. Also, we'd need a new argument for acpiconf, because right now,
there is only acpiconf -i X, which reads battery information. I can see a
design where the userland command would be "acpiconf -i 0 -w 20", where w would
be the warning level.
But I think the sysctl is just fine.
3. More information is on github.
I just want to put this out there.
4. So far tested on:
ThinkPad x220
Thanks everyone.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 283679] in release, make ftp fails, because DISTDIR in base conflicts with DISTDIR in ports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283679 Dave Cottlehuber changed: What|Removed |Added CC||bro...@freebsd.org, ||ema...@freebsd.org --- Comment #2 from Dave Cottlehuber --- suitable work-around for me was setting __MAKE_CONF=/dev/null for src builds. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283693] OOB read during HCI event mask filtering
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283693
Bug ID: 283693
Summary: OOB read during HCI event mask filtering
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: zy...@cl.cam.ac.uk
- Overview:
During raw HCI packet filtering, ng_btsocket_hci_raw_filter incorrectly filters
packets due to an out-of-bounds read.
- Root cause:
In ng_btsocket_hci_raw_filter, if the HCI event code is greater than
NG_HCI_EVENT_MASK_SIZE * 8, where NG_HCI_EVENT_MASK_SIZE is 8, then an integer
overflow happens in bit_test. This is due to an incorrect declaration of
bitstrings in the ng_btsocket_hci_raw_filter struct. Valid event codes range
from 0x01 to 0xff, whereas the bitstring declaration specifies
NG_HCI_EVENT_MASK_SIZE * 8 = 64. The specific line of code is in:
https://github.com/freebsd/freebsd-src/blob/837feb4d05c2dccafa1698649b58f7b7fdc59c54/sys/netgraph/bluetooth/socket/ng_btsocket_hci_raw.c#L715:
if (!bit_test(pcb->filter.event_mask, event))
This crash was found when working with a CheriBSD purecap kernel, where the
issue causes a kernel panic instead of a silent OOB.
- Fix:
The bitstring declaration can be fixed as suggested in the diff below. Also,
the bitstring declaration of packet_mask in ng_btsocket_hci_raw_filter struct
specifies 32, but valid packet types range from 0x1 to 0x4. Therefore, a
bitstring declaration of 8 bits is enough.
diff --git a/sys/netgraph/bluetooth/include/ng_btsocket.h
b/sys/netgraph/bluetooth/include/ng_btsocket.h
index 2dc15d44e72..8ccfad2d808 100644
--- a/sys/netgraph/bluetooth/include/ng_btsocket.h
+++ b/sys/netgraph/bluetooth/include/ng_btsocket.h
@@ -69,8 +69,8 @@ struct sockaddr_hci {
*/
struct ng_btsocket_hci_raw_filter {
- bitstr_tbit_decl(packet_mask, 32);
- bitstr_tbit_decl(event_mask, (NG_HCI_EVENT_MASK_SIZE * 8));
+ bitstr_tbit_decl(packet_mask, 8);
+ bitstr_tbit_decl(event_mask, 256);
};
/*
- Kernel commit and config:
This is reproducible as of the latest commit on 27th December 2024 in a GENERIC
kernel, with enabled Bluetooth.
- Credits:
Yichen Chai
Zhuo Ying Jiang Li
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 283693] OOB read during HCI event mask filtering
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283693 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org Keywords||patch --- Comment #1 from Mark Linimon --- ^Triage: note that this PR contains an inline patch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283683] [PATCH] dev/acpica/acpi_cmbat.c: Add battery trip point (_BTP)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283683 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|a...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 --- Comment #333 from George Mitchell --- I have another build in progress. Thanks for the revised patch! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 --- Comment #334 from George Mitchell --- New build is complete and installed, but hasn't exhibited any crashes yet. Please stand by! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028
--- Comment #336 from Mark Millard ---
(In reply to George Mitchell from comment #335)
For reference: going backwards through the found_modules
list (via also using my extra recorded data) is the
following. It is pairs of my modlist_newmod_hist and
then a the prior node's link.tqe_next value that
should agree with the the prior modAddr.
(kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos]
$48 = {modAddr = 0xf80004718180, containerAddr = 0xf8000362f300,
modnameAddr = 0x82ea6025 "amdgpu_raven_vcn_bin_fw", version = 1}
(kgdb) print
modlist_newmod_hist[modlist_newmod_hist_pos-1].modAddr->link.tqe_next
$49 = (struct modlist *) 0xf80004718180
(kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-1]
$50 = {modAddr = 0xf800047182c0, containerAddr = 0xf8000362f480,
modnameAddr = 0x82e62026 "amdgpu_raven_mec2_bin_fw", version = 1}
(kgdb) print
modlist_newmod_hist[modlist_newmod_hist_pos-2].modAddr->link.tqe_next
$51 = (struct modlist *) 0xf800047182c0
(kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-2]
$52 = {modAddr = 0xf80003647d40, containerAddr = 0xf80003169180,
modnameAddr = 0x82e1e010 "amdgpu_raven_mec_bin_fw", version = 1}
(kgdb) print
modlist_newmod_hist[modlist_newmod_hist_pos-3].modAddr->link.tqe_next
$53 = (struct modlist *) 0xf80003647d40
(kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-3]
$54 = {modAddr = 0xf80004718240, containerAddr = 0xf80003169300,
modnameAddr = 0x82e12009 "amdgpu_raven_rlc_bin_fw", version = 1}
(kgdb) print
modlist_newmod_hist[modlist_newmod_hist_pos-4].modAddr->link.tqe_next
$55 = (struct modlist *) 0xf80004718240
(kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-4]
$56 = {modAddr = 0xf800035bb8c0, containerAddr = 0xf80003169600,
modnameAddr = 0x829f6010 "amdgpu_raven_ce_bin_fw", version = 1}
(kgdb) print
modlist_newmod_hist[modlist_newmod_hist_pos-5].modAddr->link.tqe_next
$57 = (struct modlist *) 0xf807
(kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-5]
$58 = {modAddr = 0xf80004b90140, containerAddr = 0xf80004c42000,
modnameAddr = 0x829ef000 "amdgpu_raven_me_bin_fw", version = 1}
(kgdb) print
modlist_newmod_hist[modlist_newmod_hist_pos-6].modAddr->link.tqe_next
$59 = (struct modlist *) 0xf80004b90140
(kgdb) print modlist_newmod_hist[modlist_newmod_hist_pos-6]
$60 = {modAddr = 0xf80004b90180, containerAddr = 0xf80004c42300,
modnameAddr = 0x829e7025 "amdgpu_raven_pfp_bin_fw", version = 1}
(kgdb) print
modlist_newmod_hist[modlist_newmod_hist_pos-7].modAddr->link.tqe_next
$61 = (struct modlist *) 0xf80004b90180
$57's (modlist_newmod_hist_pos-5's) link.tqe_next does not agree with
$56's modlist_newmod_hist[modlist_newmod_hist_pos-4].modAddr , again by having
the value 0xf807 .
The code did not stop when 0xf807 was stored into that
link.tqe_next instance, unfortunately.
There is something just before that was unusual in the core.9.txt ( or,
as named here, core.txt.9 ): I think it is the first time I've seen any
"WARNING !drm_modeset_is_locked . . ." messages BEFORE the first part of
the first trap(/panic?) reported. In this example, it looks like:
<6>[drm] Initialized amdgpu 3.40.0 20150101 for drmn0 on minor 0
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
/usr/ports/graphics/drm-510-kmod/work/drm-kmod-drm_v5.10.163_7/drivers/gpu/drm/drm_atomic_helper.c:619
. . .
WARNING !drm_modeset_is_locked(&plane->mutex) failed at
/usr/ports/graphics/drm-510-kmod/work/drm-kmod-drm_v5.10.163_7/drivers/gpu/drm/drm_atomic_helper.c:894
kernel trap 22 with interrupts disabled
kernel trap 22 with interrupts disabled
panic: modlist_lookup: a prior tqe_next changed!
. . .
I wonder if that is some sort of consequence of my attempt to
have the hardware monitoring three 8-Byte address ranges for
being written to.
As stands, I do not see how the results provide any specific
additional useful-evidence that I can identify.
The only thing that I've thought of is to add printf reporting of
the address argument passed to each attempted db_hwatchpoint_cmd
use to help validate that I have that code doing what I intended.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 283698] New version of swab(3) breaks port graphics/dcraw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283698 Bug ID: 283698 Summary: New version of swab(3) breaks port graphics/dcraw Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: nwhiteh...@freebsd.org The new version of swab(3) committed in bac2eea13ae3e4dc8fd2aec261b2a18930138495 has slightly different semantics than the old version. In particular, if the input and output buffers are identical, the old version will work, but the new one -- which does not use a temporary buffer like the old one did -- will not. Strictly speaking, this is fine since the input and output pointers are marked 'restrict' so cannot be identical, but at least one program in the wild (graphics/dcraw and all the versions of it in other photography programs) uses identical buffers anyway and expects it to work. Closing this "won't fix" is legitimate -- I will alert the dcraw developers as well, since the bug is clearly on their end -- but I wanted to also write something here since there appear to be compatibility implications both relative to Linux and older versions of FreeBSD. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283698] New version of swab(3) breaks port graphics/dcraw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283698 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|i...@freebsd.org --- Comment #1 from Mark Linimon --- ^Triage: over to committer of change in question. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283696] rc-scripts: Request: rtadvd_flags=""
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283696 --- Comment #1 from Mark Linimon --- disk-WCC6Y0TZTA2A% whereis rc-scripts rc-scripts: Please be specific on what you want to see changed. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283706] atopcase0: irq storm on MacBook Pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283706 Bug ID: 283706 Summary: atopcase0: irq storm on MacBook Pro 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: sa...@saper.info Attachment #256246 text/plain mime type: Created attachment 256246 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256246&action=edit ACPI tables dump The keyboard of a MacBook Pro 13,1 suffers from IRQ storms. The workaround from the manpage prevents the driver from attaching at all: Dec 28 20:57:30 radziecki kernel: lo0: link state changed to UP Dec 28 20:57:30 radziecki kernel: atopcase0: at cs 0 mode 0 on spibus0 Dec 28 20:57:30 radziecki kernel: atopcase0: Using ACPI GPE. Dec 28 20:57:30 radziecki kernel: atopcase0: can't establish communication Dec 28 20:57:30 radziecki kernel: spi0: transfer timeout Dec 28 20:57:30 radziecki kernel: atopcase0: SPI error: 5 Dec 28 20:57:30 radziecki kernel: device_attach: atopcase0 attach returned 5 Dec 28 20:57:30 radziecki kernel: Cuse v0.1.37 @ /dev/cuse Dec 28 20:57:30 radziecki root[1800]: /etc/rc: WARNING: Dump device does not exist. Savecore not run. Dec 28 20:57:30 radziecki named[1854]: starting BIND 9.18.32 (Extended Support Version) Without the workaround it attaches, but the keyboard is hard to use Dec 29 00:38:15 radziecki kernel: tap0: link state changed to UP Dec 29 00:38:15 radziecki kernel: wifibox0: link state changed to UP Dec 29 00:38:15 radziecki kernel: lo0: link state changed to UP Dec 29 00:38:15 radziecki kernel: atopcase0: at cs 0 mode 0 irq 14 on spibus0 Dec 29 00:38:15 radziecki kernel: atopcase0: Using interrupts. Dec 29 00:38:15 radziecki kernel: stray irq14 Dec 29 00:38:15 radziecki kernel: atopcase0: Interrupt storm detected. Falling back to polling Dec 29 00:38:15 radziecki kernel: hidbus0: on atopcase0 Dec 29 00:38:15 radziecki kernel: hidbus1: on atopcase0 Dec 29 00:38:15 radziecki kernel: hkbd0: on hidbus0 This is FreeBSD 15.0-CURRENT #15 main-n274377-cf6b389f7c48: Fri Dec 20 10:09:35 CET 2024 saper@radziecki:/big/obj/usr/src/amd64.amd64/sys/VAIO -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283706] atopcase0: irq storm on MacBook Pro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283706 --- Comment #1 from Marcin Cieślak --- Created attachment 256247 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256247&action=edit dmesg dmesg since boot -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267028] kernel panics when booting with both (zfs,ko or vboxnetflt,ko or acpi_wmi.ko) and amdgpu.ko
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267028 --- Comment #335 from George Mitchell --- Created attachment 256245 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256245&action=edit core.txt.9 Crash with latest patch. Mark, vmcore.9.z, kernel, and kernel.debug are in the usual place. I hope provides a clue! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267317] encryption_change() in ng_hci_evnt.c can dereference NULL pointer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267317 Zhuo Ying Jiang Li changed: What|Removed |Added CC||zy...@cl.cam.ac.uk --- Comment #1 from Zhuo Ying Jiang Li --- Created attachment 256242 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=256242&action=edit Patch for encryption_change null dereference -- You are receiving this mail because: You are the assignee for the bug.
[Bug 267317] encryption_change() in ng_hci_evnt.c can dereference NULL pointer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267317 --- Comment #2 from Zhuo Ying Jiang Li --- I found this bug again while fuzzing with syzkaller. Please find attached a proposed patch. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283678] w/uptime: uses 12-hour time format for zh_CN locale
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283678 Bug ID: 283678 Summary: w/uptime: uses 12-hour time format for zh_CN locale Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: msl023...@gmail.com The up time report uses 12-hour time format under zh_CN locale: # LANG=zh_CN.UTF-8 uptime 8:50下午 up 410 days, 5:54, 2 users, load averages: 0.04, 0.10, 0.12 However, 24-hour time format is preferred for this locale. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283679] in release, make ftp fails, because DISTDIR in base conflicts with DISTDIR in ports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283679 Bug ID: 283679 Summary: in release, make ftp fails, because DISTDIR in base conflicts with DISTDIR in ports Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: d...@freebsd.org DISTDIR has been used for a long time in PORTS, where tarballs are fetched to allowing separating writable distfiles from read-only ports tree during build. https://docs.freebsd.org/en/books/porters-handbook/book/#slow-porting This recently started conflicting with 15.0-CURRENT possibly after 41adc5f29ba6955e09f46e4d2c25da6fcd263ba2. When make.conf has DISTDIR=/var/cache/distfiles, then (cd release && make ftp) will fail. ===> etc/sendmail (install) make[6]: "/usr/obj/usr/src/amd64.amd64/toolchain-metadata.mk" line 1: Using cached toolchain metadata from build at wintermute.skunkwerks.at on Sat Dec 28 09:41:40 UTC 2024 58.12 real35.42 user22.68 sys Failed to build new tree. *** Error code 1 Stop. make: stopped making "ftp" in /usr/src/release .ERROR_TARGET='base.txz' .ERROR_META_FILE='' .MAKE.LEVEL='0' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes' _ERROR_CMD='.PHONY' .CURDIR='/usr/src/release' .MAKE='make' .OBJDIR='/usr/obj/usr/src/amd64.amd64/release' .TARGETS='ftp' CPUTYPE='' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MACHINE_CPUARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20240711' PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/usr/src/amd64.amd64' 64.51 real40.92 user23.82 sys -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283678] w/uptime: uses 12-hour time format for zh_CN locale
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283678 --- Comment #1 from WHR --- In addition, it should also use 24-hour format for the C locale. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283678] w/uptime: uses 12-hour time format for C and zh_CN locales
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283678 WHR changed: What|Removed |Added Summary|w/uptime: uses 12-hour time |w/uptime: uses 12-hour time |format for zh_CN locale |format for C and zh_CN ||locales -- You are receiving this mail because: You are the assignee for the bug.
[Bug 283679] in release, make ftp fails, because DISTDIR in base conflicts with DISTDIR in ports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283679 --- Comment #1 from Dave Cottlehuber --- It's mentioned in both build(7) and ports(7), so this may be trickier to detangle than expected. -- You are receiving this mail because: You are the assignee for the bug.
