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 th
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
In message
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 write than 64k on a aha-1542 card given the worst case scatter
gath
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 maj
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 be
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 article <86r9nn8nzl@hamhae.wdb.co.kr>
c...@wdb.co.kr writes:
>> It means that I should update my messages.ko_KR translation after last
>> translation? And, what is the meaning, "almost okay"?
Sorry, I added many message ID's yesterday.
The new message.lt_EN can be found in the translation
> Hello,
>
> I'm having a trouble programming a special login shell, and would like
> to hear any opinions on this.
>
> I want this shell (which automatically becomes a session leader) to
> release its ctty but remain unterminated (the ctty must be taken by its
> child). However, there seems to
Hi,
I too see this type of failure until I can download the appropriate
distfiles into /usr/ports/distfiles...
The file /etc/resolv.conf is copied from /etc to the chroot
area and is probably ok. I typically find that my upstream
domain name server is not responding correctly when this hap
> "HT" == HOSOKAWA Tatsumi writes:
HT> Now, the Current Translation Status is:
HT> ---
HT> JapaneseKorean
HT> ---
I am using FreeBSD-3.1-RELEASE
I met panic.
Panic occured at FIONREAD ioctl().
I found it was called at rdchk() at rbsb.c in lrzsz 0.12.16 packages.
Before panic, there was kernel warning message
--- "b_to_q to a clist with no reserved cblocks".
Is it related ?
Following is gdb output for core du
you might look to see if 'screen' (in ports)
has something that does this when it disconnects from a session.
(just an idea)
julian
On Mon, 7 Jun 1999, Eugene M. Kim wrote:
> Hello,
>
> I'm having a trouble programming a special login shell, and would like
> to hear any opinions on this.
>
>
Hello,
I'm having a trouble programming a special login shell, and would like
to hear any opinions on this.
I want this shell (which automatically becomes a session leader) to
release its ctty but remain unterminated (the ctty must be taken by its
child). However, there seems to be no easy way t
On Mon, 7 Jun 1999 18:38:51 -0400 (EDT), Brian Feldman
wrote:
: On Mon, 7 Jun 1999, Matthew Dillon wrote:
: > ... what version of the operating system?
: 4.0-CURRENT
3.2R too...
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the mess
I don't know why it's there, but that seems to be the sysctl tree.
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.freebsd.org _ |___)___/_
On Mon, 7 Jun 1999, Matthew Dillon wrote:
> ... what version of the operating system?
>
> -Matt
4.0-CURRENT
>
> : In the long-standing tradition of deadlocks, I present to you all a new
> one.
> :This one locks in getblk, and causes other pro
On Mon, 7 Jun 1999, Zhihui Zhang wrote:
>
> While studying the file ufs_readwrite.c, I see routines like uiomoveco()
> that calls vm_uiomove() in vm_map.c. I am almost sure that these are new
> in FreeBSD 3.x. The comment in ffs_read() says "not a VM based I/O
> requests" == "not headed for t
The 'netiso' and 'netccitt' trees are still included in NetBSD.
- ad
On Mon, 7 Jun 1999, Alfred Perlstein wrote:
> -- Forwarded message --
> Date: Mon, 07 Jun 1999 15:23:57 -0400
> From: Spud Taylor
> To: freebsd-questi...@freebsd.org
> Subject: netiso tree
>
> We have been usi
... what version of the operating system?
-Matt
: In the long-standing tradition of deadlocks, I present to you all a new one.
:This one locks in getblk, and causes other processes to lock in inode. It's
:easy to induce, but I have no idea how
Alfred Perlstein scribbled this message on Jun 7:
> -- Forwarded message --
> Date: Mon, 07 Jun 1999 15:23:57 -0400
> From: Spud Taylor
> To: freebsd-questi...@freebsd.org
> Subject: netiso tree
>
> We have been using Free BSD and BSDI since 1992. There was a descision
> to elimi
-Alfred
-- Forwarded message --
Date: Mon, 07 Jun 1999 15:23:57 -0400
From: Spud Taylor
To: freebsd-questi...@freebsd.org
Subject: netiso tree
We have been using Free BSD and BSDI since 1992. There was a descision
to eliminate the netiso and netccitt trees in the OS a few yea
It seems Chris D. Faulhaber wrote:
>
> I have an off-brand (NEC) Zip Drive with:
>
> which does have buggy firmware; I also have another one with:
>
> that has no problem when I remove the 64 block limitation.
>
> In this case, I would use strncmp instead of strcmp to test the first 2
> On Mon, 7 Jun 1999, Mike Smith wrote:
>
> > > 12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be.
> > > Since the current method of sorting out the revisions doesn't seem to
> > > be perfect, would it be acceptible to consider them all buggy unless known
> > > not to be (i.e
Christoph Kukulies writes:
Comments from someone who's studied Linux for a while and has started
studying FreeBSD only recently.
> Could one say that Linux vs. FreeBSD kernels are conceptually
> different what task scheduling, queueing, interrupt handling,
> driver architecture, buffer caching,
On Mon, 7 Jun 1999, Mike Smith wrote:
> > 12.A, 21.*, and 23.* are known to be buggy...13.A doesn't appear to be.
> > Since the current method of sorting out the revisions doesn't seem to
> > be perfect, would it be acceptible to consider them all buggy unless known
> > not to be (i.e. compare ap
> On Tue, 8 Jun 1999, Junichi Satoh wrote:
>
> > Hmm...
> >
> > I have an ATAPI ZIP drive:
> >
> > wdc0: unit 1 (atapi): , removable, intr,
> > iordis
> > wfd1: medium type unknown (no disk)
> > wfd1: buggy Zip drive, 64-bl
While studying the file ufs_readwrite.c, I see routines like uiomoveco()
that calls vm_uiomove() in vm_map.c. I am almost sure that these are new
in FreeBSD 3.x. The comment in ffs_read() says "not a VM based I/O
requests" == "not headed for the buffer cache". This does not make sense
to me alt
Of all the gin joints in all the towns in all the world, Anthony Bourov
had to walk into mine and say:
> Hi,
>
> I am running a FreeBSD server, and I am running into this problem very
> often. The machine stops responding and instead outputs 1000s of
> xl0: no memory for rx list -- packet dropp
Hi,
anybody here knows what is it about ?
/usr/home/ilia/test-hpf > hpf hello.f90
Pacific-Sierra Research VAST-HPF V5.1C 23:17:54 6/ 7/99 HPF
programhello
/home/ilia/fortran-cd/vast/vhpf_linux/lib//libvhpf_pvm.a(envnproc.o): In
function `envnproc
In article <199906071600.baa09...@afs.ntc.mita.keio.ac.jp>
hosok...@itc.keio.ac.jp writes:
>> Currently, following binary package is compiled with English, Japanese
>> and Korean support. As a result of increased size of boot.flp,
>> Japanese and Korean support is now merged again into the same b
Hi,
I am running a FreeBSD server, and I am running into this problem very
often. The machine stops responding and instead outputs 1000s of
xl0: no memory for rx list -- packet dropped!
xl0: no memory for rx list -- packet dropped!
xl0: no memory for rx list -- packet dropped!
xl0: no memory fo
Yes, quite.
> -Original Message-
> From: Christoph Kukulies [SMTP:k...@gilberto.physik.rwth-aachen.de]
> Sent: Monday, June 07, 1999 10:59 AM
> To: hack...@freebsd.org
> Subject: linux and freebsd kernels conceptually different?
>
> Could one say that Linux vs. FreeBSD kernels are
Here is a patch that checks for the revision numbers instead of simply the
inquiry string (and adds my buggy revision):
--- wfd.c.orig Thu Feb 18 17:06:08 1999
+++ wfd.c Mon Jun 7 12:02:25 1999
@@ -243,17 +243,21 @@
return -1;
/*
-* The IOMEGA ZIP 100, at f
In <199906060553.oaa24...@afs.ntc.mita.keio.ac.jp> I wrote,
>> Thank you. Now I'm working on updated sysinstall messages.
>> I'll send the URL of message.lt_EN, *.TXT, *.hlp files to translate
>> when I finished this work.
>> I want translators to other languages.
I finished updating indices
Could one say that Linux vs. FreeBSD kernels are conceptually
different what task scheduling, queueing, interrupt handling,
driver architecture, buffer caching, vm etc. is concerned?
--
Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de
To Unsubscribe: send mail to majord...@freebsd.
Quoting Dag-Erling Smorgrav (d...@flood.ping.uio.no):
> Kazutaka YOKOTA writes:
> > >su-2.02# config BANTU
> > >BANTU:135: unknown option "VM86"
> > >Unknown option used - it is VERY important that you do
> > > make clean && make depend
> > >before recompiling
> > >
On Mon, Jun 7, 1999, Christoph Kukulies wrote:
> What is the status of the EGCS compiler WRT kernel build?
> (And world build in general?)
It's been working great for ages in -CURRENT. I don't know
how it may handle in -STABLE, though.
--
Chris Costello
It sai
What is the status of the EGCS compiler WRT kernel build?
(And world build in general?)
--
Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
On Tue, 8 Jun 1999, Junichi Satoh wrote:
> Hmm...
>
> I have an ATAPI ZIP drive:
>
> wdc0: unit 1 (atapi): , removable, intr,
> iordis
> wfd1: medium type unknown (no disk)
> wfd1: buggy Zip drive, 64-block transfer limit s
Kazutaka YOKOTA writes:
> >su-2.02# config BANTU
> >BANTU:135: unknown option "VM86"
> >Unknown option used - it is VERY important that you do
> > make clean && make depend
> > before recompiling
> > Kernel build directory is ../../compile/BANTU
>
> Umm, this mea
>> My thoughts now are:
>> 1) My two drive are somewhat 'rogue' in that they don't conform to the
>> driver's expectations.
>> 2) When the driver was written, the '!strcmp' should be 'strcmp' since
>> strcmp returns 0 when equal (-1 or 1 when < or >), in which case my patch
>> makes sense:
>>
>>
>> Are you sure you enabled "options VM86" in the kernel configuration
>> file and loaded the vesa module by the boot loader?
>Hmmm ...
>When I added "options VM86" to my kernel config file I get:
>
>su-2.02# config BANTU
>BANTU:135: unknown option "VM86"
>Unknown option used - it is VERY importan
Quoting Kazutaka YOKOTA (yok...@zodiac.mech.utsunomiya-u.ac.jp):
[snip, snip]
> Are you sure you enabled "options VM86" in the kernel configuration
> file and loaded the vesa module by the boot loader?
Hmmm ...
When I added "options VM86" to my kernel config file I get:
su-2.02# config BANTU
BANT
I am using FreeBSD-3.1-RELEASE
I met panic.
Panic occured at FIONREAD ioctl().
I found it was called at rdchk() at rbsb.c in lrzsz 0.12.16 packages.
Before panic, there was kernel warning message
--- "b_to_q to a clist with no reserved cblocks".
Is it related ?
Following is gdb output for core du
Hello,
I got the following kernel messages. Does anybody know what
caused this messages? Is this the first sign of upcoming problems?
Jun 5 21:05:01 mail /kernel: 128 v_inactive_target R *Handler Int
Jun 5 21:05:01 mail /kernel: 129 v_inactive_count R *Handler Int
Jun 5 21:05:01 mail /kernel
Brian Feldman said:
> In the long-standing tradition of deadlocks, I present to you all a new one.
> This one locks in getblk, and causes other processes to lock in inode. It's
> easy to induce, but I have no idea how I'd go about fixing it myself
> (being very new to that part of the kernel.)
>
>
> One of the problems that would make it sensible to do a complete rewrite
> of vfs_bio.c is this?
>
Specifically for that reason, probably not. However, if the effort
was taken as an entire and encompassing effort, with the understanding
of what is really happening in the code regarding policy
On Thu, 3 Jun 1999, Jake Burkholder wrote:
> I spent most of the day recompiling X and what not.
> All the patches applied cleanly, there are some rejects with MESA,
> but I think that has to do with tags and comments at the beginning of
> files.
>
> Everything compiled fine, and the module load
One of the problems that would make it sensible to do a complete rewrite
of vfs_bio.c is this?
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.freebs
49 matches
Mail list logo
