On Fri, 22 Mar 2013 mla_str...@att.net wrote:
I recently bought a 4 TB usb disk drive and discovered that it reported
a sector size of 4096 bytes instead of the traditional 512 bytes. This
is apparently necessary because there may be a 32 bit sector number field
somewhere in the usb mass storag
On Thu, 4 Apr 2013, Brian Demsky wrote:
Description:
Here is the code for swap context:
int
swapcontext(ucontext_t *oucp, const ucontext_t *ucp)
{
int ret;
if ((oucp == NULL) || (ucp == NULL)) {
errno = EINVAL;
return (-1);
}
oucp->uc_flags &= ~UC
The following reply was made to PR misc/177624; it has been noted by GNATS.
From: Bruce Evans
To: Brian Demsky
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: misc/177624: Swapcontext can get compiled incorrectly
Date: Fri, 5 Apr 2013 00:46:32 +1100 (EST)
This
On Fri, 5 Apr 2013, Bruce Evans wrote:
On Thu, 4 Apr 2013, Brian Demsky wrote:
Description:
Here is the code for swap context:
int
swapcontext(ucontext_t *oucp, const ucontext_t *ucp)
{
int ret;
if ((oucp == NULL) || (ucp == NULL)) {
errno = EINVAL
The following reply was made to PR misc/177624; it has been noted by GNATS.
From: Bruce Evans
To: Bruce Evans
Cc: Brian Demsky , freebsd-bugs@freebsd.org,
freebsd-gnats-sub...@freebsd.org
Subject: Re: misc/177624: Swapcontext can get compiled incorrectly
Date: Fri, 5 Apr 2013 02:16:02
On Thu, 4 Apr 2013, Brian Demsky wrote:
On Apr 4, 2013, at 8:16 AM, Bruce Evans wrote:
On Fri, 5 Apr 2013, Bruce Evans wrote:
On Thu, 4 Apr 2013, Brian Demsky wrote:
Description:
Here is the code for swap context:
int
swapcontext(ucontext_t *oucp, const ucontext_t *ucp)
{
int ret
The following reply was made to PR misc/177624; it has been noted by GNATS.
From: Bruce Evans
To: Brian Demsky
Cc: Bruce Evans , freebsd-bugs@FreeBSD.org,
freebsd-gnats-sub...@freebsd.org
Subject: Re: misc/177624: Swapcontext can get compiled incorrectly
Date: Fri, 5 Apr 2013 06:38:51
On Sun, 19 May 2013, Jilles Tjoelker wrote:
The following reply was made to PR bin/178664; it has been noted by GNATS.
From: Jilles Tjoelker
To: bug-follo...@freebsd.org, kwia...@panic.pl
Cc:
Subject: Re: bin/178664: truss(1) may kill process
Date: Sun, 19 May 2013 14:09:32 +0200
In PR bin/17
On Sun, 26 May 2013, Klaus Weber wrote:
Environment:
FreeBSD filepile 9.1-STABLE FreeBSD 9.1-STABLE #5 r250475: Sun May 12 19:14:21
CEST 2013 root@filepile:/usr/obj/usr/src/sys/FILEPILE amd64
(Kernel config has some drivers removed and debugging options added. Tested
with GENERIC as well
The following reply was made to PR kern/178997; it has been noted by GNATS.
From: Bruce Evans
To: Klaus Weber
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/178997: Heavy disk I/O may hang system
Date: Mon, 27 May 2013 15:57:56 +1000 (EST)
On Sun, 26 May 2013
On Mon, 27 May 2013, Klaus Weber wrote:
On Mon, May 27, 2013 at 03:57:56PM +1000, Bruce Evans wrote:
On Sun, 26 May 2013, Klaus Weber wrote:
Description:
During heavy disk I/O (two bonnie++ processes working on the same disk
simultaneously) causes an extreme degradation in disk throughput
The following reply was made to PR kern/178997; it has been noted by GNATS.
From: Bruce Evans
To: Klaus Weber
Cc: Bruce Evans , freebsd-gnats-sub...@freebsd.org,
freebsd-bugs@FreeBSD.org
Subject: Re: kern/178997: Heavy disk I/O may hang system
Date: Tue, 28 May 2013 22:03:10 +1000 (EST
On Fri, 31 May 2013, Klaus Weber wrote:
Sorry for the late reply, testing took longer than expected.
This is very interesting. It will take me a long time to complete
testing and replying too. Maybe more later.
(I have combined your replies from separate mails into one, and
reordered some
The following reply was made to PR kern/178997; it has been noted by GNATS.
From: Bruce Evans
To: Klaus Weber
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/178997: Heavy disk I/O may hang system
Date: Tue, 4 Jun 2013 07:09:59 +1000 (EST)
On Fri, 31 May 2013
The following reply was made to PR kern/178997; it has been noted by GNATS.
From: Bruce Evans
To: Klaus Weber
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/178997: Heavy disk I/O may hang system
Date: Mon, 10 Jun 2013 11:00:29 +1000 (EST)
On Mon, 10 Jun 2013, Klaus Weber wrote
On Thu, 8 Aug 2013, Garrett Cooper wrote:
Synopsis: [PATCH] set{domain,host}name doesn't permit NUL terminated
strings that are MAXHOSTNAMELEN long
...
Description:
The noted link/patch fixes POSIX and generic requirement compliance for
set{domain,host}name per the manpages by account
The following reply was made to PR kern/181127; it has been noted by GNATS.
From: Bruce Evans
To: Garrett Cooper
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/181127: [PATCH] set{domain, host}name doesn't permit NUL
terminated strings that are MAXHOSTNA
On Thu, 8 Aug 2013, Garrett Cooper wrote:
On Aug 8, 2013, at 4:35 AM, Bruce Evans wrote:
On Thu, 8 Aug 2013, Garrett Cooper wrote:
Synopsis: [PATCH] set{domain,host}name doesn't permit NUL terminated
strings that are MAXHOSTNAMELEN long
...
Description:
The noted link/patch
The following reply was made to PR kern/181127; it has been noted by GNATS.
From: Bruce Evans
To: Garrett Cooper
Cc: Bruce Evans , freebsd-gnats-sub...@freebsd.org,
freebsd-bugs@freebsd.org
Subject: Re: kern/181127: [PATCH] set{domain, host}name doesn't permit NUL
terminated strings
On Tue, 20 Aug 2013, Vitja Makarov wrote:
Description:
Recently I was playing with small socket timeouts. setsockopt(2)
SO_RCVTIMEO and found a problem with it: if timeout is small enough
read(2) may return before timeout is actually expired.
I was unable to reproduce this on linux box.
I fou
The following reply was made to PR kern/181416; it has been noted by GNATS.
From: Bruce Evans
To: Vitja Makarov
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/181416: socket timeout rounding issue
Date: Tue, 20 Aug 2013 20:11:37 +1000 (EST)
On Tue, 20 Aug
On Wed, 21 Aug 2013, Jilles Tjoelker wrote:
In PR kern/181439, you wrote:
> [ does not define siginfo_t]
POSIX says that shall define siginfo_t and may make visible
all symbols from .
This was even in the 2001 version (under an XSI extension) (waitid was
there too).
It has other bugs like r
On Wed, 27 Nov 2013, Brooks Davis wrote:
On Wed, Nov 27, 2013 at 11:03:31PM +, David Cundiff wrote:
> Change PATH_MAX in kernel to 4096 from 1024. Should be harmless and will fix
the issue in any program that uses PATH_MAX from the kernel headers. Also would
allow longer 32-bit unicode pat
On Wed, 12 Feb 2014, Justin Hibbits wrote:
Description:
On x86 it would be very useful to be able to show MSR values using rdmsr in the
debugger.
All inline functions in should be backed by extern
functions, as for on x86 (this too is broken on
other arches). This gives a function rdmsr()
The following reply was made to PR misc/186699; it has been noted by GNATS.
From: Bruce Evans
To: Justin Hibbits
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: misc/186699: ddb on i386 and amd64 should be enhanced to show
MSR values (enhancement)
Date: Thu, 13 Feb
On Wed, 10 Aug 2011, Robert Millan wrote:
Description:
The following headers use register_t but don't #include :
This mostly intentional. , or more often both
and , is a prerequisite for all kernel headers.
arm/include/frame.h
arm/include/profile.h
is not a user header. It is an error
The following reply was made to PR misc/159654; it has been noted by GNATS.
From: Bruce Evans
To: Robert Millan
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org,
k...@freebsd.org
Subject: Re: misc/159654: 46 kernel headers use register_t but don't #include
Date: Th
On Sat, 13 Aug 2011, Alex K. wrote:
Description:
The spelling of acknowledgements could be changed to acknowledgments. Trivial
and submitted to gain experienced making diffs.
How-To-Repeat:
Fix:
--- chio.c 2010-06-02 05:34:41.0 -0400
+++ chio.temp 2011-08-13 23:12:22.00
The following reply was made to PR bin/159752; it has been noted by GNATS.
From: Bruce Evans
To: "Alex K."
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: bin/159752: [patch] chio - incorrect spelling in license
Date: Sun, 14 Aug 2011 12:37:25 +1000 (EST
On Sun, 28 Aug 2011, Kostik Belousov wrote:
On Thu, Aug 11, 2011 at 12:57:33PM +1000, Bruce Evans wrote:
is not a kernel header, but it is not a user
header either. It is an error to include this header directly. The
only supported includes of it are indirectly via in
applications and via
The following reply was made to PR misc/159654; it has been noted by GNATS.
From: Bruce Evans
To: Kostik Belousov
Cc: Bruce Evans , Robert Millan ,
freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: misc/159654: 46 kernel headers use register_t but don't #in
On Sat, 24 Sep 2011, Arnaud Lacombe wrote:
Description:
The following block of code, in `sys/sys/buf_ring.h':
/*
* If there are other enqueues in progress
* that preceeded us, we need to wait for them
* to complete
*/
while (br->br_prod_tail != prod_hea
The following reply was made to PR kern/160992; it has been noted by GNATS.
From: Bruce Evans
To: Arnaud Lacombe
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/160992: buf_ring(9) statistics accounting not MPSAFE
Date: Sun, 25 Sep 2011 13:01:04 +1000 (EST)
On
On Tue, 11 Oct 2011, Garrett Cooper wrote:
Description:
mount(2) claims that it should fail with ENAMETOOLONG if the path is <= 255 or
1023 characters:
[ENAMETOOLONG] A component of a pathname exceeded 255 characters, or
the entire length of a path name exceeded
The following reply was made to PR kern/161481; it has been noted by GNATS.
From: Bruce Evans
To: Garrett Cooper
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/161481: mount fails with ENAMETOOLONG with path shorter
than 255 // 1023 characters
Date: Tue, 11
On Tue, 11 Oct 2011, Garrett Cooper wrote:
The following reply was made to PR kern/161481; it has been noted by GNATS.
From: Garrett Cooper
To: freebsd-gnats-sub...@freebsd.org
Cc: Garrett Cooper
Subject: Re: kern/161481: mount fails with ENAMETOOLONG with path shorter
than 255 // 1023 charac
On Mon, 21 Nov 2011, Adam McDougall wrote:
Description:
[Misformatted lines deleted]
Fix:
Patch attached with submission follows:
--- sys/kern/kern_malloc.c.orig 2011-11-21 12:19:25.712591472 -0500
+++ sys/kern/kern_malloc.c 2011-11-21 17:25:11.831042640 -0500
@@ -704,10 +704,10 @@
The following reply was made to PR kern/162741; it has been noted by GNATS.
From: Bruce Evans
To: Adam McDougall
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/162741: [PATCH] vm_kmem_size miscalculated due to int type
overflow sometimes
Date: Wed, 23 Nov 2011
On Tue, 29 Nov 2011, Emil wrote:
FreeBSD $HOSTNAME.local 8.2-RELEASE FreeBSD 8.2-RELEASE #3: Sat Apr 16 09:20:53
CEST 2011 emil@$HOSTNAME.local:/usr/obj/usr/src/sys/IPSEC i386
Description:
When attempting to include netinet/tcp_var.h in a c++ file, the compiler throws
a number of error
The following reply was made to PR misc/162952; it has been noted by GNATS.
From: Bruce Evans
To: Emil
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: misc/162952: Problems including netinet/tcp_var.h
Date: Wed, 30 Nov 2011 16:41:32 +1100 (EST)
On Tue, 29 Nov 2011
On Mon, 5 Dec 2011, Petr Salinger wrote:
Description:
It is not possible to read in chunks from linprocfs and procfs.
It is a regression against stable-8.
I suspect it is due to changes of sbuf implementation between 8 and 9.
Some files are rather big (over 4KB) and it is really standard to re
The following reply was made to PR kern/163076; it has been noted by GNATS.
From: Bruce Evans
To: Petr Salinger
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/163076: It is not possible to read in chunks from linprocfs
and procfs.
Date: Tue, 6 Dec 2011 02:07
On Tue, 13 Dec 2011, [ISO-8859-1] Olivier Cochard-Labb? wrote:
The following reply was made to PR bin/162659; it has been noted by GNATS.
THe following reply probably won't be noted by gnats, since gnats
created an incomplete Cc list as usual.
I've did some tests: The number of inode after a
On Wed, 14 Dec 2011, Bruce Evans wrote:
On Tue, 13 Dec 2011, [ISO-8859-1] Olivier Cochard-Labb? wrote:
The following reply was made to PR bin/162659; it has been noted by GNATS.
THe following reply probably won't be noted by gnats, since gnats
created an incomplete Cc list as usual.
On Fri, 6 Jan 2012, Eugen Konkov wrote:
Description:
there must not be ^M endline style
How-To-Repeat:
#script
Script done, output file is typescript
when look into 'typesript' file in 'mc' you can see ^M as endline
Edit src/sys/dev/et/if_etreg.h^M
Add delta 1.4.2.2 2012.01.06.18.15.2
The following reply was made to PR bin/163871; it has been noted by GNATS.
From: Bruce Evans
To: Eugen Konkov
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: misc/163871: 'script' save endline as ^M
Date: Sat, 7 Jan 2012 17:00:20 +1100 (EST)
On Fri,
On Sat, 7 Jan 2012, Bruce Evans wrote:
...
watch(8) probably works better for input too. Someone recently tried to
fix EOF handling in script(1) and had problems using VEOF since this gives
input processing unless the default echo mode is turned off. Perhaps
watch(8) can handle this better
The following reply was made to PR bin/163871; it has been noted by GNATS.
From: Bruce Evans
To: Bruce Evans
Cc: Eugen Konkov , freebsd-gnats-sub...@freebsd.org,
freebsd-bugs@FreeBSD.org
Subject: Re: misc/163871: 'script' save endline as ^M
Date: Sat, 7 Jan 2012 19:24:15
On Sun, 8 Jan 2012, Warren Block wrote:
Description:
usbconfig(8)'s -h option prints output to stderr. This output is not due to an
error, and is already 28 lines line. A typical terminal will not display it
all, so the user has to redirect stderr to view it with less or other utilities.
H
On Mon, 9 Jan 2012, Warren Block wrote:
The user can request usage() output with -h or --help or something
equivalent, and that output should go to stdout because it's not an error and
that data is what was requested. IMO, of course.
This should probably be implemented by passing a FILE poin
On Fri, 27 Jan 2012, Marcus Reid wrote:
Description:
ps(1) truncates long commands to the size of the screen even when stdout is not
a terminal. This is counter-intuitive and differs from another implementation
I looked at. Output of ps | grep differs depending on how big your terminal
win
The following reply was made to PR bin/164535; it has been noted by GNATS.
From: Bruce Evans
To: Marcus Reid
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: bin/164535: ps(1) truncates command to screen size even when
stdout is not a tty
Date: Fri, 27 Jan 2012 22:49
On Tue, 31 Jan 2012, Jyun-Yan You wrote:
Description:
ucontext.h does not include any header file that defines size_t.
If we write a program that includes sys/ucontext.h, it may cause compilation
errors.
ports/164654 is the real case.
-current added 2 new prototypes with 5 bugs altogether; 3
The following reply was made to PR kern/164656; it has been noted by GNATS.
From: Bruce Evans
To: Jyun-Yan You
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/164656: Add size_t declaration to ucontext.h of 10-CURRENT
Date: Tue, 31 Jan 2012 18:19:48 +1100 (EST
On Sun, 5 Feb 2012, Nicolas Bourdaud wrote:
Description:
When a write() cannot transfer as many bytes as requested (because of a file
limit), it fails instead of transferring as many bytes as there is room to
write.
This is a violation of the POSIX standard:
http://pubs.opengroup.org/onlinepub
The following reply was made to PR standards/164793; it has been noted by GNATS.
From: Bruce Evans
To: Nicolas Bourdaud
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/164793: 'write' system call violates POSIX standard
Date: Mon, 6 Feb 2012 05:54:50
On Sat, 11 Feb 2012, David Xu wrote:
[... excessive quoting removed]
>> Description:
> When tee(1) tries to write to a file descriptor that has been set to
non-blocking mode the write(2) call may fail with EAGAIN. Instead of retrying the
operation, tee will throw that chunk of data away.
so t
On Wed, 15 Feb 2012, Nicolas Bourdaud wrote:
On 05/02/2012 19:54, Bruce Evans wrote:
I think this is actually a bug in POSIX (XSI). Most programs aren't
prepared to deal with short writes, and returning an error like
truncate() is specified to is adequate.
I disagree, I think that
The following reply was made to PR standards/164793; it has been noted by GNATS.
From: Bruce Evans
To: Nicolas Bourdaud
Cc: Bruce Evans , freebsd-gnats-sub...@freebsd.org,
freebsd-bugs@freebsd.org
Subject: Re: kern/164793: 'write' system call violates POSIX standard
Date: T
The following reply was made to PR kern/19402; it has been noted by GNATS.
From: Bruce Evans
To: Jilles Tjoelker
Cc: bug-follo...@freebsd.org, ne...@segfault.kiev.ua, b...@freebsd.org
Subject: Re: kern/19402: Signals 127 and 128 cannot be detected in wait4()
interface
Date: Mon, 30 Apr 2012 18
On Tue, 14 Sep 2010, Tijl Coosemans wrote:
On Thu, Jul 08, 2010 at 11:29:50AM -0400, John Baldwin wrote:
> ...longjmp(3) isn't safe in a signal context...
POSIX says it's supposed to be safe:
"As it bypasses the usual function call and return mechanisms,
longjmp() shall execute correctly i
On Tue, 21 Sep 2010, Derrick Brashear wrote:
Description:
All but one inclusion of limits.h use the portable (/usr/include) header path;
One uses sys/limits.h, which is included by limits.h.
I wonder if we could properly break unportable includers. In this case,
maybe use one of:
A. Don't
The following reply was made to PR bin/150772; it has been noted by GNATS.
From: Bruce Evans
To: Derrick Brashear
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: bin/150772: csup should include limits.h instead of sys/limits.h
Date: Tue, 21 Sep 2010 18:24:49 +1000
On Fri, 24 Sep 2010 bru...@freebsd.org wrote:
Synopsis: fsck(8) wrapper is not properly passing options to fsck_
Responsible-Changed-From-To: freebsd-bugs->freebsd-fs
Responsible-Changed-By: brucec
Responsible-Changed-When: Fri Sep 24 20:52:17 UTC 2010
Responsible-Changed-Why:
Over to maintaine
On Sun, 26 Sep 2010, Kevin K. Han wrote:
Description:
Create a directory on the root folder, for example ("/whatever").
Switch to user's home directory ("cd /usr/home/username") ... from now onwards,
work in this directory:
Create a symbolic link from inside a user's home ("ln -s /whatever .")
The following reply was made to PR misc/150972; it has been noted by GNATS.
From: Bruce Evans
To: "Kevin K. Han"
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: misc/150972: symbolic link bug
Date: Mon, 27 Sep 2010 06:25:42 +1000 (EST)
On Sun, 26 Sep 201
On Tue, 28 Sep 2010, Mark Blackman wrote:
The following reply was made to PR kern/147599; it has been noted by GNATS.
From: Mark Blackman
To: bug-follo...@freebsd.org,
d...@db.net
Cc:
Subject: Re: kern/147599: [libm] [patch] Import netbsd complex functions into
our libm
Date: Tue, 28 Sep 2010
On Fri, 8 Oct 2010, Svatopluk Kraus wrote:
Description:
A macro ASSERT_ATOMIC_LOAD_PTR() hits in colfire port I work on. It is possibly
due to use of GNU GCC (4.5.1) compiler -Os option (size optimalization). The
macro is applied on four places:
Perhaps gcc-4.5.1 -Os is doing invalid packin
The following reply was made to PR kern/151304; it has been noted by GNATS.
From: Bruce Evans
To: Svatopluk Kraus
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: kern/151304: patch - definitions of variables tested by
ASSERT_ATOMIC_LOAD_PTR
Date: Sat, 9 Oct 2010 07
On Sun, 10 Oct 2010, Garrett Cooper wrote:
...
I've been sitting on this PR for a while and I'd like to wrap it
up and move on, if that's ok. Here's a patch with a more suitable
comment above the stat(2) call.
% Index: usr.sbin/mtree/excludes.c
%
On Tue, 9 Nov 2010, Ulrich [utf-8] Sp??rlein wrote:
Hello Steve, I saw your updated patch for jnf(3) on the mailing list and
was wondering what the correct values for your test case would look like?
I'm asking because on Ubuntu I get slightly different values. Especially
disturbing is, that for
On Wed, 10 Nov 2010, Bruce Evans wrote:
On Tue, 9 Nov 2010, Ulrich [utf-8] Sp??rlein wrote:
FreeBSD -CURRENT:
freebsd64# cc -o testjn -lm testjn.c && ./testjn
2 4.317548e-01
3 1.98e-01
4 6.474667e-02
5 1.638924e-02
6 3.404818e-03
7 6.006884e-04
8 9.216579e-05
9 1.251727e-05
On Wed, 10 Nov 2010, Bruce Evans wrote:
[...unrelated]
Just noticed a minor bug in the float version: from the PR:
% diff --git a/lib/msun/src/e_jnf.c b/lib/msun/src/e_jnf.c
% index 3bbf7b7..d045bb05 100644
% --- a/lib/msun/src/e_jnf.c
% +++ b/lib/msun/src/e_jnf.c
% @@ -152,7 +152,12
On Thu, 11 Nov 2010, Ronald F.Guilmette wrote:
Description:
Apparently, /bin/csh (aka /bin/tcsh) is diddling termios flags, in particular
the ECHO flag, for no apparently good reason and without ever even having been
asked to do so. The result is that the /usr/bin/script program, when invoked
The following reply was made to PR bin/152154; it has been noted by GNATS.
From: Bruce Evans
To: "Ronald F.Guilmette"
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: bin/152154: /bin/csh & /bin/tcsh improperly diddle termios flags
Date: Fri, 12 Nov
On Fri, 12 Nov 2010, Bruce Evans wrote:
On Thu, 11 Nov 2010, Ronald F.Guilmette wrote:
Description:
Apparently, /bin/csh (aka /bin/tcsh) is diddling termios flags, in
particular
the ECHO flag, for no apparently good reason and without ever even having
Perhaps I shouldn't have repli
The following reply was made to PR bin/152154; it has been noted by GNATS.
From: Bruce Evans
To: Bruce Evans
Cc: "Ronald F.Guilmette" , freebsd-bugs@FreeBSD.org,
freebsd-gnats-sub...@freebsd.org
Subject: Re: bin/152154: /bin/csh & /bin/tcsh improperly diddle termios flags
On Sun, 21 Nov 2010, Jilles Tjoelker wrote:
With the new "libteken" terminal emulator code in 9-current, syscons is
now much like xterm. It appears that Backspace is still ^H, but Delete
is now ^[[3~ instead of ^?.
That is a bug, but libteken in syscons mode doesn't have it. Termios
only supp
On Fri, 3 Dec 2010 d...@freebsd.org wrote:
Synopsis: [libm] fma(3) does not respect rounding mode using extended precision
Thanks for the report! This limitation is described in the source for
fma(), and unfortunately, it is unlikely to ever change. There are
several reasons:
- We are a long wa
On Fri, 10 Dec 2010, Warren Block wrote:
Description:
iostat(8) says:
-cRepeat the display count times. If no repeat count is specified,
the default is infinity.
This used to be correct. It said "if no wait interval is specified, then
the default [for the wait interval] is 1 secon
The following reply was made to PR bin/153012; it has been noted by GNATS.
From: Bruce Evans
To: Warren Block
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: bin/153012: iostat(8) requires an argument to -c option
Date: Sat, 11 Dec 2010 21:23:19 +1100 (EST)
On Fri
On Tue, 14 Dec 2010, Alexander Best wrote:
how do you feel about the wording of the vmstat(8) manual? it would be possible
to re-use it for the iostat(8) manual. of course just the -c and -w part.
It's even worse than in iostat(8), mainly due to it being more verbose and
having a similar densi
On Fri, 24 Dec 2010, Keith White wrote:
Description:
It is possible to create and use an msdos filesystem with 2048-byte
sectors; but it is not possible to "fsck" it. "fsck_msdosfs" on
such a fileystem returns:
"could not read boot block (Invalid argument)"
Fix:
The following POC
The following reply was made to PR bin/153426; it has been noted by GNATS.
From: Bruce Evans
To: Keith White
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: bin/153426: [patch] fsck_msdosfs only works with sector size
512
Date: Sat, 25 Dec 2010 01:23:25 +1100 (EST
On Sat, 1 Jan 2011, Roger Leigh wrote:
t...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Description:
When mount is asked to mount a filesystem on a node whose absolute path is
longer than 85 characters in length, the mount fails. Umount also fails under
some circumstances, tho
The following reply was made to PR bin/153600; it has been noted by GNATS.
From: Bruce Evans
To: Roger Leigh
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: bin/153600: Path length restrictions in mount/umount tools
prevent filesystem mount/unmount
Date: Sun, 2 Jan
On Sat, 15 Jan 2011, Stefan `Sec` Zehl wrote:
Description:
On amd64 the PERSIST timer does not get started (and consecquently executed)
for tcp connections stalled on a 0-size receive window. This means that no
single-byte probe packet is sent, so connections might hang indefinitely.
This is
The following reply was made to PR kern/154006; it has been noted by GNATS.
From: Bruce Evans
To: Stefan `Sec` Zehl
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: kern/154006: tcp "window probe" bug on 64bit
Date: Sat, 15 Jan 2011 16:31:10 +1100 (EST)
On Sat, 15 Jan 2011, Bruce Evans wrote:
...
Later code in tcp_output uses bogus casts to long and larger code instead:
% if (recwin < (long)(tp->rcv_adv - tp->rcv_nxt))
% recwin = (long)(tp->rcv_adv - tp->rcv_nxt);
% if (recwin > (long)TCP_MAXWI
The following reply was made to PR kern/154006; it has been noted by GNATS.
From: Bruce Evans
To: Bruce Evans
Cc: Stefan `Sec` Zehl , freebsd-bugs@freebsd.org,
freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/154006: tcp "window probe" bug on 64bit
Date: Sat, 15 Jan 201
On Thu, 24 Feb 2011, Colin Percival wrote:
Description:
make(1) doesn't handle .POSIX: correctly. It sucks in sys.mk before it
reads the Makefile, and sys.mk has several instances of
.if defined(%POSIX)
to switch between POSIX and non-POSIX mode; because sys.mk is processed
first, there is no
The following reply was made to PR bin/155000; it has been noted by GNATS.
From: Bruce Evans
To: Colin Percival
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: bin/155000: make(1) doesn't handle .POSIX: correctly
Date: Fri, 25 Feb 2011 09:35:30 +1100 (EST)
O
On Thu, 24 Feb 2011, Colin Percival wrote:
On 02/24/11 14:35, Bruce Evans wrote:
Except that there is the opportunity to set %POSIX using make -D. This
might be enough in practice. The namespace pollution avoidance is
too perfect -- there seems to be no way to set %POSIX or .POSIX in the
The following reply was made to PR bin/155000; it has been noted by GNATS.
From: Bruce Evans
To: Colin Percival
Cc: Bruce Evans , freebsd-gnats-sub...@freebsd.org,
freebsd-bugs@FreeBSD.org
Subject: Re: bin/155000: make(1) doesn't handle .POSIX: correctly
Date: Fri, 25 Feb 2011 13:
On Sun, 6 Mar 2011, Martin Matuska wrote:
Description:
In many ports, we have to deal with patching the missing bswap32()
and bswap64() functions.
Er, we have these in endian.h.
The gcc-4.3 branch SVN revision is 118361, is GPLv2-licensed,
applies cleanly and is fully compatible with our co
The following reply was made to PR gnu/155309; it has been noted by GNATS.
From: Bruce Evans
To: Martin Matuska
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org
Subject: Re: gnu/155309: [PATCH] gcc: backport bswap32() and bswap64()
Date: Sun, 6 Mar 2011 22:28:19 +1100 (EST)
On
The following reply was made to PR misc/156637; it has been noted by GNATS.
From: Bruce Evans
To: Robert Andersson
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: misc/156637: sys/types.h can't be included when _XOPEN_SOURCE
is defined
Date: Mon, 25 Apr 2011
On Mon, 25 Apr 2011, Robert Andersson wrote:
Description:
When including with _XOPEN_SOURCE defined to 500 or higher, compila
tion will fail with a message similar to this one (using clang, gcc fails with a
similar message):
In file included from main.c:3:
/usr/include/sys/file.h:161:2: err
On Fri, 13 May 2011, Jens Schweikhardt wrote:
Description:
Apparently, "vidcontrol -r foreground background" no longer works. I don't know
when exactly it stopped.
I use it via /etc/rc.conf with
allscreens_flags="-r cyan blue"
The symptom is that running "man man" still uses black on white
The following reply was made to PR bin/157017; it has been noted by GNATS.
From: Bruce Evans
To: Jens Schweikhardt
Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@freebsd.org
Subject: Re: bin/157017: "vidcontrol -r" no longer works
Date: Sat, 14 May 2011 21:04:48 +1000 (EST)
On F
1 - 100 of 231 matches
Mail list logo
