you'll need to make sure all the modules build with -DXEN, which isn't
something someone has done or can tell you for sure method for it.
probably just setting DBG=-O2 -DXEN is most likely.
you'll also need to rebild your kernel with this line changed:
sys/arch/amd64/include/pmap.h:#define
On Mon, Nov 19, 2012 at 05:23:07AM +, David Holland wrote:
Also, it obviously needs to be possible to open files O_RDONLY|O_EXEC
for O_EXEC to be useful, and open directories O_RDONLY|O_SEARCH, and
so forth. I don't know what POSIX may have been thinking when they
tried to forbid this but
On Mon, Nov 19, 2012 at 05:23:07AM +, David Holland wrote:
On Sun, Nov 18, 2012 at 06:51:51PM +, David Holland wrote:
This appears to contradict either the description of O_EXEC in the
standard, or the standard's rationale for adding fexecve(). The
standard says
On Mon, Nov 19, 2012 at 08:08:58AM +, Emmanuel Dreyfus wrote:
On Mon, Nov 19, 2012 at 05:23:07AM +, David Holland wrote:
Also, it obviously needs to be possible to open files O_RDONLY|O_EXEC
for O_EXEC to be useful, and open directories O_RDONLY|O_SEARCH, and
so forth. I don't know
If you don't have read rights you can open with O_EXEC instead, and
you can't read the file you just opened; it merely provides a
mechanism to pointlessly use fexecve.
I disagree that it's pointless.
You can still check that, for example, it's the same dev/inumber/size
you have recorded in a
On Wed, Oct 31, 2012 at 05:42:12PM +0100, Edgar Fuß wrote:
Invoke crash(8), then just perform ps and t/a address on each LWP
which seems to be stuck (on tstile or elsewhere).
So it seems I can sort of lock up the machine for minutes with a simple
dd if=/dev/zero of=/dev/dk14 bs=64k
Regarding (A), there seems to be no single difference explaining the whole
performance degradation, so I tried to test intermediate steps.
Was anyone able to confirm this or obtain better performance on a different
SAS controller?
It looks like my only option is trying a an MPT-II controller.
On Mon, Nov 19, 2012 at 12:31:47PM +0100, Edgar Fuß wrote:
The problem is that this lock-up, artificial as the dd to the block device
may seem, appears to happen real-world during an svn update command: the
other nfsd threads get stuck to the point where other clients get nfs server
not
Why do you think both lockups are related?
Because the real world problem also involves large amounts of metadata being
written and also results in nfsd's stuck in tstile.
Should I try to get crash(8) outputs of the real world situation?
On Mon, Nov 19, 2012 at 12:59:13PM +0100, Edgar Fuß wrote:
Should I try to get crash(8) outputs of the real world situation?
I guess that would be good - even if only to verify this is related or
not.
Martin
Hi all,
during review of the EVFILT_PROC fix by dsl@, we found that the current
argument mangling breaks if the system uses PIDs larger than 64k. While
this is unlikely on many systems, it can be certainly be triggered.
Attached is a patch that separates events and additional data.
I would like to
On Mon, 19 Nov 2012 08:38:11 +
David Laight da...@l8s.co.uk wrote:
On Mon, Nov 19, 2012 at 08:08:58AM +, Emmanuel Dreyfus wrote:
If you have r-x permission, you open with O_RDONLY and you do not
need O_SEARCH/O_EXEC.
If you have --x permission, you open with O_SEARCH/O_EXEC
On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
No, Emmanuel is right: [...] use the O_EXEC flag when opening fd. In
this case, the application will not be able to perform a checksum test
since it will not be able to read the contents of the file. You can
open with --x but
OK, this is the svn process (directly running on the file server, not operating
via NFS) tstile-ing:
crash ps | grep \(vnode\|tstile\)
250511 3 0 0 fe82ec17d200svn tstile
crash t/a fe82ec17d200
trace: pid 25051 lid 1 at 0xfe811e901700
sleepq_block() at
On Mon, Nov 19, 2012 at 03:13:02PM +, Emmanuel Dreyfus wrote:
On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
No, Emmanuel is right: [...] use the O_EXEC flag when opening fd. In
this case, the application will not be able to perform a checksum test
since it will not be able
On Nov 19, 2012, at 4:53 PM, Edgar Fuß e...@math.uni-bonn.de wrote:
OK, this is the svn process (directly running on the file server, not
operating
via NFS) tstile-ing:
crash ps | grep \(vnode\|tstile\)
250511 3 0 0 fe82ec17d200svn tstile
crash t/a
Do you get a deadlock
No.
will the system come back to work after some time?
Yes. At least for appropriate values of some time.
This may take minutes (at least in the dd case, I haven't seen this in the
svn case).
On Nov 19, 2012, at 6:40 PM, Edgar Fuß e...@math.uni-bonn.de wrote:
Do you get a deadlock
No.
will the system come back to work after some time?
Yes. At least for appropriate values of some time.
This may take minutes (at least in the dd case, I haven't seen this in the
svn case).
Try
On Mon, Nov 19, 2012 at 11:25:07AM -0500, Thor Lancelot Simon wrote:
On Mon, Nov 19, 2012 at 03:13:02PM +, Emmanuel Dreyfus wrote:
On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
No, Emmanuel is right: [...] use the O_EXEC flag when opening fd. In
this case, the
David Laight da...@l8s.co.uk wrote:
Given the comments later about O_SEARCH | O_RDONLY not being distinguishable
from O_SEARCH
The satandard forbids O_SEARCH | O_RDONLY anyway, so it should not be a
problem.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On Apr 11, 9:48am, Emmanuel Dreyfus wrote:
} On Mon, Nov 19, 2012 at 02:39:36PM +, Julian Yon wrote:
} No, Emmanuel is right: [...] use the O_EXEC flag when opening fd. In
} this case, the application will not be able to perform a checksum test
} since it will not be able to read the
On Wed, 14 Nov 2012, Iain Hibbert wrote:
On Wed, 14 Nov 2012, Iain Hibbert wrote:
On Mon, 12 Nov 2012, Iain Hibbert wrote:
On Fri, 9 Nov 2012, Thor Lancelot Simon wrote:
On Sat, Nov 10, 2012 at 12:39:59AM +0700, Robert Elz wrote:
How?
And if that's something
hello. I'm sure the problem is caused by a hardware error or firmware
bug. However, when one drive fails, the entire controller currently goes
to lunch, or it can. The FreeBSD driver deals with this by keeping a kernel
thread going which watches for commands which have been put into the
23 matches
Mail list logo
