t
> this for me?
Hmm, I've had a CFP1080S (Antigua) for years, and never experienced
any trouble at all with it. It held my FreeBSD CVS repo mirror until I
got a new desktop last fall, so it's seen some pretty heavy activity
over the years.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTE
Cy Schubert - ITSD Open Systems Group <[EMAIL PROTECTED]> writes:
> In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav
> writes:
> > Hmm, I've had a CFP1080S (Antigua) for years, and never experienced
> > any trouble at all with it. [...]
> I've got th
slowdown to try to
narrow down the day (or even the week) on which it occurred?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ot; RAM, then touches every page during startup.
Unless some form of clustering is done, this causes 16384 write
operations for a 64 MB virtual machine...
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Jake Burkholder <[EMAIL PROTECTED]> writes:
> As I mentioned in the commit message, this changes the size and layout
> of struct kinfo_proc, so you'll have to recompile libkvm-using programs.
I thought the whole point with kinfo_proc was to avoid this kind of
situation...
D
Warner Losh <[EMAIL PROTECTED]> writes:
> Alternatively, the upgrade path must be fixed.
I don't see any way to do that. Everything on your system that isn't
statically linked will need to be recompiled unless the libc major
number is bumped.
DES
--
Dag-Erling Smorgrav - [EM
rks, I'll commit it.
Please. Let's not, and say we did.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
been
discussing possible solutions on IRC for the past two hours. Peter
will likely commit a patch sometime soon.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
; desire for that.
Yes, there is. Steal _cookie, rename it to _ext or something like
that, and make it point to a separate structure that contains _cookie
and the mutex. Optionally add a #define to avoid changing libc code
that uses _cookie. That's not what Peter intends to commit, though.
of more than 1.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
installworld.
No, it doesn't, because you bumped the libc major. Set it to 500 like
we discussedm, and commit (or I will, damnit).
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
st they'll have plenty of
time to rebuild their ports and stuff. For 6.0, we'd go straight from
5 to 600 or 601, then down to 6 right before 6.0-RELEASE, and nobody
would get screwed. You know it makes sense.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to
ocale support,
so Perl is spewing error messages about en_US.ISO_8859-1 not being
supported. Like Juliana Hatfield says: dumb, dumb, fun.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
at case, the initial "grab
copies of the binaries we need" phase in the installworld target could
be changed to "grab staticized copies of the binaries we need".
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscrib
en say
> libc.so.645 in 6.0?
Umm, I dunno, except that it'll look weird, but that's just a matter
of taste.
Of course, what we really need is "mandatory minor numbers", i.e.
minor numbers that are treated as "I need this version", not as "I
need this version o
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> When we back down to 5, we add magic to the Makefiles to move
> libc.so.5?? to /usr/lib/compat - that way they're only used when
> needed at runtime, not for linking new programs.
Umm, never mind this gross hack; as Peter poi
TABLE OR A PRE-FEB 10 -CURRENT TO A POST-FEB
10 -CURRENT UNTIL THIS IS RESOLVED. YOU HAVE BEEN WARNED.
Thank you for your attention. We now return you to our regularly
scheduled hacking.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
Donny Lee <[EMAIL PROTECTED]> writes:
> ===>ipfilter
> make: don't know how to make machine/lock.h Stop.
> *** Error code 2
Looks like a stale dependency file to me. Try 'make cleandir' twice,
followed by the usual 'make depend && make &&
can't see how this code can
try to jump to or call 0xd73bb600, so I assume it's stack smash job.
I'm getting tons of these crashes while doing various things - I even
had a panic while saving the core dump shown above!
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: sen
"David O'Brien" <[EMAIL PROTECTED]> writes:
> On Tue, Feb 13, 2001 at 05:18:04AM +0100, Dag-Erling Smorgrav wrote:
> > Donny Lee <[EMAIL PROTECTED]> writes:
> > > ===>ipfilter
> > > make: don't know how to make machine/lock.h S
make depend all install
^^
Wrong. It only accidentally works because you always use 'config -r'.
The correct command is 'make depend && make && make install'. If you
do 'make depend all', the dependency information generated by the
'depend' tar
Donny Lee <[EMAIL PROTECTED]> writes:
> Dag-Erling Smorgrav wrote:
> > > config -r mykernel
> > No point.
> -r removes objects generated by a previous kernel config, i guess.
Still no point. Unless your tree is hosed, make(1) takes care of that,
as long as yo
but pkg_install
> fails because the specific packages it expects to see are missing.
porteasy (/usr/ports/misc/porteasy) goes to great lengths to determine
the actual dependencies of a specific port. You might have better luck
trying to hack an update function into porteasy than using pkg_update
uldn't get cleaned out from the .h files, and it caused
> a problem somewhere.
Old-style options weren't placed in .h files, but passed on the
command line, so they broke the dependency system. Perhaps that is
what you are referring to?
DES
--
Dag-Erling Smorgrav - d...@flood.ping.u
fig information in one place, such as
/etc/rc.conf, would be a good thing.
YMMV.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
ne properly, but I don't agree with
the way they chose to solve some of the problems that arise when you
do that.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Kazutaka YOKOTA writes:
> What if we declare death to LKM screen savers and remove them from
> the source tree? After all KLD screen savers are working well.
Sure. I don't see any reason to keep them. I'll do the deed.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To U
Dag-Erling Smorgrav writes:
> Kazutaka YOKOTA writes:
> > What if we declare death to LKM screen savers and remove them from
> > the source tree? After all KLD screen savers are working well.
> Sure. I don't see any reason to keep them. I'll do the deed.
Doh, they
Mark Murray writes:
> Dag-Erling Smorgrav wrote:
> > Doh, they were already axed by sos in late December. 'cvs co src/lkm'
> > still creates directories for them though. I'm sure someone with more
> > CVS experience than me will be able to explain why :)
&g
at/
> /usr.sbin/xntpd/xntpd/
These are dynamically linked, and will automatically pick up the new
libkvm.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Brian Feldman writes:
> On 24 Jan 1999, Dag-Erling Smorgrav wrote:
> > [...]
> > These are statically linked, and must be relinked after libkvm has
> > been rebuilt.
> > [...]
> > These are dynamically linked, and will automatically pick up the new
> >
x should be enough. Ask Mike ;)
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
I have a very simple NIS configuration at home: niobe is the server
and luna, my scratch box, is the client. Niobe runs 4.0-CURRENT, and
luna runs 3.0-RELEASE until 'make world' finishes on niobe so I can
make installworld over NFS. In addition to being the NIS and NFS
server, niobe is also its own
Bill Paul writes:
> Of all the gin joints in all the towns in all the world, Dag-Erling
> Smorgrav had to walk into mine and say:
> > Luna, however, seems absolutely allergic to NIS. Everything is
> > configured correctly as far as I can see
> [chop]
>
> Sure, that&#x
Bill Paul writes:
> Of all the gin joints in all the towns in all the world, Dag-Erling
> Smorgrav had to walk into mine and say:
> > Yes to most of the above. Tcpdump does not work on PLIP links, and I
> > do not use IP aliases at all.
> Explain to me how you concluded that
the plip code still causes regular panics. I haven't caught a
dump yet because my dump device was misconfigured, but I've had at
least two plip-related panics on an otherwise perfectly stable system
in the last two weeks. I'll send a backtrace as soon as I have one.
DES
--
Dag-Erlin
[moved to -hackers]
Peter Jeremy writes:
> Dag-Erling Smorgrav wrote:
> > Tcpdump does not work on PLIP links,
> Check out http://www.freebsd.org/cgi/query-pr.cgi?pr=7241
> This includes fixes for PLIP in lpt.c, but the code in ppbus/if_plip.c
> looks virtually the same. No
know what it is? Does the driver actually work? Is there a good
reason (or any reason at all) why we shouldn't just bobbit it?
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
any credibility as a workstation OS, we
need DHCP. It should be possible for a user or admin to smack in the
boot floppy, have it autoconfigure the selected network interface, and
perform an FTP installation.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majo
Steve Kargl writes:
> Dag-Erling Smorgrav wrote:
> > I stumbled upon the (undocumented) gpib driver today [...]
> Actually, John Galbraith has written
> a better driver for the National Instrument GPIB cards. Search
> the hardware mailing list for a URL to his latest driver.
Steve Kargl writes:
> Dag-Erling Smorgrav wrote:
> > If we want FreeBSD to have any credibility as a workstation OS, we
> > need DHCP. It should be possible for a user or admin to smack in the
> > boot floppy, have it autoconfigure the selected network interface, a
, you'd know the cause of this
breakage, and why it wasn't fixed until three hours ago.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Matthew Dillon writes:
> union mounts are broken. I must have panic'd my test box 50 times
> trying to get them to work.
Nonono. The union filesystem ('mount -t union') is broken. Union
mounts ('mount -o union') are not.
DES
--
Dag-Erling Smorgr
who's stopping you?
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
7;s stopping you from committing the driver", not "who's
stopping you from committing the driver to 2.2". I too think 2.2
should be left to die in peace.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
ne about practically anything we do, on the assumption that
they know better, even though they never do any work of their own.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Steve Kargl writes:
> Dag-Erling Smorgrav wrote:
> > Steve isn't even a committer. He's one of those oh-so-many people who
> > love to whine about practically anything we do, on the assumption that
> > they know better, even though they never do any work of their ow
s on ppbus, see the man pages.
BE ADVISED that the nlpt driver will soon be renamed to lpt.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
to it tho... Thanks!
That's because we're too busy making 3.1 happen 8)
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Nicolas Souchu writes:
> controllerppbus0 # The ppbus system
> devicenlpt0 at ppbus? # The printer driver
OBTW, when are you planning to rename nlpt0 to lpt0?
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to
fix loose ends.
The alternative is to just update GENERIC, LINT et al to use ppbus
instead of the old lpt driver, and throw in a warning in the probe
messages in src/sys/i386/lpt.c telling people to move to ppbus. It
should be pretty safe.
DES
--
Dag-Erling Smorgrav - d...@flood.ping
le of said make world).
> Shouldn't a make world take about 10 hours on a P100 ?? -depends on
> the speed of your disks.
More like five or six. But he wasn't saying his make world took ten
minutes, he was saying it died after ten minutes.
DES
--
Dag-Erling Smorgrav - d...@flood.p
, the result is a panic (whereas with a kernel without invariants,
the bug might actually go unnoticed).
You must be thinking of the FAILSAFE option.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-curre
rease data safety, which I find
difficult to understand.
The only possible value an end user could derive from a kernel with
invariants is a backtrace to attach to a send-pr.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
n the kernel. David Greenman
committed a patch to better support large memory configurations.
Unfortunately, it seems this was not possible to achieve without
breaking BSDI compatibility.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with
"Daniel O'Connor" writes:
> On 17-Mar-99 Dag-Erling Smorgrav wrote:
> > The bug is on the web site, not in the kernel. David Greenman
> > committed a patch to better support large memory configurations.
> > Unfortunately, it seems this was not possible t
lems, or is it just a matter of ps
and top not working?
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
"David O'Brien" writes:
> The core files from the panic seem to be useless -- I can't get anything
> useful out of ``where'' with a kernel w/debugging symbols:
Link CD9660 support statically, instead of using the KLD module.
DES
--
Dag-Erling Smorgrav - d..
Leif Neland writes:
> Will frontpage (fp30.bsdi3.tar.Z) run on current 4.0?
Only if your kernel is configured for a 256 MB address space. See
section 13.15 in the FAQ for instructions on how to do this.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to maj
out libraries - the re-compiled aout libraries
> seem to be missing a symbol).
I run an Elf build of Emacs 19.34b daily on a completely Elf, very
up-to-date 4.0-CURRENT box with Elf XFree86 3.3.3.1. No trouble at all.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail
kernel pages
> (kernel is pageable these days IIRC, at least the data if not the code).
It's not, as far as I know.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
k. New users will get DES
passwords.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
Alexander Leidinger <[EMAIL PROTECTED]> writes:
> Dag-Erling, any ideas?
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/46628
Fixed a couple of minutes ago.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-c
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
Alexander Leidinger <[EMAIL PROTECTED]> writes:
> Just tested with a world from yesterday: it doesn't segfault anymore,
> but there's no ssh-agent running.
Harrumph. Did you try reverting pam_ssh.c?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send ma
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
restore's temporary files, but a) I've never seen this before, and b)
isn't -L supposed to prevent just that?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
' doesn't really exist
pkg_delete: file '/usr/local/share/doc/lcms/iccjpeg.c' doesn't really exist
pkg_delete: file '/usr/local/share/doc/lcms/icctrans.c' doesn't really exist
pkg_delete: file '/usr/local/share/doc/lcms/jpegicc.c' doesn't really exist
pkg_delete: file '/usr/local/share/doc/lcms/tifficc.c' doesn't really exist
pkg_delete: file '/usr/local/share/doc/lcms/wtpt.c' doesn't really exist
pkg_delete: file '/usr/local/share/doc/lcms' doesn't really exist
pkg_delete: unable to completely remove directory '/usr/local/share/doc/lcms'
pkg_delete: couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)
[now it worked, so the trace is useless]
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
301 - 400 of 1156 matches
Mail list logo
