Re: em(4) broken in HEAD?
On Sat, May 21, 2016 at 02:00:09AM -0700, K. Macy wrote: > Much to my chagrin, this too is my fault. Please apply the attached > patch if it hasn't yet been committed to -CURRENT. > thanks, it fixes em for me. > On Fri, May 20, 2016 at 11:28 PM, Joel Dahl wrote: > > On Fri, May 20, 2016 at 07:32:30PM -0700, K. Macy wrote: > >> I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two. > >> > >> > > >> > > >> > I don't use ipfw, aliases or anything other than stock networking. I > >> > was unable to copy a large image off the VM without getting an > >> > unending stream of watchdog resets which could only be fixed by a > >> > reboot. Fortunately a subsequent IFC fixed it as of ~15 hours ago. > >> > > >> > >> I take that back. It's still happening. > > > > OK - good to know. I'm going to be travelling for a few days so I won't have > > time to do a binary search to find the commit that broke it. > > > > -- > > Joel > diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c > index 2ef5a3c..00cb46f 100644 > --- a/sys/kern/subr_taskqueue.c > +++ b/sys/kern/subr_taskqueue.c > @@ -68,7 +68,6 @@ struct taskqueue { > TAILQ_HEAD(, taskqueue_busy) tq_active; > struct mtx tq_mutex; > struct thread **tq_threads; > - struct thread *tq_curthread; > int tq_tcount; > int tq_spin; > int tq_flags; > @@ -222,7 +221,7 @@ taskqueue_enqueue_locked(struct taskqueue *queue, struct > task *task) >* Count multiple enqueues. >*/ > if (task->ta_pending) { > - if (task->ta_pending < UCHAR_MAX) > + if (task->ta_pending < USHRT_MAX) > task->ta_pending++; > TQ_UNLOCK(queue); > return (0); > @@ -465,8 +464,7 @@ taskqueue_run_locked(struct taskqueue *queue) > > TQ_LOCK(queue); > tb.tb_running = NULL; > - if ((task->ta_flags & TASK_SKIP_WAKEUP) == 0) > - wakeup(task); > + wakeup(task); > > TAILQ_REMOVE(&queue->tq_active, &tb, tb_link); > tb_first = TAILQ_FIRST(&queue->tq_active); > @@ -481,9 +479,7 @@ taskqueue_run(struct taskqueue *queue) > { > > TQ_LOCK(queue); > - queue->tq_curthread = curthread; > taskqueue_run_locked(queue); > - queue->tq_curthread = NULL; > TQ_UNLOCK(queue); > } > > @@ -716,7 +712,6 @@ taskqueue_thread_loop(void *arg) > tq = *tqp; > taskqueue_run_callback(tq, TASKQUEUE_CALLBACK_TYPE_INIT); > TQ_LOCK(tq); > - tq->tq_curthread = curthread; > while ((tq->tq_flags & TQ_FLAGS_ACTIVE) != 0) { > /* XXX ? */ > taskqueue_run_locked(tq); > @@ -730,7 +725,6 @@ taskqueue_thread_loop(void *arg) > TQ_SLEEP(tq, tq, &tq->tq_mutex, 0, "-", 0); > } > taskqueue_run_locked(tq); > - tq->tq_curthread = NULL; > /* >* This thread is on its way out, so just drop the lock temporarily >* in order to call the shutdown callback. This allows the callback > @@ -754,8 +748,7 @@ taskqueue_thread_enqueue(void *context) > > tqp = context; > tq = *tqp; > - if (tq->tq_curthread != curthread) > - wakeup_one(tq); > + wakeup_one(tq); > } > > TASKQUEUE_DEFINE(swi, taskqueue_swi_enqueue, NULL, > diff --git a/sys/sys/_task.h b/sys/sys/_task.h > index 4cfa171..ce89781 100644 > --- a/sys/sys/_task.h > +++ b/sys/sys/_task.h > @@ -45,8 +45,7 @@ typedef void task_fn_t(void *context, int pending); > > struct task { > STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ > - uint8_t ta_pending; /* (q) count times queued */ > - uint8_t ta_flags; /* (q) flags */ > + uint16_t ta_pending;/* (q) count times queued */ > u_short ta_priority;/* (c) Priority */ > task_fn_t *ta_func; /* (c) task handler */ > void*ta_context;/* (c) argument for handler */ > diff --git a/sys/sys/taskqueue.h b/sys/sys/taskqueue.h > index bc01088..4c4044f 100644 > --- a/sys/sys/taskqueue.h > +++ b/sys/sys/taskqueue.h > @@ -98,7 +98,6 @@ voidtaskqueue_set_callback(struct taskqueue *queue, > > #define TASK_INITIALIZER(priority, func, context)\ > { .ta_pending = 0, \ > - .ta_flags = 0,\ > .ta_priority = (priority),\ > .ta_func = (func),\ > .ta_context = (context) } > @@ -114,7 +113,6 @@ void taskqueue_thread_enqueue(void *context); > */ > #define TASK_INIT(task, priority, func, context) do {\ > (task)->ta_pending = 0; \ > - (task)->ta_flags = 0; \ > (task)->ta_priority = (priority); \ >
Re: em(4) broken in HEAD?
Much to my chagrin, this too is my fault. Please apply the attached patch if it hasn't yet been committed to -CURRENT. On Fri, May 20, 2016 at 11:28 PM, Joel Dahl wrote: > On Fri, May 20, 2016 at 07:32:30PM -0700, K. Macy wrote: >> I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two. >> >> > >> > >> > I don't use ipfw, aliases or anything other than stock networking. I >> > was unable to copy a large image off the VM without getting an >> > unending stream of watchdog resets which could only be fixed by a >> > reboot. Fortunately a subsequent IFC fixed it as of ~15 hours ago. >> > >> >> I take that back. It's still happening. > > OK - good to know. I'm going to be travelling for a few days so I won't have > time to do a binary search to find the commit that broke it. > > -- > Joel diff --git a/sys/kern/subr_taskqueue.c b/sys/kern/subr_taskqueue.c index 2ef5a3c..00cb46f 100644 --- a/sys/kern/subr_taskqueue.c +++ b/sys/kern/subr_taskqueue.c @@ -68,7 +68,6 @@ struct taskqueue { TAILQ_HEAD(, taskqueue_busy) tq_active; struct mtx tq_mutex; struct thread **tq_threads; - struct thread *tq_curthread; int tq_tcount; int tq_spin; int tq_flags; @@ -222,7 +221,7 @@ taskqueue_enqueue_locked(struct taskqueue *queue, struct task *task) * Count multiple enqueues. */ if (task->ta_pending) { - if (task->ta_pending < UCHAR_MAX) + if (task->ta_pending < USHRT_MAX) task->ta_pending++; TQ_UNLOCK(queue); return (0); @@ -465,8 +464,7 @@ taskqueue_run_locked(struct taskqueue *queue) TQ_LOCK(queue); tb.tb_running = NULL; - if ((task->ta_flags & TASK_SKIP_WAKEUP) == 0) - wakeup(task); + wakeup(task); TAILQ_REMOVE(&queue->tq_active, &tb, tb_link); tb_first = TAILQ_FIRST(&queue->tq_active); @@ -481,9 +479,7 @@ taskqueue_run(struct taskqueue *queue) { TQ_LOCK(queue); - queue->tq_curthread = curthread; taskqueue_run_locked(queue); - queue->tq_curthread = NULL; TQ_UNLOCK(queue); } @@ -716,7 +712,6 @@ taskqueue_thread_loop(void *arg) tq = *tqp; taskqueue_run_callback(tq, TASKQUEUE_CALLBACK_TYPE_INIT); TQ_LOCK(tq); - tq->tq_curthread = curthread; while ((tq->tq_flags & TQ_FLAGS_ACTIVE) != 0) { /* XXX ? */ taskqueue_run_locked(tq); @@ -730,7 +725,6 @@ taskqueue_thread_loop(void *arg) TQ_SLEEP(tq, tq, &tq->tq_mutex, 0, "-", 0); } taskqueue_run_locked(tq); - tq->tq_curthread = NULL; /* * This thread is on its way out, so just drop the lock temporarily * in order to call the shutdown callback. This allows the callback @@ -754,8 +748,7 @@ taskqueue_thread_enqueue(void *context) tqp = context; tq = *tqp; - if (tq->tq_curthread != curthread) - wakeup_one(tq); + wakeup_one(tq); } TASKQUEUE_DEFINE(swi, taskqueue_swi_enqueue, NULL, diff --git a/sys/sys/_task.h b/sys/sys/_task.h index 4cfa171..ce89781 100644 --- a/sys/sys/_task.h +++ b/sys/sys/_task.h @@ -45,8 +45,7 @@ typedef void task_fn_t(void *context, int pending); struct task { STAILQ_ENTRY(task) ta_link; /* (q) link for queue */ - uint8_t ta_pending; /* (q) count times queued */ - uint8_t ta_flags; /* (q) flags */ + uint16_t ta_pending; /* (q) count times queued */ u_short ta_priority; /* (c) Priority */ task_fn_t *ta_func; /* (c) task handler */ void *ta_context; /* (c) argument for handler */ diff --git a/sys/sys/taskqueue.h b/sys/sys/taskqueue.h index bc01088..4c4044f 100644 --- a/sys/sys/taskqueue.h +++ b/sys/sys/taskqueue.h @@ -98,7 +98,6 @@ void taskqueue_set_callback(struct taskqueue *queue, #define TASK_INITIALIZER(priority, func, context) \ { .ta_pending = 0,\ - .ta_flags = 0,\ .ta_priority = (priority), \ .ta_func = (func),\ .ta_context = (context) } @@ -114,7 +113,6 @@ void taskqueue_thread_enqueue(void *context); */ #define TASK_INIT(task, priority, func, context) do { \ (task)->ta_pending = 0;\ - (task)->ta_flags = 0;\ (task)->ta_priority = (priority); \ (task)->ta_func = (func); \ (task)->ta_context = (context); \ @@ -224,7 +222,6 @@ int taskqgroup_adjust(struct taskqgroup *qgroup, int cnt, int stride); #define GTASK_INIT(task, priority, func, context) do { \ (task)->ta_pending = 0;\ - (task)->ta_flags = TASK_SKIP_WAKEUP; \ (task)->ta_priority = (priority); \ (task)->ta_func = (func); \ (task)->ta_context = (context); \ ___ 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: em(4) broken in HEAD?
On Fri, May 20, 2016 at 07:32:30PM -0700, K. Macy wrote: > I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two. > > > > > > > I don't use ipfw, aliases or anything other than stock networking. I > > was unable to copy a large image off the VM without getting an > > unending stream of watchdog resets which could only be fixed by a > > reboot. Fortunately a subsequent IFC fixed it as of ~15 hours ago. > > > > I take that back. It's still happening. OK - good to know. I'm going to be travelling for a few days so I won't have time to do a binary search to find the commit that broke it. -- Joel ___ 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: em(4) broken in HEAD?
I'm seeing watchdog resets on em(4) in my VMWare as of the last day or two. > > > I don't use ipfw, aliases or anything other than stock networking. I > was unable to copy a large image off the VM without getting an > unending stream of watchdog resets which could only be fixed by a > reboot. Fortunately a subsequent IFC fixed it as of ~15 hours ago. > I take that back. It's still happening. That's too bad I had been hoping to announce the Skylake i915 CFT tonight. -M ___ 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: em(4) broken in HEAD?
On Fri, May 20, 2016 at 11:33 AM, Johan Hendriks wrote: > H > > Op vrijdag 20 mei 2016 heeft Joel Dahl het volgende > geschreven: > >> On Fri, May 20, 2016 at 01:59:46PM +0200, O. Hartmann wrote: >> > On Fri, 20 May 2016 13:55:50 +0200 >> > Joel Dahl > wrote: >> > >> > > Hi, >> > > >> > > I've just rebuilt CURRENT on a VMware virtual machine and it's now >> > > running r300276. After reboot, I ssh'ed to the machine but my ssh >> > > session hanged after ~10 seconds or so. The console started spitting >> > > out "em0: Watchdog timeout - resetting" messages at the same time. >> > > Basically no networking works. >> > > >> > > It's the same thing after every reboot. Networking works for a few >> > > seconds, just long enough for you to run a couple of commands over >> > > ssh. Then it breaks. >> > > >> > > My previous build on this machine was from about one week ago. It >> > > works like it should. >> > > >> > >> > Do you use by any means IPFW ? >> >> Nope. >> I don't use ipfw, aliases or anything other than stock networking. I was unable to copy a large image off the VM without getting an unending stream of watchdog resets which could only be fixed by a reboot. Fortunately a subsequent IFC fixed it as of ~15 hours ago. -M ___ 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: em(4) broken in HEAD?
H Op vrijdag 20 mei 2016 heeft Joel Dahl het volgende geschreven: > On Fri, May 20, 2016 at 01:59:46PM +0200, O. Hartmann wrote: > > On Fri, 20 May 2016 13:55:50 +0200 > > Joel Dahl > wrote: > > > > > Hi, > > > > > > I've just rebuilt CURRENT on a VMware virtual machine and it's now > > > running r300276. After reboot, I ssh'ed to the machine but my ssh > > > session hanged after ~10 seconds or so. The console started spitting > > > out "em0: Watchdog timeout - resetting" messages at the same time. > > > Basically no networking works. > > > > > > It's the same thing after every reboot. Networking works for a few > > > seconds, just long enough for you to run a couple of commands over > > > ssh. Then it breaks. > > > > > > My previous build on this machine was from about one week ago. It > > > works like it should. > > > > > > > Do you use by any means IPFW ? > > Nope. > > -- > Joel > ___ > 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 > " > Do you have alias ipadresses on the interface. That is what I have and that is broken. If i disable alias ipadresses, all is fine again. Btw in my case it is on alc0 as i do not have an em interface to test. ___ 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: em(4) broken in HEAD?
On Fri, May 20, 2016 at 01:59:46PM +0200, O. Hartmann wrote: > On Fri, 20 May 2016 13:55:50 +0200 > Joel Dahl wrote: > > > Hi, > > > > I've just rebuilt CURRENT on a VMware virtual machine and it's now > > running r300276. After reboot, I ssh'ed to the machine but my ssh > > session hanged after ~10 seconds or so. The console started spitting > > out "em0: Watchdog timeout - resetting" messages at the same time. > > Basically no networking works. > > > > It's the same thing after every reboot. Networking works for a few > > seconds, just long enough for you to run a couple of commands over > > ssh. Then it breaks. > > > > My previous build on this machine was from about one week ago. It > > works like it should. > > > > Do you use by any means IPFW ? Nope. -- Joel ___ 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: em(4) broken in HEAD?
On Fri, 20 May 2016 13:55:50 +0200 Joel Dahl wrote: > Hi, > > I've just rebuilt CURRENT on a VMware virtual machine and it's now > running r300276. After reboot, I ssh'ed to the machine but my ssh > session hanged after ~10 seconds or so. The console started spitting > out "em0: Watchdog timeout - resetting" messages at the same time. > Basically no networking works. > > It's the same thing after every reboot. Networking works for a few > seconds, just long enough for you to run a couple of commands over > ssh. Then it breaks. > > My previous build on this machine was from about one week ago. It > works like it should. > Do you use by any means IPFW ? Regards, Oliver ___ 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"
em(4) broken in HEAD?
Hi, I've just rebuilt CURRENT on a VMware virtual machine and it's now running r300276. After reboot, I ssh'ed to the machine but my ssh session hanged after ~10 seconds or so. The console started spitting out "em0: Watchdog timeout - resetting" messages at the same time. Basically no networking works. It's the same thing after every reboot. Networking works for a few seconds, just long enough for you to run a couple of commands over ssh. Then it breaks. My previous build on this machine was from about one week ago. It works like it should. -- Joel ___ 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"