Richard Wackerbarth wrote:
>
> On Tue, 25 Apr 2000, Kris Kennaway wrote:
> > On Tue, 25 Apr 2000, Richard Wackerbarth wrote:
> > > Actually, I didn't start this. Someone else brought up the idea.
> >
> > ...and quickly decided it was not worthwhile.
>
> Yes, the developers do a good job of repre
On Wed, 26 Apr 2000, Greg Lehey wrote:
> Even that didn't work for me. BTW, the fix had the side effect of
> making the clock stand still. I've changed the code (spltty instead
The gdb code apparently assumes that the kernel debugger runs entirely
with interrupts disabled (as is required for t
On Wednesday, 5 April 2000 at 11:43:52 -0700, Matthew Dillon wrote:
>
>>
>>> Also, as a general note to everyone, make sure you are building vinum
>>> into the kernel directly and not using it as a kld, just to ensure that
>>> it stays in sync with the kernel.
>>
>> Isn't this
oops, I forgot all about that, thanks. :-)
=
| Kenneth Culver | FreeBSD: The best OS around.|
| Unix Systems Administrator | ICQ #: 24767726 |
| and student at The | AIM: muythaibxr
The RCS info stored in the binaries is insufficient for this purpose. There is
no record of the versions of all included files. Changes to constants and/or
macros would not be identifiable.
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
>
> On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
>
On Tue, 25 Apr 2000, Richard Wackerbarth wrote:
> On Tue, 25 Apr 2000, you wrote:
>
> > I told myself I wouldn't get into this debate with you again, Richard, but
> > you're not listening. The vast majority (all? I might have missed one) of
> > the other respondants
>
> Actually, I didn't start
On Tue, 25 Apr 2000, Kris Kennaway wrote:
>You've never run ident(1), right? :)
Very cool! No I hadn't. I was working with the assumption that it was
probably possible, but I know very little about how RCS actually works.
I just know that it does work and that's always been enough for me to
us
Hello,
On Tue, Apr 25, 2000 at 09:14:57PM -0400, Kenneth Wayne Culver wrote:
> As of about Thursday, Apr 20 I get this message when I try to run linux
> ldconfig:
>
> Segmentation fault(core dumped)
>
> I recompiled the module and the kernel on this day so I think that's what
> cause the proble
On Tue, Apr 25, 2000 at 09:14:57PM -0400, Kenneth Wayne Culver wrote:
> As of about Thursday, Apr 20 I get this message when I try to run linux
> ldconfig:
>
> Segmentation fault(core dumped)
>
> I recompiled the module and the kernel on this day so I think that's what
> cause the problem, but I
On Tuesday, 25 April 2000 at 9:39:10 +0100, Doug Rabson wrote:
> On Tue, 25 Apr 2000, Greg Lehey wrote:
>
>> On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote:
>>> On Sun, 23 Apr 2000, Greg Lehey wrote:
>>>
In the last few days, my remote serial gdb has almost completely
sto
On Tue, 25 Apr 2000, Jake Burkholder wrote:
> Has anyone thought about using kobj(9) for this?
>
> For example, it should be possible to make simple_lock and lockmgr locks
> safe for use from modules by introducing a lock_if.h, which has
> abstract version of all the lock routines. A class woul
Dear FreeBSD'ers,
Although I had been reading negative news, I went ahead ruthlessly and
I upgraded one of my 4.0-S slices to 5-CURRENT. My attempt was
successful.
For the record, I had cvsup'ed -CURRENT on 25 April at about 9 GMT.
However,I found a couple of curious things:
1) Albeit I had r
As of about Thursday, Apr 20 I get this message when I try to run linux
ldconfig:
Segmentation fault(core dumped)
I recompiled the module and the kernel on this day so I think that's what
cause the problem, but I was wondering if there was anyone else having
this problem. This started last thurs
On Tuesday, 25 April 2000 at 18:09:00 +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Andrzej
>Bialecki writes:
>> On Tue, 25 Apr 2000, Poul-Henning Kamp wrote:
>>
>>>
>>> ===
>>> SUMMARY
>>> ===
>>
>> [27kB long li
> On a similar note: I think one of serious drawbacks of FreeBSD's model
> for
> updating and bugfixing the stable branch is 'make world'. It's very
> inefficient and cumbersome way to do this on production machines.
> STABLE
> is stable enough for us to be able to prepare binary patches, w
On Tue, 25 Apr 2000, Matthew Hunt wrote:
> Maintaining a CVS repository is necessary only if you are working
> on the code, so your proposal would only affect devlopers, not Joe
> User. Normal users do not maintain copies of the repository and do
> not have a frequent need to examine history. T
On Tue, 25 Apr 2000, Jordan K. Hubbard wrote:
> > And if I put up, will you (the organization) use it? It's certainly too
> > much work to prove the obvious. I don't have to convince myself of
> > anything. The only value accrues if it gets used.
>
> Erm, haven't we been here with you before? I c
On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
> The only way something like this is feasible is if the binaries
> themselves contain information about what version they are. In other
> words some sort of a header in the binary which contains the RCS version
> number the binary was compiled fr
> And if I put up, will you (the organization) use it? It's certainly too much
> work to prove the obvious. I don't have to convince myself of anything.
> The only value accrues if it gets used.
Erm, haven't we been here with you before? I can even replay the
script from heart:
1. Richard come
On Tue, Apr 25, 2000 at 09:02:34PM +, attila! wrote:
> in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd
> was not in the cvs files.
xntpd is obsolete. It has been replaced with ntpd.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
To Unsubscribe
On Tue, 25 Apr 2000, attila! wrote:
> in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd
> was not in the cvs files.
>
> too a copy from a 3.1 disk; same version 3.4e. --it works.
usr.sbin/ntpd (NTP 4.0.99b) replaced xntpd 3.x last December...
Guy
Guy Helmer, Ph.D. Candida
On Tue, Apr 25, 2000 at 09:02:34PM +, attila! wrote:
> in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd
> was not in the cvs files.
It was replaced with ntpd some time ago wasn't it?
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-c
On Tue, 25 Apr 2000, Matthew Hunt wrote:
> Maintaining a CVS repository is necessary only if you are working
> on the code,
I disagree. Anyone who attempts to run "-current" on a regular basis
needs the recent history to cobble together a working system.
It is also very helpful if you are a "te
in 5.0-CURRENT as of this morning (Tue, 25) usr.sbin/xntpd
was not in the cvs files.
too a copy from a 3.1 disk; same version 3.4e. --it works.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, 25 Apr 2000, Wilko Bulte wrote:
>OK. But you do have to uniquely identify the binary that needs to be
>patched. So, my question is when you generate 10x the same binary, will all
>these 10 binaries have the same MD5 checksum? In other words: if people did
>a local buildworld once on a -re
On Tue, Apr 25, 2000 at 03:30:27PM -0500, Richard Wackerbarth wrote:
> Yes, the developers do a good job of repressing opinions that differ from
> their own.
It should be noted that the person who brought this up was a developer.
--
Will Andrews <[EMAIL PROTECTED]>
GCS/E/S @d- s+:+>+:- a--->++
On Tue, 25 Apr 2000, Jake Burkholder wrote:
> > On Tue, 25 Apr 2000, Boris Popov wrote:
> >
> > > simple_lock* functions has breakage too. They defined as macros
> > > for non-SMP case and as functions for SMP.
> >
> > This currently apparently affects the following modules:
> >
> > ccd
On Tue, Apr 25, 2000 at 03:30:27PM -0500, Richard Wackerbarth wrote:
> And if I put up, will you (the organization) use it? It's certainly too much
I cannot remember anybody ever having a guarantee that their submission
will be incorporated into FreeBSD, code-unseen. That's not how it works.
On Tue, 25 Apr 2000, Richard Wackerbarth wrote:
> Yes, the developers do a good job of repressing opinions that differ from
> their own.
Thats an interesting revision of the plain facts.
> And if I put up, will you (the organization) use it? It's certainly too much
> work to prove the obvious
On Tue, Apr 25, 2000 at 03:10:53PM -0500, Richard Wackerbarth wrote:
> The quiet majority that might benefit are not very likely to speak up when
> they are told some is impossible. After all, they are at the mercy of the
> very developers who oppose change because it does not directly benefit
>
On Tue, 25 Apr 2000, Kris Kennaway wrote:
> On Tue, 25 Apr 2000, Richard Wackerbarth wrote:
> > Actually, I didn't start this. Someone else brought up the idea.
>
> ...and quickly decided it was not worthwhile.
Yes, the developers do a good job of repressing opinions that differ from
their own.
> > No-one needs to grab a repository, unless they're looking at history.
> > Just use CVSup to grab the latest bits, no need to grab the entire
> > history.
>
> I find it virtually impossible to work with anything but the most stable
> without the recent part of the repository because I often h
On Tue, 25 Apr 2000, Kris Kennaway wrote:
> On Tue, 25 Apr 2000, Wilko Bulte wrote:
> > OK. But you do have to uniquely identify the binary that needs to be
> > patched. So, my question is when you generate 10x the same binary, will
> > all these 10 binaries have the same MD5 checksum? In other wo
On Tue, 25 Apr 2000, Richard Wackerbarth wrote:
> Actually, I didn't start this. Someone else brought up the idea.
...and quickly decided it was not worthwhile.
> The quiet majority that might benefit are not very likely to speak up when
> they are told some is impossible. After all, they are a
On Tue, 25 Apr 2000, you wrote:
> I told myself I wouldn't get into this debate with you again, Richard, but
> you're not listening. The vast majority (all? I might have missed one) of
> the other respondants
Actually, I didn't start this. Someone else brought up the idea.
> P.S. Please don't t
In message <[EMAIL PROTECTED]>, Brian Somers writes:
>> ===
>> SUMMARY
>> ===
>> World
>> compiled
>> 637 Warnings
>> 45 Errors
>> Kernel LINT
>> compiled
>> 149 Warnings
>> 0 Errors
>> Kernel GENERIC
>>
On Tue, 25 Apr 2000, Richard Wackerbarth wrote:
> Actually, it isn't. it can be automated rather easily based on parsing the
> CVS tags and using RCS primitives.
>
> The hard part is to get developers like yourself to recognize that they could
> refer to a CD for the old parts to the history a
> ===
> SUMMARY
> ===
> World
> compiled
> 637 Warnings
> 45 Errors
> Kernel LINT
> compiled
> 149 Warnings
> 0 Errors
> Kernel GENERIC
> compiled
> 59 Warnings
> 0 Errors
> Kernel
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> OK. But you do have to uniquely identify the binary that needs to be
> patched. So, my question is when you generate 10x the same binary, will all
> these 10 binaries have the same MD5 checksum? In other words: if people did
> a local buildworld once on a
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> In other words: if people did
> a local buildworld once on a -release sourcetree will all the executables
> have the same MD5 as the ones on the -release cdrom?
If you are using someone's patches, you must be patching the files that they
provided. If yo
< said:
> I love binary answers :-) Which brings me to my original point: it looks
> like you can only do binary patches relative to a -release. Unless
> you want to blindly patch and hope for the best. Rather unlikely.
I think you are right. Doing so would still require resolving the
full depe
On Tue, Apr 25, 2000 at 02:50:46PM -0400, Garrett Wollman wrote:
> < said:
>
> > In other words: if people did a local buildworld once on a -release
> > sourcetree will all the executables have the same MD5 as the ones on
> > the -release cdrom?
>
> No.
I love binary answers :-) Which brings me
< said:
> In other words: if people did a local buildworld once on a -release
> sourcetree will all the executables have the same MD5 as the ones on
> the -release cdrom?
No.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the messa
On Tue, Apr 25, 2000 at 05:54:20PM +0200, Andrzej Bialecki wrote:
> On Tue, 25 Apr 2000, Paul Richards wrote:
> > branch. Most commercial users are not developers, and have no interest
> > in anything relating to development. Professional sysadmins are
> > conservative creatures, they expect prof
Any getting these too?
ild-tools
cd /usr/src/bin/sh; make build-tools
cc -O -pipe -DSHELL -I. -I/usr/src/bin/sh -Wall -Wformat -c
/usr/src/bin/sh/mkinit.c
cc: Internal compiler error: program cc1 got fatal signal 11
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd
On Tue, Apr 25, 2000 at 01:00:28PM -0500, Richard Wackerbarth wrote:
> On Tue, 25 Apr 2000, Wilko Bulte wrote:
>
> > > On a similar note: I think one of serious drawbacks of FreeBSD's model
> > > for updating and bugfixing the stable branch is 'make world'. It's very
> > > inefficient and cumbers
The summary may have saved lots of net time.
I did not cvsup today because of the summary.
tomdean
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> > On a similar note: I think one of serious drawbacks of FreeBSD's model
> > for updating and bugfixing the stable branch is 'make world'. It's very
> > inefficient and cumbersome way to do this on production machines. STABLE
> > is stable enough for us t
> > If that's the _only_ point, then Garrett Wollman's idea should work
> > perfectly. Stick the files under CVS
>
> No, that was not my proposal. I want to keep them out of CVS
> entirely. CVS is Not Good at handling binary files (even if you never
> change them). That's why I'd like them in
> > I'd like to add that it can be particularly important when legal
> > questions arise.
>
> You confuse the argument for SOME complete repositories with
> the necessity that ALL (or at each most) repositories be so extensive.
No-one needs to grab a repository, unless they're looking at histor
On Tue, 25 Apr 2000, Nate Williams wrote:
> No-one needs to grab a repository, unless they're looking at history.
> Just use CVSup to grab the latest bits, no need to grab the entire
> history.
I find it virtually impossible to work with anything but the most stable
without the recent part of t
Hiya folks. I'm running on FreeBSD 4.0-RELEASE, trying to get a Lucent
Wavelan card (wi) working via an ActionTec PC700 PCMCIA controller (detail
on this controller: http://www.actiontec.com/support/readers/pc700.html)
I've been chatting with Bill (who wrote the 'wi' driver), and we can't
seem
In message <[EMAIL PROTECTED]>, Andrzej Bialecki
writes:
>On Tue, 25 Apr 2000, Poul-Henning Kamp wrote:
>
>>
>> ===
>> SUMMARY
>> ===
>
>[27kB long list of errors deleted..]
>
>I thought that the final conclusion was to have some ot
> On Tue, 25 Apr 2000, Boris Popov wrote:
>
> > simple_lock* functions has breakage too. They defined as macros
> > for non-SMP case and as functions for SMP.
>
> This currently apparently affects the following modules:
>
> ccd
> cd9660
> msdosfs
> nfs
> ntfs
> nwfs
On Tue, 25 Apr 2000, Poul-Henning Kamp wrote:
>
> ===
> SUMMARY
> ===
[27kB long list of errors deleted..]
I thought that the final conclusion was to have some other mailing list
for this type of messages... ?
Andrzej Bialecki
/
> On Mon, 24 Apr 2000, Nate Williams wrote:
> > I'm violently opposed to removing it completely. The only thing I
> > wouldn't be violently opposed to would be removing 'Attic' files (truly
> > unused file), and having them stored away somewhere in the tree for
> > archival purposes.
>
> You rea
Ok, I got the buildworld to finih up this morning, but when I try
installworld, I get:
m/vm_zone.h -> vm/vm_zone.ph
vm/vnode_pager.h -> vm/vnode_pager.ph
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl/utils/h2ph.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl/utils.
*** Error code 1
Sto
On Tue, 25 Apr 2000, Paul Richards wrote:
> branch. Most commercial users are not developers, and have no interest
> in anything relating to development. Professional sysadmins are
> conservative creatures, they expect professional quality code to play by
> the rules of the industry and those rul
I'm not running a recent current on my TP600E (it's pre 4.0-RELEASE).
Sound works on this snapshot (4.0-2314-CURRENT).
The relavent config bits...
options PNPBIOS
device pcm0
(notice no bridge drivers (like sbc0))
dmesg output
...
unknown6: at port 0x3bc-0x3bf irq 7 on isa0
un
< said:
> If that's the _only_ point, then Garrett Wollman's idea should work
> perfectly. Stick the files under CVS
No, that was not my proposal. I want to keep them out of CVS
entirely. CVS is Not Good at handling binary files (even if you never
change them). That's why I'd like them in a
===
SUMMARY
===
World
compiled
637 Warnings
45 Errors
Kernel LINT
compiled
149 Warnings
0 Errors
Kernel GENERIC
compiled
59 Warnings
0 Errors
Kernel GENERIC98
Thus spake Donn Miller ([EMAIL PROTECTED]):
> cd /usr/src
> make -j8 buildworld || make -DNOCLEAN buildworld
Hmmm. Or make -k -j8 buildworld || make -DNOCLEAN buildworld
in order to build as much multithreaded as possible and then the
reminding part non-threaded? :-)
Alex
--
I need a new ~/.s
On Tue, 25 Apr 2000, Robert Small wrote:
> I was using -J8, and I kept getting the same error about 20 minutes into the
> build, but I did it without the -j and got a perfect build, thanks for the
> help!
One way to automate this would be:
cd /usr/src
make -j8 buildworld || make -DNOCLEAN build
I was using -J8, and I kept getting the same error about 20 minutes into the
build, but I did it without the -j and got a perfect build, thanks for the
help!
Robert
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David O'Brien
Sent: Monday, April 24, 200
On Mon, 24 Apr 2000 13:52:20 MST, Matthew Jacob wrote:
> But this isn't the point. The point is to cause less cvsup turbulence
> for all and sundry. I think I can do enough of this by just splitting
> the file apart to keep everyone happy. Or happy enough.
If that's the _only_ point, then Garr
Hi,
I've just found what it seems to me an error somewhere in the KLD modules
implementation affecting both 4-STABLE and 5-CURRENT. Following course of
actions makes kernel panic on both releases:
1. Load vn module into kernel
2. Configure vn device using vnconfig
3. Mount vn device
4. Unmount vn
On Mon, 24 Apr 2000, Garrett Wollman wrote:
> < said:
> > You confuse the argument for SOME complete repositories with
> > the necessity that ALL (or at each most) repositories be so extensive.
>
> You're welcome to remove whatever history you like from your personal
> copy.
Not if I want to k
"Brandon D. Valentine" wrote:
>
> On Tue, 25 Apr 2000, Daniel C. Sobral wrote:
>
> >Because if we do not provide a STABLE ABI, we WON'T get third-party
> >(binary only) kernel modules.
> >
> >I'm very divided in this issue. 4.x has just started, and would be
> >seriously impaired if no further i
Bill Fumerola wrote:
>
> On Mon, Apr 24, 2000 at 04:46:43AM -0500, Richard Wackerbarth wrote:
>
> > >From the USER's perspective, anything that requires me to as much as reload
> > a module/program that I have already installed "breaks" it.
> > The fact that it is only necessary to recompile it
On Tue, 25 Apr 2000, Boris Popov wrote:
> simple_lock* functions has breakage too. They defined as macros
> for non-SMP case and as functions for SMP.
This currently apparently affects the following modules:
ccd
cd9660
msdosfs
nfs
ntfs
nwfs
vinum
All of these
:> The network stack is equally easy to make MP-safe. In this case we
:> have a shared lock to lookup sockets for host/port combinations and
:> then fine-grained exclusive locks within those sockets. Route table
:> and other high level operations could in fact remain BGL'd witho
On Tue, 25 Apr 2000, Greg Lehey wrote:
> On Sunday, 23 April 2000 at 10:07:38 +0100, Doug Rabson wrote:
> > On Sun, 23 Apr 2000, Greg Lehey wrote:
> >
> >> In the last few days, my remote serial gdb has almost completely
> >> stopped working. Previously I had (almost) no trouble at 38400 bps;
>
On Mon, Apr 24, 2000 at 11:56:50PM -0700, Christopher Nielsen <[EMAIL PROTECTED]>
wrote:
> Solaris is far and away better at SMP than NT. I haven't seen NT running
> on 64-cpu machines, and I certainly haven't seen it scaling very nearly
> linearly to ~20 CPUs (diminishing returns start to take
Hope this can help -- here it is:
Copyright (c) 1992-1999 FreeBSD Inc.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
FreeBSD 3.4-RELEASE #0: Tue Apr 25 02:23:41 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/BELL
Timecou
On Tue, 25 Apr 2000, Tal S Eilon wrote:
> I Just installed my Dell PowerEdge 1300 P-III/500 + 512MB RAM +
> 8Gb UW-SCSI Drive but I my system is VERY slow. It took me close
> to 15min to compile tcsh-6.09.00. Did anyone experienced anything
> like that before?
Sounds like you must have your CPU
Hi all,
I Just installed my Dell PowerEdge 1300 P-III/500 + 512MB RAM +
8Gb UW-SCSI Drive but I my system is VERY slow. It took me close
to 15min to compile tcsh-6.09.00. Did anyone experienced anything
like that before?
Tal S. Eilon
Unix System Adminisrator
Cybertel Ltd.
--
To Unsubscribe:
On Tue, 25 Apr 2000, Vallo Kallaste wrote:
> Fair enough, but as somebody (Greg Lehey if I recall) said it was taken
> about 5 years for Sun to develop fine SMP support and we can't expect to
> be faster. FreeBSD is quite behind of Linux on the SMP issues currently,
> Linux is somewhat behind of
On Mon, Apr 24, 2000 at 10:55:05PM -0400, "Brandon D. Valentine"
<[EMAIL PROTECTED]> wrote:
> The number one excuse large third party server vendors use to justify
> use of NT over Linux on their high end SMP systems is the poor
> performance of Linux SMP. This is a tremendous opportunity for F
Jon Hamilton wrote:
> I've been following this thread at some distance for a while, and I
> don't understand your definition of ``everyone''. Aside from developers,
> who do you feel is a good candidate to track the entire CVS repository, rather
> than using CVSUP or some other method to get onl
Richard Wackerbarth wrote:
>
> On Mon, 24 Apr 2000, you wrote:
>
> > I'd like to add that it can be particularly important when legal
> > questions arise.
>
> You confuse the argument for SOME complete repositories with
> the necessity that ALL (or at each most) repositories be so extensive.
80 matches
Mail list logo
