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]"
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: 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: 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]"
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: 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]"
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=8&category=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: 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: 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: 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 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]"
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 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
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 :lea0x4(%esp),%ecx PJ> 0x080481d4 :and$0xfff0,%esp PJ> 0x080481d7 :pushl 0xfffc(%ecx) PJ> 0x080481da : push %ebp PJ> 0x080481db : mov%esp,%ebp PJ> 0x080481dd : push %ecx PJ> 0x080481de : sub$0x14,%esp PJ> 0x080481e1 : call 0x8051b50 <.mcount> PJ> 0x080481e6 : mov0x4(%ecx),%eax PJ> 0x080481e9 : mov(%eax),%eax PJ> 0x080481eb : mov%eax,0x8(%esp) PJ> 0x080481ef : mov(%ecx),%eax PJ> 0x080481f1 : mov%eax,0x4(%esp) PJ> 0x080481f5 : movl $0x8066b0a,(%esp) PJ> 0x080481fc : call 0x8051b00 PJ> 0x08048201 : mov$0x0,%eax PJ> 0x08048206 : add$0x14,%esp PJ> 0x08048209 : pop%ecx PJ> 0x0804820a : pop%ebp PJ> 0x0804820b : lea0xfffc(%ecx),%esp PJ> 0x0804820e : 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: 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: 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: 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 :lea0x4(%esp),%ecx 0x080481d4 :and$0xfff0,%esp 0x080481d7 :pushl 0xfffc(%ecx) 0x080481da : push %ebp 0x080481db : mov%esp,%ebp 0x080481dd : push %ecx 0x080481de : sub$0x14,%esp 0x080481e1 : call 0x8051b50 <.mcount> 0x080481e6 : mov0x4(%ecx),%eax 0x080481e9 : mov(%eax),%eax 0x080481eb : mov%eax,0x8(%esp) 0x080481ef : mov(%ecx),%eax 0x080481f1 : mov%eax,0x4(%esp) 0x080481f5 : movl $0x8066b0a,(%esp) 0x080481fc : call 0x8051b00 0x08048201 : mov$0x0,%eax 0x08048206 : add$0x14,%esp 0x08048209 : pop%ecx 0x0804820a : pop%ebp 0x0804820b : lea0xfffc(%ecx),%esp 0x0804820e : 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: 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: 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
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: 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 size>100K Then look at /var/log/messages.0.bz2 Also, check `last`. -- Jeroen Ruigrok van der Werven / 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: 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 size>100K * 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]"
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]"