Re: why 100 packages are evil
On 25/04/2016 08:39, Miroslav Lachman wrote: Gerrit Kühn wrote on 04/25/2016 07:48: On Sat, 23 Apr 2016 18:52:32 +0100 Matthew Seaman wrote about Re: why 100 packages are evil: MS> > Is freebsd-update going away as result of the new packaging ? Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that's the plan for 11.0-RELEASE. Hm... I never had any troubles with freebsd-update, it always "just worked" for me. OTOH, I remember having several issues with pkg, requiring to fix databases manually and so on. I had many issues with freebsd-update in the past so the last year I converted all machines back to "installkernel & installworld" from NFS mounted build server. It is faster and predictable than freebsd-update (in my case). I hope that pkg upgrade will be good replacement one day. But I don't think it is good enough right now. Miroslav Lachman As another useless datapoint - I've not had any real issues with freebsd-update and I've been using it since 6.x, same with pkg(ng) after the initial bugs were ironed out, this is on 30-40 production servers. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bay Trail 32bit UEFI
On 02/03/2016 19:45, Lundberg, Johannes wrote: On Wed, Mar 2, 2016 at 11:37 AM, Jakob Alvermark mailto:ja...@alvermark.net>> wrote: On Wed, March 2, 2016 20:00, Lundberg, Johannes wrote: > On Wed, Mar 2, 2016 at 2:10 AM, Joe Holden mailto:m...@m.jwh.me.uk>> wrote: > > >> On 02/03/2016 01:45, Lundberg, Johannes wrote: >> >> >>> CherryTrail devices/boards with 64bit UEFI are already out. Upgrading >>> the hardware is one solution (I did). >>> >>> I'm thinking of the sticks etc, they all have 32bit UEFI and no >>> >> CSM/legacy boot, but have 64bit cpus >> > > > > Yeah and it sucks. All to adapt to Microsoft who couldn't make 64bit UEFI > boot loader in time (or so I heard)... I heard though that newer (Linux) > versions of Intel Compute Stick would have 64bit UEFI but I'm not sure. The Intel Compute sticks can boot both 32 and 64 bit. It doesn't matter if you have the Windows or Linux version. (The difference between the is the amount of RAM and onboard storage, the firmware is the same) I have the Windows one and it boots 64 bit just fine. You can select it in the settings. (OS setting: Windows=32 bit, Linux=64 bit) That's great. However, as for all other BayTrail devices out there that does not support Linux officially I think you're stuck with 32bit. Jakob My point was that it is possible to boot amd64 bit kernels from 32bit UEFI, grub (and therefore, linux) does it. I think even openbsd at least has a 32bit loader, I'd settle for 32bit but the problem is I can't easily boot it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bay Trail 32bit UEFI
On 02/03/2016 01:45, Lundberg, Johannes wrote: CherryTrail devices/boards with 64bit UEFI are already out. Upgrading the hardware is one solution (I did). I'm thinking of the sticks etc, they all have 32bit UEFI and no CSM/legacy boot, but have 64bit cpus I never did try FreeBSD on BayTrail but for running Linux on BayTrail I used special built Grub that was 32bit but could load 64bit OS. Could this kind of Grub boot a 64bit FreeBSD, I wonder? I looked at this but honestly it looked like a giant nightmare - I did get grub loading on a test platform (tablet, for display etc) but didn't manage to make it boot anything On Tue, Mar 1, 2016 at 5:20 PM, John Baldwin mailto:j...@freebsd.org>> wrote: On Sunday, February 28, 2016 07:00:06 AM Joe Holden wrote: > Hi all, > > Apologies if this is the wrong list... > > Is there any plan to support booting FreeBSD on 32bit UEFI systems (with > or without 64bit kernel/userland)? Obviously there is no i386 efi loader > currently so neither is possible... I don't think anyone is actively working on it. I think it shouldn't be that much work once the i386 loader is resurrected. The i386 kernel just needs to use the EFI memory map and I think the rest of it should generally just work. -- John Baldwin ___ freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org <mailto:freebsd-current-unsubscr...@freebsd.org>" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Bay Trail 32bit UEFI
Hi all, Apologies if this is the wrong list... Is there any plan to support booting FreeBSD on 32bit UEFI systems (with or without 64bit kernel/userland)? Obviously there is no i386 efi loader currently so neither is possible... TIA, J ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVE-2015-7547: critical bug in libc
On 22/02/2016 00:04, Chris H wrote: On Thu, 18 Feb 2016 08:39:32 -0600 (CST) Dan Mack wrote On Thu, 18 Feb 2016, Joe Holden wrote: On 17/02/2016 14:07, Daniel Kalchev wrote: On 17.02.2016 ?., at 15:40, Shawn Webb wrote: >>> TL;DR: FreeBSD is not affected by CVE-2015-7547. Unless you use Linux applications under emulation. Daniel Which is supported by ports so at most it should be a ports advisory and not a FreeBSD (base) SA and therefore not on the website. Just my 2p ;) Documenting and putting out security advisiories for other operating systems seems like a bad precedent in general. The same could be said for runniing java applications, windows under bhyve, etc. - *sigh* - if the cross over use is common via a port, then have the port maybe remind users to consult their distribution specific security vulnerabilites prior to running it maybe - which is what they should be doing anyway. That's my two insignificant cents :-) Dan If Sell distributes a bad batch of gasoline. It's not Chevrolet's responsibility to inform it's car buyers/owners, that Shell produced a bad batch of gasoline. Is it? :) --Chris Exactly, however it is done now so nevermind ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVE-2015-7547: critical bug in libc
On 17/02/2016 14:07, Daniel Kalchev wrote: On 17.02.2016 г., at 15:40, Shawn Webb wrote: TL;DR: FreeBSD is not affected by CVE-2015-7547. Unless you use Linux applications under emulation. Daniel Which is supported by ports so at most it should be a ports advisory and not a FreeBSD (base) SA and therefore not on the website. Just my 2p ;) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd replacement (Was: Re: Import of DragonFly Mail Agent)
On 24/02/2014 15:40, Poul-Henning Kamp wrote: In message <530b666a.1000...@rewt.org.uk>, Joe Holden writes: Please check how NTP is authenticated before giving bad advice, it's all in the RFC. v3 or v4? It is an optional part of the spec in both cases and again isn't required for 99% of people using ntpd as a client, which was the entire point of this exercise in the first place. Authentication of NTP is rapidly gaining focus these days, for obvious reasons, so I think adopting software now which don't support it would be needlessly shortsighted. 3 years ago I would have agree with you, but not now. Fair enough, that isn't the real problem we are facing but rather than derail this thread even further I think it would be best to discuss that another day :) ___ 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: ntpd replacement (Was: Re: Import of DragonFly Mail Agent)
On 24/02/2014 13:52, Poul-Henning Kamp wrote: In message <530b2dee.3030...@rewt.org.uk>, Joe Holden writes: The other point I should make here is that if you care that much about time security you shouldn't be contacting ntp servers over 3rd party networks anyway, at least not without some IP-level encryption/authentication, or use a source that can't easily be used as an attack surface, such as GPS/MSF etc. Please check how NTP is authenticated before giving bad advice, it's all in the RFC. v3 or v4? It is an optional part of the spec in both cases and again isn't required for 99% of people using ntpd as a client, which was the entire point of this exercise in the first place. If the argument is that X feature is missing then we may as well replace sendmail with exim as it has even more features, for example. But most importantly, explain how it was bad advice? There are provisions for integrity checking (not authentication) and autokey. My point was that if you need to authenticate ntp to avoid mitm-style attacks then perhaps the setup you have is wrong. If there is something huge I have missed then feel free to correct me! ___ 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: ntpd replacement (Was: Re: Import of DragonFly Mail Agent)
On 24/02/2014 11:26, Joe Holden wrote: On 24/02/2014 11:18, Ollivier Robert wrote: According to Joe Holden on Mon, Feb 24, 2014 at 11:13:23AM +: hm, I can't say I have noticed this as being a problem where I've used it, are there any scenarios where this is a showstopper? Non-support for auth is a concern, lack of NTPv4 protocol support is another. Base ntpd also include SNTP which is a lightweight NTPv3 client. I suspect if you can't be reasonably sure about the integrity of your network traffic you have other problems anyway... one can run ntpd -s to get a similar function to ntpdate/sntp. But again, for 99% of installs as a client, auth and/or ntpv4 doesn't matter and much like sendmail/dma, one can always install ntp.org from ports if they require authentication (I've never seen it used). The other point I should make here is that if you care that much about time security you shouldn't be contacting ntp servers over 3rd party networks anyway, at least not without some IP-level encryption/authentication, or use a source that can't easily be used as an attack surface, such as GPS/MSF etc. ___ 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: ntpd replacement (Was: Re: Import of DragonFly Mail Agent)
On 24/02/2014 11:18, Ollivier Robert wrote: According to Joe Holden on Mon, Feb 24, 2014 at 11:13:23AM +: hm, I can't say I have noticed this as being a problem where I've used it, are there any scenarios where this is a showstopper? Non-support for auth is a concern, lack of NTPv4 protocol support is another. Base ntpd also include SNTP which is a lightweight NTPv3 client. I suspect if you can't be reasonably sure about the integrity of your network traffic you have other problems anyway... one can run ntpd -s to get a similar function to ntpdate/sntp. But again, for 99% of installs as a client, auth and/or ntpv4 doesn't matter and much like sendmail/dma, one can always install ntp.org from ports if they require authentication (I've never seen it used). ___ 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: Import of DragonFly Mail Agent
On 24/02/2014 11:08, Baptiste Daroussin wrote: On Mon, Feb 24, 2014 at 11:04:48AM +, Joe Holden wrote: On 24/02/2014 10:56, Poul-Henning Kamp wrote: In message <530b2500.5030...@rewt.org.uk>, Joe Holden writes: Can I also suggest that ntp.org shouldn't be in the base either? :P I absolutely agree, but the replacement is less clear in that case. I'd suggest openntpd as a candidate as it would require less work than dntpd since that has some kernel changes. At ~400K it is pretty lightweight and doesn't listen at all by default, suitable as a default ntpd that just maintains time - one can always install ntp.org from ports should they need more features (such as access control and monlist, etc) openntpd not able to authenticate the sources it is using and thus lack a big ntp feature as a client. regards, Bapt hm, I can't say I have noticed this as being a problem where I've used it, are there any scenarios where this is a showstopper? ___ 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: Import of DragonFly Mail Agent
On 24/02/2014 10:56, Poul-Henning Kamp wrote: In message <530b2500.5030...@rewt.org.uk>, Joe Holden writes: Can I also suggest that ntp.org shouldn't be in the base either? :P I absolutely agree, but the replacement is less clear in that case. I'd suggest openntpd as a candidate as it would require less work than dntpd since that has some kernel changes. At ~400K it is pretty lightweight and doesn't listen at all by default, suitable as a default ntpd that just maintains time - one can always install ntp.org from ports should they need more features (such as access control and monlist, etc) ___ 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: Import of DragonFly Mail Agent
On 24/02/2014 10:00, Baptiste Daroussin wrote: On Mon, Feb 24, 2014 at 09:56:05AM +, Poul-Henning Kamp wrote: In message <530b13ca.6000...@rewt.org.uk>, Joe Holden writes: On 24/02/2014 04:26, Julio Merino wrote: On Sun, Feb 23, 2014 at 4:11 PM, Baptiste Daroussin wrote: As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. I'd argue, for example, that postfix can be also easily configured and can be made to not listen on port 25 for local mail delivery, while at the same time it is a fully-functional MTA that could replace sendmail altogether. The trend towards having sensible lightweight things in the base is a good thing IMO. Fully agree. To the extent we can manage it, we should have minimal client-focused tools for things like DNS, SMTP and NTP in the tree and make it trivial for people to install the fully featured server version of their choice from ports. That's is what I'm doing with dma :) you want a full featured smtp server: pkg install ${FAVORITESMTP:-opensmtpd} regards, Bapt Can I also suggest that ntp.org shouldn't be in the base either? :P ___ 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: Import of DragonFly Mail Agent
On 24/02/2014 04:26, Julio Merino wrote: On Sun, Feb 23, 2014 at 4:11 PM, Baptiste Daroussin wrote: Hi, As some of you may have noticed, I have imorted a couple of days ago dma (DragonFly Mail Agent) in base. I have been asked to explain my motivation so here they are. DragonFly Mail Agent is a minimalistic mailer that is able to relay mails to some smtp servers (with TLS, authentication and so on) It supports MASQUERADE and NULLCLIENT, and is able to deliver mails locally (respecting aliases). I imported it because dma is lightweight, BSD license and easy to use. The code base is rather small and easy to capsicumize (which I plan to do) My initial goal is not to replace sendmail. But is it an eventual goal? *I* don't see why not, but if it is: what's the plan? How is the decision to drop sendmail going to be made when the time comes? (I.e. who _can_ and will make the call?) All I want is a small mailer simple to configure, and not listening to port 25, suitable for small environment (embedded and/or resource bounded) as well as for server deployment. Playing devil's advocate: what specific problems is this trying to solve? I'd argue, for example, that postfix can be also easily configured and can be made to not listen on port 25 for local mail delivery, while at the same time it is a fully-functional MTA that could replace sendmail altogether. (Which, by the way, is the configuration with which postfix ships within the NetBSD base system.) The reason I'm asking these questions is because I have seen NetBSD maintain two MTAs (sendmail + postfix) in the base system for _years_ and it was not a pretty situation. The eventual removal of sendmail was appreciated, but of course it came with the associated bikeshedding. *dons flame-proof suit* The trend towards having sensible lightweight things in the base is a good thing IMO. There is no need for things like bind (replaced by unbound), or a full featured mta like sendmail in the base, base install should contain enough to get going but for specific functions like performing MTA tasks, the user can install the appropriate software, such as postfix. Just my 2p :) ___ 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: how do i cross build world/kernel with clang?
Doh should have checked the thread before sending - is there any news on this? > -Original Message- > From: owner-freebsd-m...@freebsd.org [mailto:owner-freebsd- > m...@freebsd.org] On Behalf Of Joe Holden > Sent: 15 September 2013 23:28 > To: 'Adrian Chadd'; 'freebsd-current'; freebsd-m...@freebsd.org > Subject: RE: how do i cross build world/kernel with clang? > > Are you still playing with this? Reason I ask is that I tried to build world with > clang for the crack and it bails with: > > /usr/obj/mips.mips64/pseudosrc/tmp/usr/bin/ld: > /usr/obj/mips.mips64/pseudosrc/tmp/usr/lib/crtn.o: warning: linking PIC > files with non-PIC files > exect.So: In function `exect': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > setjmp.So: In function `botch': > (.text+0x124): relocation truncated to fit: R_MIPS_PC16 against `abort' > _setjmp.So: In function `botch': > (.text+0xac): relocation truncated to fit: R_MIPS_PC16 against `abort' > _sigwait.So: In function `err': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > _getlogin.So: In function `err': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > aio_mlock.So: In function `err': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > pipe2.So: In function `err': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > accept4.So: In function `err': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > chflagsat.So: In function `err': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > connectat.So: In function `err': > (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' > bindat.So: In function `err': > (.text+0x18): additional relocation overflows omitted from the output > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 > > Built on HEAD amd64 as of a few hours ago... > > Cheers > Joe > > > -Original Message- > > From: owner-freebsd-m...@freebsd.org [mailto:owner-freebsd- > > m...@freebsd.org] On Behalf Of Adrian Chadd > > Sent: 01 September 2013 03:30 > > To: freebsd-current; freebsd-m...@freebsd.org > > Subject: how do i cross build world/kernel with clang? > > > > Hi! > > > > How do i cross-build a mips world/kernel with clang? > > > > ie, how do I tell the build system to build a mips targetted clang > > instead > of gcc > > and use that to build everything? > > > > Thanks, > > > > > > -adrian > > ___ > > freebsd-m...@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > > To unsubscribe, send any mail to "freebsd-mips-unsubscr...@freebsd.org" > > > ___ > freebsd-m...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscr...@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: how do i cross build world/kernel with clang?
Are you still playing with this? Reason I ask is that I tried to build world with clang for the crack and it bails with: /usr/obj/mips.mips64/pseudosrc/tmp/usr/bin/ld: /usr/obj/mips.mips64/pseudosrc/tmp/usr/lib/crtn.o: warning: linking PIC files with non-PIC files exect.So: In function `exect': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' setjmp.So: In function `botch': (.text+0x124): relocation truncated to fit: R_MIPS_PC16 against `abort' _setjmp.So: In function `botch': (.text+0xac): relocation truncated to fit: R_MIPS_PC16 against `abort' _sigwait.So: In function `err': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' _getlogin.So: In function `err': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' aio_mlock.So: In function `err': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' pipe2.So: In function `err': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' accept4.So: In function `err': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' chflagsat.So: In function `err': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' connectat.So: In function `err': (.text+0x18): relocation truncated to fit: R_MIPS_PC16 against `__cerror' bindat.So: In function `err': (.text+0x18): additional relocation overflows omitted from the output clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Built on HEAD amd64 as of a few hours ago... Cheers Joe > -Original Message- > From: owner-freebsd-m...@freebsd.org [mailto:owner-freebsd- > m...@freebsd.org] On Behalf Of Adrian Chadd > Sent: 01 September 2013 03:30 > To: freebsd-current; freebsd-m...@freebsd.org > Subject: how do i cross build world/kernel with clang? > > Hi! > > How do i cross-build a mips world/kernel with clang? > > ie, how do I tell the build system to build a mips targetted clang instead of gcc > and use that to build everything? > > Thanks, > > > -adrian > ___ > freebsd-m...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscr...@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: route get fails
On 24/08/2013 13:30, Kimmo Paasiala wrote: On Sat, Aug 24, 2013 at 2:42 PM, Pawel Pekala wrote: Hi, For some time now I get this: [corn:~]> route get route: writing to routing socket: Invalid argument Is this just my build or anyone can confirm this? -- pozdrawiam / with regards Paweł Pękala Nothing wrong there, you're not providing a required argument that is the destination IP address. In my opinion route(8) should return a proper error message in this case. OS X route(8) behaves exactly the same BTW. -Kimmo You probably want netstat -rnfinet[6] here, judging from your surprise that 'route get' returns the above. ___ 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: It's not as annoying as you may think.
Install Windows, OSS is not suitable for audio production, except maybe at a push, OS X. Super Bisquit wrote: I can't use the SoundBlaster PCI card on the laptop. Also, I need to be able to switch between the FreeBSD sound drivers and OSS drivers. What do I need to do to the kernel configuration file to allow this? Some ports will build with GCC and others with clang. What is the switch/command argument in make to allow this? I am very much aware of the capabilities of the processors and what works best on them. Effects such as loops are repetitive and that works just fine for the RISC load-store mechanism on Power 32 and 64 bit architectures. I do not currently have a PS3. The set up is for a friend who is not able to afford all of those great programs. I have spare machines. I am aware of and have used a lot of sound, audio, and conversion programs. On Fri, May 3, 2013 at 11:35 PM, Michael Copeland < mich...@kryptos-security.com> wrote: Well the last I checked, clang was still busted on ppc32. YMMV. I still don't think you're gonna get much use out of a ppc machine for any form of effects unless you're just talking about using it as an equalizer. For that matter, you could do almost all of it on the i386 laptop. Why do you need to add in so many machines for this? For the record, you're not going to get any form of realtime audio effects from that ppc machine, unless you're running an old version of garage band from 10.5.8 on it, even then it's not going to be quick. If you're hellbent on using a ppc machine, get a ps3 for that purpose. ___ 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" ___ 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: ipfilter(4) needs maintainer
wishmaster wrote: --- Original message --- From: "Gary Palmer" Date: 14 April 2013, 19:06:59 On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. Cheers, For non-nat ipfw is still superior in every way, numbered rules (think: scripts), dummynet, much faster than pf, syntax is a lot nicer and predictable... Does anyone even use ipf? it doesn't even work on Linux anymore, junk it and keep pf+ipfw, job done. ___ 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: Dynamic Ticks/HZ
Joe Holden wrote: Luigi Rizzo wrote: On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote: Luigi Rizzo wrote: On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote: On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote: doh, running kernel wasn't as GENERIC as I thought it was, looks like device polling not only breaks dynamic ticks but also reduces rx ability significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without Is this a known issue? (and if device polling isn't as useful as it once was, should it be removed?) Device polling on modern multiqueue NICs isn't very useful because you're limited to a single thread for handling packets. I have a patch that fixes this that I've let fall by the wayside. the 150,000 is result of the combination of the default value of sysctl kern.polling.burst_max and kern.polling.idle_poll=0 (i think this is the default value for the latter). The 150 was sized for the peak pps on a 100Mbit/s interface, back in 2001. You should at least be able to raise the number and see what kind of throughput you can achieve. This said, modern nics also have interrupt moderation so you don't really need polling. cheers luigi Hi Luigi, This makes sense, am I likely to achieve better throughput (in the forwarding path at this point) with netisr rather than polling, especially as mentioned above the igb does indeed have multiple queues for rx? at 1Gbit/s you probably don't need multiqueue (I am actually surpised you can only do 650kpps, but perhaps because you are using ipfw and not just doing plain forwarding ?) On another note, is netmap usable in the forwarding context at all as it is rather awesome It depends on what you need to do. If you have a v4/v6 router you won't see any advantage (at the moment; there is some work in the pipeline but probably it won't be available before spring). If you just need to implement a firewall to protect the internal network then it is another story and you can use the ipfw on netmap that I posted in august. cheers luigi Hi, I have a setup where box1 is connected directly to box2 (igb0), with pkt-gen however box2 doesn't seem to actually forward any packets, sysctl -ip 1 shows 1.48Mpps unreachables generated (matching the input), is there something specific I need to do to test forwarding? Thanks, Joe Nevermind, didn't set destination MAC addr, apologies for the noise! ___ 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: Dynamic Ticks/HZ
Luigi Rizzo wrote: On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote: Luigi Rizzo wrote: On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote: On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote: doh, running kernel wasn't as GENERIC as I thought it was, looks like device polling not only breaks dynamic ticks but also reduces rx ability significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without Is this a known issue? (and if device polling isn't as useful as it once was, should it be removed?) Device polling on modern multiqueue NICs isn't very useful because you're limited to a single thread for handling packets. I have a patch that fixes this that I've let fall by the wayside. the 150,000 is result of the combination of the default value of sysctl kern.polling.burst_max and kern.polling.idle_poll=0 (i think this is the default value for the latter). The 150 was sized for the peak pps on a 100Mbit/s interface, back in 2001. You should at least be able to raise the number and see what kind of throughput you can achieve. This said, modern nics also have interrupt moderation so you don't really need polling. cheers luigi Hi Luigi, This makes sense, am I likely to achieve better throughput (in the forwarding path at this point) with netisr rather than polling, especially as mentioned above the igb does indeed have multiple queues for rx? at 1Gbit/s you probably don't need multiqueue (I am actually surpised you can only do 650kpps, but perhaps because you are using ipfw and not just doing plain forwarding ?) On another note, is netmap usable in the forwarding context at all as it is rather awesome It depends on what you need to do. If you have a v4/v6 router you won't see any advantage (at the moment; there is some work in the pipeline but probably it won't be available before spring). If you just need to implement a firewall to protect the internal network then it is another story and you can use the ipfw on netmap that I posted in august. cheers luigi Hi, I have a setup where box1 is connected directly to box2 (igb0), with pkt-gen however box2 doesn't seem to actually forward any packets, sysctl -ip 1 shows 1.48Mpps unreachables generated (matching the input), is there something specific I need to do to test forwarding? Thanks, Joe ___ 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: Dynamic Ticks/HZ
Luigi Rizzo wrote: On Mon, Nov 05, 2012 at 04:25:36PM +, Joe Holden wrote: Luigi Rizzo wrote: On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote: On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote: doh, running kernel wasn't as GENERIC as I thought it was, looks like device polling not only breaks dynamic ticks but also reduces rx ability significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without Is this a known issue? (and if device polling isn't as useful as it once was, should it be removed?) Device polling on modern multiqueue NICs isn't very useful because you're limited to a single thread for handling packets. I have a patch that fixes this that I've let fall by the wayside. the 150,000 is result of the combination of the default value of sysctl kern.polling.burst_max and kern.polling.idle_poll=0 (i think this is the default value for the latter). The 150 was sized for the peak pps on a 100Mbit/s interface, back in 2001. You should at least be able to raise the number and see what kind of throughput you can achieve. This said, modern nics also have interrupt moderation so you don't really need polling. cheers luigi Hi Luigi, This makes sense, am I likely to achieve better throughput (in the forwarding path at this point) with netisr rather than polling, especially as mentioned above the igb does indeed have multiple queues for rx? at 1Gbit/s you probably don't need multiqueue (I am actually surpised you can only do 650kpps, but perhaps because you are using ipfw and not just doing plain forwarding ?) No ipfw/dummynet (yet), I've been testing by using netblast, may just be tx limit of this machine - rebuilding with netmap so I can use pkt-gen On another note, is netmap usable in the forwarding context at all as it is rather awesome It depends on what you need to do. If you have a v4/v6 router you won't see any advantage (at the moment; there is some work in the pipeline but probably it won't be available before spring). If you just need to implement a firewall to protect the internal network then it is another story and you can use the ipfw on netmap that I posted in august. cheers luigi ___ 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: Dynamic Ticks/HZ
Alexander Motin wrote: Hi. Full interrupt rate on some CPU means that your system is not idle, but running some process. Another possibility is that you have DUMMYNET compiled into your kernel, which tends to schedule callout for every HZ tick, effectively blocking skipping interrupts for one of CPUs. Check 'top -SH' for running processes, or 'top -SH -m io -o vcsw' for processes doing a lot of context switches. That most likely should give an answer. Hi, It looks like the device polling is what was causing it, once I'd removed that from kernconf it returned to normal - full interupt rate is ok though if I can increase the rate to a decent level ___ 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: Dynamic Ticks/HZ
Luigi Rizzo wrote: On Mon, Nov 05, 2012 at 08:11:41AM -0500, Ryan Stone wrote: On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden wrote: doh, running kernel wasn't as GENERIC as I thought it was, looks like device polling not only breaks dynamic ticks but also reduces rx ability significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without Is this a known issue? (and if device polling isn't as useful as it once was, should it be removed?) Device polling on modern multiqueue NICs isn't very useful because you're limited to a single thread for handling packets. I have a patch that fixes this that I've let fall by the wayside. the 150,000 is result of the combination of the default value of sysctl kern.polling.burst_max and kern.polling.idle_poll=0 (i think this is the default value for the latter). The 150 was sized for the peak pps on a 100Mbit/s interface, back in 2001. You should at least be able to raise the number and see what kind of throughput you can achieve. This said, modern nics also have interrupt moderation so you don't really need polling. cheers luigi Hi Luigi, This makes sense, am I likely to achieve better throughput (in the forwarding path at this point) with netisr rather than polling, especially as mentioned above the igb does indeed have multiple queues for rx? On another note, is netmap usable in the forwarding context at all as it is rather awesome Thanks, Joe ___ 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: Dynamic Ticks/HZ
Davide Italiano wrote: On Nov 4, 2012 10:40 PM, "Joe Holden" wrote: Davide Italiano wrote: On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden wrote: Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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" Which is your refresh rate for systat? I generally measure sampling every one second (i.e. systat -vm 1). Also, are you making your measurements when the system is idle? In order to trace the source(s) of these interrupts you might consider to collect data via KTR. I'm also using a one second refresh rate, the system is entirely idle and the interupt rate is almost entirely static at 1127, occasionally it will drop to 1119. From what I understand the timer is hz/ticks which became dynamic in 9.0, although that behaviour doesn't appear to be in HEAD anymore, at least on this hardware. Thanks, J It should be available, AFAIK. As I can see from your previous post you get about 20 interrupts on cpu1. This number is about 1/100 of the value you get on a !tickless kernel. If you provide the required ktr infos, probably someone will take a look. doh, running kernel wasn't as GENERIC as I thought it was, looks like device polling not only breaks dynamic ticks but also reduces rx ability significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without Is this a known issue? (and if device polling isn't as useful as it once was, should it be removed?) ___ 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: Dynamic Ticks/HZ
Davide Italiano wrote: On Mon, Nov 5, 2012 at 7:12 AM, Joe Holden wrote: Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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" Which is your refresh rate for systat? I generally measure sampling every one second (i.e. systat -vm 1). Also, are you making your measurements when the system is idle? In order to trace the source(s) of these interrupts you might consider to collect data via KTR. I'm also using a one second refresh rate, the system is entirely idle and the interupt rate is almost entirely static at 1127, occasionally it will drop to 1119. From what I understand the timer is hz/ticks which became dynamic in 9.0, although that behaviour doesn't appear to be in HEAD anymore, at least on this hardware. Thanks, J ___ 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"
Dynamic Ticks/HZ
Hi guys, Has some default changed between 9.1-RC2 and HEAD? On identical machines, one with 9.1-RC2 and one with HEAD from yesterday (GENERIC) I see the following in systat -v: 9.1: 65 cpu0:timer 10 cpu1:timer HEAD: 1127 cpu0:timer 22 cpu1:timer These are Supermicro i3 boxes and as far as I can see they have matching BIOS config. Thanks, J ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
Arnaud Lacombe wrote: Hi, On Thu, Dec 15, 2011 at 2:32 AM, O. Hartmann wrote: Just saw this shot benchmark on Phoronix dot com today: http://www.phoronix.com/scan.php?page=news_item&px=MTAyNzA it might be worth highlighting that despite Oracle Linux 6.1 Server is using a kernel + compiler almost 2 years old, it still manages to out-perform the bleeding edge FreeBSD :-) serenity# gcc --version gcc (GCC) 4.2.1 20070831 patched [FreeBSD] serenity# uname -r 9.0-RC3 Now, from what I've read so far in this thread, it seems that a lot of people are still in abnegation... my 0.2c, - Arnaud It may be worth to discuss the sad performance of FBSD in some parts of the benchmark. A difference of a factor 10 or 100 is simply far beyond disapointing, it is more than inacceptable and by just reading those benchmarks, I'd like to drop thinking of using FreeBSD even as a backend server in scientific and business environments. In detail, some of the SciMark benches look disappointing. The overall image can't help over the fact that in C-Ray FreeBSD is better performing. From the compiler, I'd like say there couldn't be a drop of more than 10 - 15% in performance - but not 10 or 100 times. I'm just thinking about the discussion of SCHED_ULE and all the saur spots we discussed when I stumbled over the test. Regards, Oliver ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@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"