Re: Why is intr taking up so much cpu?
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: Okey dokey, here you go: http://people.freebsd.org/~dougb/normal-dtrace.txt http://people.freebsd.org/~dougb/bad-dtrace.txt Thanks again, 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 Sun, 18 Jul 2010, Kostik Belousov wrote: 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, I thought I was going to be able to do this easily but I didn't realize that the numbers in the second column were thread ids, and I don't know how to correlate the clock thread tid with the backtrace. Can you give me a hint? :) 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: Problem with ZFS version 15
-Ursprüngliche Nachricht- Von: Xin LI delp...@delphij.net Gesendet: 19.07.2010 23:20:28 An: Michael Gusek michael.gu...@web.de Betreff: 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. I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: gpart create -s GPT ad0 ? Do i lost my data ? Micha Cheers, Cheers, - -- Xin LI http://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 ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de ___ 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
- Original Message
From: Hans Petter Selasky hsela...@c2i.net
To: freebsd-current@freebsd.org
Cc: PseudoCylon moonlightak...@yahoo.ca; Sam Leffler s...@freebsd.org;
freebsd-...@freebsd.org
Sent: Mon, July 19, 2010 1:17:04 PM
Subject: 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
Hi
If we change sc-cmdq_run = RUN_CMDQ_ABORT,
-- begin excerpt --
@@ -4890,7 +4877,10 @@ run_stop(void *arg)
ifp-if_drv_flags = ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE);
sc-ratectl_run = RUN_RATECTL_OFF;
-sc-cmdq_run = RUN_CMDQ_ABORT;
+
+RUN_CMDQ_LOCK(sc);
+sc-cmdq_run = sc-cmdq_key_set = RUN_CMDQ_ABORT;
+RUN_CMDQ_UNLOCK(sc);
-- end excerpt --
we also need to change this, otherwise key will be cleared.
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index 017e4b0..f7abe17 100644
--- a/dev/usb/wlan/if_run.c
+++ b/dev/usb/wlan/if_run.c
@@ -4670,8 +4670,6 @@ run_init_locked(struct run_softc *sc)
if(ic-ic_nrunning 1)
return;
-run_stop(sc);
-
for (ntries = 0; ntries 100; ntries++) {
if (run_read(sc, RT2860_ASIC_VER_ID, tmp) != 0)
goto fail;
-- end patch --
Also please compile a kernel with WITNESS enabled to catch any LOR's, hence
we
introduced another mutex.
The 2nd mutex did solve a deadlock, but doesn't solve the LOR.
-- begin message --
lock order reversal:
1st 0xff8000a257d0 run0_node_lock (run0_node_lock) @
/usr/src/sys/net80211/ieee80211_node.c:1736
2nd 0xff8000a19348 run0 (network driver) @
/mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:2212
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_mtx_lock_flags() at _mtx_lock_flags+0x78
run_key_delete() at run_key_delete+0x45
_ieee80211_crypto_delkey() at _ieee80211_crypto_delkey+0x9e
ieee80211_crypto_delkey() at ieee80211_crypto_delkey+0x28
ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x78
ieee80211_sta_leave() at ieee80211_sta_leave+0x16
ieee80211_node_leave() at ieee80211_node_leave+0x11d
hostap_recv_mgmt() at hostap_recv_mgmt+0x33f
hostap_input() at hostap_input+0xc09
run_rx_frame() at run_rx_frame+0x13f
run_bulk_rx_callback() at run_bulk_rx_callback+0x3b7
usbd_callback_wrapper() at usbd_callback_wrapper+0x12b
usb_command_wrapper() at usb_command_wrapper+0x76
usb_callback_proc() at usb_callback_proc+0x76
usb_process() at usb_process+0xbb
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff8029b4ed30, rbp = 0 ---
-- end message --
or
-- begin message --
lock order reversal:
1st 0xff8000a257d0 run0_node_lock (run0_node_lock) @
/usr/src/sys/net80211/ieee80211_node.c:1736
2nd 0xff8000a19348 run0 (network driver) @
/mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:2212
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x81e
_mtx_lock_flags() at _mtx_lock_flags+0x78
run_key_delete() at run_key_delete+0x47
_ieee80211_crypto_delkey() at _ieee80211_crypto_delkey+0x9e
ieee80211_crypto_delkey() at ieee80211_crypto_delkey+0x28
ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x78
ieee80211_sta_leave() at ieee80211_sta_leave+0x16
ieee80211_node_leave() at ieee80211_node_leave+0x11d
ieee80211_node_timeout() at ieee80211_node_timeout+0x1d5
softclock() at softclock+0x2a0
intr_event_execute_handlers() at intr_event_execute_handlers+0x66
ithread_loop() at ithread_loop+0xb2
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff852d30, rbp = 0 ---
-- end message --
There are new warning, acquiring duplicate lock. For example,
-- begin message --
acquiring duplicate lock of same type: network driver
1st run0 @ /usr/src/sys/dev/usb/usb_request.c:691
2nd run0 @
/mnt/share/home/AK/FreeBSD/modules/usb/run/../../../../mnt/dev/usb/wlan/if_run.c:4831
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x8ef
_mtx_lock_flags() at _mtx_lock_flags+0x78
run_init_locked() at run_init_locked+0x753
run_ioctl() at run_ioctl+0xad
taskqueue_run() at taskqueue_run+0x91
taskqueue_thread_loop() at taskqueue_thread_loop+0x3f
fork_exit() at fork_exit+0x12a
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff803e5b2d30, rbp = 0 ---
-- end message --
I don't know if it's worth patching or safe to patch (specially lock/unlock in
run_bulk_tx_callbackN()), but here is one
-- begin patch --
diff --git a/dev/usb/wlan/if_run.c b/dev/usb/wlan/if_run.c
index
Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On Mon, Jul 19, 2010 at 07:06:54PM +0200, Stle Kristoffersen wrote: 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. That's more or less expected as the sanity check issuing the panic just isn't compiled in then. However, my understanding was that with STABLE you don't get the timeouts in the first place, or do you see them there also? Marius ___ 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 20.07.2010 13:51, Michael Gusek wrote: 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. It is very strange why this command broke your GPT. Actually incorrect PMBR can prevent probes for GEOM_PART_GPT. I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: gpart create -s GPT ad0 ? Do i lost my data ? GPT headers and tables will be initialized. After that you should add all partitions with exactly same offsets and sizes. In this case your data will not be touched. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [panic] Race in IEEE802.11 layer towards device drivers
On Tuesday 20 July 2010 12:03:22 PseudoCylon wrote: - Original Message From: Hans Petter Selasky hsela...@c2i.net To: freebsd-current@freebsd.org Cc: PseudoCylon moonlightak...@yahoo.ca; Sam Leffler s...@freebsd.org; freebsd-...@freebsd.org Sent: Mon, July 19, 2010 1:17:04 PM Subject: 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 Hi If we change sc-cmdq_run = RUN_CMDQ_ABORT, -- begin excerpt -- @@ -4890,7 +4877,10 @@ run_stop(void *arg) ifp-if_drv_flags = ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); sc-ratectl_run = RUN_RATECTL_OFF; -sc-cmdq_run = RUN_CMDQ_ABORT; + +RUN_CMDQ_LOCK(sc); +sc-cmdq_run = sc-cmdq_key_set = RUN_CMDQ_ABORT; +RUN_CMDQ_UNLOCK(sc); -- end excerpt -- we also need to change this, otherwise key will be cleared. Ok. Try to give the second mutex a different name, and see how many warnings go away. --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: [TESTING]: updated clang/LLVM needs testing in ClangBSD
On Wed, Jul 14, 2010 at 3:38 PM, Roman Divacky rdiva...@freebsd.org wrote: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld Hi. Until here worked fine. I'm on an AMD64-Quadcore (Phenom x4). I did 'make buildworld'. Should I use something like 'make -j 8' for testing? The 'installworld' and kernel I will test thursday. snip -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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
-Urspr?ngliche Nachricht- Von: Andrey V. Elsukov bu7c...@yandex.ru Gesendet: 20.07.2010 12:47:49 An: Michael Gusek michael.gu...@web.de Betreff: Re: Problem with ZFS version 15 On 20.07.2010 13:51, Michael Gusek wrote: 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. It is very strange why this command broke your GPT. Actually incorrect PMBR can prevent probes for GEOM_PART_GPT. Yes, this is very strange. I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: gpart create -s GPT ad0 ? Do i lost my data ? GPT headers and tables will be initialized. After that you should add all partitions with exactly same offsets and sizes. In this case your data will not be touched. Ok, i will try it. I did a backup of the first 16GB of my disk, because i don't know the exact size of my swap partition, but this is my part. Thank you, Michael -- WBR, Andrey V. Elsukov ___ GRATIS für alle WEB.DE Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de signature.asc Description: OpenPGP digital signature
Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On 2010-07-20 at 12:17, Marius Strobl wrote: On Mon, Jul 19, 2010 at 07:06:54PM +0200, Stle Kristoffersen wrote: 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. That's more or less expected as the sanity check issuing the panic just isn't compiled in then. However, my understanding was that with STABLE you don't get the timeouts in the first place, or do you see them there also? I got the timeouts with STABLE as well, that was the reason for me to try out CURRENT. I'm sorry I didn't mention that earlier. My main concern is to get rid of the timeouts, but a panic on one can't be right. How can I debug this further? I can get timeout fairly consistent by putting a bit of load on the drives. If it would help I can also provide remote access. I'm trying to update the firmware on some of the drives now to see if that helps with 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: Can't make distribution TARGET_ARCH=... after r209510
Mykola Dzham wrote:
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!
This is tinderbox error: tinderbox run make distribution directly in
${SRCBASE}/etc and set all variables (including MAKEOBJDIRPREFIX)
manually. So, after r209510 this method does not work properly.
This patch on tinderbox fixes problem:
--- scripts/lib/tc_command.sh.orig 2010-07-20 09:32:57.977402441 +0300
+++ scripts/lib/tc_command.sh 2010-07-20 09:35:12.935906873 +0300
@@ -774,10 +774,10 @@
# determine if we're cross-building world
crossEnv=
if [ ${jailArch} != ${myArch} ]; then
- crossEnv=TARGET_ARCH=${jailArch} MACHINE_ARCH=${jailArch}
MAKEOBJDIRPREFIX=${J_OBJDIR}/${jailArch} MACHINE=${jailArch}
+ crossEnv=TARGET_ARCH=${jailArch}
fi
-cd ${SRCBASE}/etc env DESTDIR=${J_TMPDIR} ${crossEnv} \
- make -m ${J_TMPDIR}/usr/share/mk distribution
${jailBase}/distribution.tmp 21
+cd ${SRCBASE} env DESTDIR=${J_TMPDIR} ${crossEnv} \
+ make distribution ${jailBase}/distribution.tmp 21
if [ $? -ne 0 ]; then
echo ERROR: distribution failed - see ${jailBase}/distribution.tmp
buildJailCleanup 1 ${jailName} ${J_SRCDIR}
--
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
Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On 20.07.2010 13:55, Ståle Kristoffersen wrote: On 2010-07-20 at 12:17, Marius Strobl wrote: On Mon, Jul 19, 2010 at 07:06:54PM +0200, Stle Kristoffersen wrote: 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. That's more or less expected as the sanity check issuing the panic just isn't compiled in then. However, my understanding was that with STABLE you don't get the timeouts in the first place, or do you see them there also? I got the timeouts with STABLE as well, that was the reason for me to try out CURRENT. I'm sorry I didn't mention that earlier. My main concern is to get rid of the timeouts, but a panic on one can't be right. How can I debug this further? I can get timeout fairly consistent by putting a bit of load on the drives. If it would help I can also provide remote access. I'm trying to update the firmware on some of the drives now to see if that helps with the timeouts. Sorry for the late response here, but what you're describing matches fairly well what I saw with RELENG_8 (just after 8.0 was released), but luckily I didn't have any disks on my MPT, just my tape autoloader. Random timeouts, and then bus resets (that made tape IO unreliable). The bad news, is that I had the exact same trouble with OpenSolaris (134), and something-similar with Linux (can't remember versions), at the time. I never did find a solution, and ended up throwing windows on the box, just to get reliable backups. My MPT is a 3801 LSI1068e based card running the latest bios. //Svein -- +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. Picture Gallery: https://gallery.stillbilde.net/v/svein/ signature.asc Description: OpenPGP digital signature
Re: emt64 performance degradation over amd64
On 07/18/10 21:21, Fabio Kaminski wrote: (note that i cant be too precise , since i didnt go any further with more tests... its more a subjective feel (boot time, general use.. etc)) It is probable then that it is only your imagination, and if you are really serious about this you should make some objective measurements on directly comparable hardware. http://wiki.freebsd.org/BenchmarkAdvice ___ 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 11:05:26PM -0700, Doug Barton wrote: On Sun, 18 Jul 2010, Kostik Belousov wrote: 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, I thought I was going to be able to do this easily but I didn't realize that the numbers in the second column were thread ids, and I don't know how to correlate the clock thread tid with the backtrace. Can you give me a hint? :) It already printed the thread names, so no need. Unfortunately, the clock threads were running instead of blocking etc (I suspected that this would be a case), so procstat cannot get the backtrace. Another option is to do a backtrace from ddb. I cannot get much information from the dtrace snippets you posted in parallel. I can only see that some threads used msleep (?) with timeout a lot, and something at the address 0xc67bbe90 also raised a head. Can you manually lookup nearby symbol for 0xc67bbe90 ? pgp91DUQuoccc.pgp Description: PGP signature
Re: firefox is stuck in getbuf()
On Tue, Jul 20, 2010 at 10:58:00AM +0800, David Xu wrote: 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 Can you, please, do the following: show the backtraces for the system processes, in particular, syncer, bufdaemon, softdepflush daemon, pagedaemon and vm ? for the stuck firefox thread, find the address of the buffer supplied as an argument to getdirtybuf, and print the *(struct buf *)addr ? This can be done on the live/stuck system using kgdb on /dev/mem. pgpCalVWrMNKp.pgp Description: PGP signature
i love freebsd
stupid censored internet. elite control thru open source development, or a censure of legit mail messages from a subscribed developer to control the development process ? please investigate if you believe in such thing as freedom of expression. Python.org web-sig admins also blocked my e-mail address yet i get replies from And who is subscribed to the list? I really don't understand. only wanted to give my 2 cents. kind regards/cordiales salutations, Etienne p -s : FreeBSD: The power to serve! [1]http://www.freebsd.org/ !!!Evil Spam that You Must Block!!! !!!Support Free and Open Alternatives to Restricted Python Development!!! Open alternatives for web development with Python: 1) notmm toolkit: a general-purpose and non-monolithic web toolkit for Django: [2]http://gthc.org/projects/notmm/ 2) blogengine: a Python blogging API with zero-sql in mind... [3]http://gthc.org/projects/blogengine/ Please donate anything you have if you like thoses apps despite being censored from the net!!! If we don't believe in freedom of expression for people we despise, we don't believe in it at all. -- Noam Chomsky -- Etienne Robillard Green Tea Hackers Club E-mail: [4]e...@gthcfoundation.org Work phone: 1 (514) 962-7703 Website:[5]https://gthc.org/ During times of universal deceit, telling the truth becomes a revolutionary act . -- George Orwell References 1. http://www.freebsd.org/ 2. http://gthc.org/projects/notmm/ 3. http://gthc.org/projects/blogengine/ 4. mailto:e...@gthcfoundation.org 5. https://gthc.org/ ___ 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 Hi, Michael, On 2010/07/20 02:51, Michael Gusek wrote: I don't have such a backup, only the whole disk for now. Everything else what can i do ? What if i initialize the gpt header: gpart create -s GPT ad0 ? Do i lost my data ? No it won't touch your data (assuming you were using GPT rather than a whole disk directly in the past) as long as you create/destroy GPT partition tables/scheme on the disk. Only the partition table itself gets changed which won't modify your on-disk data. 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) iQEcBAEBCAAGBQJMRdNRAAoJEATO+BI/yjfBkHEH/2io9HddIfAQ8bP1foNABqsU rI43+CjUeHlCNfXyxpfQC/u8d2UX/dsvpnoWLOTLNLaHcCALIeQ1YQW2D1Pn5zLg 15TLMJLmIkNzrwGZV1qHRuDGI0JqR4cco00A/9VqTNTESJ0Ys/nuOQz3lGDo4Df0 J2smW/q05w/+D3ZZABq4OxCoEImyWiOFvlcwky2f8vuvh5rWDSFZmuH4J0Oivj0g Ok3KOEfFYrEfWiQGDTp+1GTztXsOxo+LZ5zz1o7WsuLSoVIr/M0oTYNXiy28QxeA ovd/jDKqN/YTfbGNMBc/wUYBnVYr9nTlKU7Wo+zPhXrQWCBQzfwxT2/7FNHCEgw= =55Jr -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?
In the last episode (Jul 19), Doug Barton said:
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:
Okey dokey, here you go:
http://people.freebsd.org/~dougb/normal-dtrace.txt
http://people.freebsd.org/~dougb/bad-dtrace.txt
I don't see any real difference between those two runs, so maybe it's not a
callout eating your CPU. How about running this for a few seconds, which
will print all the stack traces seen during the sampling period:
dtrace -n 'profile:::profile-276hz { @pc[stack()]=count(); }'
On an otherwise idle system, you should see most of the counts in cpu_idle,
with the remainder clustered in whatever code is eating your CPU.
--
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
[INFO]: newer clang/LLVM in HEAD
hi, ed@ just committed an update of clang/LLVM to HEAD. This update has (at least) 3 bugs fixed that were reported from FreeBSD. these are: - annoying unknown pragma warning during make depend of kernel - DWARF fix that fixes dtrace (contributed by kan@) this requires libelf fix as well - clang (the driver) execing itself (the compiler) fix regardless of PATH Beside this, clang should compile C++ better than the previous snapshot. It should be faster as well. So far a few problems in clang/LLVM and FreeBSD were fixed but many other remains, what to do about it? Test clang with your code! just cd /usr/src/my/code/ CC=clang make clang can spot problems gcc cannot and it would be nice to have those fixed. it improves the code quality and takes at most a few minutes. if you encounter something that you think is a clang bug/problem/annoyance please let us know so we can get this fixed. thank you for your help! Roman Divacky pgp6NHtWVf2Uh.pgp Description: PGP signature
Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD
On Tue, Jul 20, 2010 at 8:25 AM, Marcelo/Porks marceloro...@gmail.com wrote: On Wed, Jul 14, 2010 at 3:38 PM, Roman Divacky rdiva...@freebsd.org wrote: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld Hi. Until here worked fine. I'm on an AMD64-Quadcore (Phenom x4). I did 'make buildworld'. Should I use something like 'make -j 8' for testing? The 'installworld' and kernel I will test thursday. Hi again. I did a 'svn up' on http://svn.freebsd.org/base/projects/clangbsd at 2010-07-20 21:30:00 UTC make -j 8 buildworld make installworld DESTDIR=/usr/clang cd sys/amd64/conf config GENERIC export CC=clang cd ../compile/GENERIC make make install KODIR=/boot/clang nextboot -k clang shutdown -r now and... BARAD-DUR% grep clang -A 3 -B 3 /var/log/messages Jul 20 20:52:51 BARAD-DUR su: porks to root on /dev/pts/5 Jul 20 20:52:58 BARAD-DUR shutdown: reboot by porks: Jul 20 20:53:02 BARAD-DUR syslogd: exiting on signal 15 Jul 20 20:54:21 BARAD-DUR syslogd: kernel boot file is /boot/clang/kernel Jul 20 20:54:21 BARAD-DUR kernel: Copyright (c) 1992-2010 The FreeBSD Project. Jul 20 20:54:21 BARAD-DUR kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 20 20:54:21 BARAD-DUR kernel: The Regents of the University of California. All rights reserved. BARAD-DUR% uname -a FreeBSD BARAD-DUR 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r210317: Tue Jul 20 20:40:06 BRT 2010 po...@barad-dur:/usr/src/sys/amd64/compile/GENERIC amd64 (I'm using GMT-3) Everything is running ok : ) -- Marcelo Rossi This e-mail is provided AS IS with no warranties, and confers no rights. I have nothing against God, I just hate His fan club ___ 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: firefox is stuck in getbuf()
Kostik Belousov wrote: Can you, please, do the following: show the backtraces for the system processes, in particular, syncer, bufdaemon, softdepflush daemon, pagedaemon and vm ? for the stuck firefox thread, find the address of the buffer supplied as an argument to getdirtybuf, and print the *(struct buf *)addr ? This can be done on the live/stuck system using kgdb on /dev/mem. Unfortunately, I can not always reproduce it. :-( ___ 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
