KSE status report
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 debug messages when he managed to get both of his CPUs to enter teh debugger at the same time. I thought that was impossible, but it definitly happenned. (or it certainly looked that way to me :-) 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). A libc_r imported from a system that is not yet upgraded to have KSE sources works fine. A libc_r from a KSE machine will not work correctly on the KSE machine or the pre-KSE machine. The sources are identical, so some thing else in the tree must be influencing its correctness. the result of this problem is that KDE and Gnome apps that are linked with a libc_r created on this system. The test directory in the libc sources is giving me some avenues to work on but I must say, given allthe things that could have gone wrong in the kernel, I'm surprised that the largest problem seems to have come from a userland library that I haven't touched :-/ julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 found. > He however gets the award for most confusing > debug messages when he managed to get both of his CPUs > to enter teh debugger at the same time. I thought that was > impossible, but it definitly happenned. (or it certainly > looked that way to me :-) > > 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). > > A libc_r imported from a system that is not yet upgraded to have > KSE sources works fine. A libc_r from a KSE machine > will not work correctly on the KSE machine or the pre-KSE machine. > > The sources are identical, so some thing else in the tree must be > influencing its correctness. > > the result of this problem is that KDE and Gnome apps that > are linked with a libc_r created on this system. don't work > > The test directory in the libc sources is giving me some avenues to > work on but I must say, given allthe things that could have gone wrong > in the kernel, I'm surprised that the largest problem seems to > have come from a userland library that I haven't touched :-/ > > julian > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 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 > debug messages when he managed to get both of his CPUs > to enter teh debugger at the same time. I thought that was > impossible, but it definitly happenned. (or it certainly > looked that way to me :-) > > 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). > > A libc_r imported from a system that is not yet upgraded to have > KSE sources works fine. A libc_r from a KSE machine > will not work correctly on the KSE machine or the pre-KSE machine. > > The sources are identical, so some thing else in the tree must be > influencing its correctness. > > the result of this problem is that KDE and Gnome apps that > are linked with a libc_r created on this system. > > The test directory in the libc sources is giving me some avenues to > work on but I must say, given allthe things that could have gone wrong > in the kernel, I'm surprised that the largest problem seems to > have come from a userland library that I haven't touched :-/ > > julian > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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)->field.tqe_next = (void *)-1; in TAILQ_REMOVE a likely candidate? That could easily tickle old bugs in other code. The libc_r code does use a lot of TAILQ macros. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 bit ironic really).
>
>Is the new
>
> (elm)->field.tqe_next = (void *)-1;
>
>in TAILQ_REMOVE a likely candidate? That could easily tickle old
>bugs in other code. The libc_r code does use a lot of TAILQ macros.
>From casual inspection of the sources, it appears this may be the case:
uthread/pthread_private.h:
#define PTHREAD_WORKQ_REMOVE(thrd) do { \
TAILQ_REMOVE(&_workq,thrd,qe); \
(thrd)->flags &= ~PTHREAD_FLAGS_IN_WORKQ; \
} while (0)
uthread/uthread_kern.c (in multiple locations):
TAILQ_FOREACH(pthread, &_workq, qe) {
PTHREAD_WORKQ_REMOVE(pthread);
}
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 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)->field.tqe_next = (void *)-1; > > in TAILQ_REMOVE a likely candidate? That could easily tickle old > bugs in other code. The libc_r code does use a lot of TAILQ macros. > > Ian > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 us from successfully compiling a working libc_r.
> >>(a bit ironic really).
> >
> >Is the new
> >
> > (elm)->field.tqe_next = (void *)-1;
> >
> >in TAILQ_REMOVE a likely candidate? That could easily tickle old
> >bugs in other code. The libc_r code does use a lot of TAILQ macros.
>
> >From casual inspection of the sources, it appears this may be the case:
>
> uthread/pthread_private.h:
> #define PTHREAD_WORKQ_REMOVE(thrd) do { \
> TAILQ_REMOVE(&_workq,thrd,qe); \
> (thrd)->flags &= ~PTHREAD_FLAGS_IN_WORKQ; \
> } while (0)
>
> uthread/uthread_kern.c (in multiple locations):
> TAILQ_FOREACH(pthread, &_workq, qe) {
>
> PTHREAD_WORKQ_REMOVE(pthread);
> }
This used to be safe as long as the element removed wasn't re-added to
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);
...
TAILQ_REMOVE(&q, pthread, p_qe);
...
}
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
:...
: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);
: ...
: TAILQ_REMOVE(&q, pthread, p_qe);
: ...
: }
:
:--
:Dan Eischen
Why don't we simply conditionalize sys/queue.h for the _KERNEL
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
Index: sys/sys/queue.h
===
RCS file: /home/ncvs/src/sys/sys/queue.h,v
retrieving revision 1.50
diff -u -r1.50 queue.h
--- sys/sys/queue.h 29 Jun 2002 19:16:10 - 1.50
+++ sys/sys/queue.h 2 Jul 2002 16:28:24 -
@@ -102,7 +102,11 @@
* _REMOVE + + + +
*
*/
-#define QUEUE_MACRO_DEBUG 0
+#ifdef _KERNEL
+#define QUEUE_MACRO_DEBUG 0/* change this for kernel debugging */
+#else
+#define QUEUE_MACRO_DEBUG 0/* leave alone for userland compatibility */
+#endif
#if QUEUE_MACRO_DEBUG
/* Store the last 2 places the queue element or head was altered */
struct qm_trace {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 should be reverted. Also, enabling the queue macro debugging will definitely break libc_r too. > 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 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)->field.tqe_next = (void *)-1; > > > > in TAILQ_REMOVE a likely candidate? That could easily tickle old > > bugs in other code. The libc_r code does use a lot of TAILQ macros. > > > > Ian -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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, Daniel Eischen wrote:
> 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 us from successfully compiling a working libc_r.
> > >>(a bit ironic really).
> > >
> > >Is the new
> > >
> > > (elm)->field.tqe_next = (void *)-1;
> > >
> > >in TAILQ_REMOVE a likely candidate? That could easily tickle old
> > >bugs in other code. The libc_r code does use a lot of TAILQ macros.
> >
> > >From casual inspection of the sources, it appears this may be the case:
> >
> > uthread/pthread_private.h:
> > #define PTHREAD_WORKQ_REMOVE(thrd) do { \
> > TAILQ_REMOVE(&_workq,thrd,qe); \
> > (thrd)->flags &= ~PTHREAD_FLAGS_IN_WORKQ; \
> > } while (0)
> >
> > uthread/uthread_kern.c (in multiple locations):
> > TAILQ_FOREACH(pthread, &_workq, qe) {
> >
> > PTHREAD_WORKQ_REMOVE(pthread);
> > }
>
> This used to be safe as long as the element removed wasn't re-added to
> 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);
> ...
> TAILQ_REMOVE(&q, pthread, p_qe);
> ...
> }
>
> --
> Dan Eischen
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 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 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 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)->field.tqe_next = (void *)-1; > >> > >> in TAILQ_REMOVE a likely candidate? That could easily tickle old bugs > >> in other code. The libc_r code does use a lot of TAILQ macros. > >> > >> Ian > >> > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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
> :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);
> : ...
> : TAILQ_REMOVE(&q, pthread, p_qe);
> : ...
> : }
> :
> :--
> :Dan Eischen
>
> Why don't we simply conditionalize sys/queue.h for the _KERNEL
>
> -Matt
> Matthew Dillon
> <[EMAIL PROTECTED]>
>
> Index: sys/sys/queue.h
> ===
> RCS file: /home/ncvs/src/sys/sys/queue.h,v
> retrieving revision 1.50
> diff -u -r1.50 queue.h
> --- sys/sys/queue.h 29 Jun 2002 19:16:10 - 1.50
> +++ sys/sys/queue.h 2 Jul 2002 16:28:24 -
> @@ -102,7 +102,11 @@
> * _REMOVE + + + +
> *
> */
> -#define QUEUE_MACRO_DEBUG 0
> +#ifdef _KERNEL
> +#define QUEUE_MACRO_DEBUG 0 /* change this for kernel debugging */
> +#else
> +#define QUEUE_MACRO_DEBUG 0 /* leave alone for userland compatibility */
> +#endif
> #if QUEUE_MACRO_DEBUG
> /* Store the last 2 places the queue element or head was altered */
> struct qm_trace {
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 KDE stuff seems to be working but I haven't confirmation on that. I will try install some KDE and gnome stuff on my test machines.. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 bring those two files back into sync, and then recompile libc_r? (uh, and reinstall it..) thats 1.52 ow queue.h and 1.226 of proc.h Hopefully the last commit fixed it.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 David found. > He however gets the award for most confusing > debug messages when he managed to get both of his CPUs > to enter teh debugger at the same time. I thought that was > impossible, but it definitly happenned. (or it certainly > looked that way to me :-) I just wanted to add that I have no problems with KSE. All of my apps are working normally and I haven't had any panics. I was a bit worried about KDE, but it works correctly as well. BTW im running -current from yesterday. Good job, Beech -- --- Beech Rintoul - IT Manager - Instructor - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | Anchorage Gospel Rescue Mission \ / - NO HTML/RTF in e-mail | P.O. Box 230510 X - NO Word docs in e-mail | Anchorage, AK 99523-0510 / \ - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 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 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)->field.tqe_next = (void *)-1; >> >> in TAILQ_REMOVE a likely candidate? That could easily tickle old bugs >> in other code. The libc_r code does use a lot of TAILQ macros. >> >> Ian >> > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 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 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 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 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)->field.tqe_next = (void *)-1; >> >> >> >> in TAILQ_REMOVE a likely candidate? That could easily tickle old >> >> bugs in other code. The libc_r code does use a lot of TAILQ macros. >> >> >> >> Ian >> >> >> > >> > >> > To Unsubscribe: send mail to [EMAIL PROTECTED] >> > with "unsubscribe freebsd-current" in the body of the message >> >> >> >> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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. Nautilus hangs indefinitely taking up almost all of the CPU. Once it's killed, other GNOME apps respond again. This is -CURRENT kernel+world minus your recent queue.h commit. I can get a back trace if you'd like. Joe > > 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 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 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 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)->field.tqe_next = (void *)-1; > > >> > > >> in TAILQ_REMOVE a likely candidate? That could easily tickle old bugs > > >> in other code. The libc_r code does use a lot of TAILQ macros. > > >> > > >> Ian > > >> > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- PGP Key : http://www.marcuscom.com/pgp.asc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 be compiler dependent). Yeah, I'll try to update the tests before upgrading. Some changes were made to sigsuspend and sigpending, and perhaps some other recent changes to signal handling in libc_r, that seem to have affected the tests. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 of queue.h. Last > > cvsup was Jul 1 17:13 MDT. > ok so cen you bring those two files back into sync, > and then recompile libc_r? > (uh, and reinstall it..) > > thats 1.52 ow queue.h and 1.226 of proc.h > > Hopefully the last commit fixed it.. After rebuilding world and kernel on the latest queue.h, the nautilus problem is solved. Joe > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > signature.asc Description: This is a digitally signed message part
Re: KSE status report
> 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 _thread_kern_sched() is ___longjmp(_thread_kern_sched_jb, 1); I think that's where the crash is. the setjmp is in uthread_init.c, on line 320, "_setjmp(_thread_kern_sched_jb);", but that function doesn't seem to be called? I put some printf's with fflush's in there and I'm not seeing them come up. Maybe I'm misreading something, but that seems to me to be the issue, _thread_kern_sched_jb having junk when it gets longjmp'd... I'm really not quite what all goes into this, so I'm throwing this out to let more experienced minds consider it? :) I think I'm going to wait an hour or two before trying to fix it, maybe someone sees this as a quick fix -- -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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, 2 Jul 2002, Erik Greenwald wrote: > > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 > > ___longjmp(_thread_kern_sched_jb, 1); > > I think that's where the crash is. the setjmp is in uthread_init.c, on > line 320, "_setjmp(_thread_kern_sched_jb);", but that function doesn't > seem to be called? I put some printf's with fflush's in there and I'm > not seeing them come up. Maybe I'm misreading something, but that seems > to me to be the issue, _thread_kern_sched_jb having junk when it gets > longjmp'd... I'm really not quite what all goes into this, so I'm > throwing this out to let more experienced minds consider it? :) I think > I'm going to wait an hour or two before trying to fix it, maybe someone > sees this as a quick fix Yeah, that's where I'm poking at currently. The thing that I'm seeing is that the entry function _thread_start is on the wrong stack. This problem predates the KSE commit, so it's not related to it. It could be that the jump_buf isn't being set up correctly or some other unknown craziness, but I believe I'm close to finding the SEGV in question. The problem is persistent across pre-KSE (3 days ago) and KSE kernels. I'm running an older kernel now with the latest world, so that the environment is stable enough for me to do bug tracking. If I'm doing something wrong, then please tell me. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
After building today's -CURRENT successfully (CVSup started at 0347 hrs.
Pacific (7 hrs. west of GMT/UTC at this time of year) from cvsup14, with
the addition of Ruslan's updates to the src/share/mk/bsd.*.mk files),
I thought it might be of use to just let this SMP (2x866 PIII) box sit
in a "make -j8 buildworld" loop for a while and see how far it gets.
The answer would appear to be "not as far as I would have expected" --
I tried to ssh back into the machine, was getting no response, so I
resumed the "screen" session on another machine that had a "tip" going
to the test machine's serial console. This is what I see (modulo tab/space
replacement):
Local package initialization:Creating DISK md10
md10: invalid primary partition table: no magic
md10: invalid primary partition table: no magic
[1] 234 Floating point exception (core dumped)
Jul 3 07:21:37 freebeast kernel: pid 234 (newfs), uid 0: exited on signal 8 (core
dumped)
apache cvsupd
.
Additional TCP options:.
Starting background filesystem checks
Wed Jul 3 07:21:38 PDT 2002
FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)
login: panic: vm_page_free: invalid wire count (360), pindex: 0x1
cpuid = 0; lapic.id =
Debugger("panic")
uernteilm etoruatp s9t owpiptihn gi nctpeursr
Sttso pdpiesda balte d
in_Debugger.0x46: xchgl %ebx,
db>
al trap 9: general protectinuwlppippelo
u 1lcd i10
irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = c)elt r,o=
S
Xc
pDcXKK`K$KhK,KpK4KxK
Fatal trap 12: page fault while in kernel mode
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x199
fault code = supervisor read, page not present
instruction pointer = 0x1ba0:0x9b
stack pointer = 0x10:0xc03d39a8
frame pointer = 0x10:0xc0361ba0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= trace trap, IOPL = 0
current process = 92825 (cc1)
kernel: type 12 trap, code=0
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db>
which isn't all that bad, in that it should provide some access to poke
around and get some clues as to what broke.
Unfortunately, that serial console appears to be completely unresponsive:
I tried typing "tr" at it; nothing. Sent a break; nothing.
Is there anything anyone can suggest for getting some additional
information out of this? I don't have a critical need for the machine
until tomorrow morning, so the only disadvantage to leaving it on is that
it consumes electricity & generates heat.
Thanks,
david
--
David H. Wolfskill [EMAIL PROTECTED]
Trying to support or use Microsoft products makes about as much sense
as painting the outside of a house with watercolors.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 etoruatp s9t owpiptihn gi nctpeursr
> Sttso pdpiesda balte d
> in_Debugger.0x46: xchgl %ebx,
> db>
> al trap 9: general protectinuwlppippelo
> u 1lcd i10
> irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= resume, IOPL = 0
> current process = c)elt r,o=
> S
> Xc
> pDcXKK`K$KhK,KpK4KxK
doing an nm and figuring out where the processor was
might be informative.
Julian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
On 03-Jul-2002 Julian Elischer wrote:
> 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 etoruatp s9t owpiptihn gi nctpeursr
>> Sttso pdpiesda balte d
>> in_Debugger.0x46: xchgl %ebx,
>> db>
>> al trap 9: general protectinuwlppippelo
>> u 1lcd i10
>> irtnot 0:c026scpnr 01:da20fmpnr 010a2ppx8cxppxexpeppxxeppxp pps@xxltx
>> = DPL 0, pres 1, def32 1, gran 1
>> processor eflags= resume, IOPL = 0
>> current process = c)elt r,o=
>> S
>> Xc
>> pDcXKK`K$KhK,KpK4KxK
>
> doing an nm and figuring out where the processor was
> might be informative.
If you have a valid eip you can use addr2line to get the
exact source line. We probably need to not allow concurrent
panics. We already don't allow concurrent ddb sessions, but
we do let both processors panic at the same time I think.
Hmm, this should already be happening though:
panic(const char *fmt, ...)
{
int bootopt;
va_list ap;
static char buf[256];
#ifdef SMP
/*
* We don't want multiple CPU's to panic at the same time, so we
* use panic_cpu as a simple spinlock. We have to keep checking
* panic_cpu if we are spinning in case the panic on the first
* CPU is canceled.
*/
if (panic_cpu != PCPU_GET(cpuid))
while (atomic_cmpset_int(&panic_cpu, NOCPU,
PCPU_GET(cpuid)) == 0)
while (panic_cpu != NOCPU)
; /* nothing */
#endif
I suppose this could be broken if we migrate. I'll try to
think of a better solution. Probably using curthread instead
of cpuid. Try this untested diff (warning, my mailer will
probably botch this):
Index: kern_shutdown.c
===
RCS file: /usr/cvs/src/sys/kern/kern_shutdown.c,v
retrieving revision 1.128
diff -u -r1.128 kern_shutdown.c
--- kern_shutdown.c 12 May 2002 18:27:28 - 1.128
+++ kern_shutdown.c 3 Jul 2002 17:12:32 -
@@ -421,7 +421,7 @@
}
#ifdef SMP
-static u_int panic_cpu = NOCPU;
+static uintptr_t panic_thread = NULL;
#endif
/*
@@ -441,15 +441,17 @@
#ifdef SMP
/*
* We don't want multiple CPU's to panic at the same time, so we
-* use panic_cpu as a simple spinlock. We have to keep checking
-* panic_cpu if we are spinning in case the panic on the first
+* use panic_thread as a simple spinlock. We have to keep checking
+* panic_thread if we are spinning in case the panic on the first
* CPU is canceled.
*/
- if (panic_cpu != PCPU_GET(cpuid))
- while (atomic_cmpset_int(&panic_cpu, NOCPU,
- PCPU_GET(cpuid)) == 0)
- while (panic_cpu != NOCPU)
- ; /* nothing */
+ if (panic_thread != curthread)
+ while (atomic_cmpset_ptr(&panic_thread, NULL, curthread) == 0)
+ while (panic_thread != NULL) {
+#ifdef __i386__
+ ia32_pause();
+#endif
+ }
#endif
bootopt = RB_AUTOBOOT | RB_DUMP;
@@ -479,7 +481,7 @@
/* See if the user aborted the panic, in which case we continue. */
if (panicstr == NULL) {
#ifdef SMP
- atomic_store_rel_int(&panic_cpu, NOCPU);
+ atomic_store_rel_ptr(&panic_thread, NULL);
#endif
return;
}
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
> > 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 :-) > 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... - -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 for trying and welcome to the club of people willing to get their fingers dirty :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote: > > > 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 for trying and welcome to the club > of people willing to get their fingers dirty :-) > > Well, I feel cheated. Damn thing never crashed on me. :-) (pushes harder) Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
> 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 for trying and welcome to the club > of people willing to get their fingers dirty :-) not the first time I've dug into the 'dirty' stuff, was just kinda hoping this time I'd be first to the solution :) ah well, no core segment to my name, but still a few ports, guess I'll have to keep trying until I luck out :) -- -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
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 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 for trying and welcome to the club > > of people willing to get their fingers dirty :-) > > > > > > Well, I feel cheated. Damn thing never crashed on me. :-) > > (pushes harder) > > Cheers, > > Jerry Hicks > [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE status report
W Gerald Hicks wrote: > > On Wednesday, July 3, 2002, at 04:13 PM, Julian Elischer wrote: > >> >> >> 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 for trying and welcome to the club >> of people willing to get their fingers dirty :-) >> >> > > Well, I feel cheated. Damn thing never crashed on me. :-) > > (pushes harder) > > Cheers, Same here, I run a 2nd July 11am CET cvsup, system behaves 'normal' to me (yet?). -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
