Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/12/2012 05:00, matt wrote:
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of
"USE_GCC=any" to a port's Makefile, and then committed that change to
various ports. In most (but not all!) cases this will tell the port
"build with gcc instead of clang" (*) .
Why not USE_GCC ?= any for the poor guys like me who build (some)
ports with
USE_GCC=4.6 ?
For those users with CC installed as gcc (including -stable), this
patch should have no effect. Variations of combinations have been
heavily tested on pointyhat-west. If there are any regressions, please
contact me.
Does this override setting CC explicitly in make.conf?
Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC
vs CC in the make system.
Dumb as I am, I also wonder when I see that in multimedia/x264:
...
USE_GCC=any
...
.if ${PORT_OPTIONS:MGCC44}
USE_GCC?= 4.4+
.endif
...
which seems to deny the intent of the GCC44 option
Sorry but I can not make the test at this present time
Matt
Claude Buisson
___
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: Buying recommendation for silent router/fileserver
11.10.2012 17:54, Ulrich Spörlein wrote: Hey guys, I need to replace an aging Pentium IV system that has been serving as my router, access point, file- and mediaserver for quite some time now. The replacement should have: - amd64 CPU (for ZFS, obviously) - 2x GigE (igress, egress interfaces) - some form of wlan interface (I currently use an Atheros based PCI card) - eSATA for attaching a backup disk where I stream ZFS snapshots to - serial port is always nice, for when I mess up an upgrade - fan-less if possible So far, this here seems to fit the bill perfectly http://www.fit-pc.com/web/fit-pc/intensepc/ but pricing seems to defy any reality. It does not state directly which chipsets are used for Wifi and Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and RTL8111D, but I don't trust that fully. For Wifi I can always fall back to sticking in a supported USB stick, although that's kinda hacky. So how well is networking going to be supported by FreeBSD? Should I just bite the bullet and find out? Why not trying to look at cheap barebones or desktop PC's? http://www.silentpcreview.com/Sapphire_Edge_HD3 http://www.newegg.com/Product/Product.aspx?Item=N82E16856119070 They are cheaper, hold much better processors for ZFS and can be upgraded with extra GigE/eSATA interfaces by USB3. -- Sphinx of black quartz, judge my vow. ___ 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: Bull Mountain (IvyBridge +) random number generator
schrieb Konstantin Belousov am 02.09.2012 12:34 (localtime): > It is relatively well known that Ivy Bridge CPUs (Core iX 3XXX) have > built-in hardware random number generator, which is claimed to be both > very fast and high quality. Generator is accessible using non-privileged > RDRAND instruction. It is claimed that CPU performs sanitization of the > random sequence. In particular, it seems that paranoid AES encryption of > the raw random stream, performed by our padlock driver, is not needed > for Bull Mountain (there are hints that hardware performs it already). > > See > http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 > http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ > and IA32 ADM. > > Patch at > http://people.freebsd.org/~kib/misc/bull_mountain.2.patch > implements support for the generator. I do not own any IvyBridge machines, > so I cannot test. Patch makes both padlock and bull generators the options, > you need to enable IVY_RNG to get support for the generator. > > I would be interested in seeing reports including verbose boot dmesg, > and some tests of /dev/random quality on the IvyBridge machines, you can > start with > http://lists.gnupg.org/pipermail/gnupg-devel/2000-March/016328.html. Thanks a lot for implementing this! I have an ESXi host with Ivy Brindge CPU. FreeBSD guest reports the following: CPU: Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz (3492.07-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306a9 Family = 6 Model = 3a Stepping = 9 Features=0x1fa3fbff Features2=0xfeba2203 AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8235110400 (7853 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI But unfortunately accessing /dev/random doesn't work with IVY_RNG enabled. 'dd' consumes 100% wcpu bound to one core but never finishes (dd if=/dev/random bs=1k count=100|./ent) Also some other functions are blocked, logging in for example (doesn't matter if it's console or ssh). But I can walk arround in already established sessions. I made a 9.1-RC-2 debug kernel but no info appears. Also IVY_RNG isn't reported after kldloading, nor during boot, but this is the expected behaviour if I unterstand your patch correctly. I guess using RDRAND in an hypervisor environment should make no difference but please correct me if I'm wrong. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: Buying recommendation for silent router/fileserver
On Thu, 2012-10-11 at 17:05:46 +0200, Rainer Duffner wrote: > Am Thu, 11 Oct 2012 16:54:53 +0200 > schrieb Ulrich Spörlein : > > > Hey guys, > > > > I need to replace an aging Pentium IV system that has been serving as > > my router, access point, file- and mediaserver for quite some time > > now. The replacement should have: > > > > - amd64 CPU (for ZFS, obviously) > > - 2x GigE (igress, egress interfaces) > > - some form of wlan interface (I currently use an Atheros based PCI > > card) > > - eSATA for attaching a backup disk where I stream ZFS snapshots to > > - serial port is always nice, for when I mess up an upgrade > > - fan-less if possible > > > > So far, this here seems to fit the bill perfectly > > http://www.fit-pc.com/web/fit-pc/intensepc/ > > but pricing seems to defy any reality. > > > > It does not state directly which chipsets are used for Wifi and > > Ethernet, the block diagram claims Ethernet chips to be Intel 82579 > > and RTL8111D, but I don't trust that fully. > > > > For Wifi I can always fall back to sticking in a supported USB stick, > > although that's kinda hacky. > > > > So how well is networking going to be supported by FreeBSD? Should I > > just bite the bullet and find out? > > > > What about the > > HP ProLiant N40L > ? > > It's not fanless, of course - but it's IMO more suited for a > server-type system than anything else in that price-range. > > I don't have one (I have no need for anything beyond what an > AlIX-system can do) - but if I would need a home-server, I'd buy a N40L > (it can boot from USB and you can thus boot FreeNAS from it) Interesting one, with only one GigE port though, both PCIe slots would need to be populated to get a second Ethernet and a Wifi port ... Hmmm Uli ___ 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: Bull Mountain (IvyBridge +) random number generator
- Original Message - From: "Harald Schmalzbauer" ... I guess using RDRAND in an hypervisor environment should make no difference but please correct me if I'm wrong. Try compiling your kernel with:- no options PADLOCK_RNG no options IVY_RNG Or commenting the relevant lines out of your kernel conf. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Buying recommendation for silent router/fileserver
On Fri, 2012-10-12 at 10:48:22 +0300, Volodymyr Kostyrko wrote: > 11.10.2012 17:54, Ulrich Spörlein wrote: > > Hey guys, > > > > I need to replace an aging Pentium IV system that has been serving as my > > router, access point, file- and mediaserver for quite some time now. The > > replacement should have: > > > > - amd64 CPU (for ZFS, obviously) > > - 2x GigE (igress, egress interfaces) > > - some form of wlan interface (I currently use an Atheros based PCI card) > > - eSATA for attaching a backup disk where I stream ZFS snapshots to > > - serial port is always nice, for when I mess up an upgrade > > - fan-less if possible > > > > So far, this here seems to fit the bill perfectly > > http://www.fit-pc.com/web/fit-pc/intensepc/ > > but pricing seems to defy any reality. > > > > It does not state directly which chipsets are used for Wifi and > > Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and > > RTL8111D, but I don't trust that fully. > > > > For Wifi I can always fall back to sticking in a supported USB stick, > > although that's kinda hacky. > > > > So how well is networking going to be supported by FreeBSD? Should I > > just bite the bullet and find out? > > Why not trying to look at cheap barebones or desktop PC's? > > http://www.silentpcreview.com/Sapphire_Edge_HD3 > http://www.newegg.com/Product/Product.aspx?Item=N82E16856119070 > > They are cheaper, hold much better processors for ZFS and can be > upgraded with extra GigE/eSATA interfaces by USB3. I'm not looking forward to attaching both a Wifi USB dongle and another Ethernet one. :( Btw, eSATA is supposed to simply show up as another SATA port in FreeBSD, right? No special driver supported needed for that one? That 4 year warranty option on the IntensePC really looks nice ... I'll shoot them an email to see if the MiniPCI wifi card is supposed to be replaceable by an Atheros based one (I lost track of all the a/b/g/n a while ago, especially which antennae have to go with those ...) Cheers, Uli ___ 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: Buying recommendation for silent router/fileserver
On Fri, Oct 12, 2012 at 10:58 AM, Ulrich Spörlein wrote: > Btw, eSATA is supposed to simply show up as another SATA port in > FreeBSD, right? No special driver supported needed for that one? Yep, I have an eSATA hard drive dock, drop the drive in and it is instantly recognised. The eSATA port in my case comes from Intel ICH10, and uses ahci(4). Cheers Tom ___ 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: Buying recommendation for silent router/fileserver
On 12.10.2012 11:03, Ulrich Spörlein wrote: > On Thu, 2012-10-11 at 17:05:46 +0200, Rainer Duffner wrote: >> Am Thu, 11 Oct 2012 16:54:53 +0200 >> schrieb Ulrich Spörlein : >> >>> Hey guys, >>> >>> I need to replace an aging Pentium IV system that has been serving as >>> my router, access point, file- and mediaserver for quite some time >>> now. The replacement should have: >>> >>> - amd64 CPU (for ZFS, obviously) >>> - 2x GigE (igress, egress interfaces) >>> - some form of wlan interface (I currently use an Atheros based PCI >>> card) >>> - eSATA for attaching a backup disk where I stream ZFS snapshots to >>> - serial port is always nice, for when I mess up an upgrade >>> - fan-less if possible >>> >>> So far, this here seems to fit the bill perfectly >>> http://www.fit-pc.com/web/fit-pc/intensepc/ >>> but pricing seems to defy any reality. >>> >>> It does not state directly which chipsets are used for Wifi and >>> Ethernet, the block diagram claims Ethernet chips to be Intel 82579 >>> and RTL8111D, but I don't trust that fully. >>> >>> For Wifi I can always fall back to sticking in a supported USB stick, >>> although that's kinda hacky. >>> >>> So how well is networking going to be supported by FreeBSD? Should I >>> just bite the bullet and find out? >> >> >> >> What about the >> >> HP ProLiant N40L >> ? >> >> It's not fanless, of course - but it's IMO more suited for a >> server-type system than anything else in that price-range. It has a big fan which doesn't generate much noise. It is also decent looking in case you need to integrate it into a living room. >> I don't have one (I have no need for anything beyond what an >> AlIX-system can do) - but if I would need a home-server, I'd buy a N40L >> (it can boot from USB and you can thus boot FreeNAS from it) > > Interesting one, with only one GigE port though, both PCIe slots would > need to be populated to get a second Ethernet and a Wifi port ... I don't think that would be a drawback unless you want to cramp in a second SSD (or more) into the 5.25" slot. Maybe there is a wireless/wired combo card, but I havent found one. The USB boot + SSD (zfs cache) + 4 disks is a nice storage solution. mata ne, Hendrik signature.asc Description: OpenPGP digital signature
[head tinderbox] failure on i386/i386
TB --- 2012-10-12 04:50:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-12 04:50:01 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-12 04:50:01 - starting HEAD tinderbox run for i386/i386 TB --- 2012-10-12 04:50:01 - cleaning the object tree TB --- 2012-10-12 04:50:01 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-12 04:50:01 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-10-12 04:50:01 - /usr/local/bin/svn cleanup /src TB --- 2012-10-12 04:53:23 - /usr/local/bin/svn update /src TB --- 2012-10-12 04:53:42 - At svn revision 241478 TB --- 2012-10-12 04:53:43 - building world TB --- 2012-10-12 04:53:43 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 04:53:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 04:53:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 04:53:43 - SRCCONF=/dev/null TB --- 2012-10-12 04:53:43 - TARGET=i386 TB --- 2012-10-12 04:53:43 - TARGET_ARCH=i386 TB --- 2012-10-12 04:53:43 - TZ=UTC TB --- 2012-10-12 04:53:43 - __MAKE_CONF=/dev/null TB --- 2012-10-12 04:53:43 - cd /src TB --- 2012-10-12 04:53:43 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Oct 12 04:53:54 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Oct 12 07:29:12 UTC 2012 TB --- 2012-10-12 07:29:12 - generating LINT kernel config TB --- 2012-10-12 07:29:12 - cd /src/sys/i386/conf TB --- 2012-10-12 07:29:12 - /usr/bin/make -B LINT TB --- 2012-10-12 07:29:13 - cd /src/sys/i386/conf TB --- 2012-10-12 07:29:13 - /usr/sbin/config -m LINT TB --- 2012-10-12 07:29:13 - building LINT kernel TB --- 2012-10-12 07:29:13 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 07:29:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 07:29:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 07:29:13 - SRCCONF=/dev/null TB --- 2012-10-12 07:29:13 - TARGET=i386 TB --- 2012-10-12 07:29:13 - TARGET_ARCH=i386 TB --- 2012-10-12 07:29:13 - TZ=UTC TB --- 2012-10-12 07:29:13 - __MAKE_CONF=/dev/null TB --- 2012-10-12 07:29:13 - cd /src TB --- 2012-10-12 07:29:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 12 07:29:13 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Oct 12 08:04:36 UTC 2012 TB --- 2012-10-12 08:04:36 - cd /src/sys/i386/conf TB --- 2012-10-12 08:04:36 - /usr/sbin/config -m LINT-NOINET TB --- 2012-10-12 08:04:36 - building LINT-NOINET kernel TB --- 2012-10-12 08:04:36 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 08:04:36 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 08:04:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 08:04:36 - SRCCONF=/dev/null TB --- 2012-10-12 08:04:36 - TARGET=i386 TB --- 2012-10-12 08:04:36 - TARGET_ARCH=i386 TB --- 2012-10-12 08:04:36 - TZ=UTC TB --- 2012-10-12 08:04:36 - __MAKE_CONF=/dev/null TB --- 2012-10-12 08:04:36 - cd /src TB --- 2012-10-12 08:04:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Oct 12 08:04:36 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Fri Oct 12 08:37:58 UTC 2012 TB --- 2012-10-12 08:37:58 - cd /src/sys/i386/conf TB --- 2012-10-12 08:37:58 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-10-12 08:37:59 - building LINT-NOINET6 kernel TB --- 2012-10-12 08:37:59 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 08:37:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 08:37:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 08:37:59 - SRCCONF=/dev/null TB --- 2012-10-12 08:37:59 - TARGET=i386 TB --- 2012-10-12 08:37:59 - TARGET_ARCH=i386 TB --- 2012-10-12 08:37:59 - TZ=UTC TB --- 2012-10-12 08:37:59 - __MAKE_CONF=/dev/null TB --- 2012-10-12 08:37:59 - cd /src TB --- 2012-10-12 08:37:59 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Oct 12 08:37:59 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-N
Re: Buying recommendation for silent router/fileserver
Am Fri, 12 Oct 2012 11:03:10 +0200 schrieb Ulrich Spörlein : > Interesting one, with only one GigE port though, both PCIe slots would > need to be populated to get a second Ethernet and a Wifi port ... As said, it would be better to use a 2nd system (ALIX only uses 5-10W or so) for WIFI (and even then, the pfSense folk recommends using a dedicated AP on OPT1 to handle the WIFI-stuff) - unless you want it to act as a client only. Then an USB-stick should do, right? Or one of the WLAN-bridges for 40€ Does FreeNAS do VLANs? Then, you'd only need a VLAN-capable switch and one NIC would be enough. I don't think the machine could saturate 2 GBIT-ports anyway... ___ 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: Buying recommendation for silent router/fileserver
On Fri, 2012-10-12 at 13:03:23 +0200, Hendrik Hasenbein wrote: > On 12.10.2012 11:03, Ulrich Spörlein wrote: > > On Thu, 2012-10-11 at 17:05:46 +0200, Rainer Duffner wrote: > >> Am Thu, 11 Oct 2012 16:54:53 +0200 > >> schrieb Ulrich Spörlein : > >> > >>> Hey guys, > >>> > >>> I need to replace an aging Pentium IV system that has been serving as > >>> my router, access point, file- and mediaserver for quite some time > >>> now. The replacement should have: > >>> > >>> - amd64 CPU (for ZFS, obviously) > >>> - 2x GigE (igress, egress interfaces) > >>> - some form of wlan interface (I currently use an Atheros based PCI > >>> card) > >>> - eSATA for attaching a backup disk where I stream ZFS snapshots to > >>> - serial port is always nice, for when I mess up an upgrade > >>> - fan-less if possible > >>> > >>> So far, this here seems to fit the bill perfectly > >>> http://www.fit-pc.com/web/fit-pc/intensepc/ > >>> but pricing seems to defy any reality. > >>> > >>> It does not state directly which chipsets are used for Wifi and > >>> Ethernet, the block diagram claims Ethernet chips to be Intel 82579 > >>> and RTL8111D, but I don't trust that fully. > >>> > >>> For Wifi I can always fall back to sticking in a supported USB stick, > >>> although that's kinda hacky. > >>> > >>> So how well is networking going to be supported by FreeBSD? Should I > >>> just bite the bullet and find out? > >> > >> > >> > >> What about the > >> > >> HP ProLiant N40L > >> ? > >> > >> It's not fanless, of course - but it's IMO more suited for a > >> server-type system than anything else in that price-range. > > It has a big fan which doesn't generate much noise. It is also decent > looking in case you need to integrate it into a living room. For longevity, I'd have a bit more confidence if this was an IvyBridge system ... Now that FreeBSD somewhat supports the Intel HD graphics, I might even slap on XBMC. And yes, living room + low noise is key, aka Wife Acceptance Factor (http://en.wikipedia.org/wiki/Wife_acceptance_factor) > >> I don't have one (I have no need for anything beyond what an > >> AlIX-system can do) - but if I would need a home-server, I'd buy a N40L > >> (it can boot from USB and you can thus boot FreeNAS from it) > > > > Interesting one, with only one GigE port though, both PCIe slots would > > need to be populated to get a second Ethernet and a Wifi port ... > > I don't think that would be a drawback unless you want to cramp in a > second SSD (or more) into the 5.25" slot. Maybe there is a > wireless/wired combo card, but I havent found one. The USB boot + SSD > (zfs cache) + 4 disks is a nice storage solution. Yeah, I was aiming for a 32GB SSD, with 8-16GB as UFS2 to boot from and hold all the software, 16GB as ZIL or L2ARC or whatever it is called and have an external 2TiB HDD (eSATA) for the GELI+ZFS volume. Another 2TiB HDD (USB, usually detached/powered down, running ZFS with compression and dedup) already exists and is receiving the ZFS snapshots from the current 1TiB (ATA, internal) disk of the Pentium 4 system. Cheers, Uli ___ 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: Buying recommendation for silent router/fileserver
I did not, but I put it on my list to try to accomplish. On 10/11/12 13:41, Adrian Chadd wrote: Did you ever file a PR for the slow SATA behaviour? Adrian On 11 October 2012 09:52, Adam McDougall wrote: On 10/11/12 12:05, Gary Palmer wrote: On Thu, Oct 11, 2012 at 04:54:53PM +0200, Ulrich Sp??rlein wrote: Hey guys, I need to replace an aging Pentium IV system that has been serving as my router, access point, file- and mediaserver for quite some time now. The replacement should have: - amd64 CPU (for ZFS, obviously) - 2x GigE (igress, egress interfaces) - some form of wlan interface (I currently use an Atheros based PCI card) - eSATA for attaching a backup disk where I stream ZFS snapshots to - serial port is always nice, for when I mess up an upgrade - fan-less if possible So far, this here seems to fit the bill perfectly http://www.fit-pc.com/web/fit-pc/intensepc/ but pricing seems to defy any reality. It does not state directly which chipsets are used for Wifi and Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and RTL8111D, but I don't trust that fully. For Wifi I can always fall back to sticking in a supported USB stick, although that's kinda hacky. So how well is networking going to be supported by FreeBSD? Should I just bite the bullet and find out? I'd recommend the Soekris net6501, but it's even more expensive than the intensepc (I suspect due to low hardware volumes but thats just a guess) http://soekris.com/products/net6501.html You also don't specify what kind of storage you need, which is obviously an important factor for a file/media server. Gary ___ 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" Be wary of the Soekris net6501, I bought three of the 1.6Ghz net6501-70 model which has an Atom E-680 cpu (E series) and it compiles more than twice as slow as a 1.6Ghz Atom N270 in an older netbook. Someone else running Linux reported similar CPU slowness. As far as practical network throughput, I could only get 100Mbit/sec with a simple HTTP download of a file full of zeros, and OpenVPN could only push about 25Mbit/sec. As a practical example of the CPU slowness, it takes about 1.5 minutes to compile pkg on the N270 netbook and 5 minutes on the 6501 (around 4.5 if I use -j2). A kernel compile took an hour. Unfortunately I had no idea this CPU (possibly implementation?) was so slow before I purchased it, and I could scarcely find evidence of it on google after hours of searching when I had already discovered the issue. I was hoping to find some comparative benchmarks between various Atom series but manufacturers generally don't do that. Additionally, the total AHCI SATA write speed on the net6501 (in BSD only?) has a strange 20MB/sec limitation but reads can go over 100MB/sec. If I write to one disk I get 20MB/sec, if I write to both SATA disks I get 10MB/sec each. Write is equally slow on a SSD. Both someone running OpenBSD and I running FreeBSD reported the same symptoms to the soekris-tech mailing list and received no useful replies towards getting that problem solved. I tested the write speed briefly with Linux and it did not appear to have the 20MB/sec limitation. I did confirm it was using MSI(-X?) with boot -v. I think this hardware would need to fall into Alexander Motin's hands to get anywhere with debugging the SATA speed issue. Since it seems fine in Linux, maybe some day it can be fixed in BSD but I have no clue how that limitation could happen. The disks I tested with are fine in normal computers. ___ 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: Bull Mountain (IvyBridge +) random number generator
On Fri, Oct 12, 2012 at 10:50:55AM +0200, Harald Schmalzbauer wrote: > schrieb Konstantin Belousov am 02.09.2012 12:34 (localtime): > > It is relatively well known that Ivy Bridge CPUs (Core iX 3XXX) have > > built-in hardware random number generator, which is claimed to be both > > very fast and high quality. Generator is accessible using non-privileged > > RDRAND instruction. It is claimed that CPU performs sanitization of the > > random sequence. In particular, it seems that paranoid AES encryption of > > the raw random stream, performed by our padlock driver, is not needed > > for Bull Mountain (there are hints that hardware performs it already). > > > > See > > http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0 > > http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/ > > and IA32 ADM. > > > > Patch at > > http://people.freebsd.org/~kib/misc/bull_mountain.2.patch > > implements support for the generator. I do not own any IvyBridge machines, > > so I cannot test. Patch makes both padlock and bull generators the options, > > you need to enable IVY_RNG to get support for the generator. > > > > I would be interested in seeing reports including verbose boot dmesg, > > and some tests of /dev/random quality on the IvyBridge machines, you can > > start with > > http://lists.gnupg.org/pipermail/gnupg-devel/2000-March/016328.html. > > Thanks a lot for implementing this! > I have an ESXi host with Ivy Brindge CPU. > FreeBSD guest reports the following: > CPU: Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz (3492.07-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0x306a9 Family = 6 Model = 3a > Stepping = 9 > > Features=0x1fa3fbff > > Features2=0xfeba2203 > AMD Features=0x28100800 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 8589934592 (8192 MB) > avail memory = 8235110400 (7853 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > MADT: Forcing active-low polarity and level trigger for SCI > > But unfortunately accessing /dev/random doesn't work with IVY_RNG enabled. > 'dd' consumes 100% wcpu bound to one core but never finishes (dd > if=/dev/random bs=1k count=100|./ent) > Also some other functions are blocked, logging in for example (doesn't > matter if it's console or ssh). But I can walk arround in already > established sessions. > > I made a 9.1-RC-2 debug kernel but no info appears. Also IVY_RNG isn't > reported after kldloading, nor during boot, but this is the expected > behaviour if I unterstand your patch correctly. > > I guess using RDRAND in an hypervisor environment should make no > difference but please correct me if I'm wrong. Try the stable/9 instead. The code was merged in r240950. There was a bug in the original patch with the similar description. pgpyU8aDlj1LH.pgp Description: PGP signature
Re: [head tinderbox] failure on i386/i386
Hi,
- Original Message -
> From: "FreeBSD Tinderbox"
> To: "FreeBSD Tinderbox" , curr...@freebsd.org,
> i...@freebsd.org
> Sent: Friday, October 12, 2012 6:11:27 AM
> Subject: [head tinderbox] failure on i386/i386
>
> TB --- 2012-10-12 04:50:01 - tinderbox 2.9 running on
> freebsd-current.sentex.ca
> TB --- 2012-10-12 04:50:01 - FreeBSD freebsd-current.sentex.ca
> 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT
> 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC
> amd64
> TB --- 2012-10-12 04:50:01 - starting HEAD tinderbox run for
> i386/i386
> TB --- 2012-10-12 04:50:01 - cleaning the object tree
> TB --- 2012-10-12 04:50:01 - checking out /src from
> svn://svn.freebsd.org/base/head
> TB --- 2012-10-12 04:50:01 - cd /tinderbox/HEAD/i386/i386
> TB --- 2012-10-12 04:50:01 - /usr/local/bin/svn cleanup /src
> TB --- 2012-10-12 04:53:23 - /usr/local/bin/svn update /src
> TB --- 2012-10-12 04:53:42 - At svn revision 241478
[SNIP]
> TB --- 2012-10-12 10:54:26 - /usr/bin/make -B buildkernel
> KERNCONF=XEN
> >>> Kernel build for XEN started on Fri Oct 12 10:54:26 UTC 2012
> >>> stage 1: configuring the kernel
> >>> stage 2.1: cleaning up the object tree
> >>> stage 2.2: rebuilding the object tree
> >>> stage 2.3: build tools
> >>> stage 3.1: making dependencies
> >>> stage 3.2: building everything
> [...]
> objcopy --only-keep-debug virtio_balloon.ko.debug
> virtio_balloon.ko.symbols
> objcopy --strip-debug --add-gnu-debuglink=virtio_balloon.ko.symbols
> virtio_balloon.ko.debug virtio_balloon.ko
> ===> virtio/scsi (all)
> cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include
> /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq
> -finline-limit=8000 --param inline-unit-growth=100 --param
> large-function-growth=1000 -fno-common -g
> -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings
> -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float
> -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector
> -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
> -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs
> -fdiagnostics-show-option -c
> /src/sys/modules/virtio/scsi/../../../dev/virtio/scsi/virtio_scsi.c
> cc1: warnings being treated as errors
> /src/sys/modules/virtio/scsi/../../../dev/virtio/scsi/virtio_scsi.c:
> In function 'vtscsi_sg_append_scsi_buf':
> /src/sys/modules/virtio/scsi/../../../dev/virtio/scsi/virtio_scsi.c:974:
> warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> /src/sys/modules/virtio/scsi/../../../dev/virtio/scsi/virtio_scsi.c:982:
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
> *** [virtio_scsi.o] Error code 1
I cannot seem to recreate this locally, but I think these need
to be casted through uintptr?
diff --git a/sys/dev/virtio/scsi/virtio_scsi.c
b/sys/dev/virtio/scsi/virtio_scsi.c
index f2e1412..79bc988 100644
--- a/sys/dev/virtio/scsi/virtio_scsi.c
+++ b/sys/dev/virtio/scsi/virtio_scsi.c
@@ -971,7 +971,7 @@ vtscsi_sg_append_scsi_buf(struct vtscsi_softc *sc, struct
sglist *sg,
csio->data_ptr, csio->dxfer_len);
else
error = sglist_append_phys(sg,
- (vm_paddr_t) csio->data_ptr, csio->dxfer_len);
+ (vm_paddr_t)(uintptr_t) csio->data_ptr,
csio->dxfer_len);
} else {
for (i = 0; i < csio->sglist_cnt && error == 0; i++) {
@@ -979,7 +979,7 @@ vtscsi_sg_append_scsi_buf(struct vtscsi_softc *sc, struct
sglist *sg,
if ((ccbh->flags & CAM_SG_LIST_PHYS) == 0)
error = sglist_append(sg,
- (void *) dseg->ds_addr, dseg->ds_len);
+ (void *)(uintptr_t) dseg->ds_addr,
dseg->ds_len);
else
error = sglist_append_phys(sg,
(vm_paddr_t) dseg->ds_addr, dseg->ds_len);
That being said, compiling VirtIO for a XEN kernel probably
doesn't make any sense.
Bryan
>
> Stop in /src/sys/modules/virtio/scsi.
> *** [all] Error code 1
>
> Stop in /src/sys/modules/virtio.
> *** [all] Error code 1
>
> Stop in /src/sys/modules.
> *** [modules-all] Error code 1
>
> Stop in /obj/i386.i386/src/sys/XEN.
> *** [buildkernel] Error code 1
>
> Stop in /src.
> *** Error code 1
>
> Stop in /src.
> TB --- 2012-10-12 11:11:27 - WARNING: /usr/bin/make returned exit
> code 1
> TB --- 2012-10-12 11:11:27 - ERROR: failed to build XEN kernel
> TB --- 2012-10-12 11:11:27 - 17474.50 user 2374.09 system 22886.60
> real
>
>
> http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full
> ___
> freebsd-current@freebsd.org mailing li
Re: Buying recommendation for silent router/fileserver
Hi, I have a Supermicros X7SPA-HF-D525 running as a fileserver. Six SATA connectors on board and runs flawlessly with eight GiB Mem. On Thu, 11 Oct 2012, Ulrich Spörlein wrote: Date: Thu, 11 Oct 2012 16:54:53 +0200 From: Ulrich Spörlein To: curr...@freebsd.org Subject: Buying recommendation for silent router/fileserver Hey guys, I need to replace an aging Pentium IV system that has been serving as my router, access point, file- and mediaserver for quite some time now. The replacement should have: - amd64 CPU (for ZFS, obviously) - 2x GigE (igress, egress interfaces) - some form of wlan interface (I currently use an Atheros based PCI card) - eSATA for attaching a backup disk where I stream ZFS snapshots to - serial port is always nice, for when I mess up an upgrade - fan-less if possible So far, this here seems to fit the bill perfectly http://www.fit-pc.com/web/fit-pc/intensepc/ but pricing seems to defy any reality. It does not state directly which chipsets are used for Wifi and Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and RTL8111D, but I don't trust that fully. For Wifi I can always fall back to sticking in a supported USB stick, although that's kinda hacky. So how well is networking going to be supported by FreeBSD? Should I just bite the bullet and find out? Cheers, Uli ___ 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" Bye/2 --- Michael Reifenberger mich...@reifenberger.com http://www.Reifenberger.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Buying recommendation for silent router/fileserver
On 10/11/2012 04:54 PM, Ulrich Spörlein wrote: > Hey guys, > > I need to replace an aging Pentium IV system that has been serving as my > router, access point, file- and mediaserver for quite some time now. The > replacement should have: > > - amd64 CPU (for ZFS, obviously) > - 2x GigE (igress, egress interfaces) > - some form of wlan interface (I currently use an Atheros based PCI card) > - eSATA for attaching a backup disk where I stream ZFS snapshots to > - serial port is always nice, for when I mess up an upgrade > - fan-less if possible > > So far, this here seems to fit the bill perfectly > http://www.fit-pc.com/web/fit-pc/intensepc/ > but pricing seems to defy any reality. > > It does not state directly which chipsets are used for Wifi and > Ethernet, the block diagram claims Ethernet chips to be Intel 82579 and > RTL8111D, but I don't trust that fully. > > For Wifi I can always fall back to sticking in a supported USB stick, > although that's kinda hacky. > > So how well is networking going to be supported by FreeBSD? Should I > just bite the bullet and find out? > > Cheers, > Uli > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Hi Uli, I have bought this one: http://www.mindfactory.de/product_info.php/info/775548 with 4GB RAM DDR3 on 1066Mhz, with additional 1Gb/s PCI Ethernetcard and using old but silent power supply. Pfsense is not yet running, because I am still testing, but I can tell so far that it has enough power to run the 3 ethX interfaces full speed (about 100MB/s each for like 2 days testing) with live debian USB. I am planning to run pfsense on it soon. I also tested how fast the cpu is and I must say that is not blazing fast, it is about 3 times slower than my laptop with 2x2,4 Ghz intell T8300, but it is low power ... Cheers, Asen ___ 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"
[head tinderbox] failure on i386/i386
TB --- 2012-10-12 14:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-10-12 14:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-10-12 14:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-10-12 14:20:00 - cleaning the object tree TB --- 2012-10-12 14:26:23 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-10-12 14:26:23 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-10-12 14:26:23 - /usr/local/bin/svn cleanup /src TB --- 2012-10-12 14:27:06 - /usr/local/bin/svn update /src TB --- 2012-10-12 14:27:13 - At svn revision 241483 TB --- 2012-10-12 14:27:14 - building world TB --- 2012-10-12 14:27:14 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 14:27:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 14:27:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 14:27:14 - SRCCONF=/dev/null TB --- 2012-10-12 14:27:14 - TARGET=i386 TB --- 2012-10-12 14:27:14 - TARGET_ARCH=i386 TB --- 2012-10-12 14:27:14 - TZ=UTC TB --- 2012-10-12 14:27:14 - __MAKE_CONF=/dev/null TB --- 2012-10-12 14:27:14 - cd /src TB --- 2012-10-12 14:27:14 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Fri Oct 12 14:27:19 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Oct 12 16:53:15 UTC 2012 TB --- 2012-10-12 16:53:15 - generating LINT kernel config TB --- 2012-10-12 16:53:15 - cd /src/sys/i386/conf TB --- 2012-10-12 16:53:15 - /usr/bin/make -B LINT TB --- 2012-10-12 16:53:16 - cd /src/sys/i386/conf TB --- 2012-10-12 16:53:16 - /usr/sbin/config -m LINT TB --- 2012-10-12 16:53:16 - building LINT kernel TB --- 2012-10-12 16:53:16 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 16:53:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 16:53:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 16:53:16 - SRCCONF=/dev/null TB --- 2012-10-12 16:53:16 - TARGET=i386 TB --- 2012-10-12 16:53:16 - TARGET_ARCH=i386 TB --- 2012-10-12 16:53:16 - TZ=UTC TB --- 2012-10-12 16:53:16 - __MAKE_CONF=/dev/null TB --- 2012-10-12 16:53:16 - cd /src TB --- 2012-10-12 16:53:16 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 12 16:53:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Oct 12 17:27:02 UTC 2012 TB --- 2012-10-12 17:27:02 - cd /src/sys/i386/conf TB --- 2012-10-12 17:27:02 - /usr/sbin/config -m LINT-NOINET TB --- 2012-10-12 17:27:02 - building LINT-NOINET kernel TB --- 2012-10-12 17:27:02 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 17:27:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 17:27:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 17:27:02 - SRCCONF=/dev/null TB --- 2012-10-12 17:27:02 - TARGET=i386 TB --- 2012-10-12 17:27:02 - TARGET_ARCH=i386 TB --- 2012-10-12 17:27:02 - TZ=UTC TB --- 2012-10-12 17:27:02 - __MAKE_CONF=/dev/null TB --- 2012-10-12 17:27:02 - cd /src TB --- 2012-10-12 17:27:02 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Oct 12 17:27:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Fri Oct 12 17:58:57 UTC 2012 TB --- 2012-10-12 17:58:57 - cd /src/sys/i386/conf TB --- 2012-10-12 17:58:57 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-10-12 17:58:57 - building LINT-NOINET6 kernel TB --- 2012-10-12 17:58:57 - CROSS_BUILD_TESTING=YES TB --- 2012-10-12 17:58:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-10-12 17:58:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-10-12 17:58:57 - SRCCONF=/dev/null TB --- 2012-10-12 17:58:57 - TARGET=i386 TB --- 2012-10-12 17:58:57 - TARGET_ARCH=i386 TB --- 2012-10-12 17:58:57 - TZ=UTC TB --- 2012-10-12 17:58:57 - __MAKE_CONF=/dev/null TB --- 2012-10-12 17:58:57 - cd /src TB --- 2012-10-12 17:58:57 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Oct 12 17:58:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-N
Re: Buying recommendation for silent router/fileserver
On Fri, 12 Oct 2012 13:51:06 +0200 Ulrich Spörlein wrote: > For longevity, I'd have a bit more confidence if this was an IvyBridge > system ... Now that FreeBSD somewhat supports the Intel HD graphics, I > might even slap on XBMC. And yes, living room + low noise is key, aka > Wife Acceptance Factor > (http://en.wikipedia.org/wiki/Wife_acceptance_factor) Fans are not evil. The trick is to use very big ones which run slowly and quiet. Have a look for: - big/normal but nice case (for air-flow reasons with the benefit of space for hard drives and you can change parts inside later at will without space problems), let your significant other chose it - bg CPU cooler (Scyte, Noctua, Thermalright, ...) - big CPU fan (12cm / 14cm... big ones can run slow and silent) - low power CPU - at leat one big case fan (12cm) - 40 EUR fan-less Nvidia card - 80 Plus Platinum PSU I have a system which is like this, big case with 5 harddisks and a ssd, a big case fan blowing on it (speed adjustable, but already with a very slow and quiet setting the disks don't heat up) in direction of the CPU, the fan of the CPU more or less not turning (the CPU coolers which come with big CPU fans have a temperature controlled fan most of the time), and a second big case fan sucking out the air on the top of the case. The fan of the PSU is also temperature controlled, and very quiet (in case the fan should turn at all). With this you can put inside whatever you want. For your use case maybe a Core i3/5 CPU with a low max-TDP (30-40W instead of the usual 95). Together with a fan-less NVidia GeForce GT 520 card (40 EUR) you can have plenty of horse power (for your envisioned use-case) but you don't hear it (except you put your ear directly beneath the case). Such a system may be not as flexible to hide as the one you talked about initially, but you have the possibility to upgrade easily and as necessary. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: new DragonFly-3.2 scheduler and PostgreSQL comparision with FreeBSD 9.1-RC1
On 12 October 2012 11:10, Miroslav Lachman <000.f...@quip.cz> wrote: > I don't like comparing Release Candidates without any details about config, > but the fact that DF 3.2 is much better than DF 3.0 is interesting. And they > are very close to performance of Scientific Linux 6.2. Hey cool! And FreeBSD-9.1 is on there and doing worse than Linux and Dragonfly BSD. I wonder why that is. Lemme cross post this a little to see what people think. > http://lists.dragonflybsd.org/pipermail/users/2012-October/017536.html > > Graphs are available as PDF attachments > > http://lists.dragonflybsd.org/pipermail/users/attachments/20121010/7996ff88/attachment-0002.pdf > > http://lists.dragonflybsd.org/pipermail/users/attachments/20121010/7996ff88/attachment-0003.pdf Adrian ___ 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"
boot2/loader: serial port handling
Hi,
We have some rather hacky quick hack at $WORK that addresses a problem
we have found with boot2/loader and wants to share it and see if we can
have more neat solution.
Here is the problem: the current boot2 and loader have various places
where it considers serial port to exist. When the port is not there,
the code would hang because it tests whether the hardware's -READY bit,
basically something like:
do {
} while (inpb(state register) & READY_BIT);
This unfortunately would enter an infinite loop when the device is not
present -- all in operations would get all bits set.
To reproduce this, one can compile boot2/loader with non-existent port
and the system will hang at very early stage of boot.
---
Because boot2 is size constrained we can not use very sophisticated
detection logic there, what I did is to use something like:
outb(line control register, word)
if (inb(line control register) != word)
Disable the serial port read/write
For loader I'm not sure if we should use better detection logic. By the
way, it seems that the system may force using the default console in
loader regardless if the detection logic said no, if it decides that's
the only usable one.
So what would be the right way to solve these issue?
Cheers,
--
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
Index: sys/boot/i386/boot2/boot2.c
===
--- sys/boot/i386/boot2/boot2.c (revision 241434)
+++ sys/boot/i386/boot2/boot2.c (working copy)
@@ -415,8 +415,10 @@ parse()
}
ioctrl = OPT_CHECK(RBX_DUAL) ? (IO_SERIAL|IO_KEYBOARD) :
OPT_CHECK(RBX_SERIAL) ? IO_SERIAL : IO_KEYBOARD;
- if (ioctrl & IO_SERIAL)
- sio_init(115200 / comspeed);
+ if (ioctrl & IO_SERIAL) {
+ if (sio_init(115200 / comspeed))
+ ioctrl &= ~IO_SERIAL;
+ }
} else {
for (q = arg--; *q && *q != '('; q++);
if (*q) {
Index: sys/boot/i386/boot2/lib.h
===
--- sys/boot/i386/boot2/lib.h (revision 241434)
+++ sys/boot/i386/boot2/lib.h (working copy)
@@ -17,7 +17,7 @@
* $FreeBSD$
*/
-void sio_init(int) __attribute__((regparm (3)));
+int sio_init(int) __attribute__((regparm (3)));
void sio_flush(void);
void sio_putc(int) __attribute__((regparm (3)));
int sio_getc(void);
Index: sys/boot/i386/boot2/sio.S
===
--- sys/boot/i386/boot2/sio.S (revision 241434)
+++ sys/boot/i386/boot2/sio.S (working copy)
@@ -24,12 +24,15 @@
.globl sio_getc
.globl sio_ischar
-/* void sio_init(int div) */
+/* int sio_init(int div) */
sio_init: pushl %eax
movw $SIO_PRT+0x3,%dx # Data format reg
movb $SIO_FMT|0x80,%al # Set format
outb %al,(%dx) # and DLAB
+ inb (%dx),%al
+ cmpb $SIO_FMT|0x80,%al
+ jnz sio_init.1
subb $0x3,%dl # Divisor latch reg
popl %eax
outw %ax,(%dx) # BPS
@@ -41,8 +44,13 @@ sio_init:pushl %eax
outb %al,(%dx) # DTR
incl %edx # Line status reg
call sio_flush
+ xor %eax,%eax
ret
+sio_init.1:popl %eax
+ movb $0x1,%al
+ ret
+
/* void sio_flush(void) */
sio_flush.0: call sio_getc.1 # Get character
Index: sys/boot/i386/libi386/comconsole.c
===
--- sys/boot/i386/libi386/comconsole.c (revision 241434)
+++ sys/boot/i386/libi386/comconsole.c (working copy)
@@ -33,7 +33,7 @@ __FBSDID("$FreeBSD$");
#include "libi386.h"
#define COMC_FMT 0x3 /* 8N1 */
-#define COMC_TXWAIT0x4 /* transmit timeout */
+#define COMC_TXWAIT0x80/* transmit timeout */
#define COMC_BPS(x)(115200 / (x)) /* speed to DLAB divisor */
#define COMC_DIV2BPS(x)(115200 / (x)) /* DLAB divisor to speed */
@@ -57,6 +57,7 @@ static intcomc_speed_set(struct env_var *ev, int
static int comc_started;
static int comc_curspeed;
+static int comc_disabled;
struct console comconsole = {
"comconsole",
@@ -76,9 +77,12 @@ comc_probe(struct console *cp)
char *cons, *speedenv;
int speed;
-/* XXX check the BIOS equipment list? */
-cp->c_flags |= (C_PRESENTIN | C_PRESENTOUT);
+u_char dlbh;
+u_char dlbl;
+u_char cfcr;
+comc_disabled = 0;
+
if (comc_curspeed == 0) {
comc_curspeed = COMSPEED;
/*
@@ -102,6 +106,22 @@ comc_probe(struct console *cp)
Re: boot2/loader: serial port handling
On Fri, Oct 12, 2012 at 4:30 PM, Xin Li wrote:
> Hi,
>
> We have some rather hacky quick hack at $WORK that addresses a problem
> we have found with boot2/loader and wants to share it and see if we can
> have more neat solution.
>
> Here is the problem: the current boot2 and loader have various places
> where it considers serial port to exist. When the port is not there,
> the code would hang because it tests whether the hardware's -READY bit,
> basically something like:
>
> do {
> } while (inpb(state register) & READY_BIT);
>
> This unfortunately would enter an infinite loop when the device is not
> present -- all in operations would get all bits set.
>
> To reproduce this, one can compile boot2/loader with non-existent port
> and the system will hang at very early stage of boot.
>
> ---
>
> Because boot2 is size constrained we can not use very sophisticated
> detection logic there, what I did is to use something like:
>
> outb(line control register, word)
> if (inb(line control register) != word)
> Disable the serial port read/write
>
> For loader I'm not sure if we should use better detection logic. By the
> way, it seems that the system may force using the default console in
> loader regardless if the detection logic said no, if it decides that's
> the only usable one.
>
> So what would be the right way to solve these issue?
Have you tried out Andriy's commit yet to loader(8) (r241301)?
Cheers,
-Garrett
___
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: boot2/loader: serial port handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/12/12 17:04, Garrett Cooper wrote:
> On Fri, Oct 12, 2012 at 4:30 PM, Xin Li
> wrote:
>> Hi,
>>
>> We have some rather hacky quick hack at $WORK that addresses a
>> problem we have found with boot2/loader and wants to share it and
>> see if we can have more neat solution.
>>
>> Here is the problem: the current boot2 and loader have various
>> places where it considers serial port to exist. When the port is
>> not there, the code would hang because it tests whether the
>> hardware's -READY bit, basically something like:
>>
>> do { } while (inpb(state register) & READY_BIT);
>>
>> This unfortunately would enter an infinite loop when the device
>> is not present -- all in operations would get all bits set.
>>
>> To reproduce this, one can compile boot2/loader with non-existent
>> port and the system will hang at very early stage of boot.
>>
>> ---
>>
>> Because boot2 is size constrained we can not use very
>> sophisticated detection logic there, what I did is to use
>> something like:
>>
>> outb(line control register, word) if (inb(line control register)
>> != word) Disable the serial port read/write
>>
>> For loader I'm not sure if we should use better detection logic.
>> By the way, it seems that the system may force using the default
>> console in loader regardless if the detection logic said no, if
>> it decides that's the only usable one.
>>
>> So what would be the right way to solve these issue?
>
> Have you tried out Andriy's commit yet to loader(8) (r241301)?
Ah I wish I am not this far behind my email backlog. Yes I think
these (241300 and 241301) will solve the problem.
Cheers,
- --
Xin LI https://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
iQEcBAEBCAAGBQJQeLFFAAoJEG80Jeu8UPuzktAH/3nyrSCrvHWlOSp/eOWf1oMU
KQwzyUXOVgKWCVTHUYHN6tCs0sN1Vguc1n+Q8tqSCuDOJ4/x0lyb6GcyxZv2tf6+
gGYE54yYjf9UDM0HQ3Zb3ZxmH8Z06eH3jK/SlUg8nMXnReLW2v1KkuQ+T3yTyhQH
7vCjOzQylF4CmzpS7l/skNL2lxkJsoD/XROFzRrDAUSK2rdnupjUIxuTXI2G+Bjf
i51qFZk6JRHnecL2c4Zm6ynO65eXyD0Ux7l+FOa00ntOKD33/HJP/Qtpl2UrU+J5
YhMcPUU2uRM3LTSl2D3mtbasrgKQMTmH4syp4ucR7belFPloX7RYjHItQdO6x1M=
=0R8e
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot2/loader: serial port handling
On Fri, Oct 12, 2012 at 5:09 PM, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 ... > Ah I wish I am not this far behind my email backlog. Yes I think > these (241300 and 241301) will solve the problem. Yeah -- forgot about the other one. There's another enhancement that would make this even better (apart from maybe having multiple primary consoles): setting the primary console if present and having fallbacks in the event that the original primary wasn't set or configurable; it was a thing that was present in another project I worked on with sio that was pretty slick (and I think that there would be some parties who wouldn't mind if the same was done with uart(4)). Cheers! -Garrett ___ 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: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
On 10/12/12 00:54, Claude Buisson wrote:
On 10/12/2012 05:00, matt wrote:
I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of
"USE_GCC=any" to a port's Makefile, and then committed that change to
various ports. In most (but not all!) cases this will tell the port
"build with gcc instead of clang" (*) .
Why not USE_GCC ?= any for the poor guys like me who build (some)
ports with
USE_GCC=4.6 ?
For those users with CC installed as gcc (including -stable), this
patch should have no effect. Variations of combinations have been
heavily tested on pointyhat-west. If there are any regressions,
please
contact me.
Does this override setting CC explicitly in make.conf?
Sorry if it's a dumb question, not sure exactly the hierarchy of USE_GCC
vs CC in the make system.
Dumb as I am, I also wonder when I see that in multimedia/x264:
...
USE_GCC=any
...
.if ${PORT_OPTIONS:MGCC44}
USE_GCC?=4.4+
.endif
...
which seems to deny the intent of the GCC44 option
Sorry but I can not make the test at this present time
Matt
Claude Buisson
I tested, and can confirm two things. CC is overpowered by USE_GCC=any,
which means that I end up with no sse4a and limited support for my arch
(Opteron 4xxx) because I can't set a better -march/cputype than
opteron-sse3. As far as I know base gcc doesn't even support sse4a. This
is really perhaps an issue with me setting CC in make.conf moreso than
ports, however this was the approved method of using clang by default as
well as the approved method of using ports gcc in the ports system. Is
there a new approved method?
M. Buisson's test case also fails, with base gcc being used even though
the gcc44 option is chosen. This may not break as many ports as it
might, but it will certainly create low performing editions of many
multimedia ports given the CPU features supported by either later clang
or gcc. Some will probably break?
If I missed something, please let me know, or if my testing is somehow
compromised. I removed make.conf (as mine is customized) for Claude's
test case, but it's possible something else may have affected my test
results. USE_GCC=any was manually added to the ports makefiles (test
case was editors/nano and multimedia/x264).
Matt
___
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"
