https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Eugene Grosbein changed:
What|Removed |Added
See Also||https://bugs.freebsd.org/bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Peter Much changed:
What|Removed |Added
CC||p...@citylink.dinoex.sub.org
---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Eugene Grosbein changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #46 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=e900c81ede851f52ab50b541b9a6ef5fbc9bb919
commit e900c81ede851f52ab50b541b9a6ef5fbc9bb919
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #45 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=5230afce76a2de387cc162384ffef4cebf576e97
commit 5230afce76a2de387cc162384ffef4cebf576e97
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #44 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=27f1ec0be24b45559793e486a4fa5a2e7fdadc17
commit 27f1ec0be24b45559793e486a4fa5a2e7fdadc17
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Eugene Grosbein changed:
What|Removed |Added
Status|New |In Progress
--- Comment #43
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #42 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #40)
A week has passed running kernel with this your patch. So far, so good. No
panics.
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #41 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #40)
Thank you very much. I built new kernel with this patch to tuntap in addition
to previous one from comment #20. I will boot new kernel at the end
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #40 from Konstantin Belousov ---
commit 508e5f7d8d852b0f24cf0200d4486997d5d09409
Author: Konstantin Belousov
Date: Thu Sep 21 13:47:14 2023 +0300
tun/tap: correct ref count on cloned cdevs
PR: 273418
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #39 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #38)
Last chunk either lacks closing } with some code, or has extra opening {
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #38 from Konstantin Belousov ---
Or better, this one. Previous patch would leak refcount on non-cloned cdevs.
commit 0da5656dd70cd5a41c7fb3f4f1c5b8d7f72b9801
Author: Konstantin Belousov
Date: Thu Sep 21 13:47:14 2023 +0300
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #37 from Konstantin Belousov ---
devfs consumer is same. There was a trivial conflict. Below is the stable/13'
equivalent.
commit e84128814bcdc854c1670447ba1525711736d7f9
Author: Konstantin Belousov
Date: Thu Sep 21
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #36 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #35)
It is not, it lacks KPI change present in main:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #35 from Konstantin Belousov ---
(In reply to Eugene Grosbein from comment #34)
Code seems to be same.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #34 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #33)
Should I try it with stable/13?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #33 from Konstantin Belousov ---
Yes, this is the usual problem with dev_clone handlers.
commit f041428f9d8aea9fe5a33c5c91ac31074d652672
Author: Konstantin Belousov
Date: Thu Sep 21 13:47:14 2023 +0300
tun/tap: correct
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #32 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #31)
(kgdb) frame 5
#5 0x80a994d2 in devfs_free (cdev=0xf804490bf400)
at /data/src/sys/fs/devfs/devfs_devs.c:180
180
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #31 from Konstantin Belousov ---
(In reply to Eugene Grosbein from comment #29)
So print out cdp 0xf804490bf400
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #30 from Eugene Grosbein ---
/etc/newsyslog.conf contains a line:
/var/log/openvpn.log 640 30*@T00 J /var/run/openvpn.pid
So, newsyslogd sends SIGHUP to the openvpn daemon at midnight. Its logs before
panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #29 from Eugene Grosbein ---
(In reply to Eugene Grosbein from comment #26)
tun0 is open and active network interface used by site-to-site OpenVPN tunnel.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #28 from Eugene Grosbein ---
(kgdb) frame 21
#21 0x80d08c58 in kern_openat (td=0xfe0037918c80,
td@entry=, fd=-100,
fd@entry=,
path=0x2dbfc31974a0 ,
path@entry=,
pathseg=UIO_USERSPACE,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #27 from Eugene Grosbein ---
(kgdb) bt
#0 __curthread () at /data/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=textdump@entry=1) at
/data/src/sys/kern/kern_shutdown.c:396
#2 0x80c0dd43 in kern_reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #26 from Eugene Grosbein ---
Yesterday I applied the patch from the comment #20 and rebooted with new
kernel. And now I got another panic with one of new KASSERTs.
Unread portion of the kernel message buffer:
panic:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #25 from Eugene Grosbein ---
(In reply to Eugene Grosbein from comment #23)
Also, noted virtual machine had Uptime: 1d2h59m35s when I decided to power it
down with "shutdown -p now" and it printed devfs-related LOR to its
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #24 from Eugene Grosbein ---
(In reply to Jason A. Harmening from comment #20)
The patch applied cleanly to stable/13. However, panics are irregular. Current
uptime is over 7 days but it paniced more often earlier this month:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #23 from Eugene Grosbein ---
(In reply to Jason A. Harmening from comment #22)
Yesterday I grabbed 13.2-RELEASE/amd64 stock installation DVD image, created
bhyve virtual machine installing 13.2 from the image, built custom
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #22 from Jason A. Harmening ---
Will do. Testing on -current looks good so far, at least nothing blows up.
Eugene, can you apply the patch on your machine and see if the new asserts
catch the bad actor? It should apply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #21 from Konstantin Belousov ---
(In reply to Jason A. Harmening from comment #20)
Please go ahead.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #20 from Jason A. Harmening ---
Expanded version that spits out devnode names, adds CDP_ACTIVE to devfs_free()
assert, and asserts that we don't try to add a node to the freelist while still
on the active list:
diff --git
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #19 from Konstantin Belousov ---
Well, the new flag CDP_ON_ACTIVE_LIST mostly duplicates the CDP_ACTIVE.
Crucial part is assert that CDP_ACTIVE is not set when freeing. Adding
yet another flag would not hurt but it is purely
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #18 from Jason A. Harmening ---
Shouldn't the asserts in my proposed patch already accomplish what we need
here?
It may not be truly necessary to add a new flag solely tracking active list
membership (vs. CDP_ACTIVE), but it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #17 from Konstantin Belousov ---
In which way the current scheme is buggy?
Asserting at active list manipulations would not help, the problem seems
to be that cdp was freed without removing from the list.
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #16 from Mateusz Guzik ---
i am saying the current scheme is already buggy and needs to be reworked, but
before that happens it would best to find the current bug, if only to make sure
the rewrite does not just hide it
to that
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #15 from Konstantin Belousov ---
No, checking at list addition or removal is to late.
Problem is clearly that device is dereferenced while active, i.e. it sounds
as if somebody did dev_rel() manually.
So IMO the following
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #14 from Mateusz Guzik ---
every spot which modifies the list has to come with an assert on the flag being
appropriately set or unset, apart from the spot which does the actual free
i would even go as far as making it a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Jason A. Harmening changed:
What|Removed |Added
CC||j...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #12 from Eugene Grosbein ---
This AMD machine was source-upgraded from 12.4-STABLE/amd64 to
13.2-STABLE/amd64 on July 2 and since then it suffered a hang one or two times
a month: July 27, August 7, August 29 and today
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #11 from Eugene Grosbein ---
It seems I've got same panic today on different server running system built
from same sources but completely different hardware: AMD Athlon(tm) II X2 245
Processor vs. Intel(R) Xeon(R) CPU E5620
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #10 from Eugene Grosbein ---
It paniced again today generating another crashdump with same backtrace.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Mark Linimon changed:
What|Removed |Added
Keywords||regression
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #9 from Eugene Grosbein ---
I can upload compressed kernel.debug and crashdump, if needed. Smallest of
crashdumps is 5,4G in size, uncompressed. And 483M compressed with xz -9.
--
You are receiving this mail because:
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #8 from Eugene Grosbein ---
(In reply to Konstantin Belousov from comment #7)
> Do you have any third-party modules loaded?
No third-party, but lots of ones from base system:
Id Refs AddressSize Name
1 109
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #7 from Konstantin Belousov ---
Do you have any third-party modules loaded?
Are there any changes in src comparing to stock git?
Were there unmounts of devfs mounts?
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #6 from Eugene Grosbein ---
I'm not familiar with the code and locking schema. But I'm ready to test
patches :-) Could you provide some?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #5 from Mateusz Guzik ---
So cdp is backed by dev, but freeing dev is decoupled from unlinking it from
the global cdp list and it may be some of the frees happen when they should
not. There is very funky refcount scheme in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #4 from Eugene Grosbein ---
(In reply to Mateusz Guzik from comment #3)
cdp has lots of 0xdeadc0dedeadc0de :
(kgdb) frame 7
#7 devfs_populate_loop (dm=dm@entry=0xf8044020a000,
cleanup=cleanup@entry=0)
at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #3 from Mateusz Guzik ---
What exactly is freed here? Since this is in a multi-line if statement I would
not trust the line number.
As in can you print cdp itself and then cdp->cdp_dirent if the former is not
bogus? cdp in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Eugene Grosbein changed:
What|Removed |Added
CC||c...@freebsd.org,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Eugene Grosbein changed:
What|Removed |Added
Keywords||crash
--
You are receiving
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
--- Comment #1 from Eugene Grosbein ---
Unread portion of the kernel message buffer:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 14
instruction pointer = 0x20:0x80a9a1a1
stack pointer
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Bug ID: 273418
Summary: [panic] Repeating kernel panic on open(/dev/console)
Product: Base System
Version: 13.2-STABLE
Hardware: Any
OS: Any
Status: New
52 matches
Mail list logo
