o avoid race conditions. But we can create a temporary
file in /var/db when we are nobody.
I'm going to change this line back to cat(1) in a week unless Dag-Erling
responds.
--
Gleb Smirnoff
On Mon, Sep 30, 2024 at 02:25:49PM -0400, Michael Butler wrote:
M> On 9/30/24 14:11, Gleb Smirnoff wrote:
M> > On Sat, Sep 28, 2024 at 11:10:57PM +0100, void wrote:
M> > v> I have found that *only* on arm64, locate errors like so:
M> > v>
M> > v> # sh /etc/perio
gt; Moving /var/db/locate.database aside makes no difference. The problem doesn't
v> happen on amd64 arch, same 6e414739fc95.
I also observe this and on amd64, so this is not arch specific.
Not sure this appeared in the latest stabilization cycle, could have been
introduced earlier.
Manual run of the periodic job doesn't reproduce the problem :(
--
Gleb Smirnoff
On Mon, Sep 23, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the September 2024
stabilization week
T> started with FreeBSD/main at main-n272449-6e414739fc95, which was tagged as
T> main-stabweek-2024-Sep.
The only issue discovered a
uring
the stabilization week, but focus on bugfixes instead. The stabilization week
runs up to Friday 18:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.
Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff
On Thu, Sep 05, 2024 at 12:53:52PM -0400, Alexander Motin wrote:
A> Hi Gleb,
A>
A> Could you check if this is relevant:
A> https://github.com/openzfs/zfs/pull/16505 ?
Yes! This is exactly the patch I am writing right now :)
I will cherry-pick that to FreeBSD/main.
--
Gleb Smirnoff
amd64_syscall() at amd64_syscall+0x65/frame 0xfe021a59cf30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe021a59cf30
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x3fa386c2a8fa, rsp =
0x3fa379d24b38, rbp = 0x3fa379d24ba0 ---
Uptime: 28s
--
Gleb Smirnoff
Hi,
On Mon, Aug 26, 2024 at 01:00:08AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the August 2024 stabilization
week
T> started with FreeBSD/main at main-n271832-04262ed78d23, which was tagged as
T> main-stabweek-2024-Aug.
I'm sorry to report bu
ilization week, but focus on bugfixes instead. The stabilization week
runs up to Friday 18:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.
Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff
M> sysctl_warn_reuse: can't re-use a leaf
(kstat.zfs.zroot.dataset.objset-0x204.zil_itx_metaslab_slog_alloc)!
This should fix it:
https://github.com/openzfs/zfs/pull/16448
--
Gleb Smirnoff
dialog
K>
K>
https://gitlab.com/alfix/bsddialog/-/commit/ce220b82ad546d3518a805750e5ee6add73f1fbf
btw, I'd suggest to switch to subtree merges for future bsddialog imports, so
that full commit history is preserved. I can help with that, if needed.
Can you please ack that POLA breakage will be noted in the Release Notes of
15.0 and won't be merged to 14.x?
--
Gleb Smirnoff
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the July 2024 stabilization
week
T> T> started with FreeBSD/main at main-n271321-9ae91f59c500, which
On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the July 2024 stabilization
week
T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged as
T> main-stabweek-2024-Jul.
Testing at Netflix didn'
8:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.
Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff
"doesn't help at all", or "your stupid idea prevents me from pushing
my commits". A longer email of course is even more appreciated. If you care,
please give me some feedback. Thanks all!
--
Gleb Smirnoff
signature.asc
Description: PGP signature
On Mon, Jun 24, 2024 at 01:00:05AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the June 2024 stabilization
week
T> started with FreeBSD/main at main-n270917-5dbf886104b4, which was tagged as
T> main-stabweek-2024-Jun.
The 5dbf886104b4 aka main-stabweek
8:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.
Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff
On Mon, May 27, 2024 at 09:24:14PM -0700, Gleb Smirnoff wrote:
T> On Mon, May 27, 2024 at 01:00:24AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the May 2024 stabilization
week
T> T> started with FreeBSD/main at main-n270422-cca0ce62f367, which w
On Mon, May 27, 2024 at 01:00:24AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the May 2024 stabilization week
T> started with FreeBSD/main at main-n270422-cca0ce62f367, which was tagged as
T> main-stabweek-2024-May.
Monday night status update:
- U
8:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.
Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff
tree=sys/contrib/openzfs
9f83eec03904b18e052fbe2c66542bd47254cf57
# git cherry-pick -x a8acc2bf5699556946dda2a37589d3c3bd9762c6
I'm planning to end the advisory freeze on the main branch Wednesday morning
at 8:00 UTC, unless somebody opposes that with a valid reason, e.g. a
regression that I missed.
--
Hi FreeBSD/main users & developers,
On Mon, Apr 22, 2024 at 01:00:50AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the April 2024 stabilization
week
T> started with FreeBSD/main at main-n269602-dd03eafacba9, which was tagged as
T> main-stabweek-20
easily than running the entire
A> poudriere in ktrace (e.g. a hint/script which dtrace probes to use)?
I don't have any better idea than ktrace over failing application. Yep, I
understand that poudriere will produce a lot. But first we need to determine
what syscall fails and on what type of socket. After that we can scope down to
using dtrace on very particular functions.
--
Gleb Smirnoff
8:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.
Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff
[...]
F> commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/main,
origin/HEAD)
Is the crash same or different? Can you please share backtrace?
--
Gleb Smirnoff
[ thread pid 1208 tid 101107 ]
D> Stopped at kdb_enter+0x33: movq$0,0x104eb92(%rip)
D> db>
This should be fixed by just pushed e205fd318a296ffdb7392486cdcec7f660fcffcf.
Sorry for that!
--
Gleb Smirnoff
Hi,
On Mon, Mar 25, 2024 at 01:00:07AM -0700, Gleb Smirnoff wrote:
T> This is an automated email to inform you that the March 2024 stabilization
week
T> started with FreeBSD/main at main-n268989-caccf6d3c008, which was tagged as
T> main-stabweek-2024-Mar.
A quick status update:
8:00 UTC, but if there is consensus that any regressions
discovered by participants have been fixed, it will end early.
Once that happens, the advisory freeze of FreeBSD/main branch is thawed.
--
Gleb Smirnoff
:10PM +, Gleb Smirnoff wrote:
T> The branch main has been updated by glebius:
T>
T> URL:
https://cgit.FreeBSD.org/src/commit/?id=e34ea0196f4497d3f3939025aff3a89ee77b652e
T>
T> commit e34ea0196f4497d3f3939025aff3a89ee77b652e
T> Author: Gleb Smirnoff
T> AuthorDate: 2024-0
branch is published at
https://github.com/glebius/FreeBSD/tree/stabweek-2024-Feb.
Otherwise I would recommend to use 7d233b2220cd3d23c028bdac7eb3b6b7b2025125 of
FreeBSD/main as a good point to update. We did not observe any large or risky
changes in main during the week.
--
Gleb Smirnoff
P.S. The February 2024 stabilization week was run internally, without sharing
publicly and in a few minutes I will post its results in a separate email.
--
Gleb Smirnoff
signature.asc
Description: PGP signature
both installed.
Sorry, that was my failure. Fix pushed and now working on
a regression test that would cover Netlink group writers.
--
Gleb Smirnoff
for that, my fault. Can you please test this patch?
--
Gleb Smirnoff
diff --git a/sys/netlink/netlink_domain.c b/sys/netlink/netlink_domain.c
index 7660dcada103..4790845d1d31 100644
--- a/sys/netlink/netlink_domain.c
+++ b/sys/netlink/netlink_domain.c
@@ -233,7 +233,7 @@ nl_send_group(struct nl_w
On Thu, Jun 08, 2023 at 07:56:07PM -0700, Gleb Smirnoff wrote:
T> I'm switching to INVARIANTS kernel right now and will see if that panics
earlier.
This is what I got with INVARIANTS:
panic: VERIFY3(dev->l2ad_hand <= dev->l2ad_evict) failed (225142071296 <=
2251420631
crip.c:3920
warning: Source file is more recent than executable.
3920bzero(pwd, sizeof(*pwd));
(kgdb) p pwd
$1 = (struct pwd *) 0xfff2fff0fff1ffed
(kgdb) p *pwd
Cannot access memory at address 0xfff2fff0fff1ffed
I'm switching to INVARIANTS kernel right now and will see if that panics
earlier.
--
Gleb Smirnoff
H> git blame sys/kern_sysctl.c
H>
H> I guess that for VNETs you'll have to keep on using TUNABLE_XXX_FETCH()
H> to get appropriate values into the sysctls . This discussion could also
H> continue on curr...@freebsd.org .
What if we remove the CTLFLAG_VNET check from the code you posted above?
I don't see anything going wrong, rather going right :)
CTLFLAG_VNET will not mask away CTLFLAG_TUN.
--
Gleb Smirnoff
(4)] adapters (others also possibly affected)
E> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264160
E> although it was submitted some time ago. I am not sure if it's a real
E> issue or not.
At this point I'm fine with removing the drivers.
--
Gleb Smirnoff
narios of TCPDEBUG without trpt. What does
it provide that other logging facilities (BB, DTrace) doesn't?
--
Gleb Smirnoff
archival" directory for programs phased out of
from base, especially ones that are almost four decades old.
M>
M> -Max
M>
M> Nov 3, 2022 11:04:07 PM Mike Karels :
M>
M> > On 3 Nov 2022, at 22:48, Gleb Smirnoff wrote:
M> >
M> >> Hi,
M> >>
M&g
black box logging and
siftr. These are the tools that modern developers use.
Already touched this topic with rscheff@, tuexen@, rrs@ and jtl@.
None of them new what trpt(8) is :) Looks like a good justification
to me.
--
Gleb Smirnoff
ng like this?
A>
A> Since it's the host that resets it would be hard to capture any traces.
I also run bhyve on Ryzen since late 2021 and never had such an issue.
But not FreeBSD 12, I run the head.
--
Gleb Smirnoff
On Sun, Apr 24, 2022 at 09:49:48AM +0200, Florian Smeets wrote:
F> On 23.04.22 01:38, Gleb Smirnoff wrote:
F> >Hi Florian,
F> >
F> > here is a patch that should help with the IPv6 problem. I'm not
F> > yet committing it, it might be not final.
F>
F> ye
cks for a host not equipped with any
firewall.
For a machine acting as a router better behavior is not to drop anything routed
through unless explicitly told so by a filtering policy.
--
Gleb Smirnoff
he route to each jail being on lo0 so .. probably :-)
This probably is somehow related to bridge. Can you please help me
providing minimal configuration of bridge/jails where the problem
shows up?
--
Gleb Smirnoff
Hi Florian,
here is a patch that should help with the IPv6 problem. I'm not
yet committing it, it might be not final.
--
Gleb Smirnoff
diff --git a/sys/netinet6/ip6_input.c b/sys/netinet6/ip6_input.c
index 3a13d2a9dc7..625de6d3657 100644
--- a/sys/netinet6/ip6_input.c
+++ b/sys/net
-(
I see your mails and will look into the problem ASAP.
Meanwhile...
Florian, can you please confirm you are using jails too?
Michael, can you please confirm or decline that you see the packets
that are dropped when you tcpdump on lo0?
--
Gleb Smirnoff
On Mon, Jan 17, 2022 at 06:07:43PM -0800, Gleb Smirnoff wrote:
T> * Reclaim the memory from pcb zone(s), when jail is destroyed, returning back
T> the old behaviour that with test suites 'jail -r' is always synchronous.
T> Some prerequisites for this approa
lone_destroy() would lookup vnet0 cloner
list
in case if interface is not found on the current vnet list.
To put it short, it is yet another problem created by if_vmove :( Not an easy
one
to fix and makes the third approach to the problem complicated.
To sum up: I'm sorry for tests broken, I'm working on it, it isn't easy problem.
Suggestions and help are welcome.
--
Gleb Smirnoff
MSL period. This is not covered by the above (and possibly not
M> relevant on the machine you where looking at).
Good point. We are not counting this kind of use.
--
Gleb Smirnoff
TIME-WAIT was actively recycled
0 times connection in TIME-WAIT responded with RST
They show were the TIME-WAITs actually used.
--
Gleb Smirnoff
24
After change a connection in TIME-WAIT would consume 424+1064 bytes instead
of 424+72. Multiply that by expected number of connections in TIME-WAIT on
your machine.
Comments welcome.
--
Gleb Smirnoff
() in do_fork() if we assume the
A> process has completed and the struct proc was reused. I guess if we
A> could somehow leak scheduled callout in exit1(). May be we could add
A> some more assertions to try catch callout still being active there.
Note that _callout_stop_safe(p_itcall
allows us to deduct that the callout belongs to proc subsystem and
we can retrieve the proc it points to: c_lock - 0x128 = 0xf8030521e548
It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its
p_itcallout.
So there is something that would zero out most of the p_itcallout while
it is scheduled?
--
Gleb Smirnoff
On Thu, Dec 16, 2021 at 07:53:10AM -0800, Gleb Smirnoff wrote:
T> P.S. If you really wish to deprecate something, I can suggest you to
T> sacrifice sbni(4) :)
P.P.S.
The driver actually provides a historical example: a driver removed,
later appeared not only used by somebody but even ha
enefit is zero.
I can't refute Emmanuel's statement, I can only speculate that benefit
could be non-zero, as apparently devices are still produced and E1 lines
still exist.
So I'm fine with removal if anybody demonstrates me a non-zero cost of
leaving the drivers in.
--
Gleb Smirnoff
u to revert it then, please? If you have time we can discuss
and work on the above described policy of built but not included into
default install devices/tools.
P.S. If you really wish to deprecate something, I can suggest you to
sacrifice sbni(4) :)
--
Gleb Smirnoff
ecationPlan
As you see, a developer who wants to remove something needs to propose
that, communicate that and plan. And as you can see there, Cronyx devices
were proposed properly by Ed. The ISA ones were deleted quickly. For the
PCI ones I communicated Cronyx and checked their status. Later the
drivers were made as minimal as possible, removing sppp(4). This is a
proper process. Not do a drive by commit and refuse to revert it.
--
Gleb Smirnoff
hey contain
obfuscated code.
Does sconfig create any problems for you? I'm fine with removing
the drivers and the tool if they do really create a burden for us.
That was case with their sppp(4) half, and I removed it in 6aae3517ed25.
If there is no maintainance burden, why remove them? Just to save
disk space?
--
Gleb Smirnoff
enabled,
hence
J> the out of the box kernel panics reliably. :)
J>
J> > So, do you suggest to push D33340 before finalizing D9?
J>
J> Yes, I think so.
Pushed. And I plan to post new version of D9 today.
--
Gleb Smirnoff
s probably better than always panicking as it does today.
AFAIK, today it will always panic only with WITNESS. Without WITNESS it would
pass through mtx_lock as long as the mutex is not locked.
So, do you suggest to push D33340 before finalizing D9?
--
Gleb Smirnoff
ove trying to diagnose
J> the hang as "sitting in ddb" initially, though I don't know if DDB itself
J> emits a beep for invalid commands, etc.)
Didn't know about this one. Is this isolated to actually entering DDB or
there is some path that in a normal inpcb lookup we would M_WAITOK?
--
Gleb Smirnoff
..21%..31%..41%..51%..61%..71%..81%..91%
x>
x> ___
x> freebsd-current@freebsd.org mailing list
x> https://lists.freebsd.org/mailman/listinfo/freebsd-current
x> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.o
b4aba, rsp =
x> 0x7fffe2b8, rbp = 0x7fffe360 ---
x> Uptime: 14s
x> Dumping 3794 out of 97961
x> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
x>
x> ___
x> freebsd-current@freebsd.org mailing list
x> https://list
On Fri, Sep 11, 2020 at 07:45:09PM +0300, xto...@mm.st wrote:
x> Gleb Smirnoff wrote:
x> >Hi,
x> >
x> > can you please try out this patch? This is configuration event
x> > and we should use sleepable lock to synchronize, not epoch.
x>
x> It didn't
On Wed, Feb 12, 2020 at 09:18:32AM -0800, Gleb Smirnoff wrote:
T> On Wed, Feb 12, 2020 at 07:41:54PM +0300, y...@mm.st wrote:
T> y> Gleb Smirnoff wrote:
T> y> > On Wed, Feb 12, 2020 at 09:49:12AM +0300, y...@mm.st wrote:
T> y> > y> Getting the following panic aft
On Wed, Feb 12, 2020 at 07:41:54PM +0300, y...@mm.st wrote:
y> Gleb Smirnoff wrote:
y> > On Wed, Feb 12, 2020 at 09:49:12AM +0300, y...@mm.st wrote:
y> > y> Getting the following panic after updating to r357793 (expect typos,
hand
y> > y> copied):
y> > y&g
, and Hans's patch covers _task_fn_tx(). However,
Hans's patch helped you. So, my guess is happen just due to
recompilation and reinstall of the module, not due to patch.
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
htt
M> My machine was panicked on r357061 with in_epoch in netisr.c.
M> I can not capture screen.
I believe this is fixed by r357088.
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freeb
211_vap_attach().
Or fix ath, which I'm going to do in next five minutes.
P.S. Answering your other email. Of course I did grep. Some things are
untrivial and sometimes sweeping over all collection of drivers doesn't
go smoothly.
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
the tree drivers? AFAIU, they
are maintained by the same team that maintains in-tree drivers. Cced them.
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any
assume these changes are only for FreeBSD-current now and have to be
tested and proven before committing to releng 12.
T>
T> But I am working on other things now on the computer and will not be able to
get to FreeBSD-current immediately.
These changes a
qlxge
qlxgbe
qlxgb
qlnx
ps3
otus
oce
nge
nfe
ndis
my
msk
mge
malo
llan
lio
lge
le
jme
hme
gem
fxp
fv
ffec
et
emac
em
dwc
dc
cxgbe
cxgb
cpsw
cgem
cas
bxe
bnxt
bge
bfe
bce
awg
atse
ath
ale
alc
al_eth
age
ae
--
Gleb Smirnoff
___
freebsd-current@freebs
reports (salvad...@freebsd.org)
M> > 14. Re: Lockdown adaX numbers to allow booting ? (Kurt Jaeger)
M> > 15. Re: Lockdown adaX numbers to allow booting ? (O'Connor, Daniel)
M> >
M> > ___
M> > freebsd-current@fre
P_TO_IA(ifp, ia, &in_ifa_tracker);
M> (kgdb) print imo
M> $1 = (struct ip_moptions *) 0xfe0072b14780
M> (kgdb) print ifp
M> $2 = (struct ifnet *) 0xf8000411
M> (kgdb) print ia
M> $3 =
...
This all looks good.
Can you please traverse the 'in_i
p detachment
K> from my previous patch, so that's fixed/committed anyways). CC'ing
K> Gleb for further triage as committer of r347375 that touched things in
K> this path.
Michael, can you please dump a core and look at it in kgdb? Line 362 in
ip_output() really belo
Enji,
can you please check that with this patch all your tests pass?
--
Gleb Smirnoff
Index: sys/kern/kern_sendfile.c
===
--- sys/kern/kern_sendfile.c (revision 339098)
+++ sys/kern/kern_sendfile.c (working copy)
@@ -526,6 +526,8
lated to sendfile but definitely
is related to my other changes. Will fix.
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-cur
sd/tree/sendfile_tests
Клонирование в «sendfile_tests»…
fatal: repository 'https://github.com/ngie-eign/freebsd/tree/sendfile_tests/'
not found
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/l
On Sun, Feb 18, 2018 at 10:15:24PM +0200, Andriy Gapon wrote:
A> On 18/02/2018 15:26, Gleb Smirnoff wrote:
A> > My only point is that it is a performance improvement. IMHO that's enough
:)
A>
A> I don't think that passing an invalid argument to a documented KP
to zfs_freebsd_getpages()?
A>
A> I cited two reasons above and expected to hear some counter-points rather
than
A> them being ignored :-)
A> If we settle upon allowing bogus_page to be used in ma[], then that will
A> obviously need to be documented.
d not verify that the requested pages are busied.
This is optimization that improves throughput when file memory cache is
fragmented. Why don't you like adding the code to zfs_freebsd_getpages()?
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
20
J> > boot
J> >
J> > When booting kernel.old, vm.boot_pages is 64.
J> >
J> > There is something wrong with r328916.
J>
J> Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the
J> issue here.
r328982 should fix the boot w
syslogd.core?
--
Gleb Smirnoff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Mon, Apr 03, 2017 at 03:39:56PM +, Darren wrote:
D> I have not experienced the crash after updating with Glebs patch. Consider
the issue solved.
I really don't want to put ACCEPT_LOCK() on to the sendfile() path.
However, once I commit my listening sockets rewrite patch, there
will be no
On Sat, Mar 25, 2017 at 11:45:29AM +0200, Konstantin Belousov wrote:
K> On Fri, Mar 24, 2017 at 08:31:42PM -0700, Gleb Smirnoff wrote:
K> > Darren,
K> >
K> > On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote:
K> > K> On Fri, Mar 24, 2017 at 05:
Darren,
On Sat, Mar 25, 2017 at 03:03:14AM +0200, Konstantin Belousov wrote:
K> On Fri, Mar 24, 2017 at 05:40:15PM +, Darren wrote:
K> > I am getting this panic every hour to every couple of hours.
K> >
K> > FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23
14:56:45 E
On Wed, Feb 15, 2017 at 10:56:29AM +0330, mokhi wrote:
m> Is this removing is because no-interest on maintaining it?
m>
m> If it helps, I am working to use the `kern_* instead sys_*` as
m> mentioned patch in that discussion suggests for svr4, if this helps.
Well, we all "maintain" it, meaning tha
Hello!
After some discussion on svn mailing list [1], there is intention
to remove SVR4 binary compatibilty layer from FreeBSD head, meaning
that FreeBSD 12.0-RELEASE, available in couple of years would
be shipped without it. There is no intention of merge of the removal.
The stable@ mailing l
Thanks for report, I will look at it.
On Thu, Feb 02, 2017 at 06:00:45AM +0300, Alex Deiter wrote:
A> Hello,
A>
A> Please take a look HEAD [r313048] - buildworld failed for IPv4-only system
(WITHOUT_INET6):
A>
A> cc -target x86_64-unknown-freebsd12.0
--sysroot=/export/freebsd/obj/export/free
On Thu, Feb 02, 2017 at 06:28:50AM +0300, Alex Deiter wrote:
A> Please review attached patch.
Thanks. It seems strange to me to reduce functionality of
tcpdump when a build doesn't support INET6. I still want
it able to parse packets I see on a network.
--
Totus tuus, Glebius.
__
On Wed, Dec 21, 2016 at 11:03:14AM +0100, Eivind Nicolay Evensen wrote:
E>
E> On Tue, Dec 13, 2016 at 09:48:59AM -0600, Eric van Gyzen wrote:
E> > On 12/13/2016 09:24, Michael Butler wrote:
E> > > Any hints as to why all of my -current equipment is complaining like
below. Is
E> > > there a sysctl
On Tue, Dec 13, 2016 at 11:07:19AM -0500, Michael Butler wrote:
M> >> Any hints as to why all of my -current equipment is complaining like
below. Is
M> >> there a sysctl to moderate/turn this off?
M> >>
M> >> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to
200
M> >> packe
On Tue, Dec 13, 2016 at 11:07:19AM -0500, Michael Butler wrote:
M> On 12/13/16 10:48, Eric van Gyzen wrote:
M> > On 12/13/2016 09:24, Michael Butler wrote:
M> >> Any hints as to why all of my -current equipment is complaining like
below. Is
M> >> there a sysctl to moderate/turn this off?
M> >>
M>
On Mon, Sep 12, 2016 at 06:14:35PM +0200, Guido Falsi wrote:
G> > Upgraded to yesterdays head (and packages) and
G> > now my X doesn't come up. Black screen with vt(4)'s
G> > cursor in left upper corner and with vt(4)'s mouse
G> > pointer. I'm able to switch to other console.
G> >
G> > Haven't y
Hi!
Upgraded to yesterdays head (and packages) and
now my X doesn't come up. Black screen with vt(4)'s
cursor in left upper corner and with vt(4)'s mouse
pointer. I'm able to switch to other console.
Haven't yet done any bisecting, just a heads up
for anyone encountering the same.
--
Totus
On Thu, Jul 14, 2016 at 10:14:46PM -0700, Matthew Macy wrote:
M> > On 07/15/16 05:45, Matthew Macy wrote:
M> > > glebius last commit needs some further re-work.
M> >
M> > Glebius commit needs to be backed out, at least the API change that
M> > changes the return value when calling callou
On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote:
H> On 06/20/16 11:58, Gleb Smirnoff wrote:
H> > The fix I am working on now is doing exactly that. callout_reset must
H> > return 0 if the callout is currently running.
H> >
H> > What are the old paths
On Mon, Jun 20, 2016 at 11:55:55AM +0200, Julien Charbon wrote:
J> > On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
J> > J> > Comparing stable/10 and head, I see two changes that could
J> > J> > affect that:
J> > J> >
J> > J> > - callout_async_drain
J> > J> > - switch to READ lock
Hi!
On Fri, Jun 17, 2016 at 11:27:39AM +0200, Julien Charbon wrote:
J> > Comparing stable/10 and head, I see two changes that could
J> > affect that:
J> >
J> > - callout_async_drain
J> > - switch to READ lock for inp info in tcp timers
J> >
J> > That's why you are in To, Julien and Hans :)
J>
Hi!
At Netflix we are observing a race in TCP timers with head.
The problem is a regression, that doesn't happen on stable/10.
The panic usually happens after several hours at 55 Gbit/s of
traffic.
What happens is that tcp_timer_keep finds t_tcpcb being
NULL. Some coredumps have tcpcb already
1 - 100 of 360 matches
Mail list logo
