OSPF Neighbors inactivity on 8.0-STABLE
I have a few NASes based on FreeBSD 7.2 and quagga 0.99.14, they all have same configuration with little changes. When I add to network a test server based on FreeBSD 8.0-STABLE with quagga 0.99.15, other servers doesn't receive HELLO packets from him. nas9# tcpdump -i vr0 proto ospf 13:24:04.591907 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:09.594136 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:14.596375 IP 193.62.62.14a> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:19.598678 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:24.600867 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:29.603050 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:34.605322 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:39.607564 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:44.609799 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 Counter of multicast packets on switch port constantly increasing. What the reason of inaccessibility other servers over multicast? ___ 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: misc/144377: Display of discritics is mildly broken
The following reply was made to PR bin/144377; it has been noted by GNATS. From: Ed Schouten To: Garrett Cooper Cc: Ollivier Robert , freebsd-gnats-sub...@freebsd.org Subject: Re: misc/144377: Display of discritics is mildly broken Date: Mon, 1 Mar 2010 08:55:54 +0100 --/c0JJ5TGZ+xtmyhA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Garrett, * Garrett Cooper wrote: > Could this be related to the syscons changes in 8.x? Quite odd. ache@ fixed this bug in HEAD, but it seems it didn't get MFCd back to 8.x. Can you folks try the following patch to see whether it fixes the issue? http://svn.freebsd.org/viewvc/base/head/contrib/ee/ee.c?r1=3D192954&r2=3D1= 96750&view=3Dpatch Greetings, --=20 Ed Schouten WWW: http://80386.nl/ --/c0JJ5TGZ+xtmyhA Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuLcwoACgkQ52SDGA2eCwUADwCeP0wN+bVY2fHUBJalXs/j2cdR pb8An3ASTLUIvz4rlMriAqhaRUWtqNqd =ZTwq -END PGP SIGNATURE- --/c0JJ5TGZ+xtmyhA-- ___ 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/144388: different behavior of make(1) between command line argument and .MAKEFLAGS special target
>Number: 144388 >Category: bin >Synopsis: different behavior of make(1) between command line argument >and .MAKEFLAGS special target >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: Mon Mar 01 12:10:04 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Jui-Nan Lin >Release:FreeBSD 8.0-RELEASE-p2 amd64 >Organization: FreeBSD Taiwan >Environment: System: FreeBSD Florence.tamama.org 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #8: Thu Jan 7 11:34:24 CST 2010 r...@florence.tamama.org:/usr/obj/usr/src/sys/KERNEL amd64 >Description: There's different behavior of specifying -j1 in command line argument and special target ".MAKEFLAGS" >How-To-Repeat: # cat Makefile .MAKEFLAGS: -j1 all: @/bin/sleep 10 & @/bin/sleep 10 & @wait # time make 0.000u 0.006s 0:00.01 0.0% 0+0k 0+0io 0pf+0w # time make -j1 0.000u 0.006s 0:10.00 0.0% 0+0k 0+0io 0pf+0w >Fix: The behavior should be the same. (running for 10 seconds) >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/144388: different behavior of make(1) between command line argument and .MAKEFLAGS special target
The following reply was made to PR bin/144388; it has been noted by GNATS. From: Garrett Cooper To: Jui-Nan Lin Cc: "freebsd-gnats-sub...@freebsd.org" Subject: Re: bin/144388: different behavior of make(1) between command line argument and .MAKEFLAGS special target Date: Mon, 1 Mar 2010 05:14:20 -0800 On Mar 1, 2010, at 4:09 AM, Jui-Nan Lin wrote: > >> Number: 144388 >> Category: bin >> Synopsis: different behavior of make(1) between command line >> argument and .MAKEFLAGS special target >> 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: Mon Mar 01 12:10:04 UTC 2010 >> Closed-Date: >> Last-Modified: >> Originator: Jui-Nan Lin >> Release:FreeBSD 8.0-RELEASE-p2 amd64 >> Organization: > FreeBSD Taiwan >> Environment: > System: FreeBSD Florence.tamama.org 8.0-RELEASE-p2 FreeBSD 8.0- > RELEASE-p2 #8: Thu Jan 7 11:34:24 CST 2010 r...@florence.tamama.org:/ > usr/obj/usr/src/sys/KERNEL amd64 > >> Description: > There's different behavior of specifying -j1 in command line > argument and special target ".MAKEFLAGS" >> How-To-Repeat: > > # cat Makefile > .MAKEFLAGS: -j1 > > all: >@/bin/sleep 10 & >@/bin/sleep 10 & >@wait > # time make > 0.000u 0.006s 0:00.01 0.0% 0+0k 0+0io 0pf+0w > # time make -j1 > 0.000u 0.006s 0:10.00 0.0% 0+0k 0+0io 0pf+0w >> Fix: > The behavior should be the same. (running for 10 seconds) Can you try adding a line continuation (\) to lines 1 and 2, and remove the @ from lines 2 and 3? I agree that behavior should be the same, or at least in the same ballpark, but I think the former version (0 seconds) is correct. Thanks, -Garrett ___ 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/144388: different behavior of make(1) between command line argument and .MAKEFLAGS special target
The following reply was made to PR bin/144388; it has been noted by GNATS. From: Jui-Nan Lin To: bug-follo...@freebsd.org, yanef...@gmail.com Cc: Subject: Re: bin/144388: different behavior of make(1) between command line argument and .MAKEFLAGS special target Date: Mon, 1 Mar 2010 21:36:56 +0800 Hi Garrett, Following is the result: # cat Makefile .MAKEFLAGS: -j1 all: /bin/sleep 10 & \ /bin/sleep 10 & @wait # time make all /bin/sleep 10 & /bin/sleep 10 & 0.000u 0.006s 0:00.01 0.0% 0+0k 0+0io 0pf+0w # time make -j1 all /bin/sleep 10 & /bin/sleep 10 & 0.000u 0.007s 0:10.00 0.0% 0+0k 0+0io 0pf+0w The latter version is correct because when specifying "-j", make(1) only forks a shell for all commands. If no "-j" specified, make forks 1 shell for each command. You can see manpage of make(1). ___ 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/141956: commit references a PR
The following reply was made to PR kern/141956; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/141956: commit references a PR
Date: Mon, 1 Mar 2010 14:27:30 + (UTC)
Author: bruno
Date: Mon Mar 1 14:27:16 2010
New Revision: 204519
URL: http://svn.freebsd.org/changeset/base/204519
Log:
Deliver siginfo when signal is generated by thr_kill(2) (SI_USER with
properly
filled si_uid and si_pid).
Reported by: Joel Bertrand
PR: 141956
Reviewed by: kib
MFC after: 2 weeks
Modified:
head/sys/kern/kern_thr.c
Modified: head/sys/kern/kern_thr.c
==
--- head/sys/kern/kern_thr.c Mon Mar 1 13:56:15 2010(r204518)
+++ head/sys/kern/kern_thr.c Mon Mar 1 14:27:16 2010(r204519)
@@ -303,12 +303,18 @@ int
thr_kill(struct thread *td, struct thr_kill_args *uap)
/* long id, int sig */
{
+ ksiginfo_t ksi;
struct thread *ttd;
struct proc *p;
int error;
p = td->td_proc;
error = 0;
+ ksiginfo_init(&ksi);
+ ksi.ksi_signo = uap->sig;
+ ksi.ksi_code = SI_USER;
+ ksi.ksi_pid = p->p_pid;
+ ksi.ksi_uid = td->td_ucred->cr_ruid;
PROC_LOCK(p);
if (uap->id == -1) {
if (uap->sig != 0 && !_SIG_VALID(uap->sig)) {
@@ -320,7 +326,7 @@ thr_kill(struct thread *td, struct thr_k
error = 0;
if (uap->sig == 0)
break;
- tdsignal(p, ttd, uap->sig, NULL);
+ tdsignal(p, ttd, uap->sig, &ksi);
}
}
}
@@ -336,7 +342,7 @@ thr_kill(struct thread *td, struct thr_k
else if (!_SIG_VALID(uap->sig))
error = EINVAL;
else
- tdsignal(p, ttd, uap->sig, NULL);
+ tdsignal(p, ttd, uap->sig, &ksi);
}
PROC_UNLOCK(p);
return (error);
@@ -346,6 +352,7 @@ int
thr_kill2(struct thread *td, struct thr_kill2_args *uap)
/* pid_t pid, long id, int sig */
{
+ ksiginfo_t ksi;
struct thread *ttd;
struct proc *p;
int error;
@@ -362,6 +369,11 @@ thr_kill2(struct thread *td, struct thr_
error = p_cansignal(td, p, uap->sig);
if (error == 0) {
+ ksiginfo_init(&ksi);
+ ksi.ksi_signo = uap->sig;
+ ksi.ksi_code = SI_USER;
+ ksi.ksi_pid = td->td_proc->p_pid;
+ ksi.ksi_uid = td->td_ucred->cr_ruid;
if (uap->id == -1) {
if (uap->sig != 0 && !_SIG_VALID(uap->sig)) {
error = EINVAL;
@@ -372,7 +384,8 @@ thr_kill2(struct thread *td, struct thr_
error = 0;
if (uap->sig == 0)
break;
- tdsignal(p, ttd, uap->sig,
NULL);
+ tdsignal(p, ttd, uap->sig,
+ &ksi);
}
}
}
@@ -388,7 +401,7 @@ thr_kill2(struct thread *td, struct thr_
else if (!_SIG_VALID(uap->sig))
error = EINVAL;
else
- tdsignal(p, ttd, uap->sig, NULL);
+ tdsignal(p, ttd, uap->sig, &ksi);
}
}
PROC_UNLOCK(p);
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
___
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/144388: different behavior of make(1) between command line argument and .MAKEFLAGS special target
The following reply was made to PR bin/144388; it has been noted by GNATS. From: Jui-Nan Lin To: Garrett Cooper Cc: "freebsd-gnats-sub...@freebsd.org" Subject: Re: bin/144388: different behavior of make(1) between command line argument and .MAKEFLAGS special target Date: Mon, 1 Mar 2010 22:28:23 +0800 Hi, I have make a patch: http://www.csie.nctu.edu.tw/~jnlin/patch/usr.bin.make.c.patch It works for me. ___ 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/141956: [libc] signal(3): siginfo-> si_pid null in signal handler [regression]
The following reply was made to PR kern/141956; it has been noted by GNATS. From: Bruno Ducrot To: bug-follo...@freebsd.org, joel.bertr...@systella.fr Cc: Subject: Re: kern/141956: [libc] signal(3): siginfo->si_pid null in signal handler [regression] Date: Mon, 01 Mar 2010 15:31:59 +0100 Hi, Actually, the problem was with thr_kill(), and not kill(2). Just commited a fix for this, with kib review. Expect this problem being MFCd in 2 weeks if you stick with RELENG_8. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ 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/141956: [libc] signal(3): siginfo->si_pid null in signal handler [regression]
Synopsis: [libc] signal(3): siginfo->si_pid null in signal handler [regression] State-Changed-From-To: open->Patched State-Changed-By: bruno State-Changed-When: Mon Mar 1 17:45:43 UTC 2010 State-Changed-Why: Has been fixed in HEAD. Waiting MFC before closing this PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=141956 ___ 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"
BTX loader issue
Is the BTX loader issue (or issues) being actively pursued? Upon digging through the PR DB I find that I am not alone and I have ordered new hardware to migrate my current workstation to and everything is on hold due to the BTX loader halting. If the bug has been deemed non-critical and not on the radar, I just need to know, as I may have to load an alternate OS. Thanks -- -=-=-=-=-=-=-+-=-=-=-=-=-=- Rick Chisholm Manager Information Technology Southland Insurance t. 519-326-4455 x. f. 519-326-1324 e. rchish...@southlandonline.com ___ 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/144397: Add PCI ID for MosChip Semiconductor 16550 UART
>Number: 144397
>Category: kern
>Synopsis: Add PCI ID for MosChip Semiconductor 16550 UART
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Mon Mar 01 20:30:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:9-CURRENT
>Organization:
Cisco Systems, Inc
>Environment:
FreeBSD left4dead.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #2: Mon Mar 1
10:29:49 PST 2010
garrc...@left4dead.cisco.com:/usr/obj/usr/src/sys/LEFT4DEAD i386
>Description:
The PCI ID for the card here is missing:
http://www.startech.com/item/PEX2S5521P-2S1P-Port-PCI-Express-Parallel-Serial-Combo-Card-with-16550-UART.aspx
. This also covers several other cards, as mentioned on the webpage.
>How-To-Repeat:
n/a
>Fix:
See patch.
Patch attached with submission follows:
Index: uart_bus_pci.c
===
--- uart_bus_pci.c (revision 204532)
+++ uart_bus_pci.c (working copy)
@@ -113,6 +113,7 @@
{ 0x9710, 0x9820, 0x1000, 1, "NetMos NM9820 Serial Port", 0x10 },
{ 0x9710, 0x9835, 0x1000, 1, "NetMos NM9835 Serial Port", 0x10 },
{ 0x9710, 0x9865, 0xa000, 0x1000, "NetMos NM9865 Serial Port", 0x10 },
+{ 0x9710, 0x9901, 0xa000, 0x1000, "MosChip Semiconductors (Was: Netmos
Technology) 16550 UART", 0x10 },
{ 0xdeaf, 0x9051, 0x, 0, "Middle Digital PC Weasel Serial Port", 0x10 },
{ 0x, 0, 0x, 0, NULL, 0, 0}
};
>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/144397: [uart] [patch] Add PCI ID for MosChip Semiconductor 16550 UART
Synopsis: [uart] [patch] Add PCI ID for MosChip Semiconductor 16550 UART State-Changed-From-To: open->patched State-Changed-By: delphij State-Changed-When: Mon Mar 1 20:41:28 UTC 2010 State-Changed-Why: Slightly modified patch applied against -HEAD. Responsible-Changed-From-To: freebsd-bugs->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Mon Mar 1 20:41:28 UTC 2010 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=144397 ___ 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/144400: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound
>Number: 144400
>Category: misc
>Synopsis: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound
>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: Mon Mar 01 21:50:02 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: andy wilson
>Release:8.0-RELEASE-p2
>Organization:
>Environment:
FreeBSD urania.tx.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #3: Wed Feb 24
11:30:46 CST 2010 j...@urania.tx.net:/usr/obj/usr/src/sys/URANIA i386
>Description:
If you set $named_wait_host to a remote hostname and something is going wrong
with the name resolution process for that particular hostname, your system will
hang indefinitely. Some services (like ntpd) depend on being able to resolve
remote DNS hostnames, but you would still want the system to come up if it is
having trouble resolving $named_wait_host.
It would help to have an additional variable that specifies an upper bound for
how long /etc/rc.d/named spends attempting to resolve $named_wait_host. That
way $named_wait_host can be set to a remote hostname but your system will not
be completely dependent on that hostname successfully resolving.
This addition would make it easy to solve problems like the one discussed here:
http://forums.freebsd.org/showthread.php?t=9171
>How-To-Repeat:
Set up rc.conf with the following variables:
ntpd_enable="YES"
named_enable="YES"
named_wait="YES"
named_wait_host="someunresolvablehostname.somenonexistentdomain.com"
Then run:
/etc/rc.d/named restart
>Fix:
I've attached patches for /etc/rc.d/named and /etc/defaults/rc.conf ; these
patches add and document an optional $named_wait_max variable that sets the
maximum number of seconds that rc.d/named will wait while trying to resolve
$named_wait_host.
Patch attached with submission follows:
--- /etc/rc.d/named.orig2010-03-01 14:25:19.0 -0600
+++ /etc/rc.d/named 2010-03-01 14:26:58.0 -0600
@@ -98,11 +98,16 @@
}
named_poststart () {
+local count
+
make_symlinks
+count=0
+
if checkyesno named_wait; then
- until ${command%/sbin/named}/bin/host $named_wait_host
>/dev/null 2>&1; do
+ until ${command%/sbin/named}/bin/host $named_wait_host
>/dev/null 2>&1 || ([ $named_wait_max ] && [ $count -gt $named_wait_max ]) ; do
echo " Waiting for nameserver to resolve
$named_wait_host"
+count=$((${count} + 1))
sleep 1
done
fi
--- /etc/defaults/rc.conf.orig 2010-03-01 15:07:19.0 -0600
+++ /etc/defaults/rc.conf 2010-03-01 15:13:24.0 -0600
@@ -259,6 +259,9 @@
named_symlink_enable="YES" # Symlink the chrooted pid file
named_wait="NO"# Wait for working name service before exiting
named_wait_host="localhost"# Hostname to check if named_wait is enabled
+#named_wait_max="60"# Maximum number of seconds named_wait will
wait
+# while attempting to resolve named_wait_host.
+# If not set, it will never stop waiting.
named_auto_forward="NO"# Set up forwarders from /etc/resolv.conf
named_auto_forward_only="NO" # Do "forward only" instead of "forward first"
>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/144402: [zfs] panic at zfs_znode_dmu_init: existing znode for dbuf
>Number: 144402 >Category: kern >Synopsis: [zfs] panic at zfs_znode_dmu_init: existing znode for dbuf >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Mar 01 22:20:05 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Alex Bakhtin >Release:8.0-STABLE >Organization: >Environment: FreeBSD tarzan-new.private.flydrag.ru 8.0-STABLE FreeBSD 8.0-STABLE #1: Sun Feb 28 18:58:11 UTC 2010 bakh...@tarzan-new.private.flydrag.ru:/zfs/obj/usr/src.old/sys/DEBUG amd64 >Description: In pre-production testing of FreeBSD 8.0 with ZFS/raidz I found a 100% reproducible panic in zfs. The problem was initially found after two hours of benchmarks/dbench testing on 8.0-RELEASE. The problem was reproduced on 8.0-STABLE csuped at Feb 28, 2010. FreeBSD 8.0-RELEASE #0: Sun Feb 28 15:40:09 UTC 2010 bakh...@tarzan-new.private.flydrag.ru:/zfs/obj/usr/src.old/sys/DEBUG CPU: Intel(R) Pentium(R) CPU E5200 @ 2.50GHz (2536.15-MHz K8-class CPU) real memory = 8589934592 (8192 MB) tarzan-new# zpool status pool: zfs state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAMESTATE READ WRITE CKSUM zfs ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad10ONLINE 0 0 0 ad12ONLINE 0 0 0 ad16ONLINE 0 0 0 errors: No known data errors tarzan-new# tarzan-new# zdb -vvv zfs version=13 name='zfs' state=0 txg=342 pool_guid=14801748754090954299 hostid=4266611921 hostname='tarzan-new.private.flydrag.ru' vdev_tree type='root' id=0 guid=14801748754090954299 children[0] type='raidz' id=0 guid=11719031541734505632 nparity=1 metaslab_array=23 metaslab_shift=31 ashift=9 asize=240064659456 is_log=0 children[0] type='disk' id=0 guid=541462146913312867 path='/dev/ad10' whole_disk=0 children[1] type='disk' id=1 guid=14783639361535716946 path='/dev/ad12' whole_disk=0 children[2] type='disk' id=2 guid=8087457233125113893 path='/dev/ad16' whole_disk=0 tarzan-new# Crash data: 6040548853.18 MB/sec execute 400 sec 6040566453.18 MB/sec execute 401 sec panic: existing znode 0xff0103514468 for dbuf 0xff00d494ea80^M cpuid = 1^M KDB: enter: panic^M [thread pid 1113 tid 100202 ] Stopped at kdb_enter+0x3d: movq$0,0x69a270(%rip) db:0:kdb.enter.panic> bt Tracing pid 1113 tid 100202 td 0xff00196703a0 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b zfs_znode_dmu_init() at zfs_znode_dmu_init+0xb5 zfs_znode_alloc() at zfs_znode_alloc+0xa0 zfs_mknode() at zfs_mknode+0x204 zfs_freebsd_create() at zfs_freebsd_create+0x594 VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 vn_open_cred() at vn_open_cred+0x473 kern_openat() at kern_openat+0x179 syscall() at syscall+0x118 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip = 0x80073075c, rsp = 0x7fffdd98, rbp = 0x800a05100 --- Console logs: http://flydrag.dyndns.org:9090/freebsd/zfs-panic/1/console.txt crashinfo: http://flydrag.dyndns.org:9090/freebsd/zfs-panic/1/core.txt vmcore: http://flydrag.dyndns.org:9090/freebsd/zfs-panic/1/vmcore.1.gz >How-To-Repeat: Install FreeBSD/amd64 (not tested on i386) 8.0-RELEASE, csup (optionally) to STABLE. Create zpool (tested on raidz1). Install /usr/ports/benchmarks/dbench Run dbench -t 1 -D /zfs/bench 60 >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: misc/144400: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound
The following reply was made to PR misc/144400; it has been noted by GNATS. From: Andrew Wilson To: bug-follo...@freebsd.org, wilson.andre...@gmail.com Cc: Subject: Re: misc/144400: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound Date: Mon, 1 Mar 2010 17:30:09 -0600 I misfiled this; it should have been filed in conf. Sorry about that. ___ 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: conf/144400: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound
Synopsis: [patch] /etc/rc.d/named - $named_wait_host needs an upper bound Responsible-Changed-From-To: freebsd-bugs->freebsd-rc Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 2 00:36:42 UTC 2010 Responsible-Changed-Why: Fix category and assign. http://www.freebsd.org/cgi/query-pr.cgi?pr=144400 ___ 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/144402: [zfs] [panic] panic at zfs_znode_dmu_init: existing znode for dbuf
Old Synopsis: [zfs] panic at zfs_znode_dmu_init: existing znode for dbuf New Synopsis: [zfs] [panic] panic at zfs_znode_dmu_init: existing znode for dbuf Responsible-Changed-From-To: freebsd-bugs->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 2 00:40:49 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=144402 ___ 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/144398: Re: kern/142921: [kernel] memory allocation/release problem?
Old Synopsis: =?UTF-8?q?Re:%20kern/142921:%20[kernel]%20memory%20allocation/release%20problem=3F?= New Synopsis: Re: kern/142921: [kernel] memory allocation/release problem? State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Tue Mar 2 00:41:16 UTC 2010 State-Changed-Why: Misfiled followup to kern/142921; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 2 00:41:16 UTC 2010 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=144398 ___ 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/144411: mtree(8) doesn't reject non-regular files for -X
>Number: 144411
>Category: bin
>Synopsis: mtree(8) doesn't reject non-regular files for -X
>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: Tue Mar 02 04:40:02 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:
Didn't fully read the manpage for mtree(8), and I assumed that -X accepted
exclusion arguments like tar does.
Turns out that wasn't the case, and mtree hangs when given directories via -X:
[r...@garrcoop-fbsd /usr/home/garrcoop/head/tools/regression/lib/libc/gen]#
mtree -X /boot/
^C
The patch attached does a stat(2) on the file first to ensure that the resolved
file is in fact legitimate, then proceeds to poke at the file to make sure that
it's a regular file.
This is a draft patch and can and will be revised if necessary..
>How-To-Repeat:
mtree -X /boot
>Fix:
See proposed patch attached.
Patch attached with submission follows:
Index: excludes.c
===
--- excludes.c (revision 204532)
+++ excludes.c (working copy)
@@ -31,6 +31,7 @@
__FBSDID("$FreeBSD$");
#include
+#include
#include /* XXX for mtree.h */
#include
@@ -39,6 +40,7 @@
#include
#include
#include
+#include
#include "mtree.h" /* XXX for extern.h */
#include "extern.h"
@@ -66,10 +68,23 @@
FILE *fp;
char *line, *str;
struct exclude *e;
+ struct stat exclude_stat;
size_t len;
+ /* Let's resolve the name via stat(2) so symlinks to files pass. */
+ if (stat(name, &exclude_stat) < 0) {
+ err(1, "%s", name);
+ }
+ /* Don't let certain files like directories, fifos, etc pass. */
+ if (!S_ISREG(exclude_stat.st_mode)) {
+ /* Make the error message make sense for the directory error
+* case. All other values can be EINVAL. */
+ errno = S_ISDIR(exclude_stat.st_mode) ? EISDIR : EINVAL;
+ err(1, "%s", name);
+ }
+
fp = fopen(name, "r");
- if (fp == 0)
+ if (fp == NULL)
err(1, "%s", name);
while ((line = fgetln(fp, &len)) != 0) {
>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"
