Re: Announcement: PmcTools callchain capture for RELENG_7
Hello, A new patch is available that was done just after dtrace backport. You can find it like the previous one on the pmc wiki. It also include some new bugfix from head. Fabien Le 13 juil. 08 à 07:05, Joseph Koshy a écrit : 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
ports/126853: ports-mgmt/portaudit: speed up audit of installed packages
Good day.
A while ago I had created the new utility that serves as VuXML
filter for the installed packages:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853
My primary intention was to speed up the process of auditing the
vulnerable ports: I needed to run portaudit checks with Nagios and to
avoid large timeouts.
The new utility is called pkg_audit and it serves as a simple text
filter: on input it takes the full VuXML feed and on output it puts
VuXML entries that matches ports that are installed in the system with
port version specification substituted with the actual port versions.
No harm is done to the actual poartudit -- if pkg_audit is missing, old
code path is activated.
If someone is interested and will be able to test -- I am all ears.
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
pgphOb5l21SUP.pgp
Description: PGP signature
panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64
Got the following panic overnight: panic: lockmgr: thread 0xff0053cda680, not exclusive lock holder 0xff002d7da680 unlocking cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a _lockmgr() at _lockmgr+0x872 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 null_unlock() at null_unlock+0xff VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 nullfs_mount() at nullfs_mount+0x244 vfs_donmount() at vfs_donmount+0xe4d nmount() at nmount+0xa5 syscall() at syscall+0x254 Xfast_syscall() at Xfast_syscall+0xab --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = 0x7fffdfb8, rbp = 0x7fffdfc0 --- I've done some searches and "not exclusive lock holder" has been seen before, but I didn't find any previous reports related to nullfs with a stack trace at all like this on FreeBSD 7. This machine is diskless and thus cannot store a kernel dump. Ideas/ suggestions for fixes, causes or debugging steps? The kernel is amd64, with config shown below. Thanks, Jeff include GENERIC device carp device pf device pflog device pfsync options SW_WATCHDOG options DEVICE_POLLING options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ options ALTQ_NOPCC options KDB options KDB_UNATTENDED options KDB_TRACE options DDB options BREAK_TO_DEBUGGER ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Patch for working AMD Geode CS5530 audio driver on HEAD
On 2008-08-09 21:32, Rink Springer wrote: > Hi Ivan, > > On Sat, Aug 09, 2008 at 07:36:07PM +0200, Ivan Voras wrote: > > This patch looks like it needs something. Can you post or link to the > > entire driver please? > > Sure - this was already outlined in the original thread, but have a look > at http://63.249.85.132/gx_audio/index.html - the driver there works. > You need minor tweaks to the Makefile, these can be found in > http://setfilepointer.com/pub/geode/ns_geode.diff. > > Regards, I just got around to playing with this again, to no avail: geode Probe devid 20821022 classid 0010! geode Probe devid 20931022 classid 0004! pcm0: port 0xfe00-0xfe7f irq 11 at device 15.3 on pci0 geode Attach! ---> Geode mem regs at fe01 AUDIO PCI HDR *** -->Vendor ID =1022 -->Dev ID =2093 -->PCI cmd =5 -->PCI status =2a0 -->Dev revision =1 -->PCI class = -->PCI latency =0 -->PCI header type =0 -->BIST =0 --> Register Base address =fe01 pcm0: calling bus_alloc_resource pcm0: failed to enable memory mapping! pcm0: unable to map BAR reg device_attach: pcm0 attach returned 6 Anyone got any ideas? Remote access is available upon request. -- Alec Kloss [EMAIL PROTECTED] IM: [EMAIL PROTECTED] PGP key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA241980E "No Bunny!" -- Simon, http://wiki.adultswim.com/xwiki/bin/Frisky+Dingo/Simon pgpBIXqysv4OF.pgp Description: PGP signature
Major SMP problems with lstat/namei
We have encountered some serious SMP performance/scalability problems that we've tracked back to lstat/namei calls. I've written a quick benchmark with a pair of tests to simplify/measure the problem. Both tests use a tree of directories: the top level directory contains five subdirectories a, b, c, d, and e. Each subdirectory contains five subdirectories a, b, c, d, and e, and so on.. 1 directory at level one, 5 at level two, 25 at level three, 125 at level four, 625 at level five, and 3125 at level six. In the "realpath" test, a random path is constructed at the bottom of the tree (e.g. /tmp/lstat/a/b/c/d/e) and realpath() is called on that, provoking lstat() calls on the whole tree. This is to simulate a mix of high-contention and low-contention lstat() calls. In the "lstat" test, lstat is called directly on a path at the bottom of the tree. Since there are 3125 files, this simulates relatively low-contention lstat() calls. In both cases, the test repeats as many times as possible for 60 seconds. Each test is run simultaneously by multiple processes, with progressively doubling concurrency from 1 to 512. What I found was that everything is fine at concurrency 2, probably indicating that the benchmark pegged on some other resource limit. At concurrency 4, realpath drops to 31.8% of concurrency 1. At concurrency 8, performance is down to 18.3%. In the interim, CPU load goes to 80-90% system CPU. I've confirmed via ktrace and the rusage that the CPU usage is all system time, and that lstat() is the *only* system call in the test (realpath() is called with an absolute path). I then reran the 32-process test on 1-7 cores, and found that performance peaks at 2 cores and drops sharply from there. eight cores runs *fifteen* times slower than two cores. The test full results are at the bottom of this message. This is on 6.3-RELEASE-p4 with vfs.lookup_shared=1. I believe this is the same issue that was previously discussed as "2 x quad-core system is slower that 2 x dual core on FreeBSD" archived here: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038441.html In that post, Kris Kennaway wrote: > It is hard to say for certain without a direct profile comparison of the > workload, but it is probably due to lockmgr contention. lockmgr is used > for various locking operations to do with VFS data structures. It is > known to have poor performance and scale very badly." At this point, what I've got is one of those synthetic benchmarks, but it matches our production problems exactly, except that the production processes need a whole lot more RAM and eventually when this manifests, they backlog and the server death spirals through swap, which is a most unfortunate difference. I've chased my way up the kernel source to kern_lstat(), where a shared lock is obtained, and then onto namei, where vfs.lookup_shared comes into play. But unfortunately, I don't understand lockmgr, I don't know how the macros and flags I see here relate to it, I can't figure out what happened to the changes that Attilio Rao was working on, and there didn't seem to be much other hope at the time. This is becoming a huge problem for us. Is there anything that at all can be done, or any news? In the case linked above, improvement was made by changing a PHP setting that isn't applicable in our case. Thanks, Jeff Concurrency 1 realpath Total = 1409069 (100%) Total/Sec = 23484 Total/Sec/Worker = 23484 lstat Total = 6828763 (100%) Total/Sec = 113812 Total/Sec/Worker = 113812 Concurrency 2 realpath Total = 1450489 (100%) Total/Sec = 24174 Total/Sec/Worker = 12087 lstat Total = 6891417 (100.9%) Total/Sec = 114856 Total/Sec/Worker = 57428 Concurrency 4 realpath Total = 448693 (31.8%) Total/Sec = 7478 Total/Sec/Worker = 1869 lstat Total = 3047933 (44.6%) Total/Sec = 50798 Total/Sec/Worker = 12699 Concurrency 8 realpath Total = 258281 (18.3%) Total/Sec = 4304 Total/Sec/Worker = 538 lstat Total = 1688728 (24.7%) Total/Sec = 28145 Total/Sec/Worker = 3518 Concurrency 16 realpath Total = 179150 (12.7%) Total/Sec = 2985 Total/Sec/Worker = 186 lstat Total = 966558 (14.1%) Total/Sec = 16109 Total/Sec/Worker = 1006 Concurrency 32 realpath Total = 116982 (8.3%) Total/Sec = 1949 Total/Sec/Worker = 60 lstat
