Re: WITHOUT_PROFILE=yes by default
Quick! Martinis for all conversation participants, stat! Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On 12/01/2011 23:23, Steve Kargl wrote: > On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote: >> On 12/01/2011 22:41, Steve Kargl wrote: >> >>> Having a set of profiled libraries in-sync with the static >>> and shared libraries allows one to run the profiler on their >>> code when someone changes a library and that change causes >>> a dramatic change in the performance of one's code. >> >> And as Max pointed out in his OP, that only applies to a tiny fraction >> of our users, or even our developers. If you want to use them, turn the >> knob. > > Not only do I want to use them, I do use use profiled libraries. > All those changes to libm that I've submitted over the years > have been run through the profile. I'm glad that you find them useful. How does changing the default affect your ability to do that? > More importantly, we are > discussion freebsd-current. I would hope that the other developers > profile their changes to system before committing. I'd be happy if our developers would stop breaking the build. >>> PS: David was not complaining about "fixing a 17 year old bug". >>> He was stating that a single day of discussion changing >>> a 17 year old practice seems a little too brief. >> >> If it's a good idea, it's a good idea no matter how many different ways >> we flog it. :) >> > > I think it is a horrible idea. Perhaps, we should discuss the > technical issues before you start yet another bikeshed (see > your recent posts concerning the ports repo for your hypocricy). Um, you did see the smiley, right? -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On Thu, Dec 01, 2011 at 10:59:59PM -0800, Doug Barton wrote: > On 12/01/2011 22:41, Steve Kargl wrote: > > > Having a set of profiled libraries in-sync with the static > > and shared libraries allows one to run the profiler on their > > code when someone changes a library and that change causes > > a dramatic change in the performance of one's code. > > And as Max pointed out in his OP, that only applies to a tiny fraction > of our users, or even our developers. If you want to use them, turn the > knob. Not only do I want to use them, I do use use profiled libraries. All those changes to libm that I've submitted over the years have been run through the profile. More importantly, we are discussion freebsd-current. I would hope that the other developers profile their changes to system before committing. > > > PS: David was not complaining about "fixing a 17 year old bug". > > He was stating that a single day of discussion changing > > a 17 year old practice seems a little too brief. > > If it's a good idea, it's a good idea no matter how many different ways > we flog it. :) > I think it is a horrible idea. Perhaps, we should discuss the technical issues before you start yet another bikeshed (see your recent posts concerning the ports repo for your hypocricy). -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Upgrade contributed gperf, m4 and flex
On Fri, Nov 25, 2011 at 08:01:37PM +0100, Baptiste Daroussin wrote: > and last: upgrade flex to the latest upstream version (it will need the m4 > upgrade) while here I'll move back flex to contrib/ > patches can be found there: > http://people.freebsd.org/~bapt/flex-update.diff Hi Baptiste, I cannot tell from this what you are really doing. It would likely be best to keep the old history, so that would involve a 'svn move usr.bin/lex contrib/flex'. Additionally if flex is now considered to be 3rd-party code (signified by living in contrib/) it should be imported we into '$REPO/base/vendor'. These actions would give a different diff than that above. Do you have a diff that shows what the real changes to FreeBSD are? > I also plan to upgrade m4 syncing code from openbsd, taking code from netbsd > (improve gnu m4 compatibility). > http://people.freebsd.org/~bapt/update_m4_from_openbsd_and_netbsd.diff We don't seen to have '$REPO/base/vendor/OpenBSD/m4' as we likely should. How different is our usr.bin/m4 from OpenBSD's? > http://people.freebsd.org/~bapt/upgrade-gperf-to-3.0.3.diff I assume an import into '$REPO/base/vendor/gperf/' will happen first? ['$REPO/base/vendor/gperf/' needs to be "flattend out" first] thanks, -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On 12/01/2011 22:41, Steve Kargl wrote: > Having a set of profiled libraries in-sync with the static > and shared libraries allows one to run the profiler on their > code when someone changes a library and that change causes > a dramatic change in the performance of one's code. And as Max pointed out in his OP, that only applies to a tiny fraction of our users, or even our developers. If you want to use them, turn the knob. > PS: David was not complaining about "fixing a 17 year old bug". > He was stating that a single day of discussion changing > a 17 year old practice seems a little too brief. If it's a good idea, it's a good idea no matter how many different ways we flog it. :) Doug -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On Fri, Dec 02, 2011 at 11:56:31AM +0700, Max Khon wrote: > David, > > On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien wrote: > > On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > > I would like to disable building profiled libraries by default. Opinions? > > > > On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: > > > Author: fjoe > > > Date: Tue Nov 29 19:46:17 2011 > > > New Revision: 228143 > > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > > > Log: > > > Turn off profiled libs build by default. > > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > > > Wow, a single day of discussion in freebsd-current@ was sufficient to > > invert a 17 year default. > > > > You still failed to name a single compelling reason to leave profiled libs > even in -CURRENT. > Having a set of profiled libraries in-sync with the static and shared libraries allows one to run the profiler on their code when someone changes a library and that change causes a dramatic change in the performance of one's code. PS: David was not complaining about "fixing a 17 year old bug". He was stating that a single day of discussion changing a 17 year old practice seems a little too brief. PPS: I was on work-related travel for the last 4 days, and only saw this discussion after you pulled the trigger. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Steve, On Fri, Dec 2, 2011 at 1:33 PM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote: > > On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > > I would like to disable building profiled libraries by default. > Opinions? > > > > On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: > > > Author: fjoe > > > Date: Tue Nov 29 19:46:17 2011 > > > New Revision: 228143 > > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > > > Log: > > > Turn off profiled libs build by default. > > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > > > Wow, a single day of discussion in freebsd-current@ was sufficient to > > invert a 17 year default. > > > > I'd like to see the profile libs remain built by default in -CURRENT. > > > > +1 > > In particular, many (most, all?) people running -current > will have profiled libaries installed. These libraries > will become stale/out-of-sync with the static and shared > libraries as (if) changes are made to libc. This is a completely different thing and is actually what ObsoleteFilesInc/OptionalObsoleteFiles.inc mechanism is for. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On Fri, Dec 02, 2011 at 12:41:00PM +0800, Adrian Chadd wrote: > On 2 December 2011 09:51, David O'Brien wrote: > > > Wow, a single day of discussion in freebsd-current@ was sufficient to > > invert a 17 year default. > > > > I'd like to see the profile libs remain built by default in -CURRENT. > > > > If you like, add it to the list of things to disable on -STABLE creation. > > It's easier to do that than go review/re-engineer bloated code. :) > To what does "that" refer? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On Thu, Dec 01, 2011 at 05:51:33PM -0800, David O'Brien wrote: > On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > I would like to disable building profiled libraries by default. Opinions? > > On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: > > Author: fjoe > > Date: Tue Nov 29 19:46:17 2011 > > New Revision: 228143 > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > Log: > > Turn off profiled libs build by default. > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > Wow, a single day of discussion in freebsd-current@ was sufficient to > invert a 17 year default. > > I'd like to see the profile libs remain built by default in -CURRENT. > +1 In particular, many (most, all?) people running -current will have profiled libaries installed. These libraries will become stale/out-of-sync with the static and shared libraries as (if) changes are made to libc. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 8:55 AM, David O'Brien wrote: If you go with (2) above, we'll still have *tons* of ports that want a > libreadline, so we'll just end up growing a port of it and we'll wind up > with a libreadline on the system anyway. Then you need to define what base system is. We have much more ports that depend on libintl or libglib2 than libreadline. Should we add these libs to the base system too? Also, almost all ports require gmake and autotools to be built. Should we add them to the base system too? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
David, On Fri, Dec 2, 2011 at 8:51 AM, David O'Brien wrote: On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > > I would like to disable building profiled libraries by default. Opinions? > > On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: > > Author: fjoe > > Date: Tue Nov 29 19:46:17 2011 > > New Revision: 228143 > > URL: http://svn.freebsd.org/changeset/base/228143 > > > > Log: > > Turn off profiled libs build by default. > > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf > > Wow, a single day of discussion in freebsd-current@ was sufficient to > invert a 17 year default. > You still failed to name a single compelling reason to leave profiled libs even in -CURRENT. And it sounds like we should not fix 17-year old bugs or things that are no longer of any practical use because they were implemented 17 years ago. I'd like to see the profile libs remain built by default in -CURRENT. > > If you like, add it to the list of things to disable on -STABLE creation. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: removing libreadline from base system
David, On Fri, Dec 2, 2011 at 8:59 AM, David O'Brien wrote: > This is a separate issue that I want to handle separately. > > I see no value in handling it separately. I either have a libreadline on > my system or I don't. > What I meant is that this problem is not related to the original question but it will be analyzed/resolved before the commit (if it will ever happen). I am not saying that my sole intention is to remove libreadline from base system. I just picked an item from here http://wiki.freebsd.org/GPLinBase and will come up with the analysis. If it turns out that libreadline removal is impractical it will not be removed. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On 2 December 2011 09:51, David O'Brien wrote: > Wow, a single day of discussion in freebsd-current@ was sufficient to > invert a 17 year default. > > I'd like to see the profile libs remain built by default in -CURRENT. > > If you like, add it to the list of things to disable on -STABLE creation. It's easier to do that than go review/re-engineer bloated code. :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: removing libreadline from base system
Brooks, On Fri, Dec 2, 2011 at 9:41 AM, Brooks Davis wrote: > What is the value in doing either? > > > > libreadline isn't infecting any non-GPL code turning into GPLv2. > > > > Some of use have fancy .input files, and quite frankly the vi mode of > > libedit still doesn't work quite the same as libreadline. > > > > If you go with (2) above, we'll still have *tons* of ports that want a > > libreadline, so we'll just end up growing a port of it and we'll wind up > > with a libreadline on the system anyway. > > We are rapidly approaching the point where it will be practical to > remove all GPL code from the base system (assuming we are willing to > require external toolchains for some architectures) and a number of us > are pushing to make this a reality for 10.0. If we have people willing > to do the work now--as Max seems to be--then we might as well deal with > the ports fallout from the removal of libreadline sooner rather than > later. > > The existence of incompatibilities between libedit and libreadline > probably does argue for option (2). Agree. I submitted the patch w/ INTERNALLIB for libreadline for 10.0 exp-run. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
On 12/1/11 4:42 PM, Andriy Gapon wrote:
on 01/12/2011 22:53 John Baldwin said the following:
On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote:
Returning to critical_exit, what do you think about the following patch?
I guess that it could be committed independently of / before the
SCHEDULER_STOPPED thing.
commit ee3d1a04985e86911a68d854439ae8c5429b7bd5
Author: Andriy Gapon
Date: Thu Dec 1 18:53:36 2011 +0200
critical_exit: ignore td_owepreempt if kdb_active
calling mi_switch in such a context result in a recursion via
kdb_switch
diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c
index 93cbf7b..885dc22 100644
--- a/sys/kern/kern_switch.c
+++ b/sys/kern/kern_switch.c
@@ -200,7 +200,7 @@ critical_exit(void)
if (td->td_critnest == 1) {
td->td_critnest = 0;
- if (td->td_owepreempt) {
+ if (td->td_owepreempt&& !kdb_active) {
td->td_critnest = 1;
thread_lock(td);
td->td_critnest--;
I think this is fine, but I'd probably change this to SCHEDULER_STOPPED()
in the SCHEDULER_STOPPED() patch.
I don't understand why... What if kdb is entered for some other reason, not
because of panic? In that case SCHEDULER_STOPPED() would be false, but it is
still possible to find a way into mi_switch.
The SCHEDULER_STOPPED patch adds this:
@@ -428,6 +428,8 @@ mi_switch(int flags, struct thread *newtd)
*/
if (kdb_active)
kdb_switch();
+ if (SCHEDULER_STOPPED())
+ return;
if (flags& SW_VOL) {
td->td_ru.ru_nvcsw++;
td->td_swvoltick = ticks;
Ah, ok (I had thought SCHEDULER_STOPPED was going to always be true when
kdb was active). But I think these two changes should cover
critical_exit() ok.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stupid cp(1) behaviour
On Thu, Dec 1, 2011 at 2:35 PM, Matt Mullins wrote: > On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote: >> implement a new -N switch or so which isn't based on a file's existance, but >> a >> file's checksum. > > You can always use net/rsync, which does by default compare checksums. sysutils/cpdup also does this. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: removing libreadline from base system
On Thu, Dec 01, 2011 at 05:55:37PM -0800, David O'Brien wrote: > On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: > > It is possible to build and link our in-tree gdb & friends with libedit > > after r228114. > > The remaining question is what to do with libreadline: > > 1) just build & link gdb with libedit > > OR > > 2) re-import libreadline from gdb sources and build INTERNALLIB version of > > it that is never installed and is linked only to gdb > > Max, > What is the value in doing either? > > libreadline isn't infecting any non-GPL code turning into GPLv2. > > Some of use have fancy .input files, and quite frankly the vi mode of > libedit still doesn't work quite the same as libreadline. > > If you go with (2) above, we'll still have *tons* of ports that want a > libreadline, so we'll just end up growing a port of it and we'll wind up > with a libreadline on the system anyway. We are rapidly approaching the point where it will be practical to remove all GPL code from the base system (assuming we are willing to require external toolchains for some architectures) and a number of us are pushing to make this a reality for 10.0. If we have people willing to do the work now--as Max seems to be--then we might as well deal with the ports fallout from the removal of libreadline sooner rather than later. The existence of incompatibilities between libedit and libreadline probably does argue for option (2). -- Brooks pgpNBlLgOGQcg.pgp Description: PGP signature
Re: removing libreadline from base system
On Tue, Nov 29, 2011 at 12:02:23PM +0700, Max Khon wrote: > It is possible to build and link our in-tree gdb & friends with libedit > after r228114. > The remaining question is what to do with libreadline: > 1) just build & link gdb with libedit > OR > 2) re-import libreadline from gdb sources and build INTERNALLIB version of > it that is never installed and is linked only to gdb Max, What is the value in doing either? libreadline isn't infecting any non-GPL code turning into GPLv2. Some of use have fancy .input files, and quite frankly the vi mode of libedit still doesn't work quite the same as libreadline. If you go with (2) above, we'll still have *tons* of ports that want a libreadline, so we'll just end up growing a port of it and we'll wind up with a libreadline on the system anyway. > I am inclined to go for 1) but libedit may have (and has) incompatibilities > with libreadline. I'm inclined to DO NOTHING. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On Mon, Nov 28, 2011 at 05:38:20PM +0700, Max Khon wrote: > I would like to disable building profiled libraries by default. Opinions? On Tue, Nov 29, 2011 at 07:46:17PM +, Max Khon wrote: > Author: fjoe > Date: Tue Nov 29 19:46:17 2011 > New Revision: 228143 > URL: http://svn.freebsd.org/changeset/base/228143 > > Log: > Turn off profiled libs build by default. > Can be enabled back using WITH_PROFILE=yes in /etc/src.conf Wow, a single day of discussion in freebsd-current@ was sufficient to invert a 17 year default. I'd like to see the profile libs remain built by default in -CURRENT. If you like, add it to the list of things to disable on -STABLE creation. -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: removing libreadline from base system
On Tue, Nov 29, 2011 at 04:46:30PM +0700, Max Khon wrote: > This is a separate issue that I want to handle separately. I see no value in handling it separately. I either have a libreadline on my system or I don't. Again, "what problem are you trying to solve"? > The question is what to do with gdb & friends. Link it with libedit or > re-import bundled readline (that is shipped with gdb) and build/link it > only to gdb. > > I am inclined to do the former. Consider this an explicit request to do nothing to the base libreadline. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Remove debug echo
On Thu, Dec 1, 2011 at 6:08 PM, David O'Brien wrote: > On Thu, Dec 01, 2011 at 10:04:08AM -0500, John Baldwin wrote: >> I think this is useful, perhaps send it to harti@ or jilles@ for review? > > I'd like to get some NetBSD bmake maintainers POV too. > We should reduce the needless diversion between the two makes. Agreed, but this is also a more extensive project. I just implemented the patch shown above because it makes pmake in FreeBSD match GNU make's behavior with printouts, which is a plus for people like me who have scripts that parse for errors messages like that. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stupid cp(1) behaviour
On Thu, Dec 01, 2011 at 11:35:50AM -0800, Matt Mullins wrote: > On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote: > > implement a new -N switch or so which isn't based on a file's > > existance, but a file's checksum. > > You can always use net/rsync, which does by default compare checksums. I don't believe that is true [anymore]: $ rsync --help rsync version 3.0.9 protocol version 30 Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others. [...] -c, --checksum skip based on checksum, not mod-time & size ... -I, --ignore-times don't skip files that match in size and mod-time --size-only skip files that match in size --modify-window=NUM compare mod-times with reduced accuracy -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Remove debug echo
On Thu, Dec 01, 2011 at 10:04:08AM -0500, John Baldwin wrote: > I think this is useful, perhaps send it to harti@ or jilles@ for review? I'd like to get some NetBSD bmake maintainers POV too. We should reduce the needless diversion between the two makes. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Remove debug echo
On Wed, Nov 30, 2011 at 05:59:33PM -0800, Garrett Cooper wrote: > On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best wrote: > > On Wed Nov 30 11, Garrett Cooper wrote: > >> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best > >> wrote: > >> ? ? pmake sucks as far as diagnostic output is concerned when compared > >> with gmake. I'd rather not have to fish through with -j1 (if I'm lucky > >> and it's not a race) to determine what directory created the "Error > >> Code" output. With the printouts discussed here, at least you have a > >> chance at determining what the issue was. > >> ? ? Maybe it's just me, but I like noisy builds -- otherwise the > >> amount of time I have to spend root-causing the issue becomes > >> expensive. [...] > Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I > have to start using some serious grep'ing, and if I'm lucky I can find > the source of error). Well its a PITA mostly because we disabled Pmake's -j "job-markers" back in 1998 (r41151). If you build with 'make -v -j>1' you get much more debugable output. bmake (NetBSD's make) is even nicer in this regard. I was *amazed* when I joined $WORK and a '-j16' build was debugable. -- -- David (obr...@freebsd.org) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Using Instruction Pointer address in debug interfaces [Was: Re: vm_page_t related KBI [Was: Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3]]
Hi, On Mon, Nov 14, 2011 at 5:14 AM, Andriy Gapon wrote: > on 14/11/2011 02:38 Arnaud Lacombe said the following: >> you (committers) > > I wonder how it would work out if you were made a committer and couldn't say > "you (committers)" any more... :-) > The real question is rather whether or not I would accept such a role, or better, would I ever be proposed such a role ? I doubt someone praising the Bazaar, openly challenging core and historical members, would fit in the Cathedral, even if my work is only ever gonna be in the `projects/' subdirectory. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ahci in FreeBSD 9
On Thu, 1 Dec 2011 21:31:18 +0200 George Kontostanos wrote: > Hi everyone, > > From my understanding as of 20110424 revision device ahci has been > integrated into kernel: > > > It is possible to load devices ahci, ata, siis and mvs as modules, but > option ATA_CAM should remain in kernel configuration to make ata > module work as CAM driver supporting legacy ATA controllers. Device > ata still can be used in modular fashion > ... > No kernel config options or code have been removed, so if a problem > arises, please report it and optionally revert to the old ATA stack. > In order to do it you can remove from the kernel config: > optionsATA_CAM > device ahci > > > Does this mean that loading ahci in loader.conf is useless ? > No, I load mine from there. It's not necessary to have "device ahci" in your kernel config file since the module will be generated and installed by default. This is what I have makeoptions MODULES_OVERRIDE="ahci linux linprocfs msdosfs pseudofs" ... #device ahci so it's obvious that I'm using only the module. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [patch] turning devctl into a "multiple openable" device
On Wed, Nov 30, 2011 at 05:20:17PM +0100, Olivier Houchard wrote: > On Wed, Nov 30, 2011 at 06:04:50PM +0200, Kostik Belousov wrote: > > > > I wonder why the waiting_threads stuff is needed at all. The cv could > > > > be woken up unconditionally everytime. What is the reason for the > > > > cv_wait > > > > call in cdevpriv data destructor ? You cannot have a thread doing e.g. > > > > read on the file descriptor while destructor is run. > > > > > > > > > > What will prevent you from having a thread stuck in read(), while an > > > another > > > one close() the fd ? > > > > > Nothing, but file reference count goes to zero only after the thread > > stuck in read is unstuck. Cdevpriv destructor is run only when file > > reference count becomes zero, i.e. there can be no any accessing threads, > > and new accesses are impossible since file descriptors also own references > > on the file. > > Right, I was a bit confused, this part can be removed. > > Regards, > > Olivier Here is a new version of the patch mostly reworked by Olivier, It doesn't duplicate anymore the devq, and fix all that have been spotted here previously. http://people.freebsd.org/~bapt/devctl_multi_open.diff bonus, it removes the needless giant lock regards, Bapt pgpcRpG0lN1YH.pgp Description: PGP signature
Re: Remove debug echo
On Thu, Dec 1, 2011 at 9:17 AM, Freddie Cash wrote: > So, now that you've improved the default diagnostic output of make, how > about the OP's original request: > make -s truly silent by removing unnecessary diagnostic messages when -s > is used? :) > > [Thought I'd bring the thread back around to it's original purpose.] Sure. I'd be more than happy if someone would review and commit my proposed patches as well :). Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
on 01/12/2011 22:53 John Baldwin said the following:
> On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote:
>> Returning to critical_exit, what do you think about the following patch?
>> I guess that it could be committed independently of / before the
>> SCHEDULER_STOPPED thing.
>>
>> commit ee3d1a04985e86911a68d854439ae8c5429b7bd5
>> Author: Andriy Gapon
>> Date: Thu Dec 1 18:53:36 2011 +0200
>>
>> critical_exit: ignore td_owepreempt if kdb_active
>>
>> calling mi_switch in such a context result in a recursion via
>> kdb_switch
>>
>> diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c
>> index 93cbf7b..885dc22 100644
>> --- a/sys/kern/kern_switch.c
>> +++ b/sys/kern/kern_switch.c
>> @@ -200,7 +200,7 @@ critical_exit(void)
>>
>> if (td->td_critnest == 1) {
>> td->td_critnest = 0;
>> -if (td->td_owepreempt) {
>> +if (td->td_owepreempt && !kdb_active) {
>> td->td_critnest = 1;
>> thread_lock(td);
>> td->td_critnest--;
>
> I think this is fine, but I'd probably change this to SCHEDULER_STOPPED()
> in the SCHEDULER_STOPPED() patch.
I don't understand why... What if kdb is entered for some other reason, not
because of panic? In that case SCHEDULER_STOPPED() would be false, but it is
still possible to find a way into mi_switch.
The SCHEDULER_STOPPED patch adds this:
@@ -428,6 +428,8 @@ mi_switch(int flags, struct thread *newtd)
*/
if (kdb_active)
kdb_switch();
+ if (SCHEDULER_STOPPED())
+ return;
if (flags & SW_VOL) {
td->td_ru.ru_nvcsw++;
td->td_swvoltick = ticks;
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r227487 breaks C++ programs that use __isthreaded
On Thu, Dec 01, 2011, George Liaskos wrote: > Hello > > One example is Google's tcmalloc [1], is this behaviour intended? > > [1] > http://code.google.com/p/google-perftools/source/browse/trunk/src/maybe_threads.cc This code uses an unportable workaround for a bug that I believe was fixed in r227999. Using internal names starting with a double underscore isn't supported. Separately, I'm still hoping that the namespace polution introduced in r227487 gets fixed... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
On Thursday, December 01, 2011 3:42:24 pm Andriy Gapon wrote:
> on 01/12/2011 20:49 John Baldwin said the following:
> > On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote:
> >>
> >> [cc list trimmed]
> >>
> >> on 21/11/2011 18:32 John Baldwin said the following:
> >>> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
> on 17/11/2011 23:38 John Baldwin said the following:
> > On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
> >> Hmmm, you could also make critical_exit() not perform deferred
> >> preemptions
> >> if SCHEDULER_STOPPED? That would fix the recursion and still let the
> >> preemption "work" when resuming from the debugger?
> >>
> >>
> >> Just to clarify, probably you are actually suggesting to not perform
> >> deferred
> >> preemptions if kdb_active == TRUE. Because that's where we get the
> >> recursion (via
> >> kdb_switch).
> >>
> >> I think that if we get into the mi_switch in a state where !kdb_active &&
> >> SCHEDULER_STOPPED(), then we probably should just - I don't know - panic
> >> again?
> >>
> >> [the following is preserved for context]
> >
> > Hmmm. I'd be tempted to just ignore pending preemptions anytime
> > SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being
> > in the debugger (e.g. panic), I'd rather make a best effort at getting a
> > dump
> > than panic again.
>
> Yep, me too. It's just that I assumed that ending up at mi_switch in the
> panic
> thread/context meant that something had gone very wrong already. But I am not
> sure if this was a valid assumption.
>
> Returning to critical_exit, what do you think about the following patch?
> I guess that it could be committed independently of / before the
> SCHEDULER_STOPPED thing.
>
> commit ee3d1a04985e86911a68d854439ae8c5429b7bd5
> Author: Andriy Gapon
> Date: Thu Dec 1 18:53:36 2011 +0200
>
> critical_exit: ignore td_owepreempt if kdb_active
>
> calling mi_switch in such a context result in a recursion via
> kdb_switch
>
> diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c
> index 93cbf7b..885dc22 100644
> --- a/sys/kern/kern_switch.c
> +++ b/sys/kern/kern_switch.c
> @@ -200,7 +200,7 @@ critical_exit(void)
>
> if (td->td_critnest == 1) {
> td->td_critnest = 0;
> - if (td->td_owepreempt) {
> + if (td->td_owepreempt && !kdb_active) {
> td->td_critnest = 1;
> thread_lock(td);
> td->td_critnest--;
I think this is fine, but I'd probably change this to SCHEDULER_STOPPED()
in the SCHEDULER_STOPPED() patch.
> Would it make sense wrap kdb_active check with __predict_false?
I don't think so.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
on 01/12/2011 20:49 John Baldwin said the following:
> On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote:
>>
>> [cc list trimmed]
>>
>> on 21/11/2011 18:32 John Baldwin said the following:
>>> On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote:
on 17/11/2011 23:38 John Baldwin said the following:
> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote:
>> Hmmm, you could also make critical_exit() not perform deferred
>> preemptions
>> if SCHEDULER_STOPPED? That would fix the recursion and still let the
>> preemption "work" when resuming from the debugger?
>>
>>
>> Just to clarify, probably you are actually suggesting to not perform deferred
>> preemptions if kdb_active == TRUE. Because that's where we get the
>> recursion (via
>> kdb_switch).
>>
>> I think that if we get into the mi_switch in a state where !kdb_active &&
>> SCHEDULER_STOPPED(), then we probably should just - I don't know - panic
>> again?
>>
>> [the following is preserved for context]
>
> Hmmm. I'd be tempted to just ignore pending preemptions anytime
> SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being
> in the debugger (e.g. panic), I'd rather make a best effort at getting a dump
> than panic again.
Yep, me too. It's just that I assumed that ending up at mi_switch in the panic
thread/context meant that something had gone very wrong already. But I am not
sure if this was a valid assumption.
Returning to critical_exit, what do you think about the following patch?
I guess that it could be committed independently of / before the
SCHEDULER_STOPPED thing.
commit ee3d1a04985e86911a68d854439ae8c5429b7bd5
Author: Andriy Gapon
Date: Thu Dec 1 18:53:36 2011 +0200
critical_exit: ignore td_owepreempt if kdb_active
calling mi_switch in such a context result in a recursion via
kdb_switch
diff --git a/sys/kern/kern_switch.c b/sys/kern/kern_switch.c
index 93cbf7b..885dc22 100644
--- a/sys/kern/kern_switch.c
+++ b/sys/kern/kern_switch.c
@@ -200,7 +200,7 @@ critical_exit(void)
if (td->td_critnest == 1) {
td->td_critnest = 0;
- if (td->td_owepreempt) {
+ if (td->td_owepreempt && !kdb_active) {
td->td_critnest = 1;
thread_lock(td);
td->td_critnest--;
Would it make sense wrap kdb_active check with __predict_false?
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r227487 breaks C++ programs that use __isthreaded
Hello One example is Google's tcmalloc [1], is this behaviour intended? [1] http://code.google.com/p/google-perftools/source/browse/trunk/src/maybe_threads.cc Regards, George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stupid cp(1) behaviour
On Thu, Dec 1, 2011 at 3:28 AM, Alexander Best wrote: > implement a new -N switch or so which isn't based on a file's existance, but a > file's checksum. You can always use net/rsync, which does by default compare checksums. -- Matt Mullins ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ahci in FreeBSD 9
Hi everyone, >From my understanding as of 20110424 revision device ahci has been integrated into kernel: It is possible to load devices ahci, ata, siis and mvs as modules, but option ATA_CAM should remain in kernel configuration to make ata module work as CAM driver supporting legacy ATA controllers. Device ata still can be used in modular fashion ... No kernel config options or code have been removed, so if a problem arises, please report it and optionally revert to the old ATA stack. In order to do it you can remove from the kernel config: optionsATA_CAM device ahci Does this mean that loading ahci in loader.conf is useless ? Thanks -- George Kontostanos Aicom telecoms ltd http://www.barebsd.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Malformed conditional (${MK_CTF} != "no") [solved]
On Thu, 2011-12-01 at 10:56 -0800, Garrett Cooper wrote: > to workaround this issue -- or just install all of the include > Makefiles there, via (cd ~/head/share/mk; make -m `pwd` install) Thanks amigo. sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Malformed conditional (${MK_CTF} != "no")
On Dec 1, 2011, at 10:46 AM, Sean Bruno wrote:
> I've noted that this morning's svn update seems to be breaking pretty
> badly. Is this related to the DTRACE conf changes?
>
> [seanb@sbpi386 ~/head/sys/modules/firewire]$ make
> ===> firewire (all)
> "/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk",
> line 204: Malformed conditional (${MK_CTF} != "no")
> "/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk",
> line 206: if-less endif
> make: fatal errors encountered -- cannot continue
> *** Error code 1
>
> Stop in /usr/home/seanb/head/sys/modules/firewire.
You'll need to use the updated share/mk/bsd.own.mk in order to build on trunk,
which is obscured by the toolchain target IIRC. You could invoke make like so
in the meantime:
make -m $HOME/head/share/mk all
to workaround this issue -- or just install all of the include Makefiles there,
via (cd ~/head/share/mk; make -m `pwd` install)
HTH!
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
On Thursday, December 01, 2011 11:59:10 am Andriy Gapon wrote: > > [cc list trimmed] > > on 21/11/2011 18:32 John Baldwin said the following: > > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: > >> on 17/11/2011 23:38 John Baldwin said the following: > >>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: > Hmmm, you could also make critical_exit() not perform deferred > preemptions > if SCHEDULER_STOPPED? That would fix the recursion and still let the > preemption "work" when resuming from the debugger? > > > Just to clarify, probably you are actually suggesting to not perform deferred > preemptions if kdb_active == TRUE. Because that's where we get the recursion > (via > kdb_switch). > > I think that if we get into the mi_switch in a state where !kdb_active && > SCHEDULER_STOPPED(), then we probably should just - I don't know - panic > again? > > [the following is preserved for context] Hmmm. I'd be tempted to just ignore pending preemptions anytime SCHEDULER_STOPPED() is true. If it's stopped for a reason other than being in the debugger (e.g. panic), I'd rather make a best effort at getting a dump than panic again. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Malformed conditional (${MK_CTF} != "no")
I've noted that this morning's svn update seems to be breaking pretty
badly. Is this related to the DTRACE conf changes?
[seanb@sbpi386 ~/head/sys/modules/firewire]$ make
===> firewire (all)
"/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk",
line 204: Malformed conditional (${MK_CTF} != "no")
"/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk",
line 206: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /usr/home/seanb/head/sys/modules/firewire.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lock order reversals with netmap
On Thu, Dec 01, 2011 at 05:54:44PM +0100, Luigi Rizzo wrote: > On Thu, Dec 01, 2011 at 04:44:24PM +0100, Rene Ladan wrote: > > Hi, > > > > on FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 > > (GENERIC + CAPABILITIES + netmap with head.diff and bge patches applied) > > I get these lock order reversals when running a netmap-enabled program > > (details in the attachment) with syscall (54, FreeBSD ELF64, sys_ioctl): > > Rene, > thanks for the report. > > As i mentioned earlier to Rene, the 'bge' driver > is neither complete nor tested so i am even surprised > that it does not crash right away. I'll keep his report > in mind when we will complete the support for bge. > > BTW is someone is familiar with the architecture of the 'bge' NICs > please can she/he contact me. I am unclear on why there are two > lists of rx buffers (std and jumbo) and one ring -- perhaps the > NIC first receives the frame in its fifo and then decides which > type of buffer to use to store it ? > Actually there are three rings but the additional mini ring is only available for BCM5700. Controller determines which ring(mini, standard and jumbo) would be used to receive the frame based on the frame size. For example, if jumbo frame is enabled and controller receives a pure TCP ACK, controller will use standard RX ring, mini RX ring on BCM5700, which in turn can save system resources. Controller maintains pool of TX/RX buffers in NIC's internal memory space(2 MIPS processors in NIC) and all these decision is made by firmware of the NIC with the help of driver. Broadcom provides publicly available data sheet for open source developers. See the following URL. http://www.broadcom.com/support/ethernet_nic/open_source.php Having two RX buffers are common for controllers that support header splitting. igb(4) and ti(4) have the feature but I think that feature was disabled in igb(4) due to bugs or incomplete implementation in driver. > cheers > luigi > > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory > > allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) > > locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > > > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) > > r = 0 (0xff8000768010) locked @ > > /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > > > > The application does not invoke the offending function (netmap_malloc()) > > itself. > > > > Regards, > > Ren? > > -- > > http://www.rene-ladan.nl:8080/ > > > > GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC > > (subkeys.pgp.net) > > > Dec 1 15:41:20 acer kernel: FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 > > 13:56:02 CET 2011 > > Dec 1 15:41:20 acer kernel: real memory = 4294967296 (4096 MB) > > Dec 1 15:41:20 acer kernel: avail memory = 4080091136 (3891 MB) > > Dec 1 15:41:20 acer kernel: 001.05 netmap_memory_init [1627] > > netmap_buffer_base 0xff8117eaa000 (offset 679936) > > Dec 1 15:41:20 acer kernel: 001.06 netmap_memory_init [1636] Have 129 > > MB, use 661KB for rings, 65862 buffers at 0xff8117eaa000 > > Dec 1 15:41:20 acer kernel: netmap: loaded module with 129 Mbytes > > Dec 1 15:41:20 acer kernel: bge0: > Controller, ASIC rev. 0x5784100> mem 0xf510-0xf510 irq 16 at > > device 0.0 on pci2 > > Dec 1 15:41:20 acer kernel: bge0: CHIP ID 0x05784100; ASIC REV 0x5784; > > CHIP REV 0x57841; PCI-E > > Dec 1 15:41:20 acer kernel: miibus0: on bge0 > > Dec 1 15:41:20 acer kernel: brgphy0: PHY 1 > > on miibus0 > > Dec 1 15:41:20 acer kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, > > 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, > > 1000baseT-FDX-master, auto, auto-flow > > Dec 1 15:41:20 acer kernel: bge0: Ethernet address: 00:26:2d:5e:d8:ee > > Dec 1 15:41:20 acer kernel: 001.09 netmap_attach [1243] ok for bge0 > > Dec 1 16:23:09 acer kernel: 989.882634 netmap_set_ringid [779] ringid bge0 > > set to SW RING > > Dec 1 16:23:09 acer kernel: uma_zalloc_arg: zone "64" with the following > > non-sleepable locks held: > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator > > lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ > > /usr/src/sys/dev/netmap/netmap.c:1484 > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r > > = 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > > Dec 1 16:23:09 acer kernel: KDB: stack backtrace: > > Dec 1 16:23:09 acer kernel: db_trace_self_wrapper() at > > db_trace_self_wrapper+0x2a > > Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 > > Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c > > Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 > > Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 > > Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe > > Dec 1 16:23:10 acer kernel: netmap_ma
Looking to start Testing 10-current on Vbox
I'm looking to start testing 10 on my own. I went to: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ Last update was 201107 Where do I get the Current snapshot of 10. (Or do I upgrade from 9.0-RC2)? Thanks -- Ben Adams http://www.SpryMed.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Remove debug echo
Garrett,
On Thu, Dec 1, 2011 at 2:15 PM, Garrett Cooper wrote:
> What I really want is this:
> >
> > $ cat Makefile
> > all: foo bar baz yadda
> >
> > foo bar yadda:
> >
> > baz:
> >false
> > $ gmake
> > false
> > gmake: *** [baz] Error 1
> >
> > $ make all
> > false
> > *** Error code 1
> >
> > Stop in /tmp.
> >
> > Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I
> > have to start using some serious grep'ing, and if I'm lucky I can find
> > the source of error). If I get a few spare cycles I might just
> > implement it and post a patch somewhere (the entering and leaving
> > directory feature of gmake is really nice too, but it's less
> > important.. unless you have the same target in multiple directories)..
>
> I've attached a patch that makes make do what I would like it to do;
> there are some other items that require cleanup to achieve the `argv0'
> prefixing that's available in gmake, but this is good enough for a
> meaningful traceback when things fail. Pastebin available here, just
> in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv
>
> $ cat ~/Makefile
> all:
>cd $$HOME/foo; ${MAKE} $@
> $ cat ~/foo/Makefile
> all: foo bar barf yadda
>
> foo bar yadda:
>@true
>
> baz:
>@false
>
> barf: baz
> $ $PWD/make -j4 -f ~/Makefile all
> cd $HOME/foo; /usr/src/usr.bin/make/make all
> *** [baz] Error code 1
> 1 error
> *** [all] Error code 2
> 1 error
> $
>
> If someone would please, PLEASE commit this.. I will give you beer, or
> wine, or a copy of Skyrim, or a few months subscription to WoW, or
> something else of value to you that we could negotiate :)... I'm quite
> frankly tired of having to playing guessing games fishing through logs
> trying to determine build errors on FreeBSD if and when they do occur
> with pmake, and I'm sure that a number of developers and build/release
> engineers out there are in the same boat as I am.
>
I hit the same problem regularly. The patch looks good to me as well.
Max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C) [solved]
On Wed, 2011-11-30 at 15:55 -0800, Jung-uk Kim wrote: > On Wednesday 30 November 2011 06:40 pm, Andriy Gapon wrote: > > on 01/12/2011 01:22 Sean Bruno said the following: > > > I have a Shuttle based intel box that appears to have some pretty > > > bad ACPI implementation. Is there a good way to quiesce this > > > spam? > > > > Ask on acpi@ list. > > Kidding :-) or not. > > Try hw.acpi.thermal.polling_rate=0. > > Adding the following line in /boot/loader.conf will disable > acpi_thermal(4) completely: > > debug.acpi.disabled="thermal" > > Jung-uk Kim Aye, both are my "huckleberry". Thanks! Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Remove debug echo
So, now that you've improved the default diagnostic output of make, how about the OP's original request: make -s truly silent by removing unnecessary diagnostic messages when -s is used? :) [Thought I'd bring the thread back around to it's original purpose.] -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Stop scheduler on panic
[cc list trimmed] on 21/11/2011 18:32 John Baldwin said the following: > On Friday, November 18, 2011 4:59:32 pm Andriy Gapon wrote: >> on 17/11/2011 23:38 John Baldwin said the following: >>> On Thursday, November 17, 2011 4:35:07 pm John Baldwin wrote: Hmmm, you could also make critical_exit() not perform deferred preemptions if SCHEDULER_STOPPED? That would fix the recursion and still let the preemption "work" when resuming from the debugger? Just to clarify, probably you are actually suggesting to not perform deferred preemptions if kdb_active == TRUE. Because that's where we get the recursion (via kdb_switch). I think that if we get into the mi_switch in a state where !kdb_active && SCHEDULER_STOPPED(), then we probably should just - I don't know - panic again? [the following is preserved for context] >> Yes, that's a good solution, I think. I just didn't want to touch such a >> "low >> level" code, but I guess there is no rational reason for that. >> >>> Or you could let the debugger run in a permament critical section (though >>> perhaps that breaks too many other things like debugger routines that try >>> to use locks like the 'kill' command (which is useful!)). Effectively what >>> you >>> are trying to do is having the debugger run in a critical section until the >>> debugger is exited. It would be cleanest to let it run that way explicitly >>> if possible since then you don't have to catch as many edge cases. >> >> I like this idea, but likely it would take some effort to get done. > > Yes, it would take some effort, so checking SCHEDULER_STOPPED in > critical_exit() is probably good for the short term. Would be nice to fix > it properly some day. > >> Related to this is something that I attempted to discuss before. I think >> that >> because the debugger acts on a frozen system image (the debugger is a sole >> actor >> and observer), the debugger should try to minimize its interaction with the >> debugged system. In this vein I think that the debugger should also bypass >> any >> locks just like with SCHEDULER_STOPPED. The debugger should also be careful >> to >> note a state of any subsystems that it uses (e.g. the keyboard) and return >> them >> to the initial state if it had to be changed. But that's a bit different >> story. >> And I really get beyond my knowledge zone when I try to think about things >> like >> handling 'call func_' in the debugger where func_ may want to acquire >> some locks or noticeably change some state within a system. > > I think to some extent, I think if a user calls a function from the debugger > they better know what they are doing. However, I think it can also be useful > to have the debugger modify the system in some cases if it can safely do so > (e.g. the 'kill' command from DDB can be very useful, and IIRC, it is careful > to only use try locks and just fail if it can't acquire the needed locks). > >> But to continue about the locks... I have this idea to re-implement >> SCHEDULER_STOPPED as some more general check that could be abstractly >> denoted as >> LOCKING_POLICY_CHECK(context). Where the context could be defined by flags >> like >> normal, in-panic, in-debugger, etc. And the locking policies could be: >> normal, >> bypass, warn, panic, etc. >> >> However, I am not sure if this could be useful (and doable properly) in >> practice. I am just concerned with the interaction between the debugger and >> the >> locks. It still seems to me inconsistent that we are going with >> SCHEDULER_STOPPED for panic, but we are continuing to use "if (!kdb_active)" >> around some locks that could be problematic under kdb (e.g. in USB). In my >> opinion the amount of code shared between normal context and kdb context is >> about the same as amount of code shared between normal context and panic >> context. But I haven't really quantified those. > > I think you need to keep the 'kill' case in mind. In that case you don't want > to ignore locks, but the code is carefully written to use try locks instead > (or > should be). > -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lock order reversals with netmap
On Thu, Dec 01, 2011 at 04:44:24PM +0100, Rene Ladan wrote: > Hi, > > on FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 > (GENERIC + CAPABILITIES + netmap with head.diff and bge patches applied) > I get these lock order reversals when running a netmap-enabled program > (details in the attachment) with syscall (54, FreeBSD ELF64, sys_ioctl): Rene, thanks for the report. As i mentioned earlier to Rene, the 'bge' driver is neither complete nor tested so i am even surprised that it does not crash right away. I'll keep his report in mind when we will complete the support for bge. BTW is someone is familiar with the architecture of the 'bge' NICs please can she/he contact me. I am unclear on why there are two lists of rx buffers (std and jumbo) and one ring -- perhaps the NIC first receives the frame in its fifo and then decides which type of buffer to use to store it ? cheers luigi > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory > allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) > locked @ /usr/src/sys/dev/netmap/netmap.c:1484 > > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) > r = 0 (0xff8000768010) locked @ > /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > > The application does not invoke the offending function (netmap_malloc()) > itself. > > Regards, > Ren? > -- > http://www.rene-ladan.nl:8080/ > > GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC > (subkeys.pgp.net) > Dec 1 15:41:20 acer kernel: FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 > 13:56:02 CET 2011 > Dec 1 15:41:20 acer kernel: real memory = 4294967296 (4096 MB) > Dec 1 15:41:20 acer kernel: avail memory = 4080091136 (3891 MB) > Dec 1 15:41:20 acer kernel: 001.05 netmap_memory_init [1627] > netmap_buffer_base 0xff8117eaa000 (offset 679936) > Dec 1 15:41:20 acer kernel: 001.06 netmap_memory_init [1636] Have 129 > MB, use 661KB for rings, 65862 buffers at 0xff8117eaa000 > Dec 1 15:41:20 acer kernel: netmap: loaded module with 129 Mbytes > Dec 1 15:41:20 acer kernel: bge0: Controller, ASIC rev. 0x5784100> mem 0xf510-0xf510 irq 16 at > device 0.0 on pci2 > Dec 1 15:41:20 acer kernel: bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP > REV 0x57841; PCI-E > Dec 1 15:41:20 acer kernel: miibus0: on bge0 > Dec 1 15:41:20 acer kernel: brgphy0: PHY 1 on > miibus0 > Dec 1 15:41:20 acer kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, > 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, > 1000baseT-FDX-master, auto, auto-flow > Dec 1 15:41:20 acer kernel: bge0: Ethernet address: 00:26:2d:5e:d8:ee > Dec 1 15:41:20 acer kernel: 001.09 netmap_attach [1243] ok for bge0 > Dec 1 16:23:09 acer kernel: 989.882634 netmap_set_ringid [779] ringid bge0 > set to SW RING > Dec 1 16:23:09 acer kernel: uma_zalloc_arg: zone "64" with the following > non-sleepable locks held: > Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator > lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ > /usr/src/sys/dev/netmap/netmap.c:1484 > Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r = > 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > Dec 1 16:23:09 acer kernel: KDB: stack backtrace: > Dec 1 16:23:09 acer kernel: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2a > Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 > Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c > Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 > Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 > Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe > Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 > Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x5bd > Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a > Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd > Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd > Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac > Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 > Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip > = 0x8022aef0c, rsp = 0x7fffd4b8, rbp = 0x802bfb100 --- > Dec 1 16:23:10 acer kernel: uma_zalloc_arg: zone "64" with the following > non-sleepable locks held: > Dec 1 16:23:10 acer kernel: exclusive sleep mutex netmap memory allocator > lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ > /usr/src/sys/dev/netmap/netmap.c:1484 > Dec 1 16:23:10 acer kernel: exclusive sleep mutex bge0 (network driver) r = > 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 > Dec 1 16:23:10 acer kernel: KDB: stack backtrace: > Dec 1 16:23:10 acer kernel: db_trace_self_wrapper() at > db_trace_self_wrapper+0x2a > Dec 1 16:23:10
Re: man ugen error
On Thursday 01 December 2011 11:44:13 Thomas Mueller wrote: > > On Wednesday 30 November 2011 11:24:39 Thomas Mueller wrote: > > > According to ugen man page, ugen can be compiled into the kernel with > > > device ugen > > > in config file. > > > > > > I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 > > > to RC2, but the kernel build stopped quickly with the message that > > > ugen was not valid. After removing that line from kernel config, > > > "make kernel" was successful. > > > > > > I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC > > > files. > > > > > > I hope this man page error can be fixed in time for FreeBSD > > > 9.0-RELEASE. > > > > FYI: "device ugen" is now part of "device usb" > > > > Could you send me a manpage diff? > > --HPS > > What version of FreeBSD do you run? Do you not have a ugen manpage? Can > you run "man ugen"? > > I have the manpages for ugen, and "man usb", also "man 4 usb", but no diff > as such. > > I guess ugen manpage failed to reflect becoming part of usb. There is: share/man/man4/ugen.4 in FreeBSD 10-current. It should be removed and added to old files. Could you make a patch for that? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On Thursday 01 December 2011 03:37 am, Bernhard Froehlich wrote: > On 01.12.2011 00:07, Jung-uk Kim wrote: > > On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: > >> on 26/11/2011 18:33 Gleb Kurtsou said the following: > >> > Using new vm_page_alloc_contig() may be a better option here. > >> > Can't help with patch, stuck with pre Nov 15 CURRENT myself. > >> > >> on 27/11/2011 19:09 Alan Cox said the following: > >> > vm_page_alloc_contig() should be used instead. > >> > >> My take on the patch: > >> http://people.freebsd.org/~avg/vbox-10.patch > >> This is for head only, no check for FreeBSD version. > > > > Actually, I did the same thing last night: > > > > > > http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-free > >bsd-memobj-r0drv-freebsd.c > > > > This is a drop-in replacement for the patch. The only practical > > difference I see from yours is I used VM_ALLOC_INTERRUPT instead > > of VM_ALLOC_NORMAL. I believe this function may be used in > > interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without > > problem. > > Thanks a lot for both patches! Could you please as usual reply and > tell me if it is okay to send this patch upstream under MIT > license? Yes, as usual. :-) > Once there is some positive feedback I will commit both patches to > the ports tree. Thanks! Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
lock order reversals with netmap
Hi, on FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 (GENERIC + CAPABILITIES + netmap with head.diff and bge patches applied) I get these lock order reversals when running a netmap-enabled program (details in the attachment) with syscall (54, FreeBSD ELF64, sys_ioctl): Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 The application does not invoke the offending function (netmap_malloc()) itself. Regards, René -- http://www.rene-ladan.nl:8080/ GPG fingerprint = ADBC ECCD EB5F A6B4 549F 600D 8C9E 647A E564 2BFC (subkeys.pgp.net) Dec 1 15:41:20 acer kernel: FreeBSD 10.0-CURRENT #7 r228176M: Thu Dec 1 13:56:02 CET 2011 Dec 1 15:41:20 acer kernel: real memory = 4294967296 (4096 MB) Dec 1 15:41:20 acer kernel: avail memory = 4080091136 (3891 MB) Dec 1 15:41:20 acer kernel: 001.05 netmap_memory_init [1627] netmap_buffer_base 0xff8117eaa000 (offset 679936) Dec 1 15:41:20 acer kernel: 001.06 netmap_memory_init [1636] Have 129 MB, use 661KB for rings, 65862 buffers at 0xff8117eaa000 Dec 1 15:41:20 acer kernel: netmap: loaded module with 129 Mbytes Dec 1 15:41:20 acer kernel: bge0: mem 0xf510-0xf510 irq 16 at device 0.0 on pci2 Dec 1 15:41:20 acer kernel: bge0: CHIP ID 0x05784100; ASIC REV 0x5784; CHIP REV 0x57841; PCI-E Dec 1 15:41:20 acer kernel: miibus0: on bge0 Dec 1 15:41:20 acer kernel: brgphy0: PHY 1 on miibus0 Dec 1 15:41:20 acer kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Dec 1 15:41:20 acer kernel: bge0: Ethernet address: 00:26:2d:5e:d8:ee Dec 1 15:41:20 acer kernel: 001.09 netmap_attach [1243] ok for bge0 Dec 1 16:23:09 acer kernel: 989.882634 netmap_set_ringid [779] ringid bge0 set to SW RING Dec 1 16:23:09 acer kernel: uma_zalloc_arg: zone "64" with the following non-sleepable locks held: Dec 1 16:23:09 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:09 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 Dec 1 16:23:09 acer kernel: KDB: stack backtrace: Dec 1 16:23:09 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x5bd Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 1 16:23:10 acer kernel: --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8022aef0c, rsp = 0x7fffd4b8, rbp = 0x802bfb100 --- Dec 1 16:23:10 acer kernel: uma_zalloc_arg: zone "64" with the following non-sleepable locks held: Dec 1 16:23:10 acer kernel: exclusive sleep mutex netmap memory allocator lock (netmap memory allocator lock) r = 0 (0xfe00027d1880) locked @ /usr/src/sys/dev/netmap/netmap.c:1484 Dec 1 16:23:10 acer kernel: exclusive sleep mutex bge0 (network driver) r = 0 (0xff8000768010) locked @ /usr/src/sys/dev/netmap/if_bge_netmap.h:60 Dec 1 16:23:10 acer kernel: KDB: stack backtrace: Dec 1 16:23:10 acer kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Dec 1 16:23:10 acer kernel: kdb_backtrace() at kdb_backtrace+0x37 Dec 1 16:23:10 acer kernel: _witness_debugger() at _witness_debugger+0x2c Dec 1 16:23:10 acer kernel: witness_warn() at witness_warn+0x2c2 Dec 1 16:23:10 acer kernel: uma_zalloc_arg() at uma_zalloc_arg+0x335 Dec 1 16:23:10 acer kernel: malloc() at malloc+0xbe Dec 1 16:23:10 acer kernel: netmap_malloc() at netmap_malloc+0x86 Dec 1 16:23:10 acer kernel: netmap_ioctl() at netmap_ioctl+0x817 Dec 1 16:23:10 acer kernel: devfs_ioctl_f() at devfs_ioctl_f+0x7a Dec 1 16:23:10 acer kernel: kern_ioctl() at kern_ioctl+0xcd Dec 1 16:23:10 acer kernel: sys_ioctl() at sys_ioctl+0xfd Dec 1 16:23:10 acer kernel: amd64_syscall() at amd64_syscall+0x3ac Dec 1 16:23:10 acer kernel: Xfast_syscall() at Xfast_syscall+0xf7 Dec 1 16:23:10 acer kernel: --- syscall (5
Re: Remove debug echo
On Thursday, December 01, 2011 2:15:11 am Garrett Cooper wrote:
> On Wed, Nov 30, 2011 at 5:59 PM, Garrett Cooper wrote:
> > On Wed, Nov 30, 2011 at 5:43 PM, Alexander Best
wrote:
> >> On Wed Nov 30 11, Garrett Cooper wrote:
> >>> On Wed, Nov 30, 2011 at 4:25 PM, Alexander Best
wrote:
> >>> > On Tue Nov 29 11, Warner Losh wrote:
> >>> >> kill it.
> >>> >>
> >>> >> Warner
> >>> >> On Nov 29, 2011, at 2:07 PM, John Baldwin wrote:
> >>> >>
> >>> >> > Any objections to this? It removes a weird line during 'make -s
buildworld'
> >>> >> > output and I think it was debugging accidentally left in in 213077
by Warner:
> >>> >> >
> >>> >> > Index: newvers.sh
> >>> >> > ===
> >>> >> > --- newvers.sh (revision 228074)
> >>> >> > +++ newvers.sh (working copy)
> >>> >> > @@ -99,7 +99,6 @@ for dir in /bin /usr/bin /usr/local/bin; do
> >>> >> > done
> >>> >> >
> >>> >> > if [ -n "$svnversion" ] ; then
> >>> >> > - echo "$svnversion"
> >>> >> > svn=`cd ${SYSDIR} && $svnversion`
> >>> >> > case "$svn" in
> >>> >> > [0-9]*) svn=" r${svn}" ;;
> >>> >
> >>> > also...
> >>> >
> >>> > when running buildkernel via 'make -s', do we really need all those
module
> >>> > printfs? i see messages for "cleandir", "obj", "depend" and "all". i
think for
> >>> > 'make -s', that's pure overkill!
> >>> >
> >>> > for a GENERIC kernel, 'make' enters ~ 670 module dirs. take that times
4 and
> >>> > you'll get 2680 lines of output. not really *silent*, is it? ;)
> >>>
> >>> pmake sucks as far as diagnostic output is concerned when compared
> >>> with gmake. I'd rather not have to fish through with -j1 (if I'm lucky
> >>> and it's not a race) to determine what directory created the "Error
> >>> Code" output. With the printouts discussed here, at least you have a
> >>> chance at determining what the issue was.
> >>> Maybe it's just me, but I like noisy builds -- otherwise the
> >>> amount of time I have to spend root-causing the issue becomes
> >>> expensive.
> >>
> >> ehmmm...a noisy silent flag? i totally agree, if we're talking about
'make' in
> >> its default mode, but what's the point of a silent flag, if it produces >
2500
> >> lines of output? nobody uses the -s flag for diagnostics. its purpose is
to
> >> build a kernel without producing a lot of output and also not fiddling
with
> >> stdout/stderr to achieve that goal.
> >
> > What I really want is this:
> >
> > $ cat Makefile
> > all: foo bar baz yadda
> >
> > foo bar yadda:
> >
> > baz:
> >false
> > $ gmake
> > false
> > gmake: *** [baz] Error 1
> >
> > $ make all
> > false
> > *** Error code 1
> >
> > Stop in /tmp.
> >
> > Otherwise diagnosing issues becomes a PITA with -j > 1 (with pmake I
> > have to start using some serious grep'ing, and if I'm lucky I can find
> > the source of error). If I get a few spare cycles I might just
> > implement it and post a patch somewhere (the entering and leaving
> > directory feature of gmake is really nice too, but it's less
> > important.. unless you have the same target in multiple directories)..
>
> I've attached a patch that makes make do what I would like it to do;
> there are some other items that require cleanup to achieve the `argv0'
> prefixing that's available in gmake, but this is good enough for a
> meaningful traceback when things fail. Pastebin available here, just
> in case the mailing list eats my patch: http://pastebin.com/dFqcDRfv
I think this is useful, perhaps send it to harti@ or jilles@ for review?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [patch] turning devctl into a "multiple openable" device
On Wednesday, November 30, 2011 11:41:25 am Hans Petter Selasky wrote: > On Wednesday 30 November 2011 13:43:20 Baptiste Daroussin wrote: > > Hi all, > > > > With the help of cognet, I wrote a patch to turn devctl into a multiple > > openable device, that mean that it will allow to open /dev/devctl in > > multiple programs, for example hald and everythings that want to receive > > notification from the device won't need to depend on haveing devd running. > > > > here is the patch: > > http://people.freebsd.org/~bapt/devctl_multi_open.diff > > > > regards, > > bapt > > Comment: > > Is the track-close flag set for the devfs sw? Not, it uses the far-superior devfs_set_cdevpriv(). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
On 1 December 2011 10:44, Max Khon wrote: > Are you sure you mean profile support and not CTF data? Hi Max, I mean profile support. Havent tested on 9.0, but definitely the case with prior versions. Will try & repeat the process & report back if this is not a common occurrence which has been reported. Sevan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
stupid cp(1) behaviour
is there a chance to change cp's behaviour in connection with the -R switch, so that it stops after the first error? i just ran into the following situation: 1) cp -ai bla /mnt/umass 2) i got a lot of warnings that /mnt/umass was full 3) cp -an bla /mnt/umass 4) ...that didn't work, since cp created 0 byte files for all files it couldn't copy in 1. 5) what i had to do is 'find /mnt/umass/bla -type f - size 0 -delete' and then try 3 again of course, if cp would have bailed out after the first error, there still would be one file with < actual file size. maybe the available filesize could be checked before crating the file, or another possibility: implement a new -N switch or so which isn't based on a file's existance, but a file's checksum. cheers. alex ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: man ugen error
> On Wednesday 30 November 2011 11:24:39 Thomas Mueller wrote: > > According to ugen man page, ugen can be compiled into the kernel with > > device ugen > > in config file. > > I tried that in the kernel config when upgrading from FreeBSD 9.0-RC1 to > > RC2, but the kernel build stopped quickly with the message that ugen was > > not valid. After removing that line from kernel config, "make kernel" was > > successful. > > I didn't find "device ugen" anywhere in the conf/NOTES or conf/GENERIC > > files. > > I hope this man page error can be fixed in time for FreeBSD 9.0-RELEASE. > FYI: "device ugen" is now part of "device usb" > Could you send me a manpage diff? --HPS What version of FreeBSD do you run? Do you not have a ugen manpage? Can you run "man ugen"? I have the manpages for ugen, and "man usb", also "man 4 usb", but no diff as such. I guess ugen manpage failed to reflect becoming part of usb. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
pf.conf + IPV6 to IPV4 port rdr
pfctl -v -s nat rdr inet6 proto tcp from any to 2001:49f0:4004::/48 port = 9191 -> :::67.159.46.238 [ Evaluations: 512 Packets: 3 Bytes: 228 States: 1 ] [ Inserted: uid 0 pid 80940 State Creations: 2 ] I can see here that after i tried on another host to telnet to 2001:49f0:4004::2 9191 , that a state was in fact created for the rdr, but it doesn't appear to be actually forwarding: My rule: rdr inet6 proto tcp to 2001:49f0:4004::/48 port 9191 -> :::67.159.46.238 Am I missing something here? I have checked on ipv6 forwarding and redirects set to 1, net.inet6.ip6.v6only=0 to allow the mapping... I can even telnet to :::67.159.46.238 9191 from any host yet it will not forward the 2001:49f0:4004:: addresses, and yes inet6 is allowing the port to pass, so this makes no sense to me Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_PROFILE=yes by default
Sevan, On Thu, Dec 1, 2011 at 6:56 AM, Sevan / Venture37 wrote: On 30/11/2011 16:03, Sevan / Venture37 wrote: > >> system breaks if you try to add dtrace support to a system built with >> profile support. >> > > sorry, I meant *without* profile support. Are you sure you mean profile support and not CTF data? Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On 1 December 2011 13:17, Kostik Belousov wrote: > On Thu, Dec 01, 2011 at 12:12:18PM +0300, Sergey Kandaurov wrote: >> On 1 December 2011 10:20, Milan Obuch wrote: >> > On Tue, 29 Nov 2011 19:22:39 +0300 >> > Sergey Kandaurov wrote: >> > >> >> On 29 November 2011 20:16, Maxim Khitrov wrote: >> >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov >> >> > wrote: >> >> >> On 26 November 2011 11:44, Milan Obuch >> >> >> wrote: >> >> >>> Hi, >> >> >>> >> >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source >> >> >>> updated via csup. In both example files there is line specifying >> >> >>> what to csup >> >> >>> >> >> >>> *default release=cvs tag=RELENG_8 >> >> >>> >> >> >>> which is incorrect, I think. It is convenient for me to issue just >> >> >>> >> >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >> >>> >> >> >>> to update full sources without need to create any cvsup config >> >> >>> file, however in system installed from 9.0 snapshot (maybe two >> >> >>> weeks old) this file points to version 8 files, so I need to >> >> >>> correct it for 9.0-PRERELEASE to not accidentally download older >> >> >>> version sources. >> >> >>> >> >> >>> The same is also true after upgrade from source - make >> >> >>> installworld install example files pointing to older version... >> >> >>> >> >> >>> Is it something I do not know about or is it an oversight? I >> >> >>> think this line should already be changed to new tag... >> >> >>> >> >> >>> *default release=cvs tag=RELENG_9 >> >> >> >> >> >> Hi. >> >> >> >> >> >> Fixed. Thanks for your report. >> >> >> Now cvs tag points to RELENG_9 in 9.x sources. >> >> > >> >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm >> >> > using csup with "tag=RELENG_9_0" and standard-supfile still points >> >> > to HEAD. >> >> >> >> Yep, sure. >> >> I just sent a request to the Release Engineering Team. >> >> >> > >> > It works for me now as expected, thanks. >> > >> > Anyway, there is a question what the difference between stable-supfile >> > and standard-supfile should be. I looked in my local csupped sources, >> > they are the same in 6-STABLE (OK, some history here), 7-STABLE, >> > 8-STABLE and 9-STABLE. Are they expected to be used differently? >> >> In STABLE branches standard-supfile and stable-supfile are used to have >> the same cvs tag. FYI, compare how it is done in RELEASE branches. >> >> > And, second one - what about CURRENT? In stable-supfile I see >> > tag=RELENG_9 which is not quite clear, but just for some pedantry... I >> > use standard-supfile for CURRENT, so this is not an issue for me either. >> >> To my knowledge, in CURRENT a standard-supfile's cvs tag should be >> read as "the latest (i.e. the most recently created) stable branch". > Could the supfiles be generated from some value in newvers.sh ? I have no idea how it could be done gracefully, sorry. But I like how it is done in www/. Here are several defined entities used elsewhere in doc&www. and so on. -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On Thu, Dec 01, 2011 at 12:12:18PM +0300, Sergey Kandaurov wrote: > On 1 December 2011 10:20, Milan Obuch wrote: > > On Tue, 29 Nov 2011 19:22:39 +0300 > > Sergey Kandaurov wrote: > > > >> On 29 November 2011 20:16, Maxim Khitrov wrote: > >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov > >> > wrote: > >> >> On 26 November 2011 11:44, Milan Obuch > >> >> wrote: > >> >>> Hi, > >> >>> > >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source > >> >>> updated via csup. In both example files there is line specifying > >> >>> what to csup > >> >>> > >> >>> *default release=cvs tag=RELENG_8 > >> >>> > >> >>> which is incorrect, I think. It is convenient for me to issue just > >> >>> > >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile > >> >>> > >> >>> to update full sources without need to create any cvsup config > >> >>> file, however in system installed from 9.0 snapshot (maybe two > >> >>> weeks old) this file points to version 8 files, so I need to > >> >>> correct it for 9.0-PRERELEASE to not accidentally download older > >> >>> version sources. > >> >>> > >> >>> The same is also true after upgrade from source - make > >> >>> installworld install example files pointing to older version... > >> >>> > >> >>> Is it something I do not know about or is it an oversight? I > >> >>> think this line should already be changed to new tag... > >> >>> > >> >>> *default release=cvs tag=RELENG_9 > >> >> > >> >> Hi. > >> >> > >> >> Fixed. Thanks for your report. > >> >> Now cvs tag points to RELENG_9 in 9.x sources. > >> > > >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm > >> > using csup with "tag=RELENG_9_0" and standard-supfile still points > >> > to HEAD. > >> > >> Yep, sure. > >> I just sent a request to the Release Engineering Team. > >> > > > > It works for me now as expected, thanks. > > > > Anyway, there is a question what the difference between stable-supfile > > and standard-supfile should be. I looked in my local csupped sources, > > they are the same in 6-STABLE (OK, some history here), 7-STABLE, > > 8-STABLE and 9-STABLE. Are they expected to be used differently? > > In STABLE branches standard-supfile and stable-supfile are used to have > the same cvs tag. FYI, compare how it is done in RELEASE branches. > > > And, second one - what about CURRENT? In stable-supfile I see > > tag=RELENG_9 which is not quite clear, but just for some pedantry... I > > use standard-supfile for CURRENT, so this is not an issue for me either. > > To my knowledge, in CURRENT a standard-supfile's cvs tag should be > read as "the latest (i.e. the most recently created) stable branch". Could the supfiles be generated from some value in newvers.sh ? pgpWdpj5GwCx0.pgp Description: PGP signature
Re: Incorrect tag= in /usr/src/share/examples/cvsup/sta(ble|ndard) in 9.0-PRERELEASE?
On 1 December 2011 10:20, Milan Obuch wrote: > On Tue, 29 Nov 2011 19:22:39 +0300 > Sergey Kandaurov wrote: > >> On 29 November 2011 20:16, Maxim Khitrov wrote: >> > On Tue, Nov 29, 2011 at 10:30 AM, Sergey Kandaurov >> > wrote: >> >> On 26 November 2011 11:44, Milan Obuch >> >> wrote: >> >>> Hi, >> >>> >> >>> I am playing a bit with 9.0-PRERELEASE compiling it from source >> >>> updated via csup. In both example files there is line specifying >> >>> what to csup >> >>> >> >>> *default release=cvs tag=RELENG_8 >> >>> >> >>> which is incorrect, I think. It is convenient for me to issue just >> >>> >> >>> csup -h cvsup.freebsd.sk /usr/share/examples/cvsup/stable-supfile >> >>> >> >>> to update full sources without need to create any cvsup config >> >>> file, however in system installed from 9.0 snapshot (maybe two >> >>> weeks old) this file points to version 8 files, so I need to >> >>> correct it for 9.0-PRERELEASE to not accidentally download older >> >>> version sources. >> >>> >> >>> The same is also true after upgrade from source - make >> >>> installworld install example files pointing to older version... >> >>> >> >>> Is it something I do not know about or is it an oversight? I >> >>> think this line should already be changed to new tag... >> >>> >> >>> *default release=cvs tag=RELENG_9 >> >> >> >> Hi. >> >> >> >> Fixed. Thanks for your report. >> >> Now cvs tag points to RELENG_9 in 9.x sources. >> > >> > Should standard-supfile also be updated to point to RELENG_9_0? I'm >> > using csup with "tag=RELENG_9_0" and standard-supfile still points >> > to HEAD. >> >> Yep, sure. >> I just sent a request to the Release Engineering Team. >> > > It works for me now as expected, thanks. > > Anyway, there is a question what the difference between stable-supfile > and standard-supfile should be. I looked in my local csupped sources, > they are the same in 6-STABLE (OK, some history here), 7-STABLE, > 8-STABLE and 9-STABLE. Are they expected to be used differently? In STABLE branches standard-supfile and stable-supfile are used to have the same cvs tag. FYI, compare how it is done in RELEASE branches. > And, second one - what about CURRENT? In stable-supfile I see > tag=RELENG_9 which is not quite clear, but just for some pedantry... I > use standard-supfile for CURRENT, so this is not an issue for me either. To my knowledge, in CURRENT a standard-supfile's cvs tag should be read as "the latest (i.e. the most recently created) stable branch". -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 01.12.2011 00:07, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: > Using new vm_page_alloc_contig() may be a better option here. > Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: > vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. Thanks a lot for both patches! Could you please as usual reply and tell me if it is okay to send this patch upstream under MIT license? Once there is some positive feedback I will commit both patches to the ports tree. -- Bernhard Froehlich http://www.bluelife.at/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freeze with 10.0 and VirtualBox {4.1.4|4.1.6|4.1.51r38464}
On 01/12/2011 00:35, Andriy Gapon wrote: on 01/12/2011 01:27 Jung-uk Kim said the following: On Wednesday 30 November 2011 06:07 pm, Jung-uk Kim wrote: On Wednesday 30 November 2011 05:32 pm, Andriy Gapon wrote: on 26/11/2011 18:33 Gleb Kurtsou said the following: Using new vm_page_alloc_contig() may be a better option here. Can't help with patch, stuck with pre Nov 15 CURRENT myself. on 27/11/2011 19:09 Alan Cox said the following: vm_page_alloc_contig() should be used instead. My take on the patch: http://people.freebsd.org/~avg/vbox-10.patch This is for head only, no check for FreeBSD version. Actually, I did the same thing last night: http://people.freebsd.org/~jkim/patch-src-VBox-Runtime-r0drv-freebs d-memobj-r0drv-freebsd.c This is a drop-in replacement for the patch. The only practical difference I see from yours is I used VM_ALLOC_INTERRUPT instead of VM_ALLOC_NORMAL. I believe this function may be used in interrupt context. FYI, I tried FreeBSD 9 and Fedora 10 without problem. BTW, I needed another patch to build virtual-ose-kmod on head: http://people.freebsd.org/~jkim/patch-src-VBox-HostDrivers-Support-freebsd-SUPDrv-freebsd.c FYI... Yep, me too, obviously :-) Thank you for the complete vm_page_alloc_contig patch! Thanks for the patch. I'll give it a try. OTOH yesterday I was trying to use vm_page_alloc_contig and trying to understand the allocation classes. I was able to panic the system or in the best case VBoxHeadless was getting a sig11. I was planning to ask the mailing list about them, because even I read vm-design article in the doc section there are things I don't yet understand: First question is, if you set NULL for the vm_object_t (and then VM_ALLOC_NOOBJ must be given or the kernel will panic with INVARIANTS set) how this memory is assigned to the VirtualBox process logical space? Second set of related questions are: why should the pages be wired? and why should the VM_ALLOC_INTERRUPT alloc class be given? Third question is: I see in the patch that rtR0MemObjFreeBSDPhysPageInit is not called if the veersion is less that 100, is this because vm_phys_alloc_contig doesn't set the flags on the pages and vm_page_alloc_contig does? Thanks, Gus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
