From owner-freebsd-stable@FreeBSD.ORG Sun Jun 15 11:46:33 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5834B1065671 for ; Sun, 15 Jun 2008 11:46:33 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mx.npubs.com (mail.wsfamily.com [209.66.100.224]) by mx1.freebsd.org (Postfix) with ESMTP id EC17C8FC0A for ; Sun, 15 Jun 2008 11:46:32 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mx.npubs.com (avhost [209.66.100.194]) by mx.npubs.com (Postfix) with ESMTP id BDB10F18514; Sun, 15 Jun 2008 11:23:19 +0000 (UTC) Received: from northstar-srv2 (unknown [172.27.2.11]) by mx.npubs.com (Postfix) with ESMTP id 146C1F18512; Sun, 15 Jun 2008 11:23:17 +0000 (UTC) From: Stef Walter User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------050805000904020105080208" Message-Id: <20080615112318.146C1F18512@mx.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Sun, 15 Jun 2008 11:23:19 +0000 (UTC) Cc: Subject: FreeBSD 6.3 deadlock (vm_map?) with DDB output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2008 11:46:33 -0000 This is a multi-part message in MIME format. --------------050805000904020105080208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've been trying to track down a deadlock on some newish production servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a specific (although mundane) hardware configuration, and each of several servers running this hardware deadlock about once per week. Although I suspect that this is not hardware related, from a (naive) perusal of the attached stack traces. Forgive me if my interpretation of this is all wrong, but I'm pretty desperate for help. So here's my basic understanding of the deadlock: These processes seem to be waiting on the page queue mutex: sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) httpd (in trap > trap_pfault > vm_fault) [g_up] (in g_vfs_done > bufdone) The page queue mutex is held by rsync process: rsync (in trap > trap_pfault > vm_fault > pmap_enter) Rsync kernel process (in pmap_enter) was interrupted while holding the page queue lock? Giant is enabled in loader.conf due to the needs of the pf firewall when dealing with user credentials lookups. I do not believe that Giant plays into this deadlock. Kernel config attached. Any and all help or info is welcome. Thanks in advance. Stef Walter --------------050805000904020105080208 Content-Type: text/plain; name="vm_map-deadlock-information.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vm_map-deadlock-information.txt" # -------------------------------------------------------------------- # FREEBSD BUILD FreeBSD m2.npubs.com 6.3-RELEASE-p2 FreeBSD 6.3-RELEASE-p2 #0: Tue Jun 10 02:06:41 UTC 2008 nate@m2.npubs.com:/usr/obj/usr/src/sys/RACK2DBG i386 # -------------------------------------------------------------------- # # -------------------------------------------------------------------- # PROCESS LIST db> ps pid ppid pgrp uid state wmesg wchan cmd 35638 35637 4448 80 LJ *vm page 0xc8d5f780 sendmail 35637 40546 4448 80 SJ wait 0xc9e79218 sh 35620 1801 1801 80 SJ lockf 0xcceb4d00 httpd 35593 1801 1801 80 SJ lockf 0xcce46900 httpd 35566 1801 1801 80 SJ kqread 0xc8f8e000 httpd 35438 15070 15063 70 SJ sbwait 0xd017220c postgres 35401 4527 4527 10219 SJ select 0xc080b7e4 cleanup 35337 4527 4527 10219 SJ select 0xc080b7e4 pickup 35144 4413 4413 80 SJ select 0xc080b7e4 httpd 34797 8611 8611 0 SJ select 0xc080b7e4 virtual 34784 8611 8611 125 SJ select 0xc080b7e4 smtpd 34781 8611 8611 125 SJ select 0xc080b7e4 smtp 34761 8611 8611 125 SJ select 0xc080b7e4 proxymap 34760 8611 8611 125 SJ select 0xc080b7e4 smtpd 34757 8611 8611 125 SJ select 0xc080b7e4 smtp 34750 8611 8611 125 SJ select 0xc080b7e4 cleanup 34087 6435 6435 125 SJ kqread 0xcae9f900 anvil 34075 6435 6435 125 SJ kqread 0xcfb5b600 smtpd 33801 15070 15063 70 SJ sbwait 0xd01a8bc8 postgres 33796 4527 4527 10219 SJ select 0xc080b7e4 bounce 33423 1801 1801 80 SJ select 0xc080b7e4 httpd 33417 15070 15063 70 SJ sbwait 0xd087f638 postgres 33392 1801 1801 80 SJ select 0xc080b7e4 httpd 33207 4527 4527 10219 SJ select 0xc080b7e4 flush 33200 4527 4527 10219 SJ select 0xc080b7e4 bounce 33125 4527 4527 10219 SJ kqread 0xcb2ff900 smtp 33118 4527 4527 10219 SJ select 0xc080b7e4 smtp 33113 4527 4527 10219 SJ select 0xc080b7e4 smtp 33108 4527 4527 10219 SJ select 0xc080b7e4 smtp 33101 4527 4527 10219 SJ select 0xc080b7e4 smtp 33094 4527 4527 10219 SJ select 0xc080b7e4 smtp 33090 4527 4527 10219 SJ select 0xc080b7e4 smtp 33070 33067 33067 0 LJ *Giant 0xcaaf97c0 lynx 33067 33066 33067 0 SsJ wait 0xc9fd9648 sh 33066 4564 4564 0 SJ piperd 0xd0ab7000 cron 33056 4527 4527 10219 SJ select 0xc080b7e4 smtp 33055 4527 4527 10219 SJ lockf 0xc992f480 bounce 32994 15070 15063 70 SJ sbwait 0xc9cdc370 postgres 32976 15070 15063 70 SJ sbwait 0xd0f8e4d4 postgres 32971 4527 4527 10219 SJ select 0xc080b7e4 proxymap 32970 4527 4527 10219 SJ select 0xc080b7e4 smtpd 32869 15070 15063 70 SJ sbwait 0xc8fcc370 postgres 32852 9298 9298 10102 SJ select 0xc080b7e4 cleanup 32837 32836 32836 0 S select 0xc080b7e4 rsync 32836 7802 32836 0 RLs rsync 32774 4527 4527 0 SJ select 0xc080b7e4 local 32754 1801 1801 80 LLJ *vm page 0xc8d5f780 httpd 32753 15070 15063 70 SJ sbwait 0xc9c8ce90 postgres 32747 15070 15063 70 SJ sbwait 0xd01a8370 postgres 32739 15070 15063 70 SJ sbwait 0xccdd3d2c postgres 32710 1 32710 0 Ss biord 0xdcb814d4 jail-measure 32633 1801 1801 80 SJ select 0xc080b7e4 httpd 32623 1801 1801 80 SJ select 0xc080b7e4 httpd 32599 1801 1801 80 SJ select 0xc080b7e4 httpd 32598 1801 1801 80 SJ select 0xc080b7e4 httpd 32597 1801 1801 80 SJ select 0xc080b7e4 httpd 32596 1801 1801 80 SJ lockf 0xcceb43c0 httpd 32595 1801 1801 80 SJ select 0xc080b7e4 httpd 32301 4413 4413 80 SJ lockf 0xcce44680 httpd 32255 4413 4413 80 SJ lockf 0xcce44340 httpd 32206 15070 15063 70 SJ sbwait 0xc9cdf638 postgres 32163 1801 1801 80 SJ select 0xc080b7e4 httpd 32147 4527 4527 10219 SJ select 0xc080b7e4 trivial-rewrite 31910 8611 8611 125 SJ select 0xc080b7e4 smtpd 31740 8611 8611 125 SJ select 0xc080b7e4 trivial-rewrite 30378 4413 4413 80 SJ lockf 0xcd551b40 httpd 30355 4413 4413 80 SJ lockf 0xcceb41c0 httpd 29801 4413 4413 80 SJ lockf 0xcb331340 httpd 29375 9298 9298 10102 SJ select 0xc080b7e4 pickup 28283 4413 4413 80 SJ lockf 0xcb3317c0 httpd 28247 4413 4413 80 SJ kqread 0xcb092200 httpd 28113 9298 9298 10102 SJ select 0xc080b7e4 smtpd 28067 4413 4413 80 SJ lockf 0xd0ff87c0 httpd 26846 4413 4413 80 SJ select 0xc080b7e4 httpd 26581 9298 9298 10102 SJ select 0xc080b7e4 smtpd 26529 26528 8216 125 SJ select 0xc080b7e4 imapd 26528 8216 8216 0 SJ select 0xc080b7e4 couriertls 26424 4413 4413 80 SJ lockf 0xc92fe900 httpd 23902 15070 15063 70 SJ sbwait 0xccdcb0a8 postgres 23891 1801 1801 80 SJ select 0xc080b7e4 httpd 23721 8611 8611 125 SJ select 0xc080b7e4 pickup 22472 6435 6435 125 SJ kqread 0xcfb0cb00 pickup 21951 8958 8958 125 SJ kqread 0xcfb5b200 pickup 19724 3711 3711 125 SJ kqread 0xcfbee800 pickup 17335 9298 9298 10102 SJ select 0xc080b7e4 proxymap 17334 9298 9298 10102 SJ select 0xc080b7e4 trivial-rewrite 11733 40103 40103 80 SJ accept 0xd087d03a httpd 11732 40103 40103 80 SJ accept 0xd087d03a httpd 11731 40103 40103 80 SJ accept 0xd087d03a httpd 11730 40103 40103 80 SJ accept 0xd087d03a httpd 11728 40103 40103 80 SJ accept 0xd087d03a httpd 11727 40103 40103 80 SJ accept 0xd087d03a httpd 11726 40103 40103 80 SJ accept 0xd087d03a httpd 2181 1 2181 181 SsJ (threaded) nagios 100858 S select 0xc080b7e4 nagios 100434 S nanslp 0xc07be46c nagios 87785 7530 7530 80 SJ accept 0xca004b5a httpd 61004 8697 8697 80 SJ accept 0xca96519e httpd 56340 1917 1917 80 SJ lockf 0xcb3311c0 httpd 53973 8611 8611 125 SJ select 0xc080b7e4 anvil 52531 17166 52531 0 R+J CPU 3 ee 45059 7530 7530 80 SJ accept 0xca004b5a httpd 41862 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41181 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41180 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41179 4448 4448 80 SJ accept 0xc9c7d5ca httpd 41178 7530 7530 80 SJ accept 0xca004b5a httpd 41175 4448 4448 80 SJ accept 0xc9c7d5ca httpd 40748 9036 9036 80 SJ accept 0xca965466 httpd 40742 9036 9036 80 SJ accept 0xca965466 httpd 40739 9036 9036 80 SJ accept 0xca965466 httpd 40726 9036 9036 80 SJ accept 0xca965466 httpd 40546 4448 4448 80 SJ wait 0xd024c000 httpd 40444 1917 1917 80 SJ lockf 0xcaa00580 httpd 40443 1917 1917 80 SJ kqread 0xcf271100 httpd 40442 1917 1917 80 SJ lockf 0xcce44500 httpd 40441 1917 1917 80 SJ lockf 0xcd551480 httpd 40440 1917 1917 80 SJ lockf 0xc8dba6c0 httpd 40428 8697 8697 80 SJ accept 0xca96519e httpd 40427 8697 8697 80 SJ accept 0xca96519e httpd 40426 8697 8697 80 SJ accept 0xca96519e httpd 40425 8697 8697 80 SJ accept 0xca96519e httpd 40424 8697 8697 80 SJ accept 0xca96519e httpd 40384 9036 9036 80 SJ accept 0xca965466 httpd 40378 7530 7530 80 SJ accept 0xca004b5a httpd 40377 7530 7530 80 SJ accept 0xca004b5a httpd 40376 7530 7530 80 SJ accept 0xca004b5a httpd 40375 7530 7530 80 SJ accept 0xca004b5a httpd 40374 7530 7530 80 SJ accept 0xca004b5a httpd 40372 9036 9036 80 SJ accept 0xca965466 httpd 40371 9036 9036 80 SJ accept 0xca965466 httpd 40370 9036 9036 80 SJ accept 0xca965466 httpd 40369 9036 9036 80 SJ accept 0xca965466 httpd 40368 9036 9036 80 SJ accept 0xca965466 httpd 40334 40332 4448 0 SJ piperd 0xcca2e198 cronolog 40333 4448 4448 80 SJ accept 0xc9c7d5ca httpd 40332 4448 4448 0 SJ wait 0xcb2cf218 sh 40310 40309 40309 0 SJ piperd 0xc9257cc0 sockin 40309 8742 40309 0 SsJ wait 0xd0171430 sh 40294 40291 40291 0 SJ piperd 0xc8fe7cc0 sockin 40291 6919 40291 0 SsJ wait 0xcdccba78 sh 36263 1 36263 0 SsJ (threaded) rrdbotd 100452 S kserel 0xce155d54 rrdbotd 100188 S select 0xc080b7e4 rrdbotd 100984 S kserel 0xce155d54 rrdbotd 100311 S kserel 0xce155d54 rrdbotd 100271 S select 0xc080b7e4 rrdbotd 100268 S kserel 0xce155d54 rrdbotd 100624 S ksesigwa 0xcaa27780 rrdbotd 17166 17165 17166 0 S+J wait 0xc994d000 bash 17165 17155 17152 0 S+J wait 0xd0d11218 su 17155 17152 17152 0 S+ wait 0xc9ec0a78 sh 17152 1980 17152 0 S+ wait 0xc8a42648 sh 15079 15078 15063 70 S+J select 0xc080b7e4 postgres 15078 15070 15063 70 S+J select 0xc080b7e4 postgres 15077 15070 15063 70 S+J select 0xc080b7e4 postgres 15074 15070 15063 70 S+J select 0xc080b7e4 postgres 15070 1 15063 70 S+J select 0xc080b7e4 postgres 1980 1 1980 0 S+ wait 0xcaa27430 bash 31591 2354 2354 80 SJ lockf 0xc8c8ee80 httpd 31578 2354 2354 80 SJ lockf 0xc8c8e640 httpd 40103 1 40103 0 SsJ nanslp 0xc07be46c httpd 38293 1 38293 0 SsJ nanslp 0xc07be46c cron 38286 1 38286 0 SsJ select 0xc080b7e4 sshd 38224 1 38224 0 SsJ select 0xc080b7e4 syslogd 91887 1 91886 0 SJ select 0xc080b7e4 ruby18 91876 1 91875 0 SJ select 0xc080b7e4 ruby18 61971 61968 8645 65534 SJ piperd 0xcd2d3000 cat 61970 61967 8645 65534 SJ piperd 0xcca51cc0 cat 61968 1 8645 65534 SJ wait 0xce938c90 sh 61967 1 8645 65534 SJ wait 0xc9d2c860 sh 64190 2354 2354 80 SJ kqread 0xcbe8e500 httpd 19433 19430 8645 65534 SJ piperd 0xcffe74c8 cat 19432 19431 8645 65534 SJ piperd 0xcad1d000 cat 19431 1 8645 65534 SJ wait 0xca5b1860 sh 19430 1 8645 65534 SJ wait 0xd0195430 sh 72427 3606 3606 80 SJ select 0xc080b7e4 httpd 95713 3606 3606 80 SJ lockf 0xcd551800 httpd 79740 3606 3606 80 SJ lockf 0xc8c8e7c0 httpd 36833 1 36833 0 SsJ select 0xc080b7e4 ruby 15574 3606 3606 80 SJ lockf 0xcaa00680 httpd 13381 6677 6677 80 SJ accept 0xc9df4466 httpd 11234 9367 9367 80 SJ lockf 0xc8d16a80 httpd 10994 9367 9367 80 SJ lockf 0xd00c2900 httpd 7909 6752 6677 80 SJ select 0xc080b7e4 ruby 73129 6677 6677 80 SJ accept 0xc9df4466 httpd 58056 6752 6677 80 SJ select 0xc080b7e4 ruby 41698 3606 3606 80 SJ lockf 0xc8a53740 httpd 41694 8569 8569 80 SJ accept 0xca965b5a httpd 37070 3266 3266 80 SJ kqread 0xcadb3700 httpd 37069 3266 3266 80 SJ lockf 0xcb7f4280 httpd 37068 3266 3266 80 SJ lockf 0xcec83700 httpd 30486 9367 9367 80 SJ lockf 0xd0ff8800 httpd 30262 9367 9367 80 SJ lockf 0xca6e3d40 httpd 11692 8743 8743 80 SJ lockf 0xcb7f4b80 httpd 11690 8743 8743 80 SJ select 0xc080b7e4 httpd 11599 8743 8743 80 SJ lockf 0xcb331bc0 httpd 11214 8743 8743 80 SJ lockf 0xcb0df340 httpd 11169 8743 8743 80 SJ lockf 0xd0043c00 httpd 9660 6677 6677 80 SJ accept 0xc9df4466 httpd 9659 6752 6677 80 SJ select 0xc080b7e4 ruby 9445 3266 3266 80 SJ lockf 0xcb0df900 httpd 9407 8611 8611 125 SJ select 0xc080b7e4 tlsmgr 9404 2354 2354 80 SJ lockf 0xc95798c0 httpd 9401 9367 9367 80 SJ lockf 0xcb7f4ac0 httpd 9400 9367 9367 80 SJ lockf 0xc95628c0 httpd 9399 9367 9367 80 SJ lockf 0xd05bd080 httpd 9398 9367 9367 80 SJ kqread 0xca619400 httpd 9397 9367 9367 80 SJ lockf 0xc9b5b440 httpd 9382 1 9382 0 SsJ nanslp 0xc07be46c cron 9375 1 9375 0 SsJ select 0xc080b7e4 sshd 9367 1 9367 0 SsJ nanslp 0xc07be46c httpd 9359 3266 3266 80 SJ lockf 0xc957a0c0 httpd 9334 9333 8760 70 SJ select 0xc080b7e4 postgres 9333 8760 8760 70 SJ select 0xc080b7e4 postgres 9332 8760 8760 70 SJ select 0xc080b7e4 postgres 9328 1 9328 0 SsJ nanslp 0xc07be46c cron 9320 1 9320 0 SsJ select 0xc080b7e4 inetd 9315 1 9315 0 SsJ accept 0xcaec119e saslauthd1 9304 9298 9298 10102 SJ select 0xc080b7e4 qmgr 9298 1 9298 0 SsJ select 0xc080b7e4 master 9268 2354 2354 80 SJ lockf 0xcec83ac0 httpd 9241 1 9241 0 SsJ select 0xc080b7e4 bsnmpd 9214 1 9214 0 SsJ nanslp 0xc07be46c cron 9202 1 9202 0 SsJ select 0xc080b7e4 sshd 9139 9107 9090 88 SJ (threaded) mysqld 100427 S kserel 0xc9a0b4b4 mysqld 100308 S kserel 0xc9a0b4b4 mysqld 100276 S kserel 0xc9a0b4b4 mysqld 100582 S kserel 0xc9a0b4b4 mysqld 100572 S select 0xc080b7e4 mysqld 100568 S kserel 0xcadf8394 mysqld 100571 S sigwait 0xeca04c14 mysqld 100564 S ksesigwa 0xc9b7f780 mysqld 9107 1 9090 88 SJ wait 0xcac42a78 sh 9093 1 9093 225 SsJ select 0xc080b7e4 perl5.8.8 9068 1 9068 0 SsJ nanslp 0xc07be46c cron 9058 1 9058 0 SsJ select 0xc080b7e4 sshd 9042 1 41 0 SJ piperd 0xcad1dcc0 logger 9041 1 41 0 SJ fifoor 0xca9e6c58 tail 9036 1 9036 0 SsJ select 0xc080b7e4 httpd 9035 8996 8980 88 SJ (threaded) mysqld 100855 S kserel 0xc8cee394 mysqld 101020 S sbwait 0xc950fd2c mysqld 100994 S select 0xc080b7e4 mysqld 101012 S sbwait 0xcce6320c mysqld 101021 S sbwait 0xd08750a8 mysqld 100393 S kserel 0xc8cee394 mysqld 100999 S sbwait 0xd0eab370 mysqld 101189 S sbwait 0xd0aa1bc8 mysqld 100578 S kserel 0xc8cee394 mysqld 101017 S kserel 0xc8cee394 mysqld 100573 S kserel 0xcadf82d4 mysqld 100558 S sigwait 0xec83bc14 mysqld 100555 S ksesigwa 0xc97f4780 mysqld 8996 1 8980 88 SJ wait 0xca0c4860 sh 8963 8958 8958 125 SJ kqread 0xcabf6400 qmgr 8958 1 8958 0 SsJ kqread 0xc8d71500 master 8893 1 8893 0 SsJ nanslp 0xc07be46c cron 8874 1 8874 0 SsJ select 0xc080b7e4 sshd 8844 1 8844 0 SsJ select 0xc080b7e4 sshd 8811 1 8811 0 SsJ nanslp 0xc07be46c cron 8804 8569 8569 80 SJ accept 0xca965b5a httpd 8802 8569 8569 80 SJ accept 0xca965b5a httpd 8801 8569 8569 80 SJ accept 0xca965b5a httpd 8799 8569 8569 80 SJ accept 0xca965b5a httpd 8798 1 8798 0 SsJ select 0xc080b7e4 sshd 8797 8569 8569 80 SJ accept 0xca965b5a httpd 8791 1 8791 0 SsJ select 0xc080b7e4 proftpd 8769 8743 8743 80 SJ lockf 0xcd6aeb00 httpd 8768 8743 8743 80 SJ lockf 0xcb7f4880 httpd 8767 8743 8743 80 SJ lockf 0xcb06a580 httpd 8766 8743 8743 80 SJ lockf 0xcb0df140 httpd 8765 8743 8743 80 SJ lockf 0xc8fb1700 httpd 8760 1 8760 70 SsJ select 0xc080b7e4 postgres 8743 1 8743 0 SsJ select 0xc080b7e4 httpd 8742 1 8742 0 SsJ select 0xc080b7e4 syslogd 8715 1 8715 0 SsJ nanslp 0xc07be46c cron 8706 1 8706 0 SsJ select 0xc080b7e4 sshd 8697 1 8697 0 SsJ nanslp 0xc07be46c httpd 8645 1 8645 65534 SsJ (threaded) proxsmtpd 100309 S kserel 0xca663154 proxsmtpd 100975 S kserel 0xca663154 proxsmtpd 101018 S kserel 0xca663154 proxsmtpd 100649 S kserel 0xca663154 proxsmtpd 101013 S accept 0xca9655ca proxsmtpd 100581 S ksesigwa 0xcaaf7138 proxsmtpd 8617 8611 8611 125 SJ select 0xc080b7e4 qmgr 8611 1 8611 0 SsJ select 0xc080b7e4 master 8569 1 8569 0 SsJ nanslp 0xc07be46c httpd 8496 1 8496 0 SsJ select 0xc080b7e4 syslogd 8437 1 8437 0 SsJ select 0xc080b7e4 syslogd 8300 8170 8169 0 SJ select 0xc080b7e4 authdaemond 8299 8170 8169 0 SJ select 0xc080b7e4 authdaemond 8298 8170 8169 0 SJ select 0xc080b7e4 authdaemond 8295 1 8295 0 SsJ select 0xc080b7e4 syslogd 8272 8271 8272 0 SJ select 0xc080b7e4 couriertcpd 8271 1 8271 0 SJ piperd 0xca366b28 courierlogger 8253 8252 8253 0 SJ select 0xc080b7e4 couriertcpd 8252 1 8252 0 SJ piperd 0xc904f990 courierlogger 8229 8228 8229 0 SJ select 0xc080b7e4 couriertcpd 8228 1 8228 0 SJ piperd 0xc9e1cb28 courierlogger 8216 8215 8216 0 SJ select 0xc080b7e4 couriertcpd 8215 1 8215 0 SJ piperd 0xca610330 courierlogger 8170 8169 8169 0 SJ select 0xc080b7e4 authdaemond 8169 1 8169 0 SJ piperd 0xc9dc1cc0 courierlogger 8121 1 8121 0 SsJ nanslp 0xc07be46c cron 8105 1 8105 0 SsJ select 0xc080b7e4 sshd 8082 1 8082 0 SsJ select 0xc080b7e4 syslogd 8081 1 8081 0 SsJ select 0xc080b7e4 syslogd 7979 1 7979 0 SsJ nanslp 0xc07be46c cron 7972 1 7972 0 SsJ select 0xc080b7e4 sshd 7848 1 7848 0 Ss+ ttyin 0xc8a6e410 getty 7847 1 7847 0 Ss+ ttyin 0xc8a74810 getty 7846 1 7846 0 Ss+ ttyin 0xc8a73010 getty 7845 1 7845 0 Ss+ ttyin 0xc8a73410 getty 7844 1 7844 0 Ss+ ttyin 0xc8a70c10 getty 7843 1 7843 0 Ss+ ttyin 0xc8a73c10 getty 7842 1 7842 0 Ss+ ttyin 0xc8a76010 getty 7841 1 7841 0 Ss+ ttyin 0xc8a75010 getty 7840 1 7840 0 Ss+ ttyin 0xc8a74410 getty 7829 1 7829 0 Ls *vm page 0xc8d5f780 bsnmpd 7802 1 7802 0 Ss select 0xc080b7e4 inetd 7695 1 7695 0 SsJ select 0xc080b7e4 syslogd 7530 1 7530 0 SsJ nanslp 0xc07be46c httpd 7302 1 7302 0 SsJ select 0xc080b7e4 bsnmpd 6919 1 6919 0 SsJ select 0xc080b7e4 syslogd 6754 6677 6677 80 SJ accept 0xc9df4466 httpd 6753 6677 6677 80 SJ accept 0xc9df4466 httpd 6752 6677 6677 80 SJ select 0xc080b7e4 httpd 6694 1 6694 0 SsJ nanslp 0xc07be46c cron 6687 1 6687 0 SsJ select 0xc080b7e4 sshd 6677 1 6677 0 SsJ nanslp 0xc07be46c httpd 6639 6578 6577 88 S+J piperd 0xca3517f8 logger 6638 6578 6577 88 S+J (threaded) mysqld 100566 S kserel 0xc8e765d4 mysqld 100383 S kserel 0xc8e765d4 mysqld 100988 S kserel 0xc8e765d4 mysqld 101056 S kserel 0xc8e765d4 mysqld 101005 S select 0xc080b7e4 mysqld 100392 S sbwait 0xcceda370 mysqld 100387 S sigwait 0xec6adc14 mysqld 100381 S ksesigwa 0xc9a09568 mysqld 6578 1 6577 88 S+J wait 0xca0c6430 sh 6568 6567 6568 0 S+J select 0xc080b7e4 couriertcpd 6567 1 6567 0 S+J piperd 0xca365660 courierlogger 6509 6508 6509 0 S+J select 0xc080b7e4 couriertcpd 6508 1 6508 0 S+J piperd 0xc99fe990 courierlogger 6505 1 6505 0 SsJ select 0xc080b7e4 syslogd 6454 6435 6435 125 SJ kqread 0xca2a1400 qmgr 6435 1 6435 0 SsJ kqread 0xca122500 master 5653 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5652 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5651 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5650 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5649 5529 5521 0 S+J select 0xc080b7e4 authdaemond 5529 5521 5521 0 S+J select 0xc080b7e4 authdaemond 5521 1 5521 0 S+J piperd 0xc8ee7cc0 courierlogger 5337 1 5337 0 SsJ select 0xc080b7e4 syslogd 5166 1 5166 0 SsJ nanslp 0xc07be46c cron 5153 1 5153 0 SsJ select 0xc080b7e4 sshd 5117 1 5117 0 SsJ (threaded) httpauthd 100563 S kserel 0xc8cee2d4 httpauthd 100652 S kserel 0xc8cee2d4 httpauthd 100468 S kserel 0xc8cee2d4 httpauthd 100444 S kserel 0xc8cee2d4 httpauthd 100183 S sbwait 0xc9df4bc8 httpauthd 100277 S sbwait 0xcb305370 httpauthd 100382 S sbwait 0xcafa0638 httpauthd 100314 S sbwait 0xcb1054d4 httpauthd 100499 S sbwait 0xcae5aa64 httpauthd 100223 S sbwait 0xcae4d4d4 httpauthd 100310 S sbwait 0xcb0bfd2c httpauthd 100973 S sbwait 0xcebd34d4 httpauthd 100388 S sbwait 0xcae4d20c httpauthd 100646 S sbwait 0xd0aa0900 httpauthd 100658 S sbwait 0xc8d3779c httpauthd 100471 S sbwait 0xcae4ca64 httpauthd 100985 S sbwait 0xc9ce420c httpauthd 100175 S sbwait 0xd0cdae90 httpauthd 100317 S sbwait 0xcebce4d4 httpauthd 100580 S sbwait 0xcb105638 httpauthd 100587 S accept 0xc9e0319e httpauthd 100272 S sbwait 0xcb0aa0a8 httpauthd 100556 S sbwait 0xcae59e90 httpauthd 100562 S sbwait 0xcb154e90 httpauthd 100306 S sbwait 0xd0173e90 httpauthd 100221 S sbwait 0xcebc4370 httpauthd 100448 S sbwait 0xd01744d4 httpauthd 100380 S sbwait 0xca004638 httpauthd 100318 S sbwait 0xc9c7da64 httpauthd 100560 S sbwait 0xcaec0370 httpauthd 100205 S sbwait 0xc9dd9e90 httpauthd 100394 S sbwait 0xcb0aaa64 httpauthd 100251 S sbwait 0xcabc120c httpauthd 101072 S sbwait 0xd07560a8 httpauthd 100575 S sbwait 0xccdd7bc8 httpauthd 101207 S sbwait 0xcfd28370 httpauthd 101211 S sbwait 0xd087c370 httpauthd 100469 S sbwait 0xd0177d2c httpauthd 101004 S sbwait 0xc8fa0638 httpauthd 100253 S sbwait 0xc9e04d2c httpauthd 100585 S sbwait 0xca265a64 httpauthd 100270 S sbwait 0xcaf8f20c httpauthd 100313 S sbwait 0xd01780a8 httpauthd 100673 S sbwait 0xcaf8ce90 httpauthd 100651 S sbwait 0xcae6f638 httpauthd 100324 S sbwait 0xcfd27370 httpauthd 100259 S sbwait 0xc9ce0638 httpauthd 100391 S sbwait 0xc9dd9370 httpauthd 100321 S sbwait 0xd01a8900 httpauthd 100476 S sbwait 0xcafa0a64 httpauthd 101190 S sbwait 0xcaf8fbc8 httpauthd 100316 S sbwait 0xc9ce379c httpauthd 100657 S sbwait 0xcb090638 httpauthd 100594 S sbwait 0xd01720a8 httpauthd 100559 S sbwait 0xd01a9638 httpauthd 100583 S sbwait 0xcaf8b900 httpauthd 100574 S sbwait 0xcb154a64 httpauthd 100364 S sbwait 0xc9cd8bc8 httpauthd 100567 S sbwait 0xcf485e90 httpauthd 100971 S sbwait 0xca254900 httpauthd 101016 S sbwait 0xccdf2d2c httpauthd 100977 S sbwait 0xcb0aa638 httpauthd 100447 S sbwait 0xc9cd9d2c httpauthd 100856 S sbwait 0xd0176d2c httpauthd 100586 S sbwait 0xcebcfe90 httpauthd 100249 S sbwait 0xc8d3b370 httpauthd 100972 S sbwait 0xc8d3ba64 httpauthd 100450 S sbwait 0xcaa86370 httpauthd 100384 S sbwait 0xcebcebc8 httpauthd 100981 S sbwait 0xccdcba64 httpauthd 100591 S sbwait 0xd01760a8 httpauthd 100998 S sbwait 0xccdf279c httpauthd 100320 S sbwait 0xcab88d2c httpauthd 101031 S sbwait 0xcdb35a64 httpauthd 100349 S sbwait 0xcf4a7bc8 httpauthd 100589 S sbwait 0xcaf8b79c httpauthd 100386 S sbwait 0xd0cd60a8 httpauthd 100979 S sbwait 0xcae4de90 httpauthd 100590 S sbwait 0xccdcbd2c httpauthd 100569 S sbwait 0xcacd2bc8 httpauthd 101008 S sbwait 0xcebd3638 httpauthd 100672 S sbwait 0xcb153900 httpauthd 100557 S sbwait 0xcb153a64 httpauthd 100541 S sbwait 0xcae59bc8 httpauthd 100389 S sbwait 0xca265900 httpauthd 100415 S sbwait 0xcaf8e0a8 httpauthd 100577 S sbwait 0xce18cbc8 httpauthd 101025 S sbwait 0xcf4a7d2c httpauthd 100561 S sbwait 0xcebd0d2c httpauthd 100385 S sbwait 0xd01774d4 httpauthd 100256 S sbwait 0xcceb74d4 httpauthd 100284 S sbwait 0xcaf8cd2c httpauthd 101040 S sbwait 0xc9cdcbc8 httpauthd 100319 S sbwait 0xd0172d2c httpauthd 100274 S sbwait 0xcb0bfe90 httpauthd 100269 S sbwait 0xd0cd84d4 httpauthd 101011 S sbwait 0xcb3294d4 httpauthd 101069 S sbwait 0xd0cdb79c httpauthd 100449 S sbwait 0xcce6379c httpauthd 100970 S sbwait 0xc8f75a64 httpauthd 101002 S sbwait 0xcb2de0a8 httpauthd 100983 S sbwait 0xc8d3b638 httpauthd 100312 S ksesigwa 0xc97f4bb0 httpauthd 5000 1 5000 389 SsJ (threaded) slapd 100993 S kserel 0xc97f6c34 slapd 100445 S kserel 0xc97f6c34 slapd 100694 S kserel 0xc97f6c34 slapd 100247 S kserel 0xc97f6c34 slapd 100857 S select 0xc080b7e4 slapd 100305 S ksesigwa 0xc9e24138 slapd 4867 1 4867 0 SsJ select 0xc080b7e4 inetd 4847 1 4847 0 SsJ accept 0xc9c7de22 svnserve 4835 1 4834 0 SJ select 0xc080b7e4 ruby18 4796 1 4796 0 SsJ select 0xc080b7e4 syslogd 4712 1 4711 0 SJ select 0xc080b7e4 ruby18 4707 1 4706 0 SJ select 0xc080b7e4 ruby18 4701 1 4700 0 SJ select 0xc080b7e4 ruby18 4648 1 4647 0 SJ select 0xc080b7e4 ruby18 4564 1 4564 0 SsJ nanslp 0xc07be46c cron 4555 1 4555 0 SsJ select 0xc080b7e4 inetd 4550 1 4550 0 SsJ accept 0xc9c7dcbe saslauthd1 4542 1 4541 0 SJ select 0xc080b7e4 ruby18 4535 4527 4527 10219 SJ select 0xc080b7e4 qmgr 4527 1 4527 0 SsJ select 0xc080b7e4 master 4454 1 41 0 S+J piperd 0xc8ee07f8 logger 4453 1 41 0 S+J fifoor 0xc8d04a38 tail 4448 1 4448 0 SsJ select 0xc080b7e4 httpd 4428 1 4428 0 SsJ nanslp 0xc07be46c cron 4421 1 4421 0 SsJ select 0xc080b7e4 sshd 4413 1 4413 0 SsJ nanslp 0xc07be46c httpd 4396 1 4396 0 SsJ select 0xc080b7e4 sshd 4335 1 4335 0 SsJ select 0xc080b7e4 syslogd 4174 4106 4105 88 S+J (threaded) mysqld 100565 S kserel 0xc9a0b394 mysqld 100519 S kserel 0xc9a0b394 mysqld 100976 S kserel 0xc9a0b394 mysqld 100980 S kserel 0xc9a0b394 mysqld 100859 S select 0xc080b7e4 mysqld 101014 S sbwait 0xc950fe90 mysqld 100991 S sbwait 0xd0cd7638 mysqld 101003 S sbwait 0xcdb354d4 mysqld 101001 S sbwait 0xd074820c mysqld 100588 S sbwait 0xccdcb370 mysqld 100454 S sbwait 0xcaf8c79c mysqld 100273 S sigwait 0xec480c14 mysqld 100267 S ksesigwa 0xc9b7fdc8 mysqld 4106 1 4105 88 S+J wait 0xc97f4218 sh 4033 1 4033 0 SsJ select 0xc080b7e4 syslogd 3879 1 3879 0 SsJ select 0xc080b7e4 inetd 3865 1 3865 0 SsJ nanslp 0xc07be46c cron 3858 1 3858 0 SsJ select 0xc080b7e4 sshd 3857 3820 3817 88 S+J (threaded) mysqld 100252 S kserel 0xc8cee4b4 mysqld 100365 S kserel 0xc8cee4b4 mysqld 100245 S select 0xc080b7e4 mysqld 100323 S kserel 0xc8cee4b4 mysqld 100650 S kserel 0xc8cee4b4 mysqld 100250 S kserel 0xc9a0b634 mysqld 100244 S sigwait 0xe9ef5c14 mysqld 100242 S ksesigwa 0xc97f4138 mysqld 3820 1 3817 88 S+J wait 0xc994d430 sh 3818 3606 3606 80 SJ lockf 0xc97e7180 httpd 3816 3606 3606 80 SJ lockf 0xccecb780 httpd 3815 3606 3606 80 SJ lockf 0xc9579c80 httpd 3814 3606 3606 80 SJ lockf 0xcb06a880 httpd 3813 3606 3606 80 SJ lockf 0xc9ec7900 httpd 3729 3711 3711 125 SJ kqread 0xc9920300 qmgr 3711 1 3711 0 SsJ kqread 0xc9914200 master 3613 1 3613 0 SsJ select 0xc080b7e4 proftpd 3606 1 3606 0 SsJ select 0xc080b7e4 httpd 3472 1 3472 0 SsJ select 0xc080b7e4 syslogd 3436 3266 3266 80 SJ lockf 0xd00437c0 httpd 3435 3266 3266 80 SJ lockf 0xcec83d80 httpd 3434 3266 3266 80 SJ lockf 0xc8dba200 httpd 3433 3266 3266 80 SJ lockf 0xd0210540 httpd 3432 3266 3266 80 SJ lockf 0xc8fd8b80 httpd 3398 1 3398 0 SsJ select 0xc080b7e4 inetd 3379 1 3379 0 SsJ nanslp 0xc07be46c cron 3344 1 3344 0 SsJ select 0xc080b7e4 sshd 3288 3279 3266 0 SJ piperd 0xc927ab28 cronolog 3287 3276 3266 0 SJ piperd 0xc8d54330 cronolog 3284 3275 3266 0 SJ piperd 0xc927a990 cronolog 3283 3272 3266 0 SJ piperd 0xc8d55330 cronolog 3279 3266 3266 0 SJ wait 0xc90c7430 sh 3276 3266 3266 0 SJ wait 0xc95a5c90 sh 3275 3266 3266 0 SJ wait 0xc97ef000 sh 3272 3266 3266 0 SJ wait 0xc97ef218 sh 3266 1 3266 0 SsJ nanslp 0xc07be46c httpd 3128 3073 3072 88 S+J (threaded) mysqld 100198 S kserel 0xc8950e74 mysqld 100204 S kserel 0xc8950e74 mysqld 100206 S kserel 0xc8950e74 mysqld 100202 S select 0xc080b7e4 mysqld 100203 S kserel 0xc8950e74 mysqld 100200 S sigwait 0xec3dac14 mysqld 100197 S ksesigwa 0xc8cc0780 mysqld 3073 1 3072 88 S+J wait 0xc90c6a78 sh 3022 1 3022 0 SsJ select 0xc080b7e4 syslogd 2545 2354 2354 80 SJ lockf 0xc8c8e700 httpd 2542 2354 2354 80 SJ lockf 0xc8c8e340 httpd 2541 2354 2354 80 SJ lockf 0xccebf4c0 httpd 2539 2354 2354 80 SJ lockf 0xc8c8e740 httpd 2538 2354 2354 80 SJ lockf 0xc8c8eb40 httpd 2369 1 2369 0 SsJ nanslp 0xc07be46c cron 2362 1 2362 0 SsJ select 0xc080b7e4 sshd 2354 1 2354 0 SsJ nanslp 0xc07be46c httpd 2259 2258 2255 70 SJ select 0xc080b7e4 postgres 2258 2255 2255 70 SJ select 0xc080b7e4 postgres 2257 2255 2255 70 SJ select 0xc080b7e4 postgres 2255 1 2255 70 SsJ select 0xc080b7e4 postgres 2199 1 2199 0 SsJ select 0xc080b7e4 syslogd 1917 1 1917 0 SsJ nanslp 0xc07be46c httpd 1892 1 1892 0 SsJ nanslp 0xc07be46c cron 1885 1 1885 0 SsJ select 0xc080b7e4 sshd 1842 1 1842 0 SsJ nanslp 0xc07be46c cron 1833 1 1833 0 SsJ select 0xc080b7e4 sshd 1801 1 1801 0 SsJ nanslp 0xc07be46c httpd 1800 1 1800 0 SsJ select 0xc080b7e4 syslogd 1476 1 1476 0 SsJ select 0xc080b7e4 syslogd 1161 1 41 0 S+J piperd 0xc9257660 logger 1160 1 41 0 S+J fifoor 0xc8c9ca58 tail 1152 1 1152 0 SsJ nanslp 0xc07be46c cron 1090 1 1090 0 SsJ select 0xc080b7e4 syslogd 680 1 680 0 Ss nanslp 0xc07be46c cron 673 1 673 0 Ss select 0xc080b7e4 sshd 644 1 643 0 S nanslp 0xc07be46c python 613 1 613 0 Ss select 0xc080b7e4 ntpd 524 1 524 0 Ss select 0xc080b7e4 syslogd 469 1 469 0 Ss select 0xc080b7e4 devd 40 0 0 0 SL - 0xec126d04 [schedcpu] 39 0 0 0 SL sdflush 0xc081caf4 [softdepflush] 38 0 0 0 SL syncer 0xc07be1dc [syncer] 37 0 0 0 SL vlruwt 0xc8a58000 [vnlru] 36 0 0 0 SL psleep 0xc080bd60 [bufdaemon] 35 0 0 0 SL pgzero 0xc081dac4 [pagezero] 34 0 0 0 SL psleep 0xc081d5cc [vmdaemon] 33 0 0 0 SL psleep 0xc081d588 [pagedaemon] 32 0 0 0 WL [swi0: sio] 31 0 0 0 WL [irq1: atkbd0] 30 0 0 0 WL [irq19: atapci1] 29 0 0 0 WL [irq15: ata1] 28 0 0 0 WL [irq14: ata0] 27 0 0 0 LL *Giant 0xcaaf97c0 [irq17: em1] 26 0 0 0 LL *Giant 0xcaaf97c0 [irq16: em0] 25 0 0 0 WL [irq9: acpi0] 24 0 0 0 SL - 0xc89a3c80 [acpi_task_2] 23 0 0 0 SL - 0xc89a3c80 [acpi_task_1] 22 0 0 0 SL - 0xc89a3c80 [acpi_task_0] 21 0 0 0 WL [swi2: cambio] 9 0 0 0 SL ccb_scan 0xc07b8b84 [xpt_thrd] 8 0 0 0 SL - 0xc89a3e00 [kqueue taskq] 20 0 0 0 WL [swi5: +] 7 0 0 0 SL - 0xc89d7080 [thread taskq] 19 0 0 0 WL [swi6: Giant taskq] 18 0 0 0 WL [swi6: task queue] 17 0 0 0 SL - 0xc07bae00 [yarrow] 6 0 0 0 SL crypto_r 0xc081c7c4 [crypto returns] 5 0 0 0 SL crypto_w 0xc081c784 [crypto] 4 0 0 0 SL - 0xc07bb928 [g_down] 3 0 0 0 LL *vm page 0xc8d5f780 [g_up] 2 0 0 0 SL - 0xc07bb91c [g_event] 16 0 0 0 WL [swi1: net] 15 0 0 0 WL [swi3: vm] 14 0 0 0 LL *Giant 0xcaaf97c0 [swi4: clock sio] 13 0 0 0 RL CPU 0 [idle: cpu0] 12 0 0 0 RL CPU 1 [idle: cpu1] 11 0 0 0 RL CPU 2 [idle: cpu2] 10 0 0 0 RL [idle: cpu3] 1 0 1 0 SLs wait 0xc8951000 [init] 0 0 0 0 WLs [swapper] # -------------------------------------------------------------------- # CPU LISTING db> show pcpu cpuid = 1 curthread = 0xc894c900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894c900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xc894ca80: pid 13 "idle: cpu0" curpcb = 0xe81f5d90 fpcurthread = none idlethread = 0xc894ca80: pid 13 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: cpuid = 1 curthread = 0xc894c900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894c900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: cpuid = 2 curthread = 0xc894c780: pid 11 "idle: cpu2" curpcb = 0xe81efd90 fpcurthread = none idlethread = 0xc894c780: pid 11 "idle: cpu2" APIC ID = 2 currentldt = 0x50 spin locks held: cpuid = 3 curthread = 0xca268900: pid 52531 "ee" curpcb = 0xec710d90 fpcurthread = none idlethread = 0xc894c600: pid 10 "idle: cpu3" APIC ID = 3 currentldt = 0x50 spin locks held: # -------------------------------------------------------------------- # LOCK LISTING db> show locks db> show alllocks Process 35638 (sendmail) thread 0xd0530600 (101044) exclusive sleep mutex vm object (standard object) r = 0 (0xc9c01318) locked @ /usr/src/sys/vm/vm_map.c:1472 exclusive sx user map r = 0 (0xc8fb7734) locked @ /usr/src/sys/vm/vm_map.c:1208 Process 32836 (rsync) thread 0xc9ec1900 (100360) exclusive sleep mutex pmap r = 0 (0xca89f560) locked @ /usr/src/sys/i386/i386/pmap.c:2041 exclusive sleep mutex vm page queue mutex r = 0 (0xc081d540) locked @ /usr/src/sys/i386/i386/pmap.c:2040 exclusive sx user map r = 0 (0xca89f4e4) locked @ /usr/src/sys/vm/vm_map.c:3105 Process 32754 (httpd) thread 0xcfcc5600 (101170) exclusive sleep mutex vm object (standard object) r = 0 (0xcc8378c4) locked @ /usr/src/sys/vm/vm_fault.c:297 exclusive sx user map r = 0 (0xc984a4e4) locked @ /usr/src/sys/vm/vm_map.c:3105 Process 7829 (bsnmpd) thread 0xca196180 (100409) exclusive sleep mutex vm object (kmem object) r = 0 (0xc081d440) locked @ /usr/src/sys/vm/vm_kern.c:325 exclusive sleep mutex system map r = 0 (0xc1068144) locked @ /usr/src/sys/vm/vm_kern.c:295 exclusive sx sysctl lock r = 0 (0xc07be240) locked @ /usr/src/sys/kern/kern_sysctl.c:1375 exclusive sleep mutex Giant r = 0 (0xc07bdb80) locked @ /usr/src/sys/kern/kern_sysctl.c:1313 Process 3 (g_up) thread 0xc894ec00 (100015) exclusive sleep mutex vm object (standard object) r = 0 (0xcaf6e8c4) locked @ /usr/src/sys/kern/vfs_bio.c:3120 db> show lockedvnods Locked vnodes 0xcdcce6cc: tag ufs, type VDIR usecount 2, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcaf6e8c4 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc97f1000 (pid 32710)#0 0xc054d7f1 at lockmgr+0x4ed #1 0xc06a0f96 at ffs_lock+0x76 #2 0xc07170ab at VOP_LOCK_APV+0x87 #3 0xc05bd370 at vn_lock+0xac #4 0xc05b9f0b at getdirentries+0xff #5 0xc07046b3 at syscall+0x25b #6 0xc06efccf at Xint0x80_syscall+0x1f ino 20398955, on dev ad8s1e # -------------------------------------------------------------------- # PROCESS STACK TRACES # SENDMAIL db> trace 35638 Tracing pid 35638 tid 101044 td 0xd0530600 sched_switch(d0530600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,d0530600,0,c0768214,5f8) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c0768214,5f8) at _mtx_lock_flags+0xa2 vm_map_pmap_enter(c8fb76f0,28095000,5,c9c01318,0,0,a000,10) at vm_map_pmap_enter+0x1df vm_map_insert(c8fb76f0,c9c01318,0,0,28095000,2809f000,5,7,112) at vm_map_insert+0x28c vm_map_find(c8fb76f0,c9c01318,0,0,ed810cc8,a000,1,5,7,112) at vm_map_find+0x86 vm_mmap(c8fb76f0,ed810cc8,a000,5,7,20002,2,c9cd0ae0,0,0) at vm_mmap+0x266 mmap(d0530600,ed810d04) at mmap+0x31f syscall(2807003b,2806003b,bfbf003b,28082060,0,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (198, FreeBSD ELF32, nosys), eip = 0x2806cd63, esp = 0xbfbfea7c, ebp = 0xbfbfeab8 --- # RSYNC db> trace 32836 Tracing pid 32836 tid 100360 td 0xc9ec1900 sched_switch(c9ec1900,0,2) at sched_switch+0x177 mi_switch(2,0,c07bdb40,0,c074c42d,...) at mi_switch+0x270 critical_exit(1,c9ec1900,0,9d6f000,bfc275bc,...) at critical_exit+0x8b intr_execute_handlers(c893f6e4,ec552b6c,13,ec552bd4,c06f0033,...) at intr_execute_handlers+0x129 lapic_handle_intr(35) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc0700897, esp = 0xec552bb0, ebp = 0xec552bd4 --- pmap_enter(ca89f560,9d6f000,c332e380,7,0,ced476b4,0,c0767c8b,383) at pmap_enter+0x1bf vm_fault(ca89f4a0,9d6f000,2,8,c9ec1900,...) at vm_fault+0x10b8 trap_pfault(ec552d38,1,9d6ffb8,9d6ffb8,0,...) at trap_pfault+0xce trap(bfbf003b,3b,bfbf003b,9d6ffb8,0,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x2818527f, esp = 0xbfbf9670, ebp = 0xbfbf9b08 --- # HTTPD db> trace 32754 Tracing pid 32754 tid 101170 td 0xcfcc5600 sched_switch(cfcc5600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,cfcc5600,0,c0767c8b,356) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c0767c8b,356,c07bdb40,...) at _mtx_lock_flags+0xa2 vm_fault(c984a4a0,88d1000,2,8,cfcc5600,...) at vm_fault+0xfa7 trap_pfault(ed840d38,1,88d1d90,88d1d90,0,...) at trap_pfault+0xce trap(80a003b,875003b,bfbf003b,2360,8382000,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x286a34c1, esp = 0xbfbfb860, ebp = 0xbfbfb898 --- # BSNMPD db> trace 7829 Tracing pid 7829 tid 100409 td 0xca196180 sched_switch(ca196180,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,ca196180,0,c076806c,16f) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c076806c,16f,10928000,...) at _mtx_lock_flags+0xa2 kmem_malloc(c10680c0,7000,102,ec649b64,c06b330f,...) at kmem_malloc+0x282 page_alloc(0,7000,ec649b57,102) at page_alloc+0x1a uma_large_malloc(7000,102,64f0,c05469d6,ec649bf4,...) at uma_large_malloc+0x3b malloc(64f0,c078fb40,102,c057de5a,ec649bf4,...) at malloc+0xf3 sysctl_jail_list(c078f220,0,0,ec649bf4,c078f220,...) at sysctl_jail_list+0x8e sysctl_root(0,ec649c74,3,ec649bf4) at sysctl_root+0x11b userland_sysctl(ca196180,ec649c74,3,0,bfbfc46c,0,0,0,ec649c70,0,c07bdb80,0,c074b5cd,521) at userland_sysctl+0xf4 __sysctl(ca196180,ec649d04) at __sysctl+0x77 syscall(bfbe003b,2818003b,bfbe003b,3,bfbfc46c,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2814e77b, esp = 0xbfbfc34c, ebp = 0xbfbfc388 --- # G_UP db> trace 3 Tracing pid 3 tid 100015 td 0xc894ec00 sched_switch(c894ec00,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c081d540,c9ec1900,0,c081d540,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c081d540,c894ec00,0,c0752afd,c43) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c081d540,0,c0752afd,c43,c06b29a0,...) at _mtx_lock_flags+0xa2 bufdone(dcb814d4) at bufdone+0x176 g_vfs_done(cc0806b4) at g_vfs_done+0x8a biodone(cc0806b4) at biodone+0x58 g_io_schedule_up(c894ec00) at g_io_schedule_up+0xcb g_up_procbody(0,e8216d38,0,c0523700,0,...) at g_up_procbody+0x5a fork_exit(c0523700,0,e8216d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8216d6c, ebp = 0 --- # EE db> trace 52531 Tracing pid 52531 tid 100453 td 0xca268900 sched_switch(3dc,c074f76f,ec710b90,c0550d8e,c080b7c0,...) at sched_switch+0x177 sellock(c055154c,c07497db,a,c055154c,0,...) at sellock (null)(786574,50414d4b,544e4520,75005952,20726573,...) at 0x9 # SWI4: CLOCK SIO db> trace 14 Tracing pid 14 tid 100002 td 0xc894cc00 sched_switch(c894cc00,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,c894cc00,0,c074bcf0,102) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c074bcf0,102) at _mtx_lock_flags+0xa2 softclock(0) at softclock+0x18f ithread_execute_handlers(c894b430,c89a2b80) at ithread_execute_handlers+0xe6 ithread_loop(c89288e0,e81f8d38,c89288e0,c05456e0,0,...) at ithread_loop+0x67 fork_exit(c05456e0,c89288e0,e81f8d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe81f8d6c, ebp = 0 --- # EM0 db> trace 27 Tracing pid 27 tid 100017 td 0xc894e900 sched_switch(c894e900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,c894e900,0,c0747942,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c0747942,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a4648,c89a1480) at ithread_execute_handlers+0xde ithread_loop(c8a438d0,e8210d38,c8a438d0,c05456e0,0,...) at ithread_loop+0x67 fork_exit(c05456e0,c8a438d0,e8210d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8210d6c, ebp = 0 --- # em1 db> trace 26 Tracing pid 26 tid 100018 td 0xc894e780 sched_switch(c894e780,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,c894e780,0,c0747942,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c0747942,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a4860,c89a1500) at ithread_execute_handlers+0xde ithread_loop(c8a3f6a0,e820dd38,c8a3f6a0,c05456e0,0,...) at ithread_loop+0x67 fork_exit(c05456e0,c8a3f6a0,e820dd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe820dd6c, ebp = 0 --- # LYNX db> trace 33070 Tracing pid 33070 tid 100668 td 0xca02f600 sched_switch(ca02f600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07bdb80,ca196180,0,c07bdb80,2,c07497e6,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07bdb80,ca02f600,0,c074fb3c,ec) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07bdb80,0,c074fb3c,ec) at _mtx_lock_flags+0xa2 soo_poll(d015b000,40,d06e1b80,ca02f600) at soo_poll+0x2a selscan(ca02f600,ec5d5b94,ec5d5b84,14,c080b7c0,0,c074f76f,300) at selscan+0x1a5 kern_select(ca02f600,14,bfbfe304,0,0,...) at kern_select+0x33b select(ca02f600,ec5d5d04) at select+0x44 syscall(3b,bfbf003b,bfbf003b,0,bfbfe304,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (93, FreeBSD ELF32, select), eip = 0x281e6be4, esp = 0xbfbfe2a8, ebp = 0xbfbfe384 --- --------------050805000904020105080208 Content-Type: text/plain; name="RACK2DBG" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RACK2DBG" # # RACK2 -- M2 config file # machine i386 cpu I686_CPU ident RACK2 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options SMP options FAST_IPSEC options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options DIAGNOSTIC options BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS device crypto device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device rr232x # Highpoint RocketRAID 232x #device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) --------------050805000904020105080208-- From owner-freebsd-stable@FreeBSD.ORG Sun Jun 15 11:59:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADFF4106566C; Sun, 15 Jun 2008 11:59:01 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [213.186.42.107]) by mx1.freebsd.org (Postfix) with ESMTP id 738C68FC18; Sun, 15 Jun 2008 11:59:01 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (15.10.87-79.rev.gaoland.net [79.87.10.15]) by smtp.lamaiziere.net (Postfix) with ESMTP id E2893118059A; Sun, 15 Jun 2008 13:58:59 +0200 (CEST) Received: from baby-jane-lamaiziere-net.local (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id E21E14EE4B7; Sun, 15 Jun 2008 13:58:58 +0200 (CEST) Date: Sun, 15 Jun 2008 13:58:57 +0200 From: Patrick =?ISO-8859-15?Q?Lamaizi=E8re?= To: freebsd-stable@freebsd.org Message-ID: <20080615135857.16e03015@baby-jane-lamaiziere-net.local> In-Reply-To: <20080614015229.1c4afbe7@baby-jane-lamaiziere-net.local> References: <20080613004847.09f9b089@baby-jane-lamaiziere-net.local> <4851B7EF.7060905@FreeBSD.org> <20080614015229.1c4afbe7@baby-jane-lamaiziere-net.local> Organization: /dave/nulle X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.8; i386-apple-darwin9.2.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: Kris Kennaway Subject: Re: [7-STABLE] ping -s 4000 with ipsec panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2008 11:59:01 -0000 Le Sat, 14 Jun 2008 01:52:29 +0200, Patrick Lamaizière a écrit : > I made few tests and the panic occurs with a -s of 3989 bytes. > > ping -s 3988 => ok > ping -s 3989 => panic > > The coredump seems to be ok. > http://user.lamaiziere.net/patrick/coredump.txt > > I will try with a kernel and DEBUG_REDZONE and INVARIANT. With INVARIANT there is an assertion that failed in the ipsec code. I've filled a PR : http://www.freebsd.org/cgi/query-pr.cgi?pr=124609 Thank you, regards. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 15 12:23:10 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B201065678 for ; Sun, 15 Jun 2008 12:23:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id 769C68FC19 for ; Sun, 15 Jun 2008 12:23:10 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru (unknown [89.163.10.141]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 2DFE813DF42 for ; Sun, 15 Jun 2008 16:23:09 +0400 (MSD) Date: Sun, 15 Jun 2008 16:23:17 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v3.99.3) Professional Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <372651116.20080615162317@serebryakov.spb.ru> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: FreeBSD 7-STABLE deadlock! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2008 12:23:10 -0000 Hello, freebsd-stable. Sometimes my FreeBSD 7 machine becomes semi-dead: all network sttack is working (pingable, etc), all LIVE processes are live, but it is impossible to create new (and, it seems, EXIT finished) process. So, I can work in shell via SSH, if I have connection, but if I try to run any external program session is lost for me -- it try to run it forever, and ^C is not working. Same with "real" console. Same with scripts -- if script working, it locks on next external command forever and can not be killed with ^C. It is dual-core (E4500)-based comuter, amd64 arch. It have these debug options in kernel: options DDB options KDB options KDB_UNATTENDED options INVARIANTS options INVARIANT_SUPPORT options WITNESS options DEBUG_MEMGUARD options WITNESS_KDB options MUTEX_DEBUG I have kernel debugger and here is some information (it is re-typed from screen, so is not byte-to-byte exact output and I skipped long 64-bit addresses): (1) show allpcpu Current CPU: 1 cpuid = 0 curthread = pid 12: "idle: cpu0" curpcb = fpcurthread = none idlethread = pid 12: "idle: cpu0" spinlocks held: cpuid = 1 curthread = pid 17: "swi6: Giant taskq" curpcb = fpcurthread = none idlethread = pid 11: "idle: cpu1" spinlocks held: (2) show locks exclusive sleep mutex Giant r = 0 (ADDRESS) locked @ /usr/src/sys/kern/kern_intr.c:1035 (3) show alllocks process 723 (sshd) thread
(TID) exclusive sx so_rcv_sx r = 1 (ADDRESS) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 process 574 (nmdb) thread
(TID) exclusive sx user map r = 0 (ADDRESS) locked @ /usr/src/sys/vm/vm_map.c:3111 process 17 (swi6: Ginat taskq) thread
(TID) exclusive sleep mutex Giant r = 0 (ADDRESS) locked @ /usr/src/sys/kern/kern_intr.c:1035 (4) alltrace shows: (a) I have MANY (about 20) sendmail processes (on computer without mail traffic at all!), and all of them have "VOP_LOCK1_AVP()" in trace, which leads to sched_switch() after some steps, including _sleep(). (b) cron is sleeping with sched_switch() after vfork() (Oh! Impossibility to create processes!) (c) All other userland processes are traced up to sched_switch() from different syscalls, via _sleep()... I don't reboot this computer for now, and waiting for requests which can help diagnose this situation :) -- // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Sun Jun 15 12:35:14 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A3581065681 for ; Sun, 15 Jun 2008 12:35:14 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id CE8448FC0C for ; Sun, 15 Jun 2008 12:35:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru (unknown [89.163.10.141]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id E1F2E13DF42 for ; Sun, 15 Jun 2008 16:35:12 +0400 (MSD) Date: Sun, 15 Jun 2008 16:35:21 +0400 From: Lev Serebryakov X-Mailer: The Bat! (v3.99.3) Professional Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <941206638.20080615163521@serebryakov.spb.ru> To: freebsd-stable@freebsd.org In-Reply-To: <372651116.20080615162317@serebryakov.spb.ru> References: <372651116.20080615162317@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: Re: FreeBSD 7-STABLE deadlock! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2008 12:35:14 -0000 Hello, freebsd-stable. You wrote 15 =E8=FE=ED=FF 2008 =E3., 16:23:17: > Sometimes my FreeBSD 7 machine becomes semi-dead: all network sttack > is working (pingable, etc), all LIVE processes are live, but it is > impossible to create new (and, it seems, EXIT finished) process. It is SCHED_ULE --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 04:00:29 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8322C1065672; Mon, 16 Jun 2008 04:00:29 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id EDA0A8FC2B; Mon, 16 Jun 2008 04:00:28 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by koef.zs64.net (8.14.3/8.14.3) with ESMTP id m5G3gwiE098237; Mon, 16 Jun 2008 05:42:58 +0200 (CEST) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.14.3/8.14.3/Submit) id m5G3gwIK098234; Sun, 15 Jun 2008 23:42:58 -0400 (EDT) (envelope-from cracauer) Date: Sun, 15 Jun 2008 23:42:58 -0400 From: Martin Cracauer To: Kris Kennaway Message-ID: <20080616034258.GA94873@cons.org> References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C9C912.1020700@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@FreeBSD.ORG, cracauer@FreeBSD.ORG, Jakub Siroky , freebsd-stable@FreeBSD.ORG, maxim@FreeBSD.ORG Subject: Re: infinite loop when copying to ext2fs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 04:00:29 -0000 Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: > Jakub Siroky wrote: > >I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I > >did not noticed it before because I started using ext2fs extensively > >some months ago. > > > >Regards, > >Jakub > > > >On Sat, 19 Jan 2008 16:44:34 +0100 > >Kris Kennaway wrote: > > > >>Kris Kennaway wrote: > >>>Jakub Siroky wrote: > >>>>I have two large ext2fs partitions (368 and 313GB) to hold data > >>>>shared between several OSes. While there were no problems on > >>>>6-STABLE branch I was quite disappointed after upgrade to > >>>>7-STABLE. Whenever I copy/write to ext2fs partition the system > >>>>freezes totally without crashdump. So I set debugging settings to > >>>>kernel config (DEBUG,WITNESS,..) and in console I reproduced error > >>>>situation ending with full screen of unstoppable running text with > >>>>lot of memory addresses and a few recognisable words: 'new block > >>>>bit set for ext already' - again with no crashdump. Then I have > >>>>formatted 1GB partition with ext2fs and the problem on this small > >>>>partition appears only sometimes. > >>>OK, I am able to reproduce this. > >>> > >>>Kris > >>> > >>Is anyone able to look at this? I could not spot a candidate change > >>that has not been merged to 6.x. > >> > >>Kris > > > > > > Sounds like it may have been broken by the change to ext2_bitops.h by > cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? I don't think my change can cause a new endless loop. I only reversed the order of tests to ensure we don't overrun a page bounddary (into possibly unmapped space). - while(*p == ~0U && ofs < sz) { + while(ofs < sz && *p == ~0U) { It is, however, likely that the code was buggy in the first place. Linux has replaced all this (the allocation code). Also note that the code I fixed is amd64 only. If the endless loop appears on i386 it's something else. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 06:13:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E64E1065679 for ; Mon, 16 Jun 2008 06:13:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id 18C398FC17 for ; Mon, 16 Jun 2008 06:13:19 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so931313wra.27 for ; Sun, 15 Jun 2008 23:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=YXGVZXVatc2s+8Jt2ETAoO5mEET8HJh6EzwsrztXSFQ=; b=tNTpHYYgES9EsNB3jgdfkZ2I525elLdMN82HkbvxROxhzD0MCSciyMHgRxIrSfqnQL PtIIVWQC1g9BpUewnmRdCA/2vHAlP+UcNTqtFDwelmlnyhzNKjCvijjiYxGMIMZOYiQw JWus+qudMH6ltCoUr8omJNtujGsgmfz9+uezg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=NFuQTzs7h2ZtDlil8B5spu6Pd4bKhXM48yMjxFrKo7AZbUAp8YBEoGVY/Y1k62ksQt iylqzBjfAyUYY2NMuVxg2VimSNcHjmqjIdYF1HoP0tXlO4LjPGhDA6V/tSzj6kDuWGFF jw9gCv7UJv5YZcpNIrng/xlUs5BoDOUje2dQw= Received: by 10.90.99.6 with SMTP id w6mr6426146agb.71.1213596798473; Sun, 15 Jun 2008 23:13:18 -0700 (PDT) Received: by 10.90.96.4 with HTTP; Sun, 15 Jun 2008 23:13:18 -0700 (PDT) Message-ID: Date: Mon, 16 Jun 2008 10:13:18 +0400 From: pluknet To: freebsd-stable@freebsd.org In-Reply-To: <94e0cac00712141907l601c25adw41783c122130d6cb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4761A0D8.4070609@barafranca.com> <20071213212145.GA55472@heff.fud.org.nz> <4761AE58.2070409@barafranca.com> <47633820.7050203@barafranca.com> <94e0cac00712141907l601c25adw41783c122130d6cb@mail.gmail.com> Cc: sam@freebsd.org, Andrew Thompson Subject: Re: iwi on BETA4 with WPA2: device timeout/firmware error X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 06:13:19 -0000 > On 15/12/2007, Hugo Silva wrote: >> Hugo Silva wrote: >> > Andrew Thompson wrote: >> >> On Thu, Dec 13, 2007 at 09:15:04PM +0000, Hugo Silva wrote: >> >> >> >>> Hello list, >> >>> >> >>> Just wanted to report another issue with BETA4 on my laptop. >> >>> >> >>> The wireless connection is "working" without encryption (interface >> >>> goes up and down every few minutes, but at least I don't lose any >> >>> connections, so it's barely noticeable). >> >>> >> >>> Today I was setting up WPA2 with wpa_supplicant and hostapd and >> >>> managed to do so (status: associated), however it goes down a few >> >>> seconds later with iwi0: device timeout and iwi0: firmware error, >> >>> every single time. >> >>> >> >>> Is this a known problem ? At least on my machine, WPA + iwi is >> >>> currently unusable, as I am not able to ping anything even in the >> >>> brief moments the card is associated with the AP. >> >>> >> >> >> >> Can you please set the sysctl debug.iwi to 2 and post the debugging >> >> messages that are output. Make sure you get the section of output from >> >> when you kick off wpa_supplicant and when the firmware error happens. >> >> >> >> >> > >> > Okay, down'ed the interface, set debug.iwi=2, and ran wpa_supplicant >> > -i iwi0 -c /etc/wpa_supplicant.conf. Here's the output: [..] >> >> I have managed to get WPA2 working, however the "firmware error" still >> persists (it only happens once every 10 or 20 minutes now, and simply >> unloading the if_iwi module will bring the interface back and it'll be >> operational. >> >> Without debugging, all dmesg showed was "firmware error" and "firmware >> stuck in state 4, resetting", with wlandebug -i iwi0 wpa+auth+crypto, it >> shows: >> >> >> >> Dec 15 02:06:00 laptop kernel: iwi0: link state changed to DOWN >> Dec 15 02:06:00 laptop kernel: iwi0: _ieee80211_crypto_delkey: NONE >> keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 >> Dec 15 02:06:00 laptop kernel: iwi0: _ieee80211_crypto_delkey: TKIP >> keyix 1 flags 0x36 rsc 0 tsc 1 len 16 >> Dec 15 02:06:00 laptop kernel: iwi0: _ieee80211_crypto_delkey: TKIP >> keyix 2 flags 0x36 rsc 1 tsc 1 len 16 >> Dec 15 02:06:00 laptop kernel: iwi0: _ieee80211_crypto_delkey: NONE >> keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 >> Dec 15 02:06:00 laptop kernel: iwi0: _ieee80211_crypto_delkey: NONE >> keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 >> Dec 15 02:06:04 laptop kernel: iwi0: firmware stuck in state 4, resetting >> Dec 15 02:06:04 laptop kernel: iwi0: _ieee80211_crypto_delkey: NONE >> keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 >> Dec 15 02:06:04 laptop kernel: iwi0: _ieee80211_crypto_delkey: NONE >> keyix 65535 flags 0x3 rsc 0 tsc 0 len 0 >> Dec 15 02:06:05 laptop kernel: iwi0: firmware error >> >> >> Is this helpful ? >> >> $ ifconfig iwi0 >> iwi0: flags=8843 metric 0 mtu 1500 >> ether .... >> inet 192.168.200.26 netmask 0xffffff00 broadcast 192.168.200.255 >> media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/54Mbps) >> status: associated >> ssid zaurak_wifi channel 5 (2432 Mhz 11g) bssid ... >> authmode WPA2/802.11i privacy ON deftxkey UNDEF TKIP 2:128-bit >> powersavemode CAM powersavesleep 100 bmiss 10 scanvalid 60 >> protmode CTS wme roaming MANUAL >> Today I could reproduce stuck in state 4 on recent RELENG7. -wlandebug -i iwi0 +scan iwi0: ieee80211_start_scan: active scan, duration 2147483647, desired mode auto, append, nopick, once iwi0: scan set 10g, 11g, 1b, 1g, 2b, 2g, 3b, 3g, 4b, 4g, 5b, 5g, 6b, 6g, 7b, 7g, 8b, 8g, 9b, 9g, 12b, 12g, 13b, 13g, 14b, 14g dwell min 200 max 200 iwi0: scan_next: chan 10g -> 10g [active, dwell min 200 max 200] [00:16:ca:f5:1e:71] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:16:ca:f5:1e:71] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:70] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:16:ca:f5:1e:70] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:71] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:16:ca:f5:1e:71] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:18:b0:fe:7c:b1] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:18:b0:fe:7c:b1] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:70] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:16:ca:f5:1e:70] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e iwi0: ieee80211_add_scan: chan 10g min dwell met (31910172 > 31910128) [00:16:ca:f5:1e:71] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:16:ca:f5:1e:71] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:70] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:16:ca:f5:1e:70] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:71] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:16:ca:f5:1e:71] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:18:b0:fe:7c:b0] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:18:b0:fe:7c:b0] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:70] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:16:ca:f5:1e:70] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:71] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:16:ca:f5:1e:71] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:18:b0:fe:7c:b0] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:18:b0:fe:7c:b0] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:18:b0:fe:7c:b1] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:18:b0:fe:7c:b1] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:70] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:16:ca:f5:1e:70] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [-----several screens of same output, near 10 pages -----] [00:18:b0:fe:7c:b1] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:70] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:16:ca:f5:1e:70] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:16:ca:f5:1e:71] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:16:ca:f5:1e:71] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:18:b0:fe:7c:b0] new beacon on chan 10 (bss chan 10) "Golden_WiFi" [00:18:b0:fe:7c:b0] caps 0x421 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e [00:18:b0:fe:7c:b1] new beacon on chan 10 (bss chan 10) "Golden_WiFi_B2B" [00:18:b0:fe:7c:b1] caps 0x431 bintval 100 erp 0x0 country info 52 55 00 01 0b 1e iwi0: firmware stuck in state 4, resetting iwi0: ieee80211_cancel_scan: cancel active scan iwi0: ieee80211_scan_flush iwi0: scan_next: done, [ticks 31914946, dwell min 200 scanend 2179393574] iwi0: notify scan done iwi0: ieee80211_check_scan: active scan, duration 2147483647, desired mode auto, flush iwi0: adhoc_pick_bss: no scan candidate iwi0: ieee80211_create_ibss: creating ibss I got it on ifconfig iwi0 scan, of course. iwi0: flags=8943 metric 0 mtu 1500 ether 00:0e:35:be:77:df inet 192.168.80.1 netmask 0xffffff00 broadcast 192.168.80.255 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) # note mediaopt adhoc status: associated ssid bsdap channel 10 (2457 Mhz 11g) bssid ca:af:ea:5b:86:98 authmode OPEN privacy OFF bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS Also immediately after that I reproduceably get page fault in /sys/net80211/ieee80211_ht.c:819 ... } else if (IEEE80211_IS_CHAN_HT(chan)) { ... because there is dereferencing of chan == NULL. I could avoid this panic with this dirty hack but still got "iwi0: firmware stuck in state 4, resetting": --- /sys/net80211/ieee80211_scan_sta.c.orig 2008-06-16 09:50:11.000000000 +0400 +++ /sys/net80211/ieee80211_scan_sta.c 2008-06-16 09:51:00.000000000 +0400 @@ -24,7 +24,7 @@ */ #include -__FBSDID("$FreeBSD: src/sys/net80211/ieee80211_scan_sta.c,v 1.4.2.4 2008/04/25 16:21:05 sam Exp $"); +__FBSDID("$FreeBSD$"); /* * IEEE 802.11 station scanning support. @@ -1337,6 +1337,7 @@ bestrssi = -1; mtx_lock(&st->st_lock); + bestchan = ss->ss_chans[0]; for (i = 0; i < ss->ss_last; i++) { c = ss->ss_chans[i]; if (!checktable(adhocScanTable, c)) Yes, ss->ss_last == 0, therefore bestchan stands == NULL, and therefore chan get NULL on return Last chains of call stack (sorry, on memory): adhoc_pick_bss -> -> ieee80211_ht_adjust_channel(ic, adhoc_pick_channel(ss), ic->ic_flags_ext) -> # here adhoc_pick_channel() returns NULL and ieee80211_ht_adjust_channel() deref. it on ieee80211_ht.c:819 -> trap [I don't know is it on guilty of iwi(4) or ieee80211 itself.] wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 06:56:56 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64A99106568A for ; Mon, 16 Jun 2008 06:56:56 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by mx1.freebsd.org (Postfix) with ESMTP id B45108FC25 for ; Mon, 16 Jun 2008 06:56:50 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so1582807tid.3 for ; Sun, 15 Jun 2008 23:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=YBOFaDqXoRnrEIMsLAEIdJKa+bNg0kHULsL6KDjDiog=; b=yH9GckLPrAVVll2K3aUivGRUKxFZ/Q2mzMtFcc5qg4iW7VftPXtXdd3a0VLd0Kt25z UQz/L089K8aHIBG267K8rHyRfu2AKbu27N4TGxrsaU4nb6N3qui9a6sbNI0tVBgk50/k JCY7/XpLZNVsAr67oBXMmbB4ZTBct2KjwrRhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=FCDqIK0UeWHaoxIC9HIHrQJPGsASuPHNRMXwgTJePRWmpfksqKCEJMryQfI83naaSr GCoWzxqxOURYt9A/UilCNwsXjiXbcqXuPbxlPwdo1aX3bkpKt4OmahVq71Jp/DSBOJ1k WNv7ALMqnrOEhR9lNh4lAMfy2BgA8xEDfPqIo= Received: by 10.110.43.18 with SMTP id q18mr4064763tiq.57.1213597791421; Sun, 15 Jun 2008 23:29:51 -0700 (PDT) Received: by 10.110.8.4 with HTTP; Sun, 15 Jun 2008 23:29:51 -0700 (PDT) Message-ID: <5ea5cca50806152329x7f405118o5611636b19f27a70@mail.gmail.com> Date: Mon, 16 Jun 2008 14:29:51 +0800 From: "Yi Wang" To: freebsd-stable@freebsd.org In-Reply-To: <5ea5cca50806152328k5f3d6673nfeff9b2c29032460@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5ea5cca50806152328k5f3d6673nfeff9b2c29032460@mail.gmail.com> Subject: Re: Does system change affected portsnap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 06:56:56 -0000 Sorry, The subject should be "system time", not "system". On 6/16/08, Yi Wang wrote: > Today I found the system time is incorrect. After changing it, about 5 > hours skipped. > > My question is: Will portsnap update the changes of ports in these 5 hours? > > Thanks! > > -- > Regards, > > Wang Yi > -- Regards, Wang Yi From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 06:57:15 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A841106578C for ; Mon, 16 Jun 2008 06:57:15 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by mx1.freebsd.org (Postfix) with ESMTP id 291528FC21 for ; Mon, 16 Jun 2008 06:57:14 +0000 (UTC) (envelope-from wangyi6854@gmail.com) Received: by ti-out-0910.google.com with SMTP id d27so1582807tid.3 for ; Sun, 15 Jun 2008 23:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=BIDgK+3PWLoPYx1SeEfoxw6JK/l771L1cPxEYwJ8z4I=; b=wnXRNNZuvKqsyLQe7rU94XrQCqbFJJxI/nIRTm807WAqj2Gkhky2P6HZ2Vb+3sUtsg povXQwx64W8E6g20DIWPL86g98nqvt3kapeIOlADB8Ku3SzhTTKlSpTZEjOoQSqNf7l8 QWMw/S5aHjkO5RO60Fe4f71ONUSaaJtaOh/mQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=JqKknvr8Jn25WJjK+vBKYXYbMDVKSKZn/noS4YW1Ezf3LzBMaxnfMtJKbuH2NBitix LxdxQWdEvLLQOy2NzmQC5BaAbjdoRM3ZxJx/TXmsScnEuSYq/kV5ipfP8B6gK+CtbxeS oXoQ8tbLpZn2iQU7WXvOPcwu6pfZzZsVd/4eI= Received: by 10.110.47.17 with SMTP id u17mr4068921tiu.49.1213597717959; Sun, 15 Jun 2008 23:28:37 -0700 (PDT) Received: by 10.110.8.4 with HTTP; Sun, 15 Jun 2008 23:28:37 -0700 (PDT) Message-ID: <5ea5cca50806152328k5f3d6673nfeff9b2c29032460@mail.gmail.com> Date: Mon, 16 Jun 2008 14:28:37 +0800 From: "Yi Wang" To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Does system change affected portsnap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 06:57:15 -0000 Today I found the system time is incorrect. After changing it, about 5 hours skipped. My question is: Will portsnap update the changes of ports in these 5 hours? Thanks! -- Regards, Wang Yi From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 07:08:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 390EA10656C3 for ; Mon, 16 Jun 2008 07:08:23 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: from mail5out.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) by mx1.freebsd.org (Postfix) with ESMTP id E8C688FC38 for ; Mon, 16 Jun 2008 07:08:22 +0000 (UTC) (envelope-from edwin@mavetju.org) Received: by mail5out.barnet.com.au (Postfix, from userid 1001) id 5C7F52219346; Mon, 16 Jun 2008 17:08:21 +1000 (EST) X-Viruscan-Id: <485611650000FDDBB7487F@BarNet> Received: from mail5auth.barnet.com.au (mail5.barnet.com.au [202.83.178.78]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail5auth.barnet.com.au", Issuer "*.barnet.com.au" (verified OK)) by mail5.barnet.com.au (Postfix) with ESMTP id 102A821B3A4C; Mon, 16 Jun 2008 17:08:21 +1000 (EST) Received: from k7.mavetju (k7.mavetju.org [10.251.1.18]) by mail5auth.barnet.com.au (Postfix) with ESMTP id 94B452219355; Mon, 16 Jun 2008 17:08:20 +1000 (EST) Received: by k7.mavetju (Postfix, from userid 1001) id E5CB74E3; Mon, 16 Jun 2008 17:08:20 +1000 (EST) Date: Mon, 16 Jun 2008 17:08:20 +1000 From: Edwin Groothuis To: Yi Wang Message-ID: <20080616070820.GB89656@k7.mavetju> Mail-Followup-To: Edwin Groothuis , Yi Wang , freebsd-stable@freebsd.org References: <5ea5cca50806152328k5f3d6673nfeff9b2c29032460@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ea5cca50806152328k5f3d6673nfeff9b2c29032460@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Does system change affected portsnap? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 07:08:23 -0000 On Mon, Jun 16, 2008 at 02:28:37PM +0800, Yi Wang wrote: > Today I found the system time is incorrect. After changing it, about 5 > hours skipped. > > My question is: Will portsnap update the changes of ports in these 5 hours? It shouldn't be a problem. If you want to be sure, just reboot the box (or restart *all* processes and all will be fine. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://www.mavetju.org/weblog/ From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 07:15:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 669E71065677 for ; Mon, 16 Jun 2008 07:15:50 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1E70C8FC28 for ; Mon, 16 Jun 2008 07:15:50 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.18.98.62] (brmea-proxy-1.Sun.COM [192.18.98.62]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 4B59113DF4B for ; Mon, 16 Jun 2008 11:15:47 +0400 (MSD) Message-ID: <485612AD.2000301@FreeBSD.org> Date: Mon, 16 Jun 2008 11:13:49 +0400 From: Lev Serebryakov Organization: FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.14) Gecko/20071210 Thunderbird/1.5.0.14 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <372651116.20080615162317@serebryakov.spb.ru> <941206638.20080615163521@serebryakov.spb.ru> In-Reply-To: <941206638.20080615163521@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 7-STABLE deadlock! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 07:15:50 -0000 Lev Serebryakov wrote: >> Sometimes my FreeBSD 7 machine becomes semi-dead: all network sttack >> is working (pingable, etc), all LIVE processes are live, but it is >> impossible to create new (and, it seems, EXIT finished) process. > It is SCHED_ULE It seems to be ATA/SATA or UFS2 problem: now I have computer in state, when 4 iozone processes are hanged in "Disk wait" state, and I can not "cd" to filesystem, which is tested by "iozone". But I can create processes, work on system, etc., if I don't touch this filesystem. -- // Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 09:27:57 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 969131065673; Mon, 16 Jun 2008 09:27:57 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E9E958FC1D; Mon, 16 Jun 2008 09:27:54 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48563219.9070306@FreeBSD.org> Date: Mon, 16 Jun 2008 11:27:53 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Martin Cracauer References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> <20080616034258.GA94873@cons.org> In-Reply-To: <20080616034258.GA94873@cons.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.ORG, cracauer@FreeBSD.ORG, Jakub Siroky , freebsd-stable@FreeBSD.ORG, maxim@FreeBSD.ORG Subject: Re: infinite loop when copying to ext2fs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 09:27:57 -0000 Martin Cracauer wrote: > Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: >> Jakub Siroky wrote: >>> I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I >>> did not noticed it before because I started using ext2fs extensively >>> some months ago. >>> >>> Regards, >>> Jakub >>> >>> On Sat, 19 Jan 2008 16:44:34 +0100 >>> Kris Kennaway wrote: >>> >>>> Kris Kennaway wrote: >>>>> Jakub Siroky wrote: >>>>>> I have two large ext2fs partitions (368 and 313GB) to hold data >>>>>> shared between several OSes. While there were no problems on >>>>>> 6-STABLE branch I was quite disappointed after upgrade to >>>>>> 7-STABLE. Whenever I copy/write to ext2fs partition the system >>>>>> freezes totally without crashdump. So I set debugging settings to >>>>>> kernel config (DEBUG,WITNESS,..) and in console I reproduced error >>>>>> situation ending with full screen of unstoppable running text with >>>>>> lot of memory addresses and a few recognisable words: 'new block >>>>>> bit set for ext already' - again with no crashdump. Then I have >>>>>> formatted 1GB partition with ext2fs and the problem on this small >>>>>> partition appears only sometimes. >>>>> OK, I am able to reproduce this. >>>>> >>>>> Kris >>>>> >>>> Is anyone able to look at this? I could not spot a candidate change >>>> that has not been merged to 6.x. >>>> >>>> Kris >>> >> Sounds like it may have been broken by the change to ext2_bitops.h by >> cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? > > I don't think my change can cause a new endless loop. > > I only reversed the order of tests to ensure we don't overrun a page > bounddary (into possibly unmapped space). > > - while(*p == ~0U && ofs < sz) { > + while(ofs < sz && *p == ~0U) { > > It is, however, likely that the code was buggy in the first place. > Linux has replaced all this (the allocation code). > > Also note that the code I fixed is amd64 only. If the endless loop > appears on i386 it's something else. > > Martin It is amd64 only. I am able to reproduce using the method in the original mails, can you? Kris From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 11:10:35 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93DBA106564A; Mon, 16 Jun 2008 11:10:35 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mx.npubs.com (mail.wsfamily.com [209.66.100.224]) by mx1.freebsd.org (Postfix) with ESMTP id 44E468FC1A; Mon, 16 Jun 2008 11:10:35 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mx.npubs.com (avhost [209.66.100.194]) by mx.npubs.com (Postfix) with ESMTP id 99F74F181D6; Mon, 16 Jun 2008 11:10:34 +0000 (UTC) Received: from northstar-srv2 (unknown [172.27.2.11]) by mx.npubs.com (Postfix) with ESMTP id E194BF181D4; Mon, 16 Jun 2008 11:10:32 +0000 (UTC) From: Stef Walter User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 References: <20080615112318.146C1F18512@mx.npubs.com> Content-Type: multipart/mixed; boundary="------------010905080203030203030807" Message-Id: <20080616111032.E194BF181D4@mx.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Mon, 16 Jun 2008 11:10:34 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.3 deadlock (interrupted pmap_remove_pages) with DDB output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 11:10:35 -0000 This is a multi-part message in MIME format. --------------010905080203030203030807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stef Walter wrote: > I've been trying to track down a deadlock on some newish production > servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a > specific (although mundane) hardware configuration, and each of several > servers running this hardware deadlock about once per week. > > Although I suspect that this is not hardware related, from a (naive) > perusal of the attached stack traces. Here's another similar deadlock that occurred on an similar machine. Last time pmap_enter was preempted by an interrupt, this time pmap_remove_pages was preempted by a timer. I tried changing machdep.cpu_idle_hlt to zero, based on a hint [1], but that didn't seem to make a difference. Again in this case the processes are waiting on the page queue mutex: python (in trap > trap_pfault > vm_fault) rsync (in ... cluster_read > getblk > getnewbuf > vfs_vmio_release) And another rsync process is holding the vm page queue mutex: rsync (in exit1 > vmspace_exit > pmap_remove_pages) The rsync process in pmap_remove_pages was interrupted by a timer while holding the vm page queue lock and then was not scheduled again. Kernel config and full details attched. I may try building the kernel without PREEMPTION to see if it fixes this problem. Again, any and all advice or hints are welcome. I really appreciate any time spent on this. Stef Walter [1] http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2005-02/0508.html --------------010905080203030203030807 Content-Type: text/plain; name="RACK1DBG" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="RACK1DBG" # # RACK1 # machine i386 cpu I686_CPU ident RACK1 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC options SMP options QUOTA options FAST_IPSEC options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPDIVERT options DUMMYNET options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options KDB options KDB_TRACE options KDB_UNATTENDED options DDB options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN options DIAGNOSTIC options BREAK_TO_DEBUGGER options DEBUG_LOCKS options DEBUG_VFS_LOCKS device crypto # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. #device ahd # AHA39320/29320 and onboard AIC79xx devices #options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. #device amd # AMD 53C974 (Tekram DC-390(T)) #device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module #device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') #device trm # Tekram DC395U/UW/F DC315U adapters #device adv # Advansys SCSI adapters #device adw # Advansys wide SCSI adapters #device aha # Adaptec 154x SCSI adapters #device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. #device bt # Buslogic/Mylex MultiMaster SCSI adapters #device ncv # NCR 53C500 #device nsp # Workbit Ninja SCSI-3 #device stg # TMC 18C30/18C50 # SCSI peripherals device scbus # SCSI bus (required for SCSI) #device ch # SCSI media changers device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) #device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem #device amr # AMI MegaRAID #device arcmsr # Areca SATA II RAID #device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID #device ciss # Compaq Smart RAID 5* #device dpt # DPT Smartcache III, IV - See NOTES for options #device hptmv # Highpoint RocketRAID 182x #device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx #device rr232x # Highpoint RocketRAID 232x device iir # Intel Integrated RAID #device ips # IBM (Adaptec) ServeRAID #device mly # Mylex AcceleRAID/eXtremeRAID #device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers #device aac # Adaptec FSA RAID #device aacp # SCSI passthrough for aac (requires CAM) #device ida # Compaq Smart RAID #device mfi # LSI MegaRAID SAS #device mlx # Mylex DAC960 family #device pst # Promise Supertrak SX6000 #device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor device agp # support several AGP chipsets # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port #device ppc #device ppbus # Parallel port bus (required) #device lpt # Printer #device plip # TCP/IP over parallel #device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to the sio and/or ppc drivers): #device puc # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card #device ixgb # Intel PRO/10GbE Ethernet Card #device txp # 3Com 3cR990 (``Typhoon'') #device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support #device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet #device bfe # Broadcom BCM440x 10/100 Ethernet #device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device lge # Level 1 LXT1001 gigabit Ethernet #device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet #device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking #device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') #device re # RealTek 8139C+/8169/8169S/8110S #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet #device ste # Sundance ST201 (D-Link DFE-550TX) #device stge # Sundance/Tamarack TC9021 gigabit Ethernet #device ti # Alteon Networks Tigon I/II gigabit Ethernet #device tl # Texas Instruments ThunderLAN #device tx # SMC EtherPower II (83c170 ``EPIC'') #device vge # VIA VT612x gigabit Ethernet #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. #device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' #device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards #device ex # Intel EtherExpress Pro/10 and Pro/10+ #device ep # Etherlink III based cards #device fe # Fujitsu MB8696x based cards #device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. #device lnc # NE2100, NE32-VL Lance Ethernet cards #device sn # SMC's 9000 series of Ethernet chips #device xe # Xircom pccard Ethernet # Wireless NIC cards #device wlan # 802.11 support #device wlan_wep # 802.11 WEP support #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device an # Aironet 4500/4800 802.11 wireless NICs. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath #device awi # BayStack 660 and others #device ral # Ralink Technology RT2500 wireless NICs. #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support #device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device ehci # EHCI PCI->USB interface (USB 2.0) #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device ural # Ralink Technology RT2500USB wireless NICs #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners # USB Ethernet, requires miibus #device aue # ADMtek USB Ethernet #device axe # ASIX Electronics USB Ethernet #device cdce # Generic USB over Ethernet #device cue # CATC USB Ethernet #device kue # Kawasaki LSI USB Ethernet #device rue # RealTek RTL8150 USB Ethernet # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) --------------010905080203030203030807 Content-Type: text/plain; name="pmap_remove_pages-deadlock-information.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pmap_remove_pages-deadlock-information.txt" # -------------------------------------------------------------------- # FREEBSD BUILD FreeBSD m1.npubs.com 6.3-RELEASE-p2 FreeBSD 6.3-RELEASE-p2 #0: Tue Jun 10 02:07:06 UTC 2008 nate@m1.npubs.com:/usr/obj/usr/src/sys/RACK1DBG i386 # -------------------------------------------------------------------- # PROCESS LIST db> ps pid ppid pgrp uid state wmesg wchan cmd 69677 69671 4145 65534 LLJ *vm page 0xcf2cc140 python 69674 69654 69486 0 RE rsync 69671 69670 4145 65534 SJ piperd 0xca44a660 python 69670 4145 4145 65534 SJ wait 0xcf673430 sh 69669 4684 4684 125 SJ select 0xc07b7ce4 smtpd 69668 69664 69664 0 S select 0xc07b7ce4 rsync 69664 5663 69664 0 Ls *vm page 0xcf2cc140 rsync 69654 69511 69486 0 S wait 0xca033c90 sh 69561 45988 45982 70 SJ sbwait 0xcabb4bc8 postgres 69557 4141 4141 125 SJ select 0xc07b7ce4 smtp 69541 4141 4141 125 SJ select 0xc07b7ce4 cleanup 69540 4141 4141 125 SJ select 0xc07b7ce4 smtpd 69535 4141 4141 125 SJ select 0xc07b7ce4 trivial-rewrite 69533 4141 4141 125 SJ select 0xc07b7ce4 anvil 69523 4141 4141 125 SJ select 0xc07b7ce4 proxymap 69511 69498 69486 0 S wait 0xc92e7430 sh 69510 4141 4141 125 SJ select 0xc07b7ce4 smtpd 69504 69495 69495 0 SJ sbwait 0xcf2b1638 python 69498 69486 69486 0 S wait 0xca67b648 sh 69495 69492 69495 0 SsJ wait 0xcf6aa218 sh 69492 1374 1374 0 SJ piperd 0xc91c8198 cron 69486 69484 69486 0 Ss wait 0xc92e4c90 sh 69484 691 691 0 S piperd 0xc901b990 cron 69455 1 69455 0 Ls *Giant 0xcf52b6c0 jail-measure 69434 1940 1940 125 SJ kqread 0xc9987a00 trivial-rewrite 69415 1940 1940 0 SJ kqread 0xc9b21700 local 69414 1940 1940 125 SJ kqread 0xca77a600 smtpd 69413 1940 1940 125 SJ kqread 0xc988ee00 smtp 69412 1940 1940 125 SJ kqread 0xcf87b900 cleanup 69400 4684 4684 0 SJ select 0xc07b7ce4 virtual 69379 45988 45982 70 SJ sbwait 0xd0b004d4 postgres 69374 45988 45982 70 SJ sbwait 0xc8f7579c postgres 69372 45988 45982 70 SJ sbwait 0xd08a2d2c postgres 69361 2260 2260 80 SJ accept 0xc97fe5ca httpd 69352 1940 1940 125 SJ lockf 0xc94529c0 smtpd 69335 45988 45982 70 SJ sbwait 0xcf2d5900 postgres 69327 1940 1940 125 SJ lockf 0xc9452740 bounce 69326 1940 1940 125 SJ kqread 0xd0080100 bounce 69276 1940 1940 125 SJ lockf 0xcf5158c0 smtp 69274 1940 1940 125 SJ kqread 0xca333800 smtp 69256 45988 45982 70 SJ sbwait 0xc8ce5638 postgres 69245 45988 45982 70 SJ sbwait 0xc9e23bc8 postgres 69240 45988 45982 70 SJ sbwait 0xd0ad379c postgres 69208 4684 4684 125 SJ select 0xc07b7ce4 smtp 69184 4684 4684 125 SJ select 0xc07b7ce4 smtpd 69183 4684 4684 125 SJ select 0xc07b7ce4 smtp 69182 4684 4684 125 SJ select 0xc07b7ce4 cleanup 69175 1940 1940 125 SJ kqread 0xc993ba00 smtpd 69174 4684 4684 125 SJ select 0xc07b7ce4 trivial-rewrite 69141 45988 45982 70 SJ sbwait 0xd0b030a8 postgres 68996 45988 45982 70 SJ sbwait 0xcf2b1e90 postgres 68790 2260 2260 80 SJ accept 0xc97fe5ca httpd 68693 1940 1940 125 SJ kqread 0xcbf11a00 anvil 68338 4557 4557 125 SJ select 0xc07b7ce4 imapd 68262 45988 45982 70 SJ sbwait 0xc9f54900 postgres 68199 4557 4557 125 SJ select 0xc07b7ce4 imapd 68189 45988 45982 70 SJ sbwait 0xd0afd0a8 postgres 67971 4684 4684 125 SJ select 0xc07b7ce4 proxymap 67135 4684 4684 125 SJ select 0xc07b7ce4 pickup 67085 4557 4557 125 SJ select 0xc07b7ce4 imapd 66421 45988 45982 70 SJ sbwait 0xd0ac9900 postgres 64620 1940 1940 125 SJ kqread 0xcbfa9400 pickup 63268 45988 45982 70 SJ sbwait 0xd0af9d2c postgres 62647 45988 45982 70 SJ sbwait 0xc9f23370 postgres 62453 45988 45982 70 SJ sbwait 0xc8d6379c postgres 62324 4141 4141 125 SJ select 0xc07b7ce4 pickup 59910 2260 2260 80 SJ accept 0xc97fe5ca httpd 58656 3815 3815 80 SJ accept 0xc986d892 httpd 58655 3815 3815 80 SJ accept 0xc986d892 httpd 58641 3815 3815 80 SJ accept 0xc986d892 httpd 58523 2260 2260 80 SJ accept 0xc97fe5ca httpd 58520 2260 2260 80 SJ accept 0xc97fe5ca httpd 58398 2260 2260 80 SJ accept 0xc97fe5ca httpd 57936 2260 2260 80 SJ accept 0xc97fe5ca httpd 55518 2260 2260 80 SJ accept 0xc97fe5ca httpd 49914 2260 2260 80 SJ accept 0xc97fe5ca httpd 46007 1 46007 0 SsJ nanslp 0xc076a96c cron 45999 1 45999 0 SsJ select 0xc07b7ce4 inetd 45993 45992 45982 70 S+J select 0xc07b7ce4 postgres 45992 45988 45982 70 S+J select 0xc07b7ce4 postgres 45991 45988 45982 70 S+J select 0xc07b7ce4 postgres 45989 45988 45982 70 S+J select 0xc07b7ce4 postgres 45988 1 45982 70 S+J select 0xc07b7ce4 postgres 45983 45958 45957 88 S+J (threaded) mysqld 100467 S kserel 0xcf638694 mysqld 100473 S kserel 0xcf638694 mysqld 100358 S kserel 0xcf638694 mysqld 100362 S kserel 0xcf638694 mysqld 100355 S select 0xc07b7ce4 mysqld 100948 S kserel 0xd092cc94 mysqld 100949 S sigwait 0xec446c14 mysqld 100938 S ksesigwa 0xcf6aabb0 mysqld 45958 1 45957 88 S+J wait 0xcf644000 sh 45942 1 45942 0 SsJ select 0xc07b7ce4 sshd 45876 1 45876 0 SsJ select 0xc07b7ce4 syslogd 33626 2260 2260 80 SJ accept 0xc97fe5ca httpd 23070 1336 1336 80 SJ lockf 0xd0401e40 httpd 23069 1336 1336 80 SJ kqread 0xca0be100 httpd 23057 1336 1336 80 SJ lockf 0xcf515680 httpd 22000 1336 1336 80 SJ lockf 0xc9c80380 httpd 21992 1336 1336 80 SJ lockf 0xcf515dc0 httpd 20343 1336 1336 80 SJ lockf 0xc91dd200 httpd 20342 1336 1336 80 SJ lockf 0xd0458ac0 httpd 20341 3815 3815 80 SJ accept 0xc986d892 httpd 20340 1336 1336 80 SJ lockf 0xd0401140 httpd 20339 3815 3815 80 SJ accept 0xc986d892 httpd 20337 1336 1336 80 SJ lockf 0xd0458800 httpd 20336 3815 3815 80 SJ accept 0xc986d892 httpd 20335 3815 3815 80 SJ accept 0xc986d892 httpd 20334 1336 1336 80 SJ lockf 0xcf4eb280 httpd 20333 3815 3815 80 SJ accept 0xc986d892 httpd 20324 20323 20323 0 SJ piperd 0xd02164c8 sockin 20323 4456 20323 0 SsJ wait 0xd092e430 sh 78897 0 0 0 SL ipmireq 0xcf93bec0 [ipmi0: kcs] 65042 64222 64222 70 SJ sbwait 0xcf0f14d4 postgres 64780 64222 64222 70 SJ sbwait 0xcabb4900 postgres 64778 64222 64222 70 SJ sbwait 0xd0af10a8 postgres 64777 64222 64222 70 SJ sbwait 0xc8f96370 postgres 64769 64222 64222 70 SJ sbwait 0xca43e20c postgres 64768 64222 64222 70 SJ sbwait 0xc9a26900 postgres 64767 64222 64222 70 SJ sbwait 0xd0afd4d4 postgres 64742 64222 64222 70 SJ sbwait 0xd0afb638 postgres 64666 64222 64222 70 SJ sbwait 0xccb3579c postgres 64665 64222 64222 70 SJ sbwait 0xd0afc20c postgres 64664 64222 64222 70 SJ sbwait 0xc9e4979c postgres 64663 64222 64222 70 SJ sbwait 0xd05c0e90 postgres 64662 64222 64222 70 SJ sbwait 0xd0ad3d2c postgres 64661 64222 64222 70 SJ sbwait 0xca39a79c postgres 64484 64222 64222 70 SJ sbwait 0xc8d6a370 postgres 64414 64222 64222 70 SJ sbwait 0xc9f2379c postgres 64361 64222 64222 70 SJ sbwait 0xd08a1370 postgres 64349 64222 64222 70 SJ sbwait 0xd05c8370 postgres 64348 64222 64222 70 SJ sbwait 0xcc9b70a8 postgres 64332 64222 64222 70 SJ sbwait 0xd0509a64 postgres 64331 64222 64222 70 SJ sbwait 0xc9a2679c postgres 64227 64226 64222 70 SJ select 0xc07b7ce4 postgres 64226 64222 64222 70 SJ select 0xc07b7ce4 postgres 64225 64222 64222 70 SJ select 0xc07b7ce4 postgres 64223 64222 64222 70 SJ select 0xc07b7ce4 postgres 64222 1 64222 70 SsJ select 0xc07b7ce4 postgres 43040 1114 43040 70 SsJ sbwait 0xca50b370 postgres 75907 4167 4167 1003 RJ CPU 0 stunnel 46911 1 46911 0 SsJ nanslp 0xc076a96c cron 46904 1 46904 0 SsJ select 0xc07b7ce4 sshd 46880 1 46880 0 SsJ (threaded) pdns_server 100752 S kserel 0xcf45e0f4 pdns_server 100748 S kserel 0xcf45e0f4 pdns_server 100695 S kserel 0xcf45e0f4 pdns_server 100171 S kserel 0xcf45e0f4 pdns_server 100464 S sbwait 0xcf7be638 pdns_server 100572 S sbwait 0xca872370 pdns_server 100836 S accept 0xcac13e22 pdns_server 100834 S select 0xc07b7ce4 pdns_server 100784 S ksesigwa 0xcf564bb0 pdns_server 46845 1 46845 389 SsJ (threaded) slapd 100729 S kserel 0xcf638454 slapd 100750 S kserel 0xcf638454 slapd 100747 S select 0xc07b7ce4 slapd 100630 S kserel 0xcf638454 slapd 100512 S kserel 0xcf638454 slapd 100733 S ksesigwa 0xcf6ab998 slapd 46825 1 46825 0 SsJ select 0xc07b7ce4 syslogd 68366 5772 5772 70 SJ sbwait 0xcabb379c postgres 57454 5772 5772 70 SJ sbwait 0xca4124d4 postgres 94638 5772 5772 70 SJ sbwait 0xc9f22bc8 postgres 94626 5772 5772 70 SJ sbwait 0xd052ee90 postgres 85402 5800 5800 80 SJ accept 0xc9cf4892 httpd 85398 5772 5772 70 SJ sbwait 0xceb45e90 postgres 85396 5772 5772 70 SJ sbwait 0xca4b4638 postgres 71130 1114 71130 70 SsJ sbwait 0xc9eeaa64 postgres 71129 1114 71129 70 SsJ sbwait 0xcf2b0bc8 postgres 71128 1114 71128 70 SsJ sbwait 0xc9e484d4 postgres 71127 1114 71127 70 SsJ sbwait 0xcf7bd20c postgres 71126 1114 71126 70 SsJ sbwait 0xc8f76900 postgres 71115 1114 71115 70 SsJ sbwait 0xca50ce90 postgres 71081 71080 71080 89 SJ (threaded) java 100360 S kserel 0xcf5dbe74 java 100255 S kserel 0xcf5dbe74 java 100722 S select 0xc07b7ce4 java 100746 S kserel 0xcf5dbe74 java 100505 S kserel 0xcf5dbe74 java 100409 S sbwait 0xceb88bc8 java 100718 S sbwait 0xca609900 java 100163 S sbwait 0xcf7be79c java 100518 S sbwait 0xca6094d4 java 100778 S sbwait 0xca609370 java 100258 S sbwait 0xc93454d4 java 100506 S ksesigwa 0xcf6ad780 java 71080 1 71080 0 SsJ select 0xc07b7ce4 udb-server 18181 2388 2388 80 SJ accept 0xc986d19e httpd 16803 2388 2388 80 SJ accept 0xc986d19e httpd 16802 2388 2388 80 SJ accept 0xc986d19e httpd 16801 2388 2388 80 SJ accept 0xc986d19e httpd 16795 2388 2388 80 SJ accept 0xc986d19e httpd 7788 5772 5772 70 SJ sbwait 0xc9e240a8 postgres 7723 5772 5772 70 SJ sbwait 0xcabb620c postgres 7705 5772 5772 70 SJ sbwait 0xca8dc370 postgres 7703 5800 5800 80 SJ accept 0xc9cf4892 httpd 7700 5800 5800 80 SJ accept 0xc9cf4892 httpd 7699 5772 5772 70 SJ sbwait 0xca39aa64 postgres 7696 5772 5772 70 SJ sbwait 0xc9cf3638 postgres 7694 5800 5800 80 SJ accept 0xc9cf4892 httpd 6376 4141 4141 125 SJ select 0xc07b7ce4 tlsmgr 5969 3438 3438 80 SJ lockf 0xce4036c0 httpd 5968 3438 3438 80 SJ lockf 0xcaf5dcc0 httpd 5966 3438 3438 80 SJ select 0xc07b7ce4 httpd 5962 3438 3438 80 SJ lockf 0xc94524c0 httpd 5854 5772 5772 70 SJ sbwait 0xca314638 postgres 5852 5800 5800 80 SJ accept 0xc9cf4892 httpd 5851 5800 5800 80 SJ accept 0xc9cf4892 httpd 5850 5800 5800 80 SJ accept 0xc9cf4892 httpd 5849 5800 5800 80 SJ accept 0xc9cf4892 httpd 5848 5800 5800 80 SJ accept 0xc9cf4892 httpd 5827 5826 5826 1020 SJ (threaded) java 100390 S kserel 0xc8e0b034 java 100475 S kserel 0xc8e0b034 java 100418 S kserel 0xc8e0b034 java 100389 S select 0xc07b7ce4 java 100180 S kserel 0xc8e0b034 java 100400 S sbwait 0xc9e49a64 java 100812 S sbwait 0xc9f5420c java 100382 S sbwait 0xc9f54e90 java 100394 S sbwait 0xc9cf3900 java 100388 S sbwait 0xca314370 java 100398 S sbwait 0xca02f370 java 100386 S ksesigwa 0xc8e0d138 java 5826 1 5826 0 SsJ select 0xc07b7ce4 udb-server 5819 1 5819 0 SsJ nanslp 0xc076a96c cron 5812 1 5812 0 SsJ select 0xc07b7ce4 sshd 5809 5805 5800 0 SJ piperd 0xc9cfb7f8 cronolog 5808 5803 5800 0 SJ piperd 0xc9e44b28 cronolog 5805 5800 5800 0 SJ wait 0xc969aa78 sh 5803 5800 5800 0 SJ wait 0xca033648 sh 5800 1 5800 0 SsJ nanslp 0xc076a96c httpd 5788 5787 5772 70 SJ select 0xc07b7ce4 postgres 5787 5772 5772 70 SJ select 0xc07b7ce4 postgres 5786 5772 5772 70 SJ select 0xc07b7ce4 postgres 5772 1 5772 70 SsJ select 0xc07b7ce4 postgres 5713 1 5713 0 SsJ select 0xc07b7ce4 syslogd 5704 1 5704 0 Ss+ ttyin 0xc8a61410 getty 5703 1 5703 0 Ss+ ttyin 0xc8a69c10 getty 5702 1 5702 0 Ss+ ttyin 0xc8a6c010 getty 5701 1 5701 0 Ss+ ttyin 0xc8a6b010 getty 5700 1 5700 0 Ss+ ttyin 0xc8a6a410 getty 5699 1 5699 0 Ss+ ttyin 0xc8a6a810 getty 5698 1 5698 0 Ss+ ttyin 0xc8a60810 getty 5697 1 5697 0 Ss+ ttyin 0xc8a6c410 getty 5696 1 5696 0 Ss+ ttyin 0xc8a6b410 getty 5675 1 5675 0 Ss select 0xc07b7ce4 bsnmpd 5663 1 5663 0 Ss select 0xc07b7ce4 inetd 5443 5442 5442 1020 SJ (threaded) java 100223 S kserel 0xc998b874 java 100095 S kserel 0xc998b874 java 100385 S sbwait 0xd0509978 java 100414 S sbwait 0xd089e814 java 100699 S kserel 0xc998b874 java 100187 S kserel 0xc998b874 java 100229 S select 0xc07b7ce4 java 100736 S sbwait 0xd025379c java 100157 S sbwait 0xc9644f08 java 100338 S ksesigwa 0xc998abb0 java 5442 1 5442 0 SsJ select 0xc07b7ce4 udb-server 5435 1 5435 0 SsJ nanslp 0xc076a96c cron 5419 1 5419 0 SsJ select 0xc07b7ce4 sshd 5265 1 5265 0 SsJ select 0xc07b7ce4 syslogd 4960 1 4960 0 SsJ nanslp 0xc076a96c cron 4953 1 4953 0 SsJ select 0xc07b7ce4 sshd 4906 1 4906 53 SsJ select 0xc07b7ce4 named 4891 1 4891 0 SsJ select 0xc07b7ce4 syslogd 4834 4684 4684 125 SJ select 0xc07b7ce4 anvil 4789 4684 4684 125 SJ select 0xc07b7ce4 tlsmgr 4709 1 4709 0 SsJ nanslp 0xc076a96c cron 4699 1 4699 0 SsJ accept 0xc9dfae22 saslauthd1 4691 4684 4684 125 SJ select 0xc07b7ce4 qmgr 4684 1 4684 0 SsJ select 0xc07b7ce4 master 4598 1 4598 0 SsJ select 0xc07b7ce4 rpc.dracd 4585 4584 4585 0 S+J select 0xc07b7ce4 couriertcpd 4584 1 4584 0 S+J piperd 0xc9cb6b28 courierlogger 4581 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4579 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4578 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4577 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4576 4532 4531 0 S+J select 0xc07b7ce4 authdaemond 4569 4568 4569 0 S+J select 0xc07b7ce4 couriertcpd 4568 1 4568 0 S+J piperd 0xc8e04330 courierlogger 4557 4556 4557 0 S+J select 0xc07b7ce4 couriertcpd 4556 1 4556 0 S+J piperd 0xc8f6e000 courierlogger 4544 4543 4544 0 S+J select 0xc07b7ce4 couriertcpd 4543 1 4543 0 S+J piperd 0xc9cb64c8 courierlogger 4532 4531 4531 0 S+J select 0xc07b7ce4 authdaemond 4531 1 4531 0 S+J piperd 0xc94917f8 courierlogger 4517 1 4517 0 SsJ select 0xc07b7ce4 sshd 4500 1 4500 0 SsJ select 0xc07b7ce4 bsnmpd 4467 1 4467 0 SsJ select 0xc07b7ce4 rpcbind 4456 1 4456 0 SsJ select 0xc07b7ce4 syslogd 4180 1 4180 0 SsJ nanslp 0xc076a96c cron 4172 1 4172 0 SsJ select 0xc07b7ce4 inetd 4167 1 4167 1003 SsJ (threaded) stunnel 100735 S kserel 0xc8e0b454 stunnel 100532 S kserel 0xc8e0b454 stunnel 100189 S kserel 0xc8e0b454 stunnel 100749 S kserel 0xc8e0b454 stunnel 100412 S select 0xc07b7ce4 stunnel 100080 S ksesigwa 0xc8e05780 stunnel 4160 1 4160 0 SsJ accept 0xc986d302 saslauthd1 4149 4141 4141 125 SJ select 0xc07b7ce4 qmgr 4145 1 4145 65534 SsJ (threaded) proxsmtpd 100762 S kserel 0xc8e0b9f4 proxsmtpd 100383 S kserel 0xc8e0b9f4 proxsmtpd 100761 S kserel 0xc8e0b9f4 proxsmtpd 100765 S kserel 0xc8e0b9f4 proxsmtpd 100740 S select 0xc07b7ce4 proxsmtpd 100783 S accept 0xc9a97892 proxsmtpd 100516 S ksesigwa 0xc9b99dc8 proxsmtpd 4141 1 4141 0 SsJ select 0xc07b7ce4 master 4077 1 4077 0 SsJ select 0xc07b7ce4 sshd 4021 1 4021 0 SsJ select 0xc07b7ce4 syslogd 3844 1 3844 0 SsJ select 0xc07b7ce4 inetd 3830 1 3830 0 SsJ nanslp 0xc076a96c cron 3823 1 3823 0 SsJ select 0xc07b7ce4 sshd 3815 1 3815 0 SsJ nanslp 0xc076a96c httpd 3680 1 3680 0 SsJ select 0xc07b7ce4 syslogd 3538 3534 3438 0 SJ piperd 0xc8f69660 cronolog 3537 3531 3438 0 SJ piperd 0xc9311cc0 cronolog 3536 3532 3438 0 SJ piperd 0xc9491b28 cronolog 3535 3438 3438 80 SJ lockf 0xcdedd2c0 httpd 3534 3438 3438 0 SJ wait 0xc8d95a78 sh 3532 3438 3438 0 SJ wait 0xc969a648 sh 3531 3438 3438 0 SJ wait 0xc9828430 sh 3486 3450 3449 88 S+J (threaded) mysqld 100165 S kserel 0xc894d0f4 mysqld 100256 S kserel 0xc894d0f4 mysqld 100176 S kserel 0xc894d0f4 mysqld 100181 S select 0xc07b7ce4 mysqld 100166 S kserel 0xc894d0f4 mysqld 100252 S kserel 0xc894ea54 mysqld 100253 S sigwait 0xec476c14 mysqld 100172 S ksesigwa 0xc8a4d780 mysqld 3479 1 3479 0 SsJ nanslp 0xc076a96c cron 3460 1 3460 0 SsJ select 0xc07b7ce4 inetd 3450 1 3449 88 S+J wait 0xc92e4000 sh 3448 3438 3438 80 SJ select 0xc07b7ce4 httpd 3438 1 3438 0 SsJ select 0xc07b7ce4 httpd 3326 1 3326 0 SsJ select 0xc07b7ce4 sshd 3265 1 3265 0 SsJ select 0xc07b7ce4 syslogd 2983 1 2983 0 SsJ nanslp 0xc076a96c cron 2976 1 2976 0 SsJ select 0xc07b7ce4 sshd 2968 1 2968 0 SsJ (threaded) httpauthd 100179 S kserel 0xc93a0454 httpauthd 100741 S kserel 0xc93a0454 httpauthd 100760 S kserel 0xc93a0454 httpauthd 100730 S kserel 0xc93a0454 httpauthd 100185 S sbwait 0xca02fd2c httpauthd 100593 S sbwait 0xceb5c79c httpauthd 100404 S sbwait 0xd05c8a64 httpauthd 100191 S sbwait 0xca43fd2c httpauthd 100393 S sbwait 0xca8dc20c httpauthd 100417 S sbwait 0xca41c638 httpauthd 100359 S sbwait 0xd05c04d4 httpauthd 100468 S sbwait 0xc9f224d4 httpauthd 100273 S sbwait 0xca50b638 httpauthd 100408 S sbwait 0xca50b0a8 httpauthd 100357 S sbwait 0xcabb7a64 httpauthd 100254 S sbwait 0xcf2b3900 httpauthd 100173 S sbwait 0xcf0f2900 httpauthd 100251 S sbwait 0xca50cbc8 httpauthd 100226 S sbwait 0xd0af00a8 httpauthd 100221 S sbwait 0xc9eeabc8 httpauthd 100391 S sbwait 0xca41c900 httpauthd 100162 S sbwait 0xcca28a64 httpauthd 100352 S sbwait 0xd0b01900 httpauthd 100421 S sbwait 0xc97a64d4 httpauthd 100411 S sbwait 0xd0b0120c httpauthd 100479 S accept 0xc9800892 httpauthd 100169 S sbwait 0xca41c370 httpauthd 100396 S sbwait 0xca4110a8 httpauthd 100265 S sbwait 0xcf2d5d2c httpauthd 100402 S sbwait 0xca411e90 httpauthd 100781 S sbwait 0xcf0f2bc8 httpauthd 100183 S sbwait 0xc95b7bc8 httpauthd 100356 S sbwait 0xd0afc638 httpauthd 100502 S sbwait 0xc9df8370 httpauthd 100751 S sbwait 0xc97ff0a8 httpauthd 100500 S sbwait 0xc900b0a8 httpauthd 100513 S sbwait 0xc9a794d4 httpauthd 100170 S sbwait 0xcabaf20c httpauthd 100476 S sbwait 0xc8d6a900 httpauthd 100851 S sbwait 0xca39b79c httpauthd 100274 S sbwait 0xceb44900 httpauthd 100510 S sbwait 0xca8dc79c httpauthd 100936 S sbwait 0xc986d4d4 httpauthd 100419 S sbwait 0xcabaf900 httpauthd 100711 S sbwait 0xd05aca64 httpauthd 100533 S sbwait 0xcefa7a64 httpauthd 100250 S sbwait 0xd0aef0a8 httpauthd 100422 S sbwait 0xcabb3a64 httpauthd 100405 S sbwait 0xc91dfd2c httpauthd 100514 S sbwait 0xd0ad34d4 httpauthd 100482 S sbwait 0xc9f23bc8 httpauthd 100470 S sbwait 0xc9e4879c httpauthd 100410 S sbwait 0xc96af4d4 httpauthd 100614 S sbwait 0xca50c20c httpauthd 100801 S sbwait 0xc9eea370 httpauthd 100175 S sbwait 0xd0ac9638 httpauthd 100737 S sbwait 0xd089ee90 httpauthd 100403 S ksesigwa 0xc93a1bb0 httpauthd 2920 1 2920 389 SsJ (threaded) slapd 100186 S kserel 0xc8ddedb4 slapd 100497 S kserel 0xc8ddedb4 slapd 100763 S kserel 0xc8ddedb4 slapd 100469 S kserel 0xc8ddedb4 slapd 100471 S select 0xc07b7ce4 slapd 100136 S ksesigwa 0xc8e0d998 slapd 2900 1 2900 0 SsJ select 0xc07b7ce4 syslogd 2668 1 2668 0 SsJ select 0xc07b7ce4 slapd 2661 1 2661 0 SsJ nanslp 0xc076a96c cron 2654 1 2654 0 SsJ select 0xc07b7ce4 sshd 2599 1 2599 0 SsJ select 0xc07b7ce4 syslogd 2547 2388 2388 80 SJ accept 0xc986d19e httpd 2546 2388 2388 80 SJ accept 0xc986d19e httpd 2545 2388 2388 80 SJ accept 0xc986d19e httpd 2544 2388 2388 80 SJ accept 0xc986d19e httpd 2543 2388 2388 80 SJ accept 0xc986d19e httpd 2403 1 2403 0 SsJ nanslp 0xc076a96c cron 2396 1 2396 0 SsJ select 0xc07b7ce4 sshd 2388 1 2388 0 SsJ nanslp 0xc076a96c httpd 2289 1 2289 0 SsJ select 0xc07b7ce4 inetd 2275 1 2275 0 SsJ nanslp 0xc076a96c cron 2268 1 2268 0 SsJ select 0xc07b7ce4 sshd 2260 1 2260 0 SsJ nanslp 0xc076a96c httpd 2206 1 2206 0 SsJ select 0xc07b7ce4 syslogd 2006 1951 1950 88 S+J (threaded) mysqld 100161 S kserel 0xc93a0514 mysqld 100038 S kserel 0xc93a0514 mysqld 100167 S kserel 0xc93a0514 mysqld 100225 S select 0xc07b7ce4 mysqld 100091 S kserel 0xc93a0514 mysqld 100222 S sigwait 0xec3e1c14 mysqld 100219 S ksesigwa 0xc93a1780 mysqld 1951 1 1950 88 S+J wait 0xc939f430 sh 1949 1940 1940 125 SJ kqread 0xc97a9b00 qmgr 1940 1 1940 0 SsJ kqread 0xc969eb00 master 1800 1795 1800 70 SsJ select 0xc07b7ce4 postgres 1799 1795 1799 70 SsJ nanslp 0xc076a96c postgres 1798 1795 1798 70 SsJ nanslp 0xc076a96c postgres 1797 1795 1797 70 SsJ nanslp 0xc076a96c postgres 1795 1 1791 70 S+J select 0xc07b7ce4 postgres 1765 1760 1760 0 SJ lockf 0xcca4ed00 saslauthd 1763 1760 1760 0 SJ lockf 0xca55b240 saslauthd 1762 1760 1760 0 SJ lockf 0xcf50de40 saslauthd 1761 1760 1760 0 SJ accept 0xc8f76cbe saslauthd 1760 1 1760 0 SsJ lockf 0xcff97c00 saslauthd 1731 1 1731 0 SsJ select 0xc07b7ce4 syslogd 1374 1 1374 0 SsJ nanslp 0xc076a96c cron 1364 1 1364 0 SsJ select 0xc07b7ce4 sshd 1336 1 1336 0 SsJ nanslp 0xc076a96c httpd 1117 1114 1117 70 SsJ select 0xc07b7ce4 postgres 1116 1114 1116 70 SsJ select 0xc07b7ce4 postgres 1114 1 1114 70 SsJ select 0xc07b7ce4 postgres 1057 1 1057 0 SsJ select 0xc07b7ce4 syslogd 691 1 691 0 Ss nanslp 0xc076a96c cron 685 1 685 25 Ss pause 0xc8cf0894 sendmail 681 1 681 0 Ss select 0xc07b7ce4 sendmail 675 1 675 0 Ss select 0xc07b7ce4 sshd 655 1 654 0 S nanslp 0xc076a96c python 615 1 615 0 Ss select 0xc07b7ce4 ntpd 525 1 525 0 Ss select 0xc07b7ce4 syslogd 470 1 470 0 Ss select 0xc07b7ce4 devd 41 0 0 0 SL - 0xe9c77d04 [schedcpu] 40 0 0 0 SL sdflush 0xc07c9294 [softdepflush] 39 0 0 0 SL syncer 0xc076a6dc [syncer] 38 0 0 0 SL vlruwt 0xc8a07c90 [vnlru] 37 0 0 0 SL psleep 0xc07b8260 [bufdaemon] 36 0 0 0 SL pgzero 0xc07ca264 [pagezero] 35 0 0 0 SL psleep 0xc07c9d6c [vmdaemon] 34 0 0 0 SL psleep 0xc07c9d28 [pagedaemon] 33 0 0 0 SL - 0xc8bee580 [dummynet] 32 0 0 0 WL [swi0: sio] 31 0 0 0 WL [irq1: atkbd0] 30 0 0 0 WL [irq19: atapci1] 29 0 0 0 WL [irq15: ata1] 28 0 0 0 WL [irq14: ata0] 27 0 0 0 LL *Giant 0xcf52b6c0 [irq17: em1] 26 0 0 0 LL *Giant 0xcf52b6c0 [irq16: em0] 25 0 0 0 WL [irq9: acpi0] 24 0 0 0 SL - 0xc89a2c00 [thread taskq] 23 0 0 0 SL - 0xc89a2c80 [acpi_task_2] 22 0 0 0 SL - 0xc89a2c80 [acpi_task_1] 9 0 0 0 SL - 0xc89a2c80 [acpi_task_0] 21 0 0 0 WL [swi6: Giant taskq] 20 0 0 0 WL [swi6: task queue] 19 0 0 0 WL [swi2: cambio] 8 0 0 0 SL ccb_scan 0xc0752ae4 [xpt_thrd] 7 0 0 0 SL - 0xc89ef180 [kqueue taskq] 18 0 0 0 WL [swi5: +] 17 0 0 0 SL - 0xc0767320 [yarrow] 6 0 0 0 SL crypto_r 0xc07c8ec4 [crypto returns] 5 0 0 0 SL crypto_w 0xc07c8e84 [crypto] 4 0 0 0 SL - 0xc0767e28 [g_down] 3 0 0 0 SL - 0xc0767e24 [g_up] 2 0 0 0 SL - 0xc0767e1c [g_event] 16 0 0 0 WL [swi3: vm] 15 0 0 0 LL *Giant 0xcf52b6c0 [swi4: clock sio] 14 0 0 0 WL [swi1: net] 13 0 0 0 RL [idle: cpu0] 12 0 0 0 RL CPU 1 [idle: cpu1] 11 0 0 0 RL CPU 2 [idle: cpu2] 10 0 0 0 RL CPU 3 [idle: cpu3] 1 0 1 0 SLs wait 0xc894f000 [init] 0 0 0 0 WLs [swapper] # -------------------------------------------------------------------- # CPU INFO db> show pcpu cpuid = 1 curthread = 0xc894a900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894a900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0xcf2ba780: pid 75907 "stunnel" curpcb = 0xed1b1d90 fpcurthread = none idlethread = 0xc894aa80: pid 13 "idle: cpu0" APIC ID = 0 currentldt = 0x58 spin locks held: cpuid = 1 curthread = 0xc894a900: pid 12 "idle: cpu1" curpcb = 0xe81f2d90 fpcurthread = none idlethread = 0xc894a900: pid 12 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: cpuid = 2 curthread = 0xc894a780: pid 11 "idle: cpu2" curpcb = 0xe81efd90 fpcurthread = none idlethread = 0xc894a780: pid 11 "idle: cpu2" APIC ID = 2 currentldt = 0x50 spin locks held: cpuid = 3 curthread = 0xc894a600: pid 10 "idle: cpu3" curpcb = 0xe81ecd90 fpcurthread = none idlethread = 0xc894a600: pid 10 "idle: cpu3" APIC ID = 3 currentldt = 0x50 spin locks held: # -------------------------------------------------------------------- # LOCK INFO db> show locks db> show alllocks Process 69677 (python) thread 0xca239900 (100432) exclusive sleep mutex vm object (standard object) r = 0 (0xce1f3420) locked @ /usr/src/sys/vm/vm_fault.c:688 exclusive sx user map r = 0 (0xcf67f4e4) locked @ /usr/src/sys/vm/vm_map.c:3105 Process 69674 (rsync) thread 0xc8cf5a80 (100132) exclusive sleep mutex pmap r = 0 (0xcf5b87b0) locked @ /usr/src/sys/i386/i386/pmap.c:2749 exclusive sleep mutex vm page queue mutex r = 0 (0xc07c9ce0) locked @ /usr/src/sys/i386/i386/pmap.c:2748 Process 69664 (rsync) thread 0xca239480 (100485) exclusive sleep mutex vm object (standard object) r = 0 (0xcc3ad528) locked @ /usr/src/sys/kern/vfs_bio.c:1480 exclusive sleep mutex Giant r = 0 (0xc076a080) locked @ /usr/src/sys/kern/vfs_vnops.c:492 db> show lockedvnods Locked vnodes 0xccc2e414: tag ufs, type VREG usecount 1, writecount 0, refcount 5965 mountedhere 0 flags () v_object 0xcc3ad528 ref 0 pages 81936 lock type ufs: SHARED (count 1)#0 0xc04fa690 at lockmgr+0x160 #1 0xc0649d8a at ffs_lock+0x76 #2 0xc06bf8bb at VOP_LOCK_APV+0x87 #3 0xc056a59c at vn_lock+0xac #4 0xc0569c72 at vn_read+0x132 #5 0xc052c741 at dofileread+0x85 #6 0xc052c5da at kern_readv+0x36 #7 0xc052c505 at read+0x45 #8 0xc06acec3 at syscall+0x25b #9 0xc06984df at Xint0x80_syscall+0x1f ino 13262597, on dev ad8s1e # -------------------------------------------------------------------- # PROCESS STACK TRACES # PYTHON db> trace 69677 Tracing pid 69677 tid 100432 td 0xca239900 sched_switch(ca239900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07c9ce0,c8cf5a80,0,c07c9ce0,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07c9ce0,ca239900,0,c07075e5,15a) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07c9ce0,0,c07075e5,15a,c06eba6d,...) at _mtx_lock_flags+0xa2 vm_fault(cf67f4a0,8147000,2,8,ca239900,...) at vm_fault+0x311 trap_pfault(ec755d38,1,8147f20,8147f20,0,...) at trap_pfault+0xce trap(812003b,811003b,bfbf003b,812511c,8147f20,...) at trap+0x1eb calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x8073f3c, esp = 0xbfbfda00, ebp = 0xbfbfda28 --- # RSYNC db> trace 69664 Tracing pid 69664 tid 100485 td 0xca239480 sched_switch(ca239480,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c07c9ce0,c8cf5a80,0,c07c9ce0,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c07c9ce0,ca239480,0,c06f2142,5c9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c07c9ce0,0,c06f2142,5c9,cc3ad528,...) at _mtx_lock_flags+0xa2 vfs_vmio_release(dcc09838) at vfs_vmio_release+0x35 getnewbuf(0,0,4000,4000) at getnewbuf+0x276 getblk(ccc2e414,236e,0,4000,0,...) at getblk+0x3b3 cluster_read(ccc2e414,14002000,0,236e,0,...) at cluster_read+0xde ffs_read(ec74cbf4) at ffs_read+0x2d6 VOP_READ_APV(c0741260,ec74cbf4) at VOP_READ_APV+0x9b vn_read(cb7676c0,ec74ccbc,c94d6a00,0,ca239480) at vn_read+0x1fb dofileread(ca239480,5,cb7676c0,ec74ccbc,ffffffff,...) at dofileread+0x85 kern_readv(ca239480,5,ec74ccbc,85063e8,42d10,...) at kern_readv+0x36 read(ca239480,ec74cd04) at read+0x45 syscall(3b,3b,3b,0,430f8,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x28185a63, esp = 0xbfbf987c, ebp = 0xbfbf98c8 --- # RSYNC db> trace 69674 Tracing pid 69674 tid 100132 td 0xc8cf5a80 sched_switch(c8cf5a80,0,2) at sched_switch+0x177 mi_switch(2,0,c076a040,0,c06eba6d,...) at mi_switch+0x270 critical_exit(c5e1bd38,e9f25c30,c0698a70,0,e9f20008,...) at critical_exit+0x8b lapic_handle_timer(0) at lapic_handle_timer+0xe1 Xtimerint(c5e1bd38,cf5b87b0,28120000,e9f25c48) at Xtimerint+0x30 pmap_remove_pages(cf5b87b0,0,bfc00000) at pmap_remove_pages+0x1c2 vmspace_exit(c8cf5a80,c076a240,0,c06e6c7d,125,...) at vmspace_exit+0x97 exit1(c8cf5a80,0,e9f25d30,c06acec3,c8cf5a80,...) at exit1+0x496 exit1(c8cf5a80,e9f25d04) at exit1 syscall(3b,3b,3b,8088eda,407,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x2818520b, esp = 0xbfbfd82c, ebp = 0xbfbfd848 --- # JAIL-MEASURE db> trace 69455 Tracing pid 69455 tid 100839 td 0xc9a5d780 sched_switch(c9a5d780,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c076a080,ca239480,0,c076a080,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c076a080,c9a5d780,0,c06f3435,c1) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c076a080,0,c06f3435,c1) at _mtx_lock_flags+0xa2 namei(ece75ba0) at namei+0x227 kern_lstat(c9a5d780,80637a8,0,ece75c74) at kern_lstat+0x47 lstat(c9a5d780,ece75d04) at lstat+0x1b syscall(805003b,805003b,bfbf003b,8063748,8063700,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (190, FreeBSD ELF32, lstat), eip = 0x28159b47, esp = 0xbfbfeafc, ebp = 0xbfbfeb98 --- # EM1 db> trace 27 Tracing pid 27 tid 100017 td 0xc894c900 sched_switch(c894c900,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c076a080,ca239480,0,c076a080,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c076a080,c894c900,0,c06e6f85,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c076a080,0,c06e6f85,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a3648,c89a0480) at ithread_execute_handlers+0xde ithread_loop(c8a2cae0,e8210d38,c8a2cae0,c04f290c,0,...) at ithread_loop+0x67 fork_exit(c04f290c,c8a2cae0,e8210d38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe8210d6c, ebp = 0 --- # EM0 db> trace 26 Tracing pid 26 tid 100018 td 0xc894c780 sched_switch(c894c780,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 turnstile_wait(c076a080,ca239480,0,c076a080,2,c06e8e2b,233) at turnstile_wait+0x35a _mtx_lock_sleep(c076a080,c894c780,0,c06e6f85,2a9) at _mtx_lock_sleep+0x14c _mtx_lock_flags(c076a080,0,c06e6f85,2a9) at _mtx_lock_flags+0xa2 ithread_execute_handlers(c89a3860,c89a0500) at ithread_execute_handlers+0xde ithread_loop(c8a2cc40,e820dd38,c8a2cc40,c04f290c,0,...) at ithread_loop+0x67 fork_exit(c04f290c,c8a2cc40,e820dd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe820dd6c, ebp = 0 --- # -------------------------------------------------------------------- # OTHER INFO db> x cpu_idle_hlt cpu_idle_hlt: 0 --------------010905080203030203030807-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 11:21:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02AE2106564A for ; Mon, 16 Jun 2008 11:21:21 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id B34D48FC0A for ; Mon, 16 Jun 2008 11:21:20 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.18.98.62] (brmea-proxy-1.Sun.COM [192.18.98.62]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 18D4E13DF92 for ; Mon, 16 Jun 2008 15:21:17 +0400 (MSD) Message-ID: <48564CAB.4030102@FreeBSD.org> Date: Mon, 16 Jun 2008 15:21:15 +0400 From: Lev Serebryakov Organization: FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.14) Gecko/20071210 Thunderbird/1.5.0.14 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <372651116.20080615162317@serebryakov.spb.ru> <941206638.20080615163521@serebryakov.spb.ru> <485612AD.2000301@FreeBSD.org> In-Reply-To: <485612AD.2000301@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 7-STABLE deadlock! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 11:21:21 -0000 Lev Serebryakov wrote: > It seems to be ATA/SATA or UFS2 problem: now I have computer in state, > when 4 iozone processes are hanged in "Disk wait" state, and I can not > "cd" to filesystem, which is tested by "iozone". > But I can create processes, work on system, etc., if I don't touch this > filesystem. I can reproduce it, creating gmirror on 5 disks (yes, not very useful configuration, but I've started from non-base-system RAID5 and need to exclude it), FS with 64Kb blocks, and 4 threads of iozone with mixed workload (-i 8 -+p 70). All 5 disks are ICH9DO-based, SATA-II WD5000AAKS HDDs. -- // Lev Serebryakov From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 11:36:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F627106567F for ; Mon, 16 Jun 2008 11:36:24 +0000 (UTC) (envelope-from zhpalt@gmail.com) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.227]) by mx1.freebsd.org (Postfix) with ESMTP id BC3908FC14 for ; Mon, 16 Jun 2008 11:36:23 +0000 (UTC) (envelope-from zhpalt@gmail.com) Received: by qb-out-0506.google.com with SMTP id b14so1934210qbc.35 for ; Mon, 16 Jun 2008 04:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=gUZhKHoOGyk+7HsahJwgkiSDG9pXQYGHjd4fV6IEdlM=; b=MVnt6EH7X4fWlpaDRlNcPixUcFNsu/yMQEaer+GnT0Pv5NGWCW5B5dnRRRPfToa5Mr DMubR+cuUxLVHxTHtOeW6xSpw+k5GU/SVLddHAS3GefrtqKO0fOnHbrg31nP10+kySyP qC2RAE65Avm9FfrjFw5C/9oDeZo1Nn5y3fJ6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=WtpWXKQVGeCHTs8fl2m/cMvARs9GeEpWEym8MKiI7uuwZL1tRnKtI2yGeiUOE6f+G+ 8rHCXJY+WbCoSWDemu9gRoHSXbyboDFb+bgAUMMJMJAP62t/lWY1NhLk1SStE1y9+5Eo Ugmb0R+CVd7O2Rm+jaG6Ba+3AmoC6XPO+Hpoo= Received: by 10.143.8.10 with SMTP id l10mr2277126wfi.340.1213616182743; Mon, 16 Jun 2008 04:36:22 -0700 (PDT) Received: from ?192.168.1.100? ( [222.172.214.19]) by mx.google.com with ESMTPS id 9sm11604353wfc.6.2008.06.16.04.36.18 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Jun 2008 04:36:21 -0700 (PDT) From: Palette To: freebsd-stable@freebsd.org In-Reply-To: <20080615120023.208DE10656F2@hub.freebsd.org> References: <20080615120023.208DE10656F2@hub.freebsd.org> Content-Type: text/plain Date: Mon, 16 Jun 2008 19:36:05 +0800 Message-Id: <1213616165.15253.6.camel@Artemis.site> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 7bit Subject: Re: Re: Under gnome-2.22.2, can not lock the screen X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 11:36:24 -0000 No, the hald is not running, I suppose it's the reason. > hald not running? I had the same problem when using Gentoo. > > HTH, > Sorin. > > Pallt wrote: > > Hi! > > The version of the freebsd is 7.0-stable(June 9 2008), and the gnome was > > also updated to 2.22.2. > > But, I can not lock the screen, when I click the "Lock Screen" button > > under System Menu(The acpi can works well). I can't find the right way > > to let it work. > > Thanks any way > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 12:16:13 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 296C8106567B; Mon, 16 Jun 2008 12:16:13 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id AB5298FC25; Mon, 16 Jun 2008 12:16:12 +0000 (UTC) (envelope-from cracauer@koef.zs64.net) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by koef.zs64.net (8.14.3/8.14.3) with ESMTP id m5GCG9F7027079; Mon, 16 Jun 2008 14:16:09 +0200 (CEST) (envelope-from cracauer@koef.zs64.net) Received: (from cracauer@localhost) by koef.zs64.net (8.14.3/8.14.3/Submit) id m5GCG9Zp027078; Mon, 16 Jun 2008 08:16:09 -0400 (EDT) (envelope-from cracauer) Date: Mon, 16 Jun 2008 08:16:09 -0400 From: Martin Cracauer To: Kris Kennaway Message-ID: <20080616121609.GA26978@cons.org> References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> <20080616034258.GA94873@cons.org> <48563219.9070306@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48563219.9070306@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: maxim@FreeBSD.org, freebsd-stable@FreeBSD.org, Jakub Siroky , freebsd-fs@FreeBSD.org, cracauer@FreeBSD.org, Martin Cracauer Subject: Re: infinite loop when copying to ext2fs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 12:16:13 -0000 Kris Kennaway wrote on Mon, Jun 16, 2008 at 11:27:53AM +0200: > Martin Cracauer wrote: > >Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: > >>Jakub Siroky wrote: > >>>I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I > >>>did not noticed it before because I started using ext2fs extensively > >>>some months ago. > >>> > >>>Regards, > >>>Jakub > >>> > >>>On Sat, 19 Jan 2008 16:44:34 +0100 > >>>Kris Kennaway wrote: > >>> > >>>>Kris Kennaway wrote: > >>>>>Jakub Siroky wrote: > >>>>>>I have two large ext2fs partitions (368 and 313GB) to hold data > >>>>>>shared between several OSes. While there were no problems on > >>>>>>6-STABLE branch I was quite disappointed after upgrade to > >>>>>>7-STABLE. Whenever I copy/write to ext2fs partition the system > >>>>>>freezes totally without crashdump. So I set debugging settings to > >>>>>>kernel config (DEBUG,WITNESS,..) and in console I reproduced error > >>>>>>situation ending with full screen of unstoppable running text with > >>>>>>lot of memory addresses and a few recognisable words: 'new block > >>>>>>bit set for ext already' - again with no crashdump. Then I have > >>>>>>formatted 1GB partition with ext2fs and the problem on this small > >>>>>>partition appears only sometimes. > >>>>>OK, I am able to reproduce this. > >>>>> > >>>>>Kris > >>>>> > >>>>Is anyone able to look at this? I could not spot a candidate change > >>>>that has not been merged to 6.x. > >>>> > >>>>Kris > >>> > >>Sounds like it may have been broken by the change to ext2_bitops.h by > >>cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? > > > >I don't think my change can cause a new endless loop. > > > >I only reversed the order of tests to ensure we don't overrun a page > >bounddary (into possibly unmapped space). > > > >- while(*p == ~0U && ofs < sz) { > >+ while(ofs < sz && *p == ~0U) { > > > >It is, however, likely that the code was buggy in the first place. > >Linux has replaced all this (the allocation code). > > > >Also note that the code I fixed is amd64 only. If the endless loop > >appears on i386 it's something else. > > > >Martin > > It is amd64 only. I am able to reproduce using the method in the > original mails, can you? Didn't try yet, but I did get a probably unrelated panic on ext2fs just last week :-) I'll fire it up this week. How big does the partition have to be to show the problem in this bug? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-stable@FreeBSD.ORG Mon Jun 16 12:54:05 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C726106568C; Mon, 16 Jun 2008 12:54:05 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 21C6C8FC41; Mon, 16 Jun 2008 12:54:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <48566269.2050001@FreeBSD.org> Date: Mon, 16 Jun 2008 14:54:01 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Martin Cracauer References: <20080118120140.2a8170a0@dev> <47921931.9050606@FreeBSD.org> <47921AE2.1060004@FreeBSD.org> <20080301220924.72bf355d@dev.citybikes.cz> <47C9C912.1020700@FreeBSD.org> <20080616034258.GA94873@cons.org> <48563219.9070306@FreeBSD.org> <20080616121609.GA26978@cons.org> In-Reply-To: <20080616121609.GA26978@cons.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org, cracauer@FreeBSD.org, Jakub Siroky , freebsd-stable@FreeBSD.org, maxim@FreeBSD.org Subject: Re: infinite loop when copying to ext2fs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2008 12:54:05 -0000 Martin Cracauer wrote: > Kris Kennaway wrote on Mon, Jun 16, 2008 at 11:27:53AM +0200: >> Martin Cracauer wrote: >>> Kris Kennaway wrote on Sat, Mar 01, 2008 at 10:22:26PM +0100: >>>> Jakub Siroky wrote: >>>>> I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I >>>>> did not noticed it before because I started using ext2fs extensively >>>>> some months ago. >>>>> >>>>> Regards, >>>>> Jakub >>>>> >>>>> On Sat, 19 Jan 2008 16:44:34 +0100 >>>>> Kris Kennaway wrote: >>>>> >>>>>> Kris Kennaway wrote: >>>>>>> Jakub Siroky wrote: >>>>>>>> I have two large ext2fs partitions (368 and 313GB) to hold data >>>>>>>> shared between several OSes. While there were no problems on >>>>>>>> 6-STABLE branch I was quite disappointed after upgrade to >>>>>>>> 7-STABLE. Whenever I copy/write to ext2fs partition the system >>>>>>>> freezes totally without crashdump. So I set debugging settings to >>>>>>>> kernel config (DEBUG,WITNESS,..) and in console I reproduced error >>>>>>>> situation ending with full screen of unstoppable running text with >>>>>>>> lot of memory addresses and a few recognisable words: 'new block >>>>>>>> bit set for ext already' - again with no crashdump. Then I have >>>>>>>> formatted 1GB partition with ext2fs and the problem on this small >>>>>>>> partition appears only sometimes. >>>>>>> OK, I am able to reproduce this. >>>>>>> >>>>>>> Kris >>>>>>> >>>>>> Is anyone able to look at this? I could not spot a candidate change >>>>>> that has not been merged to 6.x. >>>>>> >>>>>> Kris >>>> Sounds like it may have been broken by the change to ext2_bitops.h by >>>> cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? >>> I don't think my change can cause a new endless loop. >>> >>> I only reversed the order of tests to ensure we don't overrun a page >>> bounddary (into possibly unmapped space). >>> >>> - while(*p == ~0U && ofs < sz) { >>> + while(ofs < sz && *p == ~0U) { >>> >>> It is, however, likely that the code was buggy in the first place. >>> Linux has replaced all this (the allocation code). >>> >>> Also note that the code I fixed is amd64 only. If the endless loop >>> appears on i386 it's something else. >>> >>> Martin >> It is amd64 only. I am able to reproduce using the method in the >> original mails, can you? > > Didn't try yet, but I did get a probably unrelated panic on ext2fs > just last week :-) I'll fire it up this week. > > How big does the partition have to be to show the problem in this bug? Sorry, I don't remember. I probably tried it on a md that was a couple of GB. Kris From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 00:47:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B761A1065671 for ; Tue, 17 Jun 2008 00:47:24 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 070CE8FC28 for ; Tue, 17 Jun 2008 00:47:23 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m5H0YAdP053199 for ; Mon, 16 Jun 2008 19:34:10 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Mon Jun 16 19:34:10 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m5H0YANs053194 for freebsd-stable@freebsd.org; Mon, 16 Jun 2008 19:34:10 -0500 (CDT) (envelope-from karl) Date: Mon, 16 Jun 2008 19:34:10 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080617003410.GA52476@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: MFI driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 00:47:24 -0000 Hi folks; I have acquired a rackmount Intel server with a RAID card in it that appears to be compatable with the MFI driver. To put it mildly, this thing SMOKES! It is SCREAMING fast. Insane, in fact. Ok, enough supurlatives. Now the question is this - exactly what board(s) will this driver support? Is it only the two that are listed in the hardware release notes? LSI has a number of "MegaRaid" boards, but it does not appear that they are all supported - or are they? The ones that ARE listed as supported are INSANELY expensive - like $800+! I'd love to buy one of these for a couple of my other machines, but at that sort of price..... perhaps not. -- Karl Denninger From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 01:21:49 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E301106566B for ; Tue, 17 Jun 2008 01:21:49 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 320768FC0C for ; Tue, 17 Jun 2008 01:21:49 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m5H1Krcu085279 for ; Mon, 16 Jun 2008 20:20:53 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Mon Jun 16 20:20:53 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m5H1Kr1g085276 for freebsd-stable@freebsd.org; Mon, 16 Jun 2008 20:20:53 -0500 (CDT) (envelope-from karl) Date: Mon, 16 Jun 2008 20:20:53 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080617012053.GA82316@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Best-performing disk I/O options for a DBMS server on 7-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 01:21:49 -0000 On Thu, May 08, 2008 at 10:30:01AM +0100, Pete French wrote: > > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > > have been out of the loop on the card(s) that work properly for a good long > > while. > > HP P400 cards are PCI express and SAS - they work very well under FreeBSD. > I've also used the cheaper E200 and that appears to be fine too, though I > havent run it for as long as the 400's. > > http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html > > -pete. > Following upon my own stuff, I just laid hands on a Quad-Xeon machine with an Intel SRCSAS18E card in it, and well, the only way I can describe it is "oh my GOD!" Off a couple of older 250GB SATA drives, mirrored, it sustained 70MB/sec over the entire disk's volume space on reads and had ZERO visible impact on CPU OR another process doing mixed I/O at the same time (!). That's impressive. If its stable. The cards are not cheap, however. The only "gotcha" is that all configuration of the drive(s) appears to be done through the controller. I assume I COULD use something like gmirror, but see little reason to do so. -- Karl Denninger karl@denninger.net From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 07:04:48 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9CDD1065676 for ; Tue, 17 Jun 2008 07:04:48 +0000 (UTC) (envelope-from salex772@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8498FC1F for ; Tue, 17 Jun 2008 07:04:47 +0000 (UTC) (envelope-from salex772@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so4080248fgb.35 for ; Tue, 17 Jun 2008 00:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id :disposition-notification-to:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=qTgMxT/tbV+cfZZWRmR48fTjlW2zx7T+5hWb5yHsYgM=; b=xiTF42bFq40FEEyjVDmLs6muHaIkkntOToe5APCdy7ATOBpd2QEQALIZVAEGMOZ1Q4 gXMkt+L59pBQwQdCf8joqCK9cYrSSTHuJTToHm9bINtyrayyRGmGvORmGQduZ4DYn6/S uiaI7nBfP5IkP7J3e5qDqc29WVLG8rtcw9lz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; b=CMQmM0Tc/mvIg32Ezr8J9A2N/PM24ZtslUFzsvi98i6DvbMTlcglPlrAFuWfJ4jyFp 2awLoh6KuDdWq/Bk5XMBlL+xjCd/70Gq+nweMm447qMFsPF2t5So9jtokxQLCUCRzXEf TCe3240wHVrChIjrP5WLVxDv8qH7De/ik7erI= Received: by 10.86.100.19 with SMTP id x19mr8792862fgb.34.1213684774720; Mon, 16 Jun 2008 23:39:34 -0700 (PDT) Received: from ?192.168.1.2? ( [91.76.172.244]) by mx.google.com with ESMTPS id l19sm12951826fgb.7.2008.06.16.23.39.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Jun 2008 23:39:33 -0700 (PDT) Message-ID: <48575C21.5080705@gmail.com> Date: Tue, 17 Jun 2008 10:39:29 +0400 From: "Salex S." User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD-stable setup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 07:04:48 -0000 Hallo, Yesterday I tried to install FreeBSD-stable and I never saw that new installer which is in FreeBSD-stable. Usually I use sysinstall. Unfortunately "new" setup didn't show me my NTFS partition on that disk and I thought that it's normal and I can see only free space which will be used for FreeBSD slice. As a result NTFS partition was cleaned out! I got one partition on the whole disk with freebsd slice on it! And my big photo archive was lost! Certainly it's my fault, but I'm sure the installer is not intelligible enough in partitioning and much worse than classic sysinstall. User must see the whole disk he operating on with all partitions shown in one summary table! Now I'm trying to recover NTFS partition that now is UNDER FreeBSD slice. And I'm looking for tools that have possibilities to find NTFS tables that were not probably erased by FreeBSD empty slice. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 08:18:12 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB31106564A for ; Tue, 17 Jun 2008 08:18:12 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id 0DEFB8FC16 for ; Tue, 17 Jun 2008 08:18:11 +0000 (UTC) (envelope-from jhs@berklix.org) Received: from js.berklix.net (p549A5CD5.dip.t-dialin.net [84.154.92.213]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id m5H7rlic027176; Tue, 17 Jun 2008 09:53:47 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by js.berklix.net (8.13.8/8.13.8) with ESMTP id m5H7ra5t027479; Tue, 17 Jun 2008 09:53:36 +0200 (CEST) (envelope-from jhs@berklix.org) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.13.8/8.13.8) with ESMTP id m5H7rQHN046688; Tue, 17 Jun 2008 09:53:31 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200806170753.m5H7rQHN046688@fire.js.berklix.net> To: "Salex S." From: "Julian Stacey" Organization: http://berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://berklix.com/free/ X-URL: http://berklix.com In-reply-to: Your message "Tue, 17 Jun 2008 10:39:29 +0400." <48575C21.5080705@gmail.com> Date: Tue, 17 Jun 2008 09:53:26 +0200 Sender: jhs@berklix.org Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD-stable setup X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 08:18:12 -0000 Reference: > From: "Salex S." > Date: Tue, 17 Jun 2008 10:39:29 +0400 > Message-id: <48575C21.5080705@gmail.com> "Salex S." wrote: > Hallo, > > Yesterday I tried to install FreeBSD-stable and I never saw that new > installer which is in FreeBSD-stable. Usually I use sysinstall. > Unfortunately "new" setup didn't show me my NTFS partition on that disk > and I thought that it's normal and I can see only free space which will > be used for FreeBSD slice. As a result NTFS partition was cleaned out! I > got one partition on the whole disk with freebsd slice on it! And my big > photo archive was lost! Certainly it's my fault, but I'm sure the > installer is not intelligible enough in partitioning and much worse than > classic sysinstall. User must see the whole disk he operating on with > all partitions shown in one summary table! Now I'm trying to recover > NTFS partition that now is UNDER FreeBSD slice. And I'm looking for > tools that have possibilities to find NTFS tables that were not probably > erased by FreeBSD empty slice. /usr/ports/sysutils/ntfsprogs perhaps or ask list fs@freebsd.org Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail just Ascii plain text. HTML & Base64 text are spam. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 11:51:16 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 965A2106566C for ; Tue, 17 Jun 2008 11:51:16 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id AA6AB8FC20 for ; Tue, 17 Jun 2008 11:51:14 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-156-46.lns11.adl6.internode.on.net [121.45.156.46]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id m5HBoswX027631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Jun 2008 21:20:58 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 17 Jun 2008 21:20:34 +0930 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2687975.9RQQiV9V2L"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200806172120.41978.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Subject: AGP bridge detected as pcib X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 11:51:16 -0000 --nextPart2687975.9RQQiV9V2L Content-Type: multipart/mixed; boundary="Boundary-01=_LU6VIobyYcnf1jx" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_LU6VIobyYcnf1jx Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I have an Epox 8HDAIPRO motherboard - http://www.epox.com/usA/product.asp?I= D=3DEP-8HDAIPRO and its AGP slot is detected as pcib rather than agp as I would expect. I d= o=20 have agp in the kernel -> [midget 21:17] ~ >kldstat -v| grep agp 438 hostb/agp_ali 439 hostb/agp_amd 440 hostb/agp_amd64 441 hostb/agp_ati 442 vgapci/agp_i810 443 hostb/agp_intel 444 hostb/agp_nvidia 445 hostb/agp_sis 446 hostb/agp_via I would expect agp to attach from my reading of agp_amd64.c although I=20 haven't [yet] tried debug printfs :) I have attached dmesg and here is the output of pciconf -lv=20 hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x02821106 chip=3D0x0282110= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'K8T880Pro CPU to PCI Bridge' class =3D bridge subclass =3D HOST-PCI hostb1@pci0:0:0:1: class=3D0x060000 card=3D0x00000000 chip=3D0x1282110= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'K8T880Pro CPU to PCI Bridge' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:0:2: class=3D0x060000 card=3D0x00000000 chip=3D0x2282110= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'K8T880Pro CPU to PCI Bridge' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:0:3: class=3D0x060000 card=3D0x00000000 chip=3D0x3282110= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'K8T880Pro CPU to PCI Bridge' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:0:0:4: class=3D0x060000 card=3D0x00000000 chip=3D0x4282110= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'K8T880Pro CPU to PCI Bridge' class =3D bridge subclass =3D HOST-PCI hostb5@pci0:0:0:7: class=3D0x060000 card=3D0x00000000 chip=3D0x7282110= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'K8T880Pro CPU to PCI Bridge' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x00000000 chip=3D0xb188110= 6 rev=3D0x00 hdr=3D0x01 vendor =3D 'VIA Technologies Inc' device =3D 'VT8237 K8HTB CPU to AGP 2.0/3.0 Bridge' class =3D bridge subclass =3D PCI-PCI fwohci0@pci0:0:8:0: class=3D0x0c0010 card=3D0x581111c1 chip=3D0x581111c= 1 rev=3D0x61 hdr=3D0x00 vendor =3D 'Lucent/Agere Systems (Was: AT&T MicroElectronics)' device =3D 'FW322 1394A PCI PHY/Link Open Host Ctrlr I/F' class =3D serial bus subclass =3D FireWire bktr0@pci0:0:9:0: class=3D0x040000 card=3D0x00000000 chip=3D0x036e109= e rev=3D0x11 hdr=3D0x00 vendor =3D 'Conexant (Was: Brooktree Corp)' device =3D 'Bt878/Fusion 878A Mediastream Controller' class =3D multimedia subclass =3D video none0@pci0:0:9:1: class=3D0x048000 card=3D0x00000000 chip=3D0x0878109= e rev=3D0x11 hdr=3D0x00 vendor =3D 'Conexant (Was: Brooktree Corp)' device =3D '7610144D&REV_02\4&1F7DBC9F&0&09F0 TV Video Capture' class =3D multimedia twe0@pci0:0:10:0: class=3D0x010400 card=3D0x100113c1 chip=3D0x100113c= 1 rev=3D0x01 hdr=3D0x00 vendor =3D '3ware Inc.' device =3D '7000/8000 series ATA-133 Storage Controller' class =3D mass storage subclass =3D RAID fxp0@pci0:0:11:0: class=3D0x020000 card=3D0x00408086 chip=3D0x1229808= 6 rev=3D0x0c hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class =3D network subclass =3D ethernet rl0@pci0:0:13:0: class=3D0x020000 card=3D0x90011695 chip=3D0x813910e= c rev=3D0x10 hdr=3D0x00 vendor =3D 'Realtek Semiconductor' device =3D 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter' class =3D network subclass =3D ethernet atapci0@pci0:0:15:0: class=3D0x01018f card=3D0x300c1695 chip=3D0x3149110= 6 rev=3D0x80 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT8237 VT6410 SATA RAID Controller' class =3D mass storage subclass =3D ATA atapci1@pci0:0:15:1: class=3D0x01018a card=3D0x300c1695 chip=3D0x0571110= 6 rev=3D0x06 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT82C586A/B/VT82C686/A/B/VT823x/A/C Bus Master IDE Cont= roller' class =3D mass storage subclass =3D ATA uhci0@pci0:0:16:0: class=3D0x0c0300 card=3D0x300c1695 chip=3D0x3038110= 6 rev=3D0x81 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host = Controller' class =3D serial bus subclass =3D USB uhci1@pci0:0:16:1: class=3D0x0c0300 card=3D0x300c1695 chip=3D0x3038110= 6 rev=3D0x81 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host = Controller' class =3D serial bus subclass =3D USB uhci2@pci0:0:16:2: class=3D0x0c0300 card=3D0x300c1695 chip=3D0x3038110= 6 rev=3D0x81 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host = Controller' class =3D serial bus subclass =3D USB uhci3@pci0:0:16:3: class=3D0x0c0300 card=3D0x300c1695 chip=3D0x3038110= 6 rev=3D0x81 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host = Controller' class =3D serial bus subclass =3D USB ehci0@pci0:0:16:4: class=3D0x0c0320 card=3D0x300c1695 chip=3D0x3104110= 6 rev=3D0x86 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT6202/12 USB 2.0 Enhanced Host Controller' class =3D serial bus subclass =3D USB isab0@pci0:0:17:0: class=3D0x060100 card=3D0x32271106 chip=3D0x3227110= 6 rev=3D0x00 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT8237 PCI-to-ISA Bridge' class =3D bridge subclass =3D PCI-ISA pcm0@pci0:0:17:5: class=3D0x040100 card=3D0x300c1695 chip=3D0x3059110= 6 rev=3D0x60 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT8237 AC97 Enhanced Audio Controller - the 8251 contro= ller is different' class =3D multimedia subclass =3D audio hostb6@pci0:0:24:0: class=3D0x060000 card=3D0x00000000 chip=3D0x1100102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron HyperTransport Technology Config= uration' class =3D bridge subclass =3D HOST-PCI hostb7@pci0:0:24:1: class=3D0x060000 card=3D0x00000000 chip=3D0x1101102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron Address Map' class =3D bridge subclass =3D HOST-PCI hostb8@pci0:0:24:2: class=3D0x060000 card=3D0x00000000 chip=3D0x1102102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron DRAM Controller' class =3D bridge subclass =3D HOST-PCI hostb9@pci0:0:24:3: class=3D0x060000 card=3D0x00000000 chip=3D0x1103102= 2 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D '(K8) Athlon 64/Opteron Miscellaneous Control' class =3D bridge subclass =3D HOST-PCI nvidia0@pci0:1:0:0: class=3D0x030000 card=3D0x13511682 chip=3D0x032210d= e rev=3D0xa1 hdr=3D0x00 vendor =3D 'Nvidia Corp' device =3D 'GeForce FX 5200 [NV34.3]' class =3D display subclass =3D VGA =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Boundary-01=_LU6VIobyYcnf1jx Content-Type: text/plain; charset="utf-8"; name="dmesg.boot" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.boot" Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #1: Sun Jun 1 19:20:18 CST 2008 darius@midget.dons.net.au:/data/obj/data/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (2205.02-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 2146369536 (2046 MB) avail memory = 2082369536 (1985 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard bktr_mem: memory holder loaded kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 powernow0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xf8000000-0xf8ffffff,0xf0000000-0xf7ffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] fwohci0: mem 0xfa831000-0xfa831fff irq 16 at device 8.0 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:01:99:00:00:03:7c:7b fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:01:99:03:7c:7b fwe0: Ethernet address: 02:01:99:03:7c:7b fwip0: on firewire0 fwip0: Firewire address: 00:01:99:00:00:03:7c:7b @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d8d8000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode bktr0: mem 0xfa833000-0xfa833fff irq 17 at device 9.0 on pci0 bktr0: [GIANT-LOCKED] bktr0: [ITHREAD] bktr0: Card has no configuration EEPROM. Cannot determine card make. bktr0: IMS TV Turbo, Philips FR1236 NTSC FM tuner. pci0: at device 9.1 (no driver attached) twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xea00-0xea0f mem 0xfa830000-0xfa83000f,0xfa000000-0xfa7fffff irq 18 at device 10.0 on pci0 twe0: [GIANT-LOCKED] twe0: [ITHREAD] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 fxp0: port 0xe400-0xe43f mem 0xfa832000-0xfa832fff,0xfa800000-0xfa81ffff irq 19 at device 11.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:32:2c:51 fxp0: [ITHREAD] rl0: port 0xd000-0xd0ff mem 0xfa834000-0xfa8340ff irq 19 at device 13.0 on pci0 miibus1: on rl0 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:04:61:a1:b8:66 rl0: [ITHREAD] atapci0: port 0xeb00-0xeb07,0xe000-0xe003,0xe100-0xe107,0xe200-0xe203,0xe300-0xe30f,0xd400-0xd4ff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe500-0xe50f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xe600-0xe61f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe700-0xe71f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe800-0xe81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe900-0xe91f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfa835000-0xfa8350ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 pcm0: port 0xd800-0xd8ff irq 22 at device 17.5 on pci0 pcm0: [ITHREAD] pcm0: pcm0: acpi_tz0: on acpi0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff,0xd0000-0xd0fff,0xd1000-0xd27ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ucom0: on uhub0 uhub5: on uhub0 uhub5: 4 ports with 4 removable, self powered ulpt0: on uhub5 ulpt0: using bi-directional mode ums0: on uhub1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2205022554 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata2-master SATA150 twed0: on twe0 twed0: 305244MB (625140400 sectors) Trying to mount root from ufs:/dev/twed0s1a plip0: [GIANT-LOCKED] plip0: [ITHREAD] link_elf: symbol msleep undefined lpt0: switched to polled standard mode link_elf: symbol msleep undefined NVRM: AGP cannot be enabled on this combination of the AMD CPU and OS kernel NVRM: kernel upgrade recommended. Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 done All buffers synced. Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #1: Sun Jun 1 19:20:18 CST 2008 darius@midget.dons.net.au:/data/obj/data/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (2205.02-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 2146369536 (2046 MB) avail memory = 2082369536 (1985 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard bktr_mem: memory holder loaded kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fdf0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 powernow0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xf8000000-0xf8ffffff,0xf0000000-0xf7ffffff irq 16 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] fwohci0: mem 0xfa831000-0xfa831fff irq 16 at device 8.0 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:01:99:00:00:03:7c:7b fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:01:99:03:7c:7b fwe0: Ethernet address: 02:01:99:03:7c:7b fwip0: on firewire0 fwip0: Firewire address: 00:01:99:00:00:03:7c:7b @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x7d8d8000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode bktr0: mem 0xfa833000-0xfa833fff irq 17 at device 9.0 on pci0 bktr0: [GIANT-LOCKED] bktr0: [ITHREAD] bktr0: Card has no configuration EEPROM. Cannot determine card make. bktr0: IMS TV Turbo, Philips FR1236 NTSC FM tuner. pci0: at device 9.1 (no driver attached) twe0: <3ware Storage Controller. Driver version 1.50.01.002> port 0xea00-0xea0f mem 0xfa830000-0xfa83000f,0xfa000000-0xfa7fffff irq 18 at device 10.0 on pci0 twe0: [GIANT-LOCKED] twe0: [ITHREAD] twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 fxp0: port 0xe400-0xe43f mem 0xfa832000-0xfa832fff,0xfa800000-0xfa81ffff irq 19 at device 11.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:32:2c:51 fxp0: [ITHREAD] rl0: port 0xd000-0xd0ff mem 0xfa834000-0xfa8340ff irq 19 at device 13.0 on pci0 miibus1: on rl0 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:04:61:a1:b8:66 rl0: [ITHREAD] atapci0: port 0xeb00-0xeb07,0xe000-0xe003,0xe100-0xe107,0xe200-0xe203,0xe300-0xe30f,0xd400-0xd4ff irq 20 at device 15.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe500-0xe50f at device 15.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] uhci0: port 0xe600-0xe61f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe700-0xe71f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe800-0xe81f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe900-0xe91f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfa835000-0xfa8350ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 pcm0: port 0xd800-0xd8ff irq 22 at device 17.5 on pci0 pcm0: [ITHREAD] pcm0: pcm0: acpi_tz0: on acpi0 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff,0xd0000-0xd0fff,0xd1000-0xd27ff pnpid ORM0000 on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ucom0: on uhub0 uhub5: on uhub0 uhub5: 4 ports with 4 removable, self powered ulpt0: on uhub5 ulpt0: using bi-directional mode ums0: on uhub1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 2205023236 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) acd0: DVDR at ata2-master SATA150 twed0: on twe0 twed0: 305244MB (625140400 sectors) Trying to mount root from ufs:/dev/twed0s1a plip0: [GIANT-LOCKED] plip0: [ITHREAD] --Boundary-01=_LU6VIobyYcnf1jx-- --nextPart2687975.9RQQiV9V2L Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iD8DBQBIV6UR5ZPcIHs/zowRAuR1AJsE9lZuaOCL9599ujYhZGTuOCTQjACdEmPK FGTt1wd4Tz0q8ELJi0QRKjU= =g+tE -----END PGP SIGNATURE----- --nextPart2687975.9RQQiV9V2L-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 15:04:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A5181065679 for ; Tue, 17 Jun 2008 15:04:32 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.178]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7FB8FC0C for ; Tue, 17 Jun 2008 15:04:31 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by ik-out-1112.google.com with SMTP id c30so5192713ika.3 for ; Tue, 17 Jun 2008 08:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type; bh=n6T9bxTJoa6QywLnBjveDEw3aN2VdB+jVwVcJTQwAJI=; b=bFmWfzNio7fb5z+E9cZtiH9e+IEssdmltn1gxxCgieog4Y55+0v3XrzrGQFN46zHEX QjA0nlElYYun7SxLLz6JzwrNt6R3CGsy1dsBR8bimT3S5YFPeS5viHthxNcV13Z4JPw8 97IGE/sZhJIYUoEfXBxk6O/wJM2f1UqWaEUkk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type; b=S7NTFnRNK+4XbnVxi4rWt0h10taNi7Wo1ACnHXy67mpMpxI1FmYGhWTJZxTkX6hV/g lYsDpQSvq8B6GFo6S3vbGoh5Zb8QFdthPye7w1TD2LGxqdXS8090lEqBuFa0b81JwLk7 nHO3Kt3E35isOTMN6v4ZgEqapp9jepkyTl4FU= Received: by 10.210.67.11 with SMTP id p11mr2536643eba.96.1213714633244; Tue, 17 Jun 2008 07:57:13 -0700 (PDT) Received: by 10.210.34.1 with HTTP; Tue, 17 Jun 2008 07:57:13 -0700 (PDT) Message-ID: <3c0b01820806170757v5565b59ne0e9d5db06f26761@mail.gmail.com> Date: Tue, 17 Jun 2008 10:57:13 -0400 From: "Alexander Sack" To: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_21143_32365585.1213714633254" Cc: FreeBSD STABLE , freebsd-drivers@freebsd.org Subject: Atheros (ath) MSI wireless embedded chipset fails to attach on 7.0-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 15:04:32 -0000 ------=_Part_21143_32365585.1213714633254 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello: I have installed FreeBSD-7.0-amd64 stable on my new AMD X2 Turon based notebook, a MSI-1710A (GX710Ax) which has a generic embedded controller. During boot up I notice that ATH complains with: ath_rate: version 1.2 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xfd7f0000-0xfd7fffff irq 16 at device 0.0 on pci2 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfd7f0000 ath0: [MPSAFE] ath0: [ITHREAD] ath0: unable to attach hardware; HAL status 13 device_attach: ath0 attach returned 6 HAL status 13 from the header file seems to indicate that the 7.0-STABLE driver doesn't support my hardware revision. Here is my pciconf -l output: hostb0@pci0:0:0:0: class=0x060000 card=0x42cd1462 chip=0x79101002 rev=0x00 hdr=0x00 pcib1@pci0:0:2:0: class=0x060400 card=0x42cd1462 chip=0x79131002 rev=0x00 hdr=0x01 pcib2@pci0:0:4:0: class=0x060400 card=0x42cd1462 chip=0x79141002 rev=0x00 hdr=0x01 pcib3@pci0:0:6:0: class=0x060400 card=0x42cd1462 chip=0x79161002 rev=0x00 hdr=0x01 pcib4@pci0:0:7:0: class=0x060400 card=0x42cd1462 chip=0x79171002 rev=0x00 hdr=0x01 atapci0@pci0:0:18:0: class=0x01018f card=0x42cd1462 chip=0x43801002 rev=0x00 hdr=0x00 ohci0@pci0:0:19:0: class=0x0c0310 card=0x42cd1462 chip=0x43871002 rev=0x00 hdr=0x00 ohci1@pci0:0:19:1: class=0x0c0310 card=0x42cd1462 chip=0x43881002 rev=0x00 hdr=0x00 ohci2@pci0:0:19:2: class=0x0c0310 card=0x42cd1462 chip=0x43891002 rev=0x00 hdr=0x00 ohci3@pci0:0:19:3: class=0x0c0310 card=0x42cd1462 chip=0x438a1002 rev=0x00 hdr=0x00 ohci4@pci0:0:19:4: class=0x0c0310 card=0x42cd1462 chip=0x438b1002 rev=0x00 hdr=0x00 ehci0@pci0:0:19:5: class=0x0c0320 card=0x42cd1462 chip=0x43861002 rev=0x00 hdr=0x00 none0@pci0:0:20:0: class=0x0c0500 card=0x42cd1462 chip=0x43851002 rev=0x14 hdr=0x00 atapci1@pci0:0:20:1: class=0x01018a card=0x42cd1462 chip=0x438c1002 rev=0x00 hdr=0x00 none1@pci0:0:20:2: class=0x040300 card=0x42cd1462 chip=0x43831002 rev=0x00 hdr=0x00 isab0@pci0:0:20:3: class=0x060100 card=0x42cd1462 chip=0x438d1002 rev=0x00 hdr=0x00 pcib5@pci0:0:20:4: class=0x060401 card=0x00000000 chip=0x43841002 rev=0x00 hdr=0x01 hostb1@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 hostb2@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 hostb3@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 hostb4@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vgapci0@pci0:1:0:0: class=0x030000 card=0x42cd1462 chip=0x95811002 rev=0x00 hdr=0x00 none2@pci0:1:0:1: class=0x040300 card=0xaa081462 chip=0xaa081002 rev=0x00 hdr=0x00 ath0@pci0:2:0:0: class=0x020000 card=0x10261a3b chip=0x001c168c rev=0x01 hdr=0x00 re0@pci0:5:0:0: class=0x020000 card=0x42cd1462 chip=0x816810ec rev=0x01 hdr=0x00 cbb0@pci0:6:4:0: class=0x060700 card=0x42cd1462 chip=0x71341217 rev=0x21 hdr=0x02 none3@pci0:6:4:2: class=0x080500 card=0x42cd1462 chip=0x71201217 rev=0x01 hdr=0x00 none4@pci0:6:4:3: class=0x068000 card=0x42cd1462 chip=0x71301217 rev=0x01 hdr=0x00 fwohci0@pci0:6:4:4: class=0x0c0010 card=0x42cd1462 chip=0x00f71217 rev=0x02 hdr=0x00 ath0 is listed as rev=0x01 so I'm a little confused why I got HAL status 13. Does anyone know if this chipset is supported in 7.0-STABLE? If not, is it possible to try CURRENT on 7.0 which may fix it? I've attached my complete dmesg output. Again, any feedback would be much appreciated! -aps ------=_Part_21143_32365585.1213714633254 Content-Type: application/octet-stream; name=unity-dmesg Content-Transfer-Encoding: base64 X-Attachment-Id: f_fhkmc1x50 Content-Disposition: attachment; filename=unity-dmesg Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZy ZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjAtUkVMRUFTRSAjMDogTW9uIEp1biAxNiAxMTow MToyMiBFRFQgMjAwOAogICAgcm9vdEB1bml0eS5sb2NhbGRvbWFpbjovdXNyL29iai91c3Ivc3Jj L3N5cy9VTklUWQpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQg MHhmZmZmZmZmZjgwODk2MDAwLgpDYWxpYnJhdGluZyBjbG9jayhzKSAuLi4gaTgyNTQgY2xvY2s6 IDExOTMyMDMgSHoKQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0gdXNp bmcgZGVmYXVsdCBmcmVxdWVuY3kKVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4 MiBIeiBxdWFsaXR5IDAKQ2FsaWJyYXRpbmcgVFNDIGNsb2NrIC4uLiBUU0MgY2xvY2s6IDc5ODAw Mzk4MiBIegpDUFU6IEFNRCBUdXJpb24odG0pIDY0IFgyIE1vYmlsZSBUZWNobm9sb2d5IFRMLTY4 ICg3OTguMDAtTUh6IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQg PSAweDYwZjgyICBTdGVwcGluZyA9IDIKICBGZWF0dXJlcz0weDE3OGJmYmZmPEZQVSxWTUUsREUs UFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBT RTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIsSFRUPgogIEZlYXR1cmVzMj0weDIwMDE8U1NF MyxDWDE2PgogIEFNRCBGZWF0dXJlcz0weGVhNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixS RFRTQ1AsTE0sM0ROb3chKywzRE5vdyE+CiAgQU1EIEZlYXR1cmVzMj0weDExZjxMQUhGLENNUCxT Vk0sRXh0QVBJQyxDUjgsUHJlZmV0Y2g+CiAgQ29yZXMgcGVyIHBhY2thZ2U6IDIKTDEgMk1CIGRh dGEgVExCOiA4IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDJNQiBpbnN0cnVjdGlvbiBU TEI6IDggZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgNEtCIGRhdGEgVExCOiAzMiBlbnRy aWVzLCBmdWxseSBhc3NvY2lhdGl2ZQpMMSA0S0IgaW5zdHJ1Y3Rpb24gVExCOiAzMiBlbnRyaWVz LCBmdWxseSBhc3NvY2lhdGl2ZQpMMSBkYXRhIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xp bmUsIDEgbGluZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMSBpbnN0cnVjdGlvbiBjYWNoZTog NjQga2J5dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMi13YXkgYXNzb2NpYXRpdmUK TDIgMk1CIHVuaWZpZWQgVExCOiAwIGVudHJpZXMsIGRpc2FibGVkL25vdCBwcmVzZW50CkwyIDRL QiBkYXRhIFRMQjogNTEyIGVudHJpZXMsIDQtd2F5IGFzc29jaWF0aXZlCkwyIDRLQiBpbnN0cnVj dGlvbiBUTEI6IDUxMiBlbnRyaWVzLCA0LXdheSBhc3NvY2lhdGl2ZQpMMiB1bmlmaWVkIGNhY2hl OiA1MTIga2J5dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMTYtd2F5IGFzc29jaWF0 aXZlCnVzYWJsZSBtZW1vcnkgPSA0Mjg1Mjk2NjQwICg0MDg2IE1CKQpQaHlzaWNhbCBtZW1vcnkg Y2h1bmsocyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5YmZmZiwgNjM0ODgw IGJ5dGVzICgxNTUgcGFnZXMpCjB4MDAwMDAwMDAwMDk5NDAwMCAtIDB4MDAwMDAwMDBjNzBlOWZm ZiwgMzMyOTU4MTA1NiBieXRlcyAoODEyODg2IHBhZ2VzKQoweDAwMDAwMDAxMDAwMDAwMDAgLSAw eDAwMDAwMDAxMmZmZWZmZmYsIDgwNTI0MDgzMiBieXRlcyAoMTk2NTkyIHBhZ2VzKQphdmFpbCBt ZW1vcnkgID0gNDEyMzk4Mzg3MiAoMzkzMiBNQikKQUNQSSBBUElDIFRhYmxlOiA8TVNJX05CIE1F R0FCT09LPgpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAxIGFzIGEgdGFyZ2V0CkZyZWVCU0QvU01Q OiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwogY3B1MCAoQlNQKTogQVBJ QyBJRDogIDAKIGNwdTEgKEFQKTogQVBJQyBJRDogIDEKQVBJQzogQ1BVIDAgaGFzIEFDUEkgSUQg MQpBUElDOiBDUFUgMSBoYXMgQUNQSSBJRCAyCkFDUEk6IFJTRFAgQCAweDB4ZjkyZTAvMHgwMDE0 ICh2ICAwIEFDUElBTSkKQUNQSTogUlNEVCBAIDB4MHhjZmZjMDAwMC8weDAwNDAgKHYgIDEgTVNJ X05CIE1FR0FCT09LIDB4MDcwMDA3MjUgTVNGVCAweDAwMDAwMDk3KQpBQ1BJOiBGQUNQIEAgMHgw eGNmZmMwMjAwLzB4MDA4NCAodiAgMiBNU0lfTkIgTUVHQUJPT0sgMHgwNzAwMDcyNSBNU0ZUIDB4 MDAwMDAwOTcpCkFDUEk6IERTRFQgQCAweDB4Y2ZmYzA1YjAvMHgzRDM2ICh2ICAxICAxQUROSSAx QUROSTAwMCAweDAwMDAwMDAwIElOVEwgMHgyMDA1MTExNykKQUNQSTogRkFDUyBAIDB4MHhjZmZj ZTAwMC8weDAwNDAKQUNQSTogQVBJQyBAIDB4MHhjZmZjMDM5MC8weDAwNUMgKHYgIDEgTVNJX05C IE1FR0FCT09LIDB4MDcwMDA3MjUgTVNGVCAweDAwMDAwMDk3KQpBQ1BJOiBNQ0ZHIEAgMHgweGNm ZmMwM2YwLzB4MDAzQyAodiAgMSBNU0lfTkIgTUVHQUJPT0sgMHgwNzAwMDcyNSBNU0ZUIDB4MDAw MDAwOTcpCkFDUEk6IFNMSUMgQCAweDB4Y2ZmYzA0MzAvMHgwMTc2ICh2ICAxIE1TSV9OQiBNRUdB Qk9PSyAweDA3MDAwNzI1IE1TRlQgMHgwMDAwMDA5NykKQUNQSTogT0VNQiBAIDB4MHhjZmZjZTA0 MC8weDAwNjEgKHYgIDEgTVNJX05CIE1FR0FCT09LIDB4MDcwMDA3MjUgTVNGVCAweDAwMDAwMDk3 KQpBQ1BJOiBIUEVUIEAgMHgweGNmZmM0MmYwLzB4MDAzOCAodiAgMSBNU0lfTkIgT0VNSFBFVCAg MHgwNzAwMDcyNSBNU0ZUIDB4MDAwMDAwOTcpCkFDUEk6IFNTRFQgQCAweDB4Y2ZmYzQzMzAvMHgw MkY0ICh2ICAxIEEgTSBJICBQT1dFUk5PVyAweDAwMDAwMDAxIEFNRCAgMHgwMDAwMDAwMSkKTUFE VDogRm91bmQgSU8gQVBJQyBJRCAyLCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAwMDAwCmlvYXBpYzA6 IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBpbnRwaW4gMApNQURUOiBJbnRlcnJ1cHQgb3Zl cnJpZGU6IHNvdXJjZSAwLCBpcnEgMgppb2FwaWMwOiBSb3V0aW5nIElSUSAwIC0+IGludHBpbiAy Ck1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDksIGlycSA5CmlvYXBpYzA6IGludHBp biA5IHRyaWdnZXI6IGxldmVsCmlvYXBpYzA6IGludHBpbiA5IHBvbGFyaXR5OiBsb3cKaW9hcGlj MCA8VmVyc2lvbiAyLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApjcHUwIEJTUDoKICAgICBJ RDogMHgwMDAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZm ZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAw MDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDEwMGVmIHRoZXJtOiAweDAwMDEwMDAw IGVycjogMHgwMDAxMDAwZiBwY206IDB4MDAwMTAwMDAKYXRoX3JhdGU6IHZlcnNpb24gMS4yIDxT YW1wbGVSYXRlIGJpdC1yYXRlIHNlbGVjdGlvbiBhbGdvcml0aG0+CndsYW5fYW1ycjogPEFNUlIg VHJhbnNtaXQgUmF0ZSBDb250cm9sIEFsZ29yaXRobT4Kd2xhbjogPDgwMi4xMSBMaW5rIExheWVy PgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KbmZzbG9jazogcHNl dWRvLWRldmljZQprYmQ6IG5ldyBhcnJheSBzaXplIDQKa2JkMSBhdCBrYmRtdXgwCm1lbTogPG1l bW9yeT4KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4KaW86IDxJL08+CmF0aF9oYWw6 IDAuOS4yMC4zIChBUjUyMTAsIEFSNTIxMSwgQVI1MjEyLCBSRjUxMTEsIFJGNTExMiwgUkYyNDEz LCBSRjU0MTMpCmFjcGkwOiA8TVNJX05CIE1FR0FCT09LPiBvbiBtb3RoZXJib2FyZAppb2FwaWMw OiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIHZlY3RvciA0OAphY3BpMDogW01QU0FG RV0KYWNwaTA6IFtJVEhSRUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKQWNwaU9zRGVy aXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLlJTNDguTkIyXyAtPiBidXMgMCBkZXYgMCBmdW5jIDAKQUNQ SSBFcnJvciAoZXZyZWdpb24tMDQyNyk6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRUNfX10gKDB4 ZmZmZmZmMDAwMTFjZjY4MCkgW0VtYmVkZGVkQ29udHJvbF0gWzIwMDcwMzIwXQpBQ1BJIEVycm9y IChleGZsZGlvLTAzOTApOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVy IFsyMDA3MDMyMF0KQUNQSSBFcnJvciAocHNwYXJzZS0wNjI2KTogTWV0aG9kIHBhcnNlL2V4ZWN1 dGlvbiBmYWlsZWQgW1xcX1NCXy5QQ0kwLlNCUkcuRUNfXy5CQVQxLl9TVEFdIChOb2RlIDB4ZmZm ZmZmMDAwMTFkMjQ4MCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMwOSk6IE1l dGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uUENJMC5TQlJHLkVDX18uQkFUMS5fU1RBXSAo Tm9kZSAweGZmZmZmZjAwMDExZDI0ODApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAoZXZyZWdp b24tMDQyNyk6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRUNfX10gKDB4ZmZmZmZmMDAwMTFjZjY4 MCkgW0VtYmVkZGVkQ29udHJvbF0gWzIwMDcwMzIwXQpBQ1BJIEVycm9yIChleGZsZGlvLTAzOTAp OiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIFsyMDA3MDMyMF0KQUNQ SSBFcnJvciAocHNwYXJzZS0wNjI2KTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xc X1NCXy5QQ0kwLlNCUkcuRUNfXy5CQVQxLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTFkMjQ4MCks IEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMwOSk6IE1ldGhvZCBleGVjdXRpb24g ZmFpbGVkIFtcXF9TQl8uUENJMC5TQlJHLkVDX18uQkFUMS5fU1RBXSAoTm9kZSAweGZmZmZmZjAw MDExZDI0ODApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAoZXZyZWdpb24tMDQyNyk6IE5vIGhh bmRsZXIgZm9yIFJlZ2lvbiBbRUNfX10gKDB4ZmZmZmZmMDAwMTFjZjY4MCkgW0VtYmVkZGVkQ29u dHJvbF0gWzIwMDcwMzIwXQpBQ1BJIEVycm9yIChleGZsZGlvLTAzOTApOiBSZWdpb24gRW1iZWRk ZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIFsyMDA3MDMyMF0KQUNQSSBFcnJvciAocHNwYXJz ZS0wNjI2KTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5QQ0kwLlNCUkcu RUNfXy5CQVQxLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTFkMjQ4MCksIEFFX05PVF9FWElTVApB Q1BJIEVycm9yICh1dGV2YWwtMDMwOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8u UENJMC5TQlJHLkVDX18uQkFUMS5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDExZDI0ODApLCBBRV9O T1RfRVhJU1QKQUNQSSBFcnJvciAoZXZyZWdpb24tMDQyNyk6IE5vIGhhbmRsZXIgZm9yIFJlZ2lv biBbRUNfX10gKDB4ZmZmZmZmMDAwMTFjZjY4MCkgW0VtYmVkZGVkQ29udHJvbF0gWzIwMDcwMzIw XQpBQ1BJIEVycm9yIChleGZsZGlvLTAzOTApOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhh cyBubyBoYW5kbGVyIFsyMDA3MDMyMF0KQUNQSSBFcnJvciAocHNwYXJzZS0wNjI2KTogTWV0aG9k IHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5QQ0kwLlNCUkcuRUNfXy5CQVQxLl9TVEFd IChOb2RlIDB4ZmZmZmZmMDAwMTFkMjQ4MCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2 YWwtMDMwOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uUENJMC5TQlJHLkVDX18u QkFUMS5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDExZDI0ODApLCBBRV9OT1RfRVhJU1QKQUNQSSBF cnJvciAoZXZyZWdpb24tMDQyNyk6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRUNfX10gKDB4ZmZm ZmZmMDAwMTFjZjY4MCkgW0VtYmVkZGVkQ29udHJvbF0gWzIwMDcwMzIwXQpBQ1BJIEVycm9yIChl eGZsZGlvLTAzOTApOiBSZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIFsy MDA3MDMyMF0KQUNQSSBFcnJvciAocHNwYXJzZS0wNjI2KTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlv biBmYWlsZWQgW1xcX1NCXy5QQ0kwLlNCUkcuRUNfXy5CQVQxLl9TVEFdIChOb2RlIDB4ZmZmZmZm MDAwMTFkMjQ4MCksIEFFX05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMwOSk6IE1ldGhv ZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uUENJMC5TQlJHLkVDX18uQkFUMS5fU1RBXSAoTm9k ZSAweGZmZmZmZjAwMDExZDI0ODApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAoZXZyZWdpb24t MDQyNyk6IE5vIGhhbmRsZXIgZm9yIFJlZ2lvbiBbRUNfX10gKDB4ZmZmZmZmMDAwMTFjZjY4MCkg W0VtYmVkZGVkQ29udHJvbF0gWzIwMDcwMzIwXQpBQ1BJIEVycm9yIChleGZsZGlvLTAzOTApOiBS ZWdpb24gRW1iZWRkZWRDb250cm9sKDMpIGhhcyBubyBoYW5kbGVyIFsyMDA3MDMyMF0KQUNQSSBF cnJvciAocHNwYXJzZS0wNjI2KTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NC Xy5QQ0kwLlNCUkcuRUNfXy5CQVQxLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTFkMjQ4MCksIEFF X05PVF9FWElTVApBQ1BJIEVycm9yICh1dGV2YWwtMDMwOSk6IE1ldGhvZCBleGVjdXRpb24gZmFp bGVkIFtcXF9TQl8uUENJMC5TQlJHLkVDX18uQkFUMS5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDEx ZDI0ODApLCBBRV9OT1RfRVhJU1QKQUNQSSBFcnJvciAoZXZyZWdpb24tMDQyNyk6IE5vIGhhbmRs ZXIgZm9yIFJlZ2lvbiBbRUNfX10gKDB4ZmZmZmZmMDAwMTFjZjY4MCkgW0VtYmVkZGVkQ29udHJv bF0gWzIwMDcwMzIwXQpBQ1BJIEVycm9yIChleGZsZGlvLTAzOTApOiBSZWdpb24gRW1iZWRkZWRD b250cm9sKDMpIGhhcyBubyBoYW5kbGVyIFsyMDA3MDMyMF0KQUNQSSBFcnJvciAocHNwYXJzZS0w NjI2KTogTWV0aG9kIHBhcnNlL2V4ZWN1dGlvbiBmYWlsZWQgW1xcX1NCXy5QQ0kwLlNCUkcuRUNf Xy5CQVQxLl9TVEFdIChOb2RlIDB4ZmZmZmZmMDAwMTFkMjQ4MCksIEFFX05PVF9FWElTVApBQ1BJ IEVycm9yICh1dGV2YWwtMDMwOSk6IE1ldGhvZCBleGVjdXRpb24gZmFpbGVkIFtcXF9TQl8uUENJ MC5TQlJHLkVDX18uQkFUMS5fU1RBXSAoTm9kZSAweGZmZmZmZjAwMDExZDI0ODApLCBBRV9OT1Rf RVhJU1QKYWNwaTA6IHJlc2VydmF0aW9uIG9mIDAsIGEwMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJl c2VydmF0aW9uIG9mIDEwMDAwMCwgY2ZmMDAwMDAgKDMpIGZhaWxlZApBQ1BJIEhQRVQgdGFibGUg d2FybmluZzogU2VxdWVuY2UgaXMgbm9uLXplcm8gKDIpCkFDUEkgdGltZXI6IDAvMTI4NCAwLzEy ODQgMC8xMjgxIDAvMTI3NCAwLzEyODIgMC8xMjgyIDAvMTI4MiAwLzEyODQgMC8xMjc5IDAvMTI4 NCAtPiAwClRpbWVjb3VudGVyICJBQ1BJLXNhZmUiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxp dHkgODUwCmFjcGlfdGltZXIwOiA8MzItYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4 ODA4LTB4ODBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1iZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4 Nj4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTAKcGNpX2xpbmswOiAgICAgICAgSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsxOiAgICAgICAgSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmsyOiAgICAgICAg SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9uICAgICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNhYmxlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xpbmszOiAg ICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9uICAgICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKcGNpX2xp bms0OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFByb2JlICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxpZGF0aW9u ICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUK cGNpX2xpbms1OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFBy b2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDkKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDkKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDkK cGNpX2xpbms2OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0aWFsIFBy b2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUKICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUK ICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIg MTQgMTUKcGNpX2xpbms3OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICBJbml0 aWFsIFByb2JlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIgMTQgMTUK ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAgMTEgMTIg MTQgMTUKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDcgMTAg MTEgMTIgMTQgMTUKYWNwaV9ocGV0MDogPEhpZ2ggUHJlY2lzaW9uIEV2ZW50IFRpbWVyPiBpb21l bSAweGZlZDAwMDAwLTB4ZmVkMDAzZmYgb24gYWNwaTAKYWNwaV9ocGV0MDogdmVuZDogMHg0MzUz IHJldjogMHgxIG51bTogMyBoejogMTQzMTgxODAgb3B0czogbGVnYWN5X3JvdXRlClRpbWVjb3Vu dGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5MDAKY3B1MDogPEFDUEkg Q1BVPiBvbiBhY3BpMApjcHUwOiBzd2l0Y2hpbmcgdG8gZ2VuZXJpYyBDeCBtb2RlCmFjcGlfdGhy b3R0bGUwOiA8QUNQSSBDUFUgVGhyb3R0bGluZz4gb24gY3B1MAphY3BpX3Rocm90dGxlMDogQ0xL X1ZBTCBmaWVsZCBvdmVybGFwcyBUSFRfRU4gYml0CmRldmljZV9hdHRhY2g6IGFjcGlfdGhyb3R0 bGUwIGF0dGFjaCByZXR1cm5lZCA2CnBvd2Vybm93MDogPFBvd2VyTm93ISBLOD4gb24gY3B1MApj cHUxOiA8QUNQSSBDUFU+IG9uIGFjcGkwCnBvd2Vybm93MTogPFBvd2VyTm93ISBLOD4gb24gY3B1 MQpwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdlPiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkw CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IGRvbWFpbj0wLCBwaHlzaWNhbCBi dXM9MApmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDc5MTAsIHJldmlkPTB4MDAKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgyMjIwLCBjYWNoZWxuc3o9MCAoZHdv cmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NzkxMywgcmV2aWQ9MHgwMAoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9 MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDQwMTAsIGNhY2hlbG5zej0x NiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDFiICg2NzUwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQg RDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg3 OTE0LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9NCwgZnVuYz0wCgljbGFzcz0w Ni0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMTA2LCBzdGF0cmVnPTB4 MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRz IEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCmZvdW5kLT4JdmVuZG9y PTB4MTAwMiwgZGV2PTB4NzkxNiwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTYs IGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4 MDEwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgw MCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vy c3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2Fn ZQpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weDc5MTcsIHJldmlkPTB4MDAKCWRvbWFpbj0w LCBidXM9MCwgc2xvdD03LCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1m ZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHg0MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBz dXBwb3J0cyAxIG1lc3NhZ2UKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0MzgwLCByZXZp ZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTgsIGZ1bmM9MAoJY2xhc3M9MDEtMDEtOGYs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAyMzAsIGNh Y2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAw ICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTExCglwb3dlcnNwZWMg MiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4YTAwMCwgc2l6ZSAgMywgZW5hYmxlZAoJbWFwWzE0XTogdHlwZSBJL08g UG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg5MDAwLCBzaXplICAyLCBlbmFibGVkCgltYXBbMThdOiB0 eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDgwMDAsIHNpemUgIDMsIGVuYWJsZWQKCW1h cFsxY106IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4NzAwMCwgc2l6ZSAgMiwgZW5h YmxlZAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHg2MDAwLCBzaXpl ICA0LCBlbmFibGVkCgltYXBbMjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZDVm ZjgwMCwgc2l6ZSAxMCwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOC5JTlRB CnBjaWIwOiBzbG90IDE4IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMgpmb3VuZC0+CXZlbmRvcj0w eDEwMDIsIGRldj0weDQzODcsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOSwg ZnVuYz0wCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgw MTE3LCBzdGF0cmVnPTB4MDJhMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQw ICgxOTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBp bj1hLCBpcnE9NQoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmQ1ZmUw MDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTkuSU5UQQpw Y2liMDogc2xvdCAxOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYKZm91bmQtPgl2ZW5kb3I9MHgx MDAyLCBkZXY9MHg0Mzg4LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTksIGZ1 bmM9MQoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEx Nywgc3RhdHJlZz0weDAyYTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAo MTkyMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49 YiwgaXJxPTE1CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZDVmZDAw MCwgc2l6ZSAxMiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOS5JTlRCCnBj aWIwOiBzbG90IDE5IElOVEIgaGFyZHdpcmVkIHRvIElSUSAxNwpmb3VuZC0+CXZlbmRvcj0weDEw MDIsIGRldj0weDQzODksIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOSwgZnVu Yz0yCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTE3 LCBzdGF0cmVnPTB4MDJhMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgx OTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1j LCBpcnE9MTAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZkNWZjMDAw LCBzaXplIDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjE5LklOVEMKcGNp YjA6IHNsb3QgMTkgSU5UQyBoYXJkd2lyZWQgdG8gSVJRIDE4CmZvdW5kLT4JdmVuZG9yPTB4MTAw MiwgZGV2PTB4NDM4YSwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE5LCBmdW5j PTMKCWNsYXNzPTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMTcs IHN0YXRyZWc9MHgwMmEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5 MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIs IGlycT0xNQoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmQ1ZmIwMDAs IHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTkuSU5UQgpwY2li MDogc2xvdCAxOSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTcKZm91bmQtPgl2ZW5kb3I9MHgxMDAy LCBkZXY9MHg0MzhiLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTksIGZ1bmM9 NAoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDExNywg c3RhdHJlZz0weDAyYTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTky MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49Yywg aXJxPTEwCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZDVmYTAwMCwg c2l6ZSAxMiwgZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xOS5JTlRDCnBjaWIw OiBzbG90IDE5IElOVEMgaGFyZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDEwMDIs IGRldj0weDQzODYsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOSwgZnVuYz01 CgljbGFzcz0wYy0wMy0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTE3LCBz dGF0cmVnPTB4MDJiOCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1kLCBp cnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFw WzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmQ1ZmYwMDAsIHNpemUgIDgsIGVu YWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTkuSU5URApwY2liMDogc2xvdCAxOSBJ TlREIGhhcmR3aXJlZCB0byBJUlEgMTkKZm91bmQtPgl2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0Mzg1 LCByZXZpZD0weDE0Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjAsIGZ1bmM9MAoJY2xhc3M9MGMt MDUtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDQwMSwgc3RhdHJlZz0weDAy MzAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4YjAwLCBzaXplICA0LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAw MiwgZGV2PTB4NDM4YywgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5j PTEKCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDUs IHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJx PTI1NQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmZjAwLCBzaXpl ICA0LCBlbmFibGVkCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4MywgcmV2aWQ9MHgw MAoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5jPTIKCWNsYXNzPTA0LTAzLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwNDEwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT01Cglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwg YmFzZSAweGZkNWY0MDAwLCBzaXplIDE0LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjIwLklOVEEKcGNpYjA6IHNsb3QgMjAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2CmZvdW5k LT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4ZCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTIwLCBmdW5jPTMKCWNsYXNzPTA2LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEK CWNtZHJlZz0weDAwMGYsIHN0YXRyZWc9MHgwMjIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp CmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NDM4NCwgcmV2aWQ9MHgwMAoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTIwLCBmdW5jPTQKCWNsYXNzPTA2LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1m ZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMmEwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAwLCByZXZpZD0weDAw Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAxLCByZXZp ZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MQoJY2xhc3M9MDYtMDAtMDAs IGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAy LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MgoJY2xhc3M9MDYt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAw MDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9 MHgxMTAzLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MwoJY2xh c3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJl Zz0weDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKcGNpYjE6IDxBQ1BJIFBDSS1QQ0kg YnJpZGdlPiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKcGNpYjE6ICAgZG9tYWluICAgICAgICAgICAg MApwY2liMTogICBzZWNvbmRhcnkgYnVzICAgICAxCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAg IDEKcGNpYjE6ICAgSS9PIGRlY29kZSAgICAgICAgMHhiMDAwLTB4YmZmZgpwY2liMTogICBtZW1v cnkgZGVjb2RlICAgICAweGZkNjAwMDAwLTB4ZmQ2ZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBk ZWNvZGUgMHhkMDAwMDAwMC0weGRmZmZmZmZmCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIx CnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQpmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRl dj0weDk1ODEsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MSwgc2xvdD0wLCBmdW5jPTAKCWNs YXNzPTAzLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRy ZWc9MHg0MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBt aW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJ cG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9y dHMgMSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwg cmFuZ2UgNjQsIGJhc2UgMHhkMDAwMDAwMCwgc2l6ZSAyOCwgZW5hYmxlZApwY2liMTogcmVxdWVz dGVkIG1lbW9yeSByYW5nZSAweGQwMDAwMDAwLTB4ZGZmZmZmZmY6IGdvb2QKCW1hcFsxOF06IHR5 cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZkNmYwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBj aWIxOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmQ2ZjAwMDAtMHhmZDZmZmZmZjogZ29vZAoJ bWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhiMDAwLCBzaXplICA4LCBl bmFibGVkCnBjaWIxOiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4YjAwMC0weGIwZmY6IGluIHJhbmdl CnBjaWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxLjAuSU5UQQpwY2liMTogc2xvdCAwIElOVEEgaGFy ZHdpcmVkIHRvIElSUSAxOApmb3VuZC0+CXZlbmRvcj0weDEwMDIsIGRldj0weGFhMDgsIHJldmlk PTB4MDAKCWRvbWFpbj0wLCBidXM9MSwgc2xvdD0wLCBmdW5jPTEKCWNsYXNzPTA0LTAzLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHg0MDEwLCBjYWNo ZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDMgIHN1 cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2 NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAweGZkNmVjMDAwLCBz aXplIDE0LCBlbmFibGVkCnBjaWIxOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmQ2ZWMwMDAt MHhmZDZlZmZmZjogZ29vZApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgMS4wLklOVEIKcGNpYjE6 IHNsb3QgMCBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTkKdmdhcGNpMDogPFZHQS1jb21wYXRpYmxl IGRpc3BsYXk+IHBvcnQgMHhiMDAwLTB4YjBmZiBtZW0gMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4 ZmQ2ZjAwMDAtMHhmZDZmZmZmZiBpcnEgMTggYXQgZGV2aWNlIDAuMCBvbiBwY2kxCnBjaTE6IDxt dWx0aW1lZGlhPiBhdCBkZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaWIyOiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDQuMCBvbiBwY2kwCnBjaWIyOiAgIGRvbWFpbiAg ICAgICAgICAgIDAKcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMgpwY2liMjogICBzdWJvcmRp bmF0ZSBidXMgICAyCnBjaWIyOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MC0weDAKcGNpYjI6ICAg bWVtb3J5IGRlY29kZSAgICAgMHhmZDcwMDAwMC0weGZkN2ZmZmZmCnBjaWIyOiAgIG5vIHByZWZl dGNoZWQgZGVjb2RlCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyCnBjaTI6IGRvbWFpbj0w LCBwaHlzaWNhbCBidXM9Mgpmb3VuZC0+CXZlbmRvcj0weDE2OGMsIGRldj0weDAwMWMsIHJldmlk PTB4MDEKCWRvbWFpbj0wLCBidXM9Miwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNo ZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT01Cglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UKCU1TSS1YIHN1 cHBvcnRzIDEgbWVzc2FnZSBpbiBtYXAgMHgxMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdl IDY0LCBiYXNlIDB4ZmQ3ZjAwMDAsIHNpemUgMTYsIGVuYWJsZWQKcGNpYjI6IHJlcXVlc3RlZCBt ZW1vcnkgcmFuZ2UgMHhmZDdmMDAwMC0weGZkN2ZmZmZmOiBnb29kCnBjaWIyOiBtYXRjaGVkIGVu dHJ5IGZvciAyLjAuSU5UQQpwY2liMjogc2xvdCAwIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNgph dGgwOiA8QXRoZXJvcyA1NDI0LzI0MjQ+IG1lbSAweGZkN2YwMDAwLTB4ZmQ3ZmZmZmYgaXJxIDE2 IGF0IGRldmljZSAwLjAgb24gcGNpMgphdGgwOiBSZXNlcnZlZCAweDEwMDAwIGJ5dGVzIGZvciBy aWQgMHgxMCB0eXBlIDMgYXQgMHhmZDdmMDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxNiAo UENJIElSUSAxNikgdG8gdmVjdG9yIDQ5CmF0aDA6IFtNUFNBRkVdCmF0aDA6IFtJVEhSRUFEXQph dGgwOiB1bmFibGUgdG8gYXR0YWNoIGhhcmR3YXJlOyBIQUwgc3RhdHVzIDEzCmRldmljZV9hdHRh Y2g6IGF0aDAgYXR0YWNoIHJldHVybmVkIDYKcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBh dCBkZXZpY2UgNi4wIG9uIHBjaTAKcGNpYjM6ICAgZG9tYWluICAgICAgICAgICAgMApwY2liMzog ICBzZWNvbmRhcnkgYnVzICAgICAzCnBjaWIzOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQKcGNpYjM6 ICAgSS9PIGRlY29kZSAgICAgICAgMHhlMDAwLTB4ZWZmZgpwY2liMzogICBtZW1vcnkgZGVjb2Rl ICAgICAweGZkODAwMDAwLTB4ZmUxZmZmZmYKcGNpYjM6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhm ODAwMDAwMC0weGZhZmZmZmZmCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCnBjaTM6IGRv bWFpbj0wLCBwaHlzaWNhbCBidXM9MwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSA3LjAgb24gcGNpMApwY2liNDogICBkb21haW4gICAgICAgICAgICAwCnBjaWI0OiAgIHNl Y29uZGFyeSBidXMgICAgIDUKcGNpYjQ6ICAgc3Vib3JkaW5hdGUgYnVzICAgNQpwY2liNDogICBJ L08gZGVjb2RlICAgICAgICAweGMwMDAtMHhjZmZmCnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUgICAg IDB4ZmUyMDAwMDAtMHhmZTJmZmZmZgpwY2liNDogICBubyBwcmVmZXRjaGVkIGRlY29kZQpwY2k1 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNApwY2k1OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTUK Zm91bmQtPgl2ZW5kb3I9MHgxMGVjLCBkZXY9MHg4MTY4LCByZXZpZD0weDAxCglkb21haW49MCwg YnVzPTUsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wCgljbWRyZWc9MHgwMTA3LCBzdGF0cmVnPTB4NDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBE MyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdAoJbWFwWzEwXTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhjODAwLCBzaXplICA4LCBlbmFibGVkCnBj aWI0OiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4YzgwMC0weGM4ZmY6IGluIHJhbmdlCgltYXBbMThd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhmZTJmZjAwMCwgc2l6ZSAxMiwgZW5hYmxl ZApwY2liNDogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZlMmZmMDAwLTB4ZmUyZmZmZmY6IGdv b2QKcGNpYjQ6IG1hdGNoZWQgZW50cnkgZm9yIDUuMC5JTlRBCnBjaWI0OiBzbG90IDAgSU5UQSBo YXJkd2lyZWQgdG8gSVJRIDE5CnJlMDogUmVzZXJ2ZWQgMHgxMDAgYnl0ZXMgZm9yIHJpZCAweDEw IHR5cGUgNCBhdCAweGM4MDAKcGNpYjQ6IHJlMCByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4YzgwMC0w eGM4ZmY6IGluIHJhbmdlCnBjaWI0OiByZTAgcmVxdWVzdGVkIEkvTyByYW5nZSAweGM4MDAtMHhj OGZmOiBpbiByYW5nZQpwY2liNDogcmUwIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhjODAwLTB4Yzhm ZjogaW4gcmFuZ2UKcmUwOiA8UmVhbFRlayA4MTY4LzgxMTFCIFBDSWUgR2lnYWJpdCBFdGhlcm5l dD4gcG9ydCAweGM4MDAtMHhjOGZmIG1lbSAweGZlMmZmMDAwLTB4ZmUyZmZmZmYgaXJxIDE5IGF0 IGRldmljZSAwLjAgb24gcGNpNQpwY2liNDogcmUwIHJlcXVlc3RlZCBJL08gcmFuZ2UgMHhjODAw LTB4YzhmZjogaW4gcmFuZ2UKcmUwOiBNU0kgY291bnQgOiAyCnJlMDogYXR0ZW1wdGluZyB0byBh bGxvY2F0ZSAyIE1TSSB2ZWN0b3JzICgyIHN1cHBvcnRlZCkKbXNpOiByb3V0aW5nIE1TSSBJUlEg MjU2IHRvIHZlY3RvciA1MAptc2k6IHJvdXRpbmcgTVNJIElSUSAyNTcgdG8gdmVjdG9yIDUxCnJl MDogdXNpbmcgSVJRcyAyNTYtMjU3IGZvciBNU0kKcmUwOiBVc2luZyAyIE1TSSBtZXNzYWdlcwpt aWlidXMwOiA8TUlJIGJ1cz4gb24gcmUwCnJnZXBoeTA6IDxSVEw4MTY5Uy84MTEwUy84MjExQiBt ZWRpYSBpbnRlcmZhY2U+IFBIWSAxIG9uIG1paWJ1czAKcmdlcGh5MDogIDEwYmFzZVQsIDEwYmFz ZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZE WCwgYXV0bwpyZTA6IGJwZiBhdHRhY2hlZApyZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE5OmRi OjNjOmJjOmQ3CnJlMDogW01QU0FGRV0KcmUwOiBbRklMVEVSXQpyZTA6IFtNUFNBRkVdCnJlMDog W0ZJTFRFUl0KYXRhcGNpMDogPEFUSSBBVEEgY29udHJvbGxlcj4gcG9ydCAweGEwMDAtMHhhMDA3 LDB4OTAwMC0weDkwMDMsMHg4MDAwLTB4ODAwNywweDcwMDAtMHg3MDAzLDB4NjAwMC0weDYwMGYg bWVtIDB4ZmQ1ZmY4MDAtMHhmZDVmZmJmZiBpcnEgMjIgYXQgZGV2aWNlIDE4LjAgb24gcGNpMAph dGFwY2kwOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHg2MDAw CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIyIChQQ0kgSVJRIDIyKSB0byB2ZWN0b3IgNDkKYXRh cGNpMDogW01QU0FGRV0KYXRhcGNpMDogW0lUSFJFQURdCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBv biBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0 IGF0IDB4YTAwMAphdGFwY2kwOiBSZXNlcnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUg NCBhdCAweDkwMDAKYXRhMjogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT0wMAph dGEyOiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTI6IHN0YXQxPTB4 MDAgZXJyPTB4MDAgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMjogcmVzZXQgdHAyIHN0YXQwPTUwIHN0 YXQxPTAwIGRldmljZXM9MHgxPEFUQV9NQVNURVI+CmF0YTI6IFtNUFNBRkVdCmF0YTI6IFtJVEhS RUFEXQphdGEzOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAw eDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDgwMDAKYXRhcGNpMDogUmVzZXJ2ZWQg MHg0IGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHg3MDAwCmF0YTM6IHJlc2V0IHRwMSBt YXNrPTAzIG9zdGF0MD03ZiBvc3RhdDE9N2YKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHg3ZiBsc2I9 MHg3ZiBtc2I9MHg3ZgphdGEzOiBzdGF0MD0weDdmIGVycj0weDdmIGxzYj0weDdmIG1zYj0weDdm CmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4N2YgbHNiPTB4N2YgbXNiPTB4N2YKYXRhMzogc3RhdDA9 MHg3ZiBlcnI9MHg3ZiBsc2I9MHg3ZiBtc2I9MHg3ZgphdGEzOiBzdGF0MD0weDdmIGVycj0weDdm IGxzYj0weDdmIG1zYj0weDdmCmF0YTM6IHN0YXQwPTB4N2YgZXJyPTB4N2YgbHNiPTB4N2YgbXNi PTB4N2YKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHg3ZiBsc2I9MHg3ZiBtc2I9MHg3ZgphdGEzOiBz dGF0MD0weDdmIGVycj0weDdmIGxzYj0weDdmIG1zYj0weDdmCmF0YTM6IHN0YXQwPTB4N2YgZXJy PTB4N2YgbHNiPTB4N2YgbXNiPTB4N2YKYXRhMzogc3RhdDA9MHg3ZiBlcnI9MHg3ZiBsc2I9MHg3 ZiBtc2I9MHg3ZgphdGEzOiBzdGF0MD0weDdmIGVycj0weDdmIGxzYj0weDdmIG1zYj0weDdmCmF0 YTM6IHN0YXQwPTB4N2YgZXJyPTB4N2YgbHNiPTB4N2YgbXNiPTB4N2YKYXRhMzogc3RhdDE9MHg3 ZiBlcnI9MHg3ZiBsc2I9MHg3ZiBtc2I9MHg3ZgphdGEzOiByZXNldCB0cDIgc3RhdDA9ZmYgc3Rh dDE9ZmYgZGV2aWNlcz0weDAKYXRhMzogW01QU0FGRV0KYXRhMzogW0lUSFJFQURdCm9oY2kwOiA8 T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZkNWZlMDAwLTB4ZmQ1ZmVmZmYg aXJxIDE2IGF0IGRldmljZSAxOS4wIG9uIHBjaTAKb2hjaTA6IFJlc2VydmVkIDB4MTAwMCBieXRl cyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmQ1ZmUwMDAKaW9hcGljMDogcm91dGluZyBpbnRw aW4gMTYgKFBDSSBJUlEgMTYpIHRvIHZlY3RvciA1MgpvaGNpMDogW0dJQU5ULUxPQ0tFRF0Kb2hj aTA6IFtJVEhSRUFEXQp1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2Iw OiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCnVzYjA6IFVTQiByZXZp c2lvbiAxLjAKdWh1YjA6IDxBVEkgT0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDE+IG9uIHVzYjAKdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkCm9oY2kxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZk NWZkMDAwLTB4ZmQ1ZmRmZmYgaXJxIDE3IGF0IGRldmljZSAxOS4xIG9uIHBjaTAKb2hjaTE6IFJl c2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmQ1ZmQwMDAKaW9h cGljMDogcm91dGluZyBpbnRwaW4gMTcgKFBDSSBJUlEgMTcpIHRvIHZlY3RvciA1MwpvaGNpMTog W0dJQU5ULUxPQ0tFRF0Kb2hjaTE6IFtJVEhSRUFEXQp1c2IxOiBPSENJIHZlcnNpb24gMS4wLCBs ZWdhY3kgc3VwcG9ydAp1c2IxOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9o Y2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjE6IDxBVEkgT0hDSSByb290IGh1YiwgY2xh c3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjEKdWh1YjE6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCm9oY2kyOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNv bnRyb2xsZXI+IG1lbSAweGZkNWZjMDAwLTB4ZmQ1ZmNmZmYgaXJxIDE4IGF0IGRldmljZSAxOS4y IG9uIHBjaTAKb2hjaTI6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAz IGF0IDB4ZmQ1ZmMwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRv IHZlY3RvciA1NApvaGNpMjogW0dJQU5ULUxPQ0tFRF0Kb2hjaTI6IFtJVEhSRUFEXQp1c2IyOiBP SENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2IyOiA8T0hDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXI+IG9uIG9oY2kyCnVzYjI6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjI6IDxBVEkg T0hDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjIK dWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCm9oY2kzOiA8T0hD SSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG1lbSAweGZkNWZiMDAwLTB4ZmQ1ZmJmZmYgaXJx IDE3IGF0IGRldmljZSAxOS4zIG9uIHBjaTAKb2hjaTM6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBm b3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmQ1ZmIwMDAKb2hjaTM6IFtHSUFOVC1MT0NLRURdCm9o Y2kzOiBbSVRIUkVBRF0KdXNiMzogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5IHN1cHBvcnQKdXNi MzogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMwp1c2IzOiBVU0IgcmV2 aXNpb24gMS4wCnVodWIzOiA8QVRJIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2IzCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNl bGYgcG93ZXJlZApvaGNpNDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhm ZDVmYTAwMC0weGZkNWZhZmZmIGlycSAxOCBhdCBkZXZpY2UgMTkuNCBvbiBwY2kwCm9oY2k0OiBS ZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZkNWZhMDAwCm9o Y2k0OiBbR0lBTlQtTE9DS0VEXQpvaGNpNDogW0lUSFJFQURdCnVzYjQ6IE9IQ0kgdmVyc2lvbiAx LjAsIGxlZ2FjeSBzdXBwb3J0CnVzYjQ6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g b24gb2hjaTQKdXNiNDogVVNCIHJldmlzaW9uIDEuMAp1aHViNDogPEFUSSBPSENJIHJvb3QgaHVi LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiNAp1aHViNDogMiBwb3J0 cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKZWhjaTA6IDxFSENJIChnZW5lcmljKSBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZkNWZmMDAwLTB4ZmQ1ZmYwZmYgaXJxIDE5IGF0IGRl dmljZSAxOS41IG9uIHBjaTAKZWhjaTA6IFJlc2VydmVkIDB4MTAwIGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDMgYXQgMHhmZDVmZjAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxOSAoUENJIElS USAxOSkgdG8gdmVjdG9yIDU1CmVoY2kwOiBbR0lBTlQtTE9DS0VEXQplaGNpMDogW0lUSFJFQURd CmVoY2kwOiBEcm9wcGVkIGludGVycnVwdHMgd29ya2Fyb3VuZCBlbmFibGVkCnVzYjU6IEVIQ0kg dmVyc2lvbiAxLjAKdXNiNTogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVz YjAgdXNiMSB1c2IyIHVzYjMgdXNiNAp1c2I1OiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250 cm9sbGVyPiBvbiBlaGNpMAp1c2I1OiBVU0IgcmV2aXNpb24gMi4wCnVodWI1OiA8QVRJIEVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2I1CnVodWI1 OiAxMCBwb3J0cyB3aXRoIDEwIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCnBjaTA6IDxzZXJpYWwg YnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDIwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRhcGNpMTog PEFUSSBJWFA2MDAgVURNQTEzMyBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4 MTcwLTB4MTc3LDB4Mzc2LDB4ZmYwMC0weGZmMGYgYXQgZGV2aWNlIDIwLjEgb24gcGNpMAphdGFw Y2kxOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhmZjAwCmF0 YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxCmF0YXBjaTE6IFJlc2VydmVkIDB4OCBieXRl cyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwCmF0YXBjaTE6IFJlc2VydmVkIDB4MSBieXRl cyBmb3IgcmlkIDB4MTQgdHlwZSA0IGF0IDB4M2Y2CmF0YTA6IHJlc2V0IHRwMSBtYXNrPTAzIG9z dGF0MD01MCBvc3RhdDE9MDEKYXRhMDogc3RhdDA9MHgxMCBlcnI9MHgwMSBsc2I9MHgxNCBtc2I9 MHhlYgphdGEwOiBzdGF0MT0weDAxIGVycj0weDA0IGxzYj0weDAwIG1zYj0weDAwCmF0YTA6IHJl c2V0IHRwMiBzdGF0MD0xMCBzdGF0MT0wMSBkZXZpY2VzPTB4NDxBVEFQSV9NQVNURVI+CmlvYXBp YzA6IHJvdXRpbmcgaW50cGluIDE0IChJU0EgSVJRIDE0KSB0byB2ZWN0b3IgNTYKYXRhMDogW01Q U0FGRV0KYXRhMDogW0lUSFJFQURdCnBjaTA6IDxtdWx0aW1lZGlhPiBhdCBkZXZpY2UgMjAuMiAo bm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMjAu MyBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMApwY2liNTogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAyMC40IG9uIHBjaTAKcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAg MApwY2liNTogICBzZWNvbmRhcnkgYnVzICAgICA2CnBjaWI1OiAgIHN1Ym9yZGluYXRlIGJ1cyAg IDcKcGNpYjU6ICAgSS9PIGRlY29kZSAgICAgICAgMHhkMDAwLTB4ZGZmZgpwY2liNTogICBtZW1v cnkgZGVjb2RlICAgICAweGZlMzAwMDAwLTB4ZmViZmZmZmYKcGNpYjU6ICAgcHJlZmV0Y2hlZCBk ZWNvZGUgMHhmYjAwMDAwMC0weGZjZmZmZmZmCnBjaWI1OiAgIFN1YnRyYWN0aXZlbHkgZGVjb2Rl ZCBicmlkZ2UuCnBjaTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CnBjaTY6IGRvbWFpbj0wLCBw aHlzaWNhbCBidXM9Ngpmb3VuZC0+CXZlbmRvcj0weDEyMTcsIGRldj0weDcxMzQsIHJldmlkPTB4 MjEKCWRvbWFpbj0wLCBidXM9Niwgc2xvdD00LCBmdW5jPTAKCWNsYXNzPTA2LTA3LTAwLCBoZHJ0 eXBlPTB4MDIsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwNDEwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDQzICgxNjc1 MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0zCglwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCBy YW5nZSAzMiwgYmFzZSAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWI1OiBtYXRjaGVkIGVudHJ5IGZv ciA2LjQuSU5UQQpwY2liNTogc2xvdCA0IElOVEEgaGFyZHdpcmVkIHRvIElSUSAyMApmb3VuZC0+ CXZlbmRvcj0weDEyMTcsIGRldj0weDcxMjAsIHJldmlkPTB4MDEKCWRvbWFpbj0wLCBidXM9Niwg c2xvdD00LCBmdW5jPTIKCWNsYXNzPTA4LTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNt ZHJlZz0weDAxMDIsIHN0YXRyZWc9MHgwNDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRp bWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQoJaW50cGluPWEsIGlycT0zCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1 cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZlM2ZmYzAw LCBzaXplICA4LCBlbmFibGVkCnBjaWI1OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmUzZmZj MDAtMHhmZTNmZmNmZjogZ29vZApwY2liNTogbWF0Y2hlZCBlbnRyeSBmb3IgNi40LklOVEEKcGNp YjU6IHNsb3QgNCBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjAKZm91bmQtPgl2ZW5kb3I9MHgxMjE3 LCBkZXY9MHg3MTMwLCByZXZpZD0weDAxCglkb21haW49MCwgYnVzPTYsIHNsb3Q9NCwgZnVuYz0z CgljbGFzcz0wNi04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMTAyLCBz dGF0cmVnPTB4MDQxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBp cnE9MwoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBb MTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZTNmZTAwMCwgc2l6ZSAxMiwgZW5h YmxlZApwY2liNTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZlM2ZlMDAwLTB4ZmUzZmVmZmY6 IGdvb2QKcGNpYjU6IG1hdGNoZWQgZW50cnkgZm9yIDYuNC5JTlRBCnBjaWI1OiBzbG90IDQgSU5U QSBoYXJkd2lyZWQgdG8gSVJRIDIwCmZvdW5kLT4JdmVuZG9yPTB4MTIxNywgZGV2PTB4MDBmNywg cmV2aWQ9MHgwMgoJZG9tYWluPTAsIGJ1cz02LCBzbG90PTQsIGZ1bmM9NAoJY2xhc3M9MGMtMDAt MTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDExNywgc3RhdHJlZz0weDAyMTAs IGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0w eDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTMKCXBvd2Vyc3Bl YyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1v cnksIHJhbmdlIDMyLCBiYXNlIDB4ZmUzZmQwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjU6IHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmZTNmZDAwMC0weGZlM2ZkZmZmOiBnb29kCgltYXBbMTRd OiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmZTNmZjAwMCwgc2l6ZSAxMSwgZW5hYmxl ZApwY2liNTogcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZlM2ZmMDAwLTB4ZmUzZmY3ZmY6IGdv b2QKcGNpYjU6IG1hdGNoZWQgZW50cnkgZm9yIDYuNC5JTlRBCnBjaWI1OiBzbG90IDQgSU5UQSBo YXJkd2lyZWQgdG8gSVJRIDIwCmNiYjA6IDxQQ0ktQ2FyZEJ1cyBCcmlkZ2U+IGlycSAyMCBhdCBk ZXZpY2UgNC4wIG9uIHBjaTYKcGNpYjU6IGNiYjAgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGZl MzAwMDAwLTB4ZmViZmZmZmY6IGdvb2QKY2JiMDogTGF6eSBhbGxvY2F0aW9uIG9mIDB4MTAwMCBi eXRlcyByaWQgMHgxMCB0eXBlIDMgYXQgMHhmZTMwMDAwMApjYXJkYnVzMDogPENhcmRCdXMgYnVz PiBvbiBjYmIwCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMAppb2FwaWMwOiBy b3V0aW5nIGludHBpbiAyMCAoUENJIElSUSAyMCkgdG8gdmVjdG9yIDU3CmNiYjA6IFtNUFNBRkVd CmNiYjA6IFtJVEhSRUFEXQpjYmIwOiBQQ0kgQ29uZmlndXJhdGlvbiBzcGFjZToKICAweDAwOiAw eDcxMzQxMjE3IDB4MDQxMDAxMDcgMHgwNjA3MDAyMSAweDAwODI0MDAwIAogIDB4MTA6IDB4ZmUz MDAwMDAgMHgwMjAwMDBhMCAweDQwMDcwNzA2IDB4ZmZmZmYwMDAgCiAgMHgyMDogMHgwMDAwMDAw MCAweGZmZmZmMDAwIDB4MDAwMDAwMDAgMHgwMDAwZmZmZCAKICAweDMwOiAweDAwMDAwMDAxIDB4 MDAwMGZmZmQgMHgwMDAwMDAwMSAweDA0NDMwMTE0IAogIDB4NDA6IDB4NDJjZDE0NjIgMHgwMDAw MDAwMSAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHg1MDogMHgwMDAwMDAwMCAweDAwMDAwMDAw IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweDYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIAogIDB4NzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgCiAgMHg4MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMTAwMTAwMiAKICAweDkwOiAweDAwMDUyNDA2IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIAogIDB4YTA6IDB4ZmUwMjAwMDEgMHgwMGMwNDAwMCAweDAwMDAwMDAwIDB4MDAwMDAw MWYgCiAgMHhiMDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAK ICAweGMwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4 ZDA6IDB4MDkwMDYxMDAgMHg4MDgyMGJlYSAweDAwMDAwMDAwIDB4MDA0MDAwMTggCiAgMHhlMDog MHgwMDgyMDAwNiAweDAwMDkxMDk5IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGYwOiAweDAw MDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIApwY2k2OiA8YmFzZSBwZXJp cGhlcmFsPiBhdCBkZXZpY2UgNC4yIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTY6IDxicmlkZ2U+ IGF0IGRldmljZSA0LjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKZndvaGNpMDogdmVuZG9yPTEyMTcs IGRldj1mNwpmd29oY2kwOiB2ZW5kb3I9MTIxNywgZGV2PWY3CmZ3b2hjaTA6IDwxMzk0IE9wZW4g SG9zdCBDb250cm9sbGVyIEludGVyZmFjZT4gbWVtIDB4ZmUzZmQwMDAtMHhmZTNmZGZmZiwweGZl M2ZmMDAwLTB4ZmUzZmY3ZmYgaXJxIDIwIGF0IGRldmljZSA0LjQgb24gcGNpNgpmd29oY2kwOiBS ZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZlM2ZkMDAwCmZ3 b2hjaTA6IFtNUFNBRkVdCmZ3b2hjaTA6IFtGSUxURVJdCmZ3b2hjaTA6IE9IQ0kgdmVyc2lvbiAx LjEwIChST009MCkKZndvaGNpMDogTm8uIG9mIElzb2Nocm9ub3VzIGNoYW5uZWxzIGlzIDguCmZ3 b2hjaTA6IEVVSTY0IDAwOmRjOjEwOjAwOmNlOjdiOjFkOjAxCmZ3b2hjaTA6IFBoeSAxMzk0YSBh dmFpbGFibGUgUzQwMCwgMiBwb3J0cy4KZndvaGNpMDogTGluayBTNDAwLCBtYXhfcmVjIDIwNDgg Ynl0ZXMuCmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTAKZndl MDogPEV0aGVybmV0IG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMAppZl9md2UwOiBGYWtlIEV0 aGVybmV0IGFkZHJlc3M6IDAyOmRjOjEwOjdiOjFkOjAxCmZ3ZTA6IGJwZiBhdHRhY2hlZApmd2Uw OiBFdGhlcm5ldCBhZGRyZXNzOiAwMjpkYzoxMDo3YjoxZDowMQpmd2lwMDogPElQIG92ZXIgRmly ZVdpcmU+IG9uIGZpcmV3aXJlMApmd2lwMDogYnBmIGF0dGFjaGVkCmZ3aXAwOiBGaXJld2lyZSBh ZGRyZXNzOiAwMDpkYzoxMDowMDpjZTo3YjoxZDowMSBAIDB4ZmZmZTAwMDAwMDAwLCBTNDAwLCBt YXhyZWMgMjA0OApzYnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTAK ZGNvbnNfY3JvbTA6IDxkY29ucyBjb25maWd1cmF0aW9uIFJPTT4gb24gZmlyZXdpcmUwCmRjb25z X2Nyb20wOiBidXNfYWRkciAweDEwZmMwMDAKZndvaGNpMDogSW5pdGlhdGUgYnVzIHJlc2V0CmZ3 b2hjaTA6IEJVUyByZXNldApmd29oY2kwOiBub2RlX2lkPTB4YzAwMGZmYzAsIGdlbj0xLCBDWUNM RU1BU1RFUiBtb2RlCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV90 ejA6IDxUaGVybWFsIFpvbmU+IG9uIGFjcGkwCmF0a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVy IChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGlycSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJv YXJkPiBpcnEgMSBvbiBhdGtiZGMwCmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBj b21tYW5kIGJ5dGUgMDA2NQphdGtiZDoga2V5Ym9hcmQgSUQgMHg0MWFiICgyKQprYmQwIGF0IGF0 a2JkMAprYmQwOiBhdGtiZDAsIEFUIDEwMS8xMDIgKDIpLCBjb25maWc6MHgwLCBmbGFnczoweDNk MDAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJRIDEpIHRvIHZlY3RvciA1OAph dGtiZDA6IFtHSUFOVC1MT0NLRURdCmF0a2JkMDogW0lUSFJFQURdCnBzbTA6IHVuYWJsZSB0byBh bGxvY2F0ZSBJUlEKcHNtY3BucDA6IDxQUy8yIG1vdXNlIHBvcnQ+IGlycSAxMiBvbiBhY3BpMApw c20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDY1CnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIg b24gYXRrYmRjMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikgdG8gdmVj dG9yIDU5CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IFtJVEhSRUFEXQpwc20wOiBtb2RlbCBJ bnRlbGxpTW91c2UsIGRldmljZSBJRCAzLTAwLCAzIGJ1dHRvbnMKcHNtMDogY29uZmlnOjAwMDAw MDAwLCBmbGFnczowMDAwMDAwOCwgcGFja2V0IHNpemU6NApwc20wOiBzeW5jbWFzazowOCwgc3lu Y2JpdHM6MDAKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJhdHRlcnkwOiA8QUNQ SSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2xpZDA6IDxDb250cm9sIE1l dGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7 IHNraXBwaW5nIGl0CnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnZnYTogdmdh MCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBkaXNhYmxp bmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNl cwpvcm0wOiA8SVNBIE9wdGlvbiBST00+IGF0IGlvbWVtIDB4Y2YwMDAtMHhjZmZmZiBvbiBpc2Ew CmZkYzAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJx IDIgb24gaXNhMApwcGMwOiBjYW5ub3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpwcGMwOiA8UGFy YWxsZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKc2MwOiA8U3lzdGVt IGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29u c29sZXMsIGZsYWdzPTB4MzAwPgpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNj IChzeXNjb25zIHRlcm1pbmFsKQpzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAg b2YgcHJvYmVkIGlycXMgMApzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8wOiBpcnEg bWFwczogMCAwIDAgMApzaW8wOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIgNCA2IDcgOQpz aW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMApzaW8w OiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8wOiBpcnEgbWFwczogMCAwIDAgMApzaW8wOiBw cm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIgNCA2IDcgOQpzaW8wIGF0IHBvcnQgMHgzZjgtMHgz ZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBpc2EwCnNpbzA6IHR5cGUgODI1MCBvciBub3QgcmVzcG9u ZGluZwppb2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRvIHZlY3RvciA2MApz aW8wOiBbRklMVEVSXQpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJv YmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8xOiBpcnEgbWFwczog MCAwIDAgMApzaW8xOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIgNCA2IDcgOQpzaW8xIGZh aWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTAKc2lvMjogbm90 IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2Z2EwOiA8R2Vu ZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBv biBpc2EwCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNlcwp1Z2VuMDogPEZv cm1vc2EyMSBTbm93Zmxha2VFbXVsYXRpb24sIGNsYXNzIDAvMCwgcmV2IDIuMDAvMS4zMCwgYWRk ciAyPiBvbiB1aHViMwpEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KUmVkdWNpbmcga2Vy bi5tYXh2bm9kZXMgMjM4MzEyIC0+IDEwMDAwMApwcm9jZnMgcmVnaXN0ZXJlZApsYXBpYzogRGl2 aXNvciAyLCBGcmVxdWVuY3kgOTk3NjM1MjMgaHoKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5 IDc5ODAwMzk4MiBIeiBxdWFsaXR5IC0xMDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAg bXNlYwpsbzA6IGJwZiBhdHRhY2hlZApmaXJld2lyZTA6IDEgbm9kZXMsIG1heGhvcCA8PSAwLCBj YWJsZSBJUk0gPSAwIChtZSkKZmlyZXdpcmUwOiBidXMgbWFuYWdlciAwIChtZSkKYWNwaV9hY2Fk MDogYWNsaW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0CmJhdHRlcnkwOiBiYXR0ZXJ5IGluaXRpYWxp emF0aW9uIHN0YXJ0CmF0YTAtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTMz IGNhYmxlPTQwIHdpcmUKYWNkMDogc2V0dGluZyBQSU80IG9uIElYUDYwMCBjaGlwCmFjZDA6IHNl dHRpbmcgVURNQTMzIG9uIElYUDYwMCBjaGlwCmFjZDA6IDxPcHRpYXJjIERWRCBSVyBBRC03NTMw Qi9OWDAyPiBEVkRSIGRyaXZlIGF0IGF0YTAgYXMgbWFzdGVyCmFjZDA6IHJlYWQgNDEzNEtCL3Mg KDQxMzRLQi9zKSB3cml0ZSA0MTM0S0IvcyAoNDEzNEtCL3MpLCAyMDQ4S0IgYnVmZmVyLCBVRE1B MzMKYWNkMDogUmVhZHM6IENEUiwgQ0RSVywgQ0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgRFZE UkFNLCBwYWNrZXQKYWNkMDogV3JpdGVzOiBDRFIsIENEUlcsIERWRFIsIERWRFJBTSwgdGVzdCB3 cml0ZSwgYnVybnByb29mCmFjZDA6IEF1ZGlvOiBwbGF5LCAyNTYgdm9sdW1lIGxldmVscwphY2Qw OiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IG5vL2Js YW5rIGRpc2MKYXRhMi1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTMzIGNh YmxlPTQwIHdpcmUKYWQ0OiAxOTA3ODJNQiA8U2VhZ2F0ZSBTVDkyMDA0MjBBU0cgMy5BQUE+IGF0 IGF0YTItbWFzdGVyIFVETUEzMwphZDQ6IDM5MDcyMTk2OCBzZWN0b3JzIFszODc2MjFDLzE2SC82 M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKR0VPTTogbmV3IGRpc2sgYWQ0 CmFkNDogU2lsaWNvbiBJbWFnZSBjaGVjazMgZmFpbGVkCmFkNDogQWRhcHRlYyBjaGVjazEgZmFp bGVkCmFkNDogTFNJICh2MykgY2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjIpIGNoZWNrMSBmYWls ZWQKYWQ0OiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKYWNwaV9lYzA6IHdhaXQgdGltZWQgb3V0IChy ZXNwb25zZSksIGZvcmNpbmcgcG9sbGVkIG1vZGUKYWNwaV9hY2FkMDogT24gTGluZQphY3BpX2Fj YWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwphY3BpX2VjMDog d2FybmluZzogRUMgZG9uZSBiZWZvcmUgc3RhcnRpbmcgZXZlbnQgd2FpdApiYXR0ZXJ5MDogYmF0 dGVyeSBpbml0aWFsaXphdGlvbiBkb25lLCB0cmllZCAxIHRpbWVzCihwcm9iZTA6c2JwMDowOjA6 MCk6IGVycm9yIDIyCihwcm9iZTA6c2JwMDowOjA6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9i ZTE6c2JwMDowOjE6MCk6IGVycm9yIDIyCihwcm9iZTE6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxl IEVycm9yCihwcm9iZTI6c2JwMDowOjI6MCk6IGVycm9yIDIyCihwcm9iZTI6c2JwMDowOjI6MCk6 IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTM6c2JwMDowOjM6MCk6IGVycm9yIDIyCihwcm9iZTM6 c2JwMDowOjM6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTQ6c2JwMDowOjQ6MCk6IGVycm9y IDIyCihwcm9iZTQ6c2JwMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVycm9yCihwcm9iZTU6c2JwMDow OjU6MCk6IGVycm9yIDIyCihwcm9iZTU6c2JwMDowOjU6MCk6IFVucmV0cnlhYmxlIEVycm9yCihw cm9iZTY6c2JwMDowOjY6MCk6IGVycm9yIDIyCihwcm9iZTY6c2JwMDowOjY6MCk6IFVucmV0cnlh YmxlIEVycm9yCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApTTVA6IEFQIENQVSAjMSBMYXVuY2hlZCEK Y3B1MSBBUDoKICAgICBJRDogMHgwMTAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAw MDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0 MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDIwMGVmIHRo ZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTAwMDAKaW9hcGljMDog QXNzaWduaW5nIElTQSBJUlEgMSB0byBsb2NhbCBBUElDIDAKaW9hcGljMDogQXNzaWduaW5nIElT QSBJUlEgNCB0byBsb2NhbCBBUElDIDEKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgOSB0byBs b2NhbCBBUElDIDAKaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMTIgdG8gbG9jYWwgQVBJQyAx CmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDE0IHRvIGxvY2FsIEFQSUMgMAppb2FwaWMwOiBB c3NpZ25pbmcgUENJIElSUSAxNiB0byBsb2NhbCBBUElDIDEKaW9hcGljMDogQXNzaWduaW5nIFBD SSBJUlEgMTcgdG8gbG9jYWwgQVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDE4IHRv IGxvY2FsIEFQSUMgMQppb2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAxOSB0byBsb2NhbCBBUElD IDAKaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMjAgdG8gbG9jYWwgQVBJQyAxCmlvYXBpYzA6 IEFzc2lnbmluZyBQQ0kgSVJRIDIyIHRvIGxvY2FsIEFQSUMgMAptc2k6IEFzc2lnbmluZyBNU0kg SVJRIDI1NiB0byBsb2NhbCBBUElDIDEKbXNpOiBBc3NpZ25pbmcgTVNJIElSUSAyNTcgdG8gbG9j YWwgQVBJQyAwClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYvYWQ0czFhCnN0YXJ0 X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0CnJlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCg== ------=_Part_21143_32365585.1213714633254-- From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 15:56:02 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 224A11065670 for ; Tue, 17 Jun 2008 15:56:02 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [198.145.180.174]) by mx1.freebsd.org (Postfix) with ESMTP id 065CD8FC13 for ; Tue, 17 Jun 2008 15:56:01 +0000 (UTC) (envelope-from jfb@mr-paradox.net) Received: by vexbert.mr-paradox.net (Postfix, from userid 16139) id 50E31844B7; Tue, 17 Jun 2008 11:43:44 -0400 (EDT) Date: Tue, 17 Jun 2008 11:43:42 -0400 From: Jeff Blank To: freebsd-stable@freebsd.org Message-ID: <20080617154342.GB49490@mr-happy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Face: #0jV*~a}VtKS-&E/!EJpH('H1Va}24dxF0oT&+.R3Gu8C; xhSC+<|+H84&YLbMvphuRT4cp3.|8EN_(2Eix/6{.Up~u`a^}0Ln&b+9Fw|BPig@-{y\pL_46d&ZwA]5%_AU?}DezfE&1!>H?3E$!Yve7.O<+..Jnb4:'6Ey_]FtFzU9=*l$1p/@gA,Ze>^5<]+r(XJ+m7`/vMDc$'wy|`e Subject: bus_dmamem_alloc failed to align memory properly X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 15:56:02 -0000 Hi, I've installed a PCI (not PCIE) video card in a FreeBSD 7-STABLE (20080616 ~19:00 UTC) amd64 system, and when Xorg starts, the kernel logs the message in the subject. Context: Jun 17 11:27:30 bender kernel: drm0: on vgapci0 Jun 17 11:27:30 bender kernel: info: [drm] Initialized radeon 1.25.0 20060524 Jun 17 11:27:33 bender kernel: info: [drm] Setting GART location based on new memory map Jun 17 11:27:33 bender kernel: bus_dmamem_alloc failed to align memory properly. Jun 17 11:27:33 bender kernel: info: [drm] Loading R200 Microcode Jun 17 11:27:33 bender kernel: info: [drm] writeback test succeeded in 2 usecs Jun 17 11:27:33 bender kernel: drm0: [ITHREAD] Is this anything to worry about? Part of the reason I ask is that the machine locked up hard (had to cut power) the first time I hit ctrl-alt-bs to kill Xorg, though I can't reproduce that reliably (or, really, at all just yet). Let me know if I can provide more information. full dmesg and pciconf output below. Oh, kernel is GENERIC + "options DEVICE_POLLING". thanks, Jeff full dmesg: ===== Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-STABLE #0: Mon Jun 16 19:20:53 EDT 2008 root@bender.tc.mtu.edu:/usr/obj/usr/src/sys/POLLING Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2906.09-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 4279500800 (4081 MB) avail memory = 4108906496 (3918 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bfdd0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 bge0: mem 0xfdef0000-0xfdefffff irq 16 at device 0.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1e:c9:44:30:14 bge0: [ITHREAD] pcib3: at device 4.0 on pci0 pci3: on pcib3 pci0: at device 9.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 11.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 23 at device 14.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 20 at device 15.0 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pcib4: at device 16.0 on pci0 pci4: on pcib4 vgapci0: port 0x9c00-0x9cff mem 0xe0000000-0xe7ffffff,0xfdbf0000-0xfdbfffff irq 16 at device 8.0 on pci4 vgapci1: mem 0xd8000000-0xdfffffff,0xfdbe0000-0xfdbeffff at device 8.1 on pci4 pci0: at device 16.1 (no driver attached) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] orm0: at iomem 0xc0000-0xccfff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ums0: on uhub0 ums0: 3 buttons and Z dir. WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 6 ZFS storage pool version 6 ad4: 152587MB at ata2-master SATA300 ad6: 152587MB at ata3-master SATA300 GEOM_MIRROR: Device mirror/gm0 launched (1/2). GEOM_MIRROR: Device gm0: rebuilding provider ad4. acd0: CDROM at ata4-master SATA150 acd1: CDRW at ata5-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from zfs:zgm0/root WARNING: /_sysroot was not properly dismounted ukbd0: on uhub0 kbd2 at ukbd0 bge0: link state changed to UP drm0: on vgapci0 info: [drm] Initialized radeon 1.25.0 20060524 info: [drm] Setting GART location based on new memory map bus_dmamem_alloc failed to align memory properly. info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm0: [ITHREAD] info: [drm] Setting GART location based on new memory map bus_dmamem_alloc failed to align memory properly. info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 2 usecs drm0: [ITHREAD] info: [drm] Setting GART location based on new memory map bus_dmamem_alloc failed to align memory properly. info: [drm] Loading R200 Microcode info: [drm] writeback test succeeded in 3 usecs drm0: [ITHREAD] ===== pciconf -lv: ===== none0@pci0:0:0:0: class=0x050000 card=0x02f010de chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none1@pci0:0:0:1: class=0x050000 card=0x02fa10de chip=0x02fa10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 0' class = memory subclass = RAM none2@pci0:0:0:2: class=0x050000 card=0x02fe10de chip=0x02fe10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 1' class = memory subclass = RAM none3@pci0:0:0:3: class=0x050000 card=0x02f810de chip=0x02f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 5' class = memory subclass = RAM none4@pci0:0:0:4: class=0x050000 card=0x02f910de chip=0x02f910de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 4' class = memory subclass = RAM none5@pci0:0:0:5: class=0x050000 card=0x02ff10de chip=0x02ff10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none6@pci0:0:0:6: class=0x050000 card=0x027f10de chip=0x027f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 3' class = memory subclass = RAM none7@pci0:0:0:7: class=0x050000 card=0x027e10de chip=0x027e10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 2' class = memory subclass = RAM pcib1@pci0:0:2:0: class=0x060400 card=0x000010de chip=0x02fc10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:0:3:0: class=0x060400 card=0x000010de chip=0x02fd10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI pcib3@pci0:0:4:0: class=0x060400 card=0x000010de chip=0x02fb10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI none8@pci0:0:9:0: class=0x050000 card=0xcb8410de chip=0x027010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Host Bridge' class = memory subclass = RAM isab0@pci0:0:10:0: class=0x060100 card=0x01ec1028 chip=0x026010de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 LPC Bridge' class = bridge subclass = PCI-ISA none9@pci0:0:10:1: class=0x0c0500 card=0x01ec1028 chip=0x026410de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVIDIA SMB Bus Controller NVIDIA nForce PCI System Management' class = serial bus subclass = SMBus none10@pci0:0:10:2: class=0x050000 card=0x01ec1028 chip=0x027210de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Memory Controller 0' class = memory subclass = RAM ohci0@pci0:0:11:0: class=0x0c0310 card=0x01ec1028 chip=0x026d10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB ehci0@pci0:0:11:1: class=0x0c0320 card=0x01ec1028 chip=0x026e10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB atapci0@pci0:0:14:0: class=0x010185 card=0x01ec1028 chip=0x026610de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Serial ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:15:0: class=0x010185 card=0x01ec1028 chip=0x026710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Serial ATA Controller' class = mass storage subclass = ATA pcib4@pci0:0:16:0: class=0x060401 card=0xcb8410de chip=0x026f10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'MCP51 PCI Bridge' class = bridge subclass = PCI-PCI none11@pci0:0:16:1: class=0x040300 card=0x1f901028 chip=0x026c10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 High Definition Audio' class = multimedia hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI bge0@pci0:2:0:0: class=0x020000 card=0x01ec1028 chip=0x167a14e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5754 Broadcom NetXtreme Gigabit Ethernet Controller' class = network subclass = ethernet vgapci0@pci0:4:8:0: class=0x030000 card=0x01201092 chip=0x59601002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV280 Radeon 9200 Pro' class = display subclass = VGA vgapci1@pci0:4:8:1: class=0x038000 card=0x01211092 chip=0x59401002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'RV280 Radeon 9200 Pro - Secondary' class = display ===== From owner-freebsd-stable@FreeBSD.ORG Tue Jun 17 16:45:07 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83C391065681 for ; Tue, 17 Jun 2008 16:45:07 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 33DC48FC15 for ; Tue, 17 Jun 2008 16:45:06 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K8eIm-00032L-70 for freebsd-stable@freebsd.org; Tue, 17 Jun 2008 16:45:00 +0000 Received: from 78-1-102-59.adsl.net.t-com.hr ([78.1.102.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Jun 2008 16:45:00 +0000 Received: from ivoras by 78-1-102-59.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 17 Jun 2008 16:45:00 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Tue, 17 Jun 2008 18:44:49 +0200 Lines: 42 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7E2FA35FD2B8B36B3B122CB1" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-102-59.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-Enigmail-Version: 0.95.6 Sender: news Cc: freebsd-advocacy@freebsd.org Subject: OT: FreeBSD in impressive applications? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2008 16:45:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7E2FA35FD2B8B36B3B122CB1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I was contacted by a local (actually "national" but it's a small=20 nation...) IT magazine to write something on FreeBSD. The cause was that = some editor heard something about FreeBSD being used on some Formula 1=20 cars or equipment, or possibly something not completely unrelated to the = F1, so they thought it would be interesting to write about. The trouble=20 is: I have no idea where to start looking for information on this. Any=20 ideas? Also, I heard that it's been used or is used by various companies and=20 institutions in addition to the "usual suspects" like NetApp, Nokia and=20 the like. FBI and some banks come to mind. Any information on that? Use=20 in robotics, aeronautics, etc. would also be good to start with. Contacting me privately by e-mail is ok; asking me not to say where the=20 information came from is also ok :) --------------enig7E2FA35FD2B8B36B3B122CB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIV+oBldnAQVacBcgRAgywAKCUuHNdoqektlnURpMjEQjTHcmBGACg6yue xPD5i9rWT+nb7Ne51fr49Lg= =tok2 -----END PGP SIGNATURE----- --------------enig7E2FA35FD2B8B36B3B122CB1-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 04:16:29 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D464D1065675 for ; Wed, 18 Jun 2008 04:16:29 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 5BD138FC14 for ; Wed, 18 Jun 2008 04:16:28 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m5I4FV13083400 for ; Tue, 17 Jun 2008 23:15:31 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Tue Jun 17 23:15:31 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m5I4FUPs083389 for freebsd-stable@freebsd.org; Tue, 17 Jun 2008 23:15:30 -0500 (CDT) (envelope-from karl) Date: Tue, 17 Jun 2008 23:15:30 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080618041530.GA81315@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080617012053.GA82316@FS.denninger.net> User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 04:16:29 -0000 On Mon, Jun 16, 2008 at 08:20:53PM -0500, Karl Denninger wrote: > On Thu, May 08, 2008 at 10:30:01AM +0100, Pete French wrote: > > > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > > > have been out of the loop on the card(s) that work properly for a good long > > > while. > > > > HP P400 cards are PCI express and SAS - they work very well under FreeBSD. > > I've also used the cheaper E200 and that appears to be fine too, though I > > havent run it for as long as the 400's. > > > > http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html > > > > -pete. > > > > Following upon my own stuff, I just laid hands on a Quad-Xeon machine with an > Intel SRCSAS18E card in it, and well, the only way I can describe it is "oh > my GOD!" > > Off a couple of older 250GB SATA drives, mirrored, it sustained 70MB/sec over > the entire disk's volume space on reads and had ZERO visible impact on CPU > OR another process doing mixed I/O at the same time (!). > > That's impressive. > > If its stable. > > The cards are not cheap, however. > > The only "gotcha" is that all configuration of the drive(s) appears to be > done through the controller. I assume I COULD use something like gmirror, > but see little reason to do so. > > -- Karl Denninger > karl@denninger.net Ok, another followup! Is there a mangement interface program for the "mfi" driver somewhere? I rooted around in "ports" but didn't find one, nor on the base system. The Linux ones want to talk to the "amr" driver which is the older LSI Logic MegaRAID boards, not the newer ones that the mfi driver talks to. No management tool = el-sucko, because you can't rebuild a failed disk or even shut the alarm on the board off! -- Karl Denninger karl@denninger.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 05:24:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 885961065674 for ; Wed, 18 Jun 2008 05:24:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4695C8FC25 for ; Wed, 18 Jun 2008 05:24:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 948092BD47 for ; Wed, 18 Jun 2008 17:04:10 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnXcfXQHchWB for ; Wed, 18 Jun 2008 17:04:06 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP for ; Wed, 18 Jun 2008 17:04:06 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 3452E1142F; Wed, 18 Jun 2008 17:05:31 +1200 (NZST) Date: Tue, 17 Jun 2008 22:05:31 -0700 From: Andrew Thompson To: freebsd-stable@freebsd.org Message-ID: <20080618050530.GA75831@citylink.fud.org.nz> References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618041530.GA81315@FS.denninger.net> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 05:24:34 -0000 On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: > On Mon, Jun 16, 2008 at 08:20:53PM -0500, Karl Denninger wrote: > > On Thu, May 08, 2008 at 10:30:01AM +0100, Pete French wrote: > > > > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > > > > have been out of the loop on the card(s) that work properly for a good long > > > > while. > > > > > > HP P400 cards are PCI express and SAS - they work very well under FreeBSD. > > > I've also used the cheaper E200 and that appears to be fine too, though I > > > havent run it for as long as the 400's. > > > > > > http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html > > > > > > -pete. > > > > > > > Following upon my own stuff, I just laid hands on a Quad-Xeon machine with an > > Intel SRCSAS18E card in it, and well, the only way I can describe it is "oh > > my GOD!" > > Ok, another followup! > > Is there a mangement interface program for the "mfi" driver somewhere? I > rooted around in "ports" but didn't find one, nor on the base system. > > The Linux ones want to talk to the "amr" driver which is the older LSI Logic > MegaRAID boards, not the newer ones that the mfi driver talks to. > > No management tool = el-sucko, because you can't rebuild a failed disk or > even shut the alarm on the board off! Its sysutils/linux-megacli. Andrew From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 05:27:24 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3A30106567B for ; Wed, 18 Jun 2008 05:27:24 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 36D1C8FC0C for ; Wed, 18 Jun 2008 05:27:24 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-25-183.bredband.comhem.se ([83.253.25.183]:51582 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1K8qCZ-0006V7-3S for freebsd-stable@freebsd.org; Wed, 18 Jun 2008 07:27:23 +0200 Received: (qmail 39587 invoked from network); 18 Jun 2008 07:27:19 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 18 Jun 2008 07:27:19 +0200 Received: (qmail 61597 invoked by uid 1001); 18 Jun 2008 07:27:19 +0200 Date: Wed, 18 Jun 2008 07:27:19 +0200 From: Erik Trulsson To: freebsd-stable@freebsd.org Message-ID: <20080618052718.GA61493@owl.midgard.homeip.net> References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618041530.GA81315@FS.denninger.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-Originating-IP: 83.253.25.183 X-Scan-Result: No virus found in message 1K8qCZ-0006V7-3S. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1K8qCZ-0006V7-3S a9d4c10dd648069f99ce8a2671513e31 Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 05:27:24 -0000 On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: > On Mon, Jun 16, 2008 at 08:20:53PM -0500, Karl Denninger wrote: > > On Thu, May 08, 2008 at 10:30:01AM +0100, Pete French wrote: > > > > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > > > > have been out of the loop on the card(s) that work properly for a good long > > > > while. > > > > > > HP P400 cards are PCI express and SAS - they work very well under FreeBSD. > > > I've also used the cheaper E200 and that appears to be fine too, though I > > > havent run it for as long as the 400's. > > > > > > http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html > > > > > > -pete. > > > > > > > Following upon my own stuff, I just laid hands on a Quad-Xeon machine with an > > Intel SRCSAS18E card in it, and well, the only way I can describe it is "oh > > my GOD!" > > > > Off a couple of older 250GB SATA drives, mirrored, it sustained 70MB/sec over > > the entire disk's volume space on reads and had ZERO visible impact on CPU > > OR another process doing mixed I/O at the same time (!). > > > > That's impressive. > > > > If its stable. > > > > The cards are not cheap, however. > > > > The only "gotcha" is that all configuration of the drive(s) appears to be > > done through the controller. I assume I COULD use something like gmirror, > > but see little reason to do so. > > > > -- Karl Denninger > > karl@denninger.net > > Ok, another followup! > > Is there a mangement interface program for the "mfi" driver somewhere? I > rooted around in "ports" but didn't find one, nor on the base system. > > The Linux ones want to talk to the "amr" driver which is the older LSI Logic > MegaRAID boards, not the newer ones that the mfi driver talks to. > > No management tool = el-sucko, because you can't rebuild a failed disk or > even shut the alarm on the board off! The sysutil/linux-megacli port looks like it might do the trick. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 05:37:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFDA11065672 for ; Wed, 18 Jun 2008 05:37:03 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 588198FC0C for ; Wed, 18 Jun 2008 05:37:03 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m5I5a6bt027761 for ; Wed, 18 Jun 2008 00:36:06 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Wed Jun 18 00:36:06 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m5I5a6ov027758 for freebsd-stable@freebsd.org; Wed, 18 Jun 2008 00:36:06 -0500 (CDT) (envelope-from karl) Date: Wed, 18 Jun 2008 00:36:05 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080618053605.GA27112@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618050530.GA75831@citylink.fud.org.nz> User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 05:37:03 -0000 On Tue, Jun 17, 2008 at 10:05:31PM -0700, Andrew Thompson wrote: > On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: > > On Mon, Jun 16, 2008 at 08:20:53PM -0500, Karl Denninger wrote: > > > On Thu, May 08, 2008 at 10:30:01AM +0100, Pete French wrote: > > > > > I assume SCSI is the best path forward (either SA/SCSI or traditional) but > > > > > have been out of the loop on the card(s) that work properly for a good long > > > > > while. > > > > > > > > HP P400 cards are PCI express and SAS - they work very well under FreeBSD. > > > > I've also used the cheaper E200 and that appears to be fine too, though I > > > > havent run it for as long as the 400's. > > > > > > > > http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html > > > > > > > > -pete. > > > > > > > > > > Following upon my own stuff, I just laid hands on a Quad-Xeon machine with an > > > Intel SRCSAS18E card in it, and well, the only way I can describe it is "oh > > > my GOD!" > > > > Ok, another followup! > > > > Is there a mangement interface program for the "mfi" driver somewhere? I > > rooted around in "ports" but didn't find one, nor on the base system. > > > > The Linux ones want to talk to the "amr" driver which is the older LSI Logic > > MegaRAID boards, not the newer ones that the mfi driver talks to. > > > > No management tool = el-sucko, because you can't rebuild a failed disk or > > even shut the alarm on the board off! > > Its sysutils/linux-megacli. Nope. It builds and installs but doesn't work (already tried this one.) Attempting to ask it for the number of boards returns "0". This may have something to do with changes made to the device structure(s) in FreeBSD-7 (I don't have a 6 machine to test on any more) but it definitely does not function. -- Karl Denninger karl@denninger.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 09:56:56 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E08061065680 for ; Wed, 18 Jun 2008 09:56:56 +0000 (UTC) (envelope-from helen@nstnetwork.com) Received: from Linux-Mail.com (mail.kwww.net [61.129.70.140]) by mx1.freebsd.org (Postfix) with ESMTP id A3BDC8FC27 for ; Wed, 18 Jun 2008 09:56:56 +0000 (UTC) (envelope-from helen@nstnetwork.com) Received: from nstserver (unknown [121.34.196.142]) by Linux-Mail.com (Postfix) with ESMTP id 1832F1A84D7 for ; Wed, 18 Jun 2008 17:58:58 +0800 (CST) From: "helen@nstnetwork.com" To: stable@freebsd.org Date: Wed, 18 Jun 2008 16:58:23 +0800 Message-Id: <20080618095858.1832F1A84D7@Linux-Mail.com> Cc: Subject: Sell Cisco Systems equipment items X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: helen@nstnetwork.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 09:56:57 -0000 Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. ¡¡ Regards Helen.Zhou www.nstnetwork.com MSN: Helen@nstnetwork.com Email: Helen@nstnetwork.com AOL helenxuezhou Icq 320-880-606 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 09:56:56 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E86FF1065685 for ; Wed, 18 Jun 2008 09:56:56 +0000 (UTC) (envelope-from helen@nstnetwork.com) Received: from Linux-Mail.com (mail.kwww.net [61.129.70.140]) by mx1.freebsd.org (Postfix) with ESMTP id AA51F8FC2C for ; Wed, 18 Jun 2008 09:56:56 +0000 (UTC) (envelope-from helen@nstnetwork.com) Received: from nstserver (unknown [121.34.196.142]) by Linux-Mail.com (Postfix) with ESMTP id BE16D1A89F6 for ; Wed, 18 Jun 2008 17:56:31 +0800 (CST) From: "helen@nstnetwork.com" To: freebsd-stable@FreeBSD.org Date: Wed, 18 Jun 2008 16:55:56 +0800 Message-Id: <20080618095631.BE16D1A89F6@Linux-Mail.com> Cc: Subject: Sell Cisco Systems equipment items X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: helen@nstnetwork.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 09:56:57 -0000 Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, ...... NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, ...... WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, ...... CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, ...... MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, .... and so on. ¡¡ Regards Helen.Zhou www.nstnetwork.com MSN: Helen@nstnetwork.com Email: Helen@nstnetwork.com AOL helenxuezhou Icq 320-880-606 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 10:30:01 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE6E1065691 for ; Wed, 18 Jun 2008 10:30:01 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB208FC29 for ; Wed, 18 Jun 2008 10:30:01 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 7401A1B10EDC; Wed, 18 Jun 2008 12:29:59 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-9.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, SARE_OBFU_ALL autolearn=no version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 14EA81B10CB6; Wed, 18 Jun 2008 12:29:57 +0200 (CEST) Message-ID: <4858E3A4.2000208@moneybookers.com> Date: Wed, 18 Jun 2008 13:29:56 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> In-Reply-To: <20080618053605.GA27112@FS.denninger.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Cc: Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 10:30:01 -0000 Karl Denninger wrote: > On Tue, Jun 17, 2008 at 10:05:31PM -0700, Andrew Thompson wrote: > >> On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: >> >>> On Mon, Jun 16, 2008 at 08:20:53PM -0500, Karl Denninger wrote: >>> >>>> On Thu, May 08, 2008 at 10:30:01AM +0100, Pete French wrote: >>>> >>>>>> I assume SCSI is the best path forward (either SA/SCSI or traditional) but >>>>>> have been out of the loop on the card(s) that work properly for a good long >>>>>> while. >>>>>> >>>>> HP P400 cards are PCI express and SAS - they work very well under FreeBSD. >>>>> I've also used the cheaper E200 and that appears to be fine too, though I >>>>> havent run it for as long as the 400's. >>>>> >>>>> http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html >>>>> >>>>> -pete. >>>>> >>>>> >>>> Following upon my own stuff, I just laid hands on a Quad-Xeon machine with an >>>> Intel SRCSAS18E card in it, and well, the only way I can describe it is "oh >>>> my GOD!" >>>> >>> Ok, another followup! >>> >>> Is there a mangement interface program for the "mfi" driver somewhere? I >>> rooted around in "ports" but didn't find one, nor on the base system. >>> >>> The Linux ones want to talk to the "amr" driver which is the older LSI Logic >>> MegaRAID boards, not the newer ones that the mfi driver talks to. >>> >>> No management tool = el-sucko, because you can't rebuild a failed disk or >>> even shut the alarm on the board off! >>> >> Its sysutils/linux-megacli. >> > > Nope. It builds and installs but doesn't work (already tried this one.) > > Attempting to ask it for the number of boards returns "0". > > This may have something to do with changes made to the device structure(s) > in FreeBSD-7 (I don't have a 6 machine to test on any more) but it > definitely does not function. > It works fine for me on very recent 7-STABLE. megacli -CfgDsply -a0 ============================================================================== Adapter: 0 Product Name: PERC 5/i Integrated Memory: 256MB BBU: Present Serial No: 12345 ============================================================================== -cut- megacli -AdpAllInfo -aALL also works without a problem. 7.0-STABLE-200805 FreeBSD 7.0-STABLE-200805 #0: Sun May 11 11:55:15 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? Though I think there is a small bug in the port (maintainer CCed) It wants compat.linux.osrelease=2.6.12, but I think it should be compat.linux.osrelease=2.6.16 ? Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 I think you are confusing mega-cli with megamgr (which is the one that work with amr driver) -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 13:19:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69237106564A; Wed, 18 Jun 2008 13:19:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4C88FC21; Wed, 18 Jun 2008 13:19:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IDJWD6056994; Wed, 18 Jun 2008 09:19:33 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-hackers@freebsd.org, stef@memberwebs.com Date: Wed, 18 Jun 2008 09:17:05 -0400 User-Agent: KMail/1.9.7 References: <20080615112318.146C1F18512@mx.npubs.com> In-Reply-To: <20080615112318.146C1F18512@mx.npubs.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806180917.05689.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 09:19:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7498/Tue Jun 17 22:08:00 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 13:19:41 -0000 On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: > I've been trying to track down a deadlock on some newish production > servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a > specific (although mundane) hardware configuration, and each of several > servers running this hardware deadlock about once per week. > > Although I suspect that this is not hardware related, from a (naive) > perusal of the attached stack traces. > > Forgive me if my interpretation of this is all wrong, but I'm pretty > desperate for help. So here's my basic understanding of the deadlock: > > These processes seem to be waiting on the page queue mutex: > sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) > bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) > httpd (in trap > trap_pfault > vm_fault) > [g_up] (in g_vfs_done > bufdone) > > The page queue mutex is held by rsync process: > rsync (in trap > trap_pfault > vm_fault > pmap_enter) > > Rsync kernel process (in pmap_enter) was interrupted while holding the > page queue lock? > > > Giant is enabled in loader.conf due to the needs of the pf firewall when > dealing with user credentials lookups. I do not believe that Giant plays > into this deadlock. Kernel config attached. > > Any and all help or info is welcome. Thanks in advance. Try this change: jhb 2007-10-27 22:07:40 UTC FreeBSD src repository Modified files: sys/kern sched_4bsd.c Log: Change the roundrobin implementation in the 4BSD scheduler to trigger a userland preemption directly from hardclock() via sched_clock() when a thread uses up a full quantum instead of using a periodic timeout to cause a userland preemption every so often. This fixes a potential deadlock when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held by a thread pinned or bound to another CPU. The current thread on that CPU will never be preempted while softclock is blocked. Note that ULE already drives its round-robin userland preemption from sched_clock() as well and always enables IPI_PREEMPT. MFC after: 1 week Revision Changes Path 1.108 +8 -29 src/sys/kern/sched_4bsd.c We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD when softclock() (swi4: clock) blocks on a lock like Giant. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 13:32:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 167BB1065672 for ; Wed, 18 Jun 2008 13:32:09 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.freebsd.org (Postfix) with ESMTP id 944B58FC15 for ; Wed, 18 Jun 2008 13:32:08 +0000 (UTC) (envelope-from ruben@verweg.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verweg.com; s=verweg; t=1213795926; bh=oaStmDY5Hw9Ga+MUqZkikGv7eBd6Z7bxJpVUxvC1xsI=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Mailer; b=GJALcMwdxGPjFvZRttST5Gg/9aNeOxkcsgSpTB2eMSwZQ0RMisOJwd x1sjsRzYV1k9+BwYw53Pm4+FjYrlxwqCqI/4DRTN/wnflfxSrR4eozgYpAOby03G4iD ewIQqIJkNThCJXdqk92/mOAd0cl20c9TkWQsyaDoBelZ0fNd3E= Received: from [IPv6:::1] (chimp.ripe.net [193.0.1.199]) (authenticated bits=0) by erg.verweg.com (8.14.2/8.14.2) with ESMTP id m5IDVv7U006983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2008 13:32:05 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host chimp.ripe.net [193.0.1.199] claimed to be [IPv6:::1] Message-Id: <17DF181F-D308-4ED0-B21E-64578F1D0DEB@verweg.com> From: Ruben van Staveren To: Stefan Lambrev In-Reply-To: <4858E3A4.2000208@moneybookers.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 18 Jun 2008 15:31:50 +0200 References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> <4858E3A4.2000208@moneybookers.com> X-Mailer: Apple Mail (2.924) X-Virus-Scanned: ClamAV 0.93/6805/Wed Apr 16 19:57:54 2008 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (erg.verweg.com [217.77.141.129]); Wed, 18 Jun 2008 13:32:07 +0000 (UTC) Cc: freebsd-stable@freebsd.org Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 13:32:09 -0000 Hi, On 18 Jun 2008, at 12:29, Stefan Lambrev wrote: > Did you follow all steps from ports/sysutils/linux-megacli/pkg- > message ? > Though I think there is a small bug in the port (maintainer CCed) > It wants compat.linux.osrelease=2.6.12, but I think it should be > compat.linux.osrelease=2.6.16 ? Last time I checked it was still 2.6.12. it still is set to that value on our 2950's (running 6.2 and linux_base-fc-4_9) > Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 > I think you are confusing mega-cli with megamgr (which is the one > that work with amr driver) People should only realise that they are running a linux binary under emulation in order to manage their mission critical servers. It is a thing you might not like. Regards, Ruben From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 14:03:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90EA8106566C for ; Wed, 18 Jun 2008 14:03:34 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 144C98FC35 for ; Wed, 18 Jun 2008 14:03:33 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m5IE2awL040183 for ; Wed, 18 Jun 2008 09:02:36 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Wed Jun 18 09:02:36 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m5IE2a6R040176 for freebsd-stable@freebsd.org; Wed, 18 Jun 2008 09:02:36 -0500 (CDT) (envelope-from karl) Date: Wed, 18 Jun 2008 09:02:36 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080618140236.GA23551@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> <4858E3A4.2000208@moneybookers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4858E3A4.2000208@moneybookers.com> User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 14:03:37 -0000 On Wed, Jun 18, 2008 at 01:29:56PM +0300, Stefan Lambrev wrote: > Karl Denninger wrote: > >On Tue, Jun 17, 2008 at 10:05:31PM -0700, Andrew Thompson wrote: > > > >>On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: > >>>>Intel SRCSAS18E card in it, and well, the only way I can describe it is > >>>>"oh > >>>>my GOD!" > >>>> > >>>Ok, another followup! > >>> > >>>Is there a mangement interface program for the "mfi" driver somewhere? I > >>>rooted around in "ports" but didn't find one, nor on the base system. > >>> > >>>The Linux ones want to talk to the "amr" driver which is the older LSI > >>>Logic > >>>MegaRAID boards, not the newer ones that the mfi driver talks to. > >>> > >>>No management tool = el-sucko, because you can't rebuild a failed disk or > >>>even shut the alarm on the board off! > >>> > >>Its sysutils/linux-megacli. > >> > > > >Nope. It builds and installs but doesn't work (already tried this one.) > > > >Attempting to ask it for the number of boards returns "0". > > > >This may have something to do with changes made to the device structure(s) > >in FreeBSD-7 (I don't have a 6 machine to test on any more) but it > >definitely does not function. > > > It works fine for me on very recent 7-STABLE. > > megacli -CfgDsply -a0 > > ============================================================================== > Adapter: 0 > Product Name: PERC 5/i Integrated > Memory: 256MB > BBU: Present > Serial No: 12345 > ============================================================================== > -cut- > > megacli -AdpAllInfo -aALL also works without a problem. > > 7.0-STABLE-200805 FreeBSD 7.0-STABLE-200805 #0: Sun May 11 11:55:15 UTC > 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? > Though I think there is a small bug in the port (maintainer CCed) > It wants compat.linux.osrelease=2.6.12, but I think it should be > compat.linux.osrelease=2.6.16 ? > Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 > I think you are confusing mega-cli with megamgr (which is the one that > work with amr driver) dbms# megacli -CfgDsply -a0 Failed to get ControllerId List. Failed to get CpController object. dbms# But the card is definitely there; this is what it last logged when I manually yanked one of the mirrored drives, then shut down and told it to rebuild from the GUI before boot and let it go on its way: mfi0: 501 - PD 10(e252/s1) progress 99% seconds 7017s: Rebuild progress on PD 0a(e0xfc/s1) is 98.94%(7017s) mfi0: 502 - PD 10(e252/s1) progress 100% seconds 7158s: Rebuild progress on PD 0a(e0xfc/s1) is 99.94%(7158s) mfi0: 503 - PD 10(e252/s1) event: Rebuild complete on PD 0a(e0xfc/s1) mfi0: 504 - VD 00/0 state prior 2 new 3: State change on VD 00/0 from DEGRADED(2) to OPTIMAL(3) mfi0: 505 - VD 00/0 event: VD 00/0 is now OPTIMAL mfi0: 506 - PD 10(e252/s1) state prior 20 new 24: State change on PD 0a(e0xfc/s1) from REBUILD(14) to ONLINE(18) Oook! So we have a card that the driver is perfectly happy with, but the management interface can't find. Note that this is the Intel board; I grabbed the Intel version of the software for Linux (which appears to be essentially the same code but under Intel's name), set the branding so the Linux emulator would play nice, and got the same thing: dbms# ./CmdTool2 -Cfgdsply -a0 Failed to get ControllerId List. Failed to get CpController object. dbms# Hmmmm... this is on a new machine that I loaded 7-RELEASE on and then grabbed the CVS tree and pulled a -rRELENG_7 on and rebuilt. Let me dig around a bit..... I wonder if I got a "funny" in here... looking at kernel versions, it appears I might. If so, that's going to be an interesting problem (as in "how did that happen?") to figure out. uname -v is returning: FreeBSD 7.0-CURRENT-200608 #0: Mon Jun 16 20:54:25 UTC 2008 karl@dbms.denninger.net:/usr/obj/usr/src/sys/GENERIC How'd that happen with the tag "RELENG_7" in the tag? (and yes, it IS in there in the CVS directory in the "Tag" file....) -- Karl Denninger karl@denninger.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 14:07:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0122F1065677 for ; Wed, 18 Jun 2008 14:07:13 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 931058FC15 for ; Wed, 18 Jun 2008 14:07:12 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 8C6141B10F5E; Wed, 18 Jun 2008 16:07:10 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 1C2DC1B10FA1; Wed, 18 Jun 2008 16:07:07 +0200 (CEST) Message-ID: <4859168A.1050601@moneybookers.com> Date: Wed, 18 Jun 2008 17:07:06 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Ruben van Staveren References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> <4858E3A4.2000208@moneybookers.com> <17DF181F-D308-4ED0-B21E-64578F1D0DEB@verweg.com> In-Reply-To: <17DF181F-D308-4ED0-B21E-64578F1D0DEB@verweg.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 14:07:13 -0000 Hi, Ruben van Staveren wrote: > > Hi, > > On 18 Jun 2008, at 12:29, Stefan Lambrev wrote: > >> Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? >> Though I think there is a small bug in the port (maintainer CCed) >> It wants compat.linux.osrelease=2.6.12, but I think it should be >> compat.linux.osrelease=2.6.16 ? > > Last time I checked it was still 2.6.12. it still is set to that value > on our 2950's (running 6.2 and linux_base-fc-4_9) I never saw 2.6.12 in documentation, but you may be right. Tough in ports/UPDATING only 2.6.16 is mention. http://blogs.freebsdish.org/netchild/category/freebsd/linuxolator/ speaks also only for 2.6.16 :) > >> Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 >> I think you are confusing mega-cli with megamgr (which is the one >> that work with amr driver) > > People should only realise that they are running a linux binary under > emulation in order to manage their mission critical servers. It is a > thing you might not like. It has been always this way with lsi ? Actually the difference now is that we are forced to use tools under beta/experimental linuxolator ;) > > Regards, > Ruben -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 14:20:51 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BB6A1065672 for ; Wed, 18 Jun 2008 14:20:51 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFA18FC17 for ; Wed, 18 Jun 2008 14:20:50 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 104B41B10FB1; Wed, 18 Jun 2008 16:20:49 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-9.8 required=5.0 tests=ALL_TRUSTED,BAYES_00, SARE_OBFU_ALL autolearn=no version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 5A2A71B10E4E for ; Wed, 18 Jun 2008 16:20:40 +0200 (CEST) Message-ID: <485919B8.20705@moneybookers.com> Date: Wed, 18 Jun 2008 17:20:40 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> <4858E3A4.2000208@moneybookers.com> <20080618140236.GA23551@FS.denninger.net> In-Reply-To: <20080618140236.GA23551@FS.denninger.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 14:20:51 -0000 Hi Karl, Karl Denninger wrote: > On Wed, Jun 18, 2008 at 01:29:56PM +0300, Stefan Lambrev wrote: > >> Karl Denninger wrote: >> >>> On Tue, Jun 17, 2008 at 10:05:31PM -0700, Andrew Thompson wrote: >>> >>> >>>> On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: >>>> >>>>>> Intel SRCSAS18E card in it, and well, the only way I can describe it is >>>>>> "oh >>>>>> my GOD!" >>>>>> >>>>>> >>>>> Ok, another followup! >>>>> >>>>> Is there a mangement interface program for the "mfi" driver somewhere? I >>>>> rooted around in "ports" but didn't find one, nor on the base system. >>>>> >>>>> The Linux ones want to talk to the "amr" driver which is the older LSI >>>>> Logic >>>>> MegaRAID boards, not the newer ones that the mfi driver talks to. >>>>> >>>>> No management tool = el-sucko, because you can't rebuild a failed disk or >>>>> even shut the alarm on the board off! >>>>> >>>>> >>>> Its sysutils/linux-megacli. >>>> >>>> >>> Nope. It builds and installs but doesn't work (already tried this one.) >>> >>> Attempting to ask it for the number of boards returns "0". >>> >>> This may have something to do with changes made to the device structure(s) >>> in FreeBSD-7 (I don't have a 6 machine to test on any more) but it >>> definitely does not function. >>> >>> >> It works fine for me on very recent 7-STABLE. >> >> megacli -CfgDsply -a0 >> >> ============================================================================== >> Adapter: 0 >> Product Name: PERC 5/i Integrated >> Memory: 256MB >> BBU: Present >> Serial No: 12345 >> ============================================================================== >> -cut- >> >> megacli -AdpAllInfo -aALL also works without a problem. >> >> 7.0-STABLE-200805 FreeBSD 7.0-STABLE-200805 #0: Sun May 11 11:55:15 UTC >> 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> >> Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? >> Though I think there is a small bug in the port (maintainer CCed) >> It wants compat.linux.osrelease=2.6.12, but I think it should be >> compat.linux.osrelease=2.6.16 ? >> Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 >> I think you are confusing mega-cli with megamgr (which is the one that >> work with amr driver) >> > > dbms# megacli -CfgDsply -a0 > > Failed to get ControllerId List. > Failed to get CpController object. > dbms# > Sorry if you already answer this and I missed it, but do you have mfi_linux, linprocfs, linsysfs loaded as modules (or build in kernel)? Also do you have mounted: linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) If this is done I'm really out of ideas. > But the card is definitely there; this is what it last logged when I manually > yanked one of the mirrored drives, then shut down and told it to rebuild > from the GUI before boot and let it go on its way: > > mfi0: 501 - PD 10(e252/s1) progress 99% seconds 7017s: Rebuild progress on > PD 0a(e0xfc/s1) is 98.94%(7017s) > mfi0: 502 - PD 10(e252/s1) progress 100% seconds 7158s: Rebuild progress on > PD 0a(e0xfc/s1) is 99.94%(7158s) > mfi0: 503 - PD 10(e252/s1) event: Rebuild complete on PD 0a(e0xfc/s1) > mfi0: 504 - VD 00/0 state prior 2 new 3: State change on VD 00/0 from > DEGRADED(2) to OPTIMAL(3) > mfi0: 505 - VD 00/0 event: VD 00/0 is now OPTIMAL > mfi0: 506 - PD 10(e252/s1) state prior 20 new 24: State change on PD > 0a(e0xfc/s1) from REBUILD(14) to ONLINE(18) > > Oook! > > So we have a card that the driver is perfectly happy with, but the > management interface can't find. > > Note that this is the Intel board; I grabbed the Intel version of the > software for Linux (which appears to be essentially the same code but under > Intel's name), set the branding so the Linux emulator would play nice, and > got the same thing: > > dbms# ./CmdTool2 -Cfgdsply -a0 > > Failed to get ControllerId List. > Failed to get CpController object. > dbms# > > Hmmmm... this is on a new machine that I loaded 7-RELEASE on and then > grabbed the CVS tree and pulled a -rRELENG_7 on and rebuilt. > > Let me dig around a bit..... I wonder if I got a "funny" in here... > looking at kernel versions, it appears I might. > > If so, that's going to be an interesting problem (as in "how did that happen?") > to figure out. > > uname -v is returning: > FreeBSD 7.0-CURRENT-200608 #0: Mon Jun 16 20:54:25 UTC 2008 karl@dbms.denninger.net:/usr/obj/usr/src/sys/GENERIC > > How'd that happen with the tag "RELENG_7" in the tag? (and yes, it IS > in there in the CVS directory in the "Tag" file....) > > -- Karl Denninger > karl@denninger.net > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 14:35:19 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 362EB1065677 for ; Wed, 18 Jun 2008 14:35:19 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.freebsd.org (Postfix) with ESMTP id CF9568FC22 for ; Wed, 18 Jun 2008 14:35:18 +0000 (UTC) (envelope-from ruben@verweg.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verweg.com; s=verweg; t=1213799715; bh=m+yz77jvNXxEPFM60KYW19OHB+6+ukc8dujRUdUJoec=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Pgp-Agent:X-Mailer; b=DfFVxwonyJK/y2Y9GGtLXv8O5/SXBCrvDhCAMCKkIS QcDx4U6XRbzxnDD7Upl4kwTAYLZu7uWqhPgARm5g9rUEvgxxYe+ZHLli6IC0UlRzQnu gV/9stEhwEzy+zcttiRbvhYTZJ6RczWcPfZ2a+U2c8HbkaPCc08n6qwgJM/HJQ= Received: from [IPv6:::1] (chimp.ripe.net [193.0.1.199]) (authenticated bits=0) by erg.verweg.com (8.14.2/8.14.2) with ESMTP id m5IEZ6QY011079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2008 14:35:15 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host chimp.ripe.net [193.0.1.199] claimed to be [IPv6:::1] Message-Id: <453916E3-FF51-4EF1-B0B4-EBBC6D1E613E@verweg.com> From: Ruben van Staveren To: Stefan Lambrev In-Reply-To: <4859168A.1050601@moneybookers.com> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-224--730709520" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Wed, 18 Jun 2008 16:34:51 +0200 References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> <4858E3A4.2000208@moneybookers.com> <17DF181F-D308-4ED0-B21E-64578F1D0DEB@verweg.com> <4859168A.1050601@moneybookers.com> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.924) X-Virus-Scanned: ClamAV 0.93/6805/Wed Apr 16 19:57:54 2008 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (erg.verweg.com [217.77.141.129]); Wed, 18 Jun 2008 14:35:17 +0000 (UTC) Cc: freebsd-stable@freebsd.org Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 14:35:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-224--730709520 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 18 Jun 2008, at 16:07, Stefan Lambrev wrote: >> Last time I checked it was still 2.6.12. it still is set to that >> value on our 2950's (running 6.2 and linux_base-fc-4_9) > I never saw 2.6.12 in documentation, but you may be right. Tough in > ports/UPDATING only 2.6.16 is mention. > http://blogs.freebsdish.org/netchild/category/freebsd/linuxolator/ > speaks also only for 2.6.16 :) I got this from reading the commit message of r1.5 of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/mfi.c I don't know what the change set between 2.6.12 and 2.6.16 is regarding the linuxolator. As I see it the difference should only in more syscalls being supported. So if megacli has enough to get going on by setting it to just 2.6.12 it should not have a requirement for 2.6.16. Correct me if I am wrong (and I'll fix the instructions in the port) Of course, if you think mfi(4) should support your board csup up to the latest stable and see whether it works. Also run through /usr/ local/sbin/megacli instead of /usr/local/libexec/MegaCli as it will perform some sanity checks. >> People should only realise that they are running a linux binary >> under emulation in order to manage their mission critical servers. >> It is a thing you might not like. > It has been always this way with lsi ? Actually the difference now > is that we are forced to use tools under beta/experimental > linuxolator ;) >> Sad but true. But I managed with ease to replace a hot spare not that long ago. You might want to have a peek at the cheat sheet hosted at http://tools.rapidsoft.de/perc/ Cheers, Ruben --Apple-Mail-224--730709520 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFIWR0NZ88+mcQxRw0RArF1AJ9ZcYZOgdH4cpAIN6IpgEfHHvr2LQCfebRr YBBjQQBTjs/H4zVauWC5uLA= =XCN3 -----END PGP SIGNATURE----- --Apple-Mail-224--730709520-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 14:48:13 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 430D41065670 for ; Wed, 18 Jun 2008 14:48:13 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id D28228FC2B for ; Wed, 18 Jun 2008 14:48:12 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id 6C00D1B10FE7; Wed, 18 Jun 2008 16:48:11 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on malcho.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.4 Received: from hater.haters.org (hater.cmotd.com [192.168.3.125]) by blah.sun-fish.com (Postfix) with ESMTP id 6DF841B10FA4; Wed, 18 Jun 2008 16:48:04 +0200 (CEST) Message-ID: <48592023.7010201@moneybookers.com> Date: Wed, 18 Jun 2008 17:48:03 +0300 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Ruben van Staveren References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> <4858E3A4.2000208@moneybookers.com> <17DF181F-D308-4ED0-B21E-64578F1D0DEB@verweg.com> <4859168A.1050601@moneybookers.com> <453916E3-FF51-4EF1-B0B4-EBBC6D1E613E@verweg.com> In-Reply-To: <453916E3-FF51-4EF1-B0B4-EBBC6D1E613E@verweg.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 14:48:13 -0000 Hi Ruben, Ruben van Staveren wrote: > > On 18 Jun 2008, at 16:07, Stefan Lambrev wrote: > >>> Last time I checked it was still 2.6.12. it still is set to that >>> value on our 2950's (running 6.2 and linux_base-fc-4_9) >> I never saw 2.6.12 in documentation, but you may be right. Tough in >> ports/UPDATING only 2.6.16 is mention. >> http://blogs.freebsdish.org/netchild/category/freebsd/linuxolator/ >> speaks also only for 2.6.16 :) > > I got this from reading the commit message of r1.5 of > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/mfi.c > > I don't know what the change set between 2.6.12 and 2.6.16 is > regarding the linuxolator. As I see it the difference should only in > more syscalls being supported. So if megacli has enough to get going > on by setting it to just 2.6.12 it should not have a requirement for > 2.6.16. Correct me if I am wrong (and I'll fix the instructions in the > port) Yes that's correct, so the sanity check should be >= 2.6.12, not just equal to 2.6.12? > > Of course, if you think mfi(4) should support your board csup up to > the latest stable and see whether it works. Also run through > /usr/local/sbin/megacli instead of /usr/local/libexec/MegaCli as it > will perform some sanity checks. I do not have problems with mfi and megacli ;) It's the OP who have them. > >>> People should only realise that they are running a linux binary >>> under emulation in order to manage their mission critical servers. >>> It is a thing you might not like. >> It has been always this way with lsi ? Actually the difference now is >> that we are forced to use tools under beta/experimental linuxolator ;) >>> > > Sad but true. But I managed with ease to replace a hot spare not that > long ago. > > You might want to have a peek at the cheat sheet hosted at > http://tools.rapidsoft.de/perc/ nice site :) > > Cheers, > Ruben > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 15:32:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D340106566C for ; Wed, 18 Jun 2008 15:32:26 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id DDC9F8FC21 for ; Wed, 18 Jun 2008 15:32:25 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m5IFVRQS039496 for ; Wed, 18 Jun 2008 10:31:27 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Wed Jun 18 10:31:27 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m5IFVRmf039493 for freebsd-stable@freebsd.org; Wed, 18 Jun 2008 10:31:27 -0500 (CDT) (envelope-from karl) Date: Wed, 18 Jun 2008 10:31:27 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080618153127.GA2662@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20080508050550.GA76170@FS.denninger.net> <20080617012053.GA82316@FS.denninger.net> <20080618041530.GA81315@FS.denninger.net> <20080618050530.GA75831@citylink.fud.org.nz> <20080618053605.GA27112@FS.denninger.net> <4858E3A4.2000208@moneybookers.com> <20080618140236.GA23551@FS.denninger.net> <485919B8.20705@moneybookers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485919B8.20705@moneybookers.com> User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 15:32:26 -0000 > > > >dbms# ./CmdTool2 -Cfgdsply -a0 > > > >Failed to get ControllerId List. > >Failed to get CpController object. > >dbms# > > > >Hmmmm... this is on a new machine that I loaded 7-RELEASE on and then > >grabbed the CVS tree and pulled a -rRELENG_7 on and rebuilt. > > > >Let me dig around a bit..... I wonder if I got a "funny" in here... > >looking at kernel versions, it appears I might. > > > >If so, that's going to be an interesting problem (as in "how did that > >happen?") > >to figure out. > > > >uname -v is returning: > >FreeBSD 7.0-CURRENT-200608 #0: Mon Jun 16 20:54:25 UTC 2008 > >karl@dbms.denninger.net:/usr/obj/usr/src/sys/GENERIC > >How'd that happen with the tag "RELENG_7" in the tag? (and yes, it IS > >in there in the CVS directory in the "Tag" file....) > > > >-- Karl Denninger > >karl@denninger.net Ok, wiped the src tree, re-cvs'd out the RELENG_7, rebuild world and kernel and reinstalled (nice fast machine eh?) Anyway, no change: dbms# uname -v FreeBSD 7.0-STABLE #1: Wed Jun 18 14:43:29 CDT 2008 karl@dbms.denninger.net:/usr/obj/usr/src/sys/GENERIC dbms# megacli -adpCount Controller Count: 0. dbms# megacli -Cfgdsply -a0 Failed to get ControllerId List. Failed to get CpController object. Still no joy dbms# kldstat Id Refs Address Size Name 1 17 0xc0400000 943140 kernel 2 1 0xc0d44000 6a2c4 acpi.ko 3 1 0xc5534000 7000 linprocfs.ko 4 3 0xc553b000 22000 linux.ko 5 1 0xc5585000 3000 linsysfs.ko 6 1 0xc7a34000 3000 daemon_saver.ko 7 1 0xc7c2d000 2000 mfi_linux.ko Says I got the proper KLDs loaded. dbms# mount /dev/mfid0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/mfid0s1e on /dbms (ufs, local, soft-updates) /dev/mfid0s1d on /usr (ufs, local, soft-updates) linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) The two linux "look-sees" are there. So it looks like all the pre-reqs are there, but it still doesn't work. Here's the ID on the card and volume: mfi0: 524 (267116948s/0x0020/0) - Adapter ticks 267116948 elapsed 61s: Time established as 06/18/08 15:09:08; (61 seconds since power on) mfid0: on mfi0 mfid0: 237464MB (486326272 sectors) RAID volume '' is optimal What am I missing? -- Karl Denninger karl@denninger.net From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 16:03:17 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9931065675; Wed, 18 Jun 2008 16:03:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 154368FC12; Wed, 18 Jun 2008 16:03:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IG38Hc058177; Wed, 18 Jun 2008 12:03:09 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Aristedes Maniatis Date: Wed, 18 Jun 2008 11:16:31 -0400 User-Agent: KMail/1.9.7 References: <77E81AD6-FBCC-4D30-A5CB-A9B918D4793F@ish.com.au> <200804221334.35001.jhb@freebsd.org> <0DB3A235-DF87-4413-90ED-E38BC44CA2B3@ish.com.au> In-Reply-To: <0DB3A235-DF87-4413-90ED-E38BC44CA2B3@ish.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181116.32450.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 12:03:10 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7499/Wed Jun 18 09:02:05 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: bzeeb+freebsd+lor@zabbadoz.net, jeff@freebsd.org, Jurgen Weber , freebsd-stable@freebsd.org, davidxu@freebsd.org Subject: Re: LOR on sleepqueue chain locks, Was: LOR sleepq/scrlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:03:17 -0000 On Friday 09 May 2008 10:53:15 pm Aristedes Maniatis wrote: > > On 23/04/2008, at 3:34 AM, John Baldwin wrote: > > >>> The > >>> real problem at the bottom of the screen though is a real issue. > >>> It's a LOR > >>> of two different sleepqueue chain locks. The problem is that when > >>> setrunnable() encounters a swapped out thread it tries to wakeup > >>> proc0, but > >>> if proc0 is asleep (which is typical) then its thread lock is a > >>> sleep queue > >>> chain lock, so waking up a swapped out thread from wakeup() will > >>> usually > >>> trigger this LOR. > >>> > >>> I think the best fix is to not have setrunnable() kick proc0 > >>> directly. > >>> Perhaps setrunnable() should return an int and return true if proc0 > >>> needs to > >>> be awakened and false otherwise. Then the the sleepq code (b/c only > >>> sleeping > >>> threads can be swapped out anyway) can return that value from > >>> sleepq_resume_thread() and can call kick_proc0() directly once it > >>> has dropped > >>> all of its own locks. > >>> > >>> -- > >>> John Baldwin > >> > >> The way you describe it, it almost sounds like this LOR should be > >> happening for everyone, all the time. To try and eliminate the > >> factors > >> which trigger it for us, we tried the following: removed PAE from > >> kernel, disabled PF. Neither of these things made any difference and > >> the error is fairly quickly reproducible (within a couple of hours > >> running various things to load the machine). The one thing we did not > >> test yet is removing ZFS from the picture. Note also that this box > >> ran > >> for years and years on FreeBSD 4.x without a hiccup (non PAE, ipfw > >> instead of pf and no ZFS of course). > > > > There are two things. 1) Most people who run witness (that I know > > of) don't > > run it on spinlocks because of the overhead, so LORs of spin locks > > are less > > well-reported than LORs of other locks (mutexes, rwlocks, etc.). 2) > > You have > > to have enough load on the box to swap out active processes to get > > into this > > situation. Between those I think that is why this is not more widely > > reported. > > > Hi John, > > Thanks for your efforts so far to track this LOR down. I've been > keeping an eye on cvs logs, but haven't seen anything which looks like > a patch for this. > > * is this still outstanding? > * or will it be addressed soon? > * if not, should I create a PR so that it doesn't get forgotten? > * in our case, although we can trigger it quickly with some load, the > problem occurs (and causes a complete machine lock) even under < 10% > load. Not sure if the combination of PAE/ZFS/SCHED ULE exacerbates > that in any way compared to a 'standard' build. Try http://www.FreeBSD.org/~jhb/patches/sleepq.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 16:03:30 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DF1C1065762 for ; Wed, 18 Jun 2008 16:03:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E13A68FC15 for ; Wed, 18 Jun 2008 16:03:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IG38He058177 for ; Wed, 18 Jun 2008 12:03:23 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: stable@freebsd.org Date: Wed, 18 Jun 2008 11:56:24 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181156.24310.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 12:03:24 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7499/Wed Jun 18 09:02:05 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: arl(4) MPSAFE patch -- test or driver will be removed! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:03:30 -0000 I have a patch to make arl(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/arl.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 16:03:35 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDC931065743 for ; Wed, 18 Jun 2008 16:03:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 864AB8FC1B for ; Wed, 18 Jun 2008 16:03:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IG38Hf058177 for ; Wed, 18 Jun 2008 12:03:29 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: stable@freebsd.org Date: Wed, 18 Jun 2008 11:57:13 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181157.13937.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 12:03:29 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7499/Wed Jun 18 09:02:05 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: cnw(4) MPSAFE patch -- test or driver will be removed! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:03:36 -0000 I have a patch to make cnw(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/cnw.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 16:03:41 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9108106587F for ; Wed, 18 Jun 2008 16:03:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 474BC8FC22 for ; Wed, 18 Jun 2008 16:03:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IG38Hg058177 for ; Wed, 18 Jun 2008 12:03:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: stable@freebsd.org Date: Wed, 18 Jun 2008 11:58:10 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181158.10243.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 12:03:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7499/Wed Jun 18 09:02:05 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: sbni(4) MPSAFE patch -- test or driver will be removed! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:03:41 -0000 I have a patch to make sbni(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/sbni.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 16:03:47 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D66106593D for ; Wed, 18 Jun 2008 16:03:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E7FDD8FC1B for ; Wed, 18 Jun 2008 16:03:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IG38Hh058177 for ; Wed, 18 Jun 2008 12:03:40 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: stable@freebsd.org Date: Wed, 18 Jun 2008 11:59:37 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181159.37906.jhb@FreeBSD.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 12:03:41 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7499/Wed Jun 18 09:02:05 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: sbsh(4) MPSAFE patch -- test or driver will be removed! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:03:47 -0000 I have a patch to make sbsh(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/sbsh.patch This driver has very dubious behavior in that it sleeps in lots of places when it shouldn't. I doubt it works properly even with Giant. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 16:03:53 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AC281065780 for ; Wed, 18 Jun 2008 16:03:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id CCF2A8FC21; Wed, 18 Jun 2008 16:03:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IG38Hi058177; Wed, 18 Jun 2008 12:03:46 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: stable@freebsd.org Date: Wed, 18 Jun 2008 12:01:05 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181201.05561.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 12:03:46 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7499/Wed Jun 18 09:02:05 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: pc98@freebsd.org Subject: snc(4) MPSAFE patch -- test or driver will be removed! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:03:53 -0000 I have a patch to make snc(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/snc.patch Note that this patch is relative to some cleanups done in HEAD a while ago. You should be able to just grab the snc(4) files from HEAD and apply the patch to test this on 6.x or 7.x. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 16:03:59 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 326341065ADA for ; Wed, 18 Jun 2008 16:03:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A6BA78FC28 for ; Wed, 18 Jun 2008 16:03:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m5IG38Hj058177 for ; Wed, 18 Jun 2008 12:03:52 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: stable@freebsd.org Date: Wed, 18 Jun 2008 12:01:09 -0400 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181201.09889.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 18 Jun 2008 12:03:52 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7499/Wed Jun 18 09:02:05 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: oltr(4) MPSAFE patch -- test or driver will be removed! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 16:03:59 -0000 I have a patch to make oltr(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/oltr.patch -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 17:46:06 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BEF81065677; Wed, 18 Jun 2008 17:46:06 +0000 (UTC) (envelope-from stef@memberwebs.com) Received: from mx.npubs.com (mail.npubs.com [209.66.100.224]) by mx1.freebsd.org (Postfix) with ESMTP id 168C48FC27; Wed, 18 Jun 2008 17:46:05 +0000 (UTC) (envelope-from stef@memberwebs.com) Received: from mx.npubs.com (avhost [209.66.100.194]) by mx.npubs.com (Postfix) with ESMTP id ACD5BF181FD; Wed, 18 Jun 2008 17:25:55 +0000 (UTC) Received: from northstar-srv2 (unknown [172.27.2.11]) by mx.npubs.com (Postfix) with ESMTP id CCAB4F18047; Wed, 18 Jun 2008 17:25:54 +0000 (UTC) From: Stef User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: John Baldwin References: <20080615112318.146C1F18512@mx.npubs.com> <200806180917.05689.jhb@freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Message-Id: <20080618172554.CCAB4F18047@mx.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Wed, 18 Jun 2008 17:25:55 +0000 (UTC) Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 17:46:06 -0000 John Baldwin wrote: > Try this change: > > jhb 2007-10-27 22:07:40 UTC > We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > when softclock() (swi4: clock) blocks on a lock like Giant. Awesome. Thanks. That looks like it'll do the trick. I'll deploy it and keep the list posted. Stef From owner-freebsd-stable@FreeBSD.ORG Wed Jun 18 21:10:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5A051065682 for ; Wed, 18 Jun 2008 21:10:18 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1EF8FC14 for ; Wed, 18 Jun 2008 21:10:18 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 18 Jun 2008 13:42:29 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.14.1/8.14.1) with ESMTP id m5IKgNIC022362; Wed, 18 Jun 2008 13:42:23 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.1/8.14.1/Submit) id m5IKgNa4022361; Wed, 18 Jun 2008 13:42:23 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200806182042.m5IKgNa4022361@ambrisko.com> In-Reply-To: <20080618153127.GA2662@FS.denninger.net> To: Karl Denninger Date: Wed, 18 Jun 2008 13:42:23 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 21:10:18 -0000 Karl Denninger writes: [snip] | Ok, wiped the src tree, re-cvs'd out the RELENG_7, rebuild world and kernel | and reinstalled (nice fast machine eh?) Not needed since FreeBSD 6.2 if I recall right. Forget if I got it in 6.1. | Anyway, no change: | | dbms# uname -v | FreeBSD 7.0-STABLE #1: Wed Jun 18 14:43:29 CDT 2008 karl@dbms.denninger.net:/usr/obj/usr/src/sys/GENERIC | | dbms# megacli -adpCount | | Controller Count: 0. | | dbms# megacli -Cfgdsply -a0 | | Failed to get ControllerId List. | Failed to get CpController object. | | Still no joy | | dbms# kldstat | Id Refs Address Size Name | 1 17 0xc0400000 943140 kernel | 2 1 0xc0d44000 6a2c4 acpi.ko | 3 1 0xc5534000 7000 linprocfs.ko | 4 3 0xc553b000 22000 linux.ko | 5 1 0xc5585000 3000 linsysfs.ko | 6 1 0xc7a34000 3000 daemon_saver.ko | 7 1 0xc7c2d000 2000 mfi_linux.ko | | Says I got the proper KLDs loaded. | | dbms# mount | /dev/mfid0s1a on / (ufs, local, soft-updates) | devfs on /dev (devfs, local) | /dev/mfid0s1e on /dbms (ufs, local, soft-updates) | /dev/mfid0s1d on /usr (ufs, local, soft-updates) | linprocfs on /usr/compat/linux/proc (linprocfs, local) | linsysfs on /usr/compat/linux/sys (linsysfs, local) | | The two linux "look-sees" are there. | | So it looks like all the pre-reqs are there, but it still doesn't work. | | Here's the ID on the card and volume: | | mfi0: 524 (267116948s/0x0020/0) - Adapter ticks 267116948 elapsed 61s: Time established as 06/18/08 15:09:08; (61 seconds since power on) | mfid0: on mfi0 | mfid0: 237464MB (486326272 sectors) RAID volume '' is optimal | | What am I missing? The linux version sysctl is? Also I think you need to make sure mfi_linux.ko is loaded before linuxsys.ko mounts so you get the emulation hooks. Verify that via: head /compat/linux/sys/class/scsi_host/*/proc_name results in one saying: megaraid_sas or it won't think it is there. The count is good to see if your file system & linux version sysctl stuff is in the right state. Once it detects it, then the ioctl should work. 6-stable, 7-stable and -current all have the latest stuff to support all of the ioctl stuff as Linux does for MegaCli. MegaCli does various things to try to find the card in Linux that is really strange IMHO. For FreeBSD it doesn't have to be that complicated. They unfortunately, have not released a FreeBSD MegaCli which they could ... Doug A. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 19 16:18:34 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D6C4106566C; Thu, 19 Jun 2008 16:18:34 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id D13268FC1A; Thu, 19 Jun 2008 16:18:33 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5JFvubh050627; Thu, 19 Jun 2008 09:57:57 -0600 (MDT) Message-ID: <485A81FF.1000000@gritton.org> Date: Thu, 19 Jun 2008 09:57:51 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <20080615112318.146C1F18512@mx.npubs.com> <200806180917.05689.jhb@freebsd.org> In-Reply-To: <200806180917.05689.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2008 16:18:34 -0000 John Baldwin wrote: > On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: > >> I've been trying to track down a deadlock on some newish production >> servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a >> specific (although mundane) hardware configuration, and each of several >> servers running this hardware deadlock about once per week. >> >> Although I suspect that this is not hardware related, from a (naive) >> perusal of the attached stack traces. >> >> Forgive me if my interpretation of this is all wrong, but I'm pretty >> desperate for help. So here's my basic understanding of the deadlock: >> >> These processes seem to be waiting on the page queue mutex: >> sendmail (in vm_mmap > vm_map_find > vm_map_insert > vm_map_pmap_enter) >> bsnmpd (in malloc, uma_large_malloc > page_alloc > kmem_malloc) >> httpd (in trap > trap_pfault > vm_fault) >> [g_up] (in g_vfs_done > bufdone) >> >> The page queue mutex is held by rsync process: >> rsync (in trap > trap_pfault > vm_fault > pmap_enter) >> >> Rsync kernel process (in pmap_enter) was interrupted while holding the >> page queue lock? >> >> >> Giant is enabled in loader.conf due to the needs of the pf firewall when >> dealing with user credentials lookups. I do not believe that Giant plays >> into this deadlock. Kernel config attached. >> >> Any and all help or info is welcome. Thanks in advance. >> > > Try this change: > > jhb 2007-10-27 22:07:40 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_4bsd.c > Log: > Change the roundrobin implementation in the 4BSD scheduler to trigger a > userland preemption directly from hardclock() via sched_clock() when a > thread uses up a full quantum instead of using a periodic timeout to cause > a userland preemption every so often. This fixes a potential deadlock > when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held > by a thread pinned or bound to another CPU. The current thread on that > CPU will never be preempted while softclock is blocked. > > Note that ULE already drives its round-robin userland preemption from > sched_clock() as well and always enables IPI_PREEMPT. > > MFC after: 1 week > > Revision Changes Path > 1.108 +8 -29 src/sys/kern/sched_4bsd.c > > We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD > when softclock() (swi4: clock) blocks on a lock like Giant. > I've been seeing similar troubles on 6.2 and I'll have to give this a try as we upgrade to 6.3. I notice "MFC after: 1 week" in the log; it's been a week - any chance of seeing this fix rolled into 6.x? - Jamie From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 04:38:11 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76EB6106564A for ; Fri, 20 Jun 2008 04:38:11 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 148958FC16 for ; Fri, 20 Jun 2008 04:38:10 +0000 (UTC) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.14.2/8.13.1) with SMTP id m5K4bCX8011252 for ; Thu, 19 Jun 2008 23:37:12 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jun 19 23:37:12 2008 Received: (from karl@localhost) by FS.denninger.net (8.14.2/8.13.1/Submit) id m5K4bCDA011248 for freebsd-stable@freebsd.org; Thu, 19 Jun 2008 23:37:12 -0500 (CDT) (envelope-from karl) Date: Thu, 19 Jun 2008 23:37:12 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20080620043712.GA7635@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20080618153127.GA2662@FS.denninger.net> <200806182042.m5IKgNa4022361@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806182042.m5IKgNa4022361@ambrisko.com> User-Agent: Mutt/1.4.2.3i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 04:38:11 -0000 On Wed, Jun 18, 2008 at 01:42:23PM -0700, Doug Ambrisko wrote: > Karl Denninger writes: > [snip] > | Ok, wiped the src tree, re-cvs'd out the RELENG_7, rebuild world and kernel > | and reinstalled (nice fast machine eh?) > > Not needed since FreeBSD 6.2 if I recall right. Forget if I got it in > 6.1. > > | Anyway, no change: > | > | dbms# uname -v > | FreeBSD 7.0-STABLE #1: Wed Jun 18 14:43:29 CDT 2008 karl@dbms.denninger.net:/usr/obj/usr/src/sys/GENERIC > | > | dbms# megacli -adpCount > | > | Controller Count: 0. > | > | dbms# megacli -Cfgdsply -a0 > | > | Failed to get ControllerId List. > | Failed to get CpController object. > | > | Still no joy > | > | dbms# kldstat > | Id Refs Address Size Name > | 1 17 0xc0400000 943140 kernel > | 2 1 0xc0d44000 6a2c4 acpi.ko > | 3 1 0xc5534000 7000 linprocfs.ko > | 4 3 0xc553b000 22000 linux.ko > | 5 1 0xc5585000 3000 linsysfs.ko > | 6 1 0xc7a34000 3000 daemon_saver.ko > | 7 1 0xc7c2d000 2000 mfi_linux.ko > | > | Says I got the proper KLDs loaded. > | > | dbms# mount > | /dev/mfid0s1a on / (ufs, local, soft-updates) > | devfs on /dev (devfs, local) > | /dev/mfid0s1e on /dbms (ufs, local, soft-updates) > | /dev/mfid0s1d on /usr (ufs, local, soft-updates) > | linprocfs on /usr/compat/linux/proc (linprocfs, local) > | linsysfs on /usr/compat/linux/sys (linsysfs, local) > | > | The two linux "look-sees" are there. > | > | So it looks like all the pre-reqs are there, but it still doesn't work. > | > | Here's the ID on the card and volume: > | > | mfi0: 524 (267116948s/0x0020/0) - Adapter ticks 267116948 elapsed 61s: Time established as 06/18/08 15:09:08; (61 seconds since power on) > | mfid0: on mfi0 > | mfid0: 237464MB (486326272 sectors) RAID volume '' is optimal > | > | What am I missing? > > The linux version sysctl is? Also I think you need to make sure > mfi_linux.ko is loaded before linuxsys.ko mounts so you get the emulation > hooks. Verify that via: > head /compat/linux/sys/class/scsi_host/*/proc_name > results in one saying: > megaraid_sas > or it won't think it is there. BINGO! That did it. > The count is good to see if your file system & linux version sysctl > stuff is in the right state. Once it detects it, then the ioctl should > work. 6-stable, 7-stable and -current all have the latest stuff to > support all of the ioctl stuff as Linux does for MegaCli. MegaCli > does various things to try to find the card in Linux that is really > strange IMHO. For FreeBSD it doesn't have to be that complicated. > They unfortunately, have not released a FreeBSD MegaCli which they > could ... It looks like I need to explicitly set those to load in the /boot/loader.conf instead of letting them autoload on demand... -- Karl Denninger karl@denninger.net From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 07:35:50 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2703106567D for ; Fri, 20 Jun 2008 07:35:50 +0000 (UTC) (envelope-from ruben@verweg.com) Received: from erg.verweg.com (erg.verweg.com [217.77.141.129]) by mx1.freebsd.org (Postfix) with ESMTP id 494BD8FC0A for ; Fri, 20 Jun 2008 07:35:50 +0000 (UTC) (envelope-from ruben@verweg.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verweg.com; s=verweg; t=1213947346; bh=TJ809CBP2EBwIHSGrPCm9VXDj3RhVH1hjUOOWIcjYgc=; h=Cc:Message-Id:From:To:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mime-Version:Subject:Date:References: X-Pgp-Agent:X-Mailer; b=PIgvAOc61T3DJ9xsipD2M10uo5pRLIjlkUnvN5Omf5 l5h8+/SSC2FDpPNiz50SOMGDu6pmlvSgbm323ATtEY1gWXFtPNDx5FdyDkcwJlL8lQK Ub5a5iSdUIpK5hUXWV3mnzLz9lRyBZqCPEz8T2x/JLOiIJ4oP99qTKhH8eqiSA= Received: from [IPv6:::1] (chimp.ripe.net [193.0.1.199]) (authenticated bits=0) by erg.verweg.com (8.14.2/8.14.2) with ESMTP id m5K7ZQcs084863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Jun 2008 07:35:41 GMT (envelope-from ruben@verweg.com) X-Authentication-Warning: erg.verweg.com: Host chimp.ripe.net [193.0.1.199] claimed to be [IPv6:::1] Message-Id: <371FB814-3292-4388-9A0C-34CCF7AEEE39@verweg.com> From: Ruben van Staveren To: Karl Denninger In-Reply-To: <20080620043712.GA7635@FS.denninger.net> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-21--583081435" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Fri, 20 Jun 2008 09:35:19 +0200 References: <20080618153127.GA2662@FS.denninger.net> <200806182042.m5IKgNa4022361@ambrisko.com> <20080620043712.GA7635@FS.denninger.net> X-Pgp-Agent: GPGMail d52 (v52, Leopard) X-Mailer: Apple Mail (2.924) X-Virus-Scanned: ClamAV 0.93/6805/Wed Apr 16 19:57:54 2008 on erg.verweg.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (erg.verweg.com [217.77.141.129]); Fri, 20 Jun 2008 07:35:47 +0000 (UTC) Cc: freebsd-stable@freebsd.org Subject: Re: Management interface for cards powered by the "mfi" driver? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 07:35:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-21--583081435 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 20 Jun 2008, at 6:37, Karl Denninger wrote: >> >> The linux version sysctl is? Also I think you need to make sure >> mfi_linux.ko is loaded before linuxsys.ko mounts so you get the >> emulation >> hooks. Verify that via: >> head /compat/linux/sys/class/scsi_host/*/proc_name >> results in one saying: >> megaraid_sas >> or it won't think it is there. > > BINGO! That did it. > >> The count is good to see if your file system & linux version sysctl >> stuff is in the right state. Once it detects it, then the ioctl >> should >> work. 6-stable, 7-stable and -current all have the latest stuff to >> support all of the ioctl stuff as Linux does for MegaCli. MegaCli >> does various things to try to find the card in Linux that is really >> strange IMHO. For FreeBSD it doesn't have to be that complicated. >> They unfortunately, have not released a FreeBSD MegaCli which they >> could ... > > It looks like I need to explicitly set those to load in the > /boot/loader.conf instead of letting them autoload on demand... I'll make some changes in the port, for stressing out the load order and to let the wrapper work when compat.linux.osrelease is higher than 2.6.12 > -- Karl Denninger > karl@denninger.net Regards, Ruben --Apple-Mail-21--583081435 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFIW123Z88+mcQxRw0RAiTCAJ9gn0QZ51NhQ3TPecJ6Z30Lp485+wCggSZg al5/7o16S90k71IF5GNb06g= =eyGZ -----END PGP SIGNATURE----- --Apple-Mail-21--583081435-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 10:34:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F313D1065670 for ; Fri, 20 Jun 2008 10:34:41 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 800878FC1B for ; Fri, 20 Jun 2008 10:34:41 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.14.1/8.13.1) with ESMTP id m5KAYe0g026542 for ; Fri, 20 Jun 2008 07:34:40 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-stable@freebsd.org Date: Fri, 20 Jun 2008 07:34:35 -0300 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200806200734.35713.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on msrv.matik.com.br X-Virus-Status: Clean Subject: problem with nVidia nForce CK804 SATA300 controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 10:34:42 -0000 Hi anybody else experience a problem with this SATA controller? atapci1: port=20 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xdc00-0xdc0f mem=20 0xfe02d000-0xfe02dfff irq 21 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 7.0-STABLE FreeBSD 7.0-STABLE #0: Wed Jun 18 01:27:50 BRT 2008 my amd64 crashs under heavy disk i/o as each night at 0300 daily cron, also= =20 often after some minutes when compiling world. Also with kde and after some= =20 flash videos (youtube) or large file copying I do not see this problem with other sata controllers or same hardware and = a=20 scsi adapter and this sata disabled what makes me believe it is related to= =20 this specific sata controller this sata controller is part of some ASUS (M2N SLI Deluxe) or Epox AM2 MBs there is no panic at all, some seconds of hard freeze, on desktop machine t= he=20 mouse still moves some seconds and reset, no log either, no crash dump,=20 nothing I have no irq conflict, latest bios onboard, I also exchanged other hw part= s=20 with no success. Any idea? =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 12:34:30 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BAAB106564A for ; Fri, 20 Jun 2008 12:34:30 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 077238FC1A for ; Fri, 20 Jun 2008 12:34:29 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 19A3E3E6CC for ; Fri, 20 Jun 2008 15:34:28 +0300 (EEST) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13863-01 for ; Fri, 20 Jun 2008 15:34:27 +0300 (EEST) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 530D73E6C2 for ; Fri, 20 Jun 2008 15:34:27 +0300 (EEST) Message-ID: <485BA3D2.3090108@bulinfo.net> Date: Fri, 20 Jun 2008 15:34:26 +0300 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: FreeBSD X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 12:34:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello All, There is something strange on my mail server running 6.2-STABLE: # ls -l total 1239702 - -rw------- 1 vscan vscan 4398199488512 Jun 20 15:18 auto-whitelist - -rw------- 1 vscan vscan 22 Jun 20 15:18 bayes.lock - -rw------- 1 vscan vscan 102168 Jun 20 15:18 bayes_journal - -rw------- 1 vscan vscan 1099639861248 Jun 20 15:18 bayes_seen - -rw------- 1 vscan vscan 21057536 Jun 20 15:18 bayes_toks but: # df -h Filesystem Size Used Avail Capacity Mounted on /dev/ar0s1a 19G 3.9G 14G 22% / ... # du 1239758 . # mount /dev/ar0s1a on / (ufs, local) ... When I try to delete some entries from auto-whitelist: Out of memory during request for 52 bytes, total sbrk() is 536223744 bytes! Out of memory during request for 56 bytes, total sbrk() is 536223744 bytes! Any ideas? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFIW6PRxJBWvpalMpkRAprHAKCZ93VqWsH28i0wa4bc+ZmXNYXF4gCdELF8 EC/P28NCFIiws1yf+rci/ck= =O5TZ -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 13:27:03 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88374106566C for ; Fri, 20 Jun 2008 13:27:03 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7E84C8FC14 for ; Fri, 20 Jun 2008 13:27:03 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 5DF251CC079; Fri, 20 Jun 2008 06:27:03 -0700 (PDT) Date: Fri, 20 Jun 2008 06:27:03 -0700 From: Jeremy Chadwick To: Krassimir Slavchev Message-ID: <20080620132703.GA4968@eos.sc1.parodius.com> References: <485BA3D2.3090108@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485BA3D2.3090108@bulinfo.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 13:27:03 -0000 On Fri, Jun 20, 2008 at 03:34:26PM +0300, Krassimir Slavchev wrote: > Hello All, > > There is something strange on my mail server running 6.2-STABLE: Bring down the system and force a fsck of your filesystem(s). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 13:46:37 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1333B1065678 for ; Fri, 20 Jun 2008 13:46:37 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id CF4628FC0C for ; Fri, 20 Jun 2008 13:46:36 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 9434C6D436; Fri, 20 Jun 2008 15:28:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syVnaBecFy6D; Fri, 20 Jun 2008 15:28:33 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 860746D433; Fri, 20 Jun 2008 15:28:33 +0200 (CEST) Date: Fri, 20 Jun 2008 15:28:33 +0200 From: Rink Springer To: Krassimir Slavchev Message-ID: <20080620132833.GB83165@rink.nu> References: <485BA3D2.3090108@bulinfo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485BA3D2.3090108@bulinfo.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 13:46:37 -0000 Hi, On Fri, Jun 20, 2008 at 03:34:26PM +0300, Krassimir Slavchev wrote: > # ls -l > total 1239702 > - -rw------- 1 vscan vscan 4398199488512 Jun 20 15:18 auto-whitelist > - -rw------- 1 vscan vscan 22 Jun 20 15:18 bayes.lock > - -rw------- 1 vscan vscan 102168 Jun 20 15:18 bayes_journal > - -rw------- 1 vscan vscan 1099639861248 Jun 20 15:18 bayes_seen > - -rw------- 1 vscan vscan 21057536 Jun 20 15:18 bayes_toks > > but: > # df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/ar0s1a 19G 3.9G 14G 22% / > ... > > # du > 1239758 . > > # mount > /dev/ar0s1a on / (ufs, local) > ... This is most likely due to the use of 'sparse files': sequential file data that consists of only zeros doesn't need have actual storage associated to it. This is quite normal in UNIX environments, and quite harmless. -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 13:54:32 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0BA1065686 for ; Fri, 20 Jun 2008 13:54:32 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC838FC21 for ; Fri, 20 Jun 2008 13:54:32 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K9h4R-0005uB-Kn for freebsd-stable@freebsd.org; Fri, 20 Jun 2008 13:54:31 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jun 2008 13:54:31 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jun 2008 13:54:31 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Fri, 20 Jun 2008 15:54:22 +0200 Lines: 57 Message-ID: References: <485BA3D2.3090108@bulinfo.net> <20080620132833.GB83165@rink.nu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0F73A2E5159955FD2AA9266" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.14 (X11/20080505) In-Reply-To: <20080620132833.GB83165@rink.nu> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 13:54:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0F73A2E5159955FD2AA9266 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rink Springer wrote: > Hi, >=20 > On Fri, Jun 20, 2008 at 03:34:26PM +0300, Krassimir Slavchev wrote: >> # ls -l >> total 1239702 >> - -rw------- 1 vscan vscan 4398199488512 Jun 20 15:18 auto-whitelis= t >> - -rw------- 1 vscan vscan 22 Jun 20 15:18 bayes.lock >> - -rw------- 1 vscan vscan 102168 Jun 20 15:18 bayes_journal= >> - -rw------- 1 vscan vscan 1099639861248 Jun 20 15:18 bayes_seen >> - -rw------- 1 vscan vscan 21057536 Jun 20 15:18 bayes_toks >> >> but: >> # df -h >> Filesystem Size Used Avail Capacity Mounted on >> /dev/ar0s1a 19G 3.9G 14G 22% / >> ... >> >> # du >> 1239758 . >> >> # mount >> /dev/ar0s1a on / (ufs, local) >> ... >=20 > This is most likely due to the use of 'sparse files': sequential file > data that consists of only zeros doesn't need have actual storage > associated to it. This is quite normal in UNIX environments, and quite > harmless. Except that the file in question should be, judging by the filename, a simple text file. I don't really see how a whitelist could grow to such monstrous sizes :) Most likely it's a file system corruption - fsck should be the first thing to try. --------------enigC0F73A2E5159955FD2AA9266 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIW7aOldnAQVacBcgRAouWAKCLxfKAx9767zfE+lIgFn6rFZ4cawCeLstv Bkqut78WbRLWkrnMbUUq394= =lEs9 -----END PGP SIGNATURE----- --------------enigC0F73A2E5159955FD2AA9266-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 14:06:26 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FC131065672 for ; Fri, 20 Jun 2008 14:06:26 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 34FDA8FC19 for ; Fri, 20 Jun 2008 14:06:26 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 6C8036D436; Fri, 20 Jun 2008 16:06:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEU3Qa4OP3GX; Fri, 20 Jun 2008 16:06:23 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 8A5C56D433; Fri, 20 Jun 2008 16:06:23 +0200 (CEST) Date: Fri, 20 Jun 2008 16:06:23 +0200 From: Rink Springer To: Ivan Voras Message-ID: <20080620140623.GC83165@rink.nu> References: <485BA3D2.3090108@bulinfo.net> <20080620132833.GB83165@rink.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 14:06:26 -0000 On Fri, Jun 20, 2008 at 03:54:22PM +0200, Ivan Voras wrote: > Except that the file in question should be, judging by the filename, a > simple text file. I don't really see how a whitelist could grow to such > monstrous sizes :) Most likely it's a file system corruption - fsck > should be the first thing to try. The 'vscan' user leads me assume this is SpamAssassin - I've seen this behaviour at work, where our scripts were trying to backup a 1TB file (which actually was ~vscan/.spamassassin/auto-whitelist). The result was that the backup script died due to lack of disk space on the backup server (as we don't use compression). When I was investigating why the file could be so large it, it turned out the file was only a few hunderd 'real' MB's, so that is why I assume this person is having the same issue as we do. The file is a Berkeley DB file, by the way, so there's nothing textfile about it ;-) But still, when in doubt, fsck(8) is sure to aid you. -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 14:25:23 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4107A1065679 for ; Fri, 20 Jun 2008 14:25:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id C3AF58FC1E for ; Fri, 20 Jun 2008 14:25:22 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1K9hYA-0007HQ-QX for freebsd-stable@freebsd.org; Fri, 20 Jun 2008 14:25:16 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jun 2008 14:25:14 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Jun 2008 14:25:14 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Fri, 20 Jun 2008 16:25:05 +0200 Lines: 46 Message-ID: References: <485BA3D2.3090108@bulinfo.net> <20080620132833.GB83165@rink.nu> <20080620140623.GC83165@rink.nu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0F546CC3CB7B26CE25A2C825" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.14 (X11/20080505) In-Reply-To: <20080620140623.GC83165@rink.nu> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 14:25:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0F546CC3CB7B26CE25A2C825 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rink Springer wrote: > On Fri, Jun 20, 2008 at 03:54:22PM +0200, Ivan Voras wrote: >> Except that the file in question should be, judging by the filename, a= >> simple text file. I don't really see how a whitelist could grow to suc= h >> monstrous sizes :) Most likely it's a file system corruption - fsck >> should be the first thing to try. >=20 > The 'vscan' user leads me assume this is SpamAssassin - I've seen this > behaviour at work, where our scripts were trying to backup a 1TB file > (which actually was ~vscan/.spamassassin/auto-whitelist). The result wa= s > that the backup script died due to lack of disk space on the backup > server (as we don't use compression). >=20 > When I was investigating why the file could be so large it, it turned > out the file was only a few hunderd 'real' MB's, so that is why I assum= e > this person is having the same issue as we do. The file is a Berkeley D= B > file, by the way, so there's nothing textfile about it ;-) I learn something every day :) Didn't know BDB was smart enough to create sparse files. --------------enig0F546CC3CB7B26CE25A2C825 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIW73BldnAQVacBcgRAueCAKDvHyIIKXlCeubk7H4DdyhA76j9SACeLGUc BdGXkCi8uujS2fHqsRUtajg= =y1PG -----END PGP SIGNATURE----- --------------enig0F546CC3CB7B26CE25A2C825-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 16:48:21 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D405E1065679 for ; Fri, 20 Jun 2008 16:48:21 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from smtp02.cdmon.com (smtp02.cdmon.com [212.36.74.229]) by mx1.freebsd.org (Postfix) with ESMTP id A88AC8FC14 for ; Fri, 20 Jun 2008 16:48:21 +0000 (UTC) (envelope-from jespasac@minibofh.org) Received: from [192.168.2.102] (unknown [84.77.66.237]) by smtp02.cdmon.com (Postfix) with ESMTP id D98B545274 for ; Fri, 20 Jun 2008 18:48:19 +0200 (CEST) Message-ID: <485BDF53.70707@minibofh.org> Date: Fri, 20 Jun 2008 18:48:19 +0200 From: Jordi Espasa Clofent User-Agent: Thunderbird 2.0.0.14 (X11/20080502) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Random reboots (amd64) SOLVED X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 16:48:21 -0000 Some time ago I was crazy with this problem: http://marc.info/?l=freebsd-amd64&m=119783171822355&w=2 Finally, it has been solved with upgrade from 6.2/6.3 to 7.0. I've no idea why, but nowadays the reboots doesn't exist. -- Thanks, Jordi Espasa Clofent From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 20:22:05 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 391FD106567B for ; Fri, 20 Jun 2008 20:22:05 +0000 (UTC) (envelope-from nakal@web.de) Received: from fmmailgate03.web.de (fmmailgate03.web.de [217.72.192.234]) by mx1.freebsd.org (Postfix) with ESMTP id 0BFD18FC0A for ; Fri, 20 Jun 2008 20:22:04 +0000 (UTC) (envelope-from nakal@web.de) Received: from smtp05.web.de (fmsmtp05.dlan.cinetic.de [172.20.4.166]) by fmmailgate03.web.de (Postfix) with ESMTP id 5BE64E0A1C86 for ; Fri, 20 Jun 2008 22:21:50 +0200 (CEST) Received: from [217.236.53.174] (helo=zelda.local) by smtp05.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.109 #226) id 1K9n7G-00049U-00 for freebsd-stable@freebsd.org; Fri, 20 Jun 2008 22:21:50 +0200 Date: Fri, 20 Jun 2008 22:21:48 +0200 From: Martin To: freebsd-stable@freebsd.org Message-ID: <20080620222148.3625a8cf@zelda.local> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.10; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: nakal@web.de X-Sender: nakal@web.de X-Provags-ID: V01U2FsdGVkX1+WqFnehfMt6NndIK24tUfcGiKtPQu6Udxzv4/x 0ahI3uKciX0rwKAdGnY3LXqF0cWjzUE//RY3rRaqENEIJ6AZkz +sEfC72rI= Subject: Panic in vfs(?) near login initialization X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 20:22:05 -0000 Hi, I've submitted a PR about this panic here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124464 I'm sorry, if I remind you of this problem. I would not do this usually. This is very annoying to see this panic again and again and I am somehow surprised that noone has seen it yet. I've seen this panic 5 times now. It happens during boot, approximately when the gettys are being started. Since no one even asks me about it, I wonder if it is generally better to paste my PRs to this mailing list (I have more problems and even panics that occur on my PCs, but this one is really nasty.) I cannot tell for sure, but I think this is also the panic that occurred on one of my i386 machines right after FreeBSD 7.0 RELEASE installation with GENERIC kernel. I've lost the trace output and cannot remember for sure, but it was exactly under the same circumstances as the panic described here. Tell me, if I can do something except waiting to help fix it quickly. -- Thank you, Martin From owner-freebsd-stable@FreeBSD.ORG Fri Jun 20 20:48:45 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1BF081065673 for ; Fri, 20 Jun 2008 20:48:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4797C8FC13 for ; Fri, 20 Jun 2008 20:48:44 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m5KKmgDs073727; Fri, 20 Jun 2008 22:48:42 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m5KKmgo6073726; Fri, 20 Jun 2008 22:48:42 +0200 (CEST) (envelope-from olli) Date: Fri, 20 Jun 2008 22:48:42 +0200 (CEST) Message-Id: <200806202048.m5KKmgo6073726@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-stable User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 20 Jun 2008 22:48:42 +0200 (CEST) Cc: Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2008 20:48:45 -0000 Ivan Voras wrote: > Rink Springer wrote: > > The 'vscan' user leads me assume this is SpamAssassin - I've seen this > > behaviour at work, where our scripts were trying to backup a 1TB file > > (which actually was ~vscan/.spamassassin/auto-whitelist). The result was > > that the backup script died due to lack of disk space on the backup > > server (as we don't use compression). > > > > When I was investigating why the file could be so large it, it turned > > out the file was only a few hunderd 'real' MB's, so that is why I assume > > this person is having the same issue as we do. The file is a Berkeley DB > > file, by the way, so there's nothing textfile about it ;-) > > I learn something every day :) > Didn't know BDB was smart enough to create sparse files. BTW, you can use "ls -ls" to display the number of physical blocks allocated to the file, so you can easily see whether a file is sparse or not: $ dd if=/dev/zero of=foo1 bs=1m count=1 $ truncate -s 1m foo2 $ ls -ls foo1 foo2 1040 -rw------- 1 olli olli 1048576 Jun 20 22:43 foo1 32 -rw------- 1 olli olli 1048576 Jun 20 22:43 foo2 As you can see, the file size is the same, but the block counts are different (I have BLOCKSIZE=K in my environment, so the blocks are displayed in 1KB units). I've written a small script that can be used to detect sparse files (it even displays the "sparseness" percentage): http://www.secnetix.de/olli/scripts/sparsecheck Best regards Oliver PS: Of course it is still possible that a file system is corrupt and needs fsck, no matter whether those files are sparse or not. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From owner-freebsd-stable@FreeBSD.ORG Sat Jun 21 04:55:27 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B5CE1065684 for ; Sat, 21 Jun 2008 04:55:27 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id C7CF08FC38 for ; Sat, 21 Jun 2008 04:55:26 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m5L4tNpi076165; Sat, 21 Jun 2008 12:55:23 +0800 (KRAST) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m5L4tNrR076163; Sat, 21 Jun 2008 12:55:23 +0800 (KRAST) (envelope-from eugen) Date: Sat, 21 Jun 2008 12:55:23 +0800 From: Eugene Grosbein To: Ivan Voras Message-ID: <20080621045523.GA71068@svzserv.kemerovo.su> References: <485BA3D2.3090108@bulinfo.net> <20080620132833.GB83165@rink.nu> <20080620140623.GC83165@rink.nu> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: Incorrect file size? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2008 04:55:27 -0000 On Fri, Jun 20, 2008 at 04:25:05PM +0200, Ivan Voras wrote: > > When I was investigating why the file could be so large it, it turned > > out the file was only a few hunderd 'real' MB's, so that is why I assume > > this person is having the same issue as we do. The file is a Berkeley DB > > file, by the way, so there's nothing textfile about it ;-) > I learn something every day :) > Didn't know BDB was smart enough to create sparse files. Even base system uses such files :-) $ ls -lsk /etc/pwd.db 140 -rw-r--r-- 1 root wheel 159744 21 ÉÀÎ 12:26 /etc/pwd.db $ file /etc/pwd.db /etc/pwd.db: Berkeley DB 1.85 (Hash, version 2, native byte-order) File occupies 140K = 143360 bytes and its length is 159744 bytes, so it has to be sparse. FreeBSD 4.11-STABLE. Eugene