> personalities or styles. In this case, I'd say it was a job for the
> CRC if we currently had one. :)
Does that make it a "CRC Check"? :)
(Good old redundant-terminology Cyclical-Reduncancy-Check Checks.)
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
Hi,
I said:
> I am guessing that little of the above will be MFC'd into 4.0. So the issue
> of the current SMP patch set should be based on its merits alone. I would
> agree that they in themselves are worthy of MFCing. Lets just not kid
Mike Smith replied:
> Steve Passe actually argued quit
Hello,
On Tue, Apr 25, 2000 at 12:11:58PM +0700, Boris Popov wrote:
> > mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL
>-DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include
>-I/usr/obj/usr/src/i386/usr/include /usr/src/sys/modules/sys
Personally, I don't think that's a bad idea, I never had trouble going to
/usr/src/sys/modules and doing a make depend then make then make install,
but I guess it'd be nicer if everything just compiled when I built my
kernel, and better yet, it would be nice to have it make the
"modules.old" direc
On Tue, 25 Apr 2000, Bruce Evans wrote:
> > Given that this is a change in splxxx() I suspect that it breaks
> > most modules, but probably not all modules. A quick grep -l spl * | wc
>
> Given that this is a change in the splxxx() implementation, it breaks
> zero modules.
>
> splxxx() was cha
On Tue, 25 Apr 2000, Alexander Matey wrote:
> Cvsupped 2 hours ago:
>
> ...
> ===> sys/modules/syscons/fire
> @ -> /usr/src/sys
> machine -> /usr/src/sys/i386/include
> rm -f .depend
> mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL
>-DKLD_MODULE -I- -I/usr/src/
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 realize that its
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;
>> now I can barely get a response at all at 9600 bp
Hello,
Cvsupped 2 hours ago:
...
===> sys/modules/syscons/fire
@ -> /usr/src/sys
machine -> /usr/src/sys/i386/include
rm -f .depend
mkdep -f .depend -a -nostdinc -I/usr/src/sys/modules/syscons/fire/.. -D_KERNEL
-DKLD_MODULE -I- -I/usr/src/sys/modules/syscons/fire/.. -I. -I@ -I@/../include
-I
In message <[EMAIL PROTECTED]>, Richard Wackerbarth wrote
} > > Do we really need 5 year old history?
} >
} > Yes.
} I don't disagree that we need to maintain the history.
}
} I do, however, question the policy that REQUIRES EVERYONE to maintain that
} much history.
I've been following this t
On Mon, 24 Apr 2000, Rodney W. Grimes wrote:
> > On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
> > Are all modules effected, or only those that use certain interfaces?
>
> Given that this is a change in splxxx() I suspect that it breaks
> most modules, but probably not all
> during the mkdep, I get:
>
> ../../kern/kern_linker.c:49: linker_if.h: No such file or directory
> ../../kern/link_aout.c:45: linker_if.h: No such file or directory
> ../../kern/link_elf.c:55: linker_if.h: No such file or directory
> mkdep: compile failed
> *** Error code 1
>
> Stop in /usr/sr
The message says it all - my system does the equivalent of a 'halt -p'
upon launching `apm' during boot up -
...
acd0: CD-RW at ata0-master using PIO3
acd1: CDROM at ata0-slave using UDMA33
Waiting 2 seconds for SCSI devices to settle
pass0 at ahc0 bus 0 target 6 lun 0
pass0: < scanner 636EL 1
< 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. It's not worth the effort to the project as a whole to save a
small amount
On Mon, 24 Apr 2000, Bakul Shah wrote:
> > Do we really need 5 year old history?
>
> That really depends on your point of view.
>
> "Those who cannot remember the past are condemned to repeat it"
> -- Santayana
>
> "The only thing we learn from history is that we learn nothing fr
> Do we really need 5 year old history?
That really depends on your point of view.
"Those who cannot remember the past are condemned to repeat it"
-- Santayana
"The only thing we learn from history is that we learn nothing from history."
-- Hegel
I am with Hegel
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 improvements to it's SMP get in. On
>the other
> I want to bring up a suggestion. I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
>
> I want to suggest that, once a year, we go thru the cvs archive, and prune
> away all history more than 3 (or maybe 2, maybe 4) years old.
I'm violen
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.
To Unsubscribe: send mail to [EMAIL PROTECT
On Mon, Apr 24, 2000 at 08:59:46PM -0500, Richard Wackerbarth wrote:
> > Do we really need 5 year old history?
> a) yes, we need the history.
> b) do we need it "online everywhere"?
> I think the answer is "no". However the sandbox engineers think differently.
> c) I've brought this up more than
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
>I believe that it depends on what changes were made since the last
>recompile, although it is good practice to at least recompile the modules
>when the kernel is recompiled.
In my opinion the best way to handle things like this is to add a
module
On Mon, 24 Apr 2000, Chuck Robey wrote:
> Do we really need 5 year old history?
Yes.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent | IS
< said:
> OK. Thanks, I wanted some opinions, and I guess I have enough to satisfy
> me.
I'd like to add that it can be particularly important when legal
questions arise. Should some submarine patent cover parts of
FreeBSD's practice, it will turn out to be extremely important to be
able to do
On Mon, 24 Apr 2000, you wrote:
> On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote:
> > I want to bring up a suggestion. I just want a little bit of argument on
> > it ... and if you're violently opposed, just say so, that's fine.
>
> I'm "violently opposed". :-)
>
> > While folks do
On Mon, 24 Apr 2000, Chuck Robey wrote:
> I want to bring up a suggestion. I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
>
> I want to suggest that, once a year, we go thru the cvs archive, and prune
> away all history more than 3 (or
On Mon, 24 Apr 2000, Kent Hauser wrote:
>
> Hi all,
>
> I've been unable to get audio (mp3 & cdplay) to work on my desktop
> with a SBLive card or on my laptop (TP 600E). I would *really* like
> to have IPSec and a working audio cd player on my laptop. I this
> supposed to work, or am I swimmin
David O'Brien writes:
| On Mon, Apr 24, 2000 at 04:04:00PM -0700, Doug Ambrisko wrote:
| > With -current as of the weekend. I now have tcsh as the root shell.
| > I noticed something "strange", my history only displays the time, for example
|
| Known problem. Will be fixed in a few days.
Thank
* Chuck Robey <[EMAIL PROTECTED]> [000424 19:15] wrote:
> I want to bring up a suggestion. I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
>
> I want to suggest that, once a year, we go thru the cvs archive, and prune
> away all history
On Mon, 24 Apr 2000, David O'Brien wrote:
> On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote:
> > I want to bring up a suggestion. I just want a little bit of argument on
> > it ... and if you're violently opposed, just say so, that's fine.
>
> I'm "violently opposed". :-)
>
> > W
Chuck Robey wrote:
> I want to bring up a suggestion. I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
Okay: "so." :-)
> Do we really need 5 year old history?
Well, unfortunately (and I speak from painful experience), yes. You never
On Mon, 24 Apr 2000, Bill Fumerola wrote:
> The entire point is that somewhere the user has decided to upgrade
> their system, and they need to know what the consequences are before
> taking the plunge. If they upgrade their system half-ass (kernel, but
> not modules) they are digging their own gr
On Mon, Apr 24, 2000 at 08:15:45PM -0400, Chuck Robey wrote:
> I want to bring up a suggestion. I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
I'm "violently opposed". :-)
> While folks do sometimes go hunting for hugely old materia
On Mon, 24 Apr 2000, Chuck Robey wrote:
> I want to bring up a suggestion. I just want a little bit of argument on
> it ... and if you're violently opposed, just say so, that's fine.
>
> I want to suggest that, once a year, we go thru the cvs archive, and prune
> away all history more than 3 (
On Mon, Apr 24, 2000 at 04:04:00PM -0700, Doug Ambrisko wrote:
> With -current as of the weekend. I now have tcsh as the root shell.
> I noticed something "strange", my history only displays the time, for example
Known problem. Will be fixed in a few days.
--
-- David([EMAIL PROTECTED])
>
> 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 without
I want to bring up a suggestion. I just want a little bit of argument on
it ... and if you're violently opposed, just say so, that's fine.
I want to suggest that, once a year, we go thru the cvs archive, and prune
away all history more than 3 (or maybe 2, maybe 4) years old. This could
be done
Hi all,
I've been unable to get audio (mp3 & cdplay) to work on my desktop
with a SBLive card or on my laptop (TP 600E). I would *really* like
to have IPSec and a working audio cd player on my laptop. I this
supposed to work, or am I swimming upstream.
Thanks all.
Kent
To Unsubscribe: send ma
Not to create another argument but tcsh does not appear to be csh :-(
With -current as of the weekend. I now have tcsh as the root shell.
I noticed something "strange", my history only displays the time, for example
dual# history
1 13:42
2 13:42
3 13:42
4 13:42
5 1
during the mkdep, I get:
../../kern/kern_linker.c:49: linker_if.h: No such file or directory
../../kern/link_aout.c:45: linker_if.h: No such file or directory
../../kern/link_elf.c:55: linker_if.h: No such file or directory
mkdep: compile failed
*** Error code 1
Stop in /usr/src/sys/compile/MONI
{First one bounced by hub with ``out of memory'' error... second attempt}
> > Are there any 3rd party NIC klds yet?
>
> NTMK.
It's not quite a kld, but ET Inc's modules are distributed as a .o.
Also I know of work underway to support some of the fancier SDL WanNic
cards that would have to be kl
On Mon, Apr 24, 2000 at 02:14:50PM -0700, Rodney W. Grimes wrote:
> > Developers and early adopters are the ones tracking -STABLE. Users are
> > installing binary snapshots and releases.
>
> Some users do install snapshots and/or releases. Snap shots occur on a
> regular basis and are affected
On Mon, 24 Apr 2000, you wrote:
> > On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
> > > That is also partly why you are also lacking the respect and support of
> > > a wider audience. If you act like FreeBSD is just a "developer's
> > > sandbox", that's what it will be. If y
> On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
>
> > That is also partly why you are also lacking the respect and support of a
> > wider audience. If you act like FreeBSD is just a "developer's sandbox",
> > that's what it will be. If you want it to be something greater
> > Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
> > so every vendor that has ever tried to use them has been bitten by the
> > fact that they have to maintain N version for each branch of FreeBSD???
>
> Can you list some specific examples? I'm not trying to be a wise-a
> Matt can tell you more ;-)
People don't really want to know more. They just don't want what I provide
support for to impact them. I'll bet if I sum up all the other kernel mathoms
like netgraph, and so on, that *I* never use, it'd be less than this f/w...:-)
But this isn't the point. The poin
Are there any plans to allow rndcontrol to accept greater than 16 interrupts
on SMP machines ? On my ASUS XG-DLS board, all the interesting interrupts
that I want to use to stir the entropy pool are greater than 16.
Examination of sys/i386/i386/mem.c on RELENG_3, RELENG_4 and HEAD all have
this
> Are there any 3rd party NIC klds yet?
NTMK.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Jordan K. Hubbard writes:
> > So you guys (core) choose -- do you want 4.x to reap the benefits of
> > further SMP development or not?
>
> I've read all the feedback on this thread and now feel that it would
> be worthwhile to simply bring the SMP changes in on Wednesday. As others
On Mon, Apr 24, 2000 at 02:07:22PM -0500, Richard Wackerbarth wrote:
> On Mon, 24 Apr 2000, you wrote:
>
> > > Seriously, perhaps we should consider putting optional pieces of the
> > > kernel
> >
> > Firmware for a SCSI adapter is not optional. At least not on some of the
> > Alpha machines that
One (relatively minor) example is Open Sound System...
http://www.opensound.com/freebsd.html
Al
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jordan
> K. Hubbard
> Sent: Monday, April 24, 2000 2:58 PM
> To: Rodney W. Grimes
> Cc: Jacques A . Vi
On Mon, Apr 24, 2000 at 02:02:28PM -0500, Richard Wackerbarth wrote:
> That is also partly why you are also lacking the respect and support of a
> wider audience. If you act like FreeBSD is just a "developer's sandbox",
> that's what it will be. If you want it to be something greater than that,
On Mon, 24 Apr 2000, you wrote:
> > Seriously, perhaps we should consider putting optional pieces of the
> > kernel
>
> Firmware for a SCSI adapter is not optional. At least not on some of the
> Alpha machines that download out-of-date firmware from their SRMs so depend
> on the driver to load th
> No-one forces you to upgrade you systems. Partial upgrades
> are something that are
> nice when they work, but understood when they don't.
>
> We don't accept bug reports (typically) when a person hasn't
> upgraded their world,
> kernel, and modules. I don't understand why we're accepting
>
On Mon, 24 Apr 2000, you 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 t
On Mon, 24 Apr 2000, David O'Brien wrote:
> On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote:
> > patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to
> > "i586" or "i686" (both are actually identical at present) and rebuild.
>
> Please also support "k5" and "k6".
On Mon, Apr 24, 2000 at 01:43:44PM -0500, Richard Wackerbarth wrote:
> On Mon, 24 Apr 2000, Julian Elischer wrote:
>
> > This seems well thought out and I certainly agree that we don't need
> > DIFFs of firmware.
> > I wonder if we can somehow "cheat time" and get that 13MB file out of
> > the so
> Gee, is that perhaps because FreeBSD keeps breaking the ABI to modules
> so every vendor that has ever tried to use them has been bitten by the
> fact that they have to maintain N version for each branch of FreeBSD???
Can you list some specific examples? I'm not trying to be a wise-ass,
I'm tr
> So you guys (core) choose -- do you want 4.x to reap the benefits of
> further SMP development or not?
I've read all the feedback on this thread and now feel that it would
be worthwhile to simply bring the SMP changes in on Wednesday. As others
have pointed out, we don't have enough 3r
On Fri, Apr 21, 2000 at 07:28:28PM -0700, Kris Kennaway wrote:
> patch to sys.mk which defined MACHINE_CPU ?= i386). Set MACHINE_CPU to
> "i586" or "i686" (both are actually identical at present) and rebuild.
Please also support "k5" and "k6".
--
-- David([EMAIL PROTECTED])
To Unsubscrib
On Sat, Apr 22, 2000 at 01:05:24AM +0400, Sergey Osokin wrote:
> Hello!
> After CVSup i tryed to rebuild my 5.0...
Are you using "-j" with your makes?
Please try:
cd /usr/src
make cleandir && make cleandir
and try again. Let me know the outcome -- good or bad.
*If* the outcome is "goo
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 in order to fix it only
> means t
On Mon, 24 Apr 2000, Julian Elischer wrote:
> This seems well thought out and I certainly agree that we don't need
> DIFFs of firmware.
> I wonder if we can somehow "cheat time" and get that 13MB file out of
> the source tree and retro-actively tag the new scheme so
> that we don't have to carry
On Mon, Apr 24, 2000 at 08:40:52AM -0500, Robert Small wrote:
> I've been trying to do a buildworld since Friday, after doing a cvsup, and
> no matter how many
> times I try, I keep getting:
Please try:
cd /usr/src
make cleandir && make cleandir
and try again. Let me know the outcome -
On Mon, 24 Apr 2000, Alfred Perlstein wrote:
> I think as a whole we need to evaluate the use of macros, they're
> one of the major problems with changes like this and several people
> have come forward over time with strong numbers showing that the
> code bloat causes that comes with overuse of
* Matthew Dillon <[EMAIL PROTECTED]> [000424 11:15] wrote:
> After further review I don't think there are any compatibility problems
> with the spl*() mechanisms.
>
> But I must still caution that due to the extensive nature of the
> cleanup, despite being mostly internal to the
After further review I don't think there are any compatibility problems
with the spl*() mechanisms.
But I must still caution that due to the extensive nature of the
cleanup, despite being mostly internal to the kernel, there could
very well be other things that we have overlo
> < said:
>
> > This is probably an okay idea, except how would you include such files?
> > I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with
> > /usr/src/sys/dev/firmware/{isp, esh, ...}?
>
> The fact that said directory is under CVS control, which is what I'm
> sugge
< said:
> This is probably an okay idea, except how would you include such files?
> I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with
> /usr/src/sys/dev/firmware/{isp, esh, ...}?
The fact that said directory is under CVS control, which is what I'm
suggesting we get awa
On Mon, 24 Apr 2000, Frank Mayhar wrote:
> 1. 4.0 hasn't been out long enough for there to be any significant support
>for it in proprietary systems. It takes more lead time than this.
So make the change and release it as FreeBSD5. Save the big changes for
something called FreeBSd6 or Free
:As the original author of the cil/cml code I can say I was glad to see that
:Matt
:had finally put it to rest. It was a desperate hack made in an attempt to pinch
:a little more performance out of the paradigm without dealing with the whole
:spl() problem set. I would have done it myself if li
Matthew Dillon wrote:
> So you guys (core) choose -- do you want 4.x to reap the benefits of
> further SMP development or not? If you choose no, beware that without
> this base cleanup there is *NO* chance whatsoever of any further SMP
> work being MFC'd to 4.x. None. Zilch.
: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 improvements to it's SMP get in. On
:the other hand, if we can't garantee third party vendor
:On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
:> On a released system, I may not have the sources to recompile the module.
:> It might be a proprietary module that I got with the hardware, for example.
:
:How real is this? What modules are we talking about? The last time
> On the _other_ hand:
>
> 1. 4.0 hasn't been out long enough for there to be any significant support
>for it in proprietary systems. It takes more lead time than this.
Unfortunately, many vendors will simply install from the 4.0-RELEASE CD
and build their modules there.
> 3. Any propriet
> On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
> > On a released system, I may not have the sources to recompile the module.
> > It might be a proprietary module that I got with the hardware, for example.
>
> How real is this? What modules are we talking about? The last
This is probably an okay idea, except how would you include such files?
I'm not sure I follow your naming scheme in /usr/firmware- what's wrong with
/usr/src/sys/dev/firmware/{isp, esh, ...}?
On Mon, 24 Apr 2000, Garrett Wollman wrote:
> < said:
>
> > This seems to be inherent in the file
Richard Wackerbarth wrote:
> On a released system, I may not have the sources to recompile the module.
> It might be a proprietary module that I got with the hardware, for example.
> That is why STABLE INTERFACES are so IMPORTANT to USERS.
>
> "Current" is a sandbox. Lower expectations are part o
Garrett Wollman wrote:
>
> < said:
>
> > This seems to be inherent in the file format. Binary data is expanded
> > by a factor of 4 due to encoding it as a C array. Even tiny changes
> > in the data ripple through the array and give huge diffs. Uuencoding
> > the data would only expand it by
< said:
> This seems to be inherent in the file format. Binary data is expanded
> by a factor of 4 due to encoding it as a C array. Even tiny changes
> in the data ripple through the array and give huge diffs. Uuencoding
> the data would only expand it by a factor of 1.4 although it would
> ha
Yes, this needs to be fixed. I have an open bug about this with respect to
making the f/w a loadable module as well. I'll probably split it into several
pieces so that each f/w update is smaller. I could probably make it binary and
compress is (each f/w module is an array of 16 bit shorts), but t
Hi,
>So you guys (core) choose -- do you want 4.x to reap the benefits of
>further SMP development or not? If you choose no, beware that without
>this base cleanup there is *NO* chance whatsoever of any further SMP
>work being MFC'd to 4.x. None. Zilch. It will have diverged
> On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
>
> > > I don't think it was ever recommended that you upgrade your kernel
> > > without upgrading and rebuilding the modules (better still, world) at
> > > the same time. So this wouldn't really have an adverse effect, would it?
> >
> > I believ
Alok Dhir wrote:
>
> SMP is a significant area of weakness for 4.0 and begs for improvement. I
> for one am thrilled at the progress Matt's made in this area and am itching
> to incorporate the changes into my 4.0 development servers (my production
> servers are still at 3.4-STABLE pending 4.1).
Martin Blapp wrote:
> I really like to see your fix committed to STABLE. It fixes also the
> bad designed Staroffice 5.2 installation for some part (/usr/sbin/test).
...as well as the WordPerfect 2000 for Linux installation. Basically, it
sounds like it makes Linux emulation really complete. Al
Somehting must have changed with permissions in the last weeks.
The owner of a print sessions control file are different when
printing over network compared to a local print job.
The lineprinter input filter doesn't have permissions to grep through
the control file during runtime.
Precise problem
On Mon, Apr 24, 2000 at 09:27:04AM -0500, Richard Wackerbarth wrote:
> On a released system, I may not have the sources to recompile the module.
> It might be a proprietary module that I got with the hardware, for example.
How real is this? What modules are we talking about? The last time
I que
"Brandon D. Valentine" wrote:
>
> On Mon, 24 Apr 2000, Alok K. Dhir wrote:
>
> >
> >Totally off topic question that I've wondered for some time now - what
> >does MFC stand for?
>
> According to the FAQ section located on the web @
> http://www.freebsd.org/FAQ/misc.html#AEN3908
>
> Q: What doe
SMP is a significant area of weakness for 4.0 and begs for improvement. I
for one am thrilled at the progress Matt's made in this area and am itching
to incorporate the changes into my 4.0 development servers (my production
servers are still at 3.4-STABLE pending 4.1).
If recompiling bothers yo
On Mon, Apr 24, 2000 at 02:56:33PM +0800, Stephen Hocking scribbled:
# For sometime now, the analogue joy stick driver hasn't been working - it seems
# to persistently return totally wild deviations when being read. Also, trying
# to use it as a kld doersn't seem to work. Has anyone else had sim
On Mon, 24 Apr 2000, Kenneth Wayne Culver wrote:
> > I don't think it was ever recommended that you upgrade your kernel
> > without upgrading and rebuilding the modules (better still, world) at
> > the same time. So this wouldn't really have an adverse effect, would it?
>
> I believe that it depe
Robert:
as root:
# rm -rf /usr/include/openssl /usr/obj
* Robert Small ([EMAIL PROTECTED]) [000424 10:08]:
> I've been trying to do a buildworld since Friday, after doing a cvsup, and
> no matter how many
> times I try, I keep getting:
>
> ===> librsausa
> cp /usr/src/secure/lib/librsausa/..
> Richard Wackerbarth wrote:
> >
> > On Mon, 24 Apr 2000, Matthew Dillon wrote:
> > > : However, I consider your SMP changes VERY destablizing; they BREAK
> > > : lots of modules :-(
> > >
> > > Huh? No they don't. They simply require recompiling the modules. If
> > > they actually bro
On Mon, 24 Apr 2000, Jeroen C. van Gelderen wrote:
> I don't think it was ever recommended that you upgrade your kernel
> without upgrading and rebuilding the modules (better still, world) at
> the same time. So this wouldn't really have an adverse effect, would it?
Such a policy is totally unac
I've been trying to do a buildworld since Friday, after doing a cvsup, and
no matter how many
times I try, I keep getting:
===> librsausa
cp /usr/src/secure/lib/librsausa/../libcrypto/opensslconf-i386.h
openssl/opensslconf.h
mkdir: openssl: File exists
*** Error code 1
1 error
*** Error code 2
1
Richard Wackerbarth wrote:
>
> On Mon, 24 Apr 2000, Matthew Dillon wrote:
> > : However, I consider your SMP changes VERY destablizing; they BREAK
> > : lots of modules :-(
> >
> > Huh? No they don't. They simply require recompiling the modules. If
> > they actually broke the modules I
On 23 Apr, Daniel Eischen wrote:
>> (14) netchild@ttyp2% uname -a
>> FreeBSD Magelan.Leidinger.net 5.0-CURRENT FreeBSD 5.0-CURRENT #14:
>> Fri Apr 21 17:28:37 CEST 2000 root@:/big/usr/src/sys/compile/WORK
>> i386
>>
>> I've an application which uses pthread_cond_{wait,broadcast}() and
>> th
On Mon, 24 Apr 2000, Julian Elischer wrote:
> My cvsup appeared to be frozen, so I stopped it and looked..
>
> src/sys/dev/isp/asm_pci.c,v is 13MB long!
> it was just taking a long time..
>
> this seems a little excessive.
I was annoyed by this a few months ago when the file was only 10MB.
>
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> :I'm sure that something can be done for the kld compatibility issues
> :so that you can have your SMP cake and eat it too. Just give it a bit
> :more thought. :)
> :
> :- Jordan
>
> Thought I have. Time I don't. While I don't particularly see
On Sun, 23 Apr 2000, Matthew Dillon wrote:
> There's another good reason to MFC the linux patch on wednesday...
> that is, to do it at the same time the SMP cleanup is MFC'd, and that
> is because both patch sets require the linux kernel module to be
> recompiled and I'd rather
but, in all this, the bottom line is that compilers, until
recently, barfed on __func__. to compile the kernel, I
substituted the function name in the printf statement... no
big deal, but not what was intended, which I presume was to
guarantee the correct function name, even if
1 - 100 of 104 matches
Mail list logo
