At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote:
>Here's what I did to get XFree86-4 to build with the base system's
>toolchain in -CURRENT:
I thought I'd try this out. Before starting, I did a cvsup of
all my ports tree.
>a) ports/devel/imake-4:
>
>Replace files/patch-d and files/patch-xthre
I can rlogin to a -CURRENT box as root. However `rsh box id' comes back
with:
Jul 3 00:11:33 box rshd[4916]: root@dragon as rootk: permission denied
(authentication error). cmd='id'
Is PAM getting in the way here or something?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsu
On Tue, 2 Jul 2002, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Jonathan Lemon writes:
> >Essentially, this provides a traversal of the tailq that is safe
> >from element removal, while being simple to drop in to those sections
> >of the code that need updating, as evidenced in the patch b
At 11:01 PM -0700 7/2/02, Matthew Dillon wrote:
> I get just about the same performance for GCC2 as I
> do for GCC3 in the tests I've run so far. It makes
> me wonder what the hell GCC3 is burning all that
> cpu *on*.
One of the guys here at RPI (dec, actually) claims he got
buil
DISTRIBUTORS WANTED:
We're looking for motivated, entrepreneurial people who
would like to be their own boss and earn an executive
6-figure income by this time next year.
Sales or travel industry background a plus, but not necessary.
Would you enjoy earning $1,000 commissions starting this mont
Matthew Dillon wrote:
> I get just about the same performance for GCC2 as I do for GCC3 in
> the tests I've run so far. It makes me wonder what the hell GCC3 is
> burning all that cpu *on*.
SETI @ Home?
8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
:
:
:Andrew Gallatin fixed the problem in kern_sig.c, check it out:
:
:gallatin2002/07/02 19:55:48 PDT
:
Will do tomorrow!
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
:If you can quantify this, it is something we can pass on to the GCC
:folks. They are rather receptive right now due to wanting GCC 3.1.1 to
:be very high quality. Run-time of the compiler isn't anything that can
:be fixed right now -- but if you show how small (but not 3 line trivial)
:program
I just fixed that.. get a new version of kern_sig.c
On Tue, 2 Jul 2002, Matthew Dillon wrote:
> I can get a panic when ^C'ing buildworld on an SMP build of -current:
>
> -Matt
>
> test3# j
> test3# panic: mutex sched lock not owned at
>/FreeB
On Tue, Jul 02, 2002 at 10:53:23PM -0500, Erik Greenwald wrote:
> I took a stab at hunting it down, I think I may've found it in the
> libc_r, not the kern
>
> src/lib/libc_r/uthread/uthread_kern.c, in the neighborhood of line 172,
> the last line of _thread_kern_sched() is
>
> ___longj
Andrew Gallatin fixed the problem in kern_sig.c, check it out:
gallatin2002/07/02 19:55:48 PDT
Modified files:
sys/kern kern_sig.c
Log:
Hold the sched lock across call to forward_signal() in tdsignal() to
keep SMP systems from panic'ing when ^C'ing an app
sugge
I can get a panic when ^C'ing buildworld on an SMP build of -current:
-Matt
test3# j
test3# panic: mutex sched lock not owned at
/FreeBSD/FreeBSD-current/src/sys/kern/subr_smp.c:126
cpuid = 1; lapic.id =
Debugger("panic")
Stopped at
# Cc acpi-jp
From: Shizuka Kudo <[EMAIL PROTECTED]>
Subject: ASUS CUSL2 panic on acpi
Date: Tue, 2 Jul 2002 11:55:18 -0700 (PDT)
Message-ID: <[EMAIL PROTECTED]>
> Dear all,
>
> I wonder if anyone experienced the same issue as mime. I have an ASUS CUSL2 running
>-current and
> starting about th
On Wed, 3 Jul 2002, John Baldwin wrote:
>
> Erm, I thought I changd signotify() to require sched_lock and made the
> second half of psignal() (the whole case statement) lock sched_lock.
> Did you change that? (To Julian)
psignal as a whole hasn't existed in the KSE tree since December.
I mu
You were possibly on the right track but we got the answer already :-)
there was a debug statement left in queue.h
that was breaking some of the queues in libc_r
possibly where the thread was taken off the run queue.
Now the very important thing is that you keep looking
and hacking :-)
On Tue,
On 03-Jul-2002 Andrew Gallatin wrote:
>
> Julian Elischer writes:
> > >
> > > However, it does seem a bit silly, as we end up dropping
> > > and-reaquiring the sched lock quite a few times:
> >
> > That's why I just asked you to test the concept..
> > If I know that just aquiring it here
> BTW feel free to spend some time helping try figire out why libc_r
> is bombing out. It's not an exclusive club :-)
>
I took a stab at hunting it down, I think I may've found it in the
libc_r, not the kern
src/lib/libc_r/uthread/uthread_kern.c, in the neighborhood of line 172,
the last line of
Julian Elischer writes:
> >
> > However, it does seem a bit silly, as we end up dropping
> > and-reaquiring the sched lock quite a few times:
>
> That's why I just asked you to test the concept..
> If I know that just aquiring it here is ok,
> (I presume you tried doing some work like t
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes:
> /home/des/tinderbox/tinderbox.sh: /usr/bin/nice -n 20: not found
Bah. I am an idiot.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
ignore this Matt.. it was on ia32.
On Tue, 2 Jul 2002, Julian Elischer wrote:
> we seem pretty solid on ia32
> ^Z and then fg will sometimes kill teh process instead of forgrounding it
> though.
>
> (I aborted several buildworlds that way accidentally)
>
> Andrew's panic seems SMP specific t
On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> Julian Elischer writes:
> > try this:
> >
> > in tdsignal, (kern_sig.c)
> > take a lock on schedlock and release it again, just around the call to
> > forward-signal()
> >
> > forward_signal(c4445540) at forward_signal+0x1a
> > tdsignal(
U sys/kern/vfs_syscalls.c
U sys/sys/_mutex.h
U sys/sys/mount.h
U sys/sys/queue.h
U sys/vm/uma_core.c
U usr.bin/locate/locate/locate.1
U usr.sbin/sysinstall/devices.c
U usr.sbin/sysinstall/dist.h
U usr.sbin/sysinstall/menus.c
/home/des/tinderbox/tinderbox.sh: /usr/bin/nice -n 20: not found
To Unsu
we seem pretty solid on ia32
^Z and then fg will sometimes kill teh process instead of forgrounding it
though.
(I aborted several buildworlds that way accidentally)
Andrew's panic seems SMP specific though..
you may check if there is somethign different between ia32 and alpha
on whether it holds
AHH I assumed it was alpha...
On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> Matthew Dillon writes:
> > :...
> > : > > >
> > : > >
> > : > > This is nearly 100% for me. But only on MP boxes. On my uniprocessor
> > : > > alpha, things work just fine. Oh.. hmm.. I'm not sure if I have
Julian Elischer writes:
> try this:
>
> in tdsignal, (kern_sig.c)
> take a lock on schedlock and release it again, just around the call to
> forward-signal()
>
> forward_signal(c4445540) at forward_signal+0x1a
> tdsignal(c4445540,2,2) at tdsignal+0x182
> psignal(c443d558,2) at psignal+
Matthew Dillon writes:
> :...
> : > > >
> : > >
> : > > This is nearly 100% for me. But only on MP boxes. On my uniprocessor
> : > > alpha, things work just fine. Oh.. hmm.. I'm not sure if I have
> : > > witless compiled in there..
> : >
> : > which is almost 100%,? the ^Z killin
try this:
in tdsignal, (kern_sig.c)
take a lock on schedlock and release it again, just around the call to
forward-signal()
forward_signal(c4445540) at forward_signal+0x1a
tdsignal(c4445540,2,2) at tdsignal+0x182
psignal(c443d558,2) at psignal+0x3c8
hopefully this will not be called with the sc
On Tue, Jul 02, 2002 at 06:06:27PM -0700, Matthew Dillon wrote:
> However, since you asked, I will say that I am not at all impressed with
> GCC3 vs GCC2. I've looked at a considerable amount of code with objdump
> between -stable and -current and GCC3 doesn't really seem to improve
>
:...
: > > >
: > >
: > > This is nearly 100% for me. But only on MP boxes. On my uniprocessor
: > > alpha, things work just fine. Oh.. hmm.. I'm not sure if I have
: > > witless compiled in there..
: >
: > which is almost 100%,? the ^Z killing the process, or ^C killing the
: > machine?
:
Something has messed up natd. If I don't have the
punch_fw option in the /etc/natd.conf file it eventuially
core dumps with a bus error. I think this started JUST
BEFORE the KSE commit.
/etc/natd.conf: ( note that this works. comment out the
punch_fw option and it c
:You really cannot say this -- GCC 3.1 does things 2.95 doesn't. 3.1 has
:a totally rewritten code scheduler. People can't get Pentium-4 and
:Athlon tbird specific optimizations for free.
:
:You almost seem to be making a claim on the quality of generated code,
:vs. just the run-time of the com
Julian Elischer writes:
>
>
> On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> >
> > Julian Elischer writes:
> > >
> > >
> > > On Tue, 2 Jul 2002, Andrew Gallatin wrote:
> > >
> > > >
> > > > An easy way to induce a panic w/a post KSE -current is to ^C gdb as it
> > > >
I might add that phk added the itterators in 1.14, but since he's off
getting married we can't ask him whether he thinks the 'safe' versions are
OK..
Yeehaaa open season..
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> Julian Elischer writes:
> >
> >
> > On Tue, 2 Jul 2002, Andrew Gallatin wrote:
> >
> > >
> > > An easy way to induce a panic w/a post KSE -current is to ^C gdb as it
> > > starts on an SMP machine:
> >
> > A possibly related breakage
÷ÁÛÅ ÐÒÅÄÐÒÉÑÔÉÅ ÅÝÅ ÎÅ ×ÎÅÓÅÎÏ × ËÁÔÁÌÏÇ RTU.ru?
üÔÏ ÎÅ ÐÏÚÄÎÏ ÓÄÅÌÁÔØ ÓÅÊÞÁÓ http://www.rtu.ru/registration/
äÏÐÕÓËÁÅÔÓÑ ÒÅÇÉÓÔÒÁÃÉÑ ÐÒÅÄÐÒÉÑÔÉÊ, ÎÅ ÉÍÅÀÝÉÈ Ó×ÏÅÇÏ ÓÁÊÔÁ.
ðÏÄÒÏÂÎÏÓÔÉ ÎÁ www.rtu.ru/about/
áÄÍÉÎÉÓÔÒÁÔÏÒ ËÁÔÁÌÏÇÁ
www.rtu.ru
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
David O'Brien wrote:
> On Mon, Jul 01, 2002 at 08:14:46PM -0700, Matthew Dillon wrote:
> > My conclusion is that softupdates is working fine and (A) the new GCC
> > is a whole lot less efficient then the old GCC
>
> You really cannot say this -- GCC 3.1 does things 2.95 doesn't. 3.1 has
Julian Elischer wrote:
> I would add that there is no occurance I could find in the kernel that
> assumes this.. (except the bad one I mentionned before in my own code) (at
> least it all runs fine with -1 put in that location on deletion), so I
> must not be alone in thinking that one shouldn't r
Julian Elischer wrote:
>
> On Tue, 2 Jul 2002, Terry Lambert wrote:
>
> > Garrett Wollman wrote:
[ ... ]
> > > reverted for compatibility with the other implementations of queue(3).
>
> I would by the way argue that the statement "The queue macros always
[ ... ]
For the record, Julian is resp
On Tue, 2 Jul 2002, Julian Elischer wrote:
Having just re-read my own mail
I think I agree with jonathan now..
I think we neeed to either:
1/ augment the man page giving an example of how to do
multiple removes from a list/queue.
2/ Explain in detail why using _FOREACH()
is bad for this,
On Mon, Jul 01, 2002 at 08:14:46PM -0700, Matthew Dillon wrote:
> My conclusion is that softupdates is working fine and (A) the new GCC
> is a whole lot less efficient then the old GCC
You really cannot say this -- GCC 3.1 does things 2.95 doesn't. 3.1 has
a totally rewritten code schedu
On Tue, 2 Jul 2002, Garrett Wollman wrote:
> <
>said:
>
> > I would by the way argue that the statement "The queue macros always
> > guaranteed that traversal was safe in the presence of deletions" to be
> > false. Nowhere was this guaranteed, in fact the Manual page goes to
> > lengths to NO
On Tue, 2002-07-02 at 16:42, Julian Elischer wrote:
>
>
> On Tue, 2 Jul 2002, Wesley Morgan wrote:
>
> > KDE is working fine. GIMP & GNUCash are the only two "gnome" apps I am
> > using, and they both work. "Everybuddy" now works... In short, it all
> > seems to work. I am using rev 1.225 of pr
< said:
> I would by the way argue that the statement "The queue macros always
> guaranteed that traversal was safe in the presence of deletions" to be
> false. Nowhere was this guaranteed, in fact the Manual page goes to
> lengths to NOT do this..
I'm fairly certain that this *was* documented s
On Tue, 2 Jul 2002, Terry Lambert wrote:
> Garrett Wollman wrote:
> > < said:
> > > Essentially, this provides a traversal of the tailq that is safe
> > > from element removal, while being simple to drop in to those sections
> > > of the code that need updating, as evidenced in the patch below.
Julian Elischer writes:
>
>
> On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> >
> > An easy way to induce a panic w/a post KSE -current is to ^C gdb as it
> > starts on an SMP machine:
>
> A possibly related breakage is:
>
> type ^Z while doing "make buiildworld" (or something sim
On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> An easy way to induce a panic w/a post KSE -current is to ^C gdb as it
> starts on an SMP machine:
A possibly related breakage is:
type ^Z while doing "make buiildworld" (or something similar).
when you type 'fg' there is a high change the buil
Garrett Wollman wrote:
> < said:
> > Essentially, this provides a traversal of the tailq that is safe
> > from element removal, while being simple to drop in to those sections
> > of the code that need updating, as evidenced in the patch below.
>
> The queue macros always guaranteed that traversa
I have some new numbers. I finally was able to run the test on
-current with an SMP build. All the results are below. It seems to
confirm my hypothesis that the new cpu-hungry gcc is the main source
of the timing differences.
-Matt
On Tue, 2 Jul 2002, Julian Elischer wrote:
> Dan is there a chance that before you upgrade, you see if you can get the
> test program to pass all the tests? If we can have one that passes on a
> pre KSE system it will help us considerably.. it seems to fail
> on the last 3 tests even pre-KSE. (m
On Tue, 2002-07-02 at 16:07, Julian Elischer wrote:
> ok, so you are saying that GNOME stuff works fine?
> What do yuo have running and is there still anything that does the wrong
> thing?
I just did an update of -CURRENT about 4 hours ago, and everything in
GNOME works fine except nautilus. Nau
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
> What do people think about adding the following macro to ?
> (I don't care much about the name, just the functionality)
>
> #define TAILQ_FOREACH_TMP(var, tmp, head, field) \
> for ((var) = TAILQ_FIRST((head));
KDE is working fine. GIMP & GNUCash are the only two "gnome" apps I am
using, and they both work. "Everybuddy" now works... In short, it all
seems to work. I am using rev 1.225 of proc.h and 1.48 of queue.h. Last
cvsup was Jul 1 17:13 MDT.
> ok, so you are saying that GNOME stuff works fine?
> Wha
can you give details of your setup?
On Tue, 2 Jul 2002, Andrey A. Chernov wrote:
> I notice on just updated -current and yesterday's -current too: after few
> hours of work spiral death slowly happens: system acts like load averege
> is about 80 while it is really 0.03, it ends with no ping res
After reading this... I got to thinking, and I copied the old headers into
the wrong place. After rebuilding, it works fine :)... That's what I get
for doing it at 2am! My fault, you guys could have fixed this almost
immediately except for some bad info from me.
> Good idea.
>
> Unforunatly someon
On Tuesday 02 July 2002 12:57 am, Julian Elischer wrote:
> Ok so Usability for the average command line user is
> very good. David Xu tracked down a problem that was
> eluding me with SMP machines. Matt is tracking down
> something that may be giving some instability
> but may also be related to w
On Tue, 2 Jul 2002, Wesley Morgan wrote:
> KDE is working fine. GIMP & GNUCash are the only two "gnome" apps I am
> using, and they both work. "Everybuddy" now works... In short, it all
> seems to work. I am using rev 1.225 of proc.h and 1.48 of queue.h. Last
> cvsup was Jul 1 17:13 MDT.
ok so
An easy way to induce a panic w/a post KSE -current is to ^C gdb as it
starts on an SMP machine:
# gdb -k /var/crash/kernel.1 /var/crash/vmcore.1
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
What date -CURRENT are you upgrading from? Are you doing a proper
`make world', or short cutting the procedure?
On Tue, Jul 02, 2002 at 03:53:18PM +0400, Andrey A. Chernov wrote:
> It seems some lib*++ is missing:
>
> ...
> c++ -O -pipe -march=pentiumpro
>-I/usr/src/gnu/usr.bin/gperf/../.
< said:
> Essentially, this provides a traversal of the tailq that is safe
> from element removal, while being simple to drop in to those sections
> of the code that need updating, as evidenced in the patch below.
The queue macros always guaranteed that traversal was safe in the
presence of del
After updating my SuperMicro 370DLE to today's sources, I'm seeing
this message scroll repeatedly across my serial console (for different
values of N in the range 20-3f ):
ACPI-0988: *** Error: AcpiEvGpeDispatch: No handler or method for GPE[N], disabling
event
I've appended the boot log.
C
Dan is there a chance that before you upgrade, you see if you can get the
test program to pass all the tests? If we can have one that passes on a
pre KSE system it will help us considerably.. it seems to fail
on the last 3 tests even pre-KSE. (may be compiler dependent).
I have reports that K
Dear all,
I wonder if anyone experienced the same issue as mime. I have an ASUS CUSL2 running
-current and
starting about three days ago, it panic when acpi is autoloaded. If I unset acpi_load
at the boot
prompt, the machine works fine.
Here's the panic message and a trace for those interested
I haven't been able to use dump since the recent UFS2 changes.
the command i use is "dump 0fua /dev/nsa0 /dev/da0s1e"
I get lots of this :
DUMP: read error from /dev/da0s1e: Invalid argument: [sector -1555955710]: count=-1
DUMP: read error from /dev/da0s1e: Invalid argument: [sector -1555955709]
On Tue, Jul 02, 2002 at 12:58:24PM -0700, Julian Elischer wrote:
>
> On Tue, 2 Jul 2002, Jonathan Lemon wrote:
>
> > What do people think about adding the following macro to ?
> > (I don't care much about the name, just the functionality)
> >
> > #define TAILQ_FOREACH_TMP(var, tmp, head, fi
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
> On Tue, Jul 02, 2002 at 12:58:24PM -0700, Julian Elischer wrote:
> >
> > On Tue, 2 Jul 2002, Jonathan Lemon wrote:
> >
> > > What do people think about adding the following macro to ?
> > > (I don't care much about the name, just the functionality)
I put the -1 under the conditional
so it should be 'gone' now.
we'll see it makes a difference.
On Tue, 2 Jul 2002, Matthew Dillon wrote:
>
> :...
> :another queue using the same link. There are other places in libc_r
> :where we do re-use the same link (remove from one list and add to
> :anot
ok, so you are saying that GNOME stuff works fine?
What do yuo have running and is there still anything that does the wrong
thing?
On Tue, 2 Jul 2002, Wesley Morgan wrote:
> After reading this... I got to thinking, and I copied the old headers into
> the wrong place. After rebuilding, it works f
I just removed the extra debug line in queue.h
that set the "next" pointer to -1 then the element was removed.
Since I was told that the problem still occurs with an old queue.h
I don;t think that that will fix it but we might as well try it
again with this change.
On Tue, 2 Jul 2002, Da
On Tue, 2 Jul 2002, Julian Elischer wrote:
> Good idea.
>
> Unforunatly someone tried to complie a libc_r with the old queue.h and it
> had the same problem (or so they said).
Well, it certainly looks wrong to use TAILQ_REMOVE inside of
TAILQ_FOREACH, so either libc_r should be changed or queue.
:...
:another queue using the same link. There are other places in libc_r
:where we do re-use the same link (remove from one list and add to
:another), but roll our own loop in that case:
:
: for (p = TAILQ_FIRST(&q); p != NULL; p = p_next) {
: p_next = TAILQ_NEXT(p, p_qe);
:
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
> In article [EMAIL PROTECTED]> you
>write:
> >In message <[EMAIL PROTECTED]>, Ju
> >lian Elischer writes:
> >>The big problem at the moment is that something in the
> >>source tree as a whole, and probably something that came in with KSE
> >>is stopping
Interesting..
Is this SMP or UP?
On Tue, 2 Jul 2002, Andrey A. Chernov wrote:
> I notice on just updated -current and yesterday's -current too: after few
> hours of work spiral death slowly happens: system acts like load averege
> is about 80 while it is really 0.03, it ends with no ping respo
Good idea.
Unforunatly someone tried to complie a libc_r with the old queue.h and it
had the same problem (or so they said).
On Tue, 2 Jul 2002, Ian Dowse wrote:
> In message <[EMAIL PROTECTED]>, Ju
> lian Elischer writes:
> >The big problem at the moment is that something in the
> >source tre
On 2002.07.02 17:56:28 +, Juan Francisco Rodriguez Hervella wrote:
> Im a bit corious about what's the meaning of "UMA".
>
> Thanks and sorry fot this simple question :)
UMA is the "Universal Memory Allocator", written by Jeff Roberson.
It's the memory manager and things like malloc(9) make
I'm still getting these crashes:
Panicstring: bremfree: bp 0xc772a840 not locked
and:
Panicstring: Most recently used by kqueue
On two very different systems (both PC's). I have more info in
PR 38438. Is this happening to other people?
-Seth
To Unsubscribe: send mail to [EMAIL PROTECTED]
Martin Faxer escribió:
> On 2002.07.02 16:28:10 +, Michael Hostbaek wrote:
> > I have problems getting my sound card functioning under -CURRENT. (While
> > it was working perfect under -STABLE).
> >
> > I simply added 'device pcm' to the kernel config, when booting on new
> > kernel I get lot
In message <[EMAIL PROTECTED]>, Jonathan Lemon writes:
>Essentially, this provides a traversal of the tailq that is safe
>from element removal, while being simple to drop in to those sections
>of the code that need updating, as evidenced in the patch below.
Note that this of course is not "safe
On Tuesday, July 2, 2002, at 10:54 AM, Jonathan Lemon wrote:
> What do people think about adding the following macro to ?
> (I don't care much about the name, just the functionality)
>
Looks great. How about TAILQ_FOREACH_SAFE?
Thanks, I'm going to put this in our embedded version of queue.h
What do people think about adding the following macro to ?
(I don't care much about the name, just the functionality)
#define TAILQ_FOREACH_TMP(var, tmp, head, field) \
for ((var) = TAILQ_FIRST((head));\
(var) && (((t
On 2002.07.02 16:28:10 +, Michael Hostbaek wrote:
> I have problems getting my sound card functioning under -CURRENT. (While
> it was working perfect under -STABLE).
>
> I simply added 'device pcm' to the kernel config, when booting on new
> kernel I get lots of errors like this:
>
> port 0
I have problems getting my sound card functioning under -CURRENT. (While
it was working perfect under -STABLE).
I simply added 'device pcm' to the kernel config, when booting on new
kernel I get lots of errors like this:
port 0x1400-0x14ff irq 5 at device 8.0 on pci0
../../../vm/uma_core.c:1333
> Is there any particular reason for using -current for that? The
> problem is that -current is in horrible state now (gcc 3.1, KSE-III
> and so on), so that I'd suggest to use -stable branch or -current
> sources just before gcc 3.1 import.
>
Well there are two things going on. My employer wan
In article [EMAIL PROTECTED]> you
write:
>In message <[EMAIL PROTECTED]>, Ju
>lian Elischer writes:
>>The big problem at the moment is that something in the
>>source tree as a whole, and probably something that came in with KSE
>>is stopping us from successfully compiling a working libc_r.
>>(a
Hi!
I have some questions about it.
The first one is, when I compiled GEOM into the kernel, will physical
disks be controlled by it already? Or does it apply to md mounted
devices yet?
And the second is, when will it be officially activated? Seems to work
fine yet (toying around with it).
T
Hi,
I dunno if this is w.r.t. the KSE thingie going on, but my machine got
rebooted a while back with this error. I am presently in the old kernel.
The syslog shows this
Jul 2 18:32:24 calvin syslogd: kernel boot file is /boot/kernel.old/kernel
Jul
On Mon, 1 Jul 2002, Matthew Dillon wrote:
> SMP builds are still producing panics every 2-4 buildworlds after the
> KSE commit, I'm still trying to track that down. But I was able to
> complete the softupdates/non-softupdates test with a UP build of
> -current:
>
> with softupdat
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> I just upgrade to recent -current sshd and found that
> PasswordAuthentication not works anymore (always fails, with right
> password too). I not yet dig deeper at this moment, just FYI.
Try this:
===
It seems some lib*++ is missing:
...
c++ -O -pipe -march=pentiumpro
-I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf
-o gperf bool-array.o gen-perf.o hash-table.o iterator.o key-list.o list-node.o main.o
new.o options.o read-line.o trace.o vectors.o ver
I just upgrade to recent -current sshd and found that
PasswordAuthentication not works anymore (always fails, with right
password too). I not yet dig deeper at this moment, just FYI.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freeb
I notice on just updated -current and yesterday's -current too: after few
hours of work spiral death slowly happens: system acts like load averege
is about 80 while it is really 0.03, it ends with no ping response /
reboot required.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send m
hi
I tried those libc_r test programs under about a month old CURRENT, and output
seems to be identical to yours (didn't try gdb on it but it gives same
guard_b segfaults and same programs fail)
here's the output:
Test static library:
--
In message <[EMAIL PROTECTED]>, Ju
lian Elischer writes:
>The big problem at the moment is that something in the
>source tree as a whole, and probably something that came in with KSE
>is stopping us from successfully compiling a working libc_r.
>(a bit ironic really).
Is the new
(elm)->
Hi,
At 22:55 1/7/02, George V. Neville-Neil wrote:
> When picobsd goes to build the libraries etc. it chokes on the csu
>stuff: [etc]
First, I'd echo what someone else said about avoiding -current right now.
Second, you may have better luck if you buildworld before attempting a
picobsd build.
On Tue, 2 Jul 2002, Sid Carter wrote:
> Hi,
>
> Some of my applications are failing to start on my recently compiled
> kernel and world.
[...]
> pid 89065 (mozilla-bin), uid 1001: exited on signal 11 (core
dumped)
>
>
> FreeBSD calvi
BTW feel free to spend some time helping try figire out why libc_r
is bombing out. It's not an exclusive club :-)
On Tue, 2 Jul 2002, Julian Elischer wrote:
>
> Ok so Usability for the average command line user is
> very good. David Xu tracked down a problem that was
> eluding me with SMP mac
On Tue, 2 Jul 2002, Julian Elischer wrote:
>
> Ok so Usability for the average command line user is
> very good. David Xu tracked down a problem that was
> eluding me with SMP machines. Matt is tracking down
> something that may be giving some instability
> but may also be related to what Dav
Is there any particular reason for using -current for that? The
problem is that -current is in horrible state now (gcc 3.1, KSE-III
and so on), so that I'd suggest to use -stable branch or -current
sources just before gcc 3.1 import.
-Maxim
"George V. Neville-Neil" wrote:
>
> Hey Folks,
>
>
Ok so Usability for the average command line user is
very good. David Xu tracked down a problem that was
eluding me with SMP machines. Matt is tracking down
something that may be giving some instability
but may also be related to what David found.
He however gets the award for most confusing
de
An Tue, Jul 02, 2002 at 10:50:43AM +0200, Sheldon Hearn schreib :
> On (2002/07/02 14:13), Sid Carter wrote:
>
> > Anything obvious I missed ?
>
> Yes. You haven't been reading your mail. :-)
>
> There's known instability at present, that is believed to relate to
> changes made to libc_r in th
On (2002/07/02 14:13), Sid Carter wrote:
> Anything obvious I missed ?
Yes. You haven't been reading your mail. :-)
There's known instability at present, that is believed to relate to
changes made to libc_r in the last month, or to the recent KSE update
and its impact on libc_r.
Ciao,
Sheldon
1 - 100 of 102 matches
Mail list logo
