Re: Panic on kern_event.c
With this latest patch, after stressing syslog-ng few minutes, it do not
log anymore and a simple kill do not work (I have to do kill -9)
Le dim. 18 nov. 2018 à 01:35, Mark Johnston a écrit :
> On Fri, Nov 16, 2018 at 05:56:54PM +0100, Sylvain GALLIANO wrote:
> > Le ven. 16 nov. 2018 à 16:42, Mark Johnston a écrit
> :
> >
> > > On Fri, Nov 16, 2018 at 03:47:39PM +0100, Sylvain GALLIANO wrote:
> > > > Le jeu. 15 nov. 2018 à 23:10, Mark Johnston a
> écrit
> > > :
> > > >
> > > > > On Thu, Nov 08, 2018 at 05:05:03PM +0100, Sylvain GALLIANO wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I replaced
> > > > > > << printf("XXX knote %p already in tailq status:%x kq_count:%d
> [%p
> > > %p]
> > > > > >
> > > > >
> > >
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> > > > > > by
> > > > > > >> panic("XXX knote %p already in tailq status:%x kq_count:%d
> [%p
> > > %p]
> > > > > >
> > > > >
> > >
> %u\n",kn,kn->kn_status,kq->kq_count,kn->kn_tqe.tqe_next,kn->kn_tqe.tqe_prev,__LINE__);
> > > > > >
> > > > > > Here is the stack during panic:
> > > > > > panic: XXX knote 0xf801e1c6ddc0 already in tailq status:1
> > > kq_count:2
> > > > > > [0 0xf8000957a978] 2671
> > > > > >
> > > > > Could you please give the following patch a try?
> > > > >
> > > > > If possible, could you also ktrace one of the active syslog-ng
> > > processes
> > > > > for some time, perhaps 15 seconds, and share the kdump? I have
> been
> > > > > trying to reproduce the problem without any luck.
> > > > >
> > > > Unfortunately patched kernel is not stable:
> > > > - some processes run at 100% CPU (STOP state) and cannot be killed
> > > > - sometime the system completely freeze (need a hard reboot)
>
> Could you please give this updated a patch a try?
>
> diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
> index d9c670e29d60..f989d612bac4 100644
> --- a/sys/kern/kern_event.c
> +++ b/sys/kern/kern_event.c
> @@ -224,6 +224,7 @@ SYSCTL_UINT(_kern, OID_AUTO, kq_calloutmax, CTLFLAG_RW,
> #define KQ_LOCK(kq) do { \
> mtx_lock(&(kq)->kq_lock); \
> } while (0)
> +#defineKQ_LOCKPTR(kq) (&(kq)->kq_lock)
> #define KQ_FLUX_WAKEUP(kq) do {
> \
> if (((kq)->kq_state & KQ_FLUXWAIT) == KQ_FLUXWAIT) {\
> (kq)->kq_state &= ~KQ_FLUXWAIT; \
> @@ -687,8 +688,11 @@ filt_timerexpire(void *knx)
> struct kq_timer_cb_data *kc;
>
> kn = knx;
> + KQ_OWNED(kn->kn_kq);
> kn->kn_data++;
> - KNOTE_ACTIVATE(kn, 0); /* XXX - handle locking */
> +
> + if (!kn_in_flux(kn) || (kn->kn_status & KN_SCAN) != 0)
> + KNOTE_ACTIVATE(kn, 1);
>
> if ((kn->kn_flags & EV_ONESHOT) != 0)
> return;
> @@ -753,7 +757,7 @@ filt_timerattach(struct knote *kn)
> kn->kn_flags |= EV_CLEAR; /* automatically set */
> kn->kn_status &= ~KN_DETACHED; /* knlist_add clears it */
> kn->kn_ptr.p_v = kc = malloc(sizeof(*kc), M_KQUEUE, M_WAITOK);
> - callout_init(&kc->c, 1);
> + callout_init_mtx(&kc->c, KQ_LOCKPTR(kn->kn_kq), 0);
> filt_timerstart(kn, to);
>
> return (0);
> @@ -772,8 +776,10 @@ filt_timerstart(struct knote *kn, sbintime_t to)
> kc->next = to + sbinuptime();
> kc->to = to;
> }
> + KQ_LOCK(kn->kn_kq);
> callout_reset_sbt_on(&kc->c, kc->next, 0, filt_timerexpire, kn,
> PCPU_GET(cpuid), C_ABSOLUTE);
> + KQ_UNLOCK(kn->kn_kq);
> }
>
> static void
> @@ -826,7 +832,6 @@ filt_timertouch(struct knote *kn, struct kevent *kev,
> u_long type)
> KQ_LOCK(kq);
> if (kn->kn_status & KN_QUEUED)
> knote_dequeue(kn);
> -
> kn->kn_status &= ~KN_ACTIVE;
> kn->kn_data = 0;
> KQ_UNLOCK(kq);
> @@ -1843,12 +1848,13 @@ kqueue_scan(struct kqueue *kq, int maxevents,
> struct kevent_copyops *k_ops,
> }
>
> TAILQ_INSERT_TAIL(&kq->kq_head, marker, kn_tqe);
> + marker->kn_status |= KN_QUEUED;
> influx = 0;
> while (count) {
> KQ_OWNED(kq);
> kn = TAILQ_FIRST(&kq->kq_head);
>
> - if ((kn->kn_status == KN_MARKER && kn != marker) ||
> + if (((kn->kn_status & KN_MARKER) != 0 && kn != marker) ||
> kn_in_flux(kn)) {
> if (influx) {
> influx = 0;
> @@ -1861,24 +1867,21 @@ kqueue_scan(struct kqueue *kq, int maxevents,
> struct kevent_copyops *k_ops,
> }
>
> TAILQ_REMOVE(&kq->kq_head, kn, kn_tqe);
> - if ((kn->kn_status & KN_DISABLED) == KN_DISABLED) {
> - kn->kn_status &= ~KN_QUEUED;
> -
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kubilay Kocak changed: What|Removed |Added Component|kern|bin Flags|mfc-stable11? |mfc-stable11+ --- Comment #5 from Kubilay Kocak --- Thanks! For bonus linking points: base r335642 (current: 12.0) base r335863 (mfc: stable/11) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 208938] usr.sbin/config does not preserve whitespace in static env
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208938 Kubilay Kocak changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2333 ||14 -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
toolchain(s) for universe kernels
I want to make MAKE_JUST_KERNELS=1 universe but it seems that I need a toolchain first. There are multiple toolchain-ish make targets. If I start with an empty obj, which toolchain target(s) should I build? Eric ___ 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: toolchain(s) for universe kernels
I use:
make -sj${NCPU} tinderbox JFLAG=-j${NCPU}
UNIVERSE_TARGET=kernel-toolchain -DNO_CLEAN
Best,
Conrad
On Mon, Nov 19, 2018 at 10:00 AM Eric van Gyzen wrote:
>
> I want to
>
> make MAKE_JUST_KERNELS=1 universe
>
> but it seems that I need a toolchain first. There are multiple
> toolchain-ish make targets. If I start with an empty obj, which
> toolchain target(s) should I build?
>
> Eric
> ___
> 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"
___
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: toolchain(s) for universe kernels
On Mon, 2018-11-19 at 11:55 -0600, Eric van Gyzen wrote: > I want to > > make MAKE_JUST_KERNELS=1 universe > > but it seems that I need a toolchain first. There are multiple > toolchain-ish make targets. If I start with an empty obj, which > toolchain target(s) should I build? > > Eric Do "make kernel-toolchains" to build all the tools needed to build all universe kernels. You can also add "MAKE_LINT_KERNELS=1" to build just the lint kernels for all arches, but be aware that mips has no lint kernels. -- Ian ___ 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 commit: r339898 - head/lib/libc/amd64/sys
On 05/11/2018 21:51, Konstantin Belousov wrote: > For you, but not for me. > Turns out I omitted the fact that I have WITH_RETPOLINE enabled, which caused all this. emaste@ reported in PR 26 and committed r340650. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Devd / devmatch(8) -- netif race 12-RC1
Hello, Today I tried a simple wireless failover on a machine running free-bsd. After reboot the system cannot complete the initialization sequence OK with devmatcher. The devd/devmatch(8) combo correctly identified the wireless card and loaded required drivers and firmware. rcorder(8) reports that devd(8) runs after netif. As far as I gather, devd (8) runs devmatch(8) on nomatch class events. This results in the situation in which the interfaces are created before “plug and play” initialization of the wireless device is complete (no driver no firmware yet ) , wlan0 creation is impossible and so on and so forth. More so, I believe the runs of devmatch(8) are async in this scenario, so even if you moved devd(8) before netif service, this would not solve the issue, there will be race conditions. I know this can be solved by loading the drivers manually, but still rising some issue is in order: 1) Why does devd(8) service runs after netif ? I believe it should run before netif service, probably after kld service. Is there anything which prevents changing this order ? 2.) In the scenario in which devd(8) is started before netif, what can be done to ensure that a barier exists such that an arbitrary devmatch(8) run is guaranteed to finish loading required drivers before netif ? Ignore this if Im wrong about asyc nature of devmatch(8) run. 3 In what state is devmatcher now ? A lot of modules seems to be loaded ok, but some do not yet. coretemp(4) hwpmc(4) , intel serie 9 smbus driver seems not. ___ 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: Devd / devmatch(8) -- netif race 12-RC1
On Mon, Nov 19, 2018 at 7:48 PM Dan Partelly wrote: > Hello, > > Today I tried a simple wireless failover on a machine running free-bsd. > After reboot the system cannot complete the initialization sequence OK with > devmatcher. > The devd/devmatch(8) combo correctly identified the wireless card and > loaded required drivers and firmware. rcorder(8) reports that devd(8) runs > after netif. As far as I gather, devd (8) runs devmatch(8) on nomatch class > events. This results in the situation in which the interfaces are created > before “plug and play” initialization of the wireless device is complete > (no driver no firmware yet ) , wlan0 creation is impossible and so on and > so forth. > No, that's not what's happening. wlan0 isn't racing anything, because it's no longer listed in ifconfig. > More so, I believe the runs of devmatch(8) are async in this scenario, so > even if you moved devd(8) before netif service, this would not solve the > issue, there will be race conditions. I know this can be solved by loading > the drivers manually, but still rising some issue is in order: > Network configuration happens asynchronously. devmatch gets run in response to NOMATCH events which then causes the driver to load which then causes the pccard_ether script to run which causes the device to be configured. At least that's how it's supposed to work. > 1) Why does devd(8) service runs after netif ? I believe it should run > before netif service, probably after kld service. Is there anything which > prevents changing this order ? > Because it doesn't matter? And because if devd is run too eary, too few services are available. Getting the ordering right was... a somewhat tricky and frustrating experience when I first committed devd. > 2.) In the scenario in which devd(8) is started before netif, what can be > done to ensure that a barier exists such that an arbitrary devmatch(8) run > is guaranteed to finish loading required drivers before netif ? Ignore this > if Im wrong about asyc nature of devmatch(8) run. > Nothing. No such barrier is necessary. It should all happen asynchronously. Maybe there's a config problem? > 3 In what state is devmatcher now ? A lot of modules seems to be loaded > ok, but some do not yet. coretemp(4) hwpmc(4) , intel serie 9 smbus driver > seems not. > All of USB is done, part of PCI is done, all of the really old PC Card (since it was easy), parts of FDT for embedded and parts of ACPI are done. The drivers you've called out I think are PCI drivers that haven't been updated. They should all be in GENERIC, but none are in MINIMAL or perhaps a custom kernel. coretemp is a CPU device, and so I'm not sure we have the right PNP information for the CPU bus for it to even load. Warner ___ 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 kern_event.c
On Mon, Nov 19, 2018 at 10:26:51AM +0100, Sylvain GALLIANO wrote:
> With this latest patch, after stressing syslog-ng few minutes, it do not
> log anymore and a simple kill do not work (I have to do kill -9)
Thanks for your patience. I finally managed to reproduce the problem
and can see the bug now. Please try this patch instead.
diff --git a/sys/kern/kern_event.c b/sys/kern/kern_event.c
index d9c670e29d60..0be765a040ed 100644
--- a/sys/kern/kern_event.c
+++ b/sys/kern/kern_event.c
@@ -1538,6 +1538,10 @@ kqueue_register(struct kqueue *kq, struct kevent *kev,
struct thread *td, int wa
kn_enter_flux(kn);
error = knote_attach(kn, kq);
+ if ((kev->flags & EV_ENABLE) != 0)
+ kn->kn_status &= ~KN_DISABLED;
+ else if ((kev->flags & EV_DISABLE) != 0)
+ kn->kn_status |= KN_DISABLED;
KQ_UNLOCK(kq);
if (error != 0) {
tkn = kn;
@@ -1570,6 +1574,11 @@ kqueue_register(struct kqueue *kq, struct kevent *kev,
struct thread *td, int wa
KNOTE_ACTIVATE(kn, 1);
}
+ if ((kev->flags & EV_ENABLE) != 0)
+ kn->kn_status &= ~KN_DISABLED;
+ else if ((kev->flags & EV_DISABLE) != 0)
+ kn->kn_status |= KN_DISABLED;
+
/*
* The user may change some filter values after the initial EV_ADD,
* but doing so will not reset any filter which has already been
@@ -1595,11 +1604,9 @@ kqueue_register(struct kqueue *kq, struct kevent *kev,
struct thread *td, int wa
* kn_knlist.
*/
done_ev_add:
- if ((kev->flags & EV_ENABLE) != 0)
- kn->kn_status &= ~KN_DISABLED;
- else if ((kev->flags & EV_DISABLE) != 0)
- kn->kn_status |= KN_DISABLED;
-
+ /*
+* KN_DISABLED will be stable while the knote is in flux.
+*/
if ((kn->kn_status & KN_DISABLED) == 0)
event = kn->kn_fop->f_event(kn, 0);
else
@@ -1861,6 +1868,8 @@ kqueue_scan(struct kqueue *kq, int maxevents, struct
kevent_copyops *k_ops,
}
TAILQ_REMOVE(&kq->kq_head, kn, kn_tqe);
+ KASSERT(kn == marker || (kn->kn_status & KN_QUEUED) != 0,
+ ("knote %p not queued", kn));
if ((kn->kn_status & KN_DISABLED) == KN_DISABLED) {
kn->kn_status &= ~KN_QUEUED;
kq->kq_count--;
___
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"
