"Daniel C. Sobral" wrote:
>
> > I have no idea why this change was made - it breaks FORTH compatibility.
> > I can't find anything in ficl.sourceforge.net (except that someone has
> > helpfully stripped all the CR's off ficl205.tar before it was gzip'd -
> > which upsets tar quite a bit).
John S
Salvo Bartolotta wrote:
>
> [ resending, with a subject ]
>
> > OK, I;ve looked and looked and can't seem to figure out how to set
> hw.ata.wc to enabled. I've put and a few other things in
> /etc/sysctl.conf, the others get set, hw.ata.wc doesn't. You can't
> change it by hand either as sysctl
Peter Jeremy wrote:
>
> For anyone who writes their own FORTH in the loader scripts:
>
> ficl 2.05 (imported on 28th April by dcs) changes `base' from an
> lvalue to an rvalue. This will break any code that currently
> uses base. In particular, code to temporarily change the base
> will corrup
For anyone who writes their own FORTH in the loader scripts:
ficl 2.05 (imported on 28th April by dcs) changes `base' from an
lvalue to an rvalue. This will break any code that currently
uses base. In particular, code to temporarily change the base
will corrupt low memory. For example:
cvsup'd 5-9-2001 around 0600 PST
You must be tired of hearing about things that are broken, so
I thought I'd let you know things went well.
Running i686 (single), ide/dma66 x two disks, no isa cards, no scsi,
two ethernet cards, softupdates, devfs. A very basic box.
And ssh 2.9 seems OK as wel
On Wed, 09 May 2001 09:21:09 -0700 (PDT),
John Baldwin <[EMAIL PROTECTED]> said:
>> Now the problem is whether it is easy or difficult to free a file
>> descriptor with holding a process lock. At the level of the file
>> descriptor layer, we can convert the memory allocator of a file
>> descrip
On Wed, 9 May 2001 13:33:54 -0700 (PDT),
Matt Dillon <[EMAIL PROTECTED]> said:
Matt> * The process's descriptor table
Matt> * The struct file's referenced by that descriptor table
Those are in my TODO list, and I have already started working on them.
--
Seigo Tanimura <[EMAIL PROTECT
[ -stable dropped from cc list ]
John Baldwin <[EMAIL PROTECTED]> writes:
>
> On 09-May-01 Robert Watson wrote:
> >
> > On Tue, 8 May 2001, John Baldwin wrote:
> >
> >> That's easy enough. Well, it used to be at least. You can use 'ps' to
> >> find the address of the struct proc (first point
< said:
> I followed everything here fine until you asserted that the debugger
> shouldn't need any locks.
When the debugger is running, everything else should have been
forcibly halted.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body o
There are several issues here:
* The process's descriptor table
* The struct file's referenced by that descriptor table
* The object underlying a struct file.
A process's descriptor table is not protected by the proc lock, because
the descriptor table can be shared acros
On Wed, 9 May 2001, John Baldwin wrote:
> I am more worried about the fact that you can deadlock the debugger.
> What does the debugger do if another process hold the proc lock on the
> process you want to kill? Cute, eh? The debugger is an extra special
> environment. Most of the time you've
On 3 Mai, An: [EMAIL PROTECTED] wrote:
> Hi,
>
> /sys from cvsup around 2pm CEST from cvsup3.de.freebsd.org (contains
> npx.c fix).
CVSUP from May 7, ~1pm CEST.
I made some progress. As you see in my last message I have parts of the
kernel loaded as modules. The mfs module was responsible for
On 09-May-01 Seigo Tanimura wrote:
> On Tue, 08 May 2001 08:21:55 -0700 (PDT),
> John Baldwin <[EMAIL PROTECTED]> said:
>
> John> On 08-May-01 Seigo Tanimura wrote:
>
>>> Here is another issue. PROC_LOCK may block to acquire a process lock,
>>> during which an event of interest may occur or t
On 09-May-01 Robert Watson wrote:
>
> On Tue, 8 May 2001, John Baldwin wrote:
>
>> That's easy enough. Well, it used to be at least. You can use 'ps' to
>> find the address of the struct proc (first pointer in the display) and
>> then do 'call psignal(addr, 9)' to send SIGKILL to the process.
On Tue, 08 May 2001 08:21:55 -0700 (PDT),
John Baldwin <[EMAIL PROTECTED]> said:
John> On 08-May-01 Seigo Tanimura wrote:
>> Here is another issue. PROC_LOCK may block to acquire a process lock,
>> during which an event of interest may occur or the remaining time of
>> select(2)/poll(2) may ru
On Wed, 09 May 2001 19:20:07 +0900,
Seigo Tanimura said:
Seigo> That does not, however, necessarily imply that we can scan file
Seigo> descriptors with holding a process lock. Another process can release a
Seigo> reference to a file descriptor via closef() during polling the
Seigo> descriptor
There's a strange interaction between su, pam znd zsh.
If you su to an account that has zsh as its shell and then hit ctrl-c it
will kill the shell that you invoked su from.
If you recompile su with -DNOPAM then the problems go away and this doesn't
seem to happen with any other shells either.
> On Mon, 7 May 2001 10:18:38 -0700
> [EMAIL PROTECTED] wrote:
> > Lets try another realistic example:
> >
> > cp -uvp ab* cde*.f* g? h/*.i? j/kl /m
> > What's the find | cpio invocation for that? When you come up with it, it
>
> echo ab* cde*.f* g? h/*.i? j/kl /m | cpio ...
>
>
18 matches
Mail list logo
