Re: [head tinderbox] failure on amd64/amd64
on 10/09/2010 01:57 Doug Barton said the following: On 9/8/2010 7:39 AM, Mike Tancsa wrote: Perhaps as an interim measure a local procmail rule to filter out cvsup failures from going to the list ? That's a particularly unhelpful response. Not only is it borderline rude to attempt to shift the responsibility for this to the users, it's a violation of the robustness principle. My impression that the suggestion was to do the filtering on the sending end, not the recipients' end. -- 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: [head tinderbox] failure on amd64/amd64
At 06:57 PM 9/9/2010, Doug Barton wrote: Normally they are pointed to a local mirror here at Sentex. However, that server was having hardware problems which I think we have isolated and resolved now. I will repoint this tinderbox to the local site again. The best way to handle this would be to have messages about csup failing to be directed only to those who are actually able to fix the problem. Assuming that the cvsup server is always going to work is contrary to both history and good system administration practices. :) Perhaps as an interim measure a local procmail rule to filter out cvsup failures from going to the list ? That's a particularly unhelpful response. Not only is it borderline rude to attempt to shift the responsibility for this to the users, it's a violation of the robustness principle. I meant local procmail rule as in local to the tinderboxes so that des and myself and others who admin the boxes only get such messages. I didnt want to make such changes without des' approval and was waiting for his input... ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: {arch}/conf/DEFAULTS and uart
On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: On Thu Sep 9 10, Alexander Best wrote: On Thu Sep 9 10, Alexander Best wrote: hi there, except for arm most archs seem to enforce uart support in conf/DEFAULTS. is this really necessary? shouldn't DEFAULTS only contain vital devices/options without a kernel on a specific arch won't function at all? jhb just explained to me, that the uart entry in DEFAULTS is not a controller or something like that, but the uart backend to use *if* uart gets defined in the kernel config. sorry for the noise folks. however i found some missing comments and incorrect syntax which i fixed. see the attached patch. I think the ia64 ordering for 'io and mem' is probably more correct (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. The powerpc 'machine' changes are wrong I think as it would break GENERIC64 and powerpc64 kernel configs in general. Nathan purposefully removed 'machine' from the powerpc DEFAULTS. -- 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: {arch}/conf/DEFAULTS and uart
On Fri Sep 10 10, John Baldwin wrote: On Thursday, September 09, 2010 3:50:45 pm Alexander Best wrote: On Thu Sep 9 10, Alexander Best wrote: On Thu Sep 9 10, Alexander Best wrote: hi there, except for arm most archs seem to enforce uart support in conf/DEFAULTS. is this really necessary? shouldn't DEFAULTS only contain vital devices/options without a kernel on a specific arch won't function at all? jhb just explained to me, that the uart entry in DEFAULTS is not a controller or something like that, but the uart backend to use *if* uart gets defined in the kernel config. sorry for the noise folks. however i found some missing comments and incorrect syntax which i fixed. see the attached patch. I think the ia64 ordering for 'io and mem' is probably more correct (alphabetically sorted), so I would fix i386 and amd64 and leave ia64 alone. The powerpc 'machine' changes are wrong I think as it would break GENERIC64 and powerpc64 kernel configs in general. Nathan purposefully removed 'machine' from the powerpc DEFAULTS. thanks for the feedback. i'll hack in the changes and will send out a new patch on monday or so. :) cheers. alex -- John Baldwin -- a13x ___ 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
Eventtimers b0rking w/ math/atlas
While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, the kernel hangs at some point when math/atlas tries to run some tests (presumably the ones to profile the code and optimise). The kernel spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. After that, the system is no longer responsive, and eventually panic()s because some spinlock has been held too long in the pmap TLB invalidate code. Couldn't get a dump, because I had no dumpdev configured. Anyone else see this problem? I'm trying to reproduce it by building other ports (it has survived gcc44, gcc45, llvm and clang so far), but only math/atlas seems to trigger it. Cheers, -- Thomas E. Spanjaard t...@netphreax.net t...@deepbone.net signature.asc Description: OpenPGP digital signature
Re: Eventtimers b0rking w/ math/atlas
On 2010-09-10 15:50, Thomas E. Spanjaard wrote: While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, the kernel hangs at some point when math/atlas tries to run some tests (presumably the ones to profile the code and optimise). The kernel spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. It's probably running profiled executables (e.g. compiled with -pg)? This can lead to the above messages, and apparently also to deadlocks. I am not sure what to do about it though, except confirm that this is very likely your problem... ___ 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: Eventtimers b0rking w/ math/atlas
On Fri, Sep 10, 2010 at 04:31:40PM +0200, Dimitry Andric wrote:
On 2010-09-10 15:50, Thomas E. Spanjaard wrote:
While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411,
the kernel hangs at some point when math/atlas tries to run some tests
(presumably the ones to profile the code and optimise). The kernel
spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @
127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again.
It's probably running profiled executables (e.g. compiled with -pg)?
This can lead to the above messages, and apparently also to deadlocks.
I am not sure what to do about it though, except confirm that this is
very likely your problem...
Try this.
diff --git a/sys/kern/kern_clocksource.c b/sys/kern/kern_clocksource.c
index 6b005de..7f0c781 100644
--- a/sys/kern/kern_clocksource.c
+++ b/sys/kern/kern_clocksource.c
@@ -65,6 +65,7 @@ inline static int doconfigtimer(int i);
static voidconfigtimer(int i);
static struct eventtimer *timer[2] = { NULL, NULL };
+static int blocked_timer[2];
static int timertest = 0;
static int timerticks[2] = { 0, 0 };
static int profiling_on = 0;
@@ -91,6 +92,22 @@ static DPCPU_DEFINE(tc, configtimer);
(((uint64_t)0x8000 + ((bt)-frac 2)) / \
((bt)-frac 1))
+static void
+block_timer(int i)
+{
+
+ critical_enter();
+ atomic_add_acq_int(blocked_timer[i], 1);
+}
+
+static void
+unblock_timer(int i)
+{
+
+ atomic_add_rel_int(blocked_timer[i], -1);
+ critical_exit();
+}
+
/* Per-CPU timer1 handler. */
static int
hardclockhandler(struct trapframe *frame)
@@ -246,6 +263,8 @@ doconfigtimer(int i)
atomic_store_rel_int(*conf + i, 0);
return (1);
}
+ if (atomic_load_acq_int(blocked_timer[i]) 0)
+ return (1);
return (0);
}
@@ -366,9 +385,7 @@ cpu_initclocks_bsp(void)
profhz = round_freq(timer[1], stathz * 64);
}
tick = 100 / hz;
- ET_LOCK();
cpu_restartclocks();
- ET_UNLOCK();
}
/* Start per-CPU event timers on APs. */
@@ -376,12 +393,10 @@ void
cpu_initclocks_ap(void)
{
- ET_LOCK();
if (timer[0]-et_flags ET_FLAGS_PERCPU)
et_start(timer[0], NULL, timerperiod[0]);
if (timer[1] timer[1]-et_flags ET_FLAGS_PERCPU)
et_start(timer[1], NULL, timerperiod[1]);
- ET_UNLOCK();
}
/* Reconfigure and restart event timers after configuration changes. */
@@ -411,9 +426,11 @@ cpu_restartclocks(void)
timer2hz = round_freq(timer[1], timer2hz);
}
timer1hz = round_freq(timer[0], timer1hz);
+#ifdef notyet
printf(Starting kernel event timers: %s @ %dHz, %s @ %dHz\n,
timer[0]-et_name, timer1hz,
timer[1] ? timer[1]-et_name : NONE, timer2hz);
+#endif
/* Restart event timers. */
FREQ2BT(timer1hz, timerperiod[0]);
configtimer(0);
@@ -422,7 +439,9 @@ cpu_restartclocks(void)
timerticks[1] = 0;
FREQ2BT(timer2hz, timerperiod[1]);
configtimer(1);
+#ifdef notyet
timertest = 1;
+#endif
}
}
@@ -433,7 +452,11 @@ cpu_startprofclock(void)
ET_LOCK();
profiling_on = 1;
+ block_timer(0);
+ block_timer(1);
cpu_restartclocks();
+ unblock_timer(1);
+ unblock_timer(0);
ET_UNLOCK();
}
@@ -444,7 +467,11 @@ cpu_stopprofclock(void)
ET_LOCK();
profiling_on = 0;
+ block_timer(0);
+ block_timer(1);
cpu_restartclocks();
+ unblock_timer(1);
+ unblock_timer(0);
ET_UNLOCK();
}
@@ -461,10 +488,11 @@ sysctl_kern_eventtimer_timer1(SYSCTL_HANDLER_ARGS)
snprintf(buf, sizeof(buf), %s, et-et_name);
ET_UNLOCK();
error = sysctl_handle_string(oidp, buf, sizeof(buf), req);
+ if (error != 0 || req-newptr == NULL)
+ return (error);
ET_LOCK();
et = timer[0];
- if (error != 0 || req-newptr == NULL ||
- strcmp(buf, et-et_name) == 0) {
+ if (strcmp(buf, et-et_name) == 0) {
ET_UNLOCK();
return (error);
}
@@ -473,12 +501,14 @@ sysctl_kern_eventtimer_timer1(SYSCTL_HANDLER_ARGS)
ET_UNLOCK();
return (ENOENT);
}
+ block_timer(0);
timer1hz = 0;
configtimer(0);
et_free(timer[0]);
timer[0] = et;
et_init(timer[0], timer1cb, NULL, NULL);
cpu_restartclocks();
+ unblock_timer(0);
ET_UNLOCK();
return (error);
}
@@ -501,10 +531,11 @@ sysctl_kern_eventtimer_timer2(SYSCTL_HANDLER_ARGS)
snprintf(buf, sizeof(buf), %s, et-et_name);
ET_UNLOCK();
error = sysctl_handle_string(oidp, buf, sizeof(buf), req);
+ if (error != 0 ||
DHCP server in base
Hi folks, I personally agree that a DHCP client must exists in base, and for this purpose we have dhclient. However soon I will have a new small machine that will only work as bind and dhcpd server. I was surprised to see that there is no DHCP server in base, obviously it's not difficult to fetch the net/isc-dhcp31-server package but for people that would like to setup a new server on FreeBSD quickly they will take some time to learn how packages framework works or ports and it can be annoying. Since the size of the net/isc-dhcp31-server port is really small I think it would be really useful to get it by default on a FreeBSD install. Information for isc-dhcp31-server-3.1.3_1: Package Size: 1232(1K-blocks) What do you think? With kind regards, -- Demelier 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: Eventtimers b0rking w/ math/atlas
Hi. Thomas E. Spanjaard wrote: While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, the kernel hangs at some point when math/atlas tries to run some tests (presumably the ones to profile the code and optimise). The kernel spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. After that, the system is no longer responsive, and eventually panic()s because some spinlock has been held too long in the pmap TLB invalidate code. Couldn't get a dump, because I had no dumpdev configured. Anyone else see this problem? I'm trying to reproduce it by building other ports (it has survived gcc44, gcc45, llvm and clang so far), but only math/atlas seems to trigger it. It is reported deadlock between event timers and some IPI senders, like TLB invalidation, during switching to/from profiling clock rate. In forthcoming version of event timer patch this problem should not happen. You can get latest version of the patch here: http://people.freebsd.org/~mav/timers_oneshot13.patch -- Alexander Motin ___ 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: Eventtimers b0rking w/ math/atlas
On 09/10/2010 14:40, Kostik Belousov wrote: On Fri, Sep 10, 2010 at 04:31:40PM +0200, Dimitry Andric wrote: On 2010-09-10 15:50, Thomas E. Spanjaard wrote: While trying to build math/atlas on a FreeBSD/amd64 9.0-CURRENT r212411, the kernel hangs at some point when math/atlas tries to run some tests (presumably the ones to profile the code and optimise). The kernel spouts messages about Starting event timers: LAPIC @ 1000Hz, HPET @ 127Hz; then LAPIC @ 1000Hz, HPET @ 8128Hz (iirc), back, then back again. It's probably running profiled executables (e.g. compiled with -pg)? This can lead to the above messages, and apparently also to deadlocks. I am not sure what to do about it though, except confirm that this is very likely your problem... Try this. Your patch indeed lets me build math/atlas. Thanks! Oh, and next time, just add it as an attachment, makes it easier :P. Cheers, -- Thomas E. Spanjaard t...@netphreax.net t...@deepbone.net signature.asc Description: OpenPGP digital signature
Re: Eventtimers b0rking w/ math/atlas
On 09/10/2010 15:31, Alexander Motin wrote: It is reported deadlock between event timers and some IPI senders, like TLB invalidation, during switching to/from profiling clock rate. In forthcoming version of event timer patch this problem should not happen. You can get latest version of the patch here: http://people.freebsd.org/~mav/timers_oneshot13.patch I'll try your patch as well after math/atlas has finished building. I assume it applies cleanly to head, and this one is most likely to end up being committed? Cheers, -- Thomas E. Spanjaard t...@netphreax.net t...@deepbone.net signature.asc Description: OpenPGP digital signature
Re: DHCP server in base
David DEMELIER ha scritto: I was surprised to see that there is no DHCP server in base, obviously it's not difficult to fetch the net/isc-dhcp31-server package but for people that would like to setup a new server on FreeBSD quickly they will take some time to learn how packages framework works or ports and it can be annoying. If you (people) don't know how to use ports/packages probably you shouldn't use FreeBSD. And I hardly think that installing a port requires more knowledge than correctly configuring a DHCP server. Then, why 3.1 and not 4.1? Why not bundling also apache? etc., etc. -- Alex Dupre ___ 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: Eventtimers b0rking w/ math/atlas
Thomas E. Spanjaard wrote: On 09/10/2010 15:31, Alexander Motin wrote: It is reported deadlock between event timers and some IPI senders, like TLB invalidation, during switching to/from profiling clock rate. In forthcoming version of event timer patch this problem should not happen. You can get latest version of the patch here: http://people.freebsd.org/~mav/timers_oneshot13.patch I'll try your patch as well after math/atlas has finished building. I assume it applies cleanly to head, and this one is most likely to end up being committed? This version should be good enough. I am running it on all I have. Now I need to optimize some surrounding things and the next version has a good chances to get into HEAD soon. -- Alexander Motin ___ 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: DHCP server in base
I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. ___ 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: DHCP server in base
On Fri, Sep 10, 2010 at 05:29:40PM +0200, Alex Dupre wrote: David DEMELIER ha scritto: I was surprised to see that there is no DHCP server in base, obviously it's not difficult to fetch the net/isc-dhcp31-server package but for people that would like to setup a new server on FreeBSD quickly they will take some time to learn how packages framework works or ports and it can be annoying. As someone who changed from FreeBSD to CentOS, due to a job change, let me say that one of the things I greatly prefer about FreeBSD is that they *don't* make very many assumptions about what the user needs, whereas far too many Linux distributions do the opposite, not only throwing in too much, but often making it difficult to work around what they've decided you need. :) So, I would respectfully disagree. It's easy enough to add a dhcp server if desired, and this way, you don't annoy all the people who DON'T want it. Sincerely, -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Willow: Why couldn't he be possessed by a puppy, or some ducks? ___ 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: DHCP server in base
2010/9/10 Matthew Jacob m...@feral.com: I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. ___ 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 In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? And what about bind too? A lot of user do not needs it, by the way there is already src.conf(5) to enable or disable modules, then a WITHOUT_DHCPD would be useful. Cheers. -- Demelier 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: [head tinderbox] failure on amd64/amd64
On 9/10/2010 12:54 AM, Mike Tancsa wrote: At 06:57 PM 9/9/2010, Doug Barton wrote: Normally they are pointed to a local mirror here at Sentex. However, that server was having hardware problems which I think we have isolated and resolved now. I will repoint this tinderbox to the local site again. The best way to handle this would be to have messages about csup failing to be directed only to those who are actually able to fix the problem. Assuming that the cvsup server is always going to work is contrary to both history and good system administration practices. :) Perhaps as an interim measure a local procmail rule to filter out cvsup failures from going to the list ? That's a particularly unhelpful response. Not only is it borderline rude to attempt to shift the responsibility for this to the users, it's a violation of the robustness principle. I meant local procmail rule as in local to the tinderboxes so that des and myself and others who admin the boxes only get such messages. I didnt want to make such changes without des' approval and was waiting for his input... In that case I apologize for the misunderstanding. I've used procmail for many years on the receiving end but was not aware of the ability to use it in the manner you suggested. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: [head tinderbox] failure on amd64/amd64
At 02:02 PM 9/10/2010, Doug Barton wrote: In that case I apologize for the misunderstanding. I've used procmail for many years on the receiving end but was not aware of the ability to use it in the manner you suggested. Have the tinderbox send just one email to a local account, then use procmailrc to figure out where to send copies. ---Mike ___ 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: [head tinderbox] failure on amd64/amd64
On 9/10/2010 11:22 AM, Mike Tancsa wrote: At 02:02 PM 9/10/2010, Doug Barton wrote: In that case I apologize for the misunderstanding. I've used procmail for many years on the receiving end but was not aware of the ability to use it in the manner you suggested. Have the tinderbox send just one email to a local account, then use procmailrc to figure out where to send copies. Ah, well, see? That's even more creative than I was giving you credit for. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: DHCP server in base
On 9/10/2010 9:54 AM, David DEMELIER wrote: 2010/9/10 Matthew Jacobm...@feral.com: I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. I agree with Matt on this one, although that shouldn't be a surprise since I'm on record saying it often. :) In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? Unfortunately arguing to include something new in the base because something else that you don't agree with is already there is not a valid method. The bar is a lot higher for adding things than keeping things (for better or worse). And what about bind too? As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, so keep them, but get rid of the rest! 4. BIND is library based, so 90% of the work to make the command line tools is building the libs, after which building the server and its accessories is trivial work. 5. Oh, well, then make knobs to disable the server! 6. That's already done. 7. Oh, well, never mind then *mumble mumble* However, all that is likely to change at some point in the future (as in, years from now) when BIND 10 becomes the only and/or most viable option since it requires a lot of stuff that we are unlikely to ever import into the base (like boost, python, etc.). So there is hope for you anti-BIND folks yet! :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: DHCP server in base
On Fri, Sep 10, 2010 at 11:36 AM, Doug Barton do...@freebsd.org wrote: On 9/10/2010 9:54 AM, David DEMELIER wrote: And what about bind too? As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, so keep them, but get rid of the rest! 4. BIND is library based, so 90% of the work to make the command line tools is building the libs, after which building the server and its accessories is trivial work. 5. Oh, well, then make knobs to disable the server! 6. That's already done. 7. Oh, well, never mind then *mumble mumble* Possibly off-topic for this particular thread, but the above reminded me of what DragonflyBSD just went through, as they removed BIND from their base install: importing a smaller codeset that provides the same functionality as the BIND tools[1]. However, that may or may not be a net gain, as then you need someone to maintain those non-BIND tools. But, if one looks at the Perl situation when it was removed from base, couldn't one remove BIND, but have the package listed as mandatory install, the way Perl was for awhile (or maybe still is)? This is also something that DragonflyBSD does, using pkgsrc packages for things they want installed by default, but that they don't want to maintain as part of their source tree. Of course, then you have to train everyone to use /usr/local/etc/named instead of /etc/named. :) (But, it's that what major version updates and .0 releases are for?) [1] http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html -- 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: DHCP server in base
On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton do...@freebsd.org wrote: As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. DragonflyBSD chose to remove BIND and to use drill as a replacement [1]. Don't know if it meet our requirements, though. [1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html ___ 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: about in_multi_mtx @ netinet/in_mcast.c:1095
On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: Hello, I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag when it's initialized so I always encounters the following LOR lock order reversal: (sleepable after non-sleepable) 1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ netinet/in_mcast.c:1095 2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 usbd_do_request_flags() at usbd_do_request_flags+0xe5 axe_cmd() at axe_cmd+0xc7 axe_setmulti_locked() at axe_setmulti_locked+0x70 axe_setmulti() at axe_setmulti+0x3e axe_ioctl() at axe_ioctl+0x132 if_addmulti() at if_addmulti+0x19b in_joingroup_locked() at in_joingroup_locked+0x1bc in_joingroup() at in_joingroup+0x52 in_control() at in_control+0x1144 ifioctl() at ifioctl+0x1118 kern_ioctl() at kern_ioctl+0xbe ioctl() at ioctl+0xfd syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 when I uses the following code at driver's ioctl routine: case SIOCADDMULTI: case SIOCDELMULTI: axe_setmulti(sc, 0); break; It means that USB driver always should defer SIOCADDMULTI / SIOCDELMULTI handling to the other process context to avoid LOR. My question is that is it safe if the multicasting operations for USB device happens without IN_MULTI_LOCK? Or is there any race cases if the task is deferred? Why is USB using an sx lock instead of a mutex? Frankly speaking I also don't know why hps@ uses sx lock. That is one of things I'd like to change it. Just looking the comment at usb_reques...@441: /* * Grab the default sx-lock so that serialisation * is achieved when multiple threads are involved: */ sx_xlock(udev-ctrl_sx); I think he might want to hold the lock even if the thread is going into sleep. It might be for serialization. However even if we succeed to change the lock from sx to mutex, it's hard to avoid the requests going into the sleep. It means USB stack should call like below: mtx_sleep(chan, IN_MULTI_LOCK, ...); to avoid the kernel's complain (would be `sleep with holding non-sleepable lock'). What I'd like to say is that the sleeping is big problem if mutex is used that it'd be worse when multiple mutex locks are used. So I'm looking for a fundamental solution to solve this problem. Welcomes any ideas. It is probably fine to just schedule a task to do the actual work of axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself in your task handler as long as your handler holds the appropriate lock (if_maddr_rlock() IIRC) when walking the interface's multicast address list. OK. I'll try to use a task handler for this case. One thing, just for curious. Why the lower layer (in this case it might be netinet/in_mcast.c) calls ioctl interface with holding IN_MULTI_LOCK? If it calls ioctl without holding the lock, all drivers (specially all USB drivers) which handles SIOCADDMULTI and SIOCDELMULTI don't need to implement their own taskqueue or process context. It looks to me that calling ioctl interface with holding IN_MULTI_LOCK is useless if the drivers hold if_maddr_rlock(ifp) lock properly though I could miss something important. regards, Weongyo Jeong ___ 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
g_event spinning 100% when doing 'gpart add'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On a brand new system I'm trying to allocate new GPT partition with: gpart create -s gpt ada0 gpart add -t freebsd-zfs ada0 And gpart hangs with g_waitfor_event with g_event spinning 100% of CPU. Any thoughts? The system is FreeBSD/amd64 on Atom D510 with reasonably new FreeBSD -CURRENT code. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMipuLAAoJEATO+BI/yjfBxKoH/25/aQYEbDbYu9rXbsTpUdgw tpHhEYqePJfe9u+Xx4ivFEnasOdIsyWcVVYcuGkdXw6gtYFBK3Zvz21au3AeexeI JIj+v8go5nLy4zQ67CAzkUo4bpmr8g+yiknJzNXD1OtDFaRM/D2NT3SqZbpLAf8i Y4mq2u1Drv1CYnBPTzwgaUd+CKDcV1NtK6MDUOCWAZQLP3z1/iUKn0j385AWSKjC GKHcr4A8NvaNu9otgWBK46UmfzFy8wnhMLW5tu8Sh8OpXFX9HsgTjnGdX/dfBN3A rdjI4ItHj0wZ8iHLLD+y4orYl9cnFUHVJwUaFaBF9WcIWudEC4Tw5yoLXDzK29E= =RqkR -END PGP SIGNATURE- ___ 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: about in_multi_mtx @ netinet/in_mcast.c:1095
On Friday, September 10, 2010 4:28:58 pm Weongyo Jeong wrote: On Thu, Sep 09, 2010 at 02:32:52PM -0400, John Baldwin wrote: On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote: On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote: On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote: Hello, I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag when it's initialized so I always encounters the following LOR lock order reversal: (sleepable after non-sleepable) 1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ netinet/in_mcast.c:1095 2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 usbd_do_request_flags() at usbd_do_request_flags+0xe5 axe_cmd() at axe_cmd+0xc7 axe_setmulti_locked() at axe_setmulti_locked+0x70 axe_setmulti() at axe_setmulti+0x3e axe_ioctl() at axe_ioctl+0x132 if_addmulti() at if_addmulti+0x19b in_joingroup_locked() at in_joingroup_locked+0x1bc in_joingroup() at in_joingroup+0x52 in_control() at in_control+0x1144 ifioctl() at ifioctl+0x1118 kern_ioctl() at kern_ioctl+0xbe ioctl() at ioctl+0xfd syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 when I uses the following code at driver's ioctl routine: case SIOCADDMULTI: case SIOCDELMULTI: axe_setmulti(sc, 0); break; It means that USB driver always should defer SIOCADDMULTI / SIOCDELMULTI handling to the other process context to avoid LOR. My question is that is it safe if the multicasting operations for USB device happens without IN_MULTI_LOCK? Or is there any race cases if the task is deferred? Why is USB using an sx lock instead of a mutex? Frankly speaking I also don't know why hps@ uses sx lock. That is one of things I'd like to change it. Just looking the comment at usb_reques...@441: /* * Grab the default sx-lock so that serialisation * is achieved when multiple threads are involved: */ sx_xlock(udev-ctrl_sx); I think he might want to hold the lock even if the thread is going into sleep. It might be for serialization. However even if we succeed to change the lock from sx to mutex, it's hard to avoid the requests going into the sleep. It means USB stack should call like below: mtx_sleep(chan, IN_MULTI_LOCK, ...); to avoid the kernel's complain (would be `sleep with holding non-sleepable lock'). What I'd like to say is that the sleeping is big problem if mutex is used that it'd be worse when multiple mutex locks are used. So I'm looking for a fundamental solution to solve this problem. Welcomes any ideas. It is probably fine to just schedule a task to do the actual work of axe_setmulti(). I think you do not need to lock IN_MULTI_LOCK yourself in your task handler as long as your handler holds the appropriate lock (if_maddr_rlock() IIRC) when walking the interface's multicast address list. OK. I'll try to use a task handler for this case. One thing, just for curious. Why the lower layer (in this case it might be netinet/in_mcast.c) calls ioctl interface with holding IN_MULTI_LOCK? If it calls ioctl without holding the lock, all drivers (specially all USB drivers) which handles SIOCADDMULTI and SIOCDELMULTI don't need to implement their own taskqueue or process context. It looks to me that calling ioctl interface with holding IN_MULTI_LOCK is useless if the drivers hold if_maddr_rlock(ifp) lock properly though I could miss something important. It would introduce races in the multicast code to drop the lock around the ioctl which would complicate it a good bit. Non-USB ethernet drivers just use plain locks which handle this situation just fine. -- 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: DHCP server in base
On Fri, 10 Sep 2010 21:06:45 +0200 Julien Laffaye kime...@gmail.com wrote: On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton do...@freebsd.org wrote: As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. DragonflyBSD chose to remove BIND and to use drill as a replacement [1]. Don't know if it meet our requirements, though. [1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html ___ 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 Hi, another argument about hostapd :) if have access point we must have way to assign IP for AP clients. Last spring I made firmware based on FreeBSD for router with only 4MB NOR flash (D-Link DIR-320). Since this device is router I must be able to serve DHCP. And current implementation of dhcpclient, that we have, is same isc-dhcp, and I replace system dhcpclient with ports one+dhcpd but with small patch that put basic dhcp utils onto libdhcp.so. So: 1. We already have code for libdhcp in base. 2. We already use isc-dhcp as dhcpclient. 3. We already build small-size embedded routers firmware with DHCP server. 4. We have hostap and other router/AP functionality. So why not include dhcpd in base now? -- Aleksandr Rybalko r...@ddteam.net ___ 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
LSI 6Gb SAS driver committed
I sent this out to the -scsi list earlier today. Testers would be appreciated for the 6Gb LSI SAS driver. Please follow up to me or the -scsi list. Thanks, Ken - Forwarded message from Kenneth D. Merry k...@freebsd.org - Date: Fri, 10 Sep 2010 09:04:38 -0600 From: Kenneth D. Merry k...@freebsd.org To: s...@freebsd.org Subject: LSI 6Gb SAS driver committed Hey folks, I have commited the mps driver (LSI Logic 6Gb SAS controller driver) to the FreeBSD perforce server (//depot/projects/mps/... and FreeBSD-current. The driver works with SAS and SATA drives, directly attached or attached through expanders. Basic error recovery works as well (i.e. timeouts and aborts). There are some known issues, including: - No support for integrated RAID (IR) arrays. - Devices tend to disappear and come back in one of my configurations. I also see some phantom devices, and events that don't make sense: mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 (da2:mps0:0:6:0): SCSI command timeout on device handle 0x0017 SMID 90 mps0: mpssas_abort_complete: abort request on handle 0x17 SMID 90 complete mps0: Unhandled event 0x0 (probe2:mps0:0:2:0): AutoSense failed mps0: Unhandled event 0x0 (da10:mps0:0:0:0): unsupportable block size 0 (da10:mps0:0:0:0): lost device (da10:mps0:0:0:0): removing device entry (da2:mps0:0:6:0): lost device (da2:mps0:0:6:0): removing device entry da2 at mps0 bus 0 scbus0 target 6 lun 0 da2: ATA ST3160023AS 3.05 Fixed Direct Access SCSI-5 device da2: 150.000MB/s transfers da2: Command Queueing enabled da2: 152627MB (312581808 512 byte sectors: 255H 63S/T 19457C) mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 mps0: Unhandled event 0x0 - Sometimes you'll run into a device that fails part of the probe on boot, and you'll end up running into the run_interrupt_driven_config_hooks timeout. You see some aborts during probe, and then the 5 minute probe timeout kicks in and panics the kernel. For instance: (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 81 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 81 complete run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 214 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 214 complete run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 281 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 281 complete run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 348 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 348 complete run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config (probe4:mps0:0:20:0): SCSI command timeout on device handle 0x0012 SMID 415 mps0: mpssas_abort_complete: abort request on handle 0x12 SMID 415 complete panic: run_interrupt_driven_config_hooks: waited too long cpuid = 0 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x3d: movq$0,0x4c70b0(%rip) db - ioctl support isn't complete, and there is no userland utility. - There is no man page. The driver is in the tree at this point to allow people to test it out, report any problems, and hopefully contribute bug fixes. LSI has some developers working on this driver, and we hope to get them to put some of their work-in-progress in the FreeBSD Perforce repo. So, in view of that, if you make any changes to the driver, please make them in the FreeBSD Perforce repository first (in //depot/projects/mps/...) and then merge them into FreeBSD-current. Thanks to Scott Long for writing the driver, and to Yahoo and Spectra Logic for sponsoring the work. Ken -- Kenneth Merry k...@freebsd.org - End forwarded message - -- Kenneth Merry k...@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: DHCP server in base
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2010 14:36, Doug Barton wrote: On 9/10/2010 9:54 AM, David DEMELIER wrote: 2010/9/10 Matthew Jacobm...@feral.com: I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. I agree with Matt on this one, although that shouldn't be a surprise since I'm on record saying it often. :) In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? Unfortunately arguing to include something new in the base because something else that you don't agree with is already there is not a valid method. The bar is a lot higher for adding things than keeping things (for better or worse). And what about bind too? As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, so keep them, but get rid of the rest! 4. BIND is library based, so 90% of the work to make the command line tools is building the libs, after which building the server and its accessories is trivial work. 5. Oh, well, then make knobs to disable the server! 6. That's already done. 7. Oh, well, never mind then *mumble mumble* However, all that is likely to change at some point in the future (as in, years from now) when BIND 10 becomes the only and/or most viable option since it requires a lot of stuff that we are unlikely to ever import into the base (like boost, python, etc.). So there is hope for you anti-BIND folks yet! :) Doug This is where I say: I believe it would be the correct route to move toward a base package system for things like BIND DHCP... the common stuff that people would like to see in base but not really a conceptional sound idea. My theory behind this goes like this: Make a base package for bind-server, bind-utils, bind-tools or whatever you want to call them with the --package-root defined as /. Do this for ports/lang etc... type of stuff and ship them with the install CD/DVD's. If the user wants the base port then there is no harm done and they can trivially add it. This would leave room for other base system options to include too without having to permanently move things in and out of base because supporting them in-tree does not make sense or other reasons. Specifically I like this type of idea due to not needing to have a compiler (GCC) installed at all times. It could simply be added and removed from the base system by package or installed from ports and allow the end user to choose what they want when they want it. Stuff like GCC, BIND, DHCP Servers other languages for this make sense. Why Not ? Regards, PS: I'll coin this idea (base-board-ports) .02 - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMirvXAAoJEJBXh4mJ2FR+SocH/3pK3s8L9bOb12a6IhhrKSdI mJZeFSyMdx3n4olIkd1VhYA2O6Qsl6hUBASitpbiJ3/9Vz/BAcCW2JE+Ub0rDwZT SG7vk0aaCtjFEBk5xdLM52iDKIGs5uNaKxYQMot0KX4pi/Obm7Pf8AGmQpc8RnSd PBbUX5T0kzbStPE59tQA9gW2UcTxKtx2up+Pzns8mYvUEb+dgEuwPo2rE10aZKuK lnfoZ2LclmQg1KmvzZATrRUxFjHdJQqD4PgPFGEAAWVDlzAFnwQhBufYtyT71lqZ 0T+XW5WQUo6WjjtweyV6uhfPeJUuk+DqkmDGw8oJIRfqYOm3yetSKiOoAgmJ9Qo= =brrR -END PGP SIGNATURE- ___ 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: DHCP server in base
On 09/10/2010 19:14, jhell wrote: On 09/10/2010 14:36, Doug Barton wrote: On 9/10/2010 9:54 AM, David DEMELIER wrote: 2010/9/10 Matthew Jacobm...@feral.com: I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. I agree with Matt on this one, although that shouldn't be a surprise since I'm on record saying it often. :) In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? Unfortunately arguing to include something new in the base because something else that you don't agree with is already there is not a valid method. The bar is a lot higher for adding things than keeping things (for better or worse). And what about bind too? As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, so keep them, but get rid of the rest! 4. BIND is library based, so 90% of the work to make the command line tools is building the libs, after which building the server and its accessories is trivial work. 5. Oh, well, then make knobs to disable the server! 6. That's already done. 7. Oh, well, never mind then *mumble mumble* However, all that is likely to change at some point in the future (as in, years from now) when BIND 10 becomes the only and/or most viable option since it requires a lot of stuff that we are unlikely to ever import into the base (like boost, python, etc.). So there is hope for you anti-BIND folks yet! :) Doug This is where I say: I believe it would be the correct route to move toward a base package system for things like BIND DHCP... the common stuff that people would like to see in base but not really a conceptional sound idea. My theory behind this goes like this: Make a base package for bind-server, bind-utils, bind-tools or whatever you want to call them with the --package-root defined as /. Do this for ports/lang etc... type of stuff and ship them with the install CD/DVD's. If the user wants the base port then there is no harm done and they can trivially add it. This would leave room for other base system options to include too without having to permanently move things in and out of base because supporting them in-tree does not make sense or other reasons. Specifically I like this type of idea due to not needing to have a compiler (GCC) installed at all times. It could simply be added and removed from the base system by package or installed from ports and allow the end user to choose what they want when they want it. Stuff like GCC, BIND, DHCP Servers other languages for this make sense. Why Not ? Regards, PS: I'll coin this idea (base-board-ports) .02 This is also a conversation for another thread. So please do not let it distract you. -- jhell,v ___ 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
LAPIC timer reported as 0 Hz during boot
Looking through a dmesg from today I noticed that the LAPIC timer is being reported as running at 0 Hz: Event timer LAPIC frequency 0 Hz quality 500 But the correct frequency is still being used in the kernel: kern.eventtimer.et.LAPIC.frequency=67470437 -- Bruce Cran ___ 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: DHCP server in base
On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: Hi, another argument about hostapd :) if have access point we must have way to assign IP for AP clients. To start with, your assumption is wrong. DHCPd is not *actually* a requirement, although I admit that practically it is. Last spring I made firmware based on FreeBSD for router with only 4MB NOR flash (D-Link DIR-320). In this category (micro-miniaturization) you're already in the significant customization needed area, which means that general arguments about the base don't apply. Since this device is router I must be able to serve DHCP. And current implementation of dhcpclient, that we have, is same isc-dhcp, and I replace system dhcpclient with ports one+dhcpd but with small patch that put basic dhcp utils onto libdhcp.so. Your argument is creative and well thought out, but I personally don't find it persuasive. Counter arguments that come immediately to mind are: 1. The DHCP server is not going to benefit any but a small minority of FreeBSD users. 2. The software is already available in the ports tree, and adding a port/package of it really is not an overwhelming burden. More generally, the main reason I want to keep more stuff out of the base, and remove some of the stuff that's in there now, is that it makes maintenance difficult across FreeBSD branches. We have a general policy that if we have a major version N of something in a release branch that we don't upgrade that major version without a really good reason to avoid POLA surprises for our users. Once again using BIND as an example, this has led to a really old and past-EOL version of BIND in FreeBSD 6 which I've only gotten away with because anyone doing serious DNS work nowadays has to upgrade to at least 9.6 anyway. But it's an ugly situation, and I don't want to repeat it. The problems get worse and/or more complex with the more 3rd party stuff you start including in the base. In part because of the product lifecycle issues that are similar to BIND's, but also due to the possibility of licensing issues (such as with gcc and/or other GPL software) and other more esoteric factors. Even with home-grown stuff like our pkg_* tools we have problems because when we want to introduce new features (or deprecate old ones) there is currently a _minimum_ 3-year cycle we have to follow in order to make sure that the new feature is/is not available on all supported versions of FreeBSD. That's the main motivation behind my continuing to repeat the suggestion to move those tools specifically into the ports tree so that we can better support innovation in our ports/packages system. In my view what we've needed to do for a long time now is to seriously strip down the notion of what the base should be to those items that are needed to work together for a specific API/ABI/AKI release, and move everything else into the ports tree. (Obviously there would be some exemptions made for really basic/vital stuff like ls, etc.) We can do this in a way that finds a middle ground between the linux model where literally everything is a package and the traditional BSD model of providing a complete system, which is hardly ever true since I've never been involved with any FreeBSD system administration where there were absolutely no ports/packages installed at all. Such a system could also be streamlined by creating a ports virtual category (something like system) the packages for which could be included in the install media as long as we are judicious about what goes in there. Things like wpa_supplicant, dhclient, DNS tools, etc. could all be in that category, and all we'd have to do to make that work is to very slightly expand the list of questions that sysinstall already asks. So this is a much longer version of my previous response which hopefully gives you more background about why it's a bad idea to add *any* more 3rd party stuff to the base. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!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: g_event spinning 100% when doing 'gpart add'
Xin LI delphij at delphij.net writes: Hi, On a brand new system I'm trying to allocate new GPT partition with: gpart create -s gpt ada0 gpart add -t freebsd-zfs ada0 And gpart hangs with g_waitfor_event with g_event spinning 100% of CPU. Any thoughts? The system is FreeBSD/amd64 on Atom D510 with reasonably new FreeBSD -CURRENT code. Cheers, Probably result of kernel built with DEBUG_LOCKS and world without -DDEBUG_LOCKS. HTH, Yuri ___ 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: g_event spinning 100% when doing 'gpart add'
Nevermind me. That's what I thought why I was getting the same gpart behavior switching between kernels, with and without DEBUG_LOCKS. Sorry about that. Same here, gpart hangs on: 3826 gpartCALL __sysctl(0x7fffa250,0x3,0,0x7fffa268,0,0) 3826 gpartSCTL kern.geom.confxml Yuri ___ 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: LAPIC timer reported as 0 Hz during boot
Bruce Cran wrote: Looking through a dmesg from today I noticed that the LAPIC timer is being reported as running at 0 Hz: Event timer LAPIC frequency 0 Hz quality 500 Frequency of LAPIC timer is not reported instantly. It requires calibration to be discovered. Calibration requires time. To reduce boot time I am not calibrating LAPIC timer until it is used first time. With presence of HPET timer there is high chance that LAPIC timer will never be calibrated on significant part of systems. It is not a bug. -- Alexander Motin ___ 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: DHCP server in base
Date: Fri, 10 Sep 2010 17:33:22 -0700 From: Doug Barton do...@freebsd.org Sender: owner-freebsd-curr...@freebsd.org On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: Hi, another argument about hostapd :) if have access point we must have way to assign IP for AP clients. To start with, your assumption is wrong. DHCPd is not *actually* a requirement, although I admit that practically it is. It is not. I routinely use hostapd for access for my iPod. I use static addressing and don't run dhcpd. Since this device is router I must be able to serve DHCP. And current implementation of dhcpclient, that we have, is same isc-dhcp, and I replace system dhcpclient with ports one+dhcpd but with small patch that put basic dhcp utils onto libdhcp.so. Again, I tend to not make much use of DHCP except when traveling. If I am on a known network at work or home, I static address everything (including the iPod and my laptop). I don't need (or run) dhcpd for my use. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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
