bin/145934: [patch] add count option to netstat
>Number: 145934
>Category: bin
>Synopsis: [patch] add count option to netstat
>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 Apr 22 07:00:12 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Dmitry Banshchikov
>Release:FreeBSD 8.0-RELEASE
>Organization:
>Environment:
>Description:
Allows user to specify -c for netstat, to repeat display output in case of -w
option(Similar to -c option of iostat utility)
Example usage:
#./netstat -w2 -c3
input(Total) output
packets errs bytespackets errs bytes colls
20 0 1830 5 0334 0
9 0 3037 9 0 1246 0
14 0 1268 7 0658 0
#
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
--- if.c2009-10-25 04:10:29.0 +0300
+++ if.c2010-04-21 11:32:15.0 +0400
@@ -676,6 +676,10 @@
if (!first)
putchar('\n');
fflush(stdout);
+ if (cflag)
+ count--;
+ if (count < 0 && cflag)
+ exit(0);
oldmask = sigblock(sigmask(SIGALRM));
while (!signalled)
sigpause(0);
--- main.c 2009-10-25 04:10:29.0 +0300
+++ main.c 2010-04-22 10:30:57.0 +0400
@@ -322,6 +322,7 @@
intaflag; /* show all sockets (including servers) */
intBflag; /* show information about bpf consumers */
intbflag; /* show i/f total bytes in/out */
+intcflag; /* repeat display */
intdflag; /* show i/f dropped packets */
intgflag; /* show group (multicast) routing or stats */
inthflag; /* show counters in human readable format */
@@ -339,6 +340,7 @@
intzflag; /* zero stats */
intinterval; /* repeat interval for i/f stats */
+intcount; /* repeat display output */
char *interface; /* desired i/f for stats, or NULL for all i/fs */
intunit; /* unit number for above */
@@ -354,7 +356,7 @@
af = AF_UNSPEC;
- while ((ch = getopt(argc, argv, "AaBbdf:ghI:iLlM:mN:np:rSstuWw:xz")) !=
-1)
+ while ((ch = getopt(argc, argv, "AaBbc:df:ghI:iLlM:mN:np:rSstuWw:xz"))
!= -1)
switch(ch) {
case 'A':
Aflag = 1;
@@ -368,6 +370,10 @@
case 'b':
bflag = 1;
break;
+ case 'c':
+ cflag = 1;
+ count = atoi(optarg);
+ break;
case 'd':
dflag = 1;
break;
--- netstat.1 2009-10-25 04:10:29.0 +0300
+++ netstat.1 2010-04-22 10:27:40.0 +0400
@@ -132,6 +132,7 @@
.Bk -words
.Nm
.Fl w Ar wait
+.Op Fl c Ar count
.Op Fl I Ar interface
.Op Fl d
.Op Fl M Ar core
@@ -141,7 +142,9 @@
At intervals of
.Ar wait
seconds,
-display the information regarding packet
+display
+.Ar count
+times the information regarding packet
traffic on all configured network interfaces
or a single
.Ar interface .
--- netstat.h 2009-10-25 04:10:29.0 +0300
+++ netstat.h 2010-04-22 10:29:12.0 +0400
@@ -39,6 +39,7 @@
extern int Aflag; /* show addresses of protocol control block */
extern int aflag; /* show all sockets (including servers) */
extern int bflag; /* show i/f total bytes in/out */
+extern int cflag; /* repeat display output */
extern int dflag; /* show i/f dropped packets */
extern int gflag; /* show group (multicast) routing or stats */
extern int hflag; /* show counters in human readable format */
@@ -55,6 +56,7 @@
extern int zflag; /* zero stats */
extern int interval; /* repeat interval for i/f stats */
+extern int count;/* repeat display output */
extern char*interface; /* desired i/f for stats, or NULL for all i/fs */
extern int unit; /* unit number for above */
>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/145748: hexdump(1) %s format qualifier broken
The following reply was made to PR bin/145748; it has been noted by GNATS. From: Garrett Cooper To: Wayne Sierke Cc: bug-follo...@freebsd.org Subject: Re: bin/145748: hexdump(1) %s format qualifier broken Date: Thu, 22 Apr 2010 01:06:19 -0700 --Apple-Mail-1--588879786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 21, 2010, at 7:44 PM, Wayne Sierke wrote: > On Tue, 2010-04-20 at 17:49 -0700, Garrett Cooper wrote: >> The issue with %4s failing is still a failure. The non-issue with >> %.4s, %0.4s etc not failing is not a failure; it's just a bit more >> obfuscated logic. >=20 > I don't follow. hexdump(1) behaves as described re the "[field] > precision/byte count" value while the "field width" component remains > functional: >=20 > # jot -ns '' 8 1 | hexdump -e '"<%6.4s>\n"' > < 1234> > < 5678> > # jot -ns '' 8 1 | hexdump -e '"<%-6.4s>\n"' > <1234 > > <5678 > > #=20 >=20 >>> The part of the hexdump(1) manpage quoted previously: >>>=20 >>> o A byte count or field precision is required for each ``s'' con- >>> version character (unlike the fprintf(3) default which prints >>> the entire string if the precision is unspecified). >>=20 >> That statement is misleading. It should make the above statement with >> field width, not [field] precision. >=20 > This seems to be the crux of the claim, but I don't see the basis for > making it. >=20 >> FWIW, the statement `field >> precision' makes absolutely no sense in the terminology used by >> printf(3), and is most likely a typo. >=20 > It's true that the term "field precision" isn't defined but I'd expect > it to generally be taken as referring to "precision". It probably is a > typo in this sense but in this particular application the use of > "precision" rather than "field width" does follow a certain logic: >=20 > "precision" from printf(3): > the maximum number of characters to be printed from a string; >=20 > from hexdump(1): > The byte count is an optional positive integer. If specified it = defines > the number of bytes to be interpreted by each iteration of the format. >=20 >> And finally, yes I agree that %s is illegal because you can't qualify >> the number of characters required for each format unit -- something >> that's required for hexdump to function. %4s, etc with precision not >> being specified is legal however. >=20 > "%4s" is legal if the "byte count" is specified, eg: >=20 > # echo hello, world | hexdump -e '/3 "<%4s>"' > < hel>< lo,>< wo>< rld>< =20 >> # >=20 >>> And as observed hexdump does accept the required value when passed a >>> "field precision" - the numeric value immediately after the period = in >>> "%.4s" (NB not a "field width" - as described in fprintf(3) and = slightly >>> more clearly in printf(3)). >>=20 >> =46rom printf(3): >>=20 >> o An optional decimal digit string specifying a minimum field = width. >> If the converted value has fewer characters than the field = width, it >> will be padded with spaces on the left (or right, if the = left-adjust- >> ment flag has been given) to fill out the field width. >>=20 >> o An optional precision, in the form of a period . followed by = an >> optional digit string. If the digit string is omitted, the = precision >> is taken as zero. This gives the minimum number of digits to = appear >> for d, i, o, u, x, and X conversions, the number of digits to = appear >> after the decimal-point for a, A, e, E, f, and F conversions, = the >> maximum number of significant digits for g and G conversions, = or the >> maximum number of characters to be printed from a string for = s con- >> versions. >>=20 >> Note the word `optional' in the first and second clauses. `.' isn't >> required except to disambiguate precision from field width. >=20 > I don't agree with this interpretation. "precision" is optional, but > when present it takes the form of a period optionally followed by a > digit string. That is, when including a precision the period is not > optional but the digit string is. The period is required as a = delimiter, > not merely for disambiguation. I understand what you and Bruce were trying to say this morning; = it was all my misunderstanding because I didn't properly understand the = concept of precision and how it pertained to %s qualifiers. I'm filing a bug for the other item you saw earlier. I've = determine what the issue was and have solved it in my private workspace. Thanks, -Garrett= --Apple-Mail-1--588879786 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Tue, 2010-04-20 at 17:49 -0700, Garrett Cooper wrote:The issue with %4s failing is still a failure. The = non-issue with%.4s, %0.4s etc = not failing is not a failure; it's just a bit = mo
kern/145946: [patch] feature request: VDSO and shared pages
>Number: 145946 >Category: kern >Synopsis: [patch] feature request: VDSO and shared pages >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 Apr 22 13:50:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: Giuseppe Cocomazzi >Release:8.0-CURRENT-200809 >Organization: >Environment: FreeBSD claire 8.0-CURRENT-200809 FreeBSD 8.0-CURRENT-200809 #0: Mon Nov 2 01:03:38 CET 2009 r...@claire:/usr/obj/usr/src/sys/SCTRAMPOLINE i386 >Description: Hi, I've written a huge patch which implements vdso support and shared page subsystem for freebsd. Unfortunately, I've been waiting for a review for quite a long time and, after some positive responses, silence overcame, so the code became a bit old, also due to my difficulty in keeping the source up-to-date. I understand that now it is very unlikely for the patch to be seriously considered, however I provide the links to the code and a little explanatory paper, in case someone is interested: patch: http://sbudella.altervista.org/stuff/shared_page_vdso.patch paper: http://sbudella.altervista.org/stuff/shared_page_vdso.note tgz: http://sbudella.altervista.org/stuff/shared_page_vdso.tgz Feedback would be very appreciated. Thanks for your attention, Giuseppe Cocomazzi -- every day above ground is a good one http://sbudella.altervista.org >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: amd64/135014: [padlock] Using padlock(4) in 8-current triggers "fpudna in kernel mode!" warnings
On Monday 05 April 2010 16:22:36 Bruce Cran wrote: > On Monday 05 April 2010 15:15:08 Michael Moll wrote: > > the patch from > > http://people.freebsd.org/~kib/misc/kern_fpu.2.patch > > fixes this problem for me. > > The patch fixes the problem on my i386 mini-iTX system too. I don't know if it's related, but I've been having regular crashes on the same box since applying the patch. Sometimes it runs for 12 hours, other times only for a few minutes. -- 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: John Baldwin To: bug-follo...@freebsd.org, guilla...@morinfr.org Cc: k...@freebsd.org Subject: Re: kern/131597: [kernel] c++ exceptions very slow on FreeBSD 7.1/amd64 Date: Thu, 22 Apr 2010 16:09:34 -0400 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. -- 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: amd64/135014: [padlock] Using padlock(4) in 8-current triggers "fpudna in kernel mode!" warnings
On Thu, Apr 22, 2010 at 07:04:58PM +0100, Bruce Cran wrote: > On Monday 05 April 2010 16:22:36 Bruce Cran wrote: > > On Monday 05 April 2010 15:15:08 Michael Moll wrote: > > > the patch from > > > http://people.freebsd.org/~kib/misc/kern_fpu.2.patch > > > fixes this problem for me. > > > > The patch fixes the problem on my i386 mini-iTX system too. > > I don't know if it's related, but I've been having regular crashes on > the same box since applying the patch. Sometimes it runs for 12 hours, > other times only for a few minutes. 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. pgpL5A39xfawU.pgp Description: PGP signature
kern/145960: [patch] mfi(4) - make MFI_STAT_INVALID_STATUS error more apparent in mfi_aen_complete
>Number: 145960
>Category: kern
>Synopsis: [patch] mfi(4) - make MFI_STAT_INVALID_STATUS error more
>apparent in mfi_aen_complete
>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 Apr 22 23:10:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Garrett Cooper
>Release:9-CURRENT
>Organization:
Cisco Systems, Inc.
>Environment:
FreeBSD bioshock.cisco.com 9.0-CURRENT FreeBSD 9.0-CURRENT #7 r206031: Sat Apr
17 20:20:46 PDT 2010 r...@bioshock.cisco.com:/usr/obj/usr/src/sys/BIOSHOCK
amd64
>Description:
The proposed change just makes the error code returned in mfi_aen_complete more
apparent by changing 0xff to MFI_STAT_INVALID_STATUS, as
MFI_STAT_INVALID_STATUS is 0xff:
$ grep -r MFI_STAT_INVALID_STATUS sys/dev/mfi/mfireg.h
MFI_STAT_INVALID_STATUS = 0xFF
>How-To-Repeat:
>Fix:
Patch attached with submission follows:
Index: sys/dev/mfi/mfi.c
===
--- sys/dev/mfi/mfi.c (revision 206031)
+++ sys/dev/mfi/mfi.c (working copy)
@@ -1149,7 +1149,8 @@
if (sc->mfi_aen_cm == NULL)
return;
- if (sc->mfi_aen_cm->cm_aen_abort || hdr->cmd_status == 0xff) {
+ if (sc->mfi_aen_cm->cm_aen_abort ||
+ hdr->cmd_status == MFI_STAT_INVALID_STATUS) {
sc->mfi_aen_cm->cm_aen_abort = 0;
aborted = 1;
} else {
>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/145961: [nanobsd] improved flash update script
>Number: 145961
>Category: misc
>Synopsis: [nanobsd] improved flash update script
>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 00:30:03 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Aragon Gouveia
>Release:FreeBSD 8.0-STABLE amd64
>Organization:
>Environment:
System: FreeBSD igor.geek.sh 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Mar 8
01:27:41 SAST 2010 t...@igor.geek.sh:/usr/obj/usr/src/sys/IGOR amd64
>Description:
NanoBSD has some utility shell scripts called updatep1 and updatep2
which help upgrade system flash with a new image file and make it bootable.
These scripts still use fdisk and boot0cfg which seems to be error prone on
FreeBSD 8.0, causing vfs errors after an update.
I've attached a single update script which auto detects which partition
is active and upgrades the inactive partition. It also uses gpart for making
the new partition bootable.
>How-To-Repeat:
>Fix:
--- update begins here ---
#!/bin/sh
# usage:
# ssh somewhere cat image.s1 | sh update
#
set -e
. /etc/nanobsd.conf
ACTIVE=0
if mount |grep -q ^/dev/${NANO_DRIVE}s1; then
ACTIVE=1
fi
if mount |grep -q ^/dev/${NANO_DRIVE}s2; then
ACTIVE=$(( ${ACTIVE} + 2 ))
fi
case ${ACTIVE} in
1)
UPDATE=2
;;
2)
UPDATE=1
;;
*)
echo "Unknown system state. Aborting upgrade..." 1>&2
exit 1
;;
esac
echo "Partition ${ACTIVE} active, updating partition ${UPDATE}..."
# Blow away old system.
dd if=/dev/zero of=/dev/${NANO_DRIVE}s${UPDATE} bs=1m count=1 > /dev/null 2>&1
# Copy in new system
dd of=/dev/${NANO_DRIVE}s${UPDATE} obs=128k
# Check that it worked
fsck_ffs -n /dev/${NANO_DRIVE}s${UPDATE}a
echo
echo "Image data written successfully. Activating..."
if [ ${UPDATE} -eq 2 ]; then
# Update the /etc/fstab
trap "umount /mnt" 1 2 3 15 EXIT
mount /dev/${NANO_DRIVE}s2a /mnt
sed -i "" "s/${NANO_DRIVE}s1/${NANO_DRIVE}s2/" /mnt/conf/base/etc/fstab
sed -i "" "s/${NANO_DRIVE}s1/${NANO_DRIVE}s2/" /mnt/etc/fstab
umount /mnt
trap - 1 2 3 15 EXIT
fi
gpart set -a active -i ${UPDATE} ${NANO_DRIVE}
--- update ends here ---
>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/145961: [nanobsd] improved flash update script
The following reply was made to PR misc/145961; it has been noted by GNATS. From: Aragon Gouveia To: bug-follo...@freebsd.org Cc: Subject: Re: misc/145961: [nanobsd] improved flash update script Date: Fri, 23 Apr 2010 02:42:28 +0200 If this script is accepted, please note PR misc/144553 can be closed too. ___ 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/145962: [nanobsd] improved cfg save script
>Number: 145962
>Category: misc
>Synopsis: [nanobsd] improved cfg save script
>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 00:50:05 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Aragon Gouveia
>Release:FreeBSD 8.0-STABLE amd64
>Organization:
>Environment:
System: FreeBSD igor.geek.sh 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Mar 8
01:27:41 SAST 2010 t...@igor.geek.sh:/usr/obj/usr/src/sys/IGOR amd64
>Description:
NanoBSD has a utility shell script called save_cfg which helps keep
/cfg updated with the modified configuration files in /etc. I have written an
improved version with the following features:
* Recurses directories.
* Only requires file arguments the first time the file/directory is
added to /cfg.
* Handles file deletions.
* Is named "cfgsync" so is much easier to type.
>How-To-Repeat:
>Fix:
--- cfgsync begins here ---
#!/bin/sh
set -e
rundir="$(pwd)/"
trap "umount /cfg" 1 2 3 15 EXIT
mount /cfg
for i in "$@"; do
if [ -n "${i%%/*}" ]; then
# relative (to rundir) path given
if [ -n "${rundir%%/etc/*}" ]; then
echo "${i} not under /etc -- skipping" 1>&2
continue
fi
etcfile="${rundir}${i}"
cfgfile="/cfg/${rundir##*/etc/}${i}"
else
# absolute path given
if [ -z "${i%%/etc/*}" ]; then
echo "${i} not under /etc -- skipping" 1>&2
continue
fi
etcfile="${i}"
cfgfile="/cfg/${i##*/etc/}"
fi
cfgdir=$(dirname ${cfgfile})
if [ ! -f ${etcfile} ]; then
echo "${i} not a file -- skipping" 1>&2
continue
fi
if ! cmp -s ${etcfile} ${cfgfile}; then
if [ ! -d ${cfgdir} ]; then
mkdir -pv ${cfgdir}
fi
cp -pfv ${etcfile} ${cfgfile}
fi
done
for i in $( find /cfg -type f ); do
etcfile="/etc/${i##*/cfg/}"
cfgfile="${i}"
if [ ! -f ${etcfile} ]; then
echo -n "${etcfile} disappeared. Delete from /cfg? [y/N] "
read delconfirm
if [ "${delconfirm}" = "y" ]; then
echo -n "deleting "
rm -fv ${cfgfile}
fi
elif ! cmp -s ${etcfile} ${cfgfile}; then
cp -pfv ${etcfile} ${cfgfile}
fi
done
--- cfgsync ends here ---
>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/145961: [nanobsd] improved flash update script
On Thu, Apr 22, 2010 at 5:50 PM, Aragon Gouveia wrote: > The following reply was made to PR misc/145961; it has been noted by GNATS. > > From: Aragon Gouveia > To: bug-follo...@freebsd.org > Cc: > Subject: Re: misc/145961: [nanobsd] improved flash update script > Date: Fri, 23 Apr 2010 02:42:28 +0200 > > If this script is accepted, please note PR misc/144553 can be closed too. Including misc/145962 as well ? 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: misc/145961: [nanobsd] improved flash update script
On 04/23/10 03:04, Garrett Cooper wrote: On Thu, Apr 22, 2010 at 5:50 PM, Aragon Gouveia wrote: If this script is accepted, please note PR misc/144553 can be closed too. Including misc/145962 as well ? No, misc/145962 is a different, unrelated submission. Thanks, Aragon ___ 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/145970: avumscon
>Number: 145970 >Category: bin >Synopsis: avumscon >Confidential: no >Severity: critical >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 23 06:20:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: avumscon >Release:avumscon >Organization: avumscon >Environment: avumscon >Description: [URL=http://vhgsnduj.com]ybezdlxs[/URL] http://ugacnnuu.com";>tdymuqhk ojqkvwzq http://drdwuthn.com tufexgsj mremjuqi >How-To-Repeat: avumscon >Fix: avumscon >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"
gnu/145972: tffchela
>Number: 145972 >Category: gnu >Synopsis: tffchela >Confidential: no >Severity: non-critical >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 23 06:20:02 UTC 2010 >Closed-Date: >Last-Modified: >Originator: tffchela >Release:tffchela >Organization: tffchela >Environment: tffchela >Description: xswmomle http://gawamfye.com anqqgibv rubthuzm [URL=http://fvqzpoot.com]wytzpkeo[/URL] http://sgnxsaup.com";>wjtlbyim >How-To-Repeat: tffchela >Fix: tffchela >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"
gnu/145973: filkjlch
>Number: 145973 >Category: gnu >Synopsis: filkjlch >Confidential: no >Severity: critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 23 06:20:02 UTC 2010 >Closed-Date: >Last-Modified: >Originator: filkjlch >Release:filkjlch >Organization: filkjlch >Environment: filkjlch >Description: ncuwxsnu http://blnhqtsj.com srhmvnwf velrjroy http://etyzykvv.com";>fkushzvi [URL=http://pnokukxt.com]nhaehggd[/URL] >How-To-Repeat: filkjlch >Fix: filkjlch >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"
bin/145977: wsesxhgp
>Number: 145977 >Category: bin >Synopsis: wsesxhgp >Confidential: no >Severity: serious >Priority: high >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: update >Submitter-Id: current-users >Arrival-Date: Fri Apr 23 06:30:05 UTC 2010 >Closed-Date: >Last-Modified: >Originator: wsesxhgp >Release:wsesxhgp >Organization: wsesxhgp >Environment: wsesxhgp >Description: [URL=http://sfnillnw.com]uynkqzne[/URL] http://qscsvpvi.com";>jfcrxaek ntzruxde http://bvblbhqg.com douilozw efxxbksj >How-To-Repeat: wsesxhgp >Fix: wsesxhgp >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"
conf/145980: dpprmhpq
>Number: 145980 >Category: conf >Synopsis: dpprmhpq >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: maintainer-update >Submitter-Id: current-users >Arrival-Date: Fri Apr 23 06:40:01 UTC 2010 >Closed-Date: >Last-Modified: >Originator: dpprmhpq >Release:dpprmhpq >Organization: dpprmhpq >Environment: dpprmhpq >Description: mkwvtqvr http://sbxrfgyl.com eujhpexi fcreumkt >How-To-Repeat: dpprmhpq >Fix: dpprmhpq >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/145982: gtnvcdft
>Number: 145982 >Category: misc >Synopsis: gtnvcdft >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: Fri Apr 23 06:40:04 UTC 2010 >Closed-Date: >Last-Modified: >Originator: gtnvcdft >Release:gtnvcdft >Organization: gtnvcdft >Environment: gtnvcdft >Description: uuqhbjlr http://dkjerfvq.com qrhmuvde ogshkmpw >How-To-Repeat: gtnvcdft >Fix: gtnvcdft >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"
