Re: May 2024 stabilization week

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

Re: May 2024 stabilization week

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

May 2024 stabilization week

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

Re: April 2024 stabilization week

nzfs 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. -- Gleb Smirnoff signature

Re: April 2024 stabilization week

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

Re: Strange network/socket anomalies since about a month

; 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

April 2024 stabilization week

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

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

[...] F> commit 841cf52595b6a6b98e266b63e54a7cf6fb6ca73e (HEAD -> main, origin/main, origin/HEAD) Is the crash same or different? Can you please share backtrace? -- Gleb Smirnoff

Re: Panic after update main-n269202-4e7aa03b7076 -> n269230-f6f67f58c19d

[ 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

Re: March 2024 stabilization week

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:

March 2024 stabilization week

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

Re: git: e34ea0196f44 - main - tcp: clear all TCP timers in tcp_timer_stop() when in callout

: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

February 2024 stabilization week

. The 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

FreeBSD CURRENT stabilization cycle

ruary 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

Re: e179d973 insta-panics in nl_send_one()

both installed. Sorry, that was my failure. Fix pushed and now working on a regression test that would cover Netlink group writers. -- Gleb Smirnoff

Re: kernel: fatal trap 12 on CURRENT, when using WireGuard

r: Sorry 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

Re: panic(s) in ZFS on CURRENT

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 <= 225142063104)

panic(s) in ZFS on CURRENT

bzero(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

Re: Is it valid to combine CTLFLAG_TUN with CTLFLAG_VNET ?

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

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

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

Re: trpt(8) to be decomissioned

s of TCPDEBUG without trpt. What does it provide that other logging facilities (BB, DTrace) doesn't? -- Gleb Smirnoff

Re: trpt(8) to be decomissioned

rchival" 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

trpt(8) to be decomissioned

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

Re: problem with bhyve, ryzen 5800x, freebsd guest

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

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

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>

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

y 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

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

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

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

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/netinet6

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

-( 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

Re: netinet & netpfil tests failing

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 approach are her

netinet & netpfil tests failing

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

Re: compressed TIME-WAIT to be decomissioned

. 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

Re: compressed TIME-WAIT to be decomissioned

0 times connection in TIME-WAIT responded with RST They show were the TIME-WAITs actually used. -- Gleb Smirnoff

compressed TIME-WAIT to be decomissioned

e 424+1064 bytes instead of 424+72. Multiply that by expected number of connections in TIME-WAIT on your machine. Comments welcome. -- Gleb Smirnoff

Re: My -CURRENT crashes....

_mtx() 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

Re: My -CURRENT crashes....

uct 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

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

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

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

anuel'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

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

ed 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

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

s 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

Re: Any Cronyx Tau* (ce(4) or cp(4)) users ?

ate 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

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

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

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

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

Re: smr inp breaks some jail use cases and panics with i915kms don't switch to the console anymore

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

Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

..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

Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

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://l

Re: bridge/igb panic: sleepq_add: td 0xfffffe01bbce5300 to sleep on wchan 0xffffffff8157d9a0 with sleeping prohibited

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'

Re: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793

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

Re: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793

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

Re: panic: Assertion in_epoch(net_epoch_preempt) failed, r357793

, 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 https://li

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

M> 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

Re: panic: Assertion in_epoch(net_epoch_preempt) failed at ... src/sys/net/if.c:3694

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"

Re: SVN r353868 breaks net/intel-em-kmod

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 mail

Re: sweeping change over all NIC drivers

> I 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

sweeping change over all NIC drivers

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@freebsd.org

Re: Kernel-Crash when working with ubt0, (Lizbeth Mutterhunt, Ph.D.)

ckdown adaX numbers to allow booting ? (Kurt Jaeger) M> > 15. Re: Lockdown adaX numbers to allow booting ? (O'Connor, Daniel) M> > M> > ___ M> > freebsd-current@freebsd.org mailing list M> > https://lists.freebsd.org/mailma

Re: at SVN r347375, terminating/restarting openvpn on tap causes panic

a, _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_ifaddrhead

Re: at SVN r347375, terminating/restarting openvpn on tap causes panic

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 belongs to par

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

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

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

ted 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-current-

Re: Relatively deterministic panic with sendfile(2) when running tests in the sxlock code

ee/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/listinfo/freebsd

Re: Since last week (today) current on my Ryzen box is unstable

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 KPI is &quo

Re: Since last week (today) current on my Ryzen box is unstable

g the code 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. My only

Re: Since last week (today) current on my Ryzen box is unstable

e 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"

Re: Panic on Boot - Current AMD64

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

Re: CURRENT: core dumped no process name

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"

Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

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

Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

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:

Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

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

Re: removing SVR4 binary compatibilty layer

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

removing SVR4 binary compatibilty layer

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

Re: HEAD [r313048] WITHOUT_INET6: tcpdump build failure

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

Re: HEAD [r313048] WITHOUT_INET6: tcpdump build failure

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.

Re: Log spam: Limiting * response from 1 to 200 packets/sec

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

Re: Log spam: Limiting * response from 1 to 200 packets/sec

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> >>

Re: Log spam: Limiting * response from 1 to 200 packets/sec

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>

Re: nvidia or Xorg broken on head

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

nvidia or Xorg broken on head

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

Re: callout_drain either broken or man page needs updating

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

Re: panic with tcp timers

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

Re: panic with tcp timers

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

Re: panic with tcp timers

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>

panic with tcp timers

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

Re: CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833)

standing problem that headers were not checked against socket buffer size. One could push unlimited data into sendfile() with headers. The patch also pushes also compat code under ifdef, so it is cut away if you aren't interested in COMPAT_FREEBSD4. On Wed, Mar 23, 2016 at 04:59:25PM -0700, Gleb

Re: CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833)

Vitalij, although the first patch should fixup the panic, can you please instead run this one. And if it is possible, can you please monitor this sysctl: sysctl kern.ipc.sf_long_headers -- Totus tuus, Glebius. Index: sys/kern/kern_descrip.c

Re: CURRENT r296381 panic in vn_sendfile (/usr/src/sys/kern/kern_sendfile.c:833)

Vitalij, can you please try with this patch? On Fri, Mar 04, 2016 at 02:40:54PM +0200, Vitalij Satanivskij wrote: V> Hello. V> V> I get kernel panic on high loaded server with messages V> V> savecore: reboot after panic: V>vn_sendfile: mlen 326 space -20 hdrlen 326 V> V> V> # kgdb

Re: panic: sbappendstream 1 [head/amd64 @r293419]

On Fri, Jan 08, 2016 at 09:34:23AM -0500, Jonathan T. Looney wrote: J> The likely suspect here looks like r293405, which changed uipc_send() to J> use sbappendstream_locked() instead of sbappend_locked(). J> J> However, I can't explain *why* that change is causing this problem without J> further

Re: panic: sbappendstream 1 [head/amd64 @r293419]

David, problem confirmed. Will either fix today, or revert the change by the end of the day. On Fri, Jan 08, 2016 at 06:05:18AM -0800, David Wolfskill wrote: D> After the first panic, I rebuilt the kernel without -DNO_CLEAN; the D> crash dump & other diagnostic info is from the clean build.

Re: kernel panic by enabling net.inet.ip.random_id

On Wed, Jan 06, 2016 at 01:24:53PM -0500, Shawn Webb wrote: S> That's what gets toggled via the sysctl. I think I figured out that I S> need to call ip_initid() in the SYSINIT. Compiling and testing now. Right, that's the problem. You actually want VNET_SYSINIT(). Please next time you report a

Re: r286727 breaks geom_md.ko loading

On Wed, Sep 16, 2015 at 08:10:05AM +0300, Konstantin Belousov wrote: K> > There is regression after r286727. Our dynamic kernel linker doesn't K> > support weak symbols, so the geom_md.ko can no longer be loaded dynamically K> > neither from loader nor at runtime. Having it statically in kernel

Re: r286727 breaks geom_md.ko loading

On Wed, Sep 16, 2015 at 04:42:49PM +0300, Konstantin Belousov wrote: K> On Wed, Sep 16, 2015 at 04:15:15PM +0300, Gleb Smirnoff wrote: K> > On Wed, Sep 16, 2015 at 08:10:05AM +0300, Konstantin Belousov wrote: K> > K> > There is regression after r286727. Our dynamic kernel

Re: r286727 breaks geom_md.ko loading

On Wed, Sep 16, 2015 at 04:57:39PM +0300, Konstantin Belousov wrote: K> On Wed, Sep 16, 2015 at 04:50:03PM +0300, Gleb Smirnoff wrote: K> > On Wed, Sep 16, 2015 at 04:42:49PM +0300, Konstantin Belousov wrote: K> > K> On Wed, Sep 16, 2015 at 04:15:15PM +0300, Gleb Smirnoff wrote

r286727 breaks geom_md.ko loading

Hi! There is regression after r286727. Our dynamic kernel linker doesn't support weak symbols, so the geom_md.ko can no longer be loaded dynamically neither from loader nor at runtime. Having it statically in kernel is the only working option. -- Totus tuus, Glebius.

Re: Upgrading to r297291 LAGG(4) stops working.

On Sun, Sep 06, 2015 at 11:05:41AM -0400, Daniel Eischen wrote: D> Please add an entry to src/UPDATING to explain the change needed. D> D> Also, my question remains, if wlan now knows how to set the MAC D> address, do we still need to set the MAC address manually and D> can we go back to using

Re: Upgrading to r297291 LAGG(4) stops working.

On Fri, Sep 04, 2015 at 04:39:22PM +0300, Sergey Kandaurov wrote: S> On 1 September 2015 at 04:47, John Baldwin wrote: S> > On Monday, August 31, 2015 09:58:45 AM Adrian Chadd wrote: S> >> Hi, S> >> S> >> +glebius, as he recently messed around with the wifi stack and his S> >>

Re: Upgrading to r297291 LAGG(4) stops working.

On Mon, Aug 31, 2015 at 09:58:45AM -0700, Adrian Chadd wrote: A> Hi, A> A> +glebius, as he recently messed around with the wifi stack and his A> changes may have broken how mac addresses are assigned to the A> hardware. I've tested that with new code setting MAC address on wlan0 passed it down

Re: r287197: wlan interfaces aren't brought up at boot or u

Idwer, can you please subscribe to this bug? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202784 And getting involved with debugging is much appreciated. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list

Re: r287197: wlan interfaces aren't brought up at boot or u

On Sat, Aug 29, 2015 at 01:19:40AM +0200, Idwer Vollering wrote: I Manually running 'service netif restart' works around this. I I /etc/network.subr and /etc/rc.d/netif have been updated by mergemaster I -p and mergemaster -iF I I I can provide the, rather lengthy, output of 'sh -x

Re: r287197: wlan interfaces aren't brought up at boot or u

On Sat, Aug 29, 2015 at 12:56:39PM +0300, Oleg V. Nauman wrote: O On Saturday 29 August 2015 11:02:02 Gleb Smirnoff wrote: O On Sat, Aug 29, 2015 at 01:19:40AM +0200, Idwer Vollering wrote: O I Manually running 'service netif restart' works around this. O I O I /etc/network.subr and /etc/rc.d

Re: [head up!] WiFi drivers changes

Good news, thanks! On Thu, Aug 27, 2015 at 06:45:14PM +0200, O. Hartmann wrote: O sory, sorry - I forgot on that specific machine (1 of 5) to mergemaster :-( So, after O mergemaster, the new rc scripts also got installed on the AP server and the interface is O again up and running! O O

  1   2   3   4   >