Re: junk/145970: avumscon
Synopsis: avumscon State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Fri Apr 23 07:29:01 UTC 2010 State-Changed-Why: spam. http://www.freebsd.org/cgi/query-pr.cgi?pr=145970 ___ 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: gnu/145973: filkjlch
Synopsis: filkjlch State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Fri Apr 23 07:30:18 UTC 2010 State-Changed-Why: spam. http://www.freebsd.org/cgi/query-pr.cgi?pr=145973 ___ 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: junk/145977: wsesxhgp
Synopsis: wsesxhgp State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Fri Apr 23 07:30:44 UTC 2010 State-Changed-Why: spam http://www.freebsd.org/cgi/query-pr.cgi?pr=145977 ___ 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: junk/145980: dpprmhpq
Synopsis: dpprmhpq State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Fri Apr 23 07:31:05 UTC 2010 State-Changed-Why: spam. http://www.freebsd.org/cgi/query-pr.cgi?pr=145980 ___ 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: junk/145982: gtnvcdft
Synopsis: gtnvcdft State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Fri Apr 23 07:31:31 UTC 2010 State-Changed-Why: spam http://www.freebsd.org/cgi/query-pr.cgi?pr=145982 ___ 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: junk/145972: tffchela
Synopsis: tffchela State-Changed-From-To: open->closed State-Changed-By: brucec State-Changed-When: Fri Apr 23 07:35:26 UTC 2010 State-Changed-Why: spam http://www.freebsd.org/cgi/query-pr.cgi?pr=145972 ___ 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: amd64/135014: [padlock] Using padlock(4) in 8-current triggers "fpudna in kernel mode!" warnings
On Thursday 22 April 2010 21:07:32 Kostik Belousov wrote: > Do you consider the report you wrote useful ? > > Some time ago I posted > http://people.freebsd.org/~kib/misc/kern_fpu.3.patch > that contains a fix for a bug. Yes, it was extremely useful because I now know that the code I was running was buggy and I will apply your new patch :) -- Bruce Cran ___ 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/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS.
From: Kostik Belousov
To: John Baldwin
Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, k...@freebsd.org,
davi...@freebsd.org
Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
Date: Fri, 23 Apr 2010 15:25:01 +0300
--kG2acDqmwoBDcCHP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote:
> I tracked the sigprocmask() system calls down to the operations to
> acquire a write lock in the runtime linker. The lock was added to fix
> an earlier bug with throwing exceptions in multithreaded C++ apps. The
> relevant commit that added the lock is this:
>
>http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D178807
>
> Are exceptions permitted during a signal handler? If not, then in
> theory we would not need to invoke sigprocmask() for this particular
> lock perhaps? I'm not sure how easy that would be to achieve given the
> hooks to allow the thread library to overload the locking routines.
> Also, this doesn't explain the lack of sigprocmask() calls under i386.
> FreeBSD/i386 should be using the same locking code and thus invoking
> sigprocmask() for each exception as well.
Throwing an exception during asyncronous signal execution rises undefined
behaviour, AFAIK. sigprocmask() is there to support libc_r, and cannot
be removed as far as we need to provide FreeBSD 4.x compatibility.
What can be done is to provide completely dummy implementation of rtld
locks by the modern libc. Fortunately, libthr only injects its rtld
locks implementation into rtld on first thread creation. The simple
stack of RtldLockInfo seems to give us proper restoration to the libc
provided locks instead of default locks when process is back to
single-thread.
The prototype is below. It does not work for static linking, and this is
the first usage of __attribute__((constructor)), at least in libc.
Alexander, I do remember about -DDEBUG in rtld-elf/Makefile.
diff --git a/lib/libc/Makefile b/lib/libc/Makefile
index b58b6cb..be41c1c 100644
--- a/lib/libc/Makefile
+++ b/lib/libc/Makefile
@@ -16,6 +16,8 @@ SHLIB_MAJOR=3D 7
WARNS?=3D 2
CFLAGS+=3D-I${.CURDIR}/include -I${.CURDIR}/../../include
CFLAGS+=3D-I${.CURDIR}/${MACHINE_ARCH}
+CFLAGS+=3D-I${.CURDIR}/../../libexec/rtld-elf
+CFLAGS+=3D-I${.CURDIR}/../../libexec/rtld-elf/${MACHINE_ARCH}
CFLAGS+=3D-DNLS
CLEANFILES+=3Dtags
INSTALL_PIC_ARCHIVE=3D
diff --git a/lib/libc/gen/Makefile.inc b/lib/libc/gen/Makefile.inc
index 2f562da..fadf339 100644
--- a/lib/libc/gen/Makefile.inc
+++ b/lib/libc/gen/Makefile.inc
@@ -10,7 +10,7 @@ SRCS+=3D __getosreldate.c __xuname.c \
alarm.c arc4random.c assert.c basename.c check_utility_compat.c \
clock.c closedir.c confstr.c \
crypt.c ctermid.c daemon.c devname.c dirname.c disklabel.c \
- dlfcn.c drand48.c erand48.c err.c errlst.c errno.c \
+ dlfcn.c dllock.c drand48.c erand48.c err.c errlst.c errno.c \
exec.c fdevname.c feature_present.c fmtcheck.c fmtmsg.c fnmatch.c \
fpclassify.c frexp.c fstab.c ftok.c fts.c fts-compat.c ftw.c \
getbootfile.c getbsize.c \
diff --git a/lib/libc/gen/dllock.c b/lib/libc/gen/dllock.c
new file mode 100644
index 000..0980147
--- /dev/null
+++ b/lib/libc/gen/dllock.c
@@ -0,0 +1,107 @@
+/*-
+ * Copyright (c) 2010 Konstantin Belousov
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURP=
OSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENT=
IAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STR=
ICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY W=
AY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$");
+
+#include
+#include
+#in
conf/145990: Request to change timezone info for Russian Federation
>Number: 145990 >Category: conf >Synopsis: Request to change timezone info for Russian Federation >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: Fri Apr 23 17:15:48 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Maxim P. Kondakov >Release:8.0-RELEASE-p1 >Organization: >Environment: FreeBSD 77.94.42.156 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #0: Fri Dec 11 11:24:36 EET 2009 r...@77.94.42.156:/usr/src/sys/i386/compile/MAXX8 i386 >Description: There was changes in Russian Federation timezones since 28.03.2010. Below are government resolutions regarding time zone changes: http://premier.gov.ru/eng/events/messages/9834/ http://premier.gov.ru/eng/events/messages/9863/ http://premier.gov.ru/eng/events/messages/9864/ http://government.ru/gov/results/7752/ related bug info in debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574919 >How-To-Repeat: try to set correct timezone info >Fix: change timezone info http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574919 >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/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: John Baldwin To: Kostik Belousov Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, k...@freebsd.org, davi...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 23 Apr 2010 08:43:41 -0400 On Friday 23 April 2010 8:25:01 am Kostik Belousov wrote: > On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote: > > I tracked the sigprocmask() system calls down to the operations to > > acquire a write lock in the runtime linker. The lock was added to fix > > an earlier bug with throwing exceptions in multithreaded C++ apps. The > > relevant commit that added the lock is this: > > > >http://svn.freebsd.org/viewvc/base?view=revision&revision=178807 > > > > Are exceptions permitted during a signal handler? If not, then in > > theory we would not need to invoke sigprocmask() for this particular > > lock perhaps? I'm not sure how easy that would be to achieve given the > > hooks to allow the thread library to overload the locking routines. > > Also, this doesn't explain the lack of sigprocmask() calls under i386. > > FreeBSD/i386 should be using the same locking code and thus invoking > > sigprocmask() for each exception as well. > > Throwing an exception during asyncronous signal execution rises undefined > behaviour, AFAIK. sigprocmask() is there to support libc_r, and cannot > be removed as far as we need to provide FreeBSD 4.x compatibility. Hmmm. Why does libthr use sigprocmask() for its rtld locks then? Is that just a copy-paste from libc_r that can be removed now? -- John Baldwin ___ 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/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: Kostik Belousov To: John Baldwin Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, k...@freebsd.org, davi...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 23 Apr 2010 16:47:40 +0300 --z118w8IfbP8nVdqq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2010 at 08:43:41AM -0400, John Baldwin wrote: > On Friday 23 April 2010 8:25:01 am Kostik Belousov wrote: > > On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote: > > > I tracked the sigprocmask() system calls down to the operations to > > > acquire a write lock in the runtime linker. The lock was added to fix > > > an earlier bug with throwing exceptions in multithreaded C++ apps. The > > > relevant commit that added the lock is this: > > > > > >http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D1788= 07 > > > > > > Are exceptions permitted during a signal handler? If not, then in > > > theory we would not need to invoke sigprocmask() for this particular > > > lock perhaps? I'm not sure how easy that would be to achieve given the > > > hooks to allow the thread library to overload the locking routines. > > > Also, this doesn't explain the lack of sigprocmask() calls under i386. > > > FreeBSD/i386 should be using the same locking code and thus invoking > > > sigprocmask() for each exception as well. > >=20 > > Throwing an exception during asyncronous signal execution rises undefin= ed > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and cannot > > be removed as far as we need to provide FreeBSD 4.x compatibility. >=20 > Hmmm. Why does libthr use sigprocmask() for its rtld locks then? Is tha= t=20 > just a copy-paste from libc_r that can be removed now? Hmmm^2. It seems it is there to prevent recursive entry into rtld from signal handler, that may reference yet unresolved symbol, e.g. libc syscall wrapper, from PLT. So my patch is wrong. --z118w8IfbP8nVdqq Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvRpPwACgkQC3+MBN1Mb4he1gCg18kWbb7UFBC3TGpZ1fe7vJhU 0lUAn2Rf4j2SWLC+hdPQqJs8Qn25q+0P =IpCA -END PGP SIGNATURE- --z118w8IfbP8nVdqq-- ___ 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/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: John Baldwin To: Kostik Belousov Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, k...@freebsd.org, davi...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 23 Apr 2010 10:21:41 -0400 On Friday 23 April 2010 9:47:40 am Kostik Belousov wrote: > On Fri, Apr 23, 2010 at 08:43:41AM -0400, John Baldwin wrote: > > On Friday 23 April 2010 8:25:01 am Kostik Belousov wrote: > > > On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote: > > > > I tracked the sigprocmask() system calls down to the operations to > > > > acquire a write lock in the runtime linker. The lock was added to fix > > > > an earlier bug with throwing exceptions in multithreaded C++ apps. The > > > > relevant commit that added the lock is this: > > > > > > > >http://svn.freebsd.org/viewvc/base?view=revision&revision=178807 > > > > > > > > Are exceptions permitted during a signal handler? If not, then in > > > > theory we would not need to invoke sigprocmask() for this particular > > > > lock perhaps? I'm not sure how easy that would be to achieve given the > > > > hooks to allow the thread library to overload the locking routines. > > > > Also, this doesn't explain the lack of sigprocmask() calls under i386. > > > > FreeBSD/i386 should be using the same locking code and thus invoking > > > > sigprocmask() for each exception as well. > > > > > > Throwing an exception during asyncronous signal execution rises undefined > > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and cannot > > > be removed as far as we need to provide FreeBSD 4.x compatibility. > > > > Hmmm. Why does libthr use sigprocmask() for its rtld locks then? Is that > > just a copy-paste from libc_r that can be removed now? > > Hmmm^2. It seems it is there to prevent recursive entry into rtld from > signal handler, that may reference yet unresolved symbol, e.g. libc > syscall wrapper, from PLT. So my patch is wrong. Presumably we could use a different type of lock that doesn't use sigprocmask() to serialize calls do dl_iterate_phdr()? I'm not sure if libthr would really need to overwrite the behavior of that lock or if a simple atomic_cmpset()-based mutex would always be fine. OTOH, I'm not sure why libthr needs to use non-standard lock hooks at this point as they don't seem to be markedly different from the ones rtld uses. -- John Baldwin ___ 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/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64
The following reply was made to PR kern/131597; it has been noted by GNATS. From: Kostik Belousov To: John Baldwin Cc: bug-follo...@freebsd.org, guilla...@morinfr.org, k...@freebsd.org, davi...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Fri, 23 Apr 2010 17:41:11 +0300 --A47bNRIYjYQgpFVi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2010 at 10:21:41AM -0400, John Baldwin wrote: > On Friday 23 April 2010 9:47:40 am Kostik Belousov wrote: > > On Fri, Apr 23, 2010 at 08:43:41AM -0400, John Baldwin wrote: > > > On Friday 23 April 2010 8:25:01 am Kostik Belousov wrote: > > > > On Thu, Apr 22, 2010 at 04:09:34PM -0400, John Baldwin wrote: > > > > > I tracked the sigprocmask() system calls down to the operations to > > > > > acquire a write lock in the runtime linker. The lock was added to= fix > > > > > an earlier bug with throwing exceptions in multithreaded C++ apps= . The > > > > > relevant commit that added the lock is this: > > > > > > > > > >http://svn.freebsd.org/viewvc/base?view=3Drevision&revision=3D= 178807 > > > > > > > > > > Are exceptions permitted during a signal handler? If not, then in > > > > > theory we would not need to invoke sigprocmask() for this particu= lar > > > > > lock perhaps? I'm not sure how easy that would be to achieve give= n the > > > > > hooks to allow the thread library to overload the locking routine= s. > > > > > Also, this doesn't explain the lack of sigprocmask() calls under = i386. > > > > > FreeBSD/i386 should be using the same locking code and thus invok= ing > > > > > sigprocmask() for each exception as well. > > > >=20 > > > > Throwing an exception during asyncronous signal execution rises und= efined > > > > behaviour, AFAIK. sigprocmask() is there to support libc_r, and can= not > > > > be removed as far as we need to provide FreeBSD 4.x compatibility. > > >=20 > > > Hmmm. Why does libthr use sigprocmask() for its rtld locks then? Is= that=20 > > > just a copy-paste from libc_r that can be removed now? > >=20 > > Hmmm^2. It seems it is there to prevent recursive entry into rtld from > > signal handler, that may reference yet unresolved symbol, e.g. libc > > syscall wrapper, from PLT. So my patch is wrong. >=20 > Presumably we could use a different type of lock that doesn't use > sigprocmask() to serialize calls do dl_iterate_phdr()? I'm not sure if > libthr would really need to overwrite the behavior of that lock or if > a simple atomic_cmpset()-based mutex would always be fine. During my porting of libunwind, I was told by libunwind maintainer that they have to call dl_iterate_phdr() from signal context to unwind, if libunwind is called from signal context. Apparently, glibc' dl_iterate_phdr() is not signal-safe, while our is. > > OTOH, I'm not sure why libthr needs to use non-standard lock hooks at > this point as they don't seem to be markedly different from the ones > rtld uses. libthr locks provide exclusion both for other kernel-executed threads and signal handlers, while the rtld-default locks only protect against signal handlers and thus libc_r-style threads. --A47bNRIYjYQgpFVi Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvRsYYACgkQC3+MBN1Mb4jm5QCg8l0OCcuqNiutS2fpF84GQ7rW 1TcAoNwW+edk57r3KM/RaOBFybdHivHi =JtDQ -END PGP SIGNATURE- --A47bNRIYjYQgpFVi-- ___ 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/145990: Request to change timezone info for Russian Federation
The following reply was made to PR conf/145990; it has been noted by GNATS. From: Maxim Konovalov To: "Maxim P. Kondakov" Cc: bug-follo...@freebsd.org Subject: Re: conf/145990: Request to change timezone info for Russian Federation Date: Fri, 23 Apr 2010 21:42:49 +0400 (MSD) It is already fixed in HEAD with the following commit: r206219 | edwin | 2010-04-06 02:15:06 +0400 (×Ô, 06 ÁÐÒ 2010) | 17 lines MFV of tzdata2010h: From tzdata2010h: - Tunis will not go into DST this year. - Pakistan will not go into DST this year. From tzdata2010g: - Bangladesh cancels DST. - Palestine goes into DST one day later than expected. - Russian timezones update: Europe/Samara goes to Moscow time. Asia/Kamchatka goes to Moscow+8 time. Asia/Anadyr goes to Moscow+8 time. %%% And in RELENG_8: r206221 | edwin | 2010-04-06 03:43:23 +0400 (×Ô, 06 ÁÐÒ 2010) | 17 lines MFC of tzdata2010h: From tzdata2010h: - Tunis will not go into DST this year. - Pakistan will not go into DST this year. From tzdata2010g: - Bangladesh cancels DST. - Palestine goes into DST one day later than expected. - Russian timezones update: Europe/Samara goes to Moscow time. Asia/Kamchatka goes to Moscow+8 time. Asia/Anadyr goes to Moscow+8 time. %%% -- Maxim Konovalov ___ 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"
Remove my account from this mailing list
What the hell is going with this mailling list... I try to unsubcribe three day agon and it's today that i recevied the confirm mail to unsubscribe... When i return it, i received this one; (How can i continu to received this $...@%%#$ mail if i am already unsubcribe) The results of your email command are provided below. Attached is your original message. - Results: You are not currently a member. Have you already unsubscribed or changed your email address? - Unprocessed: DQotLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tLQ0KRGU6IGZyZWVic2QtYnVncy1yZXF1ZXN0 QGZyZWVic2Qub3JnDQpFeHDpZGl0ZXVyOiBvd25lci1mcmVlYnNkLWJ1Z3NAZnJlZWJzZC5vcmcN CsA6IGZyYW5jaXNwcm92QHlhaG9vLmNhDQpS6XBvbmRyZSDgOiBmcmVlYnNkLWJ1Z3MtcmVxdWVz dEBmcmVlYnNkLm9yZw0KT2JqZXQ6IGNvbmZpcm0gZjkwZTY3NTMyMjI0ZmM3OTdlMThiMDE0OWEz MzQ1NGI4Nzc1ZGYxMg0KRW52b3npOiAyMSBhdnIsIDIwMTAgMzo0NiBQTQ0KDQpNYWlsaW5nIGxp c3QgcmVtb3ZhbCBjb25maXJtYXRpb24gbm90aWNlIGZvciBtYWlsaW5nIGxpc3QgZnJlZWJzZC1i dWdzDQoNCldlIGhhdmUgcmVjZWl2ZWQgYSByZXF1ZXN0IGZvciB0aGUgcmVtb3ZhbCBvZiB5b3Vy IGVtYWlsIGFkZHJlc3MsDQoiZnJhbmNpc3Byb3ZAeWFob28uY2EiIGZyb20gdGhlIGZyZWVic2Qt YnVnc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QuDQpUbyBjb25maXJtIHRoYXQgeW91IHdhbnQg dG8gYmUgcmVtb3ZlZCBmcm9tIHRoaXMgbWFpbGluZyBsaXN0LCBzaW1wbHkNCnJlcGx5IHRvIHRo aXMgbWVzc2FnZSwga2VlcGluZyB0aGUgU3ViamVjdDogaGVhZGVyIGludGFjdC4gIE9yIHZpc2l0 DQp0aGlzIHdlYiBwYWdlOg0KDQogICAgaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4v Y29uZmlybS9mcmVlYnNkLWJ1Z3MvZjkwZTY3NTMyMjI0ZmM3OTdlMThiMDE0OWEzMzQ1NGI4Nzc1 ZGYxMg0KDQoNCk9yIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBsaW5lIC0tIGFuZCBvbmx5IHRoZSBm b2xsb3dpbmcgbGluZSAtLSBpbiBhDQptZXNzYWdlIHRvIGZyZWVic2QtYnVncy1yZXF1ZXN0QGZy ZWVic2Qub3JnOg0KDQogICAgY29uZmlybSBmOTBlNjc1MzIyMjRmYzc5N2UxOGIwMTQ5YTMzNDU0 Yjg3NzVkZjEyDQoNCk5vdGUgdGhhdCBzaW1wbHkgc2VuZGluZyBhIGByZXBseScgdG8gdGhpcyBt ZXNzYWdlIHNob3VsZCB3b3JrIGZyb20NCm1vc3QgbWFpbCByZWFkZXJzLCBzaW5jZSB0aGF0IHVz dWFsbHkgbGVhdmVzIHRoZSBTdWJqZWN0OiBsaW5lIGluIHRoZQ0KcmlnaHQgZm9ybSAoYWRkaXRp b25hbCAiUmU6IiB0ZXh0IGluIHRoZSBTdWJqZWN0OiBpcyBva2F5KS4NCg0KSWYgeW91IGRvIG5v dCB3aXNoIHRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QsIHBsZWFzZSBzaW1wbHkNCmRpc3Jl Z2FyZCB0aGlzIG1lc3NhZ2UuICBJZiB5b3UgdGhpbmsgeW91IGFyZSBiZWluZyBtYWxpY2lvdXNs eQ0KcmVtb3ZlZCBmcm9tIHRoZSBsaXN0LCBvciBoYXZlIGFueSBvdGhlciBxdWVzdGlvbnMsIHNl bmQgdGhlbSB0bw0KZnJlZWJzZC1idWdzLW93bmVyQGZyZWVic2Qub3JnLg0KDQoNClNlbnQgZnJv bSBteSBCbGFja0JlcnJ5IGRldmljZSBvbiB0aGUgUm9nZXJzIFdpcmVsZXNzIE5ldHdvcms= - Ignored: - Done. ___ 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/145999: optional offset for `mdconfig -t vnode'
>Number: 145999 >Category: kern >Synopsis: optional offset for `mdconfig -t vnode' >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: Fri Apr 23 19:00:12 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Mikhail T. >Release:FreeBSD 7.3-STABLE amd64 >Organization: Virtual Estates, Inc. http://sybpipe.com/ >Environment: System: FreeBSD aldan.narawntapu 7.3-STABLE FreeBSD 7.3-STABLE #3: Fri Apr 9 17:20:45 EDT 2010 m...@aldan.narawntapu:/var/src/sys/amd64/compile/SILVER-SMP amd64 >Description: It is already possible to use only part of the file by explicitly specifying the size (mdconfig -s) of the md. For completeness, it should also be possible to request, that certain number of bytes be skipped from the beginning... If necessary, requiring that this offset be a multiple of 512 or some such is acceptable. For example: mdconfig -t vnode -f zhoo -b 8192 (-b would stand for "begin"). >How-To-Repeat: This could be useful for people dealing with files, that have file-system images embedded in them -- preceded by some other data... The only existing work-around for such situations is using something like dd skip= to produce a separate file, which can almost double the storage requirements and cause other inconvenience. I propose, that the md_base field of the md_ioctl struct (currently in use only in the MD_PRELOAD cases) be used for this purpose. >Fix: The userland changes (add an option for mdconfig.c) is easy. The kernel changes required are beyond my knowledge... >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: Remove my account from this mailing list
On Fri, Apr 23, 2010 at 02:30:27PM -0400, Francis Provencher wrote: > What the hell is going with this mailling list... > > I try to unsubcribe three day agon and it's today that i recevied the > confirm mail to unsubscribe... > > When i return it, i received this one; > > (How can i continu to received this $...@%%#$ mail if i am already > unsubcribe) My guess is that you subscribed using a different Email address some time ago and then forwarded that address to the one you are currently using. Then you have tried to unsubscribe using the Email address that you forwarded your Email to rather than the one used on the list. The system cannot guess that you have forwarded your Email, nor can it backtrack forwards. Could be something else, but that fits all your symptoms and is something I see very often on a couple of other list I manage. jerry > > > > The results of your email command are provided below. Attached is your > original message. > > - Results: > You are not currently a member. Have you already unsubscribed or changed > your email address? > > - Unprocessed: > DQotLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tLQ0KRGU6IGZyZWVic2QtYnVncy1yZXF1ZXN0 > QGZyZWVic2Qub3JnDQpFeHDpZGl0ZXVyOiBvd25lci1mcmVlYnNkLWJ1Z3NAZnJlZWJzZC5vcmcN > CsA6IGZyYW5jaXNwcm92QHlhaG9vLmNhDQpS6XBvbmRyZSDgOiBmcmVlYnNkLWJ1Z3MtcmVxdWVz > dEBmcmVlYnNkLm9yZw0KT2JqZXQ6IGNvbmZpcm0gZjkwZTY3NTMyMjI0ZmM3OTdlMThiMDE0OWEz > MzQ1NGI4Nzc1ZGYxMg0KRW52b3npOiAyMSBhdnIsIDIwMTAgMzo0NiBQTQ0KDQpNYWlsaW5nIGxp > c3QgcmVtb3ZhbCBjb25maXJtYXRpb24gbm90aWNlIGZvciBtYWlsaW5nIGxpc3QgZnJlZWJzZC1i > dWdzDQoNCldlIGhhdmUgcmVjZWl2ZWQgYSByZXF1ZXN0IGZvciB0aGUgcmVtb3ZhbCBvZiB5b3Vy > IGVtYWlsIGFkZHJlc3MsDQoiZnJhbmNpc3Byb3ZAeWFob28uY2EiIGZyb20gdGhlIGZyZWVic2Qt > YnVnc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QuDQpUbyBjb25maXJtIHRoYXQgeW91IHdhbnQg > dG8gYmUgcmVtb3ZlZCBmcm9tIHRoaXMgbWFpbGluZyBsaXN0LCBzaW1wbHkNCnJlcGx5IHRvIHRo > aXMgbWVzc2FnZSwga2VlcGluZyB0aGUgU3ViamVjdDogaGVhZGVyIGludGFjdC4gIE9yIHZpc2l0 > DQp0aGlzIHdlYiBwYWdlOg0KDQogICAgaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4v > Y29uZmlybS9mcmVlYnNkLWJ1Z3MvZjkwZTY3NTMyMjI0ZmM3OTdlMThiMDE0OWEzMzQ1NGI4Nzc1 > ZGYxMg0KDQoNCk9yIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBsaW5lIC0tIGFuZCBvbmx5IHRoZSBm > b2xsb3dpbmcgbGluZSAtLSBpbiBhDQptZXNzYWdlIHRvIGZyZWVic2QtYnVncy1yZXF1ZXN0QGZy > ZWVic2Qub3JnOg0KDQogICAgY29uZmlybSBmOTBlNjc1MzIyMjRmYzc5N2UxOGIwMTQ5YTMzNDU0 > Yjg3NzVkZjEyDQoNCk5vdGUgdGhhdCBzaW1wbHkgc2VuZGluZyBhIGByZXBseScgdG8gdGhpcyBt > ZXNzYWdlIHNob3VsZCB3b3JrIGZyb20NCm1vc3QgbWFpbCByZWFkZXJzLCBzaW5jZSB0aGF0IHVz > dWFsbHkgbGVhdmVzIHRoZSBTdWJqZWN0OiBsaW5lIGluIHRoZQ0KcmlnaHQgZm9ybSAoYWRkaXRp > b25hbCAiUmU6IiB0ZXh0IGluIHRoZSBTdWJqZWN0OiBpcyBva2F5KS4NCg0KSWYgeW91IGRvIG5v > dCB3aXNoIHRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QsIHBsZWFzZSBzaW1wbHkNCmRpc3Jl > Z2FyZCB0aGlzIG1lc3NhZ2UuICBJZiB5b3UgdGhpbmsgeW91IGFyZSBiZWluZyBtYWxpY2lvdXNs > eQ0KcmVtb3ZlZCBmcm9tIHRoZSBsaXN0LCBvciBoYXZlIGFueSBvdGhlciBxdWVzdGlvbnMsIHNl > bmQgdGhlbSB0bw0KZnJlZWJzZC1idWdzLW93bmVyQGZyZWVic2Qub3JnLg0KDQoNClNlbnQgZnJv > bSBteSBCbGFja0JlcnJ5IGRldmljZSBvbiB0aGUgUm9nZXJzIFdpcmVsZXNzIE5ldHdvcms= > > - Ignored: > > > - Done. > ___ > 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" > ___ 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: Remove my account from this mailing list
On Fri, Apr 23, 2010 at 02:52:06PM -0400, Francis Provencher wrote: > Hi Jerry, > > Im unsubscribe with the two accounts the is bind to my gmail account. > > The two confirmation mail tell me that im not on this mailling list, > but i continu to received mail from it. Exactly what would happen if a different address was what was subscribed and then forwarded to another account (to your gmail account, for example). So, you need to figure out what account you originally used to subscribe. jerry > > > Grrr > > On Fri, Apr 23, 2010 at 2:46 PM, Jerry McAllister wrote: > > On Fri, Apr 23, 2010 at 02:30:27PM -0400, Francis Provencher wrote: > > > >> What the hell is going with this mailling list... > >> > >> I try to unsubcribe three day agon and it's today that i recevied the > >> confirm mail to unsubscribe... > >> > >> When i return it, i received this one; > >> > >> (How can i continu to received this $...@%%#$ mail if i am already > >> unsubcribe) > > > > My guess is that you subscribed using a different Email address some > > time ago and then forwarded that address to the one you are currently > > using. > > > > Then you have tried to unsubscribe using the Email address that you > > forwarded your Email to rather than the one used on the list. > > > > The system cannot guess that you have forwarded your Email, nor > > can it backtrack forwards. > > > > Could be something else, but that fits all your symptoms and is > > something I see very often on a couple of other list I manage. > > > > jerry > > > > > > > > > >> > >> > >> > >> The results of your email command are provided below. Attached is your > >> original message. > >> > >> - Results: > >> You are not currently a member. Have you already unsubscribed or changed > >> your email address? > >> > >> - Unprocessed: > >> > >> DQotLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tLQ0KRGU6IGZyZWVic2QtYnVncy1yZXF1ZXN0 > >> > >> QGZyZWVic2Qub3JnDQpFeHDpZGl0ZXVyOiBvd25lci1mcmVlYnNkLWJ1Z3NAZnJlZWJzZC5vcmcN > >> > >> CsA6IGZyYW5jaXNwcm92QHlhaG9vLmNhDQpS6XBvbmRyZSDgOiBmcmVlYnNkLWJ1Z3MtcmVxdWVz > >> > >> dEBmcmVlYnNkLm9yZw0KT2JqZXQ6IGNvbmZpcm0gZjkwZTY3NTMyMjI0ZmM3OTdlMThiMDE0OWEz > >> > >> MzQ1NGI4Nzc1ZGYxMg0KRW52b3npOiAyMSBhdnIsIDIwMTAgMzo0NiBQTQ0KDQpNYWlsaW5nIGxp > >> > >> c3QgcmVtb3ZhbCBjb25maXJtYXRpb24gbm90aWNlIGZvciBtYWlsaW5nIGxpc3QgZnJlZWJzZC1i > >> > >> dWdzDQoNCldlIGhhdmUgcmVjZWl2ZWQgYSByZXF1ZXN0IGZvciB0aGUgcmVtb3ZhbCBvZiB5b3Vy > >> > >> IGVtYWlsIGFkZHJlc3MsDQoiZnJhbmNpc3Byb3ZAeWFob28uY2EiIGZyb20gdGhlIGZyZWVic2Qt > >> > >> YnVnc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QuDQpUbyBjb25maXJtIHRoYXQgeW91IHdhbnQg > >> > >> dG8gYmUgcmVtb3ZlZCBmcm9tIHRoaXMgbWFpbGluZyBsaXN0LCBzaW1wbHkNCnJlcGx5IHRvIHRo > >> > >> aXMgbWVzc2FnZSwga2VlcGluZyB0aGUgU3ViamVjdDogaGVhZGVyIGludGFjdC4gIE9yIHZpc2l0 > >> > >> DQp0aGlzIHdlYiBwYWdlOg0KDQogICAgaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4v > >> > >> Y29uZmlybS9mcmVlYnNkLWJ1Z3MvZjkwZTY3NTMyMjI0ZmM3OTdlMThiMDE0OWEzMzQ1NGI4Nzc1 > >> > >> ZGYxMg0KDQoNCk9yIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBsaW5lIC0tIGFuZCBvbmx5IHRoZSBm > >> > >> b2xsb3dpbmcgbGluZSAtLSBpbiBhDQptZXNzYWdlIHRvIGZyZWVic2QtYnVncy1yZXF1ZXN0QGZy > >> > >> ZWVic2Qub3JnOg0KDQogICAgY29uZmlybSBmOTBlNjc1MzIyMjRmYzc5N2UxOGIwMTQ5YTMzNDU0 > >> > >> Yjg3NzVkZjEyDQoNCk5vdGUgdGhhdCBzaW1wbHkgc2VuZGluZyBhIGByZXBseScgdG8gdGhpcyBt > >> > >> ZXNzYWdlIHNob3VsZCB3b3JrIGZyb20NCm1vc3QgbWFpbCByZWFkZXJzLCBzaW5jZSB0aGF0IHVz > >> > >> dWFsbHkgbGVhdmVzIHRoZSBTdWJqZWN0OiBsaW5lIGluIHRoZQ0KcmlnaHQgZm9ybSAoYWRkaXRp > >> > >> b25hbCAiUmU6IiB0ZXh0IGluIHRoZSBTdWJqZWN0OiBpcyBva2F5KS4NCg0KSWYgeW91IGRvIG5v > >> > >> dCB3aXNoIHRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QsIHBsZWFzZSBzaW1wbHkNCmRpc3Jl > >> > >> Z2FyZCB0aGlzIG1lc3NhZ2UuICBJZiB5b3UgdGhpbmsgeW91IGFyZSBiZWluZyBtYWxpY2lvdXNs > >> > >> eQ0KcmVtb3ZlZCBmcm9tIHRoZSBsaXN0LCBvciBoYXZlIGFueSBvdGhlciBxdWVzdGlvbnMsIHNl > >> > >> bmQgdGhlbSB0bw0KZnJlZWJzZC1idWdzLW93bmVyQGZyZWVic2Qub3JnLg0KDQoNClNlbnQgZnJv > >> bSBteSBCbGFja0JlcnJ5IGRldmljZSBvbiB0aGUgUm9nZXJzIFdpcmVsZXNzIE5ldHdvcms= > >> > >> - Ignored: > >> > >> > >> - Done. > >> ___ > >> 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" > >> > > > ___ 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/145940: [crypto] [patch] OpenSSH_5.4p1 - do not prepend AuthorizedKeysFile with getcwd(), unbreaks relative paths
Old Synopsis: [BUG] OpenSSH_5.4p1 - do not prepend AuthorizedKeysFile with getcwd(), unbreaks relative paths New Synopsis: [crypto] [patch] OpenSSH_5.4p1 - do not prepend AuthorizedKeysFile with getcwd(), unbreaks relative paths Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 23 22:12:23 UTC 2010 Responsible-Changed-Why: reclassify http://www.freebsd.org/cgi/query-pr.cgi?pr=145940 ___ 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/145999: [request] optional offset for `mdconfig -t vnode'
Old Synopsis: optional offset for `mdconfig -t vnode' New Synopsis: [request] optional offset for `mdconfig -t vnode' State-Changed-From-To: open->suspended State-Changed-By: linimon State-Changed-When: Sat Apr 24 00:41:52 UTC 2010 State-Changed-Why: Mark suspended awaiting patches. http://www.freebsd.org/cgi/query-pr.cgi?pr=145999 ___ 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"
