> We had a brief discussion of this commit within a subset of core. This
> addition of GPLv2 code is fine as the code is easily removal to a module
> (per kmoore@) should the day come that we're read to evict all GPL code.
I don't execute the ctors until coverage is enabled because I have to
Yes. Good catch. Thanks.
-M
>
> Missing Approved by: sbruno?
>
>
>> Modified:
>> head/sys/kern/kern_descrip.c
>>
>> Modified: head/sys/kern/kern_descrip.c
>> ==
>> --- head/sys/kern/kern_descrip.c Fri May 4
Can you give any context on what they're doing? In addition - even on
a production kernel it's possible to compile in DDB to at least get a
backtrace. Your report only gives us enough information to know that
there is _an_ issue. It's difficult to proceed on this alone. I do
have a report from the
There was a panic inducing merge error, please apply if you encounter problems:
@ -2288,7 +2294,7 @@ iflib_stop(if_ctx_t ctx)
for (i = 0; i < scctx->isc_nrxqsets; i++, rxq++) {
/* make sure all transmitters have completed before
proceeding XXX */
- for (j =
Yup. git<->phab patch update fail. Maybe some day we can move to git.
-M
On Wed, Apr 11, 2018 at 10:12 AM, Jonathan T. Looney wrote:
> It appears this is causing panics (see the emails on freebsd-current@).
>
> From a brief glance, it appears that the new STATE_LOCK macros is
On Friday, May 27, 2016, Bjoern A. Zeeb
wrote:
>
> > On 28 May 2016, at 00:02 , Gleb Smirnoff wrote:
> >
> > On Fri, May 27, 2016 at 02:27:45PM -0700, Adrian Chadd wrote:
> > A> Hm, doesnt this make sense to do as part of RO_RTFREE?
> >
> > I
On Sat, May 21, 2016 at 3:36 AM, Hans Petter Selasky wrote:
> On 05/18/16 06:35, Scott Long wrote:
>>
>> Author: scottl
>> Date: Wed May 18 04:35:58 2016
>> New Revision: 300113
>> URL: https://svnweb.freebsd.org/changeset/base/300113
>>
>> Log:
>> Import the 'iflib' API
Those are new. Please just patch iflib to use them and let's move on.
-M
On Wed, May 18, 2016 at 4:58 PM, Gleb Smirnoff wrote:
> Hi!
>
> On Wed, May 18, 2016 at 04:35:58AM +, Scott Long wrote:
> S>
>
His proposed solution looks fine to me. Why don't we commit that?
-K
On Wed, Aug 5, 2015 at 7:22 PM, Glen Barber g...@freebsd.org wrote:
On Thu, Aug 06, 2015 at 04:17:23AM +0200, Pawel Jakub Dawidek wrote:
On Mon, Aug 03, 2015 at 04:20:04PM +0300, Andriy Gapon wrote:
On 30/07/2015 10:24, K
Just FYI this change introduces a deadlock with with the
spa_namespace_lock. Mount will be holding this lock while trying to
acquire the spa_namespace_lock. zfskern on the other hand holds the
spa_namespace_lock when calling zfs_freebsd_access which in turn
tries to acquire the teardown lock.
On Thu, Jul 16, 2015 at 3:28 PM, K. Macy km...@freebsd.org wrote:
I discovered this when I MFC'd and my kernel wouldn't link because of
unresolved symbols. I thought I had put the issue aside when I added
RANDOM_DUMMY to my kernel config.
However, I just hit this:
while
I discovered this when I MFC'd and my kernel wouldn't link because of
unresolved symbols. I thought I had put the issue aside when I added
RANDOM_DUMMY to my kernel config.
However, I just hit this:
while (!random_alg_context.ra_seeded()) {
if (nonblock) {
Sigh, you still do not understand. It is your duty to identify all pieces
which break after your change. After that, we can argue whether each of
them is critical or not to allow the migration. But this must have been
done before the KPI change hit the tree.
Hi,
Are you saying that
HPS: Your change failed to meet these guidelines. Some of us are upset
because these guidelines are fairly fundamental for the on-going
viability of FreeBSD. Due to linguistic / time zone / cultural
differences these expectations have not been adequately communicated
to you. You are not in
They originally found that things were spinning for way too long.
Hans found something similar and determined/concluded that the
migration code in callouts was racy-by-design and dramatically
simplified it and also put very hard constraints on what is a valid
situation to support migrating
Please back this out now. It was a substantial interface change
without review. This should not be up for debate. I hope the others
have the fortitude to insist upon this.
-K
On Thu, Jan 15, 2015 at 7:32 AM, Hans Petter Selasky
hsela...@freebsd.org wrote:
Author: hselasky
Date: Thu Jan 15
On Tue, Jan 20, 2015 at 3:48 PM, K. Macy km...@freebsd.org wrote:
Are any other drivers hitting this? e.g. cxgb/cxgbe?
The evidence is simply past experience of recurring locking and
control flow bugs in the intel drivers.
-K
-K
On Tue, Jan 20, 2015 at 3:46 PM, Sean Bruno sbr
On Tue, Jan 20, 2015 at 4:22 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:59, K. Macy wrote:
On Tue, Jan 20, 2015 at 3:53 PM, Sean Bruno
sbr...@ignoranthack.me wrote: On 01/20/15 15:48, K. Macy wrote:
Are any other drivers
I think you're working around driver locking bugs by crippling the callout code.
-K
On Tue, Jan 20, 2015 at 3:35 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 14:30, Hans Petter Selasky wrote:
On 01/20/15 22:11, Gleb Smirnoff wrote:
On Tue, Jan 20, 2015 at 3:53 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:48, K. Macy wrote:
Are any other drivers hitting this? e.g. cxgb/cxgbe?
-K
Unkown to me. Nor am I aware of anyone else who ever hit our panics
either
Are any other drivers hitting this? e.g. cxgb/cxgbe?
-K
On Tue, Jan 20, 2015 at 3:46 PM, Sean Bruno sbr...@ignoranthack.me wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/20/15 15:40, K. Macy wrote:
I think you're working around driver locking bugs by crippling the
callout
Il giorno 28/gen/2012, alle ore 09:39, Pawel Jakub Dawidek p...@freebsd.org
ha scritto:
On Fri, Jan 27, 2012 at 08:18:32PM +, Kip Macy wrote:
Author: kmacy
Date: Fri Jan 27 20:18:31 2012
New Revision: 230623
URL: http://svn.freebsd.org/changeset/base/230623
Log:
exclude
On Sat, Jan 28, 2012 at 9:39 AM, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Fri, Jan 27, 2012 at 08:18:32PM +, Kip Macy wrote:
Author: kmacy
Date: Fri Jan 27 20:18:31 2012
New Revision: 230623
URL: http://svn.freebsd.org/changeset/base/230623
Log:
exclude kmem_alloc'ed ARC data
The problem with having ZFS compiled into the kernel is that OpenSolaris
compatiblity layer needs its headers to be included before system
headers, which is/was impossible or hard to express for kernel
compilation. AFAIR Kip Macy was working on it and my understanding was
that he finished it
Will do - sorry for the delay.
Thanks,
Kip
On Wed, Oct 5, 2011 at 6:17 PM, David O'Brien obr...@freebsd.org wrote:
On Fri, Sep 16, 2011 at 01:58:51PM +, Kip Macy wrote:
Author: kmacy
Date: Fri Sep 16 13:58:51 2011
New Revision: 225617
Log:
In order to maximize the re-usability of
How has the problem been addressed? I'm seeing periodic panics with
non-zero resident count with the page lock patch applied. It is
possible that I've inadvertently re-introduced an issue you've fixed.
Thanks,
Kip
On Sat, Apr 3, 2010 at 9:20 AM, Alan Cox a...@freebsd.org wrote:
Author: alc
On Tue, Mar 23, 2010 at 6:54 AM, John Baldwin j...@freebsd.org wrote:
On Tuesday 23 March 2010 6:33:51 am K. Macy wrote:
The size change causes the initialization path to change in a way that
currently causes crashes.
Are you planning on debugging it further? Does UMA_BOOTPAGES or NKPT need
Be my guest. I've established the technical merits in production.
Thanks,
Kip
On Mar 20, 2010 4:10 AM, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Sat, Mar 13, 2010 at 09:41:53PM +, Kip Macy wrote:
Author: kmacy
Date: Sat Mar 13 21:41:5...
This is another[1] change we agreed (I hoped)
On Sat, Mar 20, 2010 at 3:10 AM, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Sat, Mar 13, 2010 at 09:41:53PM +, Kip Macy wrote:
Author: kmacy
Date: Sat Mar 13 21:41:52 2010
New Revision: 205132
URL: http://svn.freebsd.org/changeset/base/205132
Log:
Don't bottleneck on acquiring
This broke world.
On Wed, Mar 3, 2010 at 11:25 AM, Maxim Sobolev sobo...@freebsd.org wrote:
Author: sobomax
Date: Wed Mar 3 19:25:28 2010
New Revision: 204654
URL: http://svn.freebsd.org/changeset/base/204654
Log:
Use expand_number(3) from libutil instead of home-grown function to parse
30 matches
Mail list logo