Re: CFT: final patches for NGROUPS>>16
posted patches to this effect some months ago. they needed some clean-up and validation but the also mapped correctly into an RPC_NGROUPS_MAX and IPC_NGROUPS_MAX for consistent (and possibly dynamic) mapping to those problem areas. they build and run but are untested beyond that. i do not expect to have time to re-visit the problem in reasonable order. they also included some other userland changes that may be of interest. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: valgrind on FreeBSD 7
Yuri writes: > Any news on valgrind for FreeBSD? http://perforce.freebsd.org/changeList.cgi?FSPC=//depot/projects/valgrind/... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: freebsd-hackers Digest, Vol 325, Issue 4
how to start local host is freeBSD, i install apache22 even after localhost is not working ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How best to debug locking/scheduler problems
On Wednesday 17 June 2009 6:11:42 pm Mel Flynn wrote: > On Wednesday 17 June 2009 13:17:37 John Baldwin wrote: > > On Wednesday 17 June 2009 3:52:54 pm Mel Flynn wrote: > > > On Wednesday 17 June 2009 04:15:26 John Baldwin wrote: > > > > On Tuesday 16 June 2009 7:01:45 pm Mel Flynn wrote: > > > > > On Tuesday 16 June 2009 11:02:42 John Baldwin wrote: > > > > > > On Tuesday 16 June 2009 1:52:23 pm Mel Flynn wrote: > > > > > > > Hi John, > > > > > > > > > > > > > > On Tuesday 16 June 2009 04:19:57 John Baldwin wrote: > > > > > > > > On Monday 15 June 2009 5:53:05 pm Mel Flynn wrote: > > > > > > > > > PIDTID COMM TDNAME KSTACK > > > > > > > > > 4283 100215 kdeinit4 -mi_switch > > > > > > > > > turnstile_wait _mtx_lock_sleep uipc_peeraddr kern_getpeername > > > > > > > > > getpeername syscall Xint0x80_syscall > > > > > > > > > % ps -ww 4283 > > > > > > > > > PID TT STAT TIME COMMAND > > > > > > > > > 4283 ?? T 0:00.38 kdeinit4: kdeinit4: kio_http http > > > > > > > > > local:/tmp/ksocket-mel/klauncherxJ1635.slave-socket > > > > > > > > > local:/tmp/ksocket- mel/plasmayC1653.slave-socket (kdeinit4) > > > > > > > > > > > > > > > > > > %ls -l /tmp/ksocket-mel/ > > > > > > > > > > > > > > > > > > total 2 > > > > > > > > > -rw-rw-r-- 1 mel wheel 62 Jun 14 22:55 KSMserver__0 > > > > > > > > > srw--- 1 mel wheel 0 Jun 14 22:55 kdeinit4__0 > > > > > > > > > srwxrwxr-x 1 mel wheel 0 Jun 14 22:55 > > > > > > > > > klauncherxJ1635.slave-socket > > > > > > > > > > > > > > > > You can use kgdb and the scripts at www.freebsd.org/~jhb/gdb. > > > > > > > > Simply run 'kgdb' as root and do 'lcd /folder/with/scripts' and > > > > > > > > 'source gdb6'. You can then do 'lockchain 4283' to find who > > > > > > > > holds the lock this thread is blocked on and what state they > > > > > > > > are in. > > > > > > > > > > > > > > Looks like a deadlock: > > > > > > > > > > > > > > (kgdb) lockchain 4283 > > > > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > > > > 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked > > > > > > > on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) > > > > blocked > > > > > > > > > on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) > > > > > > > blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, > > > > > > > klauncher) blocked on lock 0xc6806348 "unp_mtx" thread 100215 > > > > > > > (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread > > > > > > > 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" > > > > > > > thread 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 > > > > > > > "unp_mtx" thread 100122 (pid 1635, klauncher) blocked on lock > > > > > > > 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked > > > > > > > on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) > > > > > > > blocked on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, > > > > > > > kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid > > > > > > > 1635, klauncher) blocked on lock 0xc6806348 "unp_mtx" thread > > > > > > > 100215 (pid 4283, kdeinit4) blocked on lock 0xc64374a0 "unp_mtx" > > > > > > > thread 100122 (pid 1635, klauncher) blocked on lock 0xc6806348 > > > > > > > "unp_mtx" thread 100215 (pid 4283, kdeinit4) blocked on lock > > > > > > > 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, klauncher) blocked > > > > > > > on lock 0xc6806348 "unp_mtx" thread 100215 (pid 4283, kdeinit4) > > > > > > > blocked on lock 0xc64374a0 "unp_mtx" thread 100122 (pid 1635, > > > > > > > klauncher) blocked on lock 0xc6806348 "unp_mtx" DEADLOCK > > > > > > > > > > > > > > Looking through the scripts now to see how I can get more info on > > > > the > > > > > > > > > call chain and hoping I don't panic the machine ;). It is quite > > > > > > > random to reproduce. > > > > > > > > > > > > In kgdb you can simply do 'tid 100122' followed by 'bt' and 'tid > > > > > > 100215' followed by 'bt'. > > > > > > > > > > Cool, thanks for helping John. Of course it pretty much shows me what > > > > > procstat -k shows and can't get any info on the userland part, but I > > > > > can fully inspect the locks and threads. > > > > > > > > > > Both threads are in TDS_INHIBITED state, and blocked on: > > > > > (kgdb) frame 0 > > > > > #0 sched_switch (td=0xc5971240, newtd=0xc4d39900, flags=259) > > > > > at /usr/src/sys/kern/sched_ule.c:1864 > > > > > 1864cpuid = PCPU_GET(cpuid); > > > > > > > > That doesn't really tell us anything except that it isn't running. We > > > > know > > > > > > it is actually blocked on a lock, and we need the full stack trace to > > > > see where the two threads were trying to acquire the locks, hence 'bt'. > > > > ' procstat -k' output would be fine, too. > > > > > > the respective bt's: > > >
Re: valgrind on FreeBSD 7
2008/10/2 Yuri :
> Xin LI wrote:
>>
>> Simon Barner wrote:
>>>
>>> Mike Silbersack wrote:
On Mon, 17 Mar 2008, Heiko Wundram wrote:
Here's a tarball of what's in perforce right now. I tried it a little
bit, and it seemed to work for me. Make sure to install the kernel module!
http://www.silby.com/valgrind_freebsd_3.tar.gz
But don't send me questions about it - I'm not an expert on it, I'm just
the guy who grabbed it from perforce and found that it seems to work. :)
>>>
>>> Could you please provide me with the details, so I can update my
>>> (horribly outdated :( valgrind ports?
>>
>> It was available from p4 at:
>>
>> //depot/projects/valgrind/...
>>
>> Note that this version does not work on architectures other than i386.
>>
>> Cheers,
>
>
> Any developments in Valgrind/Callgrind on FreeBSD?
> Any hope to get this version into ports and to merge FreeBSD support up into
> Valgrind project?
For our employer (Sandvine incorporated) Ed Maste and me are working
on finishing the port Peter Wemm started a while ago.
You can find updated informations on the project here:
http://wiki.freebsd.org/Valgrind
while you can get the sources pack here:
http://people.freebsd.org/~attilio/Sandvine/valgrind/valgrind.tar.bz2
Please note that 8 and 7 now have all the required support to let run
this modified version, so no further modify is required to these
branches.
Valgrind is able to run on 6 too, if the patch system_valgrind.diff is
applied (I can't recall if it targeted for SVOS, as I think, or it is
stock STABLE_6, just try it, it may apply to both).
The port is really not clean, but that's not Peter's fault. Valgrind
should be really rewritten in order to be less Linux-centric and be
more smart about interface sucking. The effort, though, would be so
large that would require too much work to happen in the short term.
What is in the tar works mostly ok (modulo missing syscalls) on both
ia32 and amd64, but you should carefully follow what is written in the
Wiki for a good install of the product.
Also note that I have an internal version that should fix most (all?)
the issues reported in the Wiki and I will try to release it on a
regular basis, until possible.
So far, I'm fighting with a segfault in the profiled process while
running with SV environment {amd64 arch}, a symptomancy that doesn't
show with a stock FreeBSD installation so far. If you could try the
port and report to us I would appreciate a lot.
For any other question please refer to us.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: freebsd-hackers Digest, Vol 325, Issue 4
start reading books On Thu, 18 Jun 2009, malathi selvaraj wrote: how to start local host is freeBSD, i install apache22 even after localhost is not working ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: How best to debug locking/scheduler problems
On Wednesday 17 June 2009 6:11:42 pm Mel Flynn wrote: > On Wednesday 17 June 2009 13:17:37 John Baldwin wrote: > > These are the key frames. It looks like uipc_peeraddr() tries to lock two > > unp locks w/o any protection from the global unp linkage lock. I've > > changed it to use the same locking as uipc_accept() where it first grabs a > > read lock on the linkage lock and then just locks the other end of the > > connection to copy out its sockaddr. > > Thanks John. I'll recompile the kernel with patch and up-to-date current and > report back if there are any side effects or if the bug resurfaces. > Is there a sure way (i.e. testcase) that would expose this condition? At > present, all I can do is wait and maybe play with network interface link > up/down, as it seems to be related from a high level view. I write a testcase for this that had two threads calling getpeername() against each other in a loop. It locked up on a stock 7.x box in a few seconds. :) It has run to completion without deadlocking with the patch. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: svn commit: r193635 - head/etc
Doug Barton writes: > Dag-Erling Smørgrav writes: > > Great, now mergemaster blew away my ntp.conf and installed this one > > instead. Apparently, it thinks AUTO_UPGRADE means it's fine to > > overwrite an existing file with a new one... > Yes, that's exactly what the option means. The problem comes in > because it's a new file, which means that there is no record of it in > the mtree file, so it does not show up as "changed." Hmm, I'm not sure I follow, since I'm not familiar with the innards of mergemaster, but can you tell it's new? If you can, you can check if there's already a file of the same name before installing the new one? > FWIW, this is one of the reasons that I resisted the idea of using > mtree for this function, and continue to resist the idea of the -U > option being the default. I didn't realize it was the default - but I really, really like it. It makes mergemaster a *lot* easier to use. > There is no way that I can see to have mtree list the files that have > _not_ changed, which would be the safest way to implement this > option. Doesn't sound unsurmountable. > Meanwhile I'm sure you were able to restore from backups Of course (not that there was much to restore - just "server ntp.des.no iburst maxpoll 6"), and now that I know about it, I can list it in IGNORE_FILES along with motd and printcap. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: freebsd-hackers Digest, Vol 325, Issue 4
malathi selvaraj writes: > how to start local host is freeBSD, > i install apache22 even after localhost is not working You'll have to state your question more clearly... and ask it on -questions; it is not appropriate for this list. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: svn commit: r193635 - head/etc
Doug Barton writes: > Now that you've had a successful run with the new sources the > signature for the stock file will be in mergemaster's mtree file so > you won't have to worry. I will for my other machines :) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: svn commit: r193635 - head/etc
Dag-Erling Smørgrav wrote: > Doug Barton writes: >> Dag-Erling Smørgrav writes: >>> Great, now mergemaster blew away my ntp.conf and installed this one >>> instead. Apparently, it thinks AUTO_UPGRADE means it's fine to >>> overwrite an existing file with a new one... >> Yes, that's exactly what the option means. The problem comes in >> because it's a new file, which means that there is no record of it in >> the mtree file, so it does not show up as "changed." > > Hmm, I'm not sure I follow, since I'm not familiar with the innards of > mergemaster, The -U option works by comparing the installed files to the mtree file created from the unmodified source files. If the file is listed as having been changed, the -U option ignores it. If not, it auto-installs it. > but can you tell it's new? If you can, you can check if > there's already a file of the same name before installing the new one? The whole point of the option is to automatically overwrite the existing file if it isn't listed as being changed. >> FWIW, this is one of the reasons that I resisted the idea of using >> mtree for this function, and continue to resist the idea of the -U >> option being the default. > > I didn't realize it was the default - but I really, really like it. It > makes mergemaster a *lot* easier to use. It's not the default. Corner cases like this one are the reason I resist making it the default. >> There is no way that I can see to have mtree list the files that have >> _not_ changed, which would be the safest way to implement this >> option. > > Doesn't sound unsurmountable. > >> Meanwhile I'm sure you were able to restore from backups > > Of course (not that there was much to restore - just "server ntp.des.no > iburst maxpoll 6"), and now that I know about it, I can list it in > IGNORE_FILES along with motd and printcap. Now that you've had a successful run with the new sources the signature for the stock file will be in mergemaster's mtree file so you won't have to worry. You might also consider adding the svn Id for the source file which will allow mergemaster to ignore it altogether at least until it changes. hope this helps, Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: svn commit: r193635 - head/etc
On Thu, Jun 18, 2009 at 09:58:01PM -0700, Doug Barton wrote: > Dag-Erling Sm??rgrav wrote: > > Doug Barton writes: > >> Dag-Erling Sm??rgrav writes: > >>> Great, now mergemaster blew away my ntp.conf and installed this one > >>> instead. Apparently, it thinks AUTO_UPGRADE means it's fine to > >>> overwrite an existing file with a new one... > >> Yes, that's exactly what the option means. The problem comes in > >> because it's a new file, which means that there is no record of it in > >> the mtree file, so it does not show up as "changed." > > > > Hmm, I'm not sure I follow, since I'm not familiar with the innards of > > mergemaster, > > The -U option works by comparing the installed files to the mtree file > created from the unmodified source files. If the file is listed as > having been changed, the -U option ignores it. If not, it > auto-installs it. Is it not possible to change the logic of -U a little. Only auto install if it is in mtree and has not changed. So if it has changed or is not in mtree, skip the auto install. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: svn commit: r193635 - head/etc
John Hay wrote: > Is it not possible to change the logic of -U a little. Only auto install > if it is in mtree and has not changed. So if it has changed or is not in > mtree, skip the auto install. Apparently you didn't read the whole thread, but the answer is no. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
