On Mon, Jul 01, 2002 at 02:59:09AM -0400, Wesley Morgan wrote:
> 2723 kdeinit CALL gettimeofday(0x28e94ab8,0)
> 2723 kdeinit RET gettimeofday 0
> 2723 kdeinit CALL wait4(0x,0,0x1,0)
> 2723 kdeinit RET wait4 2724/0xaa4
> 2723 kdeinit CALL poll(0x8059000,0x1,0)
> 2723
On (2002/06/30 00:46), Jeremy Lea wrote:
> +#ifndef SharedDepCplusplusLibraryTarget
> +#define SharedDepCplusplusLibraryTarget [...]
This patch would fix the build. Did it also fix the linking problems
involving -lstdc++ for glxinfo, or were the patches that handle
${CXXLIB} still required?
Ci
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
Reverting to:
uthread_sigpending.c 1.8
uthread_sigsuspend.c 1.11
Makefile.inc 1.32
Has no effect. As far as I can tell theres no more changes...
Looking at some ktrace / gdb output shows the funny business starting
right after kdeinit tries to fork into something else:
2723 kdeinit CALL ge
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
Doug Barton wrote:
> At this point, the only way to build -current on a -stable system is
> make buildworld; make buildkernel. Make sure that KERNCONF is defined in
> /etc/make.conf.
I left out, read /usr/src/UPDATING in the -current source tree, there
are a lot of other steps... the abo
Chuck Robey wrote:
>
> I've just finished going thru another medical session, this one took about
> 5 months, and because of the extended time spent away, I'm running 4.5
> (I've been running current since 1.1, this feels really odd). I need
> a little bit of help (or advice, maybe) to get me ba
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
>
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
Looks like someone broke AC97 rate measurement in -CURRENT
-STABLE measures AC97 rate well (about 55900). Current gives about
41000...
Hardware is Compaq EXD C600 (-STABLE) and Compaq iPAQ C700 (-CURRENT)
Both are i815 equipped with SoundMAX AC97 codec...
Sincerely, Maxim M. Kazachek
I've just finished going thru another medical session, this one took about
5 months, and because of the extended time spent away, I'm running 4.5
(I've been running current since 1.1, this feels really odd). I need
a little bit of help (or advice, maybe) to get me back to current.
I just finishe
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
libc_r... I get virtually the same dump as Michael.
#0 0x28e8d280 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5
#1 0x28e8c9a7 in _thread
Bill Huey wrote:
> Try "info threads" in gdb and then progressively walking through the thread
> list with "thread N", N being the thread number.
(...)
Program received signal SIGSEGV, Segmentation fault.
0x281cc918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5
(gdb) info threa
On Mon, Jul 01, 2002 at 07:11:31AM +0200, Michael Nottebrock wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x281cc918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5
> (gdb) bt
> #0 0x281cc918 in _thread_kern_sched_state_unlock () from
> /usr/lib/libc_r.so.5
> #
Everything that links to libc_r is now completely hosed here, this
includes all of KDE.
Since KDE is a tad too big to make a handy test, here comes ogg123 from
the vorbis-tools port:
[lofi@kiste]:1:~ > gdb ogg123
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GD
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote:
>Here's what I did to get XFree86-4 to build with the base system's
>toolchain in -CURRENT:
>
>a) ports/devel/imake-4:
>
>Replace files/patch-d and files/patch-xthreads with the attached
>patch-config::cf::FreeBSD.cf.
>
>Add the attached p
thanks..
I was aware of he race but it looks as if I miscaldulated it somehow..
I will look at the source again and confirm your patch.
As you say, msleep() is of the same form and has the same problems.
On Mon, 1 Jul 2002, David Xu wrote:
> Now let me describe where the race is:
>
> Thread A:
Title: ¿ì¸®Ä«µå
¼º¸í
Áֹεî·Ï ¹øÈ£
Á÷Àå ÀüÈ
ÈÞ´ëÆù
Now let me describe where the race is:
Thread A: | Thread B:
cv_timedwait() | softclock()
| cv_timedwait_end()
* Juli Mallett <[EMAIL PROTECTED]> escriuréres
> jmallett2002/06/30 18:45:03 PDT
>
> Modified files:
> .modules
> .MAINTAINERS
> lib Makefile
> Added files:
> lib/libufs Makefile block.c inode.c libufs.h
cvsup from yesterday, ppp began core dump on my machine.
back trace:
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 you are
welcome to change it and/or distribute copies of it under certain condit
setrunqueue() call can be simply removed from cv_timedwait_end(), 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_tim
Got a weird one. No backtrace. gdb got confused and wouldn't attach
properly.
-Matt
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0xd0c45a
fault code = supervisor write, page
On 2002-06-30 22:53 +, Glenn Gombert wrote:
> I get the following error when trying to rebuild the last couple of
> days...
>
> ../sys/kern/syscalls.master
> syscall.master : line 55: syscall number out of sync at 7 ...
>
> line is: struct rusage * rsuage ) ; } wait4 wait_args int
>
> ***
I get the following error when trying to rebuild the last couple of
days...
../sys/kern/syscalls.master
syscall.master : line 55: syscall number out of sync at 7 ...
line is: struct rusage * rsuage ) ; } wait4 wait_args int
Error code 1
--
Glenn Gombert
[EMAIL PROTECTED]
"Neve
On Sun, Jun 30, 2002 at 10:39:12AM -0700, Julian Elischer wrote:
> Hi
>
> so far. you are the only person who has reported this..
> please let me know if anything changes..
FWIW: I'm running gimp on an alpha running a post KSE kernel.
The world is about 2 weeks older on that machine.
--
Julian on FreeBSD-CURRENT wrote:
> On Sun, 30 Jun 2002, walt wrote:
>> Dunno if this is important, but I meant to mention it in my
>> initial problem report: the problem with gnome and mozilla
>> chewing up CPU cycles begain just after the make world
>> finished and while the make kernel w
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
I did the following (on a -STABLE system):
cvs co src
cd src
make MAKEOBJDIRPREFIX=`pwd`/../usr/obj buildworld
and got the error below.
Any ideas ? Am i doing something wrong ?
cheers
luigi
===> gnu/usr.bin/tar
rm -f tar addext.o argmatch.o backupfile.o
: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 :-/
:
There are a bunch of wakeup race conditions in the CV code where
the
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,
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+0x46
panic(c02ec8a9,c6461d80,c6461d80,c6461d80,c01afa30) at p
ty a new libkvm..
also please try the same binary booted off the old non KSE kernel..
(what, you don't still have it?)
On Sun, 30 Jun 2002, Julian Elischer wrote:
> well, that's different :-)
>
> any chance to get a ktrace ?
>
> On Sun, 30 Jun 2002, Steve Kargl wrote:
>
> > On Sun, Jun 30, 2
hmmm
well, since the only changes were in the kernel except for libkvm
I'm puzzled. If you boot off the old kernel (You still have it right? :-)
does it still act the same?
On Sun, 30 Jun 2002, walt wrote:
> Dunno if this is important, but I meant to mention it in my
> initial problem repor
well, that's different :-)
any chance to get a ktrace ?
On Sun, 30 Jun 2002, Steve Kargl wrote:
> On Sun, Jun 30, 2002 at 10:39:12AM -0700, Julian Elischer wrote:
> > Hi
> >
> > so far. you are the only person who has reported this..
> > please let me know if anything changes..
> >
> >
Dunno if this is important, but I meant to mention it in my
initial problem report: the problem with gnome and mozilla
chewing up CPU cycles begain just after the make world
finished and while the make kernel was still compiling,
so whatever this problem is it was not due to changes
in the kernel
On Sun, Jun 30, 2002 at 10:39:12AM -0700, Julian Elischer wrote:
> Hi
>
> so far. you are the only person who has reported this..
> please let me know if anything changes..
>
> It's now the 'top' item in my list of problems.
>
kargl[34] mozilla
[1] 1347 Segmentation fault
:-)
--
Ste
:
:which panic message?
:the code here is still FULL of asserts.
:
"Unexpected ke present". I'm resynching and will run the build test
again. If it crunches again I'll do a more detailed check.
-Matt
To Unsubscribe: send mail to [EMAIL
Hi
so far. you are the only person who has reported this..
please let me know if anything changes..
It's now the 'top' item in my list of problems.
On Fri, 28 Jun 2002, walt wrote:
> Following make world && make kernel after the KSE update
> I find that mozilla and any gnome app will su
Hello,
I see no problems with neither GNOME nor Mozilla.
Kernel compiled about an hour ago (15:30:13 CEST / GMT+2). Userland
last compiled on June 27.
On Sun, 2002-06-30 at 10:29, Julian Elischer wrote:
> Ithink these may be threaded
> it's possible the are using signals and they may be broken
On Sun, 30 Jun 2002, Julian Elischer wrote:
>
>
>
> On Sun, 30 Jun 2002, Julian Elischer wrote:
>
>
> Well after 1 day I'm releatively happy..
that's "relatively"
>
> There seem to have been 4 bugs showing themselves..
>
> A machine doing REAL HEAVY work and SWAPPING LIKE CRAZY
> eventua
On Sun, 30 Jun 2002, Julian Elischer wrote:
Well after 1 day I'm releatively happy..
There seem to have been 4 bugs showing themselves..
A machine doing REAL HEAVY work and SWAPPING LIKE CRAZY
eventually paniced. (one instance)
Matt triggered a panic we put into the code and thought
we'd n
Sun Jun 30 07:00:07 PDT 2002
cd: can't cd to /home/des/tinderbox/alpha/src
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
I'm still using old 16bit Linksys card and it's not working with
newcard. Otherwise newcard is just fine with my Toshiba 3440 when
using Cisco Aironet 340. Newcard don't detect Linksys as it should.
Is anyone using this card?
--- newcard ---
Jun 30 14:58:38 phb kernel: ed0: at port
0x100-0x11f
Well, this has been happening for about a year on my dev box. It's not
gcc 3.1 specific.
I've never gotten around to figuring out why it works on some machines.
On Sat, 29 Jun 2002 19:41:51 -0700, David O'Brien wrote:
> On Sat, Jun 29, 2002 at 11:30:48PM +0100, Brian Somers wrote:
> > The probl
Grrr, hit me baby one more time.
One of the diffs included a completely gratuitous one-line change which
I made yesterday night while I was tired and neglected to correct today.
So, the patchset again. (Take three!)
--
Regards:
Szilveszter ADAM
Szombathely Hungary
Index: Makefile
==
- One in usr.bin/gcore/gcore.c (open #ifndef, lost the errorlog,
commit-accident?)
- Another:
cc -O -pipe -DLIBC_SCCS -I/usr/src/lib/libkvm -c
/usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o
/usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist':
/usr/src/lib/libkvm/kvm_proc.c:271: invalid
Ithink these may be threaded
it's possible the are using signals and they may be broken
On Fri, 28 Jun 2002, walt wrote:
> Following make world && make kernel after the KSE update
> I find that mozilla and any gnome app will suck up 98%
> of the CPU and will never actually write anything to
well afte a day I'm releatively happy..
there seem to be 4 bugs showing themselves..
plus one braino I just fixed..
(there was a bug where ps would panic the kernel
when it got to a zombie process because it tried to
print thread info but ther eis no thread).
in addition the following problems
Hello everybody,
Sorry for taking a tad long with this, here is the second patch set for
the GDB info files.
I implemented both of David's suggestions, so the third patch is no
longer needed and GDBvn.texi can be safely cvs rm-d now, it is generated
dynamically at build time.
If you want to go
which panic message?
the code here is still FULL of asserts.
On Sun, 30 Jun 2002, Matthew Dillon wrote:
> I got the ithread_loop/setrunqueue panic again while building the
> world normally (no memory pressure). I'm too tired to deal with
> it tonight but tomorrow morning I'll attac
I got the ithread_loop/setrunqueue panic again while building the
world normally (no memory pressure). I'm too tired to deal with
it tonight but tomorrow morning I'll attach a gdb and track it down.
-Matt
db>
db> trace
Debugger(c02ec1
53 matches
Mail list logo
