Re: Browsing over IPv6
Many more sites are actually putting, or have put, IPv6 into production since the latest world IPv6 day last month. Some growing pains are inevitable. i've actually had IPv6 working 5 years ago, but only as tunneled and still no operators here provide IPv6. Nothing special. As they needed 10-20 years to learn how to make IPv4 work ;) they will need at least 20 years to learn IPv6. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
Robert Simmons rsimmo...@gmail.com writes: OpenSSH 6.0p1 No. It doesn't build cleanly on FreeBSD (I reported two issues during the pre-release cycle, one was fixed but the other was not), and even if it did, it's too big a change to push through on such short notice. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
contigmalloc() breaking Xorg
I have a reasonably recent 8-stable/amd64 system (r237444) with a ATI Radeon HD 2400 Pro, xorg-server-1.10.6,1 and xf86-video-ati-6.14.3_1 8GB RAM and ZFS. I'm seeing fairly consistent problems with Xorg spinning in swwrt for long periods (I've seen ½hr) and then failing. The resultant Xorg.0.log shows (eg): [854259.962] (EE) RADEON(0): [pci] Out of memory (-12) That message comes from xf86-video-ati-6.14.3/src/radeon_dri.c:RADEONDRIPciInit() and the -12 indicates ENOMEM. That code (indirectly) issues DRM_IOCTL_SG_ALLOC and winds up in sys/dev/drm/drm_scatter.c:drm_sg_alloc(), which uses bus_dma_tag_create(), bus_dmamem_alloc() and bus_dmamap_load() to actually allocate memory below 4GB. Setting hw.dri.0.debug shows that it's trying to allocate 32MB: Jul 3 18:57:49 server kernel: [drm:pid72128:drm_ioctl] pid=72128, cmd=0xc0106438, nr=0x38, dev 0xff000246ee00, auth=1 Jul 3 18:57:49 server kernel: [drm:pid72128:drm_sg_alloc_ioctl] Jul 3 18:57:49 server kernel: [drm:pid72128:drm_sg_alloc] sg size=33554432 pages=8192 Jul 3 19:28:09 server kernel: [drm:pid72128:drm_ioctl] returning 12 [note the timestamps] Whilst drm_sg_alloc() allows non-contiguous allocation (the code just wants 8192 pages), bus_dma(9) states: The current implementation of bus_dmamem_alloc() will allocate all requests as a single segment. (and this is the same in 10-current). bus_dmamem_alloc() for a region greater than one page uses contigmalloc(). I believe that Xorg spinning in swwrt is a regression but I don't have a good idea for when it started (and http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061369.html suggests that it's been occurring for quite a while). For that matter contigmalloc() also seems to have a long history of causing problems with other parts of FreeBSD - I first crossed swords with it 7½ years ago (when it was causing panics in umass(4)). Previously, the work-around for contigmalloc() issues was to ensure that the appropriate contigmalloc() calls occurred shortly after a reboot - before RAM got too fragmented. That doesn't appear to work here because it looks like Xorg releases and (tries to) re-allocates the memory during a reset (ie on logout). It is a _serious_ nuisance having to reboot because I fumbled my password... Can anyone suggest a way forward? Note that additional RAM isn't an option for this box. How difficult would it be to modify bus_dmamem_alloc() [at least on x86] to handle multi-segment allocations? Does anyone have a tool that can display physical RAM allocation? This would at least allow me to identify offending allocations. http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/thread.html asks the same question but just peters out. -- Peter Jeremy pgpuclQzdFSg9.pgp Description: PGP signature
Re: contigmalloc() breaking Xorg
On 2012-Jul-03 21:17:53 +1000, Peter Jeremy pe...@rulingia.com wrote: Does anyone have a tool that can display physical RAM allocation? This would at least allow me to identify offending allocations. http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/thread.html asks the same question but just peters out. That link should be http://lists.freebsd.org/pipermail/freebsd-hackers/2011-February/034321.html sorry about the mis-paste. -- Peter Jeremy pgp1iwrLyMm1P.pgp Description: PGP signature
file version and libmagic
Hi Why do FreeBSD-9 use still file-5.3 ? whereas file-5.09 was ready to use with updated magic databases (was ready FreeBSD9 release date). Do you know why FreeBSD insist to use old magic databases ? thanks.. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On 07/02/2012 19:08, Robert Simmons wrote: Are there plans to pull the following into head before the code freeze for 9.1? BIND 9.9.1p1 We never change the version of BIND in a release branch. The 9.8 version that's there is up to date. The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav d...@des.no wrote: I don't think there will be as much whinging as you expect. Times have changed. Agreed; if we need DNS in base (really, why?) then unbound+nsd are prime candidates, but they're healthily maintained in ports...soo... no real advantage. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FreeBSD 10G forwarding performance @Intel
Hello list!
I'm quite stuck with bad forwarding performance on many FreeBSD boxes
doing firewalling.
Typical configuration is E5645 / E5675 @ Intel 82599 NIC.
HT is turned off.
(Configs and tunables below).
I'm mostly concerned with unidirectional traffic flowing to single
interface (e.g. using singe route entry).
In most cases system can forward no more than 700 (or 1400) kpps which
is quite a bad number (Linux does, say, 5MPPs on nearly the same hardware).
Test scenario:
Ixia XM2 (traffic generator) ix0 (FreeBSD).
Ixia sends 64byte IP packets from vlan10 (10.100.0.64 - 10.100.0.156) to
destinations in vlan11 (10.100.1.128 - 10.100.1.192).
Static arps are configured for all destination addresses.
Traffic level is slightly above or slightly below system performance.
= Test 1 ===
Kernel: FreeBSD-8-S r237994, stock drivers, stock routing, no FLOWTABLE,
no firewall
Traffic: 1-1 flow (1 src, 1 dst)
(This is actually a bit different from described above)
Result:
input (ix0) output
packets errs idrops bytespackets errs bytes colls
878k 48k 059M 878k 056M 0
874k 48k 059M 874k 056M 0
875k 48k 059M 875k 056M 0
16:41 [0] test15# top -nCHSIzs1 | awk '$5 ~ /(K|SIZE)/ { printf %7s
%2s %6s %10s %15s %s\n, $7, $8, $9, $10, $11, $12}'
STATE C TIMECPU COMMAND
CPU6 6 17:28100.00% kernel{ix0 que}
CPU9 9 20:42 60.06%intr{irq265: ix0:que
16:41 [0] test15# vmstat -i | grep ix0
irq256: ix0:que 0 500796167
irq257: ix0:que 16693573 2245
irq258: ix0:que 22572380862
irq259: ix0:que 33166273 1062
irq260: ix0:que 49691706 3251
irq261: ix0:que 5 10766434 3611
irq262: ix0:que 68933774 2996
irq263: ix0:que 75246879 1760
irq264: ix0:que 83548930 1190
irq265: ix0:que 9 11817986 3964
irq266: ix0:que 10227561 76
irq267: ix0:link 1 0
Note that system is using 2 cores to forward, so 12 cores should be able
to forward 4+ mpps which is more or less consistent with Linux results.
Note that interrupts on all queues are (as far as I understand from the
fact that AIM is turned off and interrupt rates are the same from
previous test). Additionally, despite hw.intr_storm_threshold = 200k,
i'm constantly getting
interrupt storm detected on irq265:; throttling interrupt source
message.
= Test 2 ===
Kernel: FreeBSD-8-S r237994, stock drivers, stock routing, no FLOWTABLE,
no firewall
Traffic: Unidirectional many-2-many
16:20 [0] test15# netstat -I ix0 -hw 1
input (ix0) output
packets errs idrops bytespackets errs bytes colls
507k 651k 074M 508k 032M 0
506k 652k 074M 507k 028M 0
509k 652k 074M 508k 037M 0
16:28 [0] test15# top -nCHSIzs1 | awk '$5 ~ /(K|SIZE)/ { printf %7s
%2s %6s %10s %15s %s\n, $7, $8, $9, $10, $11, $12}'
STATE C TIMECPU COMMAND
CPU10 6 0:40100.00% kernel{ix0 que}
CPU2 2 11:47 84.86%intr{irq258: ix0:que
CPU3 3 11:50 81.88%intr{irq259: ix0:que
CPU8 8 11:38 77.69%intr{irq264: ix0:que
CPU7 7 11:24 77.10%intr{irq263: ix0:que
WAIT 1 10:10 74.76%intr{irq257: ix0:que
CPU4 4 8:57 63.48%intr{irq260: ix0:que
CPU6 6 8:35 61.96%intr{irq262: ix0:que
CPU9 9 14:01 60.79%intr{irq265: ix0:que
RUN 0 9:07 59.67%intr{irq256: ix0:que
WAIT 5 6:13 43.26%intr{irq261: ix0:que
CPU11 11 5:19 35.89% kernel{ix0 que}
- 4 3:41 25.49% kernel{ix0 que}
- 1 3:22 21.78% kernel{ix0 que}
- 1 2:55 17.68% kernel{ix0 que}
- 4 2:24 16.55% kernel{ix0 que}
- 1 9:54 14.99% kernel{ix0 que}
CPU0 11 2:13 14.26% kernel{ix0 que}
16:07 [0] test15# vmstat -i | grep ix0
irq256: ix0:que 0 13654 15
irq257: ix0:que 1 87043 96
irq258: ix0:que 2 39604 44
irq259: ix0:que 3 48308 53
irq260: ix0:que 4 138002153
irq261: ix0:que 5 169596188
irq262: ix0:que 6 107679119
irq263: ix0:que 7 72769 81
irq264: ix0:que 8 30878 34
irq265: ix0:que 9
Re: FreeBSD 10G forwarding performance @Intel
On Tue, Jul 03, 2012 at 08:11:14PM +0400, Alexander V. Chernikov wrote: Hello list! I'm quite stuck with bad forwarding performance on many FreeBSD boxes doing firewalling. ... In most cases system can forward no more than 700 (or 1400) kpps which is quite a bad number (Linux does, say, 5MPPs on nearly the same hardware). among the many interesting tests you have run, i am curious if you have tried to remove the update of the counters on route entries. They might be another severe contention point. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On Jul 3, 2012, at 2:39 PM, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. DES -- Dag-Erling Smørgrav - d...@des.no +1 for unbound :-) -- /\ With kind regards,| re...@elvandar.org \ / Remko Lodder | re...@freebsd.org XFreeBSD| http://www.evilcoder.org / \ The Power to Serve| Quis custodiet ipsos custodes ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD 10G forwarding performance @Intel
On 03.07.2012 20:55, Luigi Rizzo wrote:
On Tue, Jul 03, 2012 at 08:11:14PM +0400, Alexander V. Chernikov wrote:
Hello list!
I'm quite stuck with bad forwarding performance on many FreeBSD boxes
doing firewalling.
...
In most cases system can forward no more than 700 (or 1400) kpps which
is quite a bad number (Linux does, say, 5MPPs on nearly the same hardware).
among the many interesting tests you have run, i am curious
if you have tried to remove the update of the counters on route
entries. They might be another severe contention point.
21:47 [0] m@test15 netstat -I ix0 -w 1
input (ix0) output
packets errs idrops bytespackets errs bytes colls
1785514 52785 0 1213183401784650 0 117874854 0
1773126 52437 0 1207014701772977 0 117584736 0
1781948 52154 0 1210601261778271 0 75029554 0
1786169 52982 0 1214511601787312 0 160967392 0
21:47 [0] test15# sysctl net.rt_count=0
net.rt_count: 1 - 0
1814465 22546 0 1213020761814291 0 76860092 0
1817769 14272 0 1209849221816254 0 163643534 0
1815311 13113 0 1208319701815340 0 120159118 0
1814059 13698 0 1207991321813738 0 120172092 0
1818030 13513 0 1209601401814578 0 120332662 0
1814169 14351 0 1208361821814003 0 120164310 0
Thanks, another good point. I forgot to merge this option from andre's
patch.
Another 30-40-50kpps to win.
+u_int rt_count = 1;
+SYSCTL_INT(_net, OID_AUTO, rt_count, CTLFLAG_RW, rt_count, 1, );
@@ -601,17 +625,20 @@ passout:
if (error != 0)
IPSTAT_INC(ips_odropped);
else {
- ro.ro_rt-rt_rmx.rmx_pksent++;
+ if (rt_count)
+ ro.ro_rt-rt_rmx.rmx_pksent++;
IPSTAT_INC(ips_forward);
IPSTAT_INC(ips_fastforward);
cheers
luigi
--
WBR, Alexander
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav d...@des.no wrote: I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. My only issue is that unbound is still a relatively young project (released 2007) and rapidly evolving. Unless the FreeBSD releases really pick up the pace it might be worse to have an older version in base. Just read the changelogs for the last year and you'll see what I mean. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD 10G forwarding performance @Intel
On Tue, Jul 03, 2012 at 09:37:38PM +0400, Alexander V. Chernikov wrote:
...
Thanks, another good point. I forgot to merge this option from andre's
patch.
Another 30-40-50kpps to win.
not much gain though.
What about the other IPSTAT_INC counters ?
I think the IPSTAT_INC macros were introduced (by rwatson ?)
following a discussion on how to make the counters per-cpu
and avoid the contention on cache lines.
But they are still implemented as a single instance,
and neither volatile nor atomic, so it is not even clear
that they can give reliable results, let alone the fact
that you are likely to get some cache misses.
the relevant macro is in ip_var.h.
Cheers
luigi
+u_int rt_count = 1;
+SYSCTL_INT(_net, OID_AUTO, rt_count, CTLFLAG_RW, rt_count, 1, );
@@ -601,17 +625,20 @@ passout:
if (error != 0)
IPSTAT_INC(ips_odropped);
else {
- ro.ro_rt-rt_rmx.rmx_pksent++;
+ if (rt_count)
+ ro.ro_rt-rt_rmx.rmx_pksent++;
IPSTAT_INC(ips_forward);
IPSTAT_INC(ips_fastforward);
cheers
luigi
--
WBR, Alexander
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD 10G forwarding performance @Intel
On 04.07.2012 00:27, Luigi Rizzo wrote:
On Tue, Jul 03, 2012 at 09:37:38PM +0400, Alexander V. Chernikov wrote:
...
Thanks, another good point. I forgot to merge this option from andre's
patch.
Another 30-40-50kpps to win.
not much gain though.
What about the other IPSTAT_INC counters ?
Well, we should then remove all such counters (total, forwarded) and
per-interface statistics (at least for forwarded packets).
I think the IPSTAT_INC macros were introduced (by rwatson ?)
following a discussion on how to make the counters per-cpu
and avoid the contention on cache lines.
But they are still implemented as a single instance,
and neither volatile nor atomic, so it is not even clear
that they can give reliable results, let alone the fact
that you are likely to get some cache misses.
the relevant macro is in ip_var.h.
Hm. This seems to be just per-vnet structure instance.
We've got some more real DPCPU stuff (sys/pcpu.h kern/subr_pcpu.c)
which can be used for global ipstat structure, however since it is
allocated from single area without possibility to free we can't use it
for per-interface counters.
I'll try to run tests without any possibly contested counters and report
the results on Thursday.
Cheers
luigi
+u_int rt_count = 1;
+SYSCTL_INT(_net, OID_AUTO, rt_count, CTLFLAG_RW,rt_count, 1, );
@@ -601,17 +625,20 @@ passout:
if (error != 0)
IPSTAT_INC(ips_odropped);
else {
- ro.ro_rt-rt_rmx.rmx_pksent++;
+ if (rt_count)
+ ro.ro_rt-rt_rmx.rmx_pksent++;
IPSTAT_INC(ips_forward);
IPSTAT_INC(ips_fastforward);
cheers
luigi
--
WBR, Alexander
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
--
WBR, Alexander
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On 07/03/2012 05:39, Dag-Erling Smørgrav wrote: Doug Barton do...@freebsd.org writes: The correct solution to this problem is to remove BIND from the base altogether, but I have no energy for all the whinging that would happen if I tried (again) to do that. I don't think there will be as much whinging as you expect. Times have changed. I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. You've got a deal! Unbound requires ldns, which is a good thing. Part of this project would also be to enable drill so that we have a command-line dns lookup tool in the base, but that's trivial once you've got ldns imported. After you get those 3 elements in the base I'm happy to pull BIND out by the roots. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD 10G forwarding performance @Intel
On Wed, Jul 04, 2012 at 12:31:56AM +0400, Alexander V. Chernikov wrote:
On 04.07.2012 00:27, Luigi Rizzo wrote:
On Tue, Jul 03, 2012 at 09:37:38PM +0400, Alexander V. Chernikov wrote:
...
Thanks, another good point. I forgot to merge this option from andre's
patch.
Another 30-40-50kpps to win.
not much gain though.
What about the other IPSTAT_INC counters ?
Well, we should then remove all such counters (total, forwarded) and
per-interface statistics (at least for forwarded packets).
I am not saying to remove them for good, but at least have a
try at what we can hope to save by implementing them
on a per-cpu basis.
There is a chance that one will not
see big gains util the majority of such shared counters
are fixed (there are probably 3-4 at least on the non-error
path for forwarded packets), plus the per-interface ones
that are not even wrapped in macros (see if_ethersubr.c)
I think the IPSTAT_INC macros were introduced (by rwatson ?)
following a discussion on how to make the counters per-cpu
and avoid the contention on cache lines.
But they are still implemented as a single instance,
and neither volatile nor atomic, so it is not even clear
that they can give reliable results, let alone the fact
that you are likely to get some cache misses.
the relevant macro is in ip_var.h.
Hm. This seems to be just per-vnet structure instance.
yes but essentially they are still shared by all threads within a vnet
(besides you probably ran your tests in the main instance)
We've got some more real DPCPU stuff (sys/pcpu.h kern/subr_pcpu.c)
which can be used for global ipstat structure, however since it is
allocated from single area without possibility to free we can't use it
for per-interface counters.
yes, those should be moved to a private, dynamically allocated
region of the ifnet (the number of CPUs is known at driver init
time, i hope). But again for a quick test disabling the
if_{i|o}{bytesC|packets} should do the job, if you can count
the received rate by some other means.
I'll try to run tests without any possibly contested counters and report
the results on Thursday.
great, that would be really useful info.
cheers
luigi
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On 07/03/2012 06:36, Mark Felder wrote: On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav d...@des.no wrote: I don't think there will be as much whinging as you expect. Times have changed. Agreed; if we need DNS in base (really, why?) then unbound+nsd are prime candidates, but they're healthily maintained in ports...soo... no real advantage. We should not put nsd in the base. There is no need for an authoritative server in the base, the only reason BIND is there is that it is also a resolver, and, of course, hysterical raisins. The dream scenario is one we've discussed in the past: 1. Promote certain ports to system status, with more stringent requirements for both the ports, and the maintainers. 2. Re-tool the installer to give the users choice of which (if any) of the key system components get installed. Obvious choices for this category are the perennial favorites of DNS (resolver) and mail, reasonable arguments can be made for others of course. Whether we do the above or not, ldns/drill should be imported into the base so that we have at least one command line DNS resolution tool. A good junior hacker project would be to make a host(1) clone using ldns. If users want the regular bind tools, ports/dns/bind-tools already exists. Given it's unlikely that actually making the installer more modular will happen before 10-RELEASE, importing unbound is the next best alternative. And regarding the it's a young project issue, I've followed their development closely, I know the people involved, and I've used it for some projects. I have zero hesitation. And for those who are unclear on the problem we're trying to solve, a quick recap. As things have evolved over time the BIND release cycles and ours have diverged. Since we don't update the version of BIND in the base for POLA reasons, for FreeBSD 6, and now 7, this has led to a situation where our oldest release has an unsupported version of BIND. Clearly this is unacceptable. Oh, and to anticipate the traditional zomg! don't turn freebsd into linux!!!11!!! response: First, just because linux does something doesn't make it wrong, and Second, we can definitely add a *little* more modularity (which the users have been asking for as long as I can remember) without turning into linux. And finally, to address the why have a resolver on the system at all? question, one word: DNSSEC. At this time there is no good solution to the problem of the local host system being able to validate a DNSSEC response. The only viable solution _at this time_ is to have a local, validating resolver. (Of course, other solutions are being worked on, but they aren't here yet.) This will become much more important over time as DNSSEC adoption increases, and more things begin to use it (like DANE). Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: file version and libmagic
Why do FreeBSD-9 use still file-5.3 ? whereas file-5.09 was ready to use with updated magic databases (was ready FreeBSD9 release date). Do you know why FreeBSD insist to use old magic databases ? FreeBSD doesn't insist on the use of old versions of file -- it is just that no committer imported the new version into the base system during the time that FreeBSD 9.0 was being developed and tested. (This may have been partly influenced by the discovery of several security problems in newer versions of file, but it is more likely that the committer that usually maintains file in the base system was simply preoccupied with other matters.) You could have requested an import during that time, if you were interested. file 5.11 was recently imported into -CURRENT and 9-STABLE, so it should be in the next 9-* and 10-* releases. In the meantime, you may use ports/sysutils/file from FreeBSD Ports. Incidentally, it is more appropriate to send an inquiry of this kind to the freebsd-stable mailing list, rather than to freebsd-hackers. b. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nvidia-driver-295.49 is highly unstable
On 05/27/2012 13:08, Alexey Dokuchaev wrote: Perhaps you can try asking on official nVidia FreeBSD forum: http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 I reported there 05-28-12, but got no response. Do you know if there is a way to report a problem with NVidia? For example, is there a for example bugzilla or other bug reporting system for this? In addition, I observe system hangup for a few seconds when running glxinfo. Also I observe Xorg freeze when I run nvidia-settings. So I have to run 285.05.09 from cvs instead. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nvidia-driver-295.49 is highly unstable
On Tue, Jul 03, 2012 at 08:20:49PM -0700, Yuri wrote: On 05/27/2012 13:08, Alexey Dokuchaev wrote: Perhaps you can try asking on official nVidia FreeBSD forum: http://www.nvnews.net/vbulletin/forumdisplay.php?f=47 I reported there 05-28-12, but got no response. That's very sad indeed. Do you know if there is a way to report a problem with NVidia? For example, is there a for example bugzilla or other bug reporting system for this? Unfortunately, I am not aware of such thing being exposed to the public. Forum is the closest thing that comes to mind. Individual developers can probably be contacted privately, but AFAICT they all read forum pretty regularly, so it makes little sense to spam them directly. In addition, I observe system hangup for a few seconds when running glxinfo. Also I observe Xorg freeze when I run nvidia-settings. So I have to run 285.05.09 from cvs instead. Do these issues persist with 295.59, latest long lived branch version? ./danfe ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
