weird restarts when compiling
Hi to all the list, i 've been using FreeBSD for almost a month ,and i
have this weird problem. Sometimes when i try to compile a program the
computer will hard-reset itself, like someone pulled of the plug...
For example yesterday i was trying to install jdk1.6 + eclipse, and
while i was compiling eclipse {more precisely -if i remember
correctly- the diablo-jdk needed for eclipse} the computer rebooted
itself.
The load of the computer was: 2-3xterms, 1 Konversation irc client
,several opera9.51 windows, 1-2 konqueror windows, and 1-2 Firefox
widows. I have a dual core box with 2GB of memory and i use freebsd7
32bit. The computer was online for 8hours with almost the same load
{minus the compilation-procedure}.
* Has anyone had problems like this?
* What can i do to investigate a bit more what was the situation
before the restart?
* Is there anyway to solve this problem.
thanks for your help,
nikos
PS: i could blame the power company but the above problem has happened
before{several times} when i tried to compile big programs like
firefox or do a pkgdb -Fu, so i don't think it is this.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: weird restarts when compiling
On Sun, 13 Jul 2008 09:09:09 +0300
Aggelidis Nikos [EMAIL PROTECTED] wrote:
Hi to all the list, i 've been using FreeBSD for almost a month ,and i
have this weird problem. Sometimes when i try to compile a program the
computer will hard-reset itself, like someone pulled of the plug...
For example yesterday i was trying to install jdk1.6 + eclipse, and
while i was compiling eclipse {more precisely -if i remember
correctly- the diablo-jdk needed for eclipse} the computer rebooted
itself.
The load of the computer was: 2-3xterms, 1 Konversation irc client
,several opera9.51 windows, 1-2 konqueror windows, and 1-2 Firefox
widows. I have a dual core box with 2GB of memory and i use freebsd7
32bit. The computer was online for 8hours with almost the same load
{minus the compilation-procedure}.
* Has anyone had problems like this?
Yes. It's always turned out to be flaky hardware for me.
* What can i do to investigate a bit more what was the situation
before the restart?
Look through /var/log/messages.
* Is there anyway to solve this problem.
Well, you really can't solve it, so much as troubleshoot it. Make up
a list of possible causes, and then start checking each possible
cause. You haven't given any real information about the system or the
problem, so we can't eliminate anything. My top suspects would be the
PSU (old or inadequate) and CPU (overheating or overclocked). Memory
and the I/O subsystem would be next, but they tend to cause
random process failure rather than system shutdowns when they go
flaky, so I'd try them last.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
merging into DVD+RW with growisofs non aligned DMA transfer (7.0R)
Hello, I wanted to add a file to an already written DVD+RW (written a day before on the same system) with # growisofs -M /dev/cd0 -r -T -J -joliet-long -v directory This produced tons of error messages via syslog as Jul 11 13:45:30 rebelion kernel: ata0: FAILURE - non aligned DMA transfer attempted Jul 11 13:45:30 rebelion kernel: acd0: setting up DMA failed and the only way to get the system back to a usable state was rebooting it; I've reloaded the files from the DVD to the file system, added the file I wanted get merged and wrote the DVD again with -Z which worked fine; this is with FreeBSD-7.0R; what is wrong with -M or what I've done wrong? thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e [EMAIL PROTECTED] - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ «...una sola vez, que es cuanto basta si se trata de verdades definitivas.» «...only once, which is enough if it has todo with definite truth.» José Saramago, Historia del Cerca de Lisboa ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: weird restarts when compiling
Thanks for your answers Manolis and Mike. In the beginning i didn't suspect hardware because it happened only at compilation procedures. Now i realize that every other task i do isn't really demanding. Look through /var/log/messages. i get this: Jul 13 09:00:00 apollo newsyslog[1018]: logfile turned over due to size100K * CPU overheating - Is there anyway to check for cpu temperatures within freebsd? - I 've used the pc for like 8 hours in a really hot day but it didn't restart...if this can be considered as an indication. *Memory - i used memtest ,from an ubuntu live cd, to check the memory and everything works fine according to it. *PSU I have a 400Watt PSU... maybe this is inadequate. I will try to swap it for something stronger to see how it goes. In general where are there any stress tests i can do, to test the PSU and some major subsystems of the computer? thanks in advance, nikos PS: this was a ready-made pc that had it's p4 processor upgraded to a dual core. It also got a new motherboard and 2G of ddr2. It has an old nvidia GeForce fx 5200, and a 400watt nameless PSU. I only have freebsd,which i installed a month ago, on it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: weird restarts when compiling
-On [20080713 10:04], Aggelidis Nikos ([EMAIL PROTECTED]) wrote: Look through /var/log/messages. i get this: Jul 13 09:00:00 apollo newsyslog[1018]: logfile turned over due to size100K Then look at /var/log/messages.0.bz2 Also, check `last`. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B There is time in life for everything... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, Jul 13, 2008 at 01:34:11AM -0700, Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. I was seeing similar problems (audio stutter during compiles, jerky mouse) after upgrading to 7.0. The box is an Athlon-XP 2400+ with 1GB of RAM. Since removing SMP support from the kernel and switching to ULE, interactivity has been acceptible again. I did not update the xserver at the time, and I can't recall if it has been updated since. Stefan pgpwzVr88QUYs.pgp Description: PGP signature
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. It shows *a* difference, but perhaps not the *same* difference. Please humour me and rule it out. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: profiling broken on RELENG_7/i386
On 2008-Jul-04 13:01:11 +0400, Dmitry Morozovsky [EMAIL PROTECTED] wrote: It seems we step on a bug in gcc in RELENG_7/i386 It is triggered at least by profiling program which uses getopt(3): I think it's actually in the profiling initialisation code. If you try to run sample code under gdb, you can see that .mcount() is not preserving %ecx, though main() assumes it does. (gdb) disas $eip Dump of assembler code for function main: 0x080481d0 main+0:lea0x4(%esp),%ecx 0x080481d4 main+4:and$0xfff0,%esp 0x080481d7 main+7:pushl 0xfffc(%ecx) 0x080481da main+10: push %ebp 0x080481db main+11: mov%esp,%ebp 0x080481dd main+13: push %ecx 0x080481de main+14: sub$0x14,%esp 0x080481e1 main+17: call 0x8051b50 .mcount 0x080481e6 main+22: mov0x4(%ecx),%eax 0x080481e9 main+25: mov(%eax),%eax 0x080481eb main+27: mov%eax,0x8(%esp) 0x080481ef main+31: mov(%ecx),%eax 0x080481f1 main+33: mov%eax,0x4(%esp) 0x080481f5 main+37: movl $0x8066b0a,(%esp) 0x080481fc main+44: call 0x8051b00 printf 0x08048201 main+49: mov$0x0,%eax 0x08048206 main+54: add$0x14,%esp 0x08048209 main+57: pop%ecx 0x0804820a main+58: pop%ebp 0x0804820b main+59: lea0xfffc(%ecx),%esp 0x0804820e main+62: ret End of assembler dump. (gdb) x/10x $esp 0xbfbfeadc: 0x0804815f 0x0001 0xbfbfeb08 0xbfbfeb10 0xbfbfeaec: 0x 0x 0x 0x 0xbfbfeafc: 0x 0x (gdb) info regi eax0xbfbfeb08 -1077941496 ecx0x1e968 125288 edx0x8051d1a134552858 ebx0x1 1 esp0xbfbfeadc 0xbfbfeadc ebp0xbfbfeb00 0xbfbfeb00 esi0xbfbfeb10 -1077941488 edi0x0 0 eip0x80481d00x80481d0 eflags 0x282642 cs 0x33 51 ss 0x3b 59 ds 0x3b 59 es 0x3b 59 fs 0x3b 59 gs 0x1b 27 ... [step through .mcount] ... (gdb) stepi main (argc=Error accessing memory address 0x1b: Bad address. ) at x.c:4 4 printf(Hello %d %s\n, argc, argv[0]); (gdb) info regi eax0x1 1 ecx0x1b 27 edx0x804815f134512991 ebx0x1 1 esp0xbfbfeab0 0xbfbfeab0 ebp0xbfbfeac8 0xbfbfeac8 esi0xbfbfeb10 -1077941488 edi0x0 0 eip0x80481e60x80481e6 eflags 0x246582 cs 0x33 51 ss 0x3b 59 ds 0x3b 59 es 0x3b 59 fs 0x3b 59 gs 0x1b 27 -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpvlUdyjzYFW.pgp Description: PGP signature
Re: weird restarts when compiling
On Sun, Jul 13, 2008 at 11:04:31AM +0300, Aggelidis Nikos wrote: * CPU overheating - Is there anyway to check for cpu temperatures within freebsd? - I 've used the pc for like 8 hours in a really hot day but it didn't restart...if this can be considered as an indication. Not easily. If coretemp(4) is loaded, you should have some sysctls named dev.cpu.X.temperature which contain the temperature of the core in Celcius. Otherwise, you can try utilities like mbmon and healthd, but those were written for old (circa 90s) hardware. Also, are you running powerd(8) on this machine? *Memory - i used memtest ,from an ubuntu live cd, to check the memory and everything works fine according to it. That's a good start; your memory is probably not the issue then. *PSU I have a 400Watt PSU... maybe this is inadequate. I will try to swap it for something stronger to see how it goes. Wattage is not the only thing that matters with a PSU. Voltages are significantly more important, if you ask me. I'd make a list of what your voltages are (go into the BIOS and see) and provide them here. There may be one which is significantly off, indicating a bad PSU. In general where are there any stress tests i can do, to test the PSU and some major subsystems of the computer? Windows offers many free utilities that do this; I'm not sure about FreeBSD. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, Jul 13, 2008 at 03:11:23AM +0200, Kris Kennaway wrote: It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? No, it's not. I have exactly the same problem with SCHED_4BSD after upgrade from 6.3-STABLE to 7.0-STABLE. I didn't upgrade my x.org 6.9.0, only OS (all 6.x compat shims are installed). There is some sort of regression, certainly. Eugene Grosbein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: profiling broken on RELENG_7/i386
On Sun, 13 Jul 2008, Peter Jeremy wrote: PJ On 2008-Jul-04 13:01:11 +0400, Dmitry Morozovsky [EMAIL PROTECTED] wrote: PJ It seems we step on a bug in gcc in RELENG_7/i386 PJ PJ It is triggered at least by profiling program which uses getopt(3): PJ PJ I think it's actually in the profiling initialisation code. If PJ you try to run sample code under gdb, you can see that .mcount() PJ is not preserving %ecx, though main() assumes it does. I see. However, I'm afraid we need knowledge of some gcc guru to bring the fix in. Alexander, could you please comment? PJ PJ (gdb) disas $eip PJ Dump of assembler code for function main: PJ 0x080481d0 main+0:lea0x4(%esp),%ecx PJ 0x080481d4 main+4:and$0xfff0,%esp PJ 0x080481d7 main+7:pushl 0xfffc(%ecx) PJ 0x080481da main+10: push %ebp PJ 0x080481db main+11: mov%esp,%ebp PJ 0x080481dd main+13: push %ecx PJ 0x080481de main+14: sub$0x14,%esp PJ 0x080481e1 main+17: call 0x8051b50 .mcount PJ 0x080481e6 main+22: mov0x4(%ecx),%eax PJ 0x080481e9 main+25: mov(%eax),%eax PJ 0x080481eb main+27: mov%eax,0x8(%esp) PJ 0x080481ef main+31: mov(%ecx),%eax PJ 0x080481f1 main+33: mov%eax,0x4(%esp) PJ 0x080481f5 main+37: movl $0x8066b0a,(%esp) PJ 0x080481fc main+44: call 0x8051b00 printf PJ 0x08048201 main+49: mov$0x0,%eax PJ 0x08048206 main+54: add$0x14,%esp PJ 0x08048209 main+57: pop%ecx PJ 0x0804820a main+58: pop%ebp PJ 0x0804820b main+59: lea0xfffc(%ecx),%esp PJ 0x0804820e main+62: ret PJ End of assembler dump. PJ (gdb) x/10x $esp PJ 0xbfbfeadc: 0x0804815f 0x0001 0xbfbfeb08 0xbfbfeb10 PJ 0xbfbfeaec: 0x 0x 0x 0x PJ 0xbfbfeafc: 0x 0x PJ (gdb) info regi PJ eax0xbfbfeb08 -1077941496 PJ ecx0x1e968 125288 PJ edx0x8051d1a134552858 PJ ebx0x1 1 PJ esp0xbfbfeadc 0xbfbfeadc PJ ebp0xbfbfeb00 0xbfbfeb00 PJ esi0xbfbfeb10 -1077941488 PJ edi0x0 0 PJ eip0x80481d00x80481d0 PJ eflags 0x282642 PJ cs 0x33 51 PJ ss 0x3b 59 PJ ds 0x3b 59 PJ es 0x3b 59 PJ fs 0x3b 59 PJ gs 0x1b 27 PJ ... PJ [step through .mcount] PJ ... PJ (gdb) stepi PJ main (argc=Error accessing memory address 0x1b: Bad address. PJ ) at x.c:4 PJ 4 printf(Hello %d %s\n, argc, argv[0]); PJ (gdb) info regi PJ eax0x1 1 PJ ecx0x1b 27 PJ edx0x804815f134512991 PJ ebx0x1 1 PJ esp0xbfbfeab0 0xbfbfeab0 PJ ebp0xbfbfeac8 0xbfbfeac8 PJ esi0xbfbfeb10 -1077941488 PJ edi0x0 0 PJ eip0x80481e60x80481e6 PJ eflags 0x246582 PJ cs 0x33 51 PJ ss 0x3b 59 PJ ds 0x3b 59 PJ es 0x3b 59 PJ fs 0x3b 59 PJ gs 0x1b 27 PJ PJ -- PJ Peter Jeremy PJ Please excuse any delays as the result of my ISP's inability to implement PJ an MTA that is either RFC2821-compliant or matches their claimed behaviour. PJ Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: [EMAIL PROTECTED] ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: profiling broken on RELENG_7/i386
On Sun, 13 Jul 2008 18:01:12 +0400 (MSD) Dmitry Morozovsky [EMAIL PROTECTED] wrote: On Sun, 13 Jul 2008, Peter Jeremy wrote: PJ On 2008-Jul-04 13:01:11 +0400, Dmitry Morozovsky [EMAIL PROTECTED] PJ wrote: PJ It seems we step on a bug in gcc in RELENG_7/i386 PJ PJ It is triggered at least by profiling program which uses PJ getopt(3): PJ PJ I think it's actually in the profiling initialisation code. If PJ you try to run sample code under gdb, you can see that .mcount() PJ is not preserving %ecx, though main() assumes it does. I see. However, I'm afraid we need knowledge of some gcc guru to bring the fix in. This is a known bug in 7.x and has apparently been fixed in -CURRENT. See http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/119709 for more details. -- Bruce Cran signature.asc Description: PGP signature
Pls sanity check my semtimedop(2) implementation
Hi,
Below is a semtimedop(2) implementation that I'm using for FreeBSD. I
was hoping someone could look it over and tell me if they think the
implementation is sound.
The code seems to work ok but when stressing the FreeBSD build of my app
I have managed to provoke errors related to concurrency (usually when a
SIGALRM goes off). The Linux build works flawlessesly so I'm wondering
about this one critical function that is different.
Is there any reason why I would want to use ITIMER_VIRTUAL /
SIGVTALRM instead of ITIMER_REAL / SIGALRM?
Or perhaps I should be using a different implementation entirely?
Mike
int
_semtimedop(int semid,
struct sembuf *array,
size_t nops,
struct timespec *_timeout)
{
struct timeval timeout, before, after;
struct itimerval value, ovalue;
struct sigaction sa, osa;
int ret;
if (_timeout) {
timeout.tv_sec = _timeout-tv_sec;
timeout.tv_usec = _timeout-tv_nsec / 1000;
if (gettimeofday(before, NULL) == -1) {
return -1;
}
memset(value, 0, sizeof value);
value.it_value = timeout;
memset(sa, 0, sizeof sa);
/* signal_print writes the signal info to a log file
*/
sa.sa_sigaction = signal_print;
sa.sa_flags = SA_SIGINFO;
sigemptyset(sa.sa_mask);
sigaction(SIGALRM, sa, osa);
if (setitimer(ITIMER_REAL, value, ovalue) == -1) {
sigaction(SIGALRM, osa, NULL);
return -1;
}
}
ret = semop(semid, array, nops);
if (_timeout) {
sigaction(SIGALRM, osa, NULL);
if (setitimer(ITIMER_REAL, ovalue, NULL) == -1) {
return -1;
}
}
if (ret == -1) {
if (_timeout) {
struct timeval elapsed;
if (gettimeofday(after, NULL) == -1) {
return -1;
}
_timeval_diff(after, before, elapsed);
if (timercmp(elapsed, timeout, =))
errno = EAGAIN;
}
return -1;
}
return 0;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: profiling broken on RELENG_7/i386
On Sun, 13 Jul 2008, Bruce Cran wrote:
BC PJ On 2008-Jul-04 13:01:11 +0400, Dmitry Morozovsky [EMAIL PROTECTED]
BC PJ wrote:
BC PJ It seems we step on a bug in gcc in RELENG_7/i386
BC PJ
BC PJ It is triggered at least by profiling program which uses
BC PJ getopt(3):
BC PJ
BC PJ I think it's actually in the profiling initialisation code. If
BC PJ you try to run sample code under gdb, you can see that .mcount()
BC PJ is not preserving %ecx, though main() assumes it does.
BC
BC I see. However, I'm afraid we need knowledge of some gcc guru to
BC bring the fix in.
BC
BC
BC This is a known bug in 7.x and has apparently been fixed in -CURRENT.
BC See http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/119709 for more
BC details.
It seems it is not, at least on cluster reference -CURRENT i386 machine:
Thu Jul 3 21:52:15 UTC 2008
[EMAIL PROTECTED]:~/tmp/gprof ./test
Segmentation fault (core dumped)
Profiling program does not always dump core, but .mcount definitely clobbers
one of the registers:
[EMAIL PROTECTED]:~/tmp/gprof cat test-x.c
#include stdio.h
int
main(int argc, char *argv[])
{
printf(Hello, world!\n);
printf(argc=%d, argv=%p\n, argc, argv);
return (0);
}
w/o -pg:
[EMAIL PROTECTED]:~/tmp/gprof ./test
Hello, world!
argc=1, argv=0xbf7febf8
with -pg:
[EMAIL PROTECTED]:~/tmp/gprof ./test
Hello, world!
argc=0, argv=0x0
Sincerely,
D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer: [EMAIL PROTECTED] ]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPG encryption of binary sample requested.
Julian Stacey wrote: Summary: A problem in zlib is confirmed here (for mail gpg decryption), do others see this too or have comment please ? It turns out /usr/ports/mail/popd is corrupting data from both my servers running FreeBSD-6.2 FreeBSD-6.3, (3rd server with 7.0 back soon to test). Detail: zlib was reacting to corrupt data. I did some loop tests grabbing data half way with sftp found: - Data out goes OK with SMTP+Auth to servers, - Data served back via POP3 is corrupted from my remote FreeBSD popd servers ( /usr/ports/mail/popd popd-2.2.2a_4, on both FreeBSD-6.2, 6.3, (My FreeBSD-7.0 server off line, not tested), - My local fetchmail on my dynamic IP gate running FreeBSD-6.2, my internal host send out recieve back fine using an alternate POP3 - No problem with large base64 bins, only when I receive encrypted. I'll have to install some other POP3 (or IMAP) server, Big choice: cd /usr/ports/mail; echo *pop* akpop3d cucipop freepops mdpop3d nullpop p5-vpopmail pecl-pop3 pop-before-smtp pop3gwd pop3lite pop3proxy pop3vscan popa3d popa3d-before-sendmail popcheck popclient popd popfile poppassd popper poppwd poppy popular qpopper solidpop3d teapop teapop-devel tpop3d vm-pop3d vpopmail vpopmail-devel wmmultipop3 wmpop3 wmpop3lb PS test accounts are handy to have for debugging when things break, so if 1 or 2 people fancy offering me a POP3 account, I'd happily reciprocate. PPS Earlier I tried /usr/ports/mail/getmail, It fetches 1M of uuencoded random data, but fails on 10M with: operation error (child pid 56001 killed by signal 9) Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML Base64 text are spam. www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPG encryption of binary sample requested.
Am Sonntag, 13. Juli 2008 18:35:59 schrieb Julian Stacey: I'll have to install some other POP3 (or IMAP) server, Big choice: cd /usr/ports/mail; echo *pop* akpop3d cucipop freepops mdpop3d nullpop p5-vpopmail pecl-pop3 pop-before-smtp pop3gwd pop3lite pop3proxy pop3vscan popa3d popa3d-before-sendmail popcheck popclient popd popfile poppassd popper poppwd poppy popular qpopper solidpop3d teapop teapop-devel tpop3d vm-pop3d vpopmail vpopmail-devel wmmultipop3 wmpop3 wmpop3lb I'm personally very happy with courier-imap (which is both a POP and IMAP implementation). courier requires you to keep your mail-spools in maildir format, though (which I favor anyway over mbox, but YMMV). Depending on the MTA/MDA you use, it should be easy to adapt it to store mails to maildirs. For Postfix, maildir support is builtin, for sendmail, you can use procmail to do the delivery, which also sports maildir support. -- Heiko Wundram ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Re: Hardware support for AMD Geode CS5536 audio?
Hi, re: Bruce, This is Andrew Gray. I am running an Alix-1C board with the CS5536 on it. This board is very nice. It's only about $138 and it has a good standard clone AWARD bios that we are all used to (unlike say, the Soekris boards). It uses only 5 watts and has everthing including 21 GPIO pins. (except is doesn't have a Freebsd sound driver yet. ---snip--- http://www.mini-box.com/Alix-1C-Board-1-LAN-1-MINI-PCI?sc=8category=754 Looks like a nice board, close to the reference platform, and has exposed audio (unlike some of the Geode-based embedded systems). Looks like a decent CS5536 audio development platform. Its use of the CS5536 is not apparent from a casual skim of the web-page, thanks, I would not have known about it if not for your mail. A question for you? Do Freebsd 4.6 drivers still work on freebsd 6.2 and 7.0? Not sure, I haven't had relevant Geode hardware up for awhile... I'd be rather surprised if even for the CS5530 something hadn't changed or needed tweaking, but I don't know. Are you working on this CS5536 driver? Do you have hardware yet? I don't have hardware, but I've just ordered an Alix-1C. :) I haven't been working on this. I had googled for a few days without finding anything that looked like a convenient dev platform (mostly closed embedded systems). I also came across info at AMD's site that implied the CS5536 had been end-of-lifed and that made me a bit depressed. Does anyone know, BTW, if this is the case? When I get this Alix-1C I will try to get something up. But it will definitely just be in all-too-infrequent spare-time cycles between real-life and dayjob, so we're talking weekend-and-late-night-hobby here. If anyone such as yourself want to hack away on it, that would be great too. I'll try to stay in touch. Thanks, -bruce ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help with copytree code
On Saturday 12 July 2008, Beech Rintoul said: On Saturday 12 July 2008, Stanislav Sedov said: On Sun, 6 Jul 2008 13:26:21 -0800 Beech Rintoul [EMAIL PROTECTED] mentioned: I'd just like to thank stas@ and everyone who replied with suggestions, code etc. I believe that I now have something workable and it's been submitted to portmgr for review and possible inclusion in bsd.port.mk along with some new features of my own. Hopefully, this will fix a long standing problem with copytree_*. Have you filled the PR so we could review/comment? No, portmgr (Pav) has it and is reviewing. I'll chat with him and see if he wants me to file a pr. Meanwhile I'll be happy to send it to anyone who wants it. The FreeBSD server will just strip it off and I'm moving webservers today so I can't post it for a while. Beech OK, if anyone wishes to test this code I posted it here: http://www.alaskaparadise.com/freebsd/copytree.diff Comments or suggestions are welcome :-) Beech -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://www.freebsd.org X - NO Word docs in e-mail | Latest Release: / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Announcement: PmcTools callchain capture for RELENG_7
Hello List(s), I am very pleased to announce a patch, by Fabien Thomas, that brings PmcTools' callchain capture features to 7-STABLE. Thank you, Fabien! The patch is linked to from the PmcTools wiki page: http://wiki.freebsd.org/PmcTools. The current file name is: patch-callchain-FreeBSD-7-STABLE-2008-07-12.gz. As the file name indicates, it should apply against a 7-STABLE tree of 2008-07-12 vintage. To apply the patch: % cd /home/src-7x # or whereever your RELENG_7 tree resides % patch PATCH-FILE Then you should follow the full procedure to update userland and kernel from source as spelled out in src/UPDATING. Please note that HWPMC(4) log files that contain callchain information are not binary compatible with prior versions of pmc(3) and pmcstat(8). Please do test on your systems and let Fabien and me know how you fared. Koshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: Hi folks, Hopefully this is a good list for this topic. It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? Update to the latest version and see if your X interactivity improves. Yes, I had not yet upgraded my x.org port when testing this, so it was the same x.org that was fine under 6.3. Also: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. It shows *a* difference, but perhaps not the *same* difference. Please humour me and rule it out. Okay. I am in the process of recompiling all my ports, so after that is done I will boot with a GENERIC kernel and see what happens. -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pls sanity check my semtimedop(2) implementation
On Sun, 13 Jul 2008, Michael B Allen wrote:
Hi,
Below is a semtimedop(2) implementation that I'm using for FreeBSD. I
was hoping someone could look it over and tell me if they think the
implementation is sound.
The code seems to work ok but when stressing the FreeBSD build of my app
I have managed to provoke errors related to concurrency (usually when a
SIGALRM goes off). The Linux build works flawlessesly so I'm wondering
about this one critical function that is different.
At the very least you need to check errno when semop() returns -1.
Unless it is EINTR, you have other problems.
Also, if there is any other code using the timer across this function
call, you have race conditions between changing the signal handler and
setting the timer. Even if there is no other use of the timer across
this function, resetting the signal handler before disarming the timer
leaves you open to the signal being handled by the default handler
which will make the process exit.
$.02,
/Mikko
Is there any reason why I would want to use ITIMER_VIRTUAL /
SIGVTALRM instead of ITIMER_REAL / SIGALRM?
Or perhaps I should be using a different implementation entirely?
Mike
int
_semtimedop(int semid,
struct sembuf *array,
size_t nops,
struct timespec *_timeout)
{
struct timeval timeout, before, after;
struct itimerval value, ovalue;
struct sigaction sa, osa;
int ret;
if (_timeout) {
timeout.tv_sec = _timeout-tv_sec;
timeout.tv_usec = _timeout-tv_nsec / 1000;
if (gettimeofday(before, NULL) == -1) {
return -1;
}
memset(value, 0, sizeof value);
value.it_value = timeout;
memset(sa, 0, sizeof sa);
/* signal_print writes the signal info to a log file
*/
sa.sa_sigaction = signal_print;
sa.sa_flags = SA_SIGINFO;
sigemptyset(sa.sa_mask);
sigaction(SIGALRM, sa, osa);
if (setitimer(ITIMER_REAL, value, ovalue) == -1) {
sigaction(SIGALRM, osa, NULL);
return -1;
}
}
ret = semop(semid, array, nops);
if (_timeout) {
sigaction(SIGALRM, osa, NULL);
if (setitimer(ITIMER_REAL, ovalue, NULL) == -1) {
return -1;
}
}
if (ret == -1) {
if (_timeout) {
struct timeval elapsed;
if (gettimeofday(after, NULL) == -1) {
return -1;
}
_timeval_diff(after, before, elapsed);
if (timercmp(elapsed, timeout, =))
errno = EAGAIN;
}
return -1;
}
return 0;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pls sanity check my semtimedop(2) implementation
On 7/13/08, Mikko Työläjärvi [EMAIL PROTECTED] wrote:
On Sun, 13 Jul 2008, Michael B Allen wrote:
Hi,
Below is a semtimedop(2) implementation that I'm using for FreeBSD. I
was hoping someone could look it over and tell me if they think the
implementation is sound.
The code seems to work ok but when stressing the FreeBSD build of my app
I have managed to provoke errors related to concurrency (usually when a
SIGALRM goes off). The Linux build works flawlessesly so I'm wondering
about this one critical function that is different.
At the very least you need to check errno when semop() returns -1.
Unless it is EINTR, you have other problems.
Also, if there is any other code using the timer across this function
call, you have race conditions between changing the signal handler and
setting the timer. Even if there is no other use of the timer across
this function, resetting the signal handler before disarming the timer
leaves you open to the signal being handled by the default handler
which will make the process exit.
Hi Mikko,
So if some other code uses setitimer(2) for whatever reason, then I
have the potential for a race. I'm not aware of any other such
instances of setitimer but my app is actually a plugin for a larger
application so I can't entirely rule out the possibility.
Is there any facility for creating a stateful timer so that I don't
run into this problem?
Can anyone provide the basis for an alternative implementation?
Should I use select(2) instead?
Mike
Is there any reason why I would want to use ITIMER_VIRTUAL /
SIGVTALRM instead of ITIMER_REAL / SIGALRM?
Or perhaps I should be using a different implementation entirely?
Mike
int
_semtimedop(int semid,
struct sembuf *array,
size_t nops,
struct timespec *_timeout)
{
struct timeval timeout, before, after;
struct itimerval value, ovalue;
struct sigaction sa, osa;
int ret;
if (_timeout) {
timeout.tv_sec = _timeout-tv_sec;
timeout.tv_usec = _timeout-tv_nsec / 1000;
if (gettimeofday(before, NULL) == -1) {
return -1;
}
memset(value, 0, sizeof value);
value.it_value = timeout;
memset(sa, 0, sizeof sa);
/* signal_print writes the signal info to a log file
*/
sa.sa_sigaction = signal_print;
sa.sa_flags = SA_SIGINFO;
sigemptyset(sa.sa_mask);
sigaction(SIGALRM, sa, osa);
if (setitimer(ITIMER_REAL, value, ovalue) == -1) {
sigaction(SIGALRM, osa, NULL);
return -1;
}
}
ret = semop(semid, array, nops);
if (_timeout) {
sigaction(SIGALRM, osa, NULL);
if (setitimer(ITIMER_REAL, ovalue, NULL) == -1) {
return -1;
}
}
if (ret == -1) {
if (_timeout) {
struct timeval elapsed;
if (gettimeofday(after, NULL) == -1) {
return -1;
}
_timeval_diff(after, before, elapsed);
if (timercmp(elapsed, timeout, =))
errno = EAGAIN;
}
return -1;
}
return 0;
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, Jul 13, 2008 at 12:47 AM, Eugene Grosbein [EMAIL PROTECTED] wrote: On Sun, Jul 13, 2008 at 03:11:23AM +0200, Kris Kennaway wrote: It seems like there has been a regression in interactivity from 6.3-RELEASE to 7.0-RELEASE when using the SCHED_4BSD scheduler. After upgrading my single-cpu amd64 box, 7.0 has much worse latency. When running a kernel compile, there is a noticeable lag to echo my typing or scroll my browser windows, and playing an mp3 frequently cuts out for a second or two. This did not happen on 6.3-RELEASE. Are you sure it's not the x.org server bug that was present in the version shipped with 7.0? No, it's not. I have exactly the same problem with SCHED_4BSD after upgrade from 6.3-STABLE to 7.0-STABLE. I didn't upgrade my x.org 6.9.0, only OS (all 6.x compat shims are installed). There is some sort of regression, certainly. IIRC some folks reported performance degradation using SCHED_4BSD in the past after the SMP fixes, so this isn't a new news story. SCHED_ULE isn't going to be default until 7.1-RELEASE I believe because they might be fanning out a few bugs in -CURRENT (the number of bugs are small from what I've seen) and MFC'ing them to 7-RELEASE. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
