Hi, I noticed that IPFW as a built in kernel options quietly doesn't
seem to work,
no compile errors, but the resultant kernel passes evrything and does
not appear
to contain ipfw funtionality.
ipfw -a l returns
ipfw: getsockopt(IP_FW_GET): Protocol not available.
kldload ipfw and it all works
As stated. The Makefile calls for perl5, which is not available at that
time. Replacing perl5 by perl solves the problem.
Cheers,
PYD
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
:On Sat, Apr 17, 1999 at 12:38:25PM -0700, Annelise Anderson wrote:
:
: I think it was, thanks. I changed the order of the nameservers
: in resolv.conf and it no longer happens. :)
:
:What about setting up a caching DNS server on your machine ?
:You could configure forwarders.
:
:options {
:
On Sat, 17 Apr 1999, Alex Zepeda wrote:
I'm as excited as anyone to see progress, especially if it means the
ability to modularize the kernel and load various drivers on demand. But,
alas, it seems this whole thing was rushed horribly.
The first thing I noticed was the panic I got, in
On Sat, 17 Apr 1999, Alex Zepeda wrote:
I'm as excited as anyone to see progress, especially if it means the
ability to modularize the kernel and load various drivers on demand. But,
alas, it seems this whole thing was rushed horribly.
The first thing I noticed was the panic I got, in
I'm as excited as anyone to see progress, especially if it means the
ability to modularize the kernel and load various drivers on demand. But,
alas, it seems this whole thing was rushed horribly.
Not at all, it's simply something which will require some time to work
out the details of in
I had to try this due to an unfortunate 'accident', and no, it currently does
not work. The aout assembler complains about a '.section' tag in the assembly
output of contrib/gcc/cp/tinfo2.cc.
You have to elfify your system with a non-egcs compiler before you can move
onto using egcs to make the
On Sun, Apr 18, 1999 at 12:26:15AM -0700, Matthew Dillon wrote:
Setting a forwarders chain sucks, because named doesn't do the right thing
with it -- even if you have multiple entries, if the first one is
unreachable it will create a significant delay for nearly all your
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same. Looking with vmstat -i and
systat -vmstat, there
Motomichi Matsuzaki wrote:
The 'mandatory + recommended' object size is no more than 5 kbytes.
The GENERIC kernel does not require necessarily
the euc-jp support or any other charsets.
I think the iso8859-1 support alone is sufficient for GENERIC.
The custom kernels can have the euc-jp
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same. Looking with vmstat -i and
4.0-current
=== sys/modules/fdesc
@ - /usr/src/sys
machine - /usr/src/sys/i386/include
sh /usr/src/sys/modules/fdesc/../../kern/vnode_if.sh
/usr/src/sys/modules/fdesc/../../kern/vnode_if.src
cc -nostdinc -O -pipe -DFDESC -DKERNEL -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes
On Sun, 18 Apr 1999, Gianmarco Giovannelli wrote:
4.0-current
...
perl5: not found
*** Error code 1
I cvsuped about one hour ago, but the problem was there from before...
Fixed.
--
Doug Rabson Mail: d...@nlsystems.com
Nonlinear Systems Ltd.
Doug Rabson wrote:
I'm not sure about pnp but this patch should fix the overflows (not
tested):
Seems to work fine for me (I had the sio overflow problems too).
Index: sio.c
===
RCS file: /home/ncvs/src/sys/isa/sio.c,v
Let us not forget that much of the newconfig work can be used with
newconfig shims in the newbus scheme.
Probably some simple drivers for newconfig works with newconfig
shims, but bus code that depends on newconfig may not work.
I don't go to new-bus, this direction is disunion of BSDs. It is
On 1999-04-16 00:54:32 -0600, Warner Losh wrote:
Does make aout-to-elf still purport to work from a 2.2.8R system to
a recent (like today's) current?
I updated my laptop 4 weeks ago from 2.2.6R to 4.0-current.
There where only minor problems, see PR bin/10784 and bin/10785
--
Wolfram
I don't go to new-bus, this direction is disunion of BSDs. It is
bad decision.
I'm sorry that you feel this way, but I can only re-state that better
communication could have prevented this in the first place and hope
that you've learned your own lessons from this exercise. If you
haven't, then
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same. Looking with vmstat
On Sun, 18 Apr 1999, John Hay wrote:
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel
On Sun, 18 Apr 1999, Jordan K. Hubbard wrote:
I'm as excited as anyone to see progress, especially if it means the
ability to modularize the kernel and load various drivers on demand. But,
alas, it seems this whole thing was rushed horribly.
Not at all, it's simply something which will
The first thing I noticed was the panic I got, in atkbd_isa_intr, which
has since been fixed.
Well, that is what you have to expect when running current. You are a
betatester, and you can't expect the authors to have access to every
combination of hardware.
Well that's my point.
Alex Zepeda wrote:
Which means that it perhaps should be worked out before being merged. Take
for instance CAM. It didn't work perfectly, but it sure got a lot more
exposure than newbus, and when it was integrated it caused very few
problems.
I think CAM is a very bad example. We *still*
On Mon, 19 Apr 1999, Daniel C. Sobral wrote:
I think CAM is a very bad example. We *still* don't have all the
drivers we had, and that includes at least one reasonably requested
driver.
Is that an offer to write the missing drivers?
On the other hand, I don't see we losing anything with
Which means that it perhaps should be worked out before being merged. Take
for instance CAM. It didn't work perfectly, but it sure got a lot more
exposure than newbus, and when it was integrated it caused very few
problems.
The two systems aren't equivalent so it's not really correct to make
And then what about newconfig? To me this just adds more truth to the
whole /. argument that *BSD promotes a closed development model.
I think your perceptions are fundamentally flawed here, it's just that
simple. You can argue the point all you like in -current, but it
won't change that fact
I'm currently working on a driver for the Lucent WaveLAN/IEEE 802.11
PCMCIA adapter, as part of a project for the COMET lab people here
at Columbia. Lucent has a PCMCIA and an ISA version of this adapter,
however the ISA version is really just a PCMCIA card fitted into an
add-in PCMCIA controller
Alex Zepeda wrote:
On Mon, 19 Apr 1999, Daniel C. Sobral wrote:
I think CAM is a very bad example. We *still* don't have all the
drivers we had, and that includes at least one reasonably requested
driver.
Is that an offer to write the missing drivers?
Is that sidetracking the
On Sun, 18 Apr 1999, Bill Paul wrote:
I'm currently working on a driver for the Lucent WaveLAN/IEEE 802.11
PCMCIA adapter, as part of a project for the COMET lab people here
at Columbia. Lucent has a PCMCIA and an ISA version of this adapter,
however the ISA version is really just a PCMCIA
Since everybody's slagging new-bus right now, I thought I'd just jump
in and say that as of 10 minutes ago, having made the world and a new
kernel, everything's working great. NOTE: Look at GENERIC! Things
have changed and you will likely need to update your old config file
before everything is
Why would I say it wasn't ready? Because outside of core (apparently),
nobody was warned/told that this was going to be committed in a few
days/hours/minutes.
The USB code has been using newbus for over 4 months now. And up to now
we've had only one bug to fix. The rest was feature requests.
I would ask people to STOP DOING THIS. Do not harass or ridicule
someone for not being fluent in english! Now, it is sorely true
that someone wil
Let me just reinforce this statement.
This is wonderful, but has this ever happened in our mailing lists? I
guess I don't
On ISA only machine,
w/o controller pci0at nexus?
in kernel config, after make depend:
In file included from ../../i386/i386/nexus.c:74:
../../pci/pcivar.h:192: pci_if.h: No such file or
directory
In file included from
../../i386/i386/userconfig.c:132:
../../pci/pcivar.h:192: pci_if.h:
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same. Looking with vmstat -i and
: that someone wil
:
: Let me just reinforce this statement.
:
:This is wonderful, but has this ever happened in our mailing lists? I
:guess I don't remember anyone *ever* ridiculing or harassing someone for
:not being fluent in the language.
:
:Nate
Oh sure, it happens quite often.
Jordan K. Hubbard wrote:
Since everybody's slagging new-bus right now, I thought I'd just jump
in and say that as of 10 minutes ago, having made the world and a new
kernel, everything's working great. NOTE: Look at GENERIC! Things
have changed and you will likely need to update your old
Mark Murray wrote:
John Hay wrote:
As of a few minutes ago, a minimal set of changes to bring the so-called
'new-bus' functionality to the i386 kernel in -current.
It looks like the stat clock isn't started after this. I have tried a SMP
and UNI kernel and both behave the same.
Peter Wemm wrote:
Known bogon... In between putting out fires (here), I hope to take a
further shot at cleaning up the interrupt layering shortly.
... as I saw 3 messages later.
I wasn't too worried about that, I didn't think the world would end if the
labels fell off the irq table, so I
In message pine.bsf.3.96.990418205350.3261e-100...@heidi.plazza.it, Nick Hibm
a wrote:
Why would I say it wasn't ready? Because outside of core (apparently),
nobody was warned/told that this was going to be committed in a few
days/hours/minutes.
I've ported the newconfig style USB code of
Hello,
Has anyone been successful getting pccard services to run on this laptop?
I enabled the card controller and rebuilt the kernel, enable pccard
services in rc.conf, but when I run pccardc dumpcis I get 0 slots
found.
I have a feeling the pcmcia controller isn't being recognized. Can
Hi,
I ave found one more thing that seems to be broken. I have used the
irq autodetect feature of the ed(4) for a long time, but it seems
that the newbus compatability shim is not doing the right thing
with it. My kernel config file have a line like this:
device ed0 at isa? port 0x280 net irq ?
Guess I should mention this is 3.1-RELEASE.
-- Forwarded message --
Date: Sun, 18 Apr 1999 16:37:55 -0400 (EDT)
From: T.D. Brace t...@stargate.org
To: freebsd-current@FreeBSD.ORG
Subject: compaq presario 1675 pccard
Hello,
Has anyone been successful getting pccard services to
I'm running current as of April 6th and whenever I try to multi-volume tar
directly to my parallel port zip drive using /dev/da0 it hangs when it gets to
the end of the zip. I don't think it's a hardware problem because I've seen
it happen on 2 completely separate machines.
To Unsubscribe: send
On Sun, 18 Apr 1999, T.D. Brace wrote:
Guess I should mention this is 3.1-RELEASE.
-- Forwarded message --
Date: Sun, 18 Apr 1999 16:37:55 -0400 (EDT)
From: T.D. Brace t...@stargate.org
To: freebsd-current@FreeBSD.ORG
Subject: compaq presario 1675 pccard
Hello,
On Sun, 18 Apr 1999, Jordan K. Hubbard wrote:
Since everybody's slagging new-bus right now, I thought I'd just jump
in and say that as of 10 minutes ago, having made the world and a new
kernel, everything's working great. NOTE: Look at GENERIC! Things
have changed and you will likely need
Valentin Shopov wrote:
On ISA only machine,
w/o controller pci0at nexus?
in kernel config, after make depend:
In file included from ../../i386/i386/nexus.c:74:
../../pci/pcivar.h:192: pci_if.h: No such file or
directory
In file included from
../../i386/i386/userconfig.c:132:
Hello,
A better place to ask this question would be over on freebsd-mobile.
The whole list is nothing but portables.
Can anyone tell me if I can get freebsd 3.1 running on a compaq
pressario 1675 - I'm worried about the pcmcia controller being
recognized (and my xircom re-100btx working).
On Sun, 18 Apr 1999, Alex Zepeda wrote:
On Mon, 19 Apr 1999, Daniel C. Sobral wrote:
I think CAM is a very bad example. We *still* don't have all the
drivers we had, and that includes at least one reasonably requested
driver.
Is that an offer to write the missing drivers?
On the
On Sun, 18 Apr 1999, Brian Feldman wrote:
I saw this and just had to note something to you. THINK what branch you
are using. This is _WHERE_ things are being aired publically, and merged
eventually to the STABLE branch.
Gosh, thank you, without your wonderful help and understanding, I NEVER
On Sun, 18 Apr 1999, Smelly Pooh wrote:
I'm running current as of April 6th and whenever I try to multi-volume tar
directly to my parallel port zip drive using /dev/da0 it hangs when it gets to
the end of the zip. I don't think it's a hardware problem because I've seen
it happen on 2
On Sun, 18 Apr 1999, Alex Zepeda wrote:
On Sun, 18 Apr 1999, Brian Feldman wrote:
I saw this and just had to note something to you. THINK what branch you
are using. This is _WHERE_ things are being aired publically, and merged
eventually to the STABLE branch.
Gosh, thank you, without
NFS patch #5 is now available for -current. I believe I have fixed all
the bugs for NFSV3 over UDP, but I need people to help test it.
http://www.backplane.com/FreeBSD4/
This patch also includes general B_VMIO caching for directories ( ufs, nfs,
anyone ), which DG may
In message 19990416083544.a10...@timog.prestel.co.uk Timo Geusch writes:
: You have to elfify your system with a non-egcs compiler before you can move
: onto using egcs to make the world.
Yes. I discovered this the hard way... I did an upgrade to
3.1-stable with a make aout-to-elf and then to
In message 199904181923.naa25...@mt.sri.com Nate Williams writes:
: This is wonderful, but has this ever happened in our mailing lists? I
: guess I don't remember anyone *ever* ridiculing or harassing someone for
: not being fluent in the language.
I have seen people ask others to explain again
In message pine.bsf.4.05.9904181854010.85882-100...@herring.nlsystems.com
Doug Rabson writes:
: I think it works as well it did before but I haven't personally tested it.
I have personally tested my new ata-flash support as well as my 3C589D
card, both with a PC-Card Vadem 365 based ISA on my
On Sun, Apr 18, 1999 at 05:20:44PM -0400, Chuck Robey wrote:
This new-bus stuff is absolutely great, and I hope Doug, Peter, and
everyone else involved doesn't hear the criticism only. You guys are
doing fine work.
Hear Hear!
A painless switch here too (nothing unusual about the box).
--
55 matches
Mail list logo
