In message 199905302213.raa05...@home.dragondata.com Kevin Day writes:
: 1) The kernel config options are only documented in LINT, which really isn't
: meant for that sorta thing, and I'll admit, they're not documented well.
: (contrast linux's config where you can hit ? and get a few paragraphs
In message
14162.35022.502546.522...@r84aap011262.sbo-smr.ma.cable.rcn.com
Robert Huff writes:
: How often _do_ people rebuild their kernels? (On non-testing
: machines.)
On my stable machines never, or very rarely. I have machines in my
basement that tend to have 200-500 day uptimes
In message 19990601190941.46f9f29...@localhost.localdomain Christian Murray
writes:
: I have some problems with m3socks and cvsup.
I've never been able to make this work. You might try -P m and adding
a netcat redirector or 10 on your gateway machine.
Warner
To Unsubscribe: send mail to
In message
pine.gso.3.96.990603101914.28480a-100...@sol.cs.binghamton.edu
Zhihui Zhang writes:
: The value of MAXPHYS is chosen to be 64K for the maximum raw I/O transfer
: size. I am wondering why it is not set larger.
I don't think that it is possible to guarantee that you can do a
larger
On Tue, Jun 08, 1999 at 12:24:36AM -0600, Warner Losh wrote:
In message 19990601190941.46f9f29...@localhost.localdomain Christian Murray
writes:
: I have some problems with m3socks and cvsup.
I've never been able to make this work. You might try -P m and adding
a netcat redirector or 10
In message 19990603231216.a36...@hal.mpn.cp.philips.com Jos Backus writes:
: On Thu, Jun 03, 1999 at 07:30:20PM +0200, Wilko Bulte wrote:
: 20 bits. But older cards can do no more than 64 kB.
:
: Indeed, 20 bits (=1 Mbyte) for the address, 16 bits for the transfer counter
: (offset).
Isn't that
In message 19990608084217.a5...@alaska.cert.siemens.de Udo Schweigert writes:
: I'm using it (runsocks cvsup -P m) for a year now and it works without
: any problems. (Since cvsup 16 the -P m is not needed, so runsocks cvsup
: should so it).
Oddd. I can't get mine to work. I always get a
On Tue, Jun 08, 1999 at 12:53:54AM -0600, Warner Losh wrote:
Isn't that 24 bits for addresses? You can dma from an ISA card to
anywhere in the first 16M...
Arrgh, yes, I'm terribly confused. Sorry 'bout that.
--
Jos Backus _/ _/_/_/ Reliability means never
I seem to have killed my 2.NIC. Both probe and init as usual, and can read
from the net (trafshow) but can't transmit.
I removed both from the pc, without removing the netcable. (Trying to
resolve an IRQ-conflict)
Is this a bad-thing (tm) ?
If something went broke from this, I would expect it to
On Tue, Jun 08, 1999 at 01:36:21AM -0600, Warner Losh wrote:
In message 19990608084217.a5...@alaska.cert.siemens.de Udo Schweigert
writes:
: I'm using it (runsocks cvsup -P m) for a year now and it works without
: any problems. (Since cvsup 16 the -P m is not needed, so runsocks cvsup
:
I believe the DMA chip itself provides 20 bits, and external circuitry
extends the remaining 4 bits.
Chuck Youse
Director of Systems
cyo...@cybersites.com
-Original Message-
From: Warner Losh i...@harmony.village.org
To: Jos Backus jos.bac...@nl.origin-it.com
Cc: Wilko Bulte
Strange.
I'm having a wierd time trying to get a package called Swish++ working.
It's a C++/STL based program, which the author recommends compiling up
with Gcc2.8 or higher.
So... I've installed gcc-2.8.1 glibstdc++-2.8.1.1, and compiled it
up. Strangely however, the 'search' part of it core
Dag-Erling Smorgrav wrote:
No, I don't think there's much point in doing that before Kirk
McKusick removes the restrictions on the soft updates code. When that
happens, we can make soft updates non-optional and turn on soft
updates on all file systems by default.
I hope *that* doesn't
Strange.
I'm having a wierd time trying to get a package called Swish++ working.
It's a C++/STL based program, which the author recommends compiling up
with Gcc2.8 or higher.
So... I've installed gcc-2.8.1 glibstdc++-2.8.1.1, and compiled it
up. Strangely however, the 'search' part
On Tue, Jun 08, 1999 at 10:45:39AM -0400, Thomas David Rivers wrote:
(gdb) bt
#0 0x8052c0f in ostream::flush () at /usr/include/ctype.h:149
#1 0x8052912 in ostream::operator () at /usr/include/ctype.h:149
#2 0x804995f in main (argc=1, argv=0xbfbfdb54) at search.c:219
(gdb) l
Or
On Tue, Jun 08, 1999 at 10:45:39AM -0400, Thomas David Rivers wrote:
(gdb) bt
#0 0x8052c0f in ostream::flush () at /usr/include/ctype.h:149
#1 0x8052912 in ostream::operator () at /usr/include/ctype.h:149
#2 0x804995f in main (argc=1, argv=0xbfbfdb54) at search.c:219
(gdb) l
On Tue, Jun 08, 1999 at 12:03:03PM -0400, Thomas David Rivers wrote:
Program received signal SIGSEGV, Segmentation fault.
0x8052c0f in ostream::flush () at /usr/include/ctype.h:149
149 }
Is it because the program's compiled using the wrong includes?
As Jos Backus wrote ...
On Tue, Jun 08, 1999 at 12:53:54AM -0600, Warner Losh wrote:
Isn't that 24 bits for addresses? You can dma from an ISA card to
anywhere in the first 16M...
Arrgh, yes, I'm terribly confused. Sorry 'bout that.
Be happy, you're not alone ;-)
| / o / / _
In message 19990608120755.a92...@alaska.cert.siemens.de Udo Schweigert writes:
: Is your cvsup linked dynamic? If not, runsocks wont work.
No. That's the problem...
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
I've edited the makefile in the portes, and the source, to install
xcircuit 2.0a10 rather than 1.7 (1.7 can't open its own files, it
seems).
the old patch-aa was
*** Imakefile.orig Thu Mar 12 12:22:41 1998
--- Imakefile Sun May 17 15:52:05 1998
***
*** 31,37
#
The machine is a SMP 3.0-RELEASE box.
A heavily threaded program is segfaulting in the longjmp() function.
Any ideas what would cause this?
Regards,
Dan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
The machine is a SMP 3.0-RELEASE box.
A heavily threaded program is segfaulting in the longjmp() function.
Any ideas what would cause this?
Regards,
Dan
You could have trashed your jmp_buf... (i.e. you're passing bad data
to longjmp().)
Just a thought...
- Dave
Dan Moschuk wrote:
The machine is a SMP 3.0-RELEASE box.
A heavily threaded program is segfaulting in the longjmp() function.
Any ideas what would cause this?
A bug in the thread exit code. This was fixed at the 13th hour during
the release of 3.2.
--
John Birrell - j...@cimlogic.com.au;
Dan Moschuk wrote:
The machine is a SMP 3.0-RELEASE box.
A heavily threaded program is segfaulting in the longjmp() function.
Any ideas what would cause this?
Libc_r or Linuxthreads?
There are some known problems WRT signal handling in libc_r. I
think they've been mostly fixed (with
On Tue, 8 Jun 1999, Richard E. Hawkins wrote:
I've edited the makefile in the portes, and the source, to install
xcircuit 2.0a10 rather than 1.7 (1.7 can't open its own files, it
seems).
See the section in the handbook on porting. These kinds of questions are
better sent to freebsd-ports
On Tue, Jun 08, 1999 at 12:03:03PM -0400, Thomas David Rivers wrote:
Program received signal SIGSEGV, Segmentation fault.
0x8052c0f in ostream::flush () at /usr/include/ctype.h:149
149 }
Is it because the program's compiled using the wrong includes?
26 matches
Mail list logo
