I found it, will commit in a sec. Sorry.
Poul-Henning
In message 19990508231949.a93...@hal.mpn.cp.philips.com, Jos Backus writes:
Some more information:
In sys/i386/i386/autoconf I'm seeing the following happen:
static void
setroot()
{
int majdev, mindev, unit, slice, part;
Ah- that's why root stuff is broke... good
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Greg Lehey wrote:
A day or so ago, bdevsw changed from being an array of struct cdevsws
to an inline function. That's not a problem in itself: do a make
world and all will be well. It does, however, mean that klds which
were compiled before the change will no longer load. I had a report
On Sunday, 9 May 1999 at 16:15:51 +0800, Peter Wemm wrote:
Greg Lehey wrote:
A day or so ago, bdevsw changed from being an array of struct cdevsws
to an inline function. That's not a problem in itself: do a make
world and all will be well. It does, however, mean that klds which
were
In message 19990509081553.6ab261...@spinner.netplex.com.au, Peter Wemm write
s:
Greg Lehey wrote:
A day or so ago, bdevsw changed from being an array of struct cdevsws
to an inline function. That's not a problem in itself: do a make
world and all will be well. It does, however, mean that klds
In message 19990509174914.a22...@freebie.lemis.com, Greg Lehey writes:
People who are running -current for stability had better be damn careful
and be very selective about what they choose to run as a stable snapshot.
I think the real problem is that the klds get built with make world
and not
On Sunday, 9 May 1999 at 10:21:57 +0200, Poul-Henning Kamp wrote:
In message 19990509174914.a22...@freebie.lemis.com, Greg Lehey writes:
People who are running -current for stability had better be damn careful
and be very selective about what they choose to run as a stable snapshot.
I think
Greg Lehey wrote:
On Sunday, 9 May 1999 at 16:15:51 +0800, Peter Wemm wrote:
Greg Lehey wrote:
A day or so ago, bdevsw changed from being an array of struct cdevsws
to an inline function. That's not a problem in itself: do a make
world and all will be well. It does, however, mean that
Greg Lehey wrote:
I think the real problem is that the klds get built with make world
and not with a kernel build. How about changing that? I've got the
opposite problem on another machine: I did a make world, but not a
reboot, and now my Linux emulation is broken.
Same problem with
i had problems with the old kdelibs packages(1.1), all the programs i compiled
couldn't link.
i think it's an EGCS issue, so i decided to compile the kdelibs (1.1.1) with
-current.
it compiled, but no KDE software worked (including kwm).
tried to go back to the old pkg, but got the same
I already submitted this (about a week ago) :(
Please take a look at negative bandwith reported by i586_bzero...
(kernel cvsup'ed and rebuilded several minutes ago). Looks like data
type owerflow (my machine have K6-2 266 running on 250MHz and 1MB of L2
cache).
Calibrating clock(s) ... TSC
Tomer Weller wrote:
re -lXext -lqt -lX11 -lkdeui -lkdecore -lXext -lqt -lX11
root.o: file not recognized: File truncated
Maybe you are building ports over NFS - some time ago NFS client code on
-CURRENT was broken, however now it seems to be fixed.
Sincerely,
Maxim
To Unsubscribe: send
On Sun, May 09, 1999 at 09:52:31AM +0200, Poul-Henning Kamp wrote:
I found it, will commit in a sec. Sorry.
No problem, and thanks. Kept me off the streets for an evening at least.
Cheers,
--
Jos Backus _/ _/_/_/ Reliability means never
Nope.
Maxim Sobolev wrote:
Tomer Weller wrote:
re -lXext -lqt -lX11 -lkdeui -lkdecore -lXext -lqt -lX11
root.o: file not recognized: File truncated
Maybe you are building ports over NFS - some time ago NFS client code on
-CURRENT was broken, however now it seems to be fixed.
Hello folks
I cvsupped,made world, built a kernel today and from now on the de
interfaces only comes up in 100BaseTX, what causes it not to negotiate ?
My Apr_29 kernel doesnt behave like this.
The link lamp flickered like hell so it was quite a nice atmosphere for
awhile , but i got tired of it
I think the real problem is that the klds get built with make world
and not with a kernel build. How about changing that?
I've shot myself in the foot this way too. I'd really like to see
modules built as part of the kernel and not userland. As time goes on, I
think we will push more and
On Sun, May 9, 1999, Tomer Weller wrote:
kdebase-1.1.1 port errors with :
root.o: file not recognized: File truncated
Try doing:
make deinstall
make clean
make all
It looks like root.o may have been built with an older version
of egcs, or perhaps it was an a.out object file.
--
Chris
The changes that I added to soft updates two days ago only kick in
when the soft dependency memory limit is hit. This certainly should
not be happening at system startup, and on any machine with more
than 64Mb of memory, almost never. I did make a couple of minor
textual changes to other parts of
[.]
#0 0x805b519 in FsmRecvConfigRej (fp=0x80ae608, lhp=0xbfbfce98, bp=0x0)
^^
[.]
I'm on the case :-) The fsm_Input code now does an mbuf_Read() which
will return a NULL mbuf if everything has been read from it.
Kirk McKusick wrote:
The changes that I added to soft updates two days ago only kick in
when the soft dependency memory limit is hit. This certainly should
not be happening at system startup, and on any machine with more
than 64Mb of memory, almost never.
In my case it looks like your
I was thinking about Peter Wemm's recent change to the kernel Makefile,
making a way to install multiple kernels without fragging your last
known good kernel, and it got me to thinking, scragging kernel.old, now
that we have good kld's, isn't the only way to find yourself well and
truly screwed if
In message pine.bsf.4.10.9905091608060.401-100...@picnic.mat.net, Chuck Robe
y writes:
Something on the order of modules.old is going to need to
be implemented.
Not to mention /boot/kernel.old.config ...
I think you are seeing -current as the norm. You shouldn't. Under
-stable the modules
On Sun, 9 May 1999, Khaled Daham wrote:
Hello folks
I cvsupped,made world, built a kernel today and from now on the de
interfaces only comes up in 100BaseTX, what causes it not to negotiate ?
My Apr_29 kernel doesnt behave like this.
The link lamp flickered like hell so it was quite a
[.]
I'm using the 3.1R PPP right now, until the problem is
resolved. I'm sending a problem report, as well.
It should be resolved now. A NULL mbuf value is valid - it just
means that there's nothing in it. I changed fsm_Input() with the
last commits, and didn't notice the
Something on the order of modules.old is going to need to
be implemented.
Not to mention /boot/kernel.old.config ...
I think you are seeing -current as the norm. You shouldn't. Under
-stable the modules should (tm) continue to work since there are not
made API changes in -stable.
BUT
In message 19224.926238...@critter.freebsd.dk Poul-Henning Kamp writes:
: In general any commit to sys/kern/* or sys/sys/* should make you pay
: a LOT of attention.
Also, when the number of commits in these areas has been as high as it
has been lately, one should think twice before updating...
Anyone very -CURRENT and running i4b ? I just upgraded to the new config
syntax and it seems that it doesn't grok pseudo-devices with numbers in the
name correctly...
With this config(8) works but some dependencies are not generated and make
fails.
-=-=-
# Q.921 / layer 2 - i4b passive cards D
On Sun, 9 May 1999, Ollivier Robert wrote:
Anyone very -CURRENT and running i4b ? I just upgraded to the new config
syntax and it seems that it doesn't grok pseudo-devices with numbers in the
name correctly...
I'm running a kernel from yesterday, patched with i4b 0.80.
With this config(8)
I wish :-(
It seems that some people think that it is OK to make changes to stable
even though those changes break things which used to work.
IMHO, branches of the kernel SHOULD be like shared libraries.
(It is OK to ADD previously absent features or CORRECT internal errors,
but NOT OK to delete
Ollivier Robert writes:
Anyone very -CURRENT and running i4b ? I just upgraded to the new config
syntax and it seems that it doesn't grok pseudo-devices with numbers in the
name correctly...
With this config(8) works but some dependencies are not generated and make
fails.
-=-=-
# Q.921 / layer 2
I'm running 4.0-19990503-CURRENT.
In my case, freebsd swap is on /dev/wd0s3b (3-th
partition)
I'm trying to upgrade to last 4.0-0509-current.
I got error msg:
Unable to make device node for /dev/wd0s3b in /dev!
The creation of filesystems will be aborted.
On DEBUG screen I got:
DEBUG: MakeDev:
Hi,
The following is error related to compat22 is causing a
make release to fail... Has mtree been updated approriately?
thanks!
John
=== lib/compat/compat22
cd /usr/src/lib/compat/compat22 ; make install DESTDIR=/R/stage/trees/compat22
SHARED=copies
install -c -o root -g wheel -m 444
On Sun, 9 May 1999, Tomer Weller wrote:
Nope.
Well, is root.o truncated or otherwise corrupted? Are you seeing any other
filesystem problems on this machine? Did you crash/reboot during the build?
Kris
Maxim Sobolev wrote:
Tomer Weller wrote:
re -lXext -lqt -lX11 -lkdeui -lkdecore
The following is error related to compat22 is causing a make release
to fail... Has mtree been updated approriately?
A grep in /usr/src/etc/mtree/* shows there is no special handling for
compat?? dists.
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send
This is late, but a few hours ago, phk chopped out some old stuff from
config(8) and removed some backwards compatability warnings.
A summary of the changes:
If you had old tty, bio, net, cam flags, these are obsolete and will
now cause a syntax error rather than a warning.
If you had old
On Monday, 10 May 1999 at 10:04:40 +0800, Peter Wemm wrote:
It should be noted that config(8) is destined to die sooner or later and
almost certainly never make it to a release branch.
I suppose this makes it almost bearable. What's coming in its place?
Greg
--
See complete headers for
Peter Wemm pe...@netplex.com.au wrote:
If you had old vector xxxintr, it will now cause a syntax error rather than
a warning.
What is the new method of specifying a non-standard interrupt
function? I have some code (currently on 2.x, but I was hoping to be
able to move it) where I have different
If you had old vector xxxintr, it will now cause a syntax error rather than
a warning.
What is the new method of specifying a non-standard interrupt
function? I have some code (currently on 2.x, but I was hoping to be
able to move it) where I have different interrupt functions within the
same
Peter Wemm wrote:
If you had old tty, bio, net, cam flags, these are obsolete and will
now cause a syntax error rather than a warning.
If you had old vector xxxintr, it will now cause a syntax error rather than
a warning.
This is wrong, the warnings are just the same as before.
'config
I was quite surprised the First Time I got SPAM through this mailing list, I
thought for sure there would be someone to moderate it so that no garbage gets
through, I personally find it quite offensive to get SPAM on a help based
mailing list, I have been thinking that maybe this list should
subscribe
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Is anyone planning on upgrading the binutils gas to a later version so that we
can get 3DNow! support? I'd like to use it, but I can't seem to get binutils
to work right manually.
Brian Feldman_ __ ___ ___ ___ ___
gr...@unixhelp.org_ __ ___ | _ ) __| \
According to Gary Jennejohn:
pseudo-devicei4b
^ is there really a missing here ?
Oops. That was the error, shame on me for not seeing it.
The bad thing is that config(8) never complained about that error :-(
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=-
43 matches
Mail list logo