Re: numeric sort(1) is broken on -STABLE
On Thu, Feb 11, 2010 at 08:40:51AM +0100, Ulrich Spörlein wrote: On Wed, 10.02.2010 at 15:00:07 -0600, Dan Nelson wrote: In the last episode (Feb 10), Ulrich Spörlein said: On Wed, 10.02.2010 at 13:49:05 +0300, Ruslan Ermilov wrote: On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: not sure if this is a pilot error, but it seems to me that gnu sort -n is broken on at least -STABLE (couldn't test -CURRENT yet). It somehow does not manifest when using a simple list and sorting on a specific column, but it always happens to me when using it in combination with find(1). % truncate -s10m a; truncate -s5m b; truncate -s800k c % find a b c -ls|sort -nk7,7 8 64 -rw-r--r--1 uqs wheel 10485760 Feb 10 09:13 a 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c I bet you're using some non-C locale for LC_NUMERIC. What does locale output tell you? Yes and no. LC_NUMERIC is still at C, LC_CTYPE is set to UTF-8, but as there are no non-ASCII symbols in that output it shouldn't matter, right? For me, 819200 is smaller than 10485760 in pretty much all locales. Why the hell is a numeric gnusort locale dependant? Why is -g working anyway? Try adding a 'b' to your sort flags. I bet the leading spaces in front of your numbers are being treated as part of the sort key. Maybe de_DE.UTF-8 and C have different ideas of what is whitespace? Indeed, 'b' is working too. So I've stocked up on the number of workarounds for this problem. What amazes me, is that no one seems to be as shocked as I to find out something basic like sorting on a number is not DTRT. It is a long standing issue with Russian locales as well, but there the problem manifests itself only with LC_NUMERIC, not LC_CTYPE. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: numeric sort(1) is broken on -STABLE
On Wed, Feb 10, 2010 at 09:58:14AM +0100, Ulrich Spörlein wrote: Hi guys, not sure if this is a pilot error, but it seems to me that gnu sort -n is broken on at least -STABLE (couldn't test -CURRENT yet). It somehow does not manifest when using a simple list and sorting on a specific column, but it always happens to me when using it in combination with find(1). % truncate -s10m a; truncate -s5m b; truncate -s800k c % find a b c -ls|sort -nk7,7 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c I bet you're using some non-C locale for LC_NUMERIC. What does locale output tell you? % find a b c -ls|sort -gk7,7 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a at least -g does what is expected and I can work around this for the time being. Here's bsdsort % find a b c -ls|bsdsort -nk7,7 12 64 -rw-r--r--1 uqs wheel 819200 Feb 10 09:13 c 10 64 -rw-r--r--1 uqs wheel 5242880 Feb 10 09:13 b 8 64 -rw-r--r--1 uqs wheel10485760 Feb 10 09:13 a and this is on Solaris 8 % find a b c -ls|sort -nk7,7 546728 16 -rw-r--r-- 1 spoerul xxx819200 Feb 10 09:49 c 546727 16 -rw-r--r-- 1 spoerul xxx 5242880 Feb 10 09:48 b 546724 16 -rw-r--r-- 1 spoerul xxx 10485760 Feb 10 09:48 a It even occured to me, that we don't have a sort regression suite under tools/regression. Anyone know a place to find one with a suitable license? Regards, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange symbols in man-pages
On Sun, Jan 24, 2010 at 10:49:34AM +0300, Ruslan Mahmatkhanov wrote: On 24.01.2010 04:45, Jeremy Chadwick wrote: On Sat, Jan 23, 2010 at 11:34:14PM +0300, Ruslan Mahmatkhanov wrote: I'm viewing dd man-page in gnome with gnome-terminal and i see some strange symbols instead `-`. For example from man dd(1): http://www.onlinedisk.ru/get_image.php?id=327964 The problem is rised only when i on ru_RU.UTF-8 locale. There is no problem with C-locale. Is this known problem and does anybody have a solution? Thanks in advance and keep me in Cc: please (i'm not subscribed to freebsd-stable@). PS. Using 8.0-STABLE. http://lists.freebsd.org/pipermail/freebsd-stable/2010-January/053804.html So i can avoid this by setting alias in .cshrc: alias man env LANG=C man Thanks. I've fixed this recently. -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: netstat output changes in 8.0?
On Mon, Jan 25, 2010 at 07:01:46PM -0800, Nick Rogers wrote:
Before 8.0-RELEASE, if I ran netstat -rn, it listed a separate route for
each host on the network, along with its MAC address. For example ...
172.20.172.17 00:02:b3:2f:64:6a UHLW1 105712 1500
vlan172595
172.20.172.20 00:1e:c9:bb:7c:a9 UHLW1 1002 1500
vlan172598
172.20.172.22 00:14:5e:16:bb:b6 UHLW1107 1500
vlan172491
This behavior seems to have changed in 8.0, where now only the
locally-assigned IP addresses and related CIDRs are displayed.
From src/UPDATING:
: 20081214:
: __FreeBSD_version 800059 incorporates the new arp-v2 rewrite.
: RTF_CLONING, RTF_LLINFO and RTF_WASCLONED flags are eliminated.
: The new code reduced struct rtentry{} by 16 bytes on 32-bit
: architecture and 40 bytes on 64-bit architecture. The userland
: applications arp and ndp have been updated accordingly.
: The output from netstat -r shows only routing entries and
: none of the L2 information.
Is there any way to get this behavior back, perhaps with a new flag that I
am not able to find? Or some sysctl? I have a script that was relying on
each host's expire flag in the routing table to determine when the MAC
address first appeared on the network according to ARP.
If you need to know when a particular ARP entry expires, a variation
of the following patch can be used, perhaps hiding this output by the
-v (verbose) option.
%%%
Index: arp.c
===
--- arp.c (revision 203016)
+++ arp.c (working copy)
@@ -101,7 +101,8 @@
static int nflag; /* no reverse dns lookups */
static char *rifname;
-static int expire_time, flags, doing_proxy, proxy_only;
+static time_t expire_time;
+static int flags, doing_proxy, proxy_only;
/* which function we're supposed to do */
#define F_GET 1
@@ -594,6 +595,15 @@
printf( on %s, ifname);
if (rtm-rtm_rmx.rmx_expire == 0)
printf( permanent);
+ else {
+ static struct timeval tv;
+ if (tv.tv_sec == 0)
+ gettimeofday(tv, 0);
+ if ((expire_time = rtm-rtm_rmx.rmx_expire - tv.tv_sec) 0)
+ printf( expires %d, (int)expire_time);
+ else
+ printf( expired);
+ }
if (addr-sin_other SIN_PROXY)
printf( published (proxy only));
if (rtm-rtm_flags RTF_ANNOUNCE)
%%%
Cheers,
--
Ruslan Ermilov
r...@freebsd.org
FreeBSD committer
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: locate(1) ZFS addition
On Sun, Sep 27, 2009 at 11:37:14PM -0400, CmdLnKid wrote: I just came across what I believe to be just a oversight on locate(1). By default as stated in its locate.rc file in /etc it states that the default file systems that will be searched is ufs ext2fs. Would it be wise to have the default be ufs zfs xfs ext2fs ? or some other combination. PS: Should a PR be filed for this ? The default list is actually ufs ext2fs zfs for RELENG_7 now, it's just that the comment hasn't been updated. For HEAD and RELENG_8, the default list contains all local file systems that are not synthetic, loopback mounts, or read-only, according to lsvfs. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 crash
On Tue, Apr 21, 2009 at 11:20:13AM -0400, Mike Tancsa wrote: At 11:11 AM 4/21/2009, John Baldwin wrote: Can you do 'frame 7' followed by 'l', 'p ifp', and 'p ifp-if_snd'? Hi, kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05964d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05967a9 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc07f64ac in trap_fatal (frame=0xe766ea6c, eva=104) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc07f6730 in trap_pfault (frame=0xe766ea6c, usermode=0, eva=104) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc07f70dc in trap (frame=0xe766ea6c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc07db7eb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 #8 0xc059fd77 in sysctl_root (oidp=Variable oidp is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1413 #9 0xc059ff14 in userland_sysctl (td=0xc5374460, name=0xe766ec14, namelen=6, old=0x0, oldlenp=0xbfbf8478, inkernel=0, new=0x0, newlen=0, retval=0xe766ec10, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1506 #10 0xc05a0064 in __sysctl (td=0xc5374460, uap=0xe766ecfc) at /usr/src/sys/kern/kern_sysctl.c:1443 #11 0xc07f6a85 in syscall (frame=0xe766ed38) at /usr/src/sys/i386/i386/trap.c:1090 #12 0xc07db850 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #13 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 7 #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 127 ifp-if_snd.ifq_drops = ifmd.ifmd_snd_drops; (kgdb) l 122 DONTCOPY(baudrate); 123 #undef DONTCOPY 124 #define COPY(fld) ifp-if_##fld = ifmd.ifmd_##fld 125 COPY(data); 126 ifp-if_snd.ifq_maxlen = ifmd.ifmd_snd_maxlen; 127 ifp-if_snd.ifq_drops = ifmd.ifmd_snd_drops; 128 #undef COPY 129 break; 130 131 case IFDATA_LINKSPECIFIC: (kgdb) p ifp $1 = (struct ifnet *) 0x0 (kgdb) p ifp-if_snd Cannot access memory at address 0xf4 (kgdb) Is it possible I am running into some of the interface lock fixes rwatson has been working on ? This box has a lot of ng interfaces which come and go. Perhaps snmp asking about an interface that just went away caused the panic ? I disabled bsnmp since the reboot and the box has been up for 10hrs so far. It's a documented bug: : revision 1.281 : date: 2008/06/26 23:05:28; author: rwatson; state: Exp; lines: +69 -12 : SVN rev 180042 on 2008-06-26 23:05:28Z by rwatson : : Introduce locking around use of ifindex_table, whose use was previously : unsynchronized. While races were extremely rare, we've now had a : couple of reports of panics in environments involving large numbers of : IPSEC tunnels being added very quickly on an active system. : : - Add accessor functions ifnet_byindex(), ifaddr_byindex(), : ifdev_byindex() to replace existing accessor macros. These functions : now acquire the ifnet lock before derefencing the table. : - Add IFNET_WLOCK_ASSERT(). : - Add static accessor functions ifnet_setbyindex(), ifdev_setbyindex(), : which set values in the table either asserting of acquiring the ifnet : lock. : - Use accessor functions throughout if.c to modify and read : ifindex_table. : - Rework ifnet attach/detach to lock around ifindex_table modification. : : Note that these changes simply close races around use of ifindex_table, : and make no attempt to solve the probem of disappearing ifnets. Further ^^ : refinement of this work, including with respect to ifindex_table : resizing, is still required. : : In a future change, the ifnet lock should be converted from a mutex to an : rwlock in order to reduce contention. : : Reviewed and tested by: brooks Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: buildworld fails immediately
On Wed, Sep 24, 2008 at 07:03:15PM -0700, Jason C. Wells wrote: I am trying to build RELENG_6. I receive the following errors. [EMAIL PROTECTED] /usr/src]# make buildworld /dev/null, line 4: Need an operator /dev/null, line 6: Need an operator /dev/null, line 8: Need an operator /dev/null, line 9: Need an operator /dev/null, line 11: Need an operator /dev/null, line 12: Need an operator /dev/null, line 13: Need an operator /dev/null, line 15: Need an operator /dev/null, line 16: Need an operator /dev/null, line 18: Need an operator I figured I got a partial update or something. Re-supping didn't help. I am building on 6.2-RELEASE inside a jail. Jails are new for me so maybe I missed something there. Any ideas? Make sure /dev/null inside a jail is a device and not a plain file. If the latter, you probably forgot to mount devfs onto a jail's /dev. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: no more src/compat and install.sh
On Tue, Jun 24, 2008 at 05:56:37PM +0800, Mars G Miro wrote: Greetz, src/compat was repocopied to src/cddl/compat about 2months ago. I think we need to remove for good 'compat' in src/release/scripts/src-install.sh. Fixed, thanks. -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make KNOBS
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote: Hello All, Maintaining a make.conf file can be a fairly daunting task within itself. But when upgrading, it becomes even more laborious. Peeking into the port Makefile to discover any /new/, or /changed/ knobs is standard fare. But it's not always obvious exactly /what/ the WITH_this, or WITHOUT_that actually provides. To the point: Is there, or does anyone maintain a KNOBS list possibly categorized by application/port/version, etc...? If not, are there any resources that might help me facilitate one online for myself and others to refer to? Thank you for all your time and consideration. For src/, there is an src.conf(5) manpage that documents supported WITH_*/WITHOUT_* knobs. For ports/, I'm not aware of such a list. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: date manupulation strangeness
On Mon, Oct 29, 2007 at 01:19:51AM +, Miguel Lopes Santos Ramos wrote: From: Holger Kipp [EMAIL PROTECTED] On Mon, Oct 29, 2007 at 01:35:08AM +0700, Eugene Grosbein wrote: On Sun, Oct 28, 2007 at 07:20:11PM +0100, Holger Kipp wrote: # unixtime=1193511599 # LC_ALL=C TZ=Asia/Krasnoyarsk date -jr $unixtime Sun Oct 28 02:59:59 KRAT 2007 Here it shows 'Sun Oct 28 02:59:59 KRAST 2007' really (cut-n-paste error, mea culpa). Take a note of zone name, KRAST stands for 'KRAsnoyarsk Summer Time' and KRAT stands for 'KRAsnoyarsk Time' (winter one). ah, I see. I can reproduce it here as well: %setenv LC_ALL C %setenv TZ Asia/Krasnoyarsk %setenv unixtime 1193511599 %date -jr $unixtime Sun Oct 28 02:59:59 KRAST 2007 %date -jf $s $unixtime Sun Oct 28 02:59:59 KRAT 2007 %date -juf %s $unixtime Sat Oct 27 18:59:59 UTC 2007 %date -jur $unixtime Sat Oct 27 18:59:59 UTC 2007 This is a lot of fun! Bugs like this go unnoticed for years... It is also very exciting finding people at GMT+8. Mind you, we programmers who live at GMT+0 do a lot of timezone errors because we look at a time and often don't know whether it's localtime or gmt. At least I do. Then we only find out when we change to summer time. The problem is of course in src/bin/date.c, line 268. Someone added the following on revision 1.32.2.4: 267:/* Let mktime() decide whether summer time is in effect. */ 268:lt-tm_isdst = -1; Now, who's mktime() to know? This line is erasing the output of strptime(), and strptime() knows better than anyone what the user might have wanted! [...] There's no point in naming the revision... the problematic line was introduced 6 years and 5 months ago by ru... Complete reference: src/bin/date.c Revision 1.32.2.4 Is ru around? Who fills in a pr for this? In summary, I think we should move line 268 to line 191 and erase the comment on line 267 (mktime() is no one to decide, strptime() must have the final word). I've committed a different fix, so that it doesn't re-introduce the bug fixed in rev. 1.36 (or 1.32.2.4, which was an MFC of 1.36). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Minidumps in -STABLE and smaller than physical memory
On Thu, Jan 31, 2008 at 01:35:39PM +0100, Peter Holm wrote: On Wed, Jan 30, 2008 at 08:06:40PM +0300, Ruslan Ermilov wrote: On Thu, Sep 21, 2006 at 05:16:36PM +0200, Peter Holm wrote: On Thu, Sep 21, 2006 at 05:15:47PM +0400, Ruslan Ermilov wrote: On Thu, Sep 21, 2006 at 11:14:33AM +0100, Gavin Atkinson wrote: On Thu, 2006-09-21 at 11:44 +0300, Dmitry Pryanishnikov wrote: Hello! I've noticed (with the 2-day old RELENG_6) that I still can't configure my 256Mb swap partition as a dump device for i386 machine with 1Gb RAM despite having minidumps enabled: [EMAIL PROTECTED] sysctl debug.minidump debug.minidump: 1 [EMAIL PROTECTED] dumpon -v /dev/ad0s3b /dev/ad0s3b is smaller than physical memory Am I correctly understand that minidumps should lift the restriction sizeof(dumpdev) = sizeof(RAM) Yes. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dumpon/dumpon.c.diff?r1=1.22r2=1.23 needs to be MFC'd. I sent an MFC request to [EMAIL PROTECTED] From time to time I've had problems with minidumps on HEAD. Calling doadump() seems to work ok, but after a reset there's no dump. I haven't had time to test this systematically. Has anybody else seen this problem? I think this was the same problem as was diagnosed (minidumps + amd64 + SMP). Though it's not fixed yet, it's understood and its damage is avoided. No, this was and is i386. After changing doadump;reset to doadump;continue it would seem that the dumps has a higher chance of making it to the disk. call doadump and the continue renders my systems unusable due to a regression made in kern_shutdown.c,v 1.122. I'm now living with this patch: %%% Index: kern_shutdown.c === RCS file: /home/ncvs/src/sys/kern/kern_shutdown.c,v retrieving revision 1.189 diff -u -p -r1.189 kern_shutdown.c --- kern_shutdown.c 28 Jan 2008 19:04:07 - 1.189 +++ kern_shutdown.c 1 Feb 2008 15:40:38 - @@ -249,6 +249,7 @@ doadump(void) else #endif dumpsys(dumper); + dumping--; } static int %%% Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Minidumps in -STABLE and smaller than physical memory
On Thu, Sep 21, 2006 at 05:16:36PM +0200, Peter Holm wrote: On Thu, Sep 21, 2006 at 05:15:47PM +0400, Ruslan Ermilov wrote: On Thu, Sep 21, 2006 at 11:14:33AM +0100, Gavin Atkinson wrote: On Thu, 2006-09-21 at 11:44 +0300, Dmitry Pryanishnikov wrote: Hello! I've noticed (with the 2-day old RELENG_6) that I still can't configure my 256Mb swap partition as a dump device for i386 machine with 1Gb RAM despite having minidumps enabled: [EMAIL PROTECTED] sysctl debug.minidump debug.minidump: 1 [EMAIL PROTECTED] dumpon -v /dev/ad0s3b /dev/ad0s3b is smaller than physical memory Am I correctly understand that minidumps should lift the restriction sizeof(dumpdev) = sizeof(RAM) Yes. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dumpon/dumpon.c.diff?r1=1.22r2=1.23 needs to be MFC'd. I sent an MFC request to [EMAIL PROTECTED] From time to time I've had problems with minidumps on HEAD. Calling doadump() seems to work ok, but after a reset there's no dump. I haven't had time to test this systematically. Has anybody else seen this problem? I think this was the same problem as was diagnosed (minidumps + amd64 + SMP). Though it's not fixed yet, it's understood and its damage is avoided. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: src-install.sh and compat/opensolaris/
On Wed, Nov 07, 2007 at 04:59:45PM +0800, Mars G Miro wrote:
Hiya
I think there might be a need to add 'compat' in $dists in
src-install.sh. When the src is extracted from the ISO, compat is left
out and buildworld fails at:
mkdep -f .depend -a
-I/usr/src/cddl/lib/libnvpair/../../../sys/compat/opensolaris
-I/usr/src/cddl/lib/libnvpair/../../../include
-I/usr/src/cddl/lib/libnvpair/../../../sys/contrib/opensolaris/uts/common
-D_SOLARIS_C_SOURCE
/usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/libnvpair.c
/usr/src/cddl/lib/libnvpair/../../../contrib/opensolaris/lib/libnvpair/nvpair_alloc_system.c
/usr/src/cddl/lib/libnvpair/../../../sys/contrib/opensolaris/common/nvpair/nvpair_alloc_fixed.c
/usr/src/cddl/lib/libnvpair/../../../sys/contrib/opensolaris/common/nvpair/nvpair.c
=== cddl/lib/libumem (depend)
make: don't know how to make umem.c. Stop
*** Error code 2
Stop in /usr/src/cddl/lib.
*** Error code 1
because there's no more cddl/ [0]. Of course when csupping it can be
checked out but for those that do not csup, they may not be able to
rebuild their world. For instance, I have a 7.0-PRERELEASE box and not
able to rebuild my world using the 7.0-BETA2 src from the ISO.
Thanks ;-)
Try the attached patch.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
Index: release/scripts/src-install.sh
===
RCS file: /home/ncvs/src/release/scripts/src-install.sh,v
retrieving revision 1.11
diff -u -p -r1.11 src-install.sh
--- release/scripts/src-install.sh 28 Jun 2007 18:26:35 - 1.11
+++ release/scripts/src-install.sh 8 Nov 2007 21:11:45 -
@@ -11,8 +11,8 @@ if [ $# -lt 1 ]; then
echo You must specify which components of src to extract
echo possible subcomponents are:
echo
- echo base bin cddl contrib crypto etc games gnu include krb5 lib
- echo libexec release rescue sbin secure share sys tools ubin
+ echo base bin cddl compat contrib crypto etc games gnu include krb5
+ echo lib libexec release rescue sbin secure share sys tools ubin
echo usbin
echo
echo You may also specify all to extract all subcomponents.
@@ -20,7 +20,7 @@ if [ $# -lt 1 ]; then
fi
if [ $1 = all ]; then
- dists=base bin cddl contrib crypto etc games gnu include krb5 lib
libexec release rescue sbin secure share sys tools ubin usbin
+ dists=base bin cddl compat contrib crypto etc games gnu include krb5
lib libexec release rescue sbin secure share sys tools ubin usbin
else
dists=$*
fi
Index: usr.sbin/sysinstall/dist.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/dist.c,v
retrieving revision 1.250
diff -u -p -r1.250 dist.c
--- usr.sbin/sysinstall/dist.c 8 Nov 2007 15:40:40 - 1.250
+++ usr.sbin/sysinstall/dist.c 8 Nov 2007 21:14:17 -
@@ -109,6 +109,7 @@ static Distribution KernelDistTable[] =
static Distribution SrcDistTable[] = {
DTE_TARBALL(sbase,SrcDists, SRC_BASE,/usr/src),
DTE_TARBALL(scddl,SrcDists, SRC_CDDL,/usr/src),
+DTE_TARBALL(scompat, SrcDists, SRC_COMPAT, /usr/src),
DTE_TARBALL(scontrib, SrcDists, SRC_CONTRIB, /usr/src),
DTE_TARBALL(scrypto, SrcDists, SRC_SCRYPTO, /usr/src),
DTE_TARBALL(sgnu,SrcDists, SRC_GNU, /usr/src),
Index: usr.sbin/sysinstall/dist.h
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/dist.h,v
retrieving revision 1.68
diff -u -p -r1.68 dist.h
--- usr.sbin/sysinstall/dist.h 8 Nov 2007 15:40:40 - 1.68
+++ usr.sbin/sysinstall/dist.h 8 Nov 2007 21:13:45 -
@@ -44,6 +44,7 @@
#define DIST_SRC_SKERBEROS50x4
#define DIST_SRC_RESCUE0x8
#define DIST_SRC_CDDL 0x10
+#define DIST_SRC_COMPAT0x20
#define DIST_SRC_ALL 0x1F
/* Subtypes for X.Org packages */
Index: usr.sbin/sysinstall/menus.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/menus.c,v
retrieving revision 1.426
diff -u -p -r1.426 menus.c
--- usr.sbin/sysinstall/menus.c 8 Nov 2007 15:40:40 - 1.426
+++ usr.sbin/sysinstall/menus.c 8 Nov 2007 21:15:30 -
@@ -1066,6 +1066,8 @@ DMenu MenuSrcDistributions = {
dmenuFlagCheck, dmenuSetFlag, NULL, SrcDists, '[', 'X', ']',
DIST_SRC_BASE },
{ cddl, /usr/src/cddl (software from Sun),
dmenuFlagCheck, dmenuSetFlag, NULL, SrcDists, '[', 'X', ']',
DIST_SRC_CDDL },
+ { compat, /usr/src/compat (compatibility software),
+ dmenuFlagCheck, dmenuSetFlag, NULL, SrcDists, '[', 'X', ']',
DIST_SRC_COMPAT },
{ contrib,/usr/src/contrib (contributed software),
dmenuFlagCheck, dmenuSetFlag, NULL, SrcDists, '[', 'X', ']',
DIST_SRC_CONTRIB
Re: rpc.statd--256M okay, but 1G?
On Thu, Oct 18, 2007 at 12:07:02PM -0700, Christopher Chen wrote: Is there a simple and easy reason why rpc.statd would mmap 1G? I've read the FAQ and understand why it would allocate 256M, but this one shows 1G--file.c in /usr/src/usr.sbin/rpc.statd is still set to allocate 256M, btw. This is a 6.2 machine on i386, with 4G RAM, but PAE is not enabled. That's what I would assume, that if PAE was enabled, it may change the characteristics of that mmap (but even then, the address space of each process would be the same...) The machine is a nfs client, has no exports, and has two mounts. Any quick thoughts? It has been fixed in RELENG_6 in rev. 1.12.8.2 of statd.c: : revision 1.12.8.2 : date: 2007/08/12 01:46:19; author: truckman; state: Exp; lines: +1 -1 : MFC statd.c 1.15 - : The call to init_file() needs to be moved outside the loop in statd.c, : otherwise mmap() gets called multiple times, which eventually fails due : to address space exhaustion on i386. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kldxref: file isn't dynamically-linked -- expected behaviour?
On Thu, Oct 18, 2007 at 09:06:55PM +0200, Philipp Ost wrote: Vlad GALU wrote: On 10/18/07, Philipp Ost [EMAIL PROTECTED] wrote: Hi list, I'm currently upgrading from 6.2-STABLE (13 Oct. 2007) to RELENG_7. I did the following after csup'ing my sources: # make kernel-toolchain # make -DALWAYS_CHECK_MAKE buildkernel KERNCONF=MYKERNEL # make -DALWAYS_CHECK_MAKE installkernel KERNCONF=MYKERNEL The last thing 'installkernel' reports is: [...] kldxref /boot/kernel kldxref: file isn't dynamically-linked [...] This message is repeated 514 times... ;-) Is this expected behaviour? Before I do a reboot I would like to make sure everything works as I rely on that particular machine. If needed I can provide full logs; MYKERNEL is a cut down version of GENERIC with atapicam, drm, radeondrm, sound added ;-) Thanks in advance for any hint/help! It's harmless. Once you boot with your new RELENG_7 they will disappear on the next kernel build/install. Thanks a lot. I saw this message for the first time in my life and was a little bit concerned about it... But if everything seems to be fine I will give it a try. As others have pointed out, these messages are harmless. It's caused by the old (6.x version) kldxref(8) binary trying to hash the *.symbols files that are installed along with debug versions of kernel and module objects, and that contain symbol information needed for debugging, and aren't dynamically linked ELF files. So the old kldxref(8) ignores these files, but issues a warning. Once you upgrade to 7.x, you'll have also installed the new (7.x version) of kldxref(8) that is aware of .symbols files, so warnings will be gone. Technically, kldxref(8) should be a cross-tool (in the buildworld sense), but last time I tried to convert it to be a cross-tool several years ago it wasn't very easy. It's quite possible it will be easier now that we only support limited upgrade paths. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld issue on 6.2 stable
On Fri, May 25, 2007 at 12:07:10PM +0930, Shaun Branden wrote: uname -a FreeBSD sagan.cai 6.2-STABLE FreeBSD 6.2-STABLE #0: Sat May 5 23:34:08 CST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAGAN i386 The results of make buildworld on this system: ide -k _crunched_chroot_stub chroot.lo cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pax.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo bsdlabel.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_ext2fs.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_std.lo mount_udf.lo mount_umapfs.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo slattach.lo spppcontrol.lo startslip.lo swapon.lo sysctl.lo tunefs.lo umount.lo atm.lo atmconfig.lo fore_dnld.lo ilmid.lo ping6.lo ipf.lo sconfig.lo fdisk.lo dhclient.lo gzip.lo bzip2.lo tar.lo vi.lo id.lo chroot.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -lm -ltermcap -lutil -lcrypto -latm -lalias -lbsdxml -lcam -lcurses -ldevstat -lipsec -lipx -lgeom -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -larchive ifconfig.lo(.text+0x4df8): In function `print_chaninfo': : undefined reference to `IEEE80211_IS_CHAN_PASSIVE' *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src I haven't seen anyone else get this error so I think it is just this system. Any thoughts? IEEE80211_IS_CHAN_PASSIVE() is a macro defined in src/sys/net80211/_ieee80211.h. Check that you have an up-to-date copy of that file in /usr/src. If you have it and still get the error, rm -rf /usr/obj/usr/src first, then try to build world again. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpTM5jOneYje.pgp Description: PGP signature
Re: make buildworld issue on 6.2 stable
On Fri, May 25, 2007 at 07:06:38PM +0930, Shaun Branden wrote: On Fri, May 25, 2007 at 12:28:18PM +0400, Ruslan Ermilov wrote: On Fri, May 25, 2007 at 12:07:10PM +0930, Shaun Branden wrote: IEEE80211_IS_CHAN_PASSIVE() is a macro defined in src/sys/net80211/_ieee80211.h. Check that you have an up-to-date copy of that file in /usr/src. If you have it and still get the error, rm -rf /usr/obj/usr/src first, then try to build world again. Thanks for that The file is there: [EMAIL PROTECTED]:net80211$ pwd /usr/src/sys/net80211 You have mail in /var/mail/shaun [EMAIL PROTECTED]:net80211$ ls -l _ieee80211.h -rw-r--r-- 1 root wheel 8181 Jan 28 14:37 _ieee80211.h You have an incomplete source tree. Jan 28 corresponds to rev. 1.2.2.3 of that file, and the IEEE80211_IS_CHAN_PASSIVE() define was added in rev. 1.2.2.4. From CVS history: : revision 1.2.2.4 : date: 2007/03/10 00:28:43; author: sam; state: Exp; lines: +2 -0 : MFC 1.7: add IEEE80211_IS_CHAN_PASSIVE : : revision 1.2.2.3 : date: 2007/01/28 04:07:54; author: sam; state: Exp; lines: +11 -0 : MFC: half- and quarter-rate channel support : 900MHz channel support : support for respecifying the channel set after attach : default rate sets and this is from my history: 489 cvsup -g ~shaun/cvs/stable-supfile 490 cd /usr/obj 491 rm -rf * 492 chflags -R noschg * 493 rm -rf * 494 cd /usr/src I just ran these again, ie !489, !490 etc with make buildworld at the end and got the same result. ... ifconfig.lo(.text+0x4df8): In function `print_chaninfo': : undefined reference to `IEEE80211_IS_CHAN_PASSIVE' *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpUdDbMybaxl.pgp Description: PGP signature
Re: installworld breaks
On Fri, May 25, 2007 at 11:44:51AM +0100, Tom Judge wrote: [EMAIL PROTECTED] wrote: cvsup and built around 20.30 BST cd /usr/src; make -f Makefile.inc1 install === share/info install === include install creating osreldate.h from newvers.sh touch: not found ***error code 127 Stop in /usr/src/include ***error code 1 I tried cd usr.bin/touch make make install but it does not seem to have any effect any offers? cheers I have seen this problem when PATH was not set correctly. http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#TOUCH-NOT-FOUND Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpb5cXfbu98V.pgp Description: PGP signature
Re: buildworld fail?
On Thu, Apr 12, 2007 at 09:47:23AM +0300, Krassimir Slavchev wrote:
=== usr.sbin/bsnmpd/modules/snmp_bridge (depend)
cat /usr/src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_tree.def |
gensnmptree -p bridge_
line 31: '(' expected at begin of node
context: TruthValue ENUM (
*** Error code 1
Stop in /usr/src/usr.sbin/bsnmpd/modules/snmp_bridge.
*** Error code 1
Stop in /usr/src/usr.sbin/bsnmpd/modules.
*** Error code 1
Stop in /usr/src/usr.sbin/bsnmpd.
*** Error code 1
Looks like you screwed up your build environment, and
the installed /usr/include/osreldate.h lies about the
actual __FreeBSD_version. To work around it, do this
(one time only):
make buildworld OSRELDATE=0
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpG9FR9dtz5e.pgp
Description: PGP signature
Re: make: parallel jobs broken when using -f -
Hi Ulrich,
On Thu, Apr 12, 2007 at 11:24:04PM +0200, Ulrich Spoerlein wrote:
there is an annoying bug in 6-STABLE make(1), where -f - seems to
serialize the target making.
Consider the following Makefile
all: a b c d
a b c d:
@echo Makeing ${.TARGET}
@sleep 4
And observe the following behaviour:
$ make -j4
Makeing a
Makeing b
Makeing c
Makeing d
pause
$ make -j4 -f- Makefile
Makeing b
Makeing d
pause
Makeing a
pause
Makeing c
pause
$
The make(1) on -CURRENT has this fixed already, is there any chance of
this getting MFCed?
AFAICS the following revisions are not up to date (wrt to CURRENT):
$FreeBSD: src/usr.bin/make/job.c,v 1.122.2.1 2005/07/20 19:05:23 harti
Exp $
$FreeBSD: src/usr.bin/make/main.c,v 1.155 2005/05/24 16:05:51 harti Exp $
$FreeBSD: src/usr.bin/make/parse.c,v 1.108.2.1 2005/11/16 08:25:19 ru
Exp $
$FreeBSD: src/usr.bin/make/str.c,v 1.45.2.1 2006/10/16 11:51:18 ru Exp $
$FreeBSD: src/usr.bin/make/var.c,v 1.159 2005/05/24 16:05:51 harti Exp $
The bug you're seeing is PR bin/101232. Please query
Will Andrews about the MFC, or if he doesn't reply in
a timely manner, ping me and I'll commit it for you.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgp4pyS9KIp3i.pgp
Description: PGP signature
Re: make buildworld error on am64
On Wed, Apr 04, 2007 at 05:00:09PM +0700, zen wrote: Niclas Zeising wrote: On 4/4/07, zen [EMAIL PROTECTED] wrote: hi , sorry to bother you again, i'm trying updating my machine to 6.2STABLE, [snip error log] the box was fresh install from 6.2RELEASE, and was build on am64 arch. it has 4Gigs RAM and amd64 X2 AM2 socket. could you tell me how to resolve this problem? TIA Zen What's in your /etc/make.conf? It seems to me you have set cputype to a faulty value... HTH! //Niclas this is my /etc/make.conf CFLAGS= -O -pipe NOPROFILE= true USA_RESIDENT= yes CPUTYPE=amd64 NO_PROFILE=yes amd64 is not a valid CPUTYPE; see /usr/share/examples/etc/make.conf for a list of supported CPU types and pick up any suitable value. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpgQA6igbWuE.pgp Description: PGP signature
Re: 'make buildworld' fails
/libgroff/uniuni.cpp
version.cpp
/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/cmap.cpp:27:18:
cmap.h: No such file or directory
[...]
/usr/src/gnu/usr.bin/groff/src/libs/libgroff/../../../../../../contrib/groff/src/libs/libgroff/uniuni.cpp:29:21:
unicode.h: No such file or directory
mkdep: compile failed
*** Error code 1
Stop in /usr/src/gnu/usr.bin/groff/src/libs/libgroff.
*** Error code 1
[...]
My /etc/make.conf configuration file:
CPUTYPE?=pentium4
CFLAGS=-O0 -g -pipe
MAKE_SHELL?=sh
COPTFLAGS=-O0 -g -pipe
CXXFLAGS=-O0 -g -pipe
Don't do that! The make.conf(5) manpage states it explicitly
that CXXFLAGS (if ever set) is to be set using the += operator.
By setting it explicitly, you broke it -- by default, it's set
to ${CFLAGS} (the latter is expanded at run time!). In your
case, just removing the CXXFLAGS line will 1) do what you want
and 2) unbreak the build.
: CXXFLAGS (str) Controls the compiler settings when compiling C++
: code. CXXFLAGS is initially set to the value of CFLAGS.
: If you want to add to the CXXFLAGS value, use ``+=''
: instead of ``=''.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpI0sdQ5qk9T.pgp
Description: PGP signature
Re: 6.2: make buildworld fails at usr.bin/passwd
On Thu, Jan 18, 2007 at 09:41:11AM +0100, Heinrich Rebehn wrote: Hi list, I just cvsup'ed 6.2 (tag=RELENG_6_2) and buildworld fails with: [...] rm -f opiepasswd opiepasswd.o opiepasswd.1.gz opiepasswd.1.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS === usr.bin/pagesize (cleandir) rm -f pagesize.1.gz pagesize.1.cat.gz === usr.bin/passwd (cleandir) cd: can't cd to /usr/src/usr.bin/passwd *** Error code 2 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Does anyone know what is wrong here? Why is /usr/src/usr.bin/passwd missing? I tried different german mirrors. It could be you configured you CVSup to ignore it in one way or another. Run cvsup(1) in verbose mode and see what happens. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp4jyqO5OFKz.pgp Description: PGP signature
Re: make buildworld error on recent sources
On Wed, Dec 06, 2006 at 03:02:31PM -0200, JoaoBR wrote: i get an error on recent sources releng_6 when doing make buildworld from clean 6.1-STABLE install I compile the same sources from a already releng_6 and it compiles fine sed /usr/src/lib/libncurses/../../contrib/ncurses/include/unctrl.h.in unctrl.h -e /@NCURSES_MAJOR@/s%%5% -e /@NCURSES_MINOR@/s%%2% cc -o make_keys -O2 -fno-strict-aliasing -pipe -I. -I/usr/src/lib/libncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/make_keys.c /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lc *** Error code 1 Stop in /usr/src/lib/libncurses. *** Error code 1 I bet the date/time on your computer is set incorrectly. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpAExPPCKVti.pgp Description: PGP signature
Re: make buildworld error on recent sources
On Wed, Dec 06, 2006 at 03:43:32PM -0200, JoaoBR wrote: On Wednesday 06 December 2006 15:07, Ruslan Ermilov wrote: /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/ti nfo/make_keys.c /usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lc *** Error code 1 Stop in /usr/src/lib/libncurses. *** Error code 1 I bet the date/time on your computer is set incorrectly. firstable thanks and also the bet was good Good to hear. could you be so kind and tell me where you saw it or was it kind of feeling? I have magic glasses ;-) and some experience with the FreeBSD build system. If you search the mailing list archives, you'll see that your case is not new. The really short version of what happens here is that by NOT having the system's date/time set correctly, you fool make(1) into thinking it should rebuild something when it's not supposed to do it. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpZaEgIOrygZ.pgp Description: PGP signature
Re: nfe: can not cvs sources anymore!
On Sun, Nov 19, 2006 at 03:08:58PM +0100, O. Hartmann wrote: Hello. Using these two sources for getting nfe() driver support for my FreeBSD 6.2-BETA/AMD64 box was pretty convenient in the past weeks due to my big interrupt problems using the nve() driver. But with yesterday, I can't get the sources anymore. nfe() isn't yet a part of the 6.2 BETA, that's what I looked first for, so can anybody help me out? Is nfe() a part of 6.2-REL in the near future or are there other reasons stop spreading the sources via that cvs source? Thanks for your help in advance, Did you try the version at http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html ? I use it and except for some peer-to-peer gigabit problems I didn't notice any other bad signs. It's far more stable that what we have now in the CVS tree. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpfeE8IJcsn8.pgp Description: PGP signature
Re: systat -vm output showing negative total virtual memory
On Fri, Nov 17, 2006 at 01:38:00AM +0300, Ruslan Ermilov wrote: Actually, the values are also in pages. Below is a new patch to try. The total amount of virtual memory reported is still insane; I think some objects are included in the stats mistakenly, but I'm not yet sure. Okay, the attached patch that includes a fix for vm_meter.c now prints the sane values for virtual memory. The huge contributions to vm total were from vnode objects representing mounted file systems (g_vfs_open()). Alan, could you please review this patch for me (the vm_meter.c portion at least) or suggest a better fix? On my amd64 system, I now get: : vm.vmtotal: : System wide totals computed every five seconds: (values in kilobytes) : === : Processes: (RUNQ: 2 Disk Wait: 0 Page Wait: 0 Sleep: 35) : Virtual Memory: (Total: 4458372K, Active 95772K) : Real Memory:(Total: 93468K Active 71016K) : Shared Virtual Memory: (Total: 20504K Active: 18952K) : Shared Real Memory: (Total: 13956K Active: 13148K) : Free Memory Pages: 3024836K The patch is against RELENG_6 but should apply to HEAD too. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpsgCkiyhzqs.pgp Description: PGP signature
Re: systat -vm output showing negative total virtual memory
(total.t_vm/1024, MEMROW + 3, MEMCOL + 19, 9); + putint(total.t_vmshr/1024, MEMROW + 3, MEMCOL + 28, 9); putint(pgtokb(total.t_free), MEMROW + 2, MEMCOL + 37, 8); putint(total.t_rq - 1, PROCSROW + 1, PROCSCOL + 3, 3); putint(total.t_pw, PROCSROW + 1, PROCSCOL + 6, 3); %%% Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpNGRvUxOU1N.pgp Description: PGP signature
Re: systat -vm output showing negative total virtual memory
On Thu, Nov 16, 2006 at 08:10:37PM +0100, Ulrich Spoerlein wrote:
Ruslan Ermilov wrote:
sysctl(8) knows that t_vm is in bytes, but for the other stats
it thinks they are in pages. systat -vm thinks they are all
in bytes. Here's a fix:
Thanks!, I applied your patch to RELENG_6
22K active VM and 1K shared? Seems pretty low to me...
Actually, the values are also in pages. Below is a new patch
to try. The total amount of virtual memory reported is still
insane; I think some objects are included in the stats
mistakenly, but I'm not yet sure.
%%%
Index: sbin/sysctl/sysctl.c
===
RCS file: /home/ncvs/src/sbin/sysctl/sysctl.c,v
retrieving revision 1.67.2.7
diff -u -p -r1.67.2.7 sysctl.c
--- sbin/sysctl/sysctl.c8 Sep 2006 09:45:35 - 1.67.2.7
+++ sbin/sysctl/sysctl.c16 Nov 2006 22:23:35 -
@@ -395,8 +395,8 @@ S_vmtotal(int l2, void *p)
%hu Sleep: %hu)\n,
v-t_rq, v-t_dw, v-t_pw, v-t_sl);
printf(
- Virtual Memory:\t\t(Total: %luK, Active %lldK)\n,
- (unsigned long)v-t_vm / 1024,
+ Virtual Memory:\t\t(Total: %lldK, Active %lldK)\n,
+ (long long)v-t_vm * pageKilo,
(long long)v-t_avm * pageKilo);
printf(Real Memory:\t\t(Total: %lldK Active %lldK)\n,
(long long)v-t_rm * pageKilo, (long long)v-t_arm * pageKilo);
Index: usr.bin/systat/vmstat.c
===
RCS file: /home/ncvs/src/usr.bin/systat/vmstat.c,v
retrieving revision 1.60.2.1
diff -u -p -r1.60.2.1 vmstat.c
--- usr.bin/systat/vmstat.c 21 Mar 2006 20:49:50 - 1.60.2.1
+++ usr.bin/systat/vmstat.c 16 Nov 2006 22:35:34 -
@@ -58,6 +58,7 @@ static const char sccsid[] = @(#)vmstat
#include ctype.h
#include err.h
#include errno.h
+#include inttypes.h
#include langinfo.h
#include nlist.h
#include paths.h
@@ -135,7 +136,7 @@ static void copyinfo(struct Info *, stru
static float cputime(int);
static void dinfo(int, int, struct statinfo *, struct statinfo *);
static void getinfo(struct Info *);
-static void putint(int, int, int, int);
+static void putint(intmax_t, int, int, int);
static void putfloat(double, int, int, int, int, int);
static void putlongdouble(long double, int, int, int, int, int);
static int ucount(void);
@@ -472,7 +473,7 @@ showkre()
putfloat(avenrun[1], STATROW, STATCOL + 23, 6, 2, 0);
putfloat(avenrun[2], STATROW, STATCOL + 29, 6, 2, 0);
mvaddstr(STATROW, STATCOL + 53, buf);
-#define pgtokb(pg) ((pg) * (s.v_page_size / 1024))
+#define pgtokb(pg) ((intmax_t)(unsigned)(pg) * (s.v_page_size / 1024))
putint(pgtokb(total.t_arm), MEMROW + 2, MEMCOL + 3, 8);
putint(pgtokb(total.t_armshr), MEMROW + 2, MEMCOL + 11, 8);
putint(pgtokb(total.t_avm), MEMROW + 2, MEMCOL + 19, 9);
@@ -667,7 +668,8 @@ cputime(indx)
static void
putint(n, l, lc, w)
- int n, l, lc, w;
+ intmax_t n;
+ int l, lc, w;
{
char b[128];
@@ -677,11 +679,11 @@ putint(n, l, lc, w)
addch(' ');
return;
}
- snprintf(b, sizeof(b), %*d, w, n);
+ snprintf(b, sizeof(b), %*jd, w, n);
if ((int)strlen(b) w)
- snprintf(b, sizeof(b), %*dk, w - 1, n / 1000);
+ snprintf(b, sizeof(b), %*jdk, w - 1, n / 1000);
if ((int)strlen(b) w)
- snprintf(b, sizeof(b), %*dM, w - 1, n / 100);
+ snprintf(b, sizeof(b), %*jdM, w - 1, n / 100);
addstr(b);
}
%%%
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpgnPSqeKhlL.pgp
Description: PGP signature
Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ?
On Mon, Nov 13, 2006 at 07:30:09PM +0100, Olivier Mueller wrote: Hello, I will soon get some new servers with more than 4 GB of RAM, and I am wondering if they will work fine even with the PAE option activated: are all the required drivers (RAID mfid, bce on the Dell, ciss0 on the HP) 100% compatible, or should I expect trouble? Drivers that are either known to NOT work with PAE or were not tested with PAE are excluded by the PAE config file, you can check there. : 0 edoofus:ttyp2:/sys/i386/conf egrep 'ciss|mfi|bce' GENERIC PAE : GENERIC:device ciss# Compaq Smart RAID 5* : GENERIC:device mfi # LSI MegaRAID SAS : GENERIC:device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet So it looks like all of them should work fine with PAE. If you have a working /usr/src/sys/i386/conf/ with active PAE on one of these servers, I'd be interested :) Btw, when will we see these new servers listed under: http://www.freebsd.org/platforms/amd64/motherboards.html ? Or should I use send-pr ? :) And you absolutely have no option of running FreeBSD/amd64 on them? What a PITA! :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpeDvMFeUUAT.pgp Description: PGP signature
Re: 6.1 with PAE on a recent server (HP DL380 G5 or Dell PE 1950) ?
On Mon, Nov 13, 2006 at 10:57:50PM +0100, Olivier Mueller wrote: On Mon, 2006-11-13 at 22:14 +0300, Ruslan Ermilov wrote: Btw, when will we see these new servers listed under: http://www.freebsd.org/platforms/amd64/motherboards.html ? And you absolutely have no option of running FreeBSD/amd64 on them? What a PITA! :-) Ehm well, I must admit I never tried that, for a simple (and silly?) reason: freebsd installation selects the i386 SMP kernel by default... Because you're trying to install FreeBSD/i386 on it; download and burn the FreeBSD/amd64 ISOs instead -- it will select an amd64 SMP kernel then. But of course if you (and Mike Jakubik) strongly suggest it would be a good idea, why not, I will give a try asap :-) Any special thing I should take care of when switching from the i686 kernel to the amd64 one? It will be a 64-bit world with 64-bit time_t. ;) Will the systems be quicker this way, or will it just help with this 4GB memory limit? Quicker - probably not. Will certainly help with the 4G limit. (systems are going to be simple web mail hosting servers, with mysql, php, qmail, clamav, etc.). It should be fine then. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpebBrWSHCJ2.pgp Description: PGP signature
Re: Debugging a dump - need alternative?
On Fri, Nov 10, 2006 at 05:56:54AM -1000, Robert Marella wrote: On Fri, 10 Nov 2006 10:33:44 -0500 Vivek Khera [EMAIL PROTECTED] wrote: On Nov 10, 2006, at 10:19 AM, Robert Marella wrote: Thank you for your response. It seems unlikely that it is the power supply because I can buildworld on the same machine with an i386 install. The only difference is the i386 is on a SATA drive while the AMD64 is on an IDE drive. The funny thing about hardware failure is that the symptoms often make no sense. Don't rule it out until you test the equipment. I am planning to. We were also having random crashes (mostly ATA related) on a number of AMD64 boxes here, until it was identified as insufficient powering. So yes, don't rule it out yet. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpuhUJft6p93.pgp Description: PGP signature
Re: problems compiling stable
On Tue, Nov 07, 2006 at 08:07:26PM +, Vince Hoffman wrote: Have you tried cd /usr/obj/usr/src/usr.bin/vi rm -rf * rm .depend (make clean doesnt delete .depend and rm -rf * doesnt either.) then try cd /usr/src/usr.bin make There's a convenience target for this, make cleandepend. Another useful target is cleandir, which removes the object directory if it's different from source directory, and otherwise does make clean cleandepend. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpdEzKblsaWJ.pgp Description: PGP signature
Re: FreeBSD doesn't boot at Supermicro H8SSL-i2
On Mon, Nov 06, 2006 at 02:45:14PM +0100, Thomas Krause wrote: Hello, I got a brand new Supermicro H8SSL-i2 http://www.supermicro.com/Aplus/motherboard/Opteron1000/HT1000/H8SSL-i2.cfm but FreeBSD i386 6.2 Beta3 doesn't boot, whether if acpi is enabled or not. The latest BIOS is installed. Here is a picture of the boot process with verbose logging: http://moldau.webmatic.de/h8-boot.jpg Check that the USB speed setting in the BIOS is set to its defaults, either HiSpeed or FullSpeed, I don't remember exactly. If I change it, it similarly hangs on boot, but I'm using FreeBSD/amd64 on it. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpkVGeuzJlY5.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Thu, Nov 02, 2006 at 12:44:56AM +1100, Bruce Evans wrote: The masking hack is probably only needed for aout. For elf, objdump -h /kernel says: % Sections: % Idx Name Size VMA LMA File off Algn % ... % CONTENTS, ALLOC, LOAD, READONLY, DATA % 4 .text 002853e0 c043b510 c043b510 0003b510 2**4 so KERNBASE = LMA - File off for at least this kernel. boot2 now loads the text section from file offset File off to address LMA(masked). I think it just needs to load at an address that is the same mod PAGE_SIZE as LMA or VMA (these must agree mod PAGE_SIZE), provided it adjusts the entry address to match. It isn't generally: : LINT/kernel: file format elf32-i386-freebsd : : Sections: : Idx Name Size VMA LMA File off Algn : [...] : 4 .text 009c589c bf490e60 bf490e60 00090e60 2**4 : CONTENTS, ALLOC, LOAD, READONLY, CODE But: : $ nm LINT/kernel | grep kernbase : bf00 A kernbase The paddr of the first loadable segment is KERNBASE + KERNLOAD, and KERNLOAD is always 2M for PAE and 4M for non-PAE. (Please see my other private email I just sent that goes into more detail about this, and provides one possible formulae to compute the KERNBASE from paddr.) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpMNvhG7NRzA.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Fri, Oct 27, 2006 at 01:54:11AM +0100, Bruce M. Simpson wrote: Do we even need the PAGING code in btx any more? It might make the real mode hackery less confusing to implement. It's #ifdef'ed out and not compiled in by default, what's the problem with that? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp8qrLY7p0oP.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Mon, Sep 11, 2006 at 01:09:15PM -0500, Brooks Davis wrote: On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote: I just tried to load my standard kernel from the boot blocks (instead of using loader(8)), but I either get a hang before the kernel prints anything, or a BTX halted. Is this still supposed to work in 6- stable, or has it finally disappeared? You may be able to get this to work, but it is unsupported. I've been investigating this today. Here's what I've found: 1) You need hints statically compiled into your kernel. (This has been a long time requirement.) 2) You can only do it on i386, because boot2 only knows about ELF32, so attempts to load ELF64 amd64 kernels will fail. (loader(8) knows about both ELF32/64.) 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgprDIQrizNwX.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 10:52:30PM +1000, Bruce Evans wrote:
On Thu, 26 Oct 2006, Ruslan Ermilov wrote:
3) It's currently broken even on i386; backing out
rev. 1.71 of boot2.c by jhb@ fixes this for me.
: revision 1.71
: date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3
: A long, long time ago in a CVS branch far away (specifically, HEAD prior
: to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat
: mode and clients were limited to a virtual address space of 16 megabytes.
: Because of this limitation, boot2 silently masked all physical addresses
: in any binaries it loaded so that they were always loaded into the first
: 16 Meg. Since BTX no longer has this limitation (and hasn't for a long
: time), remove the masking from boot2. This allows boot2 to load kernels
: larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE).
:
: Submitted by: Sergey Lyubka devnull at uptsoft dot com
: MFC after: 1 month
The kernel is linked at 0xc000 but loade din low memory, so the high
bits must be masked off like they used to be for the kernel to boot at all.
This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since
BTX isn't large, and large kernels are more unbootable than before with
1.71.
The real purpose of this commit was to allow to directly load kernels
larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). (Old
version masked high 8 bits, leaving only 2^24=16MB for the kernel.)
I have compiled GENERIC and PAE kernels; objdump(1) reports that GENERIC
kernel has virtual start address 0xc0449cb0, and PAE has virtual start
address 0xc02458f0.
What happens here is that BTX now uses flat memory model, and by not
masking higher bits at all, BTX attempts to load kernels at above 3G,
which silently fails, and then jumps to the entry point located in
no memory unless the machine has enough memory.
If the machine has enough physical memory, e.g. 4G, then it works (I
think that was the case on the machine John tested this change), but
on my test machine I only have 3G of memory, so it fails.
My interim solution to the problem that would still allow booting
larger than 16MB kernels is to mask some of the higher bits.
Currently, I mask 28 bits that gives possible 256MB which is probably
practical.
%%%
Index: boot2.c
===
RCS file: /home/ncvs/src/sys/boot/i386/boot2/boot2.c,v
retrieving revision 1.72.2.4
diff -u -p -r1.72.2.4 boot2.c
--- boot2.c 15 Feb 2006 15:08:51 - 1.72.2.4
+++ boot2.c 26 Oct 2006 13:48:44 -
@@ -332,7 +332,7 @@ load(void)
return;
}
if (fmt == 0) {
- addr = hdr.ex.a_entry;
+ addr = hdr.ex.a_entry 0x0fff;
p = PTOV(addr);
fs_off = PAGE_SIZE;
if (xfsread(ino, p, hdr.ex.a_text))
@@ -366,7 +366,7 @@ load(void)
j++;
}
for (i = 0; i 2; i++) {
- p = PTOV(ep[i].p_paddr);
+ p = PTOV(ep[i].p_paddr 0x0fff);
fs_off = ep[i].p_offset;
if (xfsread(ino, p, ep[i].p_filesz))
return;
@@ -387,7 +387,7 @@ load(void)
p += es[i].sh_size;
}
}
- addr = hdr.eh.e_entry;
+ addr = hdr.eh.e_entry 0x0fff;
}
bootinfo.bi_esymtab = VTOP(p);
bootinfo.bi_kernelname = VTOP(kname);
%%%
A more intelligent approach would be to use the size of available
memory. I haven't yet looking at implementing this and I don't
know if this kind of information is available in boot2.
There is an another PR about this.
I've already closed PR 104709 as a duplicate for PR 96430.
Are there any other PRs with the same subject?
4) Another rev. broke support for booting with -c and -d to save 4 bytes.
-c is useful for RELENG_6 and -d is essential for debugging. If you
always use loader(8) then you would only notice this if you try to set
these flags in boot2.
I'll fix that.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpmpgJUwyag1.pgp
Description: PGP signature
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:18, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:52:30PM +1000, Bruce Evans wrote: On Thu, 26 Oct 2006, Ruslan Ermilov wrote: 3) It's currently broken even on i386; backing out rev. 1.71 of boot2.c by jhb@ fixes this for me. : revision 1.71 : date: 2004/09/18 02:07:00; author: jhb; state: Exp; lines: +3 -3 : A long, long time ago in a CVS branch far away (specifically, HEAD prior : to 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat : mode and clients were limited to a virtual address space of 16 megabytes. : Because of this limitation, boot2 silently masked all physical addresses : in any binaries it loaded so that they were always loaded into the first : 16 Meg. Since BTX no longer has this limitation (and hasn't for a long : time), remove the masking from boot2. This allows boot2 to load kernels : larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). : : Submitted by: Sergey Lyubka devnull at uptsoft dot com : MFC after: 1 month The kernel is linked at 0xc000 but loade din low memory, so the high bits must be masked off like they used to be for the kernel to boot at all. This has nothing to do with paging AFAIK. Rev.1.71 makes no sense, since BTX isn't large, and large kernels are more unbootable than before with 1.71. The real purpose of this commit was to allow to directly load kernels larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE). (Old version masked high 8 bits, leaving only 2^24=16MB for the kernel.) I have compiled GENERIC and PAE kernels; objdump(1) reports that GENERIC kernel has virtual start address 0xc0449cb0, and PAE has virtual start address 0xc02458f0. Yes, KERNLOAD for PAE is 2MB and for non-PAE is 4MB (to skip PSE page 0). What happens here is that BTX now uses flat memory model, and by not masking higher bits at all, BTX attempts to load kernels at above 3G, which silently fails, and then jumps to the entry point located in no memory unless the machine has enough memory. If the machine has enough physical memory, e.g. 4G, then it works (I think that was the case on the machine John tested this change), but on my test machine I only have 3G of memory, so it fails. Actually, it should never work, as the kernel assumes it is loaded at KERNLOAD. My interim solution to the problem that would still allow booting larger than 16MB kernels is to mask some of the higher bits. Currently, I mask 28 bits that gives possible 256MB which is probably practical. boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpDkDkDWNbkb.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 11:38:24AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:42, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Ah, ok. Make them both just mask the top 8 bits then. :) OK, I backed out your change to boot2.c. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpPW2iquvRdb.pgp Description: PGP signature
Re: Still possible to directly boot without loader?
On Thu, Oct 26, 2006 at 03:42:34PM -0400, John Baldwin wrote: On Thursday 26 October 2006 15:18, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 11:38:24AM -0400, John Baldwin wrote: On Thursday 26 October 2006 10:42, Ruslan Ermilov wrote: On Thu, Oct 26, 2006 at 10:28:09AM -0400, John Baldwin wrote: boot2 should do whatever loader does. But this would be a regression, since loader(8) does the following, in the ELF32 case: : 0 edoofus:ttyp2:/sys/boot/i386/libi386 grep -w entry elf32_freebsd.c : vm_offset_t entry, bootinfop, modulep, kernend; : entry = ehdr-e_entry 0xff; : printf(Start @ 0x%lx ...\n, entry); : __exec((void *)entry, boothowto, bootdev, 0, 0, 0, bootinfop, modulep, kernend); Ah, ok. Make them both just mask the top 8 bits then. :) OK, I backed out your change to boot2.c. Sorry, I meant that both boot2 and loader should follow your proposal of masking 28 bits. Just masking the top 4 bits is probably sufficient. :-) OK, I'll craft a patch tomorrow. This will also require patching at least sys/boot/common/load_elf.c:__elfN(loadimage), maybe something else. I think we could actually mask 30 bits; that would allow to load 1G kernels, provided that sufficient memory exists. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp5j705mSAeB.pgp Description: PGP signature
Please test keyboard-related fixes to be MFCed
Hi,
I'm going to ask re@'s approval to MFC the attached patches to
RELENG_6 in 3 days. I'd appreciate it if some of you who have
issues listed below could test it and report back if it got
better with these patches. What has been fixed:
- If PS/2 keyboard is attached *after* the system has booted,
the keyboard LEDs now work as expected, with or without
kbdmux(4).
- CAPS LED now works on USB keyboards under X.
- It's now possible to build a release with -P in installation
/boot.config, similar to how this was possible for a long
time on i386. (amd64 only.)
- It's now possible to plug a PS/2 keyboard after boot, and
have it working during the initial installation. Previously
it's been disabled by a hint.atkbd.0.flags=0x1 in the
installation /boot/device.hints. It doesn't break USB
keyboard installations which this was a workaround for
before we had kbdmux(4). (amd64 and i386.)
- Related to the previous change; if /boot/device.hints is
updated with a fresh copy of GENERIC.hints, the PS/2
keyboard can be plugged after the system has already booted,
and will work. (amd64 only.)
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
Index: sys/amd64/conf/GENERIC.hints
===
RCS file: /home/ncvs/src/sys/amd64/conf/GENERIC.hints,v
retrieving revision 1.15
diff -u -p -r1.15 GENERIC.hints
--- sys/amd64/conf/GENERIC.hints22 Jul 2004 22:28:34 - 1.15
+++ sys/amd64/conf/GENERIC.hints25 Oct 2006 13:56:37 -
@@ -11,7 +11,6 @@ hint.atkbdc.0.at=isa
hint.atkbdc.0.port=0x060
hint.atkbd.0.at=atkbdc
hint.atkbd.0.irq=1
-hint.atkbd.0.flags=0x1
hint.psm.0.at=atkbdc
hint.psm.0.irq=12
hint.vga.0.at=isa
Index: sys/dev/atkbdc/atkbd.c
===
RCS file: /home/ncvs/src/sys/dev/atkbdc/atkbd.c,v
retrieving revision 1.47.2.2
diff -u -p -r1.47.2.2 atkbd.c
--- sys/dev/atkbdc/atkbd.c 4 Oct 2006 06:09:08 - 1.47.2.2
+++ sys/dev/atkbdc/atkbd.c 25 Oct 2006 13:08:08 -
@@ -482,6 +482,22 @@ atkbd_intr(keyboard_t *kbd, void *arg)
int delay[2];
int c;
+ if (!KBD_HAS_DEVICE(kbd)) {
+ /*
+* The keyboard was not detected before;
+* it must have been reconnected!
+*/
+ state = (atkbd_state_t *)kbd-kb_data;
+ init_keyboard(state-kbdc, kbd-kb_type,
+ kbd-kb_config);
+ KBD_FOUND_DEVICE(kbd);
+ atkbd_ioctl(kbd, KDSETLED, (caddr_t)state-ks_state);
+ get_typematic(kbd);
+ delay[0] = kbd-kb_delay1;
+ delay[1] = kbd-kb_delay2;
+ atkbd_ioctl(kbd, KDSETREPEAT, (caddr_t)delay);
+ }
+
if (KBD_IS_ACTIVE(kbd) KBD_IS_BUSY(kbd)) {
/* let the callback function to process the input */
(*kbd-kb_callback.kc_func)(kbd, KBDIO_KEYINPUT,
@@ -491,22 +507,6 @@ atkbd_intr(keyboard_t *kbd, void *arg)
do {
c = atkbd_read_char(kbd, FALSE);
} while (c != NOKEY);
-
- if (!KBD_HAS_DEVICE(kbd)) {
- /*
-* The keyboard was not detected before;
-* it must have been reconnected!
-*/
- state = (atkbd_state_t *)kbd-kb_data;
- init_keyboard(state-kbdc, kbd-kb_type,
- kbd-kb_config);
- atkbd_ioctl(kbd, KDSETLED, (caddr_t)state-ks_state);
- get_typematic(kbd);
- delay[0] = kbd-kb_delay1;
- delay[1] = kbd-kb_delay2;
- atkbd_ioctl(kbd, KDSETREPEAT, (caddr_t)delay);
- KBD_FOUND_DEVICE(kbd);
- }
}
return 0;
}
Index: sys/dev/usb/ukbd.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ukbd.c,v
retrieving revision 1.52.2.2
diff -u -p -r1.52.2.2 ukbd.c
--- sys/dev/usb/ukbd.c 4 Oct 2006 06:09:10 - 1.52.2.2
+++ sys/dev/usb/ukbd.c 25 Oct 2006 12:17:27 -
@@ -1208,7 +1208,8 @@ ukbd_ioctl(keyboard_t *kbd, u_long cmd,
}
i = *(int *)arg;
/* replace CAPS LED with ALTGR LED for ALTGR keyboards */
- if (kbd-kb_keymap-n_keys ALTGR_OFFSET) {
+ if (state-ks_mode == K_XLATE
+ kbd-kb_keymap-n_keys ALTGR_OFFSET) {
if (i ALKED)
i |= CLKED;
else
Index: release/Makefile
===
RCS file: /home/ncvs/src/release/Makefile,v
retrieving revision 1.887.2.17
diff -u -p -r1.887.2.17 Makefile
--- release/Makefile15 Sep 2006 19:27:40
Re: error in /etc/rc.d/mdconfig{,2}
On Wed, Oct 25, 2006 at 10:44:34PM +0200, Zahemszky G?bor wrote: Hi! I've just found, that both /etc/rc.d/mdconfig, and /etc/rc.d/mdconfig2 file in my 6.2.prerelease (cvsupped yesterday), has an incorrect kldload line: kldstat -q -m g_md || kldload geom_md || err 1 geom_md failed to load. (mdconfig line 97, and mdconfig2 line 104) The module name is g_md, and not geom_md. # $FreeBSD: src/etc/rc.d/mdconfig,v 1.3.2.1 2006/08/21 15:06:38 flz Exp $ # $FreeBSD: src/etc/rc.d/mdconfig2,v 1.3.2.1 2006/08/21 15:06:38 flz Exp $ True. In RELENG_6 the module is named g_md.ko, while in HEAD it was renamed to geom_md.ko. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplpvmbukmN5.pgp Description: PGP signature
Re: 6.2-PRERELEASE em still not working
On Tue, Oct 17, 2006 at 10:26:34AM +0200, Danny Braniss wrote: reposting. with the latest cvsup'ed, the em is sending packets but not receiving. the last working version that i have is from 3rd. Oct. host is S2466 TIGER MPX, but have seen the problem on PIII/STL2 too. o- there is no if_em changes that i can see. o- smp/up has no effect o- there is no usb, nor shared interrups that i can see. Please do a binary search and find the commit that broke it for you. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp4Sc7v6sw6R.pgp Description: PGP signature
Re: ENABLE_SUID_SSH in make.conf
On Tue, Oct 17, 2006 at 02:46:39AM -0500, Albert Chin wrote: According to make.conf(5): ENABLE_SUID_SSH (bool) Set this to install ssh(1) with the set-user-ID bit turned on. However, I think ENABLE_SUID_SSH only sets the suid bit for /usr/libexec/ssh-keysign. Why isn't /usr/libexec/ssh-keysign suid by default anyway? It's pointless without it. Good question. Let's see what our maintainer has to say about it. My feeling as well is that the option should just be removed. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpVFc8hUAViB.pgp Description: PGP signature
Re: FreeBSD and make -j# buildworld usability
On Fri, Oct 13, 2006 at 11:06:37AM -0400, Vivek Khera wrote: On Oct 13, 2006, at 10:31 AM, Buki wrote: I searched the archives and web a little but found many different opinions on stability/usability of using make -j# with buildworld (and buildkernel). Works for me with -j2 on buildworld. My buildkernel fails since I compile acpi static. Hmm, and where and how does it break? This commit (not yet in RELENG_6) doesn't help? : ru 2006-09-06 14:23:40 UTC : : FreeBSD src repository : : Modified files: : sys/i386/acpica Makefile : Log: : Refine previous revision to allow acpi_wakecode.h to be safely built : from both the acpi module build directory and a kernel build directory. : The latter didn't work when one attempted to build a kernel which had : device acpi with the make kernel-toolchain buildkernel command : because a cross-compiler couldn't find anything in the standard system : include path (it's empty in the kernel-toolchain case). : : Fix this by passing a better root path to kernel headers (src/sys) : which works for both cases, kernel and module (-I@ only worked for : module). : : Also, while here, pass -nostdinc (and a different spelling for icc) -- : it's a feature that the kernel source tree is self-contained, and this : change enforces this. : : Reported by:glebius : : Revision ChangesPath : 1.7 +7 -1 src/sys/i386/acpica/Makefile Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpmJ1tyFl693.pgp Description: PGP signature
Re: FreeBSD and make -j# buildworld usability
On Fri, Oct 13, 2006 at 12:56:28PM -0400, Vivek Khera wrote: On Oct 13, 2006, at 12:33 PM, Ruslan Ermilov wrote: Works for me with -j2 on buildworld. My buildkernel fails since I compile acpi static. Hmm, and where and how does it break? This commit (not yet in RELENG_6) doesn't help? To be clear: make buildkernel works, but make -j2 builkernel used to fail complaining that something wasn't built yet. Just tried it now (twice) on an amd64 box and it worked. might have been luck of timing. Tried on an i386 box and it dies here every time with -j2, but builds to completion without: === nullfs (depend) @ - /n/lorax1/usr6/src/sys machine - /n/lorax1/usr6/src/sys/i386/include awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -p awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -q awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- - DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include - I/usr/include -I/n/lorax1/usr6/obj.i386/n/lorax1/usr6/src/sys/KCI32 / n/lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_subr.c /n/ lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c /n/ lorax1/usr6/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c 1 error *** Error code 2 1 error *** Error code 2 1 error 11.259user 14.494sys 84.0%, 0ib 1122ob 1049tx 3006da 4055to 0swp 0:30.63 Perhaps my memory of it being acpi were incorrect (or I've since added nullfs to my kernel...) Can you put somewhere a full (combined stdout + stderr) output available for download, together with the kernel config (if it is not GENERIC)? P.S. Please don't manually exclude me from To:. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpG383CHGhVh.pgp Description: PGP signature
Re: FreeBSD and make -j# buildworld usability
On Fri, Oct 13, 2006 at 01:12:38PM -0400, Vivek Khera wrote: On Oct 13, 2006, at 12:33 PM, Ruslan Ermilov wrote: Works for me with -j2 on buildworld. My buildkernel fails since I compile acpi static. Hmm, and where and how does it break? This commit (not yet i poked around some more and i do see acpi broken, but make just ignores the error during make depend phase when running with -j2 on the i386: /usr/obj/n/lorax1/usr6/src/make.i386/make -f /n/lorax1/usr6/src/sys/ i386/acpica/Makefile MAKESRCPATH=/n/lorax1/usr6/src/sys/i386/acpica rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- - DHAVE_KERNEL_OPTION_HEADERS -I. -I@ -I@/contrib/altq -I@/../include - I/usr/include -I/n/lorax1/usr6/obj.i386/n/lorax1/usr6/src/sys/ KCI32SMP usb_if.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ hid.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/uhub.c /n/ lorax1/usr6/src/sys/modules/usb/../../dev/usb/usb.c /n/lorax1/usr6/ src/sys/modules/usb/../../dev/usb/usb_mem.c /n/lorax1/usr6/src/sys/ modules/usb/../../dev/usb/usb_quirks.c /n/lorax1/usr6/src/sys/modules/ usb/../../dev/usb/usb_subr.c /n/lorax1/usr6/src/sys/modules/usb/../../ dev/usb/usbdi.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ usbdi_util.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ usb_ethersubr.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/ uhci_pci.c /n/lorax1/usr6/src/sys/modules/usb/../../dev/usb/uhci.c /n/ lorax1/usr6/src/sys/modules/usb/../../dev/usb/ohci_pci.c /n/lorax1/ usr6/src/sys/modules/usb/../../dev/usb/ohci.c /n/lorax1/usr6/src/sys/ modules/usb/../../dev/usb/ehci_pci.c /n/lorax1/usr6/src/sys/modules/ usb/../../dev/usb/ehci.c Warning: Object directory not changed from original /n/lorax1/usr6/ obj.i386/n/lorax1/usr6/src/sys/KCI32SMP cc -O2 -fno-strict-aliasing -pipe -I. -I@ -c /n/lorax1/usr6/src/sys/ i386/acpica/acpi_wakecode.S /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S:35:19: assym.s: No such file or directory /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S: Assembler messages: /n/lorax1/usr6/src/sys/i386/acpica/acpi_wakecode.S:103: Error: suffix or operands invalid for `ljmp' *** Error code 1 1 error *** Error code 2 === ukbd (depend) @ - /n/lorax1/usr6/src/sys ... and keeps going until it hits the nullfs depend step where it really stops... OK, please try merging my fix then, it should help. Please come back to me with a success report. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpTYqkkiJ804.pgp Description: PGP signature
Re: FreeBSD and make -j# buildworld usability
On Fri, Oct 13, 2006 at 04:52:18PM -0400, Vivek Khera wrote: On Oct 13, 2006, at 4:07 PM, Ruslan Ermilov wrote: OK, please try merging my fix then, it should help. Please come back to me with a success report. :-) I applied the patch to bring i386/acpica/Makefile up to version 1.7 Same exact error on buildkernel -j2, but success without -j2. I put up logs + kernel config at http://vivek.khera.org/scratch/ buildkernel/ That one has been fixed in RELENG_6, in src/sys/conf/files.i386: : revision 1.538.2.7 : date: 2006/05/25 20:25:44; author: ru; state: Exp; lines: +1 -1 : MFC: 1.545: Add missing acpi_wakecode.h dependency on assym.s. : : : /usr/src/sys/i386/acpica/acpi_wakecode.S:35:19: assym.s: No such file or directory : : /usr/src/sys/i386/acpica/acpi_wakecode.S: Assembler messages: : : /usr/src/sys/i386/acpica/acpi_wakecode.S:103: Error: suffix or operands invalid for `ljmp' : : Reported by:many Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpYUgefyPAmv.pgp Description: PGP signature
Re: buildworld: undefined reference to `SHA256_Update'
On Mon, Oct 09, 2006 at 02:11:13PM +0200, Philip Paeps wrote:
On 2006-10-07 12:09:15 (+0200), Tobias Roth [EMAIL PROTECTED] wrote:
On Sat, Oct 07, 2006 at 01:48:55PM +0400, Ruslan Ermilov wrote:
Verify that libssh.so in objdir lists libmd as its dependency.
No, it doesn't.
As a hackaround, this patch seems to work for me here:
Index: Makefile
===
RCS file: /home/ncvs/src/secure/lib/libssh/Makefile,v
retrieving revision 1.34.2.4
diff -u -r1.34.2.4 Makefile
--- Makefile6 Oct 2006 14:07:23 - 1.34.2.4
+++ Makefile9 Oct 2006 12:10:08 -
@@ -38,8 +38,8 @@
NO_LINT=
-DPADD+=${LIBCRYPTO} ${LIBCRYPT}
-LDADD+=-lcrypto -lcrypt
+DPADD+=${LIBCRYPTO} ${LIBCRYPT} ${LIBMD}
+LDADD+=-lcrypto -lcrypt -lmd
.include bsd.lib.mk
I sent a more complete patch (which includes also fixing static
linking).
I wonder why libssh only lists libmd as a dependency in the !NO_KERBEROS case.
Mysterious mystery...
Because it wasn't required before before the last OpenSSH upgrade.
It's also not required in -CURRENT because libcrypto in -CURRENT
has SHA256 functions, and doesn't need libmd.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpcdtR0ekOde.pgp
Description: PGP signature
Re: buildworld fails in openssh
On Mon, Oct 09, 2006 at 07:12:28AM -1000, Randy Bush wrote:
Please double-check if this is really a problem with -current, and not
with -stable. Afaik, -current is not affected.
doh. with eight -current systems and one -stable, my mind is stuck in
-current. but indeed, this was in -stable. blush
I fixed the list.
The workaround is to re-enable the build of kerberos in /etc/make.conf.
A proper solution is underway, it's ru@ who handles this.
i will probably wait.
Actually it's now in des@'s hands. :-)
A patch is attached if you want it immediately.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
Index: secure/lib/libssh/Makefile
===
RCS file: /home/ncvs/src/secure/lib/libssh/Makefile,v
retrieving revision 1.34.2.4
diff -u -p -r1.34.2.4 Makefile
--- secure/lib/libssh/Makefile 6 Oct 2006 14:07:23 - 1.34.2.4
+++ secure/lib/libssh/Makefile 7 Oct 2006 15:43:13 -
@@ -32,14 +32,14 @@ LDADD= -lz
.if !defined(NO_KERBEROS)
CFLAGS+= -DGSSAPI -DHAVE_GSSAPI_H=1 -DKRB5 -DHEIMDAL
-DPADD+=${LIBGSSAPI} ${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBMD}
${LIBROKEN}
-LDADD+=-lgssapi -lkrb5 -lasn1 -lcom_err -lmd -lroken
+DPADD+=${LIBGSSAPI} ${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN}
+LDADD+=-lgssapi -lkrb5 -lasn1 -lcom_err -lroken
.endif
NO_LINT=
-DPADD+=${LIBCRYPTO} ${LIBCRYPT}
-LDADD+=-lcrypto -lcrypt
+DPADD+=${LIBCRYPTO} ${LIBCRYPT} ${LIBMD}
+LDADD+=-lcrypto -lcrypt -lmd
.include bsd.lib.mk
Index: secure/libexec/ssh-keysign/Makefile
===
RCS file: /home/ncvs/src/secure/libexec/ssh-keysign/Makefile,v
retrieving revision 1.6.2.1
diff -u -p -r1.6.2.1 Makefile
--- secure/libexec/ssh-keysign/Makefile 8 Jul 2006 14:37:18 - 1.6.2.1
+++ secure/libexec/ssh-keysign/Makefile 8 Oct 2006 00:42:40 -
@@ -8,8 +8,8 @@ CFLAGS+=-I${SSHDIR} -include ssh_namespa
BINMODE=4511
.endif
-DPADD= ${LIBSSH} ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ}
-LDADD= -lssh -lcrypt -lcrypto -lz
+DPADD= ${LIBSSH} ${LIBCRYPT} ${LIBCRYPTO} ${LIBMD} ${LIBZ}
+LDADD= -lssh -lcrypt -lcrypto -lmd -lz
.include bsd.prog.mk
Index: secure/usr.bin/sftp/Makefile
===
RCS file: /home/ncvs/src/secure/usr.bin/sftp/Makefile,v
retrieving revision 1.12.2.1
diff -u -p -r1.12.2.1 Makefile
--- secure/usr.bin/sftp/Makefile8 Jul 2006 14:37:18 - 1.12.2.1
+++ secure/usr.bin/sftp/Makefile7 Oct 2006 15:29:30 -
@@ -4,8 +4,8 @@ PROG= sftp
SRCS= sftp.c sftp-client.c sftp-common.c sftp-glob.c progressmeter.c
CFLAGS+=-I${SSHDIR} -include ssh_namespace.h
-DPADD= ${LIBSSH} ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} ${LIBEDIT}
-LDADD= -lssh -lcrypt -lcrypto -lz -ledit
+DPADD= ${LIBSSH} ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ} ${LIBEDIT} ${LIBNCURSES}
+LDADD= -lssh -lcrypt -lcrypto -lz -ledit -lncurses
.include bsd.prog.mk
Index: secure/usr.bin/ssh/Makefile
===
RCS file: /home/ncvs/src/secure/usr.bin/ssh/Makefile,v
retrieving revision 1.31.2.1
diff -u -p -r1.31.2.1 Makefile
--- secure/usr.bin/ssh/Makefile 8 Jul 2006 14:37:18 - 1.31.2.1
+++ secure/usr.bin/ssh/Makefile 7 Oct 2006 17:26:38 -
@@ -11,13 +11,15 @@ SRCS= ssh.c readconf.c clientloop.c ssht
sshconnect.c sshconnect1.c sshconnect2.c \
gss-genr.c
+DPADD= ${LIBSSH} ${LIBMD} ${LIBUTIL} ${LIBZ}
+LDADD= -lssh -lmd -lutil -lz
DPADD= ${LIBSSH} ${LIBUTIL} ${LIBZ}
LDADD= -lssh -lutil -lz
.if !defined(NO_KERBEROS)
CFLAGS+= -DGSSAPI -DHAVE_GSSAPI_H=1 -DKRB5 -DHEIMDAL
-DPADD+= ${LIBGSSAPI} ${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBMD}
${LIBROKEN}
-LDADD+= -lgssapi -lkrb5 -lasn1 -lcom_err -lmd -lroken
+DPADD+= ${LIBGSSAPI} ${LIBKRB5} ${LIBASN1} ${LIBCOM_ERR} ${LIBROKEN}
+LDADD+= -lgssapi -lkrb5 -lasn1 -lcom_err -lroken
.endif
.if defined(X11BASE)
Index: secure/usr.bin/ssh-keyscan/Makefile
===
RCS file: /home/ncvs/src/secure/usr.bin/ssh-keyscan/Makefile,v
retrieving revision 1.9.2.1
diff -u -p -r1.9.2.1 Makefile
--- secure/usr.bin/ssh-keyscan/Makefile 8 Jul 2006 14:37:19 - 1.9.2.1
+++ secure/usr.bin/ssh-keyscan/Makefile 7 Oct 2006 15:29:58 -
@@ -3,8 +3,8 @@
PROG= ssh-keyscan
CFLAGS+=-I${SSHDIR} -include ssh_namespace.h
-DPADD= ${LIBSSH} ${LIBCRYPT} ${LIBCRYPTO} ${LIBZ}
-LDADD= -lssh -lcrypt -lcrypto -lz
+DPADD= ${LIBSSH} ${LIBCRYPT} ${LIBCRYPTO} ${LIBMD} ${LIBZ}
+LDADD= -lssh -lcrypt -lcrypto -lmd -lz
.include bsd.prog.mk
pgp5YzxggRXv9.pgp
Description: PGP signature
Re: buildworld: undefined reference to `SHA256_Update'
On Sat, Oct 07, 2006 at 11:07:25AM +0200, Tobias Roth wrote: Hi I get this buildworld error with a reshly updated RELENG_6: cc -O2 -pipe -fno-strict-aliasing -march=pentium-m -I/usr/src/secure/libexec/sftp-server/../../../crypto/openssh -include ssh_namespace.h -DNO_IDEA -o sftp-server sftp-server.o sftp-common.o -lssh -lcrypt -lcrypto -lz /usr/obj/usr/src/tmp/usr/lib/libssh.so: undefined reference to `SHA256_Update' /usr/obj/usr/src/tmp/usr/lib/libssh.so: undefined reference to `SHA256_Final' /usr/obj/usr/src/tmp/usr/lib/libssh.so: undefined reference to `SHA256_Init' *** Error code 1 Stop in /usr/src/secure/libexec/sftp-server. I was away for the last two weeks, so maybe this is already known? All I did so far was check the latest security advisories and google, but that turned out nothing usable. Verify that libssh.so in objdir lists libmd as its dependency. Verify that libmd.so in objdir has these functions. You should get output similar to this: : # env LD_LIBRARY_PATH=/usr/obj/usr/src/tmp/lib:/usr/obj/usr/src/tmp/usr/lib ldd /usr/obj/usr/src/tmp/usr/lib/libssh.so : /usr/obj/usr/src/tmp/usr/lib/libssh.so: : libz.so.3 = /usr/obj/usr/src/tmp/lib/libz.so.3 (0x80097d000) : libgssapi.so.8 = /usr/obj/usr/src/tmp/usr/lib/libgssapi.so.8 (0x800a91000) : libkrb5.so.8 = /usr/obj/usr/src/tmp/usr/lib/libkrb5.so.8 (0x800ba) : libasn1.so.8 = /usr/obj/usr/src/tmp/usr/lib/libasn1.so.8 (0x800ce4000) : libcom_err.so.3 = /usr/obj/usr/src/tmp/usr/lib/libcom_err.so.3 (0x800e0d000) : libmd.so.3 = /usr/obj/usr/src/tmp/lib/libmd.so.3 (0x800f0f000) : libroken.so.8 = /usr/obj/usr/src/tmp/usr/lib/libroken.so.8 (0x80101b000) : libcrypto.so.4 = /usr/obj/usr/src/tmp/lib/libcrypto.so.4 (0x801129000) : libcrypt.so.3 = /usr/obj/usr/src/tmp/lib/libcrypt.so.3 (0x80137) : # nm /usr/obj/usr/src/tmp/usr/lib/libmd.so | grep SHA256_Update : 3820 T SHA256_Update : # Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp09YW5GUvk0.pgp Description: PGP signature
Re: buildworld: undefined reference to `SHA256_Update'
On Sat, Oct 07, 2006 at 02:04:40PM +0200, Tobias Roth wrote: On Sat, Oct 07, 2006 at 12:09:15PM +0200, Tobias Roth wrote: Bjoern A. Zeeb suggested that might be connected to not having Kerberos built. I'll now remove NO_KERBEROS=true from my make.conf and try building again. I'll report my findings. Adding kerberos to the build helped. What is the next action? Should I submit a PR? No, I'll look into it. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpawZVWEy5i3.pgp Description: PGP signature
Re: RELENG_6/amd64 buildworld error
On Fri, Oct 06, 2006 at 02:02:27AM +0400, Dmitry Morozovsky wrote: Hi there colleagues am I the only one who got the following error? === sbin/geom/class/mirror (all) cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -march=opteron -I/usr/src/sbin/geom/class/mirror/../.. -I/usr/src/sbin/geom/class/mirror/../../../../sys -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/sbin/geom/class/mirror/geom_mirror.c -o geom_mirror.So /usr/src/sbin/geom/class/mirror/geom_mirror.c: In function `mirror_main': /usr/src/sbin/geom/class/mirror/../../../../sys/geom/mirror/g_mirror.h:374: warning: inlining failed in call to 'mirror_metadata_decode': --param max-inline-insns-single limit reached after inlining into the callee /usr/src/sbin/geom/class/mirror/geom_mirror.c:310: warning: called from here /usr/src/sbin/geom/class/mirror/../../../../sys/geom/mirror/g_mirror.h:374: warning: inlining failed in call to 'mirror_metadata_decode': --param max-inline-insns-single limit reached after inlining into the callee /usr/src/sbin/geom/class/mirror/geom_mirror.c:346: warning: called from here It I go into sbin/geom/class/mirror and compile it like this: make DEBUG_FLAGS=-I/usr/src/sbin/geom/class/mirror/../../../../sys I also get this error. The question is why you have this -I added. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpGbMEUwPrjE.pgp Description: PGP signature
Re: RELENG_6/amd64 buildworld error
On Fri, Oct 06, 2006 at 09:24:39AM +0400, Ruslan Ermilov wrote: On Fri, Oct 06, 2006 at 02:02:27AM +0400, Dmitry Morozovsky wrote: Hi there colleagues am I the only one who got the following error? === sbin/geom/class/mirror (all) cc -fpic -DPIC -O2 -fno-strict-aliasing -pipe -march=opteron -I/usr/src/sbin/geom/class/mirror/../.. -I/usr/src/sbin/geom/class/mirror/../../../../sys -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/sbin/geom/class/mirror/geom_mirror.c -o geom_mirror.So /usr/src/sbin/geom/class/mirror/geom_mirror.c: In function `mirror_main': /usr/src/sbin/geom/class/mirror/../../../../sys/geom/mirror/g_mirror.h:374: warning: inlining failed in call to 'mirror_metadata_decode': --param max-inline-insns-single limit reached after inlining into the callee /usr/src/sbin/geom/class/mirror/geom_mirror.c:310: warning: called from here /usr/src/sbin/geom/class/mirror/../../../../sys/geom/mirror/g_mirror.h:374: warning: inlining failed in call to 'mirror_metadata_decode': --param max-inline-insns-single limit reached after inlining into the callee /usr/src/sbin/geom/class/mirror/geom_mirror.c:346: warning: called from here It I go into sbin/geom/class/mirror and compile it like this: make DEBUG_FLAGS=-I/usr/src/sbin/geom/class/mirror/../../../../sys I also get this error. The question is why you have this -I added. The below explains why the warning is only seen when using non-system headers: :-Winline :Warn if a function can not be inlined and it was declared as :inline. Even with this option, the compiler will not warn about :failures to inline functions declared in system headers. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp3lJnduj5jF.pgp Description: PGP signature
Re: 6.2-PRE /boot/loader
Hi John, On Tue, Oct 03, 2006 at 03:00:40PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. Do you mean that my (uncommitted) changes can cause this or are you trying to say that making it use high and more memory for heap by default would probably be a good idea? Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpe7t3jjpm9j.pgp Description: PGP signature
Re: 6.2-PRE /boot/loader
On Tue, Oct 03, 2006 at 11:47:35PM +0400, Ruslan Ermilov wrote: Hi John, On Tue, Oct 03, 2006 at 03:00:40PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. Do you mean that my (uncommitted) changes can cause this or are you trying to say that making it use high and more memory for heap by default would probably be a good idea? Hmm, well. I forgot that I've already committed them. But it doesn't use high memory by default, only if bzip2 support is activated. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpH23KlIzVHg.pgp Description: PGP signature
Re: 6.2-PRE /boot/loader
On Tue, Oct 03, 2006 at 03:58:38PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 15:48, Ruslan Ermilov wrote: On Tue, Oct 03, 2006 at 11:47:35PM +0400, Ruslan Ermilov wrote: Hi John, On Tue, Oct 03, 2006 at 03:00:40PM -0400, John Baldwin wrote: On Tuesday 03 October 2006 12:55, Norbert Augenstein wrote: Hi list, i have just updated to 6.2-PRERELEASE and GRUB is unable to use the new /boot/loader. Ending in an endless loop rebooting after selecting FreeBSD. As a workaround it was possible to chainload FreeBSD. Further investigation shows that /boot/loader.old is woking. So what can cause the new loader to fail? I have not set CFLAGS / CPUTYPE in /etc/make.conf No other problems , em device is working fine here:) Talk to ru@ about his changes to make it use high memory by default. Do you mean that my (uncommitted) changes can cause this or are you trying to say that making it use high and more memory for heap by default would probably be a good idea? Hmm, well. I forgot that I've already committed them. But it doesn't use high memory by default, only if bzip2 support is activated. I thought you changed that from '#ifdef LOADER_BZIP2_SUPPORT' to '#if 1' in your patches so it now always uses high memory? In experimental uncommitted patches, yes. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpNiqfK0hS74.pgp Description: PGP signature
Re: [PATCH] Various smbus(4) driver fixups and locking
On Tue, Oct 03, 2006 at 09:00:29PM +0200, Torfinn Ingolfsen wrote: On Mon, 02 Oct 2006 15:53:26 -0400 John Baldwin [EMAIL PROTECTED] wrote: http://www.FreeBSD.org/~jhb/patches/smbus_locking.patch Hmm, I have a Nforce4-based maonboard, and went looking for nfsmb, but I can't find it anywhere on my system. My system is: [EMAIL PROTECTED] uname -a FreeBSD kg-quiet.kg4.no 6.1-STABLE FreeBSD 6.1-STABLE #9: Wed Sep 20 22:59:59 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/QUIET amd64 Isn't that strange? How did you search for it? Or is nfsmb only an i386-thing? Definitely not. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpJq2xgbTsfQ.pgp Description: PGP signature
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
On Sat, Sep 30, 2006 at 09:29:06AM +0200, Uwe Doering wrote: Ruslan Ermilov wrote: [...] OK, you had 4.11 and what were you trying to build? RELENG_4? So I can try to reproduce the problem here. Yes, I use RELENG_4. Thanks for your help. Worked for me building fresh RELENG_4: : uname -srm : FreeBSD 4.10-RELEASE i386 : tail -3 build.log : rm -f freebsd.submit.cf : m4 -D_CF_DIR_=/spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/ /spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /spool/ru_tmp/src/etc/sendmail/freebsd.submit.mc freebsd.submit.cf : chmod 444 freebsd.submit.cf : Thanks for testing it. So this problem seems to be specific to my workstation. If it happens again I'll investigate it more thoroughly. Don't hesitate to let me know (I'll need a full combined stdout+stderr output to investigate). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp5qng82oj0P.pgp Description: PGP signature
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
On Fri, Sep 29, 2006 at 06:01:14PM +0200, Christer Solskogen wrote: On Fri, 29 Sep 2006 08:27:55 -0700 security [EMAIL PROTECTED] wrote: Christer Solskogen wrote: On Fri, 29 Sep 2006 05:30:05 -0700 Colin Percival [EMAIL PROTECTED] wrote: Do you mean using different mirrors? I'm using a supfile for that. But if you mean building I used 'make buildkernel buildworld' But doing a make includes did the trick. It compiles as it should now. I though the order was always buildworld before buildkernel You can choose what order you want. It will work either way. For the record; a word of a patch for the patch was just in. No, buildworld should generally be built before buildkernel because buildworld also builds (possibly new) a compiler and binutils that buildkernel will use. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp7qGzoFWfAh.pgp Description: PGP signature
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
On Fri, Sep 29, 2006 at 05:40:36PM +0200, Uwe Doering wrote: [...] The same happened on my workstation, which runs 4.11. The cause of this problem is that the openssl sources under '/usr/src' apparently use some include files installed under '/usr/include/openssl' instead of those in the '/usr/src' tree. The fix for me was to copy the '*.h' files that changed into '/usr/include/openssl' by hand. Afterwards things worked as expected. This is of course just a workaround. The proper fix would be to modify the respective makefiles to add all the directories where there are header files to the list of include directories given to 'cc' with '-I' options. This apparently hasn't been done so far. At least not completely. No. The correct way is to either do a full build (aka buildworld), or a partial build by first installing headers, and then doing the library build. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpKpddu9fSDn.pgp Description: PGP signature
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
On Fri, Sep 29, 2006 at 08:34:29PM +0200, Uwe Doering wrote: Ruslan Ermilov wrote: On Fri, Sep 29, 2006 at 05:40:36PM +0200, Uwe Doering wrote: [...] The same happened on my workstation, which runs 4.11. The cause of this problem is that the openssl sources under '/usr/src' apparently use some include files installed under '/usr/include/openssl' instead of those in the '/usr/src' tree. The fix for me was to copy the '*.h' files that changed into '/usr/include/openssl' by hand. Afterwards things worked as expected. This is of course just a workaround. The proper fix would be to modify the respective makefiles to add all the directories where there are header files to the list of include directories given to 'cc' with '-I' options. This apparently hasn't been done so far. At least not completely. No. The correct way is to either do a full build (aka buildworld), or a partial build by first installing headers, and then doing the library build. ?? Did you notice the subject of this thread? The problem occured while running 'buildworld'. It doesn't matter. What you suggest is not the correct way. Perhaps the buildworld is broken, but that's a separate issue. My understanding so far is that the files under '/usr/include' don't get touched until I run 'installworld'. So the 'buildworld' universe has to be self-contained. That's what I was trying to point out. Yes, they are not touched. During buildworld, a special version of the compiler is built that looks headers up in the temporary location, normally /usr/obj/usr/src/tmp/usr/include. Then all (new) headers are installed there, then new libraries are built, then all the rest. If buildworld touched /usr/include, you could easily end up with a partially upgraded system, e.g. if build failed in the middle. If it still fails for you (the buildworld), please collect and put the full combiled stdout + stderr output from running make buildworld available somewhere for download and analysis. Colin said he did build all worlds, on all patched branches. OK, you had 4.11 and what were you trying to build? RELENG_4? So I can try to reproduce the problem here. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpgfH00E7zlp.pgp Description: PGP signature
Re: buildworld fails after patch (FreeBSD-SA-06:23.openssl)
On Fri, Sep 29, 2006 at 09:21:56PM +0200, Uwe Doering wrote: Ruslan Ermilov wrote: It doesn't matter. What you suggest is not the correct way. Perhaps the buildworld is broken, but that's a separate issue. My understanding so far is that the files under '/usr/include' don't get touched until I run 'installworld'. So the 'buildworld' universe has to be self-contained. That's what I was trying to point out. Yes, they are not touched. During buildworld, a special version of the compiler is built that looks headers up in the temporary location, normally /usr/obj/usr/src/tmp/usr/include. Then all (new) headers are installed there, then new libraries are built, then all the rest. If buildworld touched /usr/include, you could easily end up with a partially upgraded system, e.g. if build failed in the middle. If it still fails for you (the buildworld), please collect and put the full combiled stdout + stderr output from running make buildworld available somewhere for download and analysis. Colin said he did build all worlds, on all patched branches. Unfortunately I can no longer reproduce the error because I fixed the problem by hand, as pointed out above. Sorry. OK, you had 4.11 and what were you trying to build? RELENG_4? So I can try to reproduce the problem here. Yes, I use RELENG_4. Thanks for your help. Worked for me building fresh RELENG_4: : uname -srm : FreeBSD 4.10-RELEASE i386 : tail -3 build.log : rm -f freebsd.submit.cf : m4 -D_CF_DIR_=/spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/ /spool/ru_tmp/src/etc/sendmail/../../contrib/sendmail/cf/m4/cf.m4 /spool/ru_tmp/src/etc/sendmail/freebsd.submit.mc freebsd.submit.cf : chmod 444 freebsd.submit.cf : Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpOHMAdiF8EY.pgp Description: PGP signature
Re: 6.2-PRERELEASE/amd64 boot kernel.gz failes
On Thu, Sep 28, 2006 at 02:33:10AM +0400, Ruslan Ermilov wrote: I can confirm this: RELENG_6 doesn't pxeboot when /boot/kernel/kernel is gzipped. In my case, it hangs just after loading a loader.conf file. I've also verified that loading gzipped kernels/modules works on 7-CURRENT/i386. So it's either loader vs. pxeboot issue (unlikely, since pxeboot reuses the loader binary), or i386 vs. amd64 issue (unlikely as well as amd64 reuses the i386 boot code), or more likely because some changes were not MFCed. Perhaps this one: : sobomax 2005-12-19 09:00:11 UTC : : FreeBSD src repository : : Modified files: : sys/boot/i386/libi386 Makefile biosdisk.c biospnp.c biossmap.c : i386_copy.c : Log: : Long-long time ago, when the trees were large and memory expensive amount of : memory directly available to loader(8) and friends was limited to 640K on i386. : Those times have passed long time ago and now loader(8) can directly access : up to 4GB of RAM at least theoretically. At the same time, there are several : places where it's assumed that malloc() will only allocate memory within : first megabyte. : : Remove that assumption by allocating appropriate bounce buffers for BIOS : calls on stack where necessary. : : This allows using memory above first megabyte for heap if necessary. : : Revision ChangesPath : 1.39 +3 -0 src/sys/boot/i386/libi386/Makefile : 1.46 +10 -17src/sys/boot/i386/libi386/biosdisk.c : 1.10 +1 -1 src/sys/boot/i386/libi386/biospnp.c : 1.4 +3 -2 src/sys/boot/i386/libi386/biossmap.c : 1.11 +6 -22 src/sys/boot/i386/libi386/i386_copy.c I'll narrow this down tomorrow if noone bites me while I sleep. :-) Yes, this and the follow-up commit plus the following diff make pxeboot work with gzipped files. %%% Index: i386/loader/main.c === RCS file: /home/ncvs/src/sys/boot/i386/loader/main.c,v retrieving revision 1.37 diff -u -r1.37 main.c --- i386/loader/main.c 4 Aug 2006 07:56:32 - 1.37 +++ i386/loader/main.c 28 Sep 2006 09:06:02 - @@ -91,7 +91,7 @@ */ bios_getmem(); -#ifdef LOADER_BZIP2_SUPPORT +#if 1 heap_top = PTOV(memtop_copyin); memtop_copyin -= 0x30; heap_bottom = PTOV(memtop_copyin); %%% Here's the loader heap command output on the same machine: : 6.x /boot/loader (unpatched): : OK heap : Active Allocations: 803/2173 : 274432 bytes reserved 194432 bytes allocated : 65 fragments (30016 bytes fragmented) : heap base at 0x404c0, top at 0x834c0 : : 7.x pxeboot loader (unpatched): : OK heap : Active Allocations: 896/2209 : 229376 bytes reserved 196728 bytes allocated : 71 fragments (18992 bytes fragmented) : heap base at 0x404c0, top at 0x784c0, upper limit at 0x9fc00 : : 7.x pxeboot loader (patched): : OK heap : Active Allocations: 896/2209 : 229376 bytes reserved 196728 bytes allocated : 71 fragments (18992 bytes fragmented) : heap base at 0xfbce6000, top at 0xfbd1e000, upper limit at 0xfbfe6000 Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpaebVazxkOH.pgp Description: PGP signature
Re: 6.2-PRERELEASE/amd64 boot kernel.gz failes
On Wed, Sep 27, 2006 at 05:09:16PM +0300, Danny Braniss wrote: originally posted to [EMAIL PROTECTED]: Hi, While trying to figure out why boot/pxeboot failes on some kernels/hosts, I think i've come up with one solid nogo, if the kernel is gzipped it always fails. Can someone confirm this? or am i suffering from some local problem? I can confirm this: RELENG_6 doesn't pxeboot when /boot/kernel/kernel is gzipped. In my case, it hangs just after loading a loader.conf file. I've also verified that loading gzipped kernels/modules works on 7-CURRENT/i386. So it's either loader vs. pxeboot issue (unlikely, since pxeboot reuses the loader binary), or i386 vs. amd64 issue (unlikely as well as amd64 reuses the i386 boot code), or more likely because some changes were not MFCed. Perhaps this one: : sobomax 2005-12-19 09:00:11 UTC : : FreeBSD src repository : : Modified files: : sys/boot/i386/libi386 Makefile biosdisk.c biospnp.c biossmap.c : i386_copy.c : Log: : Long-long time ago, when the trees were large and memory expensive amount of : memory directly available to loader(8) and friends was limited to 640K on i386. : Those times have passed long time ago and now loader(8) can directly access : up to 4GB of RAM at least theoretically. At the same time, there are several : places where it's assumed that malloc() will only allocate memory within : first megabyte. : : Remove that assumption by allocating appropriate bounce buffers for BIOS : calls on stack where necessary. : : This allows using memory above first megabyte for heap if necessary. : : Revision ChangesPath : 1.39 +3 -0 src/sys/boot/i386/libi386/Makefile : 1.46 +10 -17src/sys/boot/i386/libi386/biosdisk.c : 1.10 +1 -1 src/sys/boot/i386/libi386/biospnp.c : 1.4 +3 -2 src/sys/boot/i386/libi386/biossmap.c : 1.11 +6 -22 src/sys/boot/i386/libi386/i386_copy.c I'll narrow this down tomorrow if noone bites me while I sleep. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp71AsPmXP7J.pgp Description: PGP signature
Re: make release vs. installworld
On Tue, Sep 26, 2006 at 09:30:25AM +0200, Ulrich Spoerlein wrote: [...] So, what's the recommended way to a) build own releases Follow the release(7) manpage instructions. and b) update your servers with it. You can use shell-script type of installation to do binary upgrades, .../R/stage/dists/*/install.sh. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpap7rkxFOyP.pgp Description: PGP signature
Re: make release vs. installworld
On Tue, Sep 26, 2006 at 10:18:05AM +0200, Ulrich Spoerlein wrote: On 9/26/06, Ruslan Ermilov [EMAIL PROTECTED] wrote: On Tue, Sep 26, 2006 at 09:30:25AM +0200, Ulrich Spoerlein wrote: [...] So, what's the recommended way to a) build own releases Follow the release(7) manpage instructions. The actual release building is working fine. It's just that various binaries disappear from the object directory. The object files itself are still there: cat.o, df.o, dd.o, echo.o. But where have the binaries gone? If I understand release(7) correctly, it does a full buildworld/installworld cycle within the chroot. How can the installworld succeed? After installworld inside the release chroot succeeds, the release.4 target makes one or more crunched binaries, and these throw away some stuff in the objdir. In my release object directory, I don't see the hostname, etc. which is expected (they are part of these crunched binaries), but chmod is cerainly here: $ ls -l /spool/release/usr/obj/usr/src/bin/chmod/ total 256 -rwxr-xr-x 1 root wheel 10974 Sep 12 19:01 chmod -rw-r--r-- 1 root wheel 2824 Sep 12 19:01 chmod.1.cat.gz -rw-r--r-- 1 root wheel 3459 Sep 12 19:01 chmod.1.gz -rw-r--r-- 1 root wheel 6816 Sep 12 19:01 chmod.o $ The bottomline is that without fixing release.4 you cannot reuse the release object directory to do an installworld. Fixing release.4 is not easy since it reuses some preparatory stuff built by early stages of buildworld, to be upgrade- and cross-friendly, so just changing MAKEOBJDIRPREFIX wouldn't work (just verified this). and b) update your servers with it. You can use shell-script type of installation to do binary upgrades, .../R/stage/dists/*/install.sh. Thanks for the tip, that might work. Although I would have preferred a 'make installkernel installworld delete-old delete-old-libs; mergemaster'. There is a serious drawback in just installing the distributions: It will clobber /etc. And since I have to run mergemaster and delete-old anyway, there is no way around mount /usr/src via NFS. Perhaps I just do a full 'make buildworld' inside the chroot after 'make release' has finished. That way all the binaries should be where they are. Any objections? If you do a make -DNO_CLEAN buildworld it won't build exactly the same binaries as a normal buildworld would do. This has to do with the same bug that crunched binaries build reuses the same object directory. Will this interfere with release.6 - release.8? I don't undertstand your question. After release has rolled, release.[6-8] have already been built, the contents has been packaged, and you're free to do whatever you want with your /usr/obj (in the release chroot). Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpi0MTRzKQzN.pgp Description: PGP signature
Re: Building a kernel with config ?
On Tue, Sep 26, 2006 at 11:23:49AM +0100, Pete French wrote: On Mon, 25 Sep 2006 11:34:42 -0700, Kevin Oberman [EMAIL PROTECTED] wrote: 2. Building a kernel with config is not officially supported. It's at your risk and may not work in all cases. Build a kernel with: cd /usr/src make buildkernel I was not aware that you wern't supposed to use config anymore - and I am not convinced that the suggested alternative is actually a replacement as I thought that buildkernel required you to have built the world first ? Is this no longer true ? If it *is* true thhen what is the alternative to using 'config' which should be used if you are on a system where you do not have the time or the disc space to rebuild the world and simply want to recompile the kernel ? If you're upgrading or cross-building for a different architecture then you should be using the upgrade path via buildworld/buildkernel. If you're building the kernel on (and for) a system whose binaries match the sources you're attempting to build your kernel from, you are of course free to use the classical config/make method. Basically, the upgrade path does the same thing (config/make) but also ensures that the tools (compiler, toolchain, headers, libraries, config(8), etc.) that are used for the kernel build are up-to-date with your sources. Obviously, when you're NOT upgrading and cross building, your installed tools are up-to-date with your sources, and can be used safely, so you can use a classical config/make method. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpda3V6ZrzIx.pgp Description: PGP signature
Re: Minidumps in -STABLE and smaller than physical memory
On Thu, Sep 21, 2006 at 11:14:33AM +0100, Gavin Atkinson wrote: On Thu, 2006-09-21 at 11:44 +0300, Dmitry Pryanishnikov wrote: Hello! I've noticed (with the 2-day old RELENG_6) that I still can't configure my 256Mb swap partition as a dump device for i386 machine with 1Gb RAM despite having minidumps enabled: [EMAIL PROTECTED] sysctl debug.minidump debug.minidump: 1 [EMAIL PROTECTED] dumpon -v /dev/ad0s3b /dev/ad0s3b is smaller than physical memory Am I correctly understand that minidumps should lift the restriction sizeof(dumpdev) = sizeof(RAM) Yes. http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/dumpon/dumpon.c.diff?r1=1.22r2=1.23 needs to be MFC'd. I sent an MFC request to [EMAIL PROTECTED] Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpaVFoQyArAH.pgp Description: PGP signature
Re: RELENG_6 does not compile
On Thu, Sep 21, 2006 at 08:00:40PM +0200, martinko wrote: hello list, i've just pulled the releng_6 sources and run make -j4 buildworld as usual and this i've got: === gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info.info info.info.gz gzip -cn info-stnd.info info-stnd.info.gz gzip -cn texinfo.info texinfo.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error I'm generally interested in fixing -jX build failures. I'd need at least the following info: - the contents of /etc/make.conf - exact make command - full output (combined stdout + stderr) available somewhere for download in a compressed form Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpIY4BZIpOU6.pgp Description: PGP signature
Re: 6.2-PRE/amd64: make installworld fails: btxld:No such file or directory
On Thu, Sep 14, 2006 at 06:55:24PM +0200, Raphael H. Becker wrote: Hi * today i checked out fresh RELENG_6 on my amd64, build(world|kernel) seems fine, installworld fails: [...] === sys/boot/i386/btx (install) === sys/boot/i386/btx/btx (install) === sys/boot/i386/btx/btxldr (install) === sys/boot/i386/btx/lib (install) === sys/boot/i386/boot2 (install) btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin btxld:No such file or directory *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 [...] It's trying to build things at an inappropriate time (install phase), hence the error. Why i386 here: boot/i386/boot2/? amd64 shares the boot code with i386. I did the following procedure: 1) install new Dell PE2950 with amd64/6.1-RELEASE from CD (minimal) 2) cvsup /usr/src to RELENG_6 this afternoon 3) make clean buildworld buildkernel (forgot to build it for SMP) 4) make buildkernel KERNCONF=PE2950 (which is just SMP plus ident a.t.m) 5) make installkernel KERNCONF=PE2950 6) reboot 7) make installworld -- fails. Did I miss something here? How to fix? 1) Check that your date/time is correct during the build. 2) Check that your date/time is correct during the install (perhaps missed adjkerntz -i after rebooting into SU?) 3) Check that /usr/src doesn't have files from the future. Is this amd64 specific? No. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpdOK9h1Y37o.pgp Description: PGP signature
Re: cap_mkdb: illegal option -i. upgrade 5.4-6.1
On Wed, Sep 13, 2006 at 10:20:39AM +0200, [EMAIL PROTECTED] wrote:
Ruslan Ermilov wrote:
On Tue, Sep 12, 2006 at 04:52:32PM +0200, [EMAIL PROTECTED] wrote:
Hi list
I'm upgrading 5.4 p18 to 6.1 p6.
here's my tag: RELENG_6_1
I did:
make update
make cleanworld
make buildworld
which gives following issue:
cap_mkdb: illegal option -i
It seems a known problem on netbsd during buildworld compilation. here's
the solution I'm tring:
cd /usr/src/usr.bin/cap_mkdb
make clean
make
make install
and I'm building world again.
is that a known problem on freebsd?
This shouldn't happen. The buildworld target detects the current
version of your system, and bootstraps cap_mkdb if necessary:
: .if ${BOOTSTRAPPING} 600015
: _cap_mkdb= usr.bin/cap_mkdb
: .endif
BOOTSTRAPPING is defined as follows:
: .if !defined(OSRELDATE)
: .if exists(/usr/include/osreldate.h)
: OSRELDATE!= awk '/^\#define[[:space:]]*__FreeBSD_version/ { print
$$3 }' \
: /usr/include/osreldate.h
: .else
: OSRELDATE= 0
: .endif
That is, it's the value of __FreeBSD_version as defined in
/usr/include/osreldate.h. If your /usr/include/osreldate.h
is lying about the current version, e.g. if you accidentally
installed the new headers, then you can force it to zero,
such as:
make buildworld OSRELDATE=0
Cheers,
I'm pretty sure about what's happing
i'd propably built my world twice...or something like that. anyway,
building
cap_mkdb before the world resolved the issue.
But that's what buildworld already does (when it detects the need
to do so). My point was to make it clear. :-)
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpQTXfDuIF8I.pgp
Description: PGP signature
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 03:08:23AM -0700, Pete Slagle wrote: Oliver Fromme wrote: Marc G. Fournier [EMAIL PROTECTED] wrote: What are ppl currently using for CFLAGS/COPTFLAGS in /etc/make.conf for building kernel/world? I know awhile back it wasn't recommended to go above -O2, for instance, but suspect that has changed ... ? The best optimization is probably to not override the defaults at all, because they're already pretty optimal. In fact, by overriding the defaults there's a good chance to make things worse. :-) The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. /etc/make.conf on most of my 6.1 machines contains (in part) this: CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS= -O2 -pipe I no longer remember exactly why, but at some point I must have understood or assumed that to be the recommendation. Just to be completely clear, are you saying that this CFLAGS=-O2 -pipe -fno-strict-aliasing COPTFLAGS= -O2 -pipe -fno-strict-aliasing would be better in the general case? Doesn't matter; kern.pre.mk will automatically add -fno-strict-aliasing to COPTFLAGS if needed: : . if !empty(COPTFLAGS:M-O[23s]) empty(COPTFLAGS:M-fno-strict-aliasing) : COPTFLAGS+= -fno-strict-aliasing : . endif Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpXqRQmgleu1.pgp Description: PGP signature
Re: optimization levels for 6-STABLE build{kernel,world}
On Wed, Sep 13, 2006 at 11:26:00AM +0200, Oliver Fromme wrote: Stefan Lambrev wrote: Oliver Fromme wrote: The default CFLAGS are -O2 -pipe -fno-strict-aliasing. Anything above -O2 isn't supported, and using -O2 without -fno-strict-aliasing also isn't supported (and will create broken code for some programs). A common mistake is to specify CFLAGS=-O2 -pipe and omit -fno-strict-aliasing. That'll shot you in the foot sooner or later. May be default flags have to be set here: /usr/src/share/examples/etc/make.conf ? I'm asking because in this file I read: # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to -O or -O2 before submitting bug # reports without patches to the developers. # #CFLAGS= -O -pipe May be -fno-strict-aliasing have to be added here then ? Yes, you are right. I think a clarification should be added to the make.conf(5) manual page and to the /usr/share/examples/etc/make.conf file. Someone care to submit a PR ...? Should be fixed in src/share/examples/etc/make.conf,v 1.277. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpCOeN3iL0RB.pgp Description: PGP signature
Re: Releng_6 suddenly no longer -j safe
On Tue, Sep 12, 2006 at 01:53:28PM +0200, [LoN]Kamikaze wrote: Last time I built a kernel on Releng_6 (only a couple of days ago) everything was fine with -j 4. Now buildkernel stops, this is an example: === sound/driver/als4000 (depend) awk -f @/tools/makeobjops.awk @/kern/device_if.m -h machine - /usr/src/sys/i386/include awk: can't open file @/tools/makeobjops.awk source line number 1 source file @/tools/makeobjops.awk context is *** Error code 2 @ - /usr/src/sys 1 error ... Where it stops is random (I suppose it sometimes is accidentally built in the right order), but the error is always similar. This puzzled me for a while, since kmod.mk has mechanisms that try to ensure `@' is built before it's accessed. What the implementation is missing is anti-footshooting measures. I bet your /usr/src/sys/modules/ has some stray `@' symlinks possibly left from compiling modules manually without creating object directories, and forgetting to run make clean afterwards. Here's how I can reproduce the behavior you're seeing: : # pwd : /usr/src/sys/modules/sound/driver/als4000 : # make -s cleandir : # make -s cleandir : # make @ : @ - /usr/src/sys : # make obj : /usr/obj/usr/src/sys/modules/sound/driver/als4000 created for /usr/src/sys/modules/sound/driver/als4000 : # make device_if.h : awk -f @/tools/makeobjops.awk @/kern/device_if.m -h : awk: can't open file @/tools/makeobjops.awk : source line number 1 source file @/tools/makeobjops.awk : context is : : *** Error code 2 : : Stop in /usr/src/sys/modules/sound/driver/als4000. Fix: cd /usr/src/sys/modules make cleandir make cleandir Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplaXWKCvVJL.pgp Description: PGP signature
Re: cap_mkdb: illegal option -i. upgrade 5.4-6.1
On Tue, Sep 12, 2006 at 04:52:32PM +0200, [EMAIL PROTECTED] wrote:
Hi list
I'm upgrading 5.4 p18 to 6.1 p6.
here's my tag: RELENG_6_1
I did:
make update
make cleanworld
make buildworld
which gives following issue:
cap_mkdb: illegal option -i
It seems a known problem on netbsd during buildworld compilation. here's
the solution I'm tring:
cd /usr/src/usr.bin/cap_mkdb
make clean
make
make install
and I'm building world again.
is that a known problem on freebsd?
This shouldn't happen. The buildworld target detects the current
version of your system, and bootstraps cap_mkdb if necessary:
: .if ${BOOTSTRAPPING} 600015
: _cap_mkdb= usr.bin/cap_mkdb
: .endif
BOOTSTRAPPING is defined as follows:
: .if !defined(OSRELDATE)
: .if exists(/usr/include/osreldate.h)
: OSRELDATE!= awk '/^\#define[[:space:]]*__FreeBSD_version/ { print $$3 }' \
: /usr/include/osreldate.h
: .else
: OSRELDATE= 0
: .endif
That is, it's the value of __FreeBSD_version as defined in
/usr/include/osreldate.h. If your /usr/include/osreldate.h
is lying about the current version, e.g. if you accidentally
installed the new headers, then you can force it to zero,
such as:
make buildworld OSRELDATE=0
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpxaixm4fu4M.pgp
Description: PGP signature
Re: sound card
On Fri, Sep 01, 2006 at 09:54:23PM +0600, S. M. Ibrahim (Lavlu) wrote: On Fri, 2006-09-01 at 21:02 +0530, Joseph Koshy wrote: I installed it yesterday. Everything goes ok, but problem with sound card, It's a builtin Intl HDA on gigabyte 915G-DU motherboard. I added the line sound_load=YES snd_driver_load=YES snd_cmi_load=YES to /boot/loader.conf but sound is not working. Things to check: - Does loading the driver module using kldload work: # kldload snd_driver.ko already loaded - What are the last few lines from `dmesg` after this step. no changes - Do you have a /dev/sndstat? If so what does # cat /dev/sndstat [EMAIL PROTECTED] ~]$ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: [EMAIL PROTECTED] ~]$ reveal? in my debian, it's my card work ok with snd_hda_intl mod :( Try the OSS drivers from http://www.opensound.com/. Mine is detected but doesn't work, while you may be more lucky. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpc5hljJ88Q0.pgp Description: PGP signature
Re: 5.5 to 6.1 upgrade
On Wed, Aug 23, 2006 at 01:51:52PM -0700, Doug Barton wrote: Ruslan Ermilov wrote: On Tue, Aug 22, 2006 at 11:07:45PM +0300, Todorov @ Paladin wrote: Also - why portupgrade is not always aware of previously chosen options for a port build? It depends. If options are OPTIONS (in the ports sense), they are saved and independent of portupgrade. If options are makefile options specified in pkgtools.conf, they are only taken into accont if the port is (re)build explicitly; they are not taken into account if a port is (re)built as a dependency of another port. In plain text: if port B has options in pkgtools.conf, and port A has B as its dependency, and you portinstall/portupgrade A, B will be built (if needs be) without pkgtools.conf options. Be careful. sysutils/portconf does not have that limitation. If you specify flags using that method, they will always be used. True. The implementation is also smart -- it doesn't spam make(1) environment when not necessary. Thanks! Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp0L5O42e3js.pgp Description: PGP signature
Re: source tree borked for 6.1-stable ?
On Thu, Aug 24, 2006 at 03:17:51PM -0400, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kris Kennaway wrote: On Thu, Aug 24, 2006 at 02:12:53PM +0400, Nikolay Kalev wrote: /usr/src/sys/netinet/ip_fw2.c:37:23: opt_ip6fw.h: No such file or directory /usr/src/sys/netinet6/ip6_forward.c:33:23: opt_ip6fw.h: No such file or directory [ .. ] Perhaps someone accidentally updated their source to current? Nope .. a 'cd /usr/src; make kernel' prompts this behaviour on today's - -stable sources :-( This has been fixed for several hours now, please re-cvsup. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgppfGonw8Uts.pgp Description: PGP signature
Re: _malloc_prefork not found
On Wed, Aug 23, 2006 at 07:17:40AM -0400, Daniel Eischen wrote: Your system is not consistent. There is no _malloc_prefork() (or _malloc_foofork()) in -stable; it only exists in -current. You've got -current libraries (at least libpthread) on -stable. libpthread is installed in /usr/lib in RELENG_6, not /lib. So if you've downgraded from -current, you'll need to remove the -current libraries that have different locations in RELENG_6 (no, I don't think there is an automated way to do this). We don't provide any convenience scripts for downgrades. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpJfkLjXCoi6.pgp Description: PGP signature
Re: 5.5 to 6.1 upgrade
On Tue, Aug 22, 2006 at 11:07:45PM +0300, Todorov @ Paladin wrote: Also - why portupgrade is not always aware of previously chosen options for a port build? It depends. If options are OPTIONS (in the ports sense), they are saved and independent of portupgrade. If options are makefile options specified in pkgtools.conf, they are only taken into accont if the port is (re)build explicitly; they are not taken into account if a port is (re)built as a dependency of another port. In plain text: if port B has options in pkgtools.conf, and port A has B as its dependency, and you portinstall/portupgrade A, B will be built (if needs be) without pkgtools.conf options. Be careful. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpoxLj6jY7P6.pgp Description: PGP signature
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
On Mon, Aug 21, 2006 at 03:23:37PM -0400, David Gilbert wrote: Could someone please MFC at least v 1.168 of ata-chipset.c into RELENG_6? Specifically the Nvidia NFORCE-4 support? Most of the AMD64 motherboards I've gotten lately require this patch. I have been able to apply diff between 1.165 and 1.168 to RELENG-6 and it makes the chipset work. (this also requires 1.65 to 1.68 of ata-pci.h). Any takers? I'll do it in a few days if Soren doesn't do it earlier -- I also have plenty of such motherboards which want to meet 6.x. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpDteDSzmLZB.pgp Description: PGP signature
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
Hi Soren, On Tue, Aug 22, 2006 at 10:56:19AM +0200, S?ren Schmidt wrote: I plan to bacport *all* of ATA, as there are so many bugfixes that a resync is needed. ATA from -current fits right into 6-stable so its a nobrainer it just need a little more exposure... Do you have any ETA? Yes, I'm currently running HEAD version of sys/dev/ata/ on these motherboards. Thanks! Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpEhZyMYNSLZ.pgp Description: PGP signature
Re: FreeBSD boots too fast on Dell PE850
On Fri, Aug 18, 2006 at 06:22:56PM +0900, Pyun YongHyeon wrote: On Fri, Aug 18, 2006 at 10:51:07AM +0200, Martin Horcicka wrote: 2006/8/18, Dan Nelson [EMAIL PROTECTED]: In the last episode (Aug 17), Alan Amesbury said: OK, booting *too* quickly is a somewhat unusual problem. I have FreeBSD 6.1-RELEASE-p3 running on a Dell PowerEdge 850. For some reason, in the PowerEdge 850 Dell chose to replace the perfectly adequate em(4) adapters found on the PE750 with bge(4) hardware. [...] It's a little hack but it works as expected. Anyway, in some cases it does not help. The NIC is probably reset at some later point. I have not investigated it further yet. Another thing to check is whether you have alias IPs. I believe the bge driver has to reset the card every time you add or remove an IP. I know the ti driver (whose chipset the broadcom chips are based on) had that problem. Yes, but I believe that all such operations are done by the netif script. I think it's job of device driver. If the driver find its link negotiation is in progress it should not send frames. Unfortunately not all drivers handle this correctly. But the bge's start() routine does this, and did it in 6.1-RELEASE, so it doesn't look like a problem in this particular case. : if (!sc-bge_link || IFQ_DRV_IS_EMPTY(ifp-if_snd)) : return; Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpxP9mBvWi35.pgp Description: PGP signature
Re: installword with DESTDIR=/nfs doesn't work?
On Mon, Aug 14, 2006 at 07:02:09PM +0200, Oliver Fromme wrote: Hi, I just tried to do a make installworld with DESTDIR set to a directory on an NFS server. It broke like this: === lib/libcom_err/doc (install) lockf -k /mnt/data/6.1-TEST/original-tree/usr/share/info/dir install-info --quiet --defsection=Programming development tools. --defentry=* libcom_err: (com_err).A Common Error Description Library for UNIX. com_err.info /mnt/data/6.1-TEST/original-tree/usr/share/info/dir lockf: cannot open /mnt/data/6.1-TEST/original-tree/usr/share/info/dir: Operation not supported *** Error code 73 Stop in /usr/src/lib/libcom_err/doc. *** Error code 1 Am I missing something? Is installworld over NFS supported at all? I could swear I have done it before ... Yes. From build(7): : installworld Install everything built by a preceding buildworld step : into the directory hierarchy pointed to by make(1) vari- : able DESTDIR. : : If installing onto an NFS file system, make sure that : rpc.lockd(8) is running on both client and server. See : rc.conf(5) on how to make it start at boot time. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp4jR0esnFvq.pgp Description: PGP signature
Re: nfpm
On Sun, Aug 13, 2006 at 04:30:31PM +0200, Zoran Kolic wrote: Hi all! I would like to add nfpm device into kernel, but cannot find it in source. Googling for awile, I've found a lot of posts on nfsmb, broken compilings... In this moment looks to me that the correct way should be to add smbus, smb and nfpm. Since nfsmb is taken from sensors, do I compile zombie device. Mobo is asus nforce3 k8n 250, 6.1 and amd64. [EMAIL PROTECTED]:1:1:class=0x0c0500 card=0x813f1043 chip=0x00e410de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce PCI SMB Controller' class= serial bus subclass = SMBus You motherboard is nForce3 based so you don't need nfpm. nfpm is just an alias for amdpm, so this is probably why you can't find its sources: # grep nfpm sys/conf/files pci/amdpm.c optional amdpm pci | nfpm pci # amdpm AMD 756 Power Management Unit # amdsmbAMD 8111 SMBus 2.0 Controller # nfpm NVIDIA nForce Power Management Unit # nfsmb NVIDIA nForce2/3/4 MCP SMBus 2.0 Controller I've written amdsmb for Asus SK8N, only to find out that there are no sensors attached to it. :-) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgp4xuOGLYJxm.pgp Description: PGP signature
Re: amd64 cannot boot on ASUS M2N-E
On Thu, Aug 10, 2006 at 12:55:15PM +0200, Angelo Turetta wrote: The motherboard (BIOS rev.0203) is based on the nVidia MCP55 chipset, AMD64 3500+ (2200 MHz), 1 GB DDR553, two SATA2 Maxtor 80GB, DVD-R Samsung. Trying to boot the latest snapshot 6.1-STABLE-200608-amd64, the kernel probes most peripherals (the Marvel gigabit-ethernet is not detected, but that's a known item), but just after reporting acd0 it hangs solid with the IDE led on. No panic, nor errors. It seems related to the detection of the disks (they are not reported). I even left it in that state the whole night (just in case it was some lng timeout), but nothing. The -i386 image exhibits the same exact behaviour. Booting without ACPI does not solve. 7.0-CURRENT-200608-amd64 boots fine (no Marvel gbit, of course). What should I try next? You need ata-chipset.c from -CURRENT, or wait for fix to be merged. : revision 1.166 : date: 2006/07/24 10:44:50; author: sos; state: Exp; lines: +47 -34 : Finally fix support for the newer MCP51/MCP55 nVidia chipsets. : The register layout has changed since the original NV4 - sigh. : Hotplug support has been fixed for all nVidia chipsets that supports it : (including the MCP51/55). : : HW donated by: Kingsley College Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpp881CeZWBP.pgp Description: PGP signature
Re: Problem in src/lib/libpam/modules/pam_ssh/Makefile
On Fri, Jul 14, 2006 at 09:27:15AM -0700, David Wolfskill wrote:
[-current removed from recipient list, since rev. 1.20.2.1 of the file
in question is on the RELENG_6 branch, which is not CURRENT. -- dhw]
On Fri, Jul 14, 2006 at 03:27:14PM +0200, Nenad Gavrilovic wrote:
...
Looking in other Makefiles I think that correction:
CFLAGS+= -I${SSHSRC} -include ssh_namespace.
to:
CFLAGS+= -I${SSHDIR} -include ssh_namespace.
That change allowed my buildworld to complete; my laptop is now running
the newly-built -installed system:
I've just committed a more complete fix for this.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgp19j0HmMmhs.pgp
Description: PGP signature
Re: em device hangs on ifconfig alias ...
On Sat, Jul 08, 2006 at 12:32:55PM +0900, Pyun YongHyeon wrote:
On Fri, Jul 07, 2006 at 10:38:01PM +0100, Robert Watson wrote:
On Fri, 7 Jul 2006, User Freebsd wrote:
I think that I have patched, built and loaded the em(4) kernel module
correctly. After applying the patch there were no rejects, before
building the module I intentionally appended (patched) to its version
string in if_em.c, and could see that in dmesg every time I loaded the
module: em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18
(patched)
Is it possible that we're going at this issue backwards? It isn't the
lack of ARP packet going out that is causing the problems with moving
IPs,
but that delay that we're seeing when aliasing a new IP on the stack?
The
ARP packet *is* being attempted, but is timing out before the re-init is
completing?
Yes -- basically, there are two problems:
(1) A little problem, in which an arp announcement is sent before the link
has
settled after reset.
(2) A big problem, in which the interface is gratuitously recent requiring
long settling times.
I'd really like to see a fix to the second of these problems (not
resetting
when an IP is added or removed, resulting in link renegotiation); the
first
one I'm less concerned about, although it would make some amount of sense
to do an arp announcement when the link goes up.
Ah, I see. Thanks for the insight.
How about the attached patch?
I've been working on this problem for Mike Tancsa about a year ago,
and my fix was naive. I ended up not committing it because I found
that it broke something else, but I don't remember what exactly now.
Ahh, I seem to remember now -- setting a different MAC address was
not programmed into a hardware with my patch applied.
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
---BeginMessage---
On Thu, Mar 31, 2005 at 10:20:25AM +0300, Ruslan Ermilov wrote:
On Thu, Mar 31, 2005 at 10:01:52AM +0300, Ruslan Ermilov wrote:
Hi Mike,
On Wed, Mar 30, 2005 at 08:03:21PM -0500, Mike Tancsa wrote:
[...]
If you could somehow fix the problem with em bouncing its interface
when you add or remove an alias from it (RELENG_5), I would gladly
send you two nics! ;-)
eg ifconfig em0 192.168.13.9 netmask 255.255.255.252 alias
will down and up the interface. If the switch port it is in has STP,
the port will go into blocking for 30 seconds, which is really
troublesome :(
Is this also a problem in HEAD, or only in RELENG_5?
OK, I can easily reproduce the problem here, hold on.
I'm not fully sure this is a right fix, but it works for me.
Here's what happens: on SIOCSIFADDR, em_ioctl() is called,
then ether_ioctl() which calls em_init() which calls
em_hardware_init() (for some odd reason I don't understand).
em_hardware_init() is correctly called on attach, so I
don't understand why it's also needed in em_init().
Anyway, the hack is as easy as this:
%%%
Index: if_em.c
===
RCS file: /home/ncvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.62
diff -u -p -r1.62 if_em.c
--- if_em.c 5 Mar 2005 18:30:10 - 1.62
+++ if_em.c 31 Mar 2005 07:41:47 -
@@ -832,12 +832,14 @@ em_init_locked(struct adapter * adapter)
bcopy(adapter-interface_data.ac_enaddr, adapter-hw.mac_addr,
ETHER_ADDR_LEN);
+#if 0
/* Initialize the hardware */
if (em_hardware_init(adapter)) {
printf(em%d: Unable to initialize the hardware\n,
adapter-unit);
return;
}
+#endif
if (ifp-if_capenable IFCAP_VLAN_HWTAGGING)
em_enable_vlans(adapter);
%%%
Cheers,
--
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer
pgpsRxXyUafG6.pgp
Description: PGP signature
---End Message---
pgpFvy5lSGyI8.pgp
Description: PGP signature
Re: Upgrading to 6.1-RELEASE problems with make buildkernel
On Tue, May 16, 2006 at 05:15:04PM +0300, Yousef Raffah wrote: Hi, I'm trying to upgrade from 6.1-RC to 6.1-RELEASE my cvssup file is: *default host=cvsup3.de.FreeBSD.org *default base=/var/db *default prefix=/usr/ *default tag=RELENG_6_1_0_RELEASE *default release=cvs delete use-rel-suffix compress src-all [...] # cd /usr/src # make buildkernel Unfortunately, it keeps on failing with the following: MAKE=/usr/obj/usr/src/make.i386/make sh /usr/src/sys/conf/newvers.sh GENERIC cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror vers.c linking kernel.debug textdata bss dec hex filename 5951318 622880 323724 6897922 694102 kernel.debug objcopy --strip-debug kernel.debug kernel cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/GENERIC/modules KMODDIR=/boot/kernel DEBUG_FLAGS=-g MACHINE=i386 KERNBUILDDIR=/usr/obj/usr/src/sys/GENERIC /usr/obj/usr/src/make.i386/make all === 3dfx (all) cc -O2 -fno-strict-aliasing -pipe -march=pentium3 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/3dfx/../../dev/tdfx/tdfx_pci.c ld -d -warn-common -r -d -o 3dfx.kld tdfx_pci.o touch export_syms awk -f /usr/src/sys/modules/3dfx/../../conf/kmod_syms.awk 3dfx.kld export_syms | xargs -J% objcopy % 3dfx.kld *** Error code 1 Stop in /usr/src/sys/modules/3dfx. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Any suggestions? :'( The above output doesn't have any provisions as to what the actual error was, so it's really hard to help you. Please try to catch the actual error message. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpLYDnCLkalo.pgp Description: PGP signature
Re: libnetgraph doesn't build fine on RELENG_6
On Tue, May 02, 2006 at 10:52:23AM -0300, Renato Botelho wrote: I've updated my src today using RELENG_6, when i'm running a buildworld, i got this problem on libnetgraph === lib/libnetgraph (depend,all,install) rm -f .depend CC='/usr/local/libexec/ccache/cc' mkdep -f .depend -a /usr/src/lib/libnetgraph/sock.c /usr/src/lib/libnetgraph/msg.c /usr/src/lib/libnetgraph/debug.c /usr/local/libexec/ccache/cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/lib/libnetgraph/sock.c /usr/local/libexec/ccache/cc -O2 -fno-strict-aliasing -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/lib/libnetgraph/msg.c /usr/src/lib/libnetgraph/msg.c: In function `NgDeliverMsg': /usr/src/lib/libnetgraph/msg.c:236: error: `NGM_HASREPLY' undeclared (first use in this function) /usr/src/lib/libnetgraph/msg.c:236: error: (Each undeclared identifier is reported only once /usr/src/lib/libnetgraph/msg.c:236: error: for each function it appears in.) *** Error code 1 I ran a cd /usr/src/includes make depend all install and problem was fixed, is this the correct way? If yes, it's supposed to be documented on UPDATING, isn't it? You used ccache, so you're supposed to fix problems like this on our own. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpFuQC1YiSQf.pgp Description: PGP signature
Re: Build kernel fails after cvsup tag=RELENG_6_1
On Thu, Apr 13, 2006 at 03:56:11PM +0200, J Hendriks wrote: Hello i did a cvsup as of now and did a useual buildworld cycles on three of my testing machines 2 p4 and 1 p3 The all exited at the buildkernel part with the following error. cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/bce/if_bce.c /usr/src/sys/dev/bce/if_bce.c: In function `bce_rx_intr': /usr/src/sys/dev/bce/if_bce.c:4093: error: structure has no member named `rxcycles' /usr/src/sys/dev/bce/if_bce.c: In function `bce_ioctl': /usr/src/sys/dev/bce/if_bce.c:4897: error: label `bce_ioctl_exit' used but not defined *** Error code 1 Stop in /usr/obj/usr/src/sys/KRNL. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. No special things in make.conf except CPUTYPE?=p4 an p3 for the p3 machine the routine i use is cd /usr/src make cleanworld make cleandir make cleandir make -j2 buildworld make buildkernel KERNCONF=configfile First i thought it was the kernel config file so kopied GENERIC to KRNL and remove the 486 and 586 option and that is it but they still fail. Your kernel has DEVICE_POLLING option which was broken in the driver. I've committed a fix to HEAD, you can pull it up from here or wait for it to be MFCed. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpcXh599qMHB.pgp Description: PGP signature
Re: GEOM_RAID3: Device datos is broken, too few valid components
On Mon, Apr 10, 2006 at 03:32:58PM +0200, Jos? M. Fandi?o wrote: I have follow this procedure and it worked for me: select 6. Escape to loader prompt OK unload OK disable-module geom_raid3 OK boot -s # fsck -p # mount -a # graid3 dump ad4s2 | grep -w no # graid3 dump ad5s2 | grep -w no # graid3 dump ad6s2 | grep -w no (this will give you the right order to use with the next command) # graid3 label -h ad5s2 ad6s2 ad4s2 # graid3 load # graid3 remove -n 0 datos # graid3 insert -n 0 datos ad5s2 now, all is working as expected. However I'm curious about the missing flag HARDCODED for ad5s2. This is because your insert command above didn't include the -h option. The remove/insert could be replaced by graid3 rebuild datos ad5s2. is it reasonable to ignore this missing flag? You can graid3 configure -h it. # grai3 list Geom name: datos State: COMPLETE Components: 3 Flags: ROUND-ROBIN GenID: 0 SyncID: 1 ID: 1391160618 Providers: 1. Name: raid3/datos Mediasize: 311491352576 (290G) Sectorsize: 1024 Mode: r1w1e1 Consumers: 1. Name: ad4s2 Mediasize: 155745676800 (145G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY, HARDCODED GenID: 0 SyncID: 1 Number: 2 Type: PARITY 2. Name: ad5s2 Mediasize: 155745676800 (145G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY GenID: 0 SyncID: 1 Number: 0 Type: DATA 3. Name: ad6s2 Mediasize: 155745676800 (145G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Flags: DIRTY, HARDCODED GenID: 0 SyncID: 1 Number: 1 Type: DATA Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpUNhHKYOyRS.pgp Description: PGP signature
Re: buildworld error (texinfo)
On Fri, Mar 31, 2006 at 04:25:19PM -0800, Kent Stewart wrote: On Friday 31 March 2006 15:28, Fernan Aguero wrote: Hi! I've just cvsuped to the latest RELENG_6_0 (p6) and I can't get buildworld to finish ... this is the second time I got stopped at the same place: === gnu/usr.bin/texinfo/doc (all) makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info .texi -o info.info makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info -stnd.texi -o info-stnd.info ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texi nfo.txi texinfo.texi makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info gzip -cn info.info info.info.gz gzip -cn info-stnd.info info-stnd.info.gz gzip -cn texinfo.info texinfo.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error This looks like you were running with a -j? set and you aren't seeing the real error. It was hidden somewhere. Should anyone encounter reproducible -jX build breakages, I'm interested in tracking them down and fixing. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgplgT9M4k3H7.pgp Description: PGP signature
Re: SETFEATURES SET TRANSFER MODE semaphore timeout on FreeBSD 6.0 RELEASE
On Fri, Mar 17, 2006 at 02:13:59PM +0200, Peter van Heusden wrote: Hi I have a newly installed FreeBSD 6.0 release machine on which I am getting the following error on the console: ad4: req=0xc23bc258 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! Update to the latest RELENG_6. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpPawLgB85iv.pgp Description: PGP signature
Re: swap at beginning of slice - danger?
On Wed, Mar 15, 2006 at 02:48:31PM +0100, Oliver Fromme wrote: Vadim Goncharov [EMAIL PROTECTED] wrote: I have 5.5-PRERELEASE server in production, booting from ad0s1: # BLOCKSIZE=512 swapinfo Device 512-blocks UsedAvail Capacity /dev/ad0s1b209715252872 2044280 3% /dev/ad1s1b209715251952 2045200 2% Total 4194304 104824 4089480 2% # bsdlabel ad0s1 | fgrep b: b: 20971520 swap Previously, on a 4.11 system, swapinfo said that swap size was less than size of b: partition on a slice - it was ok, as boot sectors are located at beginning of slice. But now, sizes match exactly. What changed and is it dangerous nowadays to have swap partition at offset 0 ? The code in sys/swap_pager.c does not touch the first two blocks, where blocks are measured in PAGE_SIZE units. The smallest page size supported on FreeBSD architectures is 4 KB (on i386), so that's at least 2 * 4k, which is 16 sectors on the disk. That's enough to skip MBR, disklabel and boot blocks. In other words: You're save. No danger. No need to worry. Also, geom_bsd.c doesn't allow writing to the label sector: : # bsdlabel md0 : # /dev/md0: : 8 partitions: : #size offsetfstype [fsize bsize bps/cpg] : a: 20480unused0 0 : c: 20480unused0 0 # raw part, don't edit : # dd if=/dev/zero of=/dev/md0a count=1 seek=1 : dd: /dev/md0a: Operation not permitted : 1+0 records in : 0+0 records out : 0 bytes transferred in 0.000153 secs (0 bytes/sec) Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpp0HrhHipw1.pgp Description: PGP signature
Re: Kernel INCLUDE_CONFIG_FILE workaround?
On Mon, Mar 13, 2006 at 09:32:24AM -0600, Alan Amesbury wrote: Jorge Aldana wrote: I'm on 6.1PreRelease and this works: strings -n 3 /boot/kernel/kernel | grep -v | sed -n 's/^___//p' There was a minor tweek in this line back in 5.X transition form 4.X but my script works fine for 6.X since then. Note that the problem isn't in the line you provided above that extracts the built-in configuration file. It's in the build procedure that's supposed to put the config file into the kernel in the first place. In other words, options INCLUDE_CONFIG_FILE doesn't include *all* the configuration data, because it doesn't include included configuration files. It's only including the very first level of nested configuration files, which is not an accurate representation of what's in the kernel. In my example, the configuration file for GENERIC should've been in there somewhere, as well as anything included by GENERIC (such as the stuff in DEFAULTS). Again, this used to work great, but appears to have been broken in favor of... usability? I posted a patch to config(8) some time ago that did what you want, but it wasn't widely accepted so I abandoned it. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpJAB7lRLsgr.pgp Description: PGP signature
Re: loader_color=YES
On Thu, Mar 09, 2006 at 09:14:26PM +0100, martinko wrote: Holger Kipp wrote: On Tue, Feb 28, 2006 at 04:55:49AM -0600, Nikolas Britton wrote: What happen to 'loader_color=YES' if FreeBSD 6.x? If you put this in loader.conf it would make a color daemon in the boot menu. Please use loader_logo=beastie loader_color=YES you don't need loader_color for beastie in colour afair. loader_color is deprecated. One should use loader_logo as described in loader.conf(5) instead. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpeog4YXMtKA.pgp Description: PGP signature
Re: loader_color=YES
On Tue, Feb 28, 2006 at 05:56:57PM -0600, Nikolas Britton wrote: On 2/28/06, Pete Slagle [EMAIL PROTECTED] wrote: Holger Kipp wrote: Please use loader_logo=beastie loader_color=YES loader_logo does not appear in /boot/defaults/loader.conf, at least not in 6.0-RELEASE-p4. Is that an oversight? Their are lots of undocumented feature in FreeBSD. loader_color=YES AFAIK It was never document in 5.x, I found it by accident You're right about RELENG_5, but: : RCS file: /home/ncvs/src/sys/boot/forth/loader.conf.5,v : Working file: loader.conf.5 : head: 1.26 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 44;selected revisions: 2 : description: : : revision 1.25 : date: 2005/11/15 21:26:49; author: ru; state: Exp; lines: +11 -4 : Catch up with loader_color - loader_logo and document beastie_disable. : : revision 1.23 : date: 2004/11/07 17:01:08; author: krion; state: Exp; lines: +6 -1 : branches: 1.23.2; : Document loader_color variable. : : PR: conf/73396 : Submitted by: Aleksander Fafula alex at fafula dot com : Approved by:scottl All of this is in RELENG_6, too. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpjoY8ZVf6kV.pgp Description: PGP signature
