Re: [PATCH] PCI bus number management
On 02/06/2014 08:37 PM, John Baldwin wrote: I would like to commit this to HEAD soon but thought I would post it for some pre-commit testing for the brave. :) If you are really brave, try booting with 'hw.pci.clear_buses=1' which will force the kernel to renumber all buses in the system. This is a really bad idea, because BIOS/SMM tends to have those hardcoded. Or am I misunderstanding the purpose of this patch? Julian signature.asc Description: OpenPGP digital signature
Re: CURRENT: Ivy Bridge CPU (i3-3220) and Intel Bull Mountain RNG (options RDRAND_RNG)
On 07/30/2013 01:46 PM, O. Hartmann wrote: I tried the new option options RDRAND_RNG on my SOHO server, equipted with a Intel i3-3220 Ivy Brdige CPU, which is supposed to have the Bull Mountain random number generator as a piece of hardware in its uncore. Enabling the kernel option doesn't reveal any presence of such a hardware number generator. sysct kern.random always reports kern.random.adaptors: yarrow By intentionally disallowing yarrow via commenting out options YARROW_RNG, the box reports no adaptors loaded. So, either this Ivy Bridge has been castrated and ripped off by Intel of its RNG or FreeBSD isn't capable of detecting it properly or I'm incapable of properly configure the kernel. This might be Erratum BV54: Problem: On processors that support the RDRAND instruction, that capability should be reported via the setting of CPUID.01H:ECX.RDRAND[bit 30]. Due to this erratum, that bit will not be set, and the execution of the RDRAND instruction will result in a #UD exception. Implication: Software will not be able to utilize the RDRAND instruction http://www.intel.de/content/dam/www/public/us/en/documents/specification-updates/3rd-gen-core-desktop-specification-update.pdf Julian ___ 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: bmake (installed as default make): make: illegal option -- J
On 05/17/2013 09:45 PM, Florent Peterschmitt wrote: Hi, With the r250749 revision of head, rebuilt world with make -j4 buildworld, all was fine. Then install new world, reboot and so: $ cd /usr/src $ make -j4 kernel --- buildkernel --- make: illegal option -- J usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable] [-d flags] [-E variable] [-f makefile] [-I directory] [-j max_jobs] [-m directory] [-V variable] [variable=value] [target ...] *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src This also affects building CURRENT from a 9.1 system. One workaround is to build without -j, but this is quite painful on an 8-core box. I tried using bmake from ports, but this fails, because the build system seems to have PATH hardcoded and it doesn't include /usr/local/bin. With `which bmake` -j8 buildworld it seems to work, though, but it is not finished compiling yet. Maybe a paragraph about the proper way to upgrade could be added to the UPDATING entry? Julian ___ 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: bmake (installed as default make): make: illegal option -- J
On 05/22/2013 01:05 PM, Julian Stecklina wrote: This also affects building CURRENT from a 9.1 system. One workaround is to build without -j, but this is quite painful on an 8-core box. I tried using bmake from ports, but this fails, because the build system seems to have PATH hardcoded and it doesn't include /usr/local/bin. With `which bmake` -j8 buildworld it seems to work, though, but it is not finished compiling yet. Fails when building /rescue, same as without absolute path. Julian ___ 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
Aliasing bug in FICL (may break loader with gcc4.4)
Hello,
while porting FICL, I noticed an aliasing bug which manifests (at least)
with gcc 4.4.2 and 4.4.3 when strict-aliasing is enabled. The root cause is
#define LVALUEtoCELL(v) (*(CELL *)v)
in sys/boot/ficl/ficl.h. CELL is a union:
typedef union _cell
{
FICL_INT i;
FICL_UNS u;
[...]
void *p;
void (*fn)(void);
} CELL;
If you compile the attached C file with gcc-4.4.3 and -O3, all stores to
i are optimized out and the result is bogus. A ficl built with this gcc
is inoperable.
Giving the union the may_alias attribute works around this, but is GCC
specific (patch is attached). Just using ((CELL)v) does not work without
casting all over the place or extending the union.
Regards, Julian
--
Actually I made up the term 'object-oriented', and I can tell you I
did not have C++ in mind. - Alan Kay (OOPSLA 1997 Keynote)
--- ficl.h 2010-02-15 18:46:27.020120933 +0100
+++ /home/julian/src/nova/ficl/ficl.h 2010-02-15 18:16:32.370312051 +0100
@@ -269,13 +269,17 @@
#endif
void *p;
void (*fn)(void);
-} CELL;
+} __attribute__((may_alias)) CELL;
/*
** LVALUEtoCELL does a little pointer trickery to cast any CELL sized
** lvalue (informal definition: an expression whose result has an
** address) to CELL. Remember that constants and casts are NOT
** themselves lvalues!
+**
+** XXX This only works as long as the strict-aliasing rule is
+** circumvented (see attribute above). Otherwise GCC 4.4 will
+** silently throw away v and just put garbage into the CELL.
*/
#define LVALUEtoCELL(v) (*(CELL *)v)
pgpxe1pn0ZTVW.pgp
Description: PGP signature
