https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #15 from shail...@google.com ---
(In reply to Konstantin Belousov from comment #14)
Unfortunately I have lost access to the VMs in this repro and will need to make
a fresh repro. I'll post the "show pcpu" for the new repro, hopef
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #14 from Konstantin Belousov ---
(In reply to shailend from comment #13)
What does 'show pcpu 11' show?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #13 from shail...@google.com ---
(In reply to Andrew Gallatin from comment #12)
Hmmm interesting. In this case though, I'm sure nothing is traversing the
networking stack, and no cpu is being consumed. The offending thread seems
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #12 from Andrew Gallatin ---
Comment on attachment 253834
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253834
procstat_kka
Are we absolutely certain that this is a deadlock and not a livelock? If you
look at netwo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #11 from shail...@google.com ---
Just a more succinct view of iperf thread 100719's central role in this
deadlock:
```
db> show lockchain 100413
thread 100413 (pid 0, gve0 rxq 0) is blocked on lock 0xfe00df57a3d0 (sleep
mute
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #10 from shail...@google.com ---
Superficially it looks like that the iperf thread 100719 was interrupted by an
ipi while it held the uma zone lock. It is the only iperf thread in the "run"
state, the rest are in "stop".
--
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276774
--- Comment #8 from Franco Fichtner ---
ISP server implementations appear to differ subtly even inside the protocol. We
can get a couple of reports per year about new weirdness during lease acquire
or renew. Personally, I've never had persi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276774
k...@denninger.net changed:
What|Removed |Added
CC||k...@denninger.net
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276774
Franco Fichtner changed:
What|Removed |Added
CC||fra...@opnsense.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #9 from shail...@google.com ---
(In reply to Mark Johnston from comment #7)
Also the trace for the uma zone lock holding iperf thread:
```
db> trace 100719
Tracing pid 857 tid 100719 td 0xf800b87ca000
sched_switch() at sche
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #8 from shail...@google.com ---
Created attachment 253834
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=253834&action=edit
procstat_kka
This is the output of procstat -kka, after the onset of a deadlock, with a
singl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276774
--- Comment #5 from Curtis Villamizar ---
(In reply to Zhenlei Huang from comment #4)
The problem did not go away if using dhcp6c, I just gave up on using dhcp6c.
I'm using dhcpcd with 14.1-STABLE built on 20240809 (uname -K == 1401502,
un
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281560
--- Comment #7 from Mark Johnston ---
(In reply to shailend from comment #6)
The memory utilization is low, so this is not a low memory deadlock.
We have an iperf thread which is holding a UMA zone lock and an inpcb lock, and
it looks like
13 matches
Mail list logo
