[head tinderbox] failure on ia64/ia64
TB --- 2010-06-13 05:40:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 05:40:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-06-13 05:40:45 - cleaning the object tree TB --- 2010-06-13 05:40:57 - cvsupping the source tree TB --- 2010-06-13 05:40:57 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-06-13 05:41:33 - building world TB --- 2010-06-13 05:41:33 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 05:41:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 05:41:33 - TARGET=ia64 TB --- 2010-06-13 05:41:33 - TARGET_ARCH=ia64 TB --- 2010-06-13 05:41:33 - TZ=UTC TB --- 2010-06-13 05:41:33 - __MAKE_CONF=/dev/null TB --- 2010-06-13 05:41:33 - cd /src TB --- 2010-06-13 05:41:33 - /usr/bin/make -B buildworld World build started on Sun Jun 13 05:41:33 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/command.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/config.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/devices.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/dhcp.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/disks.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/disks.c: In function 'diskPartitionWrite': /src/usr.sbin/sysinstall/disks.c:877: warning: unused variable 'boot1' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 07:02:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 07:02:34 - ERROR: failed to build world TB --- 2010-06-13 07:02:34 - 3819.82 user 633.77 system 4909.10 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter ti...@cicely7.cicely.de writes: Dag-Erling Smørgrav d...@des.no writes: Bernd Walter ti...@cicely7.cicely.de writes: I'm not sure when removing a memset is allowed. Always, if the compiler can determine that the data will not be used later. I'm at least sure that the compiler can't if it is linked from another object file. When running in hosted mode, the compiler can *always* inline a memset() call or eliminate it if it can determine that the result is not used. The problem with memset is that the compiler has an internal implementation. That's a feature, not a problem. On the other hand I wonder what the deep sense is to clear memory which is unused later. I know that crypto code can be tricky sometimes, but if someone is willing to explain the specific reason my curiosity would be satified. You always overwrite passphrases, keys etc. as soon as you're done with them so they don't end up in a crash dump or on a swap disk or something. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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
[CFT] SIFTR - Statistical Information For TCP Research
Hi all, The time has come to solicit some external testing for my SIFTR tool. I'm hoping to commit it within a week or so unless problems are discovered. SIFTR is a kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. You can use the data to find bugs in the stack, understand why connections are performing badly and test new code to name a few uses. Development has been made possible in part by grants from the Cisco University Research Program Fund at Community Foundation Silicon Valley, and the FreeBSD Foundation. Bringing it into FreeBSD proper is being carried out under the auspices of the Enhancing the FreeBSD TCP Implementation FreeBSD Foundation project. More details are available at [1,2,3]. If you can help out, please read on! Before continuing, make sure you're running with at least svn revision 209119 (my commit to sys/pcpu.h), or you can manually apply the r209119 diff to to your earlier rev source tree. The SIFTR patch is here: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/siftr_9.x.r209119.patch Copy it to the root of your source tree and run the following: patch -p1 siftr_9.x.r209119.patch It's a loadable kernel module so you can build it for testing like so: cd path/to/src/sys/modules/siftr make kldload ./siftr.ko (don't forget to make cleandir to remove cruft when finished testing) After applying the patch, you can read the man page by running: man -M path/to/src/share/man siftr If I've done a decent job, all the info you need to understand what it does and how to use it should be in the man page. I'm interested in all feedback and reports of success/failure, along with details of the architecture tested and number of CPUs if you would be so kind. That should be enough to get the ball rolling. Thanks and I look forward to hearing from you! Cheers, Lawrence [1] http://caia.swin.edu.au/freebsd/etcp09/ [2] http://www.freebsdfoundation.org/projects.shtml#Swinburne [3] http://caia.swin.edu.au/urp/newtcp/ ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 12:17:50AM +, Bruce Cran wrote: On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote: I'm at least sure that the compiler can't if it is linked from another object file. Is that still true if LTO is enabled? Good question - I wasn't aware of LTO. My precondition was that the function doesn't see what is done with the result and LTO invalidates this. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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 sparc64/sparc64
TB --- 2010-06-13 07:39:07 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 07:39:07 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-06-13 07:39:07 - cleaning the object tree TB --- 2010-06-13 07:39:16 - cvsupping the source tree TB --- 2010-06-13 07:39:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-06-13 07:41:18 - building world TB --- 2010-06-13 07:41:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 07:41:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 07:41:18 - TARGET=sparc64 TB --- 2010-06-13 07:41:18 - TARGET_ARCH=sparc64 TB --- 2010-06-13 07:41:18 - TZ=UTC TB --- 2010-06-13 07:41:18 - __MAKE_CONF=/dev/null TB --- 2010-06-13 07:41:18 - cd /src TB --- 2010-06-13 07:41:18 - /usr/bin/make -B buildworld World build started on Sun Jun 13 07:41:18 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/install.c: In function 'installStandard': /src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs' /src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries' /src/usr.sbin/sysinstall/install.c: In function 'installFixupBase': /src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 08:41:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 08:41:25 - ERROR: failed to build world TB --- 2010-06-13 08:41:25 - 2730.92 user 569.55 system 3738.56 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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 powerpc/powerpc
TB --- 2010-06-13 07:11:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 07:11:24 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-06-13 07:11:24 - cleaning the object tree TB --- 2010-06-13 07:11:35 - cvsupping the source tree TB --- 2010-06-13 07:11:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-06-13 07:14:58 - building world TB --- 2010-06-13 07:14:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 07:14:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 07:14:58 - TARGET=powerpc TB --- 2010-06-13 07:14:58 - TARGET_ARCH=powerpc TB --- 2010-06-13 07:14:58 - TZ=UTC TB --- 2010-06-13 07:14:58 - __MAKE_CONF=/dev/null TB --- 2010-06-13 07:14:58 - cd /src TB --- 2010-06-13 07:14:58 - /usr/bin/make -B buildworld World build started on Sun Jun 13 07:14:59 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/install.c: In function 'installStandard': /src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs' /src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries' /src/usr.sbin/sysinstall/install.c: In function 'installFixupBase': /src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 08:52:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 08:52:42 - ERROR: failed to build world TB --- 2010-06-13 08:52:42 - 4778.73 user 734.32 system 6077.99 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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 sparc64/sun4v
TB --- 2010-06-13 07:57:08 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 07:57:08 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-06-13 07:57:08 - cleaning the object tree TB --- 2010-06-13 07:57:17 - cvsupping the source tree TB --- 2010-06-13 07:57:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-06-13 07:58:42 - building world TB --- 2010-06-13 07:58:42 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 07:58:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 07:58:42 - TARGET=sun4v TB --- 2010-06-13 07:58:42 - TARGET_ARCH=sparc64 TB --- 2010-06-13 07:58:42 - TZ=UTC TB --- 2010-06-13 07:58:42 - __MAKE_CONF=/dev/null TB --- 2010-06-13 07:58:42 - cd /src TB --- 2010-06-13 07:58:42 - /usr/bin/make -B buildworld World build started on Sun Jun 13 07:58:43 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/install.c: In function 'installStandard': /src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs' /src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries' /src/usr.sbin/sysinstall/install.c: In function 'installFixupBase': /src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 08:56:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 08:56:44 - ERROR: failed to build world TB --- 2010-06-13 08:56:44 - 2717.34 user 559.16 system 3575.33 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter: In more general terms, the compiler is allowed to make any changes it likes to the program as long as the end result behaves exactly like it would if it hadn't been changed. This is called the as if rule. For instance, if you call printf() or fprintf() with a format string that does not contain any conversion specifiers, gcc will call gets() or fgets() instead. Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Recently I had to implement my own atoi on a controller because using the library one magically had blown my RAM usage by 1k on a controller with just 8k RAM. There are certain compiler flags to affect that. For GCC, -Os is one (which doesn't necessarily work in FreeBSD though, on some versions the compiler would go into unterminated loop, leak memory and ultimately fail with OOM), flags to tell the compiler that the implementation is freestanding, and attributes to select builtins and the likes. -- Matthias Andree ___ 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: Our aging base system heimdal
Dnia 06.06.2010 b. f. bf1...@googlemail.com napisał/a: Is anybody planning to update the base system heimdal, which has been largely untouched since May 2008? In addition to the many other bug-fixes and improvements in the current version 1.3.3 (see, for example: I decided to give it a try. My first steup is to make it compile on FreeBSD. As you know, as of recently FreeBSD-current has no utmp.h You want at least 2 or 3 patches to make 1.3.3 useful: 1. The patch that fixes http access to the kdc 2. The patch that makes kxd work again 3. If your freebsd version needs strerror_r from libroken, the patch that fixes the broken call to strlcpy. Harald. ___ 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
wpa_supplicant update? CTRL-EVENT-SCAN-RESULTS
Hello. Is update of wpa_supplicant planned? Current version in STABLE as well as CURRENT (v0.6.8) is suffering from CTRL-EVENT-SCAN-RESULTS log spam. If it's the same problem, looks like it's fixed in v0.6.10 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539915 best regards, Jakub Lach -- View this message in context: http://old.nabble.com/wpa_supplicant-update--CTRL-EVENT-SCAN-RESULTS-tp28870665p28870665.html Sent from the freebsd-current mailing list archive at Nabble.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: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 12:44:03PM +0200, Matthias Andree wrote: Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter: In more general terms, the compiler is allowed to make any changes it likes to the program as long as the end result behaves exactly like it would if it hadn't been changed. This is called the as if rule. For instance, if you call printf() or fprintf() with a format string that does not contain any conversion specifiers, gcc will call gets() or fgets() instead. Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Recently I had to implement my own atoi on a controller because using the library one magically had blown my RAM usage by 1k on a controller with just 8k RAM. There are certain compiler flags to affect that. For GCC, -Os is one (which doesn't necessarily work in FreeBSD though, on some versions the compiler would go into unterminated loop, leak memory and ultimately fail with OOM), flags to tell the compiler that the implementation is freestanding, and attributes to select builtins and the likes. I know -Os - the problem was more complicated and at linker stage. It was because atoi sucked more hardly related library parts in, of which one had 1k static RAM requirement. Quite surprising outcome from using atoi. But this isn't related to FreeBSD at all, since it happened with newlibc. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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
[OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi yongari!
I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
I couldn't use mge1 like following. So I tried to investigate.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout
Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
I found a initialize issue in e1000phy.c.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
--- sys/dev/mii/e1000phy.c.orig 2010-05-01 10:17:15.282196000 +0900
+++ sys/dev/mii/e1000phy.c 2010-06-13 16:19:46.616650536 +0900
@@ -278,6 +278,7 @@
case MII_MODEL_MARVELL_E1118:
break;
case MII_MODEL_MARVELL_E1116:
+ case MII_MODEL_MARVELL_E1149:
page = PHY_READ(sc, E1000_EADR);
/* Select page 3, LED control register. */
PHY_WRITE(sc, E1000_EADR, 3);
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
I confirmed OK on my environment, OpenRD Ultimate has a 88E1121(I
saw it, physically):
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Jun 13 15:20:01 sidearms kernel: miibus0: miibus_probe: ma.mii_id1 = 0x141,
ma.mii_id2 = 0xcb3
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
And I confirmed that MII chipset ID is same as 88E1249.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
mge0
Marvell OBIO Memory:
4043776000-4043784191
Marvell OBIO IRQ:
11
12
13
14
46
miibus0
e1000phy0 pnpinfo oui=0x5043 model=0xb rev=0x3 at phyno=0
mge1
Marvell OBIO Memory:
4043792384-4043800575
Marvell OBIO IRQ:
15
16
17
18
47
miibus1
e1000phy1 pnpinfo oui=0x5043 model=0xb rev=0x3 at phyno=1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
BTW, I knew same issue on OpenRD Client, it has a 88E1116R, maybe.
Sorry, I don't already have it. I couldn't confirm.
So accordingly my memo:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
miibus0: ma.mii_id1 = 0x141, ma.mii_id2 = 0xe40
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
I found many initialize issues on 88E1116R by not existing on
e1000phy.c. Maybe 88E1116 = 88E1116R like following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
switch (esc-mii_model) {
case MII_MODEL_MARVELL_E:
case MII_MODEL_MARVELL_E1112:
case MII_MODEL_MARVELL_E1116:
+ case MII_MODEL_MARVELL_E1116R:
case MII_MODEL_MARVELL_E1118:
case MII_MODEL_MARVELL_E1149:
case MII_MODEL_MARVELL_PHYG65G:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
But there are many points, I don't know that this modify is right.
--
Hayabusa, Okaerinasai!
Norikatsu Shigemura n...@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: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter ti...@cicely7.cicely.de writes: Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Only if you break the rules. Bad code is always bad, even if it sometimes works by accident. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote: Bernd Walter ti...@cicely7.cicely.de writes: Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Only if you break the rules. Bad code is always bad, even if it sometimes works by accident. To expect that function calls are replaced with other functions isn't a very obvious rule. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter ti...@cicely7.cicely.de writes: Dag-Erling Smørgrav d...@des.no writes: Bernd Walter ti...@cicely7.cicely.de writes: Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Only if you break the rules. Bad code is always bad, even if it sometimes works by accident. To expect that function calls are replaced with other functions isn't a very obvious rule. You don't need to know that gcc replaces printf() with puts(). That's the whole point of the as-if rule: the compiler can only modify the program in ways that do not change observable behavior. The only way you can tell that gcc did it is if you break the rules, such as by defining your own version of printf() or puts(). DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
+---[ Bernd Walter ]-- | On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote: | Bernd Walter ti...@cicely7.cicely.de writes: | Amazing - this is one of the things which can get nasty if you try some | kind of microtuning. | | Only if you break the rules. Bad code is always bad, even if it | sometimes works by accident. | | To expect that function calls are replaced with other functions isn't a | very obvious rule. Don't turn on compiler optimisation then. You're explicitly telling the compiler to make your code better/faster/smaller. Optimisation flags always come with the caveat that your code may not work exactly the same... -- Andrew Milton a...@theinternet.com.au ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 06:14:11PM +0200, Dag-Erling Smørgrav wrote: Bernd Walter ti...@cicely7.cicely.de writes: Dag-Erling Smørgrav d...@des.no writes: Bernd Walter ti...@cicely7.cicely.de writes: Amazing - this is one of the things which can get nasty if you try some kind of microtuning. Only if you break the rules. Bad code is always bad, even if it sometimes works by accident. To expect that function calls are replaced with other functions isn't a very obvious rule. You don't need to know that gcc replaces printf() with puts(). That's the whole point of the as-if rule: the compiler can only modify the program in ways that do not change observable behavior. Well in ways the compiler _thinks_ it is not observeable. I'm not saying that it is doing wrong per definition, but if it is really not observeable and obvious we wouldn't need to talk about it. The only way you can tell that gcc did it is if you break the rules, such as by defining your own version of printf() or puts(). Our loader stages do this for good reasons. And in microcontroller programming (surely out of FreeBSD scope) it is done very regulary. All I say is that the rules are not obvious in many cases. Most people using compilers don't have the deep knowledge as you have. Of course we are talking about corner cases which most people also never have to face. In any case - I've learned something new. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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 ia64/ia64
TB --- 2010-06-13 16:32:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 16:32:45 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-06-13 16:32:45 - cleaning the object tree TB --- 2010-06-13 16:32:54 - cvsupping the source tree TB --- 2010-06-13 16:32:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-06-13 16:33:19 - building world TB --- 2010-06-13 16:33:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 16:33:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 16:33:19 - TARGET=ia64 TB --- 2010-06-13 16:33:19 - TARGET_ARCH=ia64 TB --- 2010-06-13 16:33:19 - TZ=UTC TB --- 2010-06-13 16:33:19 - __MAKE_CONF=/dev/null TB --- 2010-06-13 16:33:19 - cd /src TB --- 2010-06-13 16:33:19 - /usr/bin/make -B buildworld World build started on Sun Jun 13 16:33:20 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/command.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/config.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/devices.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/dhcp.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/disks.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/disks.c: In function 'diskPartitionWrite': /src/usr.sbin/sysinstall/disks.c:877: warning: unused variable 'boot1' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 17:54:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 17:54:01 - ERROR: failed to build world TB --- 2010-06-13 17:54:01 - 3812.89 user 610.40 system 4875.87 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ 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: wpa_supplicant update? CTRL-EVENT-SCAN-RESULTS
On 13 Jun 2010, at 04:23, Jakub Lach wrote: Hello. Is update of wpa_supplicant planned? Current version in STABLE as well as CURRENT (v0.6.8) is suffering from CTRL-EVENT-SCAN-RESULTS log spam. If it's the same problem, looks like it's fixed in v0.6.10 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=539915 I'll likely work on this soon. -- Rui Paulo ___ 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 sparc64/sparc64
TB --- 2010-06-13 18:27:13 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 18:27:13 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-06-13 18:27:13 - cleaning the object tree TB --- 2010-06-13 18:27:22 - cvsupping the source tree TB --- 2010-06-13 18:27:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-06-13 18:27:39 - building world TB --- 2010-06-13 18:27:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 18:27:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 18:27:39 - TARGET=sparc64 TB --- 2010-06-13 18:27:39 - TARGET_ARCH=sparc64 TB --- 2010-06-13 18:27:39 - TZ=UTC TB --- 2010-06-13 18:27:39 - __MAKE_CONF=/dev/null TB --- 2010-06-13 18:27:39 - cd /src TB --- 2010-06-13 18:27:39 - /usr/bin/make -B buildworld World build started on Sun Jun 13 18:27:40 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/install.c: In function 'installStandard': /src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs' /src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries' /src/usr.sbin/sysinstall/install.c: In function 'installFixupBase': /src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 19:28:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 19:28:26 - ERROR: failed to build world TB --- 2010-06-13 19:28:26 - 2727.27 user 566.72 system 3673.15 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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 powerpc/powerpc
TB --- 2010-06-13 18:00:52 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 18:00:52 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-06-13 18:00:52 - cleaning the object tree TB --- 2010-06-13 18:01:03 - cvsupping the source tree TB --- 2010-06-13 18:01:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-06-13 18:01:29 - building world TB --- 2010-06-13 18:01:29 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 18:01:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 18:01:29 - TARGET=powerpc TB --- 2010-06-13 18:01:29 - TARGET_ARCH=powerpc TB --- 2010-06-13 18:01:29 - TZ=UTC TB --- 2010-06-13 18:01:29 - __MAKE_CONF=/dev/null TB --- 2010-06-13 18:01:29 - cd /src TB --- 2010-06-13 18:01:29 - /usr/bin/make -B buildworld World build started on Sun Jun 13 18:01:29 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/install.c: In function 'installStandard': /src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs' /src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries' /src/usr.sbin/sysinstall/install.c: In function 'installFixupBase': /src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 19:39:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 19:39:23 - ERROR: failed to build world TB --- 2010-06-13 19:39:23 - 4768.15 user 723.59 system 5910.27 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ 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: wpa_supplicant update? CTRL-EVENT-SCAN-RESULTS
Rui Paulo-3 wrote: On 13 Jun 2010, at 04:23, Jakub Lach wrote: Hello. Is update of wpa_supplicant planned? I'll likely work on this soon. -- Rui Paulo That's splendid, thanks for fast reply. Is MFC to 8 feasible? regards, - Jakub Lach -- View this message in context: http://old.nabble.com/wpa_supplicant-update--CTRL-EVENT-SCAN-RESULTS-tp28870665p28873483.html Sent from the freebsd-current mailing list archive at Nabble.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
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-06-13 18:47:41 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-13 18:47:41 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-06-13 18:47:41 - cleaning the object tree TB --- 2010-06-13 18:47:51 - cvsupping the source tree TB --- 2010-06-13 18:47:51 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-06-13 18:48:10 - building world TB --- 2010-06-13 18:48:10 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-13 18:48:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-13 18:48:10 - TARGET=sun4v TB --- 2010-06-13 18:48:10 - TARGET_ARCH=sparc64 TB --- 2010-06-13 18:48:10 - TZ=UTC TB --- 2010-06-13 18:48:10 - __MAKE_CONF=/dev/null TB --- 2010-06-13 18:48:10 - cd /src TB --- 2010-06-13 18:48:10 - /usr/bin/make -B buildworld World build started on Sun Jun 13 18:48:11 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/index.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/install.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/install.c: In function 'installStandard': /src/usr.sbin/sysinstall/install.c:632: warning: unused variable 'devs' /src/usr.sbin/sysinstall/install.c:631: warning: unused variable 'tries' /src/usr.sbin/sysinstall/install.c: In function 'installFixupBase': /src/usr.sbin/sysinstall/install.c:877: warning: unused variable 'fp' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-13 19:46:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-13 19:46:16 - ERROR: failed to build world TB --- 2010-06-13 19:46:16 - 2716.34 user 551.34 system 3514.29 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full ___ 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: wpa_supplicant update? CTRL-EVENT-SCAN-RESULTS
On 13 Jun 2010, at 12:40, Jakub Lach wrote: Rui Paulo-3 wrote: On 13 Jun 2010, at 04:23, Jakub Lach wrote: Hello. Is update of wpa_supplicant planned? I'll likely work on this soon. -- Rui Paulo That's splendid, thanks for fast reply. Is MFC to 8 feasible? Possibly, but it won't make it in time for 8.1. -- Rui Paulo ___ 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: wpa_supplicant update? CTRL-EVENT-SCAN-RESULTS
Rui Paulo-3 wrote: On 13 Jun 2010, at 12:40, Jakub Lach wrote: Rui Paulo-3 wrote: On 13 Jun 2010, at 04:23, Jakub Lach wrote: Hello. Is update of wpa_supplicant planned? I'll likely work on this soon. -- Rui Paulo That's splendid, thanks for fast reply. Is MFC to 8 feasible? Possibly, but it won't make it in time for 8.1. That's understandable, I track STABLE anyway (since 8 became STABLE as a matter of fact). regards, - Jakub Lach -- View this message in context: http://old.nabble.com/wpa_supplicant-update--CTRL-EVENT-SCAN-RESULTS-tp28870665p28873587.html Sent from the freebsd-current mailing list archive at Nabble.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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
On 2010-06-13 23:37:23 (+0900), Norikatsu Shigemura n...@freebsd.org wrote:
Hi yongari!
I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
I couldn't use mge1 like following. So I tried to investigate.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout
Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
I believe the mge(4) driver incorrectly configures the PHY address for
the second interface. Can you give the attached patch a try?
I'm not familiar with the PHY code so I won't comment on those changes.
Regards,
Kristof
Index: sys/dev/mge/if_mge.c
===
--- sys/dev/mge/if_mge.c (revision 208113)
+++ sys/dev/mge/if_mge.c (working copy)
@@ -606,7 +606,6 @@
mge_attach(device_t dev)
{
struct mge_softc *sc;
- struct mii_softc *miisc;
struct ifnet *ifp;
uint8_t hwaddr[ETHER_ADDR_LEN];
int i, error ;
@@ -690,9 +689,9 @@
}
sc-mii = device_get_softc(sc-miibus);
- /* Tell the MAC where to find the PHY so autoneg works */
- miisc = LIST_FIRST(sc-mii-mii_phys);
- MGE_WRITE(sc, MGE_REG_PHYDEV, miisc-mii_phy);
+ /* Tell the MAC where to find the PHY so autoneg works
+ * We assume a static mapping (see mge_miibus_readreg) */
+ MGE_WRITE(sc, MGE_REG_PHYDEV, device_get_unit(dev) + MII_ADDR_BASE);
/* Attach interrupt handlers */
for (i = 0; i 2; ++i) {
___
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
two buildworld problems
hi there. i'm experiencing two problems during buildworld. i'm not sure if these are the result of me doing weird stuff or a problem in the src structure: 1. i have the following in my make.conf: .if empty(.CURDIR:M/usr/src/*) empty(.CURDIR:M/usr/obj/*) exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif this should make sure that anywhere outside of /usr/src and /usr/obj gcc44 should be used instead of the base gcc. however during buidlworld i get: === libvers (installincludes)^M cd /usr/src/usr.bin/lex/lib; MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/usr/src/lib32 VERSION=FreeBSD 9.0-CURRENT amd64 900013 MACHINE=i386 MACHINE_ARCH=i386 MACHINE_CPU=i686 mmx sse sse2 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tm /usr/obj/lib32/usr/src/usr.bin/lex/lib created for /usr/src/usr.bin/lex/lib^M cd /usr/src/lib/ncurses/ncurses; MAKEOBJDIRPREFIX=/usr/obj/lib32 /usr/obj/usr/src/make.amd64/make SSP_CFLAGS= DESTDIR= build-tools^M sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKhashsize.sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps hashsize.h^M AWK=awk sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKncurses_def.sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/ncurses_defs ncurses_def.h^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/curses.h.in curses.head -e /@BROKEN_LINKER@/s%%0% -e /@HAVE_VSSCANF@/s%%1% -e /@NCURSES_CH_T@/s%%chtype% -e /@NCURSES_CONST@/s%%const% -e /@NCURSES_EXT_COLORS@/s%%0% -e /@NCURSES_EXT_FUNCS@/s cat curses.head curses.h.new^M AWK=awk _POSIX2_VERSION=199209 sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKkey_defs.sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps curses.h.new^M cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/curses.tail curses.h.new^M mv -f curses.h.new curses.h^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKterm.h.awk.in MKterm.h.awk -e /@BROKEN_LINKER@/s%%0% -e /@NCURSES_MAJOR@/s%%5% -e /@NCURSES_MINOR@/s%%7% -e /@NCURSES_CONST@/s%%const% -e /@NCURSES_TPARM_VARARGS@/s%%1% -e /@NCURSES_SBOOL@/ awk -f MKterm.h.awk /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps term.h.new^M sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/edit_cfg.sh /usr/src/lib/ncurses/ncurses/ncurses_cfg.h term.h.new^M ** edit: HAVE_TCGETATTR 1^M ** edit: HAVE_TERMIOS_H 1^M ** edit: HAVE_TERMIO_H 0^M ** edit: BROKEN_LINKER 0^M mv -f term.h.new term.h^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/termcap.h.in termcap.h -e /@NCURSES_MAJOR@/s%%5% -e /@NCURSES_MINOR@/s%%7% -e /@NCURSES_CONST@/s%%const% -e /@NCURSES_OSPEED@/s%%short%^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/unctrl.h.in unctrl.h -e /@NCURSES_MAJOR@/s%%5% -e /@NCURSES_MINOR@/s%%7%^M cc -o make_hash -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ awk -f /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/MKnames.awk bigstrings=1 /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps names.c^M cc -o make_keys -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ cd /usr/src/lib/ncurses/ncursesw; MAKEOBJDIRPREFIX=/usr/obj/lib32 /usr/obj/usr/src/make.amd64/make SSP_CFLAGS= DESTDIR= build-tools^M sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/MKhashsize.sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/Caps hashsize.h^M AWK=awk sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/MKncurses_def.sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/ncurses_defs ncurses_def.h^M cc -o make_hash -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncursesw/../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncurses -I/usr/src/ awk -f /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/MKnames.awk bigstrings=1 /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/Caps names.c^M cc -o make_keys -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncursesw/../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncurses -I/usr/src/ cd /usr/src/lib/libmagic; MAKEOBJDIRPREFIX=/usr/obj/lib32 /usr/obj/usr/src/make.amd64/make SSP_CFLAGS=
Re: two buildworld problems
On Jun 13, 2010, at 3:28 PM, Alexander Best wrote: hi there. i'm experiencing two problems during buildworld. i'm not sure if these are the result of me doing weird stuff or a problem in the src structure: 1. i have the following in my make.conf: .if empty(.CURDIR:M/usr/src/*) empty(.CURDIR:M/usr/obj/*) exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif this should make sure that anywhere outside of /usr/src and /usr/obj gcc44 should be used instead of the base gcc. however during buidlworld i get: I noticed the same thing on my system today. 2. if i set CC=cc (or clang) CXX=c++ (or clang) CPP=cpp (or clang) in src.conf buildworld fails with this error: My buildworld breaks in a different place at the beginning of the build process. My last successful build was r208970. === lib/clang/libllvmsupport (obj,depend,all,install) /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for /usr/src/lib/clang/libllvmsupport rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regcomp.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regerror.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regexec.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regfree.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regstrlcpy.c mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APInt.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APSInt.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Allocator.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/CommandLine.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConstantRange.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Debug.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/DeltaAlgorithm.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Dwarf.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ErrorHandling.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FileUtilities.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FoldingSet.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FormattedStream.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/GraphWriter.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IsInf.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/IsNAN.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ManagedStatic.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/MemoryBuffer.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/MemoryObject.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/PluginLoader.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/PrettyStackTrace.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Regex.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SlowOperationInformer.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SmallPtrSet.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SmallVector.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SourceMgr.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Statistic.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringExtras.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringMap.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringPool.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/StringRef.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/SystemUtils.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/TargetRegistry.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Timer.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Triple.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Twine.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/circular_raw_ostream.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_os_ostream.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_ostream.cpp /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15:30: error: llvm/ADT/APFloat.h: No such file or
Re: two buildworld problems
On Sun, Jun 13, 2010 at 10:28 PM, Alexander Best alexbes...@uni-muenster.de wrote: hi there. i'm experiencing two problems during buildworld. i'm not sure if these are the result of me doing weird stuff or a problem in the src structure: 1. i have the following in my make.conf: .if empty(.CURDIR:M/usr/src/*) empty(.CURDIR:M/usr/obj/*) exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif this should make sure that anywhere outside of /usr/src and /usr/obj gcc44 should be used instead of the base gcc. however during buidlworld i get: === libvers (installincludes)^M cd /usr/src/usr.bin/lex/lib; MAKEOBJDIRPREFIX=/usr/obj/lib32 _SHLIBDIRPREFIX=/usr/obj/usr/src/lib32 VERSION=FreeBSD 9.0-CURRENT amd64 900013 MACHINE=i386 MACHINE_ARCH=i386 MACHINE_CPU=i686 mmx sse sse2 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/tm /usr/obj/lib32/usr/src/usr.bin/lex/lib created for /usr/src/usr.bin/lex/lib^M cd /usr/src/lib/ncurses/ncurses; MAKEOBJDIRPREFIX=/usr/obj/lib32 /usr/obj/usr/src/make.amd64/make SSP_CFLAGS= DESTDIR= build-tools^M sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKhashsize.sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps hashsize.h^M AWK=awk sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKncurses_def.sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/ncurses_defs ncurses_def.h^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/curses.h.in curses.head -e /@BROKEN_LINKER@/s%%0% -e /@HAVE_VSSCANF@/s%%1% -e /@NCURSES_CH_T@/s%%chtype% -e /@NCURSES_CONST@/s%%const% -e /@NCURSES_EXT_COLORS@/s%%0% -e /@NCURSES_EXT_FUNCS@/s cat curses.head curses.h.new^M AWK=awk _POSIX2_VERSION=199209 sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKkey_defs.sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps curses.h.new^M cat /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/curses.tail curses.h.new^M mv -f curses.h.new curses.h^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKterm.h.awk.in MKterm.h.awk -e /@BROKEN_LINKER@/s%%0% -e /@NCURSES_MAJOR@/s%%5% -e /@NCURSES_MINOR@/s%%7% -e /@NCURSES_CONST@/s%%const% -e /@NCURSES_TPARM_VARARGS@/s%%1% -e /@NCURSES_SBOOL@/ awk -f MKterm.h.awk /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps term.h.new^M sh /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/edit_cfg.sh /usr/src/lib/ncurses/ncurses/ncurses_cfg.h term.h.new^M ** edit: HAVE_TCGETATTR 1^M ** edit: HAVE_TERMIOS_H 1^M ** edit: HAVE_TERMIO_H 0^M ** edit: BROKEN_LINKER 0^M mv -f term.h.new term.h^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/termcap.h.in termcap.h -e /@NCURSES_MAJOR@/s%%5% -e /@NCURSES_MINOR@/s%%7% -e /@NCURSES_CONST@/s%%const% -e /@NCURSES_OSPEED@/s%%short%^M sed /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/unctrl.h.in unctrl.h -e /@NCURSES_MAJOR@/s%%5% -e /@NCURSES_MINOR@/s%%7%^M cc -o make_hash -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ awk -f /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/tinfo/MKnames.awk bigstrings=1 /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps names.c^M cc -o make_keys -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../ncurses -I/usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/ cd /usr/src/lib/ncurses/ncursesw; MAKEOBJDIRPREFIX=/usr/obj/lib32 /usr/obj/usr/src/make.amd64/make SSP_CFLAGS= DESTDIR= build-tools^M sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/MKhashsize.sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/Caps hashsize.h^M AWK=awk sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/MKncurses_def.sh /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/ncurses_defs ncurses_def.h^M cc -o make_hash -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncursesw/../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncursesw -I/usr/src/lib/ncurses/ncursesw/../ncurses -I/usr/src/ awk -f /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/ncurses/tinfo/MKnames.awk bigstrings=1 /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/Caps names.c^M cc -o make_keys -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -D_XOPEN_SOURCE_EXTENDED -DENABLE_WIDEC -I. -I/usr/obj/lib32/usr/src/lib/ncurses/ncursesw/../ncursesw
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
On Mon, Jun 14, 2010 at 02:20:26AM +1000, Andrew Milton wrote: +---[ Bernd Walter ]-- | On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote: | Bernd Walter ti...@cicely7.cicely.de writes: | Amazing - this is one of the things which can get nasty if you try some | kind of microtuning. | | Only if you break the rules. Bad code is always bad, even if it | sometimes works by accident. | | To expect that function calls are replaced with other functions isn't a | very obvious rule. Don't turn on compiler optimisation then. You're explicitly telling the compiler to make your code better/faster/smaller. Optimisation flags always come with the caveat that your code may not work exactly the same... This isn't helpfull at all. Yes - we can disable everything and have nothing after all including nothing unexpected. In Germany we say Kind mit dem Bade auschütten. With other words you throw all the good things away just to catch a single bad point. Optimization isn't bad as such, but it is influencing more and more things, which could be considered save before. It is important to know which parts can be considered save in future and how it can be ensured. And don't tell me in the early/mid 90th anyone has ever expected compilers to optimize at the same level they do today. LTO was a very interesting new area because before that compilers never touched anything outside it's own scope. printf = puts isn't that amazing if you consider printf to be a puts consumer which is just shrink to nothing, but I understood Dags point that this was not the end of function exchange to expect. Volatile is also a very strong mechanism and often it is enough to just cast a variable volatile in a specific context as done in the macro of this thread - instead of just defining it volatile for every use as was suggested as well. Compilier optimization is even required in many cases to get decent performance or in small environments to get it small enough to fit into memory at all, but this doesn't mean it is what you want in every case. The wish to wipe out sensitive data in crypto code is very reasonable, but this doesn't mean disabling optimzation is the way to go. So far there isn't a save solution to use memset to wipe out a whole block of memory. Go back to the originating mail. Crypto code wasn't aware of this problem and this is a way more obviuous optimization than function exchange. And I do believe that the programmers were clever people. Alarming, isn't it? Maybe paranoid users might consider compiling their OS with -O0, but I don't think this is the right way. It is amazing how strong the influence of optimization is and how weak the programmers assumptions are. The thread is about how to handle optimization in corner cases and not to disable it. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
Bernd Walter ti...@cicely7.cicely.de writes: Dag-Erling Smørgrav d...@des.no writes: The only way you can tell that gcc did it is if you break the rules, such as by defining your own version of printf() or puts(). Our loader stages do this for good reasons. And in microcontroller programming (surely out of FreeBSD scope) it is done very regulary. Those are freestanding environments, where printf() and puts() don't exist as far as the C standard is concerned. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: two buildworld problems
Alexander, * Alexander Best alexbes...@uni-muenster.de wrote: .if empty(.CURDIR:M/usr/src/*) empty(.CURDIR:M/usr/obj/*) exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif Try /usr/local/bin/gcc44. The FreeBSD build infrastructure overrides PATH to prevent accidental use of local tools. 2. if i set CC=cc (or clang) CXX=c++ (or clang) CPP=cpp (or clang) in src.conf buildworld fails with this error: I can't say what's going on here, but keep in mind that you shouldn't set CXX to clang, but clang++. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpnEEOF3tFhp.pgp Description: PGP signature
Re: Cleanup for cryptographic algorithms vs. compiler optimizations
Le Sun, 13 Jun 2010 23:35:12 +0200, Bernd Walter ti...@cicely7.cicely.de a écrit : Go back to the originating mail. Crypto code wasn't aware of this problem and this is a way more obviuous optimization than function exchange. And I do believe that the programmers were clever people. Alarming, isn't it? The removal of dead store by gcc is recent. There was a discussion about this problem on the linux crypto mailing list, see: http://www.mail-archive.com/linux-cry...@vger.kernel.org/msg04229.html If i remember well, they have introduced a secure_memset() function or something like that, but I do not find this piece of code any more. Regards. ___ 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: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 11:41:03PM +0200, Dag-Erling Smørgrav wrote: Bernd Walter ti...@cicely7.cicely.de writes: Dag-Erling Smørgrav d...@des.no writes: The only way you can tell that gcc did it is if you break the rules, such as by defining your own version of printf() or puts(). Our loader stages do this for good reasons. And in microcontroller programming (surely out of FreeBSD scope) it is done very regulary. Those are freestanding environments, where printf() and puts() don't exist as far as the C standard is concerned. Most controller environments have some kind of libc. We even have devel/avr-libc and devel/msp430-libc in ports. Anyway - printf=puts isn't scarying as such, it is more that this might happen in other cases as well. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: two buildworld problems
On Sun, Jun 13, 2010 at 11:46 PM, Ed Schouten e...@80386.nl wrote: Alexander, * Alexander Best alexbes...@uni-muenster.de wrote: .if empty(.CURDIR:M/usr/src/*) empty(.CURDIR:M/usr/obj/*) exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif Try /usr/local/bin/gcc44. The FreeBSD build infrastructure overrides PATH to prevent accidental use of local tools. hmmm...but i thought during buildworld either empty(.CURDIR:M/usr/src/*) or empty(.CURDIR:M/usr/obj/*) should be false. so CC/CXX/CPP should never actually be set during buildworld or buildkernel. cheers. alex 2. if i set CC=cc (or clang) CXX=c++ (or clang) CPP=cpp (or clang) in src.conf buildworld fails with this error: I can't say what's going on here, but keep in mind that you shouldn't set CXX to clang, but clang++. thanks for the hint. i'll try and see if that works. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ -- Alexander Best ___ 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: two buildworld problems
On 06/13/10 15:58, Alexander Best wrote: hmmm...but i thought during buildworld either empty(.CURDIR:M/usr/src/*) or empty(.CURDIR:M/usr/obj/*) should be false. so CC/CXX/CPP should never actually be set during buildworld or buildkernel. That depends, are /usr/src and /usr/obj literally directories in the /usr/ filesystem? -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: two buildworld problems
On Mon, Jun 14, 2010 at 1:02 AM, Doug Barton do...@freebsd.org wrote: On 06/13/10 15:58, Alexander Best wrote: hmmm...but i thought during buildworld either empty(.CURDIR:M/usr/src/*) or empty(.CURDIR:M/usr/obj/*) should be false. so CC/CXX/CPP should never actually be set during buildworld or buildkernel. That depends, are /usr/src and /usr/obj literally directories in the /usr/ filesystem? `mount -p stat -x /usr/src /usr/obj`: /dev/ufs/rootfs / ufs noatime 1 1 devfs /devdevfs rw 0 0 procfs /proc procfs rw 0 0 linprocfs /usr/compat/linux/proc linprocfs rw 0 0 linsysfs/usr/compat/linux/sys linsysfsrw 0 0 devfs /usr/compat/linux/dev devfs rw 0 0 linprocfs /usr/local/gentoo-stage3/proc linprocfs rw 0 0 linsysfs/usr/local/gentoo-stage3/sys linsysfs rw 0 0 devfs /usr/local/gentoo-stage3/dev devfs rw 0 0 tmpfs /tmptmpfs rw 0 0 /dev/cd0/media/dvd cd9660 ro,nosuid 0 0 File: /usr/src Size: 1024 FileType: Directory Mode: (0775/drwxrwxr-x) Uid: (0/root) Gid: (0/ wheel) Device: 0,93 Inode: 6854420Links: 23 Access: Tue Jun 8 03:06:08 2010 Modify: Sun Jun 13 23:02:23 2010 Change: Sun Jun 13 23:02:23 2010 File: /usr/obj Size: 512 FileType: Directory Mode: (0755/drwxr-xr-x) Uid: (0/root) Gid: (0/ wheel) Device: 0,93 Inode: 6830264Links: 3 Access: Thu Jun 10 01:32:19 2010 Modify: Sun Jun 13 23:08:27 2010 Change: Sun Jun 13 23:08:27 2010 -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -- Alexander Best ___ 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: two buildworld problems
On 06/13/10 16:21, Alexander Best wrote: `mount -p stat -x /usr/src /usr/obj`: wow, completely unhelpful. So let me try again. If the /usr/src and /usr/obj are not literal directories in /usr then the tests you posted won't work. Given what you've posted so far I strongly suspect that there is something in your environment that is more complicated than it needs to be, which is why you're running into the problems that you are. So to debug it I would suggest that you move make.conf out of the way, then try again without one. If that works, then you can gradually add things back until you find the culprit. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: two buildworld problems
On Mon, Jun 14, 2010 at 1:28 AM, Doug Barton do...@freebsd.org wrote: On 06/13/10 16:21, Alexander Best wrote: `mount -p stat -x /usr/src /usr/obj`: wow, completely unhelpful. So let me try again. If the /usr/src and /usr/obj are not literal directories in /usr then the tests you posted won't work. Given what you've posted so far I strongly suspect that there is something in your environment that is more complicated than it needs to be, which is why you're running into the problems that you are. oh sorry for that. if i comment out all the gcc44 stuff in my make.conf and don't set CC/CXX/CPP in src.conf everything works fine. any suggestions what i should put into my make.conf so that gcc44 only gets picked when the current directory is not /usr/src/* or /usr/obj/*? as you pointed out empty(.CURDIR:M/usr/src/*) and empty(.CURDIR:M/usr/obj/*) aren't doing what i want. actually i just modified this .if !empty(.CURDIR:M/usr/ports/*) exists(/usr/local/bin/gcc44) CC=gcc44 CXX=g++44 CPP=cpp44 .endif which was suggested over @ http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html cheers. So to debug it I would suggest that you move make.conf out of the way, then try again without one. If that works, then you can gradually add things back until you find the culprit. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -- Alexander Best ___ 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
Protecting sensitive data [was Re: Cleanup for cryptographic algorithms vs. compiler optimizations]
On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav d...@des.no wrote: You always overwrite passphrases, keys etc. as soon as you're done with them so they don't end up in a crash dump or on a swap disk or something. Which brings up an associated issue: By default, mlock(2) can only be used by root processes. It would be really handy if non-privileged processes could lock small amounts of VM so they can securely handle passwords, passphrases, keys, etc. MAC offers the option of allowing non-root processes access to mlock() but doesn't provide any restrictions on the amount of memory they can lock. -- Peter Jeremy pgp2LOL7MFufA.pgp Description: PGP signature
Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 06/01/10 08:26, John Baldwin wrote: I've asked the driver author if the calls to vm_page_wire() and vm_page_unwire() can simply be removed but have not heard back yet. Is there any news on this? I have updated to the latest current so I'm running the nv driver now, but I'd like to get the nvidia driver running again. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: Cleanup for cryptographic algorithms vs. compiler optimizations
On Sun, Jun 13, 2010 at 11:35 PM, Bernd Walter ti...@cicely7.cicely.de wrote: Crypto code wasn't aware of this problem and this is a way more obviuous optimization than function exchange. And I do believe that the programmers were clever people. Alarming, isn't it? Maybe paranoid users might consider compiling their OS with -O0, but I don't think this is the right way. I think that most crypto code isn't compiled with strong optimizations anyway, even when the rest of the OS or program is (or can be). After all, we do have separate compilation units... as long as you don't enable LTO, of course. Turning off strong optimizations for crypto code may seem paradoxical, but since most performance-critical routines often contain hand-optimized assembly anyway, and compiler-optimizations may be counter-productive here, the point is rather moot, usually. It is amazing how strong the influence of optimization is and how weak the programmers assumptions are. Indeed. That's a classic trap that trips a lot of crypto programmers in particular, and even seasoned C programmers occasionally. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: Protecting sensitive data [was Re: Cleanup for cryptographic algorithms vs. compiler optimizations]
2010/6/14 Peter Jeremy peterjer...@acm.org: On 2010-Jun-13 10:07:15 +0200, Dag-Erling Smørgrav d...@des.no wrote: You always overwrite passphrases, keys etc. as soon as you're done with them so they don't end up in a crash dump or on a swap disk or something. Which brings up an associated issue: By default, mlock(2) can only be used by root processes. It would be really handy if non-privileged processes could lock small amounts of VM so they can securely handle passwords, passphrases, keys, etc. MAC offers the option of allowing non-root processes access to mlock() but doesn't provide any restrictions on the amount of memory they can lock. Interesting! From an admin point of view, this behavior could them be enabled or disabled via sysctl(8), and this sysctl variable could define what small means exactly (#nr of pages per process maybe?) Another sysctl variable should probably define how many pages can be locked in general by all non-privileged processes, to prevent malicious programs like fork bombs to mlock the whole memory. Peter Jeremy -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On Sun, Jun 13, 2010 at 8:38 PM, Doug Barton do...@freebsd.org wrote: On 06/01/10 08:26, John Baldwin wrote: I've asked the driver author if the calls to vm_page_wire() and vm_page_unwire() can simply be removed but have not heard back yet. Is there any news on this? I have updated to the latest current so I'm running the nv driver now, but I'd like to get the nvidia driver running again. Yes, the unnecessary (and now problematic) wiring and unwiring calls will be removed in a future release of the driver. Alan ___ 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: [bsdtar] strange compression with ^T command
Thanks for the report! This was caused by an overflow in the compression calculation when the in bytes was larger than the out bytes. I just committed a fix as r209152. Tim Boris Samorodov wrote: Hi! - % uname -a FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #4 r208799: Fri Jun 4 13:58:47 MSD 2010 b...@host.ipt.ru:/storage/obj/storage/src/sys/HOST i386 % make extract === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE === Extracting for eric5-5.0.0 = No checksum file (/m/home/bsam/shared/FreeBSD/exp/eric5/devel/eric5/distinfo). load: 6.85 cmd: bsdtar 68052 [runnable] 131.55r 0.03u 0.30s 0% 2044k In: 17512980 bytes, compression 1290122025%; Out: 1502 files, 17509012 bytes Current: eric5-5.0.0-RC1/eric/icons/default/drawEraser.png (1172 bytes) load: 6.96 cmd: gzip 68051 [pipdwt] 150.90r 0.16u 0.00s 0% 1052k In: 24466168 bytes, compression -1782936608%; Out: 1821 files, 24460918 bytes Current: eric5-5.0.0-RC1/eric/E5Gui/E5SingleApplication.py (4726 bytes) % - One can get the file to experiment: - % fetch http://heanet.dl.sourceforge.net/project/eric-ide/eric5/stable/5.0.0-RC1/eric5-5.0.0-RC1.tar.gz - Extracted files seems to be OK. ___ 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: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
On 06/13/10 19:09, Alan Cox wrote: On Sun, Jun 13, 2010 at 8:38 PM, Doug Bartondo...@freebsd.org wrote: On 06/01/10 08:26, John Baldwin wrote: I've asked the driver author if the calls to vm_page_wire() and vm_page_unwire() can simply be removed but have not heard back yet. Is there any news on this? I have updated to the latest current so I'm running the nv driver now, but I'd like to get the nvidia driver running again. Yes, the unnecessary (and now problematic) wiring and unwiring calls will be removed in a future release of the driver. Excellent! Any ETA? Or are there patches against an existing version of the driver? Thanks, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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
[head tinderbox] failure on ia64/ia64
TB --- 2010-06-14 03:23:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-14 03:23:02 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-06-14 03:23:02 - cleaning the object tree TB --- 2010-06-14 03:23:11 - cvsupping the source tree TB --- 2010-06-14 03:23:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-06-14 03:23:54 - building world TB --- 2010-06-14 03:23:54 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-14 03:23:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-14 03:23:54 - TARGET=ia64 TB --- 2010-06-14 03:23:54 - TARGET_ARCH=ia64 TB --- 2010-06-14 03:23:54 - TZ=UTC TB --- 2010-06-14 03:23:54 - __MAKE_CONF=/dev/null TB --- 2010-06-14 03:23:54 - cd /src TB --- 2010-06-14 03:23:54 - /usr/bin/make -B buildworld World build started on Mon Jun 14 03:23:55 UTC 2010 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 [...] cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/command.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/config.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/devices.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/dhcp.c cc -O2 -pipe -DUSE_GZIP=1 -fno-strict-aliasing -I/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/sysinstall/disks.c cc1: warnings being treated as errors /src/usr.sbin/sysinstall/disks.c: In function 'diskPartitionWrite': /src/usr.sbin/sysinstall/disks.c:877: warning: unused variable 'boot1' *** Error code 1 Stop in /src/usr.sbin/sysinstall. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-14 04:46:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-14 04:46:10 - ERROR: failed to build world TB --- 2010-06-14 04:46:10 - 3844.49 user 638.02 system 4988.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ 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: two buildworld problems
* Alexander Best alexbes...@uni-muenster.de wrote: CC=gcc44 CXX=g++44 CPP=cpp44 As I mentioned before, gcc44 and /usr/local/bin/gcc44 are spelled differently. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpCgGKibtSmx.pgp Description: PGP signature
