On Wed, 11 Oct 2006, Dmitry Pryanishnikov wrote:
On Wed, 11 Oct 2006, Jeremie Le Hen wrote:
...
Is it envisageable to extend the RELENG_4's and RELENG_4_11's EoL once
more ?
Yes, I'm also voting for it. This support may be limited to
remote-exploitable vulnerabilities only, but I'm sure
On Wed, 18 Oct 2006, Kris Kennaway wrote:
I have been working with someone's system that has em shared with fxp,
and a simple fetch over the em (e.g. of a 10 GB file of zeroes) is
enough to produce watchdog timeouts after a few seconds.
As previously mentioned, changing the INTR_FAST to
On Thu, 26 Oct 2006, Ruslan Ermilov wrote:
On Mon, Sep 11, 2006 at 01:09:15PM -0500, Brooks Davis wrote:
On Sun, Sep 10, 2006 at 09:10:26PM +0200, Stefan Bethke wrote:
I just tried to load my standard kernel from the boot blocks (instead
of using loader(8)), but I either get a hang before the
On Mon, 30 Oct 2006, John Baldwin wrote:
On Thursday 26 October 2006 15:54, Ruslan Ermilov wrote:
On Thu, Oct 26, 2006 at 03:42:34PM -0400, John Baldwin wrote:
On Thursday 26 October 2006 15:18, Ruslan Ermilov wrote:
On Thu, Oct 26, 2006 at 11:38:24AM -0400, John Baldwin wrote:
Sorry, I
On Tue, 12 Dec 2006, Kostik Belousov wrote:
On Tue, Dec 12, 2006 at 12:44:54AM -0800, Suleiman Souhlal wrote:
Is the mount lock really required, if all we're doing is a single read of a
single word (mnt_kern_flags) (v_mount should be read-only for the whole
lifetime of the vnode, I believe)?
On Tue, 12 Dec 2006, John Baldwin wrote:
On Tuesday 12 December 2006 13:43, Suleiman Souhlal wrote:
Why is memory barrier usage not encouraged? As you said, they can be used to
reduce the number of atomic (LOCKed) operations, in some cases.
...
Admittedly, they are harder to use than atomic
On Sun, 7 Jan 2007, Sven Willenberger wrote:
I am starting a new thread on this as what I had assumed was a panic in
nfsd turns out to be an issue with the bge driver. This is an amd64 box,
dual processor (SMP kernel) that happens to be running nfsd. About every
3-5 days the kernel panics and I
On Mon, 8 Jan 2007, Sven Willenberger wrote:
On Mon, 2007-01-08 at 16:06 +1100, Bruce Evans wrote:
On Sun, 7 Jan 2007, Sven Willenberger wrote:
The short and dirty of the dump:
...
--- trap 0xc, rip = 0x801d5f17, rsp = 0xb371ab50, rbp =
0xb371aba0 ---
bge_rxeof
On Tue, 9 Jan 2007, John Baldwin wrote:
On Tuesday 09 January 2007 09:37, Sven Willenberger wrote:
On Tue, 2007-01-09 at 12:50 +1100, Bruce Evans wrote:
Oops. I should have asked for the statment in bge_rxeof().
#7 0x801d5f17 in bge_rxeof (sc=0x8836b000)
at /usr/src/sys
On Wed, 10 Jan 2007, Sven Willenberger wrote:
Bruce Evans presumably uttered the following on 01/09/07 21:42:
Also look at nearby chain entries (especially at (rxidx - 1) mod 512)).
I think the previous 255 entries and the rxidx one should be
non-NULL since we should have refilled them as we
On Wed, 23 Mar 2005, Vinod Kashyap wrote:
If any kernel module has the following, or a similar line in it:
-
char x[100] = {0};
-
I think you mean:
-
auto char x[100] = {0};
-
or after fixing some style bugs:
-
char x[100] = { 0 };
-
building of the GENERIC kernel
On Thu, 24 Mar 2005, Bruce Evans wrote:
On Wed, 23 Mar 2005, Vinod Kashyap wrote:
If any kernel module has the following, or a similar line in it:
-
char x[100] = {0};
-
building of the GENERIC kernel on FreeBSD 5 -STABLE for amd64
as of 03/19/05, fails with the following message
On Thu, 24 Mar 2005, Nick Barnes wrote:
At 2005-03-24 08:31:14+, Bruce Evans writes:
what is gcc to do when -fno-builtin tells it to turn off its
builtins and -ffreestanding tells it that the relevant interfaces
might not exist in the library?
Plainly, GCC should generate code which fills
On Fri, 25 Mar 2005, Peter Jeremy wrote:
On Thu, 2005-Mar-24 12:03:19 -0800, Vinod Kashyap wrote:
[ char x[100] = { 0 }; ]
A statement like this (auto and not static)
I'd point out that this is the first time that you've mentioned that
the variable is auto. Leaving out critical information will
On Mon, 23 May 2005, John-Mark Gurney wrote:
Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400:
We are running a PostgreSQL server (8.0.3) on a dual opteron system with
8G of RAM. If I interpret top and vfs.hibufspace correctly (which show
values of 215MB and 225771520
On Thu, 2 Feb 2006, O. Hartmann wrote:
O. Hartmann schrieb:
Hello.
I do not know whether this should be a bug report or not, I will ask prior
to any further action.
Reading 'man fpresetsticky' show up a man page for FPGETROUND(3) and tells
me the existence of the fpresetsticky routine.
On Thu, 2 Feb 2006, O. Hartmann wrote:
Bruce Evans schrieb:
On Thu, 2 Feb 2006, O. Hartmann wrote:
...
Now take a look into machine/ieeefp.h, where this function should be
declared. Nothing, I can not find this routine, it seems to be 'not
available' on my FreeBSD6.1-PRERELEASE AMD64
On Tue, 25 Sep 2007, LI Xin wrote:
I think this is a bug, here is a fix obtained from NetBSD.
This bug, if any, cannot be fixed in rm.
The reasoning (from NetBSD's rm.c,v 1.16):
Bugs can easily be added to rm.
Strip trailing slashes of operands in checkdot().
POSIX.2 requires that if .
On Wed, 24 Oct 2007, Oliver Fromme wrote:
Dmitry Marakasov [EMAIL PROTECTED] wrote:
I was told long time ago that -ounion is even
more broken than unionfs.
That's wrong. The union mount option was _never_ really
broken. I'm using it for almost as long as FreeBSD exists.
I recently
On Tue, 30 Oct 2007, Jack Vogel wrote:
Another bit of data, if I define DEVICE_POLLING on the Oct. snap it
also will work.
Defining DEVICE_POLLING (globally) breaks configuration of fast
interrupt handlers in em. I have to #undef it to test fast interrupt
handlers in em without losing
On Sat, 17 Nov 2007, Peter Jeremy wrote:
On Sat, Nov 17, 2007 at 04:53:22AM +1100, Bruce Evans wrote:
Behaviour like this should be expected on i386 but not on amd64. It
gives the well-known property of the sin() function, that sin(x) != sin(x)
for almost all x (!). It happens because
On Fri, 16 Nov 2007, Peter Jeremy wrote:
I've Cc'd bde@ because this relates to the FPU initialisation - which
he is the expert on.
On Thu, Nov 15, 2007 at 12:54:29PM +, Pete French wrote:
On Fri, Nov 02, 2007 at 10:04:48PM +, Pete French wrote:
int
main(int argc,
On Tue, 17 Feb 2009, Gary Jennejohn wrote:
I tested this with an Adaptec 29160. I saw no real improvement in
performance, but also no regressions.
I suspect that the old disk I had attached just didn't have enough
performance reserves to show an improvement.
My test scenario was buildworld.
On Wed, 3 Jun 2009, Kostik Belousov wrote:
On Wed, Jun 03, 2009 at 05:30:51PM +0300, Kostik Belousov wrote:
On Wed, Jun 03, 2009 at 04:10:34PM +0300, Vlad Galu wrote:
Hm, I was having an issue with an internal piece of software, but
never checked what kind of pipe caused the problem. Turns
On Mon, 17 Dec 2007, David G Lawrence wrote:
One more comment on my last email... The patch that I included is not
meant as a real fix - it is just a bandaid. The real problem appears to
be that a very large number of vnodes (all of them?) are getting synced
(i.e. calling ffs_syncvnode())
On Mon, 17 Dec 2007, David G Lawrence wrote:
While trying to diagnose a packet loss problem in a RELENG_6 snapshot
dated
November 8, 2007 it looks like I've stumbled across a broken driver or
kernel routine which stops interrupt processing long enough to severly
degrade network performance
On Mon, 17 Dec 2007, Mark Fullmer wrote:
Thanks. Have a kernel building now. It takes about a day of uptime after
reboot before I'll see the problem.
Yes run find / /dev/null to see the problem if it is the syncer one.
At least the syscall latency problem does seem to be this. Under ~5.2,
On Mon, 17 Dec 2007, Scott Long wrote:
Bruce Evans wrote:
On Mon, 17 Dec 2007, David G Lawrence wrote:
One more comment on my last email... The patch that I included is not
meant as a real fix - it is just a bandaid. The real problem appears to
be that a very large number of vnodes (all
On Tue, 18 Dec 2007, David G Lawrence wrote:
Thanks. Have a kernel building now. It takes about a day of uptime
after reboot before I'll see the problem.
You may also wish to try to get the problem to occur sooner after boot
on a non-patched system by doing a tar cf /dev/null / (note:
On Tue, 18 Dec 2007, David G Lawrence wrote:
I didn't say it caused any bogus disk I/O. My original problem
(after a day or two of uptime) was an occasional large scheduling delay
for a process that needed to process VoIP frames in real-time. It was
happening every 31 seconds and was causing
On Tue, 18 Dec 2007, David G Lawrence wrote:
I got an almost identical delay (with 64000 vnodes).
Now, 17ms isn't much.
Says you. On modern systems, trying to run a pseudo real-time application
on an otherwise quiescent system, 17ms is just short of an eternity. I agree
that the syncer
On Tue, 18 Dec 2007, Mark Fullmer wrote:
A little progress.
I have a machine with a KTR enabled kernel running.
Another machine is running David's ffs_vfsops.c's patch.
I left two other machines (GENERIC kernels) running the packet loss test
overnight. At ~ 32480 seconds of uptime the
On Wed, 19 Dec 2007, David G Lawrence wrote:
Debugging shows that the problem is like I said. The loop really does
take 125 ns per iteration. This time is actually not very much. The
Considering that the CPU clock cycle time is on the order of 300ps, I
would say 125ns to do a few checks
On Wed, 19 Dec 2007, David G Lawrence wrote:
Try it with find / -type f /dev/null to duplicate the problem almost
instantly.
FreeBSD used to have some code that would cause vnodes with no cached
pages to be recycled quickly (which would have made a simple find
ineffective without reading
On Thu, 20 Dec 2007, Bruce Evans wrote:
On Wed, 19 Dec 2007, David G Lawrence wrote:
Considering that the CPU clock cycle time is on the order of 300ps, I
would say 125ns to do a few checks is pathetic.
As I said, 125 nsec is a short time in this context. It is approximately
the time
On Wed, 19 Dec 2007, David G Lawrence wrote:
The patch should work fine. IIRC, it yields voluntarily so that other
things can run. I committed a similar hack for uiomove(). It was
It patches the bottom of the loop, which is only reached if the vnode
is dirty. So it will only help if
On Sat, 22 Dec 2007, Kostik Belousov wrote:
On Fri, Dec 21, 2007 at 05:43:09PM -0800, David Schwartz wrote:
I'm just an observer, and I may be confused, but it seems to me that this is
motion in the wrong direction (at least, it's not going to fix the actual
problem). As I understand the
On Sat, 22 Dec 2007, Kostik Belousov wrote:
On Sun, Dec 23, 2007 at 04:08:09AM +1100, Bruce Evans wrote:
On Sat, 22 Dec 2007, Kostik Belousov wrote:
Yes, rewriting the syncer is the right solution. It probably cannot be done
quickly enough. If the yield workaround provide mitigation for now
On Mon, 24 Dec 2007, Kostik Belousov wrote:
On Sun, Dec 23, 2007 at 10:20:31AM +1100, Bruce Evans wrote:
On Sat, 22 Dec 2007, Kostik Belousov wrote:
Ok, since you talked about this first :). I already made the following
patch, but did not published it since I still did not inspected all
On Sat, 22 Dec 2007, Mark Fullmer wrote:
On Dec 22, 2007, at 12:08 PM, Bruce Evans wrote:
I still don't understand the original problem, that the kernel is not
even preemptible enough for network interrupts to work (except in 5.2
where Giant breaks things). Perhaps I misread the problem
On Fri, 28 Dec 2007, Bruce Evans wrote:
In previous mail, you (Mark) wrote:
# With FreeBSD 4 I was able to run a UDP data collector with rtprio set,
# kern.ipc.maxsockbuf=2048, then use setsockopt() with SO_RCVBUF
# in the application. If packets were dropped they would show up
On Fri, 28 Dec 2007, Bruce Evans wrote:
On Fri, 28 Dec 2007, Bruce Evans wrote:
In previous mail, you (Mark) wrote:
# With FreeBSD 4 I was able to run a UDP data collector with rtprio set,
# kern.ipc.maxsockbuf=2048, then use setsockopt() with SO_RCVBUF
# in the application. If packets
On Thu, 29 Jan 2009, Brent Jones wrote:
On Wed, Jan 28, 2009 at 11:21 PM, Brent Jones br...@servuhome.net wrote:
...
The issue I am seeing, is that for certain file types, the FreeBSD NFS
client will either issue an ASYNC write, or an FSYNC.
However, NFSv3 and v4 both support safe ASYNC
On Thu, 17 Feb 2011, John Baldwin wrote:
On Thursday, February 17, 2011 7:18:28 am Steven Hartland wrote:
This has become a issue for us in 8.x as well.
I'm pretty sure in pre 8.x these nfs mounts would simply background but
recently machines are now failing to boot. It seems that failure to
On Wed, 14 Dec 2011, Ivan Klymenko wrote:
?? Wed, 14 Dec 2011 00:04:42 +0100
Jilles Tjoelker jil...@stack.nl ??:
On Tue, Dec 13, 2011 at 10:40:48AM +0200, Ivan Klymenko wrote:
If the algorithm ULE does not contain problems - it means the
problem has Core2Duo, or in a piece of code
On Fri, 24 Feb 2012, Desai, Kashyap wrote:
From: Alexander Kabaev [mailto:kab...@gmail.com]
...
sleep locks are by definition unbound. There is no spinning, no priority
propagation. Holders are free to take, say, page faults and go to long
journey to disk and back, etc.
I understood your
On Sat, 3 Mar 2018, tech-lists wrote:
On 03/03/2018 00:23, Dimitry Andric wrote:
Indeed. I have had the following for a few years now, due to USB drives
with ZFS pools:
--- /usr/src/etc/rc.d/zfs 2016-11-08 10:21:29.820131000 +0100
+++ /etc/rc.d/zfs 2016-11-08 12:49:52.971161000
47 matches
Mail list logo
