On Mon, 1 Jul 2002, Daniel Eischen wrote:
On Mon, 1 Jul 2002, Julian Elischer wrote:
I think that gets us a LOT closer!
Total tests 212, passed 212, failed 0
ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on
signal 11 (core dumped)
Jul 2 01:52:52 ref4
On Mon, 1 Jul 2002, Julian Elischer wrote:
On Mon, 1 Jul 2002, Daniel Eischen wrote:
On Mon, 1 Jul 2002, Julian Elischer wrote:
I think that gets us a LOT closer!
Total tests 212, passed 212, failed 0
ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited
On Mon, 1 Jul 2002, Christian Weisgerber wrote:
I would like to clean up the last instances of (int)signal(...) in
the tree. Any objection to the changes below?
No, but ...
Other occurrences not worth touching:
- contrib/opie/opieftpd.c: contrib, not used
- libexec/bootpd/bootpd.c:
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,
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 the last
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
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,
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 David
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
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 calvin
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.
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
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:
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
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
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
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
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).
In article local.mail.freebsd-current/[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
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:
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 softupdates
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 wants
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:
ESS Technology Maestro-2E port 0x1400-0x14ff irq 5 at device 8.0 on pci0
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:
ESS
What do people think about adding the following macro to sys/queue.h?
(I don't care much about the name, just the functionality)
#define TAILQ_FOREACH_TMP(var, tmp, head, field) \
for ((var) = TAILQ_FIRST((head));\
On Tuesday, July 2, 2002, at 10:54 AM, Jonathan Lemon wrote:
What do people think about adding the following macro to sys/queue.h?
(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
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 from
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 lots of
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
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 use
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 tree as a
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
In article local.mail.freebsd-current/[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
:...
: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, 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.h
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
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,
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
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
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 sys/queue.h?
(I don't care much about the name, just the functionality)
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 sys/queue.h?
(I don't care much about the name, just the functionality)
#define TAILQ_FOREACH_TMP(var, tmp, head,
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]:
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
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
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.
On Tue, 2 Jul 2002 09:54:02 -0500, Jonathan Lemon [EMAIL PROTECTED] 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
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
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 cen you
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 what
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 someone
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?
What do
On Tue, 2 Jul 2002, Jonathan Lemon wrote:
What do people think about adding the following macro to sys/queue.h?
(I don't care much about the name, just the functionality)
#define TAILQ_FOREACH_TMP(var, tmp, head, field) \
for ((var) =
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.
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. (may
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
Garrett Wollman wrote:
On Tue, 2 Jul 2002 09:54:02 -0500, Jonathan Lemon [EMAIL PROTECTED] 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
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 build
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 similar).
On Tue, 2 Jul 2002, Terry Lambert wrote:
Garrett Wollman wrote:
On Tue, 2 Jul 2002 09:54:02 -0500, Jonathan Lemon [EMAIL PROTECTED] 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
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
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
On Tue, 2 Jul 2002 16:07:36 -0700 (PDT), Julian Elischer [EMAIL PROTECTED] 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
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 proc.h and 1.48
On Tue, 2 Jul 2002, Garrett Wollman wrote:
On Tue, 2 Jul 2002 16:07:36 -0700 (PDT), Julian Elischer [EMAIL PROTECTED]
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
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
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,
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 responding to
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 rely
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
a
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 is:
type ^Z
: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
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
:...
:
:
: 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?
:
:^C killing
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
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
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 killing the process, or ^C
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+0x3c8
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
: witless
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
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
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(c4445540,2,2) at
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
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 this)
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
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
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 is ok,
(I
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 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 must
# 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 three days
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
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
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
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
: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)
:
:
: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
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
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
96 matches
Mail list logo
