Re: Why is intr taking up so much cpu?
On Sun, Jul 18, 2010 at 10:06:06PM -0700, Doug Barton wrote:
On 07/18/10 12:41, Kostik Belousov wrote:
On Sun, Jul 18, 2010 at 12:21:00PM -0700, Doug Barton wrote:
On 07/18/10 03:30, Kostik Belousov wrote:
On Sun, Jul 18, 2010 at 01:14:41AM -0700, Doug Barton wrote:
On Sat, 17 Jul 2010, Kostik Belousov wrote:
Run top in the mode where all system threads are shown separately
(e.g. top -HS seems to do it), then watch what thread eats the
processor.
And the winner is!
11 root -32- 0K 168K WAIT0 0:28 18.02% {swi4:
clock}
11 root21 -64- 0K 168K WAIT0 1:17 18.90% intr
The first is with -H, the second without.
Most likely it is some callout handling. Just in case, do you have
console screensaver active ?
I assume you mean saver=yes in rc.conf, and the answer is no, I am not
using that. Usually I run xscreensaver, but at the time this happened I
was not. I do have DPMS enabled in my X config though.
Any suggestions on how to dig deeper on this? Are there any settings I
can twiddle to try and mitigate it?
When intr time starts accumulating again, try to do
procstat -kk intr process pid and correlate the clock thread tid
with the backtrace. Might be, it helps to guess what callouts are eating
the CPU.
Ok, file attached.
--
Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/
Computers are useless. They can only give you answers.
-- Pablo Picasso
PIDTID COMM TDNAME KSTACK
11 14 intr swi1: netisr 0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 15 intr swi4: clock mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 16 intr swi4: clock mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 17 intr swi3: vm
11 100014 intr swi6: Giant task mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100015 intr swi6: task queue mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100020 intr swi2: cambio mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100021 intr swi5: +
11 100022 intr irq9: acpi0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100023 intr irq16:
11 100024 intr irq256: hdac0mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100026 intr irq17: wpi0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100027 intr irq20: hpet0 uhc mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100032 intr irq21: uhci1
11 100037 intr irq22: uhci2 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100042 intr irq23: uhci3
11 100052 intr irq14: ata0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100053 intr irq15: ata1 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100055 intr irq1: atkbd0 mi_switch+0x200
ithread_loop+0x1da fork_exit+0xb8 fork_trampoline+0x8
11 100056 intr irq12: psm0
11 100057 intr swi0: uart
You should correlate the backtrace and the id of the cpu-consuming thread
(15 or 16, or both) and do periodic procstat -k to see which
functions are referenced most often.
Might be, suggested dtrace solution is easier.
pgpdw3vZqYxla.pgp
Description: PGP signature
Re: Can't make distribution TARGET_ARCH=... after r209510
M. Warner Losh wrote: In message: 20100718.171610.338707487962422543@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : In message: 20100718210154.ga94...@laptop.levsha.me : Mykola Dzham i...@levsha.me writes: : : Hi! : : Attemt to make jail with different target arch on tinderbox (i386 jail : : on amd64 host) exits with error: : : : : ERROR: distribution failed - see /usr/local/tinderbox/jails/9-HEAD.i386/distribution.tmp : : : : Last lines from log: : : : : cd /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail; make distribution : : install -o root -g wheel -m 644 /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail/freebsd.mc freebsd.cf /tmp/tinderbox/jails/9-HEAD.i386/tmp/etc/mail : : install: freebsd.cf: No such file or directory : : *** Error code 71 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc/sendmail. : : *** Error code 1 : : : : Stop in /usr/local/tinderbox/jails/9-HEAD.i386/src/etc. : : : : Full build and distribution logs avaliable on : : http://levsha.me/tmp/20100718/world.txt (20M) : : http://levsha.me/tmp/20100718/distribution.txt (7.4K) : : : : Reverting r209510 fixes this problem : : It works for me. : : on an amd64 box: : setenv TARGET=i386 : make buildworld : make installworld DESTDIR=/tmp/mumble : make distribution DESTDIR=/tmp/mumble To which I forgot to add: Please send me the exact sequence of commands that fails, as well as the uname of the host. I'd like to try to track this down... Hmm, all work properly with TARGET_ARCH when i build directly: export TARGET_ARCH=i386 make buildworld make installworld DESTDIR=/tmp/i386 make distribution DESTDIR=/tmp/i386 Problem occurs only if i try to make i386 jail in tinderbox $ sudo ./tc tbversion Tinderbox version 3.3.r1 $ svn info /usr/local/tinderbox/jails/9-HEAD.i386/src Path: /usr/local/tinderbox/jails/9-HEAD.i386/src URL: file:///usr/local/arch/base/head Repository Root: file:///usr/local/arch/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 210161 Node Kind: directory Schedule: normal Last Changed Author: imp Last Changed Rev: 210161 Last Changed Date: 2010-07-16 09:35:17 +0300 (пт, 16 лип 2010) I will try to get commands, used by tinderbox to build world and distribution, and check this commands. Thanks! -- LEFT-(UANIC|RIPE) JID: lev...@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[CFR] devfs improvements
Hi, I have been working on some devfs improvements and I am now posting the patch for wider review and testing. Especially testing from people using multiple devfs mounts and/or symbolic links would be useful. The patch: http://people.freebsd.org/~jh/patches/devfs.7.diff Notable changes: - Automatically remove empty directories. - Allow user created symbolic links to cover device files and directories if the device file appears after the link creation. - It's now possible to report if the device file already exists or is invalid to make_dev_credf(9) and make_dev_p(9) callers. There is a new flag MAKEDEV_CHECKNAME to indicate that the caller is prepared to handle such error. If the flag is not specified and the device name is invalid, a panic will occur. This code is not yet enabled because there are some driver issues which need to be sorted out before. (See #ifdef notyet in make_dev_credv().) In addition the patch should fix these bugs: - kern/114057 - fstat(2) could return stale information through open file descriptors. My main motivation for these changes was erratic handling of duplicate and invalid device names. For example currently you can crash the system through geom_label by inserting a specially crafted CD. Driver bugs causing duplicate device registrations weren't detected either. Most of the ideas implemented in the patch are from Kostik Belousov. Special thanks for him providing help and reviews during the development. Additional patches: A patch for GEOM to convert g_dev_taste() to use make_dev_p() with MAKEDEV_CHECKNAME flag instead of make_dev(). http://people.freebsd.org/~jh/patches/geom_dev-checkname.diff Enable panicking on invalid device names: http://people.freebsd.org/~jh/patches/make_dev-checkname.diff -- Jaakko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On 2010-07-18 at 14:20, Marius Strobl wrote: Downgrading now... And it crashed again, with current from r209598... Ok, this at least means that your problem isn't caused by the recent changes to mpt(4) as the pre-r209599 version only differed from the 8-STABLE one in a cosmetic change at that time. I have another data-point, I cvsup'ed to the latest current again, and rebuilt without INVARIANT and WITNESS, and now it seems to survive the timeouts. -- Ståle Kristoffersen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [panic] Race in IEEE802.11 layer towards device drivers
Hi AK, I've committed your patches to USB P4. I've made some additional patches. Can you check and verify everything? http://p4web.freebsd.org/@@181189?ac=10 Also please compile a kernel with WITNESS enabled to catch any LOR's, hence we introduced another mutex. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for testers: wireless module for bsnmpd(1)
Hi all,
Thanks for the feedback and comments.
I've uploaded an updated tarball at
http://people.freebsd.org/~syrinx/snmp/snmp_wlan-20100719-01.tar .
On Sun, Jul 11, 2010 at 8:23 PM, Gabor PALI p...@freebsd.org wrote:
A few comments:
- I think there should be bsnmpd(1) instead of bsnmpd(8) in the NAME
section of snmp_wlan(3).
Fixed in the latest sources.
- It creates an /usr/lib/snmp_wlan.so. file which seems a bit strange
for me.
Yes, indeed - this weird naming happens when an bsnmp module is built
outside the source tree and SHLIB_MAJOR is not defined - the
bsd.snmpmod.mk file names a module based on
snmp_${MOD}.so.${SHLIB_MAJOR} - this should be resolved once the
module is made part of the source tree.
- It produces the following on my machine:
snmpd[3871]: SNMP wlan loaded wlan_wlan_acl module
snmpd[3871]: send: Connection refused
snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
snmpd[3871]: iface wlan0 - get param: ioctl(41) failed: Invalid argument
This is because ioctl(wname, IEEE80211_IOC_MACCMD, ...) returns EINVAL
when no MAC ACL policy has been configured in the interface - should
be resolved in the latest sources.
On Wed, Jul 14, 2010 at 5:40 AM, Adrian Chadd adr...@freebsd.org wrote:
Howdy!
Compiling this on MIPS gives this error:
Warning: Object directory not changed from original
/usr/home/adrian/w/snmp_wlan
cc -fpic -DPIC -O -pipe -EB -msoft-float -G0 -mno-dsp -mabicalls
-DSNMPTREE_TYPES -g -I. -std=gnu99 -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual
-Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter
-Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -c wlan_sys.c -o wlan_sys.So
cc1: warnings being treated as errors
wlan_sys.c: In function 'wlan_get_scan_results':
wlan_sys.c:2221: warning: cast increases required alignment of target type
wlan_sys.c: In function 'wlan_get_peerinfo':
wlan_sys.c:2713: warning: cast increases required alignment of target type
*** Error code 1
In the latest sources, I replaced the cast with memcopy's which shold
fix the errors, but I haven't tested it since I don't have a MIPS
platform to test. It'll be good to know the errors have been actually
fixed.
On Wed, Jul 14, 2010 at 6:16 AM, Adrian Chadd adr...@freebsd.org wrote:
I've already emailed you about the alignment warnings.
The returned error value is an SNMPv2 error (SNMP_ERR_INCONS_VALUE)
which causes v1 requests to error out. Is it at all possible to return
something valid if a v1 request is made?
The SNMP_ERR_INCONS_VALUE is only returned in responce to SET requests
when the value requested for SET is not valid - in such case if the
packet is SNMPv1 packet the SNMP agent should itself replace any
SNMPv2 error code with a corresponding SNMPv1 code (e.g
SNMP_ERR_BADVALUE should be returned instead of
SNMP_ERR_INCONS_VALUE); could you please specify your agent config and
what exact client command and aparameters are you issueing to produce
the problem.
snmpwalk'ing to inspect what -is- returned fails, even when querying in v2
mode:
BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nRIFS.wlan0 = INTEGER: false(2)
BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nShortGI.wlan0 = INTEGER: false(2)
BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode.wlan0 = INTEGER: disabled(1)
Error in packet.
Reason: (genError) A general failure occured
Failed object: BEGEMOT-WIRELESS-MIB::wlanIfaceDot11nSMPSMode.wlan0
The daemon logs errors when features aren't supported by the
underlying driver (eg querying TDMA stats on a non-TDMA interface.)
This may hide any actual underlying issues.
This shouldn't be the case - the module reads each wlan parent
capabilities and a relevant setting is only attempted in the kernel,
only if the parent/wlan iterface capabilities indicate it is
supported. I'm trying to test it on my system, but I don't see a
problem. Again, could you please specify your kernel config, hardware
wireless card, FreeBSD vsersion and the commands that you're running
to create the problem.
It isn't immediately clear which parameters are related to station and
which are related to hostap. Eg, wlanIfaceBeaconMissedThreshold. Is
that the station threshold or the AP threshold? Would it be worthwhile
creating separate branches for different stat types (station, ap, TDMA
AP, dot11n stuff, etc, etc?) rather than whacking it all together in
one tree?
The description of each object (and specifically under the
wlanIfaceConfigTable table) in the BEGEMOT-WIRELESS-MIB.txt specifies
whether the relevant object is meaningfull for interfaces in station
or ap mode. I've thought about splitting the configuration in separate
tables
Re: Problem with ZFS version 15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 2010/07/17 06:40, Michael Gusek wrote: Hi, i updated my 8.1-PRERELEASE to ZFS version 15. The patch http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch applies fine and after reboot i upgrade my pool successfully to version 15. Now, after a new reboot the bootloader can't boot from version 15, it supports only 13. Well, i build a bootable usb pen with 8.1-PRERELEASE and ZFS version 15, boot from it and apply a new bootloader: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0|ad1. After this, i've lost my gpt scheme ! gpart show ad0 says gpart: No such geom: ad0. How can i recover my gpt on ad0 and ad1 ? I'm running a zfs mirror on ad0 and ad1. If you have previous saved gpart information (e.g. start/end) then you can safely destroy and re-create the GPT partitions without destroying the data. Note that you may need to backup and dd the first and last sector of your hard drive before proceeding. Cheers, Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRMGcAAoJEATO+BI/yjfBbVUIAMIKRxUKMRpEdDJkPKqE3hZJ sjCUm8XveedJHVz2SupvpsQizo/hKDkgksfzeqeRd8JA1g4jerORLCNYilpcwMfc 2AiyjgvpKbsYmT27WcG4Grnl3eE4jFF+7Wm8B8WtuzE7L+YMo+QcEYiSPzL8P8hJ 1+RwLas/4nVkaDWWBW9osanLYT1v62zIN0ik1bnZypY3kYuprfJN3G7ZCKVX7ffD 4AZr7bvO57mcQOXON9gkmOMfewt89lNJiMYf5yQiGX+BL/i3pYUGSj2kt1Yc0su5 y5NyC42wiUNVEn15pVsIS5AUJVHs574pZBH2+DX5DfvDZMgxCkcUxgKq08QVnjE= =qQgN -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
If you have previous saved gpart information (e.g. start/end) then you can safely destroy and re-create the GPT partitions without destroying the data. Note that you may need to backup and dd the first and last sector of your hard drive before proceeding. Could someone post a example of how to correctly backup a gpart partition information -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/19 14:37, Sam Fourman Jr. wrote: If you have previous saved gpart information (e.g. start/end) then you can safely destroy and re-create the GPT partitions without destroying the data. Note that you may need to backup and dd the first and last sector of your hard drive before proceeding. Could someone post a example of how to correctly backup a gpart partition information For now it would be to backup the first 34 and last 33 sectors of a given disk. Another way would be to copy what gpart show says and restore it manually. Cheers, - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRNC6AAoJEATO+BI/yjfBEjcIAIj3e/n7DUBfXhaUKEOSrP2q fvJlAKiQoDyRpzuovT/9/c9jCUxOOgpW43S7EVQ244uzgVEGB2Su5jXOjX6dU+rZ ba0JwH60ANMB6RAsJFSk1cT6xMmQ4TMfSYCwwlx9p6Fbv2ejdd5gKE+zvbc20fwN HIojqdF9xIW2XT3gjvAngn69c/0EtHoJVG1gydlO3H3te6iDVM6CY5yHV71WJrEk cFDD6x65VYmC2GWYYbeokf2ud8nry1QjzxzBJRd9T0eHXPWweJBC7lOsIOSW5QYa 1VsyhFE8s1xPwtYTAYFUw3IhBzJdLt36n+YAEQEbrX20/G5+Qn2oo/bw0kIYrFg= =SsvG -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
how about adding a periodic script to /etc/periodic/daily to backup the information? the idea was raised a long time ago already, but was abandoned [1]. cheers. alex [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/86388 On Mon, Jul 19, 2010 at 03:24:58PM -0700, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/19 14:37, Sam Fourman Jr. wrote: If you have previous saved gpart information (e.g. start/end) then you can safely destroy and re-create the GPT partitions without destroying the data. Note that you may need to backup and dd the first and last sector of your hard drive before proceeding. Could someone post a example of how to correctly backup a gpart partition information For now it would be to backup the first 34 and last 33 sectors of a given disk. Another way would be to copy what gpart show says and restore it manually. Cheers, - -- Xin LI delp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve!Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRNC6AAoJEATO+BI/yjfBEjcIAIj3e/n7DUBfXhaUKEOSrP2q fvJlAKiQoDyRpzuovT/9/c9jCUxOOgpW43S7EVQ244uzgVEGB2Su5jXOjX6dU+rZ ba0JwH60ANMB6RAsJFSk1cT6xMmQ4TMfSYCwwlx9p6Fbv2ejdd5gKE+zvbc20fwN HIojqdF9xIW2XT3gjvAngn69c/0EtHoJVG1gydlO3H3te6iDVM6CY5yHV71WJrEk cFDD6x65VYmC2GWYYbeokf2ud8nry1QjzxzBJRd9T0eHXPWweJBC7lOsIOSW5QYa 1VsyhFE8s1xPwtYTAYFUw3IhBzJdLt36n+YAEQEbrX20/G5+Qn2oo/bw0kIYrFg= =SsvG -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why is intr taking up so much cpu?
I added options KDTRACE_HOOKS to my kernel config, built a new kernel,
and rebooted. I decided to try your script before things went sideways
so I'd have an idea of what to expect, and it didn't work:
dtrace: failed to initialize dtrace: DTrace device not available on
system
Is there something else I need to do to enable it?
Doug
On Sun, 18 Jul 2010, Dan Nelson wrote:
You can also use dtrace to get a count of callouts and their time spent.
Run this for a few seconds then hit ^C:
#! /usr/sbin/dtrace -s
/* #pragma D option quiet */
callout_execute:::callout_start
{
this-start = timestamp;
}
callout_execute:::callout_end
{
this-end = timestamp;
/* printf(%a %d\n,args[0]-c_func, this-end - this-start); */
@times[args[0]-c_func] = quantize(this-end - this-start);
/* @times[args[0]-c_func] = lquantize(this-end -
this-start,0,30,1); */
@counts[args[0]-c_func] = count();
}
END
{
printa(%a %...@u\n,@times);
printa(%a %...@u\n,@counts);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why is intr taking up so much cpu?
On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton do...@freebsd.org wrote: I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and rebooted. I decided to try your script before things went sideways so I'd have an idea of what to expect, and it didn't work: dtrace: failed to initialize dtrace: DTrace device not available on system Is there something else I need to do to enable it? You need to build the kernel with CTF. Try adding makeoptions WITH_CTF=yes to your config and rebuilding your kernel. There's a blurb in src/UPDATING about other ways to accomplish the same thing. -- Chris - http://twitter.com/chrisattack http://chrisattack.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
On Mon, Jul 19, 2010 at 7:37 PM, Alexander Best arun...@freebsd.org wrote: how about adding a periodic script to /etc/periodic/daily to backup the information? the idea was raised a long time ago already, but was abandoned [1]. cheers. alex I think that is a good idea, if you have a script to do that I would test it -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problem with ZFS version 15
On Mon, Jul 19, 2010 at 08:31:11PM -0500, Sam Fourman Jr. wrote: On Mon, Jul 19, 2010 at 7:37 PM, Alexander Best arun...@freebsd.org wrote: how about adding a periodic script to /etc/periodic/daily to backup the information? the idea was raised a long time ago already, but was abandoned [1]. cheers. alex I think that is a good idea, if you have a script to do that I would test it unfortunately i don't. ;) i think however that for such a script using gpart to dump a fs's layout would be suited much better than dumping the primary and backup GPT table directly (using `dd` e.g.). cheers. alex -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why is intr taking up so much cpu?
On Mon, 19 Jul 2010, Chris Ruiz wrote: On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton do...@freebsd.org wrote: I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and rebooted. I decided to try your script before things went sideways so I'd have an idea of what to expect, and it didn't work: dtrace: failed to initialize dtrace: DTrace device not available on system Is there something else I need to do to enable it? You need to build the kernel with CTF. Try adding makeoptions WITH_CTF=yes to your config and rebuilding your kernel. There's a blurb in src/UPDATING about other ways to accomplish the same thing. Thanks for the suggestion, but no improvement. Doing: strings /boot/kernel/kernel | grep -i dtrace Shows lots of dtrace-related entries, unlike previous kernels built without the KDTRACE_HOOKS option, but same error with Dan's script. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why is intr taking up so much cpu?
On Mon, Jul 19, 2010 at 07:33:01PM -0700, Doug Barton wrote: On Mon, 19 Jul 2010, Chris Ruiz wrote: On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton do...@freebsd.org wrote: I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and rebooted. I decided to try your script before things went sideways so I'd have an idea of what to expect, and it didn't work: dtrace: failed to initialize dtrace: DTrace device not available on system Is there something else I need to do to enable it? You need to build the kernel with CTF. Try adding makeoptions WITH_CTF=yes to your config and rebuilding your kernel. There's a blurb in src/UPDATING about other ways to accomplish the same thing. Thanks for the suggestion, but no improvement. Doing: strings /boot/kernel/kernel | grep -i dtrace Shows lots of dtrace-related entries, unlike previous kernels built without the KDTRACE_HOOKS option, but same error with Dan's script. Try a kldload dtraceall before running the script. Regards, Navdeep ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why is intr taking up so much cpu?
On Tuesday 20 July 2010 04:33:01 Doug Barton wrote: On Mon, 19 Jul 2010, Chris Ruiz wrote: On Mon, Jul 19, 2010 at 8:03 PM, Doug Barton do...@freebsd.org wrote: I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and rebooted. I decided to try your script before things went sideways so I'd have an idea of what to expect, and it didn't work: dtrace: failed to initialize dtrace: DTrace device not available on system Is there something else I need to do to enable it? You need to build the kernel with CTF. Try adding makeoptions WITH_CTF=yes to your config and rebuilding your kernel. There's a blurb in src/UPDATING about other ways to accomplish the same thing. Thanks for the suggestion, but no improvement. Doing: strings /boot/kernel/kernel | grep -i dtrace Shows lots of dtrace-related entries, unlike previous kernels built without the KDTRACE_HOOKS option, but same error with Dan's script. Just a stab in the dark, did you kldload dtraceall? KDTRACE_HOOKS just adds the needed linkage for the dtrace modules to work. Max ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why is intr taking up so much cpu?
On Tue, 20 Jul 2010, Max Laier wrote: Just a stab in the dark, did you kldload dtraceall? KDTRACE_HOOKS just adds the needed linkage for the dtrace modules to work. No, I had not done that, in fact, I didn't even know I needed those modules. I use MODULES_OVERRIDE so I had to add dtrace, cyclic, and opensolaris to the list. In any case ... It's working now! :) I'm collecting some data for normal atm, then I'll try to get it into the situation where intr runs away, and I'll do the same thing again. Thanks Max and Chris, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
firefox is stuck in getbuf()
With newest -HEAD code, firefox is stuck in getbuf(). top last pid: 1814; load averages: 0.00, 0.05, 0.07 up 0+00:37:11 10:54:01 135 processes: 1 running, 134 sleeping CPU: 3.7% user, 0.0% nice, 0.6% system, 0.0% interrupt, 95.7% idle Mem: 259M Active, 393M Inact, 151M Wired, 1484K Cache, 111M Buf, 186M Free Swap: 2020M Total, 2020M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1427 davidxu 1 450 114M 101M select 0 1:24 0.29% Xorg 1588 davidxu 10 440 279M 145M getbuf 0 2:15 0.00% firefox-bin procstat -k 1588 PIDTID COMM TDNAME KSTACK 1588 100200 firefox-bin initial thread mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100207 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _cv_wait_sig seltdwait poll syscallenter syscall Xint0x80_syscall 1588 100208 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100209 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100210 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_timedwait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100216 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100220 firefox-bin -mi_switch sleepq_switch sleepq_wait _sleep getdirtybuf flush_deplist softdep_sync_metadata ffs_syncvnode ffs_fsync VOP_FSYNC_APV fsync syscallenter syscall Xint0x80_syscall 1588 100238 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100239 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall 1588 100240 firefox-bin -mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep __umtx_op_cv_wait _umtx_op syscallenter syscall Xint0x80_syscall ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why is intr taking up so much cpu?
In the last episode (Jul 19), Doug Barton said: I added options KDTRACE_HOOKS to my kernel config, built a new kernel, and rebooted. I decided to try your script before things went sideways so I'd have an idea of what to expect, and it didn't work: dtrace: failed to initialize dtrace: DTrace device not available on system Is there something else I need to do to enable it? I think you also need WITH_CTF=yes , either in your kernel config or directly on the make commandline. The kernel config option should work, but if it doesn't, it's guaranteed to work on the commandline. http://wiki.freebsd.org/DTrace http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016620.html -- Dan Nelson dnel...@allantgroup.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
