https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280028
cos changed:
What|Removed |Added
Status|Open|Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279
Bug ID: 282279
Summary: The rc(8) scripts 'netif' or 'routing' man pages
Product: Base System
Version: 14.1-RELEASE
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281218
--- Comment #18 from cyberponk ---
Same problem here and I have an external LTE modem so I will use it until the
problem is fixed. If you need any testing i´m available.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279
Mark Linimon changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #54 from Mark Millard ---
I've finally tested the RPi5 with video. I've installed official
builds of:
xorg-minimal-7.5.2_3 X.Org minimal distribution metaport
xf86-video-scfb-0.0.7_2X.Org syscons display drive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #8 from Mark Johnston ---
(In reply to Christos Margiolis from comment #7)
Those messages are the result of basically the same bug, but this time in
devmatch.
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #9 from Mark Johnston ---
https://reviews.freebsd.org/D47243
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #52 from Mark Millard ---
(In reply to Henrich Hartzer from comment #50)
Were Active, Inact, Laundry, Wired, and Free such that
Laundry was huge in each case (and the others were not)?
Did the lead up to the failures have Laund
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #50 from Henrich Hartzer ---
Thank you! That is interesting.
So the memory can be reclaimed if pushed out to swap, but I wonder if swap
would fill up fairly quickly.
Running with all of the patches I had some more OOM behavior
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #51 from Mark Millard ---
(In reply to Mark Millard from comment #49)
Hmm. Making explicit that unswappable is laundry would
be more like (adding "laundry" to each of the pair):
vm.domain.0.stats.unswappable: Unswappable laund
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #6 from Christos Margiolis ---
(In reply to Mark Johnston from comment #5)
Right, this makes since the panics would occur after recompiling the module I
work working on. I'm now compiling the kernel with the patch applied to tes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #53 from Mark Millard ---
(In reply to Henrich Hartzer from comment #50)
"failed to reclaim memory" is from multiple attempts
to increase the free RAM to not be below a target
threshold. There is a parameter for controlling the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #5 from Mark Johnston ---
(In reply to Christos Margiolis from comment #4)
Yes, one of the consequences of the UFS soft updates implementation is that
crashes can result in truncated files if those files had been written shortly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #10 from Christos Margiolis ---
The devmatch patch catches the truncated linker files fine. Now I do not get
any panic, but I do need to recompile the module in order to be able to load
it.
--
You are receiving this mail becau
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594
--- Comment #17 from Mark Johnston ---
(In reply to Andriy Gapon from comment #16)
Yes, I've observed this too when measuring TCP ping-pong latency over loopback
- latency is higher if the core was recently idle, I guess because autonomous
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #7 from Christos Margiolis ---
The crash is fixed, thanks. It turns that linker.hints was indeed getting
truncated (see below). Should these messages be concerning by any chance?
Loading kernel modules:
linker.hints file trunca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267
--- Comment #4 from Trond Endrestøl ---
To clarify, this was experienced yesterday on a VM running on Xen, XCP-ng
8.2.1. It might apply to any system, physical or virtual, exposing a serial
port.
--
You are receiving this mail because:
Yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #49 from Mark Millard ---
(In reply to commit-hook from comment #48)
Previous(/current) descriptions :
vm.domain.0.stats.laundpdpgs: Laundry pages scanned by the page daemon
vm.domain.0.stats.laundry: laundry pages
vm.domain.0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279
Alexander Ziaee changed:
What|Removed |Added
CC||zi...@runbox.com
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282281
Bug ID: 282281
Summary: zfs: panic: VERIFY(avl_is_empty(&sk->sk_dsl_keys))
failed
Product: Base System
Version: 15.0-CURRENT
Hardware: amd64
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282279
--- Comment #2 from Slawomir Wojciech Wojtczak ---
IMHO it does not have to be 'separate' man pages - it may be something like
'rc-roles' or rc-scripts' or 'rc-services' ... that would be probably good way
to start - and more and more servi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282269
Bug ID: 282269
Summary: /etc/rc.d/kld: print the kernel modules being loaded
Product: Base System
Version: Unspecified
Hardware: Any
OS: Any
Status: New
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282269
Mark Felder changed:
What|Removed |Added
Component|misc|conf
--
You are receiving this mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #47 from Mark Johnston ---
(In reply to Mark Millard from comment #46)
My wording wasn't very good. I was speculating about the contents of the
laundry queue on Henrich's system specifically. You're right that process exit
can
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846
--- Comment #48 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=6a07e67fb7a8b5687a492d9d70a10651d5933ff5
commit 6a07e67fb7a8b5687a492d9d70a10651d5933ff5
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #2 from Christos Margiolis ---
Not sure if this theory is correct, but I am noticing that the issue is more
frequent when the panic was caused by a manual call to panic(9), as opposed to,
say, a memory issue.
I sent you the dum
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243548
Eric Sproul changed:
What|Removed |Added
CC||e...@thesprouls.net
--- Comment #1 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
Bug ID: 282268
Summary: linker_load_module() panics with KASAN after
post-panic reboot
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
Mark Johnston changed:
What|Removed |Added
Status|New |Open
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
Christos Margiolis changed:
What|Removed |Added
Summary|linker_load_module() panics |linker_load_module() panics
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267
Bug ID: 282267
Summary: boot_multicons="NO", boot_serial="NO", and
console="efi" in /boot/loader.conf isn't respected by
the boot loader's menu
Product: Base System
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267
--- Comment #1 from Trond Endrestøl ---
Created attachment 254441
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254441&action=edit
The last six lines of /boot/loader.conf
--
You are receiving this mail because:
You are the ass
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267
--- Comment #2 from Trond Endrestøl ---
Created attachment 254442
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254442&action=edit
Excerpt from the show command, notice the values for boot_multicons,
boot_serial, and console
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282267
--- Comment #3 from Trond Endrestøl ---
Created attachment 254443
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=254443&action=edit
The boot loader's menu thinks I want a dual console with serial as the primary
--
You are recei
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282143
Mark Johnston changed:
What|Removed |Added
Resolution|--- |Works As Intended
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282271
Bug ID: 282271
Summary: praudit -n still resolves uids/gids
Product: Base System
Version: 14.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: A
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
Mark Linimon changed:
What|Removed |Added
Keywords||crash, loader
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256594
--- Comment #16 from Andriy Gapon ---
Just in case, I want to share an old discovery of mine:
https://forums.FreeBSD.org/threads/variable-ping-latency-on-ryzen-setup.82791/post-547552
The point is that not all "micro-stutter" can be attrib
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #3 from Mark Johnston ---
Are you using UFS? I bet your linker.hints is getting truncated during the
panic, which triggers a small bug in the kernel linker:
https://reviews.freebsd.org/D47240
--
You are receiving this mail be
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282268
--- Comment #4 from Christos Margiolis ---
(In reply to Mark Johnston from comment #3)
Yes, the VM is using UFS. Why is this a problem on UFS specifically, by the
way?
--
You are receiving this mail because:
You are the assignee for the b
40 matches
Mail list logo
