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
--- Comm
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273418
Eugene Grosbein changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In Prog
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
Author
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
Author
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 from
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 f
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 o
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
(cherr
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 bug
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 13:47:14
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://cgit.freebsd.org/src/commit/sys/net/if_tuntap.c?id=91ebcbe02a48ebd40edb49283b90f38d246da15
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
180KASSERT
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 a
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 b
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,
pathseg@entr
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 (howt
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: devfs_free:
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 conso
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 kern
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 cleanly
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 a/sys
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 d
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 se
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 receiving
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 asser
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 non-ass
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 September
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 etc.
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 th
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 t
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 0
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 assignee
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 there
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 /data/src/sys
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 fact
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 this
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
