In message [EMAIL PROTECTED], Peter Wemm writes:
As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if
you like. ie: it is a time bomb waiting for the right low memory condition
which will then explode with a 100% authentic crash or lock up.
Pretend it said M_SLEEPOK
Peter Wemm wrote:
I think _sleeping_ is a problem, but allocation with M_WAITOK
shouldn't be, given it's strange definition of waiting. This
is one of those hacks that John Baldwin was talking about earlier...
As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if
you
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Peter Wemm writes:
As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if
you like. ie: it is a time bomb waiting for the right low memory condition
which will then explode with a 100% authentic crash or lock up.
Hello,
I have trouble building world:
--
stage 2: cleaning up the object tree
--
cd /opt/freebsd/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386
On 2002-05-19 12:20, Mark Murray wrote:
What I've done so far (and only slightly tested) is available at
http://www.FreeBSD.org/~keramida/diff/periodic.diff
Untested, but seemingly complete, the patch is available for review at
the address mentioned above. I am thinking a nice way to
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Peter Wemm writes:
As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if
you like. ie: it is a time bomb waiting for the right low memory conditio
n
which will then explode with a 100% authentic crash or lock
On Tue, 28 May 2002 14:56:04 -0400 (EDT),
John Baldwin [EMAIL PROTECTED] said:
The prototype patch is at:
http://people.FreeBSD.org/~tanimura/patches/ippreempt.diff.gz
And the p4 depot
//depot/user/tanimura/ippreempt/...
The patch is for only i386 at the moment.
The following
As you can see, the patch is trivial, so I have no clue why this wasn't
left alone when they modified symfile.c. If I can be bothered I'll
submit it to them.
Hmm. Looking at this patch, it seems it's complaining about being
handed a hex value where it's looking for an address. I'd
Terry Lambert wrote:
Peter Wemm wrote:
I think _sleeping_ is a problem, but allocation with M_WAITOK
shouldn't be, given it's strange definition of waiting. This
is one of those hacks that John Baldwin was talking about earlier...
As you said, _sleeping_ is the problem. M_WAITOK
Terry Lambert wrote:
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Peter Wemm writes:
As you said, _sleeping_ is the problem. M_WAITOK means you may sleep if
you like. ie: it is a time bomb waiting for the right low memory condit
ion
which will then explode with a 100%
Igor Roboul wrote:
Hello,
I have trouble building world:
--
stage 2: cleaning up the object tree
--
cd /opt/freebsd/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386
On Wed, 29 May 2002 16:13:13 +0900,
Seigo Tanimura [EMAIL PROTECTED] said:
tanimura Maybe we can solve both of the issues above by roughly checking if a
tanimura thread can keep spinning without acquiring any locks, in the similar
tanimura way as we do for a spin mutex. First, test the
Hi,
I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL
PCI card) I think there are some linuxdrivers but what could be needed for
FreeBSD support?
Contact the guys listed on http://www.xsproject.org/speedtouch/ (bottom of
the page).
--
Bob Bishop +44
Howdy,
I'm trying to build a FreeBSD-current snapshot release with a -current
install as of 28/05/02 1400 GMT and the CVS tree updated to the same date.
I've noticed that when -current is installed into the sandbox, groff isn't
installed, nor is it built prior to building the usr/share/doc/usd
I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL
PCI card) I think there are some linuxdrivers but what could be needed for
FreeBSD support?
Contact the guys listed on http://www.xsproject.org/speedtouch/ (bottom of
the page).
That's the Speedtouch USB, not the
On Mon, May 27, 2002 at 08:34:18PM +0900, MOCHIZUKI Akihide/??? wrote:
#define TENDCASE 9
#define TENDBQUOTE :
#define TREDIR ;
#define TWORD
#define TIF =
I think that there are problem with awk's printing of numbers.
':' is just '9'+1
so awk tries print numbers from 10 to 15 same
On Wed, May 29, 2002 at 12:50:15AM -0700, Peter Wemm wrote:
make obj
make depend
make
make install
As long as your /usr/src is up to date, that should save you.
Thank you. But now it fails on building of libncurses, with many:
lib_gen.c:504: `a0' undeclared (first use in this
cvsup'ed about 1 hour ago
in /etc/make.conf
MAKEOBJDIRPREFIX?=/r+d/obj
and with setnev MAKEOBJDIRPREFIX /r+d/obj
make buildworld
...
FATAL: can't create /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/cp-demangle
.o: Permission denied
how can i fix this?
danny
To Unsubscribe: send
Howdy,
Disconnecting usr/share/doc/usd/13.viref and usr/share/doc/papers/sysperf
from the build process allowed me to build a -current snapshot.
I found the reference in the CVS logs (2002/05/15 09:29:45 PDT) that c++
isn't being built. This explains the lack of groff and tbl.
There must be some
On Tue, 28 May 2002, Peter Wemm wrote:
Richard Wenninger wrote:
/usr/src/sys/vm/uma_core.c:1324: could sleep with UMA lock locked from
/usr/src/sys/vm/uma-core.c:1157
Should I be concerned?
Excessively concerned: no. But these are all *real* problems that must
be fixed.
On Wed, 29 May 2002, Peter Wemm wrote:
Poul-Henning Kamp wrote:
Uhm, I'm actually seeing the opposite behaviour as well: after I
changed the md(4) driver to use M_NOWAIT I still see malloc/zalloc
sleeping...
No, this is a bug in UMA. In certain circumstances, it calls itself
with
On Wed, 29 May 2002, Peter Wemm wrote:
M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means
you must not tsleep!. M_WAITOK conversely means that tsleep should be
called as needed. Things like malloc still can return NULL even with M_WAITOK
for non-recoverable scenarios.
On 29-May-2002 Peter Wemm wrote:
M_NOWAIT to the mbuf m_get*, malloc*, contigmalloc*, uma_* etc means
you must not tsleep!. M_WAITOK conversely means that tsleep should be
called as needed. Things like malloc still can return NULL even with M_WAITOK
for non-recoverable scenarios.
No,
On 29-May-2002 Seigo Tanimura wrote:
And the p4 depot
//depot/user/tanimura/ippreempt/...
The patch is for only i386 at the moment.
The following is the brief description of the patch:
jhb I would prefer that this was hung off the preemption stuff I've already done
jhb rather than
On Wed, May 29, 2002 at 05:56:28PM +0200, Martin Blapp wrote:
Hi Martin,
/usr/ports/editors/openoffice/work/oo_1.0_src/config_office/configure:3620:
undefined reference to `__gxx_personality_v0'
I've seen this problem too. I don't know if it has been solved, but
-CURRENT's C++ compiler has
Hi,
I've seen this problem too. I don't know if it has been solved, but
-CURRENT's C++ compiler has been broken for a while. The workaround has
been to install the gcc31 port and use it, e.g make
CXX=/usr/local/bin/g++31
And this doesn't work anymore. I see this with a fresh 3.1 port too
On Wed, 29 May 2002 18:06:10 +0200
Miguel Mendez [EMAIL PROTECTED] wrote:
I've seen this problem too. I don't know if it has been solved, but
-CURRENT's C++ compiler has been broken for a while. The workaround
has been to install the gcc31 port and use it, e.g make
CXX=/usr/local/bin/g++31
On Wed, May 29, 2002 at 06:08:58PM +0200, Martin Blapp wrote:
Hi,
And this doesn't work anymore. I see this with a fresh 3.1 port too now.
Martin, I don't doubt about your answer, but, can you verify you are
indeed using the ports g++ compiler? I can't reproduce the bug here.
Cheers,
--
Hi,
I managed to make pccard device driver into loadable module.
http://people.freebsd.org/~takawata/cardmodule.diff
To use this,
1. Apply following patch.(diff from HEAD)
2. Remove 'pccard','pcic','pccbb','cardbus', 'card'
line from configuration file.
3. Add following line to
On Wed, May 29, 2002 at 12:12:02PM -0400, Alexander Kabaev wrote:
Hi,
Martin is using GCC 3.1 from ports. It sounds like GCC tries to use some
library left over from the previous version of GCC, which does not
provide this symbol. g++13 -v should tell you what parameters GCC passes
to the
I'm new to the list, so please excuse my question If it has already been
asked before.
Being that -CURRENT's C++ compiler is b0rked, how long will it be until
it's problems have been resolved? I've seen many problems with it
lately, and it kinda made me worried, almost to the point where I
On 28-May-2002 Julian Elischer wrote:
Now things are moving again.
Jonathon Mini and I have cleaned up the patches a bit
and fixed the more obvious problems..
from teh point of view of non KSE processes
(that would be all of them at the moment) it shuold act the
same as now. Hopefully,
I have no doubt of the progress that's being made. Anyway, thanks for
the help. Again, keep up the good work.
-dt
-Original Message-
From: Sheldon Hearn [mailto:[EMAIL PROTECTED]] On
Behalf Of Sheldon Hearn
Sent: Wednesday, May 29, 2002 9:49 AM
To: Dan Trainor
Cc: [EMAIL PROTECTED]
On Wed, May 29, 2002 at 09:27:50AM -0700, Dan Trainor wrote:
Hi,
Being that -CURRENT's C++ compiler is b0rked, how long will it be until
it's problems have been resolved? I've seen many problems with it
lately, and it kinda made me worried, almost to the point where I
thought a re-install
On Wed, 29 May 2002 09:27:50 MST, Dan Trainor wrote:
Being that -CURRENT's C++ compiler is b0rked, how long will it be until
it's problems have been resolved? I've seen many problems with it
lately, and it kinda made me worried, almost to the point where I
thought a re-install from the
Martin Blapp wrote:
Hi all,
I see this configure failure when using the system gcc3.1 or a newer one from
ports. A version from march works.
configure:3602: checking for XOpenDisplay in -lX11
configure:3624: /usr/local/bin/g++31 -o conftest -g -L/usr/X11R6/lib
conftest.C -lX11
In message [EMAIL PROTECTED], John Baldwin writes:
+ frame = td-td_frame;
+ frame-tf_eax = retval; /* Child returns zero */
+ frame-tf_edx = aux;/* I dunno */
You could always ask about that instead of having a I dunno comment. :)
I think that we no longer
Hi all,
Have you done a 'make world' in the last 24 hours or so? What does this show:
No. And I have tested it now in STABLE to with the gcc32 and gcc31 ports.
Result is the same.
gcc295 in stable, and a march gcc31 port are fine. All other gcc3.x versions
are failing.
ls -l /usr/bin/c++
kthreads are not threads, but, rather, kernel processes..
they have a separate 'proc' structure.
(they are badly named..)
On Wed, 29 May 2002, kai ouyang wrote:
Thank you! I know a little more. From the kthread_create() function, I
find Both 4.x and 5.0 are implemented by fork1(). I am
I would like to know as well cause right now I have made it work under
linux using the driver from sourceforge and a patched pppd supporting
PPPoATM and I would say it works pretty stable under 2.4.18. Maybe it
would get to work under Linux emulation but I have never tried so I
would like to know
On Wed, 29 May 2002, John Baldwin wrote:
On 28-May-2002 Julian Elischer wrote:
Now things are moving again.
Jonathon Mini and I have cleaned up the patches a bit
and fixed the more obvious problems..
from teh point of view of non KSE processes
(that would be all of them at the
On Wed, May 29, 2002 at 05:56:28PM +0200, Martin Blapp wrote:
configure:3602: checking for XOpenDisplay in -lX11
configure:3624: /usr/local/bin/g++31 -o conftest -g -L/usr/X11R6/lib
conftest.C -lX11 15
/var/tmp//ccask2mP.o: In function `main':
On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
9) More gratuitous braces as well as gratuituos ()'s and white space
changes in ithread_schedule() obfuscate the functional diffs.
I guess so though it made it a hell of a lot more readable to me.
That isn't the issue.
On 2002-05-29 00:24 -0700, Peter Wemm wrote:
There is a known bug in UMA where it recurses and calls itself with with
M_WAITOK even if it was explicitly called with M_NOWAIT set. The bug is
real and would cause a panic if we actually ran low on memory at that
point.
Just in case anyone more
Bosko Milekic wrote:
On Tue, May 28, 2002 at 11:32:03PM -0700, Terry Lambert wrote:
Can we get rid of the NULL tests we had to put in when M_WAIT
turned into M_WAITOK?
No. What you see as a bad thing others (including me) see as a good
thing. I _want_ to be able to say: okay, try
:On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
:
: 9) More gratuitous braces as well as gratuituos ()'s and white space
: changes in ithread_schedule() obfuscate the functional diffs.
:
: I guess so though it made it a hell of a lot more readable to me.
:
:That isn't
Warning
Unable to process data:
multipart/mixed;boundary==_NextPart_000_00B0_33B54E8A.C0266E75
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
I agree that as a general rule of thumb it makes sense to commit
whitespace/paren/brace changes separately, but that is ALL it is.
A rule of thumb. It should not be followed blindly, on principle,
if it has an adverse effect
Warning
Unable to process data:
multipart/mixed;boundary==_NextPart_000_00A4_81E07D7A.A0001C56
On Wed, May 29, 2002 at 01:07:01PM -0700, Matthew Dillon wrote:
:On Wed, May 29, 2002 at 11:26:26AM -0700, Julian Elischer wrote:
:
: 9) More gratuitous braces as well as gratuituos ()'s and white space
: changes in ithread_schedule() obfuscate the functional diffs.
:
: I guess so
Hello guys,
I've update May 25 my notebook with a fresh -CURRENT cvsup
source and now when I want to build a new -current on my notebook
I've got repeated build failures.
I've got a lot of time this type of error Illegal instruction - core dumped
with or without -j in buildworld in the
On Wed, 29 May 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Matthew Dillon w
rites:
I agree that as a general rule of thumb it makes sense to commit
whitespace/paren/brace changes separately, but that is ALL it is.
A rule of thumb. It should not be followed
On Wed, 29 May 2002, Matthew Dillon wrote:
I agree that as a general rule of thumb it makes sense to commit
whitespace/paren/brace changes separately, but that is ALL it is.
A rule of thumb. It should not be followed blindly, on principle,
if it has an adverse effect on
:
: Furthermore, it is an extreme and inappropriate imposition on Julian
: to require that he extract all the alleged 'gratuitous braces and
: ()'s)' into a separate commit.
:
:Uh, no it isn't. That is the rules we operate under. This type of
:request comes up _daily_, and is
:having said that,
:In this case the braces in question in ithread_schedule are:
:- } else
:+ } else {
:curthread-td_kse-ke_flags |= KEF_NEEDRESCHED;
:+ }
:
:I tend to always put braces on the else clause if the 'then' clause
:has
Ok I just committed that one on it's own
now back to the real points that jhb raised..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
In message: [EMAIL PROTECTED]
Takanori Watanabe [EMAIL PROTECTED] writes:
: 3. Add following line to configuration file. (Should it be standard?)
: ==
: device cardcom
They should be standard. I have a patch that does this for all the
_if* files in the system, with a bloatage of a
* From Matthew Dillon [EMAIL PROTECTED]
No hold on a minute. Some of us believe that adding those extra
braces and parenthesis makes the code a whole lot more readable. they
are NOT gratuitous in the least, certainly not from my point of view!
When you make the code more
On Wed, 29 May 2002, Julian Elischer wrote:
On Wed, 29 May 2002, John Baldwin wrote:
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
I
:
:When you make the code more readable, you introduce further diffs, and you
:leave no reference against the original code of where the functional changes
:are. Either make the base code cleaned up by committing non-functional
:changes first, or commit against the base code your functional
* From Matthew Dillon [EMAIL PROTECTED]
:
:When you make the code more readable, you introduce further diffs, and you
:leave no reference against the original code of where the functional changes
:are. Either make the base code cleaned up by committing non-functional
:changes first, or
Julian Elischer wrote:
On Wed, 29 May 2002, Julian Elischer wrote:
On Wed, 29 May 2002, John Baldwin wrote:
4) It would be nice if you didn't mix in gratuitous style changes with
actual content changes such as extra braces in else clause of
PROCFS_CTRL_WAIT case in procfs_ctl.c
On Wed, May 29, 2002 at 10:39:08PM +0200, Sebastien Gioria wrote:
Hello guys,
I've update May 25 my notebook with a fresh -CURRENT cvsup
source and now when I want to build a new -current on my notebook
I've got repeated build failures.
I've got a lot of time this type of error Illegal
On Wed, 29 May 2002, Peter Wemm wrote:
ie: it is ok to change this:
if (foo) {
fumble();
futz();
} else
bah;
into
} else {
bah;
}
In this case it's moot because I already did it as a separate commit
but it was changing:
if (foo) {
mumble();
When it comes right down to it, I am getting wholely sick and tired
of people acting like rulez-police and complaining about the most
minor, most insignificant syntactical changes imagineable. The
rest of us developers have better things to do with their time then
to spend it
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
I'm getting the following error on a just built -current, which was a
fresh install of 5.0-CURRENT-20020519-JPSNAP:
installing in lib/XThrStub...
rm -f UIThrStubs.o
LD_LIBRARY_PATH=../../exports/lib cc -c -O -pipe-ansi -pedantic
-Dasm=__asm
-Wall -Wpointer-arith -I../..
On Wed, May 29, 2002 at 11:38:57PM -0500, Peter Schultz wrote:
FWIW: same here yesterday. I have not yet investigated what's up
Wilko
I'm getting the following error on a just built -current, which was a
fresh install of 5.0-CURRENT-20020519-JPSNAP:
installing in lib/XThrStub...
rm -f
Hi !
I am starting to be developer on Fbsd and sometime I was working on 5.0,
then I stopped because of lack of time, and after a while I couldn't build
no more, so I decided to reinstall my development environment.
Install went OK, but startup didn't. I know excatly where the problem is. I
69 matches
Mail list logo
