Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Julian Elischer wrote: > > On Mon, 1 Jul 2002, Daniel Eischen wrote: > > > On Mon, 1 Jul 2002, Julian Elischer wrote: > > > > > I think that gets us a LOT closer! > > > > > > > > > Total tests 212, passed 212, failed 0 > > > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on > > > signal 11 (core dumped) > > > Jul 2 01:52:52 ref4 kernel: pid 338 (guard_b), uid 0: exited on signal 11 > > > (core dumped) > > > > I think this is supposed to SEGV. It's testing guard pages placed > > above thread stacks. > > I would imagine that it is supposed to capture the sigsegv > instead of actually dying... There's a perl script which is supposed to do that I think. guard_s.pl I think. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Daniel Eischen wrote: > On Mon, 1 Jul 2002, Julian Elischer wrote: > > > I think that gets us a LOT closer! > > > > > > Total tests 212, passed 212, failed 0 > > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on > > signal 11 (core dumped) > > Jul 2 01:52:52 ref4 kernel: pid 338 (guard_b), uid 0: exited on signal 11 > > (core dumped) > > I think this is supposed to SEGV. It's testing guard pages placed > above thread stacks. I would imagine that it is supposed to capture the sigsegv instead of actually dying... > > -- > Dan Eischen > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Julian Elischer wrote: > I think that gets us a LOT closer! > > > Total tests 212, passed 212, failed 0 > ref4# Jul 2 01:52:52 ref4 kernel: pid 330 (guard_b), uid 0: exited on > signal 11 (core dumped) > Jul 2 01:52:52 ref4 kernel: pid 338 (guard_b), uid 0: exited on signal 11 > (core dumped) I think this is supposed to SEGV. It's testing guard pages placed above thread stacks. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current results (was something funny with soft updates?)
SMP builds are still producing panics every 2-4 buildworlds after the KSE commit, I'm still trying to track that down. But I was able to complete the softupdates/non-softupdates test with a UP build of -current: with softupdates (UP BUILD, CURRENT): 3122.30 real 2360.70 user 532.54 sys 3083.17 real 2361.14 user 529.53 sys 3085.05 real 2361.59 user 529.32 sys without softupdates (UP BUILD, CURRENT): 3361.70 real 2365.23 user 535.50 sys 3451.55 real 2368.22 user 537.26 sys 3454.85 real 2369.42 user 536.69 sys ^ ~350 second dif note user times for real. Included below are the original tests that were done under stable... the overall 'real' times are NOT COMPARATIVE since the original tests were done with an SMP build, but the user times should be, and that is where I believe the major difference is occuring. My guess is that the new GCC in -current is eating a massive amount of extra cpu. It is eating over 2300 cpu seconds under -current and only 1400 under -stable while system time remains roughly comparable (remember that the interrupts are not charged to processes under -current). The difference in real time softupdate vs non-softupdates between current and stable is around 350 seconds under current, and 889 seconds under stable. This is fairly comparable when we consider that a good portion of the extra user time eaten in -current is absorbing the stall delays for processes undergoing I/O that softupdates mostly fixes. My conclusion is that softupdates is working fine and (A) the new GCC is a whole lot less efficient then the old GCC and (B) user times are masking gains (due to high parallelism) that would otherwise be realized with softupdates. : (original tests under -stable) :test1# cat x1 (SMP BUILD, STABLE, WITH SOFTUPDATES) : 1497.09 real 1397.98 user 612.06 sys : 1500.12 real 1399.33 user 609.79 sys : 1494.82 real 1398.30 user 612.46 sys :test1# cat x2 (SMP BUILD, STABLE, WITHOUT SOFTUPDATES) : 2449.14 real 1401.34 user 625.54 sys : 2389.75 real 1400.38 user 629.86 sys : 2358.82 real 1403.26 user 624.93 sys : ( ~889 second difference in real time) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:52 ref4 kernel: pid 342 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:52 ref4 kernel: pid 346 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:52 ref4 kernel: pid 350 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 354 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 358 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 362 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 366 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 370 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 374 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 378 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:53 ref4 kernel: pid 382 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:54 ref4 kernel: pid 386 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:54 ref4 kernel: pid 390 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:54 ref4 kernel: pid 394 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:54 ref4 kernel: pid 398 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:54 ref4 kernel: pid 402 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 406 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 410 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 414 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 418 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 422 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 426 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 430 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:55 ref4 kernel: pid 434 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:56 ref4 kernel: pid 438 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:56 ref4 kernel: pid 442 (guard_b), uid 0: exited on signal 11
(core dumped)
Jul 2 01:52:56 ref4 kernel: pid 446 (guard_b), uid 0: exited on signal 11
(core dumped)
--
sigsuspend_d0.00 0.010.01
passed
--
sigwait_d 0.00 0.010.01
*** FAILED ***
--
guard_s.pl 0.06 0.880.95
*** FAILED *** (30/30 failed)
--
propagate_s.pl 0.14 0.070.21
*** FAILED *** (1/1 failed)
--
Totals 3.34 151.65 154.99 0.00
6 / 9 passed (66.67%) 0.00 0.000.000.00%
--
*** Error code 1
Stop in /usr/src/lib/libc_r/test.
in gdb:
Breakpoint 1, main (argc=3, argv=0xbfbffc10) at guard_b.c:103
103 assert(pthread_attr_init(&attr) == 0);
(gdb) s
98 fprintf(stderr, "Test begin\n");
(gdb)
Test begin
100 stacksize = strtoul(argv[1], NULL, 10);
(gdb)
101 guardsize = strtoul(argv[2], NULL, 10);
(gdb)
103 assert(pthread_attr_init(&attr) == 0);
(gdb)
108 assert(pthread_attr_getstacksize(&attr, &def_stacksize) ==
0);
(gdb)
109 assert(pthread_attr_getguardsize(&attr, &def_guardsize) ==
0);
(gdb)
110 if (def_stacksize != stacksize) {
(gdb)
111 assert(pthread_attr_setstacksize(&attr,
stacksize) == 0);
(gdb)
112 assert(pthread_attr_getstacksize(&attr,
&def_stacksize) == 0);
(gdb)
113 assert(def_stacksize == stacksize);
(gdb)
115 if (def_guardsize != guardsize) {
(gdb)
116 assert(pthread_attr_setguardsize(&attr,
guardsize) == 0);
(gdb)
117 assert(pthread_attr_getguardsize(&attr,
&def_guardsize) == 0);
(gdb)
118 ass
Re: Post-KSE disaster with libc_r
> In <[EMAIL PROTECTED]> > Julian Elischer <[EMAIL PROTECTED]> wrote: JE> the question is: JE> did you update both kernel and userland? Yes. I always do update the whole world. > I updated my current box about an hour ago, and got into trouble too. And I backed kernel only of date=2002.06.29.17.00.00 and this old kernel has problem. While running /etc/rc it gets panic, but I've lost the message. I'm now rebuilding the latest world, i.e. userland and kernel, with the kernel and userland of yesterday. -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 alarm so far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Julian Elischer wrote: > 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't know how to make test. Stop > ref4# make > Test static library: > -- > Test c_user c_system c_total chng > passed/FAILEDh_user h_system h_total % chng > -- > hello_d 0.00 0.000.00 > passed > -- > hello_s 0.00 0.010.01 > passed > -- > join_leak_d 0.19 0.150.34 > passed > -- > 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. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 think of are the queues (with the > > QMD debug defined, that would definitely cause problems), but that > > seems to have been ruled out also when queue.h was reverted. Did > > USRSTACK or SIGSTKSZ get changed somehow? > > > > 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. > > I'd try but... > cc -Wall -pipe -g3 -D_LIBC_R_ -D_REENTRANT -c mutex_d.c -o mutex_d_a.o > mutex_d.c:168: initializer element is not constant > mutex_d.c: In function `waiter': > mutex_d.c:358: warning: too few arguments for format > *** Error code 1 > > Stop in /usr/src/lib/libc_r/test. > > > > 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: Post-KSE disaster with libc_r
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't know how to make test. Stop ref4# make Test static library: -- Test c_user c_system c_total chng passed/FAILEDh_user h_system h_total % chng -- hello_d 0.00 0.000.00 passed -- hello_s 0.00 0.010.01 passed -- join_leak_d 0.19 0.150.34 passed -- mutex_d (**hangs here**) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ATAPI_SET_SPEED on Panasonic LF-D321
I got this drive ("LF-D321" is printed in front of drive), but burncd
cannot set speed.
> acd1: DVD-R at ata1-slave PIO4
% sudo burncd -f /dev/acd1c data release.iso
burncd: ioctl(CDRIOCWRITESPEED): Input/output error
Dmesg shows:
> acd1: SET_SPEED - ILLEGAL REQUEST asc=0x20 ascq=0x00 error=0x00
Cannot this drive accept ATAPI_SET_SPEED atapi command?
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 when queue.h was reverted. Did > USRSTACK or SIGSTKSZ get changed somehow? > > 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. I'd try but... cc -Wall -pipe -g3 -D_LIBC_R_ -D_REENTRANT -c mutex_d.c -o mutex_d_a.o mutex_d.c:168: initializer element is not constant mutex_d.c: In function `waiter': mutex_d.c:358: warning: too few arguments for format *** Error code 1 Stop in /usr/src/lib/libc_r/test. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Another post-KSE bug?
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.. (and since I can't comit for a couple more hours) On Mon, 1 Jul 2002, Peter Wemm wrote: > This is on beast.freebsd.org, running -current as of about 20 minutes > ago. I just rm'ed a .o file and did a make: > > peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-6# rm yarrow.o > peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-7# make > cc -c -O -pipe -mcpu=ev56 -Wall -Wredundant-decls -Wnested-externs >-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >-Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev >-I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include >-D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev56 >-ffreestanding ../../../dev/random/yarrow.c > ^Z > [1] + Suspended make > peter@beast[5:33pm]/usr/src/sys/alpha/compile/BEAST-8# fg > make > [1] 327 Abort trap (core dumped) > *** Error code 134 > > Stop in /usr/src/sys/alpha/compile/BEAST. > > Since we're all having fun now, I thought I'd mention this one too. > > Cheers, > -Peter > -- > Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Julian Elischer wrote: > > 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 guess this means that teh KSE changes are in some way contaminating the > build of libc_r.. but what? and how? 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 when queue.h was reverted. Did USRSTACK or SIGSTKSZ get changed somehow? 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. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Another post-KSE bug?
This is on beast.freebsd.org, running -current as of about 20 minutes ago. I just rm'ed a .o file and did a make: peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-6# rm yarrow.o peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-7# make cc -c -O -pipe -mcpu=ev56 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wno-format -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev56 -ffreestanding ../../../dev/random/yarrow.c ^Z [1] + Suspended make peter@beast[5:33pm]/usr/src/sys/alpha/compile/BEAST-8# fg make [1] 327 Abort trap (core dumped) *** Error code 134 Stop in /usr/src/sys/alpha/compile/BEAST. Since we're all having fun now, I thought I'd mention this one too. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 guess this means that teh KSE changes are in some way contaminating the build of libc_r.. but what? and how? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[광고] freebsd-current님 로버트할리의 속성영어비법이 담긴 무료샘플테이프를 신청하세요.
Title: ces ±ÍÇÏÀÇ ½Â¶ô¾øÀÌ È«º¸¼º ÀüÀÚ ¿ìÆíÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°ú µå¸³´Ï´Ù. Á¤º¸Åë½Å¸ÁÀÌ¿ëÃËÁø¹ý ±ÔÁ¤À» ÁؼöÇÏ¿© ±¤°í¸ÞÀÏÀÓÀ» Ç¥½ÃÇÏ¿´À¸¸ç, ¼ö½Å°ÅºÎ ÀåÄ¡¸¦ ¸¶·ÃÇÏ°í ÀÖ½À´Ï´Ù. ±ÍÇÏÀÇ ÀüÀÚ ¿ìÆí ÁÖ¼Ò´Â ÀÎÅÍ³Ý »óÀÇ °ø°³µÈ Àå¼Ò¿¡¼ ½ÀµæÇÏ¿´À¸¸ç, ÀúÈñ´Â ±ÍÇÏÀÇ ÀüÀÚ¿ìÆí ÁÖ¼Ò ¿Ü ¾î¶°ÇÑ °³ÀÎÁ¤º¸µµ °¡Áö°í ÀÖÁö ¾ÊÀ¸¹Ç·Î ¾È½ÉÇϽñ⠹ٶø´Ï´Ù. ¼ö½ÅÀ» ¿øÄ¡ ¾ÊÀ¸½Ã¸é ¼ö½Å°ÅºÎ¸¦ Ŭ¸¯ÇØ Áֽʽÿä.
Re: Post-KSE disaster with libc_r
oops,, sorry, you are right.. still it's being so confusing with people saying this and that, that it's only now that I'm starting to believe that it's not the kernel doing something nasty. On Mon, 1 Jul 2002, Wesley Morgan wrote: > I already tried that this morning, 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 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 respectively. > > > > --end quote.. > > > > so that is uthread_sigpending.c version 1.18 > > and > > uthread_sigsuspend.c version 1.11 > > > > Thanks > > > > Julian > > > > > > > > > > On Mon, 1 Jul 2002, Wesley Morgan wrote: > > > > > Reverting proc.h and queue.h do nothing. Booting a kernel from 20020624, > > > still crashes all threaded systems. Same behavior on a 20020620 kernel. > > > > 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 problems. > > > >> > > > > > > > > > > > > It's still unclear if a KSE kernel works with an old libc_r or visa > > > > versa. > > > > > > > > I'd like to see if a new libc_r works with an old kernel (someone who > > > > can boot kernel.back and test...) > > > > > > > > to check if you have a non KSE kernel, > > > > sysctl kern.threads will only succeed in a new kernel. > > > > > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > > > > > > > -- >_ __ ___ ___ ___ ___ > Wesley N Morgan _ __ ___ | _ ) __| \ > [EMAIL PROTECTED] _ __ | _ \._ \ |) | > FreeBSD: The Power To Serve _ |___/___/___/ > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
I already tried that this morning, 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 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 respectively. > > --end quote.. > > so that is uthread_sigpending.c version 1.18 > and > uthread_sigsuspend.c version 1.11 > > Thanks > > Julian > > > > > On Mon, 1 Jul 2002, Wesley Morgan wrote: > > > Reverting proc.h and queue.h do nothing. Booting a kernel from 20020624, > > still crashes all threaded systems. Same behavior on a 20020620 kernel. > > > 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 problems. > > >> > > > > > > > > > It's still unclear if a KSE kernel works with an old libc_r or visa > > > versa. > > > > > > I'd like to see if a new libc_r works with an old kernel (someone who > > > can boot kernel.back and test...) > > > > > > to check if you have a non KSE kernel, > > > sysctl kern.threads will only succeed in a new kernel. > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 respectively. --end quote.. so that is uthread_sigpending.c version 1.18 and uthread_sigsuspend.c version 1.11 Thanks Julian On Mon, 1 Jul 2002, Wesley Morgan wrote: > Reverting proc.h and queue.h do nothing. Booting a kernel from 20020624, > still crashes all threaded systems. Same behavior on a 20020620 kernel. > > 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 problems. > >> > > > > > > It's still unclear if a KSE kernel works with an old libc_r or visa > > versa. > > > > I'd like to see if a new libc_r works with an old kernel (someone who > > can boot kernel.back and test...) > > > > to check if you have a non KSE kernel, > > sysctl kern.threads will only succeed in a new kernel. > > > > > > > > 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
[Fwd: Re: Post-KSE disaster with libc_r]
Somehow this thread slipped into privmail. Original Message Subject: Re: Post-KSE disaster with libc_r Date: Mon, 1 Jul 2002 14:23:23 -0700 (PDT) From: Julian Elischer <[EMAIL PROTECTED]> To: Michael Nottebrock <[EMAIL PROTECTED]> > [Applied 'thediff' to pre-KSE CURRENT and rebuilt world, things > break, things remain broken when booting the old kernel with the > new world.] THANKS!!! ok so it's libc_r for sure.. now we have two possibilities: 1/ It's ingherrently broken because of a recent change. if so, checking out 1 month old sources to libc_r and compiling it should yield a working libc_r. 2/ Something I've committed is polluting the compile. e.g. a namespace clash or similar in a new include file. In this case, teh new compile of old sources should yield a bad libc_r. can someone test this? msg40222/pgp0.pgp Description: PGP signature
picobsd redux
Hey Folks, So now I'm working somewhere that we're trying to use Picobsd on the Soekris boards (www.soekris.com). Right now there is a build problem I'm trying to solve. When picobsd goes to build the libraries etc. it chokes on the csu stuff: CC="cc" MKDEP_CPP_OPTS="-M -DCRT_BEGIN" mkdep -f .depend -a -nostdinc -I/sandb oxes/gnn/FreeBSD/src/../usr/include -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/sandboxes /gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/config -I/sandboxes/gnn/FreeBS D/src/gnu/lib/csu/../../../contrib/gcc -I. -I/sandboxes/gnn/FreeBSD/src/gnu/lib / csu/../../usr.bin/cc/cc_tools /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../ c ontrib/gcc/crtstuff.c cc -nostdinc -I/sandboxes/gnn/FreeBSD/src/../usr/include -DIN_GCC -DHAVE_LD_EH_ FRAME_HDR -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-o mit-frame-pointer -I/sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc / config -I/sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc -I. -I/san dboxes/gnn/FreeBSD/src/gnu/lib/csu/../../usr.bin/cc/cc_tools -g0 -DCRT_BEGIN - c -o crtbegin.o /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crt s tuff.c In file included from /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/g c c/crtstuff.c:63: /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:37 : field `array' has incomplete type /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:13 5 : field `augmentation' has incomplete type /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/unwind-dw2-fde.h:14 3 : field `pc_begin' has incomplete type /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:254: warn ing: `used' attribute directive ignored /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c: In funct ion `__do_global_dtors_aux': /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:256: synt ax error before `completed' /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:259: `com pleted' undeclared (first use in this function) /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:259: (Eac h undeclared identifier is reported only once /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:259: for each function it appears in.) /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c: At top l evel: /sandboxes/gnn/FreeBSD/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:298: warn ing: `used' attribute directive ignored *** Error code 1 Any pointers would be great, I need to get this stuff back up to snuff fast. Thanks, George -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
Reverting proc.h and queue.h do nothing. Booting a kernel from 20020624, still crashes all threaded systems. Same behavior on a 20020620 kernel. > 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 problems. >> > > > It's still unclear if a KSE kernel works with an old libc_r or visa > versa. > > I'd like to see if a new libc_r works with an old kernel (someone who > can boot kernel.back and test...) > > to check if you have a non KSE kernel, > sysctl kern.threads will only succeed in a new kernel. > > > > 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: More on gnome and mozilla (post-KSE)
÷ Mon, 01.07.2002, × 00:21, Julian Elischer ÎÁÐÉÓÁÌ: > 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? I have same problem, reverting to old (20020625) kernel not helps :( I was forced to get old world and make world. gkrellm gets 11 signal too, licq eats 100%CPU after forking qt plugin > 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 was still compiling, > > so whatever this problem is it was not due to changes > > in the kernel. > > > > > > 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 > -- Vladimir B. Grebenschikov [EMAIL PROTECTED], SWsoft, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Julian Elischer wrote: > 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 problems. > > > > > It's still unclear if a KSE kernel works with an old libc_r or visa versa. > > I'd like to see if a new libc_r works with an old kernel (someone who can > boot kernel.back and test...) > > to check if you have a non KSE kernel, > sysctl kern.threads will only succeed in a new kernel. 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. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 problems. > It's still unclear if a KSE kernel works with an old libc_r or visa versa. I'd like to see if a new libc_r works with an old kernel (someone who can boot kernel.back and test...) to check if you have a non KSE kernel, sysctl kern.threads will only succeed in a new kernel. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 versions > > of proc.h and queue.h in the system? > > What changed in queue.h? We do have some macros defined for presetting > queue.h *_HEAD's. > > -- > Dan Eischen > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LP64: (int)signal()
On Mon, 1 Jul 2002, Christian Weisgerber wrote: > Mike Barcroft <[EMAIL PROTECTED]> wrote: > > > You might want to get rid of the other misuse of `rc' above this and > > just remove the variable. > > The use of an gratuitous int variable rc to capture return values > is rampant throughout this code. In fact, not using it is something > of a violation of the local style, but in the case of signal() I > think it's justifiable because SIG_ERR is so much neater than > changing rc to long and messing around with explicit casts. How about eliminating signal() all together and using sigaction()? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Julian Elischer wrote: > > 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 compiled in). I got it even with updated userland and old > > pre-KSE kernel (with both updated I have it too). Only switching to libc_r > > old about month ago helps. > > Ok this is good news becasue it helps narrow the problem. > If an old libc_r runs well it at least suggests that the kernel is > working as it should. That is a great relief to me! > > My current guess is that something in an include file is poisonning the > compile of a new libc_r. > > I think we may need Dan to help us find it.. I'm a few days away from being able to upgrade to the latest -current. 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 problems. You can enable error checking when compiling libc_r and see if anything comes up too. It should be relatively error free (other than a few _ not being defined). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Julian Elischer wrote: > 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? What changed in queue.h? We do have some macros defined for presetting queue.h *_HEAD's. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 kernel and userland? > > This bug is not related to in-kernel KSE code (but, maybe related to > header files compiled in). I got it even with updated userland and old > pre-KSE kernel (with both updated I have it too). Only switching to libc_r > old about month ago helps. > > > > > > > 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 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? > > > > > > MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a > > > MR> post-KSE kernel (30.06.) and I've none of the described problems. > > > MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. > > > > > > I updated my current box about an hour ago, and got into trouble too. > > > > > > My case is that amavis-milter dumps core with signal 11 and I cannot check > > > virus in emails. :( > > > > > > $ sudo gdb ./amavis-milter /etc/mail/amavis-milter.core > > > 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 conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > > This GDB was configured as "i386-undermydesk-freebsd"... > > > Core was generated by `amavis-milter'. > > > Program terminated with signal 11, Segmentation fault. > > > Reading symbols from /usr/lib/libmilter.so.2...done. > > > Loaded symbols for /usr/lib/libmilter.so.2 > > > Reading symbols from /usr/lib/libc_r.so.5...done. > > > Loaded symbols for /usr/lib/libc_r.so.5 > > > Reading symbols from /usr/lib/libc.so.5...done. > > > Loaded symbols for /usr/lib/libc.so.5 > > > Reading symbols from /usr/libexec/ld-elf.so.1...done. > > > Loaded symbols for /usr/libexec/ld-elf.so.1 > > > #0 0x2808e918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 > > > (gdb) > > > -- > > > NAKAJI Hiroyuki > > > > > > 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 > > -- > Andrey A. Chernov > http://ache.pp.ru/ > > 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: Post-KSE disaster with libc_r
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 compiled in). I got it even with updated userland and old > pre-KSE kernel (with both updated I have it too). Only switching to libc_r > old about month ago helps. Ok this is good news becasue it helps narrow the problem. If an old libc_r runs well it at least suggests that the kernel is working as it should. That is a great relief to me! My current guess is that something in an include file is poisonning the compile of a new libc_r. I think we may need Dan to help us find it.. > > > > > > > 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 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? > > > > > > MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a > > > MR> post-KSE kernel (30.06.) and I've none of the described problems. > > > MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. > > > > > > I updated my current box about an hour ago, and got into trouble too. > > > > > > My case is that amavis-milter dumps core with signal 11 and I cannot check > > > virus in emails. :( > > > > > > $ sudo gdb ./amavis-milter /etc/mail/amavis-milter.core > > > 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 conditions. > > > Type "show copying" to see the conditions. > > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > > This GDB was configured as "i386-undermydesk-freebsd"... > > > Core was generated by `amavis-milter'. > > > Program terminated with signal 11, Segmentation fault. > > > Reading symbols from /usr/lib/libmilter.so.2...done. > > > Loaded symbols for /usr/lib/libmilter.so.2 > > > Reading symbols from /usr/lib/libc_r.so.5...done. > > > Loaded symbols for /usr/lib/libc_r.so.5 > > > Reading symbols from /usr/lib/libc.so.5...done. > > > Loaded symbols for /usr/lib/libc.so.5 > > > Reading symbols from /usr/libexec/ld-elf.so.1...done. > > > Loaded symbols for /usr/libexec/ld-elf.so.1 > > > #0 0x2808e918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 > > > (gdb) > > > -- > > > NAKAJI Hiroyuki > > > > > > 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 > > -- > Andrey A. Chernov > http://ache.pp.ru/ > > 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: Post-KSE disaster with libc_r
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 compiled in). I got it even with updated userland and old > pre-KSE kernel (with both updated I have it too). Only switching to libc_r > old about month ago helps. I applied "thediff" to a -CURRENT box as of June 25th and it promptly shows the symptoms, so I still think it's somewhere in the KSE-code. Regards, -- Michael Nottebrock "The circumstance ends uglily in the cruel result." - Babelfish msg40232/pgp0.pgp Description: PGP signature
Re: LP64: (int)signal()
Mike Barcroft <[EMAIL PROTECTED]> wrote: > You might want to get rid of the other misuse of `rc' above this and > just remove the variable. The use of an gratuitous int variable rc to capture return values is rampant throughout this code. In fact, not using it is something of a violation of the local style, but in the case of signal() I think it's justifiable because SIG_ERR is so much neater than changing rc to long and messing around with explicit casts. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Weird panic (possibly KSE related)
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 be completely undebuggable. It drops
> into DDB> but the serial port is completely screwed up and I can't type.
> Hitting gives me colons and semicolons at db> prompt. Changing
> baud rates does not seem to help.
>
> This has occured twice. I am going to try dropping back to a standard
> console to see if I can get better debugging. I don't know if this is
> KSE related or not.
>
> I've included the serial console output.
>
> -Matt
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id = 0100
> fault virtual address = 0xb
> fault code = supervisor write, page not present
> instruction pointer = 0xd35:0xe
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; lapic.id = 0100
> fault virtual addrepsasni=:
>t nceode!
> p=
>
> cs
>puupeirdv =is o1r; lraeapdi
> n c, .pidag e= n0o0t00 0pr00es0e
> tDe
> niugnsgetrru("cptaioninc "p)oi
> Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
> db> ;;:
>
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
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 compiled in). I got it even with updated userland and old pre-KSE kernel (with both updated I have it too). Only switching to libc_r old about month ago helps. > > > 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 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? > > > > MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a > > MR> post-KSE kernel (30.06.) and I've none of the described problems. > > MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. > > > > I updated my current box about an hour ago, and got into trouble too. > > > > My case is that amavis-milter dumps core with signal 11 and I cannot check > > virus in emails. :( > > > > $ sudo gdb ./amavis-milter /etc/mail/amavis-milter.core > > 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 conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-undermydesk-freebsd"... > > Core was generated by `amavis-milter'. > > Program terminated with signal 11, Segmentation fault. > > Reading symbols from /usr/lib/libmilter.so.2...done. > > Loaded symbols for /usr/lib/libmilter.so.2 > > Reading symbols from /usr/lib/libc_r.so.5...done. > > Loaded symbols for /usr/lib/libc_r.so.5 > > Reading symbols from /usr/lib/libc.so.5...done. > > Loaded symbols for /usr/lib/libc.so.5 > > Reading symbols from /usr/libexec/ld-elf.so.1...done. > > Loaded symbols for /usr/libexec/ld-elf.so.1 > > #0 0x2808e918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 > > (gdb) > > -- > > NAKAJI Hiroyuki > > > > 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 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Weird panic (possibly KSE related)
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 be completely undebuggable. It drops
into DDB> but the serial port is completely screwed up and I can't type.
Hitting gives me colons and semicolons at db> prompt. Changing
baud rates does not seem to help.
This has occured twice. I am going to try dropping back to a standard
console to see if I can get better debugging. I don't know if this is
KSE related or not.
I've included the serial console output.
-Matt
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0xb
fault code = supervisor write, page not present
instruction pointer = 0xd35:0xe
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual addrepsasni=:
t nceode!
p=
cs
puupeirdv =is o1r; lraeapdi
n c, .pidag e= n0o0t00 0pr00es0e
tDe
niugnsgetrru("cptaioninc "p)oi
Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
db> ;;:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: FW: UMA question..
> > 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 have their stacks etc. attached to > them. These are only splitt off when the UMA decides to stop caching an > item and actualy return it's memory to the system. > In this regard the UMA allocator is not a memory alocator but a 'complex > object allocator'... Very cool. > > Now my question.. > > I ant to allocate proc structures the same way... > in other words, I want a cached proc structure to already have a thread > attached to it and a stack attached to the thread.. > Is it legal for teh init function which is called by UMA to in turn > call UMA to allocate a sub element.. > > so if I do uma_zalloc(proc args) > that in turn should do a uma_zalloc(thread args). > would this work? is it legal? No locks are held when doing init ctor or fini. The zone and possibly per cpu queue lock is held while doing the dtor though. So it is safe as long as you don't cause a recursive allocation in the same zone. In short, what you want to do is perfectly reasonable. > > I need to allocate extra threads independantly of processes, but I could > work it so that freed process structures always had a single thread left > on them, which would save on allocations.. > In the future I need to do teh same for KSEs and KSEGRPS. sp having > UMA cache pre-constructed complex items made up of groups of separatly > UMA-allocated objects would be a great saving.. > > the question is.. will it work? can I call UMA from withing a UMA > constructor? > > > > 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: Post-KSE disaster with libc_r
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 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? > > MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a > MR> post-KSE kernel (30.06.) and I've none of the described problems. > MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. > > I updated my current box about an hour ago, and got into trouble too. > > My case is that amavis-milter dumps core with signal 11 and I cannot check > virus in emails. :( > > $ sudo gdb ./amavis-milter /etc/mail/amavis-milter.core > 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 conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-undermydesk-freebsd"... > Core was generated by `amavis-milter'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/lib/libmilter.so.2...done. > Loaded symbols for /usr/lib/libmilter.so.2 > Reading symbols from /usr/lib/libc_r.so.5...done. > Loaded symbols for /usr/lib/libc_r.so.5 > Reading symbols from /usr/lib/libc.so.5...done. > Loaded symbols for /usr/lib/libc.so.5 > Reading symbols from /usr/libexec/ld-elf.so.1...done. > Loaded symbols for /usr/libexec/ld-elf.so.1 > #0 0x2808e918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 > (gdb) > -- > NAKAJI Hiroyuki > > 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
PANIC Most recently used by routetbl
Hi,
panic: Most recently used by routetbl
I get this type of panic withing minutes of uptime with a -current of
25-Jun-2002 around 13:52 GMT-2. Another anomaly is that name resolution
doesn't seem to work reliably, or maybe even TCP in general has a
problem -- it all takes very long if it works at all.
This is still a pre-KSE-III system.
As a workaround I am currently running with a kernel of about 11 Apr in
the same userland, which seems to work.
hunter[4]$ gdb -k kernel.debug vmcore.25
GNU gdb 4.18 (FreeBSD)
Copyright 1998 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 conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at
/usr/src/contrib/gdb/gdb/dbxread.c line 2617 in elfstab_build_psymtabs
Deprecated bfd_read called at /usr/src/contrib/gdb/gdb/dbxread.c line 930 in
fill_symbuf
IdlePTD at physical address 0x00498000
initial pcb at physical address 0x003b3cc0
panicstr: bremfree: bp 0xd2a84230 not locked
panic messages:
---
panic: Most recently used by routetbl
syncing disks... panic: bremfree: bp 0xd2a84230 not locked
Uptime: 24m55s
pfs_vncache_unload(): 2 entries remaining
/dev/vmmon: Module vmmon: unloaded
Dumping 1023 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0 0xc01cff40 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
353 }
(kgdb) where
#0 0xc01cff40 in doadump () at /usr/src/sys/kern/kern_shutdown.c:353
#1 0xc01d054b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:353
#2 0xc01d0767 in panic (fmt=0xc034f0a9 "bremfree: bp %p not locked")
at /usr/src/sys/kern/kern_shutdown.c:353
#3 0xc02146a6 in bremfree (bp=0xd2a84230) at /usr/src/sys/kern/vfs_bio.c:1368
#4 0xc021723b in getblk (vp=0xc624e000, blkno=262208, size=8192, slpflag=0,
slptimeo=0) at /usr/src/sys/kern/vfs_bio.c:1368
#5 0xc02147d1 in breadn (vp=0xc624e000, blkno=262208, size=8192, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0xe557aa40)
at /usr/src/sys/kern/vfs_bio.c:1368
#6 0xc0214793 in bread (vp=0xc624e000, blkno=262208, size=8192, cred=0x0,
bpp=0xe557aa40) at /usr/src/sys/kern/vfs_bio.c:1368
#7 0xc029cb62 in ffs_update (vp=0xc6658e00, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:441
#8 0xc02b24ba in ffs_fsync (ap=0xe557aab4)
at /usr/src/sys/ufs/ufs/ufs_readwrite.c:596
#9 0xc02b0b9c in VOP_FSYNC (vp=0xc6658e00, cred=0xc21a1f00, waitfor=2,
td=0xc037d6a0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:813
#10 0xc02afff4 in ffs_sync (mp=0xc60d8600, waitfor=2, cred=0xc21a1f00,
td=0xc037d6a0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:813
#11 0xc022736c in sync (td=0xc037d6a0, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:584
#12 0xc01d0055 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:353
#13 0xc01d0767 in panic (fmt=0xc0360748 "Most recently used by %s\n")
at /usr/src/sys/kern/kern_shutdown.c:353
#14 0xc02d6f3a in mtrash_ctor (mem=0xc697cc00, size=252, arg=0x0)
at /usr/src/sys/vm/uma_dbg.c:284
#15 0xc02d5765 in uma_zalloc_arg (zone=0xc2179140, udata=0x0, flags=0)
at /usr/src/sys/vm/uma_core.c:663
#16 0xc01c5254 in uma_zalloc (zone=0xc2179140, flags=0)
at /usr/src/sys/kern/kern_malloc.c:555
#17 0xc01c484b in malloc (size=224, type=0xc037e760, flags=0)
at /usr/src/sys/kern/kern_malloc.c:555
#18 0xc01b34d2 in fdcopy (td=0xc62ccd70)
at /usr/src/sys/kern/kern_descrip.c:476
#19 0xc01bb7bd in fork1 (td=0xc62ccd70, flags=20, procp=0xe557acd8)
at /usr/src/sys/kern/kern_fork.c:734
#20 0xc01baea6 in fork (td=0xc62ccd70, uap=0xe557acfc)
at /usr/src/sys/kern/kern_fork.c:734
#21 0xc0310af6 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = 70, tf_ebp = -1077937164, tf_isp = -447238796,
tf_ebx = 678978900, tf_edx = 484, tf_ecx = -33, tf_eax = 2,
tf_trapno = 12, tf_err = 2, tf_eip = 672142263, tf_cs = 31,
tf_eflags = 642, tf_esp = -1077937224, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:655
#22 0xc02ff8ed in syscall_with_err_pushed () at /var/tmp//ccMqLVIG.s:128
#23 0x2877f460 in ?? ()
#24 0x2877e79b in ?? ()
#25 0x28776f62 in ?? ()
#26 0x28776e45 in ?? ()
#27 0x287765c1 in ?? ()
#28 0x8055304 in ?? ()
#29 0x805caea in ?? ()
#30 0x805d267 in ?? ()
#31 0x804fdad in ?? ()
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On Sun, Jun 30, 2002 at 11:58:51PM -0400, Garance A Drosihn wrote: > Have many people had a chance to test this? I wanted to try it out > this weekend, but I lost most of the weekend due to other problems > with compiling current on my test machine. I finally got by those > problems, but now it's midnight on Sunday and I can't really afford > to start on this right now... Sorry, me not. I also was struggling with -CURRENT buildworld during the weekend and my machine is slow. I rebuilt X with the most recent patch to libGLU from this list and libGLU now seems working. (with the system compiler) The machine freezes under X quite frequently however, but I don't know what is causing it. (and X freezes have the disgusting property of locking up the system solid: no console, no network, nothing in the logs.) Life is sometimes hard in -CURRENT land, but hey, we should never loose our sense of humour. (And yes, maybe I really should get another graphics card... the S3 Virge GX2 may also take part of the blame for the lockups...) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
Ktracing with context switches look the same as before
Stepping into libc_r leads me on a merry chase through what appears to be
normal execution, until somewhere in uthread_sig.c about line 552...
(gdb) r
Starting program: /usr/local/bin/kdeinit
Breakpoint 1 at 0x28e839f6: file
/usr/src/lib/libc_r/uthread/uthread_fork.c, line 49.Breakpoint 1, 0x28eda7d4 in fork
() from /usr/lib/libc.so.5
(gdb) b /usr/src/lib/libc_r/uthread/uthread_sig.c:546
Breakpoint 2 at 0x28e8723d: file
/usr/src/lib/libc_r/uthread/uthread_sig.c, line 546.(gdb) c
Continuing.
Breakpoint 2, thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:546
546 for (pthread = TAILQ_FIRST(&_waitingq);
(gdb) print _waitingq
$1 = {tqh_first = 0x8054000, tqh_last = 0x8054210}
(gdb) s
0x28e8723e in thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:546
546 for (pthread = TAILQ_FIRST(&_waitingq);
Program received signal SIGSEGV, Segmentation fault.
0x28e8723e in thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:546
546 for (pthread = TAILQ_FIRST(&_waitingq);
Odd... Now if I set a breakpoint inside of the for() loop at line 552, it
will actually get past that:
Breakpoint 2, thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:552
552 pthread_next = TAILQ_NEXT(pthread, pqe);
(gdb) s
558 if (pthread->state == PS_WAIT_WAIT) {
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
thread_sig_handle_special (sig=20)
at /usr/src/lib/libc_r/uthread/uthread_sig.c:558
558 if (pthread->state == PS_WAIT_WAIT) {
(gdb) print pthread
$1 = (struct pthread *) 0x210
That definitely is not right!
Backing up, this is the content of the pthread struct before it gets
munched into 0x210 (re-ran the process of course)$1 = {magic = 3499860245,
name = 0x8056030 "_thread_initial", uniqueid = 0, lock = {access_lock = 686322256,
lock_owner = 0, fname = 0x0, lineno = 0},
tle = {tqe_next = 0x0, tqe_prev = 0x28e94a88}, dle = {tqe_next = 0x0,
tqe_prev = 0x0}, start_routine = 0, arg = 0x0, stack = 0xbfb0,
attr = {sched_policy = 3, sched_inherit = 0, sched_interval = 2, prio = 15,
suspend = 0, flags = 0, arg_attr = 0x0, cleanup_attr = 0,
stackaddr_attr = 0xbfb0, stacksize_attr = 1048576,
guardsize_attr = 4096}, ctx = {jb = {{_jb = {686343554, 686378132,
-1077939364, -1077939336, -1, 134561792, 4735, 0, 0, 0, 0, 0}}},
uc = {uc_sigmask = {__bits = {686343554, 686378132, 3217027932,
3217027960}}, uc_mcontext = {mc_onstack = -1, mc_gs = 134561792,
mc_fs = 4735, mc_es = 0, mc_ds = 0, mc_edi = 0, mc_esi = 0,
mc_ebp = 0, mc_isp = 0, mc_ebx = 0, mc_edx = 0, mc_ecx = 0,
mc_eax = 0, mc_trapno = 0, mc_err = 0, mc_eip = 0, mc_cs = 0,
mc_eflags = 0, mc_esp = 0, mc_ss = 0, mc_fpregs = {
0 }, mc_flags = 0, __spare__ = {
0 }}, uc_link = 0x0, uc_stack = {ss_sp = 0x0,
ss_size = 0, ss_flags = 0}, __spare__ = {0, 0, 0, 0, 0, 0, 0, 0}}},
curframe = 0x0, cancelflags = 4, continuation = 0, sigmask = {__bits = {0,
0, 0, 0}}, sigpend = {__bits = {0, 0, 0, 0}}, sigmask_seqno = 0,
check_pending = 0, state = PS_FDR_WAIT, last_active = 0, last_inactive = 0,
slice_usec = -1, wakeup_time = {tv_sec = -1, tv_nsec = -1}, timeout = 0,
error = 0, joiner = 0x0, join_status = {thread = 0x0, ret = 0x0, error =
0}, pqe = {tqe_next = 0x0, tqe_prev = 0x28e9a8d0}, sqe = {tqe_next =
0x0,tqe_prev = 0x0}, qe = {tqe_next = 0x0, tqe_prev = 0x28e97080}, data = {
mutex = 0x7, cond = 0x7, sigwait = 0x7, fd = {fd = 7, branch = 0,
fname = 0x0}, fp = 0x7, poll_data = 0x7, spinlock = 0x7, thread = 0x7},
poll_data = {nfds = 0, fds = 0x0}, interrupted = 0, signo = 0,
sig_defer_count = 0, yield_on_sig_undefer = 0, flags = 20,
base_priority = 15 '\017', inherited_priority = 0 '\0',
active_priority = 15 '\017', priority_mutex_count = 0, mutexq = {
tqh_first = 0x0, tqh_last = 0x8054254}, ret = 0x0, specific = 0x0,
specific_data_count = 0, cleanup = 0x0,
fname = 0x28e925a0 "/usr/src/lib/libc_r/uthread/uthread_read.c", lineno
= 81}
Of course all this means absolutely nothing to me :) ... Setting the
breakpoint just past the for() loop give me the same old crash as before:
#0 thread_kern_poll (wait_reqd=0)
at /usr/src/lib/libc_r/uthread/uthread_kern.c:862
#1 0x28e8c8d7 in _thread_kern_scheduler ()
at /usr/src/lib/libc_r/uthread/uthread_kern.c:372
#2 0xd0d0d0d0 in ?? ()
(gdb) print pthread
$2 = (struct pthread *) 0x
That's all I've got for now. Someone please tell me if posting this much
junk to -current is frowned upon. I'm looking for an old libc_r now, but
there could be some problems with the GCC changeout since DP1 that won't
work too well with KDE...
> can you
Re: LP64: (int)signal()
Christian Weisgerber <[EMAIL PROTECTED]> writes:
> I would like to clean up the last instances of (int)signal(...) in
> the tree. Any objection to the changes below?
>
> Other occurrences not worth touching:
> - contrib/opie/opieftpd.c: contrib, not used
> - libexec/bootpd/bootpd.c: #ifdef'ed out in favor of sigaction().
>
> Index: atmarpd/atmarpd.c
> ===
> RCS file: /home/ncvs/src/usr.sbin/atm/atmarpd/atmarpd.c,v
> retrieving revision 1.4
> diff -u -r1.4 atmarpd.c
> --- atmarpd/atmarpd.c 9 Dec 2000 09:35:42 - 1.4
> +++ atmarpd/atmarpd.c 1 Jul 2002 11:38:07 -
> @@ -294,8 +294,7 @@
> /*
>* Set up signal handlers
>*/
> - rc = (int)signal(SIGINT, atmarp_sigint);
> - if (rc == -1) {
> + if (signal(SIGINT, atmarp_sigint) == SIG_ERR) {
> atmarp_log(LOG_ERR, "SIGINT signal setup failed");
> exit(1);
> }
You might want to get rid of the other misuse of `rc' above this and
just remove the variable.
> Index: scspd/scspd.c
> ===
> RCS file: /home/ncvs/src/usr.sbin/atm/scspd/scspd.c,v
> retrieving revision 1.4
> diff -u -r1.4 scspd.c
> --- scspd/scspd.c 9 Dec 2000 09:35:42 - 1.4
> +++ scspd/scspd.c 1 Jul 2002 11:38:08 -
> @@ -319,14 +319,12 @@
> /*
>* Set up signal handlers
>*/
> - rc = (int)signal(SIGHUP, scsp_sighup);
> - if (rc == -1) {
> + if (signal(SIGHUP, scsp_sighup) == SIG_ERR) {
> scsp_log(LOG_ERR, "SIGHUP signal setup failed");
> exit(1);
> }
>
> - rc = (int)signal(SIGINT, scsp_sigint);
> - if (rc == -1) {
> + if (signal(SIGINT, scsp_sigint) == SIG_ERR) {
> scsp_log(LOG_ERR, "SIGINT signal setup failed");
> exit(1);
> }
[Repeat above sentence.] :)
Otherwise it looks good.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: getting back to current
On Sun, 30 Jun 2002, Doug Barton wrote: > 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 back to current. > > Glad to hear you're feeling better. :) The bad news is that this is a > really terrible time to upgrade to -current. The KSE mark III update > just went in, so things are very unstable right now. Clearing out about 50,000 old mails today ... need to update myself. Much thanks for the heads-up. I'm OK with instability, I'm used to that, as long as it works at least a bit. > > I just finished cvsupping, and the main sources built just fine. I > > installed a new config (static, the libs are now too old) and fixed all > > the changes in my config file, so now my kernel file configs but it > > doesn't build (breaks in 'make depend', I think in genassym). I'm > > guessing that this is only one of a string of incompatibilities, in > > jumping from 4.5 back to current. > > 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. > > You'll probably want to read -current and cvs-all for a while before > you finish the upgrade though > > HTH, > > Doug > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld problems with today's sources
On Mon, 2002-07-01 at 09:02, Luigi Rizzo wrote: > On Mon, Jul 01, 2002 at 09:58:04AM -0400, Andrew Gallatin wrote: > ... > > That's actually rather scary. It implies that a freshly checked out > > tree checked out with plain 'cvs co src' is no longer buildable. > > c'mon... it is not that terrible, just a matter of adding a -P flag > Do these problems concern someone using cvsup? I've been having a terrible time with -current lately. Of course I realize development is going full speed, I'm being patient and using the down time to encourage others to turn to FreeBSD. The file system is blazing fast and as soon as the kernel smooths out FreeBSD-5.0 is going to rock. I'm very happy with FreeBSD. It does take a very great deal of studying, but once you've done that it's so ultimately powerful. To my dismay I've only just scratched the surface, but I'm not giving up yet! My thanks goes out to all those valuable FreeBSD commits. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libc_r now dumps core
Several threaded applications like mnogosearch, drweb-sendmail now dumps core (recent -current). When libc_r replaced by old variant, they works again. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav <[EMAIL PROTECTED]> writes: > gzip: stdout: No space left on device > *** Error code 1 I moved the Alpha build to a different disk, the next run should be OK. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Is pcm broken?
> > 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 >mailto:[EMAIL PROTECTED] >mailto:[EMAIL PROTECTED] > Hi, My calibration fix for the ich driver might have broken your setup. Could you boot with bootverbose set and send me the dmesg output? Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld problems with today's sources
On Mon, Jul 01, 2002 at 09:58:04AM -0400, Andrew Gallatin wrote: ... > That's actually rather scary. It implies that a freshly checked out > tree checked out with plain 'cvs co src' is no longer buildable. c'mon... it is not that terrible, just a matter of adding a -P flag luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld problems with today's sources
Luigi Rizzo writes: > On Mon, Jul 01, 2002 at 09:47:26AM -0400, Andrew Gallatin wrote: > > > > The same thing happened to me when buildworlding on a ~june 20th > > current box. > > Ruslan explained me the source of the problem... cvs does not > prune empty directories unless you specify a revision or a date. > In my case i wanted HEAD so i did > > cvs co src > > whereas I should have done > > cvs co -P src > > After doing that, mostly things worked (modulo the fact that i probably > was in the middle of some commit and there was some breakage > somewhere, but nothing important) Ah! That makes sense. I lost a few hundred files after the fsck, so I did an 'lcvs up' to make sure none of the src tree was missing. And my .cvsrc has 'update -Pd' in it. It had been a fresh checkout previously. That's actually rather scary. It implies that a freshly checked out tree checked out with plain 'cvs co src' is no longer buildable. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld problems with today's sources
On Mon, Jul 01, 2002 at 09:47:26AM -0400, Andrew Gallatin wrote: > > The same thing happened to me when buildworlding on a ~june 20th > current box. Ruslan explained me the source of the problem... cvs does not prune empty directories unless you specify a revision or a date. In my case i wanted HEAD so i did cvs co src whereas I should have done cvs co -P src After doing that, mostly things worked (modulo the fact that i probably was in the middle of some commit and there was some breakage somewhere, but nothing important) cheers luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld problems with today's sources
The same thing happened to me when buildworlding on a ~june 20th current box. I removed CPUTYPE from /etc/make.conf, and I fsck'ed the disk in question (after a crash resulting from the condvar problem discussed here). And I removed -j4 from my make flags. One of these things (sorry that I don't know which), cured the problem. I was mainly interested in getting a -current world, not diagnosing the breakage. Drew Luigi Rizzo writes: <...> > Stop in /home/luigi/XORP/HEAD_020630/src/gnu/usr.bin/tar. > *** Error code 1 <...> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
LP64: (int)signal()
I would like to clean up the last instances of (int)signal(...) in
the tree. Any objection to the changes below?
Other occurrences not worth touching:
- contrib/opie/opieftpd.c: contrib, not used
- libexec/bootpd/bootpd.c: #ifdef'ed out in favor of sigaction().
Index: atmarpd/atmarpd.c
===
RCS file: /home/ncvs/src/usr.sbin/atm/atmarpd/atmarpd.c,v
retrieving revision 1.4
diff -u -r1.4 atmarpd.c
--- atmarpd/atmarpd.c 9 Dec 2000 09:35:42 - 1.4
+++ atmarpd/atmarpd.c 1 Jul 2002 11:38:07 -
@@ -294,8 +294,7 @@
/*
* Set up signal handlers
*/
- rc = (int)signal(SIGINT, atmarp_sigint);
- if (rc == -1) {
+ if (signal(SIGINT, atmarp_sigint) == SIG_ERR) {
atmarp_log(LOG_ERR, "SIGINT signal setup failed");
exit(1);
}
Index: scspd/scspd.c
===
RCS file: /home/ncvs/src/usr.sbin/atm/scspd/scspd.c,v
retrieving revision 1.4
diff -u -r1.4 scspd.c
--- scspd/scspd.c 9 Dec 2000 09:35:42 - 1.4
+++ scspd/scspd.c 1 Jul 2002 11:38:08 -
@@ -319,14 +319,12 @@
/*
* Set up signal handlers
*/
- rc = (int)signal(SIGHUP, scsp_sighup);
- if (rc == -1) {
+ if (signal(SIGHUP, scsp_sighup) == SIG_ERR) {
scsp_log(LOG_ERR, "SIGHUP signal setup failed");
exit(1);
}
- rc = (int)signal(SIGINT, scsp_sigint);
- if (rc == -1) {
+ if (signal(SIGINT, scsp_sigint) == SIG_ERR) {
scsp_log(LOG_ERR, "SIGINT signal setup failed");
exit(1);
}
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/j/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> gnu/usr.bin/dialog ===> gnu/usr.bin/dialog/TESTS ===> gnu/usr.bin/diff /j/des/src/contrib/diff/prepend_args.c: In function `prepend_default_options': /j/des/src/contrib/diff/prepend_args.c:74: warning: initialization makes pointer from integer without a cast /j/des/src/contrib/diff/prepend_args.c:78: warning: cast to pointer from integer of different size ===> gnu/usr.bin/diff/doc /j/des/src/gnu/usr.bin/diff/doc/../../../../contrib/diff/diff.texi:2678: warning: unlikely character ] in @var. gzip: stdout: No space left on device *** Error code 1 Stop in /j/des/src/gnu/usr.bin/diff/doc. *** Error code 1 Stop in /j/des/src/gnu/usr.bin/diff. *** Error code 1 Stop in /j/des/src/gnu/usr.bin. *** Error code 1 Stop in /j/des/src/gnu. *** Error code 1 Stop in /j/des/src. *** Error code 1 Stop in /j/des/src. *** Error code 1 Stop in /j/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sparc64 tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating >/home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- ===> share/doc/smm/title ===> share/doc/smm/contents ===> share/doc/smm/01.setup ===> share/doc/smm/02.config ===> share/doc/smm/03.fsck ===> share/doc/smm/04.quotas ===> share/doc/smm/05.fastfs ===> share/doc/smm/06.nfs ===> share/doc/smm/10.named make: don't know how to make 00macs.me. Stop *** Error code 2 Stop in /usr/home/des/tinderbox/sparc64/src/share/doc/smm. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/share/doc. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/share. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
> MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a > MR> post-KSE kernel (30.06.) and I've none of the described problems. > MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. > > I updated my current box about an hour ago, and got into trouble too. But you've updated the userland _and_ the kernel. I've only updated the kernel and left the userland int the pre-KSE state. Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
> 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 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? MR> I don't know if this helps, but I've a pre-KSE userland (28.06.), a MR> post-KSE kernel (30.06.) and I've none of the described problems. MR> Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. I updated my current box about an hour ago, and got into trouble too. My case is that amavis-milter dumps core with signal 11 and I cannot check virus in emails. :( $ sudo gdb ./amavis-milter /etc/mail/amavis-milter.core 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 conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... Core was generated by `amavis-milter'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libmilter.so.2...done. Loaded symbols for /usr/lib/libmilter.so.2 Reading symbols from /usr/lib/libc_r.so.5...done. Loaded symbols for /usr/lib/libc_r.so.5 Reading symbols from /usr/lib/libc.so.5...done. Loaded symbols for /usr/lib/libc.so.5 Reading symbols from /usr/libexec/ld-elf.so.1...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2808e918 in _thread_kern_sched_state_unlock () from /usr/lib/libc_r.so.5 (gdb) -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
> 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 don't know if this helps, but I've a pre-KSE userland (28.06.), a post-KSE kernel (30.06.) and I've none of the described problems. Evolution, KDE3, Mozilla, ogg123, jdk13 all run without a problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Build world problems in todays sources
Glenn Gombert writes: > 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've seen this and if I remember anything it was sed or awk problem. Do first cd /usr/src/usr.bin/sed ; make all install and then try buildworld again. Tomppa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: qt3 and kde-2.2.2
According to Beech Rintoul: > Will kde-2.2.2 work with qt3? No. Qt3 is only for kde 3.x. > Or will I completely hose my desktop? > My qt2 got borked during a restore and I can't get it to build with the new > gcc31. Add that to several others that won't build either. Best way is to go to kde3. It is faster anyway (although the speed of C++ compilation with gcc31 makes it a dog to compile...). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails at share/doc/smm/10.named
NAKAJI Hiroyuki wrote: > > > In <[EMAIL PROTECTED]> > > NAKAJI Hiroyuki <[EMAIL PROTECTED]> wrote: > > NH> I noticed share/doc/smm/10.named fails after dougb's commit deleting > NH> contrib/bind/doc/bog/*. > > Oops. Dougb already fixed the problem about 2 hours ago. Yep, sorry about that my pre-commit build/installworld went fine, but I caught the problem after checking out a clean tree and doing the buildworld again. Mea culpa. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kde3 compile probs..
According to Michael L. Hostbaek: > When trying to compile the kdebase3 port under recent -CURRENT - I get > the following error: Are you sure your libstdc++ is in sync ? Hvae you compiled QT with the ports gcc (it will break if not) ? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic on apm resume with ata
According to Gavin Atkinson: > My laptop powered off due to a flat battery, and upon powerup, i > immediately experienced a panic. > > ata0: resetting devices .. done > panic: ata_dmasetup: transfer active on this device! It does happen sometimes on my Z600TEL Vaio too. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails at share/doc/smm/10.named
> In <[EMAIL PROTECTED]> > NAKAJI Hiroyuki <[EMAIL PROTECTED]> wrote: NH> I noticed share/doc/smm/10.named fails after dougb's commit deleting NH> contrib/bind/doc/bog/*. Oops. Dougb already fixed the problem about 2 hours ago. I'm now under fourth buildworld today. Thanks. -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld fails at share/doc/smm/10.named
Hi, I noticed share/doc/smm/10.named fails after dougb's commit deleting contrib/bind/doc/bog/*. === Revision 1.1.1.2 (vendor branch), Mon Jul 1 01:27:59 2002 UTC (6 hours, 43 minutes ago) by dougb Branch: VIXIE, MAIN, ISC CVS Tags: HEAD Changes since 1.1.1.1: +0 -0 lines FILE REMOVED I don't think we ever installed these files, and they are more than a little dated. === Error message is, ===> share/doc/smm/10.named make: don't know how to make 00macs.me. Stop *** Error code 2 Stop in /usr/src/share/doc/smm. *** Error code 1 Stop in /usr/src/share/doc. *** Error code 1 Stop in /usr/src/share. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- NAKAJI Hiroyuki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Re: Which .info files have been disabled?
On (2002/06/30 11:15), Szilveszter Adam wrote: > 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!) I've tested your patch through a 'make world' and have committed your patch: rev 1.12src/gnu/usr.bin/binutils/doc/Makefile rev 1.4 src/gnu/usr.bin/binutils/doc/inc-hist.diff Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Post-KSE disaster with libc_r
On Mon, 1 Jul 2002, Wesley Morgan wrote: > > Both the kdeinit and a child it forks are dying... Setting a breakpoint of > fork() in the binary shows: > > > Breakpoint 1, 0x28eda7d4 in fork () from /usr/lib/libc.so.5 > (gdb) bt > #0 0x28eda7d4 in fork () from /usr/lib/libc.so.5 > #1 0x28e83a5c in fork () from /usr/lib/libc_r.so.5 > #2 0x0804e8d5 in QGListIterator::~QGListIterator() () > #3 0x0804add1 in QGListIterator::~QGListIterator() () > (gdb) s > Single stepping until exit from function fork, > which has no line number information. > 0x28e83a5c in fork () from /usr/lib/libc_r.so.5 > (gdb) > Single stepping until exit from function fork, > which has no line number information. > warning: Cannot insert breakpoint 0: > Error accessing memory address 0xd0d0d0d0: Bad address. > (gdb) > > the 0xd0d0d0d0 is the same as in the coredump earlier. > > Rebuilt libc_r with debugging symbols and... > In the ktrace, an you show context switches? (add -w to both ktrace and kdump) Is this where is broke? it doesn't look much like the above.. > > (gdb) bt > #0 thread_kern_poll (wait_reqd=0) > at /usr/src/lib/libc_r/uthread/uthread_kern.c:862 > #1 0x28e8c8d7 in _thread_kern_scheduler () > at /usr/src/lib/libc_r/uthread/uthread_kern.c:372 > #2 0xd0d0d0d0 in ?? () > #3 0x0001 in ?? () > #4 0x5f28 in ?? () > Error accessing memory address 0xbecf2000: Bad address. > can you do what you did before and try singlestep a bit? also.. instead of checking out an older libc_r, can you try see if there is actually on old copy (say from teh DP1-image) somewhere and try that... it's possible we have symbol polution problemm.. a lot 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 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 likely that it's breakage in signals from KSE > > but I'd like to know that before I tear even more hair out chasing this.. > > > > SO, I'm suffering from brain fade now.. > > but please, signals is known to be in dire need of cleanup > > after the KSE edit, (signals are delivered to processes but can effect > > individual threads. yuck) > > > > Anyone who can help identify the problem please do.. I'm off to bed before > > my head explodes.. > > I'll be back tomorrow AM. > > I'm going to spend as much of msuspension sleeping as possible :-) > > > > 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 > > > 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_kern_scheduler () from /usr/lib/libc_r.so.5 > > > #2 0xd0d0d0d0 in ?? () > > > #3 0x0001 in ?? () > > > #4 0x5f28 in ?? () > > > > > > > > > > > > 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, 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 > > > > > #1 0x281cc2e2 in _thread_kern_scheduler () from /usr/lib/libc_r.so.5 > > > > > #2 0xd0d0d0d0 in ?? () > > > > > #3 0x080570b0 in ?? () > > > > > > > > This is unlikely to be a KSE problem. > > > > > > > > What do the rest of the threads look like ? > > > > > > > > Try "info threads" in gdb and then progressively walking through the thread > > > > list with "thread N", N being the thread number. I ran into a funny > > > > create at thread start up time crash and I'm wondering if it could > > > > be the same thing. > > > > > > > > bill > > > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > > with "unsubscribe freebsd-current" in the body of the message > > > > > > > > > > -- > > >_ __ ___ ___ ___ ___ > > > Wesley N Morgan _ __ ___ | _ ) __| \ > > > [EMAIL PROTECTED] _ __ | _ \._ \ |) | > > > FreeBSD: The Power To Serve _ |___/___/___/ > > > Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > > with "unsubscribe freebsd-current" in the body of the message > > > >
is buildworld broken?
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/src/gnu/usr.bin/cc/cc_int/../cc_tools/tconfig.h:10, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/hconfig.h:2, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/config.h:1, from /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/timevar.c:22: /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:70: warning: `TARGET_DEFAULT' redefined /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:400: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:83: warning: `FUNCTION_VALUE_REGNO_P' redefined /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:1654: 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/src/gnu/usr.bin/cc/cc_int/../cc_tools/tconfig.h:10, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/hconfig.h:2, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/config.h:1, from /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/ssa-dce.c:70: /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:70: warning: `TARGET_DEFAULT' redefined /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:400: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:83: warning: `FUNCTION_VALUE_REGNO_P' redefined /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:1654: 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/src/gnu/usr.bin/cc/cc_int/../cc_tools/tconfig.h:10, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/hconfig.h:2, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/config.h:1, from /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/ssa-ccp.c:62: /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:70: warning: `TARGET_DEFAULT' redefined /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:400: warning: this is the location of the previous definition /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/unix.h:83: warning: `FUNCTION_VALUE_REGNO_P' redefined /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config/i386/i386.h:1654: 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/src/gnu/usr.bin/cc/cc_int/../cc_tools/tconfig.h:10, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/hconfig.h:2, from /usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools/config.h:1, from /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/df.c:158: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for UPDATING notice
In message: <[EMAIL PROTECTED]> Julian Elischer <[EMAIL PROTECTED]> writes: : Who's doing UPDATING now? Nobody owns it. I've committed your change. I have a few more changes I should commit. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
UMA question..
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 have their stacks etc. attached to them. These are only splitt off when the UMA decides to stop caching an item and actualy return it's memory to the system. In this regard the UMA allocator is not a memory alocator but a 'complex object allocator'... Very cool. Now my question.. I ant to allocate proc structures the same way... in other words, I want a cached proc structure to already have a thread attached to it and a stack attached to the thread.. Is it legal for teh init function which is called by UMA to in turn call UMA to allocate a sub element.. so if I do uma_zalloc(proc args) that in turn should do a uma_zalloc(thread args). would this work? is it legal? I need to allocate extra threads independantly of processes, but I could work it so that freed process structures always had a single thread left on them, which would save on allocations.. In the future I need to do teh same for KSEs and KSEGRPS. sp having UMA cache pre-constructed complex items made up of groups of separatly UMA-allocated objects would be a great saving.. the question is.. will it work? can I call UMA from withing a UMA constructor? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
