Re: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 07:32, Warner Losh wrote:
On May 8, 2014, at 10:12 PM, Sulev-Madis Silber (ketas) madis...@hot.ee
wrote:
On 2014-05-09 02:54, Warner Losh wrote:
On May 8, 2014, at 3:26 PM, Guy Yur guy...@gmail.com wrote:
Hi,
After the bsd.opts.mk / src.opts.mk split
WITHOUT_NIS in src.conf doesn't work.
It should still work… At least that’s the intention...
src.conf is included in src.opts.mk after bsd.own.mk
which includes bsd.opts.mk.
Yea, that’s a problem… It should be included after.
Should bsd.opts.mk options overrides now be set in
make.conf instead of src.conf?
That’s a good workaround until I get that fix tested and committed. Or you
could include src.conf in make.conf at the end. Either will have the same
effect.
Here’s the fix I’m testing, if you’d like to test that instead...
diff -r d69444b828c1 share/mk/src.opts.mk
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -30,17 +30,15 @@
.if !target(__src.opts.mk__)
__src.opts.mk__:
-# Compat -- needed still?
-.include bsd.own.mk
-
-# Allow user to configure things, but in the future this will move
-# elsehwere...
-
+# Allow user to configure things that only effect src tree builds.
SRCCONF?= /etc/src.conf
.if exists(${SRCCONF}) || ${SRCCONF} != /etc/src.conf
.include ${SRCCONF}
.endif
+# Must be included after src.conf
+.include bsd.own.mk
+
#
# Define MK_* variables (which are either yes or no) for users
# to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
Yea, sorry about missing this subtle issue in the split. There was another
report of something similar that I hadn’t tracked down, but your report
pointed me to where I needed to go.
Warner
Sorry, that didn't exactly help. I don't fully get what went so wrong there?
Now I got this during install:
---
=== gnu/lib/libregex/doc (install)
install-info: not found
*** Error code 127
---
It was total WTF error but just in case I tried putting .include
../src.conf back, and it worked!
I use __MAKE_CONF, and inside that file I have SRCCONF.
To be clear, you define SRCCONF in /etc/make.conf (or the file defined by
__MAKE_CONF). The file defined by SRCCONF has WITHOUT_NIS=t defined, but
that’s not effective, even with my change. However, if you add an include to
the file defined by __MAKE_CONF, then it is effective… Is that what you are
telling me?
9.2, BTW... unsure if it matters here?
I’m doing my testing on 10-stable… I’ll have to try on my 9.x system… But it
is a lot slower than my 10.x system...
Warner
Yes, that's exactly what I mean. It seems to partially work now. I
actually have lot of WITHOUT_*'s. That install error is really weird,
never seen it before. All I know is that before all those changes,
everything worked well. And if I .include file, old behavior (everything
works as expected) is back.
___
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: ports broken in current
On Thu, 8 May 2014 09:04-0700, Warner Losh wrote: On May 7, 2014, at 5:41 PM, Shane Ambler free...@shaneware.biz wrote: I have just updated my 11-CURRENT tinderbox machine and found an issue that breaks ports building. make: /usr/share/mk/bsd.port.mk line 15: Could not find bsd.own.mk Install again. This was fixed last night. You can fix it just by updating and running make install in share/mk. This is highlighted as tinderbox creates a clean build environment while the base system kept working with the old file being left behind - make delete-old doesn't remove bsd.own.mk from base but a clean system doesn't get it installed. In r265420 /head/share/mk/Makefile removed reference to bsd.own.mk and replaced it with src.opts.mk Yea that?s totally bogus. Which is why I fixed it. One too many automatic replacements that slipped through the cracks. bsd.port.mk was left unaltered still including bsd.own.mk which now doesn't get installed but is still in svn, breaking ports building. Yea, bsd.port.mk is good. The above breakage was bad... Should bsd.port.mk include src.opts.mk instead of bsd.own.mk or should bsd.own.mk be re-added to the install list? The proper fix is in the tree: re-add bsd.own.mk. This appears to carry on from the yesterdays build fails with src.opts.mk not being found. Please update. If the problems persist, please let me know. Also, be sure to remove /usr/share/mk/src.opts.mk, since if will cause you head-aches in the future if you don?t. If we're supposed to remove /usr/share/mk/src.opts.mk until futher notice, why is it being reinstalled by make installworld? make installworld sure did this at r265705 yesterday. Maybe I'm missing something. Sorry for the bumps? The beumps? ;-) -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ ___ 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: ale(4) cannot negotiate as GigE
On Fri, May 09, 2014 at 02:38:16PM +0900, Yonghyeon PYUN wrote: On Thu, May 08, 2014 at 05:23:32PM +, Alexey Dokuchaev wrote: I just had a chance to plug the Ethernet cable directly into my laptop's bge(4) port, and it immediately negotiated at 1000baseT; but with the switch, it can only feel fine with 10baseT/UTP (after some 1000baseT-no carrier flip flopping). So it looks like it fails to talk to the switch. Given that this switch of mine in a simple (dumb) piece of equipment, any ideas how to help ale(4) to negotiate with it at full speed? Because there is no publicly available data sheet for Atheros F1 PHY I'm not sure what could be done in this case. The only thing I can think of at this moment is announcement of next page in auto negotiation. [...] Try attached patch and let me know whether this makes any difference for you. You may have to cold boot the box because stock driver used to clear next page bit in auto-negotiation. Thanks for the patch, but it does not make any noticeable difference. I'll try to boot some Ubuntu livecd to see if it works there; eventually I might have to simply go out and buy some PCI-E gigE card. :( ./danfe ___ 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: Questions and *little* bugs in new vt(9)
On 08/05/2014 17:09, Ed Maste wrote: On 8 May 2014 04:16, David Demelier demelier.da...@gmail.com wrote: Hi there, I'm currently trying vt(9) on a CURRENT kernel (only the kernel not the base). I have very small bugs, not really serious. I'm currently using the radeon KMS driver. * When I switch from a tty to X I can see the mouse appearing but the tty is still displayed until I move the mouse. Or until I wait something like 3 seconds. It sounds like a small refresh trouble. Interesting. On my stable/9 desktop with i915kms I can't reproduce this; after switching back to X the previous display is restored, and then a redraw happens, within a few hundred mS. I do see it on my laptop, which also has i915kms but newer software (recent CURRENT, and newer xorg packages). I'll see if I can gather more information at BSDCan next week. Funny, I can't reproduce the bug neither. I've removed some parts from my xorg.conf, maybe the problem came from here. * When I don't use the native resolution (i.e the radeon firmwares are not loaded) switching from a tty to another results sometimes in a black screen when only some colors are displayed. This does not seems to appear when the native resolution is set. Can you describe the corruption in some more detail, or share a picture of it? I haven't observed something like this with stock vt, and the vt_vga driver. Yes, I've recorded a video [1]. Please note again that I can reproduce this bug only when I don't have any firmware loaded / KMS enabled. I just boot with stock vt and vt_vga enabled. In the video I've successfully reproduced the bug two times by switching ttys at around 0:25 when you can see just the cursor shown and also at 0:40 where you can see some garbage colors which came from vim. You can also notice that sometimes switching from one to other displays some artifacts until it is refreshed. And some questions: * Will you add support for dead keys? I have a UK keyboard and when I want to write french characters like à ô ê I usually press the ` character then a. This isn't currently planned, but I'll keep it in mind if I look into future work on the keyboard input path. I hope for :-). [1] http://www.demelierdavid.fr/files/vt.mp4 Regards, David. ___ 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_NIS after bsd.opts.mk / src.opts.mk split
Hi,
On Fri, May 9, 2014 at 2:54 AM, Warner Losh i...@bsdimp.com wrote:
On May 8, 2014, at 3:26 PM, Guy Yur guy...@gmail.com wrote:
Hi,
After the bsd.opts.mk / src.opts.mk split
WITHOUT_NIS in src.conf doesn't work.
It should still work… At least that’s the intention...
src.conf is included in src.opts.mk after bsd.own.mk
which includes bsd.opts.mk.
Yea, that’s a problem… It should be included after.
Your fix worked for me.
Another issue that is probably very uncommon so I don't know
if anything should be done about it:
WITHOUT_NIS, WITHOUT_KERBEROS and WITHOUT_OPENSSH also affect
bsd.libnames.mk definition of LIBPAM and MINUSLPAM in case
you build programs with bsd make outside of /usr/src that
use LIBPAM/MINUSLPAM and have NO_SHARED / LDFLAGS+=-static.
The addition of ${LIBYPCLNT} / -lypclnt to LDFLAGS will fail to link if world
was installed without NIS.
A brief look in the ports tree doesn't show any program that does this.
Thanks,
Guy
___
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: wbem, cim and instrumentation
On Wed, 2014-05-07 at 08:39 -0400, Bruno Lauzé wrote: One thing I feel FreeBSD always ignored is instrumentation frameworks. I am talking about wbem, cim model and implementation like OpenPegasus. Why is that? I ported OpenPegasus to work in FreeBSD with few patches. However, of course without providers a wbem doesn't go far. I started to see how to shape providers for freebsd at: github.com/brunolauze/openpegasus-providers my openpegasus port is at: github.com/brunolauze/freebsd-ports/tree/master/net-mgmt/openpegasus Apple ships a wbem Microsoft ships a wbem / non-standard RedHat ships it. Suse ships it. z/OS ships it. Ubuntu and distro-like ships it. And Solaris does also. Why not us? The advantage outside of this idea is better coding technique and design to expose API first and utility based on those APIs. if any utility can be used as API, this discard the need for application to use system() or popen() to execute shell code to accomplish system tasks, which is really bad but widely widespread in lack of good API exposure of those utilities. This reduce a lot of error with changes in utilities switches, etc. and mitigate security risks. Wouldn't it be great to query FreeBSD with queries like: select * from UNIX_DiskDrive where Storage_Capacity 1000 or select * from UNIX_SCSIController WHERE LastErrorCode 0 Anyway, this is just to talk, let me know your opinions! Are you going to propose updates/new ports for these tools? sean Well, like I mentioned, it's pretty useless to publish my port of openpegasus if there's no effort to develop providers for FreeBSD. A task that I started working on when time permits it. My point was to see what people in FreeBSD community thinks about this, about instrumentation and OS exposure to this standard. ___ 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
[FIXED] Re: New and exciting panic, possibly re(4)
On Thu, 2014-05-08 at 16:46 +0400, Alexander V. Chernikov wrote: On 07.05.2014 23:24, Sean Bruno wrote: While screwing around with comcast, I can trivially get this panic out of my desktop machine, and am very confused. It seems to happen on link change up/down events. I'm running 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r265280M. I don't have any direct evidence that this is re(4), just a I'm sorry, that's my fault :) Commit r265279 has introduced panic on IPv4 address removal. That was fixed in r265288. Thanks! Updated and the crash is gone. 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: [rfc] bind per-cpu timeout threads to each CPU
On Thursday, May 08, 2014 11:43:39 pm Adrian Chadd wrote: Hi, I'd like to revisit this now. I'd like to commit this stuff as-is and then take some time to revisit the catch-all softclock from cpu0 swi. It's more complicated than it needs to be as it just assumes timeout_cpu == cpuid of cpu 0. So there's no easy way to slide in a new catch-all softclock. Once that's done I'd like to then experiment with turning on the pcpu tcp timer stuff and gluing that into the RSS CPU ID / netisr ID stuff. Thanks, To be clear, are you going to commit the change to bind all but CPU 0 to their CPU but let the default swi float for now? I think that is fine to commit, but I wouldn't want to bind the default swi for now. -a On 20 February 2014 13:48, Adrian Chadd adr...@freebsd.org wrote: On 20 February 2014 11:17, John Baldwin j...@freebsd.org wrote: (A further variant of this would be to divorce cpu0's swi from the catch-all softclock and let the catch-all softclock float, but bind all the per-cpu swis) I like this idea. If something (eg per-CPU TCP timers, if it's turned on) makes a very specific decision about the CPU then it should be fixed. Otherwise a lot of the underlying assumptions for things like RSS just aren't guaranteed to hold. It could also perhaps extend to some abstract pool of CPUs later, if we wanted to do things like one flowing swi per socket or whatnot when we start booting on 1024 core boxes... -a -- 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: [rfc] bind per-cpu timeout threads to each CPU
On 9 May 2014 10:49, John Baldwin j...@freebsd.org wrote: On Thursday, May 08, 2014 11:43:39 pm Adrian Chadd wrote: Hi, I'd like to revisit this now. I'd like to commit this stuff as-is and then take some time to revisit the catch-all softclock from cpu0 swi. It's more complicated than it needs to be as it just assumes timeout_cpu == cpuid of cpu 0. So there's no easy way to slide in a new catch-all softclock. Once that's done I'd like to then experiment with turning on the pcpu tcp timer stuff and gluing that into the RSS CPU ID / netisr ID stuff. Thanks, To be clear, are you going to commit the change to bind all but CPU 0 to their CPU but let the default swi float for now? I think that is fine to commit, but I wouldn't want to bind the default swi for now. I'd like to do it in the other order and bind everything, so things like the per-CPU TCP timer thing can be flipped on for RSS and actually be useful. I'm looking into what it'd take to create a separate default swi as well as a cpu-0 swi but as I said, it's pretty hairy there. How about i instead do the comprimise: * i'll pin all other swi's * default swi isn't pinned by default, but one can flip on a sysctl at boot time to pin it How's that sound? -a ___ 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: [rfc] bind per-cpu timeout threads to each CPU
How about i instead do the comprimise: * i'll pin all other swi's * default swi isn't pinned by default, but one can flip on a sysctl at boot time to pin it How's that sound? And also please a sysctl that disables any swi pinning. It is sometimes useful to change the default cpuset, for instance to allocate a subset of CPUs to some particular applications and not FreeBSD. Having kernel threads pinned prevents this from happening since they are in the default set. (Note that some network drivers are also culprits here, though disabling MSI-x in them is a workaround). later, Peter. ___ 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: [rfc] bind per-cpu timeout threads to each CPU
On 9 May 2014 12:50, Peter Grehan gre...@freebsd.org wrote: How about i instead do the comprimise: * i'll pin all other swi's * default swi isn't pinned by default, but one can flip on a sysctl at boot time to pin it How's that sound? And also please a sysctl that disables any swi pinning. It is sometimes useful to change the default cpuset, for instance to allocate a subset of CPUs to some particular applications and not FreeBSD. Having kernel threads pinned prevents this from happening since they are in the default set. (Note that some network drivers are also culprits here, though disabling MSI-x in them is a workaround). Yup. I've just done that. http://people.freebsd.org/~adrian/norse/20140509-swi-pin-1.diff Which workloads are you thinking about? Maybe we could introduce some higher level description of which CPU(s) at boot time to do freebsd stuff on, and then don't start things like pcpu swi's and NIC threads on those CPUs. Can you think of situations where we'd want to have per-cpu swi's even _running_ for CPUs that you want to dedicate to other things? There's nothing stopping you from scheduling a callout on a different target CPU. (It'd require some work, but it likely should be done in some form as part of overall RSS framework hacking.) -a ___ 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: [rfc] bind per-cpu timeout threads to each CPU
On Friday, May 09, 2014 3:50:28 pm Peter Grehan wrote: How about i instead do the comprimise: * i'll pin all other swi's * default swi isn't pinned by default, but one can flip on a sysctl at boot time to pin it How's that sound? And also please a sysctl that disables any swi pinning. It is sometimes useful to change the default cpuset, for instance to allocate a subset of CPUs to some particular applications and not FreeBSD. Having kernel threads pinned prevents this from happening since they are in the default set. (Note that some network drivers are also culprits here, though disabling MSI-x in them is a workaround). I'd actually like a way to exempt certain kernel threads that are inherently per-CPU (such as queues for NIC drivers or per-CPU swi threads) from the default cpuset so that they don't break 'cpuset -l 0 -s 1'. Providing some sort of way to disable the pinning for now should be good, but I think I'd eventually prefer the former suggestion. -- 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: [rfc] bind per-cpu timeout threads to each CPU
Yup. I've just done that. http://people.freebsd.org/~adrian/norse/20140509-swi-pin-1.diff Thanks, that'll work. Which workloads are you thinking about? Maybe we could introduce some higher level description of which CPU(s) at boot time to do freebsd stuff on, and then don't start things like pcpu swi's and NIC threads on those CPUs. A classic case is partitioning cores into control and data plane groups. I'm sure there are lots more. What's nice about cpuset is that the choice and change can be dynamic, so long as there aren't pinned threads in the default set. An option to restrict FreeBSD pCPU threads to a subset could be useful. Can you think of situations where we'd want to have per-cpu swi's even _running_ for CPUs that you want to dedicate to other things? There's nothing stopping you from scheduling a callout on a different target CPU. At least for the uses I know, it's complete isolation from other processing, kernel threads included. The 'freebsd stuff' info you mentioned should be sufficient. later, Peter. ___ 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: [rfc] bind per-cpu timeout threads to each CPU
On 9 May 2014 16:49, Peter Grehan gre...@freebsd.org wrote: Yup. I've just done that. http://people.freebsd.org/~adrian/norse/20140509-swi-pin-1.diff Thanks, that'll work. Which workloads are you thinking about? Maybe we could introduce some higher level description of which CPU(s) at boot time to do freebsd stuff on, and then don't start things like pcpu swi's and NIC threads on those CPUs. A classic case is partitioning cores into control and data plane groups. I'm sure there are lots more. What's nice about cpuset is that the choice and change can be dynamic, so long as there aren't pinned threads in the default set. An option to restrict FreeBSD pCPU threads to a subset could be useful. Cool. Can you think of situations where we'd want to have per-cpu swi's even _running_ for CPUs that you want to dedicate to other things? There's nothing stopping you from scheduling a callout on a different target CPU. At least for the uses I know, it's complete isolation from other processing, kernel threads included. The 'freebsd stuff' info you mentioned should be sufficient. Cool. I'll look at committing this stuff in the next few hours. It can always easily be undone. I'll revisit the limit pcpu threads to cpuids x idea later. -a ___ 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: [rfc] bind per-cpu timeout threads to each CPU
ok, I've committed it but I've left the default at don't pin. That way the existing behaviour hasn't changed and it's easy to flip on to play with. Thanks for the feedback John / Peter! -a ___ 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
