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:
Hi,
Some of my applications are failing to start on my recently compiled
kernel and world.
These are the errors I get:
pid 944 (xlock), uid 1001: exited on signal 11
pid 998 (superquadrics), uid 1001: exited on signal 11 (core dumped)
pid 1253 (s
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
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
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
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 Dav
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, 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
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
(elm)->
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 m
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
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 ver
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
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
"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 softupdat
> 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
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
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
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 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
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
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
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]
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
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 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
:...
: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.
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
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
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 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
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)
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
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 interested
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
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
< 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
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
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
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
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
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));
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, 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
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:
> < 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
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
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, 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.
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/../.
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
< 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, 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
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 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, 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 resp
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
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
÷ÁÛÅ ÐÒÅÄÐÒÉÑÔÉÅ ÅÝÅ ÎÅ ×ÎÅÓÅÎÏ × ËÁÔÁÌÏÇ RTU.ru?
üÔÏ ÎÅ ÐÏÚÄÎÏ ÓÄÅÌÁÔØ ÓÅÊÞÁÓ http://www.rtu.ru/registration/
äÏÐÕÓËÁÅÔÓÑ ÒÅÇÉÓÔÒÁÃÉÑ ÐÒÅÄÐÒÉÑÔÉÊ, ÎÅ ÉÍÅÀÝÉÈ Ó×ÏÅÇÏ ÓÁÊÔÁ.
ðÏÄÒÏÂÎÏÓÔÉ ÎÁ www.rtu.ru/about/
áÄÍÉÎÉÓÔÒÁÔÏÒ ËÁÔÁÌÏÇÁ
www.rtu.ru
To Unsubscribe: send mail to [EMAIL PROTECTED]
wi
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
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
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
> > > >
: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
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
:...
: > > >
: > >
: > > 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?
:
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 sc
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
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+
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
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
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
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(
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
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
> 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
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 mu
# 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
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
sugge
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
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
: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
:
:
: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 mont
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
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
1 - 100 of 102 matches
Mail list logo
