Re: em(4) broken in HEAD?

[Chagin Dmitry]

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(>tq_active, , tb_link);
>   tb_first = TAILQ_FIRST(>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_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?

[K. Macy]

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(>tq_active, , tb_link);
 		tb_first = TAILQ_FIRST(>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_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?

[Joel Dahl]

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?

[K. Macy]

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?

[K. Macy]

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?

[Johan Hendriks]

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?

[Joel Dahl]

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?

[O. Hartmann]

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?

[Joel Dahl]

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"