(FWIW, Theo claims his changes are only enforcing POSIX.)
--- Peter Jeremy [EMAIL PROTECTED] wrote:
...
Does OpenBSD support any JIT JVM?
Hmmm... no, looks like they run our (or the linux) JVM under emulation.
If perl didn't break, I think Java will survive too.
Emacs and perl both
In a message written on Sun, Aug 31, 2003 at 12:06:28AM +0100, Pedro F. Giffuni wrote:
Well, we only have a JIT JVM for the i386, and on the particular case of the
i386 we cannot enforce full protection anyways so there is probably a
workaround if we do need it.
I'm not sure I want to suggest
I have a GF4 MX440 Video card in 5.1_Release running KDE3.1.3 that keeps
either locking up or putting vertical red/blue lines on the screen.
Is there any way to manually refresh or repage the memory to see if that helps
stop the problem? maybe a cron script?
any ideas? did the same with 4.8
Hi,
I was wondering how to retreive data from the kernel if I wanna. I want TCP
option(if any) to let the application know about that. Can u please tell me if
there is any way that I can do it without adding any additional code. If I
need to add it sould you please tell me the easiest way to do
Whilst the Java bytecode is not natively executable, a JIT JVM needs to be able
towrite and immediately execute native code. The OpenBSD W^X approach would
require system calls between the compilation and execution steps. My understanding
of current JIT is that the compilation is done is
On Sat, 30 Aug 2003, Stone Gecko wrote:
I have a GF4 MX440 Video card in 5.1_Release running KDE3.1.3 that keeps
either locking up or putting vertical red/blue lines on the screen.
Are you by any chance running the binary drivers provided by nvidia with
this card? I have exactly the same card,
Ugh... or just consider not all equipment out there needs JIT Java, and make it
a kernel option!
cheers,
Pedro.
--- Andrew Lankford [EMAIL PROTECTED] wrote: Whilst the Java bytecode is
not natively executable, a JIT JVM needs to be
able towrite and immediately execute native code. The
Hi,
I noticed that initstate() caused memory corruption on
FreeBSD/sparc64. I guess this is because lib/libc/stdlib/random.c
assumes long is 32-bit long.
The attached patch works fine on my box, but this is a bit ugly.
Could anyone take care of this?
--
| Hiroki SATO [EMAIL PROTECTED]
I'm actually only running the nvidia drivers that were embedded in BSD...
haven't installed the ones from nvidia's site yet
On August 30, 2003 07:47 pm, you wrote:
On Sat, 30 Aug 2003, Stone Gecko wrote:
I have a GF4 MX440 Video card in 5.1_Release running KDE3.1.3 that keeps
either locking
Tim Kientzle [EMAIL PROTECTED] wrote:
The OpenBSD work on tightening up read/write/exec memory permissions
looks interesting, but I wonder what impact it has on
JIT technologies; do the current Java VMs or other incremental
compilation engines require write+exec?
You can disable W^X for
Just noticed that the patch to usbd.c I proposed yesterday shows an
undesirable behaviour. That is, usbd executes the actions in
usbd.conf of all matching devices, which is not exactly what I meant
to do. In fact, usbd should execute for every device name the best
matching action in usbd.conf.
Ok, today I spent some time deciphering the ums log and came up
with this patch.
--- /sys/dev/usb/ums.c Wed Nov 6 21:23:50 2002
+++ ums.c Sun Aug 31 15:08:52 2003
@@ -428,10 +428,8 @@
}
ibuf = sc-sc_ibuf;
- if (sc-sc_iid) {
- if (*ibuf++ != sc-sc_iid)
On Sun, Aug 31, 2003 at 12:06:28AM +0100, Pedro F. Giffuni wrote:
Emacs and perl both use traditional bytecode interpreters, as does the
Classic JVM. I agree they will be unaffected. This change will only
impact JIT JVMs.
Well, we only have a JIT JVM for the i386, and on the particular case
Walter C. Pelissero writes:
Ok, today I spent some time deciphering the ums log and came up
with this patch.
deletia
Unfortunately my knowledge (or rather lack of it) of the USB/UMS
driver doesn't give me very much confidence that I didn't break
something else.
What was
On Sun, Aug 31, 2003 at 04:36:40PM +0400, Buckie wrote:
KJK The next step for Windows would to be able to deal with new hardware
KJK without doing an installation from scratch. The next step for FreeBSD
KJK would to be able to replace the motherboard without shutting down the
KJK machine. :-)
Dear All,
I'd like to thank you guys for the great work. FreeBSD is getting better
with every release.
A few weeks ago I replaced my motherboard with something marginally
faster (from a 650MHz Athlon to a 1800+ one, a really minor upgrade).
FreeBSD accepted the change without even blinking its
Hi. I have been experencing some filesystem problems
for the last month or so. I was running 4.8-STABLE and
updated to 5.1-RELEASE-p2. While I was running 4.8
and I tried to run a command that required hard disk
activity, the process would 'hang' and I would no
longer be able to ssh or telnet in.
KJK The next step for Windows would to be able to deal with new hardware
KJK without doing an installation from scratch. The next step for FreeBSD
KJK would to be able to replace the motherboard without shutting down the
KJK machine. :-)
Yeah... a hot-pluggable (swappable) motherboard! Kewl.
On Sat, 30 Aug 2003 21:55:06 -0400
Sandeep Kumar Davu [EMAIL PROTECTED] wrote:
I was wondering how to retreive data from the kernel if I wanna. I
want TCP option(if any) to let the application know about that. Can u
please tell me if there is any way that I can do it without adding any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 30 Aug 2003 21:55:06 -0400 Sandeep Kumar Davu [EMAIL PROTECTED] wrote:
Hi,
I was wondering how to retreive data from the kernel if I wanna. I want TCP
option(if any) to let the application know about that. Can u please tell me if
there
Good Evening,
I've been looking at writing a program that uses both shared libraries
(dlopen/dlclose) and POSIX threads. I however haven't had any success in my
simple tests.
After doing some research via google I found that due to -shared pthreads
wasn't linked into the shared library, fair
On Sun, Aug 31, 2003 at 08:13:03PM +0100 or thereabouts, Peter Wood wrote:
Good Evening,
I've been looking at writing a program that uses both shared libraries
(dlopen/dlclose) and POSIX threads. I however haven't had any success in my
simple tests.
After doing some research via google I
--- Peter Jeremy [EMAIL PROTECTED] wrote:
...
Based on some recent BUGTRAQ postings, OpenBSD has a trick to support
full protection on the i386. The text segment and executable part of
shared libraries are placed at low virtual addresses and CS is
restricted to only cover the low address
23 matches
Mail list logo
