others have seen this one too
and the common element is that it's always in
setrunqueue() called from an interrupt.
it is also often via cv_*SOMETHING*()
I Thought we had cleared these up but apparently not :-/
On Sun, 30 Jun 2002, Matthew Dillon wrote:
>Got another one. Different panic,
On Sun, 30 Jun 2002, Matthew Dillon wrote:
>Got another one. Different panic, same place.
>
> panic: setrunqueue: bad thread state
> cpuid = 0; lapic.id = 0100
> Debugger("panic")
> Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c02ec2ba) at Debugger
), because
> > there
> > is a race in softclock() and callout_stop(), when cv_timedwait_end() losts a
> > race, it means that that thread is already running(wokenup by another
> > thread),
> > when you setrunqueue() it, of course it will panic.
> > in cv_timedwait_end(
It COULD be related to KSE if I've broken some signal delivery types..
do we have a signal guru in the house that can run a diagnostic on
signals?
On Sun, 30 Jun 2002, Bill Huey wrote:
> On Mon, Jul 01, 2002 at 07:11:31AM +0200, Michael Nottebrock wrote:
> > Program received signal SIGSEGV, Se
My guess is that it's relying on getting a signal for pre-emtion
and it's not arriving due to KSE breakage.
On Mon, 1 Jul 2002, Wesley Morgan wrote:
> I see this problem too. Luckily I have my entire KDE and QT system build
> with debugging symbols... However, the problem is definitely in the
>
Can someone please check out a libc_r tree as of 3 days ago
and try that...
There was a commit in libc_r/uthreads 2 days ago that might be relevant.
failing that, can someone try newly compiled utilities on an older pre-KSE
kernel?
We need to eliminate one of these two changes...
I think it's l
Who's doing UPDATING now?
can someone who is allowed to commit to it put in a note that right now
might be a bad time to upgade if you want to use anything that uses
libc_r. Either libc_r or KSE is causing problems. I don't yet know which.
Things that use libc_r include KDE and GNOME apparentl
Jeff , (current included because it may be an interesting answer)
As you know I'm using UMA to allocate threads and cache them.
The 'constructor methods allow me to allocated threads that have been
pre-set up with thread stacks and other special items.
When they are being cached they still h
I just cvsup'd but when I do a "make buildworld" get:
[...]
[stuff that scrolled off]
[...]
Warning: this is the location of the previous definition
In file included from
/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/att.h:22,
from
/usr/obj/usr/src/i386/usr/s
ot of the names in libc_r look awfully familliar
from the KSE code.. (this shouldn;t be possible but
> Hope some of this is useful to anyone out there!
not on its own, but as a part of a developing picture.
>
> On Sun, 30 Jun 2002, Julian Elischer wrote:
>
> > Can someone
the question is:
did you update both kernel and userland?
On Mon, 1 Jul 2002, NAKAJI Hiroyuki wrote:
> > In <[EMAIL PROTECTED]>
> > Marc Recht <[EMAIL PROTECTED]> wrote:
>
> > Can someone please check out a libc_r tree as of 3 days ago
> > and try that...
> >
> > There was a commit i
looks like 2 processors runing the ddb at the same time...
On Mon, 1 Jul 2002, Matthew Dillon wrote:
> I've been doing buildworld tests on an SMP build, 2-cpu 2550 w/ 2G of
> ram configured. It gets through two or three builds and then crashes.
>
> Unfortunately the crash seems to
I have seen this an dhoped that fixing some of the less scary ones would
fix it too..
^Z seems to occasionally kill the (or one of) process instead.
I have not figured it out..
Peter, did you see the mail I forwarded to you regarding the
condvar/msleep race?
I was hoping for a second opinion.
On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > the question is:
> > did you update both kernel and userland?
>
> This bug is not related to in-kernel KSE code (but, maybe related to
> header files com
is there any chance you can try compile a new libc_r but with old versions
of proc.h and queue.h in the system?
On Mon, 1 Jul 2002, Andrey A. Chernov wrote:
> On Mon, Jul 01, 2002 at 10:26:22 -0700, Julian Elischer wrote:
> > the question is:
> > did you update both kern
I have some debug stuff added for TAILQs
theoretically it should be defined out but
I don't trust theory :-)
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> > is there any chance you can try compile a new libc_r but with old versi
I don't change any of those.
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> I'd suspect that it is something to do with the layout of
> the fpregs, mcontext or something like that. Libc_r mucks
> about in jmp_buf (userland) and ucontext/mcontext, so anything
> that changed those would cause prob
can you try compiling a new libc_r with th efollowing change suggested by
Dan Eischen:
--begin quote:
I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
3 days ago (lib/libc_r/uthread/...). You can try reverting those
changes and go back to revisions 1.18 and 1.11 respecti
rning, it had no effect ... Unless you would
> like me to try an old kernel with it
>
> On Mon, 1 Jul 2002, Julian Elischer wrote:
>
> > can you try compiling a new libc_r with th efollowing change suggested by
> > Dan Eischen:
> >
> > --begin quo
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> I also made changes to uthread_sigpending.c and uthread_sigsuspend.c
> 3 days ago (lib/libc_r/uthread/...). You can try reverting those
> changes and go back to revisions 1.18 and 1.11 respectively.
It seems that you have been exhonorated..
I gue
On Mon, 1 Jul 2002, Daniel Eischen wrote:
> I'm not sure. I would be interested in seeing any warnings from building
> new libc_r. The only places I can think of are the queues (with the
> QMD debug defined, that would definitely cause problems), but that
> seems to have been ruled out also w
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> Someone can also try going into lib/libc_r/test and running the
> tests in there, to see if even simple threaded programs are borken
> or not.
A
cool
I didn't know they are there!
heres what happens when it is run (After fixing typos)
make: don'
turned out to be minor.. see other mail
On Mon, 1 Jul 2002, Julian Elischer wrote:
>
>
> On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > I'm not sure. I would be interested in seeing any warnings from building
> > new libc_r. The only places I can thin
On Mon, 1 Jul 2002, Daniel Eischen wrote:
>
> > mutex_d (**hangs here**)
>
> This one takes quite a long time to run. Run it by hand and you'll
> see if it's really hanging or not.
you're not wrong!
it takes ages.. (still running in another window)
false al
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 kernel: pid 334 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:52 ref4 kernel: pid 338 (g
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
&g
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
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
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
> el
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
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
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
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
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 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, 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
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.
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
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, 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 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
schedlock already locked
if we panic becasue we already own it, it gets more difficult..
On Tue, 2 Jul 2002, Andrew Gallatin wrote:
>
> Julian Elischer writes:
> >
> >
> > On Tue, 2 Jul 2002, Andrew Gallatin wrote:
> >
> &
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
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_signa
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'
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
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 Wed, 3 Jul 2002, Bruce Evans wrote:
> On Tue, 2 Jul 2002, Julian Elischer wrote:
>
> Maybe just remove the foot-shooting that releases it?
Yes I'm rationalising it at the moment..
turns out that just holding it for all of tdsignal works well.
Also removing it from setrunna
aren't you suppost to be honeymooning from yesterday?
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Wed, 3 Jul 2002, John Baldwin wrote:
>
> On 03-Jul-2002 Julian Elischer wrote:
> >
> >
> > On Wed, 3 Jul 2002, John Baldwin wrote:
> >
> >>
> >> Erm, I thought I changd signotify() to require sched_lock and made the
> >>
Expanding on my own mail:
On Wed, 3 Jul 2002, Julian Elischer wrote:
> On Wed, 3 Jul 2002, John Baldwin wrote:
>
> >
> > Well then it must be full of races then that were fixed since DP1.
> > *sigh* I wonder how many other things were lost and need to be
> &g
Sick sick sick :-)
On Wed, 3 Jul 2002, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Jul
> ian Elischer writes:
>
> >aren't you suppost to be honeymooning from yesterday?
>
> I am, I'm not working, only doing things I do for fun :-)
>
> --
> Poul-Henning Kamp | UNIX since
On Wed, 3 Jul 2002, John Baldwin wrote:
>
> The argument could be made that you shouldn't be checking in stuff
> until you know how it works, etc., or that you could commit in smaller
> pieces (say, get multiple threads per process for kernel processes
> working in the scheduler and just ignor
congratulations.. I think that you win the Matt Dillon "got both
processors to enter the ddb at the same time" award..
On Wed, 3 Jul 2002, David Wolfskill wrote:
> login: panic: vm_page_free: invalid wire count (360), pindex: 0x1
> cpuid = 0; lapic.id =
> Debugger("panic")
> uernteilm e
Unfortunatly thre is a codepath in the KSE system that has not
been tested, due to a bug in the UVM system. Jeff fixed the UVM
problem for me ysesterday but that means that the following
stack trace (representing the code path in question) is now
used and teh resulting panic happens...
Is ther
On Wed, 3 Jul 2002, Erik Greenwald wrote:
>
> Looks like I'm out of this one, I got up this morning, cvsup'd and built
> world just to make sure it was fresh, then I quit getting the crashes. I
> d'no if the issue was fixed by something someone else did or what...
>
It was solved, but thanks
On Wed, 3 Jul 2002, Neal Fachan wrote:
> We've got local changes (which I've attached) where the name is
> *_FOREACH_REMOVE. We didn't add reverse removable iterators. Also, the
> temp variable is the second argument. I can't think of a way of doing it
> without having the externally declare th
hey don't give up yet..
there's still a couple of crashing bugs hiding in there
you could have your chance yet..
On Wed, 3 Jul 2002, W Gerald Hicks wrote:
>
> On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote:
>
> >
> >
> > On
to keep the sparc 64 pmap up with the others..
I had a look at a couple of thread related points.
Here's a possible diff (1 bug found I think)
any sparc64 people care to comment?
(cat-n-pasted patch)
The last addition is I think needed to not leak KV space.
The first changes are because the co
Well it's all fun and games her at KSE central..
We have a set of cascading hidden bugs..
bug 1 hides bug 2 hides bug 3
the current state of play:
the system works well for a while however there is a leak in
the system that gradually runs the system out memory.
the wired memory count grows wit
I've tracked it down to my losing 1 page for every thread that is started.
if I start a process with 6 threads, I lose 6 x 4k.
if I start a single threaded process I lose 4k.
well, that's a start.. it narrows it down quite a bit :-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsub
On Thu, 4 Jul 2002, David Xu wrote:
> while we are getting rid of Giant, current race condition between softclock()
> and callout_stop() is unacceptable. the race causes two many places in source
> code would be modified to fit this new behaviour, besides this, everywhere
> callout_stop() is
On Wed, 3 Jul 2002, Julian Elischer wrote:
>
> Well it's all fun and games her at KSE central..
> We have a set of cascading hidden bugs..
>
> bug 1 hides bug 2 hides bug 3
>
> the current state of play:
>
> the system works well for a while however ther
I may be fixed. but there's a memory leak still.
reboot when your wired coun gets too high.
On Thu, 4 Jul 2002, Christopher Sharp wrote:
> Hello,
> with a world+kernel from yesterday I get this message
> and then the machine freezes and/or reboots.
>
> Any Ideas ? is this already fixed ?
>
>
what do you call "today's" ?
(version #?)
On 4 Jul 2002, Marc Recht wrote:
> Hi!
>
> I got this with today's pmap
> panic: pmap_new_thread: kstack allocation failed
>
> Yesterday's kernel works fine.
>
>
> Marc
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe f
try a new vm_glue.c as well.
( 1.140)
On Thu, 4 Jul 2002, Julian Elischer wrote:
> what do you call "today's" ?
> (version #?)
>
>
>
> On 4 Jul 2002, Marc Recht wrote:
>
> > Hi!
> >
> > I got this with today's pmap
> > pani
I've checked in a change for the vm change
as for the kernel.. check it is not 0 length :-)
In any case you need the newest vm_glue.c
(and everything else :-)
On Thu, 4 Jul 2002, Steve Kargl wrote:
> On Wed, Jul 03, 2002 at 11:17:53PM -0700, Julian Elischer wrote:
> >
> &g
On Thu, 4 Jul 2002, Kenneth Culver wrote:
> Does this wired memory problem only happen on SMP systems, or is it
> happening across the board?
>
> Ken
>
Uniprocessor had the bug too.
(had... as in I fixed it..)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current
that was teh plan... we're just discussing the name..
TAILQ_FOREACH_SAFE ?
On Thu, 4 Jul 2002, Daniel Eischen wrote:
> On Wed, 3 Jul 2002, Julian Elischer wrote:
> > On Wed, 3 Jul 2002, Neal Fachan wrote:
> >
> > > We've got local changes (whic
don't trust yesterday's build :-/
On Thu, 4 Jul 2002, Edwin Culp wrote:
> both with yesterday's build - kernel and world.
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
how about getting the new version of vm_glue.c that fixes this?
:-)
On Thu, 4 Jul 2002, Mario Goebbels wrote:
> 4th July 5pm CET, with world and kernel from 11am 3rd July, after a
> couple of hours runtime, doing mainly xchat and Mozilla, I got these stats:
>
> Mem: 73M Active, 221M Inact, 210
than the
current FOREACH macros, but allows element removal.
Exisiting methods would no change.
On Thu, 4 Jul 2002, Daniel Eischen wrote:
> On Thu, 4 Jul 2002, Julian Elischer wrote:
> > that was teh plan... we're just discussing the name..
> > TAILQ_FOREACH_SAFE ?
>
>
*phew* (wipes sweat from brow)
Ok After a hectic couple of days it looks like the stability of -current
is back where it should be. Multiple buildworlds are completing
with no discernable degradation.
At this time I have no information on any apps that fail to work (that did
work before KSE).
On Thu, 4 Jul 2002, Daniel Eischen wrote:
> On Thu, 4 Jul 2002, Julian Elischer wrote:
>
> > there are two proposals floatingat the moment..
> >
> > 1/ I added debugging stuff to TAILQ to help find bad usages in KSE.
> > Qusetion/proposal: Should I extend thi
this is a bug in the KSE signal handling..
peter and I are looking at it at the moemnt. it is a known problem.
On Fri, 5 Jul 2002, Dirk Engling wrote:
>
> [ erdgeist@bauklotz:~/Coding ]
> 20:59:14 $> less test.c
> int main( ) {
>char a;
>
>a = getchar();
>
>return a;
> }
> [ er
Looking at i386/exception.s
one sees:
###
.globl alltraps
.type alltraps,@function
alltraps:
pushal
pushl %ds
pushl %es
pushl %fs
alltraps_with_regs_pushed:
mov $KDSEL,%ax
mov %ax,%ds
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
>
>
> OK, current is really confusing me. When we are panic'ing and syncing
> disks, how are we supposed to come back to the current thread which
> caused the dump after we do an mi_switch() to allow an interrupt
> thread to run?
>
It depends.
th
put a breakpoint at msleep+0x290
then continue..
sprinkle a few breakpoints at locations you think other processes ahould
be hitting if they were to be running..
On Fri, 5 Jul 2002, Andrew Gallatin wrote:
>
> Hi Julian,
>
> When I panic an alpha these days, I end up with the random_kthread
>
looks to me like the idle thread is running..
what does 'ps' show from ddb
and
"show locks"
On Sat, 6 Jul 2002, Andrew Gallatin wrote:
>
> David Wolfskill writes:
> > syncing disks...
> > done
> >
> > And at that point, nothing further. I'm able to ping the machine, but I
> > didn't
Well with various hints from here and there I have fixed
the ^Z/fg problem (at least it seems fixed to me and others that
have tested) This basically leaves only one outstanding
problem that I know of which is a problem that Warner has with a
particular progam. (This may also be fixed but I don'
from ddb, type 'ps'
On Sun, 7 Jul 2002, Dirk Engling wrote:
>
> Fatal double fault:
> eip = 0xc01f75ba
> esp = 0xcdcecff8
> ebp = 0xcdced03c
> panic: double fault
> Debugger("panic")
> Stopped atDebugger+0x45:xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c02324bfc) at Debugger+
es that will have no effect on normal usage.
I think that as far as KSE is concerned, you could branch pretty much any
time now..
If there turn out to be problems that we fix they can always be merged
over later.
On Sun, 7 Jul 2002, Murray Stokely wrote:
> On Sat, Jul 06, 2002 at 04:57:08PM
On Mon, 8 Jul 2002, David Xu wrote:
>
> sorry for a bit OT, but why are pmap_mapdev and pmap_unmapdev still using
> old C language parameter style? I saw other functions in pmap using ANSI
> C style.
>
because until recently it was not 'kosher' to change them, but thank god
we have now got p
On Mon, 8 Jul 2002, David Wolfskill wrote:
[his panic]
from sources 8 hours ld, but cvsup didn;t bring anything relevant up..
my panic:
Mounting root from ufs:/dev/ad0s4a
panic: free: address 0xc18d85dc(0xc18d8000) has not been allocated.
syncing disks... panic: bdwrite: buffer is not busy
Up
On Mon, 8 Jul 2002, Julian Elischer wrote:
Ignore: Pilot error
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
A question to those who know..
why is userret() called both at the end of trap() or syscall()
and also almost immediatly again (often) at the end of ast().
It seems that really there is no one place that one can put code that will
be called ONCE and ONLY ONCE as a thread progresses to userland.
On Tue, 9 Jul 2002, Robert Watson wrote:
>
> On Tue, 9 Jul 2002, John Baldwin wrote:
>
> > > If anyone knows of something that was broken by the KSE commit,
> > > (i.e. it worked just before and not after) and is STILL
> > > broken please let me know because I think I can pretty much declare
On Wed, 10 Jul 2002, Bruce Evans wrote:
> Hopefully there won't be any unconditional code. Unconditional code
> in userret() pessimizes all syscalls. Unconditional code added by KSEIII
> pessimized basic syscall overhead by 10% according to lmbench2.
Mostly it's conditional..
if (p->
Gosh I did that SOOO long ago (almost a year I guess)
that I really cannot remember..
I think I looked at the fields and decided that since there
weren't any at that time It could probably be in that reagion..
you are right I think..
feel free to shift it.
Matt has since been there.. I can't reme
On Wed, 10 Jul 2002, Bruce Evans wrote:
> On Tue, 9 Jul 2002, Julian Elischer wrote:
>
> > On Wed, 10 Jul 2002, Bruce Evans wrote:
> >
> > > Hopefully there won't be any unconditional code. Unconditional code
> > > in userret() pessimizes all sysc
On Wed, 10 Jul 2002, Bruce Evans wrote:
> Can these flags be changed asynchronously? If so, then everything needs
> to be handled by ast() anyway. userret() should only check for work that
> needs doing in the usual case, and hopefully there is none (except for
> things like ktrace).
That's a
the new code has been tweeked for gcc 3.1
in 3.1 you need foo[]
in 2.95 you needed foo[0]
you can follow the instructions in /usr/src/Makefile
specifically the make buildkernel bit
to make both the new compiler and build the kernel with it.
On Mon, 8 Jul 2002, Kurt Erik Lindqvist wrote:
[...
On Wed, 10 Jul 2002, Archie Cobbs wrote:
> John Baldwin writes:
> > It is the same problem. What we do is change callout_stop() to let you know if
> > it actually stopped the timeout or not. You then have to use your own locking
> > and synchronization in the timeout function and yourself to c
901 - 1000 of 1656 matches
Mail list logo
