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 N
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 b
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
> > > > standa
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
> 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
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
> 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
>
> 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 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 (co
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()
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
On Nov 19, 2012, at 4:53 PM, Edgar Fuß 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 fe82ec17d
> 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ß 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 running `sv
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 a
David Laight 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 co
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?
> > > > >
>
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
