Re: nvidia-driver-295.49 is highly unstable
On Jul 3, 2012, at 8:20 PM, 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. > 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? ... There isn't an official means to do this (maybe due to resource constraints), but word of warning: they ban people that nag too much about the "right" topics. Thanks, -Garrett___ 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"
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: 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: 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 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: 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 05:39, Dag-Erling Smørgrav wrote: > Doug Barton 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 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: 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: Pull in upstream before 9.1 code freeze?
On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav 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 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 Jul 3, 2012, at 2:39 PM, Dag-Erling Smørgrav wrote: > Doug Barton 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 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"
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
Re: Pull in upstream before 9.1 code freeze?
On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav 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"
Re: Pull in upstream before 9.1 code freeze?
Doug Barton 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 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"
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: contigmalloc() breaking Xorg
On 2012-Jul-03 21:17:53 +1000, Peter Jeremy 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
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: Pull in upstream before 9.1 code freeze?
Robert Simmons 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"