Re: em(4) regression between r289975 and r300212

2016-05-23 Thread Benjamin VILLAIN 
Hi Anton,

I have the same behavior on my workstation. I just applied K. Macy's patch
and it seems to work for now.

Cheers,

--
Ben

On Mon, May 23, 2016 at 10:37 AM, Anton Shterenlikht 
wrote:

> This is an amd64 laptop, Dell Latitude 3340.
>
> I updated from:
> 11.0-CURRENT #1 r298975: Tue May  3 15:18:03 BST 2016
> /usr/obj/usr/src/sys/GENERIC  amd64
>
> to:
> 11.0-CURRENT #2 r300212: Fri May 20 09:50:53 BST 2016
> /usr/obj/usr/src/sys/GENERIC  amd64
>
> Now em(4) stops working 2-5 min after boot,
> or, perhaps, after 2-5 min of network traffic.
>
> The interface is shown as up:
>
> # ifconfig -a
> em0: flags=8843 metric 0 mtu 1500
>
> options=4019b
> ether 20:47:47:01:62:6e
> inet 10.70.14.139 netmask 0xff00 broadcast 10.70.14.255
> nd6 options=29
> media: Ethernet autoselect (1000baseT )
> status: active
>
> and there's nothing obvious in dmesg or /var/log/messages,
> but the network is not working at all, e.g. can't ping
> /etc/resolv.conf hosts.
>
> Is anybody else seeing this?
>
> Thanks
>
> Anton
> ___
> 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"
>
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);			\

Re: Using of Dragonfly Mail Agent -- what should be permissions on dma.conf and auth.conf?

2014-03-24 Thread Benjamin VILLAIN 
DMA should have a read access on both files, nothing more.

--
Ben


On Mon, Mar 24, 2014 at 1:16 PM, Mark Felder f...@freebsd.org wrote:

 On 2014-03-24 06:53, Lev Serebryakov wrote:

 Hello, Freebsd-current.

  I've tried 440 with owner 25:25 and mail l...@serebryakov.spb.ru
 complains, that it could not access them.

  Also, what is proper way to attach dma into system instead of senndmal
 now?



 I'm not sure what the permissions of those files should really be, but
 this is likely what you want in mailer.conf:

 sendmail/usr/libexec/dma
 send-mail   /usr/libexec/dma
 mailq   /usr/libexec/dma

 and rc.conf:

 sendmail_enable=NO
 sendmail_submit_enable=NO
 sendmail_outbound_enable=NO
 sendmail_msp_queue_enable=NO


 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Using of Dragonfly Mail Agent -- what should be permissions on dma.conf and auth.conf?

2014-03-24 Thread Benjamin VILLAIN 
Hi Lev,

You can set the owner of conf files to root:mail and give read access only
to the mail group.

Regards,
--
Ben


On Mon, Mar 24, 2014 at 2:32 PM, Lev Serebryakov l...@freebsd.org wrote:

 Hello, Benjamin.
 You wrote 24 марта 2014 г., 16:48:55:


 BV DMA should have a read access on both files, nothing more.
  Question is: from which user it will be run?

   Give /etc/dma/auth.conf world-read doesn't seen to be good idea!


 --
 // Black Lion AKA Lev Serebryakov l...@freebsd.org


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org