Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe
On 21 Jan 2015, at 06:53, Navdeep Parhar wrote:
>
> On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
>>
>> On 01/20/15 22:06, Adrian Chadd wrote:
>>> On 20 January 2015 at 18:19, Alexey Dokuchaev wrote:
On Tue, Jan 20, 2015 at 07:50:23PM -0500, Pedro Giffuni wrote:
> But the fix is rather ugly, isn't it? I would personally prefer to just
> kill the older gcc but in the meantime updating it so that it behaves
> like the updated gcc/clang would be better. IMHO.
Seconded. Putting extra harness on the code to avoid bugs in the compiler
that were actually fixed upsteam is totally bogus.
>>> Right, but:
>>>
>>> * not all of us work on compilers;
>>> * not all of us want to currently be working on compilers;
>>> * some of us have to use the gcc that's in tree;
>>> * .. and apparently updating that gcc to something > 4.2 is verboten.
>>
>> The external toolchain can't be that bad(?).
>>
>>> So if someone wants to help Navdeep by backporting those options,
>>
>> Hmm .. didn't I post a patch?
>>
>>> please do. I bet he'd love the help.
>>>
>> Ugh he doesn't and TBH, I don't care enough to look for
>> consensus either.
>
> Let's please just move on from this discussion then. I am not familiar
> with gcc internals so I can't vouch for this patch, and gcc is the
> default compiler on platforms that I cannot test. Given that, it would
> be reckless of me to push a gcc patch just to get it to play nice with
> one single file in the tree. High risk, little reward (given that
> -fms-extensions can be applied to just the file in question without
> disturbing anything else in the tree).
Alternatively, just use the ${GCC_MS_EXTENSIONS} Makefile macro, which
I specifically introduced for this issue.
See e.g. sys/modules/ibcore/Makefile for an example.
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r275832 - head/tools/tools/nanobsd
Hi Will,
On 12/17/14 04:59, Will Andrews wrote:
> Author: will
> Date: Tue Dec 16 17:59:05 2014
> New Revision: 275832
> URL: https://svnweb.freebsd.org/changeset/base/275832
>
> Log:
> Make NanoBSD source-able from other scripts.
>
> Summary:
> This change converts NanoBSD into a two-script bundle.
> - defaults.sh contains all non-CLI code. Most NanoBSD code is moved into
> this file.
> - nanobsd.sh now consists just of a command line interface that calls into
> functions in defaults.sh.
>
> Test Plan: Run NanoBSD using a previously-working configuration.
>
> Reviewers: imp
>
> Reviewed By: imp
>
> Differential Revision: https://reviews.freebsd.org/D1321
>
> Added:
> head/tools/tools/nanobsd/defaults.sh (contents, props changed)
> Modified:
> head/tools/tools/nanobsd/nanobsd.sh
I think this change introduced a bug - I'm seeing nanobsd error out with
the "NANO_TOOLS directory does not exist" message.
The problem is that NANO_TOOLS is initialised to "tools/tools/nanobsd",
and you changed the test in nanobsd.sh to *not* check for
"${NANO_SRC}/${NANO_TOOLS}", which errors out except if the cwd is
${NANO_SRC}.
You tweak NANO_TOOLS appropriately in set_defaults_and_export() but it's
run after the dir test. There are a couple of ways to fix but I'll leave
it to you to decide which you prefer.
Cheers,
Lawrence
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277449 - head/sys/cddl/compat/opensolaris/sys
... common/sys/zfs_context.h:538 ? -a On 20 January 2015 at 14:29, Will Andrews wrote: > Author: will > Date: Tue Jan 20 22:29:27 2015 > New Revision: 277449 > URL: https://svnweb.freebsd.org/changeset/base/277449 > > Log: > NSEC_TO_TICK(usec) -> NSEC_TO_TICK(nsec) > > Modified: > head/sys/cddl/compat/opensolaris/sys/time.h > > Modified: head/sys/cddl/compat/opensolaris/sys/time.h > == > --- head/sys/cddl/compat/opensolaris/sys/time.h Tue Jan 20 22:27:45 2015 > (r277448) > +++ head/sys/cddl/compat/opensolaris/sys/time.h Tue Jan 20 22:29:27 2015 > (r277449) > @@ -51,7 +51,7 @@ typedef longlong_thrtime_t; > #endif > > #defineSEC_TO_TICK(sec)((sec) * hz) > -#defineNSEC_TO_TICK(usec) ((usec) / (NANOSEC / hz)) > +#defineNSEC_TO_TICK(nsec) ((nsec) / (NANOSEC / hz)) > > #ifdef _KERNEL > static __inline hrtime_t > ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 01/21/15 01:49, Adrian Chadd wrote: You should totally try say, 100,000 active TCP connections on a box. See what happens to swi0 (clock). TL;DR - the lock contention sucks and it takes a chunk of the core up. The lock contention is highly not good. That's why I'd like to see both the callout stuff in its slightly-better-defined-and-sane state from you/and/ make it so TCP can use it. I'll have to double-check to see if the RSS stuff is all lined up correctly so we can use it when we create the callouts (well, at inpcb creation time, right), rather than when we first schedule them. Then we can experiment with having the initial CPU be specified at callout create time rather than expecting to be able to move it when we first schedule it. Or, hm, maybe have it so we don't have a CPU chosen until the first time we schedule the timeout, and if it hasn't been scheduled before, allow the CPU to be set? Because at that point we aren't migrating it off f timeout_cpu - it's never been added to it in the first place. Hi Adrian, What you are saying is correct. If you set the initial c_cpu value when the callout is initialized it will run on SWI#X instead of SWI#0. This is fully allowed, so maybe a callout_init_cpu() would be appropriate, to set the initial CPU number for callouts. With regard to the callout the c_cpu value can be different from zero, only the it must remain fixed/constant when there is no lock protecting updates to it! Kip and Gleb: Does adding a callout_init_cpu() function which can be used for existing callouts and in conjunction with CALLOUT_MPSAFE change anything? --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe
On Wed, Jan 21, 2015 at 09:00:03AM +0100, Dimitry Andric wrote:
> On 21 Jan 2015, at 06:53, Navdeep Parhar wrote:
> >
> > On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
> >>
> >> On 01/20/15 22:06, Adrian Chadd wrote:
> >>> On 20 January 2015 at 18:19, Alexey Dokuchaev wrote:
> On Tue, Jan 20, 2015 at 07:50:23PM -0500, Pedro Giffuni wrote:
> > But the fix is rather ugly, isn't it? I would personally prefer to just
> > kill the older gcc but in the meantime updating it so that it behaves
> > like the updated gcc/clang would be better. IMHO.
> Seconded. Putting extra harness on the code to avoid bugs in the
> compiler
> that were actually fixed upsteam is totally bogus.
> >>> Right, but:
> >>>
> >>> * not all of us work on compilers;
> >>> * not all of us want to currently be working on compilers;
> >>> * some of us have to use the gcc that's in tree;
> >>> * .. and apparently updating that gcc to something > 4.2 is verboten.
> >>
> >> The external toolchain can't be that bad(?).
> >>
> >>> So if someone wants to help Navdeep by backporting those options,
> >>
> >> Hmm .. didn't I post a patch?
> >>
> >>> please do. I bet he'd love the help.
> >>>
> >> Ugh he doesn't and TBH, I don't care enough to look for
> >> consensus either.
> >
> > Let's please just move on from this discussion then. I am not familiar
> > with gcc internals so I can't vouch for this patch, and gcc is the
> > default compiler on platforms that I cannot test. Given that, it would
> > be reckless of me to push a gcc patch just to get it to play nice with
> > one single file in the tree. High risk, little reward (given that
> > -fms-extensions can be applied to just the file in question without
> > disturbing anything else in the tree).
>
> Alternatively, just use the ${GCC_MS_EXTENSIONS} Makefile macro, which
> I specifically introduced for this issue.
Ah, a rose with another name. I'm happy to use this but it's not clear why
there is a GCC in the macro's name when clang deals with -fms-extensions
just as well. (It's not even clear why the longer ${GCC_MS_EXTENSIONS}
should be preferred to -fms-extentions. Isn't this like #define ONE 1 ?)
In any case I'm perfectly fine with any change that doesn't involve a commit
from me to gcc.
Regards,
Navdeep
>
> See e.g. sys/modules/ibcore/Makefile for an example.
>
> -Dimitry
>
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On Tue, Jan 20, 2015 at 04:37:44PM -0800, K. Macy wrote: > I would pick stability over performance any day. However, it _seems_ > to me, and maybe I simply don't understand some key details, that the > fix consisted of largely single-threading the callout system. And as I > say I may simply not understand the specifics, but this sort of large > scale disabling does not constitute a fix but is a workaround. It's > more like disabling preemption because it fixes a panic. Yes, it might > "fix" a whole array of bugs that crop up but it could not be seen as a > fix to an otherwise working system. Well, this is not a complete truth. Let me try to explain my understanding, I spent some time actually looking at the new code. Would be nice if corrections to my understanding is posted, if needed. Now, when callout_reset() is directed to change cpu, the change only happens when the callout is associated with a lock, and that lock is owned by the caller of callout_reset(). There are two consequences. One, which is good, is significant simplification of the migration code, together with the drain. This is exactly the place where there bugs which make my head hurt, see e.g. r234952 and r243901. Note that some callouts follow this pattern already, e.g. process timers after r243869. Another consequence, which is very visible and which causes the roar, is that all lockless callers of callout_reset_on(9) now silently changed the behaviour to callout_reset(9). There is no audit performed to identify such callers, and there is no even a plan to fix them. The answer to the complains seems to be 'if you think that the fix is needed, go and fix'. My impression is that some set of vocal active developers consider the second consequence unacceptable, myself included. IMO, committing the change, however good the consequence one is, without fixing the consequence two, is inappropriate. And the onus of doing this is on the person doing the change. Yes, it is very interesting is the change actually good WRT fixing migration, since indeed there is serious reduction in the migration amount due to locked callout_reset() being not universally used. It is possible that the bugs are only covered. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe
On Tue, Jan 20, 2015 at 11:19:58PM -0500, Pedro Giffuni wrote: > > On 01/20/15 22:52, Steve Kargl wrote: > > On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote: > >> On 01/20/15 22:06, Adrian Chadd wrote: > >>> * .. and apparently updating that gcc to something > 4.2 is verboten. > >> The external toolchain can't be that bad(?). > >> > > Are the ever change knobs documented somewhere? > > > https://wiki.freebsd.org/ExternalToolchain > IHMO, the wiki is not proper documentation. 'man src.conf' should have the information needed. -- Steve ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe
On Jan 21, 2015, at 0:17, Steve Kargl wrote: > On Tue, Jan 20, 2015 at 11:19:58PM -0500, Pedro Giffuni wrote: >> >> On 01/20/15 22:52, Steve Kargl wrote: >>> On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote: On 01/20/15 22:06, Adrian Chadd wrote: > * .. and apparently updating that gcc to something > 4.2 is verboten. The external toolchain can't be that bad(?). >>> Are the ever change knobs documented somewhere? >>> >> https://wiki.freebsd.org/ExternalToolchain > > IHMO, the wiki is not proper documentation. 'man src.conf' > should have the information needed. build(7) seems like a more appropriate area, but I wholeheartedly agree. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 01/21/15 00:53, Sean Bruno wrote: Unkown to me. Nor am I aware of anyone else who ever hit our panics either. Our environment, and the failure, was only seen in the Intel 10GE space (ixgbe). This is an artifact of our use cases, and hasn't been expanded nor tested in our environment with other vendor interfaces. sean Hi, I've seen this with Mellanox hardware when running some special tests, but not during regular use yet. That was the reason for going into the callout subsystem in the first place. 40GE. Also I would like to mention during the heat of this discussion, that during X-mas this year, I had a very heavy discussion with Attilio and a few other FreeBSD developers, who's name was on a patch (r220456) that changed how the return value of "callout_active()" works. "callout_active()" is heavily used inside the TCP stack and what was found is there is a potential race related to migrating the callout from one CPU to the other, which in turn might give other symptoms than a spinlock hang. FYI: https://svnweb.freebsd.org/base?view=revision&revision=225057 Cite: "If the newly scheduled thread wants to acquire the old queue it will just spin forever." This description reminds me very much of what "Jason Wolfe", others and myself have seen. Konstantin, you're responsible for r220456 (Approved by: kib). I would like to ask what investigation you did to ensure that you solved the problem as described in the commit message and didn't introduce a new one? In r220456 the "callout_reset_on()" function was changed in a way that directly conflicts with how the TCP stack works, by not always ensuring that "callout_active()" returns non-zero after a callout is restarted! See return at line 821: https://svnweb.freebsd.org/base/head/sys/kern/kern_timeout.c?revision=225057&view=markup&pathrev=225057#l821 Kib: Any comments? --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe
On Wed, Jan 21, 2015 at 12:17:14AM -0800, Steve Kargl wrote: > On Tue, Jan 20, 2015 at 11:19:58PM -0500, Pedro Giffuni wrote: > > > > On 01/20/15 22:52, Steve Kargl wrote: > > > On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote: > > >> On 01/20/15 22:06, Adrian Chadd wrote: > > >>> * .. and apparently updating that gcc to something > 4.2 is verboten. > > >> The external toolchain can't be that bad(?). > > >> > > > Are the ever change knobs documented somewhere? > > > > > https://wiki.freebsd.org/ExternalToolchain > > > > IHMO, the wiki is not proper documentation. 'man src.conf' > should have the information needed. > Planned into build(7) but not yet done as it is work in progress aka some knobs might or might not change Bapt pgpG8TRKh8xpv.pgp Description: PGP signature
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On Wed, Jan 21, 2015 at 09:32:11AM +0100, Hans Petter Selasky wrote: > On 01/21/15 00:53, Sean Bruno wrote: > > Unkown to me. Nor am I aware of anyone else who ever hit our panics > > either. Our environment, and the failure, was only seen in the Intel > > 10GE space (ixgbe). This is an artifact of our use cases, and hasn't > > been expanded nor tested in our environment with other vendor interfaces. > > > > sean > > Hi, > > I've seen this with Mellanox hardware when running some special tests, > but not during regular use yet. That was the reason for going into the > callout subsystem in the first place. 40GE. > > Also I would like to mention during the heat of this discussion, that > during X-mas this year, I had a very heavy discussion with Attilio and a > few other FreeBSD developers, who's name was on a patch (r220456) that > changed how the return value of "callout_active()" works. > "callout_active()" is heavily used inside the TCP stack and what was > found is there is a potential race related to migrating the callout from > one CPU to the other, which in turn might give other symptoms than a > spinlock hang. > > FYI: > > https://svnweb.freebsd.org/base?view=revision&revision=225057 > > Cite: "If the newly scheduled thread wants to acquire the old queue it > will just spin forever." > > This description reminds me very much of what "Jason Wolfe", others and > myself have seen. > > Konstantin, you're responsible for r220456 (Approved by: kib). I would I definitely do not see anything related to my freefall login in the log message for r220456, nor I participated in any way in the work which lead to that revision. If you mean r225057, note that approval by re != review. > like to ask what investigation you did to ensure that you solved the > problem as described in the commit message and didn't introduce a new one? > > In r220456 the "callout_reset_on()" function was changed in a way that > directly conflicts with how the TCP stack works, by not always ensuring > that "callout_active()" returns non-zero after a callout is restarted! > See return at line 821: > > > https://svnweb.freebsd.org/base/head/sys/kern/kern_timeout.c?revision=225057&view=markup&pathrev=225057#l821 > > Kib: Any comments? With the re hat on, explanation for the proposed commit looked reasonable, and committer provided enough evidence that change got adequate testing. Since change fixed a bug, and this is exactly what re wants to see during release cycle, I see no reason why commit should be denied. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277467 - in head/sys/arm: arm at91 cavium/cns11xx mv samsung/s3c2xx0 versatile xscale/i80321 xscale/i8134x xscale/ixp425 xscale/pxa
On Wed, 21 Jan 2015 02:56:14 + (UTC) Ian Lepore wrote: > Author: ian > Date: Wed Jan 21 02:56:13 2015 > New Revision: 277467 > URL: https://svnweb.freebsd.org/changeset/base/277467 > > Log: > For some reason, all the arm bus_space functions that work with > uint16 values have armv4 in the name. There's nothing armv4-special > about them, so just use the same sort of names as all the other > functions. This is because ARMv3 lacked half word load and store instructions. We got this code from NetBSD who appears to have support for these older ARM processors. Andrew ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277481 - head/sys/dev/mii
Author: kevlo
Date: Wed Jan 21 09:01:48 2015
New Revision: 277481
URL: https://svnweb.freebsd.org/changeset/base/277481
Log:
Typo: ivalid -> invalid.
Modified:
head/sys/dev/mii/mii.c
Modified: head/sys/dev/mii/mii.c
==
--- head/sys/dev/mii/mii.c Wed Jan 21 05:31:54 2015(r277480)
+++ head/sys/dev/mii/mii.c Wed Jan 21 09:01:48 2015(r277481)
@@ -374,7 +374,7 @@ mii_attach(device_t dev, device_t *miibu
}
if (offloc != MII_OFFSET_ANY && (offloc < 0 || offloc >= MII_NPHY)) {
- printf("%s: ivalid offloc %d\n", __func__, offloc);
+ printf("%s: invalid offloc %d\n", __func__, offloc);
return (EINVAL);
}
@@ -383,7 +383,7 @@ mii_attach(device_t dev, device_t *miibu
phymax = MII_NPHY - 1;
} else {
if (phyloc < 0 || phyloc >= MII_NPHY) {
- printf("%s: ivalid phyloc %d\n", __func__, phyloc);
+ printf("%s: invalid phyloc %d\n", __func__, phyloc);
return (EINVAL);
}
phymin = phymax = phyloc;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 01/21/15 09:51, Konstantin Belousov wrote: On Wed, Jan 21, 2015 at 09:32:11AM +0100, Hans Petter Selasky wrote: On 01/21/15 00:53, Sean Bruno wrote: Unkown to me. Nor am I aware of anyone else who ever hit our panics either. Our environment, and the failure, was only seen in the Intel 10GE space (ixgbe). This is an artifact of our use cases, and hasn't been expanded nor tested in our environment with other vendor interfaces. sean Hi, I've seen this with Mellanox hardware when running some special tests, but not during regular use yet. That was the reason for going into the callout subsystem in the first place. 40GE. Also I would like to mention during the heat of this discussion, that during X-mas this year, I had a very heavy discussion with Attilio and a few other FreeBSD developers, who's name was on a patch (r220456) that changed how the return value of "callout_active()" works. "callout_active()" is heavily used inside the TCP stack and what was found is there is a potential race related to migrating the callout from one CPU to the other, which in turn might give other symptoms than a spinlock hang. FYI: https://svnweb.freebsd.org/base?view=revision&revision=225057 Cite: "If the newly scheduled thread wants to acquire the old queue it will just spin forever." This description reminds me very much of what "Jason Wolfe", others and myself have seen. Konstantin, you're responsible for r220456 (Approved by: kib). I would I definitely do not see anything related to my freefall login in the log message for r220456, nor I participated in any way in the work which lead to that revision. If you mean r225057, note that approval by re != review. Yes, I meant r225057. like to ask what investigation you did to ensure that you solved the problem as described in the commit message and didn't introduce a new one? In r220456 the "callout_reset_on()" function was changed in a way that directly conflicts with how the TCP stack works, by not always ensuring that "callout_active()" returns non-zero after a callout is restarted! See return at line 821: https://svnweb.freebsd.org/base/head/sys/kern/kern_timeout.c?revision=225057&view=markup&pathrev=225057#l821 Kib: Any comments? With the re hat on, explanation for the proposed commit looked reasonable, and committer provided enough evidence that change got adequate testing. Since change fixed a bug, and this is exactly what re wants to see during release cycle, I see no reason why commit should be denied. The problem is Attilio is no longer an active committer and he was not been very willing to do more work in this area. When people writing code in an area no longer respond - what should we do? --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277482 - stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: smh Date: Wed Jan 21 09:39:20 2015 New Revision: 277482 URL: https://svnweb.freebsd.org/changeset/base/277482 Log: MFC r272509 (by delphi): Diff reduction with upstream Sponsored by: Multiplay Modified: stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c Directory Properties: stable/10/ (props changed) Modified: stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c == --- stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c Wed Jan 21 09:01:48 2015(r277481) +++ stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c Wed Jan 21 09:39:20 2015(r277482) @@ -1997,8 +1997,8 @@ zvol_ioctl(dev_t dev, int cmd, intptr_t */ if (df.df_start >= zv->zv_volsize) break; /* No need to do anything... */ - if (df.df_start + df.df_length > zv->zv_volsize) - df.df_length = DMU_OBJECT_END; + + mutex_exit(&spa_namespace_lock); rl = zfs_range_lock(&zv->zv_znode, df.df_start, df.df_length, RL_WRITER); @@ -2037,7 +2037,7 @@ zvol_ioctl(dev_t dev, int cmd, intptr_t dmu_objset_pool(zv->zv_objset), 0); } } - break; + return (error); } default: ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277483 - in stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs: . sys
Author: smh
Date: Wed Jan 21 09:45:48 2015
New Revision: 277483
URL: https://svnweb.freebsd.org/changeset/base/277483
Log:
MFC r276063:
Standardise on illumos for #ifdef's in zvol.c
MFC r276066:
Refactor zvol locking to minimise diff with upstream
MFC r276069:
Fix panic when resizing ZFS zvol's
Sponsored by: Multiplay
Modified:
stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h
stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
Directory Properties:
stable/10/ (props changed)
Modified: stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h
==
--- stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h Wed Jan
21 09:39:20 2015(r277482)
+++ stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h Wed Jan
21 09:45:48 2015(r277483)
@@ -43,7 +43,7 @@ extern void zvol_create_cb(objset_t *os,
extern int zvol_create_minor(const char *);
extern int zvol_remove_minor(const char *);
extern void zvol_remove_minors(const char *);
-extern int zvol_set_volsize(const char *, major_t, uint64_t);
+extern int zvol_set_volsize(const char *, uint64_t);
#ifdef sun
extern int zvol_open(dev_t *devp, int flag, int otyp, cred_t *cr);
Modified: stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
==
--- stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
Wed Jan 21 09:39:20 2015(r277482)
+++ stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
Wed Jan 21 09:45:48 2015(r277483)
@@ -2483,8 +2483,7 @@ zfs_prop_set_special(const char *dsname,
err = dsl_dataset_set_refreservation(dsname, source, intval);
break;
case ZFS_PROP_VOLSIZE:
- err = zvol_set_volsize(dsname, ddi_driver_major(zfs_dip),
- intval);
+ err = zvol_set_volsize(dsname, intval);
break;
case ZFS_PROP_VERSION:
{
Modified: stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c
==
--- stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c Wed Jan
21 09:39:20 2015(r277482)
+++ stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zvol.c Wed Jan
21 09:45:48 2015(r277483)
@@ -97,6 +97,7 @@
#include "zfs_namecheck.h"
+#ifndef illumos
struct g_class zfs_zvol_class = {
.name = "ZFS::ZVOL",
.version = G_VERSION,
@@ -104,19 +105,30 @@ struct g_class zfs_zvol_class = {
DECLARE_GEOM_CLASS(zfs_zvol_class, zfs_zvol);
+#endif
void *zfsdev_state;
static char *zvol_tag = "zvol_tag";
#defineZVOL_DUMPSIZE "dumpsize"
/*
- * The spa_namespace_lock protects the zfsdev_state structure from being
- * modified while it's being used, e.g. an open that comes in before a
- * create finishes. It also protects temporary opens of the dataset so that,
+ * This lock protects the zfsdev_state structure from being modified
+ * while it's being used, e.g. an open that comes in before a create
+ * finishes. It also protects temporary opens of the dataset so that,
* e.g., an open doesn't get a spurious EBUSY.
*/
+#ifdef illumos
+kmutex_t zfsdev_state_lock;
+#else
+/*
+ * In FreeBSD we've replaced the upstream zfsdev_state_lock with the
+ * spa_namespace_lock in the ZVOL code.
+ */
+#define zfsdev_state_lock spa_namespace_lock
+#endif
static uint32_t zvol_minors;
+#ifndef illumos
SYSCTL_DECL(_vfs_zfs);
SYSCTL_NODE(_vfs_zfs, OID_AUTO, vol, CTLFLAG_RW, 0, "ZFS VOLUME");
static int volmode = ZFS_VOLMODE_GEOM;
@@ -124,6 +136,7 @@ TUNABLE_INT("vfs.zfs.vol.mode", &volmode
SYSCTL_INT(_vfs_zfs_vol, OID_AUTO, mode, CTLFLAG_RWTUN, &volmode, 0,
"Expose as GEOM providers (1), device files (2) or neither");
+#endif
typedef struct zvol_extent {
list_node_t ze_node;
dva_t ze_dva; /* dva associated with this extent */
@@ -134,28 +147,40 @@ typedef struct zvol_extent {
* The in-core state of each volume.
*/
typedef struct zvol_state {
+#ifndef illumos
LIST_ENTRY(zvol_state) zv_links;
+#endif
charzv_name[MAXPATHLEN]; /* pool/dd name */
uint64_tzv_volsize; /* amount of space we advertise */
uint64_tzv_volblocksize; /* volume block size */
+#ifdef illumos
+ minor_t zv_minor; /* minor number */
+#else
struct cdev *zv_dev;/* non-GEOM device */
struct g_provider *zv_provider; /* GEOM provider */
+#endif
uint8_t zv_min_bs; /* minimum addressable block shift */
uint8_t zv_flags; /* readonly, dumpified, etc
Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe
On 21 Jan 2015, at 09:10, Navdeep Parhar wrote:
>
> On Wed, Jan 21, 2015 at 09:00:03AM +0100, Dimitry Andric wrote:
>> On 21 Jan 2015, at 06:53, Navdeep Parhar wrote:
>>>
>>> On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
...
>> Alternatively, just use the ${GCC_MS_EXTENSIONS} Makefile macro, which
>> I specifically introduced for this issue.
>
> Ah, a rose with another name. I'm happy to use this but it's not clear why
> there is a GCC in the macro's name when clang deals with -fms-extensions
> just as well.
It's because only gcc (in base) requires this flag to support anonymous
unions, whereas clang also supports them without the flag. None of the
sources requiring this flag use actual Microsoft C extensions.
> (It's not even clear why the longer ${GCC_MS_EXTENSIONS}
> should be preferred to -fms-extentions. Isn't this like #define ONE 1 ?)
Using -fms-extensions with clang can lead to other trouble, since it is
stricter about conflicts with Microsoft-reserved type names. Last time
I ran into this problem, several of our system headers tried to override
type names which are reserved by Microsoft, leading to compile errors.
Meanwhile, that issue may have been solved, but the crutches are still
there. Instead of the macro, you could also use:
CFLAGS.gcc+= -fms-extensions
But note that this flag is probably superfluous with newer gcc's, so
using the macro is still a better solution, because the compiler version
can be checked in a central location, such as sys/conf/kern.mk.
> In any case I'm perfectly fine with any change that doesn't involve a commit
> from me to gcc.
Fixing this version of gcc is not really worth the trouble, indeed.
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
svn commit: r277484 - head/cddl/contrib/opensolaris/lib/libzpool/common/sys
Author: ngie Date: Wed Jan 21 10:47:28 2015 New Revision: 277484 URL: https://svnweb.freebsd.org/changeset/base/277484 Log: Follow up to r277449 by fixing the remaining NSEC_TO_TICK macro to have the same named parameters Reported by: Ben Perrault , Willem Jan Withagen Modified: head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h Modified: head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h == --- head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h Wed Jan 21 09:45:48 2015(r277483) +++ head/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h Wed Jan 21 10:47:28 2015(r277484) @@ -535,7 +535,7 @@ extern vnode_t *rootdir; extern void delay(clock_t ticks); #defineSEC_TO_TICK(sec)((sec) * hz) -#defineNSEC_TO_TICK(usec) ((usec) / (NANOSEC / hz)) +#defineNSEC_TO_TICK(nsec) ((nsec) / (NANOSEC / hz)) #definegethrestime_sec() time(NULL) #definegethrestime(t) \ ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe
On Tue, Jan 20, 2015 at 07:06:14PM -0800, Adrian Chadd wrote: > On 20 January 2015 at 18:19, Alexey Dokuchaev wrote: > > Seconded. Putting extra harness on the code to avoid bugs in the > > compiler that were actually fixed upsteam is totally bogus. > > Right, but: > [...] > * some of us have to use the gcc that's in tree; > * .. and apparently updating that gcc to something > 4.2 is verboten. To be clear: I did not suggest moving to external toolchain (I hate to do it myself). I was talking about merging the fix to base gcc4.2 (provided that it can be licensed under GPLv2). Now that most people had lost their interest in 8.x, it can be a problem of organizational nature, but not technical. ./danfe ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277485 - head/usr.sbin/pmcstudy
Author: rrs
Date: Wed Jan 21 13:03:18 2015
New Revision: 277485
URL: https://svnweb.freebsd.org/changeset/base/277485
Log:
Fix minor errors found by coverity. Thanks Gleb for
the pointers to the email!
Modified:
head/usr.sbin/pmcstudy/pmcstudy.c
Modified: head/usr.sbin/pmcstudy/pmcstudy.c
==
--- head/usr.sbin/pmcstudy/pmcstudy.c Wed Jan 21 10:47:28 2015
(r277484)
+++ head/usr.sbin/pmcstudy/pmcstudy.c Wed Jan 21 13:03:18 2015
(r277485)
@@ -1808,6 +1808,9 @@ process_file(char *filename)
if (cnts == NULL) {
/* Nothing we can do */
printf("Nothing to do -- no counters built\n");
+ if (io) {
+ fclose(io);
+ }
return;
}
lace_cpus_together();
@@ -2044,7 +2047,7 @@ get_cpuid_set(void)
printf("No memory3 allocation fails at
startup?\n");
exit(-1);
}
- memset(more, sz, 0);
+ memset(more, 0, sz);
memcpy(more, valid_pmcs, sz);
pmc_allocated_cnt *= 2;
free(valid_pmcs);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277486 - head/share/man/man9
Author: gavin Date: Wed Jan 21 13:48:06 2015 New Revision: 277486 URL: https://svnweb.freebsd.org/changeset/base/277486 Log: "softc" is short for "software context", use that phrase in the device_get_softc(9) man page. MFC after:1 week Modified: head/share/man/man9/device_get_softc.9 Modified: head/share/man/man9/device_get_softc.9 == --- head/share/man/man9/device_get_softc.9 Wed Jan 21 13:03:18 2015 (r277485) +++ head/share/man/man9/device_get_softc.9 Wed Jan 21 13:48:06 2015 (r277486) @@ -28,7 +28,7 @@ .\" .\" $FreeBSD$ .\" -.Dd August 2, 2005 +.Dd January 21, 2015 .Dt DEVICE_GET_SOFTC 9 .Os .Sh NAME @@ -40,7 +40,7 @@ .Ft void * .Fn device_get_softc "device_t dev" .Sh DESCRIPTION -Return the driver-specific state of +Return the driver-specific software context of .Fa dev . The softc is automatically allocated and zeroed when the device is attached. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 01/20/15 09:22, Adrian Chadd wrote: > Yeah, it looks like you set c_cpu to timeout_cpu in > _callout_init_locked(), but then you only handle the case of the CPU > being changed in certain circumstances. You aren't handling the CPU > being initialised when the callout is first added. > > And, callout_restart_async() calls callout_lock(), which calls > CC_LOCK() on the callout CPU, which initially is zero. Then, it never > seems to be 'moved' into the correct CPU, even though it's being > called with a CPU id. > > So, if I am reading this all correctly, you aren't really handling > multi CPU callwheels at all. ;) > > In my instance, I'm seeing quite a lot of lock contention between the > userland threads, the network RX threads and the clock thread, all > contending on a single callout wheel being used for TCP timers. One of > the early goals for fixing up the RSS stuff in -HEAD was to make > per-CPU (Well, per-RSS-bucket really) TCP timers not contend with the > NIC RX processing path, and now it does. :( To clarify, you're seeing this with net.inet.tcp.per_cpu_timers=1? Cheers, Lawrence ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r275832 - head/tools/tools/nanobsd
On Wed, Jan 21, 2015 at 06:51:23PM +1100, Lawrence Stewart wrote:
> I think this change introduced a bug - I'm seeing nanobsd error out with
> the "NANO_TOOLS directory does not exist" message.
>
> The problem is that NANO_TOOLS is initialised to "tools/tools/nanobsd",
> and you changed the test in nanobsd.sh to *not* check for
> "${NANO_SRC}/${NANO_TOOLS}", which errors out except if the cwd is
> ${NANO_SRC}.
>
> You tweak NANO_TOOLS appropriately in set_defaults_and_export() but it's
> run after the dir test. There are a couple of ways to fix but I'll leave
> it to you to decide which you prefer.
Will this work for you?
https://people.freebsd.org/~will/patches/nanobsd.sh.diff
This also fixes another bug where NANO_PMAKE would be modified too early.
Thanks,
--Will.
pgp2UXbCbjYtC.pgp
Description: PGP signature
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 21 January 2015 at 06:00, Lawrence Stewart wrote: > On 01/20/15 09:22, Adrian Chadd wrote: >> Yeah, it looks like you set c_cpu to timeout_cpu in >> _callout_init_locked(), but then you only handle the case of the CPU >> being changed in certain circumstances. You aren't handling the CPU >> being initialised when the callout is first added. >> >> And, callout_restart_async() calls callout_lock(), which calls >> CC_LOCK() on the callout CPU, which initially is zero. Then, it never >> seems to be 'moved' into the correct CPU, even though it's being >> called with a CPU id. >> >> So, if I am reading this all correctly, you aren't really handling >> multi CPU callwheels at all. ;) >> >> In my instance, I'm seeing quite a lot of lock contention between the >> userland threads, the network RX threads and the clock thread, all >> contending on a single callout wheel being used for TCP timers. One of >> the early goals for fixing up the RSS stuff in -HEAD was to make >> per-CPU (Well, per-RSS-bucket really) TCP timers not contend with the >> NIC RX processing path, and now it does. :( > > To clarify, you're seeing this with net.inet.tcp.per_cpu_timers=1? Yup, RSS enables that by default. -adrian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277487 - in head/sys: dev/drm2 dev/drm2/i915 dev/drm2/radeon modules/drm2/i915kms
Author: kib
Date: Wed Jan 21 16:10:37 2015
New Revision: 277487
URL: https://svnweb.freebsd.org/changeset/base/277487
Log:
An update for the i915 GPU driver, which brings the code up to Linux
commit 4d93914ae3db4a897ead4b. Some related drm infrastructure
changes are imported as needed.
Biggest update is the rewrite of the i915 gem io to more closely
follow Linux model, althought the mechanism used by FreeBSD port is
different.
Sponsored by: The FreeBSD Foundation
MFC after:2 month
Added:
head/sys/dev/drm2/i915/i915_gem_stolen.c (contents, props changed)
head/sys/dev/drm2/i915/intel_ddi.c (contents, props changed)
head/sys/dev/drm2/i915/intel_pm.c (contents, props changed)
Modified:
head/sys/dev/drm2/drm.h
head/sys/dev/drm2/drmP.h
head/sys/dev/drm2/drm_crtc.c
head/sys/dev/drm2/drm_crtc.h
head/sys/dev/drm2/drm_crtc_helper.c
head/sys/dev/drm2/drm_crtc_helper.h
head/sys/dev/drm2/drm_drv.c
head/sys/dev/drm2/drm_edid.c
head/sys/dev/drm2/drm_edid.h
head/sys/dev/drm2/drm_edid_modes.h
head/sys/dev/drm2/drm_fb_helper.c
head/sys/dev/drm2/drm_ioctl.c
head/sys/dev/drm2/drm_irq.c
head/sys/dev/drm2/drm_memory.c
head/sys/dev/drm2/drm_mode.h
head/sys/dev/drm2/drm_pciids.h
head/sys/dev/drm2/drm_stub.c
head/sys/dev/drm2/i915/i915_debug.c
head/sys/dev/drm2/i915/i915_dma.c
head/sys/dev/drm2/i915/i915_drm.h
head/sys/dev/drm2/i915/i915_drv.c
head/sys/dev/drm2/i915/i915_drv.h
head/sys/dev/drm2/i915/i915_gem.c
head/sys/dev/drm2/i915/i915_gem_context.c
head/sys/dev/drm2/i915/i915_gem_evict.c
head/sys/dev/drm2/i915/i915_gem_execbuffer.c
head/sys/dev/drm2/i915/i915_gem_gtt.c
head/sys/dev/drm2/i915/i915_gem_tiling.c
head/sys/dev/drm2/i915/i915_irq.c
head/sys/dev/drm2/i915/i915_reg.h
head/sys/dev/drm2/i915/i915_suspend.c
head/sys/dev/drm2/i915/intel_bios.c
head/sys/dev/drm2/i915/intel_crt.c
head/sys/dev/drm2/i915/intel_display.c
head/sys/dev/drm2/i915/intel_dp.c
head/sys/dev/drm2/i915/intel_drv.h
head/sys/dev/drm2/i915/intel_fb.c
head/sys/dev/drm2/i915/intel_hdmi.c
head/sys/dev/drm2/i915/intel_iic.c
head/sys/dev/drm2/i915/intel_lvds.c
head/sys/dev/drm2/i915/intel_modes.c
head/sys/dev/drm2/i915/intel_overlay.c
head/sys/dev/drm2/i915/intel_panel.c
head/sys/dev/drm2/i915/intel_ringbuffer.c
head/sys/dev/drm2/i915/intel_ringbuffer.h
head/sys/dev/drm2/i915/intel_sdvo.c
head/sys/dev/drm2/i915/intel_sprite.c
head/sys/dev/drm2/i915/intel_tv.c
head/sys/dev/drm2/radeon/atombios_encoders.c
head/sys/dev/drm2/radeon/radeon_legacy_encoders.c
head/sys/modules/drm2/i915kms/Makefile
Modified: head/sys/dev/drm2/drm.h
==
--- head/sys/dev/drm2/drm.h Wed Jan 21 13:48:06 2015(r277486)
+++ head/sys/dev/drm2/drm.h Wed Jan 21 16:10:37 2015(r277487)
@@ -1018,6 +1018,9 @@ struct drm_event_vblank {
#define DRM_CAP_PRIME 0x5
#define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
+#define DRM_PRIME_CAP_IMPORT 0x1
+#define DRM_PRIME_CAP_EXPORT 0x2
+
#include "drm_mode.h"
/**
@@ -1126,6 +1129,8 @@ struct drm_event_vblank {
#define DRM_IOCTL_MODE_GETPLANEDRM_IOWR(0xB6, struct
drm_mode_get_plane)
#define DRM_IOCTL_MODE_SETPLANEDRM_IOWR(0xB7, struct
drm_mode_set_plane)
#define DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, struct drm_mode_fb_cmd2)
+#define DRM_IOCTL_MODE_OBJ_GETPROPERTIES DRM_IOWR(0xB9, struct
drm_mode_obj_get_properties)
+#define DRM_IOCTL_MODE_OBJ_SETPROPERTY DRM_IOWR(0xBA, struct
drm_mode_obj_set_property)
#define DRM_IOCTL_MM_INIT DRM_IOWR(0xc0, struct drm_mm_init_arg)
#define DRM_IOCTL_MM_TAKEDOWN DRM_IOWR(0xc1, struct drm_mm_type_arg)
Modified: head/sys/dev/drm2/drmP.h
==
--- head/sys/dev/drm2/drmP.hWed Jan 21 13:48:06 2015(r277486)
+++ head/sys/dev/drm2/drmP.hWed Jan 21 16:10:37 2015(r277487)
@@ -1246,6 +1246,7 @@ int drm_ati_pcigart_cleanup(struct drm_d
/* Cache management (drm_memory.c) */
void drm_clflush_pages(vm_page_t *pages, unsigned long num_pages);
+void drm_clflush_virt_range(char *addr, unsigned long length);
/* Locking IOCTL support (drm_drv.c) */
intdrm_lock(struct drm_device *dev, void *data,
Modified: head/sys/dev/drm2/drm_crtc.c
==
--- head/sys/dev/drm2/drm_crtc.cWed Jan 21 13:48:06 2015
(r277486)
+++ head/sys/dev/drm2/drm_crtc.cWed Jan 21 16:10:37 2015
(r277487)
@@ -352,7 +352,7 @@ void drm_framebuffer_cleanup(struct drm_
* @funcs: callbacks for the new CRTC
*
* LOCKING:
- * Caller must hold mode config lock.
+ * Takes mode_config lock.
*
* Inits a new object created as base part of an driver crtc object.
*
@@ -372,8 +372,11 @@ int drm_crtc_init(struct drm_device *dev
if (ret)
svn commit: r277488 - head/lib/libthr/thread
Author: kib
Date: Wed Jan 21 16:13:37 2015
New Revision: 277488
URL: https://svnweb.freebsd.org/changeset/base/277488
Log:
Fix bug in r276630. Do not allow pthread_sigmask() to block SIGCANCEL.
Reported and tested by: royger
Sponsored by: The FreeBSD Foundation
MFC after:3 days
Modified:
head/lib/libthr/thread/thr_sig.c
Modified: head/lib/libthr/thread/thr_sig.c
==
--- head/lib/libthr/thread/thr_sig.cWed Jan 21 16:10:37 2015
(r277487)
+++ head/lib/libthr/thread/thr_sig.cWed Jan 21 16:13:37 2015
(r277488)
@@ -604,7 +604,8 @@ __weak_reference(_pthread_sigmask, pthre
int
_pthread_sigmask(int how, const sigset_t *set, sigset_t *oset)
{
- if (_sigprocmask(how, set, oset))
+
+ if (__thr_sigprocmask(how, set, oset))
return (errno);
return (0);
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277489 - head/sys/kern
Author: kib Date: Wed Jan 21 16:32:54 2015 New Revision: 277489 URL: https://svnweb.freebsd.org/changeset/base/277489 Log: Do not assert that the new pipepair mutex is not initialized. The backing memory contains garbage and might trigger the assertion. Reported and tested by: pho Sponsored by: The FreeBSD Foundation MFC after:2 weeks Modified: head/sys/kern/sys_pipe.c Modified: head/sys/kern/sys_pipe.c == --- head/sys/kern/sys_pipe.cWed Jan 21 16:13:37 2015(r277488) +++ head/sys/kern/sys_pipe.cWed Jan 21 16:32:54 2015(r277489) @@ -318,7 +318,7 @@ pipe_zone_init(void *mem, int size, int pp = (struct pipepair *)mem; - mtx_init(&pp->pp_mtx, "pipe mutex", NULL, MTX_DEF); + mtx_init(&pp->pp_mtx, "pipe mutex", NULL, MTX_DEF | MTX_NEW); return (0); } ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277490 - in head/lib/libthr: . arch/amd64 arch/amd64/amd64 arch/amd64/include arch/arm arch/arm/arm arch/arm/include arch/common arch/i386 arch/i386/i386 arch/i386/include arch/mips ar...
Author: andrew
Date: Wed Jan 21 16:41:05 2015
New Revision: 277490
URL: https://svnweb.freebsd.org/changeset/base/277490
Log:
Merge all the copies of _tcb_ctor and _tcb_dtor.
The amd64, i386, and sparc64 versions were identical, with the one
difference where the former two used inline asm instead of _tcb_get. I
have compared the function before and after replacing the asm with _tcb_get
and found the object files to be identical.
The arm, mips, and powerpc versions were almost identical. The only
difference was the powerpc version used an alignment of 1 where arm and
mips used 16. As this is an increase in alignment is will be safe.
Along with this arm, mips, and powerpc all passed, when initial was true,
the value returned from _tcb_get as the first argument to
_rtld_allocate_tls. This would then return this pointer back to the caller.
We can remove these extra calls by checking if initial is set and setting
the thread control block directly. As this is what the sparc64 code does
we can use it directly.
As after these observations all the architectures can now have identical
code we can merge them into a common file.
Differential Revision:https://reviews.freebsd.org/D1556
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Added:
head/lib/libthr/arch/common/
head/lib/libthr/thread/thr_ctrdtr.c
- copied, changed from r277373,
head/lib/libthr/arch/sparc64/sparc64/pthread_md.c
Deleted:
head/lib/libthr/arch/amd64/amd64/pthread_md.c
head/lib/libthr/arch/arm/Makefile.inc
head/lib/libthr/arch/arm/arm/
head/lib/libthr/arch/i386/i386/pthread_md.c
head/lib/libthr/arch/mips/Makefile.inc
head/lib/libthr/arch/mips/mips/
head/lib/libthr/arch/powerpc/Makefile.inc
head/lib/libthr/arch/powerpc/powerpc/
head/lib/libthr/arch/sparc64/sparc64/pthread_md.c
Modified:
head/lib/libthr/Makefile
head/lib/libthr/arch/amd64/Makefile.inc
head/lib/libthr/arch/amd64/include/pthread_md.h
head/lib/libthr/arch/arm/include/pthread_md.h
head/lib/libthr/arch/i386/Makefile.inc
head/lib/libthr/arch/i386/include/pthread_md.h
head/lib/libthr/arch/mips/include/pthread_md.h
head/lib/libthr/arch/powerpc/include/pthread_md.h
head/lib/libthr/arch/sparc64/Makefile.inc
head/lib/libthr/arch/sparc64/include/pthread_md.h
head/lib/libthr/thread/Makefile.inc
head/lib/libthr/thread/thr_private.h
Modified: head/lib/libthr/Makefile
==
--- head/lib/libthr/MakefileWed Jan 21 16:32:54 2015(r277489)
+++ head/lib/libthr/MakefileWed Jan 21 16:41:05 2015(r277490)
@@ -45,7 +45,9 @@ PRECIOUSLIB=
.PATH: ${.CURDIR}/arch/${MACHINE_CPUARCH}/${MACHINE_CPUARCH}
+.if exists(${.CURDIR}/arch/${MACHINE_CPUARCH}/Makefile.inc)
.include "${.CURDIR}/arch/${MACHINE_CPUARCH}/Makefile.inc"
+.endif
.include "${.CURDIR}/sys/Makefile.inc"
.include "${.CURDIR}/thread/Makefile.inc"
Modified: head/lib/libthr/arch/amd64/Makefile.inc
==
--- head/lib/libthr/arch/amd64/Makefile.inc Wed Jan 21 16:32:54 2015
(r277489)
+++ head/lib/libthr/arch/amd64/Makefile.inc Wed Jan 21 16:41:05 2015
(r277490)
@@ -1,3 +1,3 @@
#$FreeBSD$
-SRCS+= pthread_md.c _umtx_op_err.S
+SRCS+= _umtx_op_err.S
Modified: head/lib/libthr/arch/amd64/include/pthread_md.h
==
--- head/lib/libthr/arch/amd64/include/pthread_md.h Wed Jan 21 16:32:54
2015(r277489)
+++ head/lib/libthr/arch/amd64/include/pthread_md.h Wed Jan 21 16:41:05
2015(r277490)
@@ -77,9 +77,6 @@ struct tcb {
__result; \
})
-struct tcb *_tcb_ctor(struct pthread *, int);
-void _tcb_dtor(struct tcb *tcb);
-
static __inline void
_tcb_set(struct tcb *tcb)
{
Modified: head/lib/libthr/arch/arm/include/pthread_md.h
==
--- head/lib/libthr/arch/arm/include/pthread_md.h Wed Jan 21 16:32:54
2015(r277489)
+++ head/lib/libthr/arch/arm/include/pthread_md.h Wed Jan 21 16:41:05
2015(r277490)
@@ -47,12 +47,6 @@ struct tcb {
struct pthread *tcb_thread;/* our hook */
};
-/*
- * The tcb constructors.
- */
-struct tcb *_tcb_ctor(struct pthread *, int);
-void _tcb_dtor(struct tcb *);
-
/* Called from the thread to set its private data. */
static __inline void
_tcb_set(struct tcb *tcb)
Modified: head/lib/libthr/arch/i386/Makefile.inc
==
--- head/lib/libthr/arch/i386/Makefile.inc Wed Jan 21 16:32:54 2015
(r277489)
+++ head/lib/libthr/arch/i386/Makefile.inc Wed Jan 21 16:41:05 2015
(r277490)
@@ -1,3 +1,3 @@
# $FreeBSD$
-SRCS+= pthread_md.c _umtx
svn commit: r277491 - head/sys/dev/ofw
Author: andrew
Date: Wed Jan 21 16:52:24 2015
New Revision: 277491
URL: https://svnweb.freebsd.org/changeset/base/277491
Log:
Update the parsing of the cpu node. We are unable to use the reg property
as the cpu id on arm64 as it may use two cells. In it's place we can use
the device id.
It is expected we will use the reg data on arm64 to enable cores so we
still need to read and store it even if it is not yet used.
Differential Revision:https://reviews.freebsd.org/D1555
Reviewed by: nwhitehorn
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/dev/ofw/ofw_cpu.c
Modified: head/sys/dev/ofw/ofw_cpu.c
==
--- head/sys/dev/ofw/ofw_cpu.c Wed Jan 21 16:41:05 2015(r277490)
+++ head/sys/dev/ofw/ofw_cpu.c Wed Jan 21 16:52:24 2015(r277491)
@@ -51,6 +51,10 @@ static const struct ofw_bus_devinfo *ofw
static MALLOC_DEFINE(M_OFWCPU, "ofwcpu", "OFW CPU device information");
+struct ofw_cpulist_softc {
+ pcell_t sc_addr_cells;
+};
+
static device_method_t ofw_cpulist_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, ofw_cpulist_probe),
@@ -74,7 +78,7 @@ static device_method_t ofw_cpulist_metho
static driver_t ofw_cpulist_driver = {
"cpulist",
ofw_cpulist_methods,
- 0
+ sizeof(struct ofw_cpulist_softc)
};
static devclass_t ofw_cpulist_devclass;
@@ -100,12 +104,18 @@ ofw_cpulist_probe(device_t dev)
static int
ofw_cpulist_attach(device_t dev)
{
+ struct ofw_cpulist_softc *sc;
phandle_t root, child;
device_t cdev;
struct ofw_bus_devinfo *dinfo;
+ sc = device_get_softc(dev);
root = ofw_bus_get_node(dev);
+ sc->sc_addr_cells = 1;
+ OF_getencprop(root, "#address-cells", &sc->sc_addr_cells,
+ sizeof(sc->sc_addr_cells));
+
for (child = OF_child(root); child != 0; child = OF_peer(child)) {
dinfo = malloc(sizeof(*dinfo), M_OFWCPU, M_WAITOK | M_ZERO);
@@ -141,6 +151,8 @@ static int ofw_cpu_read_ivar(device_t de
struct ofw_cpu_softc {
struct pcpu *sc_cpu_pcpu;
uint32_t sc_nominal_mhz;
+ boolean_tsc_reg_valid;
+ pcell_t sc_reg[2];
};
static device_method_t ofw_cpu_methods[] = {
@@ -185,17 +197,39 @@ ofw_cpu_probe(device_t dev)
static int
ofw_cpu_attach(device_t dev)
{
+ struct ofw_cpulist_softc *psc;
struct ofw_cpu_softc *sc;
phandle_t node;
- uint32_t cell;
+ pcell_t cell;
+ int rv;
sc = device_get_softc(dev);
- node = ofw_bus_get_node(dev);
- if (OF_getencprop(node, "reg", &cell, sizeof(cell)) < 0) {
- cell = device_get_unit(dev);
- device_printf(dev, "missing 'reg' property, using %u\n", cell);
+ psc = device_get_softc(device_get_parent(dev));
+
+ if (nitems(sc->sc_reg) < psc->sc_addr_cells) {
+ if (bootverbose)
+ device_printf(dev, "Too many address cells\n");
+ return (EINVAL);
}
- sc->sc_cpu_pcpu = pcpu_find(cell);
+
+ node = ofw_bus_get_node(dev);
+
+ /* Read and validate the reg property for use later */
+ sc->sc_reg_valid = false;
+ rv = OF_getencprop(node, "reg", sc->sc_reg, sizeof(sc->sc_reg));
+ if (rv < 0)
+ device_printf(dev, "missing 'reg' property\n");
+ else if ((rv % 4) != 0) {
+ if (bootverbose)
+ device_printf(dev, "Malformed reg property\n");
+ } else if ((rv / 4) != psc->sc_addr_cells) {
+ if (bootverbose)
+ device_printf(dev, "Invalid reg size %u\n", rv);
+ } else
+ sc->sc_reg_valid = true;
+
+ sc->sc_cpu_pcpu = pcpu_find(device_get_unit(dev));
+
if (OF_getencprop(node, "clock-frequency", &cell, sizeof(cell)) < 0) {
if (bootverbose)
device_printf(dev,
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277492 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: will Date: Wed Jan 21 17:03:11 2015 New Revision: 277492 URL: https://svnweb.freebsd.org/changeset/base/277492 Log: Add vfs.zfs.reference_tracking_enable sysctl/tunable. This is primarily for developer/debugging use; it enables built-in tagged tracking of refcounts inside ZFS. It can only be enabled from the loader, since it modifies how in-core state is managed. Default remains disabled. MFC after:1 week Sponsored by: Spectra Logic Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c == --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c Wed Jan 21 16:52:24 2015(r277491) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/refcount.c Wed Jan 21 17:03:11 2015(r277492) @@ -30,6 +30,10 @@ #ifdef _KERNEL int reference_tracking_enable = FALSE; /* runs out of memory too easily */ +SYSCTL_DECL(_vfs_zfs); +SYSCTL_INT(_vfs_zfs, OID_AUTO, reference_tracking_enable, CTLFLAG_RDTUN, +&reference_tracking_enable, 0, +"Track reference holders to refcount_t objects, used mostly by ZFS"); #else int reference_tracking_enable = TRUE; #endif ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277493 - stable/10/sys/x86/x86
Author: jhb
Date: Wed Jan 21 17:59:32 2015
New Revision: 277493
URL: https://svnweb.freebsd.org/changeset/base/277493
Log:
MFC 272666: Fix build for i386 kernels with out 'I686_CPU'.
Reported by: Mike Tancsa
Modified:
stable/10/sys/x86/x86/local_apic.c
Directory Properties:
stable/10/ (props changed)
Modified: stable/10/sys/x86/x86/local_apic.c
==
--- stable/10/sys/x86/x86/local_apic.c Wed Jan 21 17:03:11 2015
(r277492)
+++ stable/10/sys/x86/x86/local_apic.c Wed Jan 21 17:59:32 2015
(r277493)
@@ -1298,7 +1298,7 @@ apic_init(void *dummy __unused)
printf("APIC: Using the %s enumerator.\n",
best_enum->apic_name);
-#ifndef __amd64__
+#ifdef I686_CPU
/*
* To work around an errata, we disable the local APIC on some
* CPUs during early startup. We need to turn the local APIC back
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277494 - head/sys/kern
Author: mjg
Date: Wed Jan 21 18:02:28 2015
New Revision: 277494
URL: https://svnweb.freebsd.org/changeset/base/277494
Log:
filedesc: fix whitespace nits in fget and fget_read
No functional changes.
Modified:
head/sys/kern/kern_descrip.c
Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cWed Jan 21 17:59:32 2015
(r277493)
+++ head/sys/kern/kern_descrip.cWed Jan 21 18:02:28 2015
(r277494)
@@ -2499,7 +2499,7 @@ int
fget(struct thread *td, int fd, cap_rights_t *rightsp, struct file **fpp)
{
- return(_fget(td, fd, fpp, 0, rightsp, NULL));
+ return (_fget(td, fd, fpp, 0, rightsp, NULL));
}
int
@@ -2514,7 +2514,7 @@ int
fget_read(struct thread *td, int fd, cap_rights_t *rightsp, struct file **fpp)
{
- return(_fget(td, fd, fpp, FREAD, rightsp, NULL));
+ return (_fget(td, fd, fpp, FREAD, rightsp, NULL));
}
int
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277495 - head/sys/kern
Author: mjg
Date: Wed Jan 21 18:05:42 2015
New Revision: 277495
URL: https://svnweb.freebsd.org/changeset/base/277495
Log:
filedesc: return 0 from badfo_close
The only potential in-tree consumer (_fdrop) special-cased it and returns 0
0 on its own instead of calling badfo_close.
Remove the special case since it is not needed and very unlikely to encounter
anyway.
No objections from: kib
Modified:
head/sys/kern/kern_descrip.c
Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cWed Jan 21 18:02:28 2015
(r277494)
+++ head/sys/kern/kern_descrip.cWed Jan 21 18:05:42 2015
(r277495)
@@ -2680,11 +2680,9 @@ _fdrop(struct file *fp, struct thread *t
{
int error;
- error = 0;
if (fp->f_count != 0)
panic("fdrop: count %d", fp->f_count);
- if (fp->f_ops != &badfileops)
- error = fo_close(fp, td);
+ error = fo_close(fp, td);
atomic_subtract_int(&openfiles, 1);
crfree(fp->f_cred);
free(fp->f_advice, M_FADVISE);
@@ -3664,7 +3662,7 @@ static int
badfo_close(struct file *fp, struct thread *td)
{
- return (EBADF);
+ return (0);
}
static int
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
Sean, On Tue, Jan 20, 2015 at 04:22:44PM -0800, Sean Bruno wrote: S> In our universe, this commit (right or wrong) resolved our panics. I S> think that there is some room for improvement based on the commentary S> in this thread, but some people do indeed prefer stability over S> performance. I hope we can come to a middle ground somewhere here. Sorry, but this sounds very much like alchemy. We poured this stuff into that stuff and yield in gold precipitate. We don't understand what's going on, but let's record the recipe into our tome of aclhemy wisdom. So alchemy never came to a scientific level, and chemistry evolved as science only when researchers started to measure, explain and understand. If we treat our precious kernel in alchemy way, we will follow the path of alchemy, except that it took centuries for alchemy to die, and for a software product it would take a few years. So, for me Kip ideas sound very sensible. There could be a race somewhere else. You tweak callout subsystem in any direction, timings of events in kernel shift, your race is hidden. If we fix problems w/o understanding them, we are going alchemy way. -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277486 - head/share/man/man9
On Wed, Jan 21, 2015 at 01:48:06PM +, Gavin Atkinson wrote: G> Author: gavin G> Date: Wed Jan 21 13:48:06 2015 G> New Revision: 277486 G> URL: https://svnweb.freebsd.org/changeset/base/277486 G> G> Log: G> "softc" is short for "software context", use that phrase in the G> device_get_softc(9) man page. Thanks for making this term official :) -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277489 - head/sys/kern
On Wed, Jan 21, 2015 at 04:32:55PM +, Konstantin Belousov wrote: K> Author: kib K> Date: Wed Jan 21 16:32:54 2015 K> New Revision: 277489 K> URL: https://svnweb.freebsd.org/changeset/base/277489 K> K> Log: K> Do not assert that the new pipepair mutex is not initialized. The K> backing memory contains garbage and might trigger the assertion. I have touched dozen of places in kernel where I do explicit M_ZERO on allocation just to satisfy later assertion in the mtx_init. Is the correct fix to use MTX_NEW? -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277486 - head/share/man/man9
On Wed, Jan 21, 2015 at 10:22 AM, Gleb Smirnoff wrote: > On Wed, Jan 21, 2015 at 01:48:06PM +, Gavin Atkinson wrote: > G> Author: gavin > G> Date: Wed Jan 21 13:48:06 2015 > G> New Revision: 277486 > G> URL: https://svnweb.freebsd.org/changeset/base/277486 > G> > G> Log: > G> "softc" is short for "software context", use that phrase in the > G> device_get_softc(9) man page. > > Thanks for making this term official :) Heh, yes. Thanks Gavin! cheers, Hiren ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277496 - head/sys/kern
Author: mjg
Date: Wed Jan 21 18:32:53 2015
New Revision: 277496
URL: https://svnweb.freebsd.org/changeset/base/277496
Log:
filedesc: avoid spurious copying of capabilities in fget_unlocked
We obtain a stable copy and store it in local 'fde' variable. Storing another
copy (based on aforementioned variable) does not serve any purpose.
No functional changes.
Modified:
head/sys/kern/kern_descrip.c
Modified: head/sys/kern/kern_descrip.c
==
--- head/sys/kern/kern_descrip.cWed Jan 21 18:05:42 2015
(r277495)
+++ head/sys/kern/kern_descrip.cWed Jan 21 18:32:53 2015
(r277496)
@@ -2337,7 +2337,7 @@ fget_unlocked(struct filedesc *fdp, int
u_int count;
#ifdef CAPABILITIES
seq_t seq;
- cap_rights_t haverights;
+ cap_rights_t *haverights;
int error;
#endif
@@ -2367,9 +2367,9 @@ fget_unlocked(struct filedesc *fdp, int
if (fp == NULL)
return (EBADF);
#ifdef CAPABILITIES
- haverights = *cap_rights_fde(&fde);
+ haverights = cap_rights_fde(&fde);
if (needrightsp != NULL) {
- error = cap_check(&haverights, needrightsp);
+ error = cap_check(haverights, needrightsp);
if (error != 0)
return (error);
if (cap_rights_is_set(needrightsp, CAP_FCNTL)) {
@@ -2408,7 +2408,7 @@ fget_unlocked(struct filedesc *fdp, int
*fpp = fp;
if (haverightsp != NULL) {
#ifdef CAPABILITIES
- *haverightsp = haverights;
+ *haverightsp = *haverights;
#else
CAP_ALL(haverightsp);
#endif
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277487 - in head/sys: dev/drm2 dev/drm2/i915 dev/drm2/radeon modules/drm2/i915kms
On Wed, 2015-01-21 at 16:10 +, Konstantin Belousov wrote: > Author: kib > Date: Wed Jan 21 16:10:37 2015 > New Revision: 277487 > URL: https://svnweb.freebsd.org/changeset/base/277487 > > Log: > An update for the i915 GPU driver, which brings the code up to Linux > commit 4d93914ae3db4a897ead4b. Some related drm infrastructure > changes are imported as needed. > > Biggest update is the rewrite of the i915 gem io to more closely > follow Linux model, althought the mechanism used by FreeBSD port is > different. Hey Kostik, This causes my Haswell laptop to just display a blank screen on bootup. Is there something I should be doing? I just have i915kms_load="YES" in /boot/loader.conf. Thanks, Shawn signature.asc Description: This is a digitally signed message part
svn commit: r277497 - head
Author: emaste
Date: Wed Jan 21 19:04:55 2015
New Revision: 277497
URL: https://svnweb.freebsd.org/changeset/base/277497
Log:
Remove addr2line from cross elftoolchain tools list
It is not required, and there is no reason to install it just because it
came with the binutils cross tools.
Sponsored by: The FreeBSD Foundation
Modified:
head/Makefile.inc1
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Jan 21 18:32:53 2015(r277496)
+++ head/Makefile.inc1 Wed Jan 21 19:04:55 2015(r277497)
@@ -1428,7 +1428,6 @@ _binutils=gnu/usr.bin/binutils
.endif
.if ${MK_ELFTOOLCHAIN_TOOLS} != "no"
_elftctools= lib/libelftc \
- usr.bin/addr2line \
usr.bin/elfcopy \
usr.bin/nm \
usr.bin/size \
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277498 - in head/sys/powerpc: aim include
Author: nwhitehorn Date: Wed Jan 21 19:07:45 2015 New Revision: 277498 URL: https://svnweb.freebsd.org/changeset/base/277498 Log: Make 64-bit AIM trap handlers relocatable by changing all absolute branch instructions to call through pointers instead. In general, these are set implicitly through relocation processing. One has to be set explicitly in machdep.c, however, to fit one handler in the tiny (8 instruction) space available. Reviewed by: andreast Differential revision:D1554 Tested on:UP and SMP G5, Cell, POWER5+ Modified: head/sys/powerpc/aim/machdep.c head/sys/powerpc/aim/trap_subr64.S head/sys/powerpc/include/trap.h Modified: head/sys/powerpc/aim/machdep.c == --- head/sys/powerpc/aim/machdep.c Wed Jan 21 19:04:55 2015 (r277497) +++ head/sys/powerpc/aim/machdep.c Wed Jan 21 19:07:45 2015 (r277498) @@ -238,7 +238,7 @@ extern void *trapcode64; #endif extern void*rstcode, *rstsize; -extern void*trapcode, *trapsize; +extern void*trapcode, *trapsize, *trapcode2; extern void*slbtrap, *slbtrapsize; extern void*alitrap, *alisize; extern void*dsitrap, *dsisize; @@ -506,6 +506,7 @@ powerpc_init(vm_offset_t fdt, vm_offset_ generictrap = &trapcode; /* Set TOC base so that the interrupt code can get at it */ + *((void **)TRAP_GENTRAP) = &trapcode2; *((register_t *)TRAP_TOCBASE) = toc; #endif Modified: head/sys/powerpc/aim/trap_subr64.S == --- head/sys/powerpc/aim/trap_subr64.S Wed Jan 21 19:04:55 2015 (r277497) +++ head/sys/powerpc/aim/trap_subr64.S Wed Jan 21 19:07:45 2015 (r277498) @@ -302,8 +302,13 @@ CNAME(rstcode): insrdi %r9,%r8,1,0 mtmsrd %r9 isync + bl 1f + .llong cpu_reset +1: mflr%r9 + ld %r9,0(%r9) + mtlr%r9 - ba cpu_reset + blr CNAME(rstsize) = . - CNAME(rstcode) cpu_reset: @@ -342,16 +347,20 @@ cpu_reset: /* * This code gets copied to all the trap vectors - * (except ISI/DSI, ALI, and the interrupts) + * (except ISI/DSI, ALI, and the interrupts). Has to fit in 8 instructions! */ .globl CNAME(trapcode),CNAME(trapsize) + .p2align 3 CNAME(trapcode): mtsprg1 %r1 /* save SP */ mflr%r1 /* Save the old LR in r1 */ mtsprg2 %r1 /* And then in SPRG2 */ + li %r1,TRAP_GENTRAP + ld %r1,0(%r1) + mtlr%r1 li %r1, 0xA0 /* How to get the vector from LR */ - bla generictrap /* LR & SPRG3 is exception # */ + blrl/* Branch to generictrap */ CNAME(trapsize) = .-CNAME(trapcode) /* @@ -361,6 +370,7 @@ CNAME(trapsize) = .-CNAME(trapcode) * the only time this can be called. */ .globl CNAME(slbtrap),CNAME(slbtrapsize) + .p2align 3 CNAME(slbtrap): mtsprg1 %r1 /* save SP */ GET_CPUINFO(%r1) @@ -369,17 +379,31 @@ CNAME(slbtrap): std %r2,(PC_SLBSAVE+104)(%r1) mfsrr1 %r2 /* test kernel mode */ mtcr%r2 - bf 17,1f /* branch if PSL_PR is false */ + bf 17,2f /* branch if PSL_PR is false */ /* User mode */ ld %r2,(PC_SLBSAVE+104)(%r1) /* Restore CR */ mtcr%r2 ld %r2,(PC_SLBSAVE+16)(%r1) /* Restore R2 */ mflr%r1 /* Save the old LR in r1 */ mtsprg2 %r1 /* And then in SPRG2 */ + /* 52 bytes so far */ + bl 1f + .llong generictrap +1: mflr%r1 + ld %r1,0(%r1) + mtlr%r1 li %r1, 0x80 /* How to get the vector from LR */ - bla generictrap /* LR & SPRG3 is exception # */ -1: mflr%r2 /* Save the old LR in r2 */ - bla kern_slbtrap + blrl/* Branch to generictrap */ + /* 84 bytes */ +2: mflr%r2 /* Save the old LR in r2 */ + nop + bl 3f /* Begin dance to jump to kern_slbtrap*/ + .llong kern_slbtrap +3: mflr%r1 + ld %r1,0(%r1) + mtlr%r1 + GET_CPUINFO(%r1) + blrl/* 124 bytes -- 4 to spare */ CNAME(slbtrapsize) = .-CNAME(slbtrap) kern_slbtrap: @@ -518,6 +542,16 @@ CNAME(alitrap): mflr%r28/* save LR */ mfcr%r29/* save CR */ + /* Begin dance to branch to s_trap in a bit */ + b 1f + .p2align
svn commit: r277499 - in head/sys/powerpc: aim powerpc
Author: nwhitehorn
Date: Wed Jan 21 19:09:15 2015
New Revision: 277499
URL: https://svnweb.freebsd.org/changeset/base/277499
Log:
Make sure to relocate tmpstk with everything else and avoid processing
non-relative relocations that the UART code makes for absent modules.
Modified:
head/sys/powerpc/aim/locore64.S
head/sys/powerpc/powerpc/elf64_machdep.c
Modified: head/sys/powerpc/aim/locore64.S
==
--- head/sys/powerpc/aim/locore64.S Wed Jan 21 19:07:45 2015
(r277498)
+++ head/sys/powerpc/aim/locore64.S Wed Jan 21 19:09:15 2015
(r277499)
@@ -126,9 +126,14 @@ ASENTRY_NOPROF(__start)
ld %r1,0(%r2)
add %r2,%r1,%r2
+ /* Get load offset */
+ ld %r31,-0x8000(%r2) /* First TOC entry is TOC base */
+ subf%r31,%r31,%r2 /* Subtract from real TOC base to get base */
+
/* Set up the stack pointer */
ld %r1,TOC_REF(tmpstk)(%r2)
addi%r1,%r1,TMPSTKSZ-96
+ add %r1,%r1,%r31
/* Relocate kernel */
std %r3,48(%r1)
@@ -140,8 +145,7 @@ ASENTRY_NOPROF(__start)
1: mflr%r3
ld %r4,0(%r3)
add %r3,%r4,%r3
- ld %r4,-0x8000(%r2) /* First TOC entry is TOC base */
- subf%r4,%r4,%r2 /* Subtract from real TOC base to get base */
+ mr %r4,%r31
bl elf_reloc_self
nop
ld %r3,48(%r1)
Modified: head/sys/powerpc/powerpc/elf64_machdep.c
==
--- head/sys/powerpc/powerpc/elf64_machdep.cWed Jan 21 19:07:45 2015
(r277498)
+++ head/sys/powerpc/powerpc/elf64_machdep.cWed Jan 21 19:09:15 2015
(r277499)
@@ -226,6 +226,8 @@ elf_reloc_self(Elf_Dyn *dynp, Elf_Addr r
*/
relalim = (Elf_Rela *)((caddr_t)rela + relasz);
for (; rela < relalim; rela++) {
+ if (ELF_R_TYPE(rela->r_info) != R_PPC_RELATIVE)
+ continue;
where = (Elf_Addr *)(relocbase + rela->r_offset);
*where = (Elf_Addr)(relocbase + rela->r_addend);
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277500 - head/sys/powerpc/aim
Author: nwhitehorn Date: Wed Jan 21 19:11:15 2015 New Revision: 277500 URL: https://svnweb.freebsd.org/changeset/base/277500 Log: Add POWER7+ and POWER8 to the list of CPUs with 32 SLB slots. This is mostly a no-op since all currently-supported instances of these CPUs give the number of SLB slots in the device tree, but keep it here as well just in case. Modified: head/sys/powerpc/aim/machdep.c Modified: head/sys/powerpc/aim/machdep.c == --- head/sys/powerpc/aim/machdep.c Wed Jan 21 19:09:15 2015 (r277499) +++ head/sys/powerpc/aim/machdep.c Wed Jan 21 19:11:15 2015 (r277500) @@ -394,6 +394,9 @@ powerpc_init(vm_offset_t fdt, vm_offset_ break; #ifdef __powerpc64__ case IBMPOWER7: + case IBMPOWER7PLUS: + case IBMPOWER8: + case IBMPOWER8E: /* XXX: get from ibm,slb-size in device tree */ n_slbs = 32; break; ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277501 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: will
Date: Wed Jan 21 19:20:36 2015
New Revision: 277501
URL: https://svnweb.freebsd.org/changeset/base/277501
Log:
Eliminate an #ifdef illumos for zfs_ioc_rename().
Since allow_mounted is a FreeBSD-specific change, default to B_TRUE, then
locally check for the magic bit. Unconditionally check allow_mounted below.
Convert the setting of allow_mounted to an explicit boolean.
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 672578 (in part) on 2013/07/19
Modified:
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Wed Jan
21 19:11:15 2015(r277500)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c Wed Jan
21 19:20:36 2015(r277501)
@@ -3751,10 +3751,12 @@ static int
zfs_ioc_rename(zfs_cmd_t *zc)
{
boolean_t recursive = zc->zc_cookie & 1;
+ char *at;
+ boolean_t allow_mounted = B_TRUE;
+
#ifdef __FreeBSD__
- boolean_t allow_mounted = zc->zc_cookie & 2;
+ allow_mounted = (zc->zc_cookie & 2) != 0;
#endif
- char *at;
zc->zc_value[sizeof (zc->zc_value) - 1] = '\0';
if (dataset_namecheck(zc->zc_value, NULL, NULL) != 0 ||
@@ -3769,11 +3771,7 @@ zfs_ioc_rename(zfs_cmd_t *zc)
if (strncmp(zc->zc_name, zc->zc_value, at - zc->zc_name + 1))
return (SET_ERROR(EXDEV));
*at = '\0';
-#ifdef illumos
- if (zc->zc_objset_type == DMU_OST_ZFS) {
-#else
if (zc->zc_objset_type == DMU_OST_ZFS && allow_mounted) {
-#endif
error = dmu_objset_find(zc->zc_name,
recursive_unmount, at + 1,
recursive ? DS_FIND_CHILDREN : 0);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277502 - head/sys/arm/ti
Author: gonzo
Date: Wed Jan 21 19:23:46 2015
New Revision: 277502
URL: https://svnweb.freebsd.org/changeset/base/277502
Log:
Remove "#define DEBUG" that conflicts with "option DEBUG" in kernel config
Modified:
head/sys/arm/ti/ti_mbox.c
head/sys/arm/ti/ti_pruss.c
Modified: head/sys/arm/ti/ti_mbox.c
==
--- head/sys/arm/ti/ti_mbox.c Wed Jan 21 19:20:36 2015(r277501)
+++ head/sys/arm/ti/ti_mbox.c Wed Jan 21 19:23:46 2015(r277502)
@@ -54,7 +54,6 @@ __FBSDID("$FreeBSD$");
#include "mbox_if.h"
-#define DEBUG
#ifdef DEBUG
#defineDPRINTF(fmt, ...) do {\
printf("%s: ", __func__); \
Modified: head/sys/arm/ti/ti_pruss.c
==
--- head/sys/arm/ti/ti_pruss.c Wed Jan 21 19:20:36 2015(r277501)
+++ head/sys/arm/ti/ti_pruss.c Wed Jan 21 19:23:46 2015(r277502)
@@ -52,7 +52,6 @@ __FBSDID("$FreeBSD$");
#include
#include
-#define DEBUG
#ifdef DEBUG
#defineDPRINTF(fmt, ...) do {\
printf("%s: ", __func__); \
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277503 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: will
Date: Wed Jan 21 19:25:57 2015
New Revision: 277503
URL: https://svnweb.freebsd.org/changeset/base/277503
Log:
Ignore sync requests from the system syncher, i.e. VFS_SYNC(waitfor=MNT_LAZY).
ZFS already commits outstanding data every zfs_txg_timeout seconds, so these
syncs are unnecessarily intrusive.
Submitted by: gibbs
Sponsored by: Spectra Logic
MFSpectraBSD: 1105759 on 2014/12/11
Modified:
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.cWed Jan
21 19:23:46 2015(r277502)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.cWed Jan
21 19:25:57 2015(r277503)
@@ -132,6 +132,13 @@ zfs_sync(vfs_t *vfsp, int waitfor)
if (panicstr)
return (0);
+ /*
+* Ignore the system syncher. ZFS already commits async data
+* at zfs_txg_timeout intervals.
+*/
+ if (waitfor == MNT_LAZY)
+ return (0);
+
if (vfsp != NULL) {
/*
* Sync a specific filesystem.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277504 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Author: will
Date: Wed Jan 21 19:30:01 2015
New Revision: 277504
URL: https://svnweb.freebsd.org/changeset/base/277504
Log:
Remove commented log messages.
Modified:
head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c
Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c
==
--- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c Wed Jan 21
19:25:57 2015(r277503)
+++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c Wed Jan 21
19:30:01 2015(r277504)
@@ -2090,7 +2090,6 @@ zil_replay(objset_t *os, void *arg, zil_
zil_destroy(zilog, B_TRUE);
return;
}
- //printf("ZFS: Replaying ZIL on %s...\n", os->os->os_spa->spa_name);
zr.zr_replay = replay_func;
zr.zr_arg = arg;
@@ -2112,7 +2111,6 @@ zil_replay(objset_t *os, void *arg, zil_
zil_destroy(zilog, B_FALSE);
txg_wait_synced(zilog->zl_dmu_pool, zilog->zl_destroy_txg);
zilog->zl_replay = B_FALSE;
- //printf("ZFS: Replay of ZIL on %s finished.\n",
os->os->os_spa->spa_name);
}
boolean_t
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 21 January 2015 at 10:15, Gleb Smirnoff wrote: > Sean, > > On Tue, Jan 20, 2015 at 04:22:44PM -0800, Sean Bruno wrote: > S> In our universe, this commit (right or wrong) resolved our panics. I > S> think that there is some room for improvement based on the commentary > S> in this thread, but some people do indeed prefer stability over > S> performance. I hope we can come to a middle ground somewhere here. > > Sorry, but this sounds very much like alchemy. We poured this stuff > into that stuff and yield in gold precipitate. We don't understand > what's going on, but let's record the recipe into our tome of aclhemy > wisdom. > > So alchemy never came to a scientific level, and chemistry evolved > as science only when researchers started to measure, explain and > understand. > > If we treat our precious kernel in alchemy way, we will follow > the path of alchemy, except that it took centuries for alchemy to > die, and for a software product it would take a few years. > > So, for me Kip ideas sound very sensible. There could be a race > somewhere else. You tweak callout subsystem in any direction, > timings of events in kernel shift, your race is hidden. > > If we fix problems w/o understanding them, we are going alchemy way. Hi, I don't think it's quite this bad. 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 from one callwheel to another. Now we have fallout which we can either address or back out until the callout stuff is again reviewed/fixed. I don't think it's as alchemic as is being promoted. -a ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277505 - head/sys/dev/dcons
Author: will
Date: Wed Jan 21 19:53:52 2015
New Revision: 277505
URL: https://svnweb.freebsd.org/changeset/base/277505
Log:
Garbage collect dragonfly and legacy FreeBSD system support from dcons(4).
Submitted by: gibbs
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1110990 on 2015/01/06
Modified:
head/sys/dev/dcons/dcons.c
head/sys/dev/dcons/dcons_crom.c
head/sys/dev/dcons/dcons_os.h
Modified: head/sys/dev/dcons/dcons.c
==
--- head/sys/dev/dcons/dcons.c Wed Jan 21 19:30:01 2015(r277504)
+++ head/sys/dev/dcons/dcons.c Wed Jan 21 19:53:52 2015(r277505)
@@ -37,11 +37,9 @@
#include
-#if defined(__DragonFly__) || defined(_BOOT)
-#include "dcons.h"
#if defined(_BOOT)
+#include "dcons.h"
#include "stand.h"
-#endif
#else
#include
#endif
Modified: head/sys/dev/dcons/dcons_crom.c
==
--- head/sys/dev/dcons/dcons_crom.c Wed Jan 21 19:30:01 2015
(r277504)
+++ head/sys/dev/dcons/dcons_crom.c Wed Jan 21 19:53:52 2015
(r277505)
@@ -46,40 +46,25 @@
#include
#include
-#ifdef __DragonFly__
-#include
-#include
-#include
-#include "dcons.h"
-#include "dcons_os.h"
-#else
#include
#include
#include
#include
#include
-#endif
#include
-#define EXPOSE_IDT_ADDR 1
-
-#if (defined(__i386__) || defined(__amd64__)) && defined(EXPOSE_IDT_ADDR)
+#if (defined(__i386__) || defined(__amd64__))
#include
#include
#include
#include /* for idt */
#endif
+
static bus_addr_t dcons_paddr;
-#if __FreeBSD_version >= 50
static int force_console = 0;
TUNABLE_INT("hw.firewire.dcons_crom.force_console", &force_console);
-#endif
-
-#ifndef CSRVAL_VENDOR_PRIVATE
-#define NEED_NEW_DRIVER
-#endif
#define ADDR_HI(x) (((x) >> 24) & 0xff)
#define ADDR_LO(x) ((x) & 0xff)
@@ -115,8 +100,7 @@ dcons_crom_probe(device_t dev)
return (0);
}
-#ifndef NEED_NEW_DRIVER
-#if (defined(__i386__) || defined(__amd64__)) && defined(EXPOSE_IDT_ADDR)
+#if (defined(__i386__) || defined(__amd64__))
static void
dcons_crom_expose_idt(struct dcons_crom_softc *sc)
{
@@ -129,6 +113,7 @@ dcons_crom_expose_idt(struct dcons_crom_
crom_add_entry(&sc->unit, DCONS_CSR_KEY_RESET_LO, ADDR_LO(idt_paddr));
}
#endif
+
static void
dcons_crom_post_busreset(void *arg)
{
@@ -149,11 +134,10 @@ dcons_crom_post_busreset(void *arg)
crom_add_simple_text(src, &sc->unit, &sc->ver, "dcons");
crom_add_entry(&sc->unit, DCONS_CSR_KEY_HI, ADDR_HI(dcons_paddr));
crom_add_entry(&sc->unit, DCONS_CSR_KEY_LO, ADDR_LO(dcons_paddr));
-#if (defined(__i386__) || defined(__amd64__)) && defined(EXPOSE_IDT_ADDR)
+#if (defined(__i386__) || defined(__amd64__))
dcons_crom_expose_idt(sc);
#endif
}
-#endif
static void
dmamap_cb(void *arg, bus_dma_segment_t *segments, int seg, int error)
@@ -168,11 +152,7 @@ dmamap_cb(void *arg, bus_dma_segment_t *
bus_dmamap_sync(sc->dma_tag, sc->dma_map, BUS_DMASYNC_PREWRITE);
device_printf(sc->fd.dev,
-#if __FreeBSD_version < 50
- "bus_addr 0x%x\n", sc->bus_addr);
-#else
"bus_addr 0x%jx\n", (uintmax_t)sc->bus_addr);
-#endif
if (dcons_paddr != 0) {
/* XXX */
device_printf(sc->fd.dev, "dcons_paddr is already set\n");
@@ -182,11 +162,9 @@ dmamap_cb(void *arg, bus_dma_segment_t *
dcons_conf->dma_map = sc->dma_map;
dcons_paddr = sc->bus_addr;
-#if __FreeBSD_version >= 50
/* Force to be the high-level console */
if (force_console)
cnselect(dcons_conf->cdev);
-#endif
}
static void
@@ -200,10 +178,6 @@ dcons_crom_poll(void *p, int arg)
static int
dcons_crom_attach(device_t dev)
{
-#ifdef NEED_NEW_DRIVER
- printf("dcons_crom: you need newer firewire driver\n");
- return (-1);
-#else
struct dcons_crom_softc *sc;
int error;
@@ -227,10 +201,8 @@ dcons_crom_attach(device_t dev)
/*nsegments*/ 1,
/*maxsegsz*/ BUS_SPACE_MAXSIZE_32BIT,
/*flags*/ BUS_DMA_ALLOCNOW,
-#if __FreeBSD_version >= 501102
/*lockfunc*/busdma_lock_mutex,
/*lockarg*/&Giant,
-#endif
&sc->dma_tag);
if (error != 0)
return (error);
@@ -245,7 +217,6 @@ dcons_crom_attach(device_t dev)
sc->ehand = EVENTHANDLER_REGISTER(dcons_poll, dcons_crom_poll,
(void *)sc, 0);
return (0);
-#endif
}
static int
Modified: head/sys/dev/dcons/dcons_os.h
==
--- head/sys/dev/dcons/dcons_os.h Wed Jan 21 19:30:01 2015
(r277504)
+++ head/sys/dev/dcons/dcons_os.h Wed Jan 21 19:53:52 2015
(r277505)
@@ -34,7 +34,6 @@
* $FreeBSD$
*/
-
typedef void (*dcons_poll_fn)(v
Re: svn commit: r276076 - in stable/10/sys: amd64/amd64 i386/i386 i386/include i386/xen pc98/pc98 x86/x86
On Friday, January 16, 2015 02:42:32 PM Mike Tancsa wrote: > Hi, > I noticed while building a new ALIX_DSK kernel image for my i386 > PCEngines alix box, the commit below no longer allows a kernel to be > built without cpu I686_CPU as a kernel option. > > Is this a known side effect ? The default kernel def in > /usr/src/tools/tools/nanobsd/pcengines/ALIX_DSK should be updated then. Oops, should be fixed, sorry! -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277506 - head/sys/dev/firewire
Author: will Date: Wed Jan 21 19:59:09 2015 New Revision: 277506 URL: https://svnweb.freebsd.org/changeset/base/277506 Log: Fix one cause of firewire panics. sys/dev/firewire/firewire.c: In fw_xfer_unload(), clear the FWXF_INQ flag on the xfer under protection of the FW_GMTX, after the xfer is removeed from the tx/rx queue. Otherwise it is possible for the xfer to be removed again (corrupting the list or immediately panicing) from another thread that has found this xfer in the transaction label table. Submitted by: gibbs MFC after:1 week Sponsored by: Spectra Logic MFSpectraBSD: 1110200 on 2015/01/02 Modified: head/sys/dev/firewire/firewire.c Modified: head/sys/dev/firewire/firewire.c == --- head/sys/dev/firewire/firewire.cWed Jan 21 19:53:52 2015 (r277505) +++ head/sys/dev/firewire/firewire.cWed Jan 21 19:59:09 2015 (r277506) @@ -1166,6 +1166,7 @@ fw_xfer_unload(struct fw_xfer *xfer) s = splfw(); FW_GLOCK(xfer->fc); STAILQ_REMOVE(&xfer->q->q, xfer, fw_xfer, link); + xfer->flag &= ~FWXF_INQ; #if 0 xfer->q->queued--; #endif ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277507 - head/sys/dev/firewire
Author: will
Date: Wed Jan 21 20:02:16 2015
New Revision: 277507
URL: https://svnweb.freebsd.org/changeset/base/277507
Log:
Fix a FWXF_INQ race in the firewire driver.
sys/dev/firewire/firewire.c:
In fw_xfer_unload() expand lock coverage so that
the test for FWXF_INQ doesn't race with it being
cleared in another thread.
Submitted by: gibbs
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1110207 on 2015/01/02
Modified:
head/sys/dev/firewire/firewire.c
Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 19:59:09 2015
(r277506)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 20:02:16 2015
(r277507)
@@ -1022,9 +1022,7 @@ static void
fw_tl_free(struct firewire_comm *fc, struct fw_xfer *xfer)
{
struct fw_xfer *txfer;
- int s;
- s = splfw();
mtx_lock(&fc->tlabel_lock);
if (xfer->tl < 0) {
mtx_unlock(&fc->tlabel_lock);
@@ -1042,14 +1040,12 @@ fw_tl_free(struct firewire_comm *fc, str
fw_dump_hdr(&xfer->recv.hdr, "recv");
kdb_backtrace();
mtx_unlock(&fc->tlabel_lock);
- splx(s);
return;
}
STAILQ_REMOVE(&fc->tlabels[xfer->tl], xfer, fw_xfer, tlabel);
xfer->tl = -1;
mtx_unlock(&fc->tlabel_lock);
- splx(s);
return;
}
@@ -1157,22 +1153,18 @@ fw_xfer_done(struct fw_xfer *xfer)
void
fw_xfer_unload(struct fw_xfer *xfer)
{
- int s;
if (xfer == NULL)
return;
+ FW_GLOCK(xfer->fc);
if (xfer->flag & FWXF_INQ) {
- printf("fw_xfer_free FWXF_INQ\n");
- s = splfw();
- FW_GLOCK(xfer->fc);
STAILQ_REMOVE(&xfer->q->q, xfer, fw_xfer, link);
xfer->flag &= ~FWXF_INQ;
#if 0
xfer->q->queued--;
#endif
- FW_GUNLOCK(xfer->fc);
- splx(s);
}
+ FW_GUNLOCK(xfer->fc);
if (xfer->fc != NULL) {
/*
* Ensure that any tlabel owner can't access this
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277508 - head/sys/dev/firewire
Author: will
Date: Wed Jan 21 20:03:46 2015
New Revision: 277508
URL: https://svnweb.freebsd.org/changeset/base/277508
Log:
Fix panic in firewire and creation of invalid config ROM.
sys/boot/i386/libfirewire/firewire.c:
sys/dev/firewire/firewire.c:
Fix configuration ROM generation count wrapping logic
so that the generation count is never outside of
allowed limits (0x2 -> 0xF).
sys/dev/firewire/firewire.c:
In fw_xfer_unload(), xfer->fc may be NULL. Protect
against this before taking the fc lock.
Submitted by: gibbs
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1110685 on 2015/01/05
Modified:
head/sys/dev/firewire/firewire.c
Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 20:02:16 2015
(r277507)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 20:03:46 2015
(r277508)
@@ -761,8 +761,15 @@ fw_busreset(struct firewire_comm *fc, ui
src = &fc->crom_src_buf->src;
crom_load(src, newrom, CROMSIZE);
if (bcmp(newrom, fc->config_rom, CROMSIZE) != 0) {
- if (src->businfo.generation++ > FW_MAX_GENERATION)
+ /* Bump generation and reload. */
+ src->businfo.generation++;
+
+ /* Handle generation count wraps. */
+ if (src->businfo.generation < FW_GENERATION_CHANGEABLE)
src->businfo.generation = FW_GENERATION_CHANGEABLE;
+
+ /* Recalculate CRC to account for generation change. */
+ crom_load(src, newrom, CROMSIZE);
bcopy(newrom, fc->config_rom, CROMSIZE);
}
free(newrom, M_FW);
@@ -1156,16 +1163,18 @@ fw_xfer_unload(struct fw_xfer *xfer)
if (xfer == NULL)
return;
- FW_GLOCK(xfer->fc);
- if (xfer->flag & FWXF_INQ) {
- STAILQ_REMOVE(&xfer->q->q, xfer, fw_xfer, link);
- xfer->flag &= ~FWXF_INQ;
-#if 0
- xfer->q->queued--;
-#endif
- }
- FW_GUNLOCK(xfer->fc);
+
if (xfer->fc != NULL) {
+ FW_GLOCK(xfer->fc);
+ if (xfer->flag & FWXF_INQ) {
+ STAILQ_REMOVE(&xfer->q->q, xfer, fw_xfer, link);
+ xfer->flag &= ~FWXF_INQ;
+ #if 0
+ xfer->q->queued--;
+ #endif
+ }
+ FW_GUNLOCK(xfer->fc);
+
/*
* Ensure that any tlabel owner can't access this
* xfer after it's freed.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277509 - head/sys/dev/firewire
Author: will
Date: Wed Jan 21 20:05:10 2015
New Revision: 277509
URL: https://svnweb.freebsd.org/changeset/base/277509
Log:
Properly lock accesss to the firewire_comm->devices list.
sys/dev/firewire/firewire.c:
Add missing FW_GLOCK/UNLOCK() usage to fw_noderesolve_nodeid().
sys/dev/firewire/firewire.c:
sys/dev/firewire/fwmem.c:
Remove no-op splfw() calls from functions that have been
audited for proper lock usage.
Submitted by: gibbs
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1110992 on 2015/01/06
Modified:
head/sys/dev/firewire/firewire.c
head/sys/dev/firewire/fwmem.c
Modified: head/sys/dev/firewire/firewire.c
==
--- head/sys/dev/firewire/firewire.cWed Jan 21 20:03:46 2015
(r277508)
+++ head/sys/dev/firewire/firewire.cWed Jan 21 20:05:10 2015
(r277509)
@@ -146,13 +146,12 @@ struct fw_device *
fw_noderesolve_nodeid(struct firewire_comm *fc, int dst)
{
struct fw_device *fwdev;
- int s;
- s = splfw();
+ FW_GLOCK(fc);
STAILQ_FOREACH(fwdev, &fc->devices, link)
if (fwdev->dst == dst && fwdev->status != FWDEVINVAL)
break;
- splx(s);
+ FW_GUNLOCK(fc);
return fwdev;
}
@@ -164,15 +163,12 @@ struct fw_device *
fw_noderesolve_eui64(struct firewire_comm *fc, struct fw_eui64 *eui)
{
struct fw_device *fwdev;
- int s;
- s = splfw();
FW_GLOCK(fc);
STAILQ_FOREACH(fwdev, &fc->devices, link)
if (FW_EUI64_EQUAL(fwdev->eui, *eui))
break;
FW_GUNLOCK(fc);
- splx(s);
if (fwdev == NULL)
return NULL;
@@ -301,9 +297,7 @@ static void
fw_asystart(struct fw_xfer *xfer)
{
struct firewire_comm *fc = xfer->fc;
- int s;
- s = splfw();
/* Protect from interrupt/timeout */
FW_GLOCK(fc);
xfer->flag = FWXF_INQ;
@@ -312,7 +306,6 @@ fw_asystart(struct fw_xfer *xfer)
xfer->q->queued++;
#endif
FW_GUNLOCK(fc);
- splx(s);
/* XXX just queue for mbuf */
if (xfer->mbuf == NULL)
xfer->q->start(fc);
@@ -332,6 +325,7 @@ firewire_probe(device_t dev)
return (0);
}
+/* Just use a per-packet callout? */
static void
firewire_xfer_timeout(void *arg, int pending)
{
@@ -340,7 +334,7 @@ firewire_xfer_timeout(void *arg, int pen
struct timeval tv;
struct timeval split_timeout;
STAILQ_HEAD(, fw_xfer) xfer_timeout;
- int i, s;
+ int i;
split_timeout.tv_sec = 0;
split_timeout.tv_usec = 200 * 1000; /* 200 msec */
@@ -349,9 +343,8 @@ firewire_xfer_timeout(void *arg, int pen
timevalsub(&tv, &split_timeout);
STAILQ_INIT(&xfer_timeout);
- s = splfw();
mtx_lock(&fc->tlabel_lock);
- for (i = 0; i < 0x40; i++) {
+ for (i = 0; i < nitems(fc->tlabels); i++) {
while ((xfer = STAILQ_FIRST(&fc->tlabels[i])) != NULL) {
if ((xfer->flag & FWXF_SENT) == 0)
/* not sent yet */
@@ -370,7 +363,6 @@ firewire_xfer_timeout(void *arg, int pen
}
}
mtx_unlock(&fc->tlabel_lock);
- splx(s);
fc->timeout(fc);
STAILQ_FOREACH_SAFE(xfer, &xfer_timeout, tlabel, txfer)
Modified: head/sys/dev/firewire/fwmem.c
==
--- head/sys/dev/firewire/fwmem.c Wed Jan 21 20:03:46 2015
(r277508)
+++ head/sys/dev/firewire/fwmem.c Wed Jan 21 20:05:10 2015
(r277509)
@@ -348,12 +348,11 @@ fwmem_strategy(struct bio *bp)
struct fw_device *fwdev;
struct fw_xfer *xfer;
struct cdev *dev;
- int err = 0, s, iolen;
+ int err = 0, iolen;
dev = bp->bio_dev;
/* XXX check request length */
- s = splfw();
fms = dev->si_drv1;
fwdev = fw_noderesolve_eui64(fms->sc->fc, &fms->eui);
if (fwdev == NULL) {
@@ -395,7 +394,6 @@ fwmem_strategy(struct bio *bp)
/* XXX */
bp->bio_resid = bp->bio_bcount - iolen;
error:
- splx(s);
if (err != 0) {
if (fwmem_debug)
printf("%s: err=%d\n", __func__, err);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277510 - head/sys/dev/firewire
Author: will Date: Wed Jan 21 20:06:25 2015 New Revision: 277510 URL: https://svnweb.freebsd.org/changeset/base/277510 Log: Fix firewire panic when issuing a reply to an unhandled asynchronous remote dma request (DMA request that the hardware cannot automatically handle). sys/dev/firewire/firewire.c In fw_rcv(), add missing early return in the error path for DMA requests to unregistered regions. Submitted by: gibbs MFC after:1 week Sponsored by: Spectra Logic MFSpectraBSD: 1110993 on 2015/01/06 Modified: head/sys/dev/firewire/firewire.c Modified: head/sys/dev/firewire/firewire.c == --- head/sys/dev/firewire/firewire.cWed Jan 21 20:05:10 2015 (r277509) +++ head/sys/dev/firewire/firewire.cWed Jan 21 20:06:25 2015 (r277510) @@ -2030,6 +2030,7 @@ fw_rcv(struct fw_rcv_buf *rb) rb->xfer->hand = fw_xfer_free; if (fw_asyreq(rb->fc, -1, rb->xfer)) fw_xfer_free(rb->xfer); + return; } len = 0; for (i = 0; i < rb->nvec; i++) ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277511 - head/sys/dev/firewire
Author: will
Date: Wed Jan 21 20:08:24 2015
New Revision: 277511
URL: https://svnweb.freebsd.org/changeset/base/277511
Log:
Fix remote DMA based firewire debugging when targeting
systems with more than 4GB of physical memory.
To remotely debug the system 'stealthy' which has a kernel
with this change installed and firewire properly configured:
% fwcontrol -m stealthy (or stealthy's firewire EUI64)
% kgdb kernel /dev/fwmem0.0
sys/dev/firewire/fwohci.c:
Rather than hard code the upper limit for hw based
automatic responses to remote DMA requests at 4GB,
program the hardware using Maxmem, the page number
one higher than the highest physical page detected
in the system.
While here, garbage collect more useless splfw()
calls.
Submitted by: gibbs
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1110994 on 2015/01/06
Modified:
head/sys/dev/firewire/fwohci.c
Modified: head/sys/dev/firewire/fwohci.c
==
--- head/sys/dev/firewire/fwohci.c Wed Jan 21 20:06:25 2015
(r277510)
+++ head/sys/dev/firewire/fwohci.c Wed Jan 21 20:08:24 2015
(r277511)
@@ -48,6 +48,7 @@
#include
#include
+#include
#include
#include
@@ -188,6 +189,7 @@ static void fwohci_task_dma(void *, int)
#defineOHCI_PREQLO 0x118
#defineOHCI_PREQLOCLR 0x11c
#defineOHCI_PREQUPPER 0x120
+#define OHCI_PREQUPPER_MAX 0x
#defineOHCI_SID_BUF0x64
#defineOHCI_SID_CNT0x68
@@ -854,7 +856,7 @@ fwohci_execute_db2(void *arg, bus_dma_se
static void
fwohci_start(struct fwohci_softc *sc, struct fwohci_dbch *dbch)
{
- int i, s;
+ int i;
int tcode, hdr_len, pl_off;
int fsegment = -1;
uint32_t off;
@@ -880,7 +882,6 @@ fwohci_start(struct fwohci_softc *sc, st
if (dbch->flags & FWOHCI_DBCH_FULL)
return;
- s = splfw();
db_tr = dbch->top;
txloop:
xfer = STAILQ_FIRST(&dbch->xferq.q);
@@ -1030,7 +1031,6 @@ kick:
}
dbch->top = db_tr;
- splx(s);
return;
}
@@ -1821,6 +1821,7 @@ static void
fwohci_intr_core(struct fwohci_softc *sc, uint32_t stat, int count)
{
struct firewire_comm *fc = (struct firewire_comm *)sc;
+ uintmax_t prequpper;
uint32_t node_id, plen;
FW_GLOCK_ASSERT(fc);
@@ -1852,8 +1853,17 @@ fwohci_intr_core(struct fwohci_softc *sc
/* allow from all nodes */
OWRITE(sc, OHCI_PREQHI, 0x7fff);
OWRITE(sc, OHCI_PREQLO, 0x);
- /* 0 to 4GB region */
- OWRITE(sc, OHCI_PREQUPPER, 0x1);
+ prequpper = ((uintmax_t)Maxmem << PAGE_SHIFT) >> 16;
+ if (prequpper > OHCI_PREQUPPER_MAX) {
+ device_printf(fc->dev,
+ "Physical memory size of 0x%jx exceeds "
+ "fire wire address space. Limiting dma "
+ "to memory below 0x%jx\n",
+ (uintmax_t)Maxmem << PAGE_SHIFT,
+ (uintmax_t)OHCI_PREQUPPER_MAX << 16);
+ prequpper = OHCI_PREQUPPER_MAX;
+ }
+ OWRITE(sc, OHCI_PREQUPPER, prequpper & 0x);
}
/* Set ATRetries register */
OWRITE(sc, OHCI_ATRETRY, 1<<(13 + 16) | 0xfff);
@@ -2171,7 +2181,7 @@ fwohci_rbuf_update(struct fwohci_softc *
struct fw_bulkxfer *chunk;
struct fw_xferq *ir;
uint32_t stat;
- int s, w = 0, ldesc;
+ int w = 0, ldesc;
ir = fc->ir[dmach];
ldesc = sc->ir[dmach].ndesc - 1;
@@ -2179,7 +2189,6 @@ fwohci_rbuf_update(struct fwohci_softc *
#if 0
dump_db(sc, dmach);
#endif
- s = splfw();
if ((ir->flag & FWXFERQ_HANDLER) == 0)
FW_GLOCK(fc);
fwdma_sync_multiseg_all(sc->ir[dmach].am, BUS_DMASYNC_POSTREAD);
@@ -2218,7 +2227,6 @@ fwohci_rbuf_update(struct fwohci_softc *
}
if ((ir->flag & FWXFERQ_HANDLER) == 0)
FW_GUNLOCK(fc);
- splx(s);
if (w == 0)
return;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277497 - head
On 21 January 2015 at 14:04, Ed Maste wrote: > > Author: emaste > Date: Wed Jan 21 19:04:55 2015 > New Revision: 277497 > URL: https://svnweb.freebsd.org/changeset/base/277497 > > Log: > Remove addr2line from cross elftoolchain tools list > > It is not required, and there is no reason to install it just because it > came with the binutils cross tools. I left some detail out of this commit message and it confused a couple of people, so to be clear: this doesn't remove addr2line from the world build, only the cross-tools stage. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277512 - in head/sys/arm: arm include
Author: ian
Date: Wed Jan 21 20:12:35 2015
New Revision: 277512
URL: https://svnweb.freebsd.org/changeset/base/277512
Log:
Micro-optimize the new arm inline bus_space implementation by grouping all
the data the inline functions access together at the start of the bus_space
struct. The start-of part isn't so important, it's the grouping-together
that's the point: now all the most-accessed data should be in one cache line.
Suggested by: cognet
Modified:
head/sys/arm/arm/bus_space_base.c
head/sys/arm/include/bus.h
Modified: head/sys/arm/arm/bus_space_base.c
==
--- head/sys/arm/arm/bus_space_base.c Wed Jan 21 20:08:24 2015
(r277511)
+++ head/sys/arm/arm/bus_space_base.c Wed Jan 21 20:12:35 2015
(r277512)
@@ -150,7 +150,7 @@ static struct bus_space arm_base_bus_spa
.bs_wr_2_s = generic_bs_wr_2,
.bs_wr_4_s = generic_bs_wr_4,
.bs_wr_8_s = BS_UNIMPLEMENTED,
-};
+} __aligned(CACHE_LINE_SIZE);
#ifdef FDT
bus_space_tag_t fdtbus_bs_tag = &arm_base_bus_space;
Modified: head/sys/arm/include/bus.h
==
--- head/sys/arm/include/bus.h Wed Jan 21 20:08:24 2015(r277511)
+++ head/sys/arm/include/bus.h Wed Jan 21 20:12:35 2015(r277512)
@@ -79,9 +79,27 @@
#defineBUS_SPACE_MAP_LINEAR0x02
#defineBUS_SPACE_MAP_PREFETCHABLE 0x04
+/*
+ * Bus space for ARM.
+ *
+ * The functions used most often are grouped together at the beginning to
ensure
+ * that all the data fits into a single cache line. The inline implementations
+ * of single read/write access these values a lot.
+ */
struct bus_space {
- /* cookie */
- void*bs_privdata;
+ /* Read/write single and barrier: the most commonly used functions. */
+ uint8_t (*bs_r_1)(bus_space_tag_t, bus_space_handle_t, bus_size_t);
+ uint32_t (*bs_r_4)(bus_space_tag_t, bus_space_handle_t, bus_size_t);
+ void (*bs_w_1)(bus_space_tag_t, bus_space_handle_t,
+ bus_size_t, uint8_t);
+ void (*bs_w_4)(bus_space_tag_t, bus_space_handle_t,
+ bus_size_t, uint32_t);
+ void (*bs_barrier)(bus_space_tag_t, bus_space_handle_t,
+ bus_size_t, bus_size_t, int);
+
+ /* Backlink to parent (if copied), and implementation private data. */
+ struct bus_space *bs_parent;
+ void *bs_privdata;
/* mapping/unmapping */
int (*bs_map) (bus_space_tag_t, bus_addr_t, bus_size_t,
@@ -97,15 +115,8 @@ struct bus_space {
void(*bs_free) (bus_space_tag_t, bus_space_handle_t,
bus_size_t);
- /* get kernel virtual address */
- /* barrier */
- void(*bs_barrier) (bus_space_tag_t, bus_space_handle_t,
- bus_size_t, bus_size_t, int);
-
- /* read (single) */
- uint8_t (*bs_r_1) (bus_space_tag_t, bus_space_handle_t,
bus_size_t);
+ /* Read single, the less commonly used functions. */
uint16_t(*bs_r_2) (bus_space_tag_t, bus_space_handle_t,
bus_size_t);
- uint32_t(*bs_r_4) (bus_space_tag_t, bus_space_handle_t,
bus_size_t);
uint64_t(*bs_r_8) (bus_space_tag_t, bus_space_handle_t,
bus_size_t);
/* read multiple */
@@ -128,13 +139,9 @@ struct bus_space {
void(*bs_rr_8) (bus_space_tag_t, bus_space_handle_t,
bus_size_t, uint64_t *, bus_size_t);
- /* write (single) */
- void(*bs_w_1) (bus_space_tag_t, bus_space_handle_t,
- bus_size_t, uint8_t);
+ /* Write single, the less commonly used functions. */
void(*bs_w_2) (bus_space_tag_t, bus_space_handle_t,
bus_size_t, uint16_t);
- void(*bs_w_4) (bus_space_tag_t, bus_space_handle_t,
- bus_size_t, uint32_t);
void(*bs_w_8) (bus_space_tag_t, bus_space_handle_t,
bus_size_t, uint64_t);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277497 - head
On Wed, 2015-01-21 at 15:10 -0500, Ed Maste wrote: > On 21 January 2015 at 14:04, Ed Maste wrote: > > > > Author: emaste > > Date: Wed Jan 21 19:04:55 2015 > > New Revision: 277497 > > URL: https://svnweb.freebsd.org/changeset/base/277497 > > > > Log: > > Remove addr2line from cross elftoolchain tools list > > > > It is not required, and there is no reason to install it just because it > > came with the binutils cross tools. > > I left some detail out of this commit message and it confused a couple > of people, so to be clear: this doesn't remove addr2line from the > world build, only the cross-tools stage. > This is still not good for me. I use the cross-addr2line tool all the time, and objdump and other such tools. I have many different sandboxes with different arch builds of different freebsd versions, and each one is a self-contained little development world that includes the cross tools that are known to work with that source base. I don't think there's a single addr2line binary I can install that will work with every object on the system. If the time spent building these things is bothering people, maybe we need a WITH_CROSS_BINUTILS knob or something? -- Ian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277513 - head/sys/dev/isp
Author: will
Date: Wed Jan 21 20:22:53 2015
New Revision: 277513
URL: https://svnweb.freebsd.org/changeset/base/277513
Log:
Change 1112791 by kenm@ken.spectrabsd8 on 2015/01/15 16:45:13
Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards.
The newer boards don't have the response field that indicates
whether the SCSI status byte is present. You have to just look to
see whether it is non-zero.
The code was looking to see whether the sense length was valid
before propagating the SCSI status byte (and sense information) up
the stack. With a status like Reservation Conflict, there is no
sense information, only the SCSI status byte. So it wasn't getting
correctly returned.
isp.c:
In isp_intr(), if we are on a 2400 or 2500 type board and
get a response, look at the actual contents of the
SCSI status value and set the RQSF_GOT_STATUS flag
accordingly so that return any SCSI status value we get. The
RQSF_GOT_SENSE flag will get set later on if there is
actual sense information returned.
Submitted by: ken
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1112791 on 2015/01/15
Modified:
head/sys/dev/isp/isp_freebsd.c
Modified: head/sys/dev/isp/isp_freebsd.c
==
--- head/sys/dev/isp/isp_freebsd.c Wed Jan 21 20:12:35 2015
(r277512)
+++ head/sys/dev/isp/isp_freebsd.c Wed Jan 21 20:22:53 2015
(r277513)
@@ -5123,19 +5123,34 @@ isp_action(struct cam_sim *sim, union cc
break;
#endif
case XPT_RESET_DEV: /* BDR the specified SCSI device */
+ {
+ struct isp_fc *fc;
bus = cam_sim_bus(xpt_path_sim(ccb->ccb_h.path));
tgt = ccb->ccb_h.target_id;
tgt |= (bus << 16);
+ if (IS_FC(isp))
+ fc = ISP_FC_PC(isp, bus);
+ else
+ fc = NULL;
error = isp_control(isp, ISPCTL_RESET_DEV, bus, tgt);
if (error) {
ccb->ccb_h.status = CAM_REQ_CMP_ERR;
} else {
+ /*
+* If we have a FC device, reset the Command
+* Reference Number, because the target will expect
+* that we re-start the CRN at 1 after a reset.
+*/
+ if (fc != NULL)
+ isp_fcp_reset_crn(fc, tgt, /*tgt_set*/ 1);
+
ccb->ccb_h.status = CAM_REQ_CMP;
}
xpt_done(ccb);
break;
+ }
case XPT_ABORT: /* Abort the specified CCB */
{
union ccb *accb = ccb->cab.abort_ccb;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277514 - head/sys/dev/isp
Author: will
Date: Wed Jan 21 20:27:11 2015
New Revision: 277514
URL: https://svnweb.freebsd.org/changeset/base/277514
Log:
Force commit to record the correct log for r277513.
If the user sends an XPT_RESET_DEV CCB, make sure to reset the
Fibre Channel Command Reference Number if we're running on a FC
controller.
We send a SCSI Target Reset when we get this CCB, and as a result
need to reset the CRN to 1 on the next command.
isp_freebsd.c:
In the XPT_RESET_DEV implementation in isp_action(), reset
the CRN if we're on a FC controller.
Submitted by: ken
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1112787 on 2015/01/15
Modified:
head/sys/dev/isp/isp_freebsd.c
Modified: head/sys/dev/isp/isp_freebsd.c
==
--- head/sys/dev/isp/isp_freebsd.c Wed Jan 21 20:22:53 2015
(r277513)
+++ head/sys/dev/isp/isp_freebsd.c Wed Jan 21 20:27:11 2015
(r277514)
@@ -29,6 +29,7 @@
*/
#include
__FBSDID("$FreeBSD$");
+
#include
#include
#include
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277515 - head/sys/dev/isp
Author: will
Date: Wed Jan 21 20:32:36 2015
New Revision: 277515
URL: https://svnweb.freebsd.org/changeset/base/277515
Log:
Fix SCSI status byte reporting on 4Gb and 8Gb Qlogic boards.
The newer boards don't have the response field that indicates
whether the SCSI status byte is present. You have to just look to
see whether it is non-zero.
The code was looking to see whether the sense length was valid
before propagating the SCSI status byte (and sense information) up
the stack. With a status like Reservation Conflict, there is no
sense information, only the SCSI status byte. So it wasn't getting
correctly returned.
isp.c:
In isp_intr(), if we are on a 2400 or 2500 type board and
get a response, look at the actual contents of the
SCSI status value and set the RQSF_GOT_STATUS flag
accordingly so that return any SCSI status value we get. The
RQSF_GOT_SENSE flag will get set later on if there is
actual sense information returned.
Submitted by: ken
MFC after:1 week
Sponsored by: Spectra Logic
MFSpectraBSD: 1112791 on 2015/01/15
Modified:
head/sys/dev/isp/isp.c
Modified: head/sys/dev/isp/isp.c
==
--- head/sys/dev/isp/isp.c Wed Jan 21 20:27:11 2015(r277514)
+++ head/sys/dev/isp/isp.c Wed Jan 21 20:32:36 2015(r277515)
@@ -5224,7 +5224,10 @@ again:
}
scsi_status = sp2->req_scsi_status;
completion_status = sp2->req_completion_status;
- req_state_flags = 0;
+ if ((scsi_status & 0xff) != 0)
+ req_state_flags = RQSF_GOT_STATUS;
+ else
+ req_state_flags = 0;
resid = sp2->req_resid;
} else if (etype == RQSTYPE_RESPONSE) {
isp_get_response(isp, (ispstatusreq_t *) hp, sp);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277516 - head/sys/arm/arm
Author: ian
Date: Wed Jan 21 21:31:26 2015
New Revision: 277516
URL: https://svnweb.freebsd.org/changeset/base/277516
Log:
Move the __aligned() declaration to where it will actually do something.
Modified:
head/sys/arm/arm/bus_space_base.c
Modified: head/sys/arm/arm/bus_space_base.c
==
--- head/sys/arm/arm/bus_space_base.c Wed Jan 21 20:32:36 2015
(r277515)
+++ head/sys/arm/arm/bus_space_base.c Wed Jan 21 21:31:26 2015
(r277516)
@@ -45,7 +45,7 @@ bs_protos(generic);
* The bus space tag. This is constant for all instances, so
* we never have to explicitly "create" it.
*/
-static struct bus_space arm_base_bus_space = {
+static struct bus_space arm_base_bus_space __aligned(CACHE_LINE_SIZE) = {
/* privdata is whatever the implementer wants; unused in base tag */
.bs_privdata= NULL,
@@ -150,7 +150,7 @@ static struct bus_space arm_base_bus_spa
.bs_wr_2_s = generic_bs_wr_2,
.bs_wr_4_s = generic_bs_wr_4,
.bs_wr_8_s = BS_UNIMPLEMENTED,
-} __aligned(CACHE_LINE_SIZE);
+};
#ifdef FDT
bus_space_tag_t fdtbus_bs_tag = &arm_base_bus_space;
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r276747 - head/sys/netpfil/pf
On Wed, Jan 07, 2015 at 11:46:31PM +0300, Gleb Smirnoff wrote: T> On Tue, Jan 06, 2015 at 09:03:04AM +, Craig Rodrigues wrote: T> C> Author: rodrigc T> C> Date: Tue Jan 6 09:03:03 2015 T> C> New Revision: 276747 T> C> URL: https://svnweb.freebsd.org/changeset/base/276747 T> C> T> C> Log: T> C> Instead of creating a purge thread for every vnet, create T> C> a single purge thread and clean up all vnets from this thread. T> C> T> C> PR: 194515 T> C> Differential Revision: D1315 T> C> Submitted by: Nikos Vassiliadis T> T> I am not sure that this is a good idea. The core idea of VNETs T> is that they are isolated from each other. If we serialize purging, T> then vnets are strongly affecting each other. T> T> AFAIU, from the PR there is some panic fixed. What is the actual bug T> and why couldn't it be fixed with having per-vnet thread? So, after closer inspection, this commit is a completely messed up. You blindly remove kproc_exit(). What do you think would happen on 'kldunload -f pf'? You removed PF_RULES_RLOCK(). Cool! Now the purging thread doesn't acquire the pf lock. You substitute rw_sleep() with tsleep(). And the latter requires Giant to be held. If you tried your change with INVARIANTS, it would panic immediately. -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277497 - head
On 21 January 2015 at 15:20, Ian Lepore wrote: > I don't think > there's a single addr2line binary I can install that will work with > every object on the system. There is, in fact - ELF Tool Chain's addr2line will work regardless of the object's architecture. However, I'm happy enough to revert this change (and add a comment about non-build use cases) if you like. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277517 - head
Author: emaste
Date: Wed Jan 21 21:49:03 2015
New Revision: 277517
URL: https://svnweb.freebsd.org/changeset/base/277517
Log:
Fix bootstrap on systems with old libdwarf and WITHOUT_CDDL
ELF Tool Chain tools need libelf and libdwarf.
Submitted by: jmallett (earlier version)
Reviewed by: jmallett
Sponsored by: The FreeBSD Foundation
Modified:
head/Makefile.inc1
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Jan 21 21:31:26 2015(r277516)
+++ head/Makefile.inc1 Wed Jan 21 21:49:03 2015(r277517)
@@ -1292,12 +1292,16 @@ _clang_tblgen= \
usr.bin/clang/clang-tblgen
.endif
+# ELF Tool Chain libraries are needed for ELF tools and dtrace tools.
# dtrace tools are required for older bootstrap env and cross-build
# pre libdwarf
-.if ${MK_CDDL} != "no" && (${BOOTSTRAPPING} < 116 \
- || (${MACHINE} != ${TARGET} || ${MACHINE_ARCH} != ${TARGET_ARCH}))
-_dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \
-lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge
+.if ${BOOTSTRAPPING} < 116 || (${MACHINE} != ${TARGET} || \
+${MACHINE_ARCH} != ${TARGET_ARCH})
+_elftoolchain_libs= lib/libelf lib/libdwarf
+.if ${MK_CDDL} != "no"
+_dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf cddl/usr.bin/ctfconvert \
+cddl/usr.bin/ctfmerge
+.endif
.endif
# Default to building the GPL DTC, but build the BSDL one if users explicitly
@@ -1324,6 +1328,7 @@ bootstrap-tools: .MAKE
.for _tool in \
${_clang_tblgen} \
${_kerberos5_bootstrap_tools} \
+${_elftoolchain_libs} \
${_dtrace_tools} \
${_strfile} \
${_gperf} \
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277204 - head/sys/amd64/conf
Adrian Chadd wrote this message on Fri, Jan 16, 2015 at 10:43 -0800: > When I've done what you're doing, I end up having these options in my > minimal config file so opt_xxx.h is correctly populated. That way when > I point SYSDIR (or whichever variable it is) at the configured kernel > directory with the opt_xxx.h files, it all works out correctly. > > (I still think we shouldn't be relying on "defaults", but should ship > the opt_xxx.h files or something to derive the opt_xxx.h and makefile > config bits so things like external module building is possible > against a kernel. Or, we just kill all module options that change > behaviour/ABI of things in an incompatible way.) I have the commands that are able to stash the opt files in a kernel section, and then be able to extract them again so that when you build a kernel module it will use the correct options to match the kernel.. This is most useful for things like PAE which have a big impact... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r275832 - head/tools/tools/nanobsd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 01/22/15 02:23, Will Andrews wrote:
> On Wed, Jan 21, 2015 at 06:51:23PM +1100, Lawrence Stewart wrote:
>> I think this change introduced a bug - I'm seeing nanobsd error
>> out with the "NANO_TOOLS directory does not exist" message.
>>
>> The problem is that NANO_TOOLS is initialised to
>> "tools/tools/nanobsd", and you changed the test in nanobsd.sh to
>> *not* check for "${NANO_SRC}/${NANO_TOOLS}", which errors out
>> except if the cwd is ${NANO_SRC}.
>>
>> You tweak NANO_TOOLS appropriately in set_defaults_and_export()
>> but it's run after the dir test. There are a couple of ways to
>> fix but I'll leave it to you to decide which you prefer.
>
> Will this work for you?
>
> https://people.freebsd.org/~will/patches/nanobsd.sh.diff
>
> This also fixes another bug where NANO_PMAKE would be modified too
> early.
Yes, looks good to me and fixes the issue I reported. Please commit.
Cheers,
Lawrence
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQJ8BAEBCgBmBQJUwC4GXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RkIyRTlBMzM5RUE3OEExNUUxREI4QTI5
QTUwQkNGQ0Y0MEQ5QjA5AAoJEJpQvPz0DZsJ40QP+gOt9Sl11w5jLOxwfEYYKNCb
AjFkwhpmbAlpLMFR7OR7DvlRG6svHaO7RzK7pTbEHID3igdSx3+NRpBE+tyAe8fC
dl2hSmGLcGq6007HCGOZGW181tfv9BrRRxKwEXEP7sGhByR5hyFy0JweaLr0TpGb
8CruuZ3hUjDEaTMIBPhBaMWMNsWHJy6Qszj3iE8FwFnmMLnC9yXbfKTXP3iT88wd
y+Aq86Y5NT4HytcbWOaNa6mvQTsZfxnFIVppN+u3AWpgzhh76HzOgeFKK4Wj32/j
eK3v/hi/aSmOaW5AKR10n2ADutjFvMLaHhMVVIOIBTJ6KQ7W38PGR4/sTqbxkAqa
AUsTm53Bz9w3fjr4YhNzOtu0nwgcD1LyUJKnwoyUig97BL8Ogphj+I/4rzB150uD
dnvgLoqY8Qh2ck0eciFiKZdY9k5t0cpQPNwpRl/L+wssKbdKGg4/0Ob5/fy9HVkx
JrcrkmNyIMpLsN683OMNgvbIB5ow6Ya2cNmJtHVS8N8sJ7/Sd4RYPfEWIk7UUX9b
lv+NQm42CyERE98TvE6felmb+iLFF79D2e0wJAis+pbDf8KlMIC3DBjdXls+BEZm
048o1sulxUuo2YMnQHF1sP6bZgeCwI9LslJGlXmLG8WA2oL5I9GJfnkwyD6rbJyx
668QEgpTzhLuAUBXGMT8
=QGdi
-END PGP SIGNATURE-
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277497 - head
On Wed, 2015-01-21 at 16:45 -0500, Ed Maste wrote: > On 21 January 2015 at 15:20, Ian Lepore wrote: > > I don't think > > there's a single addr2line binary I can install that will work with > > every object on the system. > > There is, in fact - ELF Tool Chain's addr2line will work regardless of > the object's architecture. > > However, I'm happy enough to revert this change (and add a comment > about non-build use cases) if you like. Do you mean the new one you're working on? Because that doesn't seem to be true of the one installed on my 10-stable system right now. If it is true of the new one, that's a much better solution, and I can get by until it's ready for prime time, I think. -- Ian ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
> 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 from one callwheel to another. Now we > have fallout which we can either address or back out until the callout > stuff is again reviewed/fixed. > > I don't think it's as alchemic as is being promoted. Let's not get drawn into semantic debates. To me alchemy implies voodoo debugging, whereas this is, in part, disabling functionality that exposes races - which is more like disabling preemption or fine grained locking. Normally I would advocate backing this out on the basis of precedence. That is to say, back it out so that developers will get it right the first time. However, it appears that hps@ and some others don't understand what was done wrong. So I'm going to state some basic premises and then the implied basic guidelines required of a commit that were not met. If these guidelines are violated by a change in the future I will agitate for a rapid back out. Premises: A) A performance regression is a bug every bit as much as a locking race. Stability OR performance (where we are talking about _current_ performance) is a false dichotomy. - This means that a change that fixes a bug by introducing a substantial performance regression does not constitute a fix. B) Existing behavior and performance characteristics should not be adversely changed unless there is widespread consensus. - Sometimes it is necessary to "break" a KPI but that should not be discovered by svn or scanning back through the mailing lists. Guidelines: A) Performance should not measurably regress. B) If a KPI changes behavior e.g. callout_reset_on being crippled, all clients need to be updated so that they maintain their current behavior by the committer changing the KPI. The client code maintainers aren't responsible for reacting to these types of changes. That is OK for marginal architectures like sun4v or pc98. C) If there is a non-zero possibility that these changes break the client code, committers who have touched that code in the last few years should be notified. 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 the USB sandbox where others need for your support outweighs the inconvenience of random breakage. It sounds like you are making progress towards updating the concerns that have been voiced. If kib's observations are in fact comprehensive then adding a callout_init_cpu function and updating all clients so that their callouts continue to be scheduled on a CPU other than the BSP will suffice and we can all move on. Thanks in advance. -K ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
> On Jan 21, 2015, at 4:38 PM, K. Macy wrote: > >> 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 from one callwheel to another. Now we >> have fallout which we can either address or back out until the callout >> stuff is again reviewed/fixed. >> >> I don't think it's as alchemic as is being promoted. > > > Let's not get drawn into semantic debates. To me alchemy implies > voodoo debugging, whereas this is, in part, disabling functionality > that exposes races - which is more like disabling preemption or fine > grained locking. > > > Normally I would advocate backing this out on the basis of precedence. > That is to say, back it out so that developers will get it right the > first time. However, it appears that hps@ and some others don't > understand what was done wrong. So I'm going to state some basic > premises and then the implied basic guidelines required of a commit > that were not met. If these guidelines are violated by a change in the > future I will agitate for a rapid back out. > > Premises: > A) A performance regression is a bug every bit as much as a locking > race. Stability OR performance (where we are talking about _current_ > performance) is a false dichotomy. > - This means that a change that fixes a bug by introducing a > substantial performance regression does not constitute a fix. > B) Existing behavior and performance characteristics should not be > adversely changed unless there is widespread consensus. > - Sometimes it is necessary to "break" a KPI but that should not be > discovered by svn or scanning back through the mailing lists. > > Guidelines: > A) Performance should not measurably regress. > B) If a KPI changes behavior e.g. callout_reset_on being crippled, all > clients need to be updated so that they maintain their current > behavior by the committer changing the KPI. The client code > maintainers aren't responsible for reacting to these types of changes. > That is OK for marginal architectures like sun4v or pc98. > C) If there is a non-zero possibility that these changes break the > client code, committers who have touched that code in the last few > years should be notified. > > > > 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 the USB sandbox where others need for your > support outweighs the inconvenience of random breakage. > > It sounds like you are making progress towards updating the concerns > that have been voiced. If kib's observations are in fact comprehensive > then adding a callout_init_cpu function and updating all clients so > that their callouts continue to be scheduled on a CPU other than the > BSP will suffice and we can all move on. Is there some reason that we can’t back things out, break things down into smaller pieces and have everything pass through phabric with a wide ranging review? Given the fundamental nature of these changes, they really need better review and doing it after the fact seems to be to be too risky. I’m not debating that this “fixes” some issues, but given the performance regression, it sure seems like we may need a different solution to be implemented and hashing that out in a branch might be the best approach. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
>> 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 the USB sandbox where others need for your >> support outweighs the inconvenience of random breakage. >> >> It sounds like you are making progress towards updating the concerns >> that have been voiced. If kib's observations are in fact comprehensive >> then adding a callout_init_cpu function and updating all clients so >> that their callouts continue to be scheduled on a CPU other than the >> BSP will suffice and we can all move on. > > Is there some reason that we can’t back things out, break things down into > smaller pieces and have everything pass through phabric with a wide > ranging review? Given the fundamental nature of these changes, they > really need better review and doing it after the fact seems to be to be > too risky. I’m not debating that this “fixes” some issues, but given the > performance regression, it sure seems like we may need a different > solution to be implemented and hashing that out in a branch might be > the best approach. Thank you. A more incremental approach would be appreciated by many of us. To avoid the bystander effect we can permit explicit timeouts for review-to-commit (72 hours?) so that we don't collectively end up sandbagging him. -K ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 21 January 2015 at 16:07, K. Macy wrote: >>> 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 the USB sandbox where others need for your >>> support outweighs the inconvenience of random breakage. >>> >>> It sounds like you are making progress towards updating the concerns >>> that have been voiced. If kib's observations are in fact comprehensive >>> then adding a callout_init_cpu function and updating all clients so >>> that their callouts continue to be scheduled on a CPU other than the >>> BSP will suffice and we can all move on. >> >> Is there some reason that we can’t back things out, break things down into >> smaller pieces and have everything pass through phabric with a wide >> ranging review? Given the fundamental nature of these changes, they >> really need better review and doing it after the fact seems to be to be >> too risky. I’m not debating that this “fixes” some issues, but given the >> performance regression, it sure seems like we may need a different >> solution to be implemented and hashing that out in a branch might be >> the best approach. > > Thank you. A more incremental approach would be appreciated by many of > us. To avoid the bystander effect we can permit explicit timeouts for > review-to-commit (72 hours?) so that we don't collectively end up > sandbagging him. I'm +1 for this. -a ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277497 - head
On 21 January 2015 at 16:49, Ian Lepore wrote: > On Wed, 2015-01-21 at 16:45 -0500, Ed Maste wrote: >> On 21 January 2015 at 15:20, Ian Lepore wrote: >> > I don't think >> > there's a single addr2line binary I can install that will work with >> > every object on the system. >> >> There is, in fact - ELF Tool Chain's addr2line will work regardless of >> the object's architecture. >> >> However, I'm happy enough to revert this change (and add a comment >> about non-build use cases) if you like. > > Do you mean the new one you're working on? Because that doesn't seem to > be true of the one installed on my 10-stable system right now. If it is > true of the new one, that's a much better solution, and I can get by > until it's ready for prime time, I think. Yes, the new one I've been working on. It's now the default in HEAD (along with nm, strings, size, etc.). Bringing this to stable/10 would be tricky because it depends on the new libdwarf in 11 that's not backwards compatible. For that reason perhaps I ought to just leave them in the cross-tools stage, until we can assume developers are generally cross building from an 11.x host. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277497 - head
> On Jan 21, 2015, at 5:35 PM, Ed Maste wrote: > > On 21 January 2015 at 16:49, Ian Lepore wrote: >> On Wed, 2015-01-21 at 16:45 -0500, Ed Maste wrote: >>> On 21 January 2015 at 15:20, Ian Lepore wrote: I don't think there's a single addr2line binary I can install that will work with every object on the system. >>> >>> There is, in fact - ELF Tool Chain's addr2line will work regardless of >>> the object's architecture. >>> >>> However, I'm happy enough to revert this change (and add a comment >>> about non-build use cases) if you like. >> >> Do you mean the new one you're working on? Because that doesn't seem to >> be true of the one installed on my 10-stable system right now. If it is >> true of the new one, that's a much better solution, and I can get by >> until it's ready for prime time, I think. > > Yes, the new one I've been working on. It's now the default in HEAD > (along with nm, strings, size, etc.). > > Bringing this to stable/10 would be tricky because it depends on the > new libdwarf in 11 that's not backwards compatible. For that reason > perhaps I ought to just leave them in the cross-tools stage, until we > can assume developers are generally cross building from an 11.x host. There’s little harm in leaving it in, and some harm in taking it out… The time to build this stuff is tiny... Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277518 - head/tools/tools/nanobsd
Author: will
Date: Thu Jan 22 00:52:34 2015
New Revision: 277518
URL: https://svnweb.freebsd.org/changeset/base/277518
Log:
Enable nanobsd.sh to be executed when pwd != NANO_SRC.
While here, fix a bug in which NANO_PMAKE would not be appended at the
appropriate time.
Simply move both checks to after the call to set_defaults_and_export().
Tested by:lstewart
Sponsored by: Spectra Logic
Modified:
head/tools/tools/nanobsd/nanobsd.sh (contents, props changed)
Modified: head/tools/tools/nanobsd/nanobsd.sh
==
--- head/tools/tools/nanobsd/nanobsd.sh Wed Jan 21 21:49:03 2015
(r277517)
+++ head/tools/tools/nanobsd/nanobsd.sh Thu Jan 22 00:52:34 2015
(r277518)
@@ -121,6 +121,13 @@ if [ $# -gt 0 ] ; then
usage
fi
+###
+# And then it is as simple as that...
+
+# File descriptor 3 is used for logging output, see pprint
+exec 3>&1
+set_defaults_and_export
+
if [ ! -d "${NANO_TOOLS}" ]; then
echo "NANO_TOOLS directory does not exist" 1>&2
exit 1
@@ -130,13 +137,6 @@ if ! $do_clean; then
NANO_PMAKE="${NANO_PMAKE} -DNO_CLEAN"
fi
-###
-# And then it is as simple as that...
-
-# File descriptor 3 is used for logging output, see pprint
-exec 3>&1
-set_defaults_and_export
-
pprint 1 "NanoBSD image ${NANO_NAME} build starting"
if $do_world ; then
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277421 - head/sys/powerpc/powerpc
> On Jan 21, 2015, at 12:54 AM, Konstantin Belousov wrote: > > On Tue, Jan 20, 2015 at 07:59:08PM -0800, Nathan Whitehorn wrote: >> >> On 01/20/15 11:14, Konstantin Belousov wrote: >>> On Tue, Jan 20, 2015 at 04:21:59PM +, Nathan Whitehorn wrote: Author: nwhitehorn Date: Tue Jan 20 16:21:59 2015 New Revision: 277421 URL: https://svnweb.freebsd.org/changeset/base/277421 Log: There does not seem to be any reason to acquire GIANT here. Follow amd64 in removing it. MFC after: 1 month Modified: head/sys/powerpc/powerpc/mem.c Modified: head/sys/powerpc/powerpc/mem.c == --- head/sys/powerpc/powerpc/mem.c Tue Jan 20 15:45:09 2015 (r277420) +++ head/sys/powerpc/powerpc/mem.c Tue Jan 20 16:21:59 2015 (r277421) @@ -100,8 +100,6 @@ memrw(struct cdev *dev, struct uio *uio, cnt = 0; error = 0; - GIANT_REQUIRED; - >>> This is not an acquisition, to be pedantic. Really, it is cdevsw which >>> has D_NEEDGIANT flag which acquires Giant. After architectures get >>> rid of GIANT_REQUIRED, flag can be removed. >>> >> Just so I understand, you are not objecting to this commit, right? > Absolutely not, this is the right thing to do. > >> Just >> pointing out that (a) my commit message was wrong and that (b) once all >> architectures make this change (presumably more involved) we can get rid >> of the D_NEEDGIANT in /sys/dev/mem/memdev.c? > Exactly. There doesn’t seem to be a reason for i386 either. Was just looking at the code today on the plane for unrelated reasons. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r275832 - head/tools/tools/nanobsd
On Thu, Jan 22, 2015 at 09:54:04AM +1100, Lawrence Stewart wrote: > Yes, looks good to me and fixes the issue I reported. Please commit. Done in r277518. Thanks for the quick test. -- wca pgp4gwb_L8Tfr.pgp Description: PGP signature
svn commit: r277519 - in head/sys: net netpfil/pf
Author: glebius
Date: Thu Jan 22 01:23:16 2015
New Revision: 277519
URL: https://svnweb.freebsd.org/changeset/base/277519
Log:
Back out r276841, r276756, r276747, r276746. The change in r276747 is very
very questionable, since it makes vimages more dependent on each other. But
the reason for the backout is that it screwed up shutting down the pf purge
threads, and now kernel immedially panics on pf module unload. Although module
unloading isn't an advertised feature of pf, it is very important for
development process.
I'd like to not backout r276746, since in general it is good. But since it
has introduced numerous build breakages, that later were addressed in
r276841, r276756, r276747, I need to back it out as well. Better replay it
in clean fashion from scratch.
Modified:
head/sys/net/pfvar.h
head/sys/netpfil/pf/pf.c
head/sys/netpfil/pf/pf_if.c
head/sys/netpfil/pf/pf_ioctl.c
head/sys/netpfil/pf/pf_norm.c
head/sys/netpfil/pf/pf_table.c
Modified: head/sys/net/pfvar.h
==
--- head/sys/net/pfvar.hThu Jan 22 00:52:34 2015(r277518)
+++ head/sys/net/pfvar.hThu Jan 22 01:23:16 2015(r277519)
@@ -829,6 +829,7 @@ typedef int pflog_packet_t(struct pfi_ki
struct pf_ruleset *, struct pf_pdesc *, int);
extern pflog_packet_t *pflog_packet_ptr;
+#defineV_pf_end_threadsVNET(pf_end_threads)
#endif /* _KERNEL */
#definePFSYNC_FLAG_SRCNODE 0x04
@@ -1494,7 +1495,7 @@ VNET_DECLARE(struct pf_altqqueue *,pf_
VNET_DECLARE(struct pf_rulequeue, pf_unlinked_rules);
#defineV_pf_unlinked_rules VNET(pf_unlinked_rules)
-voidpf_vnet_initialize(void);
+voidpf_initialize(void);
voidpf_mtag_initialize(void);
voidpf_mtag_cleanup(void);
voidpf_cleanup(void);
@@ -1586,7 +1587,7 @@ int pf_match_addr_range(struct pf_addr *
struct pf_addr *, sa_family_t);
intpf_match_port(u_int8_t, u_int16_t, u_int16_t, u_int16_t);
-void pf_vnet_normalize_init(void);
+void pf_normalize_init(void);
void pf_normalize_cleanup(void);
intpf_normalize_ip(struct mbuf **, int, struct pfi_kif *, u_short *,
struct pf_pdesc *);
@@ -1648,7 +1649,7 @@ MALLOC_DECLARE(PFI_MTYPE);
VNET_DECLARE(struct pfi_kif *, pfi_all);
#defineV_pfi_allVNET(pfi_all)
-voidpfi_vnet_initialize(void);
+voidpfi_initialize(void);
voidpfi_cleanup(void);
voidpfi_kif_ref(struct pfi_kif *);
voidpfi_kif_unref(struct pfi_kif *);
Modified: head/sys/netpfil/pf/pf.c
==
--- head/sys/netpfil/pf/pf.cThu Jan 22 00:52:34 2015(r277518)
+++ head/sys/netpfil/pf/pf.cThu Jan 22 01:23:16 2015(r277519)
@@ -151,7 +151,6 @@ static VNET_DEFINE(struct pf_send_head,
#defineV_pf_sendqueue VNET(pf_sendqueue)
static struct mtx pf_sendqueue_mtx;
-MTX_SYSINIT(pf_sendqueue_mtx, &pf_sendqueue_mtx, "pf send queue", MTX_DEF);
#definePF_SENDQ_LOCK() mtx_lock(&pf_sendqueue_mtx)
#definePF_SENDQ_UNLOCK() mtx_unlock(&pf_sendqueue_mtx)
@@ -173,15 +172,11 @@ static VNET_DEFINE(struct task, pf_overl
#defineV_pf_overloadtask VNET(pf_overloadtask)
static struct mtx pf_overloadqueue_mtx;
-MTX_SYSINIT(pf_overloadqueue_mtx, &pf_overloadqueue_mtx,
-"pf overload/flush queue", MTX_DEF);
#definePF_OVERLOADQ_LOCK() mtx_lock(&pf_overloadqueue_mtx)
#definePF_OVERLOADQ_UNLOCK() mtx_unlock(&pf_overloadqueue_mtx)
VNET_DEFINE(struct pf_rulequeue, pf_unlinked_rules);
struct mtx pf_unlnkdrules_mtx;
-MTX_SYSINIT(pf_unlnkdrules_mtx, &pf_unlnkdrules_mtx, "pf unlinked rules",
-MTX_DEF);
static VNET_DEFINE(uma_zone_t, pf_sources_z);
#defineV_pf_sources_z VNET(pf_sources_z)
@@ -295,6 +290,8 @@ static void pf_route6(struct mbuf **,
int in4_cksum(struct mbuf *m, u_int8_t nxt, int off, int len);
+VNET_DECLARE(int, pf_end_threads);
+
VNET_DEFINE(struct pf_limit, pf_limits[PF_LIMIT_MAX]);
#definePACKET_LOOPED(pd) ((pd)->pf_mtag &&
\
@@ -731,7 +728,7 @@ pf_mtag_initialize()
/* Per-vnet data storage structures initialization. */
void
-pf_vnet_initialize()
+pf_initialize()
{
struct pf_keyhash *kh;
struct pf_idhash*ih;
@@ -791,9 +788,13 @@ pf_vnet_initialize()
STAILQ_INIT(&V_pf_sendqueue);
SLIST_INIT(&V_pf_overloadqueue);
TASK_INIT(&V_pf_overloadtask, 0, pf_overload_task, curvnet);
+ mtx_init(&pf_sendqueue_mtx, "pf send queue", NULL, MTX_DEF);
+ mtx_init(&pf_overloadqueue_mtx, "pf overload/flush queue", NULL,
+ MTX_DEF);
Re: svn commit: r276747 - head/sys/netpfil/pf
On Tue, Jan 06, 2015 at 09:03:04AM +, Craig Rodrigues wrote: C> Author: rodrigc C> Date: Tue Jan 6 09:03:03 2015 C> New Revision: 276747 C> URL: https://svnweb.freebsd.org/changeset/base/276747 C> C> Log: C> Instead of creating a purge thread for every vnet, create C> a single purge thread and clean up all vnets from this thread. C> C> PR: 194515 C> Differential Revision: D1315 C> Submitted by: Nikos Vassiliadis Sorry guys, I backed this out due to broken kldunload of pf module, which is critical when you are working with pf bugs. I had to backout r276746 as well, since it has numerous build breakages, that are addressed by later revisions. That's my fault that I don't review in time, and I will try to improve the situation. Can you please replay r276746 again, addressing all the build problems and send the patch to me? You can user reviews.freebsd.org if you want. I'd like to get this in, but in a better quality. -- Totus tuus, Glebius. ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277517 - head
On Wed, Jan 21, 2015 at 1:49 PM, Ed Maste wrote: > Author: emaste > Date: Wed Jan 21 21:49:03 2015 > New Revision: 277517 > URL: https://svnweb.freebsd.org/changeset/base/277517 > > Log: > Fix bootstrap on systems with old libdwarf and WITHOUT_CDDL > > ELF Tool Chain tools need libelf and libdwarf. Thanks very much! ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277520 - in stable/10: etc/defaults etc/periodic/daily share/man/man5
Author: gjb
Date: Thu Jan 22 02:24:09 2015
New Revision: 277520
URL: https://svnweb.freebsd.org/changeset/base/277520
Log:
MFC r277216:
Evaluate running userland/kernel version in daily
periodic(8) run, taken from uname(1) '-U' and '-K'
flags.
Sponsored by: The FreeBSD Foundation
Added:
stable/10/etc/periodic/daily/510.status-world-kernel
- copied unchanged from r277216,
head/etc/periodic/daily/510.status-world-kernel
Modified:
stable/10/etc/defaults/periodic.conf
stable/10/etc/periodic/daily/Makefile
stable/10/share/man/man5/periodic.conf.5
Directory Properties:
stable/10/ (props changed)
Modified: stable/10/etc/defaults/periodic.conf
==
--- stable/10/etc/defaults/periodic.confThu Jan 22 01:23:16 2015
(r277519)
+++ stable/10/etc/defaults/periodic.confThu Jan 22 02:24:09 2015
(r277520)
@@ -144,6 +144,10 @@ daily_status_ntpd_enable="NO"
# Check
daily_queuerun_enable="YES"# Run mail queue
daily_submit_queuerun="YES"# Also submit queue
+# 510.status-world-kernel
+daily_status_world_kernel="YES"# Check the
running
+ # userland/kernel
version
+
# 800.scrub-zfs
daily_scrub_zfs_enable="NO"
daily_scrub_zfs_pools="" # empty string selects all pools
Copied: stable/10/etc/periodic/daily/510.status-world-kernel (from r277216,
head/etc/periodic/daily/510.status-world-kernel)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ stable/10/etc/periodic/daily/510.status-world-kernelThu Jan 22
02:24:09 2015(r277520, copy of r277216,
head/etc/periodic/daily/510.status-world-kernel)
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+# Check that the running userland and kernel versions are in sync.
+
+# If there is a global system configuration file, suck it in.
+#
+if [ -r /etc/defaults/periodic.conf ]
+then
+. /etc/defaults/periodic.conf
+source_periodic_confs
+fi
+
+case "$daily_status_world_kernel" in
+[Yy][Ee][Ss])
+ rc=0
+ _U=$(/usr/bin/uname -U 2>/dev/null)
+ _K=$(/usr/bin/uname -K 2>/dev/null)
+ [ -z "${_U}" -o -z "${_K}" ] && exit 0
+ echo ""
+ echo "Checking userland and kernel versions:"
+ if [ "${_U}" != "${_K}" ]; then
+ echo "Userland and kernel are not in sync"
+ echo "Userland version: ${_U}"
+ echo "Kernel version: ${_K}"
+ rc=1
+ else
+ echo "Userland and kernel are in sync."
+ fi
+ ;;
+
+*) rc=0;;
+esac
+
+exit $rc
Modified: stable/10/etc/periodic/daily/Makefile
==
--- stable/10/etc/periodic/daily/Makefile Thu Jan 22 01:23:16 2015
(r277519)
+++ stable/10/etc/periodic/daily/Makefile Thu Jan 22 02:24:09 2015
(r277520)
@@ -16,6 +16,7 @@ FILES=100.clean-disks \
409.status-gconcat \
420.status-network \
450.status-security \
+ 510.status-world-kernel \
999.local
# NB: keep these sorted by MK_* knobs
Modified: stable/10/share/man/man5/periodic.conf.5
==
--- stable/10/share/man/man5/periodic.conf.5Thu Jan 22 01:23:16 2015
(r277519)
+++ stable/10/share/man/man5/periodic.conf.5Thu Jan 22 02:24:09 2015
(r277520)
@@ -25,7 +25,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd December 25, 2013
+.Dd January 15, 2015
.Dt PERIODIC.CONF 5
.Os
.Sh NAME
@@ -498,6 +498,11 @@ for yesterday's mail rejects.
Set to
.Dq Li YES
if you want to enable NTP status check.
+.It Va daily_status_world_kernel
+.Pq Vt bool
+Set to
+.Dq Li YES
+to check the running userland and kernel are in sync.
.It Va daily_queuerun_enable
.Pq Vt bool
Set to
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277521 - in stable/9: etc/defaults etc/periodic/daily share/man/man5
Author: gjb
Date: Thu Jan 22 02:24:42 2015
New Revision: 277521
URL: https://svnweb.freebsd.org/changeset/base/277521
Log:
MFC r277216:
Evaluate running userland/kernel version in daily
periodic(8) run, taken from uname(1) '-U' and '-K'
flags.
Sponsored by: The FreeBSD Foundation
Added:
stable/9/etc/periodic/daily/510.status-world-kernel
- copied unchanged from r277216,
head/etc/periodic/daily/510.status-world-kernel
Modified:
stable/9/etc/defaults/periodic.conf
stable/9/etc/periodic/daily/Makefile
stable/9/share/man/man5/periodic.conf.5
Directory Properties:
stable/9/etc/ (props changed)
stable/9/share/man/man5/ (props changed)
Modified: stable/9/etc/defaults/periodic.conf
==
--- stable/9/etc/defaults/periodic.conf Thu Jan 22 02:24:09 2015
(r277520)
+++ stable/9/etc/defaults/periodic.conf Thu Jan 22 02:24:42 2015
(r277521)
@@ -152,6 +152,10 @@ pkg_info="pkg_info"
# Use this progr
daily_queuerun_enable="YES"# Run mail queue
daily_submit_queuerun="YES"# Also submit queue
+# 510.status-world-kernel
+daily_status_world_kernel="YES"# Check the
running
+ # userland/kernel
version
+
# 800.scrub-zfs
daily_scrub_zfs_enable="NO"
daily_scrub_zfs_pools="" # empty string selects all pools
Copied: stable/9/etc/periodic/daily/510.status-world-kernel (from r277216,
head/etc/periodic/daily/510.status-world-kernel)
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ stable/9/etc/periodic/daily/510.status-world-kernel Thu Jan 22 02:24:42
2015(r277521, copy of r277216,
head/etc/periodic/daily/510.status-world-kernel)
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# $FreeBSD$
+#
+# Check that the running userland and kernel versions are in sync.
+
+# If there is a global system configuration file, suck it in.
+#
+if [ -r /etc/defaults/periodic.conf ]
+then
+. /etc/defaults/periodic.conf
+source_periodic_confs
+fi
+
+case "$daily_status_world_kernel" in
+[Yy][Ee][Ss])
+ rc=0
+ _U=$(/usr/bin/uname -U 2>/dev/null)
+ _K=$(/usr/bin/uname -K 2>/dev/null)
+ [ -z "${_U}" -o -z "${_K}" ] && exit 0
+ echo ""
+ echo "Checking userland and kernel versions:"
+ if [ "${_U}" != "${_K}" ]; then
+ echo "Userland and kernel are not in sync"
+ echo "Userland version: ${_U}"
+ echo "Kernel version: ${_K}"
+ rc=1
+ else
+ echo "Userland and kernel are in sync."
+ fi
+ ;;
+
+*) rc=0;;
+esac
+
+exit $rc
Modified: stable/9/etc/periodic/daily/Makefile
==
--- stable/9/etc/periodic/daily/MakefileThu Jan 22 02:24:09 2015
(r277520)
+++ stable/9/etc/periodic/daily/MakefileThu Jan 22 02:24:42 2015
(r277521)
@@ -18,6 +18,7 @@ FILES=100.clean-disks \
409.status-gconcat \
420.status-network \
450.status-security \
+ 510.status-world-kernel \
999.local
# NB: keep these sorted by MK_* knobs
Modified: stable/9/share/man/man5/periodic.conf.5
==
--- stable/9/share/man/man5/periodic.conf.5 Thu Jan 22 02:24:09 2015
(r277520)
+++ stable/9/share/man/man5/periodic.conf.5 Thu Jan 22 02:24:42 2015
(r277521)
@@ -25,7 +25,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd May 30, 2012
+.Dd January 15, 2015
.Dt PERIODIC.CONF 5
.Os
.Sh NAME
@@ -633,6 +633,11 @@ if you want to enable reverse DNS lookup
Set to
.Dq Li YES
if you want to enable NTP status check.
+.It Va daily_status_world_kernel
+.Pq Vt bool
+Set to
+.Dq Li YES
+to check the running userland and kernel are in sync.
.It Va daily_queuerun_enable
.Pq Vt bool
Set to
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277522 - head/sys/arm/ti/am335x
Author: gonzo
Date: Thu Jan 22 03:32:04 2015
New Revision: 277522
URL: https://svnweb.freebsd.org/changeset/base/277522
Log:
Write ACK for all kinds of LCDC interrupts
Modified:
head/sys/arm/ti/am335x/am335x_lcd.c
Modified: head/sys/arm/ti/am335x/am335x_lcd.c
==
--- head/sys/arm/ti/am335x/am335x_lcd.c Thu Jan 22 02:24:42 2015
(r277521)
+++ head/sys/arm/ti/am335x/am335x_lcd.c Thu Jan 22 03:32:04 2015
(r277522)
@@ -365,7 +365,7 @@ am335x_lcd_intr(void *arg)
reg = LCD_READ4(sc, LCD_RASTER_CTRL);
reg |= RASTER_CTRL_LCDEN;
LCD_WRITE4(sc, LCD_RASTER_CTRL, reg);
- return;
+ goto done;
}
if (reg & IRQ_PL) {
@@ -376,7 +376,7 @@ am335x_lcd_intr(void *arg)
reg = LCD_READ4(sc, LCD_RASTER_CTRL);
reg |= RASTER_CTRL_LCDEN;
LCD_WRITE4(sc, LCD_RASTER_CTRL, reg);
- return;
+ goto done;
}
if (reg & IRQ_EOF0) {
@@ -399,6 +399,7 @@ am335x_lcd_intr(void *arg)
/* TODO: Handle ACB */
}
+done:
LCD_WRITE4(sc, LCD_END_OF_INT_IND, 0);
}
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277523 - head/sys/arm/arm
Author: gonzo
Date: Thu Jan 22 03:33:51 2015
New Revision: 277523
URL: https://svnweb.freebsd.org/changeset/base/277523
Log:
Add last_fault_code used in pmap-v6.c if kernel is compiled with "option
DEBUG"
Modified:
head/sys/arm/arm/trap-v6.c
Modified: head/sys/arm/arm/trap-v6.c
==
--- head/sys/arm/arm/trap-v6.c Thu Jan 22 03:32:04 2015(r277522)
+++ head/sys/arm/arm/trap-v6.c Thu Jan 22 03:33:51 2015(r277523)
@@ -67,6 +67,10 @@ __FBSDID("$FreeBSD$");
extern char fusubailout[];
+#ifdef DEBUG
+int last_fault_code; /* For the benefit of pmap_fault_fixup() */
+#endif
+
struct ksig {
int sig;
u_long code;
@@ -457,6 +461,10 @@ abort_handler(struct trapframe *tf, int
if (prefetch)
ftype |= VM_PROT_EXECUTE;
+#ifdef DEBUG
+ last_fault_code = fsr;
+#endif
+
#ifndef ARM_NEW_PMAP
if (pmap_fault_fixup(vmspace_pmap(td->td_proc->p_vmspace), va, ftype,
usermode)) {
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r277524 - in head/sys: dev/hwpmc sys
Author: rstone Date: Thu Jan 22 03:56:23 2015 New Revision: 277524 URL: https://svnweb.freebsd.org/changeset/base/277524 Log: style(9) cleanup Modified: head/sys/dev/hwpmc/hwpmc_core.c head/sys/dev/hwpmc/pmc_events.h head/sys/sys/pmc.h Modified: head/sys/dev/hwpmc/hwpmc_core.c == --- head/sys/dev/hwpmc/hwpmc_core.c Thu Jan 22 03:33:51 2015 (r277523) +++ head/sys/dev/hwpmc/hwpmc_core.c Thu Jan 22 03:56:23 2015 (r277524) @@ -680,7 +680,8 @@ static struct iap_event_descr iap_events IAPDESCR(08H_0EH, 0x08, 0x0E, IAP_F_FM | IAP_F_HW | IAP_F_HWX), IAPDESCR(08H_10H, 0x08, 0x10, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_SBX | IAP_F_HW | IAP_F_HWX), -IAPDESCR(08H_20H, 0x08, 0x20, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW | IAP_F_HWX), +IAPDESCR(08H_20H, 0x08, 0x20, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW | +IAP_F_HWX), IAPDESCR(08H_40H, 0x08, 0x40, IAP_F_FM | IAP_F_I7O | IAP_F_HW | IAP_F_HWX), IAPDESCR(08H_60H, 0x08, 0x60, IAP_F_FM | IAP_F_HW | IAP_F_HWX), IAPDESCR(08H_80H, 0x08, 0x80, IAP_F_FM | IAP_F_I7 | IAP_F_HW | IAP_F_HWX), @@ -710,9 +711,12 @@ static struct iap_event_descr iap_events IAPDESCR(0EH_01H, 0x0E, 0x01, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_SB | IAP_F_IB | IAP_F_SBX | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), IAPDESCR(0EH_02H, 0x0E, 0x02, IAP_F_FM | IAP_F_I7 | IAP_F_WM), -IAPDESCR(0EH_10H, 0x0E, 0x10, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), -IAPDESCR(0EH_20H, 0x0E, 0x20, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), -IAPDESCR(0EH_40H, 0x0E, 0x40, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), +IAPDESCR(0EH_10H, 0x0E, 0x10, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), +IAPDESCR(0EH_20H, 0x0E, 0x20, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), +IAPDESCR(0EH_40H, 0x0E, 0x40, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), IAPDESCR(0FH_01H, 0x0F, 0x01, IAP_F_FM | IAP_F_I7), IAPDESCR(0FH_02H, 0x0F, 0x02, IAP_F_FM | IAP_F_I7 | IAP_F_WM), @@ -826,7 +830,8 @@ static struct iap_event_descr iap_events IAPDESCR(24H_AAH, 0x24, 0xAA, IAP_F_FM | IAP_F_I7 | IAP_F_WM), IAPDESCR(24H_F8H, 0x24, 0xF8, IAP_F_FM | IAP_F_HW | IAP_F_HWX), IAPDESCR(24H_3FH, 0x24, 0x3F, IAP_F_FM | IAP_F_HW | IAP_F_HWX), -IAPDESCR(24H_FFH, 0x24, 0xFF, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW | IAP_F_HWX), +IAPDESCR(24H_FFH, 0x24, 0xFF, IAP_F_FM | IAP_F_I7 | IAP_F_WM | IAP_F_HW | +IAP_F_HWX), IAPDESCR(25H, 0x25, IAP_M_CORE, IAP_F_ALLCPUSCORE2), @@ -967,7 +972,8 @@ static struct iap_event_descr iap_events IAPDESCR(49H_20H, 0x49, 0x20, IAP_F_FM | IAP_F_I7 | IAP_F_HW | IAP_F_HWX), IAPDESCR(49H_40H, 0x49, 0x40, IAP_F_FM | IAP_F_I7O | IAP_F_HW | IAP_F_HWX), IAPDESCR(49H_60H, 0x49, 0x60, IAP_F_FM | IAP_F_HW | IAP_F_HWX), -IAPDESCR(49H_80H, 0x49, 0x80, IAP_F_FM | IAP_F_WM | IAP_F_I7 | IAP_F_HW | IAP_F_HWX), +IAPDESCR(49H_80H, 0x49, 0x80, IAP_F_FM | IAP_F_WM | IAP_F_I7 | IAP_F_HW | +IAP_F_HWX), IAPDESCR(4BH_00H, 0x4B, 0x00, IAP_F_FM | IAP_F_ALLCPUSCORE2), IAPDESCR(4BH_01H, 0x4B, 0x01, IAP_F_FM | IAP_F_ALLCPUSCORE2 | IAP_F_I7O), @@ -1008,10 +1014,14 @@ static struct iap_event_descr iap_events IAPDESCR(53H_01H, 0x53, 0x01, IAP_F_FM | IAP_F_I7 | IAP_F_WM), -IAPDESCR(58H_01H, 0x58, 0x01, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), -IAPDESCR(58H_02H, 0x58, 0x02, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), -IAPDESCR(58H_04H, 0x58, 0x04, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), -IAPDESCR(58H_08H, 0x58, 0x08, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), +IAPDESCR(58H_01H, 0x58, 0x01, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), +IAPDESCR(58H_02H, 0x58, 0x02, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), +IAPDESCR(58H_04H, 0x58, 0x04, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), +IAPDESCR(58H_08H, 0x58, 0x08, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), IAPDESCR(59H_20H, 0x59, 0x20, IAP_F_FM | IAP_F_SB | IAP_F_SBX), IAPDESCR(59H_40H, 0x59, 0x40, IAP_F_FM | IAP_F_SB | IAP_F_SBX), @@ -1114,8 +1124,8 @@ static struct iap_event_descr iap_events IAPDESCR(79H_30H, 0x79, 0x30, IAP_F_FM | IAP_F_SB | IAP_F_IB | IAP_F_SBX | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), - -IAPDESCR(79H_3CH, 0x79, 0x3C, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | IAP_F_HWX), +IAPDESCR(79H_18H, 0x79, 0x18, IAP_F_FM | IAP_F_IB | IAP_F_IBX | IAP_F_HW | +IAP_F_HWX), IAPDESCR(7AH, 0x7A, IAP_M_AGENT, IAP_F_CA | IAP_F_CC2), @@ -1367,7 +1377,8 @@ static struct iap_event_descr iap_events IAPDESCR(B6H_04H, 0xB6, 0x04, IAP_F_CAS), IAPDESCR(B7H_01H, 0xB7, 0x01, IAP_F_
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
> On Jan 20, 2015, at 12:35 AM, Hans Petter Selasky wrote: > > On 01/20/15 06:22, Adrian Chadd wrote: >> Sweet, thanks. I'l test it, but anything that changes the locking to >> TCP is going to need a more thorough review. The "there be dragons" >> disclaimer is appropriate.:) > > No changes in locking - simply some minor code reordering. This isn’t entirely true. You changed the INFO_WLOCK protocol, and also drop the WLOCK to acquire the INFO_WLOCK in places, and it isn’t clear to me at all why this is safe to do. Please document the analysis you did to show that was safe. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
> On Jan 20, 2015, at 2:37 AM, Hans Petter Selasky wrote:
>
> On 01/20/15 10:00, Konstantin Belousov wrote:
>> On Tue, Jan 20, 2015 at 08:58:34AM +0100, Hans Petter Selasky wrote:
>>> On 01/20/15 08:51, Konstantin Belousov wrote:
On Tue, Jan 20, 2015 at 05:30:25AM +0100, Hans Petter Selasky wrote:
> On 01/19/15 22:59, Adrian Chadd wrote:
>> Hi,
>>
>> Would you please check what the results of this are with CPU specific
>> callwheels?
>>
>> I'm doing some 10+ gig traffic testing on -HEAD with RSS enabled (on
>> ixgbe) and with this setup, the per-CPU TCP callwheel stuff is
>> enabled. But all the callwheels are now back on clock(0) and so is the
>> lock contention. :(
>>
>> Thanks,
>>
>
> Hi,
>
> Like stated in the manual page, callout_reset_curcpu/on() does not work
> with MPSAFE callouts any more!
I.e. you 'fixed' some undeterminate bugs in callout migration by not
doing migration at all anymore.
>
> You need to use callout_init_{mtx,rm,rw} and remove the custom locking
> inside the callback in the TCP stack to get it working like before!
No, you need to do this, if you think that whole callout KPI must be
rototiled. It is up to the person who modifies the KPI, to ensure that
existing code is not broken.
>
> Hi,
>
> It is not very hard to update existing callout clients and you can do it too,
> if you need the extra bits of performance.
>
> Are there more API's than the TCP stack which you think needs an update and
> are performance critical?
>
As I understand, currently we are back to the one-cpu callouts.
Do other people consider this situation acceptable ?
>
> For the TCP stack - yes, but not for other clients like cv_timedwait() and
> such.
>
> If you think you have a better way to solve the callout problems, please tell
> me! In order for a callout to change its CPU you need a lock to protect which
> CPU the callout is on. Instead of introducing a third lock in the callout
> path, which will be a congestion point, to protect against changing the CPU
> number, I decided that we will use the client's mutex and the MPSAFE implies
> the client doesn't have any mutex. So it won't work with callout clients
> which use the CALLOUT_MPSAFE flag. Honestly CALLOUT_MPSAFE should not be
> used, because it leads to extra complexity in the clients catching the race
> when tearing down the callouts and any pending callbacks.
Then it is incumbent on you to fix them. You can’t just fix one instance and
wash your hands of the problem.
Maybe this is a real and legitimate bug. However, until you’ve followed your
solution through by actually fixing the abusers of it, my confidence that
another issue won’t present itself is quite low. The code seems half baked to
me. And from reading this thread, it seems like perhaps I’m not the only one.
>>> Please read the callout 9 manual page first.
>>
>> Assume I read it. How this changes any of my points above ?
>> """
>> A change in the CPU selection cannot happen if this function is
>> re-scheduled inside a callout function. Else the callback function given
>> by the func argument will be executed on the same CPU like previously
>> done.
>> """
>> You cannot do this without fixing consumers.
>>
>
> The code simply needs an update. It is not broken in any ways - right? If it
> is not broken, fixing it is not that urgent.
Radically changing the performance characteristics is breaking the code.
Performance regression in the TCP stack is urgent to fix. Not being able to
enumerate what all the consumers are that use this and provide an analysis
about why they aren’t important to fix is a bug in your process, and in your
interaction with the project. We simply do not operate that way.
Warner
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
> On Jan 20, 2015, at 12:51 AM, Konstantin Belousov wrote: > Do other people consider this situation acceptable ? Not even a little. Warner ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys
On 01/22/15 06:26, Warner Losh wrote: > The code simply needs an update. It is not broken in any ways - right? If it is not broken, fixing it is not that urgent. Radically changing the performance characteristics is breaking the code. Performance regression in the TCP stack is urgent to fix. Not being able to enumerate what all the consumers are that use this and provide an analysis about why they aren’t important to fix is a bug in your process, and in your interaction with the project. We simply do not operate that way. Hi, My plan is to work out a patch for the TCP stack today, which only change the callout_init() call or its function. This should not need any particular review. I'll let adrian test and review, because I think he is closer to me timezone wise and you're standing on my head saying its urgent. If he is still not happy, I can back my change out. Else it remains in -current AS-IS. MFC to 10-stable I can delay for sure until all issues you report to me are fixed. Thank you for your patience! --HPS ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
