misc/144278: Fixit from USB dont work
>Number: 144278 >Category: misc >Synopsis: Fixit from USB dont work >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Feb 25 08:20:03 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Joe Barbish >Release:8.0 release >Organization: none >Environment: >Description: PC hard drive has FreeBSD installed previous from CD (IE disc1.iso) burned to CD. Have installed Freebsd to USB stick from CD as full running system. Not loaded with fixit image. Booting from install CD with USB stick plugged in, see USB stick light flashing while Freebsd is loading from CD. Select fixit from sysinstall main menu and then selecting USB file system option #3. Sysinstall replies with window saying no USB device. Return to sysinstall main menu select option/re-scan. Highlight re-scan and hit space bar. Screen flickers once. Return to fixit/option #3 same results. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/144280: [boot] boot0cfg not USB aware
Old Synopsis: boot0cfg not USB aware New Synopsis: [boot] boot0cfg not USB aware Responsible-Changed-From-To: freebsd-usb->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Thu Feb 25 12:16:08 UTC 2010 Responsible-Changed-Why: hps notes that this is boot-code-related, not USB per se. http://www.freebsd.org/cgi/query-pr.cgi?pr=144280 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/144285: ps -axo user, %cpu, %mem - most processes using 0% of memory
>Number: 144285
>Category: misc
>Synopsis: ps -axo user,%cpu,%mem - most processes using 0% of memory
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 25 14:50:00 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Alex Keda
>Release:7.2-STABLE
>Organization:
USSR
>Environment:
FreeBSD srv2.host-food.ru 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Oct 4 01:38:34
MSD 2009 lissy...@srv.host-food.ru:/home/obj/usr/src/sys/HOST-FOOD i386
>Description:
Modern computers have a large amount of memory.
But, in ps(1) source I see:
(void)printf("%*.1f", v->width, getpcpu(k));
(void)printf("%*.1f", v->width, getpmem(k));
0.1% - it very big.
for 8Gb ram it = 8mb
Many of the processes is less than this number.
>How-To-Repeat:
ps -axo user,%cpu,%mem
>Fix:
see patch
Patch attached with submission follows:
--- /usr/src/bin/ps/print.c.orig2010-01-22 23:09:53.0 +0300
+++ /usr/src/bin/ps/print.c 2010-01-22 23:10:06.0 +0300
@@ -645,7 +645,7 @@
VAR *v;
v = ve->var;
- (void)printf("%*.1f", v->width, getpcpu(k));
+ (void)printf("%*.2f", v->width, getpcpu(k));
}
static double
@@ -673,7 +673,7 @@
VAR *v;
v = ve->var;
- (void)printf("%*.1f", v->width, getpmem(k));
+ (void)printf("%*.2f", v->width, getpmem(k));
}
void
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/144289: [patch] Update www/tomcat-native to 1.1.20
>Number: 144289
>Category: misc
>Synopsis: [patch] Update www/tomcat-native to 1.1.20
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 25 18:10:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Mike Jakubik
>Release:8.0-STABLE
>Organization:
>Environment:
>Description:
This patch updates tomcat-native to the latest version, no major changes.
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
diff -urN tomcat-native.orig/Makefile tomcat-native/Makefile
--- tomcat-native.orig/Makefile 2010-02-24 15:07:01.0 -0500
+++ tomcat-native/Makefile 2010-02-24 15:11:07.0 -0500
@@ -6,7 +6,7 @@
#
PORTNAME= tomcat-native
-PORTVERSION= 1.1.18
+PORTVERSION= 1.1.20
CATEGORIES=www java
MASTER_SITES= ${MASTER_SITE_APACHE}
MASTER_SITE_SUBDIR=tomcat/tomcat-connectors/native/${PORTVERSION}/source
diff -urN tomcat-native.orig/distinfo tomcat-native/distinfo
--- tomcat-native.orig/distinfo 2010-02-24 15:07:01.0 -0500
+++ tomcat-native/distinfo 2010-02-24 15:11:13.0 -0500
@@ -1,3 +1,3 @@
-MD5 (tomcat-native-1.1.18-src.tar.gz) = 03701be390f81198ca4531ab4b0a8f35
-SHA256 (tomcat-native-1.1.18-src.tar.gz) =
80b61b847b266b75fb5d59143f4505468c998a36d5ef3449d108acfe2607253e
-SIZE (tomcat-native-1.1.18-src.tar.gz) = 241951
+MD5 (tomcat-native-1.1.20-src.tar.gz) = fb2b9d073cb6575c2d0020eda266ca0c
+SHA256 (tomcat-native-1.1.20-src.tar.gz) =
847ea04b5e66f56c8db94c8675f6e9e70b8d04f8aa2dc646a4050f8cf4d0d47e
+SIZE (tomcat-native-1.1.20-src.tar.gz) = 241274
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports /144289: [patch] Update www/tomcat-native to 1.1.20
Synopsis: [patch] Update www/tomcat-native to 1.1.20 Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: brucec Responsible-Changed-When: Thu Feb 25 18:16:04 UTC 2010 Responsible-Changed-Why: Ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=144289 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/144300: mdconfig -{d,l}n doesn't work
>Number: 144300
>Category: bin
>Synopsis: mdconfig -{d,l}n doesn't work
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 25 21:10:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:8-RELEASE / 9-CURRENT
>Organization:
Cisco Systems, Inc
>Environment:
>Description:
The mdconfig(1) implies that -n will squelch `md' prefixing with any mdconfig
output...
-n When printing md device names, print only the unit number without
the md prefix.
.. but that isn't the case:
# mdconfig -ln
md1
# uname -a
FreeBSD left4dead.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Feb 18
12:19:04 PST 2010 r...@left4dead.cisco.com:/usr/obj/usr/src/sys/LEFT4DEAD
i386
1. The -n value only appears to be in use with the -a option (which doesn't
make a lot of sense to me, but I dunno...).
2. There appears to be a problem with the default n_flag setting (it is set to
random stack data unless specified on the command line), but even after fixing
that, md is still output -- I didn't really want to waste cycles chasing down
the culprit right now.
This issue is present in the RELENG_8 copy of FreeBSD as well.
>How-To-Repeat:
dd if=/dev/zero conv=sparse of=foo
mdconfig -a -t vnode -u 1 -f foo
mdconfig -l -n
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/144301: HP proliant server locks when using ciss0 drive da1 but runs fine on da0
>Number: 144301 >Category: kern >Synopsis: HP proliant server locks when using ciss0 drive da1 but runs >fine on da0 >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Feb 25 21:40:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Sheldon Jones >Release:FreeBSD 8.0-STABLE amd64 and i386 >Organization: Lobo Internet Services, Ltd. >Environment: FreeBSD wls 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Feb 23 23:17:35 MST 2010 shel...@wls:/usr/obj/usr/src/sys/GENERIC i386 >Description: Server lock when using drive da1 or da2 MB and Firmwares are all latest from HP. I'm able to reproduce this problem on a HP Proliant DL360 G5 quad amd64 8G ram using a ciss0: card. The problem is also on 3 different Proliant DL380 G3 i386 machines 4G ram using ciss0: cards. The drive configurations don't seam to affect the issue. The G5 has 3 drive in JBOD configuration and the G3's have 2 raid0+1 sets. >How-To-Repeat: setup drive da1 or da2 # newfs -U /dev/da1s1d # mount /dev/da1s1d /mnt now copy some data.. # cp -rpv /usr/src /mnt the box will hang and a reset is needed to reboot it. >Fix: Use an older kernel or 8.0-RELEASE-p2. I notice a change to the ciss.c driver in Feb, 2010. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/144301: [ciss] [hang] HP proliant server locks when using ciss0 drive da1 but runs fine on da0 [regression]
Old Synopsis: HP proliant server locks when using ciss0 drive da1 but runs fine on da0 New Synopsis: [ciss] [hang] HP proliant server locks when using ciss0 drive da1 but runs fine on da0 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-scsi Responsible-Changed-By: linimon Responsible-Changed-When: Thu Feb 25 23:48:01 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144301 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/144306: Nasty bug in jn(3)
>Number: 144306
>Category: bin
>Synopsis: Nasty bug in jn(3)
>Confidential: no
>Severity: serious
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 26 00:20:04 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Steven G. Kargl
>Release:FreeBSD 9.0-CURRENT amd64
>Organization:
APL/UW
>Environment:
System: FreeBSD troutmask.apl.washington.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #0
r204219M: Mon Feb 22 12:41:49 PST 2010
ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW amd64
>Description:
troutmask:kargl[466] cat testjn.c
#include
#include
int
main(void)
{
double z;
int n;
z = 2.4048255576957729;
for (n = 2; n < 10; n++)
printf("%d %e\n", n, jn(n,z));
return (0);
}
troutmask:kargl[467] cc -o z testjn.c -lm
troutmask:kargl[468] ./z
2 4.317548e-01
3 -inf
4 4.069027e-02
5 -inf
6 3.247664e-03
7 -inf
8 7.495602e-05
9 -inf
The value of a integer order Bessel function with
argument z = 2.4048255576957729 is never -inf.
>How-To-Repeat:
See above
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/144307: ENOENT set unnecessarily under certain circumstances when malloc is called / fails
>Number: 144307
>Category: misc
>Synopsis: ENOENT set unnecessarily under certain circumstances when
>malloc is called / fails
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 26 01:20:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:RELENG_8
>Organization:
Cisco Systems, Inc
>Environment:
FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #2: Wed Feb 3
16:57:07 PST 2010
garrc...@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386
>Description:
On systems where /etc/malloc.conf isn't present, some failures syscalls like
read will fail incorrectly with ENOENT because the file doesn't exist, and thus
output via errx will be incorrect, like shown from the following disklabel
output:
1+0 records in
1+0 records out
512 bytes transferred in 0.54 secs (9502140 bytes/sec)
disklabel: /dev/md1 read: No such file or directory
This can be reproduced as follows (yes, the dd command are stat commands are
wrong -- I know that...) if malloc.conf is not present:
dd if=/dev/zero of=$output_file conv=sparse bs=$(stat -f '%z'
"$input_directory") count=1
mdconfig -a -t vnode -u ${md_num} -f "$output_file"
disklabel -rw /dev/md${md_num} auto
Once malloc.conf is present...
sudo ln -s M /etc/malloc.conf
# ...
1+0 records in
1+0 records out
512 bytes transferred in 0.54 secs (9460280 bytes/sec)
disklabel: /dev/md1 read: Unknown error: 0
>How-To-Repeat:
dd if=/dev/zero of=foo conv=sparse bs=512 count=1
mdconfig -a -t vnode -u 1 -f foo
disklabel -rw /dev/md1 auto
>Fix:
1. Set malloc.conf to a valid value as per malloc(3).
2. Apply attached patch.
Patch attached with submission follows:
Index: lib/libc/stdlib/malloc.c
===
--- lib/libc/stdlib/malloc.c(revision 204027)
+++ lib/libc/stdlib/malloc.c(working copy)
@@ -5408,6 +5408,11 @@
/* Get runtime configuration. */
switch (i) {
case 0:
+ /*
+* Make sure that a valid errno code doesn't get wiped
+* out if malloc.conf doesn't exist.
+*/
+ int saved_errno = errno;
if ((linklen = readlink("/etc/malloc.conf", buf,
sizeof(buf) - 1)) != -1) {
/*
@@ -5421,6 +5426,7 @@
buf[0] = '\0';
opts = buf;
}
+ errno = saved_errno;
break;
case 1:
if (issetugid() == 0 && (opts =
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144306: Nasty bug in jn(3)
This patch fixes the problem. Index: e_jn.c === --- e_jn.c (revision 204219) +++ e_jn.c (working copy) @@ -200,7 +200,12 @@ } } } - b = (t*__ieee754_j0(x)/b); + z = __ieee754_j0(x); + w = __ieee754_j1(x); + if (fabs(z) >= fabs(w)) + b = (t*z/b); + else + b = (t*w/a); } } if(sgn==1) return -b; else return b; -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144306: Nasty bug in jn(3)
The following reply was made to PR bin/144306; it has been noted by GNATS. From: "Steven G. Kargl" To: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Cc: Subject: Re: bin/144306: Nasty bug in jn(3) Date: Thu, 25 Feb 2010 20:15:33 -0800 (PST) This patch fixes the problem. Index: e_jn.c === --- e_jn.c (revision 204219) +++ e_jn.c (working copy) @@ -200,7 +200,12 @@ } } } - b = (t*__ieee754_j0(x)/b); + z = __ieee754_j0(x); + w = __ieee754_j1(x); + if (fabs(z) >= fabs(w)) + b = (t*z/b); + else + b = (t*w/a); } } if(sgn==1) return -b; else return b; -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/144306: Nasty bug in jn(3)
A better patch: Index: src/e_jnf.c === --- src/e_jnf.c (revision 204219) +++ src/e_jnf.c (working copy) @@ -153,6 +153,12 @@ } } b = (t*__ieee754_j0f(x)/b); + z = __ieee754_j0f(x); + w = __ieee754_j1f(x); + if (fabsf(z) >= fabsf(w)) + b = (t * z) / b; + else + b = (t * w) / a; } } if(sgn==1) return -b; else return b; Index: src/e_jn.c === --- src/e_jn.c (revision 204219) +++ src/e_jn.c (working copy) @@ -200,7 +200,12 @@ } } } - b = (t*__ieee754_j0(x)/b); + z = __ieee754_j0(x); + w = __ieee754_j1(x); + if (fabs(z) >= fabs(w)) + b = t * z / b; + else + b = t * w / a; } } if(sgn==1) return -b; else return b; -- Steve http://troutmask.apl.washington.edu/~kargl/ ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/144311: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to'
>Number: 144311 >Category: kern >Synopsis: massive ICMP storm on lo0 occurs when using pf(4) 'reply-to' >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 26 06:00:09 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Yoshiaki Kasahara >Release:FreeBSD 8.0-STABLE amd64 >Organization: Kyushu University >Environment: System: FreeBSD elvenbow.cc.kyushu-u.ac.jp 8.0-STABLE FreeBSD 8.0-STABLE #1: Fri Feb 19 16:44:40 JST 2010 r...@elf2.nc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/GENERIC amd64 >Description: A massive amount of 'ICMP unreachable - fragmentation needed' observed on lo0 when pf(4) 'reply-to' is used for policy routing, which degrades the overall performance of the system severely. I have a web server with two NIC connected to different outgoing networks. Each network has a spoof filter, so I need to reply back to the I/F where the connection came from. +-+ |em0(IP1.IP1.IP1.IP1) -- ISP1(GW1.GW1.GW1.GW1) | | |em1(IP2.IP2.IP2.IP2) -- ISP2(GW2.GW2.GW2.GW2) +-+ So I use pf(4)'s 'reply-to' rule and noticed the symptom. The simplified pf.conf which show the symptom is as follows (IP addresses are masked): - if_isp1="em0" isp1_router="GW1.GW1.GW1.GW1" if_isp2="em1" isp2_router="GW2.GW2.GW2.GW2" pass in all pass in reply-to ( $if_isp1 $isp1_router ) from any to $if_isp1 pass in reply-to ( $if_isp2 $isp2_router ) from any to $if_isp2 pass out all - Then access the web server on IP1 from a client (SIP.SIP.SIP.SIP) and retrieve a large file such as a picture. While doing so, tcpdump -n -i lo0 shows a massive amount of ICMP packets flowing like this: # tcpdump -n -i lo0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes 12:53:59.784441 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48 12:53:59.784772 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48 12:53:59.785001 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48 12:53:59.785288 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48 12:53:59.785482 IP 127.0.0.1 > IP1.IP1.IP1.IP1: ICMP SIP.SIP.SIP.SIP unreachable - need to frag (mtu 1500), length 48 .(omit) The SIP host can retrieve the file, but the throughput is very poor. netstat(1) also shows an abnormal number of packet counts (irrelevant lines removed). % netstat -ni NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll em01500 00:1c:c0:fa:c4:6a79142 0 080093 0 0 em01500 IP1.IP1.IP1.9 IP1.IP1.IP1.IP1 2090652887 - - 472 - - em11500 00:1b:21:52:52:60 141017 0 059392 0 0 em11500 IP2.IP2.IP2.0 IP2.IP2.IP2.IP2 83355 - -58112 - - lo0 16384 2090617974 0 0 2090617950 0 0 lo0 16384 127.0.0.0/8 127.0.0.135119 - - 2090610857 - - Some hardware combination didn't seem to exhibit the symptom. Actually I recently replaced the server and suddenly the problem started to occur. I examined the old server and noticed that I could also reproduce the symptom on the old server when I changed the default route. Old system runs FreeBSD 8.0R-p1 amd64. FreeBSD elf2.nc.kyushu-u.ac.jp 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #4: Wed Dec 16 15:49:14 JST 2009 r...@elvenbow.cc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/GENERIC amd64 On the old system, msk(4) and vge(4) are used for ISP connections. Default route to msk(4) is okay, but change it toward vge(4) exhibits the problem. Exchanging NIC for ISP1 and ISP2 doesn't matter, so it is more related to hardware (driver?) than network configuration, I guess. >How-To-Repeat: Explained in the Description section. >Fix: Unknown. I don't understand what is the source of these ICMP packets and why they are generated. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/144313: ld cant find libs in /usr/local/lib but ldconfig can
>Number: 144313
>Category: misc
>Synopsis: ld cant find libs in /usr/local/lib but ldconfig can
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Feb 26 07:50:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Oscar Norlander
>Release:FreeBSD 8
>Organization:
>Environment:
FreeBSD freebsd1.localdomain 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #0: Tue Jan
5 21:11:58 UTC 2010
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
>Description:
The problem is that ld can not find libraries in /usr/local/lib even if
ldconfig can. For example:
ldconfig -r | grep event
107:-levent-1.4.3 => /usr/local/lib/libevent-1.4.so.3
108:-levent_core-1.4.3 => /usr/local/lib/libevent_core-1.4.so.3
109:-levent_extra-1.4.3 => /usr/local/lib/libevent_extra-1.4.so.3
The last rows of the next printout is intersesting because they show that
/usr/local/lib is not even searched by ld:
ld --verbose -l event
GNU ld version 2.15 [FreeBSD] 2004-05-23
Supported emulations:
elf_i386_fbsd
elf_x86_64_fbsd
using internal linker script:
==
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
"elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(_start)
SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0x40); . = 0x40 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version: { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.dyn:
{
*(.rel.init)
*(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
*(.rel.fini)
*(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
*(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
*(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
*(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
*(.rel.ctors)
*(.rel.dtors)
*(.rel.got)
*(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
}
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
}
.rel.plt: { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0x90909090
.plt: { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
} =0x90909090
.fini :
{
KEEP (*(.fini))
} =0x90909090
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1: { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN (0x10) - ((0x10 - .) & (0x10 - 1)); . =
DATA_SEGMENT_ALIGN (0x10, 0x1000);
/* Ensure the __preinit_array_start label is properly aligned. We
could instead move the label definition inside the section, but
the linker would then create the section even if it turns out to
be empty, which isn't pretty. */
. = ALIGN(64 / 8);
PROVIDE (__preinit_array_start = .);
.preinit_array : { *(.preinit_array) }
PROVIDE (__preinit_array_end = .);
PROVIDE (__init_array_start = .);
.init_array : { *(.init_array) }
PROVIDE (__init_array_end = .);
PROVIDE (__fini_array_start = .);
.fini_array : { *(.fini_array) }
PROVIDE (__fini_array_end = .);
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
.eh_frame : { KEEP (*(.eh_frame)) }
.gcc_except_table : { *(.gcc_except_table) }
.dynamic: { *(.dynamic) }
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does
