Re: Shutdown fails when there is an active kthread pinned to CPU core 0

On Wednesday, July 29, 2015 10:20:26 PM Michio Honda wrote: > Hi, > > When I create a kthread (kthread_add()) and pin it to CPU 0 (sched_bind() in > the beginning of its worker function), > shutdown (from the command line) is stuck on a message of "Waiting (max 60 > seconds) for system process

Re: [CFT] rewrite of the merge(1) utility

On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote: > Hi all, > > I was botherd to not have the merge(1) utility available in base (for > etcupdate) > when building base WITHOUT_RCS. > > So I have rewritten a merge(1) utility which should be compatible. > > I used the 3-way merge cod

Re: Memory modified after free, seemingly geli related

Ed Maste wrote this message on Wed, Aug 05, 2015 at 03:24 +: > I've encountered a few memory modified after free panics recently, > which seem to be from geli. I don't yet have any debugging to > completely confirm it's geli, but it has not happened on my other test > laptop which configured si

Re: pmspcv panic on boot on this box

> On Aug 4, 2015, at 6:13 PM, Glen Barber wrote: > > On Mon, Aug 03, 2015 at 12:10:57PM -0500, Larry Rosenman wrote: >> Just to close this out, current -HEAD is fine on this box with >> pmspcv in GENERIC, and using that as my base. No nasty pmspcv messages. >> > > Sorry for the delayed reply.

Memory modified after free, seemingly geli related

I've encountered a few memory modified after free panics recently, which seem to be from geli. I don't yet have any debugging to completely confirm it's geli, but it has not happened on my other test laptop which configured similarly but without geli. This has a few local patches from my to-commit

Jenkins build is back to normal : Build-UFS-image #2079

See ___ 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: pmspcv panic on boot on this box

On 2015-08-04 19:13, Glen Barber wrote: On Mon, Aug 03, 2015 at 12:10:57PM -0500, Larry Rosenman wrote: Just to close this out, current -HEAD is fine on this box with pmspcv in GENERIC, and using that as my base. No nasty pmspcv messages. Sorry for the delayed reply. Again, Larry, thank y

Re: pmspcv panic on boot on this box

On Mon, Aug 03, 2015 at 12:10:57PM -0500, Larry Rosenman wrote: > Just to close this out, current -HEAD is fine on this box with > pmspcv in GENERIC, and using that as my base. No nasty pmspcv messages. > Sorry for the delayed reply. Again, Larry, thank you for your help with this - you very l

Re: How should a driver shutdown a taskqueue on detach?

On Wednesday, July 01, 2015 04:25:10 PM John-Mark Gurney wrote: > Ryan Stone wrote this message on Wed, Jul 01, 2015 at 15:44 -0400: > > I'm trying to figure out how a driver is supposed to shut down its > > interrupt-handling taskqueue when it detaches. taskqueue(9) recommends > > disabling inter

Re: unp gc vs socket close/shutdown race

On Sunday, July 12, 2015 10:51:57 AM Conrad Meyer wrote: > Hi all, > > (Sorry In-Reply-To is wrong; gmail isn't the most flexible MUA and I > was not subscribed to FreeBSD-Current until today.) > > I have a slightly cleaned up version of this patch in phabricator at > https://reviews.freebsd.org/

Re: proper way to terminate a kthread when the parent process dies ?

On Tue, Aug 04, 2015 at 06:27:46PM +0200, Luigi Rizzo wrote: > Specifically, our two threads implement the host part of a virtualized network > interface and operate in a way that is very similar to an interrupt handler, > or vhost-net in KVM. In principle, the user process that issues > the system

Re: proper way to terminate a kthread when the parent process dies ?

On Tue, Aug 4, 2015 at 6:02 PM, Konstantin Belousov wrote: > On Tue, Aug 04, 2015 at 05:32:28PM +0200, Luigi Rizzo wrote: >> On Tue, Aug 4, 2015 at 4:53 PM, Konstantin Belousov >> wrote: >> > If this is a thread of the normal user process, then it is not a kernel >> > thread, even if it never le

Re: proper way to terminate a kthread when the parent process dies ?

On Tue, Aug 04, 2015 at 05:32:28PM +0200, Luigi Rizzo wrote: > On Tue, Aug 4, 2015 at 4:53 PM, Konstantin Belousov > wrote: > > If this is a thread of the normal user process, then it is not a kernel > > thread, even if it never leaves the kernel mode. > > thanks for the answer. > > i do not re

Re: proper way to terminate a kthread when the parent process dies ?

On Tue, Aug 4, 2015 at 4:53 PM, Konstantin Belousov wrote: > On Tue, Aug 04, 2015 at 04:38:14PM +0200, Luigi Rizzo wrote: >> Hi, >> we have a doubt on the proper way to terminate a kernel thread that >> has been associated to a user process U within a system call with >> >> kthread_add( ..

Re: IPSEC stop works after r285336

Two things you might do to help. The first is just send out a list of what you are testing so we know. The second is to contribute configs and the like to the netperf repo https://github.com/gvnn3/netperf We take pull requests :-) Best, George On 3 Aug 2015, at 23:20, Sydney Meyer wrote: Be

Re: proper way to terminate a kthread when the parent process dies ?

On Tue, Aug 04, 2015 at 04:38:14PM +0200, Luigi Rizzo wrote: > Hi, > we have a doubt on the proper way to terminate a kernel thread that > has been associated to a user process U within a system call with > > kthread_add( .. , .., p, ... ) > > (p is the struct proc * of the calling proces

proper way to terminate a kthread when the parent process dies ?

Hi, we have a doubt on the proper way to terminate a kernel thread that has been associated to a user process U within a system call with kthread_add( .. , .., p, ... ) (p is the struct proc * of the calling process, U) When U terminates and goes into kern_exit.c :: exit1() the kernel th

Re: Appending to message buffer while in ddb

On 08/03/2015 03:21 PM, Marcel Moolenaar wrote: On Aug 3, 2015, at 12:59 PM, Eric Badger wrote: Hi there, Since r226435, output from kernel printf/log functions is not appended to the message buffer when in ddb. The commit message doesn't call this out specifically; instead it appears to ha

FreeBSD_HEAD_i386 - Build #757 - Fixed

FreeBSD_HEAD_i386 - Build #757 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/757/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/757/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/757/console Change summaries: No chan