From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 01:47:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 597FE1065673; Sun, 9 Aug 2009 01:47:51 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 448708FC16; Sun, 9 Aug 2009 01:47:51 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n791lmCI026341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Aug 2009 18:47:50 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 284AB1CC31; Sat, 8 Aug 2009 18:47:48 -0700 (PDT) To: Doug Barton In-reply-to: Your message of "Wed, 05 Aug 2009 20:45:11 PDT." <4A7A51C7.3060702@FreeBSD.org> Date: Sat, 08 Aug 2009 18:47:48 -0700 From: "Kevin Oberman" Message-Id: <20090809014748.284AB1CC31@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-08-08_02:2009-07-24, 2009-08-08, 2009-08-08 signatures=0 Cc: current@freebsd.org Subject: Re: Unable to build HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 01:47:51 -0000 > Date: Wed, 05 Aug 2009 20:45:11 -0700 > From: Doug Barton > > Kevin Oberman wrote: > > > OK. I cleaned out /usr/obj and saved /usr/src/sys/i386/conf. > > I'm going to assume that you mean just your conf file there. > > > > While I > > will have to re-do my kernel config, I prefer to save my old one, > > That's fine, just compare it to GENERIC to make sure that all of your > entries are valid, and that you're not missing anything important. > > > But, as suggested by bf, I think that the WITHOUT_OPENSSH knob is > > broken which is a problem > > Agreed. If you want to help debug this problem you could try building > with clean /usr/obj, up to date /usr/src, and ONLY the ssh knob in > src.conf. Then debug from there. > > This (IMWO) is something that should be fixed before release. > > > Guess I should have tried V8 a couple of months ago. > > In the immortal words of Jiminy Cricket, let your conscience be your > guide. :) Doug, Two patches have been submitted to fix this problem, one by bf (conf/137483) and one by me (conf/137486). I have confidence that the bf patch is correct and appropriate and that buildworld is broken with various src.conf options. I am convinced my patch is correct, but I suspect that some might argue that it is not appropriate. It allows pam_ssh to be built even though WITHOUT_OPENSSH is specified. I will be happy to defend my patch, if challenged, but the short time until 8.0 makes it questionable as to whether a consensus can be reached in time. Whether you like my patch, I'd love to see the patch by bf (conf/137483) committed before 8.0 and I believe that you agree. If so, could you request the RE to approve it to be committed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 02:48:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC6CE106564A for ; Sun, 9 Aug 2009 02:48:43 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9438FC08 for ; Sun, 9 Aug 2009 02:48:43 +0000 (UTC) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n792mcIx061168; Sat, 8 Aug 2009 19:48:38 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id aic9dcyxmxfue9nba5ibkqwpzi; Sat, 08 Aug 2009 19:48:38 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A7E3906.60007@freebsd.org> Date: Sat, 08 Aug 2009 19:48:38 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Dimitry Andric References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> In-Reply-To: <4A7DE8A9.7070703@andric.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 02:48:43 -0000 > On 2009-08-08 23:02, Kostik Belousov wrote: >> Working with the history with reasonable speed. Additional bonus >> is ability to be able to work offline. "svnsync" is a standard SVN tool (installed as part of svn) that makes it pretty easy to set up a read-only copy of an SVN repository. It's a little confusing to get set up initially, but once you do, you can just run it from cron every hour or so to keep in sync. Main documentation for svnsync starts here: http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html Even without a replica, I've found offline work with SVN pretty reasonable. No history, but the common "svn status", "svn diff", and "svn revert" commands are fully functional when offline. Dimitry Andric wrote: > Lowering the load on the main FreeBSD svn server is also nice. :) This is much less of an issue with SVN than CVS. Tim From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 05:27:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17865106566B for ; Sun, 9 Aug 2009 05:27:11 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id C09708FC21 for ; Sun, 9 Aug 2009 05:27:10 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n795R7Nu050611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Aug 2009 22:27:07 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A7E5E2B.6060204@errno.com> Date: Sat, 08 Aug 2009 22:27:07 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Robert References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> In-Reply-To: <20090808134101.44d7d210@vaio> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: LOR wlan0 wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 05:27:11 -0000 Robert wrote: > On Sat, 08 Aug 2009 08:59:27 -0700 > Sam Leffler wrote: > >> Robert wrote: >>> Greetings >>> >>> I have just upgraded a laptop on my network to current: >>> >>> [root@hp] ~# uname -a >>> FreeBSD hp.shasta204.local 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Fri Aug >>> 7 11:15:24 PDT 2009 root@vaio.shasta204.local:/usr/ob >>> j/usr/src/sys/VESA i386 >>> >>> I have made the changes in rc.conf after reading UPDATING and >>> rc.conf defaults. Here is the bits from rc.conf >>> >>> wlans_wi0=wlan0 # I have tried with quotes around wlan0 with >>> # no difference. >>> ifconfig_wlan0="DHCP ssid MY_SSID channel any wepmode on \ >>> deftxkey 1 wepkey 0xSecretNumber78bf" >>> >>> # ifconfig_re0="DHCP" >>> >>> My wlan0 interface comes up but never retrieves an IP from the >>> router. >>> >>> [root@hp] ~# ifconfig -a >>> plip0: flags=8810 metric 0 mtu 1500 >>> lo0: flags=8049 metric 0 mtu 16384 >>> options=3 >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 >>> inet6 ::1 prefixlen 128 >>> ether 00:09:5b:25:5e:b3 >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11b >>> status: associated >>> wlan0: flags=8843 metric 0 >>> mtu 1500 ether 00:09:5b:25:5e:b3 >>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 >>> media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b >>> status: associated >>> ssid MY_SSID channel 11 (2462 Mhz 11b) bssid >>> 00:1c:df:f9:ad:fc country US authmode OPEN privacy ON deftxkey 1 >>> wepkey 1:104-bit txpower 0 bmiss 7 scanvalid 60 >>> >>> Searching dmesg I see this >>> >>> wlan0: Ethernet address: 00:09:5b:25:5e:b3 >>> lock order reversal: >>> 1st 0xc2c04014 wi0_com_lock (wi0_com_lock) >>> @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xc2bf2008 wi0 >>> (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack >>> backtrace: >>> db_trace_self_wrapper(c0c7746e,cca4ea78,c08c1435,c08b217b,c0c7a303,...) >>> at db_trace_self_wrapper+0x26 >>> kdb_backtrace(c08b217b,c0c7a303,c292f228,c2929040,cca4ead4,...) at >>> kdb_backtrace+0x29 >>> _witness_debugger(c0c7a303,c2bf2008,c2af88d0,c2929040,c0c6775c,...) >>> at _witness_debugger+0x25 >>> witness_checkorder(c2bf2008,9,c0c6775c,43b,0,...) at >>> witness_checkorder+0x839 >>> _mtx_lock_flags(c2bf2008,0,c0c6775c,43b,c2bf2008,...) at >>> _mtx_lock_flags+0xc4 >>> wi_raw_xmit(c2cc5000,c2cd0000,cca4ebba,10,c2c9c2a4,...) at >>> wi_raw_xmit+0x3e >>> ieee80211_send_probereq(c2cc5000,c2c9c2a4,c0bfd600,c0bfd600,c2ac2018,...) >>> at ieee80211_send_probereq+0x488 >>> ieee80211_probe_curchan(c2c9c000,0,c0c8aa85,326,cca4ec30,...) at >>> ieee80211_probe_curchan+0x93 >>> scan_curchan(c2ac2000,190,c0c8aa85,396,246,...) at scan_curchan+0x49 >>> scan_task(c2ac2000,1,c0c78c6a,54,c2af4d1c,...) at scan_task+0x33a >>> taskqueue_run(c2af4d00,c2af4d1c,0,c0c6a13b,0,...) at >>> taskqueue_run+0x10b >>> taskqueue_thread_loop(c2c04074,cca4ed38,c0c6f7cc,33e,c0dc60a0,...) >>> at taskqueue_thread_loop+0x68 fork_exit(c08ba5b0,c2c04074,cca4ed38) >>> at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap >>> 0, eip = 0, esp = 0xcca4ed70, ebp = 0 --- Starting Network: lo0. >>> >>> The PCMCIA is and older Netgear 802.11b that was working fine on 7 >>> stable. I have searched the archives and tried changing things in >>> rc.conf but I can not seem to make this work. >>> >>> >>> Any help or direction will be greatly appreciated. >> Ignore the LOR. The first thing to do is simplify your config; >> remove crypto. If you can pass data frames then your problem is in >> the crypto setup. If not then you have unencrypted data to examine >> for problems. >> >> Use tools/tools/net80211/wlanstats to check for errors. You can >> trace packet traffic with tcpdump to see if frames are moving. >> >> You also don't identify your card. wi in 8.0 works with a subset of >> the cards in RELENG_7 so your card may not work correctly--though >> since you appear to have associated that doesn't seem like the issue >> (cards that don't work are unlikely to successfully associate). >> >> Sam > > Sam > > Thanks for responding and for all of the fine work you are doing. > > I thought that I had tried without the crypto before but I either > didn't or messed up. Anyway, The interface links up fine without WEP > activated. > > I am able to get on the network and NFS loads all file systems from > other boxes. > > Re-enabling WEP on the router (Belkin) and in rc.conf, causes the same > failure as show above: associated without an IP. > > The interface card is old. It shows to be a Netgear MA401. I have > ordered a newer model of the Netgear card. It is a WG511T which is > supposed to have an atheros chipset. I should receive this card in about > a week. I really do not know if any of this is relevant to my problem. > > On this laptop, because it is old and slow, I NFS mount /usr/src from a > faster machine. So, wlanstats is not available when I do not have an IP. > > Running tcpdump -vv shows a whole lot of stuff. It starts with wlan0: > no IPv4 assigned, so I do not know if the rest is important. There are > many lines which contain "Unknown SSAP" and "Unknown DSAP". I have > copied some of it to a file which I can forward if it of any help. I can confirm WEP is broken on wi in sta mode (and probably ap mode). I found at least two bugs but couldn't get it to work so am going to leave it as an errata for 8.0. But what's truly odd is that WPA works fine despite a bug that should've caused it to not work. I knew WPA worked which is probably why I ignored WEP (noone in their right mind uses WEP when WPA is available :-)). Sam From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 05:27:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEFE21065680 for ; Sun, 9 Aug 2009 05:27:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 884B58FC16 for ; Sun, 9 Aug 2009 05:27:27 +0000 (UTC) Received: from [192.168.254.214] ([192.168.254.214]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n795RNRC029446; Sat, 8 Aug 2009 23:27:23 -0600 (MDT) (envelope-from scottl@samsco.org) Message-Id: <53E87472-D6F5-4EE3-B905-8A3EF8AC7D83@samsco.org> From: Scott Long To: =?WINDOWS-1252?Q?Simon_=8Eekar?= In-Reply-To: <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 8 Aug 2009 23:27:23 -0600 References: <4A66C7BB.6030307@samsco.org> <2F7346C1-E041-4D31-8FB4-24321DDAA608@siel.si> X-Mailer: Apple Mail (2.935.3) X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: List Subject: Re: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 05:27:28 -0000 I'm working on a fix, and hopefully I'll have something before the =20 next 8.0 beta/rc build. Scott On Aug 7, 2009, at 2:48 AM, Simon =8Eekar wrote: > Hello, > > what's really issue with this ? Is there any workaround ? > > interesting is that a FreeBSD 7.2 i386 boots fine when preinstalled =20= > on a server with a different controller. > > Thanks, > S. > > On Jul 22, 2009, at 10:03 AM, Scott Long wrote: > >> This is probably a CISS P410 controller, right? It'll say exactly =20= >> what it is further up in the boot messages. I know of the problem =20= >> here, and >> I'm working on a fix. However, it might be a few more days before I >> have anything that can be tested. >> >> Scott >> >> >> Simon =8Eekar wrote: >>> Hello, >>> I'm running into difficulties booting FreeBSD 8.0 BETA2 amd64 CD =20 >>> image on a HP DL380 G6. >>> it freezes right after USB hubs & CD initialization with the =20 >>> messsage: >>> umass0: on usbus5 >>> umass0: 8070i (ATAPI) over Bulk-Only; quirks =3D 0x0000 >>> umass0:2:0:-1: Attached to scbus2 >>> run_interrupt_driven_hooks: still waiting after 60 seconds for =20 >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 120 seconds for =20 >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 180 seconds for =20 >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 240 seconds for =20 >>> xpt_config >>> run_interrupt_driven_hooks: still waiting after 300 seconds for =20 >>> xpt_config >>> panic: run_interrupt_driven_config_hooks: waited too long >>> cpuid =3D 0 >>> KDB: enter : panic >>> [thread pid 0 tid 100000] >>> Stopped at kdb_enter+0x3d: movq $0,0x687f60(%rip) >>> db> >>> keyboard freezes here, so no way I can do backtrace. >>> The same error is with 7.2-RELEASE bootable CD, but there it just =20= >>> freezes, no messages about waiting for xpt_config. >>> What's there to be done ? >>> I can provide remote access to iLO of this server if this would =20 >>> somehow help fix things. >>> Thank you, >>> Simon. From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 07:00:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90E34106564A; Sun, 9 Aug 2009 07:00:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 0FB648FC08; Sun, 9 Aug 2009 07:00:54 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Ma2Oi-0000Ah-7g; Sun, 09 Aug 2009 10:00:52 +0300 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Alexander Motin In-reply-to: <4A7D8F72.8090905@FreeBSD.org> References: <1249741381.00149226.1249729205@10.7.7.3> <4A7D8D7A.5030303@mavhome.dp.ua> <4A7D8F72.8090905@FreeBSD.org> Comments: In-reply-to Alexander Motin message dated "Sat, 08 Aug 2009 17:45:06 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Aug 2009 10:00:52 +0300 From: Danny Braniss Message-ID: Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: request test drivers for iscsi_initiator 2.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 07:00:55 -0000 > Alexander Motin wrote: > > Danny Braniss wrote: > >> wups, forgot a small little detail: > >> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.3.tar.gz > > > > Is there reason why > > cpi->transport = XPORT_ISCSI; > > covered by > > #if defined(KNOB_VALID_ADDRESS) > > ? > I needed something to differentiate between the new CAM changes and the old (in <= 7.2), so if you have a better knob ... > Sorry, wrong question. But those who will test on CURRENT should take > care about it. why? it compiles - and works - ok under 8.0, at least till the last svn update :-) cheers, danny From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 09:22:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8083A106564A; Sun, 9 Aug 2009 09:22:57 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD3B8FC16; Sun, 9 Aug 2009 09:22:56 +0000 (UTC) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id A6CE461AF; Sun, 9 Aug 2009 11:22:55 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n799Mo7T075517; Sun, 9 Aug 2009 11:22:51 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1249809775; bh=M296cEneZV1/IPwd9uGOh9ahdElbT22cqJEORJiEsZM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fHe/GgeynS8gJEbofiE5joxM/vzC8zZ51OqOmCab1OM+UG+fcQb9ffH2eTr7qDW+z dmI+lt1jVhWiPPTH7KhRg== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=1QoKhYQRTvyEDgUruRSzJNsrE6UbvhSUDXY1GknDmgZbDtDM0jvoPzAt5lzVfj0YQ rVaAAT/rxJ2AbVgmMq5Kg== Message-ID: <4A7E956A.4070903@restart.be> Date: Sun, 09 Aug 2009 11:22:50 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090725) MIME-Version: 1.0 To: Robert Watson References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808175831.GA84046@in-addr.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: FreeBSD current Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 09:22:57 -0000 Robert Watson wrote: > On Sat, 8 Aug 2009, Gary Palmer wrote: > >> On Sat, Aug 08, 2009 at 07:27:23PM +0200, Thomas Backman wrote: >>> Anyone care to fill us outsiders in? ;) No commits at all in the last >>> few days, and given "Please just bear with it until commits are >>> restored" (from Attilio Rao)... How are things? Any status updates >>> anywhere? I looked through the list of mailing lists, but didn't find >>> a fitting one with a topic covering this. >> >> Not the easiest mention to find: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010255.html >> > > A lot more information on the in-progress release can be found here: > > http://wiki.freebsd.org/8.0TODO > > I updated it significantly today to add information on the current patch > queue, explicit release status, and more detailed schedule. We're > supposed to move over to the normal release web page structure shortly: Thank you for those valuable informations and for your time Henri > > http://www.freebsd.org/releases/8.0R/schedule.html > > However, I've deferred hooking that up to the build until the current > issue is resolved. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 09:53:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10CB61065674; Sun, 9 Aug 2009 09:53:57 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id BEB058FC2E; Sun, 9 Aug 2009 09:53:56 +0000 (UTC) Received: from arthur.nitro.dk (arthur.bofh [192.168.2.3]) by mx.nitro.dk (Postfix) with ESMTP id E11672D4866; Sun, 9 Aug 2009 09:53:55 +0000 (UTC) Received: by arthur.nitro.dk (Postfix, from userid 1000) id BBEED5C07; Sun, 9 Aug 2009 11:53:55 +0200 (CEST) Date: Sun, 9 Aug 2009 11:53:55 +0200 From: "Simon L. Nielsen" To: Tim Kientzle Message-ID: <20090809095354.GA1257@arthur.nitro.dk> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> <4A7E3906.60007@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7E3906.60007@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 09:53:57 -0000 On 2009.08.08 19:48:38 -0700, Tim Kientzle wrote: > Dimitry Andric wrote: > > Lowering the load on the main FreeBSD svn server is also nice. :) > > This is much less of an issue with SVN than CVS. But probably is still going to be an issue at some point, so people setting up syncs from svn.FreeBSD.org now should be expect to move to a mirror site at some point. PS. in case people are wondering - no, we don't currently have an svn mirroring infrastructure. There might be a couple of mirror sites, but I can't really recall. -- Simon L. Nielsen Hat: FreeBSD.org admins From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 10:11:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F10D106564A for ; Sun, 9 Aug 2009 10:11:03 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E650E8FC16 for ; Sun, 9 Aug 2009 10:11:01 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n79AAtvU071397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 12:11:00 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A7EA0A7.1000507@omnilan.de> Date: Sun, 09 Aug 2009 12:10:47 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: FreeBSD Current X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF2629FFC452A9C3179BBA00F" Subject: USB umass device not working on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 10:11:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2629FFC452A9C3179BBA00F Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, one year ago I fed my present for my mother with some music files - a=20 samsung ogg-player. Until now the music collection is still untouched, so I tried to help=20 her and replace some files. Unfortunately it doesn't attach as daX any more. While watching for the lines with hw.usb.umass.debug=3D-1 I found that=20 there's something strange goning on all the time. I guess it's hal. But=20 are these messages to worry (-current from today)? (Samsung lines below) Thanks in advance for any hints. -Harry Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:2:XPT_PATH_IN= Q:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:2:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:2:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4021: cmd =3D= =20 6b (0x004000000000), data =3D 0b, lun =3D 2, dir =3D out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4021: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fb5, res =3D 0, status =3D 0x01 (faile= d) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback:=20 Command failed, residue =3D 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of=20 sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4022: cmd =3D= =20 6b (0x030000002000), data =3D 32b, lun =3D 2, dir =3D in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed = to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4022: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fb6, res =3D 14, status =3D 0x00 (good= ) Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:0:XPT_PATH_IN= Q:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4023: cmd =3D= =20 6b (0x000000000000), data =3D 0b, lun =3D 0, dir =3D out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4023: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fb7, res =3D 0, status =3D 0x01 (faile= d) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback:=20 Command failed, residue =3D 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of=20 sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4024: cmd =3D= =20 6b (0x030000002000), data =3D 32b, lun =3D 0, dir =3D in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed = to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4024: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fb8, res =3D 14, status =3D 0x00 (good= ) Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:3:XPT_PATH_IN= Q:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:3:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:3:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4025: cmd =3D= =20 6b (0x006000000000), data =3D 0b, lun =3D 3, dir =3D out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4025: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fb9, res =3D 0, status =3D 0x01 (faile= d) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback:=20 Command failed, residue =3D 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of=20 sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4026: cmd =3D= =20 6b (0x030000002000), data =3D 32b, lun =3D 3, dir =3D in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed = to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4026: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fba, res =3D 14, status =3D 0x00 (good= ) Aug 9 11:55:54 titan kernel: umass0:umass_cam_action: 10:0:1:XPT_PATH_IN= Q:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:1:XPT_GET_TRAN_SETTINGS:. Aug 9 11:55:54 titan kernel: umass0:umass_cam_action:=20 10:0:1:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4027: cmd =3D= =20 6b (0x002000000000), data =3D 0b, lun =3D 1, dir =3D out Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4027: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fbb, res =3D 0, status =3D 0x01 (faile= d) Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback:=20 Command failed, residue =3D 0 Aug 9 11:55:54 titan kernel: umass0:umass_cam_cb: Fetching 32 bytes of=20 sense data Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_cbw: CBW 4028: cmd =3D= =20 6b (0x030000002000), data =3D 32b, lun =3D 1, dir =3D in Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 4 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D32 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_t_bbb_status_callback: Failed = to read CSW: USB_ERR_STALLED, try 0 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 5 Aug 9 11:55:54 titan kernel: umass0:umass_transfer_start: transfer=20 index =3D 8 Aug 9 11:55:54 titan kernel: umass0:umass_bbb_dump_csw: CSW 4028: sig =3D= =20 0x53425355 (valid), tag =3D 0x00000fbc, res =3D 14, status =3D 0x00 (good= ) #################### Here's the samsung lines: Aug 9 12:03:55 titan root: Unknown USB device: vendor 0x04e8 product=20 0x5050 bus uhub3 Aug 9 12:03:55 titan kernel: ugen3.3: at usbus3 Aug 9 12:03:55 titan kernel: umass1: on usbus3 Aug 9 12:03:55 titan kernel: umass1: SCSI over Bulk-Only; quirks =3D 0x= 0110 Aug 9 12:04:00 titan kernel: umass1:umass_init_shuttle: Shuttle init=20 returned 0x0000 Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:-1:-1:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:11:1:-1: Attached to scbus11 Aug 9 12:04:01 titan kernel: umass1:umass_cam_rescan: scbus11: scanning = for 11:1:-1 Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:-1:-1:XPT_PATH_INQ:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense Aug 9 12:04:01 titan kernel: umass1:umass_attach: Attach=20 finishedumass1:umass_bbb_dump_cbw: CBW 1: cmd =3D 6b (0x120000002400),=20 data =3D 36b, lun =3D 0, dir =3D in Aug 9 12:04:01 titan kernel: Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 4 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D36 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 8 Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_csw: CSW 1: sig =3D=20 0x53425355 (valid), tag =3D 0x00000001, res =3D 0, status =3D 0x00 (good)= Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/56b data/18b sense Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_cbw: CBW 2: cmd =3D 6= b=20 (0x120000003800), data =3D 56b, lun =3D 0, dir =3D in Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 4 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D56 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 8 Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_csw: CSW 2: sig =3D=20 0x53425355 (valid), tag =3D 0x00000002, res =3D 0, status =3D 0x00 (good)= Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 12:04:01 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:01 titan kernel: umass1:umass_bbb_dump_cbw: CBW 3: cmd =3D 6= b=20 (0x12010000ff00), data =3D 255b, lun =3D 0, dir =3D in Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 4 Aug 9 12:04:01 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D255 Aug 9 12:04:01 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 5 Aug 9 12:04:06 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:04:06 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:06 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:04:11 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:04:11 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:11 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:04:16 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:04:16 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:16 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:04:22 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:04:22 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 12:04:22 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:04:27 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:04:27 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 12:04:27 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense Aug 9 12:04:27 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:04:32 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:04:33 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x00, flags: 0xc0, 6b cmd/0b data/32b sense =2E..... Aug 9 12:05:53 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:05:53 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:05:53 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:05:59 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:05:59 titan kernel: (da4:umass-sim1:1:0:0): got CAM status 0x4 Aug 9 12:05:59 titan kernel: (da4:umass-sim1:1:0:0): fatal error,=20 failed to attach to device Aug 9 12:05:59 titan kernel: (da4:umass-sim1:1:0:0): lost device Aug 9 12:05:59 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:05:59 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:06:04 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:06:04 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:04 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:06:09 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:06:09 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:09 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:06:15 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:06:15 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:15 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:06:20 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:06:20 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x25, flags: 0x40, 10b cmd/8b data/32b sense Aug 9 12:06:20 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 12:06:26 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 12:06:26 titan kernel: (da4:umass-sim1:1:0:0): removing device ent= ry --------------enigF2629FFC452A9C3179BBA00F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkp+oK8ACgkQLDqVQ9VXb8izNACeOFMoJn5sE5X0qxCpLdN/SM9d UVYAnRk9VjZ1W3dtyUqJisjg+WWbTq+5 =8MGi -----END PGP SIGNATURE----- --------------enigF2629FFC452A9C3179BBA00F-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 10:21:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67CCB1065673; Sun, 9 Aug 2009 10:21:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id EFC998FC1D; Sun, 9 Aug 2009 10:21:26 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n79ALJEB069130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 13:21:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n79ALJn8072881; Sun, 9 Aug 2009 13:21:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n79ALJIC072880; Sun, 9 Aug 2009 13:21:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Aug 2009 13:21:19 +0300 From: Kostik Belousov To: Tim Kientzle Message-ID: <20090809102119.GC1884@deviant.kiev.zoral.com.ua> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> <4A7E3906.60007@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f3fibfc/PR0XgZAi" Content-Disposition: inline In-Reply-To: <4A7E3906.60007@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Dimitry Andric , freebsd-current@freebsd.org Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 10:21:27 -0000 --f3fibfc/PR0XgZAi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 08, 2009 at 07:48:38PM -0700, Tim Kientzle wrote: > >On 2009-08-08 23:02, Kostik Belousov wrote: > >>Working with the history with reasonable speed. Additional bonus > >>is ability to be able to work offline. >=20 > "svnsync" is a standard SVN tool (installed as part > of svn) that makes it pretty easy to set up a read-only > copy of an SVN repository. It's a little confusing > to get set up initially, but once you do, you can > just run it from cron every hour or so to keep in > sync. >=20 > Main documentation for svnsync starts here: > http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html The issue with svnsync is that modifications of the non-versioned properties, that is the normal svn operation, but disabled on our repo, are not propagated by svnsync. Also, direct manipulations on the repo, like the surgery that was done with cvs2svn:cvs-rev properties, also not propagated by svnsync. I believe this is major reason why the svnsync mirrors are not given a bless. I do use svnsync, and my local mirror is used both to feed the the git-svn and local checkouts. >=20 > Even without a replica, I've found offline work with > SVN pretty reasonable. No history, but the common > "svn status", "svn diff", and "svn revert" commands > are fully functional when offline. >=20 > Dimitry Andric wrote: > >Lowering the load on the main FreeBSD svn server is also nice. :) >=20 > This is much less of an issue with SVN than CVS. >=20 > Tim --f3fibfc/PR0XgZAi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkp+ox4ACgkQC3+MBN1Mb4i8EQCfd2K6wktsxtwKp8WlzqcbwYwB PqUAoIf5p0MPNLPJgwZrKaYHl/1A1N8U =WylE -----END PGP SIGNATURE----- --f3fibfc/PR0XgZAi-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 13:20:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956B21065677 for ; Sun, 9 Aug 2009 13:20:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.swip.net [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 2E88A8FC1E for ; Sun, 9 Aug 2009 13:20:44 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=jI2FVZWhO3cA:10 a=hlIU1J3LQChSjWV/CGRL5g==:17 a=IcPBs-gtW960K8FGitYA:9 a=BEtKyYMxcIjzGvDdfV4A:7 a=Pn4c5pwF0dnAJqZpaRv8XAWlLawA:4 Received: from [193.217.167.6] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 547970070; Sun, 09 Aug 2009 15:20:43 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 9 Aug 2009 15:20:45 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <4A7EA0A7.1000507@omnilan.de> In-Reply-To: <4A7EA0A7.1000507@omnilan.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908091520.46786.hselasky@c2i.net> Cc: Harald Schmalzbauer Subject: Re: USB umass device not working on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 13:20:45 -0000 On Sunday 09 August 2009 12:10:47 Harald Schmalzbauer wrote: > Hello, > > one year ago I fed my present for my mother with some music files - a > samsung ogg-player. > Until now the music collection is still untouched, so I tried to help > her and replace some files. > Unfortunately it doesn't attach as daX any more. > While watching for the lines with hw.usb.umass.debug=-1 I found that > there's something strange goning on all the time. I guess it's hal. But > are these messages to worry (-current from today)? (Samsung lines below) > > Thanks in advance for any hints. > > -Harry > Hi, Can you try attaching at FULL speed? sysctl hw.usb.ehci.no_hs=1 Replug your device. Another idea is that your device does not support certain SCSI commands, and will crash upon any non-support command. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 13:29:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C9A31065673 for ; Sun, 9 Aug 2009 13:29:25 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 55F148FC20 for ; Sun, 9 Aug 2009 13:29:24 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Ma8Sg-0001Es-FM for freebsd-current@freebsd.org; Sun, 09 Aug 2009 13:29:22 +0000 Received: from pd95d5cac.dip.t-dialin.net ([217.93.92.172]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 09 Aug 2009 13:29:22 +0000 Received: from js by pd95d5cac.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 09 Aug 2009 13:29:22 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Julian Stecklina Date: Sun, 09 Aug 2009 15:29:08 +0200 Lines: 25 Message-ID: <87ws5dru8r.fsf@tabernacle.localhost> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd95d5cac.dip.t-dialin.net User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:64yzdfRAI8F66leTuBlI6rmedqI= Sender: news Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 13:29:25 -0000 Kostik Belousov writes: > On Sat, Aug 08, 2009 at 01:50:55PM -0700, Doug Barton wrote: >> Mel Flynn wrote: >> >> > It's on my TODO, as soon as I'm going to convert my local cvs to svn, which is >> > as soon as someone rewrites "how to set up a local cvs repository the freebsd >> > way" to the svn equivalent ;). >> >> Actually svn basically eliminates the need for a local copy of the >> repository. What are you doing with your local repository now that you >> would like to continue doing with svn? > > Working with the history with reasonable speed. Additional bonus > is ability to be able to work offline. Perhaps someone can setup a git mirror of the Subversion repository somewhere? git svn clone is quite nice. Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 14:19:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 459F3106564A for ; Sun, 9 Aug 2009 14:19:46 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id BDAD08FC15 for ; Sun, 9 Aug 2009 14:19:45 +0000 (UTC) Received: by fxm24 with SMTP id 24so2714620fxm.36 for ; Sun, 09 Aug 2009 07:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=eReFvudcPtqqEzy6uiuSb69UQ2Kf+IFEc/x79m+1bQc=; b=TE9oUUgKyyDiTKatmBdl7I8tjjr/nFTtsXVA3XfAnJmiIgTTDV429MXx61Odt8Ra76 JsvBhAug0ewW9D7du2nMAuQP7vV/eieQrUSZ4Lho8hMeyYk07HFf4tQPwmK1tXs5CDqN y4jdugpAFoDXSrZZ4lZMSJdrEsKWIqY+LhyUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=k0NXL2yW9liyJixNaItnfaOu+IP8zU0e/xmmEBif3BTWIH/g6uwqE48P2ZZVh0WrNz F2sJXqyDrBNlKuf/THIDW/hrc8eeVReEP8dzGPZ8R4lL1v1xx+DncbKKKtDEisNHThiD MUg0NDmz+YoVzxGWOS0+ES6hBPLoKaIJJGMr4= MIME-Version: 1.0 Received: by 10.103.108.4 with SMTP id k4mr1424725mum.85.1249827584825; Sun, 09 Aug 2009 07:19:44 -0700 (PDT) In-Reply-To: <200908060915.37155.hselasky@c2i.net> References: <200908051022.45347.hselasky@c2i.net> <200908060915.37155.hselasky@c2i.net> Date: Sun, 9 Aug 2009 15:19:44 +0100 Message-ID: From: chris scott To: Hans Petter Selasky , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: usb pen drive detection - still no joy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 14:19:46 -0000 2009/8/6 Hans Petter Selasky > On Wednesday 05 August 2009 23:17:12 chris scott wrote: > > will play around with setting tomorrow > > Find out at exactly which value your device stops working, and which of the > values is critical. > > --HPS > I had a good play around with those values but no joy 8( I took the delay from fairly low (25 ms) right through to 1000ms but it didn't help. I also ranged the continue from 2- 24ms I did however manage to find the psu for a usb2 hub i had. When i plu the device into the powered hub it works. However iff i pull the power plug on the usb hub everything disconnects. I have another non powered usb hub and thats still seen ugen4.2: at usbus4 uhub5: on usbus4 uhub5: 4 ports with 4 removable, self powered ugen4.3: at usbus4 uhub6: on usbus4 uhub6: 4 ports with 4 removable, self powered ugen4.4: at usbus4 umass0: on usbus4 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3840MB (7864320 512 byte sectors: 255H 63S/T 489C) GEOM: da0: partition 1 does not start on a track boundary. GEOM: da0: partition 1 does not end on a track boundary. GEOM: ufsid/4a6383ef48125a83: partition 1 does not start on a track boundary. GEOM: ufsid/4a6383ef48125a83: partition 1 does not end on a track boundary. GEOM: ufs/uroot: partition 1 does not start on a track boundary. GEOM: ufs/uroot: partition 1 does not end on a track boundary. ugen4.2: at usbus4 (disconnected) uhub5: at uhub2, port 2, addr 2 (disconnected) (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry ugen4.3: at usbus4 (disconnected) ugen4.4: at usbus4 (disconnected) From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 14:19:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 983B81065678 for ; Sun, 9 Aug 2009 14:19:58 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 42C7C8FC19 for ; Sun, 9 Aug 2009 14:19:58 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id BB22EEB53D7; Sun, 9 Aug 2009 16:58:01 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 96B0945088; Sun, 9 Aug 2009 16:58:01 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aI21dk1qqkD; Sun, 9 Aug 2009 16:58:01 +0300 (EEST) Received: from kobe.laptop (adsl218-136.kln.forthnet.gr [79.103.31.136]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 5CDFB4503F; Sun, 9 Aug 2009 16:58:01 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n79Dquhm009098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 16:53:11 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n79DqrMO009097; Sun, 9 Aug 2009 16:52:53 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Mel Flynn References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> Date: Sun, 09 Aug 2009 16:52:52 +0300 In-Reply-To: <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> (Mel Flynn's message of "Sat, 8 Aug 2009 10:44:54 -0800") Message-ID: <87my692ix7.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Ed Schouten , freebsd-current@freebsd.org, Thomas Backman Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 14:19:58 -0000 On Sat, 8 Aug 2009 10:44:54 -0800, Mel Flynn wrote: > Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo > TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, > checkout stable/8 and re-apply diffs? It should be possible to 'svn switch'... cd svn-head-workspace svn switch --relocate http://svn.freebsd.org/base/stable/8 From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 14:57:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB261065670 for ; Sun, 9 Aug 2009 14:57:57 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 84D0E8FC26 for ; Sun, 9 Aug 2009 14:57:56 +0000 (UTC) Received: (qmail invoked by alias); 09 Aug 2009 14:31:15 -0000 Received: from p54A3AAA7.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.170.167] by mail.gmx.net (mp018) with SMTP; 09 Aug 2009 16:31:15 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/tITIwblvtPfW+o5UnUx6xYjfXm6v3zgWsr4SLgS RIKVW9UL4FmHjU Message-ID: <4A7EDDB1.6060208@gmx.de> Date: Sun, 09 Aug 2009 16:31:13 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.22 (X11/20090809) MIME-Version: 1.0 To: Giorgos Keramidas References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <87my692ix7.fsf@kobe.laptop> In-Reply-To: <87my692ix7.fsf@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 Cc: Mel Flynn , Ed Schouten , freebsd-current@freebsd.org, Thomas Backman Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 14:57:57 -0000 Giorgos Keramidas schrieb: > On Sat, 8 Aug 2009 10:44:54 -0800, Mel Flynn wrote: >> Also, what's the equivalent of find /usr/src -type d -name CVS -exec echo >> TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, rm -rf, >> checkout stable/8 and re-apply diffs? > > It should be possible to 'svn switch'... > > cd svn-head-workspace > svn switch --relocate http://svn.freebsd.org/base/stable/8 --relocate is used *only* if the URL of the repository changes but the content stays the same. E.g. FreeBSD gets renamed to UnfreeBSD and so the URL of the repository changes to http://svn.unfreebsd.org/base/, then you use --relocate. svn switch --relocate does something completely different than svn switch. The latter is used to switch between branches. Christoph From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 16:15:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B83F5106564A for ; Sun, 9 Aug 2009 16:15:31 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4B2E88FC23 for ; Sun, 9 Aug 2009 16:15:30 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:36645 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MaB3L-0001DW-5V for freebsd-current@freebsd.org; Sun, 09 Aug 2009 18:15:25 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id ED6E519142D for ; Sun, 9 Aug 2009 18:15:24 +0200 (CEST) Message-Id: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 9 Aug 2009 18:15:22 +0200 X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MaB3L-0001DW-5V. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MaB3L-0001DW-5V c581c314b0980e63aa5e67933db8660c Subject: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 16:15:32 -0000 Hey everybody, I discovered a reproducible network-triggerable panic on my -CURRENT box (r196074). The NIC is a nfe (nForce4 SLI) in case it matters. The backtrace differs slightly (the first one had less ??'s, but I'm not sure I ran the same scan that time). I ran the following on a Linux box, while trialling zenmap ("Slow comprehensive scan" - and needless to say .1.10 is the FreeBSD box): nmap -sS -sU -T4 -A -v -PE -PP -PS21,22,23,25,80,113,31339 - PA80,113,443,10042 -PO --script all 192.168.1.10 (nmap -sU -A -v 192.168.1.10 also triggers a panic within 3 seconds, at most.) Starting Nmap 5.00 ( http://nmap.org ) at 2009-08-09 17:52 CEST NSE: Loaded 59 scripts for scanning. Initiating ARP Ping Scan at 17:52 Scanning 192.168.1.10 [1 port] Completed ARP Ping Scan at 17:52, 0.01s elapsed (1 total hosts) Initiating SYN Stealth Scan at 17:52 Scanning chaos (192.168.1.10) [1000 ports] Discovered open port .../tcp on 192.168.10 Discovered open port 80/tcp on 192.168.1.10 Discovered open port .../tcp on 192.168.10 ... and a few more Completed SYN Stealth Scan at 17:52, 5.04s elapsed (1000 total ports) Initiating UDP Scan at 17:52 [... the FreeBSD target box panicked here here, within a second or two] ----------------------------------------------------------------- On the console: Limiting closed port RST response from 276 to 200 packets/sec Limiting closed port RST response from 239 to 200 packets/sec Limiting closed port RST response from 280 to 200 packets/sec Limiting closed port RST response from 319 to 200 packets/sec Limiting icmp unreach response from 214 to 200 packets/sec Limiting icmp unreach response from 275 to 200 packets/sec Limiting icmp unreach response from 449 to 200 packets/sec core.txt: Unread portion of the kernel message buffer: Limiting icmp unreach response from 449 to 200 packets/sec Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff805d2722 stack pointer = 0x28:0xffffff803e76f980 frame pointer = 0x28:0xffffff803e76f990 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 846 (nfsd: service) [NOTE: nfsd was not in use, merely running] panic: from debugger cpuid = 0 KDB: stack backtrace: Uptime: 8m48s Physical memory: 2029 MB Dumping 1625 MB: ... #11 0xffffffff805dba87 in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:224 #12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30, len=4) at /usr/src/sys/xdr/xdr_mbuf.c:302 #13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30, lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147 #14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not available. ) at /usr/src/sys/xdr/xdr.c:111 #15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30, cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188 #16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not available. ) at /usr/src/sys/rpc/svc_dg.c:216 #17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00, ismaster=0) at /usr/src/sys/rpc/svc.c:797 #18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is not available. ) at /usr/src/sys/rpc/svc.c:1198 #19 0xffffffff80341008 in fork_exit ( callout=0xffffffff80558110 , arg=0xffffff00027acc00, frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838 #20 0xffffffff805dbf5e in fork_trampoline () at /usr/src/sys/amd64/ amd64/exception.S:561 #21 0x0000000000000010 in ?? () #22 0x00007fffffffe710 in ?? () ... #47 0x0000000000000000 in ?? () #48 0xffffffff808acf00 in affinity () #49 0xffffff0002d9d390 in ?? () #50 0xffffff803e76f200 in ?? () #51 0xffffff803e76f1b8 in ?? () #52 0xffffff0002336720 in ?? () #53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110, newtd=0xffffff00027acc00, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 ----------------------------------------- I'll be honest and say that FreeBSD doesn't feel very stable for me... Yeah, sure, I use experimental features which causes many of my panics (like ZFS) and run -CURRENT, but will really all issues like this one be fixed in time for 8.0-RELEASE? It's pretty ugly that I can panic it via the network every try, in literally 2-3 seconds. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 17:04:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A0A9106566C for ; Sun, 9 Aug 2009 17:04:26 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC2F8FC19 for ; Sun, 9 Aug 2009 17:04:25 +0000 (UTC) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090809170426.WVIG26684.fed1rmmtao104.cox.net@fed1rmimpo01.cox.net>; Sun, 9 Aug 2009 13:04:26 -0400 Received: from vaio ([72.220.91.251]) by fed1rmimpo01.cox.net with bizsmtp id SH4R1c00E5RPd3403H4RwS; Sun, 09 Aug 2009 13:04:25 -0400 X-VR-Score: -140.00 X-Authority-Analysis: v=1.0 c=1 a=1xfXsQMJAAAA:8 a=JRBjLFAcjro3l8sDLKEA:9 a=3-8Rxek_0so7eHL09C4A:7 a=4Qyeol6EncINNdtwyXYfyXLRI-YA:4 a=HrZdEZb3dGQA:10 X-CM-Score: 0.00 Date: Sun, 9 Aug 2009 10:04:20 -0700 From: Robert To: Sam Leffler Message-ID: <20090809100420.3ca4ff14@vaio> In-Reply-To: <4A7E5E2B.6060204@errno.com> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOR wlan0 wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 17:04:26 -0000 On Sat, 08 Aug 2009 22:27:07 -0700 Sam Leffler wrote: > Robert wrote: > > On Sat, 08 Aug 2009 08:59:27 -0700 > > Sam Leffler wrote: > > > >> Robert wrote: > >>> Greetings > >>> > >>> I have just upgraded a laptop on my network to current: > >>> > >>> [root@hp] ~# uname -a > >>> FreeBSD hp.shasta204.local 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Fri Aug > >>> 7 11:15:24 PDT 2009 root@vaio.shasta204.local:/usr/ob > >>> j/usr/src/sys/VESA i386 > >>> > >>> I have made the changes in rc.conf after reading UPDATING and > >>> rc.conf defaults. Here is the bits from rc.conf > >>> > >>> wlans_wi0=wlan0 # I have tried with quotes around wlan0 with > >>> # no difference. > >>> ifconfig_wlan0="DHCP ssid MY_SSID channel any wepmode on \ > >>> deftxkey 1 wepkey 0xSecretNumber78bf" > >>> > >>> # ifconfig_re0="DHCP" > >>> > >>> My wlan0 interface comes up but never retrieves an IP from the > >>> router. > >>> > >>> [root@hp] ~# ifconfig -a > >>> plip0: flags=8810 metric 0 mtu 1500 > >>> lo0: flags=8049 metric 0 mtu 16384 > >>> options=3 > >>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 > >>> inet6 ::1 prefixlen 128 > >>> ether 00:09:5b:25:5e:b3 > >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > >>> status: associated > >>> wlan0: flags=8843 metric 0 > >>> mtu 1500 ether 00:09:5b:25:5e:b3 > >>> inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 > >>> media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > >>> status: associated > >>> ssid MY_SSID channel 11 (2462 Mhz 11b) bssid > >>> 00:1c:df:f9:ad:fc country US authmode OPEN privacy ON deftxkey 1 > >>> wepkey 1:104-bit txpower 0 bmiss 7 scanvalid 60 > >>> > >>> Searching dmesg I see this > >>> > >>> wlan0: Ethernet address: 00:09:5b:25:5e:b3 > >>> lock order reversal: > >>> 1st 0xc2c04014 wi0_com_lock (wi0_com_lock) > >>> @ /usr/src/sys/net80211/ieee80211_scan.c:806 2nd 0xc2bf2008 wi0 > >>> (network driver) @ /usr/src/sys/dev/wi/if_wi.c:1083 KDB: stack > >>> backtrace: > >>> db_trace_self_wrapper(c0c7746e,cca4ea78,c08c1435,c08b217b,c0c7a303,...) > >>> at db_trace_self_wrapper+0x26 > >>> kdb_backtrace(c08b217b,c0c7a303,c292f228,c2929040,cca4ead4,...) at > >>> kdb_backtrace+0x29 > >>> _witness_debugger(c0c7a303,c2bf2008,c2af88d0,c2929040,c0c6775c,...) > >>> at _witness_debugger+0x25 > >>> witness_checkorder(c2bf2008,9,c0c6775c,43b,0,...) at > >>> witness_checkorder+0x839 > >>> _mtx_lock_flags(c2bf2008,0,c0c6775c,43b,c2bf2008,...) at > >>> _mtx_lock_flags+0xc4 > >>> wi_raw_xmit(c2cc5000,c2cd0000,cca4ebba,10,c2c9c2a4,...) at > >>> wi_raw_xmit+0x3e > >>> ieee80211_send_probereq(c2cc5000,c2c9c2a4,c0bfd600,c0bfd600,c2ac2018,...) > >>> at ieee80211_send_probereq+0x488 > >>> ieee80211_probe_curchan(c2c9c000,0,c0c8aa85,326,cca4ec30,...) at > >>> ieee80211_probe_curchan+0x93 > >>> scan_curchan(c2ac2000,190,c0c8aa85,396,246,...) at > >>> scan_curchan+0x49 scan_task(c2ac2000,1,c0c78c6a,54,c2af4d1c,...) > >>> at scan_task+0x33a > >>> taskqueue_run(c2af4d00,c2af4d1c,0,c0c6a13b,0,...) at > >>> taskqueue_run+0x10b > >>> taskqueue_thread_loop(c2c04074,cca4ed38,c0c6f7cc,33e,c0dc60a0,...) > >>> at taskqueue_thread_loop+0x68 > >>> fork_exit(c08ba5b0,c2c04074,cca4ed38) at fork_exit+0xb8 > >>> fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp > >>> = 0xcca4ed70, ebp = 0 --- Starting Network: lo0. > >>> > >>> The PCMCIA is and older Netgear 802.11b that was working fine on 7 > >>> stable. I have searched the archives and tried changing things in > >>> rc.conf but I can not seem to make this work. > >>> > >>> > >>> Any help or direction will be greatly appreciated. > >> Ignore the LOR. The first thing to do is simplify your config; > >> remove crypto. If you can pass data frames then your problem is in > >> the crypto setup. If not then you have unencrypted data to examine > >> for problems. > >> > >> Use tools/tools/net80211/wlanstats to check for errors. You can > >> trace packet traffic with tcpdump to see if frames are moving. > >> > >> You also don't identify your card. wi in 8.0 works with a subset > >> of the cards in RELENG_7 so your card may not work > >> correctly--though since you appear to have associated that doesn't > >> seem like the issue (cards that don't work are unlikely to > >> successfully associate). > >> > >> Sam > > > > Sam > > > > Thanks for responding and for all of the fine work you are doing. > > > > I thought that I had tried without the crypto before but I either > > didn't or messed up. Anyway, The interface links up fine without WEP > > activated. > > > > I am able to get on the network and NFS loads all file systems from > > other boxes. > > > > Re-enabling WEP on the router (Belkin) and in rc.conf, causes the > > same failure as show above: associated without an IP. > > > > The interface card is old. It shows to be a Netgear MA401. I have > > ordered a newer model of the Netgear card. It is a WG511T which is > > supposed to have an atheros chipset. I should receive this card in > > about a week. I really do not know if any of this is relevant to my > > problem. > > > > On this laptop, because it is old and slow, I NFS mount /usr/src > > from a faster machine. So, wlanstats is not available when I do not > > have an IP. > > > > Running tcpdump -vv shows a whole lot of stuff. It starts with > > wlan0: no IPv4 assigned, so I do not know if the rest is important. > > There are many lines which contain "Unknown SSAP" and "Unknown > > DSAP". I have copied some of it to a file which I can forward if it > > of any help. > > I can confirm WEP is broken on wi in sta mode (and probably ap > mode). I found at least two bugs but couldn't get it to work so am > going to leave it as an errata for 8.0. But what's truly odd is that > WPA works fine despite a bug that should've caused it to not work. I > knew WPA worked which is probably why I ignored WEP (noone in their > right mind uses WEP when WPA is available :-)). > > Sam Sam I never claimed to be in my right mind. I haven't been myself since I quit smoking in 1986. :-) I tried WPA yesterday before answering the previous email. I kept getting and error stating: unable to start wpa_supplicant. I was thinking (always dangerous) that this old card maybe didn't have support for WPA. I'm probably wrong since I am not in my right mind. I was going to try again when the WG511T arrives. But now I will try again. Thanks again Robert From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 17:12:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E55BE106564A; Sun, 9 Aug 2009 17:12:42 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 890658FC20; Sun, 9 Aug 2009 17:12:42 +0000 (UTC) Received: by yxe11 with SMTP id 11so3351852yxe.3 for ; Sun, 09 Aug 2009 10:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=x9Iv5pD7KUgabkfvaEpoaZKCcsTSX1QG6FkXLAtV5I8=; b=cvsB1yWxjEVRpiFWLY974wXvb7341Z660eRpDbClQGciCn3mNLFmTtpdVq7j4xfXON M0fofFtdn0aKeltnrH0sIOctyGVjM6GSbkJUexz1az2tftqc4tNyWluuH8ZlkzvQqbM6 p+zUqKHtAxPTJL/eO0Wstg3hUh7TZ2mZkbyqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=r8nQYYC9AvTrW1IMiksA+uYyJFTwJmLganR1hZgsK1R1yibNwH54/ge63ITrVxzwcx ZGwcTRn3pDqZu9DyhvC9Pzt3rWl1lB0afz5UPmDsDyoqZyOFod7kH7vvckY7bUSZ1Oyv 7r7OdG8TS2lc+boghA4OdMAZXNPQ0lT/a7NMw= MIME-Version: 1.0 Sender: artemb@gmail.com Received: by 10.90.67.6 with SMTP id p6mr3142316aga.100.1249837961645; Sun, 09 Aug 2009 10:12:41 -0700 (PDT) In-Reply-To: References: Date: Sun, 9 Aug 2009 10:12:41 -0700 X-Google-Sender-Auth: 566cff3dc35df880 Message-ID: From: Artem Belevich To: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, Wes Morgan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: [SOLVED] Re: mpt errors - UNIT ATTENTION asc:29,0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 17:12:43 -0000 A bit more digging showed that these mpt errors match UDMA_CRC_Error_Count reported by drives via SMART. Connecting the same drives with the same cables to ICH7 SATA ports completely eliminates the errors which suggests that drives and cables themself are OK. So, my guess is that there's fair amount of cross-talk between LSI1068 ports on the motherboard (Asus P5BV/SAS). In the end I've switched on spread spectrum clocking on the drives (jumper 1-2 on WD SATA drives) and the errors almost completely disappeared. I've got 1 CRC error vs hundreds there used to be after ~10TB have been read/written. What didn't quite work: * Forcing drives into 1.5Gb mode (jumper 5-6 on WD drives). Errors became somewhat less frequent, but didn't go away. * replacing SATA cables -- tried three different sets with virtually no change in error rate. --Artem On Fri, Aug 7, 2009 at 11:06 AM, Artem Belevich wrote: > Hi, > > I'm running 8.0-BETA2 on Asus p5BV/SAS with built-in LSI1068 > controller with 8 SATA ports. 6 of the ports hooked up to 1TB WD Green > drives. The drives are used as a single raidz2 ZFS pool: > > =A0 =A0 =A0 =A0NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM > =A0 =A0 =A0 =A0z2 =A0 =A0 =A0 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 = =A0 0 > =A0 =A0 =A0 =A0 =A0raidz2 =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 > =A0 =A0 =A0 =A0 =A0 =A0da1 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > =A0 =A0 =A0 =A0 =A0 =A0da0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > =A0 =A0 =A0 =A0 =A0 =A0da2 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > =A0 =A0 =A0 =A0 =A0 =A0da3 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > =A0 =A0 =A0 =A0 =A0 =A0da4 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > =A0 =A0 =A0 =A0 =A0 =A0da5 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0= 0 > > I'm runing a simple stress test that copies 10GB file until it fills > the volume and then runs "zfs scrub" on it. > > dd if=3D/dev/urandom of=3D/z2/f.0 bs=3D1m count=3D10240 > for f in {1..350}; do echo $f; cp f.$[$f-1] f.$f; done; > zpool scrub z2 > > What concerns me is that I'm periodically getting error messages from > MPT driver. They usually start few hours after the start of the script > and by the end of it they are happening every few minutes seemingly > randomly on all six drives. > > Aug =A07 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 > Aug =A07 10:25:32 buz kernel: mpt0: mpt_cam_event: 0x16 > Aug =A07 10:25:32 buz kernel: (da4:mpt0:0:4:0): READ(10). CDB: 28 0 46 > 32 97 c0 0 0 80 0 > Aug =A07 10:25:32 buz kernel: (da4:mpt0:0:4:0): CAM Status: SCSI Status E= rror > Aug =A07 10:25:32 buz kernel: (da4:mpt0:0:4:0): SCSI Status: Check Condit= ion > Aug =A07 10:25:32 buz kernel: (da4:mpt0:0:4:0): UNIT ATTENTION asc:29,0 > Aug =A07 10:25:32 buz kernel: (da4:mpt0:0:4:0): Power on, reset, or bus > device reset occurred > Aug =A07 10:25:32 buz kernel: (da4:mpt0:0:4:0): Retrying Command (per Sen= se Data) > > ZFS scrub does not seem to report any issues so far - no checksum or > read/write errors. WD's hard drive diagnostics tools didn't find any > issues with te drives either. > > Sould somebody shed some light on why would such error happen? Is that > some sort of hardware issue? Driver bug? Issue with compatibility > between controller and the drives? System configuration issue (some > sysctl/tunable needs tweaking, perhaps)? > > I'd appreciate any hints on what could be going on and what should be > done about it. > > Thanks, > --Artem > From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 17:21:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D09471065673; Sun, 9 Aug 2009 17:21:00 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 475308FC15; Sun, 9 Aug 2009 17:21:00 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n79HKvpK034406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 19:20:58 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n79HKvVV034358; Sun, 9 Aug 2009 19:20:57 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Sun, 9 Aug 2009 19:20:57 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Juergen Lock Message-ID: <20090809172057.GD78940@acme.spoerlein.net> Mail-Followup-To: Juergen Lock , freebsd-current@freebsd.org, mav@freebsd.org References: <20090806184510.GA12039@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090806184510.GA12039@triton.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mav@freebsd.org, freebsd-current@freebsd.org Subject: Re: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 17:21:01 -0000 On Thu, 06.08.2009 at 20:45:10 +0200, Juergen Lock wrote: > Hi! > > So I put the problematic optical drive on a siis pcie card now because > I wanted to play with esata too which seems to be kinda broken on the > jmicron that I used before at least with _this_ esata drive (hw issue > most likely, has been reported by users of other OSes too) - and I > noticed two things: > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > any reads when a drive fails the read toc command as seems to happen > with bluray (data) discs at least; I was able to work around this > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > Index: sys/cam/scsi/scsi_cd.c > @@ -2868,12 +2868,18 @@ > } > > softc->flags |= CD_FLAG_VALID_TOC; > + > +bailout: > softc->disk->d_maxsize = DFLTPHYS; > softc->disk->d_sectorsize = softc->params.blksize; > softc->disk->d_mediasize = > (off_t)softc->params.blksize * softc->params.disksize; > > +/* if > bailout: > + * is here read requests will fail when the toc cant be read although > + * CD_FLAG_VALID_MEDIA is set. > + */ > > /* > * We unconditionally (re)set the blocksize each time the > > (I say work around because I don't know if there might be stuff > somewhere that depends on the old behaviour, although thats probably > unlikely; also acd(4) seems to behave similarly.) T H A N K Y O U ! Hi Juergen, this nice little patch lets my USB/Firewire attached Plextor drive read "pressed" DVD media, where it failed before. I have mentioned this in the past, but due to the esoteric nature of this problem failed to attract enough attention. http://lists.freebsd.org/pipermail/freebsd-usb/2007-July/003730.html http://docs.freebsd.org/cgi/getmsg.cgi?fetch=644449+0+archive/2007/freebsd-current/20070812.freebsd-current So this is not only related to Bluray, but plain DVD media is affected too (at least for some drives ...) Hopefully this can get committed some time soon... Regards, Uli From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 18:21:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D74A71065672 for ; Sun, 9 Aug 2009 18:21:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE608FC20 for ; Sun, 9 Aug 2009 18:21:34 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC6wfkqDaFvG/2dsb2JhbADMG4QYBYFM X-IronPort-AV: E=Sophos;i="4.43,349,1246852800"; d="scan'208";a="42094869" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 09 Aug 2009 14:21:33 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id A67C72100E1; Sun, 9 Aug 2009 14:21:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw+YTUB0P4Wv; Sun, 9 Aug 2009 14:21:32 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 9144E2100BD; Sun, 9 Aug 2009 14:21:32 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n79IPS419167; Sun, 9 Aug 2009 14:25:28 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 9 Aug 2009 14:25:28 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Thomas Backman In-Reply-To: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> Message-ID: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 18:21:35 -0000 On Sun, 9 Aug 2009, Thomas Backman wrote: [stuff snipped] > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805d2722 > stack pointer = 0x28:0xffffff803e76f980 > frame pointer = 0x28:0xffffff803e76f990 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 846 (nfsd: service) [NOTE: nfsd was not in use, merely > running] > panic: from debugger > cpuid = 0 > KDB: stack backtrace: > Uptime: 8m48s > Physical memory: 2029 MB > Dumping 1625 MB: ... > > #11 0xffffffff805dba87 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:224 > #12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30, len=4) > at /usr/src/sys/xdr/xdr_mbuf.c:302 > #13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30, > lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147 > #14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not available. > ) at /usr/src/sys/xdr/xdr.c:111 > #15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30, > cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188 > #16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not available. > ) at /usr/src/sys/rpc/svc_dg.c:216 > #17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00, > ismaster=0) at /usr/src/sys/rpc/svc.c:797 > #18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is not > available. > ) at /usr/src/sys/rpc/svc.c:1198 > #19 0xffffffff80341008 in fork_exit ( > callout=0xffffffff80558110 , arg=0xffffff00027acc00, > frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838 > #20 0xffffffff805dbf5e in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:561 > #21 0x0000000000000010 in ?? () > #22 0x00007fffffffe710 in ?? () > ... > #47 0x0000000000000000 in ?? () > #48 0xffffffff808acf00 in affinity () > #49 0xffffff0002d9d390 in ?? () > #50 0xffffff803e76f200 in ?? () > #51 0xffffff803e76f1b8 in ?? () > #52 0xffffff0002336720 in ?? () > #53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110, > newtd=0xffffff00027acc00, flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1858 > You could try this patch, which is currently in the re@ queue. I'm not sure if it will help, since the above panic didn't seem to happen at the beginning of xdrmbuf_inline() as I would have expected it to. rick --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 @@ -282,6 +282,8 @@ size_t available; char *p; + if (!m) + return (0); if (xdrs->x_op == XDR_ENCODE) { available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); } else { From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 18:26:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46360106564A; Sun, 9 Aug 2009 18:26:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 209F18FC2E; Sun, 9 Aug 2009 18:26:53 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9A86446B45; Sun, 9 Aug 2009 14:26:52 -0400 (EDT) Date: Sun, 9 Aug 2009 19:26:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Thomas Backman In-Reply-To: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> Message-ID: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: rmacklem@FreeBSD.org, dfr@FreeBSD.org, FreeBSD current Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 18:26:53 -0000 On Sun, 9 Aug 2009, Thomas Backman wrote: > I'll be honest and say that FreeBSD doesn't feel very stable for me... Yeah, > sure, I use experimental features which causes many of my panics (like ZFS) > and run -CURRENT, but will really all issues like this one be fixed in time > for 8.0-RELEASE? It's pretty ugly that I can panic it via the network every > try, in literally 2-3 seconds. Looks like a bug in the NFS server socket/RPC code, which has been revised in 8.0. CC'ing Doug and Rick whose hands were in this (see the original post for stack trace, etc). FYI, there's already at least one bug fix along these lines in the re@ queue pending the 8 branch being completed so that it can be merged -- not sure if it's for the same bug or not. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 18:28:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C89BA106566C for ; Sun, 9 Aug 2009 18:28:05 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by mx1.freebsd.org (Postfix) with ESMTP id A4DB48FC1E for ; Sun, 9 Aug 2009 18:28:05 +0000 (UTC) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090809182804.MGJ26819.fed1rmmtao107.cox.net@fed1rmimpo01.cox.net>; Sun, 9 Aug 2009 14:28:04 -0400 Received: from vaio ([72.220.91.251]) by fed1rmimpo01.cox.net with bizsmtp id SJU41c00A5RPd3403JU4bu; Sun, 09 Aug 2009 14:28:04 -0400 X-VR-Score: -100.00 X-Authority-Analysis: v=1.0 c=1 a=kviXuzpPAAAA:8 a=1xfXsQMJAAAA:8 a=ZI-JPulLI-hUP_d5egwA:9 a=6wicnrFJ-RJip30fg1X_w-jdPlUA:4 a=4vB-4DCPJfMA:10 a=HrZdEZb3dGQA:10 X-CM-Score: 0.00 Date: Sun, 9 Aug 2009 11:27:59 -0700 From: Robert To: Robert Message-ID: <20090809112759.3f1c2399@vaio> In-Reply-To: <20090809100420.3ca4ff14@vaio> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> <20090809100420.3ca4ff14@vaio> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOR wlan0 wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 18:28:06 -0000 On Sun, 9 Aug 2009 10:04:20 -0700 Robert wrote: > On Sat, 08 Aug 2009 22:27:07 -0700 > Sam Leffler wrote: > > > Robert wrote: > > > On Sat, 08 Aug 2009 08:59:27 -0700 > > > Sam Leffler wrote: > > > > > >> Robert wrote: > > >>> Greetings > > >>> > > >>> I have just upgraded a laptop on my network to current: > > > > I can confirm WEP is broken on wi in sta mode (and probably ap > > mode). I found at least two bugs but couldn't get it to work so am > > going to leave it as an errata for 8.0. But what's truly odd is > > that WPA works fine despite a bug that should've caused it to not > > work. I knew WPA worked which is probably why I ignored WEP (noone > > in their right mind uses WEP when WPA is available :-)). > > > > Sam > Sam > > I never claimed to be in my right mind. I haven't been myself since I > quit smoking in 1986. :-) > > I tried WPA yesterday before answering the previous email. I kept > getting and error stating: unable to start wpa_supplicant. > > I was thinking (always dangerous) that this old card maybe didn't have > support for WPA. I'm probably wrong since I am not in my right mind. I > was going to try again when the WG511T arrives. But now I will try > again. > > Thanks again > Sam Set up WPA again. The exact error is: wpa_supplicant[1919]: Failed to initialize driver interface I found this error message in wpa_supplicant.c at line 1772 as part of "static int wpa_supplicant_init_iface2(struct wpa_supplicant *wpa_s)" function. I am just guessing but it seems this card is unable to use WPA. I will wait for the delivery and try with that one. Thanks for all of your help. Robert From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 18:33:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70BF51065698; Sun, 9 Aug 2009 18:33:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4A6F28FC15; Sun, 9 Aug 2009 18:33:36 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id DB35E46B46; Sun, 9 Aug 2009 14:33:35 -0400 (EDT) Date: Sun, 9 Aug 2009 19:33:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rink Springer In-Reply-To: <20090803152202.GB61519@rink.nu> Message-ID: References: <20090803152202.GB61519@rink.nu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: David Boyd , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: FW: 8.0-BETA2 sysinstall ignoring setting of nonInteractive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 18:33:37 -0000 On Mon, 3 Aug 2009, Rink Springer wrote: > On Mon, Aug 03, 2009 at 11:04:31AM -0400, David Boyd wrote: >> Can someone "PLEASE" commit this fix. > > This fix looks OK to me; I'll ask re@ for permission. Just a status update: this is in the re@ queue but approval is pending completion of the stable/7 branch. The plan is that this should appear in beta3. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:11:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F7B106564A; Sun, 9 Aug 2009 19:11:47 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6F8548FC26; Sun, 9 Aug 2009 19:11:47 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 8FD531E0030E; Sun, 9 Aug 2009 21:11:46 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n79J4rtI004915; Sun, 9 Aug 2009 21:04:53 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n79J4rOM004914; Sun, 9 Aug 2009 21:04:53 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 9 Aug 2009 21:04:52 +0200 To: Juergen Lock , freebsd-current@freebsd.org, mav@freebsd.org Message-ID: <20090809190452.GA4740@triton8.kn-bremen.de> References: <20090806184510.GA12039@triton.kn-bremen.de> <20090809172057.GD78940@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090809172057.GD78940@acme.spoerlein.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: cd(4) vs bluray and cdda (dae) on ahci(4) and siis(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:11:47 -0000 On Sun, Aug 09, 2009 at 07:20:57PM +0200, Ulrich Spörlein wrote: > On Thu, 06.08.2009 at 20:45:10 +0200, Juergen Lock wrote: > > Hi! > > > > So I put the problematic optical drive on a siis pcie card now because > > I wanted to play with esata too which seems to be kinda broken on the > > jmicron that I used before at least with _this_ esata drive (hw issue > > most likely, has been reported by users of other OSes too) - and I > > noticed two things: > > > > 1. cd(4) (which the new ahci and siis drivers now also use) fails to do > > any reads when a drive fails the read toc command as seems to happen > > with bluray (data) discs at least; I was able to work around this > > by moving the bailout: label up a few lines in scsi_cd.c:cdcheckmedia(): > > > > Index: sys/cam/scsi/scsi_cd.c > > @@ -2868,12 +2868,18 @@ > > } > > > > softc->flags |= CD_FLAG_VALID_TOC; > > + > > +bailout: > > softc->disk->d_maxsize = DFLTPHYS; > > softc->disk->d_sectorsize = softc->params.blksize; > > softc->disk->d_mediasize = > > (off_t)softc->params.blksize * softc->params.disksize; > > > > +/* if > > bailout: > > + * is here read requests will fail when the toc cant be read although > > + * CD_FLAG_VALID_MEDIA is set. > > + */ > > > > /* > > * We unconditionally (re)set the blocksize each time the > > > > (I say work around because I don't know if there might be stuff > > somewhere that depends on the old behaviour, although thats probably > > unlikely; also acd(4) seems to behave similarly.) > > T H A N K Y O U ! > > Hi Juergen, this nice little patch lets my USB/Firewire attached Plextor > drive read "pressed" DVD media, where it failed before. Cool, I'm glad it helped. :) > I have mentioned > this in the past, but due to the esoteric nature of this problem failed > to attract enough attention. > Heh I know _that_ feeling... > http://lists.freebsd.org/pipermail/freebsd-usb/2007-July/003730.html > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=644449+0+archive/2007/freebsd-current/20070812.freebsd-current > > So this is not only related to Bluray, but plain DVD media is affected > too (at least for some drives ...) > Yeah, good to know! > Hopefully this can get committed some time soon... > *nod* Juergen From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:24:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38E0F1065676 for ; Sun, 9 Aug 2009 19:24:31 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 97B828FC0A for ; Sun, 9 Aug 2009 19:24:30 +0000 (UTC) Received: by bwz2 with SMTP id 2so1660932bwz.43 for ; Sun, 09 Aug 2009 12:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=X4KpiGZqyOESIk+rUmhIfLpsCBf8g5U/V9ecBDk1ZsU=; b=v5dZgV0Iza/ebrknvg52BPyyr3QgQHSbGwCoSNH+OQPsIy+KYQ0MY7rgcXvUGE2IaR uq5nQJ20PmdV0awvFOBOXt1p/FMZyT8KOxCN4hvXvgMyLZivAEsBzlDMiOi3ae33Axdq EB5UFFUJQu+CYLPOuI9FW0ex+BmmF9DNNmfW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=v8IiW5+7Iw+jVJCKj/y/OO3NTxVAT202BFOgYWGCMp8+BlqoZKdre/NIhFGadMXch8 kA/6H2VxhTYZxJgaVqrPAzWX/cuTHV3GLUyyTYE1K/o7jvnSDHi/eab2AOSo2QoOwIsB H7LI7ayzqzq1qv7Gc8u7RuW+xVOI/NVB3OT4k= MIME-Version: 1.0 Received: by 10.223.123.129 with SMTP id p1mr675513far.94.1249845868638; Sun, 09 Aug 2009 12:24:28 -0700 (PDT) In-Reply-To: <4A7EDDB1.6060208@gmx.de> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <87my692ix7.fsf@kobe.laptop> <4A7EDDB1.6060208@gmx.de> Date: Sun, 9 Aug 2009 15:24:28 -0400 Message-ID: <4ad871310908091224x5f26e341sc7aa74d969d2f328@mail.gmail.com> From: Glen Barber To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:24:31 -0000 On Sun, Aug 9, 2009 at 10:31 AM, Christoph Mallon wrote: > > --relocate is used *only* if the URL of the repository changes but the > content stays the same. E.g. FreeBSD gets renamed to UnfreeBSD and so the > URL of the repository changes to http://svn.unfreebsd.org/base/, then you > use --relocate. svn switch --relocate does something completely different > than svn switch. The latter is used to switch between branches. > Should we wait for a -BETA3 or -RC1 (or some other) announcement before switching the repository location, or can we assume it is safe to do so now? -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:33:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42C7D1065688 for ; Sun, 9 Aug 2009 19:33:18 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8380C8FC32 for ; Sun, 9 Aug 2009 19:33:17 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:53921 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MaE8W-0002Cp-58; Sun, 09 Aug 2009 21:32:58 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 8CBA61914A1; Sun, 9 Aug 2009 21:32:55 +0200 (CEST) Message-Id: <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> From: Thomas Backman To: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 9 Aug 2009 21:32:52 +0200 References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MaE8W-0002Cp-58. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MaE8W-0002Cp-58 7c5ed1776d2fea1585c5986d306de6da Cc: FreeBSD current Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:33:18 -0000 On Aug 9, 2009, at 20:25, Rick Macklem wrote: > > > On Sun, 9 Aug 2009, Thomas Backman wrote: > > [stuff snipped] >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x18 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff805d2722 >> stack pointer = 0x28:0xffffff803e76f980 >> frame pointer = 0x28:0xffffff803e76f990 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 846 (nfsd: service) [NOTE: nfsd was not in >> use, merely running] >> panic: from debugger >> cpuid = 0 >> KDB: stack backtrace: >> Uptime: 8m48s >> Physical memory: 2029 MB >> Dumping 1625 MB: ... >> >> #11 0xffffffff805dba87 in calltrap () at /usr/src/sys/amd64/ >> amd64/exception.S:224 >> #12 0xffffffff805d2722 in xdrmbuf_inline (xdrs=0xffffff803e76fa30, >> len=4) >> at /usr/src/sys/xdr/xdr_mbuf.c:302 >> #13 0xffffffff805d2b90 in xdrmbuf_getlong (xdrs=0xffffff803e76fa30, >> lp=0xffffff803e76f9e0) at /usr/src/sys/xdr/xdr_mbuf.c:147 >> #14 0xffffffff805d1a4d in xdr_int (xdrs=Variable "xdrs" is not >> available. >> ) at /usr/src/sys/xdr/xdr.c:111 >> #15 0xffffffff80554ef4 in xdr_callmsg (xdrs=0xffffff803e76fa30, >> cmsg=0xffffff803e76fb70) at /usr/src/sys/rpc/rpc_callmsg.c:188 >> #16 0xffffffff80559c60 in svc_dg_recv (xprt=Variable "xprt" is not >> available. >> ) at /usr/src/sys/rpc/svc_dg.c:216 >> #17 0xffffffff80557910 in svc_run_internal (pool=0xffffff00027acc00, >> ismaster=0) at /usr/src/sys/rpc/svc.c:797 >> #18 0xffffffff8055811b in svc_thread_start (arg=Variable "arg" is >> not available. >> ) at /usr/src/sys/rpc/svc.c:1198 >> #19 0xffffffff80341008 in fork_exit ( >> callout=0xffffffff80558110 , >> arg=0xffffff00027acc00, >> frame=0xffffff803e76fc80) at /usr/src/sys/kern/kern_fork.c:838 >> #20 0xffffffff805dbf5e in fork_trampoline () at /usr/src/sys/ >> amd64/amd64/exception.S:561 >> #21 0x0000000000000010 in ?? () >> #22 0x00007fffffffe710 in ?? () >> ... >> #47 0x0000000000000000 in ?? () >> #48 0xffffffff808acf00 in affinity () >> #49 0xffffff0002d9d390 in ?? () >> #50 0xffffff803e76f200 in ?? () >> #51 0xffffff803e76f1b8 in ?? () >> #52 0xffffff0002336720 in ?? () >> #53 0xffffffff80391c2d in sched_switch (td=0xffffffff80558110, >> newtd=0xffffff00027acc00, flags=Variable "flags" is not available. >> ) at /usr/src/sys/kern/sched_ule.c:1858 >> > You could try this patch, which is currently in the re@ queue. I'm not > sure if it will help, since the above panic didn't seem to happen at > the beginning of xdrmbuf_inline() as I would have expected it to. > > rick > --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 > +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 > @@ -282,6 +282,8 @@ > size_t available; > char *p; > > + if (!m) > + return (0); > if (xdrs->x_op == XDR_ENCODE) { > available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); > } else { > Initial results are certainly good! :-) Pre-patch, it panicked three times in a row, as I said within a few seconds. Post-patch I've looped the simpler scan for a while (10 minutes, or about 8-9 runs) with no crash, and I also ran the more extensive one (which I doubt makes any difference...) once. Just for fun, I tried actually using nfsd while looping the scan, too. No problems. Regards/thanks, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:42:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64F261065670 for ; Sun, 9 Aug 2009 19:42:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1183F8FC08 for ; Sun, 9 Aug 2009 19:42:38 +0000 (UTC) Received: (qmail 12755 invoked by uid 399); 9 Aug 2009 19:42:32 -0000 Received: from localhost (HELO ?192.168.0.100?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 9 Aug 2009 19:42:32 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A7F26A3.6000809@FreeBSD.org> Date: Sun, 09 Aug 2009 12:42:27 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Kevin Oberman References: <20090809014748.284AB1CC31@ptavv.es.net> In-Reply-To: <20090809014748.284AB1CC31@ptavv.es.net> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, bf@freebsd.org Subject: Re: Unable to build HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:42:39 -0000 I'll let bf take the lead on this one. :) Doug Kevin Oberman wrote: >> Date: Wed, 05 Aug 2009 20:45:11 -0700 >> From: Doug Barton >> >> Kevin Oberman wrote: >> >>> OK. I cleaned out /usr/obj and saved /usr/src/sys/i386/conf. >> I'm going to assume that you mean just your conf file there. >> >> >>> While I >>> will have to re-do my kernel config, I prefer to save my old one, >> That's fine, just compare it to GENERIC to make sure that all of your >> entries are valid, and that you're not missing anything important. >> >>> But, as suggested by bf, I think that the WITHOUT_OPENSSH knob is >>> broken which is a problem >> Agreed. If you want to help debug this problem you could try building >> with clean /usr/obj, up to date /usr/src, and ONLY the ssh knob in >> src.conf. Then debug from there. >> >> This (IMWO) is something that should be fixed before release. >> >>> Guess I should have tried V8 a couple of months ago. >> In the immortal words of Jiminy Cricket, let your conscience be your >> guide. :) > > Doug, > > Two patches have been submitted to fix this problem, one by bf > (conf/137483) and one by me (conf/137486). I have confidence that the bf > patch is correct and appropriate and that buildworld is broken with > various src.conf options. I am convinced my patch is correct, > but I suspect that some might argue that it is not appropriate. It > allows pam_ssh to be built even though WITHOUT_OPENSSH is specified. > > I will be happy to defend my patch, if challenged, but the short time > until 8.0 makes it questionable as to whether a consensus can be reached > in time. Whether you like my patch, I'd love to see the patch by bf > (conf/137483) committed before 8.0 and I believe that you agree. If so, > could you request the RE to approve it to be committed. From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:49:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 327E8106564A for ; Sun, 9 Aug 2009 19:49:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DC1858FC1F for ; Sun, 9 Aug 2009 19:49:17 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEfFfkqDaFvI/2dsb2JhbADMHIQYBQ X-IronPort-AV: E=Sophos;i="4.43,349,1246852800"; d="scan'208";a="43842801" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 09 Aug 2009 15:49:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 24F67940074; Sun, 9 Aug 2009 15:49:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNonInLsL4dF; Sun, 9 Aug 2009 15:49:16 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 383CA940073; Sun, 9 Aug 2009 15:49:16 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n79JrCq06329; Sun, 9 Aug 2009 15:53:12 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 9 Aug 2009 15:53:12 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Thomas Backman In-Reply-To: <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> Message-ID: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:49:18 -0000 On Sun, 9 Aug 2009, Thomas Backman wrote: [stuff snipped] >> --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 >> +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 >> @@ -282,6 +282,8 @@ >> size_t available; >> char *p; >> >> + if (!m) >> + return (0); >> if (xdrs->x_op == XDR_ENCODE) { >> available = M_TRAILINGSPACE(m) + (m->m_len - xdrs->x_handy); >> } else { >> > > Initial results are certainly good! :-) > Pre-patch, it panicked three times in a row, as I said within a few seconds. > Post-patch I've looped the simpler scan for a while (10 minutes, or about 8-9 > runs) with no crash, and I also ran the more extensive one (which I doubt > makes any difference...) once. > Just for fun, I tried actually using nfsd while looping the scan, too. No > problems. > Ok, sounds good. It's already in the re@ queue, so it should make it into 8.0. If it does crap out again, please let the list (and me) know. Thanks for testing the patch, rick ps: Thanks mostly goes to pho@ for his "wicked" test scripts that found the crash that the above patch fixes + a bunch of others. From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:55:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C50E106564A for ; Sun, 9 Aug 2009 19:55:18 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id EE05B8FC16 for ; Sun, 9 Aug 2009 19:55:17 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:32944 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MaEU2-0002Pi-5G; Sun, 09 Aug 2009 21:55:12 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 1D1FE191494; Sun, 9 Aug 2009 21:55:13 +0200 (CEST) Message-Id: <8934C698-C37D-4DB7-A7F5-4B93014AD0E9@exscape.org> From: Thomas Backman To: Rick Macklem In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 9 Aug 2009 21:55:10 +0200 References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MaEU2-0002Pi-5G. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MaEU2-0002Pi-5G 1171838591e9557bff3a142706d4ce10 Cc: FreeBSD current Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:55:18 -0000 On Aug 9, 2009, at 21:53, Rick Macklem wrote: > On Sun, 9 Aug 2009, Thomas Backman wrote: > > [stuff snipped] >>> --- xdr/xdr_mbuf.c.sav 2009-08-07 15:02:35.000000000 -0400 >>> +++ xdr/xdr_mbuf.c 2009-08-07 15:03:04.000000000 -0400 >>> @@ -282,6 +282,8 @@ >>> size_t available; >>> char *p; >>> + if (!m) >>> + return (0); >>> if (xdrs->x_op =3D=3D XDR_ENCODE) { >>> available =3D M_TRAILINGSPACE(m) + (m->m_len - = xdrs->x_handy); >>> } else { >> >> Initial results are certainly good! :-) >> Pre-patch, it panicked three times in a row, as I said within a few =20= >> seconds. Post-patch I've looped the simpler scan for a while (10 =20 >> minutes, or about 8-9 runs) with no crash, and I also ran the more =20= >> extensive one (which I doubt makes any difference...) once. >> Just for fun, I tried actually using nfsd while looping the scan, =20 >> too. No problems. >> > Ok, sounds good. It's already in the re@ queue, so it should make it =20= > into > 8.0. If it does crap out again, please let the list (and me) know. > > Thanks for testing the patch, rick > ps: Thanks mostly goes to pho@ for his "wicked" test scripts that =20 > found > the crash that the above patch fixes + a bunch of others. I just looked at the xdrs variable in kgdb, and "m" would indeed be 0 =20= in the crash: (kgdb) p *xdrs $2 =3D {x_op =3D XDR_DECODE, x_ops =3D 0xffffffff806a16c0, x_public =3D =20= 0xffffff007ffdc3a8 "=EF=BF=BDZ\t<", x_private =3D 0x0, x_base =3D 0xffffff000a066e00 "", x_handy =3D 0} And since m is "xdrs->x_private", accessing m wouln't be a good idea. As a newbie, I still think it's safe to say that at least this =20 particular issue is fixed (for me, anyhow). :) Regards, Thomas= From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 19:56:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3215E1065679 for ; Sun, 9 Aug 2009 19:56:16 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id DDACB8FC1E for ; Sun, 9 Aug 2009 19:56:15 +0000 (UTC) Received: from Macintosh-4.local ([10.0.0.198]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n79JuDSd055231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 12:56:13 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A7F29DD.30907@errno.com> Date: Sun, 09 Aug 2009 12:56:13 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Robert References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> <20090809100420.3ca4ff14@vaio> <20090809112759.3f1c2399@vaio> In-Reply-To: <20090809112759.3f1c2399@vaio> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: LOR wlan0 wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 19:56:16 -0000 Robert wrote: > On Sun, 9 Aug 2009 10:04:20 -0700 > Robert wrote: > >> On Sat, 08 Aug 2009 22:27:07 -0700 >> Sam Leffler wrote: >> >>> Robert wrote: >>>> On Sat, 08 Aug 2009 08:59:27 -0700 >>>> Sam Leffler wrote: >>>> >>>>> Robert wrote: >>>>>> Greetings >>>>>> >>>>>> I have just upgraded a laptop on my network to current: > > > > >>> I can confirm WEP is broken on wi in sta mode (and probably ap >>> mode). I found at least two bugs but couldn't get it to work so am >>> going to leave it as an errata for 8.0. But what's truly odd is >>> that WPA works fine despite a bug that should've caused it to not >>> work. I knew WPA worked which is probably why I ignored WEP (noone >>> in their right mind uses WEP when WPA is available :-)). >>> >>> Sam >> Sam >> >> I never claimed to be in my right mind. I haven't been myself since I >> quit smoking in 1986. :-) >> >> I tried WPA yesterday before answering the previous email. I kept >> getting and error stating: unable to start wpa_supplicant. >> >> I was thinking (always dangerous) that this old card maybe didn't have >> support for WPA. I'm probably wrong since I am not in my right mind. I >> was going to try again when the WG511T arrives. But now I will try >> again. >> >> Thanks again >> > > Sam > > Set up WPA again. The exact error is: > > wpa_supplicant[1919]: Failed to initialize driver interface > > I found this error message in wpa_supplicant.c at line 1772 as part of > > "static int wpa_supplicant_init_iface2(struct wpa_supplicant *wpa_s)" > > function. > > I am just guessing but it seems this card is unable to use WPA. I will > wait for the delivery and try with that one. > > Thanks for all of your help. You're probably correct. ifconfig wlan0 list caps will tell you for sure. I think I dropped this issue--that wpa_supplicant should check device capabilities when it hits an error to see if the device is even capable. I've got an MA401 but didn't find it. I tested with a different card the does support wpa. Sam From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 20:08:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83ABE106564A for ; Sun, 9 Aug 2009 20:08:17 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id EDE7F8FC2A for ; Sun, 9 Aug 2009 20:08:16 +0000 (UTC) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 19310EB5419; Sun, 9 Aug 2009 23:08:16 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 087DB450ED; Sun, 9 Aug 2009 23:08:16 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWpn+Ud1bEkS; Sun, 9 Aug 2009 23:08:15 +0300 (EEST) Received: from kobe.laptop (adsl218-136.kln.forthnet.gr [79.103.31.136]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 57A78450D0; Sun, 9 Aug 2009 23:08:15 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n79K1HO5011218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 23:01:33 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n79K1Fx0011217; Sun, 9 Aug 2009 23:01:15 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Christoph Mallon References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <20090808174443.GT1292@hoeg.nl> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <87my692ix7.fsf@kobe.laptop> <4A7EDDB1.6060208@gmx.de> Date: Sun, 09 Aug 2009 23:01:14 +0300 In-Reply-To: <4A7EDDB1.6060208@gmx.de> (Christoph Mallon's message of "Sun, 09 Aug 2009 16:31:13 +0200") Message-ID: <87ab28oiyd.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Mel Flynn , Ed Schouten , freebsd-current@freebsd.org, Thomas Backman Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 20:08:17 -0000 On Sun, 09 Aug 2009 16:31:13 +0200, Christoph Mallon wrote: > Giorgos Keramidas schrieb: >> On Sat, 8 Aug 2009 10:44:54 -0800, Mel Flynn wrote: >>> Also, what's the equivalent of find /usr/src -type d -name CVS -exec >>> echo TRELENG_8 \>{}/Tag \; or do we have to svn diff for local >>> patches, rm -rf, checkout stable/8 and re-apply diffs? >> >> It should be possible to 'svn switch'... >> >> cd svn-head-workspace >> svn switch --relocate http://svn.freebsd.org/base/stable/8 > > --relocate is used *only* if the URL of the repository changes but the > content stays the same. E.g. FreeBSD gets renamed to UnfreeBSD and so > the URL of the repository changes to http://svn.unfreebsd.org/base/, > then you use --relocate. svn switch --relocate does something completely > different than svn switch. The latter is used to switch between > branches. You are right, of course. Thanks :) I got too used to --relocate by using it to switch between /home/svn/base and svn+ssh access to the main repo. To switch between branches of the same repository --relocate is not needed (and may actually cause problems, now that I think about it). From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 20:25:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8C4A106564A for ; Sun, 9 Aug 2009 20:25:00 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 485668FC2A for ; Sun, 9 Aug 2009 20:24:59 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n79KOqJS081508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Aug 2009 22:24:57 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A7F308E.3050601@omnilan.de> Date: Sun, 09 Aug 2009 22:24:46 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: Hans Petter Selasky References: <4A7EA0A7.1000507@omnilan.de> <200908091520.46786.hselasky@c2i.net> In-Reply-To: <200908091520.46786.hselasky@c2i.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6F8B7F92380F97AA43990F9B" Cc: freebsd-current@freebsd.org Subject: Re: USB umass device not working on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 20:25:01 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6F8B7F92380F97AA43990F9B Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hans Petter Selasky schrieb am 09.08.2009 15:20 (localtime): =2E.. > Can you try attaching at FULL speed? >=20 > sysctl hw.usb.ehci.no_hs=3D1 Thanks for your quick response! Here's what I get with high-speed disabled: Aug 9 22:15:35 titan root: Unknown USB device: vendor 0x04e8 product=20 0x5050 bus uhub1 Aug 9 22:15:35 titan kernel: ugen1.2: at usbus1 Aug 9 22:15:36 titan kernel: umass1: on usbus1 Aug 9 22:15:36 titan kernel: umass1: SCSI over Bulk-Only; quirks =3D 0x= 0110 Aug 9 22:15:40 titan kernel: umass1:umass_init_shuttle: Shuttle init=20 returned 0x0000 Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:-1:-1:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:11:1:-1: Attached to scbus11 Aug 9 22:15:41 titan kernel: umass1:umass_cam_rescan: scbus11: scanning = for 11:1:-1 Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:-1:-1:XPT_PATH_INQ:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/36b data/18b sense Aug 9 22:15:41 titan kernel: umass1:umass_attach: Attach=20 finishedumass1:umass_bbb_dump_cbw: CBW 1: cmd =3D 6b (0x120000002400),=20 data =3D 36b, lun =3D 0, dir =3D in Aug 9 22:15:41 titan kernel: Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 4 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D36 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 8 Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_csw: CSW 1: sig =3D=20 0x53425355 (valid), tag =3D 0x00000001, res =3D 0, status =3D 0x00 (good)= Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/56b data/18b sense Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_cbw: CBW 2: cmd =3D 6= b=20 (0x120000003800), data =3D 56b, lun =3D 0, dir =3D in Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 4 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D56 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D0 Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 8 Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_csw: CSW 2: sig =3D=20 0x53425355 (valid), tag =3D 0x00000002, res =3D 0, status =3D 0x00 (good)= Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action: 11:0:0:XPT_PATH_IN= Q:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_GET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SET_TRAN_SETTINGS:. Aug 9 22:15:41 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 22:15:41 titan kernel: umass1:umass_bbb_dump_cbw: CBW 3: cmd =3D 6= b=20 (0x12010000ff00), data =3D 255b, lun =3D 0, dir =3D in Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 4 Aug 9 22:15:41 titan kernel: umass1:umass_t_bbb_data_read_callback:=20 max_bulk=3D131072, data_rem=3D255 Aug 9 22:15:41 titan kernel: umass1:umass_transfer_start: transfer=20 index =3D 5 Aug 9 22:15:46 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_TIMEOUT -> reset Aug 9 22:15:46 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 22:15:46 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! Aug 9 22:15:47 titan kernel: umass1:umass_tr_error: transfer error,=20 USB_ERR_STALLED -> reset Aug 9 22:15:47 titan kernel: umass1:umass_cam_action:=20 11:0:0:XPT_SCSI_IO: cmd: 0x12, flags: 0x40, 6b cmd/255b data/18b sense Aug 9 22:15:47 titan kernel: umass1:umass_t_bbb_reset1_callback: BBB res= et! > Another idea is that your device does not support certain SCSI commands= , and=20 > will crash upon any non-support command. Hmm, if I remember correctly there was some quirk file with devices that = need special treatment. Is it still the same? Maybe there has been an=20 entry for my player which got lost. Or should the new code auto-detect=20 such devices? How's redmond treating such devices? Needless to say that=20 the player doesn't crash on windows, nor does windows crash ;) Thanks, -Harry --------------enig6F8B7F92380F97AA43990F9B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkp/MJQACgkQLDqVQ9VXb8j5swCeKy3q1RhsFsXG3vOKS5SBHO4R VH8AoIaZyXJq55mom1mImX2mnctLMEdQ =rQEO -----END PGP SIGNATURE----- --------------enig6F8B7F92380F97AA43990F9B-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 20:51:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1994B106566B for ; Sun, 9 Aug 2009 20:51:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E4F678FC33 for ; Sun, 9 Aug 2009 20:51:37 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8F9E146B0D; Sun, 9 Aug 2009 16:51:37 -0400 (EDT) Date: Sun, 9 Aug 2009 21:51:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rick Macklem In-Reply-To: Message-ID: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current , Thomas Backman Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 20:51:38 -0000 On Sun, 9 Aug 2009, Rick Macklem wrote: >> Initial results are certainly good! :-) Pre-patch, it panicked three times >> in a row, as I said within a few seconds. Post-patch I've looped the >> simpler scan for a while (10 minutes, or about 8-9 runs) with no crash, and >> I also ran the more extensive one (which I doubt makes any difference...) >> once. Just for fun, I tried actually using nfsd while looping the scan, >> too. No problems. >> > Ok, sounds good. It's already in the re@ queue, so it should make it into > 8.0. If it does crap out again, please let the list (and me) know. > > Thanks for testing the patch, rick ps: Thanks mostly goes to pho@ for his > "wicked" test scripts that found the crash that the above patch fixes + a > bunch of others. It sounds a bit like we would benefit from some directed RPC fuzzing on the NFS client and server. I wonder if an existing fuzzer could easily be adapted to generate RPC-like garbage? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 21:24:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD4D6106566B for ; Sun, 9 Aug 2009 21:24:16 +0000 (UTC) (envelope-from cenixxx@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 631058FC1A for ; Sun, 9 Aug 2009 21:24:16 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so415354fge.12 for ; Sun, 09 Aug 2009 14:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=s8gHi8n/Oxfugn51mAqUXSm2DYiHkvSnvUWRNfRcAQM=; b=alBWn8LyKyG9t1fhJfzZhoBgWsFoNSLZPrVhg0Yh/StRjadqdvdhjt9Cm35B2wnO8g fcwlOPcD7B7uDyyOQ/Tnkfmzs1wQDIK1yiqFxHqYH47SZfa/1O6Ojp7ovAt1y4CioBwZ pwh//THp4AJIa3r84nY5QS9DPkAu/VnW1koPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=O17vfLXupr1qjbGnJZAleXG461obZit0beZDy1sQJ2MJsXgE6PLwBVDDU3jlzc+GzO RqaWdyx0fqCqNJ5KQ7+XhN8bJnRj4zzN4cpiIuuOOKqFw6dLgYHh7T5ysFbOrTk+4ZP9 MkBOBFXuBXgqR/sTzue3TKvLbAFaCTTgj05BA= MIME-Version: 1.0 Received: by 10.86.74.4 with SMTP id w4mr2596401fga.65.1249851681068; Sun, 09 Aug 2009 14:01:21 -0700 (PDT) Date: Mon, 10 Aug 2009 00:01:21 +0300 Message-ID: <5d97c6ec0908091401l26c82ab4u448f4408762fc081@mail.gmail.com> From: Nikolay Antsiferov To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: lwindschuh@googlemail.com, hselasky@c2i.net Subject: Re: reattach 3g0 device: could not allocate new device X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 21:24:17 -0000 Hi. I have seen this issue since december 2008. I have 3G EvDO modem Novatel U-727. It fully supported by u3g driver except this issue with replugging. If I kldload u3g driver and replug modem i have the same messages: > $ kldload u3g > > dmesg: > usb_test_autoinstall:571: Eject CD command status: > USB_ERR_NORMAL_COMPLETION usb_alloc_device:1781: Found Huawei auto-install > disk! > ugen0.2: at usbus0 > ugen0.2: at usbus0 (disconnected) > uhub_reattach_port:440: could not allocate new device! > HPS: Your patch resolved for me this problem. Thanks. I tested replugging modem, device attach correctly, >Try this patch: >src/sys/dev/usb/usb_device.c >@@ -1777,7 +1777,8 @@ > } > } else if (usb_test_huawei_autoinst_p(udev, &uaa) == 0) { > DPRINTFN(0, "Found Huawei auto-install disk!\n"); >- err = USB_ERR_STALLED; /* fake an error */ >+ /* leave device unconfigured */ >+ usb_unconfigure(udev, USB_UNCFG_FLAG_FREE_SUBDEV); > } > } else { > err = 0; /* set success */ -- From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 21:37:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F6A3106566C for ; Sun, 9 Aug 2009 21:37:41 +0000 (UTC) (envelope-from traveling08@cox.net) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4B20F8FC1A for ; Sun, 9 Aug 2009 21:37:41 +0000 (UTC) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090809213741.CEZD26826.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net>; Sun, 9 Aug 2009 17:37:41 -0400 Received: from vaio ([72.220.91.251]) by fed1rmimpo01.cox.net with bizsmtp id SMdg1c00F5RPd3403Mdgdz; Sun, 09 Aug 2009 17:37:40 -0400 X-VR-Score: -100.00 X-Authority-Analysis: v=1.0 c=1 a=1xfXsQMJAAAA:8 a=kviXuzpPAAAA:8 a=apH6-e_g__-scamgZL4A:9 a=QOY-gi3BpqRHscv1zBdCmLbtbX8A:4 a=HrZdEZb3dGQA:10 a=4vB-4DCPJfMA:10 X-CM-Score: 0.00 Date: Sun, 9 Aug 2009 14:37:35 -0700 From: Robert To: Sam Leffler Message-ID: <20090809143735.3fa4e8db@vaio> In-Reply-To: <4A7F29DD.30907@errno.com> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> <20090809100420.3ca4ff14@vaio> <20090809112759.3f1c2399@vaio> <4A7F29DD.30907@errno.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOR wlan0 wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 21:37:41 -0000 On Sun, 09 Aug 2009 12:56:13 -0700 Sam Leffler wrote: > Robert wrote: > > On Sun, 9 Aug 2009 10:04:20 -0700 > > Robert wrote: > > > >> On Sat, 08 Aug 2009 22:27:07 -0700 > >> Sam Leffler wrote: > >> > >>> Robert wrote: > >>>> On Sat, 08 Aug 2009 08:59:27 -0700 > >>>> Sam Leffler wrote: > >>>> > >>>>> Robert wrote: > >>>>>> Greetings > >>>>>> > >>>>>> I have just upgraded a laptop on my network to current: > > > > > > > > > >>> I can confirm WEP is broken on wi in sta mode (and probably ap > >>> mode). I found at least two bugs but couldn't get it to work so > >>> am going to leave it as an errata for 8.0. But what's truly odd > >>> is that WPA works fine despite a bug that should've caused it to > >>> not work. I knew WPA worked which is probably why I ignored WEP > >>> (noone in their right mind uses WEP when WPA is available :-)). > >>> > >>> Sam > >> Sam > >> > >> I never claimed to be in my right mind. I haven't been myself > >> since I quit smoking in 1986. :-) > >> > >> I tried WPA yesterday before answering the previous email. I kept > >> getting and error stating: unable to start wpa_supplicant. > >> > >> I was thinking (always dangerous) that this old card maybe didn't > >> have support for WPA. I'm probably wrong since I am not in my > >> right mind. I was going to try again when the WG511T arrives. But > >> now I will try again. > >> > >> Thanks again > >> > > > > Sam > > > > Set up WPA again. The exact error is: > > > > wpa_supplicant[1919]: Failed to initialize driver interface > > > > I found this error message in wpa_supplicant.c at line 1772 as part > > of > > > > "static int wpa_supplicant_init_iface2(struct wpa_supplicant > > *wpa_s)" > > > > function. > > > > I am just guessing but it seems this card is unable to use WPA. I > > will wait for the delivery and try with that one. > > > > Thanks for all of your help. > > You're probably correct. > > ifconfig wlan0 list caps > > will tell you for sure. I think I dropped this issue--that > wpa_supplicant should check device capabilities when it hits an error > to see if the device is even capable. > > I've got an MA401 but didn't find it. I tested with a different card > the does support wpa. > > Sam ifconfig wlan0 list caps drivercaps=10701 cryptocaps=1 It doesn't look promising. At least it wasn't my burned out brain :-) Robert From owner-freebsd-current@FreeBSD.ORG Sun Aug 9 21:46:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385C51065677 for ; Sun, 9 Aug 2009 21:46:24 +0000 (UTC) (envelope-from jille@quis.cx) Received: from elvis.mayaxatl.org (ip13-124-174-82.adsl2.static.versatel.nl [82.174.124.13]) by mx1.freebsd.org (Postfix) with ESMTP id E831F8FC0A for ; Sun, 9 Aug 2009 21:46:23 +0000 (UTC) Received: by elvis.mayaxatl.org (Postfix, from userid 100) id DCC4922828; Sun, 9 Aug 2009 23:27:07 +0200 (CEST) Received: from [192.168.2.146] (56-64-223.ftth.xms.internl.net [85.223.64.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elvis.mayaxatl.org (Postfix) with ESMTPSA id 847C92280B for ; Sun, 9 Aug 2009 23:27:07 +0200 (CEST) Message-ID: <4A7F3F22.6090005@quis.cx> Date: Sun, 09 Aug 2009 23:26:58 +0200 From: Jille Timmermans User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Freeze while playing with unionfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 21:46:24 -0000 I was playing with unionfs (nearly everytime I do that I lose my uptime ;)). I somehow managed to get the same unionfs mount from and to the same dir. # mount -t unionfs -o copymode=transparent,whiteout=whenneeded,noatime bla1 bla2 both empty dirs; and after hitting some tab too much, my bash froze . Backtrace (shortened; each line was () at +0x): sched_switch() +0xdd mi_switch() +0x16f sleepq_wait() +0x42 __lockmgr_args() +0x7bb ffs_lock() + 0x8c VOP_LOCK1_APV() +0x46 unionfs_lock() + 0x327 VOP_LOCK1_APV() +0x46 unionfs_lock() + 0x1ac VOP_LOCK1_APV() +0x46 _vn_lock() +0x47 unionfs_readdir() +0x134 kern_getdirentries() +0x1fa getdirentries() +0x23 I will reboot this machine in a few minutes; but I think this is reproducable. -- Jille From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 02:04:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B423106566C for ; Mon, 10 Aug 2009 02:04:14 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 62D4B8FC08 for ; Mon, 10 Aug 2009 02:04:13 +0000 (UTC) Received: from localhost (pool-70-20-219-14.phil.east.verizon.net [70.20.219.14]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id A7F4D82A6B; Mon, 10 Aug 2009 11:04:10 +0900 (JST) Date: Sun, 9 Aug 2009 22:04:02 -0400 From: Yoshihiro Ota To: Kostik Belousov Message-Id: <20090809220402.f22935e1.ota@j.email.ne.jp> In-Reply-To: <20090809102119.GC1884@deviant.kiev.zoral.com.ua> References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <200908081044.55066.mel.flynn+fbsd.current@mailing.thruhere.net> <20090808190514.GA60303@owl.midgard.homeip.net> <200908081138.07633.mel.flynn+fbsd.current@mailing.thruhere.net> <4A7DE52F.5000201@FreeBSD.org> <20090808210258.GA1884@deviant.kiev.zoral.com.ua> <4A7DE8A9.7070703@andric.com> <4A7E3906.60007@freebsd.org> <20090809102119.GC1884@deviant.kiev.zoral.com.ua> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dimitry Andric , Tim Kientzle , freebsd-current@freebsd.org Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 02:04:14 -0000 How about SVK? Something like below will copy a repository. % svk mirror svn://svn.freebsd.org/base //freebsd/base I do not know the details mentioned below, though. Hiro On Sun, 9 Aug 2009 13:21:19 +0300 Kostik Belousov wrote: > On Sat, Aug 08, 2009 at 07:48:38PM -0700, Tim Kientzle wrote: > > >On 2009-08-08 23:02, Kostik Belousov wrote: > > >>Working with the history with reasonable speed. Additional bonus > > >>is ability to be able to work offline. > > > > "svnsync" is a standard SVN tool (installed as part > > of svn) that makes it pretty easy to set up a read-only > > copy of an SVN repository. It's a little confusing > > to get set up initially, but once you do, you can > > just run it from cron every hour or so to keep in > > sync. > > > > Main documentation for svnsync starts here: > > http://svnbook.red-bean.com/en/1.5/svn.ref.svnsync.html > The issue with svnsync is that modifications of the non-versioned > properties, that is the normal svn operation, but disabled on our repo, > are not propagated by svnsync. Also, direct manipulations on the repo, > like the surgery that was done with cvs2svn:cvs-rev properties, also not > propagated by svnsync. > > I believe this is major reason why the svnsync mirrors are not given a > bless. I do use svnsync, and my local mirror is used both to feed the > the git-svn and local checkouts. > > > > > Even without a replica, I've found offline work with > > SVN pretty reasonable. No history, but the common > > "svn status", "svn diff", and "svn revert" commands > > are fully functional when offline. > > > > Dimitry Andric wrote: > > >Lowering the load on the main FreeBSD svn server is also nice. :) > > > > This is much less of an issue with SVN than CVS. > > > > Tim > From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 05:27:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5016D1065670; Mon, 10 Aug 2009 05:27:22 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1A73F8FC16; Mon, 10 Aug 2009 05:27:21 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id F17E97E818; Sun, 9 Aug 2009 21:27:20 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Sun, 9 Aug 2009 21:27:19 -0800 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <409F1C03-B18C-4084-93D0-3D1918D7F105@exscape.org> <9e20d71e0908081339l19710247nbe03edd086de7456@mail.gmail.com> <4A7DE4E0.4010205@FreeBSD.org> In-Reply-To: <4A7DE4E0.4010205@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908092127.19931.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Ed Schouten , Dimitry Andric , Doug Barton , Artis Caune , Thomas Backman Subject: Re: What's up with the SVN repository? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 05:27:22 -0000 On Saturday 08 August 2009 12:49:36 Doug Barton wrote: > Artis Caune wrote: > > 2009/8/8 Dimitry Andric : > >>> Also, what's the equivalent of find /usr/src -type d -name CVS -exec > >>> echo TRELENG_8 \>{}/Tag \; or do we have to svn diff for local patches, > >>> rm -rf, checkout stable/8 and re-apply diffs? > >> > >> Use svn switch to switch over your checked out copy, e.g. > >> > >> svn switch svn://svn.freebsd.org/base/stable/8 > > > > If you svn switch, keywords are not re-expanded: > > # $FreeBSD: head/Makefile 190628 2009-04-01 17:11:50Z bz $ > > but should be > > # $FreeBSD: stable/8/Makefile 190628 2009-04-01 17:11:50Z bz $ > > > > I think "svn diff, svn co, patch" is the only way how to switch to > > stable/8. > > You guys are making this way too complicated. Well, I took the lazy road, cause I didn't feel like sorting out what directories were not under svn's control (and thus not showing up in svn diff). svn switch worked fine and fixing the keywords was a breeze: find . -name '.svn' -prune -o -type f -print |while read FILE; do if grep -q '\$FreeBSD: head/.*\$' ${FILE}; then sed -e 's,\$FreeBSD: head/,$FreeBSD: stable/8/,' -i '' ${FILE} else echo "No match: ${FILE}" fi done I put in the else so I could see which files didn't have a keyword. That was fun when we went into contrib :) -- Mel From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 04:31:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A5F4106564A for ; Mon, 10 Aug 2009 04:31:25 +0000 (UTC) (envelope-from muriamas@yahoo.ca) Received: from n3.bullet.mail.re3.yahoo.com (n3.bullet.mail.re3.yahoo.com [68.142.237.110]) by mx1.freebsd.org (Postfix) with SMTP id B50518FC31 for ; Mon, 10 Aug 2009 04:31:24 +0000 (UTC) Received: from [68.142.230.29] by n3.bullet.mail.re3.yahoo.com with NNFMP; 10 Aug 2009 04:19:01 -0000 Received: from [67.195.9.83] by t2.bullet.re2.yahoo.com with NNFMP; 10 Aug 2009 04:19:01 -0000 Received: from [67.195.9.103] by t3.bullet.mail.gq1.yahoo.com with NNFMP; 10 Aug 2009 04:19:00 -0000 Received: from [127.0.0.1] by omp107.mail.gq1.yahoo.com with NNFMP; 10 Aug 2009 04:19:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 887538.73549.bm@omp107.mail.gq1.yahoo.com Received: (qmail 73954 invoked by uid 60001); 10 Aug 2009 02:55:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1249872929; bh=K9icIvscSJmABfwPBSCP+Hw5AStMJ7gIyfMm7omMooM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Mh9tF86sP57maF6HNX3fwyAEYQ+MNhKD4L6T4VbSkyrDGiSZJ0E2wXsGBlNN/GXd8HFZ7p4MK4d1MfsH8bz8zw7JApTQN4u5olkmSumnd9WKXUhyhoHbpdOeMVKPSw+Z7mkhB3vFqmAKck4tf10CmDpWThPd81LMfu45Z/TkAUI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=udBp+szBr10UbZgLBQJWxXA1S0aoo6SV73lDJ9etBfFH0hqQUbz+zq6BeLZuoP0ql/uxZ5aVkMbU+HqKALSDdm8fmDZ0pAzInaaJAK8t+e2HF794L7I1oxFlkYrY5Zplfs4SONzF11yoymUgf6WPNbOfiRzSleaR69umtjBBC8k=; Message-ID: <981942.73761.qm@web111615.mail.gq1.yahoo.com> X-YMail-OSG: uhR1mzMVM1nl_8ncnpaH1hB9BUOaq2UMLTNLsBI_kWlokyxkDu2l8GIiccPud.O7ju_hwgHneRyryz8o6oULcbPOzTUSuJHg5k9D67xXuHGEv07mTLNJyjONRXS9iTYJQBUdeeX.aNZSlAKiE2Mv6tQH8bdnYl2J3M.nXcsN1mQM8WyGgbxh_6_yIYU5nXu5zx6UvSI21_4dDXE01KbEgteYwwODLCvpoZmHKtlKmWzBA6DW.i6itDALlbUVX_jlHSG1czuqPMD2TzIEgYOKVLSPgoG7u6Btlc2O8QR1YVAPRfCqPQ-- Received: from [70.82.43.46] by web111615.mail.gq1.yahoo.com via HTTP; Sun, 09 Aug 2009 19:55:29 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.289.15 Date: Sun, 9 Aug 2009 19:55:29 -0700 (PDT) From: Walter Scott To: current@freebsd.org MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Aug 2009 05:28:02 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: 8-current: no internet connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 04:31:26 -0000 Please take a look: http://forums.freebsd.org/showthread.php?=6138 __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 06:54:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DD31106564A for ; Mon, 10 Aug 2009 06:54:12 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8BC118FC24 for ; Mon, 10 Aug 2009 06:54:11 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n7A6s7eT091758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Aug 2009 08:54:09 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A7FC408.6020401@omnilan.de> Date: Mon, 10 Aug 2009 08:54:00 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: FreeBSD Current References: <4A7EA0A7.1000507@omnilan.de> In-Reply-To: <4A7EA0A7.1000507@omnilan.de> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigADAC20D9091B16FEB3F11CAF" Subject: Re: USB umass device not working on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 06:54:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigADAC20D9091B16FEB3F11CAF Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Harald Schmalzbauer schrieb am 09.08.2009 12:10 (localtime): =2E.. > one year ago I fed my present for my mother with some music files - a=20 > samsung ogg-player. > Until now the music collection is still untouched, so I tried to help=20 > her and replace some files. > Unfortunately it doesn't attach as daX any more. =2E.. Hmmm, very strange, here I found a PR reporting the opposite: http://www.jp.freebsd.org/cgi/query-pr.cgi?pr=3D114154 It's my player (just the 2G version) and Ulrich Spoerlein reports it=20 working with HPS' stack, but not with the old USB code. I'm sure I filled this puppy here and I've been running FreeBSD-7 until=20 -current was ready for testing (arround beta1). None the less, this device seems to work somehow on FreeBSD. I'm not=20 sure how usb_quirk.ko is related. I'm lost. Are there still hard coded=20 quirks? Any help appreciated Thanks, -Harry --------------enigADAC20D9091B16FEB3F11CAF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkp/xA8ACgkQLDqVQ9VXb8jCewCfYi1asDk2zwRF/xWkrZgaZWtQ wWIAmQHjgj1sgDT6zFEZMrimgb8/ibBX =iTEy -----END PGP SIGNATURE----- --------------enigADAC20D9091B16FEB3F11CAF-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 09:48:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0820C1065677 for ; Mon, 10 Aug 2009 09:48:01 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 6C84C8FC3F for ; Mon, 10 Aug 2009 09:48:00 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7A9CrHa040462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Aug 2009 11:12:55 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Walter Scott In-Reply-To: <981942.73761.qm@web111615.mail.gq1.yahoo.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 11:12:52 +0200 References: <981942.73761.qm@web111615.mail.gq1.yahoo.com> X-Mailer: Apple Mail (2.936) Cc: current@freebsd.org Subject: Re: 8-current: no internet connection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 09:48:01 -0000 Am 10.08.2009 um 04:55 schrieb Walter Scott: > Please take a look: http://forums.freebsd.org/showthread.php?=6138 The correct link is (I assume). I'm quoting relevant parts from the forum post: > dmesg output: > de0: port 0x9400-0x947f mem > 0xe4800000-0xe480007f irq1 > de0: SMC 21041 [10Mb/s] pass 2.1 > de0: WARNING: using obsolete if_watchdog interface > de0: Ethernet address: xxxxxxxxxxxx > de0: [ITHREAD] > ifconfig output: > de0: flags=8843 metric 0 > mtu 1500 > ether xxxxxxxxxx > media: Ethernet autoselect (10baseT/UTP) > status: active I'm guessing that you're trying DHCP on de0? What's in /etc/rc.conf? Does it work if you assign an address manually? If not, can you see any packets arriving on the interface with tcpdump? You can also try to fiddle with the interfaces full-duplex setting. If this should be a problem with the de driver, someone will likely know more details about the hardware, so the output of pciconf -vl should be interesting, as well as dmesg output from a working FreeBSD (i.e. 6.4 or 7.x). What interrupt do other OSes report for the card? irq 1 can't be right. Or is the dmesg line cut off? There should be further output after the irq, like "at device n.m on pci0" HTH, Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 12:49:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB69E106566B; Mon, 10 Aug 2009 12:49:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE5E8FC3E; Mon, 10 Aug 2009 12:49:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 41D9546B2E; Mon, 10 Aug 2009 08:49:54 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3D0338A0AD; Mon, 10 Aug 2009 08:49:53 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 10 Aug 2009 08:07:29 -0400 User-Agent: KMail/1.9.7 References: <4A787826.5090909@lozenetz.org> In-Reply-To: <4A787826.5090909@lozenetz.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908100807.30269.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 10 Aug 2009 08:49:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: kib@freebsd.org, Anton - Valqk Subject: Re: 8.0-BETA2: two kernel lockups in one night X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 12:49:55 -0000 On Tuesday 04 August 2009 2:04:22 pm Anton - Valqk wrote: > Hi group. > I've installed amd64 8.0-BETA2 distro from iso from official ftp. > I knew there was a problem with hangs of the system because of disk io > (and this machine is going to be loaded) and started tesing with bonnie++ > > In about 5-6 hours the first lockup came into real. > Kernel went into dbg console and continue rebooted the system. > Few hours later bonnie started again - same thing in few hours I got the > second dump. > > This is the bonnie++ opts I've used: > > #> bonnie++ -u root -d /usr/test/ -c 10 -s 4098 -n 26000:100000:10:1000 > -n 2048 -r 4098 -x 10000 -q -Z /dev/urandom > stat.html > > and here are links to the txt dumps. > If someone is interested in the vmcore files let me know. > http://bg0.eu/core.txt.0 > http://bg0.eu/core.txt.1 > > Are these issues known for 8.0-BETA2? I don't think these are known issues. I think the two panics may be caused by the same bug which looks to be a duplicate free() issue in the soft updates code. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 13:05:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B492F1065674 for ; Mon, 10 Aug 2009 13:05:51 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0AFCE8FC2B for ; Mon, 10 Aug 2009 13:05:51 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 35CF13981A; Mon, 10 Aug 2009 15:05:38 +0200 (SAST) Date: Mon, 10 Aug 2009 15:05:38 +0200 From: John Hay To: freebsd-current@freebsd.org Message-ID: <20090810130538.GA62008@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: gptboot parse error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 13:05:52 -0000 Hi, When experimenting with gptboot to boot different partitions, I found that its parse() function was broken. Using 'p' to seperate the units from the partition did not work, neither did a ','. Here is a fix to make it work with 'p' like it is suggested in main(). Any comments? Should we try to get it in before 8.0? This allows me to use boot.config to select different partitions to boot from. Something like "ad(0p3)/boot/loader" for instance. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org Index: gptboot.c =================================================================== RCS file: /home/ncvs/src/sys/boot/i386/gptboot/gptboot.c,v retrieving revision 1.86.2.3 diff -u -r1.86.2.3 gptboot.c --- gptboot.c 15 Aug 2008 19:31:12 -0000 1.86.2.3 +++ gptboot.c 7 Aug 2009 10:27:09 -0000 @@ -466,16 +466,13 @@ dsk.type = i; arg += 3; dsk.unit = *arg - '0'; - if (arg[1] != ',' || dsk.unit > 9) + if (arg[1] != 'p' || dsk.unit > 9) return -1; arg += 2; - dsk.part = -1; - if (arg[1] == ',') { - dsk.part = *arg - '0'; - if (dsk.part < 1 || dsk.part > 9) - return -1; - arg += 2; - } + dsk.part = *arg - '0'; + if (dsk.part < 1 || dsk.part > 9) + return -1; + arg++; if (arg[0] != ')') return -1; arg++; From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 13:40:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3212106566B; Mon, 10 Aug 2009 13:40:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 52A418FC43; Mon, 10 Aug 2009 13:40:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C02F241C65E; Mon, 10 Aug 2009 15:40:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id lj1c17XpGTQo; Mon, 10 Aug 2009 15:40:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3D70341C64C; Mon, 10 Aug 2009 15:40:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A68CC4448EC; Mon, 10 Aug 2009 13:39:16 +0000 (UTC) Date: Mon, 10 Aug 2009 13:39:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Robert Watson In-Reply-To: Message-ID: <20090810133111.C93661@maildrop.int.zabbadoz.net> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jeff Roberson , freebsd-current@freebsd.org, kib@FreeBSD.org, Navdeep Parhar , Larry Rosenman , lstewart@FreeBSD.org Subject: Re: reproducible panic in netisr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 13:40:10 -0000 On Thu, 6 Aug 2009, Robert Watson wrote: Hi, > On Thu, 6 Aug 2009, Larry Rosenman wrote: > >> On Thu, 6 Aug 2009, Robert Watson wrote: >> >>> On Tue, 4 Aug 2009, Navdeep Parhar wrote: >>> >>>>>> This occurs on today's HEAD + some unrelated patches. That makes it >>>>>> 8.0BETA2+ code. I haven't tried older builds. >>>>> >>>>> We have finally been able to reproduce this ourselves yesterday and >>>> >>>> Well, it happens every single time on all of my amd64 machines. After I'd >>>> already sent my email I noticed that the netisr mutex has an odd address >>>> (pun intended :-)) >>>> >>>> m=0xffffffff8144d867 >>> >>> Heh, indeed. We just spotted the same result here. In this case it's >>> causing a panic because it leads to a non-atomic read due to mtx_lock >>> spanning a cache line boundary, followed shortly by a panic because it's >>> not a valid thread pointer when it's dereferenced, as we get a fractional >>> pointer. >> [snip] >> >> Do we have an ETA for a testable patch? > > RSN, I'm afraid. ... You can fetch the following from .. as well: http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff I tried to get things summarized a bit; as good as possible from my pov/knowledge: ------------------------------------------------------------------------ [ The following samples, etc are generally "thinking" arch=amd64: ] There are two different kinds of places where we find dynamic per-cpu (dpcpu) data: (1) the so called 'master copy', that is a linker set, which holds the BSS initialized compile-time defaults. (2) a copy for each PU copied to allocated memory. The problem seen has been that single members of the set had been un-aligned at run-time. Dumping the linker set (master copy), things look like this for example: ffffffff8168f8e9 g *ABS* 0000000000000000 __start_set_pcpu ffffffff8168f900 l d set_pcpu 0000000000000000 ffffffff8168f900 g O set_pcpu 0000000000000068 pcpu_entry_sched_switch_stats ffffffff8168f980 l O set_pcpu 0000000000000800 pcpu_entry_modspace ffffffff81690180 g O set_pcpu 0000000000000038 pcpu_entry_epair_dpcpu ffffffff81690200 g O set_pcpu 0000000000000500 pcpu_entry_nws ffffffff81690700 g *ABS* 0000000000000000 __stop_set_pcpu The members of the linker set (master copy) are all well aligned within the set: for example pcpu_entry_nws: 0xffffffff81690200 % 128 = 0 Looking at elfdump for the kernel this is also what we would expect: entry: 32 sh_name: set_pcpu sh_type: SHT_PROGBITS sh_flags: SHF_WRITE|SHF_ALLOC sh_addr: 0xffffffff8168f900 sh_offset: 21559552 sh_size: 3584 sh_link: 0 sh_info: 0 sh_addralign: 128 <<<< sh_entsize: 0 The problem is with __start_set_pcpu, the symbol ld adds to mark the beginning of the section. The address of __start_set_pcpu is not well-aligned, not even pointer-aligned: 0xffffffff8168f8e9 % 8 = 1. When now copying the 'master copy' to a dpcpu area the aligned symbols become un-aligned. Example: dpcpu area starts at 0xffff0000 |--------+------------------------------------------ Copyin the master copy from the objdump above starting at __start_set_pcpu will put __start_set_pcpu at 0xffff0000 but the first symbol pcpu_entry_sched_switch_stats at 0xffff0017 0xffff0000 |--------+------------------------------------------ |~~~~~~~~|------------------------------------------======== 0xffff0017 Two problems become obvious: (1) the symbols are now un-aligned in the per-cpu area. (2) due to the offset we did not copy the entire dpcpu area, so some symbols at the end might not have been properly initialized. While (2) may lead to run-time problems it usually is not a problem with memory corrution as the dpcpu area is usually allocated in pages. So unless the dpcpu symbols end page aligned there should be no corruption. (1) in contrast may lead to other effects like a lock spanning multiple cache lines thus no longer permitting atomic reads and being open to races. The results are panics with truncated pointers trying to access invalid memory regions, etc. On architectures like arm, this will immediatly fault as arm does not allow un-aligned reads. So one solution to the problem would be to make sure we allocate enough memory to also account for the offset to proper alignment and then copying the 'master copy' to a possibly unaligned address as well making the symbols properly aligned again: dpcpu area starts at 0xffff0000 |--------+---------+------------------------------------... |*** unused *******|~~~~~~~~|---------------------------... 0xffff0069 | 0xffff0080 In this sample __start_set_pcpu would be at 0xffff0069 and pcpu_entry_sched_switch_stats at 0xffff0080 and thus properly aligned again. With this things will work. Looking further at the problem you may have already noticed that the section for the 'master copy' starts at 0xffffffff8168f900 and that the __start_set_pcpu is outside of that section at 0xffffffff8168f8e9. Looking at a section dump from `readelf -S kernel` you would notice that the __start_set_pcpu directly follows the end of the previous section. The reasons for this are twofold: (1) ld places the __start_ symbol at '.' (the location counter), which at that point is at the end of the old section as the new (set_pcpu) is not yet added with __start_set_pcpu = ALIGN(0). (2) because we manually define the section, so that it is writeable, ld at the point of writing the __start_ symbol does not yet have any possible section alignment information. That is the reason for the ALIGN(0) in (1). An expected behaviour would be for ld to put the *ABS* at the address where the section begins, once known or fixup the address. This could arguably be a bug in ld we should fix post-8.0. One possible workaround would be to force the __start_ symbol and the section to be equally aligned and thus on the same address using linker scripts. The drawbacks are that we need to touch the fragile linker scripts for each of the sections we add and for all architectures individually. As the enforcement of alignment would be at a different place to the actual set creation, putting the alignment in might be easily forgotten. The advantage would be that we can always be sure that __start_ would be on the same address where the section starts. Another solution is to put minimum alignment on the objects inside the section in a way that it is only in a single place in the source code. The section directive in the respective header file, that will be included by each implementation file, is the ideal place for this. While cache line alignment seems to be the widest alignment restriction currently in use, one drawback, like with above ldscript solution, is that a symbol could possibly enforce a wider alignment restriction onto the section making the __start_ symbol and the section beginning to diverge again. Example: 0xffffffff8168f700 __start_set_pcpu 0xffffffff8168f800 set_pcpu 0xffffffff8168f800 pcpu_entry_sched_switch_stats .. if we would put an alignment of 1024 on pcpu_entry_sched_switch_stats. This is unlikely to happen. With the minimum alignment, ld, at the time of placing the __start_ symbol, already knows about the section alignment and will place it correctly on the section beginning doing: __start_set_pcpu = ALIGN(CACHE_LINE_SHIFT) at ".". Summary: The minimum alignment seems to be the least-intrusive solution and is believed to work for the moment. In addition documenting that the dpcpu and similar sections will not support super-cache line alignment. The long term solution would be to fix ld to DTRT. ------------------------------------------------------------------------ ! ! Put minimum alignment on the dpcpu and vnet section so that ld ! when adding the __start_ symbol knows the expected section alignment ! and can place the __start_ symbol correctly. ! ! These sections will not support symbols with super-cache line alignment ! requirements. ! ! See posting , 2009-08-10, to freebsd-current for full ! details. ! ! Debugging and testing patches by: ! Kamigishi Rei (spambox haruhiism.net), np, lstewart, jhb, ! kib, rwatson ! Tested by: Kamigishi Rei, lstewart ! Reviewed by: kib ! Approved by: ! Index: sys/sys/pcpu.h =================================================================== --- sys/sys/pcpu.h (revision 196086) +++ sys/sys/pcpu.h (working copy) @@ -56,12 +56,14 @@ extern uintptr_t *__start_set_pcpu; extern uintptr_t *__stop_set_pcpu; +__asm__( #if defined(__arm__) -__asm__(".section set_pcpu, \"aw\", %progbits"); + ".section set_pcpu, \"aw\", %progbits\n" #else -__asm__(".section set_pcpu, \"aw\", @progbits"); + ".section set_pcpu, \"aw\", @progbits\n" #endif -__asm__(".previous"); + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" + "\t.previous"); /* * Array of dynamic pcpu base offsets. Indexed by id. Index: sys/net/vnet.h =================================================================== --- sys/net/vnet.h (revision 196086) +++ sys/net/vnet.h (working copy) @@ -185,12 +185,14 @@ * Virtual network stack memory allocator, which allows global variables to * be automatically instantiated for each network stack instance. */ +__asm__( #if defined(__arm__) -__asm__(".section " VNET_SETNAME ", \"aw\", %progbits"); + ".section " VNET_SETNAME ", \"aw\", %progbits\n" #else -__asm__(".section " VNET_SETNAME ", \"aw\", @progbits"); + ".section " VNET_SETNAME ", \"aw\", @progbits\n" #endif -__asm__(".previous"); + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" + "\t.previous"); #define VNET_NAME(n) vnet_entry_##n #define VNET ------------------------------------------------------------------------ -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 14:45:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF70106566B for ; Mon, 10 Aug 2009 14:45:12 +0000 (UTC) (envelope-from saifi.khan@datasynergy.org) Received: from s219.sureserver.com (s219.sureserver.com [203.194.200.31]) by mx1.freebsd.org (Postfix) with ESMTP id 542B98FC1F for ; Mon, 10 Aug 2009 14:45:10 +0000 (UTC) Received: (qmail 12003 invoked by uid 1002); 10 Aug 2009 14:18:30 -0000 Received: from unknown (HELO ?10.10.10.7?) (saifi.khan@datasynergy.org@59.92.190.227) by s219.sureserver.com with ESMTPA; 10 Aug 2009 14:18:30 -0000 Date: Mon, 10 Aug 2009 19:46:51 +0530 (IST) From: Saifi Khan X-X-Sender: saifi@freebsd To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: 8.0-CURRENT beta2 AMD64 installation issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 14:45:12 -0000 Hi all: i'm trying to install, FreeBSD 8.0 beta 2 from disc1 on my AMD64 Athlon X2 box. The complete hardware specs can be seen here http://www.freebsd.org/cgi/query-pr.cgi?pr=www/133262 The issue faced is "installInitial: Couldn't clone the boot floppy into the root filesystem. Aborting" If i use the entire SATA II NCQ disk, this error is not seen, but if i create a partition eg. i'm using a 80GB FreeBSD partition (marked bootable), then this error is seen. Any pointers ? What could i be missing ? thanks Saifi. http://twitter.com/saifikhan From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 14:08:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52300106566B for ; Mon, 10 Aug 2009 14:08:00 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from mail.webreality.org (mailserver.webreality.org [217.75.141.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0262F8FC36 for ; Mon, 10 Aug 2009 14:07:59 +0000 (UTC) Received: by mail.webreality.org (Postfix, from userid 58) id 4999C1522DED; Mon, 10 Aug 2009 17:08:05 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mailserver.webreality.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=7.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 Received: from [10.0.1.101] (gw1.sofiasoftsolutions.com [195.34.104.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webreality.org (Postfix) with ESMTPSA id D2B871522DE7; Mon, 10 Aug 2009 17:08:02 +0300 (EEST) Message-ID: <4A8029BA.8060509@lozenetz.org> Date: Mon, 10 Aug 2009 17:07:54 +0300 From: Anton - Valqk User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: John Baldwin References: <4A787826.5090909@lozenetz.org> <200908100807.30269.jhb@freebsd.org> In-Reply-To: <200908100807.30269.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Aug 2009 15:12:03 +0000 Cc: freebsd-current@freebsd.org, kib@freebsd.org Subject: Re: 8.0-BETA2: two kernel lockups in one night X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 14:08:00 -0000 Hi there! Thanks for the answer. I've tested a 7-STABLE system and the benchmarks passed perfectly (I've had a doubt in my hardware)... I've installed 8Beta2 again and got some dumps and lockups again.... If I can help with something (I can give serial+ssh access to this machine with 8Beta2 - it's testing machine at the current moment. Will go in production in a month or so.)? If I can't hope that this bug will get fixed until 8-STABLE (when was the release date planned? sept?) Thanks again and cheers, valqk. John Baldwin wrote: > On Tuesday 04 August 2009 2:04:22 pm Anton - Valqk wrote: > >> Hi group. >> I've installed amd64 8.0-BETA2 distro from iso from official ftp. >> I knew there was a problem with hangs of the system because of disk io >> (and this machine is going to be loaded) and started tesing with bonnie++ >> >> In about 5-6 hours the first lockup came into real. >> Kernel went into dbg console and continue rebooted the system. >> Few hours later bonnie started again - same thing in few hours I got the >> second dump. >> >> This is the bonnie++ opts I've used: >> >> #> bonnie++ -u root -d /usr/test/ -c 10 -s 4098 -n 26000:100000:10:1000 >> -n 2048 -r 4098 -x 10000 -q -Z /dev/urandom > stat.html >> >> and here are links to the txt dumps. >> If someone is interested in the vmcore files let me know. >> http://bg0.eu/core.txt.0 >> http://bg0.eu/core.txt.1 >> >> Are these issues known for 8.0-BETA2? >> > > I don't think these are known issues. I think the two panics may be caused by > the same bug which looks to be a duplicate free() issue in the soft updates > code. > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 15:35:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B932106566C; Mon, 10 Aug 2009 15:35:20 +0000 (UTC) (envelope-from ler@lerctr.org) Received: from thebighonker.lerctr.org (thebighonker.lerctr.org [192.147.25.65]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4DD8FC15; Mon, 10 Aug 2009 15:35:20 +0000 (UTC) Received: from 76-205-169-61.lightspeed.austtx.sbcglobal.net ([76.205.169.61]:62039 helo=borg) by thebighonker.lerctr.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MaWu6-000Hdr-7j; Mon, 10 Aug 2009 10:35:19 -0500 Date: Mon, 10 Aug 2009 10:35:04 -0500 (CDT) From: Larry Rosenman Sender: ler@borg To: "Bjoern A. Zeeb" In-Reply-To: <20090810133111.C93661@maildrop.int.zabbadoz.net> Message-ID: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.5 (--) X-LERCTR-Spam-Score: -2.5 (--) X-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 X-LERCTR-Spam-Report: SpamScore (-2.5/5.0) ALL_TRUSTED=-1.8, BAYES_00=-2.599, TVD_RCVD_IP=1.931 DomainKey-Status: no signature Cc: Jeff Roberson , freebsd-current@freebsd.org, kib@FreeBSD.org, Navdeep Parhar , lstewart@FreeBSD.org, Robert Watson Subject: Re: reproducible panic in netisr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 15:35:20 -0000 On Mon, 10 Aug 2009, Bjoern A. Zeeb wrote: [snip] > > You can fetch the following from .. as well: > http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff [snip] I applied this patch to my 2009/08/03 csup checkout, and ran my bacula backup. The backup pre-patch would cause the netisr panic very quickly. With the patch applied, it's on the second host, which is a good sign. Just trying to get feedback in. Please let me know if there is anything else I can supply to help with this. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 16:39:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4DC11065674; Mon, 10 Aug 2009 16:39:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 70F988FC25; Mon, 10 Aug 2009 16:39:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHrqf0qDaFvH/2dsb2JhbADQeoQYBYFM X-IronPort-AV: E=Sophos;i="4.43,354,1246852800"; d="scan'208";a="42186724" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 10 Aug 2009 12:39:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 44B51108463E; Mon, 10 Aug 2009 12:39:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMemWiDGWXo7; Mon, 10 Aug 2009 12:39:11 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 4DB3E108460B; Mon, 10 Aug 2009 12:39:11 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n7AGh8A17021; Mon, 10 Aug 2009 12:43:08 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 10 Aug 2009 12:43:08 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current , Thomas Backman Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 16:39:14 -0000 On Sun, 9 Aug 2009, Robert Watson wrote: > > It sounds a bit like we would benefit from some directed RPC fuzzing on the > NFS client and server. I wonder if an existing fuzzer could easily be > adapted to generate RPC-like garbage? > It certainly sounds like it would make an interesting project. I vaguely recall Isilon mentioning they had something they used for "hardening" their NFS server. I have no idea what that was (or even if it was them;-), but it would be interesting to have something. CITI at UMich have a Python test suite for NFSv4 and I (again, vaguely:-) recall it does try various kinds of bogus/garbage args. It might be one starting point. Could it qualify as a Google SOC project for next summer? (hint, hint...I haven't got the time to do it.) rick From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 17:10:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B912F10656A6 for ; Mon, 10 Aug 2009 17:10:50 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D4798FC42 for ; Mon, 10 Aug 2009 17:10:50 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n7AHAkKh010286; Mon, 10 Aug 2009 10:10:46 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n7AHAkod010285; Mon, 10 Aug 2009 10:10:46 -0700 (PDT) Date: Mon, 10 Aug 2009 10:10:46 -0700 (PDT) From: Matthew Dillon Message-Id: <200908101710.n7AHAkod010285@apollo.backplane.com> To: Rick Macklem References: <598778D3-AE7B-47AF-A4F9-0D832BC1A990@exscape.org> <00694EF2-9BBC-4733-91C7-A6AE973D8973@exscape.org> Cc: FreeBSD current , Robert Watson , Thomas Backman Subject: Re: nmap UDP scan against 8.0-CURRENT -> fatal trap 12 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:10:51 -0000 There are probably still some improper uses of signed integers for length tests, against lengths being too long. If the unsigned value is (signed)negative, the test doesn't catch it. Look for cases where fxdr_unsigned() is being passed a signed integer cast *OR* is being assigned to a signed integer type. I found a few in DFly but I haven't done a real audit. For example, nfs_serv.c line 2768 in the FreeBSD codebase is one such case: cnt = fxdr_unsigned(int, *tl); if (cnt > xfer) <<< WRONG, cnt and xfer are both signed. ... -Matt From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 17:40:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67EB01065670 for ; Mon, 10 Aug 2009 17:40:12 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id BB8688FC39 for ; Mon, 10 Aug 2009 17:40:11 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7AGefuA094772 for ; Mon, 10 Aug 2009 18:40:41 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7AGeebP090339 for ; Mon, 10 Aug 2009 18:40:40 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7AGeerY090336; Mon, 10 Aug 2009 18:40:40 +0200 (CEST) (envelope-from arno) To: current@freebsd.org From: "Arno J. Klaassen" Date: Mon, 10 Aug 2009 18:40:39 +0200 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9673/Mon Aug 10 17:32:31 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A804D89.00A by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A804D89.00A/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: Subject: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:40:12 -0000 Hello, I get the following panic when pxebooting a 8.0-BETA2 on a VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable and I defined CPUTYPE?=pentiumpro in make.conf. Let me know what I can provide more as info to get around this. Thanks in advance. Best, Arno ##### OK boot -sv KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009f800 SMAP type=02 base=000000000009f800 len=0000000000000800 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=01 base=0000000000100000 len=000000007bde0000 SMAP type=04 base=000000007bee0000 len=0000000000003000 SMAP type=03 base=000000007bee3000 len=000000000000d000 SMAP type=02 base=000000007bef0000 len=0000000000010000 SMAP type=02 base=00000000e0000000 len=0000000010000000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 Copyright (c) 1992-2009 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 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc4c00000 MEMGUARD map limit: 0xc6c01000 MEMGUARD map size: 33558528 (Bytes) Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 999896638 Hz CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 Features=0xa7c9bbff Features2=0x4181 VIA Padlock Features=0xffcc real memory = 2079195136 (1982 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) avail memory = 2027855872 (1933 MB) Table 'FACP' at 0x7bee3080 Table 'MCFG' at 0x7bee6ec0 Table 'APIC' at 0x7bee6e40 MADT: Found table at 0x7bee6e40 MP Configuration Table version 1.4 found at 0xc00f1ce0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 bios32: Found BIOS32 Service Directory header at 0xc00f8f70 bios32: Entry = 0xf9580 (c00f9580) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x95d0 pnpbios: Found PnP BIOS data at 0xc00fa110 pnpbios: Entry = f0000:a140 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) ACPI: RSDT 0x7bee3000 00030 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) ACPI: FACP 0x7bee3080 00074 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 AWRDACPI 00001000 MSFT 03000000) ACPI: FACS 0x7bee0000 00040 ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) ACPI: APIC 0x7bee6e40 00066 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 null: nfslock: pseudo-device random: io: kbd: new array size 4 kbd1 at kbdmux0 mem: npx0: INT 16 interface acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 3.00 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4b9c000 pa 0x1000 AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7bde0000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 Validation 0 10 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 Validation 0 11 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 Validation 0 7 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 Validation 0 255 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 Validation 0 11 N 0 3 4 6 7 10 11 12 After Disable 0 255 N 0 3 4 6 7 10 11 12 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1106, dev=0x0353, revid=0x11 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x1353, revid=0x00 domain=0, bus=0, slot=0, func=1 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x2353, revid=0x00 domain=0, bus=0, slot=0, func=2 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x3353, revid=0x00 domain=0, bus=0, slot=0, func=3 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x4353, revid=0x00 domain=0, bus=0, slot=0, func=4 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x5353, revid=0x00 domain=0, bus=0, slot=0, func=5 class=08-00-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x6353, revid=0x00 domain=0, bus=0, slot=0, func=6 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x7353, revid=0x00 domain=0, bus=0, slot=0, func=7 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x1122, revid=0x11 domain=0, bus=0, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled map[14]: type Memory, range 32, base 0xde000000, size 24, enabled map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x1106, dev=0xc353, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 27 found-> vendor=0x1106, dev=0xe353, revid=0x00 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 31 found-> vendor=0x1106, dev=0xf353, revid=0x00 domain=0, bus=0, slot=3, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit, vector masks pcib0: matched entry for 0.3.INTB pcib0: slot 3 INTB hardwired to IRQ 39 found-> vendor=0x1106, dev=0x5324, revid=0x00 domain=0, bus=0, slot=15, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled found-> vendor=0x1106, dev=0x3038, revid=0xa0 domain=0, bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf800, size 5, enabled pcib0: matched entry for 0.16.INTA pcib0: slot 16 INTA hardwired to IRQ 20 found-> vendor=0x1106, dev=0x3038, revid=0xa0 domain=0, bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf400, size 5, enabled pcib0: matched entry for 0.16.INTB pcib0: slot 16 INTB hardwired to IRQ 22 found-> vendor=0x1106, dev=0x3038, revid=0xa0 domain=0, bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled pcib0: matched entry for 0.16.INTC pcib0: slot 16 INTC hardwired to IRQ 21 found-> vendor=0x1106, dev=0x3104, revid=0x90 domain=0, bus=0, slot=16, func=4 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xdffff000, size 8, enabled pcib0: matched entry for 0.16.INTD pcib0: slot 16 INTD hardwired to IRQ 23 found-> vendor=0x1106, dev=0x8353, revid=0x00 domain=0, bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xa353, revid=0x00 domain=0, bus=0, slot=17, func=7 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0xb353, revid=0x00 domain=0, bus=0, slot=19, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x3288, revid=0x10 domain=0, bus=0, slot=20, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 17 NMI ISA 3c, EISA 0 NMI ... going to debugger [thread pid 0 tid 100000 ] Stopped at 0xc060098f = vsscanf+0x98f: movl %edx,0xfffffe8c(%ebp) db> ps pid ppid pgrp uid state wmesg wchan cmd 5 0 0 0 RL [xpt_thrd] 4 0 0 0 RL [g_down] 3 0 0 0 RL [g_up] 2 0 0 0 RL [g_event] 12 0 0 0 WL (threaded) intr 100021 I [irq9: acpi0] 100016 I [swi2: cambio] 100014 I [swi6: task queue] 100013 I [swi6: Giant taskq] 100011 I [swi5: +] 100006 I [swi1: netisr 0] 100005 I [swi4: clock] 100004 I [swi3: vm] 11 0 0 0 RL [idle: cpu0] 1 0 0 0 ?L [kernel] 10 0 0 0 RL [audit] 0 0 0 0 RLs (threaded) kernel 100020 RunQ [acpi_task_2] 100019 RunQ [acpi_task_1] 100018 RunQ [acpi_task_0] 100017 RunQ [kqueue taskq] 100012 RunQ [thread taskq] 100010 RunQ [firmware taskq] 100000 Run CPU 0 [swapper] db> where Tracing pid 0 tid 100000 td 0xc0934590 vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc mi_startup() at 0xc05839d6 = mi_startup+0xa6 begin() at 0xc0453005 = begin+0x2c db> From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 17:52:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC2841065673 for ; Mon, 10 Aug 2009 17:52:28 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id C81028FC33 for ; Mon, 10 Aug 2009 17:52:28 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 23D17B15FD; Mon, 10 Aug 2009 10:52:29 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id DED852D6017; Mon, 10 Aug 2009 10:52:27 -0700 (PDT) Message-ID: <4A805E5B.5000103@elischer.org> Date: Mon, 10 Aug 2009 10:52:27 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> In-Reply-To: <20090810133111.C93661@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeff Roberson , lstewart@FreeBSD.org, freebsd-current@freebsd.org, kib@FreeBSD.org, Navdeep Parhar , Larry Rosenman , Robert Watson Subject: Re: reproducible panic in netisr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:52:29 -0000 Bjoern A. Zeeb wrote: > > Looking further at the problem you may have already noticed that > the section for the 'master copy' starts at 0xffffffff8168f900 > and that the __start_set_pcpu is outside of that section at > 0xffffffff8168f8e9. > Looking at a section dump from `readelf -S kernel` you would > notice that the __start_set_pcpu directly follows the end of the > previous section. > > The reasons for this are twofold: > (1) ld places the __start_ symbol at '.' (the location counter), > which at that point is at the end of the old section as the new > (set_pcpu) is not yet added with __start_set_pcpu = ALIGN(0). > (2) because we manually define the section, so that it is > writeable, ld at the point of writing the __start_ symbol does > not yet have any possible section alignment information. That > is the reason for the ALIGN(0) in (1). > > An expected behaviour would be for ld to put the *ABS* at the > address where the section begins, once known or fixup the address. > This could arguably be a bug in ld we should fix post-8.0. This is getting closer to the root cause, and thus closer to the "root fix". > > One possible workaround would be to force the __start_ symbol > and the section to be equally aligned and thus on the same address > using linker scripts. The drawbacks are that we need to touch > the fragile linker scripts for each of the sections we add and > for all architectures individually. As the enforcement of alignment > would be at a different place to the actual set creation, putting > the alignment in might be easily forgotten. personally I'd see if there is a way to align the section on a page boundary.. > The advantage would be that we can always be sure that __start_ > would be on the same address where the section starts. that sounds like the preferable answer to me. > > Another solution is to put minimum alignment on the objects inside the > section in a way that it is only in a single place in the source code. > The section directive in the respective header file, that will > be included by each implementation file, is the ideal place for this. > While cache line alignment seems to be the widest alignment > restriction currently in use, one drawback, like with above ldscript > solution, is that a symbol could possibly enforce a wider alignment > restriction onto the section making the __start_ symbol and the > section beginning to diverge again. Example: > 0xffffffff8168f700 __start_set_pcpu > 0xffffffff8168f800 set_pcpu > 0xffffffff8168f800 pcpu_entry_sched_switch_stats > .. > if we would put an alignment of 1024 on pcpu_entry_sched_switch_stats. > This is unlikely to happen. > > With the minimum alignment, ld, at the time of placing the > __start_ symbol, already knows about the section alignment > and will place it correctly on the section beginning doing: > __start_set_pcpu = ALIGN(CACHE_LINE_SHIFT) at ".". > > > Summary: The minimum alignment seems to be the least-intrusive > solution and is believed to work for the moment. In addition > documenting that the dpcpu and similar sections will not support > super-cache line alignment. > The long term solution would be to fix ld to DTRT. > > > ------------------------------------------------------------------------ > ! > ! Put minimum alignment on the dpcpu and vnet section so that ld > ! when adding the __start_ symbol knows the expected section alignment > ! and can place the __start_ symbol correctly. > ! > ! These sections will not support symbols with super-cache line alignment > ! requirements. > ! > ! See posting , 2009-08-10, to freebsd-current for full > ! details. > ! > ! Debugging and testing patches by: > ! Kamigishi Rei (spambox haruhiism.net), np, lstewart, jhb, > ! kib, rwatson > ! Tested by: Kamigishi Rei, lstewart > ! Reviewed by: kib > ! Approved by: ! Index: sys/sys/pcpu.h > =================================================================== > --- sys/sys/pcpu.h (revision 196086) > +++ sys/sys/pcpu.h (working copy) > @@ -56,12 +56,14 @@ > extern uintptr_t *__start_set_pcpu; > extern uintptr_t *__stop_set_pcpu; > > +__asm__( > #if defined(__arm__) > -__asm__(".section set_pcpu, \"aw\", %progbits"); > + ".section set_pcpu, \"aw\", %progbits\n" > #else > -__asm__(".section set_pcpu, \"aw\", @progbits"); > + ".section set_pcpu, \"aw\", @progbits\n" > #endif > -__asm__(".previous"); > + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" > + "\t.previous"); > > /* > * Array of dynamic pcpu base offsets. Indexed by id. > Index: sys/net/vnet.h > =================================================================== > --- sys/net/vnet.h (revision 196086) > +++ sys/net/vnet.h (working copy) > @@ -185,12 +185,14 @@ > * Virtual network stack memory allocator, which allows global > variables to > * be automatically instantiated for each network stack instance. > */ > +__asm__( > #if defined(__arm__) > -__asm__(".section " VNET_SETNAME ", \"aw\", %progbits"); > + ".section " VNET_SETNAME ", \"aw\", %progbits\n" > #else > -__asm__(".section " VNET_SETNAME ", \"aw\", @progbits"); > + ".section " VNET_SETNAME ", \"aw\", @progbits\n" > #endif I may be visually impaired but I'm not seeing a reason for the ifdef arm.. > -__asm__(".previous"); > + "\t.p2align " __XSTRING(CACHE_LINE_SHIFT) "\n" > + "\t.previous"); > > #define VNET_NAME(n) vnet_entry_##n > #define VNET > > ------------------------------------------------------------------------ > From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 18:02:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00EA2106566C; Mon, 10 Aug 2009 18:02:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C7B888FC31; Mon, 10 Aug 2009 18:02:10 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 60A7046B03; Mon, 10 Aug 2009 14:02:10 -0400 (EDT) Date: Mon, 10 Aug 2009 19:02:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4A805E5B.5000103@elischer.org> Message-ID: References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> <4A805E5B.5000103@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Jeff Roberson , "Bjoern A. Zeeb" , kib@FreeBSD.org, Navdeep Parhar , Larry Rosenman , lstewart@FreeBSD.org Subject: Re: reproducible panic in netisr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:02:11 -0000 On Mon, 10 Aug 2009, Julian Elischer wrote: >> One possible workaround would be to force the __start_ symbol and the >> section to be equally aligned and thus on the same address using linker >> scripts. The drawbacks are that we need to touch the fragile linker >> scripts for each of the sections we add and for all architectures >> individually. As the enforcement of alignment would be at a different >> place to the actual set creation, putting the alignment in might be easily >> forgotten. > > personally I'd see if there is a way to align the section on a page > boundary.. I'm not sure it matters for the master copy, but I believe some (if not all) architecture MD parts already allocate the per-CPU data areas as page-aligned, and we extend the master copy out to a page boundary. That said, it would be worth checking on a run-time kernel to make sure it works out that way in practice. In the future, we'll want the pages allocated to the DPCPU area to be local to the CPU from a NUMA perspective. >> --- sys/net/vnet.h (revision 196086) >> +++ sys/net/vnet.h (working copy) >> @@ -185,12 +185,14 @@ >> * Virtual network stack memory allocator, which allows global variables >> to >> * be automatically instantiated for each network stack instance. >> */ >> +__asm__( >> #if defined(__arm__) >> -__asm__(".section " VNET_SETNAME ", \"aw\", %progbits"); >> + ".section " VNET_SETNAME ", \"aw\", %progbits\n" >> #else >> -__asm__(".section " VNET_SETNAME ", \"aw\", @progbits"); >> + ".section " VNET_SETNAME ", \"aw\", @progbits\n" >> #endif > > I may be visually impaired but I'm not seeing a reason for the ifdef arm.. I stared at Jeff's original DPCPU code for a while before I saw it -- it's the "%" vs "@" difference. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 17:44:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77465106567A for ; Mon, 10 Aug 2009 17:44:52 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 263168FC3F for ; Mon, 10 Aug 2009 17:44:51 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MaYvS-0007mw-LD>; Mon, 10 Aug 2009 19:44:50 +0200 Received: from e178019231.adsl.alicedsl.de ([85.178.19.231] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MaYvS-0007vH-Ix>; Mon, 10 Aug 2009 19:44:50 +0200 Message-ID: <4A805C92.4060104@mail.zedat.fu-berlin.de> Date: Mon, 10 Aug 2009 19:44:50 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.22 (X11/20090723) MIME-Version: 1.0 To: Larry Rosenman References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.19.231 X-Mailman-Approved-At: Mon, 10 Aug 2009 18:07:01 +0000 Cc: lstewart@FreeBSD.org, freebsd-current@freebsd.org, kib@FreeBSD.org, Navdeep Parhar , Robert Watson Subject: Re: reproducible panic in netisr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 17:44:54 -0000 Larry Rosenman wrote: > On Mon, 10 Aug 2009, Bjoern A. Zeeb wrote: > [snip] >> >> You can fetch the following from .. as well: >> http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff > [snip] > > I applied this patch to my 2009/08/03 csup checkout, and ran my > bacula backup. The backup pre-patch would cause the netisr panic very > quickly. > > With the patch applied, it's on the second host, which is a good sign. > > Just trying to get feedback in. > > Please let me know if there is anything else I can supply to help with > this. > > LER > Great to hear this, I will test the patch as soon as possible. But it would be rather useful having the svn repository for stable/8 online as soon as possible. Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 18:29:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DD56106566B; Mon, 10 Aug 2009 18:29:35 +0000 (UTC) (envelope-from zec@icir.org) Received: from labs3.cc.fer.hr (labs3.cc.fer.hr [161.53.72.21]) by mx1.freebsd.org (Postfix) with ESMTP id 940148FC25; Mon, 10 Aug 2009 18:29:34 +0000 (UTC) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs3.cc.fer.hr (8.13.8+Sun/8.12.10) with ESMTP id n7AI2kQp017734; Mon, 10 Aug 2009 20:02:53 +0200 (CEST) Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 20:02:46 +0200 From: Marko Zec To: freebsd-current@freebsd.org Date: Mon, 10 Aug 2009 20:02:27 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908102002.27320.zec@icir.org> X-OriginalArrivalTime: 10 Aug 2009 18:02:46.0563 (UTC) FILETIME=[C408CF30:01CA19E4] Cc: "Arno J. Klaassen" , current@freebsd.org Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:29:35 -0000 On Monday 10 August 2009 18:40:39 Arno J. Klaassen wrote: > Hello, > > I get the following panic when pxebooting a 8.0-BETA2 on a > VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable > and I defined CPUTYPE?=pentiumpro in make.conf. > > Let me know what I can provide more as info to get around this. adding this line hint.apic.0.disabled="1" to /boot/device.hints should do the trick when booting BETA2 from a local disk, though I don't know whether and how would pxeboot load the device.hints file. Marko From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 18:29:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DD56106566B; Mon, 10 Aug 2009 18:29:35 +0000 (UTC) (envelope-from zec@icir.org) Received: from labs3.cc.fer.hr (labs3.cc.fer.hr [161.53.72.21]) by mx1.freebsd.org (Postfix) with ESMTP id 940148FC25; Mon, 10 Aug 2009 18:29:34 +0000 (UTC) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs3.cc.fer.hr (8.13.8+Sun/8.12.10) with ESMTP id n7AI2kQp017734; Mon, 10 Aug 2009 20:02:53 +0200 (CEST) Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 20:02:46 +0200 From: Marko Zec To: freebsd-current@freebsd.org Date: Mon, 10 Aug 2009 20:02:27 +0200 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908102002.27320.zec@icir.org> X-OriginalArrivalTime: 10 Aug 2009 18:02:46.0563 (UTC) FILETIME=[C408CF30:01CA19E4] Cc: "Arno J. Klaassen" , current@freebsd.org Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:29:35 -0000 On Monday 10 August 2009 18:40:39 Arno J. Klaassen wrote: > Hello, > > I get the following panic when pxebooting a 8.0-BETA2 on a > VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable > and I defined CPUTYPE?=pentiumpro in make.conf. > > Let me know what I can provide more as info to get around this. adding this line hint.apic.0.disabled="1" to /boot/device.hints should do the trick when booting BETA2 from a local disk, though I don't know whether and how would pxeboot load the device.hints file. Marko From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 18:55:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5938106566B; Mon, 10 Aug 2009 18:55:08 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 34F238FC21; Mon, 10 Aug 2009 18:55:08 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CF56541C713; Mon, 10 Aug 2009 20:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id dan2118ycF3Z; Mon, 10 Aug 2009 20:55:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id F1E1841C712; Mon, 10 Aug 2009 20:55:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 82DED4448EC; Mon, 10 Aug 2009 18:50:41 +0000 (UTC) Date: Mon, 10 Aug 2009 18:50:41 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Robert Watson In-Reply-To: Message-ID: <20090810181027.E93661@maildrop.int.zabbadoz.net> References: <20090804225806.GA54680@hub.freebsd.org> <20090805054115.O93661@maildrop.int.zabbadoz.net> <20090805063417.GA10969@doormat.home> <20090810133111.C93661@maildrop.int.zabbadoz.net> <4A805E5B.5000103@elischer.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: reproducible panic in netisr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 18:55:08 -0000 On Mon, 10 Aug 2009, Robert Watson wrote: > > On Mon, 10 Aug 2009, Julian Elischer wrote: > >>> One possible workaround would be to force the __start_ symbol and the >>> section to be equally aligned and thus on the same address using linker >>> scripts. The drawbacks are that we need to touch the fragile linker >>> scripts for each of the sections we add and for all architectures >>> individually. As the enforcement of alignment would be at a different >>> place to the actual set creation, putting the alignment in might be easily >>> forgotten. >> >> personally I'd see if there is a way to align the section on a page >> boundary.. > > I'm not sure it matters for the master copy, but I believe some (if not all) > architecture MD parts already allocate the per-CPU data areas as > page-aligned, and we extend the master copy out to a page boundary. That > said, it would be worth checking on a run-time kernel to make sure it works > out that way in practice. db> show dpcpu_off dpcpu_off[ 0] = 0x42b100 (+ DPCPU_START = 0xffffffff81002000: aligned) dpcpu_off[ 1] = 0xffffff807f44e100 (+ DPCPU_START = 0xffffff8000025000: aligned) dpcpu_off[ 2] = 0xffffff807f455100 (+ DPCPU_START = 0xffffff800002c000: aligned) dpcpu_off[ 3] = 0xffffff807f45c100 (+ DPCPU_START = 0xffffff8000033000: aligned) dpcpu_off[ 4] = 0xffffff807f463100 (+ DPCPU_START = 0xffffff800003a000: aligned) dpcpu_off[ 5] = 0xffffff807f46a100 (+ DPCPU_START = 0xffffff8000041000: aligned) dpcpu_off[ 6] = 0xffffff807f471100 (+ DPCPU_START = 0xffffff8000048000: aligned) dpcpu_off[ 7] = 0xffffff807f478100 (+ DPCPU_START = 0xffffff800004f000: aligned) Note: you don't have that ddb command. I added that last week to my kernel for debugging. But that's nothing I wouldn't have expected as we are using kmem_alloc() for dpcpu. The more intersting thing would be to see what malloc does for vnet, even if we are memeory multiple of page sizes. An updated show vnets gives: db> show vnets vnet = 0xffffff0005c4ab00 ... vnet_data_mem = 0xffffff8000b00000 vnet_data_base = 0xffffff807ff81f80 vnet = 0xffffff0005c278c0 ... vnet_data_mem = 0xffffff8000ab8000 vnet_data_base = 0xffffff807ff39f80 vnet = 0xffffff0001633dc0 ... vnet_data_mem = 0xffffff8000226000 vnet_data_base = 0xffffff807f6a7f80 So looking at vnet_data_mem this looks good as well:) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 19:39:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14639106566B for ; Mon, 10 Aug 2009 19:39:59 +0000 (UTC) (envelope-from rivanr@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 931C88FC1F for ; Mon, 10 Aug 2009 19:39:58 +0000 (UTC) Received: by bwz2 with SMTP id 2so2143218bwz.43 for ; Mon, 10 Aug 2009 12:39:57 -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 :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=tlYPnKvqquns4ojXwflja9EGbCc7ebA7XHMwpuwXrv8=; b=lJSG1V9HBX6UhCP+TQci/WEwO+c0z7YHMqHMhB8zWvrkmOYwRXxhf0y+pB6GKq7RZg 4SpICCG2S/ZPMR3REcpi0SZkKk7U3coewXRGADNUldSxtBHybTJpoiaUoOyKVEwUmoQM dH+RP+Vd0IrQwQ0kihQRzAHXK9IfjDlx+h5MY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=mYqK17e+co12uifOuFmy2/AQGP9Cved4JZbpSVPycxfPl28g1t1VlCzZEGPDKE8fSB V2s7x/Lq235fyu5p+X4tgrZDrlCb80/NowjAcJ0zjovrrpRlChT64YynkyaornavO3N3 d3SEOo2JhLUwIOt66B75oCiOKS3frkLpMdsUE= Received: by 10.204.118.133 with SMTP id v5mr6315483bkq.191.1249933197386; Mon, 10 Aug 2009 12:39:57 -0700 (PDT) Received: from azdaja.softwarehood.com ([95.180.33.218]) by mx.google.com with ESMTPS id d13sm7313904fka.2.2009.08.10.12.39.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 12:39:56 -0700 (PDT) Message-ID: <4A80778B.8090708@gmail.com> Date: Mon, 10 Aug 2009 21:39:55 +0200 From: Ivan Radovanovic User-Agent: Thunderbird 2.0.0.22 (X11/20090708) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 19:39:59 -0000 I just spotted one weird console bug - it is very easy to reproduce it - it seems if you pipe commands together output of one command has something with console settings (namely width of console) For example, if you start opera (it is convenient since process is in /usr/local... - long path), and then you want to check if opera is running with something like ps -axj | grep opera You will receive different results depending on width on console window (for example, for me no results on normal text mode console, in X it depends on width of console you are executing above command in). From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 19:43:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DF071065676 for ; Mon, 10 Aug 2009 19:43:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 22FAD8FC23 for ; Mon, 10 Aug 2009 19:43:25 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 377B169959; Mon, 10 Aug 2009 19:43:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n7AJhs3l050680; Mon, 10 Aug 2009 19:43:54 GMT (envelope-from phk@critter.freebsd.dk) To: Ivan Radovanovic From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 10 Aug 2009 21:39:55 +0200." <4A80778B.8090708@gmail.com> Date: Mon, 10 Aug 2009 19:43:54 +0000 Message-ID: <50679.1249933434@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 19:43:25 -0000 In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: >ps -axj | grep opera >You will receive different results depending on width on console window >(for example, for me no results on normal text mode console, in X it >depends on width of console you are executing above command in). See the -w option to ps -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 19:50:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5507B1065670 for ; Mon, 10 Aug 2009 19:50:27 +0000 (UTC) (envelope-from rivanr@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id D18308FC16 for ; Mon, 10 Aug 2009 19:50:26 +0000 (UTC) Received: by bwz2 with SMTP id 2so2148532bwz.43 for ; Mon, 10 Aug 2009 12:50:25 -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 :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=E+jI9bA1YKZPFP0cTZKPkiD7GgVioGmJP3geYiJimwM=; b=nI5cEZq+Y61hbh/onXlPiY6DG3WMIsWX8MRlLIPYCQO8CzL4jwZpVEgYH2QRLvcjjR 8ig8Aaxs1tBLSx2awFmX03Cq6YBKFGF12tDdmipIFYDLjUb+pRCBIY8iTs/z6Di2vG+f YkoQaUil3+b7c9ACd6kiCS9MYJaYG69iZ5pq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=TbbAZZsHaUemKzbttRruJa0q0n3ZJKyTpvoKGYDx7Eq6mK498V5aq0q31L5xr0IXLK GMtOlY6vWId3HKJLXIelK4wUcCbygSboqwUMklhlqBzI7MRuQI/xoa52AxwZGxQFrKbz 1+XpmvZCk5fx9hLVsvPYwMAllX+ByQLbMQ51Q= Received: by 10.204.115.73 with SMTP id h9mr2096632bkq.177.1249933825594; Mon, 10 Aug 2009 12:50:25 -0700 (PDT) Received: from azdaja.softwarehood.com ([95.180.33.218]) by mx.google.com with ESMTPS id 2sm7339876fks.3.2009.08.10.12.50.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 12:50:24 -0700 (PDT) Message-ID: <4A8079FF.1040007@gmail.com> Date: Mon, 10 Aug 2009 21:50:23 +0200 From: Ivan Radovanovic User-Agent: Thunderbird 2.0.0.22 (X11/20090708) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <50679.1249933434@critter.freebsd.dk> In-Reply-To: <50679.1249933434@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 19:50:27 -0000 Poul-Henning Kamp wrote: > In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: > > >> ps -axj | grep opera >> You will receive different results depending on width on console window >> (for example, for me no results on normal text mode console, in X it >> depends on width of console you are executing above command in). >> > > See the -w option to ps > > Thanks, anyway I find this behavior weird when redirecting or piping... From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 20:03:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1683106567A for ; Mon, 10 Aug 2009 20:03:40 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8DA5D8FC23 for ; Mon, 10 Aug 2009 20:03:40 +0000 (UTC) Received: (qmail 29907 invoked by uid 399); 10 Aug 2009 20:03:36 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Aug 2009 20:03:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A807D12.1000104@FreeBSD.org> Date: Mon, 10 Aug 2009 13:03:30 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: Ivan Radovanovic References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> In-Reply-To: <4A8079FF.1040007@gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:03:41 -0000 Ivan Radovanovic wrote: > Poul-Henning Kamp wrote: >> In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: >> >> >>> ps -axj | grep opera >>> You will receive different results depending on width on console >>> window (for example, for me no results on normal text mode console, >>> in X it depends on width of console you are executing above command in). >>> >> >> See the -w option to ps >> >> > > Thanks, anyway I find this behavior weird when redirecting or piping... And how does ps know when it's being redirected or piped? Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 20:15:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53C10106566C for ; Mon, 10 Aug 2009 20:15:24 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id EBB1F8FC23 for ; Mon, 10 Aug 2009 20:15:23 +0000 (UTC) Received: by yxe11 with SMTP id 11so4414547yxe.3 for ; Mon, 10 Aug 2009 13:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=UDmb2Jz2YXHTjNmPgeRFrp6GKUYxFiyfPQKxxlMwgLg=; b=AezFsHpTLGW744yH3aLwuGWjw3F7yCCEH/9Mkhyo1r3SdYuLllopzpDOCQZsntl1Lg Agl3RStFFM1XAfO+NN9sn9ovzA+1YgM2qKFEGlyED3HJtQ5mhIwvjt+VZoggI0b0c1I4 S7MC89D651E4UAQ8jJKIeFl2r1HHXqPsXv+g8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=d7TazbYciHBCMbm7RcKpY+gvsynQSUrTymhLCpjJ0cqysJ/AbwzE+XJLX/Sv5XaXvt 6R1EYw0Hd1kpQz4GnQGQWmAPN8tu3eP2brTrh+Zm+SOojBpcYlH3g3yM3+51NpimKkMl LC7XQbrTFXK9LN2zRGbDFWzcAOq2QQtl3QxTc= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.100.225.12 with SMTP id x12mr4142382ang.142.1249935322778; Mon, 10 Aug 2009 13:15:22 -0700 (PDT) In-Reply-To: <4A807D12.1000104@FreeBSD.org> References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> Date: Mon, 10 Aug 2009 16:15:21 -0400 X-Google-Sender-Auth: f4cfc4a1e86e51f9 Message-ID: From: Justin Hibbits To: Doug Barton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Radovanovic Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:15:24 -0000 On Mon, Aug 10, 2009 at 4:03 PM, Doug Barton wrote: > Ivan Radovanovic wrote: >> Poul-Henning Kamp wrote: >>> In message <4A80778B.8090708@gmail.com>, Ivan Radovanovic writes: >>> >>> >>>> ps -axj | grep opera >>>> You will receive different results depending on width on console >>>> window (for example, for me no results on normal text mode console, >>>> in X it depends on width of console you are executing above command in= ). >>>> >>> >>> See the -w option to ps >>> >>> >> >> Thanks, anyway I find this behavior weird when redirecting or piping... > > And how does ps know when it's being redirected or piped? > > > Doug > > -- > > =A0 =A0This .signature sanitized for your protection > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > ps could be modified to use isatty(3) to determine if stdout is a tty. Currently if any of the tty ioctls return -1 it assumes a failsafe of 79 column width. This may not be necessary, though, since from the man page, specifying '-w' multiple times will make it use as many columns as necessary. Perhaps this could be the default if not a tty. - Justin From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 20:18:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F20F41065672 for ; Mon, 10 Aug 2009 20:18:56 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 798F78FC3C for ; Mon, 10 Aug 2009 20:18:56 +0000 (UTC) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id n7AKItmr017779; Mon, 10 Aug 2009 21:18:55 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from host47.msm.che.vodafone ([212.183.140.18]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id n7AKImV8098128; Mon, 10 Aug 2009 21:18:48 +0100 (BST) (envelope-from rb@gid.co.uk) Message-Id: <37692697-D7DC-4963-B9D2-6793554D4E07@gid.co.uk> From: Bob Bishop To: Doug Barton In-Reply-To: <4A807D12.1000104@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 Aug 2009 21:18:40 +0100 References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> X-Mailer: Apple Mail (2.936) Cc: freebsd-current@freebsd.org, Ivan Radovanovic Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:18:57 -0000 Hi, On 10 Aug 2009, at 21:03, Doug Barton wrote: > And how does ps know when it's being redirected or piped? > > > Doug stat(2) its standard output? -- Bob Bishop rb@gid.co.uk From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 20:27:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4F7D1065672 for ; Mon, 10 Aug 2009 20:27:56 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 401528FC25 for ; Mon, 10 Aug 2009 20:27:56 +0000 (UTC) Received: (qmail 9258 invoked by uid 399); 10 Aug 2009 20:27:50 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Aug 2009 20:27:50 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A8082C0.2090200@FreeBSD.org> Date: Mon, 10 Aug 2009 13:27:44 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: Justin Hibbits References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Ivan Radovanovic Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:27:56 -0000 Justin Hibbits wrote: > ps could be modified to use isatty(3) to determine if stdout is a tty. Great, I look forward to your patch. :) Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 20:33:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98840106564A for ; Mon, 10 Aug 2009 20:33:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4D48FC20 for ; Mon, 10 Aug 2009 20:33:34 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id AA0AE6D41E; Mon, 10 Aug 2009 20:15:05 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8AB40844CC; Mon, 10 Aug 2009 22:15:05 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Ivan Radovanovic References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> Date: Mon, 10 Aug 2009 22:15:05 +0200 In-Reply-To: <4A8079FF.1040007@gmail.com> (Ivan Radovanovic's message of "Mon, 10 Aug 2009 21:50:23 +0200") Message-ID: <86r5vja0ja.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:33:35 -0000 Ivan Radovanovic writes: > Poul-Henning Kamp writes: > > Ivan Radovanovic writes: > > > ps -axj | grep opera > > > You will receive different results depending on width on console > > > window (for example, for me no results on normal text mode console, > > > in X it depends on width of console you are executing above command > > > in). > > See the -w option to ps > Thanks, anyway I find this behavior weird when redirecting or piping... It's definitely a bug; ps(1) should check isatty(). Please file a PR. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 20:36:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D44FA106564A for ; Mon, 10 Aug 2009 20:36:22 +0000 (UTC) (envelope-from rivanr@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0F68FC1A for ; Mon, 10 Aug 2009 20:36:21 +0000 (UTC) Received: by bwz2 with SMTP id 2so2170474bwz.43 for ; Mon, 10 Aug 2009 13:36:21 -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 :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9YhJJ6aTuv9GcKC2EzqiGNvduOOHeSBJcFM8sjlfmwM=; b=ESyudONTdDd4OkIKyG4z5v7QCV4+V73DqxWAnoq/sR4Jzc/37dVHps3sG6Xb1jZa4N BDtVL7lnTZSjbq4ffPIAEHy+xUylsafBj+0ymSwGGAfKQ7Uu1tlkZNRCDs279XSjThNk dHQh7muM0mnFiptd0mbFLSVJilouh0Wl87WJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Ox/UP4M2jr3LZZgQ+yy1B665iLMe5VPHwkha2Vn0WtPDUdfmT6+PpgaHcRks9z5iU+ oYF5uO0q75VQvqFpzJSMrcVwQPqIT6RSK8tMTjgTqH3JfdT4kYaWwX7fUUDvPwQnsNyH QclUiPQ5Lbv2yM6h7vyq7zbUGpjDpl2YivzZQ= Received: by 10.204.65.204 with SMTP id k12mr6395070bki.98.1249936581103; Mon, 10 Aug 2009 13:36:21 -0700 (PDT) Received: from azdaja.softwarehood.com ([95.180.33.218]) by mx.google.com with ESMTPS id 19sm7320818fkr.55.2009.08.10.13.36.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 13:36:20 -0700 (PDT) Message-ID: <4A8084C3.7090501@gmail.com> Date: Mon, 10 Aug 2009 22:36:19 +0200 From: Ivan Radovanovic User-Agent: Thunderbird 2.0.0.22 (X11/20090708) MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <86r5vja0ja.fsf@ds4.des.no> In-Reply-To: <86r5vja0ja.fsf@ds4.des.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 20:36:23 -0000 Dag-Erling Smørgrav wrote: > Ivan Radovanovic writes: > >> Poul-Henning Kamp writes: >> >>> Ivan Radovanovic writes: >>> >>>> ps -axj | grep opera >>>> You will receive different results depending on width on console >>>> window (for example, for me no results on normal text mode console, >>>> in X it depends on width of console you are executing above command >>>> in). >>>> >>> See the -w option to ps >>> >> Thanks, anyway I find this behavior weird when redirecting or piping... >> > > It's definitely a bug; ps(1) should check isatty(). Please file a PR. > > DES > PR submitted From owner-freebsd-current@FreeBSD.ORG Mon Aug 10 21:59:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F111C106564A for ; Mon, 10 Aug 2009 21:59:18 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 887328FC1A for ; Mon, 10 Aug 2009 21:59:17 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7ALxFGO050957 ; Mon, 10 Aug 2009 23:59:16 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7ALxEL7092805; Mon, 10 Aug 2009 23:59:14 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7ALxEQ9092802; Mon, 10 Aug 2009 23:59:14 +0200 (CEST) (envelope-from arno) To: Marko Zec From: "Arno J. Klaassen" References: <200908102002.27320.zec@icir.org> Date: Mon, 10 Aug 2009 23:59:14 +0200 In-Reply-To: <200908102002.27320.zec@icir.org> (Marko Zec's message of "Mon\, 10 Aug 2009 20\:02\:27 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9673/Mon Aug 10 17:32:31 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A809833.012 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A809833.012/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: current@freebsd.org Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 21:59:19 -0000 Marko Zec writes: > On Monday 10 August 2009 18:40:39 Arno J. Klaassen wrote: >> Hello, >> >> I get the following panic when pxebooting a 8.0-BETA2 on a >> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >> and I defined CPUTYPE?=pentiumpro in make.conf. >> >> Let me know what I can provide more as info to get around this. > > adding this line > > hint.apic.0.disabled="1" > > to /boot/device.hints should do the trick when booting BETA2 from a local > disk, though I don't know whether and how would pxeboot load the > device.hints file. yes, this works (in /boot/loader.conf). (though at first sight I completely ignore why, since the panic seems to be in sscanf() of a line in /boot/loader.conf or /boot/device.hints starting with "hint." and I certainly did not have any "hint.apic.*" line in it ) That said, it now panics a bit further (the 'xdr'-bug I vaguely remember from recent days? ) : Adjusted interface vge0 in_scrubprefix: deletion failed Shutdown interface vge1 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xf000e6fa fault code = supervisor read, page not present instruction pointer = 0x20:0xc07e060b stack pointer = 0x28:0xc0c20940 frame pointer = 0x28:0xc0c20990 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at 0xc07e060b = uma_zalloc_arg+0x7b: movswl 0x8(%edx),%eax db> where Tracing pid 0 tid 100000 td 0xc0934590 uma_zalloc_arg(0,0,101,c6dfec00,c060bfeb,...) at 0xc07e060b = uma_zalloc_arg+0x7b flowtable_lookup(c6eca000,c7008100,c0c20a74,8c,c0aa586c,...) at 0xc0673ffb = flowtable_lookup+0x49b ip_output(c7008100,0,0,0,0,...) at 0xc06abcfa = ip_output+0xea udp_send(c70a59a8,0,c7008300,c0aa870c,0,...) at 0xc0724198 = udp_send+0x8e8 sosend_dgram(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc063290f = sosend_dgram+0x35f sosend(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc062ff2f = sosend+0x3f krpc_call(c0aa870c,186a0,2,3,c0c20c60,...) at 0xc0757afe = krpc_call+0x2ce krpc_portmap(c0aa870c,186a5,3,c0aa870e,c0934590,...) at 0xc0757e46 = krpc_portmap+0xb6 bootpc_init(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc0757398 = bootpc_init+0x19a8 mi_startup() at 0xc05839d6 = mi_startup+0xa6 begin() at 0xc0453005 = begin+0x2c db> Merci & best, Arno From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 05:08:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C96DC106564A for ; Tue, 11 Aug 2009 05:08:43 +0000 (UTC) (envelope-from lei_du@yeah.net) Received: from m85-55.yeah.net (m85-55.yeah.net [60.191.85.55]) by mx1.freebsd.org (Postfix) with ESMTP id C91598FC40 for ; Tue, 11 Aug 2009 05:08:42 +0000 (UTC) Received: from lei_du ( [121.27.67.196] ) by ajax-webmail-app6 (Coremail) ; Tue, 11 Aug 2009 12:37:41 +0800 (CST) Date: Tue, 11 Aug 2009 12:37:41 +0800 (CST) From: lei_du To: freebsd-current@freebsd.org Message-ID: <1627335636.134231249965461840.JavaMail.coremail@app6.yeah.net> MIME-Version: 1.0 X-Originating-IP: [121.27.67.196] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2_snapshot build 090618(8092.2435.2417) Copyright (c) 2002-2009 www.mailtech.cn yeah X-CM-TRANSID: N1UQrKC7mwqW9YBKwMYtAA--.63394W X-CM-SenderInfo: pohlsv3x61vtnkoqv3/1tbiBBG6iEdys-4iQwABs- X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJTRUUUjikYjxAI6xCIbc kI1I0E57IF64kEYxAxMc804VCqF7xvr2I5M4IEnf9ElVAFpTB2q-sK649IAas0WaI_GwCS 07vEb7Iv0xC_Jr1lV2xY67kC6x804xWlV2xY67CY07I20VC2zVCF04k26cxKx2IYs7xG6r Wj6s0DMIAIbVAFxVCF77xC64kEw24lV2xY67C26IkvcIIF6IxKo4kEV4ylV2xY628EF7xv wVC0I7IYx2IY67AKxVWDJVCq3wCS07vE84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_GcCE3s 1lV2xY628EF7xvwVC2z280aVAFwI0_GcCE3s1lV2xY628EF7xvwVC2z280aVCY1x0267AK xVW0oVCq3wCS07vE5I8CrVACY4xI64kE6c02F40Ex7xfMIAIbVAqx4xG6xAqzxv2648Iw2 C25wCS07vEYx0E2Ix0cI8IcVAFwI0_JrI_JrylV2xY6cIj6I8E87Iv67AKxVWUJVW8JwCS 07vE7I0Y64k_MIAIbVCY1Ik26cxK6x8YrwCS07vEc2xSY4AK67AK6r45MIAIbVCY0x0Ix7 I2Y4AK64vIr41lV2xY6xCjnVCjjxCrMIAIbVC2zVAF1VAY17CE14v26r1j6r15MIAIbVCI 42IY6xAIw20EY4v20xvaj40_WFyUJVCq3bIYCTnIWIevJa73U Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Update 8.0beta2. Make kernel error. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 05:08:44 -0000 When I update 7.2->8.0. machine_arch is amd64 . make build kernel. Some files is missing. Just why? From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 05:11:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4C9A10656C4 for ; Tue, 11 Aug 2009 05:11:29 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by mx1.freebsd.org (Postfix) with ESMTP id BC1CB8FC16 for ; Tue, 11 Aug 2009 05:11:29 +0000 (UTC) Received: by rv-out-0506.google.com with SMTP id f9so1075260rvb.43 for ; Mon, 10 Aug 2009 22:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M+74fgFOiILSF0zb9azeYlXl75dtf1PLFvOqK8U4ijM=; b=MSewYXXsyAcL7oQ/gU0FpF/RmvUotisoI9z988/hfcHdUbKDsCQeG/67HKIBs2ZfJi 1KpraRQzdHpHSG5KR9gjPcnBkDJKAOb/IUw6V9nuZ8VPgZ1xDvwsscpAA9Wm7nIBrV5O ZeTFMQO6X09jNJcOu4xkNZT2i4QNbsPF1bLd8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s4K5F3HhYMgo9+eMVFimxewJm2UclYmCHp/dPWmaAfWQGKsz+Z3MoE+USa5k1eHqNO kI149xYLv1bGf4LyqrQofpHwsRldTFXgtNkhfeDhghhVwtzzUHJPesqZr0MeaLEnQOSt gymZBrjr2FTzvvNpG3uqQJpP4g6DsAFHqxIEQ= MIME-Version: 1.0 Received: by 10.142.245.17 with SMTP id s17mr440602wfh.316.1249967489269; Mon, 10 Aug 2009 22:11:29 -0700 (PDT) In-Reply-To: <1627335636.134231249965461840.JavaMail.coremail@app6.yeah.net> References: <1627335636.134231249965461840.JavaMail.coremail@app6.yeah.net> Date: Tue, 11 Aug 2009 12:11:29 +0700 Message-ID: From: Edho P Arief To: lei_du Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Update 8.0beta2. Make kernel error. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 05:11:30 -0000 2009/8/11 lei_du : > > When I update 7.2->8.0. machine_arch is amd64 . > make build kernel. Some files is missing. > Just why? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > you forgot to paste build log -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 12:46:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1D74106566B for ; Tue, 11 Aug 2009 12:46:10 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id B7F318FC41 for ; Tue, 11 Aug 2009 12:46:10 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Maqjw-00016Y-PS; Tue, 11 Aug 2009 12:46:08 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 5FFAD2938C4F; Tue, 11 Aug 2009 21:46:08 +0900 (JST) Date: Tue, 11 Aug 2009 21:46:08 +0900 From: Randy Bush To: Ed Schouten In-Reply-To: <24477244.post@talk.nabble.com> References: <24477244.post@talk.nabble.com> Message-ID: <20090714105429.GL48776@hoeg.nl> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD current mailing list Subject: Re: Build error "am_ET.UTF-8.out: Inappropriate ioctl for device" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 12:46:11 -0000 in today's current, i have this much discussed problem while building on FreeBSD ran.psg.com 8.0-BETA1 FreeBSD 8.0-BETA1 #5: Mon Jul 13 06:42:59 UTC 2009 root@ran.psg.com:/usr/obj/usr/src/sys/RAN i386 is there a hack out of the corner? randy From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 13:05:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0C0D1065675; Tue, 11 Aug 2009 13:05:35 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from baranao.anywi.com (baranao.anywi.com [213.207.101.176]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4E58FC20; Tue, 11 Aug 2009 13:05:35 +0000 (UTC) Received: from hind.van-laarhoven.org (ip51cfcfde.direct-adsl.nl [81.207.207.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by baranao.anywi.com (Postfix) with ESMTPSA id 9858A3F41C; Tue, 11 Aug 2009 14:49:57 +0200 (CEST) From: Nick Hibma To: freebsd-embedded@freebsd.org Date: Tue, 11 Aug 2009 14:49:51 +0200 User-Agent: KMail/1.11.4 (FreeBSD/7.2-STABLE; KDE/4.2.4; i386; ; ) References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> In-Reply-To: <20090807205817.GA82868@psconsult.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908111449.51779.nick@van-laarhoven.org> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, UNPARSEABLE_RELAY autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on baranao.anywi.com Cc: freebsd-current@freebsd.org, Paul Schenkeveld Subject: Re: [NanoBSD] Can't use boot0cfg for changing the booting slice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 13:05:36 -0000 > > : > But, after the reboot my system still reboot from the slice 1 (but > > : > the boot loader show correctly that the default choice is now the > > : > 2)! Where is my problem ? > > : > > : Are you sure you're booting from slice 1? > > : Is fstab on slice 2 pointing to slice 1? > > > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was > > the last slice you booted from... To mark it active, you must use > > fdisk. If by 'active' you mean 'what mount reports root as' then I > > think John's suggestion is right on the money... Perhaps you could change the line in the update script from boot0cfg -s $oslice $NANO_DRIVE to boot0cfg -s $oslice $NANO_DRIVE echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE That's taken from our own version of the update script, but should fit in the NanoBSD update script. Nick From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 14:24:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 747B7106564A; Tue, 11 Aug 2009 14:24:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4CB988FC3F; Tue, 11 Aug 2009 14:24:02 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 004FB46B35; Tue, 11 Aug 2009 10:24:01 -0400 (EDT) Date: Tue, 11 Aug 2009 15:24:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Arno J. Klaassen" In-Reply-To: Message-ID: References: <200908102002.27320.zec@icir.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marko Zec , current@freebsd.org, kmacy@FreeBSD.org Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 14:24:02 -0000 On Mon, 10 Aug 2009, Arno J. Klaassen wrote: > That said, it now panics a bit further (the 'xdr'-bug I vaguely > remember from recent days? ) : This is actually believed to be a flowtable bug, and has been spotted by a few people. I think Kip is circulating a bug fix for it. There's not yet a patch in the re@ queue for it. > > Adjusted interface vge0 > in_scrubprefix: deletion failed > Shutdown interface vge1 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xf000e6fa > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc07e060b > stack pointer = 0x28:0xc0c20940 > frame pointer = 0x28:0xc0c20990 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 100000 ] > Stopped at 0xc07e060b = uma_zalloc_arg+0x7b: movswl > 0x8(%edx),%eax > db> where > Tracing pid 0 tid 100000 td 0xc0934590 > uma_zalloc_arg(0,0,101,c6dfec00,c060bfeb,...) at 0xc07e060b = > uma_zalloc_arg+0x7b > flowtable_lookup(c6eca000,c7008100,c0c20a74,8c,c0aa586c,...) at > 0xc0673ffb = flowtable_lookup+0x49b > ip_output(c7008100,0,0,0,0,...) at 0xc06abcfa = ip_output+0xea > udp_send(c70a59a8,0,c7008300,c0aa870c,0,...) at 0xc0724198 = > udp_send+0x8e8 > sosend_dgram(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc063290f = > sosend_dgram+0x35f > sosend(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc062ff2f = sosend+0x3f > krpc_call(c0aa870c,186a0,2,3,c0c20c60,...) at 0xc0757afe = > krpc_call+0x2ce > krpc_portmap(c0aa870c,186a5,3,c0aa870e,c0934590,...) at 0xc0757e46 = > krpc_portmap+0xb6 > bootpc_init(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc0757398 = > bootpc_init+0x19a8 > mi_startup() at 0xc05839d6 = mi_startup+0xa6 > begin() at 0xc0453005 = begin+0x2c > db> > > > Merci & best, > > Arno > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 14:40:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62CCA10656C2 for ; Tue, 11 Aug 2009 14:40:25 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 0DED08FC40 for ; Tue, 11 Aug 2009 14:40:24 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7BEeM0O021360 ; Tue, 11 Aug 2009 16:40:22 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7BEeLuV099946; Tue, 11 Aug 2009 16:40:21 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7BEeKb1099943; Tue, 11 Aug 2009 16:40:20 +0200 (CEST) (envelope-from arno) To: Robert Watson From: "Arno J. Klaassen" References: <200908102002.27320.zec@icir.org> Date: Tue, 11 Aug 2009 16:40:20 +0200 In-Reply-To: (Robert Watson's message of "Tue\, 11 Aug 2009 15\:24\:01 +0100 \(BST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9677/Tue Aug 11 15:25:47 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A8182D6.00C by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A8182D6.00C/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: Marko Zec , current@freebsd.org, kmacy@freebsd.org Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 14:40:26 -0000 Robert Watson writes: > On Mon, 10 Aug 2009, Arno J. Klaassen wrote: > >> That said, it now panics a bit further (the 'xdr'-bug I vaguely >> remember from recent days? ) : > > This is actually believed to be a flowtable bug, and has been spotted > by a few people. I think Kip is circulating a bug fix for it. > There's not yet a patch in the re@ queue for it. OK, feel free to provide me with a pointer to Kip's fix and I'll be glad to test it (I was positively surpised that this C7 board, small as it is, still has a plain RS232, which makes providing you with debug info fairly easy). Thanx, best regards, Arno >> >> Adjusted interface vge0 >> in_scrubprefix: deletion failed >> Shutdown interface vge1 >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0xf000e6fa >> fault code = supervisor read, page not present >> instruction pointer = 0x20:0xc07e060b >> stack pointer = 0x28:0xc0c20940 >> frame pointer = 0x28:0xc0c20990 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 0 (swapper) >> [thread pid 0 tid 100000 ] >> Stopped at 0xc07e060b = uma_zalloc_arg+0x7b: movswl >> 0x8(%edx),%eax >> db> where >> Tracing pid 0 tid 100000 td 0xc0934590 >> uma_zalloc_arg(0,0,101,c6dfec00,c060bfeb,...) at 0xc07e060b = >> uma_zalloc_arg+0x7b >> flowtable_lookup(c6eca000,c7008100,c0c20a74,8c,c0aa586c,...) at >> 0xc0673ffb = flowtable_lookup+0x49b >> ip_output(c7008100,0,0,0,0,...) at 0xc06abcfa = ip_output+0xea >> udp_send(c70a59a8,0,c7008300,c0aa870c,0,...) at 0xc0724198 = >> udp_send+0x8e8 >> sosend_dgram(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc063290f = >> sosend_dgram+0x35f >> sosend(c70a59a8,c0aa870c,0,c7008300,0,...) at 0xc062ff2f = sosend+0x3f >> krpc_call(c0aa870c,186a0,2,3,c0c20c60,...) at 0xc0757afe = >> krpc_call+0x2ce >> krpc_portmap(c0aa870c,186a5,3,c0aa870e,c0934590,...) at 0xc0757e46 = >> krpc_portmap+0xb6 >> bootpc_init(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc0757398 = >> bootpc_init+0x19a8 >> mi_startup() at 0xc05839d6 = mi_startup+0xa6 >> begin() at 0xc0453005 = begin+0x2c >> db> From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 15:11:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55BB1106566B; Tue, 11 Aug 2009 15:11:20 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id E85168FC50; Tue, 11 Aug 2009 15:11:19 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id D67011CD3E; Tue, 11 Aug 2009 17:11:18 +0200 (CEST) Date: Tue, 11 Aug 2009 17:11:18 +0200 From: Ed Schouten To: Bob Bishop Message-ID: <20090811151118.GF1292@hoeg.nl> References: <50679.1249933434@critter.freebsd.dk> <4A8079FF.1040007@gmail.com> <4A807D12.1000104@FreeBSD.org> <37692697-D7DC-4963-B9D2-6793554D4E07@gid.co.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GWLvvOwKrQC9aCO6" Content-Disposition: inline In-Reply-To: <37692697-D7DC-4963-B9D2-6793554D4E07@gid.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Ivan Radovanovic , Doug Barton , freebsd-current@freebsd.org Subject: Re: Weird console bug X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:11:20 -0000 --GWLvvOwKrQC9aCO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Bob Bishop wrote: > stat(2) its standard output? It is likely that very old versions of isatty(3) called fstat(2) and looked at st_rdev to determine whether it was a TTY. This is indeed to how various related functions like ptsname(3) worked. Nowadays stuff is implemented as follows: - isatty(3) just calls tcgetattr(3), which uses TIOCGETA. - ttyname(3) first calls isatty(3) and then fdevname(), which uses FIODGNAME. - ptsname(3) first uses TIOCPTMASTER to see whether the file descriptor is a pseudo-terminal master and then fdevname(). Which is nice, because everything goes by name and not by device number. For example, ptsname(3) on Linux generates the name by looking at the major/minor number. --=20 Ed Schouten WWW: http://80386.nl/ --GWLvvOwKrQC9aCO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqBihYACgkQ52SDGA2eCwX+ZQCcDMB1Xjlw2pnCZr6ENTDiK4c1 i20An2qup+tJvccDseMVqcToz/8Vl+iJ =8lhz -----END PGP SIGNATURE----- --GWLvvOwKrQC9aCO6-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 15:25:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 236591065672 for ; Tue, 11 Aug 2009 15:25:40 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 84C3E8FC42 for ; Tue, 11 Aug 2009 15:25:39 +0000 (UTC) Received: from [192.168.1.4] (adsl-157-61-83.bna.bellsouth.net [70.157.61.83]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n7BFPZ6p071432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 11:25:36 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: "Arno J. Klaassen" In-Reply-To: References: Content-Type: multipart/mixed; boundary="=-ric05y6WgNc2Qvs4wLsT" Organization: FreeBSD Date: Tue, 11 Aug 2009 10:25:30 -0500 Message-Id: <1250004330.1773.223.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: current@freebsd.org Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:25:42 -0000 --=-ric05y6WgNc2Qvs4wLsT Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: > Hello, > > I get the following panic when pxebooting a 8.0-BETA2 on a > VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable > and I defined CPUTYPE?=pentiumpro in make.conf. > > Let me know what I can provide more as info to get around this. I've seen this as well. You can disable apic which I see has been suggested. The NMI seems to be generated by HWPMC_HOOKS, in my case removing it from the GENERIC config allows it to boot and use apic. I'm not certain what the correct fix is, but after talking to jkoshy@ we did find the specific point in the HWPMC_HOOKS code that triggers this, which can be disabled by testing for CPU_VENDOR_CENTAUR. The attached hack should get things booting... robert. > Thanks in advance. > > Best, Arno > > > > ##### > > OK boot -sv > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=000000000009f800 > SMAP type=02 base=000000000009f800 len=0000000000000800 > SMAP type=02 base=00000000000f0000 len=0000000000010000 > SMAP type=01 base=0000000000100000 len=000000007bde0000 > SMAP type=04 base=000000007bee0000 len=0000000000003000 > SMAP type=03 base=000000007bee3000 len=000000000000d000 > SMAP type=02 base=000000007bef0000 len=0000000000010000 > SMAP type=02 base=00000000e0000000 len=0000000010000000 > SMAP type=02 base=00000000fec00000 len=0000000000001000 > SMAP type=02 base=00000000fee00000 len=0000000000001000 > SMAP type=02 base=00000000ffff0000 len=0000000000010000 > Copyright (c) 1992-2009 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 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 > toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: > MEMGUARD map base: 0xc4c00000 > MEMGUARD map limit: 0xc6c01000 > MEMGUARD map size: 33558528 (Bytes) > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 999896638 Hz > CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) > Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 > Features=0xa7c9bbff > Features2=0x4181 > VIA Padlock Features=0xffcc > real memory = 2079195136 (1982 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) > avail memory = 2027855872 (1933 MB) > Table 'FACP' at 0x7bee3080 > Table 'MCFG' at 0x7bee6ec0 > Table 'APIC' at 0x7bee6e40 > MADT: Found table at 0x7bee6e40 > MP Configuration Table version 1.4 found at 0xc00f1ce0 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > ACPI APIC Table: > APIC: CPU 0 has ACPI ID 0 > bios32: Found BIOS32 Service Directory header at 0xc00f8f70 > bios32: Entry = 0xf9580 (c00f9580) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0x95d0 > pnpbios: Found PnP BIOS data at 0xc00fa110 > pnpbios: Entry = f0000:a140 Rev = 1.0 > Other BIOS signatures found: > ULE: setup cpu 0 > ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) > ACPI: RSDT 0x7bee3000 00030 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > ACPI: FACP 0x7bee3080 00074 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 AWRDACPI 00001000 MSFT 03000000) > ACPI: FACS 0x7bee0000 00040 > ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > ACPI: APIC 0x7bee6e40 00066 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 9, irq 9 > ioapic0: intpin 9 trigger: level > ioapic0: intpin 9 polarity: low > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > null: > nfslock: pseudo-device > random: > io: > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > npx0: INT 16 interface > acpi0: on motherboard > PCIe: Memory Mapped configuration base @ 0xe0000000 > pcibios: BIOS version 3.00 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xc4b9c000 pa 0x1000 > AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 > AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 > AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 > AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 > AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 > AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7bde0000 (3) failed > ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 6 7 10 11 12 > Validation 0 10 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 > Validation 0 11 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 7 N 0 3 4 6 7 10 11 12 > Validation 0 7 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 6 7 10 11 12 > Validation 0 255 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 6 7 10 11 12 > Validation 0 11 N 0 3 4 6 7 10 11 12 > After Disable 0 255 N 0 3 4 6 7 10 11 12 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x1106, dev=0x0353, revid=0x11 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x1353, revid=0x00 > domain=0, bus=0, slot=0, func=1 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x2353, revid=0x00 > domain=0, bus=0, slot=0, func=2 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x3353, revid=0x00 > domain=0, bus=0, slot=0, func=3 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x4353, revid=0x00 > domain=0, bus=0, slot=0, func=4 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x5353, revid=0x00 > domain=0, bus=0, slot=0, func=5 > class=08-00-20, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x6353, revid=0x00 > domain=0, bus=0, slot=0, func=6 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x7353, revid=0x00 > domain=0, bus=0, slot=0, func=7 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x1122, revid=0x11 > domain=0, bus=0, slot=1, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > MSI supports 1 message > map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled > map[14]: type Memory, range 32, base 0xde000000, size 24, enabled > map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled > pcib0: matched entry for 0.1.INTA > pcib0: slot 1 INTA hardwired to IRQ 16 > found-> vendor=0x1106, dev=0xc353, revid=0x00 > domain=0, bus=0, slot=2, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit, vector masks > pcib0: matched entry for 0.2.INTA > pcib0: slot 2 INTA hardwired to IRQ 27 > found-> vendor=0x1106, dev=0xe353, revid=0x00 > domain=0, bus=0, slot=3, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit, vector masks > pcib0: matched entry for 0.3.INTA > pcib0: slot 3 INTA hardwired to IRQ 31 > found-> vendor=0x1106, dev=0xf353, revid=0x00 > domain=0, bus=0, slot=3, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit, vector masks > pcib0: matched entry for 0.3.INTB > pcib0: slot 3 INTB hardwired to IRQ 39 > found-> vendor=0x1106, dev=0x5324, revid=0x00 > domain=0, bus=0, slot=15, func=0 > class=01-01-8a, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled > found-> vendor=0x1106, dev=0x3038, revid=0xa0 > domain=0, bus=0, slot=16, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf800, size 5, enabled > pcib0: matched entry for 0.16.INTA > pcib0: slot 16 INTA hardwired to IRQ 20 > found-> vendor=0x1106, dev=0x3038, revid=0xa0 > domain=0, bus=0, slot=16, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf400, size 5, enabled > pcib0: matched entry for 0.16.INTB > pcib0: slot 16 INTB hardwired to IRQ 22 > found-> vendor=0x1106, dev=0x3038, revid=0xa0 > domain=0, bus=0, slot=16, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=7 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled > pcib0: matched entry for 0.16.INTC > pcib0: slot 16 INTC hardwired to IRQ 21 > found-> vendor=0x1106, dev=0x3104, revid=0x90 > domain=0, bus=0, slot=16, func=4 > class=0c-03-20, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=d, irq=5 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xdffff000, size 8, enabled > pcib0: matched entry for 0.16.INTD > pcib0: slot 16 INTD hardwired to IRQ 23 > found-> vendor=0x1106, dev=0x8353, revid=0x00 > domain=0, bus=0, slot=17, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > found-> vendor=0x1106, dev=0xa353, revid=0x00 > domain=0, bus=0, slot=17, func=7 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0xb353, revid=0x00 > domain=0, bus=0, slot=19, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1106, dev=0x3288, revid=0x10 > domain=0, bus=0, slot=20, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled > pcib0: matched entry for 0.20.INTA > pcib0: slot 20 INTA hardwired to IRQ 17 > NMI ISA 3c, EISA 0 > NMI ... going to debugger > [thread pid 0 tid 100000 ] > Stopped at 0xc060098f = vsscanf+0x98f: movl %edx,0xfffffe8c(%ebp) > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 5 0 0 0 RL [xpt_thrd] > 4 0 0 0 RL [g_down] > 3 0 0 0 RL [g_up] > 2 0 0 0 RL [g_event] > 12 0 0 0 WL (threaded) intr > 100021 I [irq9: acpi0] > 100016 I [swi2: cambio] > 100014 I [swi6: task queue] > 100013 I [swi6: Giant taskq] > 100011 I [swi5: +] > 100006 I [swi1: netisr 0] > 100005 I [swi4: clock] > 100004 I [swi3: vm] > 11 0 0 0 RL [idle: cpu0] > 1 0 0 0 ?L [kernel] > 10 0 0 0 RL [audit] > 0 0 0 0 RLs (threaded) kernel > 100020 RunQ [acpi_task_2] > 100019 RunQ [acpi_task_1] > 100018 RunQ [acpi_task_0] > 100017 RunQ [kqueue taskq] > 100012 RunQ [thread taskq] > 100010 RunQ [firmware taskq] > 100000 Run CPU 0 [swapper] > db> where > Tracing pid 0 tid 100000 td 0xc0934590 > vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f > sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 > res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 > resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a > resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 > devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e > device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f > device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb > device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 > device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 > bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 > acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c > device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 > acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 > acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 > device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 > acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe > device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 > nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e > device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 > device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 > bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd > bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 > root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 > configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc > mi_startup() at 0xc05839d6 = mi_startup+0xa6 > begin() at 0xc0453005 = begin+0x2c > db> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD --=-ric05y6WgNc2Qvs4wLsT Content-Disposition: attachment; filename="via_pmc_hack.patch" Content-Type: text/x-patch; name="via_pmc_hack.patch"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: i386/i386/local_apic.c =================================================================== --- i386/i386/local_apic.c (revision 196050) +++ i386/i386/local_apic.c (working copy) @@ -309,7 +309,7 @@ lapic_setup(int boot) #ifdef HWPMC_HOOKS /* Program the PMC LVT entry if present. */ - if (maxlvt >= LVT_PMC) + if (maxlvt >= LVT_PMC && cpu_vendor_id != CPU_VENDOR_CENTAUR) lapic->lvt_pcint = lvt_mode(la, LVT_PMC, lapic->lvt_pcint); #endif --=-ric05y6WgNc2Qvs4wLsT-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 16:27:09 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 899541065670 for ; Tue, 11 Aug 2009 16:27:09 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id BE5188FC48 for ; Tue, 11 Aug 2009 16:27:08 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7BGR6Sb047829 ; Tue, 11 Aug 2009 18:27:07 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7BGR6tD000895; Tue, 11 Aug 2009 18:27:06 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7BGR5PT000892; Tue, 11 Aug 2009 18:27:05 +0200 (CEST) (envelope-from arno) To: Robert Noland From: "Arno J. Klaassen" References: <1250004330.1773.223.camel@balrog.2hip.net> Date: Tue, 11 Aug 2009 18:27:05 +0200 In-Reply-To: <1250004330.1773.223.camel@balrog.2hip.net> (Robert Noland's message of "Tue\, 11 Aug 2009 10\:25\:30 -0500") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9677/Tue Aug 11 15:25:47 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A819BDA.01A by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A819BDA.01A/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: current@FreeBSD.org Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 16:27:09 -0000 Robert Noland writes: > On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >> Hello, >> >> I get the following panic when pxebooting a 8.0-BETA2 on a >> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >> and I defined CPUTYPE?=pentiumpro in make.conf. >> >> Let me know what I can provide more as info to get around this. > > I've seen this as well. You can disable apic which I see has been > suggested. The NMI seems to be generated by HWPMC_HOOKS, in my case > removing it from the GENERIC config allows it to boot and use apic. I'm > not certain what the correct fix is, but after talking to jkoshy@ we did > find the specific point in the HWPMC_HOOKS code that triggers this, > which can be disabled by testing for CPU_VENDOR_CENTAUR. > > The attached hack should get things booting... Correct. It now boots OK with apic enabled (but still panics at the 'flowtable bug'). Thanks. Arno > robert. > >> Thanks in advance. >> >> Best, Arno >> >> >> >> ##### >> >> OK boot -sv >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> SMAP type=01 base=0000000000000000 len=000000000009f800 >> SMAP type=02 base=000000000009f800 len=0000000000000800 >> SMAP type=02 base=00000000000f0000 len=0000000000010000 >> SMAP type=01 base=0000000000100000 len=000000007bde0000 >> SMAP type=04 base=000000007bee0000 len=0000000000003000 >> SMAP type=03 base=000000007bee3000 len=000000000000d000 >> SMAP type=02 base=000000007bef0000 len=0000000000010000 >> SMAP type=02 base=00000000e0000000 len=0000000010000000 >> SMAP type=02 base=00000000fec00000 len=0000000000001000 >> SMAP type=02 base=00000000fee00000 len=0000000000001000 >> SMAP type=02 base=00000000ffff0000 len=0000000000010000 >> Copyright (c) 1992-2009 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 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >> toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >> WARNING: WITNESS option enabled, expect reduced performance. >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >> MEMGUARD map base: 0xc4c00000 >> MEMGUARD map limit: 0xc6c01000 >> MEMGUARD map size: 33558528 (Bytes) >> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Calibrating TSC clock ... TSC clock: 999896638 Hz >> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >> Origin = "CentaurHauls" Id = 0x6d0 Stepping = 0 >> Features=0xa7c9bbff >> Features2=0x4181 >> VIA Padlock Features=0xffcc >> real memory = 2079195136 (1982 MB) >> Physical memory chunk(s): >> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages) >> avail memory = 2027855872 (1933 MB) >> Table 'FACP' at 0x7bee3080 >> Table 'MCFG' at 0x7bee6ec0 >> Table 'APIC' at 0x7bee6e40 >> MADT: Found table at 0x7bee6e40 >> MP Configuration Table version 1.4 found at 0xc00f1ce0 >> APIC: Using the MADT enumerator. >> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >> SMP: Added CPU 0 (AP) >> ACPI APIC Table: >> APIC: CPU 0 has ACPI ID 0 >> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >> bios32: Entry = 0xf9580 (c00f9580) Rev = 0 Len = 1 >> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >> pnpbios: Found PnP BIOS data at 0xc00fa110 >> pnpbios: Entry = f0000:a140 Rev = 1.0 >> Other BIOS signatures found: >> ULE: setup cpu 0 >> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> ACPI: FACP 0x7bee3080 00074 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 AWRDACPI 00001000 MSFT 03000000) >> ACPI: FACS 0x7bee0000 00040 >> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 AWRDACPI 42302E31 AWRD 00000000) >> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >> ioapic0: Routing external 8259A's -> intpin 0 >> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >> MADT: Interrupt override: source 0, irq 2 >> ioapic0: Routing IRQ 0 -> intpin 2 >> MADT: Interrupt override: source 9, irq 9 >> ioapic0: intpin 9 trigger: level >> ioapic0: intpin 9 polarity: low >> lapic0: Routing NMI -> LINT1 >> lapic0: LINT1 trigger: edge >> lapic0: LINT1 polarity: high >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> cpu0 BSP: >> ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >> null: >> nfslock: pseudo-device >> random: >> io: >> kbd: new array size 4 >> kbd1 at kbdmux0 >> mem: >> npx0: INT 16 interface >> acpi0: on motherboard >> PCIe: Memory Mapped configuration base @ 0xe0000000 >> pcibios: BIOS version 3.00 >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >> acpi0: [MPSAFE] >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 7bde0000 (3) failed >> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> pci_link0: Index IRQ Rtd Ref IRQs >> Initial Probe 0 10 N 0 3 4 6 7 10 11 12 >> Validation 0 10 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link1: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 6 7 10 11 12 >> Validation 0 11 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link2: Index IRQ Rtd Ref IRQs >> Initial Probe 0 7 N 0 3 4 6 7 10 11 12 >> Validation 0 7 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link3: Index IRQ Rtd Ref IRQs >> Initial Probe 0 5 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link4: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link5: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link6: Index IRQ Rtd Ref IRQs >> Initial Probe 0 255 N 0 3 4 6 7 10 11 12 >> Validation 0 255 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> pci_link7: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 6 7 10 11 12 >> Validation 0 11 N 0 3 4 6 7 10 11 12 >> After Disable 0 255 N 0 3 4 6 7 10 11 12 >> acpi_button0: on acpi0 >> acpi_button1: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: domain=0, physical bus=0 >> found-> vendor=0x1106, dev=0x0353, revid=0x11 >> domain=0, bus=0, slot=0, func=0 >> class=06-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x1353, revid=0x00 >> domain=0, bus=0, slot=0, func=1 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x2353, revid=0x00 >> domain=0, bus=0, slot=0, func=2 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x3353, revid=0x00 >> domain=0, bus=0, slot=0, func=3 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x4353, revid=0x00 >> domain=0, bus=0, slot=0, func=4 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x5353, revid=0x00 >> domain=0, bus=0, slot=0, func=5 >> class=08-00-20, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x6353, revid=0x00 >> domain=0, bus=0, slot=0, func=6 >> class=06-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0000, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x7353, revid=0x00 >> domain=0, bus=0, slot=0, func=7 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0200, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x1122, revid=0x11 >> domain=0, bus=0, slot=1, func=0 >> class=03-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x3010, cachelnsz=0 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> MSI supports 1 message >> map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 26, enabled >> map[14]: type Memory, range 32, base 0xde000000, size 24, enabled >> map[18]: type Memory, range 32, base 0xc0000000, size 28, enabled >> pcib0: matched entry for 0.1.INTA >> pcib0: slot 1 INTA hardwired to IRQ 16 >> found-> vendor=0x1106, dev=0xc353, revid=0x00 >> domain=0, bus=0, slot=2, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=0 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit, vector masks >> pcib0: matched entry for 0.2.INTA >> pcib0: slot 2 INTA hardwired to IRQ 27 >> found-> vendor=0x1106, dev=0xe353, revid=0x00 >> domain=0, bus=0, slot=3, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit, vector masks >> pcib0: matched entry for 0.3.INTA >> pcib0: slot 3 INTA hardwired to IRQ 31 >> found-> vendor=0x1106, dev=0xf353, revid=0x00 >> domain=0, bus=0, slot=3, func=1 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit, vector masks >> pcib0: matched entry for 0.3.INTB >> pcib0: slot 3 INTB hardwired to IRQ 39 >> found-> vendor=0x1106, dev=0x5324, revid=0x00 >> domain=0, bus=0, slot=15, func=0 >> class=01-01-8a, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> powerspec 2 supports D0 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled >> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >> domain=0, bus=0, slot=16, func=0 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0218, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xf800, size 5, enabled >> pcib0: matched entry for 0.16.INTA >> pcib0: slot 16 INTA hardwired to IRQ 20 >> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >> domain=0, bus=0, slot=16, func=1 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=11 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xf400, size 5, enabled >> pcib0: matched entry for 0.16.INTB >> pcib0: slot 16 INTB hardwired to IRQ 22 >> found-> vendor=0x1106, dev=0x3038, revid=0xa0 >> domain=0, bus=0, slot=16, func=2 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=7 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[20]: type I/O Port, range 32, base 0xf000, size 5, enabled >> pcib0: matched entry for 0.16.INTC >> pcib0: slot 16 INTC hardwired to IRQ 21 >> found-> vendor=0x1106, dev=0x3104, revid=0x90 >> domain=0, bus=0, slot=16, func=4 >> class=0c-03-20, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0210, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=d, irq=5 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[10]: type Memory, range 32, base 0xdffff000, size 8, enabled >> pcib0: matched entry for 0.16.INTD >> pcib0: slot 16 INTD hardwired to IRQ 23 >> found-> vendor=0x1106, dev=0x8353, revid=0x00 >> domain=0, bus=0, slot=17, func=0 >> class=06-01-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0003, statreg=0x0210, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> powerspec 2 supports D0 D3 current D0 >> found-> vendor=0x1106, dev=0xa353, revid=0x00 >> domain=0, bus=0, slot=17, func=7 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0000, statreg=0x2200, cachelnsz=0 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0xb353, revid=0x00 >> domain=0, bus=0, slot=19, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=0 >> cmdreg=0x0007, statreg=0x2010, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x1106, dev=0x3288, revid=0x10 >> domain=0, bus=0, slot=20, func=0 >> class=04-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 64, base 0xdfff8000, size 14, enabled >> pcib0: matched entry for 0.20.INTA >> pcib0: slot 20 INTA hardwired to IRQ 17 >> NMI ISA 3c, EISA 0 >> NMI ... going to debugger >> [thread pid 0 tid 100000 ] >> Stopped at 0xc060098f = vsscanf+0x98f: movl %edx,0xfffffe8c(%ebp) >> db> ps >> pid ppid pgrp uid state wmesg wchan cmd >> 5 0 0 0 RL [xpt_thrd] >> 4 0 0 0 RL [g_down] >> 3 0 0 0 RL [g_up] >> 2 0 0 0 RL [g_event] >> 12 0 0 0 WL (threaded) intr >> 100021 I [irq9: acpi0] >> 100016 I [swi2: cambio] >> 100014 I [swi6: task queue] >> 100013 I [swi6: Giant taskq] >> 100011 I [swi5: +] >> 100006 I [swi1: netisr 0] >> 100005 I [swi4: clock] >> 100004 I [swi3: vm] >> 11 0 0 0 RL [idle: cpu0] >> 1 0 0 0 ?L [kernel] >> 10 0 0 0 RL [audit] >> 0 0 0 0 RLs (threaded) kernel >> 100020 RunQ [acpi_task_2] >> 100019 RunQ [acpi_task_1] >> 100018 RunQ [acpi_task_0] >> 100017 RunQ [kqueue taskq] >> 100012 RunQ [thread taskq] >> 100010 RunQ [firmware taskq] >> 100000 Run CPU 0 [swapper] >> db> where >> Tracing pid 0 tid 100000 td 0xc0934590 >> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f = vsscanf+0x98f >> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = sscanf+0x22 >> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 = res_find+0x319 >> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda = resource_find+0x5a >> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc05f8041 = resource_string_value+0x61 >> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc05f071e = devclass_add_device+0x16e >> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) at 0xc05f16af = device_set_devclass+0x6f >> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f3e6b = device_probe_child+0xfb >> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05f4160 = device_probe+0xa0 >> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0xc05f4238 = device_probe_and_attach+0x48 >> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at 0xc05f42a8 = bus_generic_attach+0x48 >> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0xc04b275c = acpi_pci_attach+0x18c >> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f42a8 = bus_generic_attach+0x48 >> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = acpi_pcib_attach+0x1a1 >> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...) at 0xc04b54a1 = acpi_pcib_acpi_attach+0x251 >> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at 0xc05f42a8 = bus_generic_attach+0x48 >> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04aa1ae = acpi_attach+0xbbe >> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 = bus_generic_attach+0x48 >> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at 0xc081caae = nexus_acpi_attach+0x7e >> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 = device_attach+0x3b7 >> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,...) at 0xc05f4255 = device_probe_and_attach+0x65 >> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) at 0xc05f449d = bus_generic_new_pass+0xcd >> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f2341 = bus_set_pass+0x81 >> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2392 = root_bus_configure+0x12 >> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc = configure+0xc >> mi_startup() at 0xc05839d6 = mi_startup+0xa6 >> begin() at 0xc0453005 = begin+0x2c >> db> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 15:58:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12AD106566C; Tue, 11 Aug 2009 15:58:58 +0000 (UTC) (envelope-from fb-embedded@psconsult.nl) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id 268D58FC41; Tue, 11 Aug 2009 15:58:57 +0000 (UTC) Received: from mx1.psconsult.nl (localhost [80.89.238.138]) by mx1.psconsult.nl (8.14.2/8.14.2) with ESMTP id n7BFwpcY050772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 17:58:56 +0200 (CEST) (envelope-from fb-embedded@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.2/8.14.2/Submit) id n7BFwp9R050771; Tue, 11 Aug 2009 17:58:51 +0200 (CEST) (envelope-from fb-embedded@psconsult.nl) Date: Tue, 11 Aug 2009 17:58:51 +0200 From: Paul Schenkeveld To: freebsd-embedded@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090811155851.GA50096@psconsult.nl> Mail-Followup-To: freebsd-embedded@freebsd.org, freebsd-current@freebsd.org References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908111449.51779.nick@van-laarhoven.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-Mailman-Approved-At: Tue, 11 Aug 2009 16:40:30 +0000 Cc: Subject: Re: [NanoBSD] Can't use boot0cfg for changing the booting slice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 15:58:59 -0000 On Tue, Aug 11, 2009 at 02:49:51PM +0200, Nick Hibma wrote: > > > : > But, after the reboot my system still reboot from the slice 1 (but > > > : > the boot loader show correctly that the default choice is now the > > > : > 2)! Where is my problem ? > > > : > > > : Are you sure you're booting from slice 1? > > > : Is fstab on slice 2 pointing to slice 1? > > > > > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was > > > the last slice you booted from... To mark it active, you must use > > > fdisk. If by 'active' you mean 'what mount reports root as' then I > > > think John's suggestion is right on the money... > > Perhaps you could change the line in the update script from > > boot0cfg -s $oslice $NANO_DRIVE > > to > > boot0cfg -s $oslice $NANO_DRIVE > echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE boot0cfg -s $oslice $NANO_DRIVE fdisk -f - << ! a $NANO_DRIVE ! is even cheaper 8-> > That's taken from our own version of the update script, but should fit in > the NanoBSD update script. I know how to solve the problem on NanoBSD machines I administer, the bigger picture is that the bootloader (boot0) changed from looking at its own default answer as tuned by boot0cfg -s to looking at the active flags in the MBR record. IMHO this is a regression and a POLA violation. The default action can no longer be "F5 boot from next drive" which is valid and useful on multi-drive servers/desktops. So far nobody has come up with a good reason why this was changed and the change cripples the functionality of boot0cfg, makes NanoBSD no longer work as advertised and will scare off new users (of NanoBSD) to some kind of embedded whatever OS besides FreeBSD. So who wins? > Nick Kind regards, Paul Schenkeveld From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 16:41:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38CA31065680 for ; Tue, 11 Aug 2009 16:41:22 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id B3AFB8FC4D for ; Tue, 11 Aug 2009 16:41:21 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5BD0D19963E; Tue, 11 Aug 2009 18:41:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4EC011995C0; Tue, 11 Aug 2009 18:41:20 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3A7BA1994DC; Tue, 11 Aug 2009 18:41:20 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009081118411928-3450 ; Tue, 11 Aug 2009 18:41:19 +0200 Received: by wep4035 (sSMTP sendmail emulation); Tue, 11 Aug 2009 18:41:19 +0200 Date: Tue, 11 Aug 2009 18:41:19 +0200 From: Alexey Shuvaev To: freebsd-embedded@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090811164119.GA79544@wep4035.physik.uni-wuerzburg.de> Mail-Followup-To: freebsd-embedded@freebsd.org, freebsd-current@freebsd.org References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> <20090811155851.GA50096@psconsult.nl> Mime-Version: 1.0 In-Reply-To: <20090811155851.GA50096@psconsult.nl> User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 08/11/2009 06:41:19 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 08/11/2009 06:41:19 PM, Serialize complete at 08/11/2009 06:41:19 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Subject: Re: [NanoBSD] Can't use boot0cfg for changing the booting slice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 16:41:22 -0000 On Tue, Aug 11, 2009 at 05:58:51PM +0200, Paul Schenkeveld wrote: > On Tue, Aug 11, 2009 at 02:49:51PM +0200, Nick Hibma wrote: > > > > : > But, after the reboot my system still reboot from the slice 1 (but > > > > : > the boot loader show correctly that the default choice is now the > > > > : > 2)! Where is my problem ? > > > > : > > > > : Are you sure you're booting from slice 1? > > > > : Is fstab on slice 2 pointing to slice 1? > > > > > > > > Also, boot0cfg won't mark the slice as ACTIVE, just remember that was > > > > the last slice you booted from... To mark it active, you must use > > > > fdisk. If by 'active' you mean 'what mount reports root as' then I > > > > think John's suggestion is right on the money... > > > > Perhaps you could change the line in the update script from > > > > boot0cfg -s $oslice $NANO_DRIVE > > > > to > > > > boot0cfg -s $oslice $NANO_DRIVE > > echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE > > boot0cfg -s $oslice $NANO_DRIVE > fdisk -f - << ! > a $NANO_DRIVE > ! > > is even cheaper 8-> > > > That's taken from our own version of the update script, but should fit in > > the NanoBSD update script. > > I know how to solve the problem on NanoBSD machines I administer, the > bigger picture is that the bootloader (boot0) changed from looking at > its own default answer as tuned by boot0cfg -s to looking at the > active flags in the MBR record. IMHO this is a regression and a POLA > violation. The default action can no longer be "F5 boot from next drive" > which is valid and useful on multi-drive servers/desktops. > > So far nobody has come up with a good reason why this was changed and > the change cripples the functionality of boot0cfg, makes NanoBSD no > longer work as advertised and will scare off new users (of NanoBSD) to > some kind of embedded whatever OS besides FreeBSD. > > So who wins? > A lot of new functionality was brought in. I would suggest going through the history at http://svn.freebsd.org/viewvc/base/head/sys/boot/i386/boot0/boot0.S?view=log and examine which compile-time options are now there. Also you can also try contacting luigi who has touched boot0.S My 0.02$, Alexey. From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 19:35:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B16F1065670 for ; Tue, 11 Aug 2009 19:35:21 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFAD8FC3A for ; Tue, 11 Aug 2009 19:35:20 +0000 (UTC) Received: by ywh17 with SMTP id 17so5446538ywh.3 for ; Tue, 11 Aug 2009 12:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Pkkh/m6JxUWONE2v2AWRL8vBgTqgAeCrvQqYZjun1l8=; b=gOaHlAjNnVY/8h942NZ9F8IJpFypcZZ5KvRIgEPXO/d0ikz2ZLAhRpjfSPa+yRb7y8 HmmACJDeHUREWNnrpz2JNoFZKfaBj08NJkHTdZRCU+4K6WC/Fco6dWQdj2xGdtez8NNi OhtMz3YHWjq85taasMu2PJUvQtXWH5XScF8tY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=efZyBKCaxuQMB14W0LsLxtNmkvaDpkxJ04suxmskPGcczZYrL7Dx+HjG+oLms9fMST 260teyJaIY761Kn4RRe1URW47W2AHIVGuZQQhAsOSDlf9oP5aehKex0eph7y/3YhLZ47 pH6hNWoQcmjNSHRYdIFEVM7lvBTFE2amRwsDs= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.5.15 with SMTP id 15mr5899489ane.105.1250019318329; Tue, 11 Aug 2009 12:35:18 -0700 (PDT) In-Reply-To: References: <1250004330.1773.223.camel@balrog.2hip.net> Date: Tue, 11 Aug 2009 12:35:18 -0700 X-Google-Sender-Auth: d532697518490042 Message-ID: <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> From: Kip Macy To: "Arno J. Klaassen" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Robert Noland Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 19:35:21 -0000 Please try the following patch: http://people.freebsd.org/~kmacy/flowtable_boot.patch On Tue, Aug 11, 2009 at 9:27 AM, Arno J. Klaassen wrote: > > Robert Noland writes: > >> On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >>> Hello, >>> >>> I get the following panic when pxebooting a 8.0-BETA2 on a >>> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >>> and I defined CPUTYPE?=3Dpentiumpro in make.conf. >>> >>> Let me know what I can provide more as info to get around this. >> >> I've seen this as well. =A0You can disable apic which I see has been >> suggested. =A0The NMI seems to be generated by HWPMC_HOOKS, in my case >> removing it from the GENERIC config allows it to boot and use apic. =A0I= 'm >> not certain what the correct fix is, but after talking to jkoshy@ we did >> find the specific point in the HWPMC_HOOKS code that triggers this, >> which can be disabled by testing for CPU_VENDOR_CENTAUR. >> >> The attached hack should get things booting... > > > Correct. It now boots OK with apic enabled (but still panics > at the 'flowtable bug'). > Thanks. > > Arno > > >> robert. >> >>> Thanks in advance. >>> >>> Best, Arno >>> >>> >>> >>> ##### >>> >>> OK boot -sv >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> SMAP type=3D01 base=3D0000000000000000 len=3D000000000009f800 >>> SMAP type=3D02 base=3D000000000009f800 len=3D0000000000000800 >>> SMAP type=3D02 base=3D00000000000f0000 len=3D0000000000010000 >>> SMAP type=3D01 base=3D0000000000100000 len=3D000000007bde0000 >>> SMAP type=3D04 base=3D000000007bee0000 len=3D0000000000003000 >>> SMAP type=3D03 base=3D000000007bee3000 len=3D000000000000d000 >>> SMAP type=3D02 base=3D000000007bef0000 len=3D0000000000010000 >>> SMAP type=3D02 base=3D00000000e0000000 len=3D0000000010000000 >>> SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000001000 >>> SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 >>> SMAP type=3D02 base=3D00000000ffff0000 len=3D0000000000010000 >>> Copyright (c) 1992-2009 The FreeBSD Project. >>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 199= 4 >>> =A0 =A0 =A0 =A0 The Regents of the University of California. All rights= reserved. >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >>> =A0 =A0 toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >>> WARNING: WITNESS option enabled, expect reduced performance. >>> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >>> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >>> =A0 =A0 =A0 =A0 MEMGUARD map base: 0xc4c00000 >>> =A0 =A0 =A0 =A0 MEMGUARD map limit: 0xc6c01000 >>> =A0 =A0 =A0 =A0 MEMGUARD map size: 33558528 (Bytes) >>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> Calibrating TSC clock ... TSC clock: 999896638 Hz >>> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >>> =A0 Origin =3D "CentaurHauls" =A0Id =3D 0x6d0 =A0Stepping =3D 0 >>> =A0 Features=3D0xa7c9bbff >>> =A0 Features2=3D0x4181 >>> =A0 VIA Padlock Features=3D0xffcc >>> real memory =A0=3D 2079195136 (1982 MB) >>> Physical memory chunk(s): >>> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >>> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >>> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pages= ) >>> avail memory =3D 2027855872 (1933 MB) >>> Table 'FACP' at 0x7bee3080 >>> Table 'MCFG' at 0x7bee6ec0 >>> Table 'APIC' at 0x7bee6e40 >>> MADT: Found table at 0x7bee6e40 >>> MP Configuration Table version 1.4 found at 0xc00f1ce0 >>> APIC: Using the MADT enumerator. >>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >>> SMP: Added CPU 0 (AP) >>> ACPI APIC Table: >>> APIC: CPU 0 has ACPI ID 0 >>> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >>> bios32: Entry =3D 0xf9580 (c00f9580) =A0Rev =3D 0 =A0Len =3D 1 >>> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >>> pnpbios: Found PnP BIOS data at 0xc00fa110 >>> pnpbios: Entry =3D f0000:a140 =A0Rev =3D 1.0 >>> Other BIOS signatures found: >>> ULE: setup cpu 0 >>> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >>> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 0000000= 0) >>> ACPI: FACP 0x7bee3080 00074 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 0000000= 0) >>> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 =A0AWRDACPI 00001000 MSFT 0300000= 0) >>> ACPI: FACS 0x7bee0000 00040 >>> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 =A0AWRDACPI 42302E31 AWRD 0000000= 0) >>> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 0000000= 0) >>> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >>> ioapic0: Routing external 8259A's -> intpin 0 >>> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >>> MADT: Interrupt override: source 0, irq 2 >>> ioapic0: Routing IRQ 0 -> intpin 2 >>> MADT: Interrupt override: source 9, irq 9 >>> ioapic0: intpin 9 trigger: level >>> ioapic0: intpin 9 polarity: low >>> lapic0: Routing NMI -> LINT1 >>> lapic0: LINT1 trigger: edge >>> lapic0: LINT1 polarity: high >>> ioapic0 irqs 0-23 on motherboard >>> ioapic1 irqs 24-47 on motherboard >>> cpu0 BSP: >>> =A0 =A0 =A0ID: 0x00000000 =A0 VER: 0x00050014 LDR: 0x00000000 DFR: 0xff= ffffff >>> =A0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >>> =A0 timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >>> null: >>> nfslock: pseudo-device >>> random: >>> io: >>> kbd: new array size 4 >>> kbd1 at kbdmux0 >>> mem: >>> npx0: INT 16 interface >>> acpi0: on motherboard >>> PCIe: Memory Mapped configuration base @ 0xe0000000 >>> pcibios: BIOS version 3.00 >>> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >>> acpi0: [MPSAFE] >>> acpi0: [ITHREAD] >>> acpi0: Power Button (fixed) >>> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >>> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >>> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >>> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >>> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >>> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >>> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >>> acpi0: reservation of 0, a0000 (3) failed >>> acpi0: reservation of 100000, 7bde0000 (3) failed >>> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>> pci_link0: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 10 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 10 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> pci_link1: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> pci_link2: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 =A07 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 =A07 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> pci_link3: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 =A05 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> pci_link4: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> pci_link5: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> pci_link6: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> pci_link7: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 11= 12 >>> acpi_button0: on acpi0 >>> acpi_button1: on acpi0 >>> pcib0: port 0xcf8-0xcff on acpi0 >>> pci0: on pcib0 >>> pci0: domain=3D0, physical bus=3D0 >>> found-> vendor=3D0x1106, dev=3D0x0353, revid=3D0x11 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x08 (240 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x1353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D1 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x2353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D2 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x3353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D3 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D0 (dword= s) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x4353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D4 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x5353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D5 >>> =A0 =A0 =A0 =A0 class=3D08-00-20, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0000, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x6353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D6 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0000, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x7353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D7 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x1122, revid=3D0x11 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D1, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x3010, cachelnsz=3D0 (dword= s) >>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 MSI supports 1 message >>> =A0 =A0 =A0 =A0 map[10]: type Prefetchable Memory, range 32, base 0xd80= 00000, size 26, enabled >>> =A0 =A0 =A0 =A0 map[14]: type Memory, range 32, base 0xde000000, size 2= 4, enabled >>> =A0 =A0 =A0 =A0 map[18]: type Memory, range 32, base 0xc0000000, size 2= 8, enabled >>> pcib0: matched entry for 0.1.INTA >>> pcib0: slot 1 INTA hardwired to IRQ 16 >>> found-> vendor=3D0x1106, dev=3D0xc353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D2, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D11 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>> pcib0: matched entry for 0.2.INTA >>> pcib0: slot 2 INTA hardwired to IRQ 27 >>> found-> vendor=3D0x1106, dev=3D0xe353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D3, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D11 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>> pcib0: matched entry for 0.3.INTA >>> pcib0: slot 3 INTA hardwired to IRQ 31 >>> found-> vendor=3D0x1106, dev=3D0xf353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D3, func=3D1 >>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Db, irq=3D11 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>> pcib0: matched entry for 0.3.INTB >>> pcib0: slot 3 INTB hardwired to IRQ 39 >>> found-> vendor=3D0x1106, dev=3D0x5324, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D15, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dword= s) >>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xfc00, size =A0= 4, enabled >>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0218, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf800, size =A0= 5, enabled >>> pcib0: matched entry for 0.16.INTA >>> pcib0: slot 16 INTA hardwired to IRQ 20 >>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D1 >>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Db, irq=3D11 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf400, size =A0= 5, enabled >>> pcib0: matched entry for 0.16.INTB >>> pcib0: slot 16 INTB hardwired to IRQ 22 >>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D2 >>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Dc, irq=3D7 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf000, size =A0= 5, enabled >>> pcib0: matched entry for 0.16.INTC >>> pcib0: slot 16 INTC hardwired to IRQ 21 >>> found-> vendor=3D0x1106, dev=3D0x3104, revid=3D0x90 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D4 >>> =A0 =A0 =A0 =A0 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Dd, irq=3D5 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 map[10]: type Memory, range 32, base 0xdffff000, size = =A08, enabled >>> pcib0: matched entry for 0.16.INTD >>> pcib0: slot 16 INTD hardwired to IRQ 23 >>> found-> vendor=3D0x1106, dev=3D0x8353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D17, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0003, statreg=3D0x0210, cachelnsz=3D0 (dword= s) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>> found-> vendor=3D0x1106, dev=3D0xa353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D17, func=3D7 >>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0000, statreg=3D0x2200, cachelnsz=3D0 (dword= s) >>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0xb353, revid=3D0x00 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D19, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x2010, cachelnsz=3D0 (dword= s) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat= =3D0x00 (0 ns) >>> found-> vendor=3D0x1106, dev=3D0x3288, revid=3D0x10 >>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D20, func=3D0 >>> =A0 =A0 =A0 =A0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 >>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwor= ds) >>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D= 0x00 (0 ns) >>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit >>> =A0 =A0 =A0 =A0 map[10]: type Memory, range 64, base 0xdfff8000, size 1= 4, enabled >>> pcib0: matched entry for 0.20.INTA >>> pcib0: slot 20 INTA hardwired to IRQ 17 >>> NMI ISA 3c, EISA 0 >>> NMI ... going to debugger >>> [thread pid 0 tid 100000 ] >>> Stopped at =A0 =A0 =A00xc060098f =3D vsscanf+0x98f: =A0 =A0 movl =A0 = =A0%edx,0xfffffe8c(%ebp) >>> db> ps >>> =A0 pid =A0ppid =A0pgrp =A0 uid =A0 state =A0 wmesg =A0 =A0 wchan =A0 = =A0cmd >>> =A0 =A0 5 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[xpt_thrd] >>> =A0 =A0 4 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_down] >>> =A0 =A0 3 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_up] >>> =A0 =A0 2 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_event] >>> =A0 =A012 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0WL =A0 =A0 =A0(threaded) =A0= =A0 =A0 =A0 =A0intr >>> 100021 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [irq9: acpi0] >>> 100016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi2: cambio] >>> 100014 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi6: task queue] >>> 100013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi6: Giant taskq] >>> 100011 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi5: +] >>> 100006 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi1: netisr 0] >>> 100005 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi4: clock] >>> 100004 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi3: vm] >>> =A0 =A011 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[idle: cpu0] >>> =A0 =A0 1 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0?L =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[kernel] >>> =A0 =A010 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[audit] >>> =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RLs =A0 =A0 (threaded) =A0 = =A0 =A0 =A0 =A0kernel >>> 100020 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_2] >>> 100019 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_1] >>> 100018 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_0] >>> 100017 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[kqueue taskq] >>> 100012 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[thread taskq] >>> 100010 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0[firmware taskq] >>> 100000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Run =A0 =A0 CPU 0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [swapper] >>> db> where >>> Tracing pid 0 tid 100000 td 0xc0934590 >>> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098f= =3D vsscanf+0x98f >>> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22 = =3D sscanf+0x22 >>> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 =3D res_find+0x319 >>> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda =3D resource_f= ind+0x5a >>> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0xc= 05f8041 =3D resource_string_value+0x61 >>> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0xc= 05f071e =3D devclass_add_device+0x16e >>> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) a= t 0xc05f16af =3D device_set_devclass+0x6f >>> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05f= 3e6b =3D device_probe_child+0xfb >>> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc05= f4160 =3D device_probe+0xa0 >>> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at 0= xc05f4238 =3D device_probe_and_attach+0x48 >>> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) at= 0xc05f42a8 =3D bus_generic_attach+0x48 >>> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0x= c04b275c =3D acpi_pci_attach+0x18c >>> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 =3D de= vice_attach+0x3b7 >>> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,..= .) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05f= 42a8 =3D bus_generic_attach+0x48 >>> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 =3D = acpi_pcib_attach+0x1a1 >>> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...)= at 0xc04b54a1 =3D acpi_pcib_acpi_attach+0x251 >>> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 =3D de= vice_attach+0x3b7 >>> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,..= .) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) at= 0xc05f42a8 =3D bus_generic_attach+0x48 >>> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04a= a1ae =3D acpi_attach+0xbbe >>> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 =3D device_at= tach+0x3b7 >>> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at 0= xc05f4255 =3D device_probe_and_attach+0x65 >>> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 =3D bus_generic= _attach+0x48 >>> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at = 0xc081caae =3D nexus_acpi_attach+0x7e >>> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 =3D device_att= ach+0x3b7 >>> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,..= .) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) a= t 0xc05f449d =3D bus_generic_new_pass+0xcd >>> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05f= 2341 =3D bus_set_pass+0x81 >>> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f239= 2 =3D root_bus_configure+0x12 >>> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc =3D configur= e+0xc >>> mi_startup() at 0xc05839d6 =3D mi_startup+0xa6 >>> begin() at 0xc0453005 =3D begin+0x2c >>> db> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > > -- > > =A0Arno J. Klaassen > > =A0SCITO S.A. > =A08 rue des Haies > =A0F-75020 Paris, France > =A0http://scito.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 19:52:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13E67106564A; Tue, 11 Aug 2009 19:52:42 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id A5F888FC47; Tue, 11 Aug 2009 19:52:41 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id BF2FF1CD73; Tue, 11 Aug 2009 21:52:40 +0200 (CEST) Date: Tue, 11 Aug 2009 21:52:40 +0200 From: Ed Schouten To: Kip Macy Message-ID: <20090811195240.GI1292@hoeg.nl> References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CD1rT0yj7A8qvce7" Content-Disposition: inline In-Reply-To: <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Arno J. Klaassen" , Robert Noland , FreeBSD Current Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 19:52:42 -0000 --CD1rT0yj7A8qvce7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Kip Macy wrote: > http://people.freebsd.org/~kmacy/flowtable_boot.patch + if ((V_flowtable_enable =3D=3D 0) || (V_flowtable_ready =3D=3D 0) should probably read: + if (V_flowtable_enable =3D=3D 0 || V_flowtable_ready =3D=3D 0) Right? --=20 Ed Schouten WWW: http://80386.nl/ --CD1rT0yj7A8qvce7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqBzAgACgkQ52SDGA2eCwX5BwCdF07YtwuxUSiFQwUrUEqlkxE8 /SQAnRQ9bZtsT8xpBqnv8QH4kpr5pecD =2Jv8 -----END PGP SIGNATURE----- --CD1rT0yj7A8qvce7-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 21:26:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3034106564A for ; Tue, 11 Aug 2009 21:26:06 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by mx1.freebsd.org (Postfix) with ESMTP id A47A08FC47 for ; Tue, 11 Aug 2009 21:26:06 +0000 (UTC) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id E67901C000FC; Tue, 11 Aug 2009 23:26:04 +0200 (CEST) Received: from localhost (dynscan2.mnet-online.de [192.168.1.215]) by mail.m-online.net (Postfix) with ESMTP id D1132901EF; Tue, 11 Aug 2009 23:26:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.1.215]) (amavisd-new, port 10024) with ESMTP id 2Hb31SC6T40U; Tue, 11 Aug 2009 23:26:03 +0200 (CEST) Received: from mail.reifenberger.com (ppp-93-104-42-101.dynamic.mnet-online.de [93.104.42.101]) by mail.mnet-online.de (Postfix) with ESMTP; Tue, 11 Aug 2009 23:26:03 +0200 (CEST) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 268DD3731A; Tue, 11 Aug 2009 23:26:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 1F40037319; Tue, 11 Aug 2009 23:26:03 +0200 (CEST) Date: Tue, 11 Aug 2009 23:26:03 +0200 (CEST) From: Michael Reifenberger To: Nick Hibma In-Reply-To: <200908111449.51779.nick@van-laarhoven.org> Message-ID: References: <3131aa530908070809l2ac13931xf65981db6eeb83e8@mail.gmail.com> <20090807.104414.221852486.imp@bsdimp.com> <20090807205817.GA82868@psconsult.nl> <200908111449.51779.nick@van-laarhoven.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-embedded@freebsd.org, Paul Schenkeveld Subject: Re: [NanoBSD] Can't use boot0cfg for changing the booting slice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 21:26:07 -0000 On Tue, 11 Aug 2009, Nick Hibma wrote: ... > to > > boot0cfg -s $oslice $NANO_DRIVE > echo "a $oslice" | fdisk -f /dev/stdin $NANO_DRIVE > Why not: gpart set -a active -i 1 ${NANO_DRIVE} Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 22:21:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71CB2106564A for ; Tue, 11 Aug 2009 22:21:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 54AEB8FC15 for ; Tue, 11 Aug 2009 22:21:30 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id D33A24C09F; Tue, 11 Aug 2009 15:21:29 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 9E0A62D600E; Tue, 11 Aug 2009 15:21:28 -0700 (PDT) Message-ID: <4A81EEE8.5060405@elischer.org> Date: Tue, 11 Aug 2009 15:21:28 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Ed Schouten References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> <20090811195240.GI1292@hoeg.nl> In-Reply-To: <20090811195240.GI1292@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Kip Macy , Robert Noland , "Arno J. Klaassen" Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 22:21:30 -0000 Ed Schouten wrote: > * Kip Macy wrote: >> http://people.freebsd.org/~kmacy/flowtable_boot.patch > > + if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0) > > should probably read: > > + if (V_flowtable_enable == 0 || V_flowtable_ready == 0) > > Right? > I prefer the first, with an extra closing paren. From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 22:56:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A33A2106566B; Tue, 11 Aug 2009 22:56:23 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by mx1.freebsd.org (Postfix) with ESMTP id 42AD48FC40; Tue, 11 Aug 2009 22:56:23 +0000 (UTC) Received: by ywh17 with SMTP id 17so5620660ywh.3 for ; Tue, 11 Aug 2009 15:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=FCxiBGdKjlfHSNz34z7AaEYSIZZe6vF9sdInyM/DIu8=; b=lJfpf25MZvp1KONRneQFHvO7LiJImoAoWS8zv724pcW04S3yXMcH8MGmh2IwoEb13P yO5pJK7RUUPMklmr6+Zv9+WAIPVtoG94jA2grqdUxiZY/Dt41s90Go1IvKSdzDqi+oLD 4HEKnvGP96DOaO22O6RVZD6NURmBJHMUWPqCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mEuwCpL1LF3RppsnYW8Q/VNdmZ4ccbecCeOsXukYsnp3qCP0KK3LE0lMg/WUbhMe3W alz67EwY9Ndw9yHjfd+YL6RidBLNQbdkyZ74S7SRHBNtekXt/arfSKshZkjpLMnpRxy0 Fk1mXqmhE5UuqnM0izVXXwUHLw1HezMguvczs= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.247.14 with SMTP id u14mr6229897anh.7.1250031382564; Tue, 11 Aug 2009 15:56:22 -0700 (PDT) In-Reply-To: <4A81EEE8.5060405@elischer.org> References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> <20090811195240.GI1292@hoeg.nl> <4A81EEE8.5060405@elischer.org> Date: Tue, 11 Aug 2009 15:56:22 -0700 X-Google-Sender-Auth: 92e0d301dc439dac Message-ID: <3c1674c90908111556t683fd2a8r49c1e70341d6dff1@mail.gmail.com> From: Kip Macy To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , FreeBSD Current , Robert Noland , "Arno J. Klaassen" Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 22:56:23 -0000 On Tue, Aug 11, 2009 at 3:21 PM, Julian Elischer wrote= : > Ed Schouten wrote: >> >> * Kip Macy wrote: >>> >>> http://people.freebsd.org/~kmacy/flowtable_boot.patch >> >> + =A0 =A0 =A0 if ((V_flowtable_enable =3D=3D 0) || (V_flowtable_ready = =3D=3D 0) >> >> should probably read: >> >> + =A0 =A0 =A0 if (V_flowtable_enable =3D=3D 0 || V_flowtable_ready =3D= =3D 0) >> >> Right? >> > > > I prefer the first, with an extra closing paren. > Oops thanks. I updated the patch. -Kip From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 23:17:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90FCF1065672 for ; Tue, 11 Aug 2009 23:17:32 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 420318FC21 for ; Tue, 11 Aug 2009 23:17:31 +0000 (UTC) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n7BMiJbL045342; Tue, 11 Aug 2009 16:44:20 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A81F443.5030905@samsco.org> Date: Tue, 11 Aug 2009 16:44:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Rick Macklem References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list , Jilles Tjoelker Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 23:17:32 -0000 Rick Macklem wrote: > > > On Thu, 2 Jul 2009, Jilles Tjoelker wrote: > >> >> This could be because of NFS "sillyrename". To avoid some ESTALE errors, >> the NFS client (for NFSv2 and NFSv3 at least) renames if you delete a >> file that is currently in use (in this case, the rm binary). Because the >> renamed file (name typically starts with .nfs) is in the same directory, >> this causes problems when removing directories. Once the file is no >> longer in use, it is finally deleted. >> > Yes, if some file that was in that directory is still open (or mmap'd and > the process hasn't yet exit()'d), it will exist as a file named ".nfsXXX" > until the v_usecount goes to 0 and then it's removed, which would explain > it. > >> Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it >> is open. >> > Afraid not. NFSv4 has an Open, but it is an open share lock and not a > POSIX style open, so NFSv4 clients still do the silly rename. (ie. The > NFSv4 Remove Op is defined as removing the file and not just unlinking > it and the NFSv4 server isn't required to retain the file after removal > if it is Open'd by a client.) > I'd like to pop this issue back to the top of the stack. Doing an installworld to local disks on a NFS-root system used to be a convenient way to install new systems without requiring release bits and release media. So, this used to work, and now it doesn't. I'd like help in getting to the bottom of this and fixing it. Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 23:25:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4820F106566C; Tue, 11 Aug 2009 23:25:55 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 269AE8FC41; Tue, 11 Aug 2009 23:25:53 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7BNPUnF069599 ; Wed, 12 Aug 2009 01:25:30 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7BNPTdm003881; Wed, 12 Aug 2009 01:25:29 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7BNPS1t003878; Wed, 12 Aug 2009 01:25:28 +0200 (CEST) (envelope-from arno) To: Kip Macy From: "Arno J. Klaassen" References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> Date: Wed, 12 Aug 2009 01:25:27 +0200 In-Reply-To: <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> (Kip Macy's message of "Tue\, 11 Aug 2009 12\:35\:18 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV 0.94.2/9677/Tue Aug 11 15:25:47 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A81FDEA.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A81FDEA.004/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: Ed Schouten , current@freebsd.org, Robert Noland , Julian Elischer Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 23:25:55 -0000 Kip Macy writes: > Please try the following patch: > > http://people.freebsd.org/~kmacy/flowtable_boot.patch yeah, this works over here. Thank you very much. Just for completeness, here is my local patch; apart from the parenthesis issue I also needed to add the=20 #define V_flowtable_ready VNET(flowtable_ready) in order to make it compile Best regards, Arno ### Index: net/flowtable.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- net/flowtable.c (revision 196087) +++ net/flowtable.c (working copy) @@ -203,8 +203,10 @@ static VNET_DEFINE(int, flowtable_fin_wait_expire) =3D FIN_WAIT_IDLE; static VNET_DEFINE(int, flowtable_tcp_expire) =3D TCP_IDLE; static VNET_DEFINE(int, flowtable_nmbflows) =3D 4096; +static VNET_DEFINE(int, flowtable_ready) =3D 0; =20 #define V_flowtable_enable VNET(flowtable_enable) +#define V_flowtable_ready VNET(flowtable_ready) #define V_flowtable_hits VNET(flowtable_hits) #define V_flowtable_lookups VNET(flowtable_lookups) #define V_flowtable_misses VNET(flowtable_misses) @@ -345,7 +347,7 @@ struct udphdr *uh; struct sctphdr *sh; =20 - if (V_flowtable_enable =3D=3D 0) + if ((V_flowtable_enable =3D=3D 0) || (V_flowtable_ready =3D=3D 0)) return (0); =20 key[1] =3D key[0] =3D 0; @@ -799,6 +801,7 @@ NULL, NULL, NULL, NULL, 64, UMA_ZONE_MAXBUCKET);=09 uma_zone_set_max(V_flow_ipv4_zone, V_flowtable_nmbflows); uma_zone_set_max(V_flow_ipv6_zone, V_flowtable_nmbflows); + V_flowtable_ready =3D 1; } =20 VNET_SYSINIT(flowtable_init, SI_SUB_KTHREAD_INIT, SI_ORDER_ANY, > > > On Tue, Aug 11, 2009 at 9:27 AM, Arno J. > Klaassen wrote: >> >> Robert Noland writes: >> >>> On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >>>> Hello, >>>> >>>> I get the following panic when pxebooting a 8.0-BETA2 on a >>>> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >>>> and I defined CPUTYPE?=3Dpentiumpro in make.conf. >>>> >>>> Let me know what I can provide more as info to get around this. >>> >>> I've seen this as well. =A0You can disable apic which I see has been >>> suggested. =A0The NMI seems to be generated by HWPMC_HOOKS, in my case >>> removing it from the GENERIC config allows it to boot and use apic. =A0= I'm >>> not certain what the correct fix is, but after talking to jkoshy@ we did >>> find the specific point in the HWPMC_HOOKS code that triggers this, >>> which can be disabled by testing for CPU_VENDOR_CENTAUR. >>> >>> The attached hack should get things booting... >> >> >> Correct. It now boots OK with apic enabled (but still panics >> at the 'flowtable bug'). >> Thanks. >> >> Arno >> >> >>> robert. >>> >>>> Thanks in advance. >>>> >>>> Best, Arno >>>> >>>> >>>> >>>> ##### >>>> >>>> OK boot -sv >>>> KDB: debugger backends: ddb >>>> KDB: current backend: ddb >>>> SMAP type=3D01 base=3D0000000000000000 len=3D000000000009f800 >>>> SMAP type=3D02 base=3D000000000009f800 len=3D0000000000000800 >>>> SMAP type=3D02 base=3D00000000000f0000 len=3D0000000000010000 >>>> SMAP type=3D01 base=3D0000000000100000 len=3D000000007bde0000 >>>> SMAP type=3D04 base=3D000000007bee0000 len=3D0000000000003000 >>>> SMAP type=3D03 base=3D000000007bee3000 len=3D000000000000d000 >>>> SMAP type=3D02 base=3D000000007bef0000 len=3D0000000000010000 >>>> SMAP type=3D02 base=3D00000000e0000000 len=3D0000000010000000 >>>> SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000001000 >>>> SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 >>>> SMAP type=3D02 base=3D00000000ffff0000 len=3D0000000000010000 >>>> Copyright (c) 1992-2009 The FreeBSD Project. >>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 >>>> =A0 =A0 =A0 =A0 The Regents of the University of California. All right= s reserved. >>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>> FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >>>> =A0 =A0 toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >>>> WARNING: WITNESS option enabled, expect reduced performance. >>>> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >>>> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >>>> =A0 =A0 =A0 =A0 MEMGUARD map base: 0xc4c00000 >>>> =A0 =A0 =A0 =A0 MEMGUARD map limit: 0xc6c01000 >>>> =A0 =A0 =A0 =A0 MEMGUARD map size: 33558528 (Bytes) >>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>> Calibrating TSC clock ... TSC clock: 999896638 Hz >>>> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >>>> =A0 Origin =3D "CentaurHauls" =A0Id =3D 0x6d0 =A0Stepping =3D 0 >>>> =A0 Features=3D0xa7c9bbff >>>> =A0 Features2=3D0x4181 >>>> =A0 VIA Padlock Features=3D0xffcc >>>> real memory =A0=3D 2079195136 (1982 MB) >>>> Physical memory chunk(s): >>>> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >>>> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >>>> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 page= s) >>>> avail memory =3D 2027855872 (1933 MB) >>>> Table 'FACP' at 0x7bee3080 >>>> Table 'MCFG' at 0x7bee6ec0 >>>> Table 'APIC' at 0x7bee6e40 >>>> MADT: Found table at 0x7bee6e40 >>>> MP Configuration Table version 1.4 found at 0xc00f1ce0 >>>> APIC: Using the MADT enumerator. >>>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >>>> SMP: Added CPU 0 (AP) >>>> ACPI APIC Table: >>>> APIC: CPU 0 has ACPI ID 0 >>>> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >>>> bios32: Entry =3D 0xf9580 (c00f9580) =A0Rev =3D 0 =A0Len =3D 1 >>>> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >>>> pnpbios: Found PnP BIOS data at 0xc00fa110 >>>> pnpbios: Entry =3D f0000:a140 =A0Rev =3D 1.0 >>>> Other BIOS signatures found: >>>> ULE: setup cpu 0 >>>> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >>>> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 000000= 00) >>>> ACPI: FACP 0x7bee3080 00074 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 000000= 00) >>>> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 =A0AWRDACPI 00001000 MSFT 030000= 00) >>>> ACPI: FACS 0x7bee0000 00040 >>>> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 =A0AWRDACPI 42302E31 AWRD 000000= 00) >>>> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 000000= 00) >>>> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >>>> ioapic0: Routing external 8259A's -> intpin 0 >>>> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >>>> MADT: Interrupt override: source 0, irq 2 >>>> ioapic0: Routing IRQ 0 -> intpin 2 >>>> MADT: Interrupt override: source 9, irq 9 >>>> ioapic0: intpin 9 trigger: level >>>> ioapic0: intpin 9 polarity: low >>>> lapic0: Routing NMI -> LINT1 >>>> lapic0: LINT1 trigger: edge >>>> lapic0: LINT1 polarity: high >>>> ioapic0 irqs 0-23 on motherboard >>>> ioapic1 irqs 24-47 on motherboard >>>> cpu0 BSP: >>>> =A0 =A0 =A0ID: 0x00000000 =A0 VER: 0x00050014 LDR: 0x00000000 DFR: 0xf= fffffff >>>> =A0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >>>> =A0 timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >>>> null: >>>> nfslock: pseudo-device >>>> random: >>>> io: >>>> kbd: new array size 4 >>>> kbd1 at kbdmux0 >>>> mem: >>>> npx0: INT 16 interface >>>> acpi0: on motherboard >>>> PCIe: Memory Mapped configuration base @ 0xe0000000 >>>> pcibios: BIOS version 3.00 >>>> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >>>> acpi0: [MPSAFE] >>>> acpi0: [ITHREAD] >>>> acpi0: Power Button (fixed) >>>> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >>>> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >>>> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >>>> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >>>> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >>>> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >>>> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >>>> acpi0: reservation of 0, a0000 (3) failed >>>> acpi0: reservation of 100000, 7bde0000 (3) failed >>>> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>> pci_link0: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 10 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 10 =A0 N =A0 =A0 0 =A03 4 6 7 = 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> pci_link1: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 = 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> pci_link2: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 =A07 =A0 N =A0 =A0 0 =A03 4 6 7 10= 11 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 =A07 =A0 N =A0 =A0 0 =A03 4 6 = 7 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> pci_link3: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 =A05 =A0 N =A0 =A0 0 =A03 4 6 7 10= 11 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 = 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> pci_link4: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 = 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> pci_link5: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 = 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> pci_link6: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 = 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> pci_link7: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 = 10 11 12 >>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 1= 1 12 >>>> acpi_button0: on acpi0 >>>> acpi_button1: on acpi0 >>>> pcib0: port 0xcf8-0xcff on acpi0 >>>> pci0: on pcib0 >>>> pci0: domain=3D0, physical bus=3D0 >>>> found-> vendor=3D0x1106, dev=3D0x0353, revid=3D0x11 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x08 (240 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x1353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D1 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x2353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D2 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x3353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D3 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D0 (dwor= ds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x4353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D4 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x5353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D5 >>>> =A0 =A0 =A0 =A0 class=3D08-00-20, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0000, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x6353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D6 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0000, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x7353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D7 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x1122, revid=3D0x11 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D1, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x3010, cachelnsz=3D0 (dwor= ds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 MSI supports 1 message >>>> =A0 =A0 =A0 =A0 map[10]: type Prefetchable Memory, range 32, base 0xd8= 000000, size 26, enabled >>>> =A0 =A0 =A0 =A0 map[14]: type Memory, range 32, base 0xde000000, size = 24, enabled >>>> =A0 =A0 =A0 =A0 map[18]: type Memory, range 32, base 0xc0000000, size = 28, enabled >>>> pcib0: matched entry for 0.1.INTA >>>> pcib0: slot 1 INTA hardwired to IRQ 16 >>>> found-> vendor=3D0x1106, dev=3D0xc353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D2, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxla= t=3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D11 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>>> pcib0: matched entry for 0.2.INTA >>>> pcib0: slot 2 INTA hardwired to IRQ 27 >>>> found-> vendor=3D0x1106, dev=3D0xe353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D3, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxla= t=3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D11 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>>> pcib0: matched entry for 0.3.INTA >>>> pcib0: slot 3 INTA hardwired to IRQ 31 >>>> found-> vendor=3D0x1106, dev=3D0xf353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D3, func=3D1 >>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxla= t=3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Db, irq=3D11 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>>> pcib0: matched entry for 0.3.INTB >>>> pcib0: slot 3 INTB hardwired to IRQ 39 >>>> found-> vendor=3D0x1106, dev=3D0x5324, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D15, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwor= ds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xfc00, size = =A04, enabled >>>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0218, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf800, size = =A05, enabled >>>> pcib0: matched entry for 0.16.INTA >>>> pcib0: slot 16 INTA hardwired to IRQ 20 >>>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D1 >>>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Db, irq=3D11 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf400, size = =A05, enabled >>>> pcib0: matched entry for 0.16.INTB >>>> pcib0: slot 16 INTB hardwired to IRQ 22 >>>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D2 >>>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Dc, irq=3D7 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf000, size = =A05, enabled >>>> pcib0: matched entry for 0.16.INTC >>>> pcib0: slot 16 INTC hardwired to IRQ 21 >>>> found-> vendor=3D0x1106, dev=3D0x3104, revid=3D0x90 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D4 >>>> =A0 =A0 =A0 =A0 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Dd, irq=3D5 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 map[10]: type Memory, range 32, base 0xdffff000, size = =A08, enabled >>>> pcib0: matched entry for 0.16.INTD >>>> pcib0: slot 16 INTD hardwired to IRQ 23 >>>> found-> vendor=3D0x1106, dev=3D0x8353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D17, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0003, statreg=3D0x0210, cachelnsz=3D0 (dwor= ds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>> found-> vendor=3D0x1106, dev=3D0xa353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D17, func=3D7 >>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0000, statreg=3D0x2200, cachelnsz=3D0 (dwor= ds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0xb353, revid=3D0x00 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D19, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x2010, cachelnsz=3D0 (dwor= ds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxla= t=3D0x00 (0 ns) >>>> found-> vendor=3D0x1106, dev=3D0x3288, revid=3D0x10 >>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D20, func=3D0 >>>> =A0 =A0 =A0 =A0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 >>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwo= rds) >>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit >>>> =A0 =A0 =A0 =A0 map[10]: type Memory, range 64, base 0xdfff8000, size = 14, enabled >>>> pcib0: matched entry for 0.20.INTA >>>> pcib0: slot 20 INTA hardwired to IRQ 17 >>>> NMI ISA 3c, EISA 0 >>>> NMI ... going to debugger >>>> [thread pid 0 tid 100000 ] >>>> Stopped at =A0 =A0 =A00xc060098f =3D vsscanf+0x98f: =A0 =A0 movl =A0 = =A0%edx,0xfffffe8c(%ebp) >>>> db> ps >>>> =A0 pid =A0ppid =A0pgrp =A0 uid =A0 state =A0 wmesg =A0 =A0 wchan =A0 = =A0cmd >>>> =A0 =A0 5 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[xpt_thrd] >>>> =A0 =A0 4 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_down] >>>> =A0 =A0 3 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_up] >>>> =A0 =A0 2 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_event] >>>> =A0 =A012 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0WL =A0 =A0 =A0(threaded) = =A0 =A0 =A0 =A0 =A0intr >>>> 100021 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [irq9: acpi0] >>>> 100016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi2: cambio] >>>> 100014 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi6: task queue] >>>> 100013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi6: Giant taskq] >>>> 100011 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi5: +] >>>> 100006 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi1: netisr 0] >>>> 100005 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi4: clock] >>>> 100004 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi3: vm] >>>> =A0 =A011 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[idle: cpu0] >>>> =A0 =A0 1 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0?L =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[kernel] >>>> =A0 =A010 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[audit] >>>> =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RLs =A0 =A0 (threaded) =A0 = =A0 =A0 =A0 =A0kernel >>>> 100020 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_2] >>>> 100019 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_1] >>>> 100018 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_0] >>>> 100017 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[kqueue taskq] >>>> 100012 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[thread taskq] >>>> 100010 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[firmware taskq] >>>> 100000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Run =A0 =A0 CPU 0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [swapper] >>>> db> where >>>> Tracing pid 0 tid 100000 td 0xc0934590 >>>> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc060098= f =3D vsscanf+0x98f >>>> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a22= =3D sscanf+0x22 >>>> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 =3D res_find+0x319 >>>> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda =3D resource_= find+0x5a >>>> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0x= c05f8041 =3D resource_string_value+0x61 >>>> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0x= c05f071e =3D devclass_add_device+0x16e >>>> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...) = at 0xc05f16af =3D device_set_devclass+0x6f >>>> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc05= f3e6b =3D device_probe_child+0xfb >>>> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc0= 5f4160 =3D device_probe+0xa0 >>>> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at = 0xc05f4238 =3D device_probe_and_attach+0x48 >>>> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) a= t 0xc05f42a8 =3D bus_generic_attach+0x48 >>>> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at 0= xc04b275c =3D acpi_pci_attach+0x18c >>>> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 =3D d= evice_attach+0x3b7 >>>> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,.= ..) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>>> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc05= f42a8 =3D bus_generic_attach+0x48 >>>> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 =3D= acpi_pcib_attach+0x1a1 >>>> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,...= ) at 0xc04b54a1 =3D acpi_pcib_acpi_attach+0x251 >>>> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 =3D d= evice_attach+0x3b7 >>>> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,.= ..) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>>> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) a= t 0xc05f42a8 =3D bus_generic_attach+0x48 >>>> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc04= aa1ae =3D acpi_attach+0xbbe >>>> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 =3D device_a= ttach+0x3b7 >>>> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at = 0xc05f4255 =3D device_probe_and_attach+0x65 >>>> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 =3D bus_generi= c_attach+0x48 >>>> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) at= 0xc081caae =3D nexus_acpi_attach+0x7e >>>> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 =3D device_at= tach+0x3b7 >>>> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,.= ..) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>>> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...) = at 0xc05f449d =3D bus_generic_new_pass+0xcd >>>> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc05= f2341 =3D bus_set_pass+0x81 >>>> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f23= 92 =3D root_bus_configure+0x12 >>>> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc =3D configu= re+0xc >>>> mi_startup() at 0xc05839d6 =3D mi_startup+0xa6 >>>> begin() at 0xc0453005 =3D begin+0x2c >>>> db> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> >> -- >> >> =A0Arno J. Klaassen >> >> =A0SCITO S.A. >> =A08 rue des Haies >> =A0F-75020 Paris, France >> =A0http://scito.com >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> --=20 Arno J. Klaassen SCITO S.A. 8 rue des Haies F-75020 Paris, France http://scito.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 11 23:55:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C9E1065673 for ; Tue, 11 Aug 2009 23:55:09 +0000 (UTC) (envelope-from cjk@home.kreklow.us) Received: from srv.home.kreklow.us (cjkreklow-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:59f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6B80D8FC39 for ; Tue, 11 Aug 2009 23:55:08 +0000 (UTC) Received: by srv.home.kreklow.us (Postfix, from userid 1000) id C135C43EE08; Tue, 11 Aug 2009 18:55:07 -0500 (CDT) Date: Tue, 11 Aug 2009 18:55:07 -0500 From: Collin Kreklow To: Robert Message-ID: <20090811235507.GA33894@srv.home.kreklow.us> References: <20090807165850.3e8541f8@vaio> <4A7DA0DF.50107@errno.com> <20090808134101.44d7d210@vaio> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090808134101.44d7d210@vaio> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org Subject: Re: LOR wlan0 wi0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 23:55:09 -0000 On Sat, Aug 08, 2009 at 01:41:01PM -0700, Robert wrote: > > The interface card is old. It shows to be a Netgear MA401. I have > ordered a newer model of the Netgear card. It is a WG511T which is > supposed to have an atheros chipset. I should receive this card in about > a week. I really do not know if any of this is relevant to my problem. > FWIW, I've found the WG511T and it's PCI sibling WG311T to be some of the most stable wireless cards available under FreeBSD. The ath driver is very capable with these cards. I've recently had bad experiences with ipw, wpi, and ral based cards prompting me to pick up a few spare 311s for my AP "just in case." I think you won't be disappointed. - Collin From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 05:07:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C222F106564A; Wed, 12 Aug 2009 05:07:49 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 4445B8FC41; Wed, 12 Aug 2009 05:07:49 +0000 (UTC) Received: by yxe11 with SMTP id 11so5707699yxe.3 for ; Tue, 11 Aug 2009 22:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=wOUcvU1cLZS4mEDrS2rV3bt0SWatjIwft/CYcPMSc5U=; b=JgHgx3FVtpE/6G+WhasYJ8t1SIrldHBYfUPQYZ/+0gHqMX87AnU6uNzpz0sUGmfSUS 5zDuRfOVHauzPu5mOMXLUY+w9u2A00UWpUVfFs24VgsP52mhvcouHTQlbdnSyKz4C7+z jbxjE3ISNRuwm9JlvH6HXGJOc/+/H0CWCJc60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=JsYD1Ed8zOAIcdZreI+/WC7JX7xvQ/loPCughuB7rcuThI/uLTJTd6qFKeXbCil3YN jXgIBZVl8YVggyFID0jz6xcvDyAOIx/Oz3crdI8O7k6q0FXhdd5huFKCvaxkzrPvQnNV H4bB49n4douFx50+xmg+fU5bNxpY9a464lhkM= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.38.17 with SMTP id l17mr6422108anl.62.1250053667657; Tue, 11 Aug 2009 22:07:47 -0700 (PDT) In-Reply-To: References: <1250004330.1773.223.camel@balrog.2hip.net> <3c1674c90908111235m158227a3q86af8b1d7235a7a2@mail.gmail.com> Date: Tue, 11 Aug 2009 22:07:47 -0700 X-Google-Sender-Auth: 051305b66ec506db Message-ID: <3c1674c90908112207k7aa4ce4age21ce6538d7e5367@mail.gmail.com> From: Kip Macy To: "Arno J. Klaassen" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ed Schouten , current@freebsd.org, Robert Noland , Julian Elischer Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 05:07:50 -0000 The patch on freefall was updated to have that earlier today. I'll pass it on to re@ Thanks, Kip On Tue, Aug 11, 2009 at 4:25 PM, Arno J. Klaassen wrote: > Kip Macy writes: > >> Please try the following patch: >> >> http://people.freebsd.org/~kmacy/flowtable_boot.patch > > yeah, this works over here. Thank you very much. > > Just for completeness, here is my local patch; apart > from the parenthesis issue I also needed to add > the > =A0#define V_flowtable_ready VNET(flowtable_ready) > in order to make it compile > > Best regards, > > Arno > > ### > Index: net/flowtable.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- net/flowtable.c =A0 =A0 (revision 196087) > +++ net/flowtable.c =A0 =A0 (working copy) > @@ -203,8 +203,10 @@ > =A0static VNET_DEFINE(int, flowtable_fin_wait_expire) =3D FIN_WAIT_IDLE; > =A0static VNET_DEFINE(int, flowtable_tcp_expire) =3D TCP_IDLE; > =A0static VNET_DEFINE(int, flowtable_nmbflows) =3D 4096; > +static VNET_DEFINE(int, flowtable_ready) =3D 0; > > =A0#define =A0 =A0 =A0 =A0V_flowtable_enable =A0 =A0 =A0 =A0 =A0 =A0 =A0V= NET(flowtable_enable) > +#define =A0 =A0 =A0 =A0V_flowtable_ready =A0 =A0 =A0 =A0 =A0 =A0 =A0 VNE= T(flowtable_ready) > =A0#define =A0 =A0 =A0 =A0V_flowtable_hits =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0VNET(flowtable_hits) > =A0#define =A0 =A0 =A0 =A0V_flowtable_lookups =A0 =A0 =A0 =A0 =A0 =A0 VNE= T(flowtable_lookups) > =A0#define =A0 =A0 =A0 =A0V_flowtable_misses =A0 =A0 =A0 =A0 =A0 =A0 =A0V= NET(flowtable_misses) > @@ -345,7 +347,7 @@ > =A0 =A0 =A0 =A0struct udphdr *uh; > =A0 =A0 =A0 =A0struct sctphdr *sh; > > - =A0 =A0 =A0 if (V_flowtable_enable =3D=3D 0) > + =A0 =A0 =A0 if ((V_flowtable_enable =3D=3D 0) || (V_flowtable_ready =3D= =3D 0)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); > > =A0 =A0 =A0 =A0key[1] =3D key[0] =3D 0; > @@ -799,6 +801,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0NULL, NULL, NULL, NULL, 64, UMA_ZONE_MAXBUCKET); > =A0 =A0 =A0 =A0uma_zone_set_max(V_flow_ipv4_zone, V_flowtable_nmbflows); > =A0 =A0 =A0 =A0uma_zone_set_max(V_flow_ipv6_zone, V_flowtable_nmbflows); > + =A0 =A0 =A0 V_flowtable_ready =3D 1; > =A0} > > =A0VNET_SYSINIT(flowtable_init, SI_SUB_KTHREAD_INIT, SI_ORDER_ANY, > >> >> >> On Tue, Aug 11, 2009 at 9:27 AM, Arno J. >> Klaassen wrote: >>> >>> Robert Noland writes: >>> >>>> On Mon, 2009-08-10 at 18:40 +0200, Arno J. Klaassen wrote: >>>>> Hello, >>>>> >>>>> I get the following panic when pxebooting a 8.0-BETA2 on a >>>>> VIA-C7-MB. The kernel is cross-build from a clean amd64-7-stable >>>>> and I defined CPUTYPE?=3Dpentiumpro in make.conf. >>>>> >>>>> Let me know what I can provide more as info to get around this. >>>> >>>> I've seen this as well. =A0You can disable apic which I see has been >>>> suggested. =A0The NMI seems to be generated by HWPMC_HOOKS, in my case >>>> removing it from the GENERIC config allows it to boot and use apic. = =A0I'm >>>> not certain what the correct fix is, but after talking to jkoshy@ we d= id >>>> find the specific point in the HWPMC_HOOKS code that triggers this, >>>> which can be disabled by testing for CPU_VENDOR_CENTAUR. >>>> >>>> The attached hack should get things booting... >>> >>> >>> Correct. It now boots OK with apic enabled (but still panics >>> at the 'flowtable bug'). >>> Thanks. >>> >>> Arno >>> >>> >>>> robert. >>>> >>>>> Thanks in advance. >>>>> >>>>> Best, Arno >>>>> >>>>> >>>>> >>>>> ##### >>>>> >>>>> OK boot -sv >>>>> KDB: debugger backends: ddb >>>>> KDB: current backend: ddb >>>>> SMAP type=3D01 base=3D0000000000000000 len=3D000000000009f800 >>>>> SMAP type=3D02 base=3D000000000009f800 len=3D0000000000000800 >>>>> SMAP type=3D02 base=3D00000000000f0000 len=3D0000000000010000 >>>>> SMAP type=3D01 base=3D0000000000100000 len=3D000000007bde0000 >>>>> SMAP type=3D04 base=3D000000007bee0000 len=3D0000000000003000 >>>>> SMAP type=3D03 base=3D000000007bee3000 len=3D000000000000d000 >>>>> SMAP type=3D02 base=3D000000007bef0000 len=3D0000000000010000 >>>>> SMAP type=3D02 base=3D00000000e0000000 len=3D0000000010000000 >>>>> SMAP type=3D02 base=3D00000000fec00000 len=3D0000000000001000 >>>>> SMAP type=3D02 base=3D00000000fee00000 len=3D0000000000001000 >>>>> SMAP type=3D02 base=3D00000000ffff0000 len=3D0000000000010000 >>>>> Copyright (c) 1992-2009 The FreeBSD Project. >>>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1= 994 >>>>> =A0 =A0 =A0 =A0 The Regents of the University of California. All righ= ts reserved. >>>>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>>>> FreeBSD 8.0-BETA2 #1 r196087M: Mon Aug 10 15:16:20 CEST 2009 >>>>> =A0 =A0 toor@push:/raid1/obj/i386/raid1/bsd/8/src/sys/C7-FW >>>>> WARNING: WITNESS option enabled, expect reduced performance. >>>>> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >>>>> MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: >>>>> =A0 =A0 =A0 =A0 MEMGUARD map base: 0xc4c00000 >>>>> =A0 =A0 =A0 =A0 MEMGUARD map limit: 0xc6c01000 >>>>> =A0 =A0 =A0 =A0 MEMGUARD map size: 33558528 (Bytes) >>>>> Preloaded elf kernel "/boot/kernel/kernel" at 0xc0bdc000. >>>>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>>>> Calibrating TSC clock ... TSC clock: 999896638 Hz >>>>> CPU: VIA C7 Processor 1000MHz (999.90-MHz 686-class CPU) >>>>> =A0 Origin =3D "CentaurHauls" =A0Id =3D 0x6d0 =A0Stepping =3D 0 >>>>> =A0 Features=3D0xa7c9bbff >>>>> =A0 Features2=3D0x4181 >>>>> =A0 VIA Padlock Features=3D0xffcc >>>>> real memory =A0=3D 2079195136 (1982 MB) >>>>> Physical memory chunk(s): >>>>> 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) >>>>> 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) >>>>> 0x0000000000c26000 - 0x0000000079baffff, 2029559808 bytes (495498 pag= es) >>>>> avail memory =3D 2027855872 (1933 MB) >>>>> Table 'FACP' at 0x7bee3080 >>>>> Table 'MCFG' at 0x7bee6ec0 >>>>> Table 'APIC' at 0x7bee6e40 >>>>> MADT: Found table at 0x7bee6e40 >>>>> MP Configuration Table version 1.4 found at 0xc00f1ce0 >>>>> APIC: Using the MADT enumerator. >>>>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >>>>> SMP: Added CPU 0 (AP) >>>>> ACPI APIC Table: >>>>> APIC: CPU 0 has ACPI ID 0 >>>>> bios32: Found BIOS32 Service Directory header at 0xc00f8f70 >>>>> bios32: Entry =3D 0xf9580 (c00f9580) =A0Rev =3D 0 =A0Len =3D 1 >>>>> pcibios: PCI BIOS entry at 0xf0000+0x95d0 >>>>> pnpbios: Found PnP BIOS data at 0xc00fa110 >>>>> pnpbios: Entry =3D f0000:a140 =A0Rev =3D 1.0 >>>>> Other BIOS signatures found: >>>>> ULE: setup cpu 0 >>>>> ACPI: RSDP 0xf79d0 00014 (v0 VX800 ) >>>>> ACPI: RSDT 0x7bee3000 00030 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 00000= 000) >>>>> ACPI: FACP 0x7bee3080 00074 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 00000= 000) >>>>> ACPI: DSDT 0x7bee3100 03D16 (v1 VX800 =A0AWRDACPI 00001000 MSFT 03000= 000) >>>>> ACPI: FACS 0x7bee0000 00040 >>>>> ACPI: MCFG 0x7bee6ec0 0003C (v1 VX800 =A0AWRDACPI 42302E31 AWRD 00000= 000) >>>>> ACPI: APIC 0x7bee6e40 00066 (v1 VX800 =A0AWRDACPI 42302E31 AWRD 00000= 000) >>>>> MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 >>>>> ioapic0: Routing external 8259A's -> intpin 0 >>>>> MADT: Found IO APIC ID 3, Interrupt 24 at 0xfecc0000 >>>>> MADT: Interrupt override: source 0, irq 2 >>>>> ioapic0: Routing IRQ 0 -> intpin 2 >>>>> MADT: Interrupt override: source 9, irq 9 >>>>> ioapic0: intpin 9 trigger: level >>>>> ioapic0: intpin 9 polarity: low >>>>> lapic0: Routing NMI -> LINT1 >>>>> lapic0: LINT1 trigger: edge >>>>> lapic0: LINT1 polarity: high >>>>> ioapic0 irqs 0-23 on motherboard >>>>> ioapic1 irqs 24-47 on motherboard >>>>> cpu0 BSP: >>>>> =A0 =A0 =A0ID: 0x00000000 =A0 VER: 0x00050014 LDR: 0x00000000 DFR: 0x= ffffffff >>>>> =A0 lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001= ff >>>>> =A0 timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x000004= 00 >>>>> null: >>>>> nfslock: pseudo-device >>>>> random: >>>>> io: >>>>> kbd: new array size 4 >>>>> kbd1 at kbdmux0 >>>>> mem: >>>>> npx0: INT 16 interface >>>>> acpi0: on motherboard >>>>> PCIe: Memory Mapped configuration base @ 0xe0000000 >>>>> pcibios: BIOS version 3.00 >>>>> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >>>>> acpi0: [MPSAFE] >>>>> acpi0: [ITHREAD] >>>>> acpi0: Power Button (fixed) >>>>> acpi0: wakeup code va 0xc4b9c000 pa 0x1000 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.IDEC.SAPR -> bus 0 dev 15 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.USB1.U2F0 -> bus 0 dev 16 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.USB2.U2F1 -> bus 0 dev 16 func 1 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.USB3.U2F2 -> bus 0 dev 16 func 2 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.EHCI.U2F4 -> bus 0 dev 16 func 4 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.AZAC.AZAR -> bus 0 dev 20 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.PEXG.RPXG -> bus 0 dev 2 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX0.RPX0 -> bus 0 dev 3 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.PEX1.RPX1 -> bus 0 dev 3 func 1 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.P2PB.P2PR -> bus 0 dev 19 func 0 >>>>> AcpiOsDerivePciId: \_SB_.PCI0.VT86.VTSB -> bus 0 dev 17 func 0 >>>>> acpi0: reservation of 0, a0000 (3) failed >>>>> acpi0: reservation of 100000, 7bde0000 (3) failed >>>>> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >>>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >>>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >>>>> pci_link0: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 10 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 10 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> pci_link1: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> pci_link2: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 =A07 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 =A07 =A0 N =A0 =A0 0 =A03 4 6= 7 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> pci_link3: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 =A05 =A0 N =A0 =A0 0 =A03 4 6 7 1= 0 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> pci_link4: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> pci_link5: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> pci_link6: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> pci_link7: =A0 =A0 =A0 =A0Index =A0IRQ =A0Rtd =A0Ref =A0IRQs >>>>> =A0 Initial Probe =A0 =A0 =A0 0 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> =A0 Validation =A0 =A0 =A0 =A0 =A00 =A0 11 =A0 N =A0 =A0 0 =A03 4 6 7= 10 11 12 >>>>> =A0 After Disable =A0 =A0 =A0 0 =A0255 =A0 N =A0 =A0 0 =A03 4 6 7 10 = 11 12 >>>>> acpi_button0: on acpi0 >>>>> acpi_button1: on acpi0 >>>>> pcib0: port 0xcf8-0xcff on acpi0 >>>>> pci0: on pcib0 >>>>> pci0: domain=3D0, physical bus=3D0 >>>>> found-> vendor=3D0x1106, dev=3D0x0353, revid=3D0x11 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x08 (240 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x1353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D1 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x2353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D2 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x3353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D3 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D0 (dwo= rds) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x4353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D4 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x5353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D5 >>>>> =A0 =A0 =A0 =A0 class=3D08-00-20, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0000, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x6353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D6 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0000, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x7353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D0, func=3D7 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0200, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x1122, revid=3D0x11 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D1, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x3010, cachelnsz=3D0 (dwo= rds) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 MSI supports 1 message >>>>> =A0 =A0 =A0 =A0 map[10]: type Prefetchable Memory, range 32, base 0xd= 8000000, size 26, enabled >>>>> =A0 =A0 =A0 =A0 map[14]: type Memory, range 32, base 0xde000000, size= 24, enabled >>>>> =A0 =A0 =A0 =A0 map[18]: type Memory, range 32, base 0xc0000000, size= 28, enabled >>>>> pcib0: matched entry for 0.1.INTA >>>>> pcib0: slot 1 INTA hardwired to IRQ 16 >>>>> found-> vendor=3D0x1106, dev=3D0xc353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D2, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxl= at=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D11 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>>>> pcib0: matched entry for 0.2.INTA >>>>> pcib0: slot 2 INTA hardwired to IRQ 27 >>>>> found-> vendor=3D0x1106, dev=3D0xe353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D3, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxl= at=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D11 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>>>> pcib0: matched entry for 0.3.INTA >>>>> pcib0: slot 3 INTA hardwired to IRQ 31 >>>>> found-> vendor=3D0x1106, dev=3D0xf353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D3, func=3D1 >>>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxl= at=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Db, irq=3D11 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit, vector masks >>>>> pcib0: matched entry for 0.3.INTB >>>>> pcib0: slot 3 INTB hardwired to IRQ 39 >>>>> found-> vendor=3D0x1106, dev=3D0x5324, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D15, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwo= rds) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xfc00, size = =A04, enabled >>>>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0218, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf800, size = =A05, enabled >>>>> pcib0: matched entry for 0.16.INTA >>>>> pcib0: slot 16 INTA hardwired to IRQ 20 >>>>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D1 >>>>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Db, irq=3D11 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf400, size = =A05, enabled >>>>> pcib0: matched entry for 0.16.INTB >>>>> pcib0: slot 16 INTB hardwired to IRQ 22 >>>>> found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0xa0 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D2 >>>>> =A0 =A0 =A0 =A0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Dc, irq=3D7 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 map[20]: type I/O Port, range 32, base 0xf000, size = =A05, enabled >>>>> pcib0: matched entry for 0.16.INTC >>>>> pcib0: slot 16 INTC hardwired to IRQ 21 >>>>> found-> vendor=3D0x1106, dev=3D0x3104, revid=3D0x90 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D16, func=3D4 >>>>> =A0 =A0 =A0 =A0 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Dd, irq=3D5 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D1 D2 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 map[10]: type Memory, range 32, base 0xdffff000, size= =A08, enabled >>>>> pcib0: matched entry for 0.16.INTD >>>>> pcib0: slot 16 INTD hardwired to IRQ 23 >>>>> found-> vendor=3D0x1106, dev=3D0x8353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D17, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0003, statreg=3D0x0210, cachelnsz=3D0 (dwo= rds) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>>> found-> vendor=3D0x1106, dev=3D0xa353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D17, func=3D7 >>>>> =A0 =A0 =A0 =A0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0000, statreg=3D0x2200, cachelnsz=3D0 (dwo= rds) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxla= t=3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0xb353, revid=3D0x00 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D19, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0007, statreg=3D0x2010, cachelnsz=3D0 (dwo= rds) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxl= at=3D0x00 (0 ns) >>>>> found-> vendor=3D0x1106, dev=3D0x3288, revid=3D0x10 >>>>> =A0 =A0 =A0 =A0 domain=3D0, bus=3D0, slot=3D20, func=3D0 >>>>> =A0 =A0 =A0 =A0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 >>>>> =A0 =A0 =A0 =A0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dw= ords) >>>>> =A0 =A0 =A0 =A0 lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat= =3D0x00 (0 ns) >>>>> =A0 =A0 =A0 =A0 intpin=3Da, irq=3D10 >>>>> =A0 =A0 =A0 =A0 powerspec 2 =A0supports D0 D3 =A0current D0 >>>>> =A0 =A0 =A0 =A0 MSI supports 1 message, 64 bit >>>>> =A0 =A0 =A0 =A0 map[10]: type Memory, range 64, base 0xdfff8000, size= 14, enabled >>>>> pcib0: matched entry for 0.20.INTA >>>>> pcib0: slot 20 INTA hardwired to IRQ 17 >>>>> NMI ISA 3c, EISA 0 >>>>> NMI ... going to debugger >>>>> [thread pid 0 tid 100000 ] >>>>> Stopped at =A0 =A0 =A00xc060098f =3D vsscanf+0x98f: =A0 =A0 movl =A0 = =A0%edx,0xfffffe8c(%ebp) >>>>> db> ps >>>>> =A0 pid =A0ppid =A0pgrp =A0 uid =A0 state =A0 wmesg =A0 =A0 wchan =A0= =A0cmd >>>>> =A0 =A0 5 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0[xpt_thrd] >>>>> =A0 =A0 4 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_down] >>>>> =A0 =A0 3 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_up] >>>>> =A0 =A0 2 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0[g_event] >>>>> =A0 =A012 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0WL =A0 =A0 =A0(threaded) = =A0 =A0 =A0 =A0 =A0intr >>>>> 100021 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [irq9: acpi0] >>>>> 100016 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi2: cambio] >>>>> 100014 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi6: task queue] >>>>> 100013 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi6: Giant taskq] >>>>> 100011 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi5: +] >>>>> 100006 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi1: netisr 0] >>>>> 100005 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi4: clock] >>>>> 100004 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 [swi3: vm] >>>>> =A0 =A011 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0[idle: cpu0] >>>>> =A0 =A0 1 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0?L =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0[kernel] >>>>> =A0 =A010 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RL =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0[audit] >>>>> =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 0 =A0RLs =A0 =A0 (threaded) =A0= =A0 =A0 =A0 =A0kernel >>>>> 100020 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_2] >>>>> 100019 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_1] >>>>> 100018 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[acpi_task_0] >>>>> 100017 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[kqueue taskq] >>>>> 100012 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[thread taskq] >>>>> 100010 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 RunQ =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0[firmware taskq] >>>>> 100000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Run =A0 =A0 CPU 0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 [swapper] >>>>> db> where >>>>> Tracing pid 0 tid 100000 td 0xc0934590 >>>>> vsscanf(c6ce5440,c089c6a3,c0c207b0,c0c207b0,c0c208c4,...) at 0xc06009= 8f =3D vsscanf+0x98f >>>>> sscanf(c6ce5440,c089c6a3,c0c20894,c0c207f0,c0c20874,...) at 0xc0600a2= 2 =3D sscanf+0x22 >>>>> res_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7ba9 =3D res_find+0x31= 9 >>>>> resource_find(c0c20940,c089252b,0,0,0,...) at 0xc05f7eda =3D resource= _find+0x5a >>>>> resource_string_value(c6d117b0,2,c089252b,c0c20964,ffffffff,...) at 0= xc05f8041 =3D resource_string_value+0x61 >>>>> devclass_add_device(101,c6d0acc0,c6dffb80,c0c209c0,c05f3e6b,...) at 0= xc05f071e =3D devclass_add_device+0x16e >>>>> device_set_devclass(c6dffb80,c08852dc,c089d6c5,c6dffbbc,c6dffbbc,...)= at 0xc05f16af =3D device_set_devclass+0x6f >>>>> device_probe_child(c6dff780,c6dffb80,0,c6d11780,c6dffb80,...) at 0xc0= 5f3e6b =3D device_probe_child+0xfb >>>>> device_probe(c6dffb80,c0c20a1c,c048ebcc,c091efd4,c6dffb80,...) at 0xc= 05f4160 =3D device_probe+0xa0 >>>>> device_probe_and_attach(c6dffb80,c6dff780,0,c6df3080,c6df3080,...) at= 0xc05f4238 =3D device_probe_and_attach+0x48 >>>>> bus_generic_attach(c6dff780,c6dd86c0,1,c04b21a0,c6dff780,0,c6dd86c0) = at 0xc05f42a8 =3D bus_generic_attach+0x48 >>>>> acpi_pci_attach(c6dff780,c6dba05c,c08e9428,c089bed4,80000000,...) at = 0xc04b275c =3D acpi_pci_attach+0x18c >>>>> device_attach(c6dff780,c6d10e88,c6d10e88,c6df3080) at 0xc05f34c7 =3D = device_attach+0x3b7 >>>>> device_probe_and_attach(c6dff780,c04b4680,c6d77000,c6df3080,c6d77000,= ...) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>>>> bus_generic_attach(c6df3080,c08c3e86,0,c0c20ae0,c6dd86c0,...) at 0xc0= 5f42a8 =3D bus_generic_attach+0x48 >>>>> acpi_pcib_attach(c6df3080,c6de82d4,0,c0c20b10,2,...) at 0xc04b4911 = =3D acpi_pcib_attach+0x1a1 >>>>> acpi_pcib_acpi_attach(c6df3080,c6d8a85c,c08e9428,c089bed4,80000000,..= .) at 0xc04b54a1 =3D acpi_pcib_acpi_attach+0x251 >>>>> device_attach(c6df3080,c0c20b84,c05f8cd1,c6d19ca0) at 0xc05f34c7 =3D = device_attach+0x3b7 >>>>> device_probe_and_attach(c6df3080,c08e9418,fffeffff,c6dd1900,fffeffff,= ...) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>>>> bus_generic_attach(c6d77000,fff80000,fffeffff,c6deb468,fff80000,...) = at 0xc05f42a8 =3D bus_generic_attach+0x48 >>>>> acpi_attach(c6d77000,c6d8385c,c08e9428,c089bed4,80000000,...) at 0xc0= 4aa1ae =3D acpi_attach+0xbbe >>>>> device_attach(c6d77000,c6ce4c50,0,c6d77500) at 0xc05f34c7 =3D device_= attach+0x3b7 >>>>> device_probe_and_attach(c6d77000,c087ebd2,0,c6d77500,c6d77500,...) at= 0xc05f4255 =3D device_probe_and_attach+0x65 >>>>> bus_generic_attach(c6d77500,a,c087ebd2,0) at 0xc05f42a8 =3D bus_gener= ic_attach+0x48 >>>>> nexus_acpi_attach(c6d77500,c6da785c,c08e9428,c089bed4,80000000,...) a= t 0xc081caae =3D nexus_acpi_attach+0x7e >>>>> device_attach(c6d77500,c089df99,184,20000) at 0xc05f34c7 =3D device_a= ttach+0x3b7 >>>>> device_probe_and_attach(c6d77500,c6d77c80,c6d77c80,c6d19100,c6d77c80,= ...) at 0xc05f4255 =3D device_probe_and_attach+0x65 >>>>> bus_generic_new_pass(c6d77c80,c6d79000,c08e9368,c08cf034,fffffff,...)= at 0xc05f449d =3D bus_generic_new_pass+0xcd >>>>> bus_set_pass(7fffffff,c0c20d6c,c081efdc,fffffff,c0c20d88,...) at 0xc0= 5f2341 =3D bus_set_pass+0x81 >>>>> root_bus_configure(fffffff,c0c20d88,c05839d6,0,c1ec00,...) at 0xc05f2= 392 =3D root_bus_configure+0x12 >>>>> configure(0,c1ec00,c1ec00,c1e000,c25000,...) at 0xc081efdc =3D config= ure+0xc >>>>> mi_startup() at 0xc05839d6 =3D mi_startup+0xa6 >>>>> begin() at 0xc0453005 =3D begin+0x2c >>>>> db> >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" >>> >>> -- >>> >>> =A0Arno J. Klaassen >>> >>> =A0SCITO S.A. >>> =A08 rue des Haies >>> =A0F-75020 Paris, France >>> =A0http://scito.com >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >>> > > -- > > =A0Arno J. Klaassen > > =A0SCITO S.A. > =A08 rue des Haies > =A0F-75020 Paris, France > =A0http://scito.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 12:29:36 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EA82106567B for ; Wed, 12 Aug 2009 12:29:36 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id F02638FC57 for ; Wed, 12 Aug 2009 12:29:35 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A642446B35 for ; Wed, 12 Aug 2009 08:29:35 -0400 (EDT) Date: Wed, 12 Aug 2009 13:29:35 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 12:29:36 -0000 Dear all: As we're approaching 8.0 BETA3, now would be a really good time to start identifying functional and performance regressions from the 7.x series. We've done a mixed job at this in the past, but when it comes to "I'll do better some day", there's no time like the present :-). Some notes: Functional testing We actually have a sizable regression test suite in src/tools/regression -- some of these tools will have broken as a result of 8-CURRENT development, so the first task may be to fix them. The next is to run them on 7-STABLE and 8-CURRENT and decide if things have gotten worse -- or maybe we have a bug to fix in both. Pick the tool of your choice, and give it a spin. More than one person per tool is fine, because that way we get more diverse testing. Performance testing On the performance front, life is always a bit more tricky -- performance testing is a subtle art. However, the most clear lessons are that (a) testing with diverse workloads and diverse environments is extremely important, (b) you should do multiple runs and use ministat(1) to analyze results, and (c) that you want to compare apples with apples -- use the same hardware/configuration wherever possible. Watch out for annoying nits such as partition layout affecting I/O throughput for two different installs on the same disk. Pick something you think is important to you: bytes/sec over TCP on loopback, web hits/sec, NFS ops/sec, disk I/O transactions/sec, and do some comparison between 7.2 and 8.0. If you find improvement -- great! If you find a regression, please start a thread on current@ to help get it diagnosed. And if you want help doing performance measurement for a particular workload that isn't well studied, send some e-mail to performance@ to ask for advice on how best to measure it. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 13:02:04 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B1A01065672 for ; Wed, 12 Aug 2009 13:02:04 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id C62C18FC5E for ; Wed, 12 Aug 2009 13:02:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 963B19CB126; Wed, 12 Aug 2009 14:59:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aBUr3xV20Xb; Wed, 12 Aug 2009 14:59:37 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 726599CB113; Wed, 12 Aug 2009 14:59:37 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n7CCxbPT095970; Wed, 12 Aug 2009 14:59:37 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 12 Aug 2009 14:59:37 +0200 From: Roman Divacky To: Robert Watson Message-ID: <20090812125937.GA95810@freebsd.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:02:04 -0000 > Performance testing > > On the performance front, life is always a bit more tricky -- performance > testing is a subtle art. However, the most clear lessons are that (a) > testing with diverse workloads and diverse environments is extremely > important, (b) you should do multiple runs and use ministat(1) to analyze > results, and (c) that you want to compare apples with apples -- use the > same hardware/configuration wherever possible. Watch out for annoying nits > such as partition layout affecting I/O throughput for two different > installs on the same disk. > > Pick something you think is important to you: bytes/sec over TCP on > loopback, web hits/sec, NFS ops/sec, disk I/O transactions/sec, and do some > comparison between 7.2 and 8.0. If you find improvement -- great! If you > find a regression, please start a thread on current@ to help get it > diagnosed. And if you want help doing performance measurement for a > particular workload that isn't well studied, send some e-mail to > performance@ to ask for advice on how best to measure it. what happened to the performance tracking project? that would ease finding performance regressions... From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 13:12:27 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B480C1065687; Wed, 12 Aug 2009 13:12:27 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7358FC41; Wed, 12 Aug 2009 13:12:26 +0000 (UTC) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MbDcs-0004dO-GM; Wed, 12 Aug 2009 14:12:25 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MbDcr-00041y-32; Wed, 12 Aug 2009 14:12:22 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n7CDCKRr001231; Wed, 12 Aug 2009 14:12:20 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n7CDCK8H001230; Wed, 12 Aug 2009 14:12:20 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 12 Aug 2009 14:12:20 +0100 From: Anton Shterenlikht To: ahze@FreeBSD.org, freebsd-ia64@FreeBSD.org, freebsd-current@FreeBSD.org Message-ID: <20090812131220.GA1205@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -3.5 X-Spam-Level: --- Cc: Subject: ia64: port www/kazekahase panic: Inconsistent high FP state X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:12:28 -0000 This is a core.txt.0 file, created with db> panic savecore crashinfo ######################## mech-cluster241.men.bris.ac.uk dumped core - see /usr//vmcore.0 Wed 12 Aug 2009 14:05:54 BST FreeBSD mech-cluster241.men.bris.ac.uk 8.0-BETA2 FreeBSD 8.0-BETA2 #1: Wed Aug 12 12:42:09 BST 2009 mexas@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV ia64 panic: Inconsistent high FP state GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ia64-marcel-freebsd"... GDB can't read core files on this machine. (kgdb) No stack. (kgdb) ------------------------------------------------------------------------ ps -axl Segmentation fault (core dumped) ------------------------------------------------------------------------ vmstat -s 0 cpu context switches 0 device interrupts 0 software interrupts 0 traps 0 system calls 0 kernel threads created 0 fork() calls 0 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 0 vnode pager pageins 0 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 475 pages reactivated 0 copy-on-write faults 0 copy-on-write optimized faults 0 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 0 total VM faults taken 0 pages affected by kernel thread creation 0 pages affected by fork() 0 pages affected by vfork() 0 pages affected by rfork() 1304 pages cached 0 pages freed 0 pages freed by daemon 53749 pages freed by exiting processes 10359 pages active 8144 pages inactive 805 pages in VM cache 12228 pages wired down 975185 pages free 8192 bytes per page 94338 total name lookups cache hits (89% pos + 6% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) filedesc 86 45K - 1352 512,1024 kenv 16 9K - 17 16,32,64,128,8192 kqueue 10 12K - 182 256,2048 proc-args 44 2K - 6814 16,32,64,128,256 CAM XPT 44 17K - 33781 16,32,64,128,256,2048 ithread 62 9K - 62 32,128,256 CAM periph 10 3K - 74 16,32,64,256 PUC 4 1K - 4 32,512 KTRACE 100 13K - 100 128 entropy 1024 64K - 1024 64 linker 35 3K - 57 16,32,64,512 lockf 20 3K - 200 64,128 UART 15 8K - 15 16,512,1024 ip6ndp 4 1K - 4 64,128 temp 222 386K - 4440 16,32,64,128,256,512,1024,2048,4096,8192 devbuf 3651 7491K - 3691 16,32,64,128,512,2048 acpidev 56 4K - 56 64 module 141 18K - 141 128 mtx_pool 2 16K - 2 8192 USBdev 24 10K - 57 64,128,512,1024 USB 21 7K - 21 16,32,64,2048 subproc 196 385K - 1460 512,4096 proc 2 16K - 2 8192 session 28 4K - 44 128 pgrp 36 5K - 157 128 cred 76 12K - 13570 64,256 uidinfo 6 3K - 24 128,2048 plimit 12 3K - 308 256 DEVFS1 135 68K - 139 512 sysctltmp 0 0K - 656 16,32,64,128 sysctloid 1766 87K - 1810 16,32,64,128 sysctl 0 0K - 1355 16,32,64 callout 1 512K - 1 umtx 152 19K - 152 128 p1003.1b 1 1K - 1 16 SWAP 4 2337K - 4 64 DEVFS3 158 40K - 163 256 bus-sc 28 140K - 1041 16,32,64,128,256,512,8192 bus 390 44K - 2395 16,32,64,128,256,512,1024,2048 devstat 12 49K - 12 32,8192 eventhandler 60 5K - 60 64,128 kobj 76 304K - 139 4096 Per-cpu 1 1K - 1 32 DEVFS 13 1K - 14 16,128 rman 78 9K - 90 16,32,128 DEVFSP 0 0K - 33 64 sbuf 0 0K - 947 16,32,64,128,256,512,1024,2048,4096,8192 msdosfs_node 4 1K - 4 256 msdosfs_fat 1 4K - 1 4096 stack 0 0K - 2 256 taskqueue 11 1K - 11 16,32,128 Unitno 7 1K - 17 32,64 msdosfs_mount 1 1K - 1 512 pfs_nodes 20 5K - 20 256 Witness 1 128K - 1 iov 0 0K - 2750 16,64,128,256,512 select 46 6K - 46 128 ioctlops 0 0K - 12889 16,32,64,128,512,1024,2048 msg 4 30K - 4 2048,4096,8192 sem 4 11K - 4 512,1024,8192 shm 2 26K - 3 2048 tty 10 10K - 12 512,1024 pts 5 2K - 5 256 mbuf_tag 0 0K - 1 32 ksem 1 8K - 1 8192 shmfd 1 8K - 1 8192 pcb 32 157K - 186 16,32,128,1024,2048,4096,8192 soname 20 2K - 912 16,32,64,128 acl 0 0K - 2 4096 biobuf 4 8K - 12 2048 vfscache 1 1024K - 1 vfs_hash 1 512K - 1 vnodes 2 1K - 2 256 GEOM 318 52K - 1382 16,32,64,128,256,512,1024,8192 vnodemarker 0 0K - 716 512 mount 99 5K - 142 16,32,64,128,256 ether_multi 20 1K - 22 16,32,64 ifaddr 48 13K - 48 32,64,128,256,512,4096 ifnet 4 7K - 4 128,2048 clone 4 16K - 4 4096 arpcom 2 1K - 2 16 lltable 13 5K - 13 256,512 SCSI sa 1 2K - 26 32,2048,8192 ddb_capture 1 48K - 1 acpica 1431 125K - 414333 16,32,64,128,256,512,1024 acpitask 1 2K - 1 2048 mirror_data 18 6K - 790 64,256,512 routetbl 21 4K - 83 32,64,128,256,512 igmp 3 1K - 3 256 in_multi 3 1K - 3 256 sctp_iter 0 0K - 4 256 sctp_ifn 3 1K - 3 128 sctp_ifa 5 1K - 5 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 4 16 hostcache 1 32K - 1 syncache 1 96K - 1 CAM dev queue 3 1K - 3 128 acpisem 161 21K - 161 128 in6_multi 12 2K - 12 32,256 CAM queue 17 7K - 562 16,32,64,2048 mld 3 1K - 3 128 audit_evclass 172 6K - 211 32 savedino 0 0K - 36 256 dirrem 1 1K - 107 64 mkdir 0 0K - 24 64 diradd 6 1K - 124 64 freefile 0 0K - 63 64 freeblks 3 1K - 54 256 freefrag 0 0K - 5 64 allocdirect 7 2K - 96 256 bmsafemap 4 1K - 50 128 newblk 1 1K - 97 64,512 inodedep 14 516K - 165 256 pagedep 7 129K - 60 128 ufs_dirhash 54 11K - 54 16,32,64,128,512 ufs_mount 12 30K - 12 512,2048,4096,8192 cdev 6 2K - 6 256 CAM SIM 3 1K - 3 256 vm_pgdata 3 513K - 3 128 scsi_da 0 0K - 25 16 SMP 2 36K - 2 4096 nexusdev 1 1K - 1 32 sigio 1 1K - 1 64 sapic 7 1K - 7 64 Unwind 2 9K - 3 64,8192 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208, 0, 85, 20, 85, 0 UMA Zones: 256, 0, 85, 5, 85, 0 UMA Slabs: 568, 0, 252, 0, 327, 0 UMA RCntSlabs: 568, 0, 214, 10, 214, 0 UMA Hash: 256, 0, 2, 28, 2, 0 16 Bucket: 152, 0, 54, 46, 54, 0 32 Bucket: 280, 0, 43, 13, 43, 0 64 Bucket: 536, 0, 49, 7, 49, 71 128 Bucket: 1048, 0, 113, 6, 113, 42473 VM OBJECT: 216, 0, 3027, 105, 28038, 0 MAP: 232, 0, 7, 59, 7, 0 KMAP ENTRY: 120, 150570, 25, 164, 998, 0 MAP ENTRY: 120, 0, 2425, 284, 62832, 0 PV ENTRY: 48, 0, 36619, 211, 622615, 0 PT ENTRY: 32, 0, 36616, 330, 583209, 0 DP fakepg: 120, 0, 0, 126, 8, 0 SG fakepg: 120, 0, 0, 0, 0, 0 mt_zone: 264, 0, 200, 32, 200, 0 16: 16, 0, 919, 299, 281620, 0 32: 32, 0, 1669, 361, 23341, 0 64: 64, 0, 1835, 199, 79966, 0 128: 128, 0, 4802, 213, 19114, 0 256: 256, 0, 647, 103, 10129, 0 512: 512, 0, 493, 77, 4905, 0 1024: 1024, 0, 70, 66, 49222, 0 2048: 2048, 0, 43, 117, 40336, 0 4096: 4096, 0, 174, 44, 1531, 0 8192: 8192, 0, 22, 13, 2038, 0 Files: 80, 0, 223, 237, 14033, 0 TURNSTILE: 136, 0, 153, 87, 153, 0 umtx pi: 96, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0 PROC: 1096, 0, 81, 31, 1345, 0 THREAD: 936, 0, 140, 12, 140, 0 SLEEPQUEUE: 80, 0, 153, 142, 153, 0 VMSPACE: 392, 0, 44, 76, 1305, 0 cpuset: 72, 0, 2, 200, 2, 0 audit_record: 952, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 322, 344, 16630, 0 mbuf: 256, 0, 4, 406, 15444, 0 mbuf_cluster: 2048, 25600, 640, 40, 640, 0 mbuf_jumbo_page: 8192, 12800, 0, 44, 491, 0 mbuf_jumbo_9k: 9216, 12800, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 6400, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 363, 103161, 0 ttyinq: 160, 0, 90, 54, 150, 0 ttyoutq: 256, 0, 48, 42, 80, 0 VNODE: 472, 0, 1509, 43, 1573, 0 VNODEPOLL: 112, 0, 29, 172, 29, 0 NAMEI: 1024, 0, 0, 48, 31838, 0 S VFS Cache: 108, 0, 1461, 147, 3805, 0 L VFS Cache: 328, 0, 14, 58, 19, 0 DIRHASH: 1024, 0, 81, 23, 81, 0 pipe: 600, 0, 15, 37, 751, 0 ksiginfo: 112, 0, 96, 976, 96, 0 itimer: 344, 0, 1, 45, 1, 0 KNOTE: 120, 0, 32, 157, 226, 0 socket: 680, 25608, 76, 12, 1183, 0 ipq: 56, 889, 0, 0, 0, 0 udp_inpcb: 336, 25622, 10, 59, 950, 0 udpcb: 16, 25781, 10, 396, 950, 0 tcp_inpcb: 336, 25622, 21, 48, 38, 0 tcpcb: 880, 25605, 19, 17, 38, 0 tcptw: 72, 5151, 2, 301, 6, 0 syncache: 144, 15370, 0, 106, 5, 0 hostcache: 136, 15400, 3, 165, 3, 0 tcpreass: 40, 1690, 0, 0, 0, 0 sackhole: 32, 0, 0, 0, 0, 0 sctp_ep: 1248, 25602, 0, 0, 0, 0 sctp_asoc: 2176, 40002, 0, 0, 0, 0 sctp_laddr: 48, 80040, 0, 290, 4, 0 sctp_raddr: 592, 80002, 0, 0, 0, 0 sctp_chunk: 144, 400044, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0 sctp_stream_msg_out: 96, 400062, 0, 0, 0, 0 sctp_asconf: 40, 400023, 0, 0, 0, 0 sctp_asconf_ack: 48, 400055, 0, 0, 0, 0 ripcb: 336, 25622, 0, 0, 0, 0 unpcb: 240, 25600, 46, 82, 193, 0 rtentry: 200, 0, 10, 107, 10, 0 selfd: 56, 0, 119, 262, 76845, 0 SWAPMETA: 288, 503442, 0, 0, 0, 0 Mountpoints: 752, 0, 6, 24, 6, 0 FFS inode: 168, 0, 1408, 110, 1471, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 1408, 62, 1471, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate clock 4039019 4913 fxp0 2954 3 mpt0 21060 25 mpt1 8705 10 bge0 10614 12 uart0 128 0 Total 4082480 4966 ------------------------------------------------------------------------ pstat -T 223/12328 files 0M/19413M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/mirror/swap 4193776 0 4193776 0% /dev/da2p1 35565888 0 35565888 0% Total 39759664 0 39759664 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid kernel virtual address iostat: disabling TTY statistics iostat: kvm_getcptime: invalid kernel virtual address iostat: disabling CPU time statistics da0 da1 da2 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 9.53 13 0.12 9.46 13 0.12 2.91 0 0.00 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 67108864 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 8192 (max amount of shared memory in pages) seminfo: semmap: 30 (# of entries in semaphore map) semmni: 10 (# of semaphore identifiers) semmns: 60 (# of semaphores in system) semmnu: 30 (# of undo structures in system) semmsl: 60 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 10 (max # of undo entries per process) semusz: 152 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat nfsstat: kvm_nlist: can't get names ------------------------------------------------------------------------ netstat -s tcp: 3870 packets sent 3600 data packets (707566 bytes) 0 data packets (0 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 230 ack-only packets (52 delayed) 0 URG only packets 0 window probe packets 10 window update packets 30 control packets 4524 packets received 2957 acks (for 707390 bytes) 8 duplicate acks 0 acks for unsent data 2782 packets (328061 bytes) received in-sequence 0 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 0 out-of-order packets (0 bytes) 0 packets (0 bytes) of data after window 0 window probes 17 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 21 connection requests 5 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 23 connections established (including accepts) 17 connections closed (including 2 drops) 9 connections updated cached RTT on close 9 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 2 embryonic connections dropped 2957 segments updated rtt (of 2763 attempts) 0 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 170 correct ACK header predictions 1182 correct data packet header predictions 5 syncache entries added 0 retransmitted 0 dupsyn 0 dropped 5 completed 0 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 5 cookies sent 0 cookies received 0 SACK recovery episodes 0 segment rexmits in SACK recovery episodes 0 byte rexmits in SACK recovery episodes 0 SACK options (SACK blocks) received 0 SACK options (SACK blocks) sent 0 SACK scoreboard overflow 0 packets with ECN CE bit set 0 packets with ECN ECT(0) bit set 0 packets with ECN ECT(1) bit set 0 successful ECN handshakes 0 times ECN reduced the congestion window udp: 467 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 0 with no checksum 8 dropped due to no socket 268 broadcast/multicast datagrams undelivered 0 dropped due to full socket buffers 0 not for hashed pcb 191 delivered 197 datagrams output 0 times multicast source filter matched ip: 5803 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 4991 packets for this host 3 packets for unknown/unsupported protocol 0 packets forwarded (0 packets fast forwarded) 0 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 4077 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header icmp: 8 calls to icmp_error 0 errors not generated in response to an icmp message Output histogram: destination unreachable: 8 0 messages with bad code fields 0 messages less than the minimum length 0 messages with bad checksum 0 messages with bad length 0 multicast echo requests ignored 0 multicast timestamp requests ignored Input histogram: destination unreachable: 3 0 message responses generated 0 invalid return addresses 0 no return routes igmp: 0 messages received 0 messages received with too few bytes 0 messages received with wrong TTL 0 messages received with bad checksum 0 V1/V2 membership queries received 0 V3 membership queries received 0 membership queries received with invalid field(s) 0 general queries received 0 group queries received 0 group-source queries received 0 group-source queries dropped 0 membership reports received 0 membership reports received with invalid field(s) 0 membership reports received for groups to which we belong 0 V3 reports received without Router Alert 0 membership reports sent ip6: 0 total packets received 0 with size smaller than minimum 0 with data size < data length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 fragments that exceeded limit 0 packets reassembled ok 0 packets for this host 0 packets forwarded 0 packets not forwardable 0 redirects sent 0 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 packets that violated scope rules 0 multicast packets which we don't join Mbuf statistics: 0 one mbuf 0 one ext mbuf 0 two or more ext mbuf 0 packets whose headers are not continuous 0 tunneling packets that can't find gif 0 packets discarded because of too many headers 0 failures of source address selection Source addresses selection rule applied: 2 first candidate 2 same address icmp6: 0 calls to icmp6_error 0 errors not generated in response to an icmp6 message 0 errors not generated because of rate limitation 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Histogram of error messages to be generated: 0 no route 0 administratively prohibited 0 beyond scope 0 address unreachable 0 port unreachable 0 packet too big 0 time exceed transit 0 time exceed reassembly 0 erroneous header field 0 unrecognized next header 0 unrecognized option 0 redirect 0 unknown 0 message responses generated 0 messages with too many ND options 0 messages with bad ND options 0 bad neighbor solicitation messages 0 bad neighbor advertisement messages 0 bad router solicitation messages 0 bad router advertisement messages 0 bad redirect messages 0 path MTU changes rip6: 0 messages received 0 checksum calculations on inbound 0 messages with bad checksum 0 messages dropped due to no socket 0 multicast messages dropped due to no socket 0 messages dropped due to full socket buffers 0 delivered 0 datagrams output ------------------------------------------------------------------------ netstat -m 326/750/1076 mbufs in use (current/cache/total) 296/384/680/25600 mbuf clusters in use (current/cache/total/max) 322/344 mbuf+clusters out of packet secondary zone in use (current/cache) 0/44/44/12800 8k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/12800 9k jumbo clusters in use (current/cache/total/max) 0/0/0/6400 16k jumbo clusters in use (current/cache/total/max) 673K/1307K/1981K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (8k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines ------------------------------------------------------------------------ netstat -id Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop fxp0 1500 00:11:0a:31:d6:ec 2949 0 0 0 0 0 fxp0 1500 10.10.10.0 10.10.10.31 3106 - 0 - - - bge0 1500 00:11:0a:31:36:40 7169 0 4013 0 0 0 bge0 1500 137.222.187.0 mech-cluster241 1824 - 4013 - - - lo0 16384 64 0 64 0 0 0 lo0 16384 fe80:3::1 fe80:3::1 0 - 0 - - - lo0 16384 localhost ::1 0 - 0 - - - lo0 16384 your-net localhost 64 - 64 - - - ------------------------------------------------------------------------ netstat -anr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 137.222.187.250 UGS 0 4013 bge0 10.10.10.0/24 link#1 U 0 0 fxp0 10.10.10.31 link#3 UHS 0 0 lo0 127.0.0.1 link#3 UH 0 64 lo0 137.222.187.0/24 link#2 U 0 0 bge0 137.222.187.241 link#3 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::1 ::1 UH lo0 fe80::%lo0/64 link#3 U lo0 ff01:3::/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 ------------------------------------------------------------------------ netstat -anA Active Internet connections (including servers) Tcpcb Proto Recv-Q Send-Q Local Address Foreign Address (state) e000000011690dc0 tcp4 0 0 137.222.187.241.50 77.238.187.39.80 SYN_SENT e000000011c4c370 tcp4 0 0 137.222.187.241.55 84.53.133.98.80 ESTABLISHED e000000011c4c6e0 tcp4 0 0 137.222.187.241.51 84.53.133.98.80 ESTABLISHED e0000000116d66e0 tcp4 0 28 137.222.187.241.55 137.222.184.33.600 ESTABLISHED e0000000116d6370 tcp4 0 0 137.222.187.241.30 137.222.184.33.600 ESTABLISHED e0000000116d6000 tcp4 0 0 137.222.187.241.18 137.222.184.33.600 ESTABLISHED e000000011690a50 tcp4 0 88 137.222.187.241.33 137.222.184.33.600 ESTABLISHED e000000011690370 tcp4 0 0 137.222.187.241.49 137.222.184.33.600 ESTABLISHED e0000000116906e0 tcp4 0 0 137.222.187.241.20 137.222.184.33.600 ESTABLISHED e000000011b20090 tcp4 0 0 137.222.187.241.14 137.222.184.33.600 TIME_WAIT e00000001194fb48 tcp4 0 0 137.222.187.241.24 137.222.184.33.600 TIME_WAIT e000000011691130 tcp4 32 0 137.222.187.241.44 137.222.184.33.600 ESTABLISHED e00000001168fb80 tcp6 0 0 *.28036 *.* LISTEN e000000011690000 tcp4 0 0 10.10.10.31.22 137.222.184.33.650 ESTABLISHED e00000001168e370 tcp4 0 0 10.10.10.31.22 137.222.184.33.546 ESTABLISHED e00000001168e6e0 tcp4 0 0 10.10.10.31.22 137.222.184.33.543 ESTABLISHED e00000001168ea50 tcp4 0 0 *.22 *.* LISTEN e00000001168edc0 tcp6 0 0 *.22 *.* LISTEN e00000001168f130 tcp4 0 0 *.587 *.* LISTEN e00000001168f4a0 tcp6 0 0 *.25 *.* LISTEN e00000001168f810 tcp4 0 0 *.25 *.* LISTEN e00000001149da40 udp4 0 0 137.222.187.241.17 *.* e00000001149c540 udp4 0 0 127.0.0.1.123 *.* e00000001149c690 udp6 0 0 ::1.123 *.* e00000001149c7e0 udp6 0 0 fe80:3::1.123 *.* e00000001149c930 udp4 0 0 137.222.187.241.12 *.* e00000001149ca80 udp4 0 0 10.10.10.31.123 *.* e00000001149cbd0 udp6 0 0 *.123 *.* e00000001149cd20 udp4 0 0 *.123 *.* e00000001149ce70 udp4 0 0 *.514 *.* e00000001149cfc0 udp6 0 0 *.514 *.* Active UNIX domain sockets Address Type Recv-Q Send-Q Inode Conn Refs Nextref Addr e0000000115c24b0 stream 0 0 0 e0000000114a4e10 0 0 /var/tmp/orbit-mexas/linc-53e-0-4451604b38530 e0000000114a4e10 stream 0 0 0 e0000000115c24b0 0 0 e0000000114a2d20 stream 0 0 e000000011c07448 0 0 0 /var/tmp/orbit-mexas/linc-53e-0-4451604b38530 e0000000114a4b40 stream 0 0 0 e0000000114a2b40 0 0 /var/tmp/orbit-mexas/linc-541-0-6b2bcc802af1e e0000000114a2b40 stream 0 0 0 e0000000114a4b40 0 0 e0000000114a2a50 stream 0 0 0 e0000000114a2690 0 0 /var/run/dbus/system_bus_socket e0000000114a2690 stream 0 0 0 e0000000114a2a50 0 0 e0000000114a43c0 stream 0 0 0 e0000000114a50e0 0 0 /var/tmp/dbus-s6GXC9Stfo e0000000114a50e0 stream 0 0 0 e0000000114a43c0 0 0 e0000000114a2c30 stream 0 0 e000000011c6aec0 0 0 0 /var/tmp/orbit-mexas/linc-541-0-6b2bcc802af1e e0000000114a4a50 stream 0 0 0 e0000000115c23c0 0 0 /var/tmp/dbus-s6GXC9Stfo e0000000115c23c0 stream 0 0 0 e0000000114a4a50 0 0 e0000000114a4870 stream 0 0 0 e0000000114a2780 0 0 e0000000114a2780 stream 0 0 0 e0000000114a4870 0 0 e0000000115c22d0 stream 0 0 e000000011afa000 0 0 0 /var/tmp/dbus-s6GXC9Stfo e0000000115c2000 stream 0 0 0 e0000000114a4000 0 0 e0000000114a4000 stream 0 0 0 e0000000115c2000 0 0 e0000000114a24b0 stream 0 0 0 e0000000114a2f00 0 0 e0000000114a2f00 stream 0 0 0 e0000000114a24b0 0 0 e0000000114a2870 stream 0 0 0 e0000000114a31d0 0 0 e0000000114a31d0 stream 0 0 0 e0000000114a2870 0 0 e0000000115c3590 stream 0 0 0 e0000000115c3680 0 0 /var/run/dbus/system_bus_socket e0000000115c3680 stream 0 0 0 e0000000115c3590 0 0 e0000000115c3770 stream 0 0 0 e0000000115c3860 0 0 /var/run/hald/dbus-tdjn5D3BsW e0000000115c3860 stream 0 0 0 e0000000115c3770 0 0 e0000000114a52c0 stream 0 0 0 e0000000114a53b0 0 0 /var/run/devd.pipe e0000000114a53b0 stream 0 0 0 e0000000114a52c0 0 0 e0000000114a54a0 stream 0 0 0 e0000000114a5590 0 0 /var/run/hald/dbus-lz7niJzPoP e0000000114a5590 stream 0 0 0 e0000000114a54a0 0 0 e0000000114a5680 stream 0 0 0 e0000000114a5770 0 0 /var/run/dbus/system_bus_socket e0000000114a5770 stream 0 0 0 e0000000114a5680 0 0 e0000000114a5860 stream 0 0 e0000000116fa000 0 0 0 /var/run/hald/dbus-lz7niJzPoP e0000000114a32c0 stream 0 0 0 e0000000114a33b0 0 0 /var/run/dbus/system_bus_socket e0000000114a33b0 stream 0 0 0 e0000000114a32c0 0 0 e0000000114a5950 stream 0 0 e0000000116fa938 0 0 0 /var/run/hald/dbus-tdjn5D3BsW e0000000114a3770 stream 0 0 0 e0000000114a3860 0 0 e0000000114a3860 stream 0 0 0 e0000000114a3770 0 0 e0000000114a5b30 stream 0 0 e0000000115d2ec0 0 0 0 /var/run/dbus/system_bus_socket e0000000115c21e0 stream 0 0 e00000001147d620 0 0 0 /var/run/devd.pipe e0000000117d62d0 dgram 0 0 0 e0000000114a3950 0 e0000000114a2ff0 e0000000114a2ff0 dgram 0 0 0 e0000000114a3950 0 e0000000114a5a40 e0000000114a3680 dgram 0 0 0 e0000000114a3a40 0 0 e0000000114a5a40 dgram 0 0 0 e0000000114a3950 0 e0000000114a5c20 e0000000114a5c20 dgram 0 0 0 e0000000114a3950 0 0 e0000000114a3950 dgram 0 0 e0000000115bd098 0 e0000000117d62d0 0 /var/run/logpriv e0000000114a3a40 dgram 0 0 e0000000115bd270 0 e0000000114a3680 0 /var/run/log ------------------------------------------------------------------------ netstat -aL Current listen queue sizes (qlen/incqlen/maxqlen) Proto Listen Local Address tcp6 0/0/5 *.28036 tcp4 0/0/128 *.ssh tcp6 0/0/128 *.ssh tcp4 0/0/10 *.submission tcp6 0/0/10 *.smtp tcp4 0/0/10 *.smtp unix 0/0/10 /var/tmp/orbit-mexas/linc-53e-0-4451604b38530 unix 0/0/10 /var/tmp/orbit-mexas/linc-541-0-6b2bcc802af1e unix 0/0/30 /var/tmp/dbus-s6GXC9Stfo unix 0/0/30 /var/run/hald/dbus-lz7niJzPoP unix 0/0/30 /var/run/hald/dbus-tdjn5D3BsW unix 0/0/30 /var/run/dbus/system_bus_socket unix 0/0/4 /var/run/devd.pipe ------------------------------------------------------------------------ fstat Segmentation fault ------------------------------------------------------------------------ dmesg GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2009 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 8.0-BETA2 #1: Wed Aug 12 12:42:09 BST 2009 mexas@mech-cluster241.men.bris.ac.uk:/usr/obj/usr/src/sys/TZAV WARNING: WITNESS option enabled, expect reduced performance. CPU: Madison (1500.00-Mhz Itanium 2) Origin = "GenuineIntel" Revision = 5 Features = 0x1 real memory = 8569184256 (8172 MB) avail memory = 8208957440 (7828 MB) FPSWA Revision = 0x10012, Entry = 0xe0000040ffe62050 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: SAPIC Id=1, SAPIC Eid=0 ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 20090521 tbfadt-625 ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 20090521 tbfadt-625 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5c1004-0xff5c1007 on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 pci0: on pcib0 ohci0: mem 0x80023000-0x80023fff irq 16 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x80022000-0x80022fff irq 17 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0x80021000-0x800210ff irq 18 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 0.95 usbus2: on ehci0 pci0: at device 2.0 (no driver attached) fxp0: port 0xd00-0xd3f mem 0x80020000-0x80020fff,0x80000000-0x8001ffff irq 20 at device 3.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:11:0a:31:d6:ec fxp0: [ITHREAD] pcib1: on acpi0 pci32: on pcib1 mpt0: port 0x2100-0x21ff mem 0x90840000-0x9084ffff,0x90830000-0x9083ffff irq 27 at device 1.0 on pci32 mpt0: [ITHREAD] mpt0: MPI Version=1.2.12.0 mpt1: port 0x2000-0x20ff mem 0x90820000-0x9082ffff,0x90810000-0x9081ffff irq 28 at device 1.1 on pci32 mpt1: [ITHREAD] mpt1: MPI Version=1.2.12.0 bge0: mem 0x90800000-0x9080ffff irq 29 at device 2.0 on pci32 miibus1: on bge0 brgphy0: PHY 1 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:11:0a:31:36:40 bge0: [ITHREAD] pcib2: on acpi0 pci64: on pcib2 pcib3: on acpi0 pci96: on pcib3 pcib4: on acpi0 pci128: on pcib4 pcib5: on acpi0 pci192: on pcib5 pcib6: on acpi0 pci224: on pcib6 uart0: <16550 or compatible> mem 0xf4051000-0xf405100f irq 82 at device 1.0 on pci224 uart0: [FILTER] puc0: mem 0xf4050000-0xf4050fff,0xf4020000-0xf403ffff irq 82 at device 1.1 on pci224 puc0: [FILTER] uart1: on puc0 uart1: [FILTER] uart1: console (9600,n,8,1) uart2: on puc0 uart2: [FILTER] vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf3ffffff,0xf4040000-0xf404ffff at device 2.0 on pci224 uart3: <16550 or compatible> iomem 0xff5e0000-0xff5e0007 irq 34 on acpi0 uart3: [FILTER] uart4: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0 uart4: [FILTER] uart4: debug port (9600,n,8,1) cpu0: on acpi0 cpu1: on acpi0 Timecounters tick every 1.000 msec IP Filter: v4.1.28 initialized. Default = block all, Logging = enabled Waiting 5 seconds for SCSI devices to settle usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 3 ports with 3 removable, self powered ugen1.1: at usbus1 uhub1: on usbus1 uhub1: 2 ports with 2 removable, self powered ugen2.1: at usbus2 uhub2: on usbus2 (probe1:mpt1:0:3:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe1:mpt1:0:3:0): CAM Status: SCSI Status Error (probe1:mpt1:0:3:0): SCSI Status: Check Condition (probe1:mpt1:0:3:0): UNIT ATTENTION asc:29,2 (probe1:mpt1:0:3:0): SCSI bus reset occurred (probe1:mpt1:0:3:0): Retrying Command (per Sense Data) uhub2: 5 ports with 5 removable, self powered sa0 at mpt1 bus 0 target 3 lun 0 sa0: Removable Sequential Access SCSI-3 device sa0: 40.000MB/s transfers (20.000MHz, offset 32, 16bit) da2 at mpt1 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 40.000MB/s transfers (20.000MHz, offset 63, 16bit) da2: Command Queueing enabled da2: 17366MB (35566478 512 byte sectors: 255H 63S/T 2213C) WARNING: WITNESS option enabled, expect reduced performance. da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da1: Command Queueing enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) GEOM_MIRROR: Device mirror/efi launched (2/2). GEOM_MIRROR: Device mirror/root launched (2/2). GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_MIRROR: Device mirror/var launched (2/2). GEOM_MIRROR: Device mirror/tmp launched (2/2). GEOM_MIRROR: Device mirror/usr launched (2/2). Trying to mount root from ufs:/dev/mirror/root Entropy harvesting: interrupts ethernet point_to_point kickstart . /dev/mirror/root: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/root: clean, 227518 free (590 frags, 28366 blocks, 0.2% fragmentation) /dev/mirror/usr: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/usr: clean, 28332023 free (70127 frags, 3532737 blocks, 0.2% fragmentation) /dev/mirror/tmp: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/tmp: clean, 506481 free (49 frags, 63304 blocks, 0.0% fragmentation) /dev/mirror/var: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mirror/var: clean, 478822 free (206 frags, 59827 blocks, 0.0% fragmentation) Enabling ipfilter. Installing NAT rules. 0 entries flushed from NAT table 0 entries flushed from NAT list Starting Network: lo0 fxp0 bge0. filter sync'd add net default: gateway 137.222.187.250 Additional routing options: IP gateway=YES . bge0: link state changed to UP Starting hald. bge0: link state changed to DOWN bge0: link state changed to UP Wed Aug 12 13:03:26 BST 2009 Aug 12 13:04:47 mech-cluster241 su: mexas to root on /dev/pts/0 Aug 12 13:20:14 mech-cluster241 su: mexas to root on /dev/pts/1 panic: Inconsistent high FP state cpuid = 0 KDB: stack backtrace: db_trace_self(0xe000000004140750) at db_trace_self+0x20 db_trace_self_wrapper(0xe0000000043f5120) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004980920, 0xe000000004393890, 0x793, 0xe000000004b616c0) at kdb_backtrace+0xc0 panic(0xe00000000486bbb0, 0x0, 0xe00000000486bb88, 0x5cf) at panic+0x2a0 ia64_highfp_drop(0xe000000011968760) at ia64_highfp_drop+0x100 cpu_thread_exit(0xe000000011968760, 0xe0000000043b0840, 0x50e, 0x15a) at cpu_thread_exit+0x20 thread_exit(0xe000000004834c00, 0xe000000004833880, 0xe0000000118044f0, 0xe000000011968760) at thread_exit+0x130 thr_exit(0xe000000011804468, 0xe000000011804540, 0xe000000004834bd8, 0xe000000011804448) at thr_exit+0x120 syscall(0xa0000000c39c1400, 0x1af, 0x200000004209c7b0, 0xe000000011968760, 0xe000000011804448, 0xe000000004931428, 0x1af, 0xa0000000c39c14e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 33m44s Dumping 8172 MB (11 chunks) chunk 0: 159 pages ------------------------------------------------------------------------ kernel config config: File /boot/kernel/kernel doesn't contain configuration file. Either unsupported, or not compiled with INCLUDE_CONFIG_FILE -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 13:32:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 395F31065670; Wed, 12 Aug 2009 13:32:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 07DC38FC57; Wed, 12 Aug 2009 13:32:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 565E946B23; Wed, 12 Aug 2009 09:32:19 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B8F488A0AD; Wed, 12 Aug 2009 09:32:18 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 12 Aug 2009 09:24:48 -0400 User-Agent: KMail/1.9.7 References: <20090811195240.GI1292@hoeg.nl> <4A81EEE8.5060405@elischer.org> In-Reply-To: <4A81EEE8.5060405@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908120924.49300.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 12 Aug 2009 09:32:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ed Schouten , Kip Macy , Robert Noland , "Arno J. Klaassen" , Julian Elischer , FreeBSD Current Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:32:20 -0000 On Tuesday 11 August 2009 6:21:28 pm Julian Elischer wrote: > Ed Schouten wrote: > > * Kip Macy wrote: > >> http://people.freebsd.org/~kmacy/flowtable_boot.patch > > > > + if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0) > > > > should probably read: > > > > + if (V_flowtable_enable == 0 || V_flowtable_ready == 0) > > > > Right? > > > > > I prefer the first, with an extra closing paren. style(9) prefers the latter assuming that it isn't confusing to read the latter (I do not think it is). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 13:32:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 395F31065670; Wed, 12 Aug 2009 13:32:20 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 07DC38FC57; Wed, 12 Aug 2009 13:32:20 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 565E946B23; Wed, 12 Aug 2009 09:32:19 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id B8F488A0AD; Wed, 12 Aug 2009 09:32:18 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 12 Aug 2009 09:24:48 -0400 User-Agent: KMail/1.9.7 References: <20090811195240.GI1292@hoeg.nl> <4A81EEE8.5060405@elischer.org> In-Reply-To: <4A81EEE8.5060405@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908120924.49300.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 12 Aug 2009 09:32:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Ed Schouten , Kip Macy , Robert Noland , "Arno J. Klaassen" , Julian Elischer , FreeBSD Current Subject: Re: 8.0-BETA2: mi_startup() panic on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:32:20 -0000 On Tuesday 11 August 2009 6:21:28 pm Julian Elischer wrote: > Ed Schouten wrote: > > * Kip Macy wrote: > >> http://people.freebsd.org/~kmacy/flowtable_boot.patch > > > > + if ((V_flowtable_enable == 0) || (V_flowtable_ready == 0) > > > > should probably read: > > > > + if (V_flowtable_enable == 0 || V_flowtable_ready == 0) > > > > Right? > > > > > I prefer the first, with an extra closing paren. style(9) prefers the latter assuming that it isn't confusing to read the latter (I do not think it is). -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 13:47:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0268C106566B for ; Wed, 12 Aug 2009 13:47:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D0A5E8FC49 for ; Wed, 12 Aug 2009 13:47:19 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8051846B2E; Wed, 12 Aug 2009 09:47:19 -0400 (EDT) Date: Wed, 12 Aug 2009 14:47:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <200908121335.n7CDZZcg047419@lava.sentex.ca> Message-ID: References: <200908121335.n7CDZZcg047419@lava.sentex.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:47:20 -0000 On Wed, 12 Aug 2009, Mike Tancsa wrote: >> As we're approaching 8.0 BETA3, now would be a really good time to start >> identifying functional and performance regressions from the 7.x series. >> We've done a mixed job at this in the past, but when it comes to "I'll do >> better some day", there's no time like the present :-). Some notes: > > Other than the removal of whats below from the kernel, what other > adjustments should be made to make more accurate comparisons ? The main thing I'm aware of is malloc debugging in userspace -- the best way to do this is to uncomment MALLOC_PRODUCTION in src/lib/libc/stdlib/malloc.c: /* * MALLOC_PRODUCTION disables assertions and statistics gathering. It also * defaults the A and J runtime options to off. These settings are appropriate * for production systems. */ /* #define MALLOC_PRODUCTION */ You can also manually disable many of the debugging features in malloc(3) using malloc.conf -- however, it looks to me like some things, such as magic number checking, etc, are basically a compile time-only configuration option, so I'd encourage using MALLOC_PRODUCTION instead. Robert N M Watson Computer Laboratory University of Cambridge > > # Debugging for use in -current > options KDB # Enable kernel debugger support. > options DDB # Support DDB. > options GDB # Support remote GDB. > options INVARIANTS # Enable calls of extra sanity > checking > options INVARIANT_SUPPORT # Extra sanity checks of internal > structures, required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks > and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for > speed > > ---Mike > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 13:51:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D8A106566C for ; Wed, 12 Aug 2009 13:51:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 248C88FC53 for ; Wed, 12 Aug 2009 13:51:50 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n7CDZZcg047419; Wed, 12 Aug 2009 09:35:35 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200908121335.n7CDZZcg047419@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Aug 2009 09:38:38 -0400 To: Robert Watson , current@freebsd.org From: Mike Tancsa In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 13:51:51 -0000 At 08:29 AM 8/12/2009, Robert Watson wrote: >Dear all: > >As we're approaching 8.0 BETA3, now would be a really good time to >start identifying functional and performance regressions from the >7.x series. We've done a mixed job at this in the past, but when it >comes to "I'll do better some day", there's no time like the present >:-). Some notes: > Hi Robert, Other than the removal of whats below from the kernel, what other adjustments should be made to make more accurate comparisons ? # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 14:17:12 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18171106566C for ; Wed, 12 Aug 2009 14:17:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E0D768FC47 for ; Wed, 12 Aug 2009 14:17:11 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 46EDA46B2E; Wed, 12 Aug 2009 10:17:11 -0400 (EDT) Date: Wed, 12 Aug 2009 15:17:11 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <4A81F443.5030905@samsco.org> Message-ID: References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> <4A81F443.5030905@samsco.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , Rick Macklem , FreeBSD current mailing list , Jilles Tjoelker Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 14:17:12 -0000 On Tue, 11 Aug 2009, Scott Long wrote: >> Yes, if some file that was in that directory is still open (or mmap'd and >> the process hasn't yet exit()'d), it will exist as a file named ".nfsXXX" >> until the v_usecount goes to 0 and then it's removed, which would explain >> it. >> >>> Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it is >>> open. >> >> Afraid not. NFSv4 has an Open, but it is an open share lock and not a POSIX >> style open, so NFSv4 clients still do the silly rename. (ie. The NFSv4 >> Remove Op is defined as removing the file and not just unlinking it and the >> NFSv4 server isn't required to retain the file after removal if it is >> Open'd by a client.) > > I'd like to pop this issue back to the top of the stack. Doing an > installworld to local disks on a NFS-root system used to be a convenient way > to install new systems without requiring release bits and release media. > So, this used to work, and now it doesn't. I'd like help in getting to the > bottom of this and fixing it. Is this issue with the default NFS client, or the experimental one? If the former, I'll put this on the RE known issues please solve thanks list. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 14:48:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6B85106566B for ; Wed, 12 Aug 2009 14:48:24 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 651348FC3A for ; Wed, 12 Aug 2009 14:48:23 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id n7CEmL5D021438; Wed, 12 Aug 2009 15:48:21 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MbF7l-0000Qq-5N; Wed, 12 Aug 2009 15:48:21 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n7CEmK1c034764; Wed, 12 Aug 2009 15:48:20 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n7CEmK5Z034763; Wed, 12 Aug 2009 15:48:20 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Jim In-Reply-To: <80f4f2b20908061705h6b218702ked110fa54d1bee5@mail.gmail.com> References: <80f4f2b20908061705h6b218702ked110fa54d1bee5@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 12 Aug 2009 15:48:20 +0100 Message-Id: <1250088500.17787.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 8.0 Beta2 / ALC driver crashbase X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 14:48:25 -0000 On Thu, 2009-08-06 at 20:05 -0400, Jim wrote: > I couldn't get the copy of the if_alc driver to compile in FreeBSD 7.2 > on my new notebook, so I decided to use 8.0, and I found an issue, > when I boot the installer media CD (boot only or DVD1), I get the > following error: > > alc0: irq 16 at device 0.0 on pci7 > alc0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). > alc0: cannot allocate memory resources). > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fatal virtual address = 0x08 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff0024c6e8 > stack pointer = 0x20:0xffffffff813f65f0 > frame pointer = 0x20:0xffffffff813f6600 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DLP 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > correct process = 0 (swapper) > [thread pid 0 tid 100000 ] > Stopped at alc_phy_down+0x0: cmpq $0,0x8(xrax) > db> > > > I'm not knowledgeable about this to the point where I could debug the > issue, is there anything I could do to provide the developers with the > info needed to fix the issue, or could someone tell me how to boot the > installer and force it to not load if_alc, and suggest give me an idea > of what this means, in laymans terms so I can try to diagnose it? If I > had to guess, I would say it's trying to access a chunk of > memory/address-space that hasn't been allocated or doesn't exist, but > I don't know if that's correct or where to go from there. First thing to do, at the "db> " prompt, enter "bt" and show us the results. What version of FreeBSD is this? (8.0-BETA2 I'm assuming?) There are probably at least two issues here: 1) The allocation shouldn't fail, but is, and 2) it shouldn't panic. Getting a backtrace (with "bt" will hopefully be enough to figure out the second issue, but for the first one we may need a full verbose dmesg from the system. Do you have a serial console hooked up to the machine with which you could obtain this? Thanks, Gavin From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 15:29:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04257106566C; Wed, 12 Aug 2009 15:29:14 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id C38EE8FC3E; Wed, 12 Aug 2009 15:29:12 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 40B652C2C60; Wed, 12 Aug 2009 10:29:12 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NrTTkzGPSHJw; Wed, 12 Aug 2009 10:29:04 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 3D31E2C2B02; Wed, 12 Aug 2009 10:29:04 -0500 (CDT) Message-ID: <4A82DFBF.5020101@cs.rice.edu> Date: Wed, 12 Aug 2009 10:29:03 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: current@freebsd.org, =?UTF-8?B?VWxyaWNoIFNww7ZybGVpbg==?= References: <20090713181650.GB76464@acme.spoerlein.net> <4A5B7D24.60100@cs.rice.edu> <20090714105245.GR2145@acme.spoerlein.net> In-Reply-To: <20090714105245.GR2145@acme.spoerlein.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Alan Cox , Kip Macy Subject: Re: panic: vm_page_free_toq: freeing mapped page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 15:29:14 -0000 Ulrich Spörlein wrote: > On Mon, 13.07.2009 at 13:29:56 -0500, Alan Cox wrote: > >> Ulrich Spörlein wrote: >> >>> On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Spörlein wrote: >>> >>> >>>> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote: >>>> >>>> >>>>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich Spörlein wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> 8.0 BETA1 @ r195622 will panic reliably when running the clang static >>>>>> analyzer on a buildworld with something like the following panic: >>>>>> >>>>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30 >>>>>> cpuid = 1 >>>>>> KDB: stack backtrace: >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>>>>> panic() at panic+0x182 >>>>>> vm_page_free_toq() at vm_page_free_toq+0x1f6 >>>>>> vm_object_terminate() at vm_object_terminate+0xb7 >>>>>> vm_object_deallocate() at vm_object_deallocate+0x17a >>>>>> _vm_map_unlock() at _vm_map_unlock+0x70 >>>>>> vm_map_remove() at vm_map_remove+0x6f >>>>>> vmspace_free() at vmspace_free+0x56 >>>>>> vmspace_exec() at vmspace_exec+0x56 >>>>>> exec_new_vmspace() at exec_new_vmspace+0x133 >>>>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee >>>>>> kern_execve() at kern_execve+0x3b2 >>>>>> execve() at execve+0x3d >>>>>> syscall() at syscall+0x1af >>>>>> Xfast_syscall() at Xfast_syscall+0xe1 >>>>>> --- syscall (59, FreeBSD ELF64, execve), rip = 0x800c20d0c, rsp = 0x7fffffffd6f8, rbp = 0x7fffffffdbf0 --- >>>>>> >>>>>> >>>>> Can you try the following change: >>>>> >>>>> http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_object.c?r1=192842&r2=195297 >>>>> >>>>> >>>> Applied this to HEAD by hand an ran with it, it died 20-30 minutes into >>>> the scan-build run. So no luck there. Next up is a test using the >>>> GENERIC kernel. >>>> >>> No improvement with a GENERIC kernel. Next up will be to run this with >>> clean sysctl, loader.conf, etc. Then I'll try disabling SMP. >>> >>> Does the backtrace above point to any specific subsystem? I'm using UFS, >>> ZFS and GELI on this machine and could try a few combinations... >>> >> The interesting thing about the backtrace is that it shows a 32-bit i386 >> executable being started on a 64-bit amd64 machine. I've seen this >> backtrace once before, and you'll find it in the PR database. In that >> case, the problem "went away" after the known-to-be-broken >> ZERO_COPY_SOCKETS option was removed from the reporter's kernel >> configuration. However, I don't see that as the culprit here. >> > > Hi Alan, first the bad news > > I ran this test with a GENERIC kernel, SMP disabled, hw.physmem set to 2 > GB in single user mode, so no other processes or deamons running, > nothing special in loader.conf except for ZFS and GELI. It reliably > panics, so nothing new here. > > Now the good news, you may be able to crash your own amd64 box in 3 > minutes by doing: > > mkdir /tmp/foo && cd /tmp/foo > fetch -o- https://www.spoerlein.net/pub/llvm-clang.tar.gz | tar xf - > while :; do for d in bin sbin usr.bin usr.sbin; do $PWD/scan-build -o /dev/null -k make -C /usr/src/$d clean obj depend all; done; done > > Please note that scan-build/ccc-analyzer wont actually do anything, as > they cannot create output in /dev/null. So this is just running the > perl-script and forking make/sh/awk/ccc-analyzer like mad. It does not > survive 3 minutes on my Core2 Duo 3.3 GHz. > Hi Ulrich, I finally got a chance to try this workload. I'm afraid that I can't reproduce the assertion failure on my amd64 test machine. I left the test running overnight, and it was still going strong this morning. I am using neither ZFS nor GELI. Is it possible for you to repeat this test without ZFS and/or GELI? I would also be curious if anyone else reading this message can reproduce the assertion failure with the above test. Regards, Alan From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 16:34:44 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29159106566C; Wed, 12 Aug 2009 16:34:44 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id CA4A18FC4D; Wed, 12 Aug 2009 16:34:43 +0000 (UTC) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n7CGYa3w049993; Wed, 12 Aug 2009 10:34:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A82EF1C.2090004@samsco.org> Date: Wed, 12 Aug 2009 10:34:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Robert Watson References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> <4A81F443.5030905@samsco.org> In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: "Bjoern A. Zeeb" , Rick Macklem , FreeBSD current mailing list , Jilles Tjoelker Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 16:34:44 -0000 Robert Watson wrote: > > On Tue, 11 Aug 2009, Scott Long wrote: > >>> Yes, if some file that was in that directory is still open (or mmap'd >>> and the process hasn't yet exit()'d), it will exist as a file named >>> ".nfsXXX" until the v_usecount goes to 0 and then it's removed, which >>> would explain it. >>> >>>> Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as >>>> it is open. >>> >>> Afraid not. NFSv4 has an Open, but it is an open share lock and not a >>> POSIX style open, so NFSv4 clients still do the silly rename. (ie. >>> The NFSv4 Remove Op is defined as removing the file and not just >>> unlinking it and the NFSv4 server isn't required to retain the file >>> after removal if it is Open'd by a client.) >> >> I'd like to pop this issue back to the top of the stack. Doing an >> installworld to local disks on a NFS-root system used to be a >> convenient way to install new systems without requiring release bits >> and release media. So, this used to work, and now it doesn't. I'd >> like help in getting to the bottom of this and fixing it. > > Is this issue with the default NFS client, or the experimental one? If > the former, I'll put this on the RE known issues please solve thanks list. > Thanks to insight from Jilles, it looks like it's a sillyrename issue triggered by a change in src/Makefile.inc, and not an NFS bug. Scott From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 16:51:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A01EE106564A; Wed, 12 Aug 2009 16:51:14 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1B3728FC41; Wed, 12 Aug 2009 16:51:14 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:38257 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MbH2b-0002sR-5x; Wed, 12 Aug 2009 18:51:12 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id D75234470A; Wed, 12 Aug 2009 18:50:47 +0200 (CEST) Message-Id: From: Thomas Backman To: Alan Cox In-Reply-To: <4A82DFBF.5020101@cs.rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 Aug 2009 18:50:45 +0200 References: <20090713181650.GB76464@acme.spoerlein.net> <4A5B7D24.60100@cs.rice.edu> <20090714105245.GR2145@acme.spoerlein.net> <4A82DFBF.5020101@cs.rice.edu> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MbH2b-0002sR-5x. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MbH2b-0002sR-5x 9f7f9ee8c275d8821bede7a8e8dcf3bc Cc: current@freebsd.org, Kip Macy Subject: Re: panic: vm_page_free_toq: freeing mapped page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 16:51:14 -0000 On Aug 12, 2009, at 17:29, Alan Cox wrote: > Ulrich Sp=F6rlein wrote: >> On Mon, 13.07.2009 at 13:29:56 -0500, Alan Cox wrote: >> >>> Ulrich Sp=F6rlein wrote: >>> >>>> On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Sp=F6rlein wrote: >>>> >>>>> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote: >>>>> >>>>>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich = Sp=F6rlein>>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> 8.0 BETA1 @ r195622 will panic reliably when running the clang =20= >>>>>>> static >>>>>>> analyzer on a buildworld with something like the following =20 >>>>>>> panic: >>>>>>> >>>>>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30 >>>>>>> cpuid =3D 1 >>>>>>> KDB: stack backtrace: >>>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >>>>>>> panic() at panic+0x182 >>>>>>> vm_page_free_toq() at vm_page_free_toq+0x1f6 >>>>>>> vm_object_terminate() at vm_object_terminate+0xb7 >>>>>>> vm_object_deallocate() at vm_object_deallocate+0x17a >>>>>>> _vm_map_unlock() at _vm_map_unlock+0x70 >>>>>>> vm_map_remove() at vm_map_remove+0x6f >>>>>>> vmspace_free() at vmspace_free+0x56 >>>>>>> vmspace_exec() at vmspace_exec+0x56 >>>>>>> exec_new_vmspace() at exec_new_vmspace+0x133 >>>>>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee >>>>>>> kern_execve() at kern_execve+0x3b2 >>>>>>> execve() at execve+0x3d >>>>>>> syscall() at syscall+0x1af >>>>>>> Xfast_syscall() at Xfast_syscall+0xe1 >>>>>>> --- syscall (59, FreeBSD ELF64, execve), rip =3D 0x800c20d0c, =20= >>>>>>> rsp =3D 0x7fffffffd6f8, rbp =3D 0x7fffffffdbf0 --- >>>>>>> >>>>>> Can you try the following change: >>>>>> >>>>>> = http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_obj= ect.c?r1=3D192842&r2=3D195297 >>>>>> >>>>> Applied this to HEAD by hand an ran with it, it died 20-30 =20 >>>>> minutes into >>>>> the scan-build run. So no luck there. Next up is a test using the >>>>> GENERIC kernel. >>>>> >>>> No improvement with a GENERIC kernel. Next up will be to run this =20= >>>> with >>>> clean sysctl, loader.conf, etc. Then I'll try disabling SMP. >>>> >>>> Does the backtrace above point to any specific subsystem? I'm =20 >>>> using UFS, >>>> ZFS and GELI on this machine and could try a few combinations... >>>> >>> The interesting thing about the backtrace is that it shows a 32-=20 >>> bit i386 executable being started on a 64-bit amd64 machine. I've =20= >>> seen this backtrace once before, and you'll find it in the PR =20 >>> database. In that case, the problem "went away" after the known-=20 >>> to-be-broken ZERO_COPY_SOCKETS option was removed from the =20 >>> reporter's kernel configuration. However, I don't see that as the =20= >>> culprit here. >>> >> >> Hi Alan, first the bad news >> >> I ran this test with a GENERIC kernel, SMP disabled, hw.physmem set =20= >> to 2 >> GB in single user mode, so no other processes or deamons running, >> nothing special in loader.conf except for ZFS and GELI. It reliably >> panics, so nothing new here. >> >> Now the good news, you may be able to crash your own amd64 box in 3 >> minutes by doing: >> >> mkdir /tmp/foo && cd /tmp/foo >> fetch -o- https://www.spoerlein.net/pub/llvm-clang.tar.gz | tar xf - >> while :; do for d in bin sbin usr.bin usr.sbin; do $PWD/scan-build -=20= >> o /dev/null -k make -C /usr/src/$d clean obj depend all; done; done >> >> Please note that scan-build/ccc-analyzer wont actually do anything, =20= >> as >> they cannot create output in /dev/null. So this is just running the >> perl-script and forking make/sh/awk/ccc-analyzer like mad. It does =20= >> not >> survive 3 minutes on my Core2 Duo 3.3 GHz. >> > > Hi Ulrich, > > I finally got a chance to try this workload. I'm afraid that I =20 > can't reproduce the assertion failure on my amd64 test machine. I =20 > left the test running overnight, and it was still going strong this =20= > morning. > > I am using neither ZFS nor GELI. Is it possible for you to repeat =20 > this test without ZFS and/or GELI? > > I would also be curious if anyone else reading this message can =20 > reproduce the assertion failure with the above test. It ran fine for me for an hour as well, assuming the error messages =20 regarding /dev/null/2009-08-12-1/ are normal. No crashes or panics. =20 amd64 with ZFS root (UFS boot) and DTrace. No patch relating to this =20 applied. dmesg: FreeBSD 8.0-BETA2 #3 r196086M: Sun Aug 9 21:03:12 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/src/sys/DTRACE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.27-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x10ff0 Stepping =3D 0 =20 Features=20 =3D=20 0x78bfbff=20 <=20 FPU=20 ,VME=20 ,DE=20 ,PSE=20 ,TSC=20 ,MSR=20 ,PAE=20 ,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> AMD Features=3D0xe2500800 AMD Features2=3D0x1 real memory =3D 2147483648 (2048 MB) avail memory =3D 2051895296 (1956 MB) ACPI APIC Table: This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq =20 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfe02e000-0xfe02e0ff =20 irq 22 at device 2.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port =20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfb00-0xfb0f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port =20 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf600-0xf60f mem =20 0xfe02b000-0xfe02bfff irq 23 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port =20 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf100-0xf10f mem =20 0xfe02a000-0xfe02afff irq 21 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib1: at device 9.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfcff8000-0xfcffbfff,=20 0xfd000000-0xfd7fffff,0xfc000000-0xfc7fffff irq 17 at device 7.0 on pci1 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdf00-0xdf7f mem =20 0xfcfff000-0xfcfff07f irq 18 at device 9.0 on pci1 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:50:da:44:c0:4a xl0: [ITHREAD] nfe0: port =20 0xf000-0xf007 mem 0xfe029000-0xfe029fff irq 22 at device 10.0 on pci0 miibus1: on nfe0 e1000phy0: PHY 1 on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, =20= 1000baseT-FDX, auto nfe0: Ethernet address: 00:13:d3:a2:aa:0f nfe0: [FILTER] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 amdtemp0: on hostb3 acpi_tz0: on acpi0 atrtc0: port 0x70-0x73 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,=20 0xcc000-0xcc7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on =20 isa0 ppc0: cannot reserve I/O port range WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounter "TSC" frequency 2009269338 Hz quality 800 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ZFS NOTICE: system has less than 4GB and prefetch enable is not set... =20= disabling. ZFS filesystem version 13 ZFS storage pool version 13 ad0: 76318MB at ata0-master UDMA100 ad2: 9768MB at ata1-master UDMA100 ugen0.1: at usbus0 uhub0: on =20 usbus0 GEOM: ad2s1: geometry does not match label (255h,63s !=3D 16h,63s). Root mount waiting for: usbus1 usbus0 uhub0: 10 ports with 10 removable, self powered ugen1.1: at usbus1 uhub1: on =20 usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub1: 10 ports with 10 removable, self powered Trying to mount root from zfs:tank/root Regards, Thomas= From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 18:17:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49498106566C; Wed, 12 Aug 2009 18:17:37 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 769888FC43; Wed, 12 Aug 2009 18:17:35 +0000 (UTC) Received: by ewy2 with SMTP id 2so202441ewy.43 for ; Wed, 12 Aug 2009 11:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=SPnwdjEiVZuWn5ll+3NDfWqet8V3dYmbUil1MzJGRFA=; b=Gt+CyJ3LDOVjba7epvuQ57lReRG1FZqbeSkBxj+RaOHlu3QKoF8u9U624SboPVhXVt 2vkihZYtiAkHdqJV6C2HF2ZlOhY+4TJKwPLwMOlX0s69jtllkEjH3DU+9n951GMSyKgR rQmPP/I+UWEPoqufBJRv1p3vAGeNYSUfU0M80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=GsZNevvXeDKMJqt1EI+4pz7jnHgcqKAJQ7IFygy/O0U6kF7hArQ48NlKn8ZjinW06r n4tmxuBMn5cLdDkgB6vvJ27RKlv8KDehGlHQ26o9NWqovq1/rQyiAVdhW3W5rGfqCc50 ObNcicivegt0pAdX2a/ciMchbi/rpMykqQT7A= Received: by 10.210.102.9 with SMTP id z9mr484714ebb.16.1250099213337; Wed, 12 Aug 2009 10:46:53 -0700 (PDT) Received: from localhost (95-24-66-205.broadband.corbina.ru [95.24.66.205]) by mx.google.com with ESMTPS id 7sm629092eyg.55.2009.08.12.10.46.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 10:46:52 -0700 (PDT) From: Anonymous To: current@freebsd.org References: <200908121335.n7CDZZcg047419@lava.sentex.ca> Date: Wed, 12 Aug 2009 21:46:48 +0400 In-Reply-To: (Robert Watson's message of "Wed, 12 Aug 2009 14:47:19 +0100 (BST)") Message-ID: <863a7wc4c7.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Robert Watson , Mike Tancsa Subject: Re: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 18:17:38 -0000 Robert Watson writes: > On Wed, 12 Aug 2009, Mike Tancsa wrote: > >>> As we're approaching 8.0 BETA3, now would be a really good time to >>> start identifying functional and performance regressions from the >>> 7.x series. We've done a mixed job at this in the past, but when it >>> comes to "I'll do better some day", there's no time like the >>> present :-). Some notes: >> >> Other than the removal of whats below from the kernel, what other >> adjustments should be made to make more accurate comparisons ? > > The main thing I'm aware of is malloc debugging in userspace -- the > best way to do this is to uncomment MALLOC_PRODUCTION in > src/lib/libc/stdlib/malloc.c: [...] According to docs/136029 one can also use it in make.conf(5), no need to touch malloc.c. From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 20:20:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDA8A1065673 for ; Wed, 12 Aug 2009 20:20:05 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id A444F8FC44 for ; Wed, 12 Aug 2009 20:20:05 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id A306F851E for ; Wed, 12 Aug 2009 20:20:03 +0000 (UTC) Date: Wed, 12 Aug 2009 21:19:59 +0100 From: Bruce Cran To: current@freebsd.org Message-ID: <20090812211959.0000293c@unknown> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: sctp panic in _mtx_lock_sleep when attempting to connect to a remote machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:20:06 -0000 I've found a way to reliably panic two machines running 8.0-BETA2. It seems that there's a problem with SCTP connection requests being made at the same time as other network traffic. The panic I see is: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 Stack trace: _mtx_lock_sleep sctp_lower_sosend sctp_sosend kern_sendit sendit sendto sycall Xfast_syscall I can trigger it by running the SCTP-enabled version of ncat from http://www.roe.ch/Nmap_SCTP . I put a few thousand lines of: cat /dev/random | ./ncat --sctp 192.168.1.80 2345 into a shell script, where 192.168.1.80 is a machine running 7.2 with SCTP enabled but no server listening - I mostly see "Connection refused" errors when I run the script. When I run the script and at the same time generate some tcp traffic by running csup for example, the box panics. -- Bruce From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 20:25:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AE85106566B for ; Wed, 12 Aug 2009 20:25:41 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 093CF8FC15 for ; Wed, 12 Aug 2009 20:25:40 +0000 (UTC) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 465CB79002; Thu, 13 Aug 2009 00:25:38 +0400 (MSD) Message-ID: <4A832545.7020807@haruhiism.net> Date: Thu, 13 Aug 2009 00:25:41 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Bruce Cran References: <20090812211959.0000293c@unknown> In-Reply-To: <20090812211959.0000293c@unknown> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: sctp panic in _mtx_lock_sleep when attempting to connect to a remote machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:25:41 -0000 Bruce Cran wrote: > I've found a way to reliably panic two machines running 8.0-BETA2. > Stack trace: > _mtx_lock_sleep > sctp_lower_sosend > sctp_sosend > kern_sendit > sendit > sendto > sycall > Xfast_syscall > Please pay attention to this thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010241.html There is a patch available in that thread, as well. Judging by the stack trace, it is the same case of a non-aligned pointer. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 20:35:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D134C106564A for ; Wed, 12 Aug 2009 20:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8CF278FC48 for ; Wed, 12 Aug 2009 20:35:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id BCAD241C678; Wed, 12 Aug 2009 22:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id CXMhjhnsFUDB; Wed, 12 Aug 2009 22:35:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id D609941C66F; Wed, 12 Aug 2009 22:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1F7F44448EC; Wed, 12 Aug 2009 20:30:39 +0000 (UTC) Date: Wed, 12 Aug 2009 20:30:39 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Bruce Cran In-Reply-To: <20090812211959.0000293c@unknown> Message-ID: <20090812202853.Q93661@maildrop.int.zabbadoz.net> References: <20090812211959.0000293c@unknown> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: sctp panic in _mtx_lock_sleep when attempting to connect to a remote machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:35:08 -0000 On Wed, 12 Aug 2009, Bruce Cran wrote: Hi, > I've found a way to reliably panic two machines running 8.0-BETA2. It > seems that there's a problem with SCTP connection requests being made > at the same time as other network traffic. The panic I see is: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > > Stack trace: > > _mtx_lock_sleep > sctp_lower_sosend > sctp_sosend > kern_sendit > sendit > sendto > sycall > Xfast_syscall unfrotunately the most intersting info is missing but it's likely that you are hitting this: http://lists.freebsd.org/pipermail/svn-src-stable-other/2009-August/000023.html I you update to latest HEAD or stable/8, can you still reproduce it? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 20:47:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472F8106566B for ; Wed, 12 Aug 2009 20:47:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2DB8FC43 for ; Wed, 12 Aug 2009 20:47:38 +0000 (UTC) Received: by ywh17 with SMTP id 17so419948ywh.3 for ; Wed, 12 Aug 2009 13:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Iv309wMo3D75mso3e26/B7dDnj55/29MPEGbjA1+go4=; b=N/z2Fm2UumJtsRodKKrzlK8ek6iGQy3/3E4f2c9q5IhTC0N51xJ4kuYJD3BVtPluXM 0Z5c3hgxNKaw9i5KIHm+igAjADRrYeLOsiLy5HHGr+DxUJafM6NhEDSngWbDQrrCJ3VG VG81J00pAUirPsc4KKaUnrvfWMIVQAWFS227M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=h8uIHAaumRq1tNaQMwxlYciH1V1jYchbT5zxzvWkS+ZiEuc+xwUL60ttZnkdjwqvTS 5nXUV/9Ea8NCrcqlGrjL2iRvhFAkhcKi9UfsSsbBMYd+UElxd4BrLEnc1qHQAOBbKchq /ktoVLFFBZqHQki/ZpfCUBRPUzEFiDg9UCOFc= Received: by 10.90.71.14 with SMTP id t14mr197640aga.66.1250108525242; Wed, 12 Aug 2009 13:22:05 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 25sm339734aga.17.2009.08.12.13.22.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 13:22:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Aug 2009 13:21:00 -0700 From: Pyun YongHyeon Date: Wed, 12 Aug 2009 13:21:00 -0700 To: Gavin Atkinson Message-ID: <20090812202100.GB55129@michelle.cdnetworks.com> References: <80f4f2b20908061705h6b218702ked110fa54d1bee5@mail.gmail.com> <1250088500.17787.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <1250088500.17787.6.camel@buffy.york.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Jim Subject: Re: FreeBSD 8.0 Beta2 / ALC driver crashbase X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:47:57 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 12, 2009 at 03:48:20PM +0100, Gavin Atkinson wrote: > On Thu, 2009-08-06 at 20:05 -0400, Jim wrote: > > I couldn't get the copy of the if_alc driver to compile in FreeBSD 7.2 > > on my new notebook, so I decided to use 8.0, and I found an issue, > > when I boot the installer media CD (boot only or DVD1), I get the > > following error: > > > > alc0: irq 16 at device 0.0 on pci7 > > alc0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). > > alc0: cannot allocate memory resources). > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fatal virtual address = 0x08 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff0024c6e8 > > stack pointer = 0x20:0xffffffff813f65f0 > > frame pointer = 0x20:0xffffffff813f6600 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DLP 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > correct process = 0 (swapper) > > [thread pid 0 tid 100000 ] > > Stopped at alc_phy_down+0x0: cmpq $0,0x8(xrax) > > db> > > > > > > I'm not knowledgeable about this to the point where I could debug the > > issue, is there anything I could do to provide the developers with the > > info needed to fix the issue, or could someone tell me how to boot the > > installer and force it to not load if_alc, and suggest give me an idea > > of what this means, in laymans terms so I can try to diagnose it? If I > > had to guess, I would say it's trying to access a chunk of > > memory/address-space that hasn't been allocated or doesn't exist, but > > I don't know if that's correct or where to go from there. > > First thing to do, at the "db> " prompt, enter "bt" and show us the > results. What version of FreeBSD is this? (8.0-BETA2 I'm assuming?) > > There are probably at least two issues here: 1) The allocation shouldn't > fail, but is, and 2) it shouldn't panic. Getting a backtrace (with "bt" > will hopefully be enough to figure out the second issue, but for the > first one we may need a full verbose dmesg from the system. Do you have I guess I found a bug in failure path. Try attached one. > a serial console hooked up to the machine with which you could obtain > this? > > Thanks, > > Gavin --yrj/dFKFPuw6o+aM Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="alc.diff" Index: if_alc.c =================================================================== --- if_alc.c (revision 196104) +++ if_alc.c (working copy) @@ -858,7 +858,8 @@ sc->alc_intrhand[i] = NULL; } } - alc_phy_down(sc); + if (sc->alc_res_spec != NULL) + alc_phy_down(sc); bus_release_resources(dev, sc->alc_irq_spec, sc->alc_irq); if ((sc->alc_flags & (ALC_FLAG_MSI | ALC_FLAG_MSIX)) != 0) pci_release_msi(dev); --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 20:56:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E25C106566B for ; Wed, 12 Aug 2009 20:56:20 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id D438C8FC43 for ; Wed, 12 Aug 2009 20:56:19 +0000 (UTC) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n7CKuHmd032595 for ; Wed, 12 Aug 2009 22:56:17 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A832C70.4030600@fgznet.ch> Date: Wed, 12 Aug 2009 22:56:16 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Subject: tools/kerneldoc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 20:56:20 -0000 Hi, does anybody care about this 'kerneldoc' package? Robert's call for testers made me browse through this tools directory and as a newbie I wanted to start with something easy. But I horribly fail to build the docs. %deuterium_fbsd# make %make: don't know how to make device_if.m. Stop I then dived into the subsys dir and started a 'make all'. Here too, I failed since a few .m files are no more or they are placed on a different place. Well, this was easy, more or less. Commenting them made the build work, but this is only half the truth, what about the new .m files? I launched a 'find . -name "*.m" | sort | sed s_\./_MFILES+=_' in the /usr/src/sys dir and adjusted the Makefile in subsys. Still building... but it is building! So, my simple question, is this kerneldoc something we want to have maintained? Or is it an artifact from earlier times? TIA, Andreas From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 21:13:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2E8D1065670 for ; Wed, 12 Aug 2009 21:13:55 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 720CD8FC47 for ; Wed, 12 Aug 2009 21:13:55 +0000 (UTC) Received: by yxe11 with SMTP id 11so443597yxe.3 for ; Wed, 12 Aug 2009 14:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=Iv309wMo3D75mso3e26/B7dDnj55/29MPEGbjA1+go4=; b=N/z2Fm2UumJtsRodKKrzlK8ek6iGQy3/3E4f2c9q5IhTC0N51xJ4kuYJD3BVtPluXM 0Z5c3hgxNKaw9i5KIHm+igAjADRrYeLOsiLy5HHGr+DxUJafM6NhEDSngWbDQrrCJ3VG VG81J00pAUirPsc4KKaUnrvfWMIVQAWFS227M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=h8uIHAaumRq1tNaQMwxlYciH1V1jYchbT5zxzvWkS+ZiEuc+xwUL60ttZnkdjwqvTS 5nXUV/9Ea8NCrcqlGrjL2iRvhFAkhcKi9UfsSsbBMYd+UElxd4BrLEnc1qHQAOBbKchq /ktoVLFFBZqHQki/ZpfCUBRPUzEFiDg9UCOFc= Received: by 10.90.71.14 with SMTP id t14mr197640aga.66.1250108525242; Wed, 12 Aug 2009 13:22:05 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 25sm339734aga.17.2009.08.12.13.22.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 13:22:04 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Aug 2009 13:21:00 -0700 From: Pyun YongHyeon Date: Wed, 12 Aug 2009 13:21:00 -0700 To: Gavin Atkinson Message-ID: <20090812202100.GB55129@michelle.cdnetworks.com> References: <80f4f2b20908061705h6b218702ked110fa54d1bee5@mail.gmail.com> <1250088500.17787.6.camel@buffy.york.ac.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <1250088500.17787.6.camel@buffy.york.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Jim Subject: Re: FreeBSD 8.0 Beta2 / ALC driver crashbase X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 21:13:56 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 12, 2009 at 03:48:20PM +0100, Gavin Atkinson wrote: > On Thu, 2009-08-06 at 20:05 -0400, Jim wrote: > > I couldn't get the copy of the if_alc driver to compile in FreeBSD 7.2 > > on my new notebook, so I decided to use 8.0, and I found an issue, > > when I boot the installer media CD (boot only or DVD1), I get the > > following error: > > > > alc0: irq 16 at device 0.0 on pci7 > > alc0: 0x40000 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). > > alc0: cannot allocate memory resources). > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fatal virtual address = 0x08 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff0024c6e8 > > stack pointer = 0x20:0xffffffff813f65f0 > > frame pointer = 0x20:0xffffffff813f6600 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DLP 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > correct process = 0 (swapper) > > [thread pid 0 tid 100000 ] > > Stopped at alc_phy_down+0x0: cmpq $0,0x8(xrax) > > db> > > > > > > I'm not knowledgeable about this to the point where I could debug the > > issue, is there anything I could do to provide the developers with the > > info needed to fix the issue, or could someone tell me how to boot the > > installer and force it to not load if_alc, and suggest give me an idea > > of what this means, in laymans terms so I can try to diagnose it? If I > > had to guess, I would say it's trying to access a chunk of > > memory/address-space that hasn't been allocated or doesn't exist, but > > I don't know if that's correct or where to go from there. > > First thing to do, at the "db> " prompt, enter "bt" and show us the > results. What version of FreeBSD is this? (8.0-BETA2 I'm assuming?) > > There are probably at least two issues here: 1) The allocation shouldn't > fail, but is, and 2) it shouldn't panic. Getting a backtrace (with "bt" > will hopefully be enough to figure out the second issue, but for the > first one we may need a full verbose dmesg from the system. Do you have I guess I found a bug in failure path. Try attached one. > a serial console hooked up to the machine with which you could obtain > this? > > Thanks, > > Gavin --yrj/dFKFPuw6o+aM Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="alc.diff" Index: if_alc.c =================================================================== --- if_alc.c (revision 196104) +++ if_alc.c (working copy) @@ -858,7 +858,8 @@ sc->alc_intrhand[i] = NULL; } } - alc_phy_down(sc); + if (sc->alc_res_spec != NULL) + alc_phy_down(sc); bus_release_resources(dev, sc->alc_irq_spec, sc->alc_irq); if ((sc->alc_flags & (ALC_FLAG_MSI | ALC_FLAG_MSIX)) != 0) pci_release_msi(dev); --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 21:50:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD8EA106564A for ; Wed, 12 Aug 2009 21:50:37 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1D48FC59 for ; Wed, 12 Aug 2009 21:50:37 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so126904qwe.7 for ; Wed, 12 Aug 2009 14:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=rQ9CnAJQsMEgB+QAisvTu5Q7/QOvVxmZdKTVPeUFtZM=; b=hWchJ129DM2MRzlUVLvT3jqs1agZxOgMMNmCs0avL/EokCtsxAjDDAgx0MZbNNoyZN 7dBgeTWXDeEp/2NxFLmoVfwGJrsL63qOaFeRFaHE5G8RHOM9G/+0LjLkjdqcQbFgzbX+ 5wSIGKLZj80bDDs1x4k2qFKI3sZIvQVRyxi6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=EGg5ylWyzIOcYCBAhcXusv65GSNkWXPEKdidlJGwpiff84ShxgqMxl5LZWW5nLGaii 0D6HfF5fOqZfQ+JAxFKenCHi0amutZmwDZDAmrrAeY5tydxvRWTuWsdm4W+o7rfNi+9e uTSDc/S/75RPGq1thXJdbCwKrdrwq4zOR9b+M= Received: by 10.224.65.77 with SMTP id h13mr667716qai.368.1250113836673; Wed, 12 Aug 2009 14:50:36 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 6sm407562qwk.42.2009.08.12.14.50.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 14:50:35 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 12 Aug 2009 14:49:32 -0700 From: Pyun YongHyeon Date: Wed, 12 Aug 2009 14:49:32 -0700 To: Ryan Rogers Message-ID: <20090812214932.GH55129@michelle.cdnetworks.com> References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline In-Reply-To: <4A679223.10604@doghouserepair.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 21:50:37 -0000 --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 22, 2009 at 03:26:43PM -0700, Ryan Rogers wrote: > Weongyo Jeong wrote: > >On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: > >>>svn co svn://svn.freebsd.org/base/head > >>>svn merge -c -193289 > >>> > >>>Thereafter, in the root of the repo: > >>>svn up > >>>svn merge > >>Confirmed, running the above set of commands fixed my 88E1116 nfe problem > >>everything works as it should now. thanks guys for the help. > >> > >>Sam Fourman Jr. > >> > >>ps. svn was WAY faster than csup, I think I am going to use svn all > >>the time now. > > > >I know that yongari@ knows what the problem is and the solution but he > >could not access the internet right now due to relocation to USA. > > > >It looks he is busy with looking for house and etc... > > > >regards, > >Weongyo Jeong > > > > > > > > Well, the good news is that r193289 was the only thing keeping my nics > from working. I was able to update to current as of today and revert > that patch, and everything is working nicely now. So I'll just keep my > eye on the commit logs and patch that up by hand whenever I need to > update until yongari is able to get situated. > Would you try attached patch and let me know how it goes on your box? --ALfTUftag+2gvp1h Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="e1000phy.88E1116.diff" Index: sys/dev/mii/e1000phy.c =================================================================== --- sys/dev/mii/e1000phy.c (revision 196104) +++ sys/dev/mii/e1000phy.c (working copy) @@ -151,12 +151,13 @@ if (PHY_READ(sc, E1000_ESSR) & E1000_ESSR_FIBER_LINK) sc->mii_flags |= MIIF_HAVEFIBER; break; + case MII_MODEL_MARVELL_E1116: case MII_MODEL_MARVELL_E1149: /* - * Some 88E1149 PHY's page select is initialized to - * point to other bank instead of copper/fiber bank - * which in turn resulted in wrong registers were - * accessed during PHY operation. It is believed that + * Some 88E1116 and 88E1149 PHY's page selection is + * initialized to point to other bank instead of + * copper/fiber bank which in turn resulted in accessing + * wrong registers during PHY operation. It is believed * page 0 should be used for copper PHY so reinitialize * E1000_EADR to select default copper PHY. If parent * device know the type of PHY(either copper or fiber), --ALfTUftag+2gvp1h-- From owner-freebsd-current@FreeBSD.ORG Wed Aug 12 23:21:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CA6D106566C for ; Wed, 12 Aug 2009 23:21:23 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id C95428FC52 for ; Wed, 12 Aug 2009 23:21:22 +0000 (UTC) Received: from [130.89.165.91] (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n7CNLEFN016664 for ; Thu, 13 Aug 2009 01:21:14 +0200 Message-ID: <4A834E69.4060603@degoeje.nl> Date: Thu, 13 Aug 2009 01:21:13 +0200 From: Pieter de Goeje User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Subject: Witness: acquiring duplicate lock of same type: "ftlk" in linux_futex.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2009 23:21:23 -0000 After upgrading a kernel from 7-stable to current, I got this witness warning during startup: acquiring duplicate lock of same type: "ftlk" 1st ftlk @ /FreeBSD/FreeBSD-current-clean/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 2nd ftlk @ /FreeBSD/FreeBSD-current-clean/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x8ef _sx_xlock() at _sx_xlock+0x55 futex_get0() at futex_get0+0xfe linux_sys_futex() at linux_sys_futex+0x22b ia32_syscall() at ia32_syscall+0x19c Xint0x80_syscall() at Xint0x80_syscall+0x95 --- syscall (240, Linux ELF32, linux_sys_futex), rip = 0x28080a91, rsp = 0x2b13834c, rbp = 0x2 --- I run a linux app (half-life dedicated server) on linux_base-f8, which uses futexes. The warning doesn't seem to impact functionality. I don't think it matters but I only installed the new kernel and modules to test things before I do a full upgrade. - Pieter From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 00:32:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36A53106564A for ; Thu, 13 Aug 2009 00:32:03 +0000 (UTC) (envelope-from rincebrain@gmail.com) Received: from mail-vw0-f180.google.com (mail-vw0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id E4F0B8FC43 for ; Thu, 13 Aug 2009 00:32:02 +0000 (UTC) Received: by vws10 with SMTP id 10so388308vws.7 for ; Wed, 12 Aug 2009 17:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=cvaPYm4crbeGOUPu6/gDqkzxyuC/837oDqcLC7H11Xs=; b=hwaWzRQy7fxDb5YLYxJ+emO7kUghVTsDhQKDKAT/7PpbEkM3sSxp8u/Bh+5TboWcmX G6HHASNu6J2fRvYDQ6EMRQCGVuinFE6UNUsAmy9T7MehW4PDq/3Ek04NtTI+Sx3Mcbjf 8I42ekkw4zi8/2+OPcJM7K0qqYSSrL2I46szw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=WPZMLIik8Jj+NvefQ7x08wrVhe0apvwIsoVZBW+d/QMMit07bARfe8SnQXPq6Z7X2O KxIhCEveACv3aEwgSk4Fo6hZ5rN08yzvYCJ05AgA/2rgq7pCAlffHtqE3XApMz6ycbQW hbLaQqFvJatFOGz0rAN61V5gkgXxZQNn8eiLc= MIME-Version: 1.0 Received: by 10.220.4.41 with SMTP id 41mr652305vcp.79.1250122057975; Wed, 12 Aug 2009 17:07:37 -0700 (PDT) Date: Wed, 12 Aug 2009 20:07:37 -0400 Message-ID: <5da0588e0908121707je41a157i569d4ecf64951727@mail.gmail.com> From: Rich To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Areca ARC-1280ML weirdness on amd64 8.0-BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 00:32:03 -0000 Hello world. I've got an AMD64 ASUS motherboard with an Areca ARC-1280ML attached. The card is neatly supported in FreeBSD, from what I've seen - all the drives I plugged in showed up, everything was happy, I created a 10-disk RAID-Z2 across the drives, hurray. Run it for a few days, scrub a few things, reboot a number of times, everything's a dream. Unplug everything, move it to its final location, replug everything. Hm, how strange. I'm only seeing /dev/da0 through da6 instead of da0 through da10 [there were 11 drives attached, one unused]. Okay, poke the ARC-1280ML directly using the sysutils/areca-cli utility. Reports all 11 drives happily attached. dmesg only reports notes on da0 through da6. camcontrol reports: # camcontrol devlist -v scbus0 on arcmsr0 bus 0: at scbus0 target 1 lun 0 (da0,pass0) at scbus0 target 1 lun 1 (da1,pass1) at scbus0 target 1 lun 2 (da2,pass2) at scbus0 target 1 lun 3 (da3,pass3) at scbus0 target 1 lun 4 (da4,pass4) at scbus0 target 1 lun 5 (da5,pass5) at scbus0 target 1 lun 6 (da6,pass6) at scbus0 target 16 lun 0 (pass7) <> at scbus0 target -1 lun -1 () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) camcontrol rescan all changes nothing. In stark contrast, areca-cli: # areca-cli disk info # Ch# ModelName Capacity Usage =============================================================================== 1 1 N.A. 0.0GB N.A. 2 2 N.A. 0.0GB N.A. 3 3 N.A. 0.0GB N.A. 4 4 N.A. 0.0GB N.A. 5 5 ST31500341AS 1500.3GB JBOD 6 6 ST31500341AS 1500.3GB JBOD 7 7 ST31500341AS 1500.3GB JBOD 8 8 ST31500341AS 1500.3GB JBOD 9 9 ST31500341AS 1500.3GB JBOD 10 10 ST31500341AS 1500.3GB JBOD 11 11 ST31500341AS 1500.3GB JBOD 12 12 ST31500341AS 1500.3GB JBOD 13 13 ST3160827AS 160.0GB JBOD 14 14 ST31500341AS 1500.3GB JBOD 15 15 ST31500341AS 1500.3GB JBOD 16 16 N.A. 0.0GB N.A. 17 17 N.A. 0.0GB N.A. 18 18 N.A. 0.0GB N.A. 19 19 N.A. 0.0GB N.A. 20 20 N.A. 0.0GB N.A. 21 21 N.A. 0.0GB N.A. 22 22 N.A. 0.0GB N.A. 23 23 N.A. 0.0GB N.A. 24 24 N.A. 0.0GB N.A. =============================================================================== GuiErrMsg<0x00>: Success. Is there something I've missed, or is this just broken behavior? - Rich -- My own business always bores me to death; I prefer other people's. -- Oscar Wilde From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 00:35:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA7FA106566C for ; Thu, 13 Aug 2009 00:35:31 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from slow3-v.mail.gandi.net (slow3-v.mail.gandi.net [217.70.178.89]) by mx1.freebsd.org (Postfix) with ESMTP id 2122A8FC60 for ; Thu, 13 Aug 2009 00:35:31 +0000 (UTC) Received: from relay1-v.mail.gandi.net (relay1-v.mail.gandi.net [217.70.178.75]) by slow3-v.mail.gandi.net (Postfix) with ESMTP id A0F013B39C for ; Thu, 13 Aug 2009 01:21:44 +0200 (CEST) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.226]) by relay1-v.mail.gandi.net (Postfix) with ESMTP id 9534E36287 for ; Thu, 13 Aug 2009 02:21:51 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id D4D2DD066; Wed, 12 Aug 2009 20:21:06 -0400 (EDT) Date: Wed, 12 Aug 2009 20:21:06 -0400 From: Damian Gerow To: freebsd-current@freebsd.org Message-ID: <20090813002104.GA1481@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.20 (2009-06-14) Subject: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 00:35:32 -0000 Some time between r195828 and r196086, resuming from an S3 suspend seems to have broken for me. When resuming in text mode, the system locks up completely before the screen comes back on. Of course, resuming from text mode has never worked, so this isn't much of a concern. When resuming from graphics mode, the screen is restored, but fails to update beyond restoring the initial display. The keyboard responds (caps lock light turns on, changing the console results in an error beep), but that's about it. Ctrl+alt+delete does cleanly reboot the system at this point, and after reboot, I can see the system did actually come back cleanly. The system is a Lenovo X200, running an amd64 install of r196086 (standard GENERIC kernel) The graphics chipset is an Intel X4500MHD. Verbose dmesg below. -- dmesg.verbose Aug 12 20:00:14 plebeian syslogd: kernel boot file is /boot/kernel/kernel Aug 12 20:00:14 plebeian kernel: Copyright (c) 1992-2009 The FreeBSD Project. Aug 12 20:00:14 plebeian kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Aug 12 20:00:14 plebeian kernel: The Regents of the University of California. All rights reserved. Aug 12 20:00:14 plebeian kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Aug 12 20:00:14 plebeian kernel: FreeBSD 8.0-BETA2 #2 r196086: Sat Aug 8 18:48:02 EDT 2009 Aug 12 20:00:14 plebeian kernel: dgerow@plebeian.afflictions.org:/usr/obj/usr/src/sys/GENERIC Aug 12 20:00:14 plebeian kernel: WARNING: WITNESS option enabled, expect reduced performance. Aug 12 20:00:14 plebeian kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff810cc000. Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/linux.ko" at 0xffffffff810cc378. Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff810ccb20. Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff810cd148. Aug 12 20:00:14 plebeian kernel: Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff810cd7f0. Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/aio.ko" at 0xffffffff810cd850. Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff810cdeb8. Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff810ce420. Aug 12 20:00:14 plebeian kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Aug 12 20:00:14 plebeian kernel: Calibrating TSC clock ... TSC clock: 2394009747 Hz Aug 12 20:00:14 plebeian kernel: CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (2394.01-MHz K8-class CPU) Aug 12 20:00:14 plebeian kernel: Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Aug 12 20:00:14 plebeian kernel: Features=0xbfebfbff Aug 12 20:00:14 plebeian kernel: Features2=0x8e3fd Aug 12 20:00:14 plebeian kernel: AMD Features=0x20100800 Aug 12 20:00:14 plebeian kernel: AMD Features2=0x1 Aug 12 20:00:14 plebeian kernel: TSC: P-state invariant Aug 12 20:00:14 plebeian kernel: real memory = 4294967296 (4096 MB) Aug 12 20:00:14 plebeian kernel: Physical memory chunk(s): Aug 12 20:00:14 plebeian kernel: 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) Aug 12 20:00:14 plebeian kernel: 0x00000000010fd000 - 0x00000000b4200fff, 3004186624 bytes (733444 pages) Aug 12 20:00:14 plebeian kernel: 0x00000000bd6a7000 - 0x00000000bd7b6fff, 1114112 bytes (272 pages) Aug 12 20:00:14 plebeian kernel: 0x00000000bd80f000 - 0x00000000bd8c6fff, 753664 bytes (184 pages) Aug 12 20:00:14 plebeian kernel: 0x00000000bdbff000 - 0x00000000bdbfffff, 4096 bytes (1 pages) Aug 12 20:00:14 plebeian kernel: 0x0000000100000000 - 0x000000013bfeffff, 1006567424 bytes (245744 pages) Aug 12 20:00:14 plebeian kernel: avail memory = 3989790720 (3804 MB) Aug 12 20:00:14 plebeian kernel: ACPI APIC Table: Aug 12 20:00:14 plebeian kernel: INTR: Adding local APIC 1 as a target Aug 12 20:00:14 plebeian kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Aug 12 20:00:14 plebeian kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Aug 12 20:00:14 plebeian kernel: cpu0 (BSP): APIC ID: 0 Aug 12 20:00:14 plebeian kernel: cpu1 (AP): APIC ID: 1 Aug 12 20:00:14 plebeian kernel: APIC: CPU 0 has ACPI ID 0 Aug 12 20:00:14 plebeian kernel: APIC: CPU 1 has ACPI ID 1 Aug 12 20:00:14 plebeian kernel: ULE: setup cpu 0 Aug 12 20:00:14 plebeian kernel: ULE: setup cpu 1 Aug 12 20:00:14 plebeian kernel: ACPI: RSDP 0xf7380 00024 (v2 LENOVO) Aug 12 20:00:14 plebeian kernel: ACPI: XSDT 0xbdb7bd45 00094 (v1 LENOVO TP-6D 00001070 LTP 00000000) Aug 12 20:00:14 plebeian kernel: ACPI: FACP 0xbdb7bf00 000F4 (v3 LENOVO TP-6D 00001070 LNVO 00000001) Aug 12 20:00:14 plebeian kernel: ACPI: DSDT 0xbdb7c2f4 0D910 (v1 LENOVO TP-6D 00001070 MSFT 03000000) Aug 12 20:00:14 plebeian kernel: ACPI: FACS 0xbdb8e000 00040 Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbdb7c0b4 00240 (v1 LENOVO TP-6D 00001070 MSFT 03000000) Aug 12 20:00:14 plebeian kernel: ACPI: ECDT 0xbdb89c04 00052 (v1 LENOVO TP-6D 00001070 LNVO 00000001) Aug 12 20:00:14 plebeian kernel: ACPI: APIC 0xbdb89c56 00078 (v1 LENOVO TP-6D 00001070 LNVO 00000001) Aug 12 20:00:14 plebeian kernel: ACPI: MCFG 0xbdb89cce 0003C (v1 LENOVO TP-6D 00001070 LNVO 00000001) Aug 12 20:00:14 plebeian kernel: ACPI: HPET 0xbdb89d0a 00038 (v1 LENOVO TP-6D 00001070 LNVO 00000001) Aug 12 20:00:14 plebeian kernel: ACPI: SLIC 0xbdb89dc2 00176 (v1 LENOVO TP-6D 00001070 LTP 00000000) Aug 12 20:00:14 plebeian kernel: ACPI: BOOT 0xbdb89f38 00028 (v1 LENOVO TP-6D 00001070 LTP 00000001) Aug 12 20:00:14 plebeian kernel: ACPI: ASF! 0xbdb89f60 000A0 (v16 LENOVO TP-6D 00001070 PTL 00000001) Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbdb8d203 0055F (v1 LENOVO TP-6D 00001070 INTL 20050513) Aug 12 20:00:14 plebeian kernel: ACPI: TCPA 0xbd907000 00032 (v0 00000000 00000000) Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d4000 00655 (v1 PmRef CpuPm 00003000 INTL 20050624) Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d3000 00274 (v1 PmRef Cpu0Tst 00003000 INTL 20050624) Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d2000 00242 (v1 PmRef ApTst 00003000 INTL 20050624) Aug 12 20:00:14 plebeian kernel: MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 Aug 12 20:00:14 plebeian kernel: ioapic0: Changing APIC ID to 1 Aug 12 20:00:14 plebeian kernel: ioapic0: Routing external 8259A's -> intpin 0 Aug 12 20:00:14 plebeian kernel: MADT: Interrupt override: source 0, irq 2 Aug 12 20:00:14 plebeian kernel: ioapic0: Routing IRQ 0 -> intpin 2 Aug 12 20:00:14 plebeian kernel: MADT: Interrupt override: source 9, irq 9 Aug 12 20:00:14 plebeian kernel: ioapic0: intpin 9 trigger: level Aug 12 20:00:14 plebeian kernel: lapic0: Routing NMI -> LINT1 Aug 12 20:00:14 plebeian kernel: lapic0: LINT1 trigger: edge Aug 12 20:00:14 plebeian kernel: lapic0: LINT1 polarity: high Aug 12 20:00:14 plebeian kernel: lapic1: Routing NMI -> LINT1 Aug 12 20:00:14 plebeian kernel: lapic1: LINT1 trigger: edge Aug 12 20:00:14 plebeian kernel: lapic1: LINT1 polarity: high Aug 12 20:00:14 plebeian kernel: ioapic0 irqs 0-23 on motherboard Aug 12 20:00:14 plebeian kernel: cpu0 BSP: Aug 12 20:00:14 plebeian kernel: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Aug 12 20:00:14 plebeian kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff Aug 12 20:00:14 plebeian kernel: timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 Aug 12 20:00:14 plebeian kernel: snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] Aug 12 20:00:14 plebeian kernel: feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 Aug 12 20:00:14 plebeian kernel: wlan: <802.11 Link Layer> Aug 12 20:00:14 plebeian kernel: nfslock: pseudo-device Aug 12 20:00:14 plebeian kernel: kbd: new array size 4 Aug 12 20:00:14 plebeian kernel: kbd1 at kbdmux0 Aug 12 20:00:14 plebeian kernel: mem: Aug 12 20:00:14 plebeian kernel: null: Aug 12 20:00:14 plebeian kernel: io: Aug 12 20:00:14 plebeian kernel: random: Aug 12 20:00:14 plebeian kernel: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 Aug 12 20:00:14 plebeian kernel: acpi0: on motherboard Aug 12 20:00:14 plebeian kernel: PCIe: Memory Mapped configuration base @ 0xe0000000 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 Aug 12 20:00:14 plebeian kernel: acpi0: [MPSAFE] Aug 12 20:00:14 plebeian kernel: acpi0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: acpi_ec0: port 0x62,0x66 on acpi0 Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.MHCS -> bus 0 dev 0 func 0 Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.EHC0.U7CS -> bus 0 dev 29 func 7 Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.EHC1.U8CS -> bus 0 dev 26 func 7 Aug 12 20:00:14 plebeian kernel: acpi0: Power Button (fixed) Aug 12 20:00:14 plebeian kernel: acpi0: wakeup code va 0xffffff800000f000 pa 0x4000 Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.LPC_.LPCS -> bus 0 dev 31 func 0 Aug 12 20:00:14 plebeian kernel: acpi0: reservation of 0, a0000 (3) failed Aug 12 20:00:14 plebeian kernel: acpi0: reservation of 100000, bff00000 (3) failed Aug 12 20:00:14 plebeian kernel: ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Aug 12 20:00:14 plebeian kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Aug 12 20:00:14 plebeian kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 Aug 12 20:00:14 plebeian kernel: pci_link0: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: pci_link1: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: pci_link2: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: pci_link3: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: pci_link4: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: pci_link5: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: pci_link6: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: pci_link7: Index IRQ Rtd Ref IRQs Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 Aug 12 20:00:14 plebeian kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Aug 12 20:00:14 plebeian kernel: acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Aug 12 20:00:14 plebeian kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 Aug 12 20:00:14 plebeian kernel: acpi_lid0: on acpi0 Aug 12 20:00:14 plebeian kernel: acpi_button0: on acpi0 Aug 12 20:00:14 plebeian kernel: pcib0: port 0xcf8-0xcff on acpi0 Aug 12 20:00:14 plebeian kernel: pci0: on pcib0 Aug 12 20:00:14 plebeian kernel: pci0: domain=0, physical bus=0 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a40, revid=0x07 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=0, func=0 Aug 12 20:00:14 plebeian kernel: class=06-00-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a42, revid=0x07 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=2, func=0 Aug 12 20:00:14 plebeian kernel: class=03-00-00, hdrtype=0x00, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2000000, size 22, enabled Aug 12 20:00:14 plebeian kernel: map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1800, size 3, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.2.INTA Aug 12 20:00:14 plebeian kernel: pcib0: slot 2 INTA hardwired to IRQ 16 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a43, revid=0x07 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=2, func=1 Aug 12 20:00:14 plebeian kernel: class=03-80-00, hdrtype=0x00, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2400000, size 20, enabled Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a44, revid=0x07 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=3, func=0 Aug 12 20:00:14 plebeian kernel: class=07-80-00, hdrtype=0x00, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0006, statreg=0x0018, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2826800, size 4, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.3.INTA Aug 12 20:00:14 plebeian kernel: pcib0: slot 3 INTA hardwired to IRQ 16 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x10f5, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=25, func=0 Aug 12 20:00:14 plebeian kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 32, base 0xf2600000, size 17, enabled Aug 12 20:00:14 plebeian kernel: map[14]: type Memory, range 32, base 0xf2625000, size 12, enabled Aug 12 20:00:14 plebeian kernel: map[18]: type I/O Port, range 32, base 0x1840, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.25.INTA Aug 12 20:00:14 plebeian kernel: pcib0: slot 25 INTA hardwired to IRQ 20 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2937, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=0 Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTA Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTA hardwired to IRQ 20 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2938, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=1 Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTB Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTB hardwired to IRQ 21 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2939, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=2 Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=c, irq=11 Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTC Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTC hardwired to IRQ 22 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x293c, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=7 Aug 12 20:00:14 plebeian kernel: class=0c-03-20, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=d, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 32, base 0xf2826c00, size 10, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTD Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTD hardwired to IRQ 23 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x293e, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=27, func=0 Aug 12 20:00:14 plebeian kernel: class=04-03-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2620000, size 14, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.27.INTB Aug 12 20:00:14 plebeian kernel: pcib0: slot 27 INTB hardwired to IRQ 17 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2940, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=28, func=0 Aug 12 20:00:14 plebeian kernel: class=06-04-00, hdrtype=0x01, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.28.INTA Aug 12 20:00:14 plebeian kernel: pcib0: slot 28 INTA hardwired to IRQ 20 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2942, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=28, func=1 Aug 12 20:00:14 plebeian kernel: class=06-04-00, hdrtype=0x01, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.28.INTB Aug 12 20:00:14 plebeian kernel: pcib0: slot 28 INTB hardwired to IRQ 21 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2946, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=28, func=3 Aug 12 20:00:14 plebeian kernel: class=06-04-00, hdrtype=0x01, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=d, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.28.INTD Aug 12 20:00:14 plebeian kernel: pcib0: slot 28 INTD hardwired to IRQ 23 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2934, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=0 Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x18c0, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTA Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTA hardwired to IRQ 16 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2935, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=1 Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTB Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTB hardwired to IRQ 17 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2936, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=2 Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=c, irq=11 Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1c00, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTC Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTC hardwired to IRQ 18 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x293a, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=7 Aug 12 20:00:14 plebeian kernel: class=0c-03-20, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=d, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 32, base 0xf2827000, size 10, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTD Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTD hardwired to IRQ 19 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2448, revid=0x93 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=30, func=0 Aug 12 20:00:14 plebeian kernel: class=06-04-01, hdrtype=0x01, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2917, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=31, func=0 Aug 12 20:00:14 plebeian kernel: class=06-01-00, hdrtype=0x00, mfdev=1 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2929, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=31, func=2 Aug 12 20:00:14 plebeian kernel: class=01-06-01, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 16 messages Aug 12 20:00:14 plebeian kernel: map[10]: type I/O Port, range 32, base 0x1c48, size 3, enabled Aug 12 20:00:14 plebeian kernel: map[14]: type I/O Port, range 32, base 0x183c, size 2, enabled Aug 12 20:00:14 plebeian kernel: map[18]: type I/O Port, range 32, base 0x1c40, size 3, enabled Aug 12 20:00:14 plebeian kernel: map[1c]: type I/O Port, range 32, base 0x1838, size 2, enabled Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1c20, size 5, enabled Aug 12 20:00:14 plebeian kernel: map[24]: type Memory, range 32, base 0xf2826000, size 11, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.31.INTB Aug 12 20:00:14 plebeian kernel: pcib0: slot 31 INTB hardwired to IRQ 16 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2930, revid=0x03 Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=31, func=3 Aug 12 20:00:14 plebeian kernel: class=0c-05-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2827400, size 8, enabled Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1c60, size 5, enabled Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.31.INTA Aug 12 20:00:14 plebeian kernel: pcib0: slot 31 INTA hardwired to IRQ 23 Aug 12 20:00:14 plebeian kernel: vgapci0: port 0x1800-0x1807 mem 0xf2000000-0xf23fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 Aug 12 20:00:14 plebeian kernel: agp0: on vgapci0 Aug 12 20:00:14 plebeian kernel: vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 Aug 12 20:00:14 plebeian kernel: vgapci0: Reserved 0x400000 bytes for rid 0x10 type 3 at 0xf2000000 Aug 12 20:00:14 plebeian kernel: agp0: detected 32764k stolen memory Aug 12 20:00:14 plebeian kernel: agp0: aperture size is 256M Aug 12 20:00:14 plebeian kernel: vgapci1: mem 0xf2400000-0xf24fffff at device 2.1 on pci0 Aug 12 20:00:14 plebeian kernel: pci0: at device 3.0 (no driver attached) Aug 12 20:00:14 plebeian kernel: em0: port 0x1840-0x185f mem 0xf2600000-0xf261ffff,0xf2625000-0xf2625fff irq 20 at device 25.0 on pci0 Aug 12 20:00:14 plebeian kernel: em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf2600000 Aug 12 20:00:14 plebeian kernel: em0: attempting to allocate 1 MSI vectors (1 supported) Aug 12 20:00:14 plebeian kernel: msi: routing MSI IRQ 256 to local APIC 0 vector 49 Aug 12 20:00:14 plebeian kernel: em0: using IRQ 256 for MSI Aug 12 20:00:14 plebeian kernel: em0: Using MSI interrupt Aug 12 20:00:14 plebeian kernel: em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf2625000 Aug 12 20:00:14 plebeian kernel: em0: [FILTER] Aug 12 20:00:14 plebeian kernel: em0: bpf attached Aug 12 20:00:14 plebeian kernel: em0: Ethernet address: 00:1f:16:02:f7:ec Aug 12 20:00:14 plebeian kernel: uhci0: port 0x1860-0x187f irq 20 at device 26.0 on pci0 Aug 12 20:00:14 plebeian kernel: uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 50 Aug 12 20:00:14 plebeian kernel: uhci0: [MPSAFE] Aug 12 20:00:14 plebeian kernel: uhci0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: uhci0: LegSup = 0x1000 Aug 12 20:00:14 plebeian kernel: usbus0: on uhci0 Aug 12 20:00:14 plebeian kernel: uhci1: port 0x1880-0x189f irq 21 at device 26.1 on pci0 Aug 12 20:00:14 plebeian kernel: uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 51 Aug 12 20:00:14 plebeian kernel: uhci1: [MPSAFE] Aug 12 20:00:14 plebeian kernel: uhci1: [ITHREAD] Aug 12 20:00:14 plebeian kernel: uhci1: LegSup = 0x0000 Aug 12 20:00:14 plebeian kernel: usbus1: on uhci1 Aug 12 20:00:14 plebeian kernel: uhci2: port 0x18a0-0x18bf irq 22 at device 26.2 on pci0 Aug 12 20:00:14 plebeian kernel: uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 52 Aug 12 20:00:14 plebeian kernel: uhci2: [MPSAFE] Aug 12 20:00:14 plebeian kernel: uhci2: [ITHREAD] Aug 12 20:00:14 plebeian kernel: uhci2: LegSup = 0x0000 Aug 12 20:00:14 plebeian kernel: usbus2: on uhci2 Aug 12 20:00:14 plebeian kernel: ehci0: mem 0xf2826c00-0xf2826fff irq 23 at device 26.7 on pci0 Aug 12 20:00:14 plebeian kernel: ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf2826c00 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 53 Aug 12 20:00:14 plebeian kernel: ehci0: [MPSAFE] Aug 12 20:00:14 plebeian kernel: ehci0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: usbus3: EHCI version 1.0 Aug 12 20:00:14 plebeian kernel: usbus3: on ehci0 Aug 12 20:00:14 plebeian kernel: hdac0: mem 0xf2620000-0xf2623fff irq 17 at device 27.0 on pci0 Aug 12 20:00:14 plebeian kernel: hdac0: HDA Driver Revision: 20090624_0136 Aug 12 20:00:14 plebeian kernel: hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xf2620000 Aug 12 20:00:14 plebeian kernel: hdac0: attempting to allocate 1 MSI vectors (1 supported) Aug 12 20:00:14 plebeian kernel: msi: routing MSI IRQ 257 to local APIC 0 vector 54 Aug 12 20:00:14 plebeian kernel: hdac0: using IRQ 257 for MSI Aug 12 20:00:14 plebeian kernel: hdac0: [MPSAFE] Aug 12 20:00:14 plebeian kernel: hdac0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: pcib1: irq 20 at device 28.0 on pci0 Aug 12 20:00:14 plebeian kernel: pcib1: domain 0 Aug 12 20:00:14 plebeian kernel: pcib1: secondary bus 2 Aug 12 20:00:14 plebeian kernel: pcib1: subordinate bus 2 Aug 12 20:00:14 plebeian kernel: pcib1: I/O decode 0xf000-0xfff Aug 12 20:00:14 plebeian kernel: pcib1: no prefetched decode Aug 12 20:00:14 plebeian kernel: pci2: on pcib1 Aug 12 20:00:14 plebeian kernel: pci2: domain=0, physical bus=2 Aug 12 20:00:14 plebeian kernel: pcib2: irq 21 at device 28.1 on pci0 Aug 12 20:00:14 plebeian kernel: pcib2: domain 0 Aug 12 20:00:14 plebeian kernel: pcib2: secondary bus 3 Aug 12 20:00:14 plebeian kernel: pcib2: subordinate bus 3 Aug 12 20:00:14 plebeian kernel: pcib2: I/O decode 0xf000-0xfff Aug 12 20:00:14 plebeian kernel: pcib2: memory decode 0xf2500000-0xf25fffff Aug 12 20:00:14 plebeian kernel: pcib2: no prefetched decode Aug 12 20:00:14 plebeian kernel: pci3: on pcib2 Aug 12 20:00:14 plebeian kernel: pci3: domain=0, physical bus=3 Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x4236, revid=0x00 Aug 12 20:00:14 plebeian kernel: domain=0, bus=3, slot=0, func=0 Aug 12 20:00:14 plebeian kernel: class=02-80-00, hdrtype=0x00, mfdev=0 Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2500000, size 13, enabled Aug 12 20:00:14 plebeian kernel: pcib2: requested memory range 0xf2500000-0xf2501fff: good Aug 12 20:00:14 plebeian kernel: pcib2: matched entry for 3.0.INTA Aug 12 20:00:14 plebeian kernel: pcib2: slot 0 INTA hardwired to IRQ 17 Aug 12 20:00:14 plebeian kernel: pci3: at device 0.0 (no driver attached) Aug 12 20:00:14 plebeian kernel: pcib3: irq 23 at device 28.3 on pci0 Aug 12 20:00:14 plebeian kernel: pcib3: domain 0 Aug 12 20:00:14 plebeian kernel: pcib3: secondary bus 5 Aug 12 20:00:14 plebeian kernel: pcib3: subordinate bus 12 Aug 12 20:00:14 plebeian kernel: pcib3: I/O decode 0x2000-0x2fff Aug 12 20:00:14 plebeian kernel: pcib3: memory decode 0xf0000000-0xf1ffffff Aug 12 20:00:14 plebeian kernel: pcib3: prefetched decode 0xf2900000-0xf29fffff Aug 12 20:00:14 plebeian kernel: pci5: on pcib3 Aug 12 20:00:14 plebeian kernel: pci5: domain=0, physical bus=5 Aug 12 20:00:14 plebeian kernel: uhci3: port 0x18c0-0x18df irq 16 at device 29.0 on pci0 Aug 12 20:00:14 plebeian kernel: uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18c0 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 55 Aug 12 20:00:14 plebeian kernel: uhci3: [MPSAFE] Aug 12 20:00:14 plebeian kernel: uhci3: [ITHREAD] Aug 12 20:00:14 plebeian kernel: uhci3: LegSup = 0x0000 Aug 12 20:00:14 plebeian kernel: usbus4: on uhci3 Aug 12 20:00:14 plebeian kernel: uhci4: port 0x18e0-0x18ff irq 17 at device 29.1 on pci0 Aug 12 20:00:14 plebeian kernel: uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18e0 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 56 Aug 12 20:00:14 plebeian kernel: uhci4: [MPSAFE] Aug 12 20:00:14 plebeian kernel: uhci4: [ITHREAD] Aug 12 20:00:14 plebeian kernel: uhci4: LegSup = 0x0000 Aug 12 20:00:14 plebeian kernel: usbus5: on uhci4 Aug 12 20:00:14 plebeian kernel: uhci5: port 0x1c00-0x1c1f irq 18 at device 29.2 on pci0 Aug 12 20:00:14 plebeian kernel: uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1c00 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 57 Aug 12 20:00:14 plebeian kernel: uhci5: [MPSAFE] Aug 12 20:00:14 plebeian kernel: uhci5: [ITHREAD] Aug 12 20:00:14 plebeian kernel: uhci5: LegSup = 0x0000 Aug 12 20:00:14 plebeian kernel: usbus6: on uhci5 Aug 12 20:00:14 plebeian kernel: ehci1: mem 0xf2827000-0xf28273ff irq 19 at device 29.7 on pci0 Aug 12 20:00:14 plebeian kernel: ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf2827000 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 58 Aug 12 20:00:14 plebeian kernel: ehci1: [MPSAFE] Aug 12 20:00:14 plebeian kernel: ehci1: [ITHREAD] Aug 12 20:00:14 plebeian kernel: usbus7: EHCI version 1.0 Aug 12 20:00:14 plebeian kernel: usbus7: on ehci1 Aug 12 20:00:14 plebeian kernel: pcib4: at device 30.0 on pci0 Aug 12 20:00:14 plebeian kernel: pcib4: domain 0 Aug 12 20:00:14 plebeian kernel: pcib4: secondary bus 13 Aug 12 20:00:14 plebeian kernel: pcib4: subordinate bus 13 Aug 12 20:00:14 plebeian kernel: pcib4: I/O decode 0xf000-0xfff Aug 12 20:00:14 plebeian kernel: pcib4: no prefetched decode Aug 12 20:00:14 plebeian kernel: pcib4: Subtractively decoded bridge. Aug 12 20:00:14 plebeian kernel: pci13: on pcib4 Aug 12 20:00:14 plebeian kernel: pci13: domain=0, physical bus=13 Aug 12 20:00:14 plebeian kernel: isab0: at device 31.0 on pci0 Aug 12 20:00:14 plebeian kernel: isa0: on isab0 Aug 12 20:00:14 plebeian kernel: atapci0: port 0x1c48-0x1c4f,0x183c-0x183f,0x1c40-0x1c47,0x1838-0x183b,0x1c20-0x1c3f mem 0xf2826000-0xf28267ff irq 16 at device 31.2 on pci0 Aug 12 20:00:14 plebeian kernel: atapci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1c20 Aug 12 20:00:14 plebeian kernel: atapci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xf2826000 Aug 12 20:00:14 plebeian kernel: atapci0: [MPSAFE] Aug 12 20:00:14 plebeian kernel: atapci0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: atapci0: AHCI v1.20 controller with 4 3Gbps ports, PM not supported Aug 12 20:00:14 plebeian kernel: atapci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC eSATA 4ports Aug 12 20:00:14 plebeian kernel: ata2: on atapci0 Aug 12 20:00:14 plebeian kernel: ata2: AHCI reset... Aug 12 20:00:14 plebeian kernel: ata2: hardware reset ... Aug 12 20:00:14 plebeian kernel: ata2: SATA connect time=0ms status=00000123 Aug 12 20:00:14 plebeian kernel: ata2: ready wait time=4ms Aug 12 20:00:14 plebeian kernel: ata2: software reset port 0... Aug 12 20:00:14 plebeian kernel: ata2: ready wait time=0ms Aug 12 20:00:14 plebeian kernel: ata2: SIGNATURE: 00000101 Aug 12 20:00:14 plebeian kernel: ata2: AHCI reset done: devices=00000001 Aug 12 20:00:14 plebeian kernel: ata2: [MPSAFE] Aug 12 20:00:14 plebeian kernel: ata2: [ITHREAD] Aug 12 20:00:14 plebeian kernel: ata3: on atapci0 Aug 12 20:00:14 plebeian kernel: ata3: AHCI reset... Aug 12 20:00:14 plebeian kernel: ata3: hardware reset ... Aug 12 20:00:14 plebeian kernel: ata3: SATA connect timeout status=00000000 Aug 12 20:00:14 plebeian kernel: ata3: AHCI reset done: phy reset found no device Aug 12 20:00:14 plebeian kernel: ata3: [MPSAFE] Aug 12 20:00:14 plebeian kernel: ata3: [ITHREAD] Aug 12 20:00:14 plebeian kernel: ichsmb0: port 0x1c60-0x1c7f mem 0xf2827400-0xf28274ff irq 23 at device 31.3 on pci0 Aug 12 20:00:14 plebeian kernel: ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1c60 Aug 12 20:00:14 plebeian kernel: ichsmb0: [MPSAFE] Aug 12 20:00:14 plebeian kernel: ichsmb0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: smbus0: on ichsmb0 Aug 12 20:00:14 plebeian kernel: acpi_tz0: on acpi0 Aug 12 20:00:14 plebeian kernel: acpi_tz1: on acpi0 Aug 12 20:00:14 plebeian kernel: atrtc0: port 0x70-0x71 irq 8 on acpi0 Aug 12 20:00:14 plebeian kernel: atrtc0: registered as a time-of-day clock (resolution 1000000us) Aug 12 20:00:14 plebeian kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Aug 12 20:00:14 plebeian kernel: atkbd0: irq 1 on atkbdc0 Aug 12 20:00:14 plebeian kernel: atkbd: the current kbd controller command byte 0047 Aug 12 20:00:14 plebeian kernel: atkbd: keyboard ID 0x54ab (2) Aug 12 20:00:14 plebeian kernel: kbd0 at atkbd0 Aug 12 20:00:14 plebeian kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 59 Aug 12 20:00:14 plebeian kernel: atkbd0: [GIANT-LOCKED] Aug 12 20:00:14 plebeian kernel: atkbd0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: psm0: unable to allocate IRQ Aug 12 20:00:14 plebeian kernel: psmcpnp0: irq 12 on acpi0 Aug 12 20:00:14 plebeian kernel: psm0: current command byte:0047 Aug 12 20:00:14 plebeian kernel: psm0: irq 12 on atkbdc0 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 60 Aug 12 20:00:14 plebeian kernel: psm0: [GIANT-LOCKED] Aug 12 20:00:14 plebeian kernel: psm0: [ITHREAD] Aug 12 20:00:14 plebeian kernel: psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons Aug 12 20:00:14 plebeian kernel: psm0: config:00000000, flags:00000008, packet size:3 Aug 12 20:00:14 plebeian kernel: psm0: syncmask:c0, syncbits:00 Aug 12 20:00:14 plebeian kernel: battery0: on acpi0 Aug 12 20:00:14 plebeian kernel: acpi_acad0: on acpi0 Aug 12 20:00:14 plebeian kernel: cpu0: on acpi0 Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d7c20 002C8 (v1 PmRef Cpu0Ist 00003000 INTL 20050624) Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d5020 0087A (v1 PmRef Cpu0Cst 00003001 INTL 20050624) Aug 12 20:00:14 plebeian kernel: est0: on cpu0 Aug 12 20:00:14 plebeian kernel: est0: Invalid id16 (set, cur) = (18726, 2333) Aug 12 20:00:14 plebeian kernel: est0: Invalid freq 2401, ignored. Aug 12 20:00:14 plebeian kernel: cpu1: on acpi0 Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d6ca0 001CF (v1 PmRef ApIst 00003000 INTL 20050624) Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d6f20 0008D (v1 PmRef ApCst 00003000 INTL 20050624) Aug 12 20:00:14 plebeian kernel: est1: on cpu1 Aug 12 20:00:14 plebeian kernel: est1: Invalid id16 (set, cur) = (18726, 2333) Aug 12 20:00:14 plebeian kernel: est1: Invalid freq 2401, ignored. Aug 12 20:00:14 plebeian kernel: ex_isa_identify() Aug 12 20:00:14 plebeian kernel: ahc_isa_probe 1: ioport 0x1c00 alloc failed Aug 12 20:00:14 plebeian kernel: isa_probe_children: disabling PnP devices Aug 12 20:00:14 plebeian kernel: atkbdc: atkbdc0 already exists; skipping it Aug 12 20:00:14 plebeian kernel: atrtc: atrtc0 already exists; skipping it Aug 12 20:00:14 plebeian kernel: sc: sc0 already exists; skipping it Aug 12 20:00:14 plebeian kernel: isa_probe_children: probing non-PnP devices Aug 12 20:00:14 plebeian kernel: orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xd2000-0xd2fff,0xde000-0xdf7ff,0xe0000-0xeffff on isa0 Aug 12 20:00:14 plebeian kernel: sc0: at flags 0x100 on isa0 Aug 12 20:00:14 plebeian kernel: sc0: VGA <16 virtual consoles, flags=0x300> Aug 12 20:00:14 plebeian kernel: sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) Aug 12 20:00:14 plebeian kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Aug 12 20:00:14 plebeian kernel: fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 Aug 12 20:00:14 plebeian kernel: ppc0: cannot reserve I/O port range Aug 12 20:00:14 plebeian kernel: ppc0: failed to probe at irq 7 on isa0 Aug 12 20:00:14 plebeian kernel: uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 Aug 12 20:00:14 plebeian kernel: uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 Aug 12 20:00:14 plebeian kernel: isa_probe_children: probing PnP devices Aug 12 20:00:14 plebeian kernel: Device configuration finished. Aug 12 20:00:14 plebeian kernel: Reducing kern.maxvnodes 251113 -> 100000 Aug 12 20:00:14 plebeian kernel: procfs registered Aug 12 20:00:14 plebeian kernel: lapic: Divisor 2, Frequency 133000550 hz Aug 12 20:00:14 plebeian kernel: Timecounter "TSC" frequency 2394009747 Hz quality -100 Aug 12 20:00:14 plebeian kernel: Timecounters tick every 1.000 msec Aug 12 20:00:14 plebeian kernel: Linux ELF exec handler installed Aug 12 20:00:14 plebeian kernel: lo0: bpf attached Aug 12 20:00:14 plebeian kernel: hptrr: no controller detected. Aug 12 20:00:14 plebeian kernel: ata2: Identifying devices: 00000001 Aug 12 20:00:14 plebeian kernel: ata2: New devices: 00000001 Aug 12 20:00:14 plebeian kernel: usbus0: 12Mbps Full Speed USB v1.0 Aug 12 20:00:14 plebeian kernel: usbus1: 12Mbps Full Speed USB v1.0 Aug 12 20:00:14 plebeian kernel: usbus2: 12Mbps Full Speed USB v1.0 Aug 12 20:00:14 plebeian kernel: usbus3: 480Mbps High Speed USB v2.0 Aug 12 20:00:14 plebeian kernel: usbus4: 12Mbps Full Speed USB v1.0 Aug 12 20:00:14 plebeian kernel: usbus5: 12Mbps Full Speed USB v1.0 Aug 12 20:00:14 plebeian kernel: usbus6: 12Mbps Full Speed USB v1.0 Aug 12 20:00:14 plebeian kernel: usbus7: 480Mbps High Speed USB v2.0 Aug 12 20:00:14 plebeian kernel: battery0: battery initialization start Aug 12 20:00:14 plebeian kernel: acpi_acad0: acline initialization start Aug 12 20:00:14 plebeian kernel: ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire Aug 12 20:00:14 plebeian kernel: ad4: 476940MB at ata2-master SATA300 Aug 12 20:00:14 plebeian kernel: ad4: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue Aug 12 20:00:14 plebeian kernel: GEOM: new disk ad4 Aug 12 20:00:14 plebeian kernel: battery0: battery initialization done, tried 1 times Aug 12 20:00:14 plebeian kernel: acpi_acad0: On Line Aug 12 20:00:14 plebeian kernel: acpi_acad0: acline initialization done, tried 1 times Aug 12 20:00:14 plebeian kernel: ad4: Intel check1 failed Aug 12 20:00:14 plebeian kernel: ad4: Adaptec check1 failed Aug 12 20:00:14 plebeian kernel: ad4: LSI (v3) check1 failed Aug 12 20:00:14 plebeian kernel: ad4: LSI (v2) check1 failed Aug 12 20:00:14 plebeian kernel: ad4: FreeBSD check1 failed Aug 12 20:00:14 plebeian kernel: ata3: Identifying devices: 00000000 Aug 12 20:00:14 plebeian kernel: ata3: New devices: 00000000 Aug 12 20:00:14 plebeian kernel: hdac0: Probing codec #0... Aug 12 20:00:14 plebeian kernel: hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) Aug 12 20:00:14 plebeian kernel: hdac0: HDA Codec ID: 0x14f15051 Aug 12 20:00:14 plebeian kernel: hdac0: Vendor: 0x14f1 Aug 12 20:00:14 plebeian kernel: hdac0: Device: 0x5051 Aug 12 20:00:14 plebeian kernel: hdac0: Revision: 0x00 Aug 12 20:00:14 plebeian kernel: hdac0: Stepping: 0x00 Aug 12 20:00:14 plebeian kernel: hdac0: PCI Subvendor: 0x20f217aa Aug 12 20:00:14 plebeian kernel: hdac0: Found audio FG nid=1 startnode=16 endnode=31 total=15 Aug 12 20:00:14 plebeian kernel: hdac0: Found modem FG nid=2 startnode=112 endnode=116 total=4 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: Processing audio FG cad=0 nid=1... Aug 12 20:00:14 plebeian kernel: hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 Aug 12 20:00:14 plebeian kernel: hdac0: nid 22 0x042140f0 as 15 seq 0 Headphones Jack jack 1 loc 4 color Green misc 0 Aug 12 20:00:14 plebeian kernel: hdac0: nid 23 0x61a190f0 as 15 seq 0 Mic None jack 1 loc 33 color Pink misc 0 Aug 12 20:00:14 plebeian kernel: hdac0: nid 24 0x04a190f0 as 15 seq 0 Mic Jack jack 1 loc 4 color Pink misc 0 Aug 12 20:00:14 plebeian kernel: hdac0: nid 25 0x612140f0 as 15 seq 0 Headphones None jack 1 loc 33 color Green misc 0 Aug 12 20:00:14 plebeian kernel: hdac0: nid 26 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 Aug 12 20:00:14 plebeian kernel: hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 Aug 12 20:00:14 plebeian kernel: hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 Aug 12 20:00:14 plebeian kernel: hdac0: nid 29 0x90a601f0 as 15 seq 0 Mic Fixed jack 6 loc 16 color Unknown misc 1 Aug 12 20:00:14 plebeian kernel: hdac0: Patched pins configuration: Aug 12 20:00:14 plebeian kernel: hdac0: nid 22 0x042140f0 as 15 seq 0 Headphones Jack jack 1 loc 4 color Green misc 0 Aug 12 20:00:14 plebeian kernel: hdac0: nid 23 0x61a190f0 as 15 seq 0 Mic None jack 1 loc 33 color Pink misc 0 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: nid 24 0x04a190f0 as 15 seq 0 Mic Jack jack 1 loc 4 color Pink misc 0 Aug 12 20:00:14 plebeian kernel: hdac0: nid 25 0x612140f0 as 15 seq 0 Headphones None jack 1 loc 33 color Green misc 0 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: nid 26 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 Aug 12 20:00:14 plebeian kernel: hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: nid 29 0x90a601f0 as 15 seq 0 Mic Fixed jack 6 loc 16 color Unknown misc 1 Aug 12 20:00:14 plebeian kernel: hdac0: 4 associations found: Aug 12 20:00:14 plebeian kernel: hdac0: Association 0 (15) out: Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=22 seq=0 Aug 12 20:00:14 plebeian kernel: hdac0: Association 1 (15) in: Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=24 seq=0 Aug 12 20:00:14 plebeian kernel: hdac0: Association 2 (15) out: Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=26 seq=0 Aug 12 20:00:14 plebeian kernel: hdac0: Association 3 (15) in: Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=29 seq=0 Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 0 (15) Aug 12 20:00:14 plebeian kernel: hdac0: Pin 22 traced to DAC 16 Aug 12 20:00:14 plebeian kernel: hdac0: Association 0 (15) trace succeeded Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 1 (15) Aug 12 20:00:14 plebeian kernel: hdac0: Unable to trace pin 24 to ADC 20, undo traces Aug 12 20:00:14 plebeian kernel: hdac0: Pin 24 traced to ADC 21 Aug 12 20:00:14 plebeian kernel: hdac0: Association 1 (15) trace succeeded Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 2 (15) Aug 12 20:00:14 plebeian kernel: hdac0: Pin 26 traced to DAC 17 Aug 12 20:00:14 plebeian kernel: hdac0: Association 2 (15) trace succeeded Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 3 (15) Aug 12 20:00:14 plebeian kernel: hdac0: Pin 29 traced to ADC 20 Aug 12 20:00:14 plebeian kernel: hdac0: Association 3 (15) trace succeeded Aug 12 20:00:14 plebeian kernel: hdac0: Tracing input monitor Aug 12 20:00:14 plebeian kernel: hdac0: Tracing beeper Aug 12 20:00:14 plebeian kernel: hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: +-------------------+ Aug 12 20:00:14 plebeian kernel: hdac0: | DUMPING HDA NODES | Aug 12 20:00:14 plebeian kernel: hdac0: +-------------------+ Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: Default Parameter Aug 12 20:00:14 plebeian kernel: hdac0: ----------------- Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: hdac0: PCM Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz Aug 12 20:00:14 plebeian kernel: hdac0: IN amp: 0x00000000 Aug 12 20:00:14 plebeian kernel: hdac0: OUT amp: 0x00000000 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 16 Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio output Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00000c1d Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 0 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: OSS: pcm (pcm) Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: hdac0: PCM Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0560 Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 192 KHz Aug 12 20:00:14 plebeian kernel: hdac0: Output amp: 0x00034a4a Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=74 size=3 offset=74 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 17 Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio output Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00000c1d Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 2 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: OSS: pcm (pcm) Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: hdac0: PCM Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0560 Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 192 KHz Aug 12 20:00:14 plebeian kernel: hdac0: Output amp: 0x00034a4a Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=74 size=3 offset=74 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 18 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio output Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00000211 Aug 12 20:00:14 plebeian kernel: hdac0: DIGITAL STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000005 Aug 12 20:00:14 plebeian kernel: hdac0: AC3 PCM Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 19 Aug 12 20:00:14 plebeian kernel: hdac0: Name: beep widget Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0070000c Aug 12 20:00:14 plebeian kernel: hdac0: Association: -2 (0x00000000) Aug 12 20:00:14 plebeian kernel: hdac0: OSS: speaker (speaker) Aug 12 20:00:14 plebeian kernel: hdac0: Output amp: 0x00170303 Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=3 size=23 offset=3 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 20 Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio input Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00100d1b Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 3 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: hdac0: PCM Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x0003504a Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=80 size=3 offset=74 Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 Aug 12 20:00:14 plebeian kernel: hdac0: | Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=29 [pin: Mic (Fixed)] (selected) Aug 12 20:00:14 plebeian kernel: hdac0: + [DISABLED] <- nid=23 [pin: Mic (None)] [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 21 Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio input Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00100d1b Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 1 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: hdac0: PCM Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x0003504a Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=80 size=3 offset=74 Aug 12 20:00:14 plebeian kernel: hdac0: connections: 1 Aug 12 20:00:14 plebeian kernel: hdac0: | Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=24 [pin: Mic (Pink Jack)] Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 22 Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Headphones (Green Jack) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400581 Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 0 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x0000001c Aug 12 20:00:14 plebeian kernel: hdac0: PDC HP OUT Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x042140f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x000000c0 HP OUT Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 Aug 12 20:00:14 plebeian kernel: hdac0: | Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=16 [audio output] (selected) Aug 12 20:00:14 plebeian kernel: hdac0: + [DISABLED] <- nid=17 [audio output] Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 23 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Mic (None) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0040048b Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00001224 Aug 12 20:00:14 plebeian kernel: hdac0: PDC IN VREF[ 50 80 ] Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x61a190f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x00270400 Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=4 size=39 offset=0 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 24 Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Mic (Pink Jack) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0040048b Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 1 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: OSS: mic (mic) Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00001224 Aug 12 20:00:14 plebeian kernel: hdac0: PDC IN VREF[ 50 80 ] Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x04a190f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000024 IN VREFs Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x00270400 Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=4 size=39 offset=0 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 25 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Headphones (None) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400581 Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00000014 Aug 12 20:00:14 plebeian kernel: hdac0: PDC OUT Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x612140f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 Aug 12 20:00:14 plebeian kernel: hdac0: | Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=16 [audio output] (selected) Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=17 [audio output] Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 26 Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Speaker (Fixed) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400501 Aug 12 20:00:14 plebeian kernel: hdac0: PWR STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 2 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00010010 Aug 12 20:00:14 plebeian kernel: hdac0: OUT EAPD Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x901701f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000040 OUT Aug 12 20:00:14 plebeian kernel: hdac0: EAPD: 0x00000002 Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 Aug 12 20:00:14 plebeian kernel: hdac0: | Aug 12 20:00:14 plebeian kernel: hdac0: + [DISABLED] <- nid=16 [audio output] Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=17 [audio output] (selected) Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 27 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Other (None) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400500 Aug 12 20:00:14 plebeian kernel: hdac0: PWR Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00010010 Aug 12 20:00:14 plebeian kernel: hdac0: OUT EAPD Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x40f001f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 Aug 12 20:00:14 plebeian kernel: hdac0: EAPD: 0x00000002 Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 Aug 12 20:00:14 plebeian kernel: hdac0: | Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=16 [audio output] (selected) Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=17 [audio output] Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 28 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Other (None) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400701 Aug 12 20:00:14 plebeian kernel: hdac0: PWR DIGITAL STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00000010 Aug 12 20:00:14 plebeian kernel: hdac0: OUT Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x40f001f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 Aug 12 20:00:14 plebeian kernel: hdac0: connections: 1 Aug 12 20:00:14 plebeian kernel: hdac0: | Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=18 [audio output] [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 29 Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Mic (Fixed) Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0040040b Aug 12 20:00:14 plebeian kernel: hdac0: PWR STEREO Aug 12 20:00:14 plebeian kernel: hdac0: Association: 3 (0x00000001) Aug 12 20:00:14 plebeian kernel: hdac0: OSS: monitor (monitor) Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00000020 Aug 12 20:00:14 plebeian kernel: hdac0: IN Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x90a601f0 Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000020 IN Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x002f0400 Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=4 size=47 offset=0 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: nid: 30 [DISABLED] Aug 12 20:00:14 plebeian kernel: hdac0: Name: vendor widget Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00f00000 Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: hdac0: Processing modem FG cad=0 nid=2... Aug 12 20:00:14 plebeian kernel: hdac0: Aug 12 20:00:14 plebeian kernel: pcm0: at cad 0 nid 1 on hdac0 Aug 12 20:00:14 plebeian kernel: pcm0: +--------------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm0: | DUMPING PCM Playback/Record Channels | Aug 12 20:00:14 plebeian kernel: pcm0: +--------------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Playback: Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: pcm0: PCM Aug 12 20:00:14 plebeian kernel: pcm0: PCM cap: 0x000e0560 Aug 12 20:00:14 plebeian kernel: pcm0: 16 20 24 bits, 44 48 96 192 KHz Aug 12 20:00:14 plebeian kernel: pcm0: DAC: 16 Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Record: Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: pcm0: PCM Aug 12 20:00:14 plebeian kernel: pcm0: PCM cap: 0x000e0160 Aug 12 20:00:14 plebeian kernel: pcm0: 16 20 24 bits, 44 48 96 KHz Aug 12 20:00:14 plebeian kernel: pcm0: ADC: 21 Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm0: | DUMPING Playback/Record Paths | Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Playback: Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: nid=22 [pin: Headphones (Green Jack)] Aug 12 20:00:14 plebeian kernel: pcm0: | Aug 12 20:00:14 plebeian kernel: pcm0: + <- nid=16 [audio output] [src: pcm] Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Record: Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: nid=21 [audio input] Aug 12 20:00:14 plebeian kernel: pcm0: | Aug 12 20:00:14 plebeian kernel: pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------+ Aug 12 20:00:14 plebeian kernel: pcm0: | DUMPING Volume Controls | Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------+ Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Master Volume (OSS: vol) Aug 12 20:00:14 plebeian kernel: pcm0: | Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: PCM Volume (OSS: pcm) Aug 12 20:00:14 plebeian kernel: pcm0: | Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Microphone Volume (OSS: mic) Aug 12 20:00:14 plebeian kernel: pcm0: | Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 7 (nid 24 out): 0/40dB (5 steps) Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Speaker/Beep Volume (OSS: speaker) Aug 12 20:00:14 plebeian kernel: pcm0: | Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 3 (nid 19 out): -18/0dB (4 steps) Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Recording Level (OSS: rec) Aug 12 20:00:14 plebeian kernel: pcm0: | Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 5 (nid 21 in 0): -74/6dB (81 steps) Aug 12 20:00:14 plebeian kernel: pcm0: Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "vol": Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "pcm": Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "speaker": Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "mic": Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "rec": Aug 12 20:00:14 plebeian kernel: pcm0: clone manager: deadline=750ms flags=0x8000001e Aug 12 20:00:14 plebeian kernel: pcm0: sndbuf_setmap 31c0000, 4000; 0xffffff8072dd1000 -> 31c0000 Aug 12 20:00:14 plebeian kernel: pcm0: sndbuf_setmap 31d0000, 4000; 0xffffff8072de1000 -> 31d0000 Aug 12 20:00:14 plebeian kernel: pcm1: at cad 0 nid 1 on hdac0 Aug 12 20:00:14 plebeian kernel: pcm1: +--------------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm1: | DUMPING PCM Playback/Record Channels | Aug 12 20:00:14 plebeian kernel: pcm1: +--------------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Playback: Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: pcm1: PCM Aug 12 20:00:14 plebeian kernel: pcm1: PCM cap: 0x000e0560 Aug 12 20:00:14 plebeian kernel: pcm1: 16 20 24 bits, 44 48 96 192 KHz Aug 12 20:00:14 plebeian kernel: pcm1: DAC: 17 Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Record: Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Stream cap: 0x00000001 Aug 12 20:00:14 plebeian kernel: pcm1: PCM Aug 12 20:00:14 plebeian kernel: pcm1: PCM cap: 0x000e0160 Aug 12 20:00:14 plebeian kernel: pcm1: 16 20 24 bits, 44 48 96 KHz Aug 12 20:00:14 plebeian kernel: pcm1: ADC: 20 Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm1: | DUMPING Playback/Record Paths | Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------------+ Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Playback: Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: nid=26 [pin: Speaker (Fixed)] Aug 12 20:00:14 plebeian kernel: pcm1: | Aug 12 20:00:14 plebeian kernel: pcm1: + <- nid=17 [audio output] [src: pcm] Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Record: Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: nid=20 [audio input] Aug 12 20:00:14 plebeian kernel: pcm1: | Aug 12 20:00:14 plebeian kernel: pcm1: + <- nid=29 [pin: Mic (Fixed)] [src: monitor] Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------+ Aug 12 20:00:14 plebeian kernel: pcm1: | DUMPING Volume Controls | Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------+ Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Master Volume (OSS: vol) Aug 12 20:00:14 plebeian kernel: pcm1: | Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: PCM Volume (OSS: pcm) Aug 12 20:00:14 plebeian kernel: pcm1: | Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Microphone2 Volume (OSS: monitor) Aug 12 20:00:14 plebeian kernel: pcm1: | Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 8 (nid 29 out): 0/48dB (5 steps) Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Recording Level (OSS: rec) Aug 12 20:00:14 plebeian kernel: pcm1: | Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 4 (nid 20 in 0): -74/6dB (81 steps) Aug 12 20:00:14 plebeian kernel: pcm1: Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "vol": Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "pcm": Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "rec": Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "ogain": Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "monitor": Aug 12 20:00:14 plebeian kernel: pcm1: clone manager: deadline=750ms flags=0x8000001e Aug 12 20:00:14 plebeian kernel: pcm1: sndbuf_setmap 35d0000, 4000; 0xffffff8072df1000 -> 35d0000 Aug 12 20:00:14 plebeian kernel: pcm1: sndbuf_setmap 31e0000, 4000; 0xffffff8072e01000 -> 31e0000 Aug 12 20:00:14 plebeian kernel: ATA PseudoRAID loaded Aug 12 20:00:14 plebeian kernel: SMP: AP CPU #1 Launched! Aug 12 20:00:14 plebeian kernel: cpu1 AP: Aug 12 20:00:14 plebeian kernel: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Aug 12 20:00:14 plebeian kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff Aug 12 20:00:14 plebeian kernel: timer: 0x000200ef therm: 0x00010200 err: 0x00010000 pcm: 0x00000400 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 49 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 50 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 52 Aug 12 20:00:14 plebeian kernel: msi: Assigning MSI IRQ 256 to local APIC 1 vector 53 Aug 12 20:00:14 plebeian kernel: WARNING: WITNESS option enabled, expect reduced performance. Aug 12 20:00:14 plebeian kernel: ugen0.1: at usbus0 Aug 12 20:00:14 plebeian kernel: uhub0: on usbus0 Aug 12 20:00:14 plebeian kernel: GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 Aug 12 20:00:14 plebeian kernel: uhub0: 2 ports with 2 removable, self powered Aug 12 20:00:14 plebeian kernel: ugen1.1: at usbus1 Aug 12 20:00:14 plebeian kernel: uhub1: on usbus1 Aug 12 20:00:14 plebeian kernel: uhub1: 2 ports with 2 removable, self powered Aug 12 20:00:14 plebeian kernel: ugen2.1: at usbus2 Aug 12 20:00:14 plebeian kernel: uhub2: on usbus2 Aug 12 20:00:14 plebeian kernel: uhub2: 2 ports with 2 removable, self powered Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 Aug 12 20:00:14 plebeian kernel: ugen5.1: at usbus5 Aug 12 20:00:14 plebeian kernel: uhub3: on usbus5 Aug 12 20:00:14 plebeian kernel: uhub3: 2 ports with 2 removable, self powered Aug 12 20:00:14 plebeian kernel: ugen3.1: at usbus3 Aug 12 20:00:14 plebeian kernel: uhub4: on usbus3 Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus4 usbus3 Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus4 usbus3 Aug 12 20:00:14 plebeian kernel: uhub4: 6 ports with 6 removable, self powered Aug 12 20:00:14 plebeian kernel: ugen7.1: at usbus7 Aug 12 20:00:14 plebeian kernel: uhub5: on usbus7 Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus4 usbus3 Aug 12 20:00:14 plebeian last message repeated 2 times Aug 12 20:00:14 plebeian kernel: uhub5: 6 ports with 6 removable, self powered Aug 12 20:00:14 plebeian kernel: ugen4.1: at usbus4 Aug 12 20:00:14 plebeian kernel: uhub6: on usbus4 Aug 12 20:00:14 plebeian kernel: uhub6: 2 ports with 2 removable, self powered Aug 12 20:00:14 plebeian kernel: ugen6.1: at usbus6 Aug 12 20:00:14 plebeian kernel: uhub7: on usbus6 Aug 12 20:00:14 plebeian kernel: uhub7: 2 ports with 2 removable, self powered Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus3 Aug 12 20:00:14 plebeian kernel: ugen3.2: at usbus3 Aug 12 20:00:14 plebeian kernel: Trying to mount root from ufs:/dev/ad4s1a Aug 12 20:00:14 plebeian kernel: WARNING: / was not properly dismounted Aug 12 20:00:14 plebeian kernel: ugen1.2: at usbus1 Aug 12 20:00:14 plebeian kernel: ct_to_ts([2009-08-12 23:59:17]) = 1250121557.000000000 Aug 12 20:00:14 plebeian kernel: start_init: trying /sbin/init Aug 12 20:00:14 plebeian kernel: This module (opensolaris) contains code covered by the Aug 12 20:00:14 plebeian kernel: Common Development and Distribution License (CDDL) Aug 12 20:00:14 plebeian kernel: see http://opensolaris.org/os/licensing/opensolaris_license/ Aug 12 20:00:14 plebeian kernel: WARNING: ZFS is considered to be an experimental feature in FreeBSD. Aug 12 20:00:14 plebeian kernel: ZFS NOTICE: system has less than 4GB and prefetch enable is not set... disabling. Aug 12 20:00:14 plebeian kernel: ZFS filesystem version 13 Aug 12 20:00:14 plebeian kernel: ZFS storage pool version 13 Aug 12 20:00:14 plebeian kernel: crypto: Aug 12 20:00:14 plebeian kernel: cryptosoft0: on motherboard Aug 12 20:00:14 plebeian kernel: crypto: assign cryptosoft0 driver id 0, flags 100663296 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 Aug 12 20:00:14 plebeian kernel: GEOM_ELI: Device ad4s1d.eli created. Aug 12 20:00:14 plebeian kernel: GEOM_ELI: Encryption: AES-CBC 256 Aug 12 20:00:14 plebeian kernel: GEOM_ELI: Crypto: software Aug 12 20:00:14 plebeian kernel: linprocfs registered Aug 12 20:00:14 plebeian kernel: lock order reversal: Aug 12 20:00:14 plebeian kernel: 1st 0xffffff0003cb2448 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 Aug 12 20:00:14 plebeian kernel: 2nd 0xffffff0003f20098 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1465 Aug 12 20:00:14 plebeian kernel: KDB: stack backtrace: Aug 12 20:00:14 plebeian kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Aug 12 20:00:14 plebeian kernel: kdb_backtrace() at kdb_backtrace+0x32 Aug 12 20:00:14 plebeian kernel: _witness_debugger() at _witness_debugger+0x1e Aug 12 20:00:14 plebeian kernel: witness_checkorder() at witness_checkorder+0x8c7 Aug 12 20:00:14 plebeian kernel: __lockmgr_args() at __lockmgr_args+0x773 Aug 12 20:00:14 plebeian kernel: ffs_vgetf() at ffs_vgetf+0x1ae Aug 12 20:00:14 plebeian kernel: ffs_vget() at ffs_vget+0xf Aug 12 20:00:14 plebeian kernel: ufs_root() at ufs_root+0x1e Aug 12 20:00:14 plebeian kernel: vfs_donmount() at vfs_donmount+0x13cd Aug 12 20:00:14 plebeian kernel: nmount() at nmount+0x6a Aug 12 20:00:14 plebeian kernel: syscall() at syscall+0x2e9 Aug 12 20:00:14 plebeian kernel: Xfast_syscall() at Xfast_syscall+0xe1 Aug 12 20:00:14 plebeian kernel: --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007ab02c, rsp = 0x7fffffffdd48, rbp = 0x800a03048 --- Aug 12 20:00:16 plebeian kernel: em0: Link is up 1000 Mbps Full Duplex Aug 12 20:00:16 plebeian kernel: em0: link state changed to UP Aug 12 20:00:17 plebeian dhclient: New IP Address (em0): 172.20.143.106 Aug 12 20:00:17 plebeian dhclient: New Subnet Mask (em0): 255.255.255.0 Aug 12 20:00:17 plebeian dhclient: New Broadcast Address (em0): 172.20.143.255 Aug 12 20:00:17 plebeian dhclient: New Routers (em0): 172.20.143.1 Aug 12 20:00:22 plebeian kernel: lock order reversal: Aug 12 20:00:22 plebeian kernel: 1st 0xffffff000350f7f8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 Aug 12 20:00:22 plebeian kernel: 2nd 0xffffff0003eee270 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2083 Aug 12 20:00:22 plebeian kernel: KDB: stack backtrace: Aug 12 20:00:22 plebeian kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Aug 12 20:00:22 plebeian kernel: kdb_backtrace() at kdb_backtrace+0x32 Aug 12 20:00:22 plebeian kernel: _witness_debugger() at _witness_debugger+0x1e Aug 12 20:00:22 plebeian kernel: witness_checkorder() at witness_checkorder+0x8c7 Aug 12 20:00:22 plebeian kernel: __lockmgr_args() at __lockmgr_args+0x773 Aug 12 20:00:22 plebeian kernel: vop_stdlock() at vop_stdlock+0x51 Aug 12 20:00:22 plebeian kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf Aug 12 20:00:22 plebeian kernel: _vn_lock() at _vn_lock+0x6e Aug 12 20:00:22 plebeian kernel: vget() at vget+0xbf Aug 12 20:00:22 plebeian kernel: vfs_msync() at vfs_msync+0xcf Aug 12 20:00:22 plebeian kernel: sync_fsync() at sync_fsync+0x141 Aug 12 20:00:22 plebeian kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7 Aug 12 20:00:22 plebeian kernel: sync_vnode() at sync_vnode+0x146 Aug 12 20:00:22 plebeian kernel: sched_sync() at sched_sync+0x259 Aug 12 20:00:22 plebeian kernel: fork_exit() at fork_exit+0x147 Aug 12 20:00:22 plebeian kernel: fork_trampoline() at fork_trampoline+0xe Aug 12 20:00:22 plebeian kernel: --- trap 0, rip = 0, rsp = 0xffffff8072e2ed30, rbp = 0 --- Aug 12 20:00:42 plebeian kernel: drm0: on vgapci0 Aug 12 20:00:42 plebeian kernel: vgapci0: attempting to allocate 1 MSI vectors (1 supported) Aug 12 20:00:42 plebeian kernel: msi: routing MSI IRQ 258 to local APIC 1 vector 54 Aug 12 20:00:42 plebeian kernel: vgapci0: using IRQ 258 for MSI Aug 12 20:00:42 plebeian kernel: info: [drm] MSI enabled 1 message(s) Aug 12 20:00:42 plebeian kernel: vgapci0: child drm0 requested pci_enable_busmaster Aug 12 20:00:42 plebeian kernel: info: [drm] AGP at 0xd0000000 256MB Aug 12 20:00:42 plebeian kernel: info: [drm] Initialized i915 1.6.0 20080730 Aug 12 20:00:43 plebeian kernel: drm0: [MPSAFE] Aug 12 20:00:43 plebeian kernel: drm0: [ITHREAD] Aug 12 20:00:48 plebeian kernel: em0: Link is Down Aug 12 20:00:48 plebeian kernel: em0: link state changed to DOWN Aug 12 20:00:52 plebeian kernel: em0: Link is up 1000 Mbps Full Duplex Aug 12 20:00:52 plebeian kernel: em0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 01:25:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF8391065672 for ; Thu, 13 Aug 2009 01:25:39 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6218FC43 for ; Thu, 13 Aug 2009 01:25:39 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbP4U-000CzU-Mv for current@freebsd.org; Thu, 13 Aug 2009 01:25:39 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 394E6293FE21 for ; Thu, 13 Aug 2009 10:25:38 +0900 (JST) Date: Thu, 13 Aug 2009 10:25:37 +0900 Message-ID: From: Randy Bush To: FreeBSD current mailing list User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 01:25:40 -0000 very current sources on FreeBSD work0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r: \ Tue Jun 2 08:51:42 UTC 2009 root@work0:/usr/obj/usr/src/sys/WORK0 amd64 ===> gnu/usr.bin/texinfo/install-info (installincludes) ===> gnu/usr.bin/texinfo/texindex (installincludes) ===> gnu/usr.bin/texinfo/doc (installincludes) ===> include (includes) cd /usr/src/include; make buildincludes; make installincludes creating osreldate.h from newvers.sh /libexec/ld-elf.so.1: /usr/local/lib/libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" *** Error code 1 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 could be the shared library version number bump but i don't think so goog not much help new kernel not much help FreeBSD work0.psg.com 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r: \ Tue Aug 11 17:51:54 UTC 2009 root@work0.psg.com:/usr/obj/usr/src/sys/WORK0 amd64 in fact, new kernel borks ipfw, but still chasing that. randy From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 01:44:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F98A1065686 for ; Thu, 13 Aug 2009 01:44:05 +0000 (UTC) (envelope-from guhi.zhang@gmail.com) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by mx1.freebsd.org (Postfix) with ESMTP id 10B4E8FC5F for ; Thu, 13 Aug 2009 01:44:04 +0000 (UTC) Received: by pzk4 with SMTP id 4so294931pzk.7 for ; Wed, 12 Aug 2009 18:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:x-mailer:mime-version:content-type; bh=9sHpfgAg9I/RDAqkLCp0MsOXOocQyfXCceOeNwEZisI=; b=lDI7bpmH59XvvJO3f+pLME1ybz5sQJ4KZBTGD51qRi9aI0ehvtM7bwFODmlFeRIanw iL4W89fFvRfHCkGk35UgRC06noodduKFmA2DH0keAJSx95/8mLalXGE32xLalYBq6Ge5 ZVe6rh29qrm9CmBAo2yuWwTvNMrkAT100uW6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; b=uij1kJQhYfi3ju6BU7TmBT3QncKRKWTHdmiSfPl9tfvGFk05Dn+rUJ1UozwWzHgnc/ KyYmj1F0Y29cawetljEEZQ6Q8rAQa4WdkrGHvCbKQnOgAoQZ1RQ5b/e+dmvyUMl7jx+e hgf6DuKy1CkBM4qQKd9C81XQY484Gmb6xbKvw= Received: by 10.115.100.33 with SMTP id c33mr566981wam.72.1250127844583; Wed, 12 Aug 2009 18:44:04 -0700 (PDT) Received: from zhanghui ([122.224.205.158]) by mx.google.com with ESMTPS id j39sm13606114waf.10.2009.08.12.18.44.01 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 18:44:03 -0700 (PDT) Date: Thu, 13 Aug 2009 09:44:53 +0800 From: "guhi.zhang" To: "freebsd-current" Message-ID: <200908130944511713153@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: I get the reason of FreeBSD 8.0-BETA2/amd64 crashes on SMP under load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 01:44:06 -0000 I think I get the reason of FreeBSD 8.0-BETA2/amd64 crashes on SMP under load. I have two machines 1. AMD Athlon 64 X2 5000+ Jetway HA07(AMD 790GX+SB750) Kingston 4GB DDR2 800 ITE 8212 IDE RAID Maxtor 80G IDE WDC 500G SATA 2. AMD Phenom II X3 710 Jetway HA08(AMD 790GX+SB750) Kingston 8GB DDR3 1333 WDC RE3 1TB*2(RAID1) Both 1 and 2 set SATA mode in RAID in BIOS. When I install FreeBSD 8.0-Beta2 on 2, it always restart, installation can't begin at all.. 3 days ago, I had an idea to install FreeBSD on 1. First I use 7.2 AMD64, and 1 normally started the installatiion, when I used the RAID1 attached to 1, it can't search my raid1 disk. When I changed the disc to 8.0-beta2 AMD64, it can normally started the installation also, but it just can recognize two seperated disk, can't recognize the RAID1. The mainboards both used AMD 790GX+SB750, So I thougt the reason of FreeBSD 8.0-BETA2/amd64 crashes on SMP under load is FreeBSD 8.0-beta2 Amd64 can't support Phenom II. But I can't understand why 8.0-beta can't recognize the RAID1. Please answer me. guhi.zhang 2009-08-13 From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 05:59:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0DA01065697; Thu, 13 Aug 2009 05:59:27 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 7EAD48FC63; Thu, 13 Aug 2009 05:59:27 +0000 (UTC) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 6EE2B7E818; Wed, 12 Aug 2009 21:59:26 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Wed, 12 Aug 2009 21:59:24 -0800 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908122159.25234.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Robert Watson Subject: Re: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 05:59:28 -0000 On Wednesday 12 August 2009 04:29:35 Robert Watson wrote: > We actually have a sizable regression test suite in src/tools/regression -- > some of these tools will have broken as a result of 8-CURRENT development, > so the first task may be to fix them. The next is to run them on 7-STABLE > and 8-CURRENT and decide if things have gotten worse -- or maybe we have a > bug to fix in both. Pick the tool of your choice, and give it a spin. > More than one person per tool is fine, because that way we get more diverse > testing. Well, there's one regression that prevents me from testing a regression. In gmirror(8) and still on 8.x it is described how to do kernel dumps on a gmirror, using /etc/rc.early. Yet, /etc/rc.d/early.sh has been removed and a grep for early in the /etc tree, has not shown me that there's a replacement in place. I'm trying to see coming sunday (downtime) if a bug has re-occured in 8.x (kern/122572) and would like to de-activate one component of the mirror, install, reboot and if garbage is written to the disk again, use livefs tools + rc.early to boot from the de-activated mirror. So my questions are: - What should really be in NOTES for gmirror(8) in 8.x? - Is it possible to deactivate a mirror component, hose the active component and nextboot from the deactivated one, preferably without opening the case? -- Mel From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 06:31:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E3A1106566B for ; Thu, 13 Aug 2009 06:31:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 48F108FC3A for ; Thu, 13 Aug 2009 06:31:21 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2D854.dip.t-dialin.net [217.226.216.84]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 1D4538440BE; Thu, 13 Aug 2009 08:15:43 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 4D67187B34; Thu, 13 Aug 2009 08:15:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1250144139; bh=DJQ9CJ2lQyuVw0RRtKbYSwq45jqB3vtVIm52dS0njVc=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=E0RyTkexHpngQUtHWyhLbiNk5CWq5A/CSteT2n3lZH25VxtGraQiD6bmCaSmT68UI 64LzcnOdCJxw4UPlChvOkqz3pcY/ktArjO3qq5hZKkf0DSI8guplyXU1kMoxpjCZGJ QGUT75pT3DWe4WoAKFrq8nd5BbJwaLTCGJseX5dor5Agrcgtd+yhXgUTedcbjiGBNR lWtoyr967E91dlX4u5cBhxGHjMeu6d+CxhxwqKewyzDTmnMa2meqa9MI3jNJTDO2rc BKpweA9pgJTuaOJ2shI3yjcWZ935EmP0UCy2GJrKVsPKxoKjSnFG9MbKlnKswyXwhL y3tHrY3Ci0q3g== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n7D6FcdD081925; Thu, 13 Aug 2009 08:15:38 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Thu, 13 Aug 2009 08:15:38 +0200 Message-ID: <20090813081538.5361241c6z2lqcn4@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 13 Aug 2009 08:15:38 +0200 From: Alexander Leidinger To: Andreas Tobler References: <4A832C70.4030600@fgznet.ch> In-Reply-To: <4A832C70.4030600@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 1D4538440BE.55B54 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.439, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1250748944.20565@QpohqhhA6zQsH+zxMRr1zw X-EBL-Spam-Status: No Cc: freebsd-current Subject: Re: tools/kerneldoc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 06:31:21 -0000 Quoting Andreas Tobler (from Wed, 12 Aug 2009 22:56:16 +0200): > Hi, > > does anybody care about this 'kerneldoc' package? [...] > I then dived into the subsys dir and started a 'make all'. > > Here too, I failed since a few .m files are no more or they are > placed on a different place. Well, this was easy, more or less. > Commenting them made the build work, but this is only half the > truth, what about the new .m files? I have patches for the subsys part. A little bit more than only the .m files fix: http://www.leidinger.net/FreeBSD/current/patches/dox.diff I haven't tested a lot there, e.g. the USB stuff needs review, as I didn't had a look at it since the new USB subsystem went in. Personally I care about the subsys part, but my spare time for it was not enough lately. I have some hope that I can setup an automatic run with the HTML files available on a public webserver after 8.0-release. At the time I do this, I will also have the time to check everything and commit the patches (I don't think this part is important enough to fix it this late in the release process, on the other hand it is something optional and a commit wouldn't hurt more than letting it in the current shape...). Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 07:49:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21CC9106564A for ; Thu, 13 Aug 2009 07:49:28 +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 DF2038FC57 for ; Thu, 13 Aug 2009 07:49:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 921DFFF6E; Thu, 13 Aug 2009 19:30:07 +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 yN0jWu0yx6Ij; Thu, 13 Aug 2009 19:30:02 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Thu, 13 Aug 2009 19:30:02 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 6211B11432; Thu, 13 Aug 2009 19:30:02 +1200 (NZST) Date: Thu, 13 Aug 2009 00:30:02 -0700 From: Andrew Thompson To: current@freebsd.org Message-ID: <20090813073002.GA66860@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Hans Petter Selasky Subject: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 07:49:28 -0000 Hi, Here is an aesthetic patch to change the usb kernel processes to threads, this hides them from the usual 'ps' output. Please test and review. 1290 ?? DL 0:00.00 [usbus0] [lots and lots more...] 1309 ?? DL 0:00.00 [usbus4] After the patch they can be seen as kernel threads. PID TID COMM TDNAME CPU PRI STATE WCHAN 0 100000 kernel swapper 0 68 sleep sched 0 100009 kernel firmware taskq 0 92 sleep - 0 100020 kernel kqueue taskq 0 92 sleep - 0 100021 kernel acpi_task_0 0 92 sleep - 0 100022 kernel acpi_task_1 0 92 sleep - 0 100023 kernel acpi_task_2 0 92 sleep - 0 100027 kernel thread taskq 0 92 sleep - 0 100031 kernel bwi0 taskq 0 16 sleep - 0 100032 kernel bwi0 taskq 0 16 sleep - 0 100106 kernel usbus0 0 20 sleep wmsg 0 100107 kernel usbus0 0 16 sleep wmsg 0 100108 kernel usbus0 0 20 sleep wmsg 0 100109 kernel usbus0 0 20 sleep wmsg [ ... ] 0 100127 kernel usbus4 0 20 sleep wmsg Andrew Index: dev/usb/usb_process.c =================================================================== --- dev/usb/usb_process.c (revision 196086) +++ dev/usb/usb_process.c (working copy) @@ -64,9 +64,9 @@ #if (__FreeBSD_version >= 800000) #define USB_THREAD_CREATE(f, s, p, ...) \ - kproc_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) -#define USB_THREAD_SUSPEND(p) kproc_suspend(p,0) -#define USB_THREAD_EXIT(err) kproc_exit(err) + kthread_add((f), (s), NULL, (p), 0, 0, __VA_ARGS__) +#define USB_THREAD_SUSPEND(p) kthread_suspend(p,0) +#define USB_THREAD_EXIT(err) kthread_exit() #else #define USB_THREAD_CREATE(f, s, p, ...) \ kthread_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) Index: dev/usb/usb_process.h =================================================================== --- dev/usb/usb_process.h (revision 196086) +++ dev/usb/usb_process.h (working copy) @@ -49,7 +49,7 @@ struct usb_process { struct cv up_cv; struct cv up_drain; - struct proc *up_ptr; + struct thread *up_ptr; struct thread *up_curtd; struct mtx *up_mtx; From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 08:23:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 644011065670; Thu, 13 Aug 2009 08:23:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id D5F728FC48; Thu, 13 Aug 2009 08:23:24 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7D8NJoe013167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 11:23:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n7D8NIdX055385; Thu, 13 Aug 2009 11:23:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n7D8NIOa055384; Thu, 13 Aug 2009 11:23:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Aug 2009 11:23:18 +0300 From: Kostik Belousov To: Andrew Thompson Message-ID: <20090813082318.GP1884@deviant.kiev.zoral.com.ua> References: <20090813073002.GA66860@citylink.fud.org.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rdO4WtzmRRaVZcLD" Content-Disposition: inline In-Reply-To: <20090813073002.GA66860@citylink.fud.org.nz> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 08:23:25 -0000 --rdO4WtzmRRaVZcLD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2009 at 12:30:02AM -0700, Andrew Thompson wrote: > Hi, >=20 >=20 > Here is an aesthetic patch to change the usb kernel processes to threads, > this hides them from the usual 'ps' output. Please test and review. >=20 > 1290 ?? DL 0:00.00 [usbus0] > [lots and lots more...] > 1309 ?? DL 0:00.00 [usbus4] >=20 > After the patch they can be seen as kernel threads. >=20 > PID TID COMM TDNAME CPU PRI STATE WCHAN = =20 > 0 100000 kernel swapper 0 68 sleep sched = =20 > 0 100009 kernel firmware taskq 0 92 sleep - = =20 > 0 100020 kernel kqueue taskq 0 92 sleep - = =20 > 0 100021 kernel acpi_task_0 0 92 sleep - = =20 > 0 100022 kernel acpi_task_1 0 92 sleep - = =20 > 0 100023 kernel acpi_task_2 0 92 sleep - = =20 > 0 100027 kernel thread taskq 0 92 sleep - = =20 > 0 100031 kernel bwi0 taskq 0 16 sleep - = =20 > 0 100032 kernel bwi0 taskq 0 16 sleep - = =20 > 0 100106 kernel usbus0 0 20 sleep wmsg = =20 > 0 100107 kernel usbus0 0 16 sleep wmsg = =20 > 0 100108 kernel usbus0 0 20 sleep wmsg = =20 > 0 100109 kernel usbus0 0 20 sleep wmsg = =20 > [ ... ] > 0 100127 kernel usbus4 0 20 sleep wmsg = =20 >=20 Can you use this opportunity to change "wmsg" wait channel name to something having "usb" in the name ? --rdO4WtzmRRaVZcLD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqDzXYACgkQC3+MBN1Mb4gzhgCgoz+SMUDSIWnyjeFUSmlTBMyW yQIAoMT52vtYFwcYHe0SCvPwhvn7lr1R =7+yf -----END PGP SIGNATURE----- --rdO4WtzmRRaVZcLD-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 08:46:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA2081065670 for ; Thu, 13 Aug 2009 08:46:35 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A08778FC45 for ; Thu, 13 Aug 2009 08:46:35 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:105f:fb4e:36e1:ba29] (unknown [IPv6:2001:7b8:3a7:0:105f:fb4e:36e1:ba29]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1A8025C59; Thu, 13 Aug 2009 10:46:34 +0200 (CEST) Message-ID: <4A83D2E7.8090208@andric.com> Date: Thu, 13 Aug 2009 10:46:31 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3pre) Gecko/20090809 Shredder/3.0b4pre MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list Subject: Re: libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 08:46:36 -0000 On 2009-08-13 03:25, Randy Bush wrote: > very current sources on > > FreeBSD work0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r: \ > Tue Jun 2 08:51:42 UTC 2009 root@work0:/usr/obj/usr/src/sys/WORK0 amd64 > > ===> gnu/usr.bin/texinfo/install-info (installincludes) > ===> gnu/usr.bin/texinfo/texindex (installincludes) > ===> gnu/usr.bin/texinfo/doc (installincludes) > ===> include (includes) > cd /usr/src/include; make buildincludes; make installincludes > creating osreldate.h from newvers.sh > /libexec/ld-elf.so.1: /usr/local/lib/libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" Most likely, you'll need to rebuild your subversion-freebsd port. From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 08:57:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58747106566B for ; Thu, 13 Aug 2009 08:57:37 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0598FC3D for ; Thu, 13 Aug 2009 08:57:37 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbW7s-000Dxt-ES; Thu, 13 Aug 2009 08:57:36 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id F05982944F59; Thu, 13 Aug 2009 17:57:35 +0900 (JST) Date: Thu, 13 Aug 2009 17:57:35 +0900 Message-ID: From: Randy Bush To: Dimitry Andric In-Reply-To: <4A83D2E7.8090208@andric.com> References: <4A83D2E7.8090208@andric.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD current mailing list Subject: Re: libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 08:57:37 -0000 >> very current sources on >> >> FreeBSD work0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r: \ >> Tue Jun 2 08:51:42 UTC 2009 root@work0:/usr/obj/usr/src/sys/WORK0 amd64 >> >> ===> gnu/usr.bin/texinfo/install-info (installincludes) >> ===> gnu/usr.bin/texinfo/texindex (installincludes) >> ===> gnu/usr.bin/texinfo/doc (installincludes) >> ===> include (includes) >> cd /usr/src/include; make buildincludes; make installincludes >> creating osreldate.h from newvers.sh >> /libexec/ld-elf.so.1: /usr/local/lib/libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" > > Most likely, you'll need to rebuild your subversion-freebsd port. to do a buildworld? ooooohkay, i guess. thanks. randy From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 09:09:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2EF31065674 for ; Thu, 13 Aug 2009 09:09:37 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-vw0-f180.google.com (mail-vw0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id B52A68FC48 for ; Thu, 13 Aug 2009 09:09:37 +0000 (UTC) Received: by vws10 with SMTP id 10so567024vws.7 for ; Thu, 13 Aug 2009 02:09:37 -0700 (PDT) MIME-Version: 1.0 Sender: andy@fud.org.nz Received: by 10.220.105.74 with SMTP id s10mr957285vco.49.1250154577087; Thu, 13 Aug 2009 02:09:37 -0700 (PDT) In-Reply-To: <20090813082318.GP1884@deviant.kiev.zoral.com.ua> References: <20090813073002.GA66860@citylink.fud.org.nz> <20090813082318.GP1884@deviant.kiev.zoral.com.ua> Date: Thu, 13 Aug 2009 10:09:37 +0100 X-Google-Sender-Auth: ad86a986067516ea Message-ID: <1280352d0908130209m21ae1d48ud2881e84b5e18a78@mail.gmail.com> From: Andrew Thompson To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 09:09:38 -0000 2009/8/13 Kostik Belousov > > On Thu, Aug 13, 2009 at 12:30:02AM -0700, Andrew Thompson wrote: > > Hi, > > > > > > Here is an aesthetic patch to change the usb kernel processes to thread= s, > > this hides them from the usual 'ps' output. Please test and review. > > > > =A01290 =A0?? =A0DL =A0 =A0 0:00.00 [usbus0] > > =A0[lots and lots more...] > > =A01309 =A0?? =A0DL =A0 =A0 0:00.00 [usbus4] > > > > After the patch they can be seen as kernel threads. > > > > =A0 PID =A0 =A0TID COMM =A0 =A0 =A0 =A0 =A0 =A0 TDNAME =A0 =A0 =A0 =A0 = =A0 CPU =A0PRI STATE =A0 WCHAN > > =A0 =A0 0 100000 kernel =A0 =A0 =A0 =A0 =A0 swapper =A0 =A0 =A0 =A0 =A0= =A00 =A0 68 sleep =A0 sched > > =A0 =A0 0 100009 kernel =A0 =A0 =A0 =A0 =A0 firmware taskq =A0 =A0 0 = =A0 92 sleep =A0 - > > =A0 =A0 0 100020 kernel =A0 =A0 =A0 =A0 =A0 kqueue taskq =A0 =A0 =A0 0 = =A0 92 sleep =A0 - > > =A0 =A0 0 100021 kernel =A0 =A0 =A0 =A0 =A0 acpi_task_0 =A0 =A0 =A0 =A0= 0 =A0 92 sleep =A0 - > > =A0 =A0 0 100022 kernel =A0 =A0 =A0 =A0 =A0 acpi_task_1 =A0 =A0 =A0 =A0= 0 =A0 92 sleep =A0 - > > =A0 =A0 0 100023 kernel =A0 =A0 =A0 =A0 =A0 acpi_task_2 =A0 =A0 =A0 =A0= 0 =A0 92 sleep =A0 - > > =A0 =A0 0 100027 kernel =A0 =A0 =A0 =A0 =A0 thread taskq =A0 =A0 =A0 0 = =A0 92 sleep =A0 - > > =A0 =A0 0 100031 kernel =A0 =A0 =A0 =A0 =A0 bwi0 taskq =A0 =A0 =A0 =A0 = 0 =A0 16 sleep =A0 - > > =A0 =A0 0 100032 kernel =A0 =A0 =A0 =A0 =A0 bwi0 taskq =A0 =A0 =A0 =A0 = 0 =A0 16 sleep =A0 - > > =A0 =A0 0 100106 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 =A0 = =A0 0 =A0 20 sleep =A0 wmsg > > =A0 =A0 0 100107 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 =A0 = =A0 0 =A0 16 sleep =A0 wmsg > > =A0 =A0 0 100108 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 =A0 = =A0 0 =A0 20 sleep =A0 wmsg > > =A0 =A0 0 100109 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 =A0 = =A0 0 =A0 20 sleep =A0 wmsg > > =A0 =A0 [ ... ] > > =A0 =A0 0 100127 kernel =A0 =A0 =A0 =A0 =A0 usbus4 =A0 =A0 =A0 =A0 =A0 = =A0 0 =A0 20 sleep =A0 wmsg > > > Can you use this opportunity to change "wmsg" wait channel name > to something having "usb" in the name ? When the thread is idle this should be `-` ? Andrew From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 09:12:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAC591065673 for ; Thu, 13 Aug 2009 09:12:48 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9F9E38FC4A for ; Thu, 13 Aug 2009 09:12:48 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:105f:fb4e:36e1:ba29] (unknown [IPv6:2001:7b8:3a7:0:105f:fb4e:36e1:ba29]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DD16B5C59; Thu, 13 Aug 2009 11:12:47 +0200 (CEST) Message-ID: <4A83D90E.5040004@andric.com> Date: Thu, 13 Aug 2009 11:12:46 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3pre) Gecko/20090809 Shredder/3.0b4pre MIME-Version: 1.0 To: Randy Bush References: <4A83D2E7.8090208@andric.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list Subject: Re: libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 09:12:49 -0000 On 2009-08-13 10:57, Randy Bush wrote: >> Most likely, you'll need to rebuild your subversion-freebsd port. > to do a buildworld? ooooohkay, i guess. The problem is that sys/conf/newvers.sh searches for svnversion, and tries to run it, if available. This is to append the Subversion revision of the sys directory to the kernel version string. Unfortunately it could not detect that your svnversion executable was not able to run. I would guess you applied an apr upgrade, to fix its recent security hole, and this broke subversion. If you just want to buildworld right now, I would chmod -x the svnversion executable, which prevents newvers.sh from running it. You will not get a fancy version string, however. :) From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 09:37:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6318D106567A; Thu, 13 Aug 2009 09:37:31 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id C6B028FC16; Thu, 13 Aug 2009 09:37:30 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=venAd3Na2t-BH2JNMa8A:9 a=lIQOWV1oFE7qzq9DyDNHCLIVzAQA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 552938778; Thu, 13 Aug 2009 11:37:29 +0200 From: Hans Petter Selasky To: Andrew Thompson Date: Thu, 13 Aug 2009 11:37:36 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090813073002.GA66860@citylink.fud.org.nz> In-Reply-To: <20090813073002.GA66860@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908131137.37466.hselasky@c2i.net> Cc: current@freebsd.org Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 09:37:31 -0000 On Thursday 13 August 2009 09:30:02 Andrew Thompson wrote: > Hi, > > > Here is an aesthetic patch to change the usb kernel processes to threads, > this hides them from the usual 'ps' output. Please test and review. Hi Andrew, Your patch looks OK. Can you commit it to USB P4? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 09:39:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 028CD106564A for ; Thu, 13 Aug 2009 09:39:55 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 7E13A8FC4A for ; Thu, 13 Aug 2009 09:39:53 +0000 (UTC) Received: by bwz19 with SMTP id 19so676713bwz.37 for ; Thu, 13 Aug 2009 02:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XOZ+wTHETUjToPi1FgFLT3E+UPOko7iwSxq5v1lhQFo=; b=IVj1b98+/NfyNn8Rf+alEXOob35wVxO1ewDiEj4dv3QhPelxmuN5OYeMEQamvHxZfG 9Fa2/LnDaoKWeZ/aOFgOgIVsu00YQc5xxEfknOp8DauFNHzxPEaDqg7IkOiFdw1PCCm2 kzIbbLRMQt7vZNuAyi4eyLOiR6xNDXUyoFf1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SfSzg6xcWW6VQ6pZKIlrQfBuUW/jhEvWO9aL+JK33TfZ5mwr3bxpVBcPTaABjHbyQb 7IRLJRjVurIlZTnEGDlTElXA+twBK5UcjrmQ07dZy2uSQrHyHEeqT865agUY+xSIK96a 5tm6GWHZcRnYQrrykY7bZxFM37FRvRB8J80vw= MIME-Version: 1.0 Received: by 10.103.6.11 with SMTP id j11mr287949mui.98.1250154769819; Thu, 13 Aug 2009 02:12:49 -0700 (PDT) In-Reply-To: References: <4A83D2E7.8090208@andric.com> Date: Thu, 13 Aug 2009 12:12:49 +0300 Message-ID: <9e20d71e0908130212g9b10c06t3519d832562f5371@mail.gmail.com> From: Artis Caune To: Randy Bush Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , FreeBSD current mailing list Subject: Re: libsvn_subr-1.so.0: Undefined symbol "apr_thread_mutex_create" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 09:39:55 -0000 2009/8/13 Randy Bush : >>> very current sources on >>> >>> FreeBSD work0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #0 r: \ >>> Tue Jun =C2=A02 08:51:42 UTC 2009 =C2=A0 =C2=A0 root@work0:/usr/obj/usr= /src/sys/WORK0 =C2=A0amd64 >>> >>> =3D=3D=3D> gnu/usr.bin/texinfo/install-info (installincludes) >>> =3D=3D=3D> gnu/usr.bin/texinfo/texindex (installincludes) >>> =3D=3D=3D> gnu/usr.bin/texinfo/doc (installincludes) >>> =3D=3D=3D> include (includes) >>> cd /usr/src/include; make buildincludes; make installincludes >>> creating osreldate.h from newvers.sh >>> /libexec/ld-elf.so.1: /usr/local/lib/libsvn_subr-1.so.0: Undefined symb= ol "apr_thread_mutex_create" >> >> Most likely, you'll need to rebuild your subversion-freebsd port. > > to do a buildworld? =C2=A0ooooohkay, i guess. Yes, if you have subversion installed - buildworld (newvers.sh) fetch svn revision number running svnversion on sys/ directory. You can uninstall subversion, but you will lose revision number in uname. --=20 Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 10:10:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E17C1065676; Thu, 13 Aug 2009 10:10:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id A79698FC47; Thu, 13 Aug 2009 10:10:51 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7DAAj2F022308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 13:10:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n7DAAiNB056530; Thu, 13 Aug 2009 13:10:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n7DAAinG056529; Thu, 13 Aug 2009 13:10:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 13 Aug 2009 13:10:44 +0300 From: Kostik Belousov To: Andrew Thompson Message-ID: <20090813101044.GV1884@deviant.kiev.zoral.com.ua> References: <20090813073002.GA66860@citylink.fud.org.nz> <20090813082318.GP1884@deviant.kiev.zoral.com.ua> <1280352d0908130209m21ae1d48ud2881e84b5e18a78@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Z+65snTBT714SHJP" Content-Disposition: inline In-Reply-To: <1280352d0908130209m21ae1d48ud2881e84b5e18a78@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 10:10:52 -0000 --Z+65snTBT714SHJP Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 13, 2009 at 10:09:37AM +0100, Andrew Thompson wrote: > 2009/8/13 Kostik Belousov > > > > On Thu, Aug 13, 2009 at 12:30:02AM -0700, Andrew Thompson wrote: > > > Hi, > > > > > > > > > Here is an aesthetic patch to change the usb kernel processes to thre= ads, > > > this hides them from the usual 'ps' output. Please test and review. > > > > > > =9A1290 =9A?? =9ADL =9A =9A 0:00.00 [usbus0] > > > =9A[lots and lots more...] > > > =9A1309 =9A?? =9ADL =9A =9A 0:00.00 [usbus4] > > > > > > After the patch they can be seen as kernel threads. > > > > > > =9A PID =9A =9ATID COMM =9A =9A =9A =9A =9A =9A TDNAME =9A =9A =9A = =9A =9A CPU =9APRI STATE =9A WCHAN > > > =9A =9A 0 100000 kernel =9A =9A =9A =9A =9A swapper =9A =9A =9A =9A = =9A =9A0 =9A 68 sleep =9A sched > > > =9A =9A 0 100009 kernel =9A =9A =9A =9A =9A firmware taskq =9A =9A 0 = =9A 92 sleep =9A - > > > =9A =9A 0 100020 kernel =9A =9A =9A =9A =9A kqueue taskq =9A =9A =9A = 0 =9A 92 sleep =9A - > > > =9A =9A 0 100021 kernel =9A =9A =9A =9A =9A acpi_task_0 =9A =9A =9A = =9A0 =9A 92 sleep =9A - > > > =9A =9A 0 100022 kernel =9A =9A =9A =9A =9A acpi_task_1 =9A =9A =9A = =9A0 =9A 92 sleep =9A - > > > =9A =9A 0 100023 kernel =9A =9A =9A =9A =9A acpi_task_2 =9A =9A =9A = =9A0 =9A 92 sleep =9A - > > > =9A =9A 0 100027 kernel =9A =9A =9A =9A =9A thread taskq =9A =9A =9A = 0 =9A 92 sleep =9A - > > > =9A =9A 0 100031 kernel =9A =9A =9A =9A =9A bwi0 taskq =9A =9A =9A = =9A 0 =9A 16 sleep =9A - > > > =9A =9A 0 100032 kernel =9A =9A =9A =9A =9A bwi0 taskq =9A =9A =9A = =9A 0 =9A 16 sleep =9A - > > > =9A =9A 0 100106 kernel =9A =9A =9A =9A =9A usbus0 =9A =9A =9A =9A = =9A =9A 0 =9A 20 sleep =9A wmsg > > > =9A =9A 0 100107 kernel =9A =9A =9A =9A =9A usbus0 =9A =9A =9A =9A = =9A =9A 0 =9A 16 sleep =9A wmsg > > > =9A =9A 0 100108 kernel =9A =9A =9A =9A =9A usbus0 =9A =9A =9A =9A = =9A =9A 0 =9A 20 sleep =9A wmsg > > > =9A =9A 0 100109 kernel =9A =9A =9A =9A =9A usbus0 =9A =9A =9A =9A = =9A =9A 0 =9A 20 sleep =9A wmsg > > > =9A =9A [ ... ] > > > =9A =9A 0 100127 kernel =9A =9A =9A =9A =9A usbus4 =9A =9A =9A =9A = =9A =9A 0 =9A 20 sleep =9A wmsg > > > > > Can you use this opportunity to change "wmsg" wait channel name > > to something having "usb" in the name ? >=20 > When the thread is idle this should be `-` ? Taskqueue loop uses "-" as a name for the wait channel used when no work is scheduled, see subr_taskqueue.c:404.=20 --Z+65snTBT714SHJP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqD5qQACgkQC3+MBN1Mb4jyCQCgo8hN03Ml70gDzPr6Fm1XJXWU 6HgAoPYIBvI1xoXgTXPbCvAM5nyx4lmC =zk82 -----END PGP SIGNATURE----- --Z+65snTBT714SHJP-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 10:32:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F14831065676 for ; Thu, 13 Aug 2009 10:32:45 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-vw0-f180.google.com (mail-vw0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id B39918FC59 for ; Thu, 13 Aug 2009 10:32:45 +0000 (UTC) Received: by vws10 with SMTP id 10so590599vws.7 for ; Thu, 13 Aug 2009 03:32:45 -0700 (PDT) MIME-Version: 1.0 Sender: andy@fud.org.nz Received: by 10.220.74.85 with SMTP id t21mr946758vcj.115.1250159564922; Thu, 13 Aug 2009 03:32:44 -0700 (PDT) In-Reply-To: <20090813101044.GV1884@deviant.kiev.zoral.com.ua> References: <20090813073002.GA66860@citylink.fud.org.nz> <20090813082318.GP1884@deviant.kiev.zoral.com.ua> <1280352d0908130209m21ae1d48ud2881e84b5e18a78@mail.gmail.com> <20090813101044.GV1884@deviant.kiev.zoral.com.ua> Date: Thu, 13 Aug 2009 11:32:44 +0100 X-Google-Sender-Auth: 566e9c44eb3f167e Message-ID: <1280352d0908130332j1487ad09t79fe0e33433021ef@mail.gmail.com> From: Andrew Thompson To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 10:32:46 -0000 2009/8/13 Kostik Belousov : > On Thu, Aug 13, 2009 at 10:09:37AM +0100, Andrew Thompson wrote: >> 2009/8/13 Kostik Belousov >> > >> > On Thu, Aug 13, 2009 at 12:30:02AM -0700, Andrew Thompson wrote: >> > > Hi, >> > > >> > > >> > > Here is an aesthetic patch to change the usb kernel processes to thr= eads, >> > > this hides them from the usual 'ps' output. Please test and review. >> > > >> > > =A01290 =A0?? =A0DL =A0 =A0 0:00.00 [usbus0] >> > > =A0[lots and lots more...] >> > > =A01309 =A0?? =A0DL =A0 =A0 0:00.00 [usbus4] >> > > >> > > After the patch they can be seen as kernel threads. >> > > >> > > =A0 PID =A0 =A0TID COMM =A0 =A0 =A0 =A0 =A0 =A0 TDNAME =A0 =A0 =A0 = =A0 =A0 CPU =A0PRI STATE =A0 WCHAN >> > > =A0 =A0 0 100000 kernel =A0 =A0 =A0 =A0 =A0 swapper =A0 =A0 =A0 =A0 = =A0 =A00 =A0 68 sleep =A0 sched >> > > =A0 =A0 0 100009 kernel =A0 =A0 =A0 =A0 =A0 firmware taskq =A0 =A0 0= =A0 92 sleep =A0 - >> > > =A0 =A0 0 100020 kernel =A0 =A0 =A0 =A0 =A0 kqueue taskq =A0 =A0 =A0= 0 =A0 92 sleep =A0 - >> > > =A0 =A0 0 100021 kernel =A0 =A0 =A0 =A0 =A0 acpi_task_0 =A0 =A0 =A0 = =A00 =A0 92 sleep =A0 - >> > > =A0 =A0 0 100022 kernel =A0 =A0 =A0 =A0 =A0 acpi_task_1 =A0 =A0 =A0 = =A00 =A0 92 sleep =A0 - >> > > =A0 =A0 0 100023 kernel =A0 =A0 =A0 =A0 =A0 acpi_task_2 =A0 =A0 =A0 = =A00 =A0 92 sleep =A0 - >> > > =A0 =A0 0 100027 kernel =A0 =A0 =A0 =A0 =A0 thread taskq =A0 =A0 =A0= 0 =A0 92 sleep =A0 - >> > > =A0 =A0 0 100031 kernel =A0 =A0 =A0 =A0 =A0 bwi0 taskq =A0 =A0 =A0 = =A0 0 =A0 16 sleep =A0 - >> > > =A0 =A0 0 100032 kernel =A0 =A0 =A0 =A0 =A0 bwi0 taskq =A0 =A0 =A0 = =A0 0 =A0 16 sleep =A0 - >> > > =A0 =A0 0 100106 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 = =A0 =A0 0 =A0 20 sleep =A0 wmsg >> > > =A0 =A0 0 100107 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 = =A0 =A0 0 =A0 16 sleep =A0 wmsg >> > > =A0 =A0 0 100108 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 = =A0 =A0 0 =A0 20 sleep =A0 wmsg >> > > =A0 =A0 0 100109 kernel =A0 =A0 =A0 =A0 =A0 usbus0 =A0 =A0 =A0 =A0 = =A0 =A0 0 =A0 20 sleep =A0 wmsg >> > > =A0 =A0 [ ... ] >> > > =A0 =A0 0 100127 kernel =A0 =A0 =A0 =A0 =A0 usbus4 =A0 =A0 =A0 =A0 = =A0 =A0 0 =A0 20 sleep =A0 wmsg >> > > >> > Can you use this opportunity to change "wmsg" wait channel name >> > to something having "usb" in the name ? >> >> When the thread is idle this should be `-` ? > > Taskqueue loop uses "-" as a name for the wait channel used when no work = is > scheduled, see subr_taskqueue.c:404. > Since the usb thread also uses a taskqueue-like system I will make it the s= ame. Andrew From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 11:12:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 097F3106564A for ; Thu, 13 Aug 2009 11:12:22 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 787538FC15 for ; Thu, 13 Aug 2009 11:12:21 +0000 (UTC) Received: from [192.168.1.4] (adsl-157-61-83.bna.bellsouth.net [70.157.61.83]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n7DBCBcx086968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 07:12:12 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Damian Gerow In-Reply-To: <20090813002104.GA1481@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: FreeBSD Date: Thu, 13 Aug 2009 06:09:17 -0500 Message-Id: <1250161757.1823.18.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:12:22 -0000 On Wed, 2009-08-12 at 20:21 -0400, Damian Gerow wrote: > Some time between r195828 and r196086, resuming from an S3 suspend seems to > have broken for me. > > When resuming in text mode, the system locks up completely before the > screen comes back on. Of course, resuming from text mode has never worked, > so this isn't much of a concern. > > When resuming from graphics mode, the screen is restored, but fails to > update beyond restoring the initial display. The keyboard responds (caps > lock light turns on, changing the console results in an error beep), but > that's about it. Ctrl+alt+delete does cleanly reboot the system at this > point, and after reboot, I can see the system did actually come back > cleanly. > > The system is a Lenovo X200, running an amd64 install of r196086 (standard > GENERIC kernel) The graphics chipset is an Intel X4500MHD. Looking at the change log, I suspect the newbus locking code... But that is just a stab in the dark. There were not any changes to drm, which is responsible for saving/restoring state when it is loaded. Also related, no changes have been made to AGP, which really only needs to restore the GART mappings on resume. robert. > Verbose dmesg below. > > -- dmesg.verbose > > Aug 12 20:00:14 plebeian syslogd: kernel boot file is /boot/kernel/kernel > Aug 12 20:00:14 plebeian kernel: Copyright (c) 1992-2009 The FreeBSD Project. > Aug 12 20:00:14 plebeian kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > Aug 12 20:00:14 plebeian kernel: The Regents of the University of California. All rights reserved. > Aug 12 20:00:14 plebeian kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. > Aug 12 20:00:14 plebeian kernel: FreeBSD 8.0-BETA2 #2 r196086: Sat Aug 8 18:48:02 EDT 2009 > Aug 12 20:00:14 plebeian kernel: dgerow@plebeian.afflictions.org:/usr/obj/usr/src/sys/GENERIC > Aug 12 20:00:14 plebeian kernel: WARNING: WITNESS option enabled, expect reduced performance. > Aug 12 20:00:14 plebeian kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff810cc000. > Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/linux.ko" at 0xffffffff810cc378. > Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/snd_hda.ko" at 0xffffffff810ccb20. > Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/sound.ko" at 0xffffffff810cd148. > Aug 12 20:00:14 plebeian kernel: Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff810cd7f0. > Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/aio.ko" at 0xffffffff810cd850. > Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/ichsmb.ko" at 0xffffffff810cdeb8. > Aug 12 20:00:14 plebeian kernel: Preloaded elf obj module "/boot/kernel/smbus.ko" at 0xffffffff810ce420. > Aug 12 20:00:14 plebeian kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 > Aug 12 20:00:14 plebeian kernel: Calibrating TSC clock ... TSC clock: 2394009747 Hz > Aug 12 20:00:14 plebeian kernel: CPU: Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz (2394.01-MHz K8-class CPU) > Aug 12 20:00:14 plebeian kernel: Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 > Aug 12 20:00:14 plebeian kernel: Features=0xbfebfbff > Aug 12 20:00:14 plebeian kernel: Features2=0x8e3fd > Aug 12 20:00:14 plebeian kernel: AMD Features=0x20100800 > Aug 12 20:00:14 plebeian kernel: AMD Features2=0x1 > Aug 12 20:00:14 plebeian kernel: TSC: P-state invariant > Aug 12 20:00:14 plebeian kernel: real memory = 4294967296 (4096 MB) > Aug 12 20:00:14 plebeian kernel: Physical memory chunk(s): > Aug 12 20:00:14 plebeian kernel: 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) > Aug 12 20:00:14 plebeian kernel: 0x00000000010fd000 - 0x00000000b4200fff, 3004186624 bytes (733444 pages) > Aug 12 20:00:14 plebeian kernel: 0x00000000bd6a7000 - 0x00000000bd7b6fff, 1114112 bytes (272 pages) > Aug 12 20:00:14 plebeian kernel: 0x00000000bd80f000 - 0x00000000bd8c6fff, 753664 bytes (184 pages) > Aug 12 20:00:14 plebeian kernel: 0x00000000bdbff000 - 0x00000000bdbfffff, 4096 bytes (1 pages) > Aug 12 20:00:14 plebeian kernel: 0x0000000100000000 - 0x000000013bfeffff, 1006567424 bytes (245744 pages) > Aug 12 20:00:14 plebeian kernel: avail memory = 3989790720 (3804 MB) > Aug 12 20:00:14 plebeian kernel: ACPI APIC Table: > Aug 12 20:00:14 plebeian kernel: INTR: Adding local APIC 1 as a target > Aug 12 20:00:14 plebeian kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > Aug 12 20:00:14 plebeian kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) > Aug 12 20:00:14 plebeian kernel: cpu0 (BSP): APIC ID: 0 > Aug 12 20:00:14 plebeian kernel: cpu1 (AP): APIC ID: 1 > Aug 12 20:00:14 plebeian kernel: APIC: CPU 0 has ACPI ID 0 > Aug 12 20:00:14 plebeian kernel: APIC: CPU 1 has ACPI ID 1 > Aug 12 20:00:14 plebeian kernel: ULE: setup cpu 0 > Aug 12 20:00:14 plebeian kernel: ULE: setup cpu 1 > Aug 12 20:00:14 plebeian kernel: ACPI: RSDP 0xf7380 00024 (v2 LENOVO) > Aug 12 20:00:14 plebeian kernel: ACPI: XSDT 0xbdb7bd45 00094 (v1 LENOVO TP-6D 00001070 LTP 00000000) > Aug 12 20:00:14 plebeian kernel: ACPI: FACP 0xbdb7bf00 000F4 (v3 LENOVO TP-6D 00001070 LNVO 00000001) > Aug 12 20:00:14 plebeian kernel: ACPI: DSDT 0xbdb7c2f4 0D910 (v1 LENOVO TP-6D 00001070 MSFT 03000000) > Aug 12 20:00:14 plebeian kernel: ACPI: FACS 0xbdb8e000 00040 > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbdb7c0b4 00240 (v1 LENOVO TP-6D 00001070 MSFT 03000000) > Aug 12 20:00:14 plebeian kernel: ACPI: ECDT 0xbdb89c04 00052 (v1 LENOVO TP-6D 00001070 LNVO 00000001) > Aug 12 20:00:14 plebeian kernel: ACPI: APIC 0xbdb89c56 00078 (v1 LENOVO TP-6D 00001070 LNVO 00000001) > Aug 12 20:00:14 plebeian kernel: ACPI: MCFG 0xbdb89cce 0003C (v1 LENOVO TP-6D 00001070 LNVO 00000001) > Aug 12 20:00:14 plebeian kernel: ACPI: HPET 0xbdb89d0a 00038 (v1 LENOVO TP-6D 00001070 LNVO 00000001) > Aug 12 20:00:14 plebeian kernel: ACPI: SLIC 0xbdb89dc2 00176 (v1 LENOVO TP-6D 00001070 LTP 00000000) > Aug 12 20:00:14 plebeian kernel: ACPI: BOOT 0xbdb89f38 00028 (v1 LENOVO TP-6D 00001070 LTP 00000001) > Aug 12 20:00:14 plebeian kernel: ACPI: ASF! 0xbdb89f60 000A0 (v16 LENOVO TP-6D 00001070 PTL 00000001) > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbdb8d203 0055F (v1 LENOVO TP-6D 00001070 INTL 20050513) > Aug 12 20:00:14 plebeian kernel: ACPI: TCPA 0xbd907000 00032 (v0 00000000 00000000) > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d4000 00655 (v1 PmRef CpuPm 00003000 INTL 20050624) > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d3000 00274 (v1 PmRef Cpu0Tst 00003000 INTL 20050624) > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d2000 00242 (v1 PmRef ApTst 00003000 INTL 20050624) > Aug 12 20:00:14 plebeian kernel: MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 > Aug 12 20:00:14 plebeian kernel: ioapic0: Changing APIC ID to 1 > Aug 12 20:00:14 plebeian kernel: ioapic0: Routing external 8259A's -> intpin 0 > Aug 12 20:00:14 plebeian kernel: MADT: Interrupt override: source 0, irq 2 > Aug 12 20:00:14 plebeian kernel: ioapic0: Routing IRQ 0 -> intpin 2 > Aug 12 20:00:14 plebeian kernel: MADT: Interrupt override: source 9, irq 9 > Aug 12 20:00:14 plebeian kernel: ioapic0: intpin 9 trigger: level > Aug 12 20:00:14 plebeian kernel: lapic0: Routing NMI -> LINT1 > Aug 12 20:00:14 plebeian kernel: lapic0: LINT1 trigger: edge > Aug 12 20:00:14 plebeian kernel: lapic0: LINT1 polarity: high > Aug 12 20:00:14 plebeian kernel: lapic1: Routing NMI -> LINT1 > Aug 12 20:00:14 plebeian kernel: lapic1: LINT1 trigger: edge > Aug 12 20:00:14 plebeian kernel: lapic1: LINT1 polarity: high > Aug 12 20:00:14 plebeian kernel: ioapic0 irqs 0-23 on motherboard > Aug 12 20:00:14 plebeian kernel: cpu0 BSP: > Aug 12 20:00:14 plebeian kernel: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > Aug 12 20:00:14 plebeian kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > Aug 12 20:00:14 plebeian kernel: timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > Aug 12 20:00:14 plebeian kernel: snd_unit_init() u=0x00ff8000 [512] d=0x00007c00 [32] c=0x000003ff [1024] > Aug 12 20:00:14 plebeian kernel: feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 > Aug 12 20:00:14 plebeian kernel: wlan: <802.11 Link Layer> > Aug 12 20:00:14 plebeian kernel: nfslock: pseudo-device > Aug 12 20:00:14 plebeian kernel: kbd: new array size 4 > Aug 12 20:00:14 plebeian kernel: kbd1 at kbdmux0 > Aug 12 20:00:14 plebeian kernel: mem: > Aug 12 20:00:14 plebeian kernel: null: > Aug 12 20:00:14 plebeian kernel: io: > Aug 12 20:00:14 plebeian kernel: random: > Aug 12 20:00:14 plebeian kernel: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > Aug 12 20:00:14 plebeian kernel: acpi0: on motherboard > Aug 12 20:00:14 plebeian kernel: PCIe: Memory Mapped configuration base @ 0xe0000000 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > Aug 12 20:00:14 plebeian kernel: acpi0: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: acpi0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: acpi_ec0: port 0x62,0x66 on acpi0 > Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.MHCS -> bus 0 dev 0 func 0 > Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.EHC0.U7CS -> bus 0 dev 29 func 7 > Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.EHC1.U8CS -> bus 0 dev 26 func 7 > Aug 12 20:00:14 plebeian kernel: acpi0: Power Button (fixed) > Aug 12 20:00:14 plebeian kernel: acpi0: wakeup code va 0xffffff800000f000 pa 0x4000 > Aug 12 20:00:14 plebeian kernel: AcpiOsDerivePciId: \_SB_.PCI0.LPC_.LPCS -> bus 0 dev 31 func 0 > Aug 12 20:00:14 plebeian kernel: acpi0: reservation of 0, a0000 (3) failed > Aug 12 20:00:14 plebeian kernel: acpi0: reservation of 100000, bff00000 (3) failed > Aug 12 20:00:14 plebeian kernel: ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 > Aug 12 20:00:14 plebeian kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > Aug 12 20:00:14 plebeian kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > Aug 12 20:00:14 plebeian kernel: pci_link0: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: pci_link1: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: pci_link2: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: pci_link3: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: pci_link4: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: pci_link5: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: pci_link6: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: pci_link7: Index IRQ Rtd Ref IRQs > Aug 12 20:00:14 plebeian kernel: Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: Validation 0 11 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: After Disable 0 255 N 0 3 4 5 6 7 9 10 11 > Aug 12 20:00:14 plebeian kernel: acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Aug 12 20:00:14 plebeian kernel: acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit > Aug 12 20:00:14 plebeian kernel: Timecounter "HPET" frequency 14318180 Hz quality 900 > Aug 12 20:00:14 plebeian kernel: acpi_lid0: on acpi0 > Aug 12 20:00:14 plebeian kernel: acpi_button0: on acpi0 > Aug 12 20:00:14 plebeian kernel: pcib0: port 0xcf8-0xcff on acpi0 > Aug 12 20:00:14 plebeian kernel: pci0: on pcib0 > Aug 12 20:00:14 plebeian kernel: pci0: domain=0, physical bus=0 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a40, revid=0x07 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=0, func=0 > Aug 12 20:00:14 plebeian kernel: class=06-00-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a42, revid=0x07 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=2, func=0 > Aug 12 20:00:14 plebeian kernel: class=03-00-00, hdrtype=0x00, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2000000, size 22, enabled > Aug 12 20:00:14 plebeian kernel: map[18]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1800, size 3, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.2.INTA > Aug 12 20:00:14 plebeian kernel: pcib0: slot 2 INTA hardwired to IRQ 16 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a43, revid=0x07 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=2, func=1 > Aug 12 20:00:14 plebeian kernel: class=03-80-00, hdrtype=0x00, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2400000, size 20, enabled > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2a44, revid=0x07 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=3, func=0 > Aug 12 20:00:14 plebeian kernel: class=07-80-00, hdrtype=0x00, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0006, statreg=0x0018, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2826800, size 4, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.3.INTA > Aug 12 20:00:14 plebeian kernel: pcib0: slot 3 INTA hardwired to IRQ 16 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x10f5, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=25, func=0 > Aug 12 20:00:14 plebeian kernel: class=02-00-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 32, base 0xf2600000, size 17, enabled > Aug 12 20:00:14 plebeian kernel: map[14]: type Memory, range 32, base 0xf2625000, size 12, enabled > Aug 12 20:00:14 plebeian kernel: map[18]: type I/O Port, range 32, base 0x1840, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.25.INTA > Aug 12 20:00:14 plebeian kernel: pcib0: slot 25 INTA hardwired to IRQ 20 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2937, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=0 > Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1860, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTA > Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTA hardwired to IRQ 20 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2938, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=1 > Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTB > Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTB hardwired to IRQ 21 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2939, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=2 > Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=c, irq=11 > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x18a0, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTC > Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTC hardwired to IRQ 22 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x293c, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=26, func=7 > Aug 12 20:00:14 plebeian kernel: class=0c-03-20, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=d, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 32, base 0xf2826c00, size 10, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.26.INTD > Aug 12 20:00:14 plebeian kernel: pcib0: slot 26 INTD hardwired to IRQ 23 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x293e, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=27, func=0 > Aug 12 20:00:14 plebeian kernel: class=04-03-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2620000, size 14, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.27.INTB > Aug 12 20:00:14 plebeian kernel: pcib0: slot 27 INTB hardwired to IRQ 17 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2940, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=28, func=0 > Aug 12 20:00:14 plebeian kernel: class=06-04-00, hdrtype=0x01, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.28.INTA > Aug 12 20:00:14 plebeian kernel: pcib0: slot 28 INTA hardwired to IRQ 20 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2942, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=28, func=1 > Aug 12 20:00:14 plebeian kernel: class=06-04-00, hdrtype=0x01, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.28.INTB > Aug 12 20:00:14 plebeian kernel: pcib0: slot 28 INTB hardwired to IRQ 21 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2946, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=28, func=3 > Aug 12 20:00:14 plebeian kernel: class=06-04-00, hdrtype=0x01, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=d, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.28.INTD > Aug 12 20:00:14 plebeian kernel: pcib0: slot 28 INTD hardwired to IRQ 23 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2934, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=0 > Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x18c0, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTA > Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTA hardwired to IRQ 16 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2935, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=1 > Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x18e0, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTB > Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTB hardwired to IRQ 17 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2936, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=2 > Aug 12 20:00:14 plebeian kernel: class=0c-03-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=c, irq=11 > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1c00, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTC > Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTC hardwired to IRQ 18 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x293a, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=29, func=7 > Aug 12 20:00:14 plebeian kernel: class=0c-03-20, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=d, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 2 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 32, base 0xf2827000, size 10, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.29.INTD > Aug 12 20:00:14 plebeian kernel: pcib0: slot 29 INTD hardwired to IRQ 19 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2448, revid=0x93 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=30, func=0 > Aug 12 20:00:14 plebeian kernel: class=06-04-01, hdrtype=0x01, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2917, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=31, func=0 > Aug 12 20:00:14 plebeian kernel: class=06-01-00, hdrtype=0x00, mfdev=1 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2929, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=31, func=2 > Aug 12 20:00:14 plebeian kernel: class=01-06-01, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=b, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 16 messages > Aug 12 20:00:14 plebeian kernel: map[10]: type I/O Port, range 32, base 0x1c48, size 3, enabled > Aug 12 20:00:14 plebeian kernel: map[14]: type I/O Port, range 32, base 0x183c, size 2, enabled > Aug 12 20:00:14 plebeian kernel: map[18]: type I/O Port, range 32, base 0x1c40, size 3, enabled > Aug 12 20:00:14 plebeian kernel: map[1c]: type I/O Port, range 32, base 0x1838, size 2, enabled > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1c20, size 5, enabled > Aug 12 20:00:14 plebeian kernel: map[24]: type Memory, range 32, base 0xf2826000, size 11, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.31.INTB > Aug 12 20:00:14 plebeian kernel: pcib0: slot 31 INTB hardwired to IRQ 16 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x2930, revid=0x03 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=0, slot=31, func=3 > Aug 12 20:00:14 plebeian kernel: class=0c-05-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0103, statreg=0x0280, cachelnsz=0 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2827400, size 8, enabled > Aug 12 20:00:14 plebeian kernel: map[20]: type I/O Port, range 32, base 0x1c60, size 5, enabled > Aug 12 20:00:14 plebeian kernel: pcib0: matched entry for 0.31.INTA > Aug 12 20:00:14 plebeian kernel: pcib0: slot 31 INTA hardwired to IRQ 23 > Aug 12 20:00:14 plebeian kernel: vgapci0: port 0x1800-0x1807 mem 0xf2000000-0xf23fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 > Aug 12 20:00:14 plebeian kernel: agp0: on vgapci0 > Aug 12 20:00:14 plebeian kernel: vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 > Aug 12 20:00:14 plebeian kernel: vgapci0: Reserved 0x400000 bytes for rid 0x10 type 3 at 0xf2000000 > Aug 12 20:00:14 plebeian kernel: agp0: detected 32764k stolen memory > Aug 12 20:00:14 plebeian kernel: agp0: aperture size is 256M > Aug 12 20:00:14 plebeian kernel: vgapci1: mem 0xf2400000-0xf24fffff at device 2.1 on pci0 > Aug 12 20:00:14 plebeian kernel: pci0: at device 3.0 (no driver attached) > Aug 12 20:00:14 plebeian kernel: em0: port 0x1840-0x185f mem 0xf2600000-0xf261ffff,0xf2625000-0xf2625fff irq 20 at device 25.0 on pci0 > Aug 12 20:00:14 plebeian kernel: em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf2600000 > Aug 12 20:00:14 plebeian kernel: em0: attempting to allocate 1 MSI vectors (1 supported) > Aug 12 20:00:14 plebeian kernel: msi: routing MSI IRQ 256 to local APIC 0 vector 49 > Aug 12 20:00:14 plebeian kernel: em0: using IRQ 256 for MSI > Aug 12 20:00:14 plebeian kernel: em0: Using MSI interrupt > Aug 12 20:00:14 plebeian kernel: em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xf2625000 > Aug 12 20:00:14 plebeian kernel: em0: [FILTER] > Aug 12 20:00:14 plebeian kernel: em0: bpf attached > Aug 12 20:00:14 plebeian kernel: em0: Ethernet address: 00:1f:16:02:f7:ec > Aug 12 20:00:14 plebeian kernel: uhci0: port 0x1860-0x187f irq 20 at device 26.0 on pci0 > Aug 12 20:00:14 plebeian kernel: uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1860 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 50 > Aug 12 20:00:14 plebeian kernel: uhci0: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: uhci0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: uhci0: LegSup = 0x1000 > Aug 12 20:00:14 plebeian kernel: usbus0: on uhci0 > Aug 12 20:00:14 plebeian kernel: uhci1: port 0x1880-0x189f irq 21 at device 26.1 on pci0 > Aug 12 20:00:14 plebeian kernel: uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1880 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 51 > Aug 12 20:00:14 plebeian kernel: uhci1: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: uhci1: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: uhci1: LegSup = 0x0000 > Aug 12 20:00:14 plebeian kernel: usbus1: on uhci1 > Aug 12 20:00:14 plebeian kernel: uhci2: port 0x18a0-0x18bf irq 22 at device 26.2 on pci0 > Aug 12 20:00:14 plebeian kernel: uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18a0 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 52 > Aug 12 20:00:14 plebeian kernel: uhci2: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: uhci2: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: uhci2: LegSup = 0x0000 > Aug 12 20:00:14 plebeian kernel: usbus2: on uhci2 > Aug 12 20:00:14 plebeian kernel: ehci0: mem 0xf2826c00-0xf2826fff irq 23 at device 26.7 on pci0 > Aug 12 20:00:14 plebeian kernel: ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf2826c00 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 53 > Aug 12 20:00:14 plebeian kernel: ehci0: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: ehci0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: usbus3: EHCI version 1.0 > Aug 12 20:00:14 plebeian kernel: usbus3: on ehci0 > Aug 12 20:00:14 plebeian kernel: hdac0: mem 0xf2620000-0xf2623fff irq 17 at device 27.0 on pci0 > Aug 12 20:00:14 plebeian kernel: hdac0: HDA Driver Revision: 20090624_0136 > Aug 12 20:00:14 plebeian kernel: hdac0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xf2620000 > Aug 12 20:00:14 plebeian kernel: hdac0: attempting to allocate 1 MSI vectors (1 supported) > Aug 12 20:00:14 plebeian kernel: msi: routing MSI IRQ 257 to local APIC 0 vector 54 > Aug 12 20:00:14 plebeian kernel: hdac0: using IRQ 257 for MSI > Aug 12 20:00:14 plebeian kernel: hdac0: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: hdac0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: pcib1: irq 20 at device 28.0 on pci0 > Aug 12 20:00:14 plebeian kernel: pcib1: domain 0 > Aug 12 20:00:14 plebeian kernel: pcib1: secondary bus 2 > Aug 12 20:00:14 plebeian kernel: pcib1: subordinate bus 2 > Aug 12 20:00:14 plebeian kernel: pcib1: I/O decode 0xf000-0xfff > Aug 12 20:00:14 plebeian kernel: pcib1: no prefetched decode > Aug 12 20:00:14 plebeian kernel: pci2: on pcib1 > Aug 12 20:00:14 plebeian kernel: pci2: domain=0, physical bus=2 > Aug 12 20:00:14 plebeian kernel: pcib2: irq 21 at device 28.1 on pci0 > Aug 12 20:00:14 plebeian kernel: pcib2: domain 0 > Aug 12 20:00:14 plebeian kernel: pcib2: secondary bus 3 > Aug 12 20:00:14 plebeian kernel: pcib2: subordinate bus 3 > Aug 12 20:00:14 plebeian kernel: pcib2: I/O decode 0xf000-0xfff > Aug 12 20:00:14 plebeian kernel: pcib2: memory decode 0xf2500000-0xf25fffff > Aug 12 20:00:14 plebeian kernel: pcib2: no prefetched decode > Aug 12 20:00:14 plebeian kernel: pci3: on pcib2 > Aug 12 20:00:14 plebeian kernel: pci3: domain=0, physical bus=3 > Aug 12 20:00:14 plebeian kernel: found-> vendor=0x8086, dev=0x4236, revid=0x00 > Aug 12 20:00:14 plebeian kernel: domain=0, bus=3, slot=0, func=0 > Aug 12 20:00:14 plebeian kernel: class=02-80-00, hdrtype=0x00, mfdev=0 > Aug 12 20:00:14 plebeian kernel: cmdreg=0x0106, statreg=0x0010, cachelnsz=16 (dwords) > Aug 12 20:00:14 plebeian kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > Aug 12 20:00:14 plebeian kernel: intpin=a, irq=11 > Aug 12 20:00:14 plebeian kernel: powerspec 3 supports D0 D3 current D0 > Aug 12 20:00:14 plebeian kernel: MSI supports 1 message, 64 bit > Aug 12 20:00:14 plebeian kernel: map[10]: type Memory, range 64, base 0xf2500000, size 13, enabled > Aug 12 20:00:14 plebeian kernel: pcib2: requested memory range 0xf2500000-0xf2501fff: good > Aug 12 20:00:14 plebeian kernel: pcib2: matched entry for 3.0.INTA > Aug 12 20:00:14 plebeian kernel: pcib2: slot 0 INTA hardwired to IRQ 17 > Aug 12 20:00:14 plebeian kernel: pci3: at device 0.0 (no driver attached) > Aug 12 20:00:14 plebeian kernel: pcib3: irq 23 at device 28.3 on pci0 > Aug 12 20:00:14 plebeian kernel: pcib3: domain 0 > Aug 12 20:00:14 plebeian kernel: pcib3: secondary bus 5 > Aug 12 20:00:14 plebeian kernel: pcib3: subordinate bus 12 > Aug 12 20:00:14 plebeian kernel: pcib3: I/O decode 0x2000-0x2fff > Aug 12 20:00:14 plebeian kernel: pcib3: memory decode 0xf0000000-0xf1ffffff > Aug 12 20:00:14 plebeian kernel: pcib3: prefetched decode 0xf2900000-0xf29fffff > Aug 12 20:00:14 plebeian kernel: pci5: on pcib3 > Aug 12 20:00:14 plebeian kernel: pci5: domain=0, physical bus=5 > Aug 12 20:00:14 plebeian kernel: uhci3: port 0x18c0-0x18df irq 16 at device 29.0 on pci0 > Aug 12 20:00:14 plebeian kernel: uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18c0 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 55 > Aug 12 20:00:14 plebeian kernel: uhci3: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: uhci3: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: uhci3: LegSup = 0x0000 > Aug 12 20:00:14 plebeian kernel: usbus4: on uhci3 > Aug 12 20:00:14 plebeian kernel: uhci4: port 0x18e0-0x18ff irq 17 at device 29.1 on pci0 > Aug 12 20:00:14 plebeian kernel: uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x18e0 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 56 > Aug 12 20:00:14 plebeian kernel: uhci4: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: uhci4: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: uhci4: LegSup = 0x0000 > Aug 12 20:00:14 plebeian kernel: usbus5: on uhci4 > Aug 12 20:00:14 plebeian kernel: uhci5: port 0x1c00-0x1c1f irq 18 at device 29.2 on pci0 > Aug 12 20:00:14 plebeian kernel: uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1c00 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 57 > Aug 12 20:00:14 plebeian kernel: uhci5: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: uhci5: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: uhci5: LegSup = 0x0000 > Aug 12 20:00:14 plebeian kernel: usbus6: on uhci5 > Aug 12 20:00:14 plebeian kernel: ehci1: mem 0xf2827000-0xf28273ff irq 19 at device 29.7 on pci0 > Aug 12 20:00:14 plebeian kernel: ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf2827000 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 58 > Aug 12 20:00:14 plebeian kernel: ehci1: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: ehci1: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: usbus7: EHCI version 1.0 > Aug 12 20:00:14 plebeian kernel: usbus7: on ehci1 > Aug 12 20:00:14 plebeian kernel: pcib4: at device 30.0 on pci0 > Aug 12 20:00:14 plebeian kernel: pcib4: domain 0 > Aug 12 20:00:14 plebeian kernel: pcib4: secondary bus 13 > Aug 12 20:00:14 plebeian kernel: pcib4: subordinate bus 13 > Aug 12 20:00:14 plebeian kernel: pcib4: I/O decode 0xf000-0xfff > Aug 12 20:00:14 plebeian kernel: pcib4: no prefetched decode > Aug 12 20:00:14 plebeian kernel: pcib4: Subtractively decoded bridge. > Aug 12 20:00:14 plebeian kernel: pci13: on pcib4 > Aug 12 20:00:14 plebeian kernel: pci13: domain=0, physical bus=13 > Aug 12 20:00:14 plebeian kernel: isab0: at device 31.0 on pci0 > Aug 12 20:00:14 plebeian kernel: isa0: on isab0 > Aug 12 20:00:14 plebeian kernel: atapci0: port 0x1c48-0x1c4f,0x183c-0x183f,0x1c40-0x1c47,0x1838-0x183b,0x1c20-0x1c3f mem 0xf2826000-0xf28267ff irq 16 at device 31.2 on pci0 > Aug 12 20:00:14 plebeian kernel: atapci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1c20 > Aug 12 20:00:14 plebeian kernel: atapci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xf2826000 > Aug 12 20:00:14 plebeian kernel: atapci0: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: atapci0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: atapci0: AHCI v1.20 controller with 4 3Gbps ports, PM not supported > Aug 12 20:00:14 plebeian kernel: atapci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC eSATA 4ports > Aug 12 20:00:14 plebeian kernel: ata2: on atapci0 > Aug 12 20:00:14 plebeian kernel: ata2: AHCI reset... > Aug 12 20:00:14 plebeian kernel: ata2: hardware reset ... > Aug 12 20:00:14 plebeian kernel: ata2: SATA connect time=0ms status=00000123 > Aug 12 20:00:14 plebeian kernel: ata2: ready wait time=4ms > Aug 12 20:00:14 plebeian kernel: ata2: software reset port 0... > Aug 12 20:00:14 plebeian kernel: ata2: ready wait time=0ms > Aug 12 20:00:14 plebeian kernel: ata2: SIGNATURE: 00000101 > Aug 12 20:00:14 plebeian kernel: ata2: AHCI reset done: devices=00000001 > Aug 12 20:00:14 plebeian kernel: ata2: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: ata2: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: ata3: on atapci0 > Aug 12 20:00:14 plebeian kernel: ata3: AHCI reset... > Aug 12 20:00:14 plebeian kernel: ata3: hardware reset ... > Aug 12 20:00:14 plebeian kernel: ata3: SATA connect timeout status=00000000 > Aug 12 20:00:14 plebeian kernel: ata3: AHCI reset done: phy reset found no device > Aug 12 20:00:14 plebeian kernel: ata3: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: ata3: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: ichsmb0: port 0x1c60-0x1c7f mem 0xf2827400-0xf28274ff irq 23 at device 31.3 on pci0 > Aug 12 20:00:14 plebeian kernel: ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1c60 > Aug 12 20:00:14 plebeian kernel: ichsmb0: [MPSAFE] > Aug 12 20:00:14 plebeian kernel: ichsmb0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: smbus0: on ichsmb0 > Aug 12 20:00:14 plebeian kernel: acpi_tz0: on acpi0 > Aug 12 20:00:14 plebeian kernel: acpi_tz1: on acpi0 > Aug 12 20:00:14 plebeian kernel: atrtc0: port 0x70-0x71 irq 8 on acpi0 > Aug 12 20:00:14 plebeian kernel: atrtc0: registered as a time-of-day clock (resolution 1000000us) > Aug 12 20:00:14 plebeian kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 > Aug 12 20:00:14 plebeian kernel: atkbd0: irq 1 on atkbdc0 > Aug 12 20:00:14 plebeian kernel: atkbd: the current kbd controller command byte 0047 > Aug 12 20:00:14 plebeian kernel: atkbd: keyboard ID 0x54ab (2) > Aug 12 20:00:14 plebeian kernel: kbd0 at atkbd0 > Aug 12 20:00:14 plebeian kernel: kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 59 > Aug 12 20:00:14 plebeian kernel: atkbd0: [GIANT-LOCKED] > Aug 12 20:00:14 plebeian kernel: atkbd0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: psm0: unable to allocate IRQ > Aug 12 20:00:14 plebeian kernel: psmcpnp0: irq 12 on acpi0 > Aug 12 20:00:14 plebeian kernel: psm0: current command byte:0047 > Aug 12 20:00:14 plebeian kernel: psm0: irq 12 on atkbdc0 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 60 > Aug 12 20:00:14 plebeian kernel: psm0: [GIANT-LOCKED] > Aug 12 20:00:14 plebeian kernel: psm0: [ITHREAD] > Aug 12 20:00:14 plebeian kernel: psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons > Aug 12 20:00:14 plebeian kernel: psm0: config:00000000, flags:00000008, packet size:3 > Aug 12 20:00:14 plebeian kernel: psm0: syncmask:c0, syncbits:00 > Aug 12 20:00:14 plebeian kernel: battery0: on acpi0 > Aug 12 20:00:14 plebeian kernel: acpi_acad0: on acpi0 > Aug 12 20:00:14 plebeian kernel: cpu0: on acpi0 > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d7c20 002C8 (v1 PmRef Cpu0Ist 00003000 INTL 20050624) > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d5020 0087A (v1 PmRef Cpu0Cst 00003001 INTL 20050624) > Aug 12 20:00:14 plebeian kernel: est0: on cpu0 > Aug 12 20:00:14 plebeian kernel: est0: Invalid id16 (set, cur) = (18726, 2333) > Aug 12 20:00:14 plebeian kernel: est0: Invalid freq 2401, ignored. > Aug 12 20:00:14 plebeian kernel: cpu1: on acpi0 > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d6ca0 001CF (v1 PmRef ApIst 00003000 INTL 20050624) > Aug 12 20:00:14 plebeian kernel: ACPI: SSDT 0xbd8d6f20 0008D (v1 PmRef ApCst 00003000 INTL 20050624) > Aug 12 20:00:14 plebeian kernel: est1: on cpu1 > Aug 12 20:00:14 plebeian kernel: est1: Invalid id16 (set, cur) = (18726, 2333) > Aug 12 20:00:14 plebeian kernel: est1: Invalid freq 2401, ignored. > Aug 12 20:00:14 plebeian kernel: ex_isa_identify() > Aug 12 20:00:14 plebeian kernel: ahc_isa_probe 1: ioport 0x1c00 alloc failed > Aug 12 20:00:14 plebeian kernel: isa_probe_children: disabling PnP devices > Aug 12 20:00:14 plebeian kernel: atkbdc: atkbdc0 already exists; skipping it > Aug 12 20:00:14 plebeian kernel: atrtc: atrtc0 already exists; skipping it > Aug 12 20:00:14 plebeian kernel: sc: sc0 already exists; skipping it > Aug 12 20:00:14 plebeian kernel: isa_probe_children: probing non-PnP devices > Aug 12 20:00:14 plebeian kernel: orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd1fff,0xd2000-0xd2fff,0xde000-0xdf7ff,0xe0000-0xeffff on isa0 > Aug 12 20:00:14 plebeian kernel: sc0: at flags 0x100 on isa0 > Aug 12 20:00:14 plebeian kernel: sc0: VGA <16 virtual consoles, flags=0x300> > Aug 12 20:00:14 plebeian kernel: sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > Aug 12 20:00:14 plebeian kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Aug 12 20:00:14 plebeian kernel: fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > Aug 12 20:00:14 plebeian kernel: ppc0: cannot reserve I/O port range > Aug 12 20:00:14 plebeian kernel: ppc0: failed to probe at irq 7 on isa0 > Aug 12 20:00:14 plebeian kernel: uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 > Aug 12 20:00:14 plebeian kernel: uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > Aug 12 20:00:14 plebeian kernel: isa_probe_children: probing PnP devices > Aug 12 20:00:14 plebeian kernel: Device configuration finished. > Aug 12 20:00:14 plebeian kernel: Reducing kern.maxvnodes 251113 -> 100000 > Aug 12 20:00:14 plebeian kernel: procfs registered > Aug 12 20:00:14 plebeian kernel: lapic: Divisor 2, Frequency 133000550 hz > Aug 12 20:00:14 plebeian kernel: Timecounter "TSC" frequency 2394009747 Hz quality -100 > Aug 12 20:00:14 plebeian kernel: Timecounters tick every 1.000 msec > Aug 12 20:00:14 plebeian kernel: Linux ELF exec handler installed > Aug 12 20:00:14 plebeian kernel: lo0: bpf attached > Aug 12 20:00:14 plebeian kernel: hptrr: no controller detected. > Aug 12 20:00:14 plebeian kernel: ata2: Identifying devices: 00000001 > Aug 12 20:00:14 plebeian kernel: ata2: New devices: 00000001 > Aug 12 20:00:14 plebeian kernel: usbus0: 12Mbps Full Speed USB v1.0 > Aug 12 20:00:14 plebeian kernel: usbus1: 12Mbps Full Speed USB v1.0 > Aug 12 20:00:14 plebeian kernel: usbus2: 12Mbps Full Speed USB v1.0 > Aug 12 20:00:14 plebeian kernel: usbus3: 480Mbps High Speed USB v2.0 > Aug 12 20:00:14 plebeian kernel: usbus4: 12Mbps Full Speed USB v1.0 > Aug 12 20:00:14 plebeian kernel: usbus5: 12Mbps Full Speed USB v1.0 > Aug 12 20:00:14 plebeian kernel: usbus6: 12Mbps Full Speed USB v1.0 > Aug 12 20:00:14 plebeian kernel: usbus7: 480Mbps High Speed USB v2.0 > Aug 12 20:00:14 plebeian kernel: battery0: battery initialization start > Aug 12 20:00:14 plebeian kernel: acpi_acad0: acline initialization start > Aug 12 20:00:14 plebeian kernel: ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > Aug 12 20:00:14 plebeian kernel: ad4: 476940MB at ata2-master SATA300 > Aug 12 20:00:14 plebeian kernel: ad4: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue > Aug 12 20:00:14 plebeian kernel: GEOM: new disk ad4 > Aug 12 20:00:14 plebeian kernel: battery0: battery initialization done, tried 1 times > Aug 12 20:00:14 plebeian kernel: acpi_acad0: On Line > Aug 12 20:00:14 plebeian kernel: acpi_acad0: acline initialization done, tried 1 times > Aug 12 20:00:14 plebeian kernel: ad4: Intel check1 failed > Aug 12 20:00:14 plebeian kernel: ad4: Adaptec check1 failed > Aug 12 20:00:14 plebeian kernel: ad4: LSI (v3) check1 failed > Aug 12 20:00:14 plebeian kernel: ad4: LSI (v2) check1 failed > Aug 12 20:00:14 plebeian kernel: ad4: FreeBSD check1 failed > Aug 12 20:00:14 plebeian kernel: ata3: Identifying devices: 00000000 > Aug 12 20:00:14 plebeian kernel: ata3: New devices: 00000000 > Aug 12 20:00:14 plebeian kernel: hdac0: Probing codec #0... > Aug 12 20:00:14 plebeian kernel: hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) > Aug 12 20:00:14 plebeian kernel: hdac0: HDA Codec ID: 0x14f15051 > Aug 12 20:00:14 plebeian kernel: hdac0: Vendor: 0x14f1 > Aug 12 20:00:14 plebeian kernel: hdac0: Device: 0x5051 > Aug 12 20:00:14 plebeian kernel: hdac0: Revision: 0x00 > Aug 12 20:00:14 plebeian kernel: hdac0: Stepping: 0x00 > Aug 12 20:00:14 plebeian kernel: hdac0: PCI Subvendor: 0x20f217aa > Aug 12 20:00:14 plebeian kernel: hdac0: Found audio FG nid=1 startnode=16 endnode=31 total=15 > Aug 12 20:00:14 plebeian kernel: hdac0: Found modem FG nid=2 startnode=112 endnode=116 total=4 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: Processing audio FG cad=0 nid=1... > Aug 12 20:00:14 plebeian kernel: hdac0: GPIO: 0x40000004 NumGPIO=4 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 22 0x042140f0 as 15 seq 0 Headphones Jack jack 1 loc 4 color Green misc 0 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 23 0x61a190f0 as 15 seq 0 Mic None jack 1 loc 33 color Pink misc 0 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 24 0x04a190f0 as 15 seq 0 Mic Jack jack 1 loc 4 color Pink misc 0 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 25 0x612140f0 as 15 seq 0 Headphones None jack 1 loc 33 color Green misc 0 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 26 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 29 0x90a601f0 as 15 seq 0 Mic Fixed jack 6 loc 16 color Unknown misc 1 > Aug 12 20:00:14 plebeian kernel: hdac0: Patched pins configuration: > Aug 12 20:00:14 plebeian kernel: hdac0: nid 22 0x042140f0 as 15 seq 0 Headphones Jack jack 1 loc 4 color Green misc 0 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 23 0x61a190f0 as 15 seq 0 Mic None jack 1 loc 33 color Pink misc 0 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: nid 24 0x04a190f0 as 15 seq 0 Mic Jack jack 1 loc 4 color Pink misc 0 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 25 0x612140f0 as 15 seq 0 Headphones None jack 1 loc 33 color Green misc 0 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: nid 26 0x901701f0 as 15 seq 0 Speaker Fixed jack 7 loc 16 color Unknown misc 1 > Aug 12 20:00:14 plebeian kernel: hdac0: nid 27 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: nid 28 0x40f001f0 as 15 seq 0 Other None jack 0 loc 0 color Unknown misc 1 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: nid 29 0x90a601f0 as 15 seq 0 Mic Fixed jack 6 loc 16 color Unknown misc 1 > Aug 12 20:00:14 plebeian kernel: hdac0: 4 associations found: > Aug 12 20:00:14 plebeian kernel: hdac0: Association 0 (15) out: > Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=22 seq=0 > Aug 12 20:00:14 plebeian kernel: hdac0: Association 1 (15) in: > Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=24 seq=0 > Aug 12 20:00:14 plebeian kernel: hdac0: Association 2 (15) out: > Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=26 seq=0 > Aug 12 20:00:14 plebeian kernel: hdac0: Association 3 (15) in: > Aug 12 20:00:14 plebeian kernel: hdac0: Pin nid=29 seq=0 > Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 0 (15) > Aug 12 20:00:14 plebeian kernel: hdac0: Pin 22 traced to DAC 16 > Aug 12 20:00:14 plebeian kernel: hdac0: Association 0 (15) trace succeeded > Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 1 (15) > Aug 12 20:00:14 plebeian kernel: hdac0: Unable to trace pin 24 to ADC 20, undo traces > Aug 12 20:00:14 plebeian kernel: hdac0: Pin 24 traced to ADC 21 > Aug 12 20:00:14 plebeian kernel: hdac0: Association 1 (15) trace succeeded > Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 2 (15) > Aug 12 20:00:14 plebeian kernel: hdac0: Pin 26 traced to DAC 17 > Aug 12 20:00:14 plebeian kernel: hdac0: Association 2 (15) trace succeeded > Aug 12 20:00:14 plebeian kernel: hdac0: Tracing association 3 (15) > Aug 12 20:00:14 plebeian kernel: hdac0: Pin 29 traced to ADC 20 > Aug 12 20:00:14 plebeian kernel: hdac0: Association 3 (15) trace succeeded > Aug 12 20:00:14 plebeian kernel: hdac0: Tracing input monitor > Aug 12 20:00:14 plebeian kernel: hdac0: Tracing beeper > Aug 12 20:00:14 plebeian kernel: hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: +-------------------+ > Aug 12 20:00:14 plebeian kernel: hdac0: | DUMPING HDA NODES | > Aug 12 20:00:14 plebeian kernel: hdac0: +-------------------+ > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: Default Parameter > Aug 12 20:00:14 plebeian kernel: hdac0: ----------------- > Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: hdac0: PCM > Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 > Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz > Aug 12 20:00:14 plebeian kernel: hdac0: IN amp: 0x00000000 > Aug 12 20:00:14 plebeian kernel: hdac0: OUT amp: 0x00000000 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 16 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio output > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00000c1d > Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 0 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: OSS: pcm (pcm) > Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: hdac0: PCM > Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0560 > Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 192 KHz > Aug 12 20:00:14 plebeian kernel: hdac0: Output amp: 0x00034a4a > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=74 size=3 offset=74 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 17 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio output > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00000c1d > Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 2 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: OSS: pcm (pcm) > Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: hdac0: PCM > Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0560 > Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 192 KHz > Aug 12 20:00:14 plebeian kernel: hdac0: Output amp: 0x00034a4a > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=74 size=3 offset=74 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 18 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio output > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00000211 > Aug 12 20:00:14 plebeian kernel: hdac0: DIGITAL STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000005 > Aug 12 20:00:14 plebeian kernel: hdac0: AC3 PCM > Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 > Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 19 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: beep widget > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0070000c > Aug 12 20:00:14 plebeian kernel: hdac0: Association: -2 (0x00000000) > Aug 12 20:00:14 plebeian kernel: hdac0: OSS: speaker (speaker) > Aug 12 20:00:14 plebeian kernel: hdac0: Output amp: 0x00170303 > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=3 size=23 offset=3 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 20 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio input > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00100d1b > Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 3 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: hdac0: PCM > Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 > Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz > Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x0003504a > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=80 size=3 offset=74 > Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 > Aug 12 20:00:14 plebeian kernel: hdac0: | > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=29 [pin: Mic (Fixed)] (selected) > Aug 12 20:00:14 plebeian kernel: hdac0: + [DISABLED] <- nid=23 [pin: Mic (None)] [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 21 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: audio input > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00100d1b > Aug 12 20:00:14 plebeian kernel: hdac0: LRSWAP PWR STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 1 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: hdac0: PCM > Aug 12 20:00:14 plebeian kernel: hdac0: PCM cap: 0x000e0160 > Aug 12 20:00:14 plebeian kernel: hdac0: 16 20 24 bits, 44 48 96 KHz > Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x0003504a > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=80 size=3 offset=74 > Aug 12 20:00:14 plebeian kernel: hdac0: connections: 1 > Aug 12 20:00:14 plebeian kernel: hdac0: | > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=24 [pin: Mic (Pink Jack)] > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 22 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Headphones (Green Jack) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400581 > Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 0 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x0000001c > Aug 12 20:00:14 plebeian kernel: hdac0: PDC HP OUT > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x042140f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x000000c0 HP OUT > Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 > Aug 12 20:00:14 plebeian kernel: hdac0: | > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=16 [audio output] (selected) > Aug 12 20:00:14 plebeian kernel: hdac0: + [DISABLED] <- nid=17 [audio output] > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 23 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Mic (None) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0040048b > Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00001224 > Aug 12 20:00:14 plebeian kernel: hdac0: PDC IN VREF[ 50 80 ] > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x61a190f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 > Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x00270400 > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=4 size=39 offset=0 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 24 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Mic (Pink Jack) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0040048b > Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 1 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: OSS: mic (mic) > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00001224 > Aug 12 20:00:14 plebeian kernel: hdac0: PDC IN VREF[ 50 80 ] > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x04a190f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000024 IN VREFs > Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x00270400 > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=4 size=39 offset=0 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 25 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Headphones (None) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400581 > Aug 12 20:00:14 plebeian kernel: hdac0: PWR UNSOL STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00000014 > Aug 12 20:00:14 plebeian kernel: hdac0: PDC OUT > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x612140f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 > Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 > Aug 12 20:00:14 plebeian kernel: hdac0: | > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=16 [audio output] (selected) > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=17 [audio output] > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 26 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Speaker (Fixed) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400501 > Aug 12 20:00:14 plebeian kernel: hdac0: PWR STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 2 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00010010 > Aug 12 20:00:14 plebeian kernel: hdac0: OUT EAPD > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x901701f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000040 OUT > Aug 12 20:00:14 plebeian kernel: hdac0: EAPD: 0x00000002 > Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 > Aug 12 20:00:14 plebeian kernel: hdac0: | > Aug 12 20:00:14 plebeian kernel: hdac0: + [DISABLED] <- nid=16 [audio output] > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=17 [audio output] (selected) > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 27 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Other (None) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400500 > Aug 12 20:00:14 plebeian kernel: hdac0: PWR > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00010010 > Aug 12 20:00:14 plebeian kernel: hdac0: OUT EAPD > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x40f001f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 > Aug 12 20:00:14 plebeian kernel: hdac0: EAPD: 0x00000002 > Aug 12 20:00:14 plebeian kernel: hdac0: connections: 2 > Aug 12 20:00:14 plebeian kernel: hdac0: | > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=16 [audio output] (selected) > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=17 [audio output] > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 28 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Other (None) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00400701 > Aug 12 20:00:14 plebeian kernel: hdac0: PWR DIGITAL STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00000010 > Aug 12 20:00:14 plebeian kernel: hdac0: OUT > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x40f001f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000000 > Aug 12 20:00:14 plebeian kernel: hdac0: connections: 1 > Aug 12 20:00:14 plebeian kernel: hdac0: | > Aug 12 20:00:14 plebeian kernel: hdac0: + <- nid=18 [audio output] [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 29 > Aug 12 20:00:14 plebeian kernel: hdac0: Name: pin: Mic (Fixed) > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x0040040b > Aug 12 20:00:14 plebeian kernel: hdac0: PWR STEREO > Aug 12 20:00:14 plebeian kernel: hdac0: Association: 3 (0x00000001) > Aug 12 20:00:14 plebeian kernel: hdac0: OSS: monitor (monitor) > Aug 12 20:00:14 plebeian kernel: hdac0: Pin cap: 0x00000020 > Aug 12 20:00:14 plebeian kernel: hdac0: IN > Aug 12 20:00:14 plebeian kernel: hdac0: Pin config: 0x90a601f0 > Aug 12 20:00:14 plebeian kernel: hdac0: Pin control: 0x00000020 IN > Aug 12 20:00:14 plebeian kernel: hdac0: Input amp: 0x002f0400 > Aug 12 20:00:14 plebeian kernel: hdac0: mute=0 step=4 size=47 offset=0 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: nid: 30 [DISABLED] > Aug 12 20:00:14 plebeian kernel: hdac0: Name: vendor widget > Aug 12 20:00:14 plebeian kernel: hdac0: Widget cap: 0x00f00000 > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: hdac0: Processing modem FG cad=0 nid=2... > Aug 12 20:00:14 plebeian kernel: hdac0: > Aug 12 20:00:14 plebeian kernel: pcm0: at cad 0 nid 1 on hdac0 > Aug 12 20:00:14 plebeian kernel: pcm0: +--------------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm0: | DUMPING PCM Playback/Record Channels | > Aug 12 20:00:14 plebeian kernel: pcm0: +--------------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Playback: > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: pcm0: PCM > Aug 12 20:00:14 plebeian kernel: pcm0: PCM cap: 0x000e0560 > Aug 12 20:00:14 plebeian kernel: pcm0: 16 20 24 bits, 44 48 96 192 KHz > Aug 12 20:00:14 plebeian kernel: pcm0: DAC: 16 > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Record: > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: pcm0: PCM > Aug 12 20:00:14 plebeian kernel: pcm0: PCM cap: 0x000e0160 > Aug 12 20:00:14 plebeian kernel: pcm0: 16 20 24 bits, 44 48 96 KHz > Aug 12 20:00:14 plebeian kernel: pcm0: ADC: 21 > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm0: | DUMPING Playback/Record Paths | > Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Playback: > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: nid=22 [pin: Headphones (Green Jack)] > Aug 12 20:00:14 plebeian kernel: pcm0: | > Aug 12 20:00:14 plebeian kernel: pcm0: + <- nid=16 [audio output] [src: pcm] > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Record: > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: nid=21 [audio input] > Aug 12 20:00:14 plebeian kernel: pcm0: | > Aug 12 20:00:14 plebeian kernel: pcm0: + <- nid=24 [pin: Mic (Pink Jack)] [src: mic] > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm0: | DUMPING Volume Controls | > Aug 12 20:00:14 plebeian kernel: pcm0: +-------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Master Volume (OSS: vol) > Aug 12 20:00:14 plebeian kernel: pcm0: | > Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: PCM Volume (OSS: pcm) > Aug 12 20:00:14 plebeian kernel: pcm0: | > Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 1 (nid 16 out): -74/0dB (75 steps) > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Microphone Volume (OSS: mic) > Aug 12 20:00:14 plebeian kernel: pcm0: | > Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 7 (nid 24 out): 0/40dB (5 steps) > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Speaker/Beep Volume (OSS: speaker) > Aug 12 20:00:14 plebeian kernel: pcm0: | > Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 3 (nid 19 out): -18/0dB (4 steps) > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Recording Level (OSS: rec) > Aug 12 20:00:14 plebeian kernel: pcm0: | > Aug 12 20:00:14 plebeian kernel: pcm0: +- ctl 5 (nid 21 in 0): -74/6dB (81 steps) > Aug 12 20:00:14 plebeian kernel: pcm0: > Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "vol": > Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "pcm": > Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "speaker": > Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "mic": > Aug 12 20:00:14 plebeian kernel: pcm0: Mixer "rec": > Aug 12 20:00:14 plebeian kernel: pcm0: clone manager: deadline=750ms flags=0x8000001e > Aug 12 20:00:14 plebeian kernel: pcm0: sndbuf_setmap 31c0000, 4000; 0xffffff8072dd1000 -> 31c0000 > Aug 12 20:00:14 plebeian kernel: pcm0: sndbuf_setmap 31d0000, 4000; 0xffffff8072de1000 -> 31d0000 > Aug 12 20:00:14 plebeian kernel: pcm1: at cad 0 nid 1 on hdac0 > Aug 12 20:00:14 plebeian kernel: pcm1: +--------------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm1: | DUMPING PCM Playback/Record Channels | > Aug 12 20:00:14 plebeian kernel: pcm1: +--------------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Playback: > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: pcm1: PCM > Aug 12 20:00:14 plebeian kernel: pcm1: PCM cap: 0x000e0560 > Aug 12 20:00:14 plebeian kernel: pcm1: 16 20 24 bits, 44 48 96 192 KHz > Aug 12 20:00:14 plebeian kernel: pcm1: DAC: 17 > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Record: > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Stream cap: 0x00000001 > Aug 12 20:00:14 plebeian kernel: pcm1: PCM > Aug 12 20:00:14 plebeian kernel: pcm1: PCM cap: 0x000e0160 > Aug 12 20:00:14 plebeian kernel: pcm1: 16 20 24 bits, 44 48 96 KHz > Aug 12 20:00:14 plebeian kernel: pcm1: ADC: 20 > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm1: | DUMPING Playback/Record Paths | > Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Playback: > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: nid=26 [pin: Speaker (Fixed)] > Aug 12 20:00:14 plebeian kernel: pcm1: | > Aug 12 20:00:14 plebeian kernel: pcm1: + <- nid=17 [audio output] [src: pcm] > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Record: > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: nid=20 [audio input] > Aug 12 20:00:14 plebeian kernel: pcm1: | > Aug 12 20:00:14 plebeian kernel: pcm1: + <- nid=29 [pin: Mic (Fixed)] [src: monitor] > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm1: | DUMPING Volume Controls | > Aug 12 20:00:14 plebeian kernel: pcm1: +-------------------------+ > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Master Volume (OSS: vol) > Aug 12 20:00:14 plebeian kernel: pcm1: | > Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: PCM Volume (OSS: pcm) > Aug 12 20:00:14 plebeian kernel: pcm1: | > Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 2 (nid 17 out): -74/0dB (75 steps) > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Microphone2 Volume (OSS: monitor) > Aug 12 20:00:14 plebeian kernel: pcm1: | > Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 8 (nid 29 out): 0/48dB (5 steps) > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Recording Level (OSS: rec) > Aug 12 20:00:14 plebeian kernel: pcm1: | > Aug 12 20:00:14 plebeian kernel: pcm1: +- ctl 4 (nid 20 in 0): -74/6dB (81 steps) > Aug 12 20:00:14 plebeian kernel: pcm1: > Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "vol": > Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "pcm": > Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "rec": > Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "ogain": > Aug 12 20:00:14 plebeian kernel: pcm1: Mixer "monitor": > Aug 12 20:00:14 plebeian kernel: pcm1: clone manager: deadline=750ms flags=0x8000001e > Aug 12 20:00:14 plebeian kernel: pcm1: sndbuf_setmap 35d0000, 4000; 0xffffff8072df1000 -> 35d0000 > Aug 12 20:00:14 plebeian kernel: pcm1: sndbuf_setmap 31e0000, 4000; 0xffffff8072e01000 -> 31e0000 > Aug 12 20:00:14 plebeian kernel: ATA PseudoRAID loaded > Aug 12 20:00:14 plebeian kernel: SMP: AP CPU #1 Launched! > Aug 12 20:00:14 plebeian kernel: cpu1 AP: > Aug 12 20:00:14 plebeian kernel: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > Aug 12 20:00:14 plebeian kernel: lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > Aug 12 20:00:14 plebeian kernel: timer: 0x000200ef therm: 0x00010200 err: 0x00010000 pcm: 0x00000400 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 1 vector 49 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 50 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 1 vector 51 > Aug 12 20:00:14 plebeian kernel: ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 1 vector 52 > Aug 12 20:00:14 plebeian kernel: msi: Assigning MSI IRQ 256 to local APIC 1 vector 53 > Aug 12 20:00:14 plebeian kernel: WARNING: WITNESS option enabled, expect reduced performance. > Aug 12 20:00:14 plebeian kernel: ugen0.1: at usbus0 > Aug 12 20:00:14 plebeian kernel: uhub0: on usbus0 > Aug 12 20:00:14 plebeian kernel: GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). > Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 usbus2 usbus1 usbus0 > Aug 12 20:00:14 plebeian kernel: uhub0: 2 ports with 2 removable, self powered > Aug 12 20:00:14 plebeian kernel: ugen1.1: at usbus1 > Aug 12 20:00:14 plebeian kernel: uhub1: on usbus1 > Aug 12 20:00:14 plebeian kernel: uhub1: 2 ports with 2 removable, self powered > Aug 12 20:00:14 plebeian kernel: ugen2.1: at usbus2 > Aug 12 20:00:14 plebeian kernel: uhub2: on usbus2 > Aug 12 20:00:14 plebeian kernel: uhub2: 2 ports with 2 removable, self powered > Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus5 usbus4 usbus3 > Aug 12 20:00:14 plebeian kernel: ugen5.1: at usbus5 > Aug 12 20:00:14 plebeian kernel: uhub3: on usbus5 > Aug 12 20:00:14 plebeian kernel: uhub3: 2 ports with 2 removable, self powered > Aug 12 20:00:14 plebeian kernel: ugen3.1: at usbus3 > Aug 12 20:00:14 plebeian kernel: uhub4: on usbus3 > Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus4 usbus3 > Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus4 usbus3 > Aug 12 20:00:14 plebeian kernel: uhub4: 6 ports with 6 removable, self powered > Aug 12 20:00:14 plebeian kernel: ugen7.1: at usbus7 > Aug 12 20:00:14 plebeian kernel: uhub5: on usbus7 > Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus7 usbus6 usbus4 usbus3 > Aug 12 20:00:14 plebeian last message repeated 2 times > Aug 12 20:00:14 plebeian kernel: uhub5: 6 ports with 6 removable, self powered > Aug 12 20:00:14 plebeian kernel: ugen4.1: at usbus4 > Aug 12 20:00:14 plebeian kernel: uhub6: on usbus4 > Aug 12 20:00:14 plebeian kernel: uhub6: 2 ports with 2 removable, self powered > Aug 12 20:00:14 plebeian kernel: ugen6.1: at usbus6 > Aug 12 20:00:14 plebeian kernel: uhub7: on usbus6 > Aug 12 20:00:14 plebeian kernel: uhub7: 2 ports with 2 removable, self powered > Aug 12 20:00:14 plebeian kernel: Root mount waiting for: usbus3 > Aug 12 20:00:14 plebeian kernel: ugen3.2: at usbus3 > Aug 12 20:00:14 plebeian kernel: Trying to mount root from ufs:/dev/ad4s1a > Aug 12 20:00:14 plebeian kernel: WARNING: / was not properly dismounted > Aug 12 20:00:14 plebeian kernel: ugen1.2: at usbus1 > Aug 12 20:00:14 plebeian kernel: ct_to_ts([2009-08-12 23:59:17]) = 1250121557.000000000 > Aug 12 20:00:14 plebeian kernel: start_init: trying /sbin/init > Aug 12 20:00:14 plebeian kernel: This module (opensolaris) contains code covered by the > Aug 12 20:00:14 plebeian kernel: Common Development and Distribution License (CDDL) > Aug 12 20:00:14 plebeian kernel: see http://opensolaris.org/os/licensing/opensolaris_license/ > Aug 12 20:00:14 plebeian kernel: WARNING: ZFS is considered to be an experimental feature in FreeBSD. > Aug 12 20:00:14 plebeian kernel: ZFS NOTICE: system has less than 4GB and prefetch enable is not set... disabling. > Aug 12 20:00:14 plebeian kernel: ZFS filesystem version 13 > Aug 12 20:00:14 plebeian kernel: ZFS storage pool version 13 > Aug 12 20:00:14 plebeian kernel: crypto: > Aug 12 20:00:14 plebeian kernel: cryptosoft0: on motherboard > Aug 12 20:00:14 plebeian kernel: crypto: assign cryptosoft0 driver id 0, flags 100663296 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 > Aug 12 20:00:14 plebeian kernel: GEOM_ELI: Device ad4s1d.eli created. > Aug 12 20:00:14 plebeian kernel: GEOM_ELI: Encryption: AES-CBC 256 > Aug 12 20:00:14 plebeian kernel: GEOM_ELI: Crypto: software > Aug 12 20:00:14 plebeian kernel: linprocfs registered > Aug 12 20:00:14 plebeian kernel: lock order reversal: > Aug 12 20:00:14 plebeian kernel: 1st 0xffffff0003cb2448 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 > Aug 12 20:00:14 plebeian kernel: 2nd 0xffffff0003f20098 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1465 > Aug 12 20:00:14 plebeian kernel: KDB: stack backtrace: > Aug 12 20:00:14 plebeian kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Aug 12 20:00:14 plebeian kernel: kdb_backtrace() at kdb_backtrace+0x32 > Aug 12 20:00:14 plebeian kernel: _witness_debugger() at _witness_debugger+0x1e > Aug 12 20:00:14 plebeian kernel: witness_checkorder() at witness_checkorder+0x8c7 > Aug 12 20:00:14 plebeian kernel: __lockmgr_args() at __lockmgr_args+0x773 > Aug 12 20:00:14 plebeian kernel: ffs_vgetf() at ffs_vgetf+0x1ae > Aug 12 20:00:14 plebeian kernel: ffs_vget() at ffs_vget+0xf > Aug 12 20:00:14 plebeian kernel: ufs_root() at ufs_root+0x1e > Aug 12 20:00:14 plebeian kernel: vfs_donmount() at vfs_donmount+0x13cd > Aug 12 20:00:14 plebeian kernel: nmount() at nmount+0x6a > Aug 12 20:00:14 plebeian kernel: syscall() at syscall+0x2e9 > Aug 12 20:00:14 plebeian kernel: Xfast_syscall() at Xfast_syscall+0xe1 > Aug 12 20:00:14 plebeian kernel: --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007ab02c, rsp = 0x7fffffffdd48, rbp = 0x800a03048 --- > Aug 12 20:00:16 plebeian kernel: em0: Link is up 1000 Mbps Full Duplex > Aug 12 20:00:16 plebeian kernel: em0: link state changed to UP > Aug 12 20:00:17 plebeian dhclient: New IP Address (em0): 172.20.143.106 > Aug 12 20:00:17 plebeian dhclient: New Subnet Mask (em0): 255.255.255.0 > Aug 12 20:00:17 plebeian dhclient: New Broadcast Address (em0): 172.20.143.255 > Aug 12 20:00:17 plebeian dhclient: New Routers (em0): 172.20.143.1 > Aug 12 20:00:22 plebeian kernel: lock order reversal: > Aug 12 20:00:22 plebeian kernel: 1st 0xffffff000350f7f8 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:1693 > Aug 12 20:00:22 plebeian kernel: 2nd 0xffffff0003eee270 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > Aug 12 20:00:22 plebeian kernel: KDB: stack backtrace: > Aug 12 20:00:22 plebeian kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > Aug 12 20:00:22 plebeian kernel: kdb_backtrace() at kdb_backtrace+0x32 > Aug 12 20:00:22 plebeian kernel: _witness_debugger() at _witness_debugger+0x1e > Aug 12 20:00:22 plebeian kernel: witness_checkorder() at witness_checkorder+0x8c7 > Aug 12 20:00:22 plebeian kernel: __lockmgr_args() at __lockmgr_args+0x773 > Aug 12 20:00:22 plebeian kernel: vop_stdlock() at vop_stdlock+0x51 > Aug 12 20:00:22 plebeian kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0xbf > Aug 12 20:00:22 plebeian kernel: _vn_lock() at _vn_lock+0x6e > Aug 12 20:00:22 plebeian kernel: vget() at vget+0xbf > Aug 12 20:00:22 plebeian kernel: vfs_msync() at vfs_msync+0xcf > Aug 12 20:00:22 plebeian kernel: sync_fsync() at sync_fsync+0x141 > Aug 12 20:00:22 plebeian kernel: VOP_FSYNC_APV() at VOP_FSYNC_APV+0xb7 > Aug 12 20:00:22 plebeian kernel: sync_vnode() at sync_vnode+0x146 > Aug 12 20:00:22 plebeian kernel: sched_sync() at sched_sync+0x259 > Aug 12 20:00:22 plebeian kernel: fork_exit() at fork_exit+0x147 > Aug 12 20:00:22 plebeian kernel: fork_trampoline() at fork_trampoline+0xe > Aug 12 20:00:22 plebeian kernel: --- trap 0, rip = 0, rsp = 0xffffff8072e2ed30, rbp = 0 --- > Aug 12 20:00:42 plebeian kernel: drm0: on vgapci0 > Aug 12 20:00:42 plebeian kernel: vgapci0: attempting to allocate 1 MSI vectors (1 supported) > Aug 12 20:00:42 plebeian kernel: msi: routing MSI IRQ 258 to local APIC 1 vector 54 > Aug 12 20:00:42 plebeian kernel: vgapci0: using IRQ 258 for MSI > Aug 12 20:00:42 plebeian kernel: info: [drm] MSI enabled 1 message(s) > Aug 12 20:00:42 plebeian kernel: vgapci0: child drm0 requested pci_enable_busmaster > Aug 12 20:00:42 plebeian kernel: info: [drm] AGP at 0xd0000000 256MB > Aug 12 20:00:42 plebeian kernel: info: [drm] Initialized i915 1.6.0 20080730 > Aug 12 20:00:43 plebeian kernel: drm0: [MPSAFE] > Aug 12 20:00:43 plebeian kernel: drm0: [ITHREAD] > Aug 12 20:00:48 plebeian kernel: em0: Link is Down > Aug 12 20:00:48 plebeian kernel: em0: link state changed to DOWN > Aug 12 20:00:52 plebeian kernel: em0: Link is up 1000 Mbps Full Duplex > Aug 12 20:00:52 plebeian kernel: em0: link state changed to UP > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 11:55:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 084631065673 for ; Thu, 13 Aug 2009 11:55:44 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id D6DFE8FC47 for ; Thu, 13 Aug 2009 11:55:43 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MbYuF-0007Od-1u for freebsd-current@freebsd.org; Thu, 13 Aug 2009 04:55:43 -0700 Message-ID: <24953536.post@talk.nabble.com> Date: Thu, 13 Aug 2009 04:55:43 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <20090813002104.GA1481@plebeian.afflictions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <20090813002104.GA1481@plebeian.afflictions.org> Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 11:55:44 -0000 Damian Gerow wrote: > > When resuming from graphics mode, the screen is restored, but fails to > update beyond restoring the initial display. The keyboard responds (caps > lock light turns on, changing the console results in an error beep), but > that's about it. Ctrl+alt+delete does cleanly reboot the system at this > point, and after reboot, I can see the system did actually come back > cleanly. > Hello. It looks the same for T400/GM45, I never used sleep so maybe I missed period when it worked fully. I reckon I had once pressed Fn+F12 by accident, notebook resumed but mouse pointer stalled. When I tried it second time, It failed to restore graphic, as above. -best regards, Jakub Lach PS. amd64 -- View this message in context: http://www.nabble.com/No-display-after-resume-in-r196086-tp24947041p24953536.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 12:06:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 490291065672 for ; Thu, 13 Aug 2009 12:06:31 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 024A58FC3F for ; Thu, 13 Aug 2009 12:06:30 +0000 (UTC) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id BE41BC4264; Thu, 13 Aug 2009 14:04:17 +0200 (CEST) From: Piotr =?iso-8859-2?q?Zi=EAcik?= Organization: Semihalf To: freebsd-current@freebsd.org Date: Thu, 13 Aug 2009 14:06:29 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906251329.35200.kosmo@semihalf.com> <4A4A7735.9060301@samsco.org> <200907151401.29706.kosmo@semihalf.com> In-Reply-To: <200907151401.29706.kosmo@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200908131406.29977.kosmo@semihalf.com> Cc: Subject: Re: [PATCH RFC]: Bus_dma eats all available memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 12:06:31 -0000 Wednesday 15 July 2009 14:01:29 Piotr Zi=EAcik napisa=B3(a): > Tuesday 30 June 2009 22:36:05 Scott Long napisa=B3(a): > > This looks reasonable. I'll give it a closer review and commit it to > > the FreeBSD repo. Thanks a lot for working on it. > > Hi. > > I have checked FreeBSD SVN and I do not see any changes related to my pat= ch > there. Are you finished review and going to commit my patch before 8.0 > release ? Is there any progress? If you do not have time, I will ask someone else to= =20 commit the patch to FreeBSD repo, but I need review from you ... =2D-=20 Best Regards, Piotr Zi=EAcik From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 12:11:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CC9C106564A for ; Thu, 13 Aug 2009 12:11:42 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id EE1CA8FC16 for ; Thu, 13 Aug 2009 12:11:41 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so243485qwe.7 for ; Thu, 13 Aug 2009 05:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=zAVxTCyhTXQfQjlsRrqfzIbxTv/BpvN5T7l946Kt/vA=; b=n9VxEvem/cSvCtQ7V1RtsN3aheCx+Ni7zoLVb5bXNlGnjDC5FoR5ATu9+ot5Ew/Xbu iUkPw/WhiwnqwN0ux5RflBnVyZbokgvKBqH3Fow+HV3g3CXNVFgzUFbotJOnnmoF4fBF Z7hS0Q8pbO45FJUCD/suq9hlU/dQhIHtcXBnU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=MtDpDfFkFUewSBluaczwHtDxPEIjP06zYAGkQz4g/yJuoVwrZAJliPWtM80HeaVXvU V9or7XywhLMa0xm3Mzqott+6+5SMOPOTlJ2ExKmY4+BLuRH8EWyRbFbRvyAeTPji+hn5 36fBP8Hy1cohDiM2FKIo2MgnhWH2R20gj0D/o= MIME-Version: 1.0 Received: by 10.229.15.75 with SMTP id j11mr725042qca.69.1250164297567; Thu, 13 Aug 2009 04:51:37 -0700 (PDT) Date: Thu, 13 Aug 2009 13:51:37 +0200 Message-ID: <90a5caac0908130451h12daf4f1nd90246a398274e43@mail.gmail.com> From: Lucius Windschuh To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: usb: panic when pulling a keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 12:11:42 -0000 Hi. As I pulled my Apple keyboard (2 external ports uhub + ukbd) this morning from my machine, it generated a panic. This one is reproducible by pulling the keyboard from the machine when rc.d/geli asks for a password. Simply pulling the keyboard at any moment does not lead to the panic, but in this special case, it does. BTW: The panic does not happen if I use a "pure" ukbd/ums PS2-to-USB adaptor without integrated hub. A text- and minidump is available. Kernel: 8.0-BETA2, r196161 Kernel log: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xdeadc0fa fault code = supervisor read, page not present instruction pointer = 0x20:0xc05f20f9 stack pointer = 0x28:0xe8e99ad8 frame pointer = 0x28:0xe8e99b10 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 45 (usbus7) Backtrace: #10 0xc05f20f9 in usb_unconfigure (udev=0xc6c0e000, flag=Variable "flag" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:1913 1913 LIST_REMOVE(pd, pd_next); Current language: auto; currently c (kgdb) #11 0xc05f23de in usb_free_device (udev=0xc6c0e000, flag=Variable "flag" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:1983 1983 usb_unconfigure(udev, flag); (kgdb) #12 0xc05f9433 in uhub_detach (dev=0xc6c1ac00) at /usr/src/sys/dev/usb/usb_hub.c:910 910 usb_free_device(child, (kgdb) #13 0xc06d9dd6 in device_detach (dev=0xc6c1ac00) at device_if.h:212 212 device_if.h: No such file or directory. in device_if.h (kgdb) #14 0xc05f2038 in usb_unconfigure (udev=0xc6bcd000, flag=Variable "flag" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:1020 1020 if (device_detach(dev)) { (kgdb) #15 0xc05f23de in usb_free_device (udev=0xc6bcd000, flag=Variable "flag" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:1983 1983 usb_unconfigure(udev, flag); (kgdb) #16 0xc05fa24c in uhub_explore (udev=0xc6bcf400) at /usr/src/sys/dev/usb/usb_hub.c:324 324 usb_free_device(child, (kgdb) #17 0xc05ea107 in usb_bus_explore (pm=0xc6923dd4) at /usr/src/sys/dev/usb/controller/usb_controller.c:235 235 (udev->hub->explore) (udev); (kgdb) #18 0xc05fc8de in usb_process (arg=0xc6923d74) at /usr/src/sys/dev/usb/usb_process.c:161 161 (pm->pm_callback) (pm); (kgdb) #19 0xc0688bf8 in fork_exit (callout=0xc05fc800 , arg=0xc6923d74, frame=0xe8e75d38) at /usr/src/sys/kern/kern_fork.c:838 838 callout(arg, frame); (kgdb) #20 0xc09290b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 270 call fork_exit I'm willing to play remote hands on the gdb for further analysis. Lucius From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 12:46:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01E9A10657AA for ; Thu, 13 Aug 2009 12:46:30 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 8B6028FC59 for ; Thu, 13 Aug 2009 12:46:29 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=HhXZYSNfp81e4FWth-kA:9 a=YDZjyK-STW7N7bJWXvm9--4fqQ0A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1292049349; Thu, 13 Aug 2009 14:46:27 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 13 Aug 2009 14:46:34 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <90a5caac0908130451h12daf4f1nd90246a398274e43@mail.gmail.com> In-Reply-To: <90a5caac0908130451h12daf4f1nd90246a398274e43@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908131446.35053.hselasky@c2i.net> Cc: Lucius Windschuh Subject: Re: usb: panic when pulling a keyboard X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 12:46:30 -0000 On Thursday 13 August 2009 13:51:37 Lucius Windschuh wrote: > Lucius Windschuh Hi, Can you try the following patch: (Needs to be hand patched, due to other changes inside the file.) http://perforce.freebsd.org/chv.cgi?CH=167286 Thanks for bughunting ! --HPS From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 13:33:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 632BA1065672; Thu, 13 Aug 2009 13:33:00 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9768FC1F; Thu, 13 Aug 2009 13:32:59 +0000 (UTC) Received: from roadrunner.spoerlein.net (e180177181.adsl.alicedsl.de [85.180.177.181]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7DDWrZL023790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Aug 2009 15:32:54 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: from roadrunner.spoerlein.net (localhost [127.0.0.1]) by roadrunner.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7DDT8tH011663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 15:29:08 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by roadrunner.spoerlein.net (8.14.3/8.14.3/Submit) id n7DDT771011662; Thu, 13 Aug 2009 15:29:07 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 13 Aug 2009 15:29:07 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Alan Cox Message-ID: <20090813132907.GA1591@roadrunner.spoerlein.net> Mail-Followup-To: Alan Cox , current@freebsd.org, Kip Macy References: <20090713181650.GB76464@acme.spoerlein.net> <4A5B7D24.60100@cs.rice.edu> <20090714105245.GR2145@acme.spoerlein.net> <4A82DFBF.5020101@cs.rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A82DFBF.5020101@cs.rice.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org, Kip Macy Subject: Re: panic: vm_page_free_toq: freeing mapped page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:33:00 -0000 On Wed, 12.08.2009 at 10:29:03 -0500, Alan Cox wrote: > Ulrich Spörlein wrote: > > On Mon, 13.07.2009 at 13:29:56 -0500, Alan Cox wrote: > > > >> Ulrich Spörlein wrote: > >> > >>> On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Spörlein wrote: > >>> > >>> > >>>> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote: > >>>> > >>>> > >>>>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich Spörlein wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> 8.0 BETA1 @ r195622 will panic reliably when running the clang static > >>>>>> analyzer on a buildworld with something like the following panic: > >>>>>> > >>>>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30 > >>>>>> cpuid = 1 > >>>>>> KDB: stack backtrace: > >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > >>>>>> panic() at panic+0x182 > >>>>>> vm_page_free_toq() at vm_page_free_toq+0x1f6 > >>>>>> vm_object_terminate() at vm_object_terminate+0xb7 > >>>>>> vm_object_deallocate() at vm_object_deallocate+0x17a > >>>>>> _vm_map_unlock() at _vm_map_unlock+0x70 > >>>>>> vm_map_remove() at vm_map_remove+0x6f > >>>>>> vmspace_free() at vmspace_free+0x56 > >>>>>> vmspace_exec() at vmspace_exec+0x56 > >>>>>> exec_new_vmspace() at exec_new_vmspace+0x133 > >>>>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee > >>>>>> kern_execve() at kern_execve+0x3b2 > >>>>>> execve() at execve+0x3d > >>>>>> syscall() at syscall+0x1af > >>>>>> Xfast_syscall() at Xfast_syscall+0xe1 > >>>>>> --- syscall (59, FreeBSD ELF64, execve), rip = 0x800c20d0c, rsp = 0x7fffffffd6f8, rbp = 0x7fffffffdbf0 --- > >>>>>> > >>>>>> > >>>>> Can you try the following change: > >>>>> > >>>>> http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_object.c?r1=192842&r2=195297 > >>>>> > >>>>> > >>>> Applied this to HEAD by hand an ran with it, it died 20-30 minutes into > >>>> the scan-build run. So no luck there. Next up is a test using the > >>>> GENERIC kernel. > >>>> > >>> No improvement with a GENERIC kernel. Next up will be to run this with > >>> clean sysctl, loader.conf, etc. Then I'll try disabling SMP. > >>> > >>> Does the backtrace above point to any specific subsystem? I'm using UFS, > >>> ZFS and GELI on this machine and could try a few combinations... > >>> > >> The interesting thing about the backtrace is that it shows a 32-bit i386 > >> executable being started on a 64-bit amd64 machine. I've seen this > >> backtrace once before, and you'll find it in the PR database. In that > >> case, the problem "went away" after the known-to-be-broken > >> ZERO_COPY_SOCKETS option was removed from the reporter's kernel > >> configuration. However, I don't see that as the culprit here. > >> > > > > Hi Alan, first the bad news > > > > I ran this test with a GENERIC kernel, SMP disabled, hw.physmem set to 2 > > GB in single user mode, so no other processes or deamons running, > > nothing special in loader.conf except for ZFS and GELI. It reliably > > panics, so nothing new here. > > > > Now the good news, you may be able to crash your own amd64 box in 3 > > minutes by doing: > > > > mkdir /tmp/foo && cd /tmp/foo > > fetch -o- https://www.spoerlein.net/pub/llvm-clang.tar.gz | tar xf - > > while :; do for d in bin sbin usr.bin usr.sbin; do $PWD/scan-build -o /dev/null -k make -C /usr/src/$d clean obj depend all; done; done > > > > Please note that scan-build/ccc-analyzer wont actually do anything, as > > they cannot create output in /dev/null. So this is just running the > > perl-script and forking make/sh/awk/ccc-analyzer like mad. It does not > > survive 3 minutes on my Core2 Duo 3.3 GHz. > > > > Hi Ulrich, > > I finally got a chance to try this workload. I'm afraid that I can't > reproduce the assertion failure on my amd64 test machine. I left the > test running overnight, and it was still going strong this morning. > > I am using neither ZFS nor GELI. Is it possible for you to repeat this > test without ZFS and/or GELI? > > I would also be curious if anyone else reading this message can > reproduce the assertion failure with the above test. Now isn't this great :/ I haven't tracked the bug for the last couple of weeks, but the system was updated to recent HEAD and got its ports rebuild (several times). I don't know which change "fixed" it, but I think it was the perl rebuild (I had some trouble with perl5.10 on 8.0 at first). Besides, the process doing the fork in the backtrace was always the perl binary, IIRC. So right now I'm no longer able to reproduce it myself ... Regards, Uli From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 13:53:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71212106566C for ; Thu, 13 Aug 2009 13:53:02 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id BFDA18FC3F for ; Thu, 13 Aug 2009 13:53:01 +0000 (UTC) Received: by bwz19 with SMTP id 19so813223bwz.37 for ; Thu, 13 Aug 2009 06:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=NYratzb9K92Lr7qcV2gcNPfzAg2QFG+g8yAx/BOTyOs=; b=sdU7/GVIYW4q2FJTZwZP1UwGTpYPaLvDmBIY8Ksp2eJbGGLhYlhzH5Z3eCpg5PMiVg 0qa3ZSulsD3eW26vYxaopHuYOHRGUZSn1YxJCt7iclBOSL6vlmg0ICZ8BQDJ4pBuXTcN kDlZ5uYwNSh7/EH3Oh4RwHMgT5E63AA5cG+ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hSAyD6Rj9sUB4HjBMq1BtLDMh5yYKFSTCoNY5eRS42UCKSH0aQgM24UL067iho5W14 YEXGKvpwIqdx0jOcbwBj64MPNsSUFRL4sR38C1Ei7qeri7lEMVP+GVCllMcpj04MO41p fZmi6fjODR+/Ignn1vpS4f75FWMHRMKFb57Mk= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.143.8 with SMTP id s8mr352084fau.39.1250171579781; Thu, 13 Aug 2009 06:52:59 -0700 (PDT) In-Reply-To: <1250161757.1823.18.camel@balrog.2hip.net> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> Date: Thu, 13 Aug 2009 15:52:59 +0200 X-Google-Sender-Auth: 8aa30cbeed44a464 Message-ID: <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> From: Attilio Rao To: Robert Noland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Damian Gerow , freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:53:02 -0000 2009/8/13 Robert Noland : > On Wed, 2009-08-12 at 20:21 -0400, Damian Gerow wrote: >> Some time between r195828 and r196086, resuming from an S3 suspend seems to >> have broken for me. >> >> When resuming in text mode, the system locks up completely before the >> screen comes back on. Of course, resuming from text mode has never worked, >> so this isn't much of a concern. >> >> When resuming from graphics mode, the screen is restored, but fails to >> update beyond restoring the initial display. The keyboard responds (caps >> lock light turns on, changing the console results in an error beep), but >> that's about it. Ctrl+alt+delete does cleanly reboot the system at this >> point, and after reboot, I can see the system did actually come back >> cleanly. >> >> The system is a Lenovo X200, running an amd64 install of r196086 (standard >> GENERIC kernel) The graphics chipset is an Intel X4500MHD. > > Looking at the change log, I suspect the newbus locking code... But that > is just a stab in the dark. There were not any changes to drm, which is > responsible for saving/restoring state when it is loaded. Damnian, why don't you directly try the revision immediately before newbus locking (so immediately prior to r196037) and try to verify it still works. I'm aware of at least one possible deadlock source but it should not happen while suspend/resume. However, I'm preparing an errata patch for newbus locking. If you verify newbus locking is the real culprit and that my further patch doesn't fix your problem we can try to hammer it down further. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 13:51:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E12C106566B; Thu, 13 Aug 2009 13:51:02 +0000 (UTC) (envelope-from mih@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 08DB18FC16; Thu, 13 Aug 2009 13:51:01 +0000 (UTC) Received: from [10.0.0.43] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id AAEEBC4264; Thu, 13 Aug 2009 15:32:33 +0200 (CEST) Message-ID: <4A841697.2080909@semihalf.com> Date: Thu, 13 Aug 2009 15:35:19 +0200 From: Michal Hajduk User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: hselasky@c2i.net, freebsd-usb@freebsd.org, freebsd-current@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 13 Aug 2009 14:17:31 +0000 Cc: Subject: Mounting rootfs from USB - problem. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 13:51:02 -0000 Hello Hans, I've observed problem with mounting root filesystem from USB device at ARM platform. In my case the da0 device has showed too late (after Manual root filesystem specification). I've read the previous threads about USB booting problem but there was no final solution for this issue. http://www.nabble.com/new-usb-stack---boot-problem-from-usb-hdd-td23100089.html Maybe you know the best way how to deal with it ? or somebody is trying to fix it? Thanks for help. Best regards, MichaÅ‚ Hajduk From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 14:21:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C16471065674; Thu, 13 Aug 2009 14:21:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id CD45C8FC55; Thu, 13 Aug 2009 14:21:54 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=dlwttS5sZ5EA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=9I5xiGouAAAA:8 a=qxxMOkJawPEcHz25rw0A:9 a=aIh_f17IdQCX5QTYh5UICmK5DJ0A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 553092958; Thu, 13 Aug 2009 16:21:53 +0200 From: Hans Petter Selasky To: Michal Hajduk , Andrew Thompson Date: Thu, 13 Aug 2009 16:21:58 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <4A841697.2080909@semihalf.com> In-Reply-To: <4A841697.2080909@semihalf.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908131622.00203.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Mounting rootfs from USB - problem. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 14:21:56 -0000 On Thursday 13 August 2009 15:35:19 Michal Hajduk wrote: > Hello Hans, > > I've observed problem with mounting root filesystem from USB device at > ARM platform. In my case the da0 device has showed too late > (after Manual root filesystem specification). > > I've read the previous threads about USB booting problem but > there was no final solution for this issue. > > http://www.nabble.com/new-usb-stack---boot-problem-from-usb-hdd-td23100089. >html > > > Maybe you know the best way how to deal with it ? or somebody > is trying to fix it? Hi, The problem is in: src/sys/kern/vfs_mount.c I have suggested a solution where the mount root code is polling for the given device until it arrives. The current device behaviour is the opposite: To wait until all devices are present until mounting anything. I'm currently not involved in any work on this. I would not recommend adding more delay during startup to catch all kinds of USB devices enumerating. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 14:29:34 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94637106567A; Thu, 13 Aug 2009 14:29:34 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 705788FC47; Thu, 13 Aug 2009 14:29:34 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0E1DC46B0D; Thu, 13 Aug 2009 10:29:34 -0400 (EDT) Date: Thu, 13 Aug 2009 15:29:33 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: stable@FreeBSD.org Subject: Update - RELENG_8 open for business (but you probably noticed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 14:29:35 -0000 Just a quick status update from the release engineering team: As was discussed on this mailing list, problems with the Subversion->CVS exporter arose during the RELENG_8 branching process. These have now been resolved, and for the last day or so, pending bug fixes have been rushing into the branch. We'll wait a couple more days while things catch up, and then cut 8.0 BETA3. You can read more about the status of 8.0, including tracking pending and approved fixes, on the 8.0 release engineering wiki: http://wiki.freebsd.org/8.0TODO Your help in testing, diagnosing, and fixing FreeBSD 8.x problems *before* the release is much appreciated! Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 14:54:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2025E106566B for ; Thu, 13 Aug 2009 14:54:06 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id DB5A48FC4D for ; Thu, 13 Aug 2009 14:54:05 +0000 (UTC) Received: (qmail 32802 invoked from network); 13 Aug 2009 14:27:23 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay00.pair.com with SMTP; 13 Aug 2009 14:27:23 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost.osted.lan [127.0.0.1]) by x2.osted.lan (8.14.2/8.14.2) with ESMTP id n7DERNx9063084; Thu, 13 Aug 2009 16:27:23 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.2/8.14.2/Submit) id n7DERNMS063083; Thu, 13 Aug 2009 16:27:23 +0200 (CEST) (envelope-from pho) Date: Thu, 13 Aug 2009 16:27:23 +0200 From: Peter Holm To: Alan Cox , current@freebsd.org, Kip Macy Message-ID: <20090813142723.GA62890@x2.osted.lan> References: <20090713181650.GB76464@acme.spoerlein.net> <4A5B7D24.60100@cs.rice.edu> <20090714105245.GR2145@acme.spoerlein.net> <4A82DFBF.5020101@cs.rice.edu> <20090813132907.GA1591@roadrunner.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090813132907.GA1591@roadrunner.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: panic: vm_page_free_toq: freeing mapped page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 14:54:06 -0000 On Thu, Aug 13, 2009 at 03:29:07PM +0200, Ulrich Spörlein wrote: > On Wed, 12.08.2009 at 10:29:03 -0500, Alan Cox wrote: > > Ulrich Spörlein wrote: > > > On Mon, 13.07.2009 at 13:29:56 -0500, Alan Cox wrote: > > > > > >> Ulrich Spörlein wrote: > > >> > > >>> On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Spörlein wrote: > > >>> > > >>> > > >>>> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote: > > >>>> > > >>>> > > >>>>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich Spörlein wrote: > > >>>>> > > >>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> 8.0 BETA1 @ r195622 will panic reliably when running the clang static > > >>>>>> analyzer on a buildworld with something like the following panic: > > >>>>>> > > >>>>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30 > > >>>>>> cpuid = 1 > > >>>>>> KDB: stack backtrace: > > >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > >>>>>> panic() at panic+0x182 > > >>>>>> vm_page_free_toq() at vm_page_free_toq+0x1f6 > > >>>>>> vm_object_terminate() at vm_object_terminate+0xb7 > > >>>>>> vm_object_deallocate() at vm_object_deallocate+0x17a > > >>>>>> _vm_map_unlock() at _vm_map_unlock+0x70 > > >>>>>> vm_map_remove() at vm_map_remove+0x6f > > >>>>>> vmspace_free() at vmspace_free+0x56 > > >>>>>> vmspace_exec() at vmspace_exec+0x56 > > >>>>>> exec_new_vmspace() at exec_new_vmspace+0x133 > > >>>>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee > > >>>>>> kern_execve() at kern_execve+0x3b2 > > >>>>>> execve() at execve+0x3d > > >>>>>> syscall() at syscall+0x1af > > >>>>>> Xfast_syscall() at Xfast_syscall+0xe1 > > >>>>>> --- syscall (59, FreeBSD ELF64, execve), rip = 0x800c20d0c, rsp = 0x7fffffffd6f8, rbp = 0x7fffffffdbf0 --- > > >>>>>> > > >>>>>> > > >>>>> Can you try the following change: > > >>>>> > > >>>>> http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_object.c?r1=192842&r2=195297 > > >>>>> > > >>>>> > > >>>> Applied this to HEAD by hand an ran with it, it died 20-30 minutes into > > >>>> the scan-build run. So no luck there. Next up is a test using the > > >>>> GENERIC kernel. > > >>>> > > >>> No improvement with a GENERIC kernel. Next up will be to run this with > > >>> clean sysctl, loader.conf, etc. Then I'll try disabling SMP. > > >>> > > >>> Does the backtrace above point to any specific subsystem? I'm using UFS, > > >>> ZFS and GELI on this machine and could try a few combinations... > > >>> > > >> The interesting thing about the backtrace is that it shows a 32-bit i386 > > >> executable being started on a 64-bit amd64 machine. I've seen this > > >> backtrace once before, and you'll find it in the PR database. In that > > >> case, the problem "went away" after the known-to-be-broken > > >> ZERO_COPY_SOCKETS option was removed from the reporter's kernel > > >> configuration. However, I don't see that as the culprit here. > > >> > > > > > > Hi Alan, first the bad news > > > > > > I ran this test with a GENERIC kernel, SMP disabled, hw.physmem set to 2 > > > GB in single user mode, so no other processes or deamons running, > > > nothing special in loader.conf except for ZFS and GELI. It reliably > > > panics, so nothing new here. > > > > > > Now the good news, you may be able to crash your own amd64 box in 3 > > > minutes by doing: > > > > > > mkdir /tmp/foo && cd /tmp/foo > > > fetch -o- https://www.spoerlein.net/pub/llvm-clang.tar.gz | tar xf - > > > while :; do for d in bin sbin usr.bin usr.sbin; do $PWD/scan-build -o /dev/null -k make -C /usr/src/$d clean obj depend all; done; done > > > > > > Please note that scan-build/ccc-analyzer wont actually do anything, as > > > they cannot create output in /dev/null. So this is just running the > > > perl-script and forking make/sh/awk/ccc-analyzer like mad. It does not > > > survive 3 minutes on my Core2 Duo 3.3 GHz. > > > > > > > Hi Ulrich, > > > > I finally got a chance to try this workload. I'm afraid that I can't > > reproduce the assertion failure on my amd64 test machine. I left the > > test running overnight, and it was still going strong this morning. > > > > I am using neither ZFS nor GELI. Is it possible for you to repeat this > > test without ZFS and/or GELI? > > > > I would also be curious if anyone else reading this message can > > reproduce the assertion failure with the above test. > > Now isn't this great :/ > > I haven't tracked the bug for the last couple of weeks, but the system > was updated to recent HEAD and got its ports rebuild (several times). > > I don't know which change "fixed" it, but I think it was the perl > rebuild (I had some trouble with perl5.10 on 8.0 at first). Besides, the > process doing the fork in the backtrace was always the perl binary, > IIRC. > > So right now I'm no longer able to reproduce it myself ... > > Regards, > Uli Using your test scenario I got the panic. - Peter From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 16:27:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7785D10656A6 for ; Thu, 13 Aug 2009 16:27:54 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay1-v.mail.gandi.net (relay1-v.mail.gandi.net [217.70.178.75]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0978FC4A for ; Thu, 13 Aug 2009 16:27:54 +0000 (UTC) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.226]) by relay1-v.mail.gandi.net (Postfix) with ESMTP id 9E552362AF; Thu, 13 Aug 2009 18:27:52 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 10DEDF082; Thu, 13 Aug 2009 12:27:05 -0400 (EDT) Date: Thu, 13 Aug 2009 12:27:05 -0400 From: Damian Gerow To: Attilio Rao Message-ID: <20090813162705.GA1468@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Robert Noland Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:27:54 -0000 Attilio Rao wrote: : why don't you directly try the revision immediately before newbus : locking (so immediately prior to r196037) and try to verify it still : works. Culprit confirmed: I can resume with r196036, but not r196037. : I'm aware of at least one possible deadlock source but it should not : happen while suspend/resume. However, I'm preparing an errata patch : for newbus locking. : If you verify newbus locking is the real culprit and that my further : patch doesn't fix your problem we can try to hammer it down further. Let me know what else you might need. From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 16:37:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F7E71065677 for ; Thu, 13 Aug 2009 16:37:25 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2928FC41 for ; Thu, 13 Aug 2009 16:37:24 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7DGbNNQ028573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 18:37:23 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7DGbNUj028572; Thu, 13 Aug 2009 18:37:23 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 13 Aug 2009 18:37:22 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Harald Schmalzbauer Message-ID: <20090813163722.GK72922@acme.spoerlein.net> Mail-Followup-To: Harald Schmalzbauer , FreeBSD Current References: <4A7EA0A7.1000507@omnilan.de> <4A7FC408.6020401@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7FC408.6020401@omnilan.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Current Subject: Re: USB umass device not working on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:37:25 -0000 On Mon, 10.08.2009 at 08:54:00 +0200, Harald Schmalzbauer wrote: > Harald Schmalzbauer schrieb am 09.08.2009 12:10 (localtime): > ... > > one year ago I fed my present for my mother with some music files - a > > samsung ogg-player. > > Until now the music collection is still untouched, so I tried to help > > her and replace some files. > > Unfortunately it doesn't attach as daX any more. > ... > > Hmmm, very strange, here I found a PR reporting the opposite: > http://www.jp.freebsd.org/cgi/query-pr.cgi?pr=114154 > It's my player (just the 2G version) and Ulrich Spoerlein reports it > working with HPS' stack, but not with the old USB code. > I'm sure I filled this puppy here and I've been running FreeBSD-7 until > -current was ready for testing (arround beta1). > None the less, this device seems to work somehow on FreeBSD. I'm not > sure how usb_quirk.ko is related. I'm lost. Are there still hard coded > quirks? > Any help appreciated The test with Hans' stack was done a long time ago. Funny thing was also, that something changed on RELENG_7 so that I needed to backout those quirks to make the device work. It is working just fine under RELENG_7 c But trying this on a recent -CURRENT, I'm outta luck again: ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0110 umass0:1:0:-1: Attached to scbus1 (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device Oh well ... Uli From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 16:38:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11ADB1065674; Thu, 13 Aug 2009 16:38:50 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6B0388FC4A; Thu, 13 Aug 2009 16:38:49 +0000 (UTC) Received: by fxm24 with SMTP id 24so910211fxm.36 for ; Thu, 13 Aug 2009 09:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=etY+Nx0Nl6I38OFVk7VTujTvaskk0gg0L0VdAa+v9Ns=; b=SPlZABAUTO3nhzE2QXhuHYzAcRi4iclBZB7dfhCIP8Fyf6vuZRUKaotTDwYcS1yG+E 3Wvr15o2/qUc3L89QjKQUi2hmQ2WhlA4KHj1tlCGRD0BLTrlp93sKCWCvxp6M0fXPmB9 fngzwxQNwidSvOXi8X9ifNosGx3Hi8/tiTi3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=L0qWErxbKhYXmCehtA0np+gBQxwXLl0uGt2qiqVl1xNEE8k4LCNsh1cocZzCG7D0eL u1VviDAw6ArqaaHC2CuoFTtywhy8WKeb+F8E0l8x9ymgYzcxj7Gf9MeVvuRo8HX01tuk KRUaUfYEeQ118pKSkyMjnBdseSnUXtuOSLtiE= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.125.207 with SMTP id z15mr418324far.7.1250181528300; Thu, 13 Aug 2009 09:38:48 -0700 (PDT) In-Reply-To: <20090813162705.GA1468@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> Date: Thu, 13 Aug 2009 18:38:48 +0200 X-Google-Sender-Auth: c177a47b0f06ab5a Message-ID: <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> From: Attilio Rao To: Damian Gerow Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Noland Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:38:50 -0000 2009/8/13 Damian Gerow : > Attilio Rao wrote: > : why don't you directly try the revision immediately before newbus > : locking (so immediately prior to r196037) and try to verify it still > : works. > > Culprit confirmed: I can resume with r196036, but not r196037. > > : I'm aware of at least one possible deadlock source but it should not > : happen while suspend/resume. However, I'm preparing an errata patch > : for newbus locking. > : If you verify newbus locking is the real culprit and that my further > : patch doesn't fix your problem we can try to hammer it down further. > > Let me know what else you might need. So, what you can do is to compile a kernel with the following options: KDB, DDB, INVARIANT_SUPPORT, INVARIANTS, WITNESS when you get the deadlock, you should break in DDB. Through a textdump(4) (or serial console or whatever you prefer) you should get the following informations: bt, ps, show allpcpu, alltrace, show alllocks and report here. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 16:49:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01FE0106566B; Thu, 13 Aug 2009 16:49:57 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5F3D08FC16; Thu, 13 Aug 2009 16:49:56 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n7DGnli2029047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 18:49:47 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n7DGnkJj029045; Thu, 13 Aug 2009 18:49:46 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Thu, 13 Aug 2009 18:49:46 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Peter Holm Message-ID: <20090813164946.GL72922@acme.spoerlein.net> Mail-Followup-To: Peter Holm , Alan Cox , current@freebsd.org, Kip Macy References: <20090713181650.GB76464@acme.spoerlein.net> <4A5B7D24.60100@cs.rice.edu> <20090714105245.GR2145@acme.spoerlein.net> <4A82DFBF.5020101@cs.rice.edu> <20090813132907.GA1591@roadrunner.spoerlein.net> <20090813142723.GA62890@x2.osted.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20090813142723.GA62890@x2.osted.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alan Cox , current@freebsd.org, Kip Macy Subject: Re: panic: vm_page_free_toq: freeing mapped page X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:49:57 -0000 On Thu, 13.08.2009 at 16:27:23 +0200, Peter Holm wrote: > On Thu, Aug 13, 2009 at 03:29:07PM +0200, Ulrich Spörlein wrote: > > On Wed, 12.08.2009 at 10:29:03 -0500, Alan Cox wrote: > > > Ulrich Spörlein wrote: > > > > On Mon, 13.07.2009 at 13:29:56 -0500, Alan Cox wrote: > > > >> Ulrich Spörlein wrote: > > > >>> On Mon, 13.07.2009 at 19:15:03 +0200, Ulrich Spörlein wrote: > > > >>>> On Sun, 12.07.2009 at 14:22:23 -0700, Kip Macy wrote: > > > >>>>> On Sun, Jul 12, 2009 at 1:31 PM, Ulrich Spörlein wrote: > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> 8.0 BETA1 @ r195622 will panic reliably when running the clang static > > > >>>>>> analyzer on a buildworld with something like the following panic: > > > >>>>>> > > > >>>>>> panic: vm_page_free_toq: freeing mapped page 0xffffff00c9715b30 > > > >>>>>> cpuid = 1 > > > >>>>>> KDB: stack backtrace: > > > >>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > > > >>>>>> panic() at panic+0x182 > > > >>>>>> vm_page_free_toq() at vm_page_free_toq+0x1f6 > > > >>>>>> vm_object_terminate() at vm_object_terminate+0xb7 > > > >>>>>> vm_object_deallocate() at vm_object_deallocate+0x17a > > > >>>>>> _vm_map_unlock() at _vm_map_unlock+0x70 > > > >>>>>> vm_map_remove() at vm_map_remove+0x6f > > > >>>>>> vmspace_free() at vmspace_free+0x56 > > > >>>>>> vmspace_exec() at vmspace_exec+0x56 > > > >>>>>> exec_new_vmspace() at exec_new_vmspace+0x133 > > > >>>>>> exec_elf32_imgact() at exec_elf32_imgact+0x2ee > > > >>>>>> kern_execve() at kern_execve+0x3b2 > > > >>>>>> execve() at execve+0x3d > > > >>>>>> syscall() at syscall+0x1af > > > >>>>>> Xfast_syscall() at Xfast_syscall+0xe1 > > > >>>>>> --- syscall (59, FreeBSD ELF64, execve), rip = 0x800c20d0c, rsp = 0x7fffffffd6f8, rbp = 0x7fffffffdbf0 --- > > > >>>>>> > > > >>>>>> > > > >>>>> Can you try the following change: > > > >>>>> > > > >>>>> http://svn.freebsd.org/viewvc/base/user/kmacy/releng_7_2_fcs/sys/vm/vm_object.c?r1=192842&r2=195297 > > > >>>>> > > > >>>>> > > > >>>> Applied this to HEAD by hand an ran with it, it died 20-30 minutes into > > > >>>> the scan-build run. So no luck there. Next up is a test using the > > > >>>> GENERIC kernel. > > > >>>> > > > >>> No improvement with a GENERIC kernel. Next up will be to run this with > > > >>> clean sysctl, loader.conf, etc. Then I'll try disabling SMP. > > > >>> > > > >>> Does the backtrace above point to any specific subsystem? I'm using UFS, > > > >>> ZFS and GELI on this machine and could try a few combinations... > > > >>> > > > >> The interesting thing about the backtrace is that it shows a 32-bit i386 > > > >> executable being started on a 64-bit amd64 machine. I've seen this > > > >> backtrace once before, and you'll find it in the PR database. In that > > > >> case, the problem "went away" after the known-to-be-broken > > > >> ZERO_COPY_SOCKETS option was removed from the reporter's kernel > > > >> configuration. However, I don't see that as the culprit here. > > > >> > > > > > > > > Hi Alan, first the bad news > > > > > > > > I ran this test with a GENERIC kernel, SMP disabled, hw.physmem set to 2 > > > > GB in single user mode, so no other processes or deamons running, > > > > nothing special in loader.conf except for ZFS and GELI. It reliably > > > > panics, so nothing new here. > > > > > > > > Now the good news, you may be able to crash your own amd64 box in 3 > > > > minutes by doing: > > > > > > > > mkdir /tmp/foo && cd /tmp/foo > > > > fetch -o- https://www.spoerlein.net/pub/llvm-clang.tar.gz | tar xf - > > > > while :; do for d in bin sbin usr.bin usr.sbin; do $PWD/scan-build -o /dev/null -k make -C /usr/src/$d clean obj depend all; done; done > > > > > > > > Please note that scan-build/ccc-analyzer wont actually do anything, as > > > > they cannot create output in /dev/null. So this is just running the > > > > perl-script and forking make/sh/awk/ccc-analyzer like mad. It does not > > > > survive 3 minutes on my Core2 Duo 3.3 GHz. > > > > > > > > > > Hi Ulrich, > > > > > > I finally got a chance to try this workload. I'm afraid that I can't > > > reproduce the assertion failure on my amd64 test machine. I left the > > > test running overnight, and it was still going strong this morning. > > > > > > I am using neither ZFS nor GELI. Is it possible for you to repeat this > > > test without ZFS and/or GELI? > > > > > > I would also be curious if anyone else reading this message can > > > reproduce the assertion failure with the above test. > > > > Now isn't this great :/ > > > > I haven't tracked the bug for the last couple of weeks, but the system > > was updated to recent HEAD and got its ports rebuild (several times). > > > > I don't know which change "fixed" it, but I think it was the perl > > rebuild (I had some trouble with perl5.10 on 8.0 at first). Besides, the > > process doing the fork in the backtrace was always the perl binary, > > IIRC. > > > > So right now I'm no longer able to reproduce it myself ... > > > > Regards, > > Uli > > Using your test scenario I got the panic. > > - Peter Umm, good news? Anyway, what svn rev? (I'm on r196169) What perl version (5.10.0) do you have running and are you using the latest ports? Something just hit me, there was the grand shlib-version bump in between my last and the current tests. But it seems that none of the bumped libs are required by llvm, they just point to /usr/lib32 and all of these are still at their old version number. Cheers, Uli From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 16:54:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0951B106566C for ; Thu, 13 Aug 2009 16:54:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outV.internet-mail-service.net (outv.internet-mail-service.net [216.240.47.245]) by mx1.freebsd.org (Postfix) with ESMTP id E36D78FC48 for ; Thu, 13 Aug 2009 16:54:04 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 7AB76240D; Thu, 13 Aug 2009 09:54:05 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 1FAFE2D601D; Thu, 13 Aug 2009 09:54:04 -0700 (PDT) Message-ID: <4A84452B.4070306@elischer.org> Date: Thu, 13 Aug 2009 09:54:03 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andrew Thompson References: <20090813073002.GA66860@citylink.fud.org.nz> In-Reply-To: <20090813073002.GA66860@citylink.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 16:54:05 -0000 Andrew Thompson wrote: > Hi, > > > Here is an aesthetic patch to change the usb kernel processes to threads, > this hides them from the usual 'ps' output. Please test and review. > > 1290 ?? DL 0:00.00 [usbus0] > [lots and lots more...] > 1309 ?? DL 0:00.00 [usbus4] > > After the patch they can be seen as kernel threads. > > PID TID COMM TDNAME CPU PRI STATE WCHAN > 0 100000 kernel swapper 0 68 sleep sched > 0 100009 kernel firmware taskq 0 92 sleep - > 0 100020 kernel kqueue taskq 0 92 sleep - > 0 100021 kernel acpi_task_0 0 92 sleep - > 0 100022 kernel acpi_task_1 0 92 sleep - > 0 100023 kernel acpi_task_2 0 92 sleep - > 0 100027 kernel thread taskq 0 92 sleep - > 0 100031 kernel bwi0 taskq 0 16 sleep - > 0 100032 kernel bwi0 taskq 0 16 sleep - > 0 100106 kernel usbus0 0 20 sleep wmsg > 0 100107 kernel usbus0 0 16 sleep wmsg > 0 100108 kernel usbus0 0 20 sleep wmsg > 0 100109 kernel usbus0 0 20 sleep wmsg > [ ... ] > 0 100127 kernel usbus4 0 20 sleep wmsg > > > Andrew use kproc_kthread_add() to create a seoarate usb process and make all the threads belong to that process. (kproc_kthread_add() will create a new process the first time and add more threads to it the more it is run.) > > > > Index: dev/usb/usb_process.c > =================================================================== > --- dev/usb/usb_process.c (revision 196086) > +++ dev/usb/usb_process.c (working copy) > @@ -64,9 +64,9 @@ > > #if (__FreeBSD_version >= 800000) > #define USB_THREAD_CREATE(f, s, p, ...) \ > - kproc_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) > -#define USB_THREAD_SUSPEND(p) kproc_suspend(p,0) > -#define USB_THREAD_EXIT(err) kproc_exit(err) > + kthread_add((f), (s), NULL, (p), 0, 0, __VA_ARGS__) > +#define USB_THREAD_SUSPEND(p) kthread_suspend(p,0) > +#define USB_THREAD_EXIT(err) kthread_exit() > #else > #define USB_THREAD_CREATE(f, s, p, ...) \ > kthread_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) > Index: dev/usb/usb_process.h > =================================================================== > --- dev/usb/usb_process.h (revision 196086) > +++ dev/usb/usb_process.h (working copy) > @@ -49,7 +49,7 @@ struct usb_process { > struct cv up_cv; > struct cv up_drain; > > - struct proc *up_ptr; > + struct thread *up_ptr; > struct thread *up_curtd; > struct mtx *up_mtx; > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 17:03:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79E1F1065691 for ; Thu, 13 Aug 2009 17:03:11 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 909518FC52 for ; Thu, 13 Aug 2009 17:03:10 +0000 (UTC) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 251514794; Thu, 13 Aug 2009 20:03:05 +0300 Message-ID: <4A84470B.6040507@FreeBSD.org> Date: Thu, 13 Aug 2009 20:02:03 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Ilya Zhuravlev References: <4A4517BE.9040504@FreeBSD.org> <4A6EBAFC.6090800@cbtnet.ru> <4A709323.6050001@FreeBSD.org> <4A7AB52B.5000300@cbtnet.ru> <4A7AEF07.2040906@FreeBSD.org> <4A8406E1.5070905@cbtnet.ru> In-Reply-To: <4A8406E1.5070905@cbtnet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 17:03:11 -0000 Ilya Zhuravlev wrote: > Alexander Motin wrote: >> Ilya Zhuravlev wrote: >>> Alexander Motin wrote: >>>> Ilya Zhuravlev wrote: >>>> >>>>> ahci cannot attach drives >>>>> 8.0-beta2, laptop asus k50in, nvidia MCP75L-based >>>>> >>>>> ahci0: [THREAD] >>>>> ahci0: AHCI v1.20 with 2 3Gbps ports, Port Multiplier supported >>>>> ahcich0: at channel 0 on ahci0 >>>>> ahcich0: [THREAD] >>>>> ahcich1: at channel 1 on ahci0 >>>>> ahcich1: [THREAD] >>>>> ...... >>>>> (aprobe0:ahcich0:0:15:0): SIGNATURE: 0000 >>>>> (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 >>>>> (aprobe0:ahcich0:0:0:0): Uncorrected Parity Error >>>>> (aprobe0:ahcich0:0:0:0): Retrying Command >>>>> (aprobe0:ahcich0:0:0:0): Uncoreccted Parity Error >>>>> (aprobe0:ahcich0:0:0:0): error 5 >>>>> (aprobe0:ahcich0:0:0:0): Retries Exhausted >>>>> (aprobe1:ahcich1:0:15:0): SIGNATURE: eb14 >>>>> (aprobe0:ahcich1:0:0:0): SIGNATURE: eb14 >>>>> (aprobe0:ahcich1:0:0:0): Uncoreccted Parity Error >>>>> (aprobe0:ahcich1:0:0:0): Retrying Command >>>>> (aprobe0:ahcich1:0:0:0): Uncoreccted Parity Error >>>>> (aprobe0:ahcich1:0:0:0): error 5 >>>>> (aprobe0:ahcich1:0:0:0): Retries Exhausted >>>>> >>>> Try please to uncomment device_printf() lines inside ahci_ch_intr() >>>> function. It could give some ideas about what's going on there. >>>> >>> Sorry for long delay. >>> boot -v, pciconf attached >>> >> >> I don't see that you've uncommented >> //device_printf(dev, "%s ERROR is %08x cs %08x... >> lines in ahci_ch_intr() and rebuilt kernel as I've said. >> >> > Ehm, sorry, svn upping after edit was bad idea Try this please: http://p4db.freebsd.org/chv.cgi?CH=167141 -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 17:37:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EF6106566C; Thu, 13 Aug 2009 17:37:24 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay2-v.mail.gandi.net (relay2-v.mail.gandi.net [217.70.178.76]) by mx1.freebsd.org (Postfix) with ESMTP id 466408FC4A; Thu, 13 Aug 2009 17:37:23 +0000 (UTC) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.226]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id AAB4F135D0; Thu, 13 Aug 2009 19:37:15 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 9273CF0A2; Thu, 13 Aug 2009 13:36:28 -0400 (EDT) Date: Thu, 13 Aug 2009 13:36:28 -0400 From: Damian Gerow To: Attilio Rao Message-ID: <20090813173627.GA1498@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Robert Noland Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 17:37:24 -0000 Attilio Rao wrote: : So, what you can do is to compile a kernel with the following options: : KDB, DDB, INVARIANT_SUPPORT, INVARIANTS, WITNESS As I'm running GENERIC, these options are already present. : when you get the deadlock, you should break in DDB. : Through a textdump(4) (or serial console or whatever you prefer) you : should get the following informations: : bt, ps, show allpcpu, alltrace, show alllocks : : and report here. I've set ddb script kdb.enter.default="textdump set; capture on; show allpcpu; bt; ps; alltrace; showalllocks; showalllock; call doadump; reset", as I don't have a serial console on this machine (and my USB<->serial adapter doesn't work on FreeBSD). The script does not run when resuming in graphics mode, unfortunately. Try as I might, I just don't get anything. I'm not sure what exactly the system is doing when it resumes, as attempts to create files on the local fs seem to fail. Resuming in text mode does generate a panic. I've included the requested information below. However, this may be a red herring: I've never been able to resume in text mode, so it is possible these two resume problems are unrelated. Note that the below was generated on r196037. I'm currently building an 8-STABLE for further testing. ----- begin msgbuf.txt <5>em0: link state changed to DOWN usbus7: port reset timeout uhub_reattach_port:373: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:463: device problem (USB_ERR_TIMEOUT), disabling port 1 calcru: runtime went backwards from 219239654 usec to 74088058 usec for pid 11 (idle) <5>em0: link state changed to UP ugen1.2: at usbus1 (disconnected) Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff8048e71b stack pointer = 0x28:0xffffff8072d59ad0 frame pointer = 0x28:0xffffff8072d59b20 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 22 (usbus1) ----- end msgbuf.txt ----- begin ddb.txt db:0:kdb.enter.default> show allpcpu Current CPU: 0 cpuid = 0 dynamic pcpu = 0x53d514 curthread = 0xffffff0003567720: pid 22 "usbus1" curpcb = 0xffffff8072d59d40 fpcurthread = none idlethread = 0xffffff00024e6390: pid 11 "idle: cpu0" curpmap = 0 tssp = 0xffffffff80de7300 commontssp = 0xffffffff80de7300 rsp0 = 0xffffff8072d59d40 gs32p = 0xffffffff80de6138 ldt = 0xffffffff80de6178 tss = 0xffffffff80de6168 spin locks held: cpuid = 1 dynamic pcpu = 0xffffff807f484514 curthread = 0xffffff000b46d390: pid 1372 "hald" curpcb = 0xffffff80755e4d40 fpcurthread = none idlethread = 0xffffff00024e6720: pid 11 "idle: cpu1" curpmap = 0 tssp = 0xffffffff80de7368 commontssp = 0xffffffff80de7368 rsp0 = 0xffffff80755e4d40 gs32p = 0xffffffff80de61a0 ldt = 0xffffffff80de61e0 tss = 0xffffffff80de61d0 spin locks held: db:0:kdb.enter.default> bt Tracing pid 22 tid 100047 td 0xffffff0003567720 usb_unconfigure() at usb_unconfigure+0x267 usb_free_device() at usb_free_device+0x1bc uhub_explore() at uhub_explore+0x2a3 usb_bus_explore() at usb_bus_explore+0x9e usb_process() at usb_process+0xcd fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072d59d30, rbp = 0 --- db:0:kdb.enter.default> ps pid ppid pgrp uid state wmesg wchan cmd 1424 1416 653 0 R acpiconf 1416 653 653 0 S wait 0xffffff0003d63460 sh 1411 1360 1411 1001 S+ ttyin 0xffffff00035010a8 zsh 1381 1376 1372 0 S select 0xffffff000b5ea540 initial thread 1376 1372 1372 0 S select 0xffffff000b0bee40 initial thread 1375 1 1375 0 Ss (threaded) console-kit-daemon 100206 S waitvt 0xffffffff80bd7438 console-kit-daemon 100205 S waitvt 0xffffffff80bd7430 console-kit-daemon 100204 S waitvt 0xffffffff80bd7428 console-kit-daemon 100203 S waitvt 0xffffffff80bd7420 console-kit-daemon 100202 S waitvt 0xffffffff80bd7418 console-kit-daemon 100201 S waitvt 0xffffffff80bd7410 console-kit-daemon 100200 S waitvt 0xffffffff80bd7408 console-kit-daemon 100199 S waitvt 0xffffffff80bd7400 console-kit-daemon 100198 S waitvt 0xffffffff80bd73f8 console-kit-daemon 100197 S waitvt 0xffffffff80bd73f0 console-kit-daemon 100196 S waitvt 0xffffffff80bd73e8 console-kit-daemon 100195 S waitvt 0xffffffff80bd73e0 console-kit-daemon 100194 S waitvt 0xffffffff80bd73d8 console-kit-daemon 100193 S waitvt 0xffffffff80bd73d0 console-kit-daemon 100192 S waitvt 0xffffffff80bd73c8 console-kit-daemon 100191 S ucond 0xffffff0003870980 console-kit-daemon 100126 S select 0xffffff0003dfda40 console-kit-daemon 1372 1 1372 560 Rs CPU 1 hald 1367 1 1367 0 Ss+ ttyin 0xffffff00033318a8 getty 1366 1 1366 0 Ss+ ttyin 0xffffff00034fd8a8 getty 1365 1 1365 0 Ss+ ttyin 0xffffff00034fe4a8 getty 1364 1 1364 0 Ss+ ttyin 0xffffff00035000a8 getty 1363 1 1363 0 Ss+ ttyin 0xffffff00034fd0a8 getty 1362 1 1362 0 Ss+ ttyin 0xffffff0003500ca8 getty 1361 1 1361 0 Ss+ ttyin 0xffffff00035008a8 getty 1360 1 1360 0 Ss+ wait 0xffffff000b416460 login 1358 1356 292 0 S+ nanslp 0xffffffff80bdc5e8 sleep 1357 1 292 0 S+ piperd 0xffffff00039dc5b0 logger 1356 1 292 0 S+ wait 0xffffff0003f738c0 sh 1304 1 1304 0 Ss nanslp 0xffffffff80bdc5e8 cron 1295 1 1295 0 Ss select 0xffffff000b22c2c0 sshd 1252 1 1252 556 Ss select 0xffffff000b0da9c0 dbus-daemon 1247 1236 1236 125 S kqread 0xffffff000b240b00 qmgr 1245 1236 1236 125 S kqread 0xffffff000b3ac000 pickup 1236 1 1236 0 Ss kqread 0xffffff000b37b700 master 1117 1 1117 65 Ss select 0xffffff000b0e8940 dhclient 1101 1 1101 0 Ss select 0xffffff000b0ead40 dhclient 1077 1 1077 0 Ss kqread 0xffffff0003ff4500 cupsd 1034 1 1034 0 Ss select 0xffffff0003e76840 powerd 961 1 961 0 Ss rpcsvc 0xffffff0003d8b1a0 NLM: master 948 1 948 0 Ss select 0xffffff000b009540 rpc.statd 946 1 946 0 Ss select 0xffffff0003e774c0 rpcbind 872 0 0 0 SL mdwait 0xffffff0003e9d800 [md0] 823 1 823 0 Ss select 0xffffff0003e76e40 syslogd 726 0 0 0 SL - 0xffffffff80bd9640 [accounting] 653 1 653 0 Ss wait 0xffffff0003f75000 devd 285 0 0 0 SL tq->tq_d 0xffffff0003ae3720 [zil_clean] 284 0 0 0 SL tq->tq_d 0xffffff0003a70840 [zil_clean] 283 0 0 0 SL tq->tq_d 0xffffff0003ae32a0 [zil_clean] 282 0 0 0 SL tq->tq_d 0xffffff0003ae3180 [zil_clean] 281 0 0 0 SL tq->tq_d 0xffffff0003ae3060 [zil_clean] 280 0 0 0 SL tq->tq_d 0xffffff0003ae3840 [zil_clean] 279 0 0 0 SL tq->tq_d 0xffffff0003a71840 [zil_clean] 278 0 0 0 SL tq->tq_d 0xffffff0003a71720 [zil_clean] 277 0 0 0 SL tq->tq_d 0xffffff0003a71600 [zil_clean] 276 0 0 0 SL tq->tq_d 0xffffff0003a714e0 [zil_clean] 275 0 0 0 SL tx->tx_s 0xffffff000365b638 [txg_thread_enter] 274 0 0 0 SL tx->tx_q 0xffffff000365b658 [txg_thread_enter] 273 0 0 0 SL vgeom:io 0xffffff0003acfc90 [vdev:worker ad4s1d.] 272 0 0 0 SL tq->tq_d 0xffffff0003a713c0 [spa_zio] 271 0 0 0 SL tq->tq_d 0xffffff0003a712a0 [spa_zio] 270 0 0 0 SL tq->tq_d 0xffffff0003a71180 [spa_zio] 269 0 0 0 SL tq->tq_d 0xffffff0003a71de0 [spa_zio] 268 0 0 0 SL tq->tq_d 0xffffff0003af32a0 [spa_zio] 267 0 0 0 SL tq->tq_d 0xffffff0003af3180 [spa_zio] 266 0 0 0 SL tq->tq_d 0xffffff0003af3060 [spa_zio] 265 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 264 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 263 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 262 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 261 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 260 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 259 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 258 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] 257 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 256 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 255 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 254 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 253 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 252 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 251 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 250 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] 249 0 0 0 SL tq->tq_d 0xffffff0003ae3ba0 [spa_zio] 248 0 0 0 SL tq->tq_d 0xffffff0003ae3a80 [spa_zio] 247 0 0 0 SL tq->tq_d 0xffffff0003ae3960 [spa_zio] 192 0 0 0 SL geli:w 0xffffff0003649400 [g_eli[1] ad4s1d] 191 0 0 0 SL geli:w 0xffffff0003649400 [g_eli[0] ad4s1d] 186 0 0 0 SL crypto_r 0xffffffff813398a0 [crypto returns] 185 0 0 0 SL crypto_w 0xffffffff81339860 [crypto] 75 0 0 0 SL l2arc_fe 0xffffffff8130be80 [l2arc_feed_thread] 74 0 0 0 SL arc_recl 0xffffffff813038a0 [arc_reclaim_thread] 72 0 0 0 SL vacv 0xffffffff813025a0 [vaclean] 71 0 0 0 SL tq->tq_d 0xffffff0003a71060 [system_taskq] 70 0 0 0 SL tq->tq_d 0xffffff0003a71060 [system_taskq] 52 0 0 0 SL flowclea 0xffffffff80bdc2c4 [flowcleaner] 51 0 0 0 SL sdflush 0xffffffff80dacd58 [softdepflush] 50 0 0 0 SL syncer 0xffffffff80d9dbc0 [syncer] 49 0 0 0 SL vlruwt 0xffffff000358a000 [vnlru] 48 0 0 0 SL psleep 0xffffffff80d9d6e8 [bufdaemon] 9 0 0 0 SL pgzero 0xffffffff80dae7ac [pagezero] 8 0 0 0 SL psleep 0xffffffff80dadb48 [vmdaemon] 7 0 0 0 SL psleep 0xffffffff80dadb0c [pagedaemon] 47 0 0 0 SL wmsg 0xffffff8000326dd0 [usbus7] 46 0 0 0 SL wmsg 0xffffff8000326d78 [usbus7] 45 0 0 0 SL wmsg 0xffffff8000326d20 [usbus7] 44 0 0 0 SL wmsg 0xffffff8000326cc8 [usbus7] 43 0 0 0 SL wmsg 0xffffff800031def0 [usbus6] 42 0 0 0 SL wmsg 0xffffff800031de98 [usbus6] 41 0 0 0 SL wmsg 0xffffff800031de40 [usbus6] 40 0 0 0 SL wmsg 0xffffff800031dde8 [usbus6] 39 0 0 0 SL wmsg 0xffffff8000314ef0 [usbus5] 38 0 0 0 SL wmsg 0xffffff8000314e98 [usbus5] 37 0 0 0 SL wmsg 0xffffff8000314e40 [usbus5] 36 0 0 0 SL wmsg 0xffffff8000314de8 [usbus5] 35 0 0 0 SL wmsg 0xffffff800030bef0 [usbus4] 34 0 0 0 SL wmsg 0xffffff800030be98 [usbus4] 33 0 0 0 SL wmsg 0xffffff800030be40 [usbus4] 32 0 0 0 SL wmsg 0xffffff800030bde8 [usbus4] 31 0 0 0 SL wmsg 0xffffff8000302dd0 [usbus3] 30 0 0 0 SL wmsg 0xffffff8000302d78 [usbus3] 29 0 0 0 SL wmsg 0xffffff8000302d20 [usbus3] 28 0 0 0 SL wmsg 0xffffff8000302cc8 [usbus3] 27 0 0 0 SL wmsg 0xffffff80002f9ef0 [usbus2] 26 0 0 0 SL wmsg 0xffffff80002f9e98 [usbus2] 25 0 0 0 SL wmsg 0xffffff80002f9e40 [usbus2] 24 0 0 0 SL wmsg 0xffffff80002f9de8 [usbus2] 23 0 0 0 SL wmsg 0xffffff80002f0ef0 [usbus1] 22 0 0 0 RL CPU 0 [usbus1] 21 0 0 0 SL wmsg 0xffffff80002f0e40 [usbus1] 20 0 0 0 SL wmsg 0xffffff80002f0de8 [usbus1] 19 0 0 0 SL wmsg 0xffffff80002e7ef0 [usbus0] 18 0 0 0 SL wmsg 0xffffff80002e7e98 [usbus0] 17 0 0 0 SL wmsg 0xffffff80002e7e40 [usbus0] 16 0 0 0 SL wmsg 0xffffff80002e7de8 [usbus0] 6 0 0 0 SL waiting_ 0xffffffff80da0ae0 [sctp_iterator] 15 0 0 0 SL cooling 0xffffff0002713558 [acpi_cooling1] 14 0 0 0 RL [acpi_thermal] 5 0 0 0 SL ccb_scan 0xffffffff80ba5560 [xpt_thrd] 13 0 0 0 SL - 0xffffffff80bdc2c4 [yarrow] 4 0 0 0 SL - 0xffffffff80bd8aa8 [g_down] 3 0 0 0 RL [g_up] 2 0 0 0 SL - 0xffffffff80bd8a90 [g_event] 12 0 0 0 WL (threaded) intr 100039 I [irq12: psm0] 100038 I [irq1: atkbd0] 100035 I [irq19: ehci1] 100034 I [irq18: uhci5] 100033 I [irq17: uhci4] 100032 I [irq16: uhci3+] 100031 I [irq257: hdac0] 100030 I [irq23: ehci0+] 100029 I [irq22: uhci2] 100028 I [irq21: uhci1] 100027 I [irq20: uhci0] 100025 I [irq9: acpi0] 100024 I [swi6: task queue] 100023 I [swi6: Giant taskq] 100020 I [swi5: +] 100019 I [swi2: cambio] 100008 I [swi1: netisr 0] 100007 I [swi3: vm] 100006 I [swi4: clock] 100005 I [swi4: clock] 11 0 0 0 RL (threaded) idle 100004 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xffffff00024e38c0 [init] 10 0 0 0 SL audit_wo 0xffffffff80dac0b0 [audit] 0 0 0 0 SLs (threaded) kernel 100026 D - 0xffffff0002711d80 [em0 taskq] 100022 D - 0xffffff0002621980 [aiod_bio taskq] 100021 D - 0xffffff0002621a00 [thread taskq] 100017 D - 0xffffff0002647380 [kqueue taskq] 100016 D - 0xffffff0002647400 [acpi_task_2] 100015 D - 0xffffff0002647400 [acpi_task_1] 100014 D ecgpe 0xffffff00026badf0 [acpi_task_0] 100012 D - 0xffffff00024f7780 [firmware taskq] 100000 D sched 0xffffffff80bd8ba0 [swapper] db:0:kdb.enter.default> alltrace Tracing command acpiconf pid 1424 tid 100177 td 0xffffff0003f86720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 ast() at ast+0x27d doreti_ast() at doreti_ast+0x1f Tracing command sh pid 1416 tid 100154 td 0xffffff0003d90390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe988, rbp = 0x28d --- Tracing command zsh pid 1411 tid 100179 td 0xffffff0003f86000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x800bea14c, rsp = 0x7fffffffe768, rbp = 0 --- Tracing command hald-addon-mouse-sy pid 1381 tid 100164 td 0xffffff0003afeab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800e0d4dc, rsp = 0x7fffffffe6a8, rbp = 0x80161d100 --- Tracing command hald-runner pid 1376 tid 100159 td 0xffffff0003d8f000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800c0d4dc, rsp = 0x7fffffffeb68, rbp = 0x1 --- Tracing command console-kit-daemon pid 1375 tid 100206 td 0xffffff000b4f8720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffafff38, rbp = 0x10 --- Tracing command console-kit-daemon pid 1375 tid 100205 td 0xffffff000b4f8ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb10f38, rbp = 0xf --- Tracing command console-kit-daemon pid 1375 tid 100204 td 0xffffff000b4fb000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb21f38, rbp = 0xe --- Tracing command console-kit-daemon pid 1375 tid 100203 td 0xffffff000b4fb390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb32f38, rbp = 0xd --- Tracing command console-kit-daemon pid 1375 tid 100202 td 0xffffff000b4fb720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb43f38, rbp = 0xc --- Tracing command console-kit-daemon pid 1375 tid 100201 td 0xffffff000b4fbab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb54f38, rbp = 0xb --- Tracing command console-kit-daemon pid 1375 tid 100200 td 0xffffff000b4fc000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb65f38, rbp = 0xa --- Tracing command console-kit-daemon pid 1375 tid 100199 td 0xffffff000b4fc390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb76f38, rbp = 0x9 --- Tracing command console-kit-daemon pid 1375 tid 100198 td 0xffffff0003f8b720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb87f38, rbp = 0x8 --- Tracing command console-kit-daemon pid 1375 tid 100197 td 0xffffff0003f8bab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb98f38, rbp = 0x7 --- Tracing command console-kit-daemon pid 1375 tid 100196 td 0xffffff000b46f000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffba9f38, rbp = 0x6 --- Tracing command console-kit-daemon pid 1375 tid 100195 td 0xffffff000b46f390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbbaf38, rbp = 0x5 --- Tracing command console-kit-daemon pid 1375 tid 100194 td 0xffffff000b46f720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbcbf38, rbp = 0x4 --- Tracing command console-kit-daemon pid 1375 tid 100193 td 0xffffff000b46fab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbdcf38, rbp = 0x3 --- Tracing command console-kit-daemon pid 1375 tid 100192 td 0xffffff000b46c000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbedf38, rbp = 0x2 --- Tracing command console-kit-daemon pid 1375 tid 100191 td 0xffffff0003a25ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80143ef0c, rsp = 0x7fffffbfed58, rbp = 0x80186d380 --- Tracing command console-kit-daemon pid 1375 tid 100126 td 0xffffff0003acb390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8015da4dc, rsp = 0x7fffffffeac8, rbp = 0x4 --- Tracing command hald pid 1372 tid 100186 td 0xffffff000b46d390 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x36 trap() at trap+0x42 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8055b213, rsp = 0xffffff8000018fe0, rbp = 0xffffff80755e4970 --- _sx_slock_hard() at _sx_slock_hard+0x13c _sx_slock() at _sx_slock+0xaa newbus_slock() at newbus_slock+0x21 acpi_battery_ioctl() at acpi_battery_ioctl+0x6f acpiioctl() at acpiioctl+0x163 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8012370ec, rsp = 0x7fffffffe598, rbp = 0x801a0ab60 --- Tracing command getty pid 1367 tid 100184 td 0xffffff000b46dab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 1366 tid 100178 td 0xffffff0003f86390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 1365 tid 100183 td 0xffffff000b468000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 1364 tid 100182 td 0xffffff000b468390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 1363 tid 100181 td 0xffffff0003d92720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 1362 tid 100180 td 0xffffff0003d92ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 1361 tid 100094 td 0xffffff0003a28ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command login pid 1360 tid 100188 td 0xffffff000b46cab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x8009e416c, rsp = 0x7fffffffec58, rbp = 0x800b969c0 --- Tracing command sleep pid 1358 tid 100089 td 0xffffff00037aeab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 kern_nanosleep() at kern_nanosleep+0xec nanosleep() at nanosleep+0x61 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800710cfc, rsp = 0x7fffffffed58, rbp = 0x7fffffffedb0 --- Tracing command logger pid 1357 tid 100170 td 0xffffff0003f8a390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 pipe_read() at pipe_read+0x3ce dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80072e14c, rsp = 0x7fffffffe858, rbp = 0x7fffffffed78 --- Tracing command sh pid 1356 tid 100167 td 0xffffff0003f8b000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffccb8, rbp = 0x124 --- Tracing command cron pid 1304 tid 100176 td 0xffffff0003f86ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 kern_nanosleep() at kern_nanosleep+0xec nanosleep() at nanosleep+0x61 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80092ecfc, rsp = 0x7fffffffeb38, rbp = 0x29 --- Tracing command sshd pid 1295 tid 100169 td 0xffffff0003f8a720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8013b70cc, rsp = 0x7fffffffe318, rbp = 0x4 --- Tracing command dbus-daemon pid 1252 tid 100121 td 0xffffff0003acd720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8009544dc, rsp = 0x7fffffffe6c8, rbp = 0 --- Tracing command qmgr pid 1247 tid 100157 td 0xffffff0003d8f720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x801132c0c, rsp = 0x7fffffffd9e8, rbp = 0x7fffffffd9f0 --- Tracing command pickup pid 1245 tid 100152 td 0xffffff0003d90ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x801126c0c, rsp = 0x7fffffffda28, rbp = 0x7fffffffda30 --- Tracing command master pid 1236 tid 100093 td 0xffffff0003a2a000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x80111dc0c, rsp = 0x7fffffffdce8, rbp = 0x7fffffffdcf0 --- Tracing command dhclient pid 1117 tid 100162 td 0xffffff0003d8e390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8006eb4dc, rsp = 0x7fffffffece8, rbp = 0x2 --- Tracing command dhclient pid 1101 tid 100166 td 0xffffff0003f8b390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8006eb4dc, rsp = 0x7fffffffece8, rbp = 0x9 --- Tracing command cupsd pid 1077 tid 100132 td 0xffffff0003a94ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x801257c0c, rsp = 0x7fffffffe7d8, rbp = 0x1 --- Tracing command powerd pid 1034 tid 100161 td 0xffffff0003d8e720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x80083d0cc, rsp = 0x7fffffffe7e8, rbp = 0x960 --- Tracing command rpc.lockd pid 961 tid 100171 td 0xffffff0003f8a000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b svc_run_internal() at svc_run_internal+0x2f8 svc_run() at svc_run+0x97 nlm_syscall() at nlm_syscall+0x6f7 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x8008baeac, rsp = 0x7fffffffec38, rbp = 0x7fffffffed60 --- Tracing command rpc.statd pid 948 tid 100122 td 0xffffff0003acd390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8008380cc, rsp = 0x7fffffffeb58, rbp = 0x800980900 --- Tracing command rpcbind pid 946 tid 100168 td 0xffffff0003f8aab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8008fb4dc, rsp = 0x7fffffffcad8, rbp = 0x800b100c0 --- Tracing command md0 pid 872 tid 100090 td 0xffffff0003a2a390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _sleep() at _sleep+0x348 md_kthread() at md_kthread+0x10c fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075400d30, rbp = 0 --- Tracing command syslogd pid 823 tid 100174 td 0xffffff0003f87390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8008430cc, rsp = 0x7fffffffdd08, rbp = 0x800a2f0d0 --- Tracing command accounting pid 726 tid 100103 td 0xffffff0003a94000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_timedwait() at sleepq_timedwait+0x6d _sleep() at _sleep+0x322 acct_thread() at acct_thread+0x2b2 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075441d30, rbp = 0 --- Tracing command devd pid 653 tid 100163 td 0xffffff0003d8e000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x4215ec, rsp = 0x7fffffffe778, rbp = 0x8006640d8 --- Tracing command zil_clean pid 285 tid 100092 td 0xffffff00037ae390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807540ad30, rbp = 0 --- Tracing command zil_clean pid 284 tid 100151 td 0xffffff0003d92000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075535d30, rbp = 0 --- Tracing command zil_clean pid 283 tid 100150 td 0xffffff0003d92390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075530d30, rbp = 0 --- Tracing command zil_clean pid 282 tid 100149 td 0xffffff0003ace720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807552bd30, rbp = 0 --- Tracing command zil_clean pid 281 tid 100148 td 0xffffff0003aceab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075526d30, rbp = 0 --- Tracing command zil_clean pid 280 tid 100147 td 0xffffff0003a4f000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075521d30, rbp = 0 --- Tracing command zil_clean pid 279 tid 100146 td 0xffffff0003a4f390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807551cd30, rbp = 0 --- Tracing command zil_clean pid 278 tid 100145 td 0xffffff0003a4f720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075517d30, rbp = 0 --- Tracing command zil_clean pid 277 tid 100144 td 0xffffff0003a4fab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075512d30, rbp = 0 --- Tracing command zil_clean pid 276 tid 100143 td 0xffffff0003af8000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _cv_wait() at _cv_wait+0x239 taskq_thread() at taskq_thread+0x379 fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807550dd30, rbp = 0 --- Tracing command txg_thread_enter pid 275 tid 100134 td 0xffffff0003afe390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_timedwai ----- end ddb.txt From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 17:42:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BE45106564A for ; Thu, 13 Aug 2009 17:42:42 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 7911B8FC47 for ; Thu, 13 Aug 2009 17:42:41 +0000 (UTC) Received: from [192.168.1.4] (adsl-157-61-83.bna.bellsouth.net [70.157.61.83]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n7DHgW2k089087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2009 13:42:33 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Damian Gerow In-Reply-To: <20090813173627.GA1498@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> Content-Type: text/plain Organization: FreeBSD Date: Thu, 13 Aug 2009 12:42:26 -0500 Message-Id: <1250185346.33905.2.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 17:42:42 -0000 On Thu, 2009-08-13 at 13:36 -0400, Damian Gerow wrote: > Attilio Rao wrote: > : So, what you can do is to compile a kernel with the following options: > : KDB, DDB, INVARIANT_SUPPORT, INVARIANTS, WITNESS > > As I'm running GENERIC, these options are already present. > > : when you get the deadlock, you should break in DDB. > : Through a textdump(4) (or serial console or whatever you prefer) you > : should get the following informations: > : bt, ps, show allpcpu, alltrace, show alllocks > : > : and report here. > > I've set ddb script kdb.enter.default="textdump set; capture on; show > allpcpu; bt; ps; alltrace; showalllocks; showalllock; call doadump; reset", > as I don't have a serial console on this machine (and my USB<->serial > adapter doesn't work on FreeBSD). > > The script does not run when resuming in graphics mode, unfortunately. > Try as I might, I just don't get anything. I'm not sure what exactly > the system is doing when it resumes, as attempts to create files on > the local fs seem to fail. > > Resuming in text mode does generate a panic. I've included the requested > information below. However, this may be a red herring: I've never been > able to resume in text mode, so it is possible these two resume problems > are unrelated. Manually kldload i915.ko when in text mode. As long as it is loaded, it should manage the hardware during suspend/resume. Meaning that you don't need to be in X for it to do it's thing... robert. > Note that the below was generated on r196037. I'm currently building an > 8-STABLE for further testing. > > ----- begin msgbuf.txt > > > <5>em0: link state changed to DOWN > usbus7: port reset timeout > uhub_reattach_port:373: port 1 reset failed, error=USB_ERR_TIMEOUT > uhub_reattach_port:463: device problem (USB_ERR_TIMEOUT), disabling port 1 > calcru: runtime went backwards from 219239654 usec to 74088058 usec for pid > 11 (idle) > <5>em0: link state changed to UP > ugen1.2: at usbus1 (disconnected) > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff8048e71b > stack pointer = 0x28:0xffffff8072d59ad0 > frame pointer = 0x28:0xffffff8072d59b20 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 22 (usbus1) > ----- end msgbuf.txt > > ----- begin ddb.txt > db:0:kdb.enter.default> show allpcpu > Current CPU: 0 > > cpuid = 0 > dynamic pcpu = 0x53d514 > curthread = 0xffffff0003567720: pid 22 "usbus1" > curpcb = 0xffffff8072d59d40 > fpcurthread = none > idlethread = 0xffffff00024e6390: pid 11 "idle: cpu0" > curpmap = 0 > tssp = 0xffffffff80de7300 > commontssp = 0xffffffff80de7300 > rsp0 = 0xffffff8072d59d40 > gs32p = 0xffffffff80de6138 > ldt = 0xffffffff80de6178 > tss = 0xffffffff80de6168 > spin locks held: > > cpuid = 1 > dynamic pcpu = 0xffffff807f484514 > curthread = 0xffffff000b46d390: pid 1372 "hald" > curpcb = 0xffffff80755e4d40 > fpcurthread = none > idlethread = 0xffffff00024e6720: pid 11 "idle: cpu1" > curpmap = 0 > tssp = 0xffffffff80de7368 > commontssp = 0xffffffff80de7368 > rsp0 = 0xffffff80755e4d40 > gs32p = 0xffffffff80de61a0 > ldt = 0xffffffff80de61e0 > tss = 0xffffffff80de61d0 > spin locks held: > > db:0:kdb.enter.default> bt > Tracing pid 22 tid 100047 td 0xffffff0003567720 > usb_unconfigure() at usb_unconfigure+0x267 > usb_free_device() at usb_free_device+0x1bc > uhub_explore() at uhub_explore+0x2a3 > usb_bus_explore() at usb_bus_explore+0x9e > usb_process() at usb_process+0xcd > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8072d59d30, rbp = 0 --- > db:0:kdb.enter.default> ps > pid ppid pgrp uid state wmesg wchan cmd > 1424 1416 653 0 R acpiconf > 1416 653 653 0 S wait 0xffffff0003d63460 sh > 1411 1360 1411 1001 S+ ttyin 0xffffff00035010a8 zsh > 1381 1376 1372 0 S select 0xffffff000b5ea540 initial thread > 1376 1372 1372 0 S select 0xffffff000b0bee40 initial thread > 1375 1 1375 0 Ss (threaded) console-kit-daemon > 100206 S waitvt 0xffffffff80bd7438 console-kit-daemon > 100205 S waitvt 0xffffffff80bd7430 console-kit-daemon > 100204 S waitvt 0xffffffff80bd7428 console-kit-daemon > 100203 S waitvt 0xffffffff80bd7420 console-kit-daemon > 100202 S waitvt 0xffffffff80bd7418 console-kit-daemon > 100201 S waitvt 0xffffffff80bd7410 console-kit-daemon > 100200 S waitvt 0xffffffff80bd7408 console-kit-daemon > 100199 S waitvt 0xffffffff80bd7400 console-kit-daemon > 100198 S waitvt 0xffffffff80bd73f8 console-kit-daemon > 100197 S waitvt 0xffffffff80bd73f0 console-kit-daemon > 100196 S waitvt 0xffffffff80bd73e8 console-kit-daemon > 100195 S waitvt 0xffffffff80bd73e0 console-kit-daemon > 100194 S waitvt 0xffffffff80bd73d8 console-kit-daemon > 100193 S waitvt 0xffffffff80bd73d0 console-kit-daemon > 100192 S waitvt 0xffffffff80bd73c8 console-kit-daemon > 100191 S ucond 0xffffff0003870980 console-kit-daemon > 100126 S select 0xffffff0003dfda40 console-kit-daemon > 1372 1 1372 560 Rs CPU 1 hald > 1367 1 1367 0 Ss+ ttyin 0xffffff00033318a8 getty > 1366 1 1366 0 Ss+ ttyin 0xffffff00034fd8a8 getty > 1365 1 1365 0 Ss+ ttyin 0xffffff00034fe4a8 getty > 1364 1 1364 0 Ss+ ttyin 0xffffff00035000a8 getty > 1363 1 1363 0 Ss+ ttyin 0xffffff00034fd0a8 getty > 1362 1 1362 0 Ss+ ttyin 0xffffff0003500ca8 getty > 1361 1 1361 0 Ss+ ttyin 0xffffff00035008a8 getty > 1360 1 1360 0 Ss+ wait 0xffffff000b416460 login > 1358 1356 292 0 S+ nanslp 0xffffffff80bdc5e8 sleep > 1357 1 292 0 S+ piperd 0xffffff00039dc5b0 logger > 1356 1 292 0 S+ wait 0xffffff0003f738c0 sh > 1304 1 1304 0 Ss nanslp 0xffffffff80bdc5e8 cron > 1295 1 1295 0 Ss select 0xffffff000b22c2c0 sshd > 1252 1 1252 556 Ss select 0xffffff000b0da9c0 dbus-daemon > 1247 1236 1236 125 S kqread 0xffffff000b240b00 qmgr > 1245 1236 1236 125 S kqread 0xffffff000b3ac000 pickup > 1236 1 1236 0 Ss kqread 0xffffff000b37b700 master > 1117 1 1117 65 Ss select 0xffffff000b0e8940 dhclient > 1101 1 1101 0 Ss select 0xffffff000b0ead40 dhclient > 1077 1 1077 0 Ss kqread 0xffffff0003ff4500 cupsd > 1034 1 1034 0 Ss select 0xffffff0003e76840 powerd > 961 1 961 0 Ss rpcsvc 0xffffff0003d8b1a0 NLM: master > 948 1 948 0 Ss select 0xffffff000b009540 rpc.statd > 946 1 946 0 Ss select 0xffffff0003e774c0 rpcbind > 872 0 0 0 SL mdwait 0xffffff0003e9d800 [md0] > 823 1 823 0 Ss select 0xffffff0003e76e40 syslogd > 726 0 0 0 SL - 0xffffffff80bd9640 [accounting] > 653 1 653 0 Ss wait 0xffffff0003f75000 devd > 285 0 0 0 SL tq->tq_d 0xffffff0003ae3720 [zil_clean] > 284 0 0 0 SL tq->tq_d 0xffffff0003a70840 [zil_clean] > 283 0 0 0 SL tq->tq_d 0xffffff0003ae32a0 [zil_clean] > 282 0 0 0 SL tq->tq_d 0xffffff0003ae3180 [zil_clean] > 281 0 0 0 SL tq->tq_d 0xffffff0003ae3060 [zil_clean] > 280 0 0 0 SL tq->tq_d 0xffffff0003ae3840 [zil_clean] > 279 0 0 0 SL tq->tq_d 0xffffff0003a71840 [zil_clean] > 278 0 0 0 SL tq->tq_d 0xffffff0003a71720 [zil_clean] > 277 0 0 0 SL tq->tq_d 0xffffff0003a71600 [zil_clean] > 276 0 0 0 SL tq->tq_d 0xffffff0003a714e0 [zil_clean] > 275 0 0 0 SL tx->tx_s 0xffffff000365b638 [txg_thread_enter] > 274 0 0 0 SL tx->tx_q 0xffffff000365b658 [txg_thread_enter] > 273 0 0 0 SL vgeom:io 0xffffff0003acfc90 [vdev:worker ad4s1d.] > 272 0 0 0 SL tq->tq_d 0xffffff0003a713c0 [spa_zio] > 271 0 0 0 SL tq->tq_d 0xffffff0003a712a0 [spa_zio] > 270 0 0 0 SL tq->tq_d 0xffffff0003a71180 [spa_zio] > 269 0 0 0 SL tq->tq_d 0xffffff0003a71de0 [spa_zio] > 268 0 0 0 SL tq->tq_d 0xffffff0003af32a0 [spa_zio] > 267 0 0 0 SL tq->tq_d 0xffffff0003af3180 [spa_zio] > 266 0 0 0 SL tq->tq_d 0xffffff0003af3060 [spa_zio] > 265 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 264 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 263 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 262 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 261 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 260 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 259 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 258 0 0 0 SL tq->tq_d 0xffffff0003ae3de0 [spa_zio] > 257 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 256 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 255 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 254 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 253 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 252 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 251 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 250 0 0 0 SL tq->tq_d 0xffffff0003ae3cc0 [spa_zio] > 249 0 0 0 SL tq->tq_d 0xffffff0003ae3ba0 [spa_zio] > 248 0 0 0 SL tq->tq_d 0xffffff0003ae3a80 [spa_zio] > 247 0 0 0 SL tq->tq_d 0xffffff0003ae3960 [spa_zio] > 192 0 0 0 SL geli:w 0xffffff0003649400 [g_eli[1] ad4s1d] > 191 0 0 0 SL geli:w 0xffffff0003649400 [g_eli[0] ad4s1d] > 186 0 0 0 SL crypto_r 0xffffffff813398a0 [crypto returns] > 185 0 0 0 SL crypto_w 0xffffffff81339860 [crypto] > 75 0 0 0 SL l2arc_fe 0xffffffff8130be80 [l2arc_feed_thread] > 74 0 0 0 SL arc_recl 0xffffffff813038a0 [arc_reclaim_thread] > 72 0 0 0 SL vacv 0xffffffff813025a0 [vaclean] > 71 0 0 0 SL tq->tq_d 0xffffff0003a71060 [system_taskq] > 70 0 0 0 SL tq->tq_d 0xffffff0003a71060 [system_taskq] > 52 0 0 0 SL flowclea 0xffffffff80bdc2c4 [flowcleaner] > 51 0 0 0 SL sdflush 0xffffffff80dacd58 [softdepflush] > 50 0 0 0 SL syncer 0xffffffff80d9dbc0 [syncer] > 49 0 0 0 SL vlruwt 0xffffff000358a000 [vnlru] > 48 0 0 0 SL psleep 0xffffffff80d9d6e8 [bufdaemon] > 9 0 0 0 SL pgzero 0xffffffff80dae7ac [pagezero] > 8 0 0 0 SL psleep 0xffffffff80dadb48 [vmdaemon] > 7 0 0 0 SL psleep 0xffffffff80dadb0c [pagedaemon] > 47 0 0 0 SL wmsg 0xffffff8000326dd0 [usbus7] > 46 0 0 0 SL wmsg 0xffffff8000326d78 [usbus7] > 45 0 0 0 SL wmsg 0xffffff8000326d20 [usbus7] > 44 0 0 0 SL wmsg 0xffffff8000326cc8 [usbus7] > 43 0 0 0 SL wmsg 0xffffff800031def0 [usbus6] > 42 0 0 0 SL wmsg 0xffffff800031de98 [usbus6] > 41 0 0 0 SL wmsg 0xffffff800031de40 [usbus6] > 40 0 0 0 SL wmsg 0xffffff800031dde8 [usbus6] > 39 0 0 0 SL wmsg 0xffffff8000314ef0 [usbus5] > 38 0 0 0 SL wmsg 0xffffff8000314e98 [usbus5] > 37 0 0 0 SL wmsg 0xffffff8000314e40 [usbus5] > 36 0 0 0 SL wmsg 0xffffff8000314de8 [usbus5] > 35 0 0 0 SL wmsg 0xffffff800030bef0 [usbus4] > 34 0 0 0 SL wmsg 0xffffff800030be98 [usbus4] > 33 0 0 0 SL wmsg 0xffffff800030be40 [usbus4] > 32 0 0 0 SL wmsg 0xffffff800030bde8 [usbus4] > 31 0 0 0 SL wmsg 0xffffff8000302dd0 [usbus3] > 30 0 0 0 SL wmsg 0xffffff8000302d78 [usbus3] > 29 0 0 0 SL wmsg 0xffffff8000302d20 [usbus3] > 28 0 0 0 SL wmsg 0xffffff8000302cc8 [usbus3] > 27 0 0 0 SL wmsg 0xffffff80002f9ef0 [usbus2] > 26 0 0 0 SL wmsg 0xffffff80002f9e98 [usbus2] > 25 0 0 0 SL wmsg 0xffffff80002f9e40 [usbus2] > 24 0 0 0 SL wmsg 0xffffff80002f9de8 [usbus2] > 23 0 0 0 SL wmsg 0xffffff80002f0ef0 [usbus1] > 22 0 0 0 RL CPU 0 [usbus1] > 21 0 0 0 SL wmsg 0xffffff80002f0e40 [usbus1] > 20 0 0 0 SL wmsg 0xffffff80002f0de8 [usbus1] > 19 0 0 0 SL wmsg 0xffffff80002e7ef0 [usbus0] > 18 0 0 0 SL wmsg 0xffffff80002e7e98 [usbus0] > 17 0 0 0 SL wmsg 0xffffff80002e7e40 [usbus0] > 16 0 0 0 SL wmsg 0xffffff80002e7de8 [usbus0] > 6 0 0 0 SL waiting_ 0xffffffff80da0ae0 [sctp_iterator] > 15 0 0 0 SL cooling 0xffffff0002713558 [acpi_cooling1] > 14 0 0 0 RL [acpi_thermal] > 5 0 0 0 SL ccb_scan 0xffffffff80ba5560 [xpt_thrd] > 13 0 0 0 SL - 0xffffffff80bdc2c4 [yarrow] > 4 0 0 0 SL - 0xffffffff80bd8aa8 [g_down] > 3 0 0 0 RL [g_up] > 2 0 0 0 SL - 0xffffffff80bd8a90 [g_event] > 12 0 0 0 WL (threaded) intr > 100039 I [irq12: psm0] > 100038 I [irq1: atkbd0] > 100035 I [irq19: ehci1] > 100034 I [irq18: uhci5] > 100033 I [irq17: uhci4] > 100032 I [irq16: uhci3+] > 100031 I [irq257: hdac0] > 100030 I [irq23: ehci0+] > 100029 I [irq22: uhci2] > 100028 I [irq21: uhci1] > 100027 I [irq20: uhci0] > 100025 I [irq9: acpi0] > 100024 I [swi6: task queue] > 100023 I [swi6: Giant taskq] > 100020 I [swi5: +] > 100019 I [swi2: cambio] > 100008 I [swi1: netisr 0] > 100007 I [swi3: vm] > 100006 I [swi4: clock] > 100005 I [swi4: clock] > 11 0 0 0 RL (threaded) idle > 100004 CanRun [idle: cpu0] > 100003 CanRun [idle: cpu1] > 1 0 1 0 SLs wait 0xffffff00024e38c0 [init] > 10 0 0 0 SL audit_wo 0xffffffff80dac0b0 [audit] > 0 0 0 0 SLs (threaded) kernel > 100026 D - 0xffffff0002711d80 [em0 taskq] > 100022 D - 0xffffff0002621980 [aiod_bio taskq] > 100021 D - 0xffffff0002621a00 [thread taskq] > 100017 D - 0xffffff0002647380 [kqueue taskq] > 100016 D - 0xffffff0002647400 [acpi_task_2] > 100015 D - 0xffffff0002647400 [acpi_task_1] > 100014 D ecgpe 0xffffff00026badf0 [acpi_task_0] > 100012 D - 0xffffff00024f7780 [firmware taskq] > 100000 D sched 0xffffffff80bd8ba0 [swapper] > db:0:kdb.enter.default> alltrace > > Tracing command acpiconf pid 1424 tid 100177 td 0xffffff0003f86720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > ast() at ast+0x27d > doreti_ast() at doreti_ast+0x1f > > Tracing command sh pid 1416 tid 100154 td 0xffffff0003d90390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > kern_wait() at kern_wait+0xa9e > wait4() at wait4+0x3a > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe988, rbp = 0x28d --- > > Tracing command zsh pid 1411 tid 100179 td 0xffffff0003f86000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x800bea14c, rsp = 0x7fffffffe768, rbp = 0 --- > > Tracing command hald-addon-mouse-sy pid 1381 tid 100164 td 0xffffff0003afeab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _cv_timedwait_sig() at _cv_timedwait_sig+0x24b > seltdwait() at seltdwait+0x73 > poll() at poll+0x325 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (209, FreeBSD ELF64, poll), rip = 0x800e0d4dc, rsp = 0x7fffffffe6a8, rbp = 0x80161d100 --- > > Tracing command hald-runner pid 1376 tid 100159 td 0xffffff0003d8f000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > seltdwait() at seltdwait+0x84 > poll() at poll+0x325 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (209, FreeBSD ELF64, poll), rip = 0x800c0d4dc, rsp = 0x7fffffffeb68, rbp = 0x1 --- > > Tracing command console-kit-daemon pid 1375 tid 100206 td 0xffffff000b4f8720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffafff38, rbp = 0x10 --- > > Tracing command console-kit-daemon pid 1375 tid 100205 td 0xffffff000b4f8ab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb10f38, rbp = 0xf --- > > Tracing command console-kit-daemon pid 1375 tid 100204 td 0xffffff000b4fb000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb21f38, rbp = 0xe --- > > Tracing command console-kit-daemon pid 1375 tid 100203 td 0xffffff000b4fb390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb32f38, rbp = 0xd --- > > Tracing command console-kit-daemon pid 1375 tid 100202 td 0xffffff000b4fb720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb43f38, rbp = 0xc --- > > Tracing command console-kit-daemon pid 1375 tid 100201 td 0xffffff000b4fbab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb54f38, rbp = 0xb --- > > Tracing command console-kit-daemon pid 1375 tid 100200 td 0xffffff000b4fc000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb65f38, rbp = 0xa --- > > Tracing command console-kit-daemon pid 1375 tid 100199 td 0xffffff000b4fc390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb76f38, rbp = 0x9 --- > > Tracing command console-kit-daemon pid 1375 tid 100198 td 0xffffff0003f8b720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb87f38, rbp = 0x8 --- > > Tracing command console-kit-daemon pid 1375 tid 100197 td 0xffffff0003f8bab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb98f38, rbp = 0x7 --- > > Tracing command console-kit-daemon pid 1375 tid 100196 td 0xffffff000b46f000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffba9f38, rbp = 0x6 --- > > Tracing command console-kit-daemon pid 1375 tid 100195 td 0xffffff000b46f390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbbaf38, rbp = 0x5 --- > > Tracing command console-kit-daemon pid 1375 tid 100194 td 0xffffff000b46f720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbcbf38, rbp = 0x4 --- > > Tracing command console-kit-daemon pid 1375 tid 100193 td 0xffffff000b46fab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbdcf38, rbp = 0x3 --- > > Tracing command console-kit-daemon pid 1375 tid 100192 td 0xffffff000b46c000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > sctty_ioctl() at sctty_ioctl+0xe13 > tty_ioctl() at tty_ioctl+0xaa > ttydev_ioctl() at ttydev_ioctl+0x99 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbedf38, rbp = 0x2 --- > > Tracing command console-kit-daemon pid 1375 tid 100191 td 0xffffff0003a25ab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > do_cv_wait() at do_cv_wait+0x4e1 > __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 > _umtx_op() at _umtx_op+0x1c > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80143ef0c, rsp = 0x7fffffbfed58, rbp = 0x80186d380 --- > > Tracing command console-kit-daemon pid 1375 tid 100126 td 0xffffff0003acb390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > seltdwait() at seltdwait+0x84 > poll() at poll+0x325 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (209, FreeBSD ELF64, poll), rip = 0x8015da4dc, rsp = 0x7fffffffeac8, rbp = 0x4 --- > > Tracing command hald pid 1372 tid 100186 td 0xffffff000b46d390 > cpustop_handler() at cpustop_handler+0x40 > ipi_nmi_handler() at ipi_nmi_handler+0x36 > trap() at trap+0x42 > nmi_calltrap() at nmi_calltrap+0x8 > --- trap 0x13, rip = 0xffffffff8055b213, rsp = 0xffffff8000018fe0, rbp = 0xffffff80755e4970 --- > _sx_slock_hard() at _sx_slock_hard+0x13c > _sx_slock() at _sx_slock+0xaa > newbus_slock() at newbus_slock+0x21 > acpi_battery_ioctl() at acpi_battery_ioctl+0x6f > acpiioctl() at acpiioctl+0x163 > devfs_ioctl_f() at devfs_ioctl_f+0xde > kern_ioctl() at kern_ioctl+0x1e4 > ioctl() at ioctl+0x158 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8012370ec, rsp = 0x7fffffffe598, rbp = 0x801a0ab60 --- > > Tracing command getty pid 1367 tid 100184 td 0xffffff000b46dab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- > > Tracing command getty pid 1366 tid 100178 td 0xffffff0003f86390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- > > Tracing command getty pid 1365 tid 100183 td 0xffffff000b468000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- > > Tracing command getty pid 1364 tid 100182 td 0xffffff000b468390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- > > Tracing command getty pid 1363 tid 100181 td 0xffffff0003d92720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- > > Tracing command getty pid 1362 tid 100180 td 0xffffff0003d92ab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- > > Tracing command getty pid 1361 tid 100094 td 0xffffff0003a28ab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > tty_wait() at tty_wait+0x65 > ttydisc_read() at ttydisc_read+0x220 > ttydev_read() at ttydev_read+0x86 > devfs_read_f() at devfs_read_f+0x7f > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- > > Tracing command login pid 1360 tid 100188 td 0xffffff000b46cab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > kern_wait() at kern_wait+0xa9e > wait4() at wait4+0x3a > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (7, FreeBSD ELF64, wait4), rip = 0x8009e416c, rsp = 0x7fffffffec58, rbp = 0x800b969c0 --- > > Tracing command sleep pid 1358 tid 100089 td 0xffffff00037aeab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _sleep() at _sleep+0x312 > kern_nanosleep() at kern_nanosleep+0xec > nanosleep() at nanosleep+0x61 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x800710cfc, rsp = 0x7fffffffed58, rbp = 0x7fffffffedb0 --- > > Tracing command logger pid 1357 tid 100170 td 0xffffff0003f8a390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > pipe_read() at pipe_read+0x3ce > dofileread() at dofileread+0x97 > kern_readv() at kern_readv+0x46 > read() at read+0x4e > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (3, FreeBSD ELF64, read), rip = 0x80072e14c, rsp = 0x7fffffffe858, rbp = 0x7fffffffed78 --- > > Tracing command sh pid 1356 tid 100167 td 0xffffff0003f8b000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > kern_wait() at kern_wait+0xa9e > wait4() at wait4+0x3a > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffccb8, rbp = 0x124 --- > > Tracing command cron pid 1304 tid 100176 td 0xffffff0003f86ab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _sleep() at _sleep+0x312 > kern_nanosleep() at kern_nanosleep+0xec > nanosleep() at nanosleep+0x61 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80092ecfc, rsp = 0x7fffffffeb38, rbp = 0x29 --- > > Tracing command sshd pid 1295 tid 100169 td 0xffffff0003f8a720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > seltdwait() at seltdwait+0x84 > kern_select() at kern_select+0x507 > select() at select+0x54 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (93, FreeBSD ELF64, select), rip = 0x8013b70cc, rsp = 0x7fffffffe318, rbp = 0x4 --- > > Tracing command dbus-daemon pid 1252 tid 100121 td 0xffffff0003acd720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _cv_timedwait_sig() at _cv_timedwait_sig+0x24b > seltdwait() at seltdwait+0x73 > poll() at poll+0x325 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (209, FreeBSD ELF64, poll), rip = 0x8009544dc, rsp = 0x7fffffffe6c8, rbp = 0 --- > > Tracing command qmgr pid 1247 tid 100157 td 0xffffff0003d8f720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _sleep() at _sleep+0x312 > kern_kevent() at kern_kevent+0x3a7 > kevent() at kevent+0x199 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (363, FreeBSD ELF64, kevent), rip = 0x801132c0c, rsp = 0x7fffffffd9e8, rbp = 0x7fffffffd9f0 --- > > Tracing command pickup pid 1245 tid 100152 td 0xffffff0003d90ab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _sleep() at _sleep+0x312 > kern_kevent() at kern_kevent+0x3a7 > kevent() at kevent+0x199 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (363, FreeBSD ELF64, kevent), rip = 0x801126c0c, rsp = 0x7fffffffda28, rbp = 0x7fffffffda30 --- > > Tracing command master pid 1236 tid 100093 td 0xffffff0003a2a000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _sleep() at _sleep+0x312 > kern_kevent() at kern_kevent+0x3a7 > kevent() at kevent+0x199 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (363, FreeBSD ELF64, kevent), rip = 0x80111dc0c, rsp = 0x7fffffffdce8, rbp = 0x7fffffffdcf0 --- > > Tracing command dhclient pid 1117 tid 100162 td 0xffffff0003d8e390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _cv_timedwait_sig() at _cv_timedwait_sig+0x24b > seltdwait() at seltdwait+0x73 > poll() at poll+0x325 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (209, FreeBSD ELF64, poll), rip = 0x8006eb4dc, rsp = 0x7fffffffece8, rbp = 0x2 --- > > Tracing command dhclient pid 1101 tid 100166 td 0xffffff0003f8b390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > seltdwait() at seltdwait+0x84 > poll() at poll+0x325 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (209, FreeBSD ELF64, poll), rip = 0x8006eb4dc, rsp = 0x7fffffffece8, rbp = 0x9 --- > > Tracing command cupsd pid 1077 tid 100132 td 0xffffff0003a94ab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > kern_kevent() at kern_kevent+0x3a7 > kevent() at kevent+0x199 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (363, FreeBSD ELF64, kevent), rip = 0x801257c0c, rsp = 0x7fffffffe7d8, rbp = 0x1 --- > > Tracing command powerd pid 1034 tid 100161 td 0xffffff0003d8e720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _cv_timedwait_sig() at _cv_timedwait_sig+0x24b > seltdwait() at seltdwait+0x73 > kern_select() at kern_select+0x507 > select() at select+0x54 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (93, FreeBSD ELF64, select), rip = 0x80083d0cc, rsp = 0x7fffffffe7e8, rbp = 0x960 --- > > Tracing command rpc.lockd pid 961 tid 100171 td 0xffffff0003f8a000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _cv_timedwait_sig() at _cv_timedwait_sig+0x24b > svc_run_internal() at svc_run_internal+0x2f8 > svc_run() at svc_run+0x97 > nlm_syscall() at nlm_syscall+0x6f7 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (154, FreeBSD ELF64, nlm_syscall), rip = 0x8008baeac, rsp = 0x7fffffffec38, rbp = 0x7fffffffed60 --- > > Tracing command rpc.statd pid 948 tid 100122 td 0xffffff0003acd390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _cv_timedwait_sig() at _cv_timedwait_sig+0x24b > seltdwait() at seltdwait+0x73 > kern_select() at kern_select+0x507 > select() at select+0x54 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (93, FreeBSD ELF64, select), rip = 0x8008380cc, rsp = 0x7fffffffeb58, rbp = 0x800980900 --- > > Tracing command rpcbind pid 946 tid 100168 td 0xffffff0003f8aab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 > _cv_timedwait_sig() at _cv_timedwait_sig+0x24b > seltdwait() at seltdwait+0x73 > poll() at poll+0x325 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (209, FreeBSD ELF64, poll), rip = 0x8008fb4dc, rsp = 0x7fffffffcad8, rbp = 0x800b100c0 --- > > Tracing command md0 pid 872 tid 100090 td 0xffffff0003a2a390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _sleep() at _sleep+0x348 > md_kthread() at md_kthread+0x10c > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075400d30, rbp = 0 --- > > Tracing command syslogd pid 823 tid 100174 td 0xffffff0003f87390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _cv_wait_sig() at _cv_wait_sig+0x23b > seltdwait() at seltdwait+0x84 > kern_select() at kern_select+0x507 > select() at select+0x54 > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (93, FreeBSD ELF64, select), rip = 0x8008430cc, rsp = 0x7fffffffdd08, rbp = 0x800a2f0d0 --- > > Tracing command accounting pid 726 tid 100103 td 0xffffff0003a94000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_timedwait() at sleepq_timedwait+0x6d > _sleep() at _sleep+0x322 > acct_thread() at acct_thread+0x2b2 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075441d30, rbp = 0 --- > > Tracing command devd pid 653 tid 100163 td 0xffffff0003d8e000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_catch_signals() at sleepq_catch_signals+0xbf > sleepq_wait_sig() at sleepq_wait_sig+0xc > _sleep() at _sleep+0x338 > kern_wait() at kern_wait+0xa9e > wait4() at wait4+0x3a > syscall() at syscall+0x2e9 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (7, FreeBSD ELF64, wait4), rip = 0x4215ec, rsp = 0x7fffffffe778, rbp = 0x8006640d8 --- > > Tracing command zil_clean pid 285 tid 100092 td 0xffffff00037ae390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff807540ad30, rbp = 0 --- > > Tracing command zil_clean pid 284 tid 100151 td 0xffffff0003d92000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075535d30, rbp = 0 --- > > Tracing command zil_clean pid 283 tid 100150 td 0xffffff0003d92390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075530d30, rbp = 0 --- > > Tracing command zil_clean pid 282 tid 100149 td 0xffffff0003ace720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff807552bd30, rbp = 0 --- > > Tracing command zil_clean pid 281 tid 100148 td 0xffffff0003aceab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075526d30, rbp = 0 --- > > Tracing command zil_clean pid 280 tid 100147 td 0xffffff0003a4f000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075521d30, rbp = 0 --- > > Tracing command zil_clean pid 279 tid 100146 td 0xffffff0003a4f390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff807551cd30, rbp = 0 --- > > Tracing command zil_clean pid 278 tid 100145 td 0xffffff0003a4f720 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075517d30, rbp = 0 --- > > Tracing command zil_clean pid 277 tid 100144 td 0xffffff0003a4fab0 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8075512d30, rbp = 0 --- > > Tracing command zil_clean pid 276 tid 100143 td 0xffffff0003af8000 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_wait() at sleepq_wait+0x6d > _cv_wait() at _cv_wait+0x239 > taskq_thread() at taskq_thread+0x379 > fork_exit() at fork_exit+0x147 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff807550dd30, rbp = 0 --- > > Tracing command txg_thread_enter pid 275 tid 100134 td 0xffffff0003afe390 > sched_switch() at sched_switch+0x403 > mi_switch() at mi_switch+0x2a6 > sleepq_switch() at sleepq_switch+0x145 > sleepq_timedwai > ----- end ddb.txt -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 17:45:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7E591065673; Thu, 13 Aug 2009 17:45:04 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id EE92E8FC4F; Thu, 13 Aug 2009 17:45:03 +0000 (UTC) Received: by bwz19 with SMTP id 19so961729bwz.37 for ; Thu, 13 Aug 2009 10:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=TBSp5dvF8WPBKtIgjyJmRUu41ggj8Nf4vRujBzaWJmk=; b=K3tZwAf1SUFR7HQkZnD+MitPMprTl7N12F9aGM+IzmdQkgnpUZOOADVuqWAVDD8//A f4Q+5ACpfMNUHZv4kYCBnzvD54TnvEiB7BW8gbJ/IF6DPKwC6MtCUIZAlbIQxkXoBmD/ RlsTFNcHLKH9wUJ7/HWGrxvi2CBkBfasK3SMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=dAhsd5TszjZrFFg7jqkROqoecmpMhamAUlOv/l5w10wjx73kqpitI6bfZVr8quvodw QUopCmQMM2KVwOy6S3S7f4BZoE+34Uxq3W83Glz84/0pTms3TwpYWn9RWwBkVuBftgd1 yqueSy27rXRiUqPZr3oM5bkSYKUYYcC4ksyJw= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.113.9 with SMTP id y9mr419401fap.61.1250185502931; Thu, 13 Aug 2009 10:45:02 -0700 (PDT) In-Reply-To: <20090813173627.GA1498@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> Date: Thu, 13 Aug 2009 19:45:02 +0200 X-Google-Sender-Auth: f7d920b885d3594a Message-ID: <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> From: Attilio Rao To: Damian Gerow Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Noland Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 17:45:05 -0000 2009/8/13 Damian Gerow : > Attilio Rao wrote: > : So, what you can do is to compile a kernel with the following options: > : KDB, DDB, INVARIANT_SUPPORT, INVARIANTS, WITNESS > > As I'm running GENERIC, these options are already present. > > : when you get the deadlock, you should break in DDB. > : Through a textdump(4) (or serial console or whatever you prefer) you > : should get the following informations: > : bt, ps, show allpcpu, alltrace, show alllocks > : > : and report here. > > I've set ddb script kdb.enter.default="textdump set; capture on; show > allpcpu; bt; ps; alltrace; showalllocks; showalllock; call doadump; reset", > as I don't have a serial console on this machine (and my USB<->serial > adapter doesn't work on FreeBSD). > > The script does not run when resuming in graphics mode, unfortunately. > Try as I might, I just don't get anything. I'm not sure what exactly > the system is doing when it resumes, as attempts to create files on > the local fs seem to fail. You have to manually break in DDB for that. BTW, differently from GENERIC, remove WITNESS_SKIPSPIN, just in case. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 18:37:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 000D21065670 for ; Thu, 13 Aug 2009 18:37:04 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id B8AB28FC52 for ; Thu, 13 Aug 2009 18:37:04 +0000 (UTC) Received: from gluon.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id B2B5E8461; Thu, 13 Aug 2009 18:37:03 +0000 (UTC) Date: Thu, 13 Aug 2009 19:36:59 +0100 From: Bruce Cran To: "Bjoern A. Zeeb" Message-ID: <20090813193659.1a98cf16@gluon.draftnet> In-Reply-To: <20090812202853.Q93661@maildrop.int.zabbadoz.net> References: <20090812211959.0000293c@unknown> <20090812202853.Q93661@maildrop.int.zabbadoz.net> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD current mailing list Subject: Re: sctp panic in _mtx_lock_sleep when attempting to connect to a remote machine X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 18:37:05 -0000 On Wed, 12 Aug 2009 20:30:39 +0000 (UTC) "Bjoern A. Zeeb" wrote: > On Wed, 12 Aug 2009, Bruce Cran wrote: > > Hi, > > > I've found a way to reliably panic two machines running 8.0-BETA2. > > It seems that there's a problem with SCTP connection requests being > > made at the same time as other network traffic. > > [...] > unfrotunately the most intersting info is missing but it's likely that > you are hitting this: > http://lists.freebsd.org/pipermail/svn-src-stable-other/2009-August/000023.html > > I you update to latest HEAD or stable/8, can you still reproduce it? > I updated to RELENG_8 at around 1700 today and I can still reproduce it: sometimes I just get the "Fatal trap 12" panic, but now I also see a more helpful message: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/netinet/sctp_output.c:12767 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: mtx_lock() of destroyed mutex @ /usr/src/sys/netinet/sctp_output.c:12767 cpuid = 1 KDB: enter: panic Uptime: 49s Physical memory: 4078 MB Dumping 1251 MB: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x4 1236 1220 1204 1188 1172 1156 1140 1124 1108 1092 1076 1060 1044 1028 1012 996 980 964 948 932 916 900 884 868 852 836 820 804 788 772 756 740 724 708 692 676 660 644 628 612 596 580 564 548 532 516 500 484 468 452 436 420 404 388 372 356 340 324 308 292 276 260 244 228 212 196 180 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/blank_saver.ko...Reading symbols from /boot/kernel/blank_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/blank_saver.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff80582023 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff805824ac in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff80573b75 in _mtx_lock_flags (m=0x0, opts=0, file=0xffffffff80980c58 "/usr/src/sys/netinet/sctp_output.c", line=12767) at /usr/src/sys/kern/kern_mutex.c:195 #4 0xffffffff806c8252 in sctp_lower_sosend (so=0xffffff0004d19aa0, addr=0x0, uio=0xffffff807987ca30, i_pak=Variable "i_pak" is not available. ) at /usr/src/sys/netinet/sctp_output.c:12767 #5 0xffffffff806ca749 in sctp_sosend (so=0xffffff0004d19aa0, addr=0x0, uio=0xffffff807987ca30, top=0x0, control=0x0, flags=0, p=0xffffff0004b81000) at /usr/src/sys/netinet/sctp_output.c:12336 #6 0xffffffff805f1c05 in kern_sendit (td=0xffffff0004b81000, s=3, mp=0xffffff807987cb00, flags=0, control=0x0, segflg=UIO_USERSPACE) at /usr/src/sys/kern/uipc_syscalls.c:783 #7 0xffffffff805f1e0c in sendit (td=0xffffff0004b81000, s=3, mp=0xffffff807987cb00, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:719 #8 0xffffffff805f1efd in sendto (td=Variable "td" is not available. ) at /usr/src/sys/kern/uipc_syscalls.c:835 #9 0xffffffff80862d3f in syscall (frame=0xffffff807987cc80) at /usr/src/sys/amd64/amd64/trap.c:984 #10 0xffffffff80849301 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #11 0x0000000800c501dc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Bruce From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 18:57:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32B05106566B for ; Thu, 13 Aug 2009 18:57:22 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id D27478FC57 for ; Thu, 13 Aug 2009 18:57:21 +0000 (UTC) Received: (qmail 27876 invoked by uid 399); 13 Aug 2009 18:57:16 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 13 Aug 2009 18:57:16 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A846206.7010803@FreeBSD.org> Date: Thu, 13 Aug 2009 11:57:10 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <200903282317.n2SNHIjI015202@svn.freebsd.org> In-Reply-To: <200903282317.n2SNHIjI015202@svn.freebsd.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: svn commit: r190514 - head/sys/conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 18:57:22 -0000 Bjoern A. Zeeb wrote: > Author: bz > Date: Sat Mar 28 23:17:18 2009 > New Revision: 190514 > URL: http://svn.freebsd.org/changeset/base/190514 > > Log: > For kernel builds reduce the impact of svnversion, just scanning > src/sys and not the entire src/ tree. > > An earlier solution by peter had been comitted in r183528 and backed out > in r183566 due to problems with newvers.sh also called from other places > during world build. With the extra test this survived a make universe. > > Modified: > head/sys/conf/newvers.sh > > Modified: head/sys/conf/newvers.sh > ============================================================================== > --- head/sys/conf/newvers.sh Sat Mar 28 21:06:59 2009 (r190513) > +++ head/sys/conf/newvers.sh Sat Mar 28 23:17:18 2009 (r190514) > @@ -100,7 +100,13 @@ for dir in /bin /usr/bin /usr/local/bin; > done > > if [ -n "$svnversion" -a -d "${SRCDIR}/.svn" ] ; then > - svn=" r`cd $SRCDIR && $svnversion`" > + # If we are called from the kernel build, limit > + # the scope of svnversion to sys/ . > + if [ -e "${SRCDIR}/sys/conf/newvers.sh" ] ; then I missed this when it went through originally, so my apologies for the late response, but I don't see any way that this first test can ever not be true. Is there a better way to detect if the script is called in the buildkernel process? Also, what problem are we really trying to solve here? With a populated cache it takes on average 5 seconds to run all of src, and just under 1 to do only sys. Is 4 seconds really that important to save? With a dry cache I'm sure it takes a little longer, but has anyone actually measured this? Doug > + svn=" r`cd $SRCDIR/sys && $svnversion`" > + else > + svn=" r`cd $SRCDIR && $svnversion`" > + fi > else > svn="" > fi > -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 19:14:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C31601065674 for ; Thu, 13 Aug 2009 19:14:04 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6149E8FC47 for ; Thu, 13 Aug 2009 19:14:03 +0000 (UTC) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n7DJDp7I098998; Thu, 13 Aug 2009 21:13:52 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A8465EF.7030604@fgznet.ch> Date: Thu, 13 Aug 2009 21:13:51 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Alexander Leidinger References: <4A832C70.4030600@fgznet.ch> <20090813081538.5361241c6z2lqcn4@webmail.leidinger.net> In-Reply-To: <20090813081538.5361241c6z2lqcn4@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current Subject: Re: tools/kerneldoc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:14:05 -0000 Alexander Leidinger wrote: > Quoting Andreas Tobler (from Wed, 12 Aug > 2009 22:56:16 +0200): > >> Hi, >> >> does anybody care about this 'kerneldoc' package? > > [...] > >> I then dived into the subsys dir and started a 'make all'. >> >> Here too, I failed since a few .m files are no more or they are >> placed on a different place. Well, this was easy, more or less. >> Commenting them made the build work, but this is only half the >> truth, what about the new .m files? > > I have patches for the subsys part. A little bit more than only the .m > files fix: > http://www.leidinger.net/FreeBSD/current/patches/dox.diff Thanks, I tried it and I was surprised how long such a build took. Well, html and latex more than 5 hours on a p4 2.8GHz. And the amount of data is also huge, nearly 2GB of data. > I haven't tested a lot there, e.g. the USB stuff needs review, as I > didn't had a look at it since the new USB subsystem went in. > > Personally I care about the subsys part, but my spare time for it was > not enough lately. I have some hope that I can setup an automatic run > with the HTML files available on a public webserver after 8.0-release. > At the time I do this, I will also have the time to check everything > and commit the patches (I don't think this part is important enough to > fix it this late in the release process, on the other hand it is > something optional and a commit wouldn't hurt more than letting it in > the current shape...). I agree here, I do not think that this is release critical. I just wondered if anybody is in touch with this code at all. Could you enlight me with the meaning of the toplevel kerneldoc, is this kerneldoc package meant as a whole or is the benefit only in the subsys part? TIA, Andreas From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 19:17:26 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3EA11065672 for ; Thu, 13 Aug 2009 19:17:26 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outW.internet-mail-service.net (outw.internet-mail-service.net [216.240.47.246]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADD48FC4D for ; Thu, 13 Aug 2009 19:17:26 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 9F9818DF27; Thu, 13 Aug 2009 12:17:26 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E6C8D2D6011; Thu, 13 Aug 2009 12:17:25 -0700 (PDT) Message-ID: <4A8466C5.2050108@elischer.org> Date: Thu, 13 Aug 2009 12:17:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dmitry Marakasov References: <20090801022523.GA93222@hades.panopticon> In-Reply-To: <20090801022523.GA93222@hades.panopticon> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: panic in ipfw with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:17:26 -0000 Dmitry Marakasov wrote: > Hi! > > Just updated to recent current (date=2009.07.30.12.00.00), and had > a panic in ipfw with minimal network activity (one time the box was > able to get IP via DHCP and panicked on ssh to another host, next > time it panicked right while booting). Rebuilding the kernel with > nooptions IPFIREWALL works nice as a workaround. > > Full text available here: > http://people.freebsd.org/~amdmi3/ipfw-panic.txt > > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc04c0049 in db_fncall (dummy1=1, dummy2=0, dummy3=-1059813280, dummy4=0xe58e0558 "") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04c042e in db_command (last_cmdp=0xc0ca72bc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04c0567 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04c223f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > #5 0xc088922e in kdb_trap (type=12, code=0, tf=0xe58e0784) at /usr/src/sys/kern/subr_kdb.c:534 > #6 0xc0aea4c6 in trap_fatal (frame=0xe58e0784, eva=28) at /usr/src/sys/i386/i386/trap.c:924 > #7 0xc0aea75a in trap_pfault (frame=0xe58e0784, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:846 > #8 0xc0aeb137 in trap (frame=0xe58e0784) at /usr/src/sys/i386/i386/trap.c:528 > #9 0xc0acf71b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0xc5f80c1c in ipfw_chk (args=0xe58e0a3c) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw2.c:2061 > #11 0xc5f815c3 in ipfw_check_in (arg=0x0, m0=0xe58e0b70, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw_pfil.c:135 > #12 0xc090a071 in pfil_run_hooks (ph=0xc0ceec20, mp=0xe58e0bc4, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:79 > #13 0xc095c93d in ip_input (m=0xc5dcfe00) at /usr/src/sys/netinet/ip_input.c:497 > #14 0xc09094f3 in netisr_dispatch_src (proto=1, source=0, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:917 > #15 0xc09097a4 in netisr_dispatch (proto=1, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:1004 > #16 0xc09031a0 in ether_demux (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:896 > #17 0xc09036a2 in ether_input (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:755 > #18 0xc053de29 in ale_int_task (arg=0xc55fd000, pending=1) at /usr/src/sys/dev/ale/if_ale.c:2581 > #19 0xc089409f in taskqueue_run (queue=0xc574dd00) at /usr/src/sys/kern/subr_taskqueue.c:282 > #20 0xc089428d in taskqueue_thread_loop (arg=0xc55fda2c) at /usr/src/sys/kern/subr_taskqueue.c:403 > #21 0xc08350a9 in fork_exit (callout=0xc08941d4 , arg=0xc55fda2c, frame=0xe58e0d38) at /usr/src/sys/kern/kern_fork.c:838 > #22 0xc0acf790 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > I just confirmed this is still there. and I need to fix it before 8.0 just keeping you up to date.. From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 19:18:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EE9910656C0; Thu, 13 Aug 2009 19:18:30 +0000 (UTC) (envelope-from dgerow@afflictions.org) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by mx1.freebsd.org (Postfix) with ESMTP id C9D4D8FC65; Thu, 13 Aug 2009 19:18:29 +0000 (UTC) Received: from plebeian.afflictions.org (CPE000db917e8b9-CM0019475d4056.cpe.net.cable.rogers.com [99.241.168.226]) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id DE4C32552F3; Thu, 13 Aug 2009 21:18:23 +0200 (CEST) Received: by plebeian.afflictions.org (Postfix, from userid 1001) id 42BC2F054; Thu, 13 Aug 2009 15:17:37 -0400 (EDT) Date: Thu, 13 Aug 2009 15:17:36 -0400 From: Damian Gerow To: Attilio Rao Message-ID: <20090813191724.GA1499@plebeian.afflictions.org> References: <20090813002104.GA1481@plebeian.afflictions.org> <1250161757.1823.18.camel@balrog.2hip.net> <3bbf2fe10908130652t77767929q44ba12f39cb3f997@mail.gmail.com> <20090813162705.GA1468@plebeian.afflictions.org> <3bbf2fe10908130938v525a18c3p9c4e10db662ab3c0@mail.gmail.com> <20090813173627.GA1498@plebeian.afflictions.org> <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe10908131045h407ddfd8o8c4204532cc82ad@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: No display after resume in r196086 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:18:31 -0000 Attilio Rao wrote: : > The script does not run when resuming in graphics mode, unfortunately. : > Try as I might, I just don't get anything. I'm not sure what exactly : > the system is doing when it resumes, as attempts to create files on : > the local fs seem to fail. : : You have to manually break in DDB for that. : BTW, differently from GENERIC, remove WITNESS_SKIPSPIN, just in case. After removing WITNESS_SKIPSPIN, the ddb script works. I've included the output from textdump below. ----- begin version.txt FreeBSD 8.0-BETA2 #0 r196196: Thu Aug 13 14:50:15 EDT 2009 dgerow@plebeian.afflictions.org:/usr/obj/usr/src/sys/GENERIC.NOSKIPSPIN ----- end version.txt ----- begin msgbuf.txt drm0: [ITHREAD] usbus3: port reset timeout uhub_reattach_port:373: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port:463: device problem (USB_ERR_TIMEOUT), disabling port 1 <5>em0: link state changed to DOWN <5>em0: link state changed to UP ugen1.2: at usbus1 (disconnected) Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff8048e80b stack pointer = 0x28:0xffffff8072d3fad0 frame pointer = 0x28:0xffffff8072d3fb20 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 22 (usbus1) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xffffff005065a8f0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 exclusive sx 123456789ABCDEF - USB config SX lock (123456789ABCDEF - USB config SX lock) r = 0 (0xffffff000369e870) locked @ /usr/src/sys/dev/usb/usb_device.c:409 exclusive sx newbus (newbus) r = 0 (0xffffffff80bfc500) locked @ /usr/src/sys/kern/subr_bus.c:219 exclusive sx ACPI embedded controller (ACPI embedded controller) r = 0 (0xffffffff80ba9d20) locked @ /usr/src/sys/dev/acpica/acpi_ec.c:212 ----- end msgbuf.txt ----- begin ddb.txt db:0:kdb.enter.default> show allpcpu Current CPU: 0 cpuid = 0 dynamic pcpu = 0x56fd80 curthread = 0xffffff00035b7720: pid 22 "usbus1" curpcb = 0xffffff8072d3fd40 fpcurthread = none idlethread = 0xffffff00024f6390: pid 11 "idle: cpu0" curpmap = 0 tssp = 0xffffffff80de7a80 commontssp = 0xffffffff80de7a80 rsp0 = 0xffffff8072d3fd40 gs32p = 0xffffffff80de68b8 ldt = 0xffffffff80de68f8 tss = 0xffffffff80de68e8 spin locks held: cpuid = 1 dynamic pcpu = 0xffffff807f483d80 curthread = 0xffffff00143eb720: pid 28222 "hald" curpcb = 0xffffff807556bd40 fpcurthread = none idlethread = 0xffffff00024f6720: pid 11 "idle: cpu1" curpmap = 0 tssp = 0xffffffff80de7ae8 commontssp = 0xffffffff80de7ae8 rsp0 = 0xffffff807556bd40 gs32p = 0xffffffff80de6920 ldt = 0xffffffff80de6960 tss = 0xffffffff80de6950 spin locks held: db:0:kdb.enter.default> bt Tracing pid 22 tid 100047 td 0xffffff00035b7720 usb_unconfigure() at usb_unconfigure+0x267 usb_free_device() at usb_free_device+0x1bc uhub_explore() at uhub_explore+0x2a3 usb_bus_explore() at usb_bus_explore+0x9e usb_process() at usb_process+0xcd fork_exit() at fork_exit+0x147 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072d3fd30, rbp = 0 --- db:0:kdb.enter.default> ps pid ppid pgrp uid state wmesg wchan cmd 28376 28356 27500 0 R acpiconf 28356 27500 27500 0 S wait 0xffffff0019273460 sh 28326 28296 28326 1001 Ss+ ttyin 0xffffff0002c0fca8 zsh 28320 28296 28320 1001 Ss+ ttyin 0xffffff00035304a8 zsh 28317 1 28304 1001 S select 0xffffff00afdb03c0 conky 28316 1 28306 1001 S select 0xffffff0077254a40 conky 28315 1 28308 1001 S select 0xffffff00afdc59c0 conky 28314 28308 28308 1001 S select 0xffffff005061d240 dzen2 28312 28306 28306 1001 S select 0xffffff005061d340 dzen2 28310 28304 28304 1001 S select 0xffffff007713ecc0 dzen2 28308 1 28308 1001 Ss wait 0xffffff0019c53000 sh 28306 1 28306 1001 Ss wait 0xffffff000ab8b460 sh 28304 1 28304 1001 Ss wait 0xffffff000ab8e8c0 sh 28302 1 28302 1001 Ss select 0xffffff005061ce40 dzen2 28300 28290 28290 1001 S+ select 0xffffff000a9c9cc0 dzen2 28299 28290 28290 1001 S+ select 0xffffff000aa21240 xmonad-x86_64-freeb 28296 1 28290 1001 S+ select 0xffffff000a3efac0 urxvtd 28295 1 28290 1001 S+ sbwait 0xffffff005065a93c urxvtd 28293 1 28293 1001 Ss select 0xffffff00aff8a2c0 ssh-agent 28290 28286 28290 1001 S+ wait 0xffffff0003ff1460 sh 28287 28286 28287 1001 R+ initial thread 28286 28268 28268 1001 S+ wait 0xffffff0019c74460 xinit 28268 28264 28268 1001 S+ wait 0xffffff0019d06460 sh 28264 28210 28264 1001 S+ pause 0xffffff0019d10500 zsh 28231 28226 28222 0 S kqread 0xffffff0014573d00 initial thread 28226 28222 28222 0 S select 0xffffff00afbfd040 initial thread 28225 1 28225 0 Ss (threaded) console-kit-daemon 100231 S waitvt 0xffffffff80bd7b40 console-kit-daemon 100238 S waitvt 0xffffffff80bd7bb8 console-kit-daemon 100237 S waitvt 0xffffffff80bd7bb0 console-kit-daemon 100236 S waitvt 0xffffffff80bd7ba8 console-kit-daemon 100235 S waitvt 0xffffffff80bd7ba0 console-kit-daemon 100234 S waitvt 0xffffffff80bd7b98 console-kit-daemon 100233 S waitvt 0xffffffff80bd7b90 console-kit-daemon 100232 S waitvt 0xffffffff80bd7b88 console-kit-daemon 100230 S waitvt 0xffffffff80bd7b78 console-kit-daemon 100229 S waitvt 0xffffffff80bd7b70 console-kit-daemon 100228 S waitvt 0xffffffff80bd7b68 console-kit-daemon 100227 S waitvt 0xffffffff80bd7b60 console-kit-daemon 100226 S waitvt 0xffffffff80bd7b58 console-kit-daemon 100225 S waitvt 0xffffffff80bd7b50 console-kit-daemon 100224 S waitvt 0xffffffff80bd7b48 console-kit-daemon 100223 S ucond 0xffffff0014ee8780 console-kit-daemon 100201 S select 0xffffff0003fc2e40 console-kit-daemon 28222 1 28222 560 Rs CPU 1 hald 28217 1 28217 0 Ss+ ttyin 0xffffff000354a8a8 getty 28216 1 28216 0 Ss+ ttyin 0xffffff000353e8a8 getty 28215 1 28215 0 Ss+ ttyin 0xffffff000354b0a8 getty 28214 1 28214 0 Ss+ ttyin 0xffffff000353fca8 getty 28213 1 28213 0 Ss+ ttyin 0xffffff000354e4a8 getty 28212 1 28212 0 Ss+ ttyin 0xffffff000353cca8 getty 28211 1 28211 0 Ss+ ttyin 0xffffff00025050a8 getty 28210 1 28210 0 Ss+ wait 0xffffff0019d108c0 login 28153 1 28153 0 Ss nanslp 0xffffffff80bdcd68 cron 28144 1 28144 0 Ss select 0xffffff00aff7c8c0 sshd 28101 1 28101 556 Ss select 0xffffff00503a72c0 dbus-daemon 28096 28085 28085 125 S kqread 0xffffff0014865b00 qmgr 28095 28085 28085 125 S kqread 0xffffff000a2bbb00 pickup 28085 1 28085 0 Ss kqread 0xffffff00191cf700 master 28050 1 28050 65 Ss select 0xffffff00503a7bc0 dhclient 28034 1 28034 0 Ss select 0xffffff00af738340 dhclient 27926 1 27926 0 Ss kqread 0xffffff0014676400 cupsd 27883 1 27883 0 Ss select 0xffffff000a96cac0 powerd 27808 1 27808 0 Ss rpcsvc 0xffffff000a2ff620 NLM: master 27795 1 27795 0 Ss select 0xffffff000adc8240 rpc.statd 27793 1 27793 0 Ss select 0xffffff000a2e2440 rpcbind 27719 0 0 0 SL mdwait 0xffffff005004f800 [md0] 27670 1 27670 0 Ss select 0xffffff000a32ce40 syslogd 27573 0 0 0 SL - 0xffffffff80bd9dc0 [accounting] 27500 1 27500 0 Ss wait 0xffffff0019269000 devd 145 0 0 0 SL tq->tq_d 0xffffff0003a49cc0 [zil_clean] 144 0 0 0 SL tq->tq_d 0xffffff0003a49ba0 [zil_clean] 143 0 0 0 SL tq->tq_d 0xffffff0003a49960 [zil_clean] 142 0 0 0 SL tq->tq_d 0xffffff0003a49840 [zil_clean] 141 0 0 0 SL tq->tq_d 0xffffff0003a49720 [zil_clean] 140 0 0 0 SL tq->tq_d 0xffffff0003a49600 [zil_clean] 139 0 0 0 SL tq->tq_d 0xffffff0003a494e0 [zil_clean] 138 0 0 0 SL tq->tq_d 0xffffff0003a493c0 [zil_clean] 137 0 0 0 SL tq->tq_d 0xffffff0003a492a0 [zil_clean] 136 0 0 0 SL tq->tq_d 0xffffff0003a49180 [zil_clean] 135 0 0 0 SL tx->tx_s 0xffffff000362ca38 [txg_thread_enter] 134 0 0 0 SL tx->tx_q 0xffffff000362ca58 [txg_thread_enter] 133 0 0 0 SL vgeom:io 0xffffff0003a70310 [vdev:worker ad4s1d.] 132 0 0 0 SL tq->tq_d 0xffffff0003a4a600 [spa_zio] 131 0 0 0 SL tq->tq_d 0xffffff0003a4a720 [spa_zio] 130 0 0 0 SL tq->tq_d 0xffffff0003a4a840 [spa_zio] 129 0 0 0 SL tq->tq_d 0xffffff0003a4a960 [spa_zio] 128 0 0 0 SL tq->tq_d 0xffffff0003a4aa80 [spa_zio] 127 0 0 0 SL tq->tq_d 0xffffff0003a4aba0 [spa_zio] 126 0 0 0 SL tq->tq_d 0xffffff0003a4acc0 [spa_zio] 125 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 124 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 123 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 122 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 121 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 120 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 119 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 118 0 0 0 SL tq->tq_d 0xffffff0003a4ade0 [spa_zio] 117 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 116 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 115 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 114 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 113 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 112 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 111 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 110 0 0 0 SL tq->tq_d 0xffffff0003b6c060 [spa_zio] 109 0 0 0 SL tq->tq_d 0xffffff0003b6c180 [spa_zio] 108 0 0 0 SL tq->tq_d 0xffffff0003b6c2a0 [spa_zio] 107 0 0 0 SL tq->tq_d 0xffffff0003a49060 [spa_zio] 79 0 0 0 SL l2arc_fe 0xffffffff8133dec0 [l2arc_feed_thread] 78 0 0 0 SL arc_recl 0xffffffff813358e0 [arc_reclaim_thread] 75 0 0 0 SL vacv 0xffffffff813345e0 [vaclean] 74 0 0 0 SL tq->tq_d 0xffffff0003a4a060 [system_taskq] 73 0 0 0 SL tq->tq_d 0xffffff0003a4a060 [system_taskq] 67 0 0 0 SL geli:w 0xffffff0003657000 [g_eli[1] ad4s1d] 66 0 0 0 SL geli:w 0xffffff0003657000 [g_eli[0] ad4s1d] 61 0 0 0 SL crypto_r 0xffffffff81247900 [crypto returns] 60 0 0 0 SL crypto_w 0xffffffff812478c0 [crypto] 52 0 0 0 SL flowclea 0xffffffff80bdca44 [flowcleaner] 51 0 0 0 SL sdflush 0xffffffff80dad4d8 [softdepflush] 50 0 0 0 SL syncer 0xffffffff80d9e340 [syncer] 49 0 0 0 SL vlruwt 0xffffff00035da000 [vnlru] 48 0 0 0 SL psleep 0xffffffff80d9de68 [bufdaemon] 9 0 0 0 SL pgzero 0xffffffff80daef2c [pagezero] 8 0 0 0 SL psleep 0xffffffff80dae2c8 [vmdaemon] 7 0 0 0 SL psleep 0xffffffff80dae28c [pagedaemon] 47 0 0 0 SL wmsg 0xffffff8000326dd0 [usbus7] 46 0 0 0 SL wmsg 0xffffff8000326d78 [usbus7] 45 0 0 0 SL wmsg 0xffffff8000326d20 [usbus7] 44 0 0 0 SL wmsg 0xffffff8000326cc8 [usbus7] 43 0 0 0 SL wmsg 0xffffff800031def0 [usbus6] 42 0 0 0 SL wmsg 0xffffff800031de98 [usbus6] 41 0 0 0 SL wmsg 0xffffff800031de40 [usbus6] 40 0 0 0 SL wmsg 0xffffff800031dde8 [usbus6] 39 0 0 0 SL wmsg 0xffffff8000314ef0 [usbus5] 38 0 0 0 SL wmsg 0xffffff8000314e98 [usbus5] 37 0 0 0 SL wmsg 0xffffff8000314e40 [usbus5] 36 0 0 0 SL wmsg 0xffffff8000314de8 [usbus5] 35 0 0 0 SL wmsg 0xffffff800030bef0 [usbus4] 34 0 0 0 SL wmsg 0xffffff800030be98 [usbus4] 33 0 0 0 SL wmsg 0xffffff800030be40 [usbus4] 32 0 0 0 SL wmsg 0xffffff800030bde8 [usbus4] 31 0 0 0 SL wmsg 0xffffff8000302dd0 [usbus3] 30 0 0 0 SL wmsg 0xffffff8000302d78 [usbus3] 29 0 0 0 SL wmsg 0xffffff8000302d20 [usbus3] 28 0 0 0 SL wmsg 0xffffff8000302cc8 [usbus3] 27 0 0 0 SL wmsg 0xffffff80002f9ef0 [usbus2] 26 0 0 0 SL wmsg 0xffffff80002f9e98 [usbus2] 25 0 0 0 SL wmsg 0xffffff80002f9e40 [usbus2] 24 0 0 0 SL wmsg 0xffffff80002f9de8 [usbus2] 23 0 0 0 SL wmsg 0xffffff80002f0ef0 [usbus1] 22 0 0 0 RL CPU 0 [usbus1] 21 0 0 0 SL wmsg 0xffffff80002f0e40 [usbus1] 20 0 0 0 SL wmsg 0xffffff80002f0de8 [usbus1] 19 0 0 0 SL wmsg 0xffffff80002e7ef0 [usbus0] 18 0 0 0 SL wmsg 0xffffff80002e7e98 [usbus0] 17 0 0 0 SL wmsg 0xffffff80002e7e40 [usbus0] 16 0 0 0 SL wmsg 0xffffff80002e7de8 [usbus0] 6 0 0 0 SL waiting_ 0xffffffff80da1260 [sctp_iterator] 15 0 0 0 SL cooling 0xffffff000352ad58 [acpi_cooling1] 14 0 0 0 RL [acpi_thermal] 5 0 0 0 SL ccb_scan 0xffffffff80ba5ce0 [xpt_thrd] 13 0 0 0 SL - 0xffffffff80bdca44 [yarrow] 4 0 0 0 SL - 0xffffffff80bd9228 [g_down] 3 0 0 0 SL - 0xffffffff80bd9220 [g_up] 2 0 0 0 SL - 0xffffffff80bd9210 [g_event] 12 0 0 0 WL (threaded) intr 100239 I [irq256: vgapci0] 100039 I [irq12: psm0] 100038 I [irq1: atkbd0] 100035 I [irq19: ehci1] 100034 I [irq18: uhci5] 100033 I [irq17: uhci4] 100032 I [irq16: uhci3+] 100031 I [irq258: hdac0] 100030 I [irq23: ehci0+] 100029 I [irq22: uhci2] 100028 I [irq21: uhci1] 100027 I [irq20: uhci0] 100025 I [irq9: acpi0] 100024 I [swi2: cambio] 100018 I [swi6: task queue] 100017 I [swi6: Giant taskq] 100014 I [swi5: +] 100008 I [swi3: vm] 100007 I [swi1: netisr 0] 100006 I [swi4: clock] 100005 I [swi4: clock] 11 0 0 0 RL (threaded) idle 100004 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xffffff00024f48c0 [init] 10 0 0 0 SL audit_wo 0xffffffff80dac830 [audit] 0 0 0 0 RLs (threaded) kernel 100026 D - 0xffffff0002726500 [em0 taskq] 100022 D - 0xffffff000265a300 [kqueue taskq] 100021 RunQ [acpi_task_2] 100020 D - 0xffffff000261fc80 [acpi_task_1] 100019 D - 0xffffff000261fc80 [acpi_task_0] 100016 D - 0xffffff000265a080 [aiod_bio taskq] 100015 D - 0xffffff000265a100 [thread taskq] 100012 D - 0xffffff00024f8580 [firmware taskq] 100000 D sched 0xffffffff80bd9320 [swapper] db:0:kdb.enter.default> alltrace Tracing command acpiconf pid 28376 tid 100146 td 0xffffff00039f9ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 ast() at ast+0x27d doreti_ast() at doreti_ast+0x1f Tracing command sh pid 28356 tid 100185 td 0xffffff00192f3ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe988, rbp = 0x6b6c --- Tracing command zsh pid 28326 tid 100205 td 0xffffff0019c92ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x800bea14c, rsp = 0x7fffffffe518, rbp = 0 --- Tracing command zsh pid 28320 tid 100149 td 0xffffff00039f9000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x800bea14c, rsp = 0x7fffffffe518, rbp = 0 --- Tracing command conky pid 28317 tid 100194 td 0xffffff00192f1720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8016f60cc, rsp = 0x7fffffffe668, rbp = 0x7 --- Tracing command conky pid 28316 tid 100142 td 0xffffff0003ed7720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8016f60cc, rsp = 0x7fffffffe668, rbp = 0x7 --- Tracing command conky pid 28315 tid 100188 td 0xffffff00192f3000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8016f60cc, rsp = 0x7fffffffe668, rbp = 0x7 --- Tracing command dzen2 pid 28314 tid 100153 td 0xffffff000a01aab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd38, rbp = 0x801271500 --- Tracing command dzen2 pid 28312 tid 100158 td 0xffffff0003ed4ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd38, rbp = 0x801271500 --- Tracing command dzen2 pid 28310 tid 100135 td 0xffffff0003eda390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd38, rbp = 0x801271500 --- Tracing command sh pid 28308 tid 100203 td 0xffffff0019c93390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe878, rbp = 0x6e94 --- Tracing command sh pid 28306 tid 100165 td 0xffffff00143f1000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe878, rbp = 0x6e92 --- Tracing command sh pid 28304 tid 100190 td 0xffffff00192ee720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe878, rbp = 0x6e90 --- Tracing command dzen2 pid 28302 tid 100170 td 0xffffff00143eaab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffdd38, rbp = 0x2a5 --- Tracing command dzen2 pid 28300 tid 100175 td 0xffffff00143ea390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8007320cc, rsp = 0x7fffffffde08, rbp = 0x801271500 --- Tracing command xmonad-x86_64-freeb pid 28299 tid 100159 td 0xffffff0003ed4720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8011d64dc, rsp = 0x7fffffffa7a8, rbp = 0x801846000 --- Tracing command urxvtd pid 28296 tid 100140 td 0xffffff0003ed8000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _cv_timedwait_sig() at _cv_timedwait_sig+0x24b seltdwait() at seltdwait+0x73 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x80284e0cc, rsp = 0x7fffffffe8e8, rbp = 0x40 --- Tracing command urxvtd pid 28295 tid 100181 td 0xffffff0003f65ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sbwait() at sbwait+0x66 soreceive_generic() at soreceive_generic+0x377 soreceive() at soreceive+0x12 soo_read() at soo_read+0x3d dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80284e14c, rsp = 0x7fffffffe6f8, rbp = 0x7fffffffe738 --- Tracing command ssh-agent pid 28293 tid 100197 td 0xffffff00143f1ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x800d2b0cc, rsp = 0x7fffffffe9d8, rbp = 0xa --- Tracing command sh pid 28290 tid 100154 td 0xffffff000a01a720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe968, rbp = 0x6e82 --- Tracing command Xorg pid 28287 tid 100198 td 0xffffff00143f1720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_wait() at sleepq_wait+0x6d _sx_xlock_hard() at _sx_xlock_hard+0x478 _sx_xlock() at _sx_xlock+0xa8 newbus_xlock() at newbus_xlock+0x21 psmclose() at psmclose+0x1a2 giant_close() at giant_close+0x61 devfs_close() at devfs_close+0x26c VOP_CLOSE_APV() at VOP_CLOSE_APV+0xb3 vn_close() at vn_close+0x179 vn_closefile() at vn_closefile+0xcd devfs_close_f() at devfs_close_f+0x1e _fdrop() at _fdrop+0x3c closef() at closef+0x262 kern_close() at kern_close+0x104 close() at close+0xb syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (6, FreeBSD ELF64, close), rip = 0x801a0210c, rsp = 0x7fffffffe2a8, rbp = 0xe --- Tracing command xinit pid 28286 tid 100199 td 0xffffff0019c94390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x8008d816c, rsp = 0x7fffffffea18, rbp = 0x7fffffffea40 --- Tracing command sh pid 28268 tid 100219 td 0xffffff0019d58390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x80092f16c, rsp = 0x7fffffffe838, rbp = 0x6e6c --- Tracing command zsh pid 28264 tid 100213 td 0xffffff00192e2ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_sigsuspend() at kern_sigsuspend+0xcd sigsuspend() at sigsuspend+0x34 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (341, FreeBSD ELF64, sigsuspend), rip = 0x800b562ac, rsp = 0x7fffffffea68, rbp = 0 --- Tracing command hald-addon-mouse-sy pid 28231 tid 100155 td 0xffffff000a01a390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_kevent() at kern_kevent+0x3a7 kevent() at kevent+0x199 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (363, FreeBSD ELF64, kevent), rip = 0x800e44c0c, rsp = 0x7fffffffe788, rbp = 0x801621070 --- Tracing command hald-runner pid 28226 tid 100082 td 0xffffff00035e0000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x800c0d4dc, rsp = 0x7fffffffeb68, rbp = 0x1 --- Tracing command console-kit-daemon pid 28225 tid 100231 td 0xffffff0003fc5390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffaeef38, rbp = 0x1 --- Tracing command console-kit-daemon pid 28225 tid 100238 td 0xffffff00505ee720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffafff38, rbp = 0x10 --- Tracing command console-kit-daemon pid 28225 tid 100237 td 0xffffff00505eeab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb10f38, rbp = 0xf --- Tracing command console-kit-daemon pid 28225 tid 100236 td 0xffffff00505ef000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb21f38, rbp = 0xe --- Tracing command console-kit-daemon pid 28225 tid 100235 td 0xffffff00505ef390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb32f38, rbp = 0xd --- Tracing command console-kit-daemon pid 28225 tid 100234 td 0xffffff00505ef720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb43f38, rbp = 0xc --- Tracing command console-kit-daemon pid 28225 tid 100233 td 0xffffff00505efab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb54f38, rbp = 0xb --- Tracing command console-kit-daemon pid 28225 tid 100232 td 0xffffff00505f0000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb65f38, rbp = 0xa --- Tracing command console-kit-daemon pid 28225 tid 100230 td 0xffffff0019c94720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb87f38, rbp = 0x8 --- Tracing command console-kit-daemon pid 28225 tid 100229 td 0xffffff0019c94ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffb98f38, rbp = 0x7 --- Tracing command console-kit-daemon pid 28225 tid 100228 td 0xffffff0019d3c000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffba9f38, rbp = 0x6 --- Tracing command console-kit-daemon pid 28225 tid 100227 td 0xffffff0019d3c390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbbaf38, rbp = 0x5 --- Tracing command console-kit-daemon pid 28225 tid 100226 td 0xffffff0019d3c720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbcbf38, rbp = 0x4 --- Tracing command console-kit-daemon pid 28225 tid 100225 td 0xffffff0019d3cab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbdcf38, rbp = 0x3 --- Tracing command console-kit-daemon pid 28225 tid 100224 td 0xffffff0019d3f000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 sctty_ioctl() at sctty_ioctl+0xe13 tty_ioctl() at tty_ioctl+0xaa ttydev_ioctl() at ttydev_ioctl+0x99 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80162c0ec, rsp = 0x7fffffbedf38, rbp = 0x2 --- Tracing command console-kit-daemon pid 28225 tid 100223 td 0xffffff0019d3f390 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 do_cv_wait() at do_cv_wait+0x4e1 __umtx_op_cv_wait() at __umtx_op_cv_wait+0x58 _umtx_op() at _umtx_op+0x1c syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (454, FreeBSD ELF64, _umtx_op), rip = 0x80143ef0c, rsp = 0x7fffffbfed58, rbp = 0x80186d380 --- Tracing command console-kit-daemon pid 28225 tid 100201 td 0xffffff0019c93ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8015da4dc, rsp = 0x7fffffffeac8, rbp = 0x4 --- Tracing command hald pid 28222 tid 100167 td 0xffffff00143eb720 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x36 trap() at trap+0x42 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff8055b303, rsp = 0xffffff8000018fe0, rbp = 0xffffff807556b970 --- _sx_slock_hard() at _sx_slock_hard+0x13c _sx_slock() at _sx_slock+0xaa newbus_slock() at newbus_slock+0x21 acpi_battery_ioctl() at acpi_battery_ioctl+0x6f acpiioctl() at acpiioctl+0x163 devfs_ioctl_f() at devfs_ioctl_f+0xde kern_ioctl() at kern_ioctl+0x1e4 ioctl() at ioctl+0x158 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x8012370ec, rsp = 0x7fffffffe598, rbp = 0x801a0aae0 --- Tracing command getty pid 28217 tid 100136 td 0xffffff0003eda000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 28216 tid 100222 td 0xffffff0019d3f720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 28215 tid 100216 td 0xffffff0019d59000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 28214 tid 100177 td 0xffffff00143f2ab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 28213 tid 100161 td 0xffffff0003ed4000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 28212 tid 100157 td 0xffffff0003ed7000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command getty pid 28211 tid 100182 td 0xffffff0003f65720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b tty_wait() at tty_wait+0x65 ttydisc_read() at ttydisc_read+0x220 ttydev_read() at ttydev_read+0x86 devfs_read_f() at devfs_read_f+0x7f dofileread() at dofileread+0x97 kern_readv() at kern_readv+0x46 read() at read+0x4e syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (3, FreeBSD ELF64, read), rip = 0x80084014c, rsp = 0x7fffffffecc8, rbp = 0 --- Tracing command login pid 28210 tid 100212 td 0xffffff0019c91000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _sleep() at _sleep+0x338 kern_wait() at kern_wait+0xa9e wait4() at wait4+0x3a syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (7, FreeBSD ELF64, wait4), rip = 0x8009e416c, rsp = 0x7fffffffec58, rbp = 0x800b969c0 --- Tracing command cron pid 28153 tid 100178 td 0xffffff00143f2720 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_timedwait_sig() at sleepq_timedwait_sig+0x12 _sleep() at _sleep+0x312 kern_nanosleep() at kern_nanosleep+0xec nanosleep() at nanosleep+0x61 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (240, FreeBSD ELF64, nanosleep), rip = 0x80092ecfc, rsp = 0x7fffffffeb38, rbp = 0x3c --- Tracing command sshd pid 28144 tid 100133 td 0xffffff0003a6dab0 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 kern_select() at kern_select+0x507 select() at select+0x54 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (93, FreeBSD ELF64, select), rip = 0x8013b70cc, rsp = 0x7fffffffe318, rbp = 0x4 --- Tracing command dbus-daemon pid 28101 tid 100208 td 0xffffff0019c92000 sched_switch() at sched_switch+0x403 mi_switch() at mi_switch+0x2a6 sleepq_switch() at sleepq_switch+0x145 sleepq_catch_signals() at sleepq_catch_signals+0xbf sleepq_wait_sig() at sleepq_wait_sig+0xc _cv_wait_sig() at _cv_wait_sig+0x23b seltdwait() at seltdwait+0x84 poll() at poll+0x325 syscall() at syscall+0x2e9 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (209, FreeBSD ELF64, poll), rip = 0x8009544dc, rsp = 0x7fffffffe6c8, rbp = 0 --- Tracing command qmgr pid 2809 ----- end ddb.txt From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 19:19:41 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ED6C10656AE; Thu, 13 Aug 2009 19:19:41 +0000 (UTC) (envelope-from erik@cederstrand.dk) Received: from mx2.itu.dk (mx2.itu.dk [130.226.142.29]) by mx1.freebsd.org (Postfix) with ESMTP id DB3DF8FC16; Thu, 13 Aug 2009 19:19:40 +0000 (UTC) Received: from [192.168.10.164] (0x573b9942.cpe.ge-1-2-0-1101.ronqu1.customer.tele.dk [87.59.153.66]) by mx2.itu.dk (Postfix) with ESMTP id 3C4436485B6; Thu, 13 Aug 2009 21:19:39 +0200 (CEST) Message-Id: <07D3A5EC-34E2-4040-8DD6-40FF5AFC2E6D@cederstrand.dk> From: Erik Cederstrand To: Roman Divacky In-Reply-To: <20090812125937.GA95810@freebsd.org> Content-Type: multipart/signed; boundary=Apple-Mail-241--846452734; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 13 Aug 2009 21:19:30 +0200 References: <20090812125937.GA95810@freebsd.org> X-Mailer: Apple Mail (2.936) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Robert Watson , current@FreeBSD.org Subject: Re: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 19:19:41 -0000 --Apple-Mail-241--846452734 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Den 12/08/2009 kl. 14.59 skrev Roman Divacky: > > what happened to the performance tracking project? That would be me. It slowed to a crawl due to relocation, kids, day job and other ENOTIME excuses. I still have a lot of interest in the project, so I'd be happy if someone has time to help. The main tasks are adapting the scripts to the new SVN repo, and restoring access to hardware resources. Thanks, Erik --Apple-Mail-241--846452734-- From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 21:25:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2A1B10656E0; Thu, 13 Aug 2009 21:25:29 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7A5028FEF4; Thu, 13 Aug 2009 20:55:25 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7DKtNZg051102 ; Thu, 13 Aug 2009 22:55:24 +0200 (CEST) X-Ids: 168 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7DKtMec040152; Thu, 13 Aug 2009 22:55:22 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7DKtMIO040149; Thu, 13 Aug 2009 22:55:22 +0200 (CEST) (envelope-from arno) To: Robert Watson From: "Arno J. Klaassen" References: Date: Thu, 13 Aug 2009 22:55:22 +0200 In-Reply-To: (Robert Watson's message of "Wed\, 12 Aug 2009 13\:29\:35 +0100 \(BST\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9693/Thu Aug 13 19:02:09 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A847DBB.00F by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A847DBB.00F/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: current@freebsd.org Subject: Re: Call for regression and performance testing - 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:25:30 -0000 Hello, Robert Watson writes: > > [ ... ] > Functional testing > > We actually have a sizable regression test suite in src/tools/regression -- is anyone aware of some rudimentary efforts to set up an overall "make && ./runtests" environment? Merci, Arno From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 21:25:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD78E10656F3 for ; Thu, 13 Aug 2009 21:25:35 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id CA2218FDC6 for ; Thu, 13 Aug 2009 20:42:15 +0000 (UTC) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n7DKgDqn048474 for ; Thu, 13 Aug 2009 22:42:13 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A847AA5.1030701@fgznet.ch> Date: Thu, 13 Aug 2009 22:42:13 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Subject: 8.0-stable/releng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:25:37 -0000 Hi, for the record, am I correct that the upcoming 8.0 branch is like this: svn ls svn://svn.freebsd.org/base/stable/ .. 8/ ? And not under 'releng'? I'm a bit confused about naming conventions, releng vs. stable. I have no problem with either, but which one is the one to be used for BETA-3/RC? Is head becoming 9.0 soon? TIA, Andreas From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 21:55:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 691F41065698 for ; Thu, 13 Aug 2009 21:55:31 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 89AF48FC43 for ; Thu, 13 Aug 2009 21:55:30 +0000 (UTC) Received: by bwz19 with SMTP id 19so1115069bwz.37 for ; Thu, 13 Aug 2009 14:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LLFim1lfud1KsU3wg/Nb63U/Gf8e0rxoYwUH7a7yeWA=; b=Nc2JsDmQ4iOCkdMI9wN3PszG1F/v1J18MCy1QMXuUeuUB6nL3ZrdX07uAc+YR7gCPQ yi12QG6p4I2q2Jdza0whu/0jx7m0kzie/mUxrOeIy0t+xx5hir8UG7lAlH/IdcCxL8GD 9P6urzZ5IP4MZK9sKWxbaPVjmvE3GwJKaJYCY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DPZW5ms+iSISY5xA1g3HW+vL1IpVBadbiqUmmCSPdJohxmtFdoVjEo33uZJrK5VDYK BKZwyipnN+TNjJiVMfGobxCpQVUonuy0BIfKT+m/0hYvo+6VaKlPPT932ha8rsSCzk9p fxSvNANFA3gWWH6yc/Aq+eVF/LQkiT4BeHH9Y= MIME-Version: 1.0 Received: by 10.103.228.19 with SMTP id f19mr460782mur.63.1250200528603; Thu, 13 Aug 2009 14:55:28 -0700 (PDT) In-Reply-To: <4A846206.7010803@FreeBSD.org> References: <200903282317.n2SNHIjI015202@svn.freebsd.org> <4A846206.7010803@FreeBSD.org> Date: Fri, 14 Aug 2009 00:55:28 +0300 Message-ID: <9e20d71e0908131455x62e2d26au52b3e5b0253cdaec@mail.gmail.com> From: Artis Caune To: Doug Barton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org Subject: Re: svn commit: r190514 - head/sys/conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:55:31 -0000 2009/8/13 Doug Barton : >> =C2=A0if [ -n "$svnversion" -a -d "${SRCDIR}/.svn" ] ; then >> - =C2=A0 =C2=A0 svn=3D" r`cd $SRCDIR && $svnversion`" >> + =C2=A0 =C2=A0 # If we are called from the kernel build, limit >> + =C2=A0 =C2=A0 # the scope of svnversion to sys/ . >> + =C2=A0 =C2=A0 if [ -e "${SRCDIR}/sys/conf/newvers.sh" ] ; then > > I missed this when it went through originally, so my apologies for the > late response, but I don't see any way that this first test can ever > not be true. Is there a better way to detect if the script is called > in the buildkernel process? > > Also, what problem are we really trying to solve here? With a > populated cache it takes on average 5 seconds to run all of src, and > just under 1 to do only sys. Is 4 seconds really that important to > save? With a dry cache I'm sure it takes a little longer, but has > anyone actually measured this? How about 'svn info' ? It will also hide M,S suffixes for modified and/or switched working copies. svn=3D" r`svn info $SRCDIR 2>/dev/null | awk '/^Revision:/ {print $2}'`" --=20 Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 21:56:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 736C7106568B for ; Thu, 13 Aug 2009 21:56:04 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id CFF218FC51 for ; Thu, 13 Aug 2009 21:56:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n7DLispj011736; Fri, 14 Aug 2009 01:44:55 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 14 Aug 2009 01:44:54 +0400 (MSD) From: Dmitry Morozovsky To: Andreas Tobler In-Reply-To: <4A847AA5.1030701@fgznet.ch> Message-ID: References: <4A847AA5.1030701@fgznet.ch> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Fri, 14 Aug 2009 01:44:55 +0400 (MSD) Cc: freebsd-current Subject: Re: 8.0-stable/releng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:56:04 -0000 On Thu, 13 Aug 2009, Andreas Tobler wrote: AT> for the record, am I correct that the upcoming 8.0 branch is like this: AT> AT> svn ls svn://svn.freebsd.org/base/stable/ AT> .. AT> 8/ AT> ? AT> AT> And not under 'releng'? AT> AT> I'm a bit confused about naming conventions, releng vs. stable. I have no AT> problem with either, but which one is the one to be used for BETA-3/RC? AT> AT> Is head becoming 9.0 soon? AFAIK, releng/8* will be created (by copying stable/8) just before 8.0-RC -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 21:56:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BF3210656A5 for ; Thu, 13 Aug 2009 21:56:05 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 150038FC4B for ; Thu, 13 Aug 2009 21:56:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n7DLkXPO011762; Fri, 14 Aug 2009 01:46:33 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Fri, 14 Aug 2009 01:46:33 +0400 (MSD) From: Dmitry Morozovsky To: Andreas Tobler In-Reply-To: Message-ID: References: <4A847AA5.1030701@fgznet.ch> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Fri, 14 Aug 2009 01:46:33 +0400 (MSD) Cc: freebsd-current Subject: Re: 8.0-stable/releng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 21:56:05 -0000 On Fri, 14 Aug 2009, Dmitry Morozovsky wrote: DM> AT> for the record, am I correct that the upcoming 8.0 branch is like this: DM> AT> DM> AT> svn ls svn://svn.freebsd.org/base/stable/ DM> AT> .. DM> AT> 8/ DM> AT> ? DM> AT> DM> AT> And not under 'releng'? DM> AT> DM> AT> I'm a bit confused about naming conventions, releng vs. stable. I have no DM> AT> problem with either, but which one is the one to be used for BETA-3/RC? DM> AT> DM> AT> Is head becoming 9.0 soon? DM> DM> AFAIK, releng/8* will be created (by copying stable/8) just before 8.0-RC http://wiki.freebsd.org/SubversionPrimer#head-034326f06fb998e6c69d1ce308f1a14aaed51c7e may sched a bit of light at the whole picture ;) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 22:04:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62F4B1065695; Thu, 13 Aug 2009 22:04:18 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (uffner.com [66.208.243.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0C0488FC52; Thu, 13 Aug 2009 22:04:17 +0000 (UTC) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id n7DLS6sq036591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Aug 2009 17:28:15 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <4A8484E4.6090504@uffner.com> Date: Thu, 13 Aug 2009 17:25:56 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.22) Gecko/20090721 SeaMonkey/1.1.17 MIME-Version: 1.0 To: pf@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: packet forwarding/firewall performance question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 22:04:18 -0000 I am curious what level of performance I should expect from the firewall box described below in terms of packets/sec and bytes/sec. it is an 800 MHz VIA c3 with a Gigabit switch on the inside interface and 20 Mbs symetric Fios on the outside. both interfaces are 100 Mbs. it is running sshd, bsnmpd, sendmail (outbound only), bind9 (serving local domain info & queries from 5-15 machines on the LAN) and isc-dhcpd. it acts as a border firewall/router for a small LAN w/ 5 static external addresses & the rest NATed. Kernel: http://www.uffner.com/temp/GATEWAY.txt dmesg: http://www.uffner.com/temp/dmesg.txt rc.conf: http://www.uffner.com/temp/rc.conf.txt pf.conf: http://www.uffner.com/temp/pf.conf.txt i'm hoping a few people will give me estimates on what kind of throughput i should theoretically expect before i provide any actual test data. also, any suggestions on tuning would be welcome. so far in preliminary tests, enabling polling on the network interfaces reduces my performance slightly both to/from and through the box. net.inet.ip.fastforwarding doesn't seem to make much difference either way but i haven't done very thorough testing of it. increasing net.inet.tcp.sendbuf_max & recvbuf_max may have helped, but again, not sufficiently tested. From owner-freebsd-current@FreeBSD.ORG Thu Aug 13 23:58:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46B7B106568B; Thu, 13 Aug 2009 23:58:00 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 3406C8FC15; Thu, 13 Aug 2009 23:58:00 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KOC00EVM7SN1040@asmtp019.mac.com>; Thu, 13 Aug 2009 15:57:59 -0700 (PDT) Message-id: From: Chuck Swiger To: Tom Uffner In-reply-to: <4A8484E4.6090504@uffner.com> Date: Thu, 13 Aug 2009 15:57:59 -0700 References: <4A8484E4.6090504@uffner.com> X-Mailer: Apple Mail (2.936) Cc: pf@freebsd.org, current@freebsd.org Subject: Re: packet forwarding/firewall performance question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2009 23:58:00 -0000 Hi-- On Aug 13, 2009, at 2:25 PM, Tom Uffner wrote: > it is an 800 MHz VIA c3 with a Gigabit switch on the inside interface > and 20 Mbs symetric Fios on the outside. both interfaces are 100 Mbs. I'd done a bit of testing of a VIA EPIA C3 (either a 600 or 800) with the on-board vr0 and an Intel fxp card, and it seemed to go OK up to ~ 8MB/s aka ~65 megabits/sec with a fairly short IPFW-based firewall doing NAT and suchlike. It's probably OK for your purpose, but the EPIA motherboard I had was somewhat flaky. I'd had the vr0 interface get wedged every few days, and trying to use both ATA channels in an UDMA mode tended to result in a total system hang; using only one ATA device, UDMA-100 was fine. I never ended up putting the box into a production use as a consequence. I've had better luck with something like the Soerkris 480x ... -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 00:00:02 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CFC71065694 for ; Fri, 14 Aug 2009 00:00:02 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 1C8128FC45 for ; Fri, 14 Aug 2009 00:00:01 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C3B8D3E1D5; Thu, 13 Aug 2009 17:00:01 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 7E6532D6010; Thu, 13 Aug 2009 17:00:01 -0700 (PDT) Message-ID: <4A84A901.4010109@elischer.org> Date: Thu, 13 Aug 2009 17:00:01 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dmitry Marakasov References: <20090801022523.GA93222@hades.panopticon> In-Reply-To: <20090801022523.GA93222@hades.panopticon> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: panic in ipfw with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 00:00:02 -0000 Dmitry Marakasov wrote: > Hi! > > Just updated to recent current (date=2009.07.30.12.00.00), and had > a panic in ipfw with minimal network activity (one time the box was > able to get IP via DHCP and panicked on ssh to another host, next > time it panicked right while booting). Rebuilding the kernel with > nooptions IPFIREWALL works nice as a workaround. > > Full text available here: > http://people.freebsd.org/~amdmi3/ipfw-panic.txt > > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc04c0049 in db_fncall (dummy1=1, dummy2=0, dummy3=-1059813280, dummy4=0xe58e0558 "") at /usr/src/sys/ddb/db_command.c:548 > #2 0xc04c042e in db_command (last_cmdp=0xc0ca72bc, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #3 0xc04c0567 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #4 0xc04c223f in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 > #5 0xc088922e in kdb_trap (type=12, code=0, tf=0xe58e0784) at /usr/src/sys/kern/subr_kdb.c:534 > #6 0xc0aea4c6 in trap_fatal (frame=0xe58e0784, eva=28) at /usr/src/sys/i386/i386/trap.c:924 > #7 0xc0aea75a in trap_pfault (frame=0xe58e0784, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:846 > #8 0xc0aeb137 in trap (frame=0xe58e0784) at /usr/src/sys/i386/i386/trap.c:528 > #9 0xc0acf71b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #10 0xc5f80c1c in ipfw_chk (args=0xe58e0a3c) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw2.c:2061 > #11 0xc5f815c3 in ipfw_check_in (arg=0x0, m0=0xe58e0b70, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/modules/ipfw/../../netinet/ipfw/ip_fw_pfil.c:135 > #12 0xc090a071 in pfil_run_hooks (ph=0xc0ceec20, mp=0xe58e0bc4, ifp=0xc56f6800, dir=1, inp=0x0) at /usr/src/sys/net/pfil.c:79 > #13 0xc095c93d in ip_input (m=0xc5dcfe00) at /usr/src/sys/netinet/ip_input.c:497 > #14 0xc09094f3 in netisr_dispatch_src (proto=1, source=0, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:917 > #15 0xc09097a4 in netisr_dispatch (proto=1, m=0xc5dcfe00) at /usr/src/sys/net/netisr.c:1004 > #16 0xc09031a0 in ether_demux (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:896 > #17 0xc09036a2 in ether_input (ifp=0xc56f6800, m=0xc5dcfe00) at /usr/src/sys/net/if_ethersubr.c:755 > #18 0xc053de29 in ale_int_task (arg=0xc55fd000, pending=1) at /usr/src/sys/dev/ale/if_ale.c:2581 > #19 0xc089409f in taskqueue_run (queue=0xc574dd00) at /usr/src/sys/kern/subr_taskqueue.c:282 > #20 0xc089428d in taskqueue_thread_loop (arg=0xc55fda2c) at /usr/src/sys/kern/subr_taskqueue.c:403 > #21 0xc08350a9 in fork_exit (callout=0xc08941d4 , arg=0xc55fda2c, frame=0xe58e0d38) at /usr/src/sys/kern/kern_fork.c:838 > #22 0xc0acf790 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 > found the fix I think.. in line 2061 of ip_fw2.c in the crhold() the argument should be pcb->inp_cred, not inp->cred 2059 if (pcb != NULL) { 2060 *uc = crhold(inp->inp_cred); <--s/inp/pcb/ 2061 *ugid_lookupp = 1; 2062 } The change that brought in the bug was: SVN rev 194498 on 2009-06-19 17:10:35Z by brooks as part of a bigger change sweep. unfortunatly it included this typo/bug an incoming syn, or unexpected UDP packet will not have a pre-exisiting pcb/socket so inp this will be NULL and so will pcb. Unfortunalty we only test pcb against beign null. The old code here also used pcb. From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 00:42:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6943A106568C for ; Fri, 14 Aug 2009 00:42:24 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 4229F8FC45 for ; Fri, 14 Aug 2009 00:42:24 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MbksB-0008Ct-L4 for freebsd-current@freebsd.org; Thu, 13 Aug 2009 17:42:23 -0700 Message-ID: <24963045.post@talk.nabble.com> Date: Thu, 13 Aug 2009 17:42:23 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <4A847AA5.1030701@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4A847AA5.1030701@fgznet.ch> Subject: Re: 8.0-stable/releng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 00:42:24 -0000 Andreas Tobler-5 wrote: > > Hi, > > for the record, am I correct that the upcoming 8.0 branch is like this: > > svn ls svn://svn.freebsd.org/base/stable/ > .. > 8/ > ? > > And not under 'releng'? > > I'm a bit confused about naming conventions, releng vs. stable. I have > no problem with either, but which one is the one to be used for BETA-3/RC? > > Is head becoming 9.0 soon? > > TIA, > Andreas > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > http://www.freebsd.org/releng/index.html -- View this message in context: http://www.nabble.com/8.0-stable-releng--tp24962689p24963045.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 00:53:37 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E420106568C for ; Fri, 14 Aug 2009 00:53:37 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3A9F48FC4F for ; Fri, 14 Aug 2009 00:53:36 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mbl2z-0001ey-Qc; Fri, 14 Aug 2009 04:53:33 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 71C71B860; Fri, 14 Aug 2009 04:53:32 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 6AD34108842; Fri, 14 Aug 2009 04:53:24 +0400 (MSD) Date: Fri, 14 Aug 2009 04:53:24 +0400 From: Dmitry Marakasov To: Julian Elischer Message-ID: <20090814005324.GA1552@hades.panopticon> References: <20090801022523.GA93222@hades.panopticon> <4A84A901.4010109@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4A84A901.4010109@elischer.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: panic in ipfw with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 00:53:37 -0000 * Julian Elischer (julian@elischer.org) wrote: > found the fix I think.. > > in line 2061 of ip_fw2.c in the crhold() > the argument should be pcb->inp_cred, not inp->cred > > 2059 if (pcb != NULL) { > 2060 *uc = crhold(inp->inp_cred); <--s/inp/pcb/ > 2061 *ugid_lookupp = 1; > 2062 } Confirmed, this fixes the problem. Filtering by gid works and no panics. Thanks a lot! -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 01:25:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73A6E106564A; Fri, 14 Aug 2009 01:25:39 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 02C2C8FC3A; Fri, 14 Aug 2009 01:25:38 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E1Pa0u052909; Thu, 13 Aug 2009 21:25:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E1PaY0068535; Thu, 13 Aug 2009 21:25:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9CA4E7302F; Thu, 13 Aug 2009 21:25:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814012536.9CA4E7302F@freebsd-current.sentex.ca> Date: Thu, 13 Aug 2009 21:25:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 01:25:39 -0000 TB --- 2009-08-14 00:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 00:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-08-14 00:20:00 - cleaning the object tree TB --- 2009-08-14 00:20:35 - cvsupping the source tree TB --- 2009-08-14 00:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-08-14 00:20:47 - building world TB --- 2009-08-14 00:20:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 00:20:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 00:20:47 - TARGET=arm TB --- 2009-08-14 00:20:47 - TARGET_ARCH=arm TB --- 2009-08-14 00:20:47 - TZ=UTC TB --- 2009-08-14 00:20:47 - __MAKE_CONF=/dev/null TB --- 2009-08-14 00:20:47 - cd /src TB --- 2009-08-14 00:20:47 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 00:20:50 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 01:25:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 01:25:36 - ERROR: failed to build world TB --- 2009-08-14 01:25:36 - 3030.63 user 369.23 system 3935.36 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 02:13:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84694106568E for ; Fri, 14 Aug 2009 02:13:52 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4148FC16 for ; Fri, 14 Aug 2009 02:13:51 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69) (envelope-from ) id 1MbmIg-0003RT-3m; Fri, 14 Aug 2009 06:13:50 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 7BCD3B865; Fri, 14 Aug 2009 06:13:48 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 61193108842; Fri, 14 Aug 2009 06:13:40 +0400 (MSD) Date: Fri, 14 Aug 2009 06:13:40 +0400 From: Dmitry Marakasov To: "Arno J. Klaassen" Message-ID: <20090814021340.GA1275@hades.panopticon> References: <20090123221826.GB30982@deprived.panopticon> <20090126144044.GB6054@hades.panopticon> <20090127164617.GA93440@hades.panopticon> <20090128042148.GA1256@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20090128042148.GA1256@hades.panopticon> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Data corruption with checksum offloading enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 02:13:52 -0000 * Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: > 3. 512MB random bytes with NFS: 2/5 correct Just for the record: this no longer seems to be a problem. Recent 8-STABLE, ale works fine with rxcsum/txcsum, at least I could not reproduce the problem with similar tests as before. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 02:20:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAB32106568E for ; Fri, 14 Aug 2009 02:20:52 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 5667B8FC43 for ; Fri, 14 Aug 2009 02:20:52 +0000 (UTC) Received: by qyk29 with SMTP id 29so1002565qyk.3 for ; Thu, 13 Aug 2009 19:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=gc2fRajp4N0R13McA0xfQRXXWZuyBFDq/c0e764LHQQ=; b=sRUbRtWAg0XVT6gH9FbsY8QO+yoGeGnCqgBEam1eK2dCUn6Y9Frbhy1Q037fb5NoXZ wuUrgox1Y3y0woY0upDCAhwfaCp0QYrsz1ska6sxfPuE5aHfvatkxKgcdpRz5fmk5Y3v gkBLmpeNYAMDi3dJAWyWdWRusyMKgr4ZPxYHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=SpD3aW5WkSKFnX3m6yD3PpWigE2nRKrcwrYGgOWBU6lHUpF5CpN+T2YM9JBDBBFRDw 8cuF0jtgt9hnAcjsCJB4Iga1K2C88zBe/K7VevE4BcQuoPaamsslG87K/i5lRKeklcBA xf4gWFcz4ki/yZOteXbfJpUj5fTv6zB3tD3Ps= Received: by 10.224.8.140 with SMTP id h12mr1905282qah.249.1250216451774; Thu, 13 Aug 2009 19:20:51 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id 5sm2314815qwg.50.2009.08.13.19.20.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 13 Aug 2009 19:20:51 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 17A25B80CB; Thu, 13 Aug 2009 23:20:47 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Thu, 13 Aug 2009 23:20:47 -0300 (BRT) Message-ID: <521743b0e93ba19c3e9d0226f5de1660.squirrel@10.1.1.10> In-Reply-To: References: Date: Thu, 13 Aug 2009 23:20:47 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Update - RELENG_8 open for business (but you probably noticed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 02:20:52 -0000 On Thu, August 13, 2009 11:29, Robert Watson wrote: > > Just a quick status update from the release engineering team: > > As was discussed on this mailing list, problems with the Subversion->CVS > exporter arose during the RELENG_8 branching process. These have now been > resolved, and for the last day or so, pending bug fixes have been rushing > into > the branch. We'll wait a couple more days while things catch up, and then > cut > 8.0 BETA3. > > You can read more about the status of 8.0, including tracking pending and > approved fixes, on the 8.0 release engineering wiki: > > http://wiki.freebsd.org/8.0TODO > > Your help in testing, diagnosing, and fixing FreeBSD 8.x problems *before* > the > release is much appreciated! hi Robert, this change from cvs to svn may solve one of my problem of not having direct connection to the internet. where I work we have a proxy upstream, and just http/https goes out. this svn rep can be used right away (same codebase?) and does it have this feature ? how to use if so ? I've seen some svn reps where svn co http://lalalalalala.caaaa/thecode would work great. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 02:44:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFE6B1065691; Fri, 14 Aug 2009 02:44:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id A2B4B8FC15; Fri, 14 Aug 2009 02:44:32 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E2iUlL057897; Thu, 13 Aug 2009 22:44:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E2iUiD099781; Thu, 13 Aug 2009 22:44:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5BB7D7302F; Thu, 13 Aug 2009 22:44:30 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814024430.5BB7D7302F@freebsd-current.sentex.ca> Date: Thu, 13 Aug 2009 22:44:30 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 02:44:33 -0000 TB --- 2009-08-14 01:25:36 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 01:25:36 - starting HEAD tinderbox run for i386/i386 TB --- 2009-08-14 01:25:36 - cleaning the object tree TB --- 2009-08-14 01:26:21 - cvsupping the source tree TB --- 2009-08-14 01:26:21 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-08-14 01:26:30 - building world TB --- 2009-08-14 01:26:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 01:26:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 01:26:30 - TARGET=i386 TB --- 2009-08-14 01:26:30 - TARGET_ARCH=i386 TB --- 2009-08-14 01:26:30 - TZ=UTC TB --- 2009-08-14 01:26:30 - __MAKE_CONF=/dev/null TB --- 2009-08-14 01:26:30 - cd /src TB --- 2009-08-14 01:26:30 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 01:26:31 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 02:44:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 02:44:30 - ERROR: failed to build world TB --- 2009-08-14 02:44:30 - 3777.65 user 368.91 system 4733.44 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 02:57:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8ACBB106568D for ; Fri, 14 Aug 2009 02:57:24 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by mx1.freebsd.org (Postfix) with SMTP id 4B6098FC4B for ; Fri, 14 Aug 2009 02:57:24 +0000 (UTC) Received: (qmail 65331 invoked from network); 14 Aug 2009 02:57:23 -0000 Received: from unknown (HELO soul.local.inet) (webmaster@69.108.138.13 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 02:57:23 -0000 X-YMail-OSG: YEeul4UVM1kn.jRUyQptocOruBJESw0FEzcn83vp.42h9rlBeWFob9Mklhu1cAkBAa2avluaLyX3lyw4d5cb7N5cXJE6cx5Y35BAOw1NOG4idLUA2pwTOaPy99xSZ88hCSm6dN1Goel2PXC.JwMlF9xOxS1HLz8HIJjiZtcbg6m8AwTWEu5assDRHnrwvVOrsEVXguDdqqR5LzDmP1IB3ObdEIePBmBHtUtkPk4qnF1H_nwkGCBdzYVMwMoToYSqg6w59Fkb2_5rWLVW5SwCFjCC2h.PZMirMSylpbFBs_ba4ZH9g_rnW1E2JIEQecMW59BSFYCIq38EeCwDs6rLvDY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A84D245.5050703@doghouserepair.com> Date: Thu, 13 Aug 2009 19:56:05 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.22 (X11/20090812) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> In-Reply-To: <20090812214932.GH55129@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 02:57:24 -0000 Pyun YongHyeon wrote: > On Wed, Jul 22, 2009 at 03:26:43PM -0700, Ryan Rogers wrote: >> Weongyo Jeong wrote: >>> On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: >>>>> svn co svn://svn.freebsd.org/base/head >>>>> svn merge -c -193289 >>>>> >>>>> Thereafter, in the root of the repo: >>>>> svn up >>>>> svn merge >>>> Confirmed, running the above set of commands fixed my 88E1116 nfe problem >>>> everything works as it should now. thanks guys for the help. >>>> >>>> Sam Fourman Jr. >>>> >>>> ps. svn was WAY faster than csup, I think I am going to use svn all >>>> the time now. >>> I know that yongari@ knows what the problem is and the solution but he >>> could not access the internet right now due to relocation to USA. >>> >>> It looks he is busy with looking for house and etc... >>> >>> regards, >>> Weongyo Jeong >>> >>> >>> >> Well, the good news is that r193289 was the only thing keeping my nics >> from working. I was able to update to current as of today and revert >> that patch, and everything is working nicely now. So I'll just keep my >> eye on the commit logs and patch that up by hand whenever I need to >> update until yongari is able to get situated. >> > > Would you try attached patch and let me know how it goes on your > box? > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" The patch works great, thanks! From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 04:04:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D539A106568D; Fri, 14 Aug 2009 04:04:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 975808FC56; Fri, 14 Aug 2009 04:04:45 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E44gTP033853; Fri, 14 Aug 2009 00:04:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E44gOP066898; Fri, 14 Aug 2009 00:04:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 986FD7302F; Fri, 14 Aug 2009 00:04:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814040442.986FD7302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 00:04:42 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 04:04:46 -0000 TB --- 2009-08-14 02:44:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 02:44:30 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-08-14 02:44:30 - cleaning the object tree TB --- 2009-08-14 02:45:08 - cvsupping the source tree TB --- 2009-08-14 02:45:08 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-08-14 02:45:18 - building world TB --- 2009-08-14 02:45:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 02:45:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 02:45:18 - TARGET=pc98 TB --- 2009-08-14 02:45:18 - TARGET_ARCH=i386 TB --- 2009-08-14 02:45:18 - TZ=UTC TB --- 2009-08-14 02:45:18 - __MAKE_CONF=/dev/null TB --- 2009-08-14 02:45:18 - cd /src TB --- 2009-08-14 02:45:18 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 02:45:20 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 04:04:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 04:04:42 - ERROR: failed to build world TB --- 2009-08-14 04:04:42 - 3738.09 user 372.40 system 4811.95 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 05:09:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA1A11065691; Fri, 14 Aug 2009 05:09:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8DDFB8FC67; Fri, 14 Aug 2009 05:09:02 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E590rE035338; Fri, 14 Aug 2009 01:09:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E58xNU082746; Fri, 14 Aug 2009 01:08:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BDE357302F; Fri, 14 Aug 2009 01:08:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814050859.BDE357302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 01:08:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 05:09:03 -0000 TB --- 2009-08-14 04:04:42 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 04:04:42 - starting HEAD tinderbox run for mips/mips TB --- 2009-08-14 04:04:42 - cleaning the object tree TB --- 2009-08-14 04:05:02 - cvsupping the source tree TB --- 2009-08-14 04:05:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-08-14 04:05:09 - building world TB --- 2009-08-14 04:05:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 04:05:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 04:05:09 - TARGET=mips TB --- 2009-08-14 04:05:09 - TARGET_ARCH=mips TB --- 2009-08-14 04:05:09 - TZ=UTC TB --- 2009-08-14 04:05:09 - __MAKE_CONF=/dev/null TB --- 2009-08-14 04:05:09 - cd /src TB --- 2009-08-14 04:05:09 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 04:05:11 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 05:08:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 05:08:59 - ERROR: failed to build world TB --- 2009-08-14 05:08:59 - 2959.47 user 335.62 system 3856.79 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 06:04:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28C901065692 for ; Fri, 14 Aug 2009 06:04:21 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id ABA398FC48 for ; Fri, 14 Aug 2009 06:04:20 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2D4AE.dip.t-dialin.net [217.226.212.174]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 39AF08440A6; Fri, 14 Aug 2009 08:04:05 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BC0B711F7BB; Fri, 14 Aug 2009 08:04:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1250229841; bh=RgjhvV4ZPkUk37BC7JLRpnrCgeGkMdztCGo0Las90ng=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=thp1VZ7jqk+7mzyynsOpXRKqY38mrgS/SdrGqrYShbD0ncyU5EXpwpUb0PMsJfIy3 UITbviuDAvjxkVObYJvQceWd0E2dlmscqlpp0PQHRqktujLtBCFnU8UAU18Ak7RlR1 MAhxIgpC1zTvzEIKTVMdhaw3DVOu5Pmv94YeB+RVARzBXE311gqDcq9hsHDcqkxGB7 AdtLw1BkP+wvfWYstM5/WWSIY5df28hAXyYm2iWsEcK0pe1rnJ3ixIPHrmw7c2YXGG V6Xno/6S3OcCF8TZBZVrsReRfqBjaT/MvMjj3q0ND4oUJvKKgFAaZGNeyVc3YPDuKR IZBm/iPCzjFNg== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n7E641sA045853; Fri, 14 Aug 2009 08:04:01 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 14 Aug 2009 08:04:00 +0200 Message-ID: <20090814080400.20646vxm44n78b8c@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 14 Aug 2009 08:04:00 +0200 From: Alexander Leidinger To: Andreas Tobler References: <4A832C70.4030600@fgznet.ch> <20090813081538.5361241c6z2lqcn4@webmail.leidinger.net> <4A8465EF.7030604@fgznet.ch> In-Reply-To: <4A8465EF.7030604@fgznet.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 39AF08440A6.C06AC X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.439, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1250834646.1647@jCuBgmkQVldi5ZrkVDjtTQ X-EBL-Spam-Status: No Cc: freebsd-current Subject: Re: tools/kerneldoc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 06:04:21 -0000 Quoting Andreas Tobler (from Thu, 13 Aug 2009 21:13:51 +0200): > Alexander Leidinger wrote: >> Quoting Andreas Tobler (from Wed, 12 Aug >> 2009 22:56:16 +0200): >> >>> Hi, >>> >>> does anybody care about this 'kerneldoc' package? >> >> [...] >> >>> I then dived into the subsys dir and started a 'make all'. >>> >>> Here too, I failed since a few .m files are no more or they are >>> placed on a different place. Well, this was easy, more or less. >>> Commenting them made the build work, but this is only half the >>> truth, what about the new .m files? >> >> I have patches for the subsys part. A little bit more than only the >> .m files fix: >> http://www.leidinger.net/FreeBSD/current/patches/dox.diff > > Thanks, I tried it and I was surprised how long such a build took. > Well, html and latex more than 5 hours on a p4 2.8GHz. And the > amount of data is also huge, nearly 2GB of data. Normally you need only one of them. > Could you enlight me with the meaning of the toplevel kerneldoc, is > this kerneldoc package meant as a whole or is the benefit only in > the subsys part? When I was looking at creating the doxygen stuff, I noticed the kerneldoc part. For my taste it was too huge. Most people are interested in specific subsystems, not about everything (those who really need everything are the minority). For this reason I created the subsys part. Not every subsystem is available there, but if someone submits the files for a missing one, I will have a look at them. Bye, Alexander. -- Automobile, n.: A four-wheeled vehicle that runs up hills and down pedestrians. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 06:21:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CCD6106568C for ; Fri, 14 Aug 2009 06:21:18 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4389C8FC4D for ; Fri, 14 Aug 2009 06:21:16 +0000 (UTC) Received: from [41.161.16.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MbqA5-0007UN-OM for current@freebsd.org; Fri, 14 Aug 2009 08:21:13 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbqAJ-0001Cm-0j for current@freebsd.org; Fri, 14 Aug 2009 08:21:27 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Fri, 14 Aug 2009 08:21:27 +0200 Message-Id: Cc: Subject: panic in netisr (I think) + DUMP FAILED (ERROR 6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 06:21:18 -0000 Hi I finally hooked up a console to this machine because its dumps have been broken or corrupted for many months. Sadly there isn't much more infonmation than this console capture. Fatal trap 12: page fault while in kernel mode cpuid = 10; apic id = 0a fault virtual address = 0x1f5cd38 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff802efbee stack pointer = 0x28:0xffffff81ccae4970 frame pointer = 0x28:0xffffff81ccae4990 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (irq258: bce2) trap number = 12 panic: page fault cpuid = 10 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 trap_fatal() at trap_fatal+0x2ad trap_pfault() at trap_pfault+0x294 trap() at trap+0x2b4 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0xffffffff802efbee, rsp = 0xffffff81ccae4970, rbp = 0xffffff81ccae4990 --- _mtx_lock_sleep() at _mtx_lock_sleep+0x4e netisr_queue_internal() at netisr_queue_internal+0xe8 netisr_queue_src() at netisr_queue_src+0x42 netisr_dispatch_src() at netisr_dispatch_src+0x125 ether_demux() at ether_demux+0x14c ether_input() at ether_input+0x1e0 ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x1e0 bce_intr() at bce_intr+0x398 intr_event_execute_handlers() at intr_event_execute_handlers+0x100 ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x117 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff81ccae4d30, rbp = 0 --- Uptime: 6d13h28m14s Physical memory: 16370 MB Dumping 3069 MB:carp4: link state changed to UP carp9: link state changed to UP 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814carp4: link state changed to DOWN carp9: link state changed to DOWN 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 2222 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14Attempt to write outside dump device boundaries. ** DUMP FAILED (ERROR 6) ** I'm not sure why the dump failed - there's more than enough space in the swap partition for all memory: [firewall2.jnb1] /usr/src # swapinfo -h Device 1K-blocks Used Avail Capacity /dev/mfid0s1b 25165824 0B 24G 0% Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 06:31:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92B6C106568F; Fri, 14 Aug 2009 06:31:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 54FED8FC56; Fri, 14 Aug 2009 06:31:40 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E6Vbnm037037; Fri, 14 Aug 2009 02:31:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E6VbH8033642; Fri, 14 Aug 2009 02:31:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B39877302F; Fri, 14 Aug 2009 02:31:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814063137.B39877302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 02:31:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 06:31:40 -0000 TB --- 2009-08-14 05:09:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 05:09:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-08-14 05:09:00 - cleaning the object tree TB --- 2009-08-14 05:09:34 - cvsupping the source tree TB --- 2009-08-14 05:09:34 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-08-14 05:09:43 - building world TB --- 2009-08-14 05:09:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 05:09:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 05:09:43 - TARGET=powerpc TB --- 2009-08-14 05:09:43 - TARGET_ARCH=powerpc TB --- 2009-08-14 05:09:43 - TZ=UTC TB --- 2009-08-14 05:09:43 - __MAKE_CONF=/dev/null TB --- 2009-08-14 05:09:43 - cd /src TB --- 2009-08-14 05:09:43 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 05:09:45 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 06:31:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 06:31:37 - ERROR: failed to build world TB --- 2009-08-14 06:31:37 - 3896.80 user 364.78 system 4957.45 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 07:44:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 447CA106568F for ; Fri, 14 Aug 2009 07:44:02 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail02.adl6.internode.on.net (ipmail02.adl6.internode.on.net [203.16.214.140]) by mx1.freebsd.org (Postfix) with ESMTP id BCBFB8FC3D for ; Fri, 14 Aug 2009 07:44:01 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAL+xhEqWZZrw/2dsb2JhbADAa5JLhBkF X-IronPort-AV: E=Sophos;i="4.43,379,1246804200"; d="scan'208";a="19934290" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail02.adl6.internode.on.net with ESMTP; 14 Aug 2009 17:13:59 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 50F4C5C45; Fri, 14 Aug 2009 17:43:58 +1000 (EST) Date: Fri, 14 Aug 2009 17:43:58 +1000 From: Emil Mikulic To: Nenhum_de_Nos Message-ID: <20090814074358.GA24969@dmr.ath.cx> References: <521743b0e93ba19c3e9d0226f5de1660.squirrel@10.1.1.10> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521743b0e93ba19c3e9d0226f5de1660.squirrel@10.1.1.10> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Update - RELENG_8 open for business (but you probably noticed) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 07:44:02 -0000 On Thu, Aug 13, 2009 at 11:20:47PM -0300, Nenhum_de_Nos wrote: > this change from cvs to svn may solve one of my problem of not having > direct connection to the internet. where I work we have a proxy upstream, > and just http/https goes out. this svn rep can be used right away (same > codebase?) and does it have this feature ? how to use if so ? Try: http://svn.freebsd.org/base/ > I've seen some svn reps where svn co http://lalalalalala.caaaa/thecode > would work great. I've seen some corporate proxies where this didn't work because svn uses some of the more exotic WebDAV methods, not just plain HTTP GET. ;) --Emil From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 08:10:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C91B8106568B for ; Fri, 14 Aug 2009 08:10:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 80A058FC43 for ; Fri, 14 Aug 2009 08:10:06 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id D156641C667; Fri, 14 Aug 2009 10:10:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id Uz1jv6Y+rQPO; Fri, 14 Aug 2009 10:10:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 73B3941C65E; Fri, 14 Aug 2009 10:10:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 07AD64448EC; Fri, 14 Aug 2009 08:07:26 +0000 (UTC) Date: Fri, 14 Aug 2009 08:07:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Ian Freislich In-Reply-To: Message-ID: <20090814080044.A93661@maildrop.int.zabbadoz.net> References: X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: panic in netisr (I think) + DUMP FAILED (ERROR 6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 08:10:06 -0000 On Fri, 14 Aug 2009, Ian Freislich wrote: Hi, > I finally hooked up a console to this machine because its dumps > have been broken or corrupted for many months. Sadly there isn't > much more infonmation than this console capture. > > > Fatal trap 12: page fault while in kernel mode > cpuid = 10; apic id = 0a > fault virtual address = 0x1f5cd38 ... > Uptime: 6d13h28m14s this has been fixed two days ago. Seeing your uptime you do not have the fix. Please update to latest RELENG_8 or HEAD. See r196118 (HEAD) or r196119 (stbale/8): http://svn.freebsd.org/viewvc/base?view=revision&revision=196118 http://svn.freebsd.org/viewvc/base?view=revision&revision=196119 /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 08:47:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 906901065697 for ; Fri, 14 Aug 2009 08:47:01 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 269458FC45 for ; Fri, 14 Aug 2009 08:47:00 +0000 (UTC) Received: from [41.161.16.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MbsR8-000896-Bt; Fri, 14 Aug 2009 10:46:58 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbsRG-0001Ra-AY; Fri, 14 Aug 2009 10:47:06 +0200 To: "Bjoern A. Zeeb" From: Ian FREISLICH In-Reply-To: <20090814080044.A93661@maildrop.int.zabbadoz.net> References: <20090814080044.A93661@maildrop.int.zabbadoz.net> X-Attribution: BOFH Date: Fri, 14 Aug 2009 10:47:05 +0200 Message-Id: Cc: FreeBSD current mailing list Subject: Re: panic in netisr (I think) + DUMP FAILED (ERROR 6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 08:47:01 -0000 "Bjoern A. Zeeb" wrote: > On Fri, 14 Aug 2009, Ian Freislich wrote: > > Hi, > > > I finally hooked up a console to this machine because its dumps > > have been broken or corrupted for many months. Sadly there isn't > > much more infonmation than this console capture. > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 10; apic id = 0a > > fault virtual address = 0x1f5cd38 > ... > > Uptime: 6d13h28m14s > > this has been fixed two days ago. Seeing your uptime you do not have > the fix. Please update to latest RELENG_8 or HEAD. I suspected that. Do you have any idea why kernel dumps are not working as shown in the OP? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 08:59:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF277106568B for ; Fri, 14 Aug 2009 08:59:08 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 9F14D8FC4B for ; Fri, 14 Aug 2009 08:59:08 +0000 (UTC) Received: from gluon.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id B05CA8463; Fri, 14 Aug 2009 08:39:30 +0000 (UTC) Date: Fri, 14 Aug 2009 09:39:16 +0100 From: Bruce Cran To: Thomas Backman Message-ID: <20090814093916.11c89255@gluon.draftnet> In-Reply-To: <94F61AF3-E0D2-4BCD-8C74-07C3C0752A47@exscape.org> References: <665DE2F7-0899-40B7-9129-2082F2188D3E@exscape.org> <94F61AF3-E0D2-4BCD-8C74-07C3C0752A47@exscape.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: ps -axl during textdumps occasionally segfaults with a HUGE ps.core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 08:59:08 -0000 On Thu, 30 Jul 2009 09:00:50 +0200 Thomas Backman wrote: > On Jul 29, 2009, at 22:19, Thomas Backman wrote: > > > All the info I happen to have: > > > > (from core.txt.X) > > "ps -axl > > > > Segmentation fault (core dumped)" > > > > The last core I got (/ps.core) was 1076211712 bytes (1026 MiB). > > > > Anyone else with this problem? > > Unfortunately, I deleted the most recent core and so can't gdb it, > > at least not right now. I did try it on the first one, but got a > > very broken backtrace. > > > > Regards, > > Thomas > More detail: > > Core was generated by `ps'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libm.so.5...(no debugging symbols > found)...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libkvm.so.5...(no debugging symbols > found)...done. > Loaded symbols for /lib/libkvm.so.5 > Reading symbols from /lib/libc.so.7...(no debugging symbols > found)...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x00000008009603a6 in bcopy () from /lib/libc.so.7 > (gdb) bt > #0 0x00000008009603a6 in bcopy () from /lib/libc.so.7 > #1 0x0000000800770141 in _kvm_freeprocs () from /lib/libkvm.so.5 > #2 0x0000000800770870 in kvm_getprocs () from /lib/libkvm.so.5 > #3 0x0000000000405322 in uname () > #4 0x0000000000401f0e in ?? () > #5 0x0000000800539000 in ?? () > #6 0x0000000000000000 in ?? () > #7 0x0000000000000006 in ?? () > #8 0x00007fffffffef40 in ?? () > #9 0x00007fffffffef43 in ?? () > #10 0x00007fffffffef46 in ?? () > #11 0x00007fffffffef5b in ?? () > #12 0x00007fffffffef5e in ?? () > #13 0x00007fffffffef72 in ?? () > #14 0x0000000000000000 in ?? () > ... > #586 0x0000000000000000 in ?? () > #587 0x0073702f6e69622f in ?? () > #588 0x247c8d48002454ff in ?? () > #589 0x01a1c0c748006a10 in ?? () > #590 0x66fdebf4050f0000 in ?? () > #591 0x9066669066669066 in ?? () > #592 0x00007fffffffeda0 in ?? () > #593 0x0000000000000006 in ?? () > #594 0x00007fffffffedd8 in ?? () > #595 0x0000000000000004 in ?? () > Cannot access memory at address 0x800000000000 > (gdb) > > Not exactly a lot of useful info. Still, anyone else noticed this? > Oh, and this core was *exactly* as big as the previous one > (1076211712 bytes)... > I'm seeing 'ps -axl' segfault too - it seems operating on core files is broken, because unsurprisingly I can get it to segfault just by running 'ps -axl -M /var/crash/vmcore.2'. During boot I only get a partial core file (350MB) because it fills my root partition, but the full core is 1GB. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 09:06:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 366B31065691 for ; Fri, 14 Aug 2009 09:06:36 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id B6CDB8FC56 for ; Fri, 14 Aug 2009 09:06:35 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:33234 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Mbsil-0002nH-3r; Fri, 14 Aug 2009 11:05:13 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 857F1144C0; Fri, 14 Aug 2009 11:05:07 +0200 (CEST) Message-Id: <9CBAB74F-45CD-4B20-835C-A77C9D01B5D1@exscape.org> From: Thomas Backman To: Bruce Cran In-Reply-To: <20090814093916.11c89255@gluon.draftnet> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 11:05:05 +0200 References: <665DE2F7-0899-40B7-9129-2082F2188D3E@exscape.org> <94F61AF3-E0D2-4BCD-8C74-07C3C0752A47@exscape.org> <20090814093916.11c89255@gluon.draftnet> X-Mailer: Apple Mail (2.936) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1Mbsil-0002nH-3r. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Mbsil-0002nH-3r 0c381e8318bf509d94bec55333632ef9 Cc: FreeBSD current Subject: Re: ps -axl during textdumps occasionally segfaults with a HUGE ps.core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 09:06:36 -0000 On Aug 14, 2009, at 10:39, Bruce Cran wrote: > On Thu, 30 Jul 2009 09:00:50 +0200 > Thomas Backman wrote: > >> On Jul 29, 2009, at 22:19, Thomas Backman wrote: >> >>> All the info I happen to have: >>> >>> (from core.txt.X) >>> "ps -axl >>> >>> Segmentation fault (core dumped)" >>> >>> The last core I got (/ps.core) was 1076211712 bytes (1026 MiB). >>> >>> Anyone else with this problem? >>> Unfortunately, I deleted the most recent core and so can't gdb it, >>> at least not right now. I did try it on the first one, but got a >>> very broken backtrace. >>> >>> Regards, >>> Thomas >> More detail: >> >> Core was generated by `ps'. >> Program terminated with signal 11, Segmentation fault. >> Reading symbols from /lib/libm.so.5...(no debugging symbols >> found)...done. >> Loaded symbols for /lib/libm.so.5 >> Reading symbols from /lib/libkvm.so.5...(no debugging symbols >> found)...done. >> Loaded symbols for /lib/libkvm.so.5 >> Reading symbols from /lib/libc.so.7...(no debugging symbols >> found)...done. >> Loaded symbols for /lib/libc.so.7 >> Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols >> found)...done. >> Loaded symbols for /libexec/ld-elf.so.1 >> #0 0x00000008009603a6 in bcopy () from /lib/libc.so.7 >> (gdb) bt >> #0 0x00000008009603a6 in bcopy () from /lib/libc.so.7 >> #1 0x0000000800770141 in _kvm_freeprocs () from /lib/libkvm.so.5 >> #2 0x0000000800770870 in kvm_getprocs () from /lib/libkvm.so.5 >> #3 0x0000000000405322 in uname () >> #4 0x0000000000401f0e in ?? () >> #5 0x0000000800539000 in ?? () >> #6 0x0000000000000000 in ?? () >> #7 0x0000000000000006 in ?? () >> #8 0x00007fffffffef40 in ?? () >> #9 0x00007fffffffef43 in ?? () >> #10 0x00007fffffffef46 in ?? () >> #11 0x00007fffffffef5b in ?? () >> #12 0x00007fffffffef5e in ?? () >> #13 0x00007fffffffef72 in ?? () >> #14 0x0000000000000000 in ?? () >> ... >> #586 0x0000000000000000 in ?? () >> #587 0x0073702f6e69622f in ?? () >> #588 0x247c8d48002454ff in ?? () >> #589 0x01a1c0c748006a10 in ?? () >> #590 0x66fdebf4050f0000 in ?? () >> #591 0x9066669066669066 in ?? () >> #592 0x00007fffffffeda0 in ?? () >> #593 0x0000000000000006 in ?? () >> #594 0x00007fffffffedd8 in ?? () >> #595 0x0000000000000004 in ?? () >> Cannot access memory at address 0x800000000000 >> (gdb) >> >> Not exactly a lot of useful info. Still, anyone else noticed this? >> Oh, and this core was *exactly* as big as the previous one >> (1076211712 bytes)... >> > > I'm seeing 'ps -axl' segfault too - it seems operating on core files > is > broken, because unsurprisingly I can get it to segfault just by > running > 'ps -axl -M /var/crash/vmcore.2'. During boot I only get a partial > core file (350MB) because it fills my root partition, but the full > core > is 1GB. > > -- > Bruce Cran Looks like you're right! I tried the same deal: [root@chaos ~]# time ps -axl -M /var/crash/vmcore.45.NMAP_SCAN Segmentation fault: 11 (core dumped) real 0m46.005s user 0m0.000s sys 0m7.753s (All the time taken, according to the hard drive noise, was to save the core dump, which existed long before it returned to the shell. [root@chaos ~]# gdb /bin/ps ps.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Core was generated by `ps'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libkvm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libkvm.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0000000800960b9b in strlen () from /lib/libc.so.7 (gdb) bt #0 0x0000000800960b9b in strlen () from /lib/libc.so.7 #1 0x0000000800959812 in open () from /lib/libc.so.7 #2 0x00000008008f0546 in vsnprintf () from /lib/libc.so.7 #3 0x0000000800772d79 in _kvm_err () from /lib/libkvm.so.5 #4 0x00000008007707f7 in kvm_getprocs () from /lib/libkvm.so.5 #5 0x0000000000405322 in uname () #6 0x0000000000401f0e in ?? () #7 0x0000000800539000 in ?? () #8 0x0000000000000000 in ?? () #9 0x0000000000000000 in ?? () ... #639 0x9066669066669066 in ?? () #640 0x00007fffffffec38 in ?? () #641 0x0000000000000004 in ?? () #642 0x00007fffffffec60 in ?? () #643 0x0000000000000012 in ?? () Cannot access memory at address 0x800000000000 Crash in strlen() this time, rather than bcopy(), but uname() in still the root cause, I guess...? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 09:18:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 367E3106568B for ; Fri, 14 Aug 2009 09:18:53 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id C04D08FC43 for ; Fri, 14 Aug 2009 09:18:52 +0000 (UTC) Received: by fxm24 with SMTP id 24so1353702fxm.36 for ; Fri, 14 Aug 2009 02:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=tIb9YLLU2k/nnUqUTrKkZ/bz08D6D21AsOTkryNDEAk=; b=IDLsy5IIl3ZYwljrtMshw8gyxbB/hzXmLqpWXAxQa4dI06Y8S5k0549xpa/TI9Z0dZ F9O+mulWhlD1zhHWMith50narPGQ3OwGbpBPd2csxerW6AsWV0tgZLnxb1DbvjhfHe3z 52ZB/IF4PPdmsSQQmE69/PGMs21sh7vorSX94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=IjE/eJ6JhPv29jHEbgyU1NLDt8G82Mv4e8OBMg6eikid8FBqa644hLFdIKJoy1rlqG ufWSUPzyjuzA9xkOets6UcLc339lu2i4nnRQX2gnYTROfSNk9nPSW5Inq1aMapX7M5Ov XqZox8jqk3OgTPXyvWY7NE/lfESwcWtp6j5xE= MIME-Version: 1.0 Received: by 10.103.78.35 with SMTP id f35mr577065mul.89.1250241531576; Fri, 14 Aug 2009 02:18:51 -0700 (PDT) Date: Fri, 14 Aug 2009 12:18:51 +0300 Message-ID: <9e20d71e0908140218h7a65d8c4g4dbe63d905a51ad8@mail.gmail.com> From: Artis Caune To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: ZFS rollback lock-up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 09:18:53 -0000 Hi, I read in zfs admin guide and could not try this (on amd64 r196047): - Rolling Back a Dataset Without Unmounting - Solaris Express Community Edition, build 80: This release provides the ability to rollback a dataset without unmounting it first. This feature means that zfs rollback -f option is no longer needed to force an umount operation. The -f option is no longer supported, and is ignored if specified. # zfs create tank/rollback-test # echo 1 > /rollback-test/file # zfs snapshot tank/rollback-test@snapshot1 # echo 2 >> /rollback-test/file # zfs rollback tank/rollback-test@snapshot1 # cat /rollback-test/file # zfs destroy tank/rollback-test works great, because file system is not busy, but if I open some file before rollback: # vim /rollback-test/file ^Z # fstat | grep '/rollback-test' root vim 1254 4 /rollback-test 7 -rw-r--r-- 4096 rw # zfs rollback tank/rollback-test@snapshot1 # fg vim offer me to load file because it has changed, and works great, but after rollback I can not list /rollback-test directory and all zfs commands lock up. Reboot also hangs in unkillable processes. After reset I can destroy dataset. Fanny part is that I can even rollback root file system from which I boot. I know it's crazy to "force"-rollback live file system, just interesting why they made such change. -- Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 09:46:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E230106568B; Fri, 14 Aug 2009 09:46:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id D4E138FC5A; Fri, 14 Aug 2009 09:46:05 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E9k3IM042691; Fri, 14 Aug 2009 05:46:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7E9k3pH078760; Fri, 14 Aug 2009 05:46:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D210F7302F; Fri, 14 Aug 2009 05:46:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814094602.D210F7302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 05:46:02 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 09:46:07 -0000 TB --- 2009-08-14 08:40:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 08:40:01 - starting HEAD tinderbox run for arm/arm TB --- 2009-08-14 08:40:01 - cleaning the object tree TB --- 2009-08-14 08:40:37 - cvsupping the source tree TB --- 2009-08-14 08:40:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-08-14 08:40:45 - building world TB --- 2009-08-14 08:40:45 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 08:40:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 08:40:45 - TARGET=arm TB --- 2009-08-14 08:40:45 - TARGET_ARCH=arm TB --- 2009-08-14 08:40:45 - TZ=UTC TB --- 2009-08-14 08:40:45 - __MAKE_CONF=/dev/null TB --- 2009-08-14 08:40:45 - cd /src TB --- 2009-08-14 08:40:45 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 08:40:49 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 09:46:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 09:46:02 - ERROR: failed to build world TB --- 2009-08-14 09:46:02 - 3030.92 user 369.27 system 3961.52 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 10:39:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B54B0106568D for ; Fri, 14 Aug 2009 10:39:03 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8AD8FC15 for ; Fri, 14 Aug 2009 10:39:03 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2D4AE.dip.t-dialin.net [217.226.212.174]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 0AA418440A6; Fri, 14 Aug 2009 12:38:46 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id AF7DCA115B; Fri, 14 Aug 2009 12:38:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1250246322; bh=1+VlpqUDP02x1HAYoy1jOtgCg2efkEijzSwU6mHa4KM=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZYuoDl8zN9Zz4/Lloh7mXffpNvxYnZ/5Teve2+9/LQ8xCARbtoXzEjw+0vi4uyGLP /U/6ovUrcZvHLajCSApM12E/SA0L+21vs2q1xJLDHhuRzJiabdGM4vX8s54B+HAtDh zLLrFsC/suCIX4JXN5dmL50276LcI/I0X6NUT9Opkuz8sZXfzoCBwYiDLPcChIWLub zLvx7UK2Zlyy6Qm2rQBDsoj4MXaiA+jstEDHyTHQvFgXyS1fqi8f244rQQBZkFL8YM 6A9HufND0K9jxICfdbLZpIP8S9sx3ekknYcBc4lTJywuL6Ulm5ejJlId4ZMjitvIUf Zm6oYqf5mWVhA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n7EAcgmp094792; Fri, 14 Aug 2009 12:38:42 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 14 Aug 2009 12:38:41 +0200 Message-ID: <20090814123841.64506vcujbf409c8@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 14 Aug 2009 12:38:41 +0200 From: Alexander Leidinger To: Andreas Tobler References: <4A832C70.4030600@fgznet.ch> <20090813081538.5361241c6z2lqcn4@webmail.leidinger.net> <4A8465EF.7030604@fgznet.ch> <20090814080400.20646vxm44n78b8c@webmail.leidinger.net> In-Reply-To: <20090814080400.20646vxm44n78b8c@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-8.0 X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 0AA418440A6.AF54F X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.439, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1250851127.27654@Ykdk+ce7Aop4Du3zsDh3pQ X-EBL-Spam-Status: No Cc: freebsd-current Subject: Re: tools/kerneldoc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 10:39:03 -0000 Quoting Alexander Leidinger (from Fri, 14 Aug 2009 08:04:00 +0200): > Quoting Andreas Tobler (from Thu, 13 Aug > 2009 21:13:51 +0200): > >> Alexander Leidinger wrote: >>> I have patches for the subsys part. A little bit more than only >>> the .m files fix: >>> http://www.leidinger.net/FreeBSD/current/patches/dox.diff >> >> Thanks, I tried it and I was surprised how long such a build took. >> Well, html and latex more than 5 hours on a p4 2.8GHz. And the >> amount of data is also huge, nearly 2GB of data. > > Normally you need only one of them. I have now the generated dox online. Hopefully updated daily (if my cronjob is correct). See http://www.leidinger.net/blog/ for more infos and the URL. Bye, Alexander. -- QOTD: "I sprinkled some baking powder over a couple of potatoes, but it didn't work." http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 11:04:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B4F2106568D; Fri, 14 Aug 2009 11:04:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C254B8FC15; Fri, 14 Aug 2009 11:04:56 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7EB4s2L045997; Fri, 14 Aug 2009 07:04:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7EB4sEv019781; Fri, 14 Aug 2009 07:04:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D63FF7302F; Fri, 14 Aug 2009 07:04:53 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814110453.D63FF7302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 07:04:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 11:04:57 -0000 TB --- 2009-08-14 09:46:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 09:46:02 - starting HEAD tinderbox run for i386/i386 TB --- 2009-08-14 09:46:02 - cleaning the object tree TB --- 2009-08-14 09:46:24 - cvsupping the source tree TB --- 2009-08-14 09:46:25 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-08-14 09:46:33 - building world TB --- 2009-08-14 09:46:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 09:46:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 09:46:33 - TARGET=i386 TB --- 2009-08-14 09:46:33 - TARGET_ARCH=i386 TB --- 2009-08-14 09:46:33 - TZ=UTC TB --- 2009-08-14 09:46:33 - __MAKE_CONF=/dev/null TB --- 2009-08-14 09:46:33 - cd /src TB --- 2009-08-14 09:46:33 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 09:46:34 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 11:04:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 11:04:53 - ERROR: failed to build world TB --- 2009-08-14 11:04:53 - 3775.40 user 365.60 system 4730.76 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 11:40:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFB67106568B for ; Fri, 14 Aug 2009 11:40:11 +0000 (UTC) (envelope-from florent.thoumie@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id 197328FC79 for ; Fri, 14 Aug 2009 11:40:10 +0000 (UTC) Received: by fxm1 with SMTP id 1so1037168fxm.7 for ; Fri, 14 Aug 2009 04:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=/I+nA4YguXbnW2Kx74oAgMjJ/7RjuTpbm75Z/MzpSQA=; b=HxbWvUb08Wlrfsgia6FYJ/9oORe72Zi9IZTIN2Mz9VS5FW85d4JuUUIucoTfmFCb48 PdAjGUEFMG1wjow5MVkm0zdfYtmMnK7Kx1k/DqgvtKyQZuYGrPUGcWmWs+RYvCp2fDQa EyVAQOAAo6fIAwfvGHLbD9j0Xy+63kFYvr8Bs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=gBIw9LRDUO+BFe1pn8vcRBZmLgtTtTNV0Ddjv919uKUFZKr51AIfDcO11chfqanz86 XQkXKhKj+Jo4hRnm/nbxn8LN88HlhZn33pILGQzua91Ml3v3mE1hro98vT9QeDvLk441 aa5Hq0jEIaG3wf9VutKsoTerIkmXMc5Rt/tA4= MIME-Version: 1.0 Sender: florent.thoumie@gmail.com Received: by 10.86.231.15 with SMTP id d15mr1164711fgh.74.1250248675068; Fri, 14 Aug 2009 04:17:55 -0700 (PDT) From: Florent Thoumie Date: Fri, 14 Aug 2009 12:17:35 +0100 X-Google-Sender-Auth: 7176ac3c15586db6 Message-ID: To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Panic in rum(4) on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 11:40:12 -0000 Since upgrading from 7.2-RELEASE to 8.0-BETA2, I've been experiencing the following panic on a regular basis: : flz@cream:/var/crash; sudo kgdb -c vmcore.1 /boot/kernel/kernel.symbols GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex rum0 (network driver) r = 0 (0xc4ad29a4) locked @ /usr/src/sys/dev/usb/wlan/if_rum.c:1278 exclusive sleep mutex rum0_com_lock (rum0_com_lock) r = 0 (0xc4b06014) locked @ /usr/src/sys/net80211/ieee80211_scan.c:683 KDB: stack backtrace: db_trace_self_wrapper(c0c6baf4,f3694a60,c08bc995,c0c7edcd,2ab,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0c7edcd,2ab,ffffffff,c0efbc54,f3694a98,...) at kdb_backtrace+0x29 _witness_debugger(c0c6df35,f3694aac,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0ca1b88,80246,c0db9aa0,...) at witness_warn+0x1fd trap(f3694b38) at trap+0x173 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc093f0e8, esp = 0xf3694b78, ebp = 0xf3694b94 --- ieee80211_crypto_encap(c592d000,c4a0ca00,c0c58b19,4b3,c0efbc60,...) at ieee80211_crypto_encap+0xa8 rum_start(c4ad2000,f3694c1c,c09232cf,c4ad2000,0,...) at rum_start+0x358 if_start(c4ad2000,0,c0c778c5,c01,52,...) at if_start+0x12 if_transmit(c4ad2000,c4a11100,c4a0b700,a4,c4b06000,...) at if_transmit+0x13f ieee80211_start(c4691800,f3694ca4,c096918e,c4691800,5,...) at ieee80211_start+0x661 if_start(c4691800,5,10,654,f3694ca4,...) at if_start+0x12 ieee80211_newstate_cb(c8cf9000,1,c0c6d2f0,54,c4ace8dc,...) at ieee80211_newstate_cb+0x20e taskqueue_run(c4ace8c0,c4ace8dc,0,c0c5e82b,0,...) at taskqueue_run+0x10b taskqueue_thread_loop(c4b06074,f3694d38,c0c63ebc,342,c0db9aa0,...) at taskqueue_thread_loop+0x68 fork_exit(c08b5b10,c4b06074,f3694d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf3694d70, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x20:0xc093f0e8 stack pointer = 0x28:0xf3694b78 frame pointer = 0x28:0xf3694b94 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (rum0 taskq) panic: from debugger cpuid = 0 Uptime: 40m53s Physical memory: 1007 MB Dumping 155 MB: 140 124 108 92 76 60 44 28 12 Reading symbols from /boot/kernel/snd_emu10kx.ko...Reading symbols from /boot/kernel/snd_emu10kx.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_emu10kx.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/linsysfs.ko...Reading symbols from /boot/kernel/linsysfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linsysfs.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) doadump Undefined command: "doadump". Try "help". (kgdb) help List of classes of commands: aliases -- Aliases of other commands breakpoints -- Making program stop at certain points data -- Examining data files -- Specifying and examining files internals -- Maintenance commands obscure -- Obscure features running -- Running the program stack -- Examining the stack status -- Status inquiries support -- Support facilities tracepoints -- Tracing of program execution without stopping the program user-defined -- User-defined commands Type "help" followed by a class name for a list of commands in that class. Type "help" followed by command name for full documentation. Command name abbreviations are allowed if unambiguous. (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xc087ba2e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc087bd02 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc04caf57 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:478 #4 0xc04cb581 in db_command (last_cmdp=0xc0d8963c, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:445 #5 0xc04cb6da in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xc04cd56d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 #7 0xc08a9696 in kdb_trap (type=12, code=0, tf=0xf3694b38) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xc0ba88cf in trap_fatal (frame=0xf3694b38, eva=32) at /usr/src/sys/i386/i386/trap.c:924 #9 0xc0ba9231 in trap (frame=0xf3694b38) at /usr/src/sys/i386/i386/trap.c:325 #10 0xc0b8b9db in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #11 0xc093f0e8 in ieee80211_crypto_encap (ni=0xc592d000, m=0xc4a0ca00) at /usr/src/sys/net80211/ieee80211_crypto.c:560 #12 0xc07c4c68 in rum_start (ifp=0xc4ad2000) at /usr/src/sys/dev/usb/wlan/if_rum.c:1216 #13 0xc0922be2 in if_start (ifp=0xc4ad2000) at /usr/src/sys/net/if.c:3061 #14 0xc09232cf in if_transmit (ifp=0xc4ad2000, m=0xc4a11100) at /usr/src/sys/net/if.c:3073 #15 0xc0963711 in ieee80211_start (ifp=0xc4691800) at /usr/src/sys/net80211/ieee80211_output.c:347 #16 0xc0922be2 in if_start (ifp=0xc4691800) at /usr/src/sys/net/if.c:3061 #17 0xc096918e in ieee80211_newstate_cb (xvap=0xc8cf9000, npending=1) at /usr/src/sys/net80211/ieee80211_proto.c:1681 #18 0xc08b5a1b in taskqueue_run (queue=0xc4ace8c0) at /usr/src/sys/kern/subr_taskqueue.c:282 #19 0xc08b5b78 in taskqueue_thread_loop (arg=0xc4b06074) at /usr/src/sys/kern/subr_taskqueue.c:403 #20 0xc0852238 in fork_exit (callout=0xc08b5b10 , arg=0xc4b06074, frame=0xf3694d38) at /usr/src/sys/kern/kern_fork.c:842 #21 0xc0b8ba50 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 I noticed that shortly before it happens, I also get the following message from wpa_supplicant: "Failed to disable WPA in the driver". -- Florent Thoumie flz@FreeBSD.org FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 12:07:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D8821065693 for ; Fri, 14 Aug 2009 12:07:51 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 6738E8FC78 for ; Fri, 14 Aug 2009 12:07:49 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=4M5xpDXfmOqrkcZeW1YA:9 a=W8rBnEO_JQCgwEdrdnwA:7 a=3lHY1hwTeyZG_4viVkEc3Neah_oA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1286776165; Fri, 14 Aug 2009 14:07:48 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 14 Aug 2009 14:07:54 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908141407.56248.hselasky@c2i.net> Cc: Florent Thoumie Subject: Re: Panic in rum(4) on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 12:07:51 -0000 On Friday 14 August 2009 13:17:35 Florent Thoumie wrote: > Since upgrading from 7.2-RELEASE to 8.0-BETA2, I've been experiencing the > > following panic on a regular basis: > : flz@cream:/var/crash; sudo kgdb -c vmcore.1 /boot/kernel/kernel.symbols > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are > > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex rum0 (network driver) r = 0 (0xc4ad29a4) locked @ > /usr/src/sys/dev/usb/wlan/if_rum.c:1278 > exclusive sleep mutex rum0_com_lock (rum0_com_lock) r = 0 (0xc4b06014) > locked @ /usr/src/sys/net80211/ieee80211_scan.c:683 > KDB: stack backtrace: > db_trace_self_wrapper(c0c6baf4,f3694a60,c08bc995,c0c7edcd,2ab,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c0c7edcd,2ab,ffffffff,c0efbc54,f3694a98,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c6df35,f3694aac,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0ca1b88,80246,c0db9aa0,...) at witness_warn+0x1fd > trap(f3694b38) at trap+0x173 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc093f0e8, esp = 0xf3694b78, ebp = 0xf3694b94 --- > ieee80211_crypto_encap(c592d000,c4a0ca00,c0c58b19,4b3,c0efbc60,...) at > ieee80211_crypto_encap+0xa8 > rum_start(c4ad2000,f3694c1c,c09232cf,c4ad2000,0,...) at rum_start+0x358 > if_start(c4ad2000,0,c0c778c5,c01,52,...) at if_start+0x12 > if_transmit(c4ad2000,c4a11100,c4a0b700,a4,c4b06000,...) at > if_transmit+0x13f > > ieee80211_start(c4691800,f3694ca4,c096918e,c4691800,5,...) at > ieee80211_start+0x661 > if_start(c4691800,5,10,654,f3694ca4,...) at if_start+0x12 > ieee80211_newstate_cb(c8cf9000,1,c0c6d2f0,54,c4ace8dc,...) at > ieee80211_newstate_cb+0x20e > taskqueue_run(c4ace8c0,c4ace8dc,0,c0c5e82b,0,...) at taskqueue_run+0x10b > taskqueue_thread_loop(c4b06074,f3694d38,c0c63ebc,342,c0db9aa0,...) at > taskqueue_thread_loop+0x68 > fork_exit(c08b5b10,c4b06074,f3694d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf3694d70, ebp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x20 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc093f0e8 > stack pointer = 0x28:0xf3694b78 > frame pointer = 0x28:0xf3694b94 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (rum0 taskq) > panic: from debugger > cpuid = 0 > Uptime: 40m53s > Physical memory: 1007 MB > Dumping 155 MB: 140 124 108 92 76 60 44 28 12 > > Reading symbols from /boot/kernel/snd_emu10kx.ko...Reading symbols from > /boot/kernel/snd_emu10kx.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/snd_emu10kx.ko > Reading symbols from /boot/kernel/sound.ko...Reading symbols from > /boot/kernel/sound.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/sound.ko > Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from > /boot/kernel/atapicam.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/atapicam.ko > Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from > /boot/kernel/fdescfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/fdescfs.ko > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from > /boot/kernel/linprocfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linprocfs.ko > Reading symbols from /boot/kernel/linux.ko...Reading symbols from > /boot/kernel/linux.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /boot/kernel/linsysfs.ko...Reading symbols from > /boot/kernel/linsysfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/linsysfs.ko > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from > /boot/kernel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from > /boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) doadump > Undefined command: "doadump". Try "help". > (kgdb) help > List of classes of commands: > > aliases -- Aliases of other commands > breakpoints -- Making program stop at certain points > data -- Examining data > files -- Specifying and examining files > internals -- Maintenance commands > obscure -- Obscure features > running -- Running the program > stack -- Examining the stack > status -- Status inquiries > support -- Support facilities > tracepoints -- Tracing of program execution without stopping the program > user-defined -- User-defined commands > > Type "help" followed by a class name for a list of commands in that class. > Type "help" followed by command name for full documentation. > Command name abbreviations are allowed if unambiguous. > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xc087ba2e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xc087bd02 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xc04caf57 in db_panic (addr=Could not find the frame base for > "db_panic". > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xc04cb581 in db_command (last_cmdp=0xc0d8963c, cmd_table=0x0, > dopager=1) at /usr/src/sys/ddb/db_command.c:445 > #5 0xc04cb6da in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 > #6 0xc04cd56d in db_trap (type=12, code=0) at > /usr/src/sys/ddb/db_main.c:229 > #7 0xc08a9696 in kdb_trap (type=12, code=0, tf=0xf3694b38) at > /usr/src/sys/kern/subr_kdb.c:534 > #8 0xc0ba88cf in trap_fatal (frame=0xf3694b38, eva=32) at > /usr/src/sys/i386/i386/trap.c:924 > #9 0xc0ba9231 in trap (frame=0xf3694b38) at > /usr/src/sys/i386/i386/trap.c:325 > #10 0xc0b8b9db in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #11 0xc093f0e8 in ieee80211_crypto_encap (ni=0xc592d000, m=0xc4a0ca00) at > /usr/src/sys/net80211/ieee80211_crypto.c:560 > #12 0xc07c4c68 in rum_start (ifp=0xc4ad2000) at > /usr/src/sys/dev/usb/wlan/if_rum.c:1216 > #13 0xc0922be2 in if_start (ifp=0xc4ad2000) at /usr/src/sys/net/if.c:3061 > #14 0xc09232cf in if_transmit (ifp=0xc4ad2000, m=0xc4a11100) at > /usr/src/sys/net/if.c:3073 > #15 0xc0963711 in ieee80211_start (ifp=0xc4691800) at > /usr/src/sys/net80211/ieee80211_output.c:347 > #16 0xc0922be2 in if_start (ifp=0xc4691800) at /usr/src/sys/net/if.c:3061 > #17 0xc096918e in ieee80211_newstate_cb (xvap=0xc8cf9000, npending=1) at > /usr/src/sys/net80211/ieee80211_proto.c:1681 > #18 0xc08b5a1b in taskqueue_run (queue=0xc4ace8c0) at > /usr/src/sys/kern/subr_taskqueue.c:282 > #19 0xc08b5b78 in taskqueue_thread_loop (arg=0xc4b06074) at > /usr/src/sys/kern/subr_taskqueue.c:403 > #20 0xc0852238 in fork_exit (callout=0xc08b5b10 , > arg=0xc4b06074, frame=0xf3694d38) at /usr/src/sys/kern/kern_fork.c:842 > #21 0xc0b8ba50 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 > > I noticed that shortly before it happens, I also get the following message > from wpa_supplicant: "Failed to disable WPA in the driver". Hi, This looks like a WLAN problem rather than an USB problem. Some months back the WLAN statemachine was converted to taskqueues. In that regard I've seen 100% reproducable panics, but I did not have time to investigate. If you put some delay between the "ifconfig" commands on your wlan device, does the problem disappear? Related PR: usb/137341: driver if_rum doesn't work at all and throws panics --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 12:24:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E9D81065690; Fri, 14 Aug 2009 12:24:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD8E8FC3D; Fri, 14 Aug 2009 12:24:39 +0000 (UTC) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7ECObQr051397; Fri, 14 Aug 2009 08:24:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n7ECObNM019680; Fri, 14 Aug 2009 08:24:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 44CC27302F; Fri, 14 Aug 2009 08:24:37 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814122437.44CC27302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 08:24:37 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 12:24:40 -0000 TB --- 2009-08-14 11:04:53 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 11:04:53 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-08-14 11:04:54 - cleaning the object tree TB --- 2009-08-14 11:05:23 - cvsupping the source tree TB --- 2009-08-14 11:05:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-08-14 11:05:32 - building world TB --- 2009-08-14 11:05:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 11:05:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 11:05:32 - TARGET=pc98 TB --- 2009-08-14 11:05:32 - TARGET_ARCH=i386 TB --- 2009-08-14 11:05:32 - TZ=UTC TB --- 2009-08-14 11:05:32 - __MAKE_CONF=/dev/null TB --- 2009-08-14 11:05:32 - cd /src TB --- 2009-08-14 11:05:32 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 11:05:33 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O2 -pipe -fno-builtin-strftime -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 12:24:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 12:24:37 - ERROR: failed to build world TB --- 2009-08-14 12:24:37 - 3738.05 user 371.45 system 4783.09 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 12:39:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0756D106568C for ; Fri, 14 Aug 2009 12:39:58 +0000 (UTC) (envelope-from ru@FreeBSD.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id B82838FC55 for ; Fri, 14 Aug 2009 12:39:57 +0000 (UTC) Received: from [10.100.124.99] (port=63174 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbvXs-0004kJ-5F; Fri, 14 Aug 2009 16:06:08 +0400 Date: Fri, 14 Aug 2009 16:06:02 +0400 From: Ruslan Ermilov To: Ian FREISLICH Message-ID: <20090814120602.GA64565@edoofus.dev.vega.ru> References: <20090814080044.A93661@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: panic in netisr (I think) + DUMP FAILED (ERROR 6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 12:39:58 -0000 On Fri, Aug 14, 2009 at 10:47:05AM +0200, Ian FREISLICH wrote: > "Bjoern A. Zeeb" wrote: > > On Fri, 14 Aug 2009, Ian Freislich wrote: > > > > Hi, > > > > > I finally hooked up a console to this machine because its dumps > > > have been broken or corrupted for many months. Sadly there isn't > > > much more infonmation than this console capture. > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 10; apic id = 0a > > > fault virtual address = 0x1f5cd38 > > ... > > > Uptime: 6d13h28m14s > > > > this has been fixed two days ago. Seeing your uptime you do not have > > the fix. Please update to latest RELENG_8 or HEAD. > > I suspected that. > > Do you have any idea why kernel dumps are not working as shown in > the OP? > There was a message, "Attempt to write outside dump device boundaries.", that explains that. Search the mailing list archives where I explained the underlying bug with current versions of FreeBSD (in short page maps get updated while we're writing a dump, due to interrupts still enabled). Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 13:17:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 691221065693 for ; Fri, 14 Aug 2009 13:17:00 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 039F08FC57 for ; Fri, 14 Aug 2009 13:16:59 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n7EDGY9D083353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Aug 2009 15:16:35 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <6C313AFE-9E97-4A45-B24A-7EF45BA0ACD1@lassitu.de> From: Stefan Bethke To: Hans Petter Selasky In-Reply-To: <49CE3C71.4060006@fgznet.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 Aug 2009 15:16:34 +0200 References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> <200903281243.36540.hselasky@c2i.net> <49CE3C71.4060006@fgznet.ch> X-Mailer: Apple Mail (2.936) Cc: Andreas Tobler , FreeBSD Current Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:17:00 -0000 Am 28.03.2009 um 16:04 schrieb Andreas Tobler: > Stefan Bethke wrote: >> Am 28.03.2009 um 12:43 schrieb Hans Petter Selasky: >>> On Saturday 28 March 2009, Stefan Bethke wrote: >>>> I've run into the same issue a couple of days ago. >>>> >>>> Loading uhci as a module is sufficient to trigger the messages. No >>>> device was attached during the output below; in other tests I >>>> noticed >>>> that uhci appears to not see any device that VMware has attached. >>> >>> Is it possible to get some debugging from the VM-ware? >> Apparently some internal debugging can be activated, but I'm not >> sure what it will show. I can try and find out. > > I did activate this debugging but I could not see anything useful. > At the same time I had to restart the guest to make this debugging > active. > But now I do not seem to be able to trigger the issue we have. > > Though, I do not have modules. > > I'll try harder. > At the moment it seems to work here. I've jsut tried again, with Fusion 2.0.5 (173382) and current r196085, and so far everything appears to be working just fine. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 13:28:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA9A0106568D; Fri, 14 Aug 2009 13:28:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBBE8FC51; Fri, 14 Aug 2009 13:28:51 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7EDSmHk059697; Fri, 14 Aug 2009 09:28:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7EDSmvg018689; Fri, 14 Aug 2009 09:28:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1232B7302F; Fri, 14 Aug 2009 09:28:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814132848.1232B7302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 09:28:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:28:52 -0000 TB --- 2009-08-14 12:24:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 12:24:37 - starting HEAD tinderbox run for mips/mips TB --- 2009-08-14 12:24:37 - cleaning the object tree TB --- 2009-08-14 12:24:55 - cvsupping the source tree TB --- 2009-08-14 12:24:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-08-14 12:25:04 - building world TB --- 2009-08-14 12:25:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 12:25:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 12:25:04 - TARGET=mips TB --- 2009-08-14 12:25:04 - TARGET_ARCH=mips TB --- 2009-08-14 12:25:04 - TZ=UTC TB --- 2009-08-14 12:25:04 - __MAKE_CONF=/dev/null TB --- 2009-08-14 12:25:04 - cd /src TB --- 2009-08-14 12:25:04 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 12:25:05 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/mfiutil (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfiutil.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_cmd.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_config.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-builtin-strftime -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/mfiutil/mfi_drive.c cc1: warnings being treated as errors /src/usr.sbin/mfiutil/mfi_drive.c: In function 'mfi_lookup_drive': /src/usr.sbin/mfiutil/mfi_drive.c:120: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/mfiutil. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 13:28:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 13:28:47 - ERROR: failed to build world TB --- 2009-08-14 13:28:47 - 2958.74 user 336.41 system 3850.43 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 13:47:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFD4B106568C for ; Fri, 14 Aug 2009 13:47:06 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 821F98FC43 for ; Fri, 14 Aug 2009 13:47:06 +0000 (UTC) Received: from [41.161.16.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Mbx7Y-0001cb-1y; Fri, 14 Aug 2009 15:47:04 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mbx7k-0001zP-UW; Fri, 14 Aug 2009 15:47:16 +0200 To: Ruslan Ermilov From: Ian FREISLICH In-Reply-To: <20090814120602.GA64565@edoofus.dev.vega.ru> References: <20090814120602.GA64565@edoofus.dev.vega.ru> <20090814080044.A93661@maildrop.int.zabbadoz.net> X-Attribution: BOFH Date: Fri, 14 Aug 2009 15:47:16 +0200 Message-Id: Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: panic in netisr (I think) + DUMP FAILED (ERROR 6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:47:07 -0000 Ruslan Ermilov wrote: > On Fri, Aug 14, 2009 at 10:47:05AM +0200, Ian FREISLICH wrote: > > Do you have any idea why kernel dumps are not working as shown in > > the OP? > > > There was a message, "Attempt to write outside dump device boundaries.", > that explains that. Search the mailing list archives where I explained > the underlying bug with current versions of FreeBSD (in short page maps > get updated while we're writing a dump, due to interrupts still enabled). And then, this bug is probably why my dumps have been unusable since about 12 months now? These (2) servers have a continuous interrupt rate in excess of 40k/s, network related, so interrupts during dumping are highly likely. Reading that thread I'm given to believe that the problem exists only for mini-dumps. I've had crashes without cores with (and without) mini-dumps enabled, but I've only recently started capturing console output, so I'll see what happens on its next crash. They reliably crash at least once a week. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 13:50:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CDCC106568E for ; Fri, 14 Aug 2009 13:50:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 277808FC59 for ; Fri, 14 Aug 2009 13:50:39 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id CE7A446B0C; Fri, 14 Aug 2009 09:50:38 -0400 (EDT) Date: Fri, 14 Aug 2009 14:50:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andreas Tobler In-Reply-To: <4A847AA5.1030701@fgznet.ch> Message-ID: References: <4A847AA5.1030701@fgznet.ch> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current Subject: Re: 8.0-stable/releng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:50:39 -0000 On Thu, 13 Aug 2009, Andreas Tobler wrote: > for the record, am I correct that the upcoming 8.0 branch is like this: > > svn ls svn://svn.freebsd.org/base/stable/ .. 8/ ? > > And not under 'releng'? > > I'm a bit confused about naming conventions, releng vs. stable. I have no > problem with either, but which one is the one to be used for BETA-3/RC? > > Is head becoming 9.0 soon? Existing documentation about branch naming (-CURRENT, -STABLE, -RELEASE, etc) remains essentially valid. The primary change of note is that in Subversion, we now include "stable" in the branch name for -STABLE branches, rather than using "releng" for that as well. The following should apply: base/head - -CURRENT base/stable/X - X-STABLE branches base/releng/X.Y - X.Y release engineering branches base/release/X.Y.Z - X.Y.Z release tag stable/8 has been created, but neither releng/8.0 nor release/8.0.0 have been created. Because the release process involves some non-atomic windows, things are currently potentially confusing -- uname -a on head and stable/8 both report BETA2, and the two branches are being kept in lock-step in the lead-up to BETA3, after which point the brannches will diverge. I'm not quite sure when head will start calling itself 9-CURRENT, but probably pretty soon. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 13:55:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5709106568F; Fri, 14 Aug 2009 13:55:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id A0A838FC51; Fri, 14 Aug 2009 13:55:19 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 52F8F46B0C; Fri, 14 Aug 2009 09:55:19 -0400 (EDT) Date: Fri, 14 Aug 2009 14:55:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tom Uffner In-Reply-To: <4A8484E4.6090504@uffner.com> Message-ID: References: <4A8484E4.6090504@uffner.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: pf@freebsd.org, current@freebsd.org Subject: Re: packet forwarding/firewall performance question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:55:19 -0000 On Thu, 13 Aug 2009, Tom Uffner wrote: > i'm hoping a few people will give me estimates on what kind of throughput i > should theoretically expect before i provide any actual test data. > > also, any suggestions on tuning would be welcome. > > so far in preliminary tests, enabling polling on the network interfaces > reduces my performance slightly both to/from and through the box. > net.inet.ip.fastforwarding doesn't seem to make much difference either > way but i haven't done very thorough testing of it. increasing > net.inet.tcp.sendbuf_max & recvbuf_max may have helped, but again, not > sufficiently tested. I can't speak to absolute numbers, but I wouldn't expect net.inet.tcp.* changes to make any difference, as they should affect only locally terminated sockets on the firewall host, not forwarded packets. You might want to try experimenting with net.isr.direct -- try setting it to 0, as this changes the kernel dispatch model for the network stack. On a UP box, I would probably anticipate a performance loss for making that change, or similar configuration changes for multiple netisr threads using net.isr.maxthreads. If you're using firewall code, fast forwarding is unlikely to make a difference. Depending on the cache/memory/CPU trade-off, you might find turning off flowtable support helps -- net.inet.flowtable.enable=0. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 14:01:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E8561065696 for ; Fri, 14 Aug 2009 14:01:42 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 1B5C98FC6B for ; Fri, 14 Aug 2009 14:01:41 +0000 (UTC) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n7EE1ceo057756; Fri, 14 Aug 2009 16:01:39 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A856E42.90900@fgznet.ch> Date: Fri, 14 Aug 2009 16:01:38 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Robert Watson References: <4A847AA5.1030701@fgznet.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current Subject: Re: 8.0-stable/releng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:01:42 -0000 Robert Watson wrote: > On Thu, 13 Aug 2009, Andreas Tobler wrote: > >> for the record, am I correct that the upcoming 8.0 branch is like this: >> >> svn ls svn://svn.freebsd.org/base/stable/ .. 8/ ? >> >> And not under 'releng'? >> >> I'm a bit confused about naming conventions, releng vs. stable. I have no >> problem with either, but which one is the one to be used for BETA-3/RC? >> >> Is head becoming 9.0 soon? > > Existing documentation about branch naming (-CURRENT, -STABLE, -RELEASE, etc) > remains essentially valid. The primary change of note is that in Subversion, > we now include "stable" in the branch name for -STABLE branches, rather than > using "releng" for that as well. The following should apply: > > base/head - -CURRENT > base/stable/X - X-STABLE branches > base/releng/X.Y - X.Y release engineering branches > base/release/X.Y.Z - X.Y.Z release tag > > stable/8 has been created, but neither releng/8.0 nor release/8.0.0 have been > created. > > Because the release process involves some non-atomic windows, things are > currently potentially confusing -- uname -a on head and stable/8 both report > BETA2, and the two branches are being kept in lock-step in the lead-up to > BETA3, after which point the brannches will diverge. I'm not quite sure when > head will start calling itself 9-CURRENT, but probably pretty soon. Thank you Robert! That was the thing/explanation I was looking for. Andreas From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 14:21:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89ED51065672; Fri, 14 Aug 2009 14:21:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB838FC4B; Fri, 14 Aug 2009 14:21:53 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EA83F46B45; Fri, 14 Aug 2009 10:21:52 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 44C448A0AD; Fri, 14 Aug 2009 10:21:52 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 14 Aug 2009 10:04:08 -0400 User-Agent: KMail/1.9.7 References: <200903282317.n2SNHIjI015202@svn.freebsd.org> <4A846206.7010803@FreeBSD.org> In-Reply-To: <4A846206.7010803@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908141004.09354.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 14 Aug 2009 10:21:52 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "Bjoern A. Zeeb" , Doug Barton Subject: Re: svn commit: r190514 - head/sys/conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 14:21:53 -0000 On Thursday 13 August 2009 2:57:10 pm Doug Barton wrote: > Bjoern A. Zeeb wrote: > > Author: bz > > Date: Sat Mar 28 23:17:18 2009 > > New Revision: 190514 > > URL: http://svn.freebsd.org/changeset/base/190514 > > > > Log: > > For kernel builds reduce the impact of svnversion, just scanning > > src/sys and not the entire src/ tree. > > Also, what problem are we really trying to solve here? With a > populated cache it takes on average 5 seconds to run all of src, and > just under 1 to do only sys. Is 4 seconds really that important to > save? With a dry cache I'm sure it takes a little longer, but has > anyone actually measured this? It takes far longer than 5 seconds here against a local SVN repo over NFS. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 15:01:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F42A10656C0 for ; Fri, 14 Aug 2009 15:01:41 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3EF8FC68 for ; Fri, 14 Aug 2009 15:01:40 +0000 (UTC) Received: from [10.100.124.99] (port=52824 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MbyHi-0007V0-6p; Fri, 14 Aug 2009 19:01:38 +0400 Date: Fri, 14 Aug 2009 19:01:32 +0400 From: Ruslan Ermilov To: Ian FREISLICH Message-ID: <20090814150132.GF69960@edoofus.dev.vega.ru> References: <20090814120602.GA64565@edoofus.dev.vega.ru> <20090814080044.A93661@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: panic in netisr (I think) + DUMP FAILED (ERROR 6) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:01:41 -0000 On Fri, Aug 14, 2009 at 03:47:16PM +0200, Ian FREISLICH wrote: > Ruslan Ermilov wrote: > > On Fri, Aug 14, 2009 at 10:47:05AM +0200, Ian FREISLICH wrote: > > > Do you have any idea why kernel dumps are not working as shown in > > > the OP? > > > > > There was a message, "Attempt to write outside dump device boundaries.", > > that explains that. Search the mailing list archives where I explained > > the underlying bug with current versions of FreeBSD (in short page maps > > get updated while we're writing a dump, due to interrupts still enabled). > > And then, this bug is probably why my dumps have been unusable since > about 12 months now? These (2) servers have a continuous interrupt > rate in excess of 40k/s, network related, so interrupts during > dumping are highly likely. Reading that thread I'm given to believe > that the problem exists only for mini-dumps. I've had crashes > without cores with (and without) mini-dumps enabled, but I've only > recently started capturing console output, so I'll see what happens > on its next crash. They reliably crash at least once a week. > True: only on SMP and only with minidumps enabled. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 15:05:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C8B51065672 for ; Fri, 14 Aug 2009 15:05:02 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id C565D8FC43 for ; Fri, 14 Aug 2009 15:05:01 +0000 (UTC) Received: from [172.31.193.10] (cpe-069-134-110-200.nc.res.rr.com [69.134.110.200]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n7EF500k029357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Aug 2009 11:05:01 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n7EF500k029357 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1250262301; bh=AVgmBz45i2PX6D+ErZmYjKvHoOm7B3JIQ7bqN/p2xzQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=W9xnZOIghL+XObGt4gDrJn+eJo58yuFoKhaSvdoR7Je/H1x0Xo4ElAaBNZpDqeEhZ LGICYUBvHbZCyCOzCM0rUsZFCX8Z0napZLK9+clW1u++1Cv4JrJKhIjPSP8nXZJIaB m8fLsPHshK9bT7LD2GpQegq1SvoHriV+BvNI/Ooo= Message-ID: <4A857D16.9070403@cs.duke.edu> Date: Fri, 14 Aug 2009 11:04:54 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:05:02 -0000 I've been porting a closed-source driver to FreeBSD 8 from FreeBSD 5/6/7. It use the dev_clone() eventhandler to mimic linux-like open semantics (for linux binary compat). From the eventhandler, I do: fake_unit = -1; i = clone_create(&mx_clones, &mx_cdevsw, &fake_unit, cdev, 0); if (i) { /* need to allocate a new /dev/mx_fake.%d device node */ *cdev = make_dev(&mx_cdevsw, unit2minor(fake_unit), UID_ROOT, GID_WHEEL, mode, "mx_fake.%d", fake_unit); } This has worked fine from 5.x through 7.x, but in 8.x, the /dev/mx_fake.* devices persist after unload. If anything attempts to access them, the machine falls over (trace appended). I'm assuming these files are lingering because clone_cleanup() (called at device detach) is not cleaning up these lingering device nodes. I've tried writing a dtrace script to trace clone_cleanup. But since that happens from device detach, dtrace doesn't work (blocks driver unload). I've also tried setting a breakpoint in ddb(), but the breakpoint seems to be ignored (other breakpoints work fine, which is odd). What changed between 7.x and 8 with respect to device cloning? BTW, is there any easier option now in 8.x? Thanks, Drew Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffffff81528a64 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8052f009 stack pointer = 0x28:0xffffff8018a75730 frame pointer = 0x28:0xffffff8018a757a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 18087 (cat) [thread pid 18087 tid 100061 ] Stopped at devfs_open+0x69: testb $0x4,0x4(%rax) db> bt Tracing pid 18087 tid 100061 td 0xffffff000188bab0 devfs_open() at devfs_open+0x69 VOP_OPEN_APV() at VOP_OPEN_APV+0x44 vn_open_cred() at vn_open_cred+0x2f4 kern_openat() at kern_openat+0x179 syscall() at syscall+0x28f Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (5, FreeBSD ELF64, open), rip = 0x8007272ac, rsp = 0x7fffffffe0d8, rbp = 0 --- db> Tracing pid 18087 tid 100061 td 0xffffff000188bab0 devfs_open() at devfs_open+0x69 VOP_OPEN_APV() at VOP_OPEN_APV+0x44 vn_open_cred() at vn_open_cred+0x2f4 kern_openat() at kern_openat+0x179 syscall() at syscall+0x28f Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (5, FreeBSD ELF64, open), rip = 0x8007272ac, rsp = 0x7fffffffe0d8, rbp = 0 --- From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 15:33:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E34FD106564A for ; Fri, 14 Aug 2009 15:33:48 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id B2AAF8FC15 for ; Fri, 14 Aug 2009 15:33:48 +0000 (UTC) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n7EFXmaV043376; Fri, 14 Aug 2009 08:33:48 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 9dax34ubf36sx58hucppe3tm5e; Fri, 14 Aug 2009 08:33:48 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A8583DB.1090507@freebsd.org> Date: Fri, 14 Aug 2009 08:33:47 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: John Baldwin References: <200903282317.n2SNHIjI015202@svn.freebsd.org> <4A846206.7010803@FreeBSD.org> <200908141004.09354.jhb@freebsd.org> In-Reply-To: <200908141004.09354.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org, Doug Barton Subject: Re: svn commit: r190514 - head/sys/conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:33:49 -0000 John Baldwin wrote: > On Thursday 13 August 2009 2:57:10 pm Doug Barton wrote: >> Bjoern A. Zeeb wrote: >>> Author: bz >>> Date: Sat Mar 28 23:17:18 2009 >>> New Revision: 190514 >>> URL: http://svn.freebsd.org/changeset/base/190514 >>> >>> Log: >>> For kernel builds reduce the impact of svnversion, just scanning >>> src/sys and not the entire src/ tree. Performance here I think is a red herring. This is really about correctness: The SVN revision of usr.bin/ls simply isn't relevant for the kernel build. >> Also, what problem are we really trying to solve here? With a >> populated cache it takes on average 5 seconds to run all of src, and >> just under 1 to do only sys. Is 4 seconds really that important to >> save? With a dry cache I'm sure it takes a little longer, but has >> anyone actually measured this? I just measured over 30 seconds for svnversion against /usr/src and around 6 for /usr/src/sys (both with cold cache). > It takes far longer than 5 seconds here against a local SVN repo over NFS. The repo has nothing to do with it. svnversion doesn't talk to the repo. It only examines the working copy. Tim From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 15:54:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECDE5106568C for ; Fri, 14 Aug 2009 15:54:03 +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 8CE768FC69 for ; Fri, 14 Aug 2009 15:54:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 60A20FFB9; Sat, 15 Aug 2009 03:54:02 +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 Bliits5-Hyic; Sat, 15 Aug 2009 03:53:57 +1200 (NZST) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 15 Aug 2009 03:53:57 +1200 (NZST) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 6764911432; Sat, 15 Aug 2009 03:53:57 +1200 (NZST) Date: Fri, 14 Aug 2009 08:53:57 -0700 From: Andrew Thompson To: Julian Elischer Message-ID: <20090814155357.GA67039@citylink.fud.org.nz> References: <20090813073002.GA66860@citylink.fud.org.nz> <4A84452B.4070306@elischer.org> <1280352d0908140845j2709fdcfme317fab916606209@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1280352d0908140845j2709fdcfme317fab916606209@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Kostik Belousov , current@freebsd.org, Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:54:04 -0000 Julian Elischer wrote: > Andrew Thompson wrote: > > > > Hi, > > > > > > Here is an aesthetic patch to change the usb kernel processes to threads, > > this hides them from the usual 'ps' output. Please test and review. > > > > ?1290 ??? ?DL ? ? 0:00.00 [usbus0] > > ?[lots and lots more...] > > ?1309 ??? ?DL ? ? 0:00.00 [usbus4] > > > > use kproc_kthread_add() > to create a seoarate usb process and make all the threads belong to > that process. > (kproc_kthread_add() will create a new process the first time > and add more threads to it the more it is run.) Patch updated with the various feedback. PID TT STAT TIME COMMAND 0 ?? DLs 0:00.38 [kernel] 1 ?? ILs 0:00.01 /sbin/init -- 2 ?? DL 0:09.66 [g_event] 3 ?? DL 0:00.20 [g_up] 4 ?? DL 0:00.20 [g_down] ... 18 ?? DL 0:00.06 [acpi_thermal] 19 ?? DL 0:00.04 [usb] % procstat -t 19 PID TID COMM TDNAME CPU PRI STATE WCHAN 19 100040 usb usbus0 0 20 sleep - 19 100041 usb usbus0 0 16 sleep - 19 100042 usb usbus0 0 20 sleep - 19 100043 usb usbus0 0 20 sleep - Andrew Index: usb_process.c =================================================================== --- usb_process.c (revision 196086) +++ usb_process.c (working copy) @@ -63,10 +63,12 @@ #endif #if (__FreeBSD_version >= 800000) +static struct proc *usbproc; #define USB_THREAD_CREATE(f, s, p, ...) \ - kproc_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) -#define USB_THREAD_SUSPEND(p) kproc_suspend(p,0) -#define USB_THREAD_EXIT(err) kproc_exit(err) + kproc_kthread_add((f), (s), &usbproc, (p), RFHIGHPID, \ + 0, "usb", __VA_ARGS__) +#define USB_THREAD_SUSPEND(p) kthread_suspend(p,0) +#define USB_THREAD_EXIT(err) kthread_exit() #else #define USB_THREAD_CREATE(f, s, p, ...) \ kthread_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) @@ -207,8 +209,8 @@ usb_proc_create(struct usb_process *up, struct mtx TAILQ_INIT(&up->up_qhead); - cv_init(&up->up_cv, "wmsg"); - cv_init(&up->up_drain, "dmsg"); + cv_init(&up->up_cv, "-"); + cv_init(&up->up_drain, "usbdrain"); if (USB_THREAD_CREATE(&usb_process, up, &up->up_ptr, pmesg)) { Index: usb_process.h =================================================================== --- usb_process.h (revision 196086) +++ usb_process.h (working copy) @@ -49,7 +49,11 @@ struct usb_process { struct cv up_cv; struct cv up_drain; +#if (__FreeBSD_version >= 800000) + struct thread *up_ptr; +#else struct proc *up_ptr; +#endif struct thread *up_curtd; struct mtx *up_mtx; From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 15:58:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2A4C106568B for ; Fri, 14 Aug 2009 15:58:40 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 776978FC57 for ; Fri, 14 Aug 2009 15:58:40 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n7EFwdPO092621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 08:58:39 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A8589AF.7010300@errno.com> Date: Fri, 14 Aug 2009 08:58:39 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Florent Thoumie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-URT-Metrics: ebb.errno.com; whitelist Cc: current@freebsd.org Subject: Re: Panic in rum(4) on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:58:40 -0000 Florent Thoumie wrote: > Since upgrading from 7.2-RELEASE to 8.0-BETA2, I've been experiencing the > following panic on a regular basis: > > : flz@cream:/var/crash; sudo kgdb -c vmcore.1 /boot/kernel/kernel.symbols > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex rum0 (network driver) r = 0 (0xc4ad29a4) locked @ > /usr/src/sys/dev/usb/wlan/if_rum.c:1278 > exclusive sleep mutex rum0_com_lock (rum0_com_lock) r = 0 (0xc4b06014) > locked @ /usr/src/sys/net80211/ieee80211_scan.c:683 > KDB: stack backtrace: > db_trace_self_wrapper(c0c6baf4,f3694a60,c08bc995,c0c7edcd,2ab,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c0c7edcd,2ab,ffffffff,c0efbc54,f3694a98,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c6df35,f3694aac,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c0ca1b88,80246,c0db9aa0,...) at witness_warn+0x1fd > trap(f3694b38) at trap+0x173 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc093f0e8, esp = 0xf3694b78, ebp = 0xf3694b94 --- > ieee80211_crypto_encap(c592d000,c4a0ca00,c0c58b19,4b3,c0efbc60,...) at > ieee80211_crypto_encap+0xa8 > rum_start(c4ad2000,f3694c1c,c09232cf,c4ad2000,0,...) at rum_start+0x358 > if_start(c4ad2000,0,c0c778c5,c01,52,...) at if_start+0x12 > if_transmit(c4ad2000,c4a11100,c4a0b700,a4,c4b06000,...) at if_transmit+0x13f > > ieee80211_start(c4691800,f3694ca4,c096918e,c4691800,5,...) at > ieee80211_start+0x661 > if_start(c4691800,5,10,654,f3694ca4,...) at if_start+0x12 > ieee80211_newstate_cb(c8cf9000,1,c0c6d2f0,54,c4ace8dc,...) at > ieee80211_newstate_cb+0x20e > taskqueue_run(c4ace8c0,c4ace8dc,0,c0c5e82b,0,...) at taskqueue_run+0x10b > taskqueue_thread_loop(c4b06074,f3694d38,c0c63ebc,342,c0db9aa0,...) at > taskqueue_thread_loop+0x68 > fork_exit(c08b5b10,c4b06074,f3694d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xf3694d70, ebp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x20 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc093f0e8 > stack pointer = 0x28:0xf3694b78 > frame pointer = 0x28:0xf3694b94 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (rum0 taskq) > panic: from debugger > cpuid = 0 > Uptime: 40m53s > Physical memory: 1007 MB > Dumping 155 MB: 140 124 108 92 76 60 44 28 12 Can you provide the line of code where the trap happened and the contents of the local variables? Also show what your network config and/or how to reproduce the issue. Do wlandebug state+crypto to collect debug msgs from the net80211 layer. Sam From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 13:39:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D5AD106568B for ; Fri, 14 Aug 2009 13:39:02 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2878FC43 for ; Fri, 14 Aug 2009 13:39:01 +0000 (UTC) Received: by fxm1 with SMTP id 1so1096679fxm.7 for ; Fri, 14 Aug 2009 06:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=oINRLTVtd9DDB/k/P07FKpBZUpYPdN5HKp7/qQqk1yg=; b=lzKQBShM1xtGX9COfBqhAzZcVPJLXdPDwk6fHPGDLLWoWIBVlGFjWxwRUfn+ci0wtx 5SJ/TIyht8rvkVkGtSZe7ps5RsuXknZBbYe1BaC0TTFMbRjoGVOC5Lshjy/px5ZVK1+b Xt/qSL3PmpVPpmXOFb1il9/qBNyqyhdQMgFJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=sqZ7YlN+B3hSYh/IEXHaEYvb53DXNw152CMXZTOtS2Dkf/czTVTyeTOuNcEmZ2U3pP kUkxLtwOlsYNzxR7vrJ6LfSAoJI6Onm/DttTj4/S64NedKYimfliiaSQtgyPdwxyyEKu ozIZNZnLe4BzKoCBdNcDIsAo7Xq6JF2+7mLq0= Received: by 10.204.152.27 with SMTP id e27mr1176535bkw.192.1250255916509; Fri, 14 Aug 2009 06:18:36 -0700 (PDT) Received: from ubm.mine.nu (e181059132.adsl.alicedsl.de [85.181.59.132]) by mx.google.com with ESMTPS id 18sm1840325fks.10.2009.08.14.06.18.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Aug 2009 06:18:34 -0700 (PDT) Date: Fri, 14 Aug 2009 15:18:26 +0200 From: Marc UBM To: freebsd-current@freebsd.org Message-Id: <20090814151826.66e5077e.ubm.freebsd@gmail.com> In-Reply-To: <20090808235013.eab98028.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> <20090808002354.61c6c5a3.ubm@u-boot-man.de> <20090808235013.eab98028.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 14 Aug 2009 16:04:37 +0000 Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 13:39:02 -0000 On Sat, 8 Aug 2009 23:50:13 +0200 Marc "UBM" Bocklet wrote: > > > I've a friend with a similar problem (also HighPoint controller, > > > also "run interrupt driven hooks: still waiting for xpt_config"), > > > who gets a panic. I'll try to get the panic string and a > > > backtrace, if I do, I'll post it here. > > > > xpt_config basically means that you're waiting on a device driver > > attached to CAM to finish probing, which could point at a number of > > potential problem sources (including things like interrupt routing > > problems). At least in the 7.x line, I've seen firewire and USB at > > various times cause this issue. It might be interesting to compile > > down to the smallest set of cam-related drivers required to support > > necessary hardware (omit firewire, for example) and see if you see > > any improvement. Pinning it down to a specific driver would have > > significant debugging value :-). > > Thanks a lot for the suggestion, I'll be on holiday for one week > starting tomorrow, I'll try narrowing it down as soon as I'm back :-) I just made sure that the problem still exists with a freshly csupped -current (unfortunately, it does), I'll try removing possible culprits from my kernel next. Bye Marc From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 15:27:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C35E1065692 for ; Fri, 14 Aug 2009 15:27:14 +0000 (UTC) (envelope-from lexasoft@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id A71198FC51 for ; Fri, 14 Aug 2009 15:27:13 +0000 (UTC) Received: by qyk29 with SMTP id 29so1244645qyk.3 for ; Fri, 14 Aug 2009 08:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=AccTmFTAlOl2LLMfYZ9jsXVGnGbqDbd3tyy0Enyj0O8=; b=GnMf5viAB2f9R24ewHSqTHRjw5zmKgVvGRF67cxDBqvwIcxca0HL3MGbnusi/1ASMM lhcefZ1PaktZKEDPHYGHzhp88tBUkhFttBs5+Rvd/E8TMRLc1c+w/bKR7KMVFSDRlA0e I/+n/MJsYiaqY+iIcrDalga0SN4s7mdjSRVMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kZQIrbwCS21BiMhh66Njo8ABmgNuUs25HSD9orz6PuBAthFM9VIKp635STXtiqEkWJ ITORAABPTTkhiGFazCUrc3aX2ZgU9kmvi98kM8EXAANjUjKUQMNBio9nH4Lc11L8FUk/ CsDBryyyYgW/5/h3BnSJPtqEvWaJo3XhueGG4= MIME-Version: 1.0 Received: by 10.229.119.131 with SMTP id z3mr1342515qcq.37.1250261932280; Fri, 14 Aug 2009 07:58:52 -0700 (PDT) Date: Fri, 14 Aug 2009 18:58:52 +0400 Message-ID: From: Alexey Tarasov To: current@freebsd.org X-Mailman-Approved-At: Fri, 14 Aug 2009 16:10:20 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:27:14 -0000 Hello. I have more than 30 Supermicro servers with same config and on all of them = I get kernel panic. Here is the screenshots of kgdb output: http://lexasoft.ru/metamphetamine/Panic/Picture%2073.png http://lexasoft.ru/metamphetamine/Panic/Picture%2074.png http://lexasoft.ru/metamphetamine/Panic/Picture%2075.png http://lexasoft.ru/metamphetamine/Panic/Picture%2076.png http://lexasoft.ru/metamphetamine/Panic/Picture%2077.png http://lexasoft.ru/metamphetamine/Panic/Picture%2078.png http://lexasoft.ru/metamphetamine/Panic/Picture%2079.png http://lexasoft.ru/metamphetamine/Panic/Picture%2080.png http://lexasoft.ru/metamphetamine/Panic/Picture%2080.png http://lexasoft.ru/metamphetamine/Panic/Picture%2082.png http://lexasoft.ru/metamphetamine/Panic/Picture%2083.png Here is dmesg output: Copyright (c) 1992-2009 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.2-STABLE #0: Wed Aug 12 01:06:04 MSD 2009 root@st2.srv.getthebit.com:/usr/obj/usr/src/sys/STORAGE WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf65 Stepping =3D 5 Features=3D0xbfebfbff Features2=3D0xe59d AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant Logical CPUs per core: 2 usable memory =3D 2132484096 (2033 MB) avail memory =3D 2056134656 (1960 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: at device 0.0 on pci9 pci10: on pcib3 pcib4: irq 17 at device 28.4 on pci0 pci13: on pcib4 em0: port 0x4000-0x401f mem 0xe8000000-0xe801ffff irq 16 at device 0.0 on pci13 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:91:93:40 pcib5: irq 16 at device 28.5 on pci0 pci14: on pcib5 em1: port 0x5000-0x501f mem 0xe8200000-0xe821ffff irq 17 at device 0.0 on pci14 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:91:93:41 uhci0: port 0x3000-0x301f irq 23 at device 29.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 0x3020-0x303f irq 19 at device 29.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 0x3040-0x305f irq 18 at device 29.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 0x3060-0x307f irq 16 at device 29.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 0xe8600000-0xe86003f= f irq 23 at device 29.7 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 pcib6: at device 30.0 on pci0 pci15: on pcib6 vgapci0: port 0x6000-0x60ff mem 0xe0000000-0xe7ffffff,0xe8300000-0xe830ffff irq 16 at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe8600400-0xe86007ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] 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] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 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 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2700000f27 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2700000f27 device_attach: est1 attach returned 6 p4tcc1: on cpu1 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: CDROM at ata0-slave UDMA33 ad4: 381554MB at ata2-master SATA150 ad5: 381554MB at ata2-slave SATA150 ad6: 381554MB at ata3-master SATA150 ad7: 476940MB at ata3-slave SATA150 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted WARNING: /data1 was not properly dismounted WARNING: /data2 was not properly dismounted WARNING: /data3 was not properly dismounted WARNING: /data4 was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted /usr: mount pending error: blocks 176 files 26 WARNING: /var was not properly dismounted /var: mount pending error: blocks 44 files 11 em0: link state changed to UP I have vmcore in /var/crash folder. What debug information is needed to debug this problem? --=20 (\__/) (=3D'.'=3D) E[: | | | | :]=D0=97 (")_(") Alexey Tarasov From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 15:38:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3D50106568B for ; Fri, 14 Aug 2009 15:38:07 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id EE0C18FC15 for ; Fri, 14 Aug 2009 15:38:06 +0000 (UTC) Received: by bwz19 with SMTP id 19so1608176bwz.37 for ; Fri, 14 Aug 2009 08:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=aUjUFWCOp2+gzPFjsVxftFLMNBdx4zW54dlIAqpUOdA=; b=t9Bn6Uk3lo5aQZKjiFB8bFL/cHaFZ9+1/mBSdn3Ep80w+3mJREZkbIsicJ746LdyoW 7unCshIskd2zVJjbum6SxdeAXkzcf7VCnRgDsHkViyZa2o99+Nm3qYhCo7TTy5gpRPw7 Ku8jU4JoZJLL1p6KK9033NpkMHltRAvKg9xxc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=H3uPt10GII4CwM/1ILe7xaLmY9ewOHkn3MFQwK9yv2/c0b1/yUFoKnmKyvCnngG3wr gmCes1ECS3qxAg4I9X705lzbsG00IG112iyvqDcA6GuodYQtAV1yYDtZiTTF+nvpQgqt rb9fkK0fo4MfoCD5niNI+0S1VoAwSbHk3rWo4= Received: by 10.204.24.2 with SMTP id t2mr1243519bkb.65.1250262957361; Fri, 14 Aug 2009 08:15:57 -0700 (PDT) Received: from ubm.mine.nu (e181059132.adsl.alicedsl.de [85.181.59.132]) by mx.google.com with ESMTPS id 9sm2036273fks.58.2009.08.14.08.15.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Aug 2009 08:15:56 -0700 (PDT) Date: Fri, 14 Aug 2009 17:15:55 +0200 From: Marc UBM To: current@freebsd.org Message-Id: <20090814171555.d1f9b036.ubm.freebsd@gmail.com> In-Reply-To: <20090814151826.66e5077e.ubm.freebsd@gmail.com> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> <20090722201750.4ff23293.ubm@u-boot-man.de> <20090806230909.d01e844a.ubm@u-boot-man.de> <20090808002354.61c6c5a3.ubm@u-boot-man.de> <20090808235013.eab98028.ubm@u-boot-man.de> <20090814151826.66e5077e.ubm.freebsd@gmail.com> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__14_Aug_2009_17_15_55_+0200_q_koWqRgACTlpyl4" X-Mailman-Approved-At: Fri, 14 Aug 2009 16:11:00 +0000 Cc: Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 15:38:07 -0000 This is a multi-part message in MIME format. --Multipart=_Fri__14_Aug_2009_17_15_55_+0200_q_koWqRgACTlpyl4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 14 Aug 2009 15:18:26 +0200 Marc "UBM" Bocklet wrote: > > > xpt_config basically means that you're waiting on a device driver > > > attached to CAM to finish probing, which could point at a number > > > of potential problem sources (including things like interrupt > > > routing problems). At least in the 7.x line, I've seen firewire > > > and USB at various times cause this issue. It might be > > > interesting to compile down to the smallest set of cam-related > > > drivers required to support necessary hardware (omit firewire, > > > for example) and see if you see any improvement. Pinning it down > > > to a specific driver would have significant debugging value :-). > > > > Thanks a lot for the suggestion, I'll be on holiday for one week > > starting tomorrow, I'll try narrowing it down as soon as I'm > > back :-) > > I just made sure that the problem still exists with a freshly csupped > -current (unfortunately, it does), I'll try removing possible culprits > from my kernel next. I've removed all scsi drivers (except those necessary for hptrr to work), usb and firewire from my kernel config (attached). Still no difference, so this really seems to point to a problem in the hptrr driver (possibly made visible by the ata overhaul?). Bye Marc --Multipart=_Fri__14_Aug_2009_17_15_55_+0200_q_koWqRgACTlpyl4 Content-Type: application/octet-stream; name="HAMSTOR" Content-Disposition: attachment; filename="HAMSTOR" Content-Transfer-Encoding: base64 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2FtZDY0CiMKIyBGb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGlzIGZpbGUsIHBsZWFzZSBy ZWFkIHRoZSBjb25maWcoNSkgbWFudWFsIHBhZ2UsCiMgYW5kL29yIHRoZSBoYW5kYm9vayBzZWN0 aW9uIG9uIEtlcm5lbCBDb25maWd1cmF0aW9uIEZpbGVzOgojCiMgICAgaHR0cDovL3d3dy5GcmVl QlNELm9yZy9kb2MvZW5fVVMuSVNPODg1OS0xL2Jvb2tzL2hhbmRib29rL2tlcm5lbGNvbmZpZy1j b25maWcuaHRtbAojCiMgVGhlIGhhbmRib29rIGlzIGFsc28gYXZhaWxhYmxlIGxvY2FsbHkgaW4g L3Vzci9zaGFyZS9kb2MvaGFuZGJvb2sKIyBpZiB5b3UndmUgaW5zdGFsbGVkIHRoZSBkb2MgZGlz dHJpYnV0aW9uLCBvdGhlcndpc2UgYWx3YXlzIHNlZSB0aGUKIyBGcmVlQlNEIFdvcmxkIFdpZGUg V2ViIHNlcnZlciAoaHR0cDovL3d3dy5GcmVlQlNELm9yZy8pIGZvciB0aGUKIyBsYXRlc3QgaW5m b3JtYXRpb24uCiMKIyBBbiBleGhhdXN0aXZlIGxpc3Qgb2Ygb3B0aW9ucyBhbmQgbW9yZSBkZXRh aWxlZCBleHBsYW5hdGlvbnMgb2YgdGhlCiMgZGV2aWNlIGxpbmVzIGlzIGFsc28gcHJlc2VudCBp biB0aGUgLi4vLi4vY29uZi9OT1RFUyBhbmQgTk9URVMgZmlsZXMuCiMgSWYgeW91IGFyZSBpbiBk b3VidCBhcyB0byB0aGUgcHVycG9zZSBvciBuZWNlc3NpdHkgb2YgYSBsaW5lLCBjaGVjayBmaXJz dAojIGluIE5PVEVTLgojCiMgJEZyZWVCU0Q6IHNyYy9zeXMvYW1kNjQvY29uZi9HRU5FUklDLHYg MS41MjMgMjAwOS8wNC8xMCAwMDo0MDo0OCBqZnYgRXhwICQKCmNwdQkJSEFNTUVSCmlkZW50CQlH RU5FUklDCgojIFRvIHN0YXRpY2FsbHkgY29tcGlsZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQg b2YgL2Jvb3QvZGV2aWNlLmhpbnRzCiNoaW50cwkJIkdFTkVSSUMuaGludHMiCQkjIERlZmF1bHQg cGxhY2VzIHRvIGxvb2sgZm9yIGRldmljZXMuCgojIFVzZSB0aGUgZm9sbG93aW5nIHRvIGNvbXBp bGUgaW4gdmFsdWVzIGFjY2Vzc2libGUgdG8gdGhlIGtlcm5lbAojIHRocm91Z2ggZ2V0ZW52KCkg KG9yIGtlbnYoMSkgaW4gdXNlcmxhbmQpLiBUaGUgZm9ybWF0IG9mIHRoZSBmaWxlCiMgaXMgJ3Zh cmlhYmxlPXZhbHVlJywgc2VlIGtlbnYoMSkKIwojIGVudgkJIkdFTkVSSUMuZW52IgoKbWFrZW9w dGlvbnMJREVCVUc9LWcJCSMgQnVpbGQga2VybmVsIHdpdGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMK Cm9wdGlvbnMgCVNDSEVEX1VMRQkJIyBVTEUgc2NoZWR1bGVyCm9wdGlvbnMgCVBSRUVNUFRJT04J CSMgRW5hYmxlIGtlcm5lbCB0aHJlYWQgcHJlZW1wdGlvbgpvcHRpb25zIAlJTkVUCQkJIyBJbnRl ck5FVHdvcmtpbmcKb3B0aW9ucyAJSU5FVDYJCQkjIElQdjYgY29tbXVuaWNhdGlvbnMgcHJvdG9j b2xzCm9wdGlvbnMgCVNDVFAJCQkjIFN0cmVhbSBDb250cm9sIFRyYW5zbWlzc2lvbiBQcm90b2Nv bApvcHRpb25zIAlGRlMJCQkjIEJlcmtlbGV5IEZhc3QgRmlsZXN5c3RlbQpvcHRpb25zIAlTT0ZU VVBEQVRFUwkJIyBFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBzdXBwb3J0Cm9wdGlvbnMgCVVGU19B Q0wJCQkjIFN1cHBvcnQgZm9yIGFjY2VzcyBjb250cm9sIGxpc3RzCm9wdGlvbnMgCVVGU19ESVJI QVNICQkjIEltcHJvdmUgcGVyZm9ybWFuY2Ugb24gYmlnIGRpcmVjdG9yaWVzCm9wdGlvbnMgCVVG U19HSk9VUk5BTAkJIyBFbmFibGUgZ2pvdXJuYWwtYmFzZWQgVUZTIGpvdXJuYWxpbmcKb3B0aW9u cyAJTURfUk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UKb3B0aW9ucyAJTkZT Q0xJRU5UCQkjIE5ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTU0VSVkVSCQkj IE5ldHdvcmsgRmlsZXN5c3RlbSBTZXJ2ZXIKb3B0aW9ucyAJTkZTTE9DS0QJCSMgTmV0d29yayBM b2NrIE1hbmFnZXIKb3B0aW9ucyAJTkZTX1JPT1QJCSMgTkZTIHVzYWJsZSBhcyAvLCByZXF1aXJl cyBORlNDTElFTlQKb3B0aW9ucyAJTVNET1NGUwkJCSMgTVNET1MgRmlsZXN5c3RlbQpvcHRpb25z IAlDRDk2NjAJCQkjIElTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJPQ0ZTCQkJIyBQcm9j ZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVET0ZTKQpvcHRpb25zIAlQU0VVRE9GUwkJIyBQ c2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJR0VPTV9QQVJUX0dQVAkJIyBHVUlE IFBhcnRpdGlvbiBUYWJsZXMuCm9wdGlvbnMgCUdFT01fTEFCRUwJCSMgUHJvdmlkZXMgbGFiZWxp emF0aW9uCm9wdGlvbnMgCUNPTVBBVF80M1RUWQkJIyBCU0QgNC4zIFRUWSBjb21wYXQgKHNndHR5 KQpvcHRpb25zIAlDT01QQVRfSUEzMgkJIyBDb21wYXRpYmxlIHdpdGggaTM4NiBiaW5hcmllcwoj b3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENAojb3B0 aW9ucyAJQ09NUEFUX0ZSRUVCU0Q1CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENQojb3B0aW9u cyAJQ09NUEFUX0ZSRUVCU0Q2CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENgojb3B0aW9ucyAJ Q09NUEFUX0ZSRUVCU0Q3CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENwpvcHRpb25zIAlTQ1NJ X0RFTEFZPTUwMDAJCSMgRGVsYXkgKGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlvbnMg CUtUUkFDRQkJCSMga3RyYWNlKDEpIHN1cHBvcnQKb3B0aW9ucyAJU1RBQ0sJCQkjIHN0YWNrKDkp IHN1cHBvcnQKb3B0aW9ucyAJU1lTVlNITQkJCSMgU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5Cm9w dGlvbnMgCVNZU1ZNU0cJCQkjIFNZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9ucyAJU1lT VlNFTQkJCSMgU1lTVi1zdHlsZSBzZW1hcGhvcmVzCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlf U0NIRURVTElORyAjIFBPU0lYIFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnNpb25zCm9wdGlvbnMg CUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEgQ0RFViBlbnRyeSBpbiAvZGV2CiNvcHRpb25z IAlTVE9QX05NSQkJIyBTdG9wIENQVVMgdXNpbmcgTk1JIGluc3RlYWQgb2YgSVBJCm9wdGlvbnMg IAlIV1BNQ19IT09LUwkJIyBOZWNlc3Nhcnkga2VybmVsIGhvb2tzIGZvciBod3BtYyg0KQojb3B0 aW9ucyAJQVVESVQJCQkjIFNlY3VyaXR5IGV2ZW50IGF1ZGl0aW5nCiNvcHRpb25zIAlLRFRSQUNF X0ZSQU1FCQkjIEVuc3VyZSBmcmFtZXMgYXJlIGNvbXBpbGVkIGluCiNvcHRpb25zIAlLRFRSQUNF X0hPT0tTCQkjIEtlcm5lbCBEVHJhY2UgaG9va3MKCiMgRGVidWdnaW5nIGZvciB1c2UgaW4gLWN1 cnJlbnQKb3B0aW9ucyAJS0RCCQkJIyBFbmFibGUga2VybmVsIGRlYnVnZ2VyIHN1cHBvcnQuCm9w dGlvbnMgCUREQgkJCSMgU3VwcG9ydCBEREIuCm9wdGlvbnMgCUdEQgkJCSMgU3VwcG9ydCByZW1v dGUgR0RCLgpvcHRpb25zIAlJTlZBUklBTlRTCQkjIEVuYWJsZSBjYWxscyBvZiBleHRyYSBzYW5p dHkgY2hlY2tpbmcKb3B0aW9ucyAJSU5WQVJJQU5UX1NVUFBPUlQJIyBFeHRyYSBzYW5pdHkgY2hl Y2tzIG9mIGludGVybmFsIHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5IElOVkFSSUFOVFMKb3B0aW9u cyAJV0lUTkVTUwkJCSMgRW5hYmxlIGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBjeWNs ZXMKI29wdGlvbnMgCVdJVE5FU1NfU0tJUFNQSU4JIyBEb24ndCBydW4gd2l0bmVzcyBvbiBzcGlu bG9ja3MgZm9yIHNwZWVkCgojIE1ha2UgYW4gU01QLWNhcGFibGUga2VybmVsIGJ5IGRlZmF1bHQK b3B0aW9ucyAJU01QCQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2VybmVsCgojIENQVSBm cmVxdWVuY3kgY29udHJvbApkZXZpY2UJCWNwdWZyZXEKCiMgQnVzIHN1cHBvcnQuCmRldmljZQkJ YWNwaQpkZXZpY2UJCXBjaQoKIyBGbG9wcHkgZHJpdmVzCiNkZXZpY2UJCWZkYwoKIyBBVEEgYW5k IEFUQVBJIGRldmljZXMKZGV2aWNlCQlhdGEKZGV2aWNlCQlhdGFkaXNrCQkjIEFUQSBkaXNrIGRy aXZlcwpkZXZpY2UJCWF0YXJhaWQJCSMgQVRBIFJBSUQgZHJpdmVzCmRldmljZQkJYXRhcGljZAkJ IyBBVEFQSSBDRFJPTSBkcml2ZXMKZGV2aWNlCQlhdGFwaWZkCQkjIEFUQVBJIGZsb3BweSBkcml2 ZXMKZGV2aWNlCQlhdGFwaXN0CQkjIEFUQVBJIHRhcGUgZHJpdmVzCm9wdGlvbnMgCUFUQV9TVEFU SUNfSUQJIyBTdGF0aWMgZGV2aWNlIG51bWJlcmluZwoKIyBTQ1NJIENvbnRyb2xsZXJzCiNkZXZp Y2UJCWFoYwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcwojb3B0aW9ucyAJ QUhDX1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcK CQkJCQkjIG91dHB1dC4gIEFkZHMgfjEyOGsgdG8gZHJpdmVyLgojZGV2aWNlCQlhaGQJCSMgQUhB MzkzMjAvMjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBkZXZpY2VzCiNvcHRpb25zIAlBSERfUkVH X1BSRVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1ZwoJCQkJCSMg b3V0cHV0LiAgQWRkcyB+MjE1ayB0byBkcml2ZXIuCiNkZXZpY2UJCWFtZAkJIyBBTUQgNTNDOTc0 IChUZWtyYW0gREMtMzkwKFQpKQojZGV2aWNlCQlocHRpb3AJCSMgSGlnaHBvaW50IFJvY2tldFJh aWQgM3h4eCBzZXJpZXMKI2RldmljZQkJaXNwCQkjIFFsb2dpYyBmYW1pbHkKI2RldmljZSAJaXNw ZncJCSMgRmlybXdhcmUgZm9yIFFMb2dpYyBIQkFzLSBub3JtYWxseSBhIG1vZHVsZQojZGV2aWNl CQltcHQJCSMgTFNJLUxvZ2ljIE1QVC1GdXNpb24KI2RldmljZQkJbmNyCQkjIE5DUi9TeW1iaW9z IExvZ2ljCiNkZXZpY2UJCXN5bQkJIyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3ZXIgY2hpcHNldHMg KyB0aG9zZSBvZiBgbmNyJykKI2RldmljZQkJdHJtCQkjIFRla3JhbSBEQzM5NVUvVVcvRiBEQzMx NVUgYWRhcHRlcnMKCiNkZXZpY2UJCWFkdgkJIyBBZHZhbnN5cyBTQ1NJIGFkYXB0ZXJzCiNkZXZp Y2UJCWFkdwkJIyBBZHZhbnN5cyB3aWRlIFNDU0kgYWRhcHRlcnMKI2RldmljZQkJYWljCQkjIEFk YXB0ZWMgMTVbMDEyXXggU0NTSSBhZGFwdGVycywgQUlDLTZbMjNdNjAuCiNkZXZpY2UJCWJ0CQkj IEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVyIFNDU0kgYWRhcHRlcnMKCiMgU0NTSSBwZXJpcGhl cmFscwpkZXZpY2UJCXNjYnVzCQkjIFNDU0kgYnVzIChyZXF1aXJlZCBmb3IgU0NTSSkKZGV2aWNl CQljaAkJIyBTQ1NJIG1lZGlhIGNoYW5nZXJzCmRldmljZQkJZGEJCSMgRGlyZWN0IEFjY2VzcyAo ZGlza3MpCmRldmljZQkJc2EJCSMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQpkZXZpY2UJ CWNkCQkjIENECmRldmljZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBTQ1NJ IGFjY2VzcykKZGV2aWNlCQlzZXMJCSMgU0NTSSBFbnZpcm9ubWVudGFsIFNlcnZpY2VzIChhbmQg U0FGLVRFKQoKIyBSQUlEIGNvbnRyb2xsZXJzIGludGVyZmFjZWQgdG8gdGhlIFNDU0kgc3Vic3lz dGVtCiNkZXZpY2UJCWFtcgkJIyBBTUkgTWVnYVJBSUQKI2RldmljZQkJYXJjbXNyCQkjIEFyZWNh IFNBVEEgSUkgUkFJRAojWFhYIGl0IGlzIG5vdCA2NC1iaXQgY2xlYW4sIC1zY290dGwKI2Rldmlj ZQkJYXNyCQkjIERQVCBTbWFydFJBSUQgViwgVkkgYW5kIEFkYXB0ZWMgU0NTSSBSQUlECiNkZXZp Y2UJCWNpc3MJCSMgQ29tcGFxIFNtYXJ0IFJBSUQgNSoKI2RldmljZQkJZHB0CQkjIERQVCBTbWFy dGNhY2hlIElJSSwgSVYgLSBTZWUgTk9URVMgZm9yIG9wdGlvbnMKI2RldmljZQkJaHB0bXYJCSMg SGlnaHBvaW50IFJvY2tldFJBSUQgMTgyeApkZXZpY2UJCWhwdHJyCQkjIEhpZ2hwb2ludCBSb2Nr ZXRSQUlEIDE3eHgsIDIyeHgsIDIzeHgsIDI1eHgKI2RldmljZQkJaWlyCQkjIEludGVsIEludGVn cmF0ZWQgUkFJRAojZGV2aWNlCQlpcHMJCSMgSUJNIChBZGFwdGVjKSBTZXJ2ZVJBSUQKI2Rldmlj ZQkJbWx5CQkjIE15bGV4IEFjY2VsZVJBSUQvZVh0cmVtZVJBSUQKI2RldmljZQkJdHdhCQkjIDN3 YXJlIDkwMDAgc2VyaWVzIFBBVEEvU0FUQSBSQUlECgojIFJBSUQgY29udHJvbGxlcnMKI2Rldmlj ZQkJYWFjCQkjIEFkYXB0ZWMgRlNBIFJBSUQKI2RldmljZQkJYWFjcAkJIyBTQ1NJIHBhc3N0aHJv dWdoIGZvciBhYWMgKHJlcXVpcmVzIENBTSkKI2RldmljZQkJaWRhCQkjIENvbXBhcSBTbWFydCBS QUlECiNkZXZpY2UJCW1maQkJIyBMU0kgTWVnYVJBSUQgU0FTCiNkZXZpY2UJCW1seAkJIyBNeWxl eCBEQUM5NjAgZmFtaWx5CiNYWFggcG9pbnRlci9pbnQgd2FybmluZ3MKI2RldmljZQkJcHN0CQkj IFByb21pc2UgU3VwZXJ0cmFrIFNYNjAwMAojZGV2aWNlCQl0d2UJCSMgM3dhcmUgQVRBIFJBSUQK CiMgYXRrYmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhlIFBTLzIgbW91c2UK ZGV2aWNlCQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxlcgpkZXZpY2UJCWF0a2JkCQkj IEFUIGtleWJvYXJkCmRldmljZQkJcHNtCQkjIFBTLzIgbW91c2UKCmRldmljZQkJa2JkbXV4CQkj IGtleWJvYXJkIG11bHRpcGxleGVyCgpkZXZpY2UJCXZnYQkJIyBWR0EgdmlkZW8gY2FyZCBkcml2 ZXIKCmRldmljZQkJc3BsYXNoCQkjIFNwbGFzaCBzY3JlZW4gYW5kIHNjcmVlbiBzYXZlciBzdXBw b3J0CgojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIsIHJlc2VtYmxpbmcg YW4gU0NPIGNvbnNvbGUKZGV2aWNlCQlzYwoKZGV2aWNlCQlhZ3AJCSMgc3VwcG9ydCBzZXZlcmFs IEFHUCBjaGlwc2V0cwoKIyBQQ0NBUkQgKFBDTUNJQSkgc3VwcG9ydAojIFBDTUNJQSBhbmQgY2Fy ZGJ1cyBicmlkZ2Ugc3VwcG9ydAojZGV2aWNlCQljYmIJCSMgY2FyZGJ1cyAoeWVudGEpIGJyaWRn ZQojZGV2aWNlCQlwY2NhcmQJCSMgUEMgQ2FyZCAoMTYtYml0KSBidXMKI2RldmljZQkJY2FyZGJ1 cwkJIyBDYXJkQnVzICgzMi1iaXQpIGJ1cwoKIyBTZXJpYWwgKENPTSkgcG9ydHMKZGV2aWNlCQl1 YXJ0CQkjIEdlbmVyaWMgVUFSVCBkcml2ZXIKCiMgUGFyYWxsZWwgcG9ydApkZXZpY2UJCXBwYwpk ZXZpY2UJCXBwYnVzCQkjIFBhcmFsbGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKZGV2aWNlCQlscHQJ CSMgUHJpbnRlcgpkZXZpY2UJCXBsaXAJCSMgVENQL0lQIG92ZXIgcGFyYWxsZWwKZGV2aWNlCQlw cGkJCSMgUGFyYWxsZWwgcG9ydCBpbnRlcmZhY2UgZGV2aWNlCiNkZXZpY2UJCXZwbwkJIyBSZXF1 aXJlcyBzY2J1cyBhbmQgZGEKCiMgSWYgeW91J3ZlIGdvdCBhICJkdW1iIiBzZXJpYWwgb3IgcGFy YWxsZWwgUENJIGNhcmQgdGhhdCBpcwojIHN1cHBvcnRlZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJp dmVyLCB1bmNvbW1lbnQgdGhlIGZvbGxvd2luZwojIGxpbmUgdG8gZW5hYmxlIGl0IChjb25uZWN0 cyB0byBzaW8sIHVhcnQgYW5kL29yIHBwYyBkcml2ZXJzKToKI2RldmljZQkJcHVjCgojIFBDSSBF dGhlcm5ldCBOSUNzLgojZGV2aWNlCQlkZQkJIyBERUMvSW50ZWwgREMyMXg0eCAoYGBUdWxpcCcn KQpkZXZpY2UJCWVtCQkjIEludGVsIFBSTy8xMDAwIEdpZ2FiaXQgRXRoZXJuZXQgRmFtaWx5CmRl dmljZQkJaWdiCQkjIEludGVsIFBSTy8xMDAwIFBDSUUgU2VydmVyIEdpZ2FiaXQgRmFtaWx5CmRl dmljZQkJaXhnYmUJCSMgSW50ZWwgUFJPLzEwR2JFIFBDSUUgRXRoZXJuZXQgRmFtaWx5CiNkZXZp Y2UJCWxlCQkjIEFNRCBBbTc5MDAgTEFOQ0UgYW5kIEFtNzlDOXh4IFBDbmV0CiNkZXZpY2UJCXRp CQkjIEFsdGVvbiBOZXR3b3JrcyBUaWdvbiBJL0lJIGdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJ dHhwCQkjIDNDb20gM2NSOTkwIChgYFR5cGhvb24nJykKI2RldmljZQkJdngJCSMgM0NvbSAzYzU5 MCwgM2M1OTUgKGBgVm9ydGV4JycpCgojIFBDSSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBj b21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNvZGUuCiMgTk9URTogQmUgc3VyZSB0byBrZWVwIHRo ZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklDcyEKZGV2aWNl CQltaWlidXMJCSMgTUlJIGJ1cyBzdXBwb3J0CiNkZXZpY2UJCWFlCQkjIEF0dGFuc2ljL0F0aGVy b3MgTDIgRmFzdEV0aGVybmV0CiNkZXZpY2UJCWFnZQkJIyBBdHRhbnNpYy9BdGhlcm9zIEwxIEdp Z2FiaXQgRXRoZXJuZXQKI2RldmljZQkJYWxlCQkjIEF0aGVyb3MgQVI4MTIxL0FSODExMy9BUjgx MTQgRXRoZXJuZXQKI2RldmljZQkJYmNlCQkjIEJyb2FkY29tIEJDTTU3MDYvQkNNNTcwOCBHaWdh Yml0IEV0aGVybmV0CiNkZXZpY2UJCWJmZQkJIyBCcm9hZGNvbSBCQ000NDB4IDEwLzEwMCBFdGhl cm5ldAojZGV2aWNlCQliZ2UJCSMgQnJvYWRjb20gQkNNNTcweHggR2lnYWJpdCBFdGhlcm5ldAoj ZGV2aWNlCQlkYwkJIyBERUMvSW50ZWwgMjExNDMgYW5kIHZhcmlvdXMgd29ya2FsaWtlcwojZGV2 aWNlCQlldAkJIyBBZ2VyZSBFVDEzMTAgMTAvMTAwL0dpZ2FiaXQgRXRoZXJuZXQKZGV2aWNlCQlm eHAJCSMgSW50ZWwgRXRoZXJFeHByZXNzIFBSTy8xMDBCICg4MjU1NywgODI1NTgpCiNkZXZpY2UJ CWptZQkJIyBKTWljcm9uIEpNQzI1MCBHaWdhYml0L0pNQzI2MCBGYXN0IEV0aGVybmV0CiNkZXZp Y2UJCWxnZQkJIyBMZXZlbCAxIExYVDEwMDEgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQltc2sJ CSMgTWFydmVsbC9TeXNLb25uZWN0IFl1a29uIElJIEdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJ bmZlCQkjIG5WaWRpYSBuRm9yY2UgTUNQIG9uLWJvYXJkIEV0aGVybmV0CiNkZXZpY2UJCW5nZQkJ IyBOYXRTZW1pIERQODM4MjAgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQludmUJCSMgblZpZGlh IG5Gb3JjZSBNQ1Agb24tYm9hcmQgRXRoZXJuZXQgTmV0d29ya2luZwojZGV2aWNlCQlwY24JCSMg QU1EIEFtNzlDOTd4IFBDSSAxMC8xMDAgKHByZWNlZGVuY2Ugb3ZlciAnbGUnKQojZGV2aWNlCQly ZQkJIyBSZWFsVGVrIDgxMzlDKy84MTY5LzgxNjlTLzgxMTBTCiNkZXZpY2UJCXJsCQkjIFJlYWxU ZWsgODEyOS84MTM5CiNkZXZpY2UJCXNmCQkjIEFkYXB0ZWMgQUlDLTY5MTUgKGBgU3RhcmZpcmUn JykKI2RldmljZQkJc2lzCQkjIFNpbGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFNpUyA5MDAvU2lT IDcwMTYKI2RldmljZQkJc2sJCSMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBnaWdhYml0 IEV0aGVybmV0CiNkZXZpY2UJCXN0ZQkJIyBTdW5kYW5jZSBTVDIwMSAoRC1MaW5rIERGRS01NTBU WCkKI2RldmljZQkJc3RnZQkJIyBTdW5kYW5jZS9UYW1hcmFjayBUQzkwMjEgZ2lnYWJpdCBFdGhl cm5ldAojZGV2aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVtZW50cyBUaHVuZGVyTEFOCiNkZXZpY2UJ CXR4CQkjIFNNQyBFdGhlclBvd2VyIElJICg4M2MxNzAgYGBFUElDJycpCiNkZXZpY2UJCXZnZQkJ IyBWSUEgVlQ2MTJ4IGdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJdnIJCSMgVklBIFJoaW5lLCBS aGluZSBJSQojZGV2aWNlCQl3YgkJIyBXaW5ib25kIFc4OUM4NDBGCmRldmljZQkJeGwJCSMgM0Nv bSAzYzkweCAoYGBCb29tZXJhbmcnJywgYGBDeWNsb25lJycpCgojIFdpcmVsZXNzIE5JQyBjYXJk cwpkZXZpY2UJCXdsYW4JCSMgODAyLjExIHN1cHBvcnQKb3B0aW9ucyAJSUVFRTgwMjExX0RFQlVH CSMgZW5hYmxlIGRlYnVnIG1zZ3MKb3B0aW9ucyAJSUVFRTgwMjExX0FNUERVX0FHRSAjIGFnZSBm cmFtZXMgaW4gQU1QRFUgcmVvcmRlciBxJ3MKZGV2aWNlCQl3bGFuX3dlcAkjIDgwMi4xMSBXRVAg c3VwcG9ydApkZXZpY2UJCXdsYW5fY2NtcAkjIDgwMi4xMSBDQ01QIHN1cHBvcnQKZGV2aWNlCQl3 bGFuX3RraXAJIyA4MDIuMTEgVEtJUCBzdXBwb3J0CmRldmljZQkJd2xhbl9hbXJyCSMgQU1SUiB0 cmFuc21pdCByYXRlIGNvbnRyb2wgYWxnb3JpdGhtCiNkZXZpY2UJCWFuCQkjIEFpcm9uZXQgNDUw MC80ODAwIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgojZGV2aWNlCQlhdGgJCSMgQXRoZXJvcyBwY2kv Y2FyZGJ1cyBOSUMncwojZGV2aWNlCQlhdGhfaGFsCQkjIHBjaS9jYXJkYnVzIGNoaXAgc3VwcG9y dAojb3B0aW9ucwkJQUhfU1VQUE9SVF9BUjU0MTYJIyBlbmFibGUgQVI1NDE2IHR4L3J4IGRlc2Ny aXB0b3JzCiNkZXZpY2UJCWF0aF9yYXRlX3NhbXBsZQkjIFNhbXBsZVJhdGUgdHggcmF0ZSBjb250 cm9sIGZvciBhdGgKI2RldmljZQkJcmFsCQkjIFJhbGluayBUZWNobm9sb2d5IFJUMjUwMCB3aXJl bGVzcyBOSUNzLgojZGV2aWNlCQl3aQkJIyBXYXZlTEFOL0ludGVyc2lsL1N5bWJvbCA4MDIuMTEg d2lyZWxlc3MgTklDcy4KCiMgUHNldWRvIGRldmljZXMuCmRldmljZQkJbG9vcAkJIyBOZXR3b3Jr IGxvb3BiYWNrCmRldmljZQkJcmFuZG9tCQkjIEVudHJvcHkgZGV2aWNlCmRldmljZQkJZXRoZXIJ CSMgRXRoZXJuZXQgc3VwcG9ydApkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVsLgpkZXZpY2UJ CXB0eQkJIyBCU0Qtc3R5bGUgY29tcGF0aWJpbGl0eSBwc2V1ZG8gdHR5cwpkZXZpY2UJCW1kCQkj IE1lbW9yeSAiZGlza3MiCmRldmljZQkJZ2lmCQkjIElQdjYgYW5kIElQdjQgdHVubmVsaW5nCmRl dmljZQkJZmFpdGgJCSMgSVB2Ni10by1JUHY0IHJlbGF5aW5nICh0cmFuc2xhdGlvbikKZGV2aWNl CQlmaXJtd2FyZQkjIGZpcm13YXJlIGFzc2lzdCBtb2R1bGUKCiMgVGhlIGBicGYnIGRldmljZSBl bmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLgojIEJlIGF3YXJlIG9mIHRoZSBhZG1p bmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyEKIyBOb3RlIHRoYXQgJ2Jw ZicgaXMgcmVxdWlyZWQgZm9yIERIQ1AuCmRldmljZQkJYnBmCQkjIEJlcmtlbGV5IHBhY2tldCBm aWx0ZXIKCiMgVVNCIHN1cHBvcnQKI2RldmljZQkJdWhjaQkJIyBVSENJIFBDSS0+VVNCIGludGVy ZmFjZQojZGV2aWNlCQlvaGNpCQkjIE9IQ0kgUENJLT5VU0IgaW50ZXJmYWNlCiNkZXZpY2UJCWVo Y2kJCSMgRUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UgKFVTQiAyLjApCiNkZXZpY2UJCXVzYgkJIyBV U0IgQnVzIChyZXF1aXJlZCkKI2RldmljZQkJdWRicAkJIyBVU0IgRG91YmxlIEJ1bGsgUGlwZSBk ZXZpY2VzCiNkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVyZmFjZSBEZXZpY2VzIgojZGV2aWNl CQl1a2JkCQkjIEtleWJvYXJkCiNkZXZpY2UJCXVscHQJCSMgUHJpbnRlcgojZGV2aWNlCQl1bWFz cwkJIyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGEKI2RldmljZQkJ dW1zCQkjIE1vdXNlCiNkZXZpY2UJCXVyYWwJCSMgUmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAwVVNC IHdpcmVsZXNzIE5JQ3MKI2RldmljZQkJcnVtCQkjIFJhbGluayBUZWNobm9sb2d5IFJUMjUwMVVT QiB3aXJlbGVzcyBOSUNzCiNkZXZpY2UJCXVyaW8JCSMgRGlhbW9uZCBSaW8gNTAwIE1QMyBwbGF5 ZXIKIyBVU0IgU2VyaWFsIGRldmljZXMKI2RldmljZQkJdWFyawkJIyBUZWNobm9sb2dpZXMgQVJL MzExNiBiYXNlZCBzZXJpYWwgYWRhcHRlcnMKI2RldmljZQkJdWJzYQkJIyBCZWxraW4gRjVVMTAz IGFuZCBjb21wYXRpYmxlIHNlcmlhbCBhZGFwdGVycwojZGV2aWNlCQl1ZnRkaQkJIyBGb3IgRlRE SSB1c2Igc2VyaWFsIGFkYXB0ZXJzCiNkZXZpY2UJCXVpcGFxCQkjIFNvbWUgV2luQ0UgYmFzZWQg ZGV2aWNlcwojZGV2aWNlCQl1cGxjb20JCSMgUHJvbGlmaWMgUEwtMjMwMyBzZXJpYWwgYWRhcHRl cnMKI2RldmljZQkJdXNsY29tCQkjIFNJIExhYnMgQ1AyMTAxL0NQMjEwMiBzZXJpYWwgYWRhcHRl cnMKI2RldmljZQkJdXZpc29yCQkjIFZpc29yIGFuZCBQYWxtIGRldmljZXMKI2RldmljZQkJdXZz Y29tCQkjIFVTQiBzZXJpYWwgc3VwcG9ydCBmb3IgRERJIHBvY2tldCdzIFBIUwojIFVTQiBFdGhl cm5ldCwgcmVxdWlyZXMgbWlpYnVzCiNkZXZpY2UJCWF1ZQkJIyBBRE10ZWsgVVNCIEV0aGVybmV0 CiNkZXZpY2UJCWF4ZQkJIyBBU0lYIEVsZWN0cm9uaWNzIFVTQiBFdGhlcm5ldAojZGV2aWNlCQlj ZGNlCQkjIEdlbmVyaWMgVVNCIG92ZXIgRXRoZXJuZXQKI2RldmljZQkJY3VlCQkjIENBVEMgVVNC IEV0aGVybmV0CiNkZXZpY2UJCWt1ZQkJIyBLYXdhc2FraSBMU0kgVVNCIEV0aGVybmV0CiNkZXZp Y2UJCXJ1ZQkJIyBSZWFsVGVrIFJUTDgxNTAgVVNCIEV0aGVybmV0CiNkZXZpY2UJCXVkYXYJCSMg RGF2aWNvbSBETTk2MDFFIFVTQgoKIyBGaXJlV2lyZSBzdXBwb3J0CiNkZXZpY2UJCWZpcmV3aXJl CSMgRmlyZVdpcmUgYnVzIGNvZGUKI2RldmljZQkJc2JwCQkjIFNDU0kgb3ZlciBGaXJlV2lyZSAo UmVxdWlyZXMgc2NidXMgYW5kIGRhKQojZGV2aWNlCQlmd2UJCSMgRXRoZXJuZXQgb3ZlciBGaXJl V2lyZSAobm9uLXN0YW5kYXJkISkKI2RldmljZQkJZndpcAkJIyBJUCBvdmVyIEZpcmVXaXJlIChS RkMgMjczNCwzMTQ2KQojZGV2aWNlCQlkY29ucwkJIyBEdW1iIGNvbnNvbGUgZHJpdmVyCiNkZXZp Y2UJCWRjb25zX2Nyb20JIyBDb25maWd1cmF0aW9uIFJPTSBmb3IgZGNvbnMK --Multipart=_Fri__14_Aug_2009_17_15_55_+0200_q_koWqRgACTlpyl4-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 16:21:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A1F1106568C for ; Fri, 14 Aug 2009 16:21:10 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id A28B58FC43 for ; Fri, 14 Aug 2009 16:21:09 +0000 (UTC) Received: by fxm1 with SMTP id 1so1190107fxm.7 for ; Fri, 14 Aug 2009 09:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Ln3lV8+Y/01Ox05bhsjwwguZfs/h563M+HPSh1wA5xA=; b=byEgT4aFbZ2jrOhF+xG4IOngMQEEQ8xUjvXFnVLQ0E/yakD06kZVQSLxf7uZrHbQ/O c81FxulWXkZ/6rSa1mKSV7Ig7k07dl03Qe+W+z7yaUAXEtQiCekIVvuUnr07CiBugsRL IThN8lOFl1/o8tY+7aX456NgpzSHXnc8Lm0lQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NPg6CoRJrOeqbjuR6fCOUMxB7nHrOkl76Tk/Gg5Fz7D2gHa+IUSCGCI24v5G3/N0og nPnP8UNLStfW5Kirtb5whzeyDJ20aBR1WwkoAzGkmwqb1k6slYrEtIlRjIK70KMd3FYC lyaBvoZmwyb5T+ehyV0sLyKLevJnhTriQHXzI= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.117.1 with SMTP id o1mr598497faq.20.1250266868531; Fri, 14 Aug 2009 09:21:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Aug 2009 18:21:08 +0200 X-Google-Sender-Auth: f39ff812399a0f08 Message-ID: <3bbf2fe10908140921v4ba9ad6drc5225a4f533206b1@mail.gmail.com> From: Attilio Rao To: Alexey Tarasov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 16:21:10 -0000 2009/8/14 Alexey Tarasov : > Hello. > > I have more than 30 Supermicro servers with same config and on all of them I > get kernel panic. > > Here is the screenshots of kgdb output: > http://lexasoft.ru/metamphetamine/Panic/Picture%2073.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2074.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2075.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2076.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2077.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2078.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2079.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2080.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2080.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2082.png > http://lexasoft.ru/metamphetamine/Panic/Picture%2083.png > > Here is dmesg output: > > Copyright (c) 1992-2009 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.2-STABLE #0: Wed Aug 12 01:06:04 MSD 2009 > root@st2.srv.getthebit.com:/usr/obj/usr/src/sys/STORAGE > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz K8-class CPU) > Origin = "GenuineIntel" Id = 0xf65 Stepping = 5 > Features=0xbfebfbff > Features2=0xe59d > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > Logical CPUs per core: 2 > usable memory = 2132484096 (2033 MB) > avail memory = 2056134656 (1960 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP/HT): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.0 on pci0 > pci9: on pcib2 > pcib3: at device 0.0 on pci9 > pci10: on pcib3 > pcib4: irq 17 at device 28.4 on pci0 > pci13: on pcib4 > em0: port 0x4000-0x401f mem > 0xe8000000-0xe801ffff irq 16 at device 0.0 on pci13 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:30:48:91:93:40 > pcib5: irq 16 at device 28.5 on pci0 > pci14: on pcib5 > em1: port 0x5000-0x501f mem > 0xe8200000-0xe821ffff irq 17 at device 0.0 on pci14 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:30:48:91:93:41 > uhci0: port 0x3000-0x301f irq 23 at device > 29.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 0x3020-0x303f irq 19 at device > 29.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 0x3040-0x305f irq 18 at device > 29.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 0x3060-0x307f irq 16 at device > 29.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 0xe8600000-0xe86003ff > irq 23 at device 29.7 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 > pcib6: at device 30.0 on pci0 > pci15: on pcib6 > vgapci0: port 0x6000-0x60ff mem > 0xe0000000-0xe7ffffff,0xe8300000-0xe830ffff irq 16 at device 0.0 on pci15 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > atapci1: port > 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem > 0xe8600400-0xe86007ff irq 19 at device 31.2 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > 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] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > sio1: [FILTER] > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 > 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 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr f2700000f27 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr f2700000f27 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > orm0: at iomem > 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > acd0: CDROM at ata0-slave UDMA33 > ad4: 381554MB at ata2-master SATA150 > ad5: 381554MB at ata2-slave SATA150 > ad6: 381554MB at ata3-master SATA150 > ad7: 476940MB at ata3-slave SATA150 > SMP: AP CPU #1 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad4s1a > WARNING: / was not properly dismounted > WARNING: /data1 was not properly dismounted > WARNING: /data2 was not properly dismounted > WARNING: /data3 was not properly dismounted > WARNING: /data4 was not properly dismounted > WARNING: /tmp was not properly dismounted > WARNING: /usr was not properly dismounted > /usr: mount pending error: blocks 176 files 26 > WARNING: /var was not properly dismounted > /var: mount pending error: blocks 44 files 11 > em0: link state changed to UP > > I have vmcore in /var/crash folder. What debug information is needed to > debug this problem? As you got a dump, could you please list with kgdb the precise point within witness_lock() where the offending spinlock unlocking happens? Can you show the state of the offending spinlock? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 16:22:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E02D106568E for ; Fri, 14 Aug 2009 16:22:51 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id C07118FC65 for ; Fri, 14 Aug 2009 16:22:50 +0000 (UTC) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 9455078FFD; Fri, 14 Aug 2009 20:22:48 +0400 (MSD) Message-ID: <4A858F5C.5060500@haruhiism.net> Date: Fri, 14 Aug 2009 20:22:52 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexey Tarasov References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 16:22:51 -0000 Alexey Tarasov wrote: > I have more than 30 Supermicro servers with same config and on all of them I > get kernel panic. > > I have vmcore in /var/crash folder. What debug information is needed to > debug this problem? > Please elaborate what's "all versions of FreeBSD" in this case. Have you tried the latest -current revision (f.ex. 196200)? If you have a core.txt file, it would surely help. (You can use "crashinfo -d /var/crash" to produce it if it's not there). -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 16:41:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2693106568D for ; Fri, 14 Aug 2009 16:41:55 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7378FC3D for ; Fri, 14 Aug 2009 16:41:55 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 0A70346B1A; Fri, 14 Aug 2009 12:41:55 -0400 (EDT) Date: Fri, 14 Aug 2009 17:41:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Gallatin In-Reply-To: <4A857D16.9070403@cs.duke.edu> Message-ID: References: <4A857D16.9070403@cs.duke.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 16:41:55 -0000 On Fri, 14 Aug 2009, Andrew Gallatin wrote: > I've been porting a closed-source driver to FreeBSD 8 from FreeBSD 5/6/7. It > use the dev_clone() eventhandler to mimic linux-like open semantics (for > linux binary compat). No particular experience with unloading cloning stuff, but have you noticed that in 8.x we now have per-file descriptor device state? This is often the semantics people actually want, rather than cloning. See devfs_set_cdevpriv(9) for details -- there are several synthetic devices in the tree that use it now (although some of them do too much error-checking, and should assert rather than return errors, I think). Robert N M Watson Computer Laboratory University of Cambridge > > From the eventhandler, I do: > > fake_unit = -1; > i = clone_create(&mx_clones, &mx_cdevsw, &fake_unit, cdev, 0); > > if (i) { > /* need to allocate a new /dev/mx_fake.%d device node */ > *cdev = make_dev(&mx_cdevsw, unit2minor(fake_unit), > UID_ROOT, GID_WHEEL, > mode, "mx_fake.%d", fake_unit); > } > > This has worked fine from 5.x through 7.x, > but in 8.x, the /dev/mx_fake.* devices persist after > unload. If anything attempts to access them, the machine > falls over (trace appended). > > I'm assuming these files are lingering because clone_cleanup() > (called at device detach) is not cleaning up these lingering > device nodes. I've tried writing a dtrace script to trace > clone_cleanup. But since that happens from device detach, > dtrace doesn't work (blocks driver unload). I've also tried > setting a breakpoint in ddb(), but the breakpoint seems to > be ignored (other breakpoints work fine, which is odd). > > What changed between 7.x and 8 with respect to device cloning? > > BTW, is there any easier option now in 8.x? > > Thanks, > > Drew > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xffffffff81528a64 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8052f009 > stack pointer = 0x28:0xffffff8018a75730 > frame pointer = 0x28:0xffffff8018a757a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 18087 (cat) > [thread pid 18087 tid 100061 ] > Stopped at devfs_open+0x69: testb $0x4,0x4(%rax) > db> bt > Tracing pid 18087 tid 100061 td 0xffffff000188bab0 > devfs_open() at devfs_open+0x69 > VOP_OPEN_APV() at VOP_OPEN_APV+0x44 > vn_open_cred() at vn_open_cred+0x2f4 > kern_openat() at kern_openat+0x179 > syscall() at syscall+0x28f > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (5, FreeBSD ELF64, open), rip = 0x8007272ac, rsp = > 0x7fffffffe0d8, rbp = 0 --- > db> > Tracing pid 18087 tid 100061 td 0xffffff000188bab0 > devfs_open() at devfs_open+0x69 > VOP_OPEN_APV() at VOP_OPEN_APV+0x44 > vn_open_cred() at vn_open_cred+0x2f4 > kern_openat() at kern_openat+0x179 > syscall() at syscall+0x28f > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (5, FreeBSD ELF64, open), rip = 0x8007272ac, rsp = > 0x7fffffffe0d8, rbp = 0 --- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 16:57:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE715106568E; Fri, 14 Aug 2009 16:57:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7F19D8FC45; Fri, 14 Aug 2009 16:57:54 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2CEE546B35; Fri, 14 Aug 2009 12:57:54 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 4776D8A0AD; Fri, 14 Aug 2009 12:57:53 -0400 (EDT) From: John Baldwin To: Tim Kientzle Date: Fri, 14 Aug 2009 12:57:42 -0400 User-Agent: KMail/1.9.7 References: <200903282317.n2SNHIjI015202@svn.freebsd.org> <200908141004.09354.jhb@freebsd.org> <4A8583DB.1090507@freebsd.org> In-Reply-To: <4A8583DB.1090507@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908141257.42672.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Fri, 14 Aug 2009 12:57:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org, Doug Barton Subject: Re: svn commit: r190514 - head/sys/conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 16:57:54 -0000 On Friday 14 August 2009 11:33:47 am Tim Kientzle wrote: > John Baldwin wrote: > > On Thursday 13 August 2009 2:57:10 pm Doug Barton wrote: > >> Bjoern A. Zeeb wrote: > >>> Author: bz > >>> Date: Sat Mar 28 23:17:18 2009 > >>> New Revision: 190514 > >>> URL: http://svn.freebsd.org/changeset/base/190514 > >>> > >>> Log: > >>> For kernel builds reduce the impact of svnversion, just scanning > >>> src/sys and not the entire src/ tree. > > Performance here I think is a red herring. This is > really about correctness: The SVN revision of usr.bin/ls > simply isn't relevant for the kernel build. Very true. > >> Also, what problem are we really trying to solve here? With a > >> populated cache it takes on average 5 seconds to run all of src, and > >> just under 1 to do only sys. Is 4 seconds really that important to > >> save? With a dry cache I'm sure it takes a little longer, but has > >> anyone actually measured this? > > I just measured over 30 seconds for svnversion against /usr/src and > around 6 for /usr/src/sys (both with cold cache). > > > It takes far longer than 5 seconds here against a local SVN repo over NFS. > > The repo has nothing to do with it. svnversion doesn't > talk to the repo. It only examines the working copy. Ah, true. My checkouts are also over NFS though rather than local disk which may explain it still. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 17:48:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71BB31065692 for ; Fri, 14 Aug 2009 17:48:55 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 54C7E8FC4B for ; Fri, 14 Aug 2009 17:48:55 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id DE4A4C3FB; Fri, 14 Aug 2009 10:49:24 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 3A09D2D6012; Fri, 14 Aug 2009 10:48:54 -0700 (PDT) Message-ID: <4A85A387.1050705@elischer.org> Date: Fri, 14 Aug 2009 10:48:55 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Andrew Thompson References: <20090813073002.GA66860@citylink.fud.org.nz> <4A84452B.4070306@elischer.org> <1280352d0908140845j2709fdcfme317fab916606209@mail.gmail.com> <20090814155357.GA67039@citylink.fud.org.nz> In-Reply-To: <20090814155357.GA67039@citylink.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , current@freebsd.org, Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 17:48:55 -0000 Andrew Thompson wrote: > Julian Elischer wrote: >> Andrew Thompson wrote: >>> Hi, >>> >>> >>> Here is an aesthetic patch to change the usb kernel processes to threads, >>> this hides them from the usual 'ps' output. Please test and review. >>> >>> ?1290 ??? ?DL ? ? 0:00.00 [usbus0] >>> ?[lots and lots more...] >>> ?1309 ??? ?DL ? ? 0:00.00 [usbus4] >>> >> use kproc_kthread_add() >> to create a seoarate usb process and make all the threads belong to >> that process. >> (kproc_kthread_add() will create a new process the first time >> and add more threads to it the more it is run.) > > > Patch updated with the various feedback. > > PID TT STAT TIME COMMAND > 0 ?? DLs 0:00.38 [kernel] > 1 ?? ILs 0:00.01 /sbin/init -- > 2 ?? DL 0:09.66 [g_event] > 3 ?? DL 0:00.20 [g_up] > 4 ?? DL 0:00.20 [g_down] > ... > 18 ?? DL 0:00.06 [acpi_thermal] > 19 ?? DL 0:00.04 [usb] > > % procstat -t 19 > PID TID COMM TDNAME CPU PRI STATE WCHAN > 19 100040 usb usbus0 0 20 sleep - > 19 100041 usb usbus0 0 16 sleep - > 19 100042 usb usbus0 0 20 sleep - > 19 100043 usb usbus0 0 20 sleep - the thread names have full printf capability.. how about giving them different names :-) usbus%d-%d > > > Andrew > > > Index: usb_process.c > =================================================================== > --- usb_process.c (revision 196086) > +++ usb_process.c (working copy) > @@ -63,10 +63,12 @@ > #endif > > #if (__FreeBSD_version >= 800000) > +static struct proc *usbproc; > #define USB_THREAD_CREATE(f, s, p, ...) \ > - kproc_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) > -#define USB_THREAD_SUSPEND(p) kproc_suspend(p,0) > -#define USB_THREAD_EXIT(err) kproc_exit(err) > + kproc_kthread_add((f), (s), &usbproc, (p), RFHIGHPID, \ > + 0, "usb", __VA_ARGS__) > +#define USB_THREAD_SUSPEND(p) kthread_suspend(p,0) > +#define USB_THREAD_EXIT(err) kthread_exit() > #else > #define USB_THREAD_CREATE(f, s, p, ...) \ > kthread_create((f), (s), (p), RFHIGHPID, 0, __VA_ARGS__) > @@ -207,8 +209,8 @@ usb_proc_create(struct usb_process *up, struct mtx > > TAILQ_INIT(&up->up_qhead); > > - cv_init(&up->up_cv, "wmsg"); > - cv_init(&up->up_drain, "dmsg"); > + cv_init(&up->up_cv, "-"); > + cv_init(&up->up_drain, "usbdrain"); > > if (USB_THREAD_CREATE(&usb_process, up, > &up->up_ptr, pmesg)) { > Index: usb_process.h > =================================================================== > --- usb_process.h (revision 196086) > +++ usb_process.h (working copy) > @@ -49,7 +49,11 @@ struct usb_process { > struct cv up_cv; > struct cv up_drain; > > +#if (__FreeBSD_version >= 800000) > + struct thread *up_ptr; > +#else > struct proc *up_ptr; > +#endif > struct thread *up_curtd; > struct mtx *up_mtx; > From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 17:57:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14192106568C for ; Fri, 14 Aug 2009 17:57:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id B84D88FC16 for ; Fri, 14 Aug 2009 17:57:34 +0000 (UTC) Received: by yxe11 with SMTP id 11so2183811yxe.3 for ; Fri, 14 Aug 2009 10:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=gP8jEkCsJfgKOBdZrUSW8u5M4J/S89hDL/VL3pfvFls=; b=P8b6jcOp+x4edufx7aa8qs0oZcFDJh0ljwRvnAx3V9sa0oOj+M+1U80QOjKG+M+POm O6Oa89Nsxnf7cmvEppdaYmdQgJmxNQBIiR3M+T/dVdmujx3c/6y8iPSlZT1FAxsvzZC+ i3ZKqs7EMJ5dAhpjeApqDWJmPwtR5INpfoJ54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=hFEGZ3AxfR4+GmaPy9ZIZWCQ/rJPbMn3AlLbIJo0IOlf3jLcIwmAySroMeOZS1M/4f M3QhKKPlzkCQgaOcnkf6iqugEbcU1KIgGwLHK9F3G5aKie+EMOm57Kd/MwzCL/Wpu32y FGwwj5zURqftnOD4mklRniBNpYhYAOmjzt04Y= Received: by 10.90.67.6 with SMTP id p6mr1166793aga.100.1250272653822; Fri, 14 Aug 2009 10:57:33 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm20424agc.7.2009.08.14.10.57.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Aug 2009 10:57:33 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 14 Aug 2009 10:56:49 -0700 From: Pyun YongHyeon Date: Fri, 14 Aug 2009 10:56:49 -0700 To: Ryan Rogers Message-ID: <20090814175649.GB1311@michelle.cdnetworks.com> References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> <4A84D245.5050703@doghouserepair.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A84D245.5050703@doghouserepair.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 17:57:35 -0000 On Thu, Aug 13, 2009 at 07:56:05PM -0700, Ryan Rogers wrote: > Pyun YongHyeon wrote: > >On Wed, Jul 22, 2009 at 03:26:43PM -0700, Ryan Rogers wrote: > >>Weongyo Jeong wrote: > >>>On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: > >>>>>svn co svn://svn.freebsd.org/base/head > >>>>>svn merge -c -193289 > >>>>> > >>>>>Thereafter, in the root of the repo: > >>>>>svn up > >>>>>svn merge > >>>>Confirmed, running the above set of commands fixed my 88E1116 nfe > >>>>problem > >>>>everything works as it should now. thanks guys for the help. > >>>> > >>>>Sam Fourman Jr. > >>>> > >>>>ps. svn was WAY faster than csup, I think I am going to use svn all > >>>>the time now. > >>>I know that yongari@ knows what the problem is and the solution but he > >>>could not access the internet right now due to relocation to USA. > >>> > >>>It looks he is busy with looking for house and etc... > >>> > >>>regards, > >>>Weongyo Jeong > >>> > >>> > >>> > >>Well, the good news is that r193289 was the only thing keeping my nics > >>from working. I was able to update to current as of today and revert > >>that patch, and everything is working nicely now. So I'll just keep my > >>eye on the commit logs and patch that up by hand whenever I need to > >>update until yongari is able to get situated. > >> > > > >Would you try attached patch and let me know how it goes on your > >box? > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > The patch works great, thanks! Thanks for testing. Unfortunately the change requires more testing on various controllers. 88E1116 PHY is commonly found on Yukon Ultra or newer Yukon controllers as well as NVIDIA controllers. Since we are in 8.0-BETA stage changing common PHY code at this time looks dangerous. From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 18:02:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E9110656A7 for ; Fri, 14 Aug 2009 18:02:36 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9175D8FC4B for ; Fri, 14 Aug 2009 18:02:36 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n7EI2W5s093315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 11:02:32 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A85A6B8.6090400@errno.com> Date: Fri, 14 Aug 2009 11:02:32 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Hans Petter Selasky References: <200908141407.56248.hselasky@c2i.net> In-Reply-To: <200908141407.56248.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org, Florent Thoumie Subject: Re: Panic in rum(4) on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:02:36 -0000 Hans Petter Selasky wrote: > This looks like a WLAN problem rather than an USB problem. Some months back > the WLAN statemachine was converted to taskqueues. In that regard I've seen > 100% reproducable panics, but I did not have time to investigate. If you put > some delay between the "ifconfig" commands on your wlan device, does the > problem disappear? The rum driver violates locking requirements by dropping the net80211 lock in the driver's newstate method in order to pickup the driver softc to do usb operations. This opens a race whereby wpa_supplicant makes a request that clocks the state machine again causing a state transition to be lost: wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost This in turns causes net80211 state to be wrong and causes the crash. I will need to understand why the above is done to see if the driver can be changed to do what is required. I also note other bugs in this routine that can cause further problems. Sam From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 18:20:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A31AE1065693 for ; Fri, 14 Aug 2009 18:20:16 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 5AFFE8FC4D for ; Fri, 14 Aug 2009 18:20:16 +0000 (UTC) Received: by qyk29 with SMTP id 29so1338414qyk.3 for ; Fri, 14 Aug 2009 11:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s43TCmNckBP4/GvAS1YXj79VaUpaCZuTYXppuEJSgcc=; b=aPSInGBK+HkGVes3D8N457FNoXskIp2vby8ThjX2USAYLlzWOzNQPOlYc/MOKUG9f8 K0Ek3G+dXSSMX40Oj/zb9DGhL3LdJLHm9hT+I4lwVIiYYtOeoJxDN0gyqUWYNFTwqk4D hV+/VsjL2Ilht1kMnN0O6GIJvDNhgSL4rQum0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Iex8SagF8IMJT+JlYVspyZlrqHXB3WmovLvweh8TkQYVlJKGPCPwvPDxJbOzrPs8e6 t4wSqYUJ0YuxEX45b7/IXEGXbWJtVeMoc3Z3GYbo0BKaffEBe0KbgZcYIAIg4TCiKoMi dyfpG9X47Angn8iV6hwT9VJZuAeg0+SZom5Rc= MIME-Version: 1.0 Received: by 10.229.54.146 with SMTP id q18mr1467521qcg.53.1250274015738; Fri, 14 Aug 2009 11:20:15 -0700 (PDT) In-Reply-To: <20090814175649.GB1311@michelle.cdnetworks.com> References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> <4A679223.10604@doghouserepair.com> <20090812214932.GH55129@michelle.cdnetworks.com> <4A84D245.5050703@doghouserepair.com> <20090814175649.GB1311@michelle.cdnetworks.com> Date: Fri, 14 Aug 2009 13:20:15 -0500 Message-ID: <11167f520908141120r3970af40s449941c9af114cc7@mail.gmail.com> From: "Sam Fourman Jr." To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ryan Rogers , freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:20:16 -0000 > Thanks for testing. > Unfortunately the change requires more testing on various > controllers. 88E1116 PHY is commonly found on Yukon Ultra or newer > Yukon controllers as well as NVIDIA controllers. Since we are in > 8.0-BETA stage changing common PHY code at this time looks > dangerous. what if you roll back this commit 193289 so that MCP55 controllers work by default again? Sam Fourman Jr From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 18:30:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FDA1106568E for ; Fri, 14 Aug 2009 18:30:49 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCF28FC43 for ; Fri, 14 Aug 2009 18:30:48 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=yNRMRhXmMXIueY2CutwA:9 a=RnpAPjtthqEIQ5MnNBgA:7 a=CsVJQCNcDdC8-IgH_Lgo0U9ELMkA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 240024439; Fri, 14 Aug 2009 20:30:46 +0200 From: Hans Petter Selasky To: Sam Leffler Date: Fri, 14 Aug 2009 20:30:53 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200908141407.56248.hselasky@c2i.net> <4A85A6B8.6090400@errno.com> In-Reply-To: <4A85A6B8.6090400@errno.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908142030.55045.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, Florent Thoumie Subject: Re: Panic in rum(4) on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:30:49 -0000 On Friday 14 August 2009 20:02:32 Sam Leffler wrote: > The rum driver violates locking requirements by dropping the net80211 > lock in the driver's That would apply to at least if_zyd and if_ural aswell. The lock is dropped so that syncronous USB I/O operations can be performed. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 18:31:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E63E1065784 for ; Fri, 14 Aug 2009 18:31:19 +0000 (UTC) (envelope-from florent.thoumie@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id EAFB58FC59 for ; Fri, 14 Aug 2009 18:31:18 +0000 (UTC) Received: by fxm1 with SMTP id 1so1256291fxm.7 for ; Fri, 14 Aug 2009 11:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=9kkAguHh19EMFI3zIWNck9EnHXHcXOm4I8F0YrgRJzk=; b=CyzZU/wbMoyxj6mbzw62slrT0ItnxlIp/89XhOfxEPyLlwa7AOq3N9u98TR4JIw9T0 XyKseMh1y5FPf33wSM108dl9Sns1sm+XywsHzkWn1UFRKqhaHPbLFbrGoVnP2Y330cCM v+xHpx5o+TIXS7OPgwh74+G4SVlrtXDY36QEc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=tbRvBiT7LpRdDf/XwF6PvmbkmGpcJnfpSkS4USsGV6vlHRQ0K1rgoE6lOT5noteWLo 0PmJl6QOrpWzE38/SI15JwCoiASz2BNIK9RDIX9G8Ttgi7Z2dXRhJSV1gYSsj3Sl8A8/ pf6Stb7EMCyyaEiqeQSXMEa0pLdka7AqE47RM= MIME-Version: 1.0 Sender: florent.thoumie@gmail.com Received: by 10.86.51.10 with SMTP id y10mr462471fgy.12.1250273185058; Fri, 14 Aug 2009 11:06:25 -0700 (PDT) In-Reply-To: <4A85A6B8.6090400@errno.com> References: <200908141407.56248.hselasky@c2i.net> <4A85A6B8.6090400@errno.com> From: Florent Thoumie Date: Fri, 14 Aug 2009 19:06:05 +0100 X-Google-Sender-Auth: 990feee42088daea Message-ID: To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Panic in rum(4) on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 18:31:19 -0000 On Fri, Aug 14, 2009 at 7:02 PM, Sam Leffler wrote: > Hans Petter Selasky wrote: > > This looks like a WLAN problem rather than an USB problem. Some months >> back the WLAN statemachine was converted to taskqueues. In that regard I've >> seen 100% reproducable panics, but I did not have time to investigate. If >> you put some delay between the "ifconfig" commands on your wlan device, does >> the problem disappear? >> > > The rum driver violates locking requirements by dropping the net80211 lock > in the driver's newstate method in order to pickup the driver softc to do > usb operations. This opens a race whereby wpa_supplicant makes a request > that clocks the state machine again causing a state transition to be lost: > > wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost > > This in turns causes net80211 state to be wrong and causes the crash. > > I will need to understand why the above is done to see if the driver can be > changed to do what is required. I also note other bugs in this routine that > can cause further problems. I've filed a PR: kern/137776, as suggested by Sam. We should probably move the discussion there. -- Florent Thoumie flz@FreeBSD.org FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 19:13:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2810B106568F for ; Fri, 14 Aug 2009 19:13:08 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 708678FC5A for ; Fri, 14 Aug 2009 19:13:07 +0000 (UTC) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n7EJD5IU090100 for ; Fri, 14 Aug 2009 21:13:06 +0200 (CEST) (envelope-from Johan@double-l.nl) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA1D13.C23DFA4A" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 14 Aug 2009 21:16:02 +0200 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111BC@w2003s01.double-l.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: From 7.2-STABLE to RELENG_8 disk not accessible twe Thread-Index: AcodE6mbB/zuC9YiTuWtmzcbbmekNg== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: From 7.2-STABLE to RELENG_8 disk not accessible twe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:13:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1D13.C23DFA4A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all I have a FreeBSD box that was running a system with 5 disk. 1 for the OS and 2 gmirror pairs =20 the OS is on the motherboards controller as is /dev/mirror/gm0 The second mirror is on a 3ware controller. These disks do not come up anymore. I destroyed the mirror and try to load just one to get my data back. If i put this disk in my other pc (running PCBSD) i can access it with = no problem. This is how my 8-BETA2 system stops. i have the following in my /etc/fstab file. /dev/twed0s1d /mnt/data =20 THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY: ufs: /dev/twed0s1d (/mnt/data) Unknown error; help! ERROR: ABORTING BOOT (sending sigterm to parent)! aug 14 ......... I also did try to use the disk on the onboard controller, same resul, i = can not access it. i enclosed my dmesg from the machine. this is the dmesg from only the base OS (ad4) and the WD 750 GB disk = (ad8)that i cannot access attached to the onboard sata controller. If i replace the base os disk (ad4) and put in the PCBSD disk and start = it up i can see my ad8 disk like before. thanks for your time. b.t.w i am not in this weekend, i will be back on monday ------_=_NextPart_001_01CA1D13.C23DFA4A Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Description: dmesg.txt Content-Disposition: attachment; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KICAgIFRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFs bCByaWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2Yg VGhlIEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgOC4wLUJFVEEyICMwOiBNb24gQXVnIDEw IDE4OjQxOjQ4IENFU1QgMjAwOQ0KICAgIHJvb3RAc2VydmVyLmxvY2FsLmxhbjovdXNyL29iai91 c3Ivc3JjL3N5cy9LUk5MDQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6 IHF1YWxpdHkgMA0KQ1BVOiBJbnRlbChSKSBQZW50aXVtKFIpIEQgQ1BVIDIuODBHSHogKDI3OTgu NjAtTUh6IDY4Ni1jbGFzcyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4 ZjYyICBTdGVwcGluZyA9IDINCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixD TEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUDQpNLFBCRT4NCiAgRmVh dHVyZXMyPTB4ZTQzZDxTU0UzLERURVM2NCxNT04sRFNfQ1BMLFZNWCxDTlhULUlELENYMTYseFRQ UixQRENNPg0KICBBTUQgRmVhdHVyZXM9MHgyMDEwMDAwMDxOWCxMTT4NCiAgQU1EIEZlYXR1cmVz Mj0weDE8TEFIRj4NCiAgVFNDOiBQLXN0YXRlIGludmFyaWFudA0KcmVhbCBtZW1vcnkgID0gMzIy MTIyNTQ3MiAoMzA3MiBNQikNCmF2YWlsIG1lbW9yeSA9IDMxNDQzOTI3MDQgKDI5OTggTUIpDQpB Q1BJIEFQSUMgVGFibGU6IDxJTlRFTCAgMDREVDA0NCA+DQpGcmVlQlNEL1NNUDogTXVsdGlwcm9j ZXNzb3IgU3lzdGVtIERldGVjdGVkOiAyIENQVXMNCkZyZWVCU0QvU01QOiAxIHBhY2thZ2Uocykg eCAyIGNvcmUocykNCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMA0KIGNwdTEgKEFQKTogQVBJQyBJ RDogIDENCmlvYXBpYzA6IENoYW5naW5nIEFQSUMgSUQgdG8gNQ0KaW9hcGljMCA8VmVyc2lvbiAy LjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZA0Ka2JkMSBhdCBrYmRtdXgwDQphY3BpMDogPElO VEVMIDA0RFQwNDQ+IG9uIG1vdGhlcmJvYXJkDQphY3BpMDogW0lUSFJFQURdDQphY3BpMDogUG93 ZXIgQnV0dG9uIChmaXhlZCkNClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5 NTQ1IEh6IHF1YWxpdHkgMTAwMA0KYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1 NDVNSHo+IHBvcnQgMHg0MDgtMHg0MGIgb24gYWNwaTANCmFjcGlfYnV0dG9uMDogPFNsZWVwIEJ1 dHRvbj4gb24gYWNwaTANCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgt MHhjZmYgb24gYWNwaTANCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQpwY2liMTogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC4wIG9uIHBjaTANCnBjaTE6IDxBQ1BJIFBD SSBidXM+IG9uIHBjaWIxDQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAy OC40IG9uIHBjaTANCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyDQpwY2liMzogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAyOC41IG9uIHBjaTANCnBjaTM6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIzDQplbTA6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24g Ni45LjE0PiBwb3J0IDB4MjAwMC0weDIwMWYgbWVtIDB4Yzg5MDAwMDAtMHhjODkxZmZmZiBpcnEg MTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kzDQplbTA6IFVzaW5nIE1TSSBpbnRlcnJ1cHQNCmVtMDog W0ZJTFRFUl0NCmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MTY6NzY6OWQ6ZGM6MmQNCnVoY2kw OiA8SW50ZWwgODI4MDFHIChJQ0g3KSBVU0IgY29udHJvbGxlciBVU0ItQT4gcG9ydCAweDMwODAt MHgzMDlmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwDQp1aGNpMDogW0lUSFJFQURdDQp1 aGNpMDogTGVnU3VwID0gMHgwZjEwDQp1c2J1czA6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBj b250cm9sbGVyIFVTQi1BPiBvbiB1aGNpMA0KdWhjaTE6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVT QiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4MzA2MC0weDMwN2YgaXJxIDE5IGF0IGRldmljZSAy OS4xIG9uIHBjaTANCnVoY2kxOiBbSVRIUkVBRF0NCnVoY2kxOiBMZWdTdXAgPSAweDBmMTANCnVz YnVzMTogPEludGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IG9uIHVoY2kx DQp1aGNpMjogPEludGVsIDgyODAxRyAoSUNINykgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IHBvcnQg MHgzMDQwLTB4MzA1ZiBpcnEgMTggYXQgZGV2aWNlIDI5LjIgb24gcGNpMA0KdWhjaTI6IFtJVEhS RUFEXQ0KdWhjaTI6IExlZ1N1cCA9IDB4MGYxMA0KdXNidXMyOiA8SW50ZWwgODI4MDFHIChJQ0g3 KSBVU0IgY29udHJvbGxlciBVU0ItQz4gb24gdWhjaTINCnVoY2kzOiA8SW50ZWwgODI4MDFHIChJ Q0g3KSBVU0IgY29udHJvbGxlciBVU0ItRD4gcG9ydCAweDMwMjAtMHgzMDNmIGlycSAxNiBhdCBk ZXZpY2UgMjkuMyBvbiBwY2kwDQp1aGNpMzogW0lUSFJFQURdDQp1aGNpMzogTGVnU3VwID0gMHgw ZjEwDQp1c2J1czM6IDxJbnRlbCA4MjgwMUcgKElDSDcpIFVTQiBjb250cm9sbGVyIFVTQi1EPiBv biB1aGNpMw0KZWhjaTA6IDxJbnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxl cj4gbWVtIDB4YzhhMDA0MDAtMHhjOGEwMDdmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNp MA0KZWhjaTA6IFtJVEhSRUFEXQ0KdXNidXM0OiBFSENJIHZlcnNpb24gMS4wDQp1c2J1czQ6IDxJ bnRlbCA4MjgwMUdCL1IgKElDSDcpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTANCnBjaWI0 OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMA0KcGNpNDogPEFD UEkgUENJIGJ1cz4gb24gcGNpYjQNCnR3ZTA6IDwzd2FyZSBTdG9yYWdlIENvbnRyb2xsZXIuIERy aXZlciB2ZXJzaW9uIDEuNTAuMDEuMDAyPiBwb3J0IDB4MTE0MC0weDExNGYgbWVtIDB4Yzg4NTAw MDAtMHhjODg1MDAwZiwweGM4MDAwMDAwLTB4Yzg3ZmZmZmYgaXJxIDIxIGF0IGRldmljZSAwLjAg b24gcGNpNA0KdHdlMDogW0dJQU5ULUxPQ0tFRF0NCnR3ZTA6IFtJVEhSRUFEXQ0KdHdlMDogMiBw b3J0cywgRmlybXdhcmUgRkU4UyAxLjA1LjAwLjA2OCwgQklPUyBCRTdYIDEuMDguMDAuMDQ4DQp2 Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDEwMDAtMHgxMGZmIG1lbSAw eGMwMDAwMDAwLTB4YzdmZmZmZmYsMHhjODg0MDAwMC0weGM4ODRmZmZmIGlycSAxOCBhdCBkZXZp Y2UgNC4wIG9uIHBjaTQNCmVtMTogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlv biA2LjkuMTQ+IHBvcnQgMHgxMTAwLTB4MTEzZiBtZW0gMHhjODgyMDAwMC0weGM4ODNmZmZmLDB4 Yzg4MDAwMDAtMHhjODgxZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDUuMCBvbiBwY2k0DQplbTE6IFtG SUxURVJdDQplbTE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjE2Ojc2OjlkOmRjOjJlDQppc2FiMDog PFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4g b24gaXNhYjANCmF0YXBjaTA6IDxJbnRlbCBJQ0g3IFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAw eDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweDMwYjAtMHgzMGJmIGlycSAxOCBh dCBkZXZpY2UgMzEuMSBvbiBwY2kwDQphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMA0K YXRhMDogW0lUSFJFQURdDQphdGFwY2kxOiA8SW50ZWwgSUNINyBTQVRBMzAwIGNvbnRyb2xsZXI+ IHBvcnQgMHgzMGM4LTB4MzBjZiwweDMwZTQtMHgzMGU3LDB4MzBjMC0weDMwYzcsMHgzMGUwLTB4 MzBlMywweDMwYTAtMHgzMGFmIG1lbSAweGM4YTAwMDAwLTB4YzhhMDAzZmYgaXJxIDE5IGF0IGRl dmljZSAzMS4yIG9uIHBjaTANCmF0YXBjaTE6IFtJVEhSRUFEXQ0KYXRhcGNpMTogQUhDSSBjYWxs ZWQgZnJvbSB2ZW5kb3Igc3BlY2lmaWMgZHJpdmVyDQphdGFwY2kxOiBBSENJIHYxLjEwIGNvbnRy b2xsZXIgd2l0aCA0IDNHYnBzIHBvcnRzLCBQTSBub3Qgc3VwcG9ydGVkDQphdGEyOiA8QVRBIGNo YW5uZWwgMD4gb24gYXRhcGNpMQ0KYXRhMjogW0lUSFJFQURdDQphdGEzOiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMQ0KYXRhMzogW0lUSFJFQURdDQphdGE0OiA8QVRBIGNoYW5uZWwgMj4gb24g YXRhcGNpMQ0KYXRhNDogW0lUSFJFQURdDQphdGE1OiA8QVRBIGNoYW5uZWwgMz4gb24gYXRhcGNp MQ0KYXRhNTogW0lUSFJFQURdDQpwY2kwOiA8c2VyaWFsIGJ1cywgU01CdXM+IGF0IGRldmljZSAz MS4zIChubyBkcml2ZXIgYXR0YWNoZWQpDQphdHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9y dCAweDcwLTB4NzEsMHg3NC0weDc3IGlycSA4IG9uIGFjcGkwDQpmZGMwOiA8ZmxvcHB5IGRyaXZl IGNvbnRyb2xsZXI+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjAgaXJxIDYgZHJxIDIgb24gYWNwaTAN CmZkYzA6IFtGSUxURVJdDQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBw b3J0IDB4NjAsMHg2NCBpcnEgMSBvbiBhY3BpMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAx IG9uIGF0a2JkYzANCmtiZDAgYXQgYXRrYmQwDQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQphdGti ZDA6IFtJVEhSRUFEXQ0KcHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwDQpwc20w OiBbR0lBTlQtTE9DS0VEXQ0KcHNtMDogW0lUSFJFQURdDQpwc20wOiBtb2RlbCBJbnRlbGxpTW91 c2UsIGRldmljZSBJRCAzDQp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgt MHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMA0KdWFydDA6IFtGSUxURVJdDQpjcHUwOiA8 QUNQSSBDUFU+IG9uIGFjcGkwDQpwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJv bD4gb24gY3B1MA0KY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KcDR0Y2MxOiA8Q1BVIEZyZXF1 ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTENCnBtdGltZXIwIG9uIGlzYTANCm9ybTA6IDxJ U0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAwMDAtMHhjYWZmZiwweGNiMDAwLTB4Y2I3ZmYg cG5waWQgT1JNMDAwMCBvbiBpc2EwDQpzYzA6IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgx MDAgb24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0K dmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEwMDAw LTB4YmZmZmYgb24gaXNhMA0KcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuDQpUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQp1c2J1czA6IDEyTWJwcyBGdWxsIFNwZWVkIFVT QiB2MS4wDQp1c2J1czE6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4wDQp1c2J1czI6IDEyTWJw cyBGdWxsIFNwZWVkIFVTQiB2MS4wDQp1c2J1czM6IDEyTWJwcyBGdWxsIFNwZWVkIFVTQiB2MS4w DQp1c2J1czQ6IDQ4ME1icHMgSGlnaCBTcGVlZCBVU0IgdjIuMA0KYWQ0OiA3NjMxOU1CIDxGQjA4 MEM0MDgwIEhQRjA+IGF0IGF0YTItbWFzdGVyIFNBVEExNTANCmFkODogNzE1NDA0TUIgPFdEQyBX RDc1MDBBQUNTLTAwWkpCMCAwMS4wMUIwMT4gYXQgYXRhNC1tYXN0ZXIgU0FUQTMwMA0KR0VPTTog YWQ0czE6IGdlb21ldHJ5IGRvZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAxNmgsNjNz KS4NClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQ0KdWdlbjAuMTogPEludGVsPiBhdCB1c2J1czAN CnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBh ZGRyIDE+IG9uIHVzYnVzMA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0IHVzYnVzMyB1 c2J1czIgdXNidXMxIHVzYnVzMA0KdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkDQp1Z2VuMS4xOiA8SW50ZWw+IGF0IHVzYnVzMQ0KdWh1YjE6IDxJbnRlbCBVSENJ IHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMxDQp1 aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVnZW4yLjE6IDxJ bnRlbD4gYXQgdXNidXMyDQp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czINCnVodWIyOiAyIHBvcnRzIHdpdGggMiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0IHVz YnVzMw0KdWdlbjQuMTogPEludGVsPiBhdCB1c2J1czQNCnVodWIzOiA8SW50ZWwgRUhDSSByb290 IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzNA0KUm9vdCBt b3VudCB3YWl0aW5nIGZvcjogdXNidXM0IHVzYnVzMw0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjog dXNidXM0IHVzYnVzMw0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0IHVzYnVzMw0KdWh1 YjM6IDggcG9ydHMgd2l0aCA4IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1Z2VuMy4xOiA8SW50 ZWw+IGF0IHVzYnVzMw0KdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJl diAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMzDQp1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQNClRyeWluZyB0byBtb3VudCByb290IGZyb20gdWZzOi9kZXYv YWQ0czFhDQplbTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA== ------_=_NextPart_001_01CA1D13.C23DFA4A-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 19:24:04 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DA2106568D; Fri, 14 Aug 2009 19:24:04 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 24CE08FC51; Fri, 14 Aug 2009 19:24:04 +0000 (UTC) Received: from [172.31.193.10] (cpe-069-134-110-200.nc.res.rr.com [69.134.110.200]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n7EJO3sj017093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 15:24:03 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n7EJO3sj017093 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1250277843; bh=gfI5I7KYjEsR9vQ5Y6N4/d6DpztiMclMfQfmNUEKVPw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=kQQrTBSUYmdR3fKiOZyi37s2jGMMrvSWS7rEJHtguIZMbL7FGc/y1A9ATHjUlYnZV nUVk8sBKqbCGVS//dyHT+fU09erNGpOBhTsaM9bhDX5pOFCwkUO3XgZUTq7Ba9rDxG KcxQX8AOGSn91vlyKlXy1pS6a3ZxMtypkljp0Pw0= Message-ID: <4A85B9CD.4050802@cs.duke.edu> Date: Fri, 14 Aug 2009 15:23:57 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Robert Watson References: <4A857D16.9070403@cs.duke.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:24:04 -0000 Robert Watson wrote: > On Fri, 14 Aug 2009, Andrew Gallatin wrote: > >> I've been porting a closed-source driver to FreeBSD 8 from FreeBSD >> 5/6/7. It use the dev_clone() eventhandler to mimic linux-like open >> semantics (for linux binary compat). > > No particular experience with unloading cloning stuff, but have you > noticed that in 8.x we now have per-file descriptor device state? This > is often the semantics people actually want, rather than cloning. See > devfs_set_cdevpriv(9) for details -- there are several synthetic devices > in the tree that use it now (although some of them do too much > error-checking, and should assert rather than return errors, I think). Unfortunately, I think I still need device cloning. The linux semantics are to open /dev/mx0, then call an ioctl to set the device private state. This gets set (in linux) in the "struct file *" ->private_data field. So multiple processes can open /dev/mx0, and they all have different private data. FWIW: >> I'm assuming these files are lingering because clone_cleanup() >> (called at device detach) is not cleaning up these lingering >> device nodes. I've tried writing a dtrace script to trace >> clone_cleanup. But since that happens from device detach, >> dtrace doesn't work (blocks driver unload). I've also tried >> setting a breakpoint in ddb(), but the breakpoint seems to >> be ignored (other breakpoints work fine, which is odd). I think ddb wasn't working because my kernel sources didn't quite match my running kernel. After a kernel & module rebuild, I can watch clone_cleanup(), and I see destroy_devl() get called. It calls devfs_destroy(), as well. The interesting thing is that if I run devd -D -d, and watch the events scroll by, I see the destruction of a device with a null name. Eg: Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev= Processing notify event <...> If I do the same thing on 7.2, I see: Processing event '!system=DEVFS subsystem=CDEV type=DESTROY cdev=mx_fake.0' Pushing table setting system=DEVFS setting subsystem=CDEV setting type=DESTROY setting cdev=mx_fake.0 Processing notify event So I wonder if the node is not getting removed because its name has gotten mangled somehow... Drew From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 19:33:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8DF010656A3; Fri, 14 Aug 2009 19:33:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 533E28FC65; Fri, 14 Aug 2009 19:33:03 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7EJWsVN047411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 22:32:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n7EJWsmS071886; Fri, 14 Aug 2009 22:32:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n7EJWsCu071885; Fri, 14 Aug 2009 22:32:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 14 Aug 2009 22:32:54 +0300 From: Kostik Belousov To: Andrew Gallatin Message-ID: <20090814193254.GO1884@deviant.kiev.zoral.com.ua> References: <4A857D16.9070403@cs.duke.edu> <4A85B9CD.4050802@cs.duke.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+MpzSEZXRO9YNlvm" Content-Disposition: inline In-Reply-To: <4A85B9CD.4050802@cs.duke.edu> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:33:04 -0000 --+MpzSEZXRO9YNlvm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 14, 2009 at 03:23:57PM -0400, Andrew Gallatin wrote: > Robert Watson wrote: > >On Fri, 14 Aug 2009, Andrew Gallatin wrote: > > > >>I've been porting a closed-source driver to FreeBSD 8 from FreeBSD=20 > >>5/6/7. It use the dev_clone() eventhandler to mimic linux-like open=20 > >>semantics (for linux binary compat). > > > >No particular experience with unloading cloning stuff, but have you=20 > >noticed that in 8.x we now have per-file descriptor device state? This= =20 > >is often the semantics people actually want, rather than cloning. See= =20 > >devfs_set_cdevpriv(9) for details -- there are several synthetic devices= =20 > >in the tree that use it now (although some of them do too much=20 > >error-checking, and should assert rather than return errors, I think). >=20 > Unfortunately, I think I still need device cloning. The linux semantics > are to open /dev/mx0, then call an ioctl to set the device private > state. This gets set (in linux) in the "struct file *" ->private_data > field. So multiple processes can open /dev/mx0, and they all have > different private data. This is exactly what you get with cdevpriv. You open a single device node, and driver attaches a private data to the file descriptor. >=20 > FWIW: >=20 > >>I'm assuming these files are lingering because clone_cleanup() > >>(called at device detach) is not cleaning up these lingering > >>device nodes. I've tried writing a dtrace script to trace > >>clone_cleanup. But since that happens from device detach, > >>dtrace doesn't work (blocks driver unload). I've also tried > >>setting a breakpoint in ddb(), but the breakpoint seems to > >>be ignored (other breakpoints work fine, which is odd). >=20 > I think ddb wasn't working because my kernel sources didn't quite > match my running kernel. After a kernel & module rebuild, I can watch > clone_cleanup(), and I see destroy_devl() get called. > It calls devfs_destroy(), as well. >=20 > The interesting thing is that if I run devd -D -d, and watch the > events scroll by, I see the destruction of a device with a > null name. Eg: >=20 > Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTROY cdev=3D' > Pushing table > setting system=3DDEVFS > setting subsystem=3DCDEV > setting type=3DDESTROY > setting cdev=3D > Processing notify event > <...> >=20 > If I do the same thing on 7.2, I see: >=20 > Processing event '!system=3DDEVFS subsystem=3DCDEV type=3DDESTROY cdev=3D= mx_fake.0' > Pushing table > setting system=3DDEVFS > setting subsystem=3DCDEV > setting type=3DDESTROY > setting cdev=3Dmx_fake.0 > Processing notify event >=20 > So I wonder if the node is not getting removed because its > name has gotten mangled somehow... >=20 > Drew > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --+MpzSEZXRO9YNlvm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqFu+YACgkQC3+MBN1Mb4hgJQCeLacbCni2Cyjn1sZGnn8trxTo FmQAn3JdMLNj64jOna1h/1o4OvREIN9K =WYqr -----END PGP SIGNATURE----- --+MpzSEZXRO9YNlvm-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 20:03:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71E51106568D; Fri, 14 Aug 2009 20:03:57 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 33CBE8FC4B; Fri, 14 Aug 2009 20:03:57 +0000 (UTC) Received: from [172.31.193.10] (cpe-069-134-110-200.nc.res.rr.com [69.134.110.200]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n7EK3uad019013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 16:03:56 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n7EK3uad019013 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1250280236; bh=VdZHlhE/hOLb4Z6wAv3y7mu8XCI1xI8HVjeiLA8iuz4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dVctKxBf/+Lsm0E5d5sQWEDJAXBUyNGIzscV2+wpx3XFOkI6nqj1SvuuMfiqhigPU hlxor55pRtRs/H9Zy+tnZbLNpDO8SDFGqc9ughKQtT95+rKVUnQh+haTBRNUd889Un cJPQiAzOYEaA4SaKfjRtVSCaTufCtcLGiUf/EinM= Message-ID: <4A85C325.6050400@cs.duke.edu> Date: Fri, 14 Aug 2009 16:03:49 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Kostik Belousov References: <4A857D16.9070403@cs.duke.edu> <4A85B9CD.4050802@cs.duke.edu> <20090814193254.GO1884@deviant.kiev.zoral.com.ua> In-Reply-To: <20090814193254.GO1884@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: clone_cleanup() doesn't X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 20:03:57 -0000 Kostik Belousov wrote: > This is exactly what you get with cdevpriv. You open a single device > node, and driver attaches a private data to the file descriptor. Ah, so it is. I missed the per-process note in the manpage. I wish we'd have had this back in 5.x, rather than this cloning stuff. Unfortunately, since I have to support those releases, I'm stuck with cloning. FWIW, the fix to my problem was to add D_NEEDMINOR to my cdevsw d_flags, to restore the same behavior as FreeBSD 5/6/7 Drew From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 20:56:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30E14106568C for ; Fri, 14 Aug 2009 20:56:12 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id C2E0E8FC41 for ; Fri, 14 Aug 2009 20:56:11 +0000 (UTC) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n7EKu33t089354; Fri, 14 Aug 2009 22:56:07 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A85CF63.7080603@fgznet.ch> Date: Fri, 14 Aug 2009 22:56:03 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Alexander Leidinger References: <4A832C70.4030600@fgznet.ch> <20090813081538.5361241c6z2lqcn4@webmail.leidinger.net> <4A8465EF.7030604@fgznet.ch> <20090814080400.20646vxm44n78b8c@webmail.leidinger.net> In-Reply-To: <20090814080400.20646vxm44n78b8c@webmail.leidinger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current Subject: Re: tools/kerneldoc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 20:56:12 -0000 Alexander Leidinger wrote: > Quoting Andreas Tobler (from Thu, 13 Aug > 2009 21:13:51 +0200): > >> Alexander Leidinger wrote: >>> Quoting Andreas Tobler (from Wed, 12 Aug >>> 2009 22:56:16 +0200): >>> >>>> Hi, >>>> >>>> does anybody care about this 'kerneldoc' package? >>> [...] >>> >>>> I then dived into the subsys dir and started a 'make all'. >>>> >>>> Here too, I failed since a few .m files are no more or they are >>>> placed on a different place. Well, this was easy, more or less. >>>> Commenting them made the build work, but this is only half the >>>> truth, what about the new .m files? >>> I have patches for the subsys part. A little bit more than only the >>> .m files fix: >>> http://www.leidinger.net/FreeBSD/current/patches/dox.diff >> Thanks, I tried it and I was surprised how long such a build took. >> Well, html and latex more than 5 hours on a p4 2.8GHz. And the >> amount of data is also huge, nearly 2GB of data. > > Normally you need only one of them. How do I say to only build one of them? Is it only possible via the doxygen build options, there I have html and latex equal to true. I guess I need to figure doxygen options, right? a few minutes later.... Bah, here we are: in common-Doxyfile: GENERATE_LATEX = NO >> Could you enlight me with the meaning of the toplevel kerneldoc, is >> this kerneldoc package meant as a whole or is the benefit only in >> the subsys part? > > When I was looking at creating the doxygen stuff, I noticed the > kerneldoc part. For my taste it was too huge. Most people are > interested in specific subsystems, not about everything (those who > really need everything are the minority). For this reason I created > the subsys part. Not every subsystem is available there, but if > someone submits the files for a missing one, I will have a look at them. For me the toplevel kerneldoc part does not work at all. But I did not investigate more. I took the opportunity to try to understand the subsys and I think I got it ;) I tried to build some stuff which is not there yet and I think I got the mechanics. I copied an existing Doxyfile to Doxyfile-dev_firewire and I 'received' what I wanted, well, I need to check the content. Btw, on -CURRENT (RELENG_8/8_STABLE) doxygen is at version 1.5.9. [tc:tools/kerneldoc/subsys] andreast% uname -r 8.0-BETA2 [tc:tools/kerneldoc/subsys] andreast% doxygen --version 1.5.9 Thank you Alexander for the insight! Regards, Andreas From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 21:00:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69C8F106568C for ; Fri, 14 Aug 2009 21:00:27 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 04C9F8FC45 for ; Fri, 14 Aug 2009 21:00:26 +0000 (UTC) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n7EL00AG092650; Fri, 14 Aug 2009 23:00:21 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A85D050.5020709@fgznet.ch> Date: Fri, 14 Aug 2009 23:00:00 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Stefan Bethke References: <49CD4AB4.8080006@fgznet.ch> <200903272339.33763.hselasky@c2i.net> <835EFCB2-DBD3-4296-B5AC-EB6875781C78@lassitu.de> <200903281243.36540.hselasky@c2i.net> <49CE3C71.4060006@fgznet.ch> <6C313AFE-9E97-4A45-B24A-7EF45BA0ACD1@lassitu.de> In-Reply-To: <6C313AFE-9E97-4A45-B24A-7EF45BA0ACD1@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: FreeBSD Current , Hans Petter Selasky Subject: Re: uhci doesn't work on VMware Fusion X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 21:00:27 -0000 Stefan Bethke wrote: > Am 28.03.2009 um 16:04 schrieb Andreas Tobler: > >> Stefan Bethke wrote: >>> Am 28.03.2009 um 12:43 schrieb Hans Petter Selasky: >>>> On Saturday 28 March 2009, Stefan Bethke wrote: >>>>> I've run into the same issue a couple of days ago. >>>>> >>>>> Loading uhci as a module is sufficient to trigger the messages. No >>>>> device was attached during the output below; in other tests I >>>>> noticed >>>>> that uhci appears to not see any device that VMware has attached. >>>> Is it possible to get some debugging from the VM-ware? >>> Apparently some internal debugging can be activated, but I'm not >>> sure what it will show. I can try and find out. >> I did activate this debugging but I could not see anything useful. >> At the same time I had to restart the guest to make this debugging >> active. >> But now I do not seem to be able to trigger the issue we have. >> >> Though, I do not have modules. >> >> I'll try harder. >> At the moment it seems to work here. > > I've jsut tried again, with Fusion 2.0.5 (173382) and current r196085, > and so far everything appears to be working just fine. No issues here either, I do not know what the fix was, but since then I had no issues with running -CURRENT inside VMware Fusion on my MacBook Pro. Still running and running and ... Andreas From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 21:04:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B845B1065696 for ; Fri, 14 Aug 2009 21:04:33 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5728B8FC60 for ; Fri, 14 Aug 2009 21:04:32 +0000 (UTC) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n7EL4UPH095935; Fri, 14 Aug 2009 23:04:30 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A85D15D.4020900@fgznet.ch> Date: Fri, 14 Aug 2009 23:04:29 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dmitry Morozovsky References: <4A847AA5.1030701@fgznet.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current Subject: Re: 8.0-stable/releng? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 21:04:33 -0000 Dmitry Morozovsky wrote: > On Fri, 14 Aug 2009, Dmitry Morozovsky wrote: > > DM> AT> for the record, am I correct that the upcoming 8.0 branch is like this: > DM> AT> > DM> AT> svn ls svn://svn.freebsd.org/base/stable/ > DM> AT> .. > DM> AT> 8/ > DM> AT> ? > DM> AT> > DM> AT> And not under 'releng'? > DM> AT> > DM> AT> I'm a bit confused about naming conventions, releng vs. stable. I have no > DM> AT> problem with either, but which one is the one to be used for BETA-3/RC? > DM> AT> > DM> AT> Is head becoming 9.0 soon? > DM> > DM> AFAIK, releng/8* will be created (by copying stable/8) just before 8.0-RC > > http://wiki.freebsd.org/SubversionPrimer#head-034326f06fb998e6c69d1ce308f1a14aaed51c7e > may sched a bit of light at the whole picture ;) Thanks for the answer, Robert did answer my question. I was confused about not seeing the 'different' trees in the corresponding svn directories as described in the docs. Andreas From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 19:56:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2622106568C; Fri, 14 Aug 2009 19:56:59 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 36CCF8FC5A; Fri, 14 Aug 2009 19:56:58 +0000 (UTC) Received: by bwz19 with SMTP id 19so1750242bwz.37 for ; Fri, 14 Aug 2009 12:56:58 -0700 (PDT) Received: by 10.103.37.34 with SMTP id p34mr710958muj.84.1250279817921; Fri, 14 Aug 2009 12:56:57 -0700 (PDT) Received: from ?192.168.1.150? (93-40-132-223.ip38.fastwebnet.it [93.40.132.223]) by mx.google.com with ESMTPS id n7sm8308619mue.58.2009.08.14.12.56.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 Aug 2009 12:56:56 -0700 (PDT) From: Andrew Thompson To: Julian Elischer In-Reply-To: <4A85A387.1050705@elischer.org> X-Mailer: iPod Mail (7A341) References: <20090813073002.GA66860@citylink.fud.org.nz> <4A84452B.4070306@elischer.org> <1280352d0908140845j2709fdcfme317fab916606209@mail.gmail.com> <20090814155357.GA67039@citylink.fud.org.nz> <4A85A387.1050705@elischer.org> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPod Mail 7A341) Date: Fri, 14 Aug 2009 21:55:48 +0200 X-Mailman-Approved-At: Fri, 14 Aug 2009 21:07:55 +0000 Cc: Kostik Belousov , "current@freebsd.org" , Andrew Thompson , Hans Petter Selasky Subject: Re: usb kthreads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:57:00 -0000 On 14/08/2009, at 19:48, Julian Elischer wrote: > Andrew Thompson wrote: >> Julian Elischer wrote: >>> Andrew Thompson wrote: >>>> Hi, >>>> >>>> >>>> Here is an aesthetic patch to change the usb kernel processes to >>>> threads, >>>> this hides them from the usual 'ps' output. Please test and review. >>>> >>>> ?1290 ??? ?DL ? ? 0:00.00 [usbus0] >>>> ?[lots and lots more...] >>>> ?1309 ??? ?DL ? ? 0:00.00 [usbus4] >>>> >>> use kproc_kthread_add() >>> to create a seoarate usb process and make all the threads belong to >>> that process. >>> (kproc_kthread_add() will create a new process the first time >>> and add more threads to it the more it is run.) >> Patch updated with the various feedback. >> PID TT STAT TIME COMMAND >> 0 ?? DLs 0:00.38 [kernel] >> 1 ?? ILs 0:00.01 /sbin/init -- >> 2 ?? DL 0:09.66 [g_event] >> 3 ?? DL 0:00.20 [g_up] >> 4 ?? DL 0:00.20 [g_down] >> ... >> 18 ?? DL 0:00.06 [acpi_thermal] >> 19 ?? DL 0:00.04 [usb] >> % procstat -t 19 >> PID TID COMM TDNAME CPU PRI STATE >> WCHAN 19 100040 usb usbus0 0 20 >> sleep - 19 100041 usb usbus0 >> 0 16 sleep - 19 100042 usb >> usbus0 0 20 sleep - 19 100043 >> usb usbus0 0 20 sleep - > > the thread names have full printf capability.. > how about giving them different names :-) usbus%d-%d Next job, I'll try to get this change in first. From owner-freebsd-current@FreeBSD.ORG Fri Aug 14 21:22:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FE0F106568D; Fri, 14 Aug 2009 21:22:27 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 008048FC43; Fri, 14 Aug 2009 21:22:26 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7ELMORw014113; Fri, 14 Aug 2009 17:22:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7ELMOUo080250; Fri, 14 Aug 2009 17:22:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E62617302F; Fri, 14 Aug 2009 17:22:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090814212223.E62617302F@freebsd-current.sentex.ca> Date: Fri, 14 Aug 2009 17:22:23 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 21:22:27 -0000 TB --- 2009-08-14 18:49:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-14 18:49:14 - starting HEAD tinderbox run for i386/i386 TB --- 2009-08-14 18:49:14 - cleaning the object tree TB --- 2009-08-14 18:49:33 - cvsupping the source tree TB --- 2009-08-14 18:49:33 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-08-14 18:49:42 - building world TB --- 2009-08-14 18:49:42 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 18:49:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 18:49:42 - TARGET=i386 TB --- 2009-08-14 18:49:42 - TARGET_ARCH=i386 TB --- 2009-08-14 18:49:42 - TZ=UTC TB --- 2009-08-14 18:49:42 - __MAKE_CONF=/dev/null TB --- 2009-08-14 18:49:42 - cd /src TB --- 2009-08-14 18:49:42 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 14 18:49:43 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Aug 14 20:11:49 UTC 2009 TB --- 2009-08-14 20:11:49 - generating LINT kernel config TB --- 2009-08-14 20:11:49 - cd /src/sys/i386/conf TB --- 2009-08-14 20:11:49 - /usr/bin/make -B LINT TB --- 2009-08-14 20:11:50 - building LINT kernel TB --- 2009-08-14 20:11:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 20:11:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 20:11:50 - TARGET=i386 TB --- 2009-08-14 20:11:50 - TARGET_ARCH=i386 TB --- 2009-08-14 20:11:50 - TZ=UTC TB --- 2009-08-14 20:11:50 - __MAKE_CONF=/dev/null TB --- 2009-08-14 20:11:50 - cd /src TB --- 2009-08-14 20:11:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Aug 14 20:11:50 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Aug 14 20:46:05 UTC 2009 TB --- 2009-08-14 20:46:05 - building GENERIC kernel TB --- 2009-08-14 20:46:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 20:46:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 20:46:05 - TARGET=i386 TB --- 2009-08-14 20:46:05 - TARGET_ARCH=i386 TB --- 2009-08-14 20:46:05 - TZ=UTC TB --- 2009-08-14 20:46:05 - __MAKE_CONF=/dev/null TB --- 2009-08-14 20:46:05 - cd /src TB --- 2009-08-14 20:46:05 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Aug 14 20:46:06 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Aug 14 21:12:17 UTC 2009 TB --- 2009-08-14 21:12:17 - building PAE kernel TB --- 2009-08-14 21:12:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 21:12:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 21:12:17 - TARGET=i386 TB --- 2009-08-14 21:12:17 - TARGET_ARCH=i386 TB --- 2009-08-14 21:12:17 - TZ=UTC TB --- 2009-08-14 21:12:17 - __MAKE_CONF=/dev/null TB --- 2009-08-14 21:12:17 - cd /src TB --- 2009-08-14 21:12:17 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Aug 14 21:12:17 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Fri Aug 14 21:19:03 UTC 2009 TB --- 2009-08-14 21:19:03 - building XEN kernel TB --- 2009-08-14 21:19:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-14 21:19:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-14 21:19:03 - TARGET=i386 TB --- 2009-08-14 21:19:03 - TARGET_ARCH=i386 TB --- 2009-08-14 21:19:03 - TZ=UTC TB --- 2009-08-14 21:19:03 - __MAKE_CONF=/dev/null TB --- 2009-08-14 21:19:03 - cd /src TB --- 2009-08-14 21:19:03 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Aug 14 21:19:04 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh XEN cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug trap.o(.text+0xb82): In function `trap': /src/sys/i386/i386/trap.c:216: undefined reference to `ipi_nmi_handler' *** Error code 1 Stop in /obj/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-14 21:22:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-14 21:22:23 - ERROR: failed to build XEN kernel TB --- 2009-08-14 21:22:23 - 7530.29 user 628.68 system 9188.81 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 00:28:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94E48106568E for ; Sat, 15 Aug 2009 00:28:31 +0000 (UTC) (envelope-from daniel@toomuchdata.se) Received: from pne-smtpout1-sn1.fre.skanova.net (pne-smtpout1-sn1.fre.skanova.net [81.228.11.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCAE8FC45 for ; Sat, 15 Aug 2009 00:28:31 +0000 (UTC) Received: from royal64.emp.zapto.org (195.198.193.168) by pne-smtpout1-sn1.fre.skanova.net (7.3.140.3) (authenticated as u35605266) id 4A683C78001E6D24; Sat, 15 Aug 2009 01:19:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 15 Aug 2009 01:19:21 +0200 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A635E95B@royal64.emp.zapto.org> In-Reply-To: <20090814171555.d1f9b036.ubm.freebsd@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: run interrupt driven hooks: still waiting for xpt_config Thread-Index: Acoc+m+VM4mf4PU5QbOEtuua1wu7JQAN4mzg References: <20090708192642.6b30167e.ubm@u-boot-man.de><20090708225048.ec9d9cad.ubm@u-boot-man.de><20090710200352.72ef6804.ubm@u-boot-man.de><20090711205837.46b11405.ubm@u-boot-man.de><20090711222304.fc99056a.ubm@u-boot-man.de><20090712122316.4f63fc62.ubm@u-boot-man.de><20090712181034.93811d03.ubm@u-boot-man.de><20090712194547.9e573116.ubm@u-boot-man.de><20090722201750.4ff23293.ubm@u-boot-man.de><20090806230909.d01e844a.ubm@u-boot-man.de><20090808002354.61c6c5a3.ubm@u-boot-man.de><20090808235013.eab98028.ubm@u-boot-man.de><20090814151826.66e5077e.ubm.freebsd@gmail.com> <20090814171555.d1f9b036.ubm.freebsd@gmail.com> From: "Daniel Eriksson" To: X-Mailman-Approved-At: Sat, 15 Aug 2009 01:37:32 +0000 Cc: Marc UBM Subject: RE: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 00:28:31 -0000 Marc UBM wrote: > Still no difference, so this really seems to point to a problem > in the hptrr driver (possibly made visible by the ata overhaul?). I'm having similar problems with a newly built box. Using RELENG_8 from a few days ago it runs fine, but refuses to boot when I plug in my Highpoint RocketRAID 2340 card. It boots up and works fine using RELENG_7 from yesterday. Below is the dmesg and pciconf output. The motherboard is a Gigabyte GA-MA78G-DS3H (AMD 780G/SB700 chipset). /Daniel Eriksson Copyright (c) 1992-2009 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.2-STABLE #0: Thu Aug 13 16:19:00 CEST 2009 root@xxx:/usr/obj/usr/src/sys/XXX Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (3114.20-MHz K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x60fb2 Stepping =3D 2 =20 Features=3D0x178bfbff Features2=3D0x2001 AMD Features=3D0xea500800 AMD Features2=3D0x11f TSC: P-state invariant Cores per package: 2 usable memory =3D 4149313536 (3957 MB) avail memory =3D 3980779520 (3796 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 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfce0000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xee00-0xeeff mem 0xd8000000-0xdfffffff,0xfdde0000-0xfddeffff,0xfdc00000-0xfdcfffff irq 18 at device 5.0 on pci1 pci1: at device 5.1 (no driver attached) pcib2: irq 18 at device 2.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 hptrr0: port 0xde00-0xdeff mem 0xfda00000-0xfdafffff irq 18 at device 4.0 on pci3 hptrr: adapter at PCI 3:4:0, IRQ 18 pcib4: at device 0.2 on pci2 pci4: on pcib4 hptrr1: port 0xce00-0xceff mem 0xfd800000-0xfd8fffff irq 18 at device 4.0 on pci4 hptrr: adapter at PCI 4:4:0, IRQ 18 pcib5: irq 18 at device 10.0 on pci0 pci5: on pcib5 re0: port 0xbe00-0xbeff mem 0xfdeff000-0xfdefffff,0xfdee0000-0xfdeeffff irq 18 at device 0.0 on pci5 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1f:d0:9f:04:9b re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 6 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.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: 3 ports with 3 removable, self powered ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 3 ports with 3 removable, self powered ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 3 ports with 3 removable, self powered ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 3 ports each: usb3 usb4 usb5: on ehci1 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib6: at device 20.4 on pci0 pci6: on pcib6 ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb6: OHCI version 1.0, legacy support usb6: SMM does not respond, resetting usb6: on ohci4 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 cryptosoft0: on motherboard ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> 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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] 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 Timecounters tick every 1.000 msec hptrr: start channel [1,0] hptrr: start channel [1,1] hptrr: start channel [1,2] hptrr: start channel [1,3] hptrr: start channel [1,4] hptrr: start channel [1,5] hptrr: start channel [1,6] hptrr: start channel [1,7] hptrr: channel [1,0] started successfully hptrr: channel [1,1] started successfully hptrr: channel [1,2] started successfully hptrr: channel [1,3] started successfully hptrr: channel [1,4] started successfully hptrr: channel [1,5] started successfully hptrr: channel [1,6] started successfully hptrr: channel [1,7] started successfully hptrr1: [GIANT-LOCKED] hptrr1: [ITHREAD] hptrr0: [GIANT-LOCKED] hptrr0: [ITHREAD] ad4: 305244MB at ata2-master SATA300 ad8: 953868MB at ata4-master SATA300 ad10: 953869MB at ata5-master SATA300 da0 at hptrr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da1 at hptrr0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-0 device da2 at hptrr0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-0 device da3 at hptrr0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-0 device da4 at hptrr0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-0 device da5 at hptrr0 bus 0 target 5 lun 0 da5: Fixed Direct Access SCSI-0 device da6 at hptrr0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-0 device da7 at hptrr0 bus 0 target 7 lun 0 da7: Fixed Direct Access SCSI-0 device SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a # pciconf -lv hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x96001022 = chip=3D0x96001022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x96021022 = chip=3D0x96021022 rev=3D0x00 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' class =3D bridge subclass =3D PCI-PCI pcib2@pci0:0:2:0: class=3D0x060400 card=3D0x96001022 = chip=3D0x96031022 rev=3D0x00 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' class =3D bridge subclass =3D PCI-PCI pcib5@pci0:0:10:0: class=3D0x060400 card=3D0x96001022 = chip=3D0x96091022 rev=3D0x00 hdr=3D0x01 vendor =3D 'Advanced Micro Devices (AMD)' class =3D bridge subclass =3D PCI-PCI atapci0@pci0:0:17:0: class=3D0x010601 card=3D0xb0021458 = chip=3D0x43911002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 SATA Controller [AHCI mode]' class =3D mass storage subclass =3D SATA ohci0@pci0:0:18:0: class=3D0x0c0310 card=3D0x50041458 = chip=3D0x43971002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 USB OHCI0 Controller' class =3D serial bus subclass =3D USB ohci1@pci0:0:18:1: class=3D0x0c0310 card=3D0x50041458 = chip=3D0x43981002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 USB OHCI1 Controller' class =3D serial bus subclass =3D USB ehci0@pci0:0:18:2: class=3D0x0c0320 card=3D0x50041458 = chip=3D0x43961002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 USB EHCI Controller' class =3D serial bus subclass =3D USB ohci2@pci0:0:19:0: class=3D0x0c0310 card=3D0x50041458 = chip=3D0x43971002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 USB OHCI0 Controller' class =3D serial bus subclass =3D USB ohci3@pci0:0:19:1: class=3D0x0c0310 card=3D0x50041458 = chip=3D0x43981002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 USB OHCI1 Controller' class =3D serial bus subclass =3D USB ehci1@pci0:0:19:2: class=3D0x0c0320 card=3D0x50041458 = chip=3D0x43961002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 USB EHCI Controller' class =3D serial bus subclass =3D USB none0@pci0:0:20:0: class=3D0x0c0500 card=3D0x43851458 = chip=3D0x43851002 rev=3D0x3a hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'ATI SMBus (ATI RD600/RS600)' class =3D serial bus subclass =3D SMBus atapci1@pci0:0:20:1: class=3D0x01018a card=3D0x50021458 = chip=3D0x439c1002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'PATA 133 Controller (SB7xx)' class =3D mass storage subclass =3D ATA isab0@pci0:0:20:3: class=3D0x060100 card=3D0x439d1002 = chip=3D0x439d1002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 LPC host controller' class =3D bridge subclass =3D PCI-ISA pcib6@pci0:0:20:4: class=3D0x060401 card=3D0x00000000 = chip=3D0x43841002 rev=3D0x00 hdr=3D0x01 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'IXP SB600 PCI to PCI Bridge' class =3D bridge subclass =3D PCI-PCI ohci4@pci0:0:20:5: class=3D0x0c0310 card=3D0x50041458 = chip=3D0x43991002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'SB700 USB OHCI2 Controller' class =3D serial bus subclass =3D USB hostb1@pci0:0:24:0: class=3D0x060000 card=3D0x00000000 = chip=3D0x11001022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration' class =3D bridge subclass =3D HOST-PCI hostb2@pci0:0:24:1: class=3D0x060000 card=3D0x00000000 = chip=3D0x11011022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Address Map' class =3D bridge subclass =3D HOST-PCI hostb3@pci0:0:24:2: class=3D0x060000 card=3D0x00000000 = chip=3D0x11021022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) DRAM = Controller' class =3D bridge subclass =3D HOST-PCI hostb4@pci0:0:24:3: class=3D0x060000 card=3D0x00000000 = chip=3D0x11031022 rev=3D0x00 hdr=3D0x00 vendor =3D 'Advanced Micro Devices (AMD)' device =3D 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control' class =3D bridge subclass =3D HOST-PCI vgapci0@pci0:1:5:0: class=3D0x030000 card=3D0xd0001458 = chip=3D0x96101002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' device =3D 'Radeon HD 3200 Integrated Graphics Processor (780G)' class =3D display subclass =3D VGA none1@pci0:1:5:1: class=3D0x040300 card=3D0x960f1458 = chip=3D0x960f1002 rev=3D0x00 hdr=3D0x00 vendor =3D 'ATI Technologies Inc. / Advanced Micro Devices, = Inc.' class =3D multimedia subclass =3D HDA pcib3@pci0:2:0:0: class=3D0x060400 card=3D0x00000000 = chip=3D0x03408086 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '41210 [Lanai] Serial to Parallel PCI Bridge = A-segment Bridge' class =3D bridge subclass =3D PCI-PCI pcib4@pci0:2:0:2: class=3D0x060400 card=3D0x00000000 = chip=3D0x03418086 rev=3D0x09 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '41210 [Lanai] Serial to Parallel PCI Bridge = B-segment Bridge' class =3D bridge subclass =3D PCI-PCI hptrr0@pci0:3:4:0: class=3D0x010000 card=3D0x11ab11ab = chip=3D0x23401103 rev=3D0x09 hdr=3D0x00 vendor =3D 'Triones Technologies Inc. (HighPoint)' device =3D 'RocketRAID 2340 16 Port SATA-II Controller' class =3D mass storage subclass =3D SCSI hptrr1@pci0:4:4:0: class=3D0x010000 card=3D0x11ab11ab = chip=3D0x23401103 rev=3D0x09 hdr=3D0x00 vendor =3D 'Triones Technologies Inc. (HighPoint)' device =3D 'RocketRAID 2340 16 Port SATA-II Controller' class =3D mass storage subclass =3D SCSI re0@pci0:5:0:0: class=3D0x020000 card=3D0xe0001458 chip=3D0x816810ec = rev=3D0x02 hdr=3D0x00 vendor =3D 'Realtek Semiconductor' device =3D 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' class =3D network subclass =3D ethernet From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 07:44:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98BA8106568C; Sat, 15 Aug 2009 07:44:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 706478FC52; Sat, 15 Aug 2009 07:44:18 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7F7iGq5036906; Sat, 15 Aug 2009 03:44:16 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7F7iFak077828; Sat, 15 Aug 2009 03:44:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 876BB7302F; Sat, 15 Aug 2009 03:44:15 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090815074415.876BB7302F@freebsd-current.sentex.ca> Date: Sat, 15 Aug 2009 03:44:15 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 07:44:18 -0000 TB --- 2009-08-15 05:08:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-15 05:08:04 - starting HEAD tinderbox run for i386/i386 TB --- 2009-08-15 05:08:04 - cleaning the object tree TB --- 2009-08-15 05:08:43 - cvsupping the source tree TB --- 2009-08-15 05:08:43 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-08-15 05:08:51 - building world TB --- 2009-08-15 05:08:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 05:08:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 05:08:51 - TARGET=i386 TB --- 2009-08-15 05:08:51 - TARGET_ARCH=i386 TB --- 2009-08-15 05:08:51 - TZ=UTC TB --- 2009-08-15 05:08:51 - __MAKE_CONF=/dev/null TB --- 2009-08-15 05:08:51 - cd /src TB --- 2009-08-15 05:08:51 - /usr/bin/make -B buildworld >>> World build started on Sat Aug 15 05:08:53 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Aug 15 06:31:12 UTC 2009 TB --- 2009-08-15 06:31:12 - generating LINT kernel config TB --- 2009-08-15 06:31:12 - cd /src/sys/i386/conf TB --- 2009-08-15 06:31:12 - /usr/bin/make -B LINT TB --- 2009-08-15 06:31:12 - building LINT kernel TB --- 2009-08-15 06:31:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 06:31:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 06:31:12 - TARGET=i386 TB --- 2009-08-15 06:31:12 - TARGET_ARCH=i386 TB --- 2009-08-15 06:31:12 - TZ=UTC TB --- 2009-08-15 06:31:12 - __MAKE_CONF=/dev/null TB --- 2009-08-15 06:31:12 - cd /src TB --- 2009-08-15 06:31:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 15 06:31:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Aug 15 07:05:54 UTC 2009 TB --- 2009-08-15 07:05:54 - building GENERIC kernel TB --- 2009-08-15 07:05:54 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 07:05:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 07:05:54 - TARGET=i386 TB --- 2009-08-15 07:05:54 - TARGET_ARCH=i386 TB --- 2009-08-15 07:05:54 - TZ=UTC TB --- 2009-08-15 07:05:54 - __MAKE_CONF=/dev/null TB --- 2009-08-15 07:05:54 - cd /src TB --- 2009-08-15 07:05:54 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Aug 15 07:05:54 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Aug 15 07:34:05 UTC 2009 TB --- 2009-08-15 07:34:05 - building PAE kernel TB --- 2009-08-15 07:34:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 07:34:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 07:34:05 - TARGET=i386 TB --- 2009-08-15 07:34:05 - TARGET_ARCH=i386 TB --- 2009-08-15 07:34:05 - TZ=UTC TB --- 2009-08-15 07:34:05 - __MAKE_CONF=/dev/null TB --- 2009-08-15 07:34:05 - cd /src TB --- 2009-08-15 07:34:05 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Aug 15 07:34:06 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Aug 15 07:40:49 UTC 2009 TB --- 2009-08-15 07:40:49 - building XEN kernel TB --- 2009-08-15 07:40:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 07:40:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 07:40:49 - TARGET=i386 TB --- 2009-08-15 07:40:49 - TARGET_ARCH=i386 TB --- 2009-08-15 07:40:49 - TZ=UTC TB --- 2009-08-15 07:40:49 - __MAKE_CONF=/dev/null TB --- 2009-08-15 07:40:49 - cd /src TB --- 2009-08-15 07:40:49 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Aug 15 07:40:49 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh XEN cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug trap.o(.text+0xb82): In function `trap': /src/sys/i386/i386/trap.c:216: undefined reference to `ipi_nmi_handler' *** Error code 1 Stop in /obj/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-15 07:44:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-15 07:44:15 - ERROR: failed to build XEN kernel TB --- 2009-08-15 07:44:15 - 7535.02 user 632.20 system 9370.84 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 08:26:45 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57142106568B for ; Sat, 15 Aug 2009 08:26:45 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2B8DC8FC55 for ; Sat, 15 Aug 2009 08:26:45 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1McEb3-000MCO-Bm; Sat, 15 Aug 2009 08:26:41 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 29A192951DD6; Sat, 15 Aug 2009 17:26:41 +0900 (JST) Date: Sat, 15 Aug 2009 17:26:41 +0900 Message-ID: From: Randy Bush To: Dmitry Marakasov In-Reply-To: <20090814005324.GA1552@hades.panopticon> References: <20090801022523.GA93222@hades.panopticon> <4A84A901.4010109@elischer.org> <20090814005324.GA1552@hades.panopticon> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@FreeBSD.org, Julian Elischer Subject: Re: panic in ipfw with recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 08:26:45 -0000 >> in line 2061 of ip_fw2.c in the crhold() >> the argument should be pcb->inp_cred, not inp->cred >> >> 2059 if (pcb != NULL) { >> 2060 *uc = crhold(inp->inp_cred); <--s/inp/pcb/ >> 2061 *ugid_lookupp = 1; >> 2062 } > > Confirmed, this fixes the problem. Filtering by gid works and no > panics. Thanks a lot! also confirmed. randy From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 10:43:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87349106568B for ; Sat, 15 Aug 2009 10:43:13 +0000 (UTC) (envelope-from lexasoft@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3278FC57 for ; Sat, 15 Aug 2009 10:43:12 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so689210qwe.7 for ; Sat, 15 Aug 2009 03:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=r527MiztbHJdETy8/rrkqToX8r692u91d6hxgJnK3dc=; b=Go8Si6jLOh8deg8YgdvTCi1kO8ueoit9ea2VrISdm9w1g95MijpF176DYSShAaRNzG SMxqvwm3P9AQ3kZkDMhNbcruS7+F4hiVFf440frMk8sP/R9qXXHHvsmDntQBNVTKMDk5 2Ag/QWC+bXobnRteeUuDO3sgIoD0L9wYv1X+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ago8iYPpw4uNkFYrDgXtqy+tKGBJhdNjC7PnFewrWFjtBcaiOzlx6GayumzO/AhCk6 C8G4cbmvy+SahY014SbNLT/M3Yd6YQs265MkIqbGMWJsy/E77ux0NiKCvLWV0bVVfIxt xQna9iOASTIXmr41WcZPMt7TZVGRhBi/Y1m/4= MIME-Version: 1.0 Received: by 10.229.13.12 with SMTP id z12mr1609822qcz.102.1250332990512; Sat, 15 Aug 2009 03:43:10 -0700 (PDT) In-Reply-To: <4A858F5C.5060500@haruhiism.net> References: <4A858F5C.5060500@haruhiism.net> Date: Sat, 15 Aug 2009 14:43:10 +0400 Message-ID: From: Alexey Tarasov To: Kamigishi Rei , current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 10:43:13 -0000 Hello. Here is core.txt:http://lexasoft.ru/metamphetamine/Panic/core.txt.0 'All versions' means all versions before and including 7-STABLE. This servers were used before on Linux. There were no problems. I have not tried latest 8.0 version. 2009/8/14 Kamigishi Rei > Alexey Tarasov wrote: > >> I have more than 30 Supermicro servers with same config and on all of th= em >> I >> get kernel panic. >> >> I have vmcore in /var/crash folder. What debug information is needed to >> debug this problem? >> >> > Please elaborate what's "all versions of FreeBSD" in this case. Have you > tried the latest -current revision (f.ex. 196200)? > If you have a core.txt file, it would surely help. (You can use "crashinf= o > -d /var/crash" to produce it if it's not there). > > -- > Kamigishi Rei > KREI-RIPE > --=20 (\__/) (=3D'.'=3D) E[: | | | | :]=D0=97 (")_(") Alexey Tarasov From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 10:48:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 504A4106568B for ; Sat, 15 Aug 2009 10:48:21 +0000 (UTC) (envelope-from lexasoft@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 05CA18FC3D for ; Sat, 15 Aug 2009 10:48:20 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so689583qwe.7 for ; Sat, 15 Aug 2009 03:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=33MYz5UDReQzDX4JqEOWHdmm16eqETHKvCeSqM+4uCY=; b=h6NpjJ6h8wFQLSF1ijiq58A4HtLv2GYQaQ4KqBwphKsquYfyp53NPHRi5vizvsw1wX p1EJ10yFgRjiL0VAlBWRVf7RMzthmpa/j4RRr/zxQMVSO4oJ/q02MuOuZzKa2xsqYFID 4DiypVgOe2MT3FJAtZyOUzd/0hu18l7MiAwms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Vw94gzK00XZHEjOz11m+qFLK56kqtIykg2xowSnxGdCcvJDNOeUfF6yTWEWcWfj1tx zYdIvWdK/+TOZnROzxZpA9vPyKYqW6JhYbqR1/xLBvtR1LNd4VG//58y2J80YM80/J7s 21qU1Y63EVsNlNMeOP5ca1kNMuTGP0SIMfJOM= MIME-Version: 1.0 Received: by 10.229.111.195 with SMTP id t3mr1561465qcp.44.1250333300161; Sat, 15 Aug 2009 03:48:20 -0700 (PDT) In-Reply-To: <3bbf2fe10908140921v4ba9ad6drc5225a4f533206b1@mail.gmail.com> References: <3bbf2fe10908140921v4ba9ad6drc5225a4f533206b1@mail.gmail.com> Date: Sat, 15 Aug 2009 14:48:20 +0400 Message-ID: From: Alexey Tarasov To: current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 10:48:21 -0000 Hello. Would you please tell me what GDB commands should I use to provide this information? I'm not so familiar with GDB, I've used it before only for debugging simple C++ applications. 2009/8/14 Attilio Rao > > As you got a dump, could you please list with kgdb the precise point > within witness_lock() where the offending spinlock unlocking happens? > Can you show the state of the offending spinlock? > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > --=20 (\__/) (=3D'.'=3D) E[: | | | | :]=D0=97 (")_(") Alexey Tarasov From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 11:08:27 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F94B106568F; Sat, 15 Aug 2009 11:08:27 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 61B688FC45; Sat, 15 Aug 2009 11:08:27 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 043931E00342; Sat, 15 Aug 2009 13:08:25 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n7FB6UB3002029; Sat, 15 Aug 2009 13:06:30 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n7FB6UAa002028; Sat, 15 Aug 2009 13:06:30 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 15 Aug 2009 13:06:30 +0200 To: freebsd-current@FreeBSD.org Message-ID: <20090815110630.GA1925@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mav@FreeBSD.org Subject: ahci(4) hang reproduced, this time it was cdrdao scanbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 11:08:27 -0000 Hi! I wanted to burn an audio cd today and ran `cdrdao scanbus' to find out cdrdao's --device arg for the optical drive (turns out its the same numbering as camcontrol devlist reports i.e. at scbus3 target 0 lun 0 (cd1,pass3) becomes --device 3,0,0) - after which ahci(4) hung again with the board's disk access led on solid. This time tho I took a photo: http://people.freebsd.org/~nox/ahcihang1.jpg Taking a dump failed again too: http://people.freebsd.org/~nox/ahcihang2.jpg cdrdao is in ports as sysutils/cdrdao and is mostly used for writing or cloning audio cds or vcds. (I haven't tried cdrecord's -scanbus command tho I wouldn't be surprised if it behaves the same... cdrecord is in ports as sysutils/cdrtools and sysutils/cdrtools-devel; you usually want cdrtools-devel.) Oh and btw, the actual burning (after reboot + fsck) then went just fine, its just the scanbus command that ahci(4) apparently doesn't like... Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 06:11:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69BC5106568B for ; Sat, 15 Aug 2009 06:11:37 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id CC20F8FC15 for ; Sat, 15 Aug 2009 06:11:36 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so348128eye.7 for ; Fri, 14 Aug 2009 23:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=HOqIdGNr2Y+o6+xYmUYLsHSME8HAebqP6MUSNB72bN8=; b=jF2qEbMKx+FltSHn963bXcx7gzZB67EXAdL2vn4Tx+8UBCqmbgEeY0I3VwPc9T0F4p ezjV1KmXWFtO0GpbbEpeinCpVZg+ZUoshpD+akklSvnW7bMN96iTlIrQcT3mOw3s/tYb ulACv8K2eWucR1FhKhxxA+4SoY4BsR8XJ4kys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RgXHHoVh64+0NfAKoiVWDKXYwk/CTvz09tiZb9eaZG5gOe+kg5X87tc4vjTod8AruF rzKErtnfK4MZK/yCxQO7Dgm1YtTcVV0PgCkMpke7RwMAkYIMHcqIbTiRHbCOUpzkB2fS nRu2JoOw/9BqafZfxkbJic4/i/VvO+TPQJylQ= MIME-Version: 1.0 Received: by 10.210.137.18 with SMTP id k18mr4129944ebd.43.1250316695779; Fri, 14 Aug 2009 23:11:35 -0700 (PDT) Date: Sat, 15 Aug 2009 02:11:35 -0400 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 15 Aug 2009 12:40:18 +0000 Cc: ivoras@freebsd.org Subject: What's cooking pages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 06:11:37 -0000 ivan... can you pages be commit to freebsd somewhere? they are really cool and contain collected references/links to such as main announce/wiki/commit messages that do not appear in the freebsd release notes. thus such info is mostly lost in the noise and harder to find such first, main and final researches on these things. maybe merge every thing into the wiki pages. From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 06:48:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94636106568F for ; Sat, 15 Aug 2009 06:48:54 +0000 (UTC) (envelope-from lexasoft@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 4CAA68FC15 for ; Sat, 15 Aug 2009 06:48:53 +0000 (UTC) Received: by qyk29 with SMTP id 29so1566661qyk.3 for ; Fri, 14 Aug 2009 23:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=OcYDa81OPr9BEtvVVIwgA+cNrXQYw16R2jHlGmG+9XE=; b=HqjXT8mLrqWPyCpWI9TrlhMb+i2KBu+A4dQynrmhLImGGdrG1k3VXbku4NDdEO+sl5 unJ/5QcN2FavRsGn6lgM9qPsIy8dj16D6fbvaVuO4j88+FFU6iVsVjwDuGIPQVrCZ+nq WSnuDs2NSvG/VVsCFEqpeRnQLNoOceuiwzOVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=RiIfK3fDaGkt/uxXb1O0mDog4QU9/Uv9uWbJJ01A65wF/0E5yCU4nOx2FC9NSfGFC8 gItwgpPfGFCVY6LmWkh3t3YJZ4FjroeCFiRgPYh2LYJR4q5CsCgDBRf0klpwZxecLTjU e7++qnD0tFcJtlo5QOfd/a8WC1Rx0dswS78AQ= MIME-Version: 1.0 Received: by 10.229.31.9 with SMTP id w9mr1530129qcc.17.1250318933537; Fri, 14 Aug 2009 23:48:53 -0700 (PDT) In-Reply-To: <3bbf2fe10908140921v4ba9ad6drc5225a4f533206b1@mail.gmail.com> References: <3bbf2fe10908140921v4ba9ad6drc5225a4f533206b1@mail.gmail.com> Date: Sat, 15 Aug 2009 10:48:53 +0400 Message-ID: From: Alexey Tarasov To: Attilio Rao , current@freebsd.org X-Mailman-Approved-At: Sat, 15 Aug 2009 12:47:01 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 06:48:54 -0000 Hello. Would you please tell me what GDB commands should I use to provide this information? I'm not so familiar with GDB, I've used it before only for debugging simple C++ applications. > > As you got a dump, could you please list with kgdb the precise point > within witness_lock() where the offending spinlock unlocking happens? > Can you show the state of the offending spinlock? > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > --=20 (\__/) (=3D'.'=3D) E[: | | | | :]=D0=97 (")_(") Alexey Tarasov From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 06:54:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52A43106564A for ; Sat, 15 Aug 2009 06:54:11 +0000 (UTC) (envelope-from lexasoft@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0A9BF8FC55 for ; Sat, 15 Aug 2009 06:54:10 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so672944qwe.7 for ; Fri, 14 Aug 2009 23:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=qTC7+Z3tUR/4QuikyVCMKQFf5oOuqz8CqzJe6KzLzdA=; b=C7JY13sjiNNODbMUEp9xWLsvQ3ryPyX8VgxQU2IziIQ7VPJcvLiF1h/dzjTXJc5/E7 Nv1qFLi3YZhiALrK3IPdqwnKk7NaphNaZ2yFCpQTS0EQ5knehyCse+JF/qJUUWmNOU67 Ip2BLal6Z2IKv3vg8gAVHaF/9UDHoAQEQ2gVE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=WH6k9rilkbChwKGx19sEy1e9rWf7YcAn0OhlXCBFAvlILZ3brOOg5gmG0I9EMt7grM yKE8arZpwSmnokVBU84Sz2A7CMo17Mtv3i1cgLK2Vn17UJ7KYMYQbcxCkP0NBc3zVf0x G+/aDEzvN7E6s3F3J1Gzig2TQVlPzkSh6OSVA= MIME-Version: 1.0 Received: by 10.229.31.9 with SMTP id w9mr1530622qcc.17.1250319249649; Fri, 14 Aug 2009 23:54:09 -0700 (PDT) In-Reply-To: <4A858F5C.5060500@haruhiism.net> References: <4A858F5C.5060500@haruhiism.net> Date: Sat, 15 Aug 2009 10:54:09 +0400 Message-ID: From: Alexey Tarasov To: Kamigishi Rei , current@freebsd.org X-Mailman-Approved-At: Sat, 15 Aug 2009 12:47:15 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 06:54:11 -0000 Hello. Here is core.txt: http://lexasoft.ru/metamphetamine/Panic/core.txt.0 'All versions' means all versions before and including 7-STABLE. This servers were used before on Linux. There were no problems. I have not tried latest 8.0 version. 2009/8/14 Kamigishi Rei > Alexey Tarasov wrote: > >> I have more than 30 Supermicro servers with same config and on all of th= em >> I >> get kernel panic. >> >> I have vmcore in /var/crash folder. What debug information is needed to >> debug this problem? >> >> > Please elaborate what's "all versions of FreeBSD" in this case. Have you > tried the latest -current revision (f.ex. 196200)? > If you have a core.txt file, it would surely help. (You can use "crashinf= o > -d /var/crash" to produce it if it's not there). > > -- > Kamigishi Rei > KREI-RIPE > --=20 (\__/) (=3D'.'=3D) E[: | | | | :]=D0=97 (")_(") Alexey Tarasov From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 11:10:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB4DD106568C for ; Sat, 15 Aug 2009 11:10:17 +0000 (UTC) (envelope-from astadtler@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 488F58FC59 for ; Sat, 15 Aug 2009 11:10:16 +0000 (UTC) Received: by bwz19 with SMTP id 19so2084856bwz.37 for ; Sat, 15 Aug 2009 04:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=pnh6bmrvcsjlUCw5XEzEUpt2CbG0hdTSoMTKmkt5z0E=; b=wNp+k1FaAzb/FnujqZiFCnybLUxsZrNjtMJaK8xTLbJwxGIk/ave4kazH4+hhJnuhG 7QNQJGwN5VrNqeNCISbLIXf1jlG6g2uZ0PlEvhlJffVqsl01E1X2HJ3vYGmSOuKZI+li +DHLZxJiw3wRhOggkkZ2S+3+RCwzIHAGcBDUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hFfuYlkGc/yyff0Oopp4wtCJvcMSnZGHorVPM2t7d6br+/64OhfLSw1UnOAam21MY5 S/NErHiKGAnXIUDLOYENuIOzKgeF5DUw1zAU2vBDlOecRveN3TfWPjBwK3c0oL+8h2sk P069PRbM+daMHKTxlpXQMq1t9lY99QMianRbo= MIME-Version: 1.0 Received: by 10.204.62.133 with SMTP id x5mr1618784bkh.89.1250334616014; Sat, 15 Aug 2009 04:10:16 -0700 (PDT) Date: Sat, 15 Aug 2009 06:10:16 -0500 Message-ID: <61f56a3b0908150410s5a454a5bu161e2b00ea40365@mail.gmail.com> From: Andrew Stadtler To: freebsd-current@freebsd.org X-Mailman-Approved-At: Sat, 15 Aug 2009 12:48:03 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RE: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 11:10:17 -0000 I have found this is related to using an onboard controller with mixed ide and sata devices. From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 12:19:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27C4A106568C for ; Sat, 15 Aug 2009 12:19:17 +0000 (UTC) (envelope-from Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id AB1218FC52 for ; Sat, 15 Aug 2009 12:19:16 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 3A729160011; Sat, 15 Aug 2009 14:19:14 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id AC6BD94120; Sat, 15 Aug 2009 14:19:13 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7FCJD18022508; Sat, 15 Aug 2009 14:19:13 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 14:19:14 +0200 Date: Sat, 15 Aug 2009 14:18:38 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: freebsd-current@freebsd.org, nox@jelal.kn-bremen.de Message-ID: <4a86a79e.fsqybTv/DWO05+80%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Aug 2009 12:19:14.0113 (UTC) FILETIME=[9A1F4B10:01CA1DA2] X-Mailman-Approved-At: Sat, 15 Aug 2009 12:48:18 +0000 Cc: Subject: Re: ahci(4) hang reproduced, this time it was cdrdao scanbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 12:19:17 -0000 >wanted to burn an audio cd today and ran `cdrdao scanbus' to find out >cdrdao's --device arg for the optical drive (turns out its the same why do you use cdrdao for writing an audio CD? >numbering as camcontrol devlist reports i.e. > at scbus3 target 0 lun 0 (cd1,pass3) >becomes --device 3,0,0) - after which ahci(4) hung again with the board's >disk access led on solid. This time tho I took a photo: > http://people.freebsd.org/~nox/ahcihang1.jpg This may be a bug in the driver, a driver is not allowed to do retries in case that a command was send via SCSI pass through. > cdrdao is in ports as sysutils/cdrdao and is mostly used for writing >or cloning audio cds or vcds. (I haven't tried cdrecord's -scanbus >command tho I wouldn't be surprised if it behaves the same... cdrecord >is in ports as sysutils/cdrtools and sysutils/cdrtools-devel; you usually >want cdrtools-devel.) Cloning CDs is not really implemented in cdrdao, if you really like to clone, use the clone feature from cdrtools: readcd -clone f=img.out cdreccord -v -raw96r -clone img.out but note that there is a quality loss with cloning, I recommend to call this: cdda2wav -vall cddb=0 -paranoia -Owav -B cdrecord -v -sao -text -useinfo *.wav for best quality of a CD-Audio copy. >Oh and btw, the actual burning (after reboot + fsck) then went just >fine, its just the scanbus command that ahci(4) apparently doesn't like... If you like to see what causes the hang, call: cdrecord -scanbus -V Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 13:20:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA3C8106568B for ; Sat, 15 Aug 2009 13:20:46 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 999278FC55 for ; Sat, 15 Aug 2009 13:20:46 +0000 (UTC) Received: from tau.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 901378461; Sat, 15 Aug 2009 13:20:45 +0000 (UTC) Date: Sat, 15 Aug 2009 14:20:43 +0100 From: Bruce Cran To: Thomas Backman Message-ID: <20090815142043.2b18dae0@tau.draftnet> In-Reply-To: <9CBAB74F-45CD-4B20-835C-A77C9D01B5D1@exscape.org> References: <665DE2F7-0899-40B7-9129-2082F2188D3E@exscape.org> <94F61AF3-E0D2-4BCD-8C74-07C3C0752A47@exscape.org> <20090814093916.11c89255@gluon.draftnet> <9CBAB74F-45CD-4B20-835C-A77C9D01B5D1@exscape.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current Subject: Re: ps -axl during textdumps occasionally segfaults with a HUGE ps.core X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 13:20:46 -0000 On Fri, 14 Aug 2009 11:05:05 +0200 Thomas Backman wrote: > Looks like you're right! > I tried the same deal: > [root@chaos ~]# time ps -axl -M /var/crash/vmcore.45.NMAP_SCAN > Segmentation fault: 11 (core dumped) >=20 > real 0m46.005s > user 0m0.000s > sys 0m7.753s >=20 > (All the time taken, according to the hard drive noise, was to save =20 > the core dump, which existed long before it returned to the shell. >=20 > [root@chaos ~]# gdb /bin/ps ps.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and =20 > you are > welcome to change it and/or distribute copies of it under certain =20 > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for =20 > details. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging =20 > symbols found)... > Core was generated by `ps'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libm.so.5...(no debugging symbols =20 > found)...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /lib/libkvm.so.5...(no debugging symbols =20 > found)...done. > Loaded symbols for /lib/libkvm.so.5 > Reading symbols from /lib/libc.so.7...(no debugging symbols =20 > found)...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols =20 > found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x0000000800960b9b in strlen () from /lib/libc.so.7 > (gdb) bt > #0 0x0000000800960b9b in strlen () from /lib/libc.so.7 > #1 0x0000000800959812 in open () from /lib/libc.so.7 > #2 0x00000008008f0546 in vsnprintf () from /lib/libc.so.7 > #3 0x0000000800772d79 in _kvm_err () from /lib/libkvm.so.5 > #4 0x00000008007707f7 in kvm_getprocs () from /lib/libkvm.so.5 > #5 0x0000000000405322 in uname () > #6 0x0000000000401f0e in ?? () > #7 0x0000000800539000 in ?? () > #8 0x0000000000000000 in ?? () > #9 0x0000000000000000 in ?? () > ... > #639 0x9066669066669066 in ?? () > #640 0x00007fffffffec38 in ?? () > #641 0x0000000000000004 in ?? () > #642 0x00007fffffffec60 in ?? () > #643 0x0000000000000012 in ?? () > Cannot access memory at address 0x800000000000 >=20 > Crash in strlen() this time, rather than bcopy(), but uname() in > still the root cause, I guess...? >=20 I managed to get a full backtrace and can at least see what's causing the crash: it seems it's stepping past the nlist array and calls vsnprintf with a bad argument. kvm_nlist returns -1 to report that the symbol table couldn't be read, but the code assumes it has returned a positive number to indicate that there's an invalid entry, so it starts searching for that entry where n_type is 0. tau# gdb ps=0D GNU gdb 6.1.1 [FreeBSD] [...] (gdb) break kvm_proc.c:631 No source file named kvm_proc.c. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (kvm_proc.c:631) pending. (gdb) run -ax -M /var/crash/vmcore.3 Starting program: /bin/ps -ax -M /var/crash/vmcore.3 Breakpoint 2 at 0x80076f2f8: file /usr/src/lib/libkvm/kvm_proc.c, line 631. Pending breakpoint "kvm_proc.c:631" resolved Program received signal SIGSEGV, Segmentation fault. 0x000000080096340b in strlen (str=3DVariable "str" is not available. ) at /usr/src/lib/libc/string/strlen.c:88 88 if (*p =3D=3D '\0') (gdb) bt #0 0x000000080096340b in strlen (str=3DVariable "str" is not available. ) at /usr/src/lib/libc/string/strlen.c:88 #1 0x000000080095c082 in __vfprintf (fp=3D0x7fffffffd9a0, fmt0=3D0x800773915 "%s: no such symbol", ap=3D0x7fffffffdb10) at /usr/src/lib/libc/stdio/vfprintf.c:825 #2 0x00000008008cc696 in vsnprintf (str=3DVariable "str" is not available. ) at /usr/src/lib/libc/stdio/vsnprintf.c:70 #3 0x0000000800772e89 in _kvm_err (kd=3DVariable "kd" is not available. ) at /usr/src/lib/libkvm/kvm.c:104 #4 0x0000000800770907 in kvm_getprocs (kd=3D0x800b02300, op=3D8, arg=3D0, cnt=3D0x7fffffffdf1c) at /usr/src/lib/libkvm/kvm_proc.c:561 #5 0x0000000000405322 in main (argc=3D4, argv=3D0x7fffffffe9a8) at /usr/src/bin/ps/ps.c:511 (gdb) frame 4 #4 0x0000000800770907 in kvm_getprocs (kd=3D0x800b02300, op=3D8, arg=3D0, cnt=3D0x7fffffffdf1c) at /usr/src/lib/libkvm/kvm_proc.c:561 561 _kvm_err(kd, kd->program, (gdb) list 556 nl[5].n_name =3D 0; 557=09 558 if (kvm_nlist(kd, nl) !=3D 0) { 559 for (p =3D nl; p->n_type !=3D 0; ++p) 560 ; 561 _kvm_err(kd, kd->program, 562 "%s: no such symbol", p->n_name); 563 return (0); 564 } 565 if (KREAD(kd, nl[0].n_value, &nprocs)) { (gdb) print nl $1 =3D {{n_name =3D 0x8007738ef "_nprocs", n_type =3D 240 '=C3=B0', n_other= =3D -1 '=C3=BF', n_desc =3D -1, n_value =3D 34365215744}, { n_name =3D 0x8007738f7 "_allproc", n_type =3D 160 '=C2=A0', n_other =3D -100 '\234', n_desc =3D 80, n_value =3D 0}, { n_name =3D 0x800773900 "_zombproc", n_type =3D 57 '9', n_other =3D 2 '\002', n_desc =3D 81, n_value =3D 34367538496}, { n_name =3D 0x80077390a "_ticks", n_type =3D 74 'J', n_other =3D 0 '\0', n_desc =3D 0, n_value =3D 34365215744}, { n_name =3D 0x800773911 "_hz", n_type =3D 168 '= =C2=A8', n_other =3D -23 '=C3=A9', n_desc =3D -1, n_value =3D 140737488349576}, {n_n= ame =3D 0x0, n_type =3D 1 '\001', n_other =3D 0 '\0', n_desc =3D 0, n_value =3D 34365024109}}=20 --=20 Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 14:33:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ABA8106568C for ; Sat, 15 Aug 2009 14:33:13 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2018FC51 for ; Sat, 15 Aug 2009 14:33:12 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 8E6D41E00341; Sat, 15 Aug 2009 16:33:11 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n7FEUT04002930; Sat, 15 Aug 2009 16:30:29 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id n7FEUSMO002929; Sat, 15 Aug 2009 16:30:28 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 15 Aug 2009 16:30:28 +0200 To: Joerg Schilling Message-ID: <20090815143028.GA2389@triton8.kn-bremen.de> References: <4a86a79e.fsqybTv/DWO05+80%Joerg.Schilling@fokus.fraunhofer.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4a86a79e.fsqybTv/DWO05+80%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, nox@jelal.kn-bremen.de Subject: Re: ahci(4) hang reproduced, this time it was cdrdao scanbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 14:33:13 -0000 On Sat, Aug 15, 2009 at 02:18:38PM +0200, Joerg Schilling wrote: > >wanted to burn an audio cd today and ran `cdrdao scanbus' to find out > >cdrdao's --device arg for the optical drive (turns out its the same > > why do you use cdrdao for writing an audio CD? > Because it writes it in one session from a toc file, getting the pregaps etc right. > > > >numbering as camcontrol devlist reports i.e. > > at scbus3 target 0 lun 0 (cd1,pass3) > >becomes --device 3,0,0) - after which ahci(4) hung again with the board's > >disk access led on solid. This time tho I took a photo: > > http://people.freebsd.org/~nox/ahcihang1.jpg > > This may be a bug in the driver, a driver is not allowed to do retries in case > that a command was send via SCSI pass through. > Well yes its most likely a driver bug, but the hang and retries were from `regular' disk access after cdrado had returned successfully, sorry if that was not clear... > > cdrdao is in ports as sysutils/cdrdao and is mostly used for writing > >or cloning audio cds or vcds. (I haven't tried cdrecord's -scanbus > >command tho I wouldn't be surprised if it behaves the same... cdrecord > >is in ports as sysutils/cdrtools and sysutils/cdrtools-devel; you usually > >want cdrtools-devel.) > > Cloning CDs is not really implemented in cdrdao, Well I meant something like cdrdao read-cd --device ... foo.toc cdrdao write --device ... foo.toc (with an optional cdrdao read-cddb foo.toc before the write in case you want cd-text and the drive can write it.) > if you really like to > clone, use the clone feature from cdrtools: > > readcd -clone f=img.out > cdreccord -v -raw96r -clone img.out > > but note that there is a quality loss with cloning, I recommend to call this: > > cdda2wav -vall cddb=0 -paranoia -Owav -B > cdrecord -v -sao -text -useinfo *.wav > > for best quality of a CD-Audio copy. > Hmm does that handle pregaps etc correctly as well? > > >Oh and btw, the actual burning (after reboot + fsck) then went just > >fine, its just the scanbus command that ahci(4) apparently doesn't like... > > If you like to see what causes the hang, call: > > cdrecord -scanbus -V Ok I managed to capture output of that by running script(1) onto an sdcard on an usb flashcard reader, but first the corresponding output of camcontrol devlist with the flashcard reader plugged in: at scbus0 target 0 lun 0 (ada0,pass0) at scbus1 target 0 lun 0 (cd0,pass1) at scbus2 target 0 lun 0 (ada1,pass2) at scbus3 target 0 lun 0 (cd1,pass3) at scbus4 target 0 lun 0 (ada2,pass4) at scbus9 target 0 lun 0 (pass5,da0) at scbus10 target 0 lun 0 (pass6,da1) at scbus10 target 0 lun 1 (pass7,da2) at scbus10 target 0 lun 2 (pass8,da3) at scbus10 target 0 lun 3 (pass9,da4) # cdrecord -scanbus -V Cdrecord-ProDVD-ProBD-Clone 2.01.01a62 (amd64-unknown-freebsd8.0) Copyright (C) 1995-2009 Jörg Schilling Using libscg version 'schily-0.9'. scsibus0: Executing 'test unit ready' command on Bus 0 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.002s timeout 40s Executing 'test unit ready' command on Bus 0 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.003s timeout 40s Executing 'inquiry' command on Bus 0 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cdrecord: Input/output error. inquiry: scsi sendcmd: retryable error CDB: 12 00 00 00 24 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.002s timeout 40s 0,0,0 0) error: 1 scb.chk: 1 sense_count: 32 sense.code: 0x0 '' '' '' NON CCS Disk Executing 'test unit ready' command on Bus 0 Target 1, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 0,1,0 1) * Executing 'test unit ready' command on Bus 0 Target 2, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 0,2,0 2) * Executing 'test unit ready' command on Bus 0 Target 3, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 0,3,0 3) * Executing 'test unit ready' command on Bus 0 Target 4, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 0,4,0 4) * Executing 'test unit ready' command on Bus 0 Target 5, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 0,5,0 5) * Executing 'test unit ready' command on Bus 0 Target 6, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 0,6,0 6) * Executing 'test unit ready' command on Bus 0 Target 7, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 0,7,0 7) * Executing 'test unit ready' command on Bus 0 Target 8, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 0 Target 9, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 0 Target 10, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 0 Target 11, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 0 Target 12, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 0 Target 13, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 0 Target 14, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 0 Target 15, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s scsibus1: Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.000s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 41 54 41 50 49 20 20 20 42 44 20 20 42 20 20 44 48 34 42 31 53 20 20 20 37 50 35 42 Executing 'inquiry' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 60 00 cmd finished after 0.000s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 41 54 41 50 49 20 20 20 42 44 20 20 42 20 20 44 48 34 42 31 53 20 20 20 37 50 35 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 52 5F 5F 5F 00 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1,0,0 100) Inquiry Data : ...2[...ATAPI BD B DH4B1S 7P5B R___.. ...................... Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 5A 00 3F 00 00 00 00 00 08 00 cmd finished after 0.001s timeout 40s Mode Sense Data 00 A6 70 00 00 00 00 00 Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 5A 00 2A 00 00 00 00 00 02 00 cmd finished after 0.001s timeout 40s Mode Sense Data 00 36 Mode Sense Data (converted) 33 Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 5A 00 2A 00 00 00 00 00 38 00 cmd finished after 0.001s timeout 40s Mode Sense Data 00 36 70 00 00 00 00 00 2A 2E 1F 17 F5 67 29 20 16 0D 00 02 40 00 16 0D 00 00 16 0D 16 0D 00 01 00 00 00 00 16 0D 00 04 00 00 1B 90 00 00 16 0D 00 00 10 8A 00 00 0B 06 Mode Sense Data (converted) 33 70 00 00 2A 2E 1F 17 F5 67 29 20 16 0D 00 02 40 00 16 0D 00 00 16 0D 16 0D 00 01 00 00 00 00 16 0D 00 04 00 00 1B 90 00 00 16 0D 00 00 10 8A 00 00 0B 06 Mode Sense Data 33 70 00 00 2A 2E 1F 17 F5 67 29 20 16 0D 00 02 40 00 16 0D 00 00 16 0D 16 0D 00 01 00 00 00 00 16 0D 00 04 00 00 1B 90 00 00 16 0D 00 00 10 8A 00 00 0B 06 Mode Page Data 2A 2E 1F 17 F5 67 29 20 16 0D 00 02 40 00 16 0D 00 00 16 0D 16 0D 00 01 00 00 00 00 16 0D 00 04 00 00 1B 90 00 00 16 0D 00 00 10 8A 00 00 0B 06 Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 5A 00 2A 00 00 00 00 00 38 00 cmd finished after 0.001s timeout 40s Mode Sense Data 00 36 70 00 00 00 00 00 2A 2E 1F 17 F5 67 29 20 16 0D 00 02 40 00 16 0D 00 00 16 0D 16 0D 00 01 00 00 00 00 16 0D 00 04 00 00 1B 90 00 00 16 0D 00 00 10 8A 00 00 0B 06 Mode Sense Data (converted) 33 70 00 00 2A 2E 1F 17 F5 67 29 20 16 0D 00 02 40 00 16 0D 00 00 16 0D 16 0D 00 01 00 00 00 00 16 0D 00 04 00 00 1B 90 00 00 16 0D 00 00 10 8A 00 00 0B 06 Mode Sense Data 33 70 00 00 2A 2E 1F 17 F5 67 29 20 16 0D 00 02 40 00 16 0D 00 00 16 0D 16 0D 00 01 00 00 00 00 16 0D 00 04 00 00 1B 90 00 00 16 0D 00 00 10 8A 00 00 0B 06 Executing 'test unit ready' command on Bus 1 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s 'ATAPI ' 'BD B DH4B1S ' '7P5B' Removable CD-ROM Executing 'test unit ready' command on Bus 1 Target 1, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 1,1,0 101) * Executing 'test unit ready' command on Bus 1 Target 2, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 1,2,0 102) * Executing 'test unit ready' command on Bus 1 Target 3, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 1,3,0 103) * Executing 'test unit ready' command on Bus 1 Target 4, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 1,4,0 104) * Executing 'test unit ready' command on Bus 1 Target 5, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 1,5,0 105) * Executing 'test unit ready' command on Bus 1 Target 6, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 1,6,0 106) * Executing 'test unit ready' command on Bus 1 Target 7, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 1,7,0 107) * Executing 'test unit ready' command on Bus 1 Target 8, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 1 Target 9, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 1 Target 10, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 1 Target 11, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 1 Target 12, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 1 Target 13, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 1 Target 14, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 1 Target 15, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s scsibus2: Executing 'test unit ready' command on Bus 2 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'test unit ready' command on Bus 2 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: cmd timeout after 40.007 (40) s CDB: 00 00 00 00 00 00 cmd finished after 40.007s timeout 40s 2,0,0 200) '' '' '' NON CCS Disk Executing 'test unit ready' command on Bus 2 Target 1, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 2,1,0 201) * Executing 'test unit ready' command on Bus 2 Target 2, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 2,2,0 202) * Executing 'test unit ready' command on Bus 2 Target 3, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 2,3,0 203) * Executing 'test unit ready' command on Bus 2 Target 4, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 2,4,0 204) * Executing 'test unit ready' command on Bus 2 Target 5, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 2,5,0 205) * Executing 'test unit ready' command on Bus 2 Target 6, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 2,6,0 206) * Executing 'test unit ready' command on Bus 2 Target 7, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 2,7,0 207) * Executing 'test unit ready' command on Bus 2 Target 8, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 2 Target 9, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 2 Target 10, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 2 Target 11, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 2 Target 12, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 2 Target 13, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 2 Target 14, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 2 Target 15, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s scsibus3: Executing 'test unit ready' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'test unit ready' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.030s timeout 40s Executing 'inquiry' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.000s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 50 49 4F 4E 45 45 52 20 44 56 44 2D 52 57 20 20 44 56 52 2D 32 31 36 44 31 2E 30 39 Executing 'inquiry' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 60 00 cmd finished after 0.030s timeout 40s Inquiry Data : 05 80 00 32 5B 00 00 00 50 49 4F 4E 45 45 52 20 44 56 44 2D 52 57 20 20 44 56 52 2D 32 31 36 44 31 2E 30 39 20 30 38 2F 30 39 2F 32 39 20 20 50 49 4F 4E 45 45 52 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3,0,0 300) Inquiry Data : ...2[...PIONEER DVD-RW DVR-216D1.09 08/09/29 PIONEER ........................................ Executing 'test unit ready' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 5A 00 3F 00 00 00 00 00 08 00 cmd finished after 0.029s timeout 40s Mode Sense Data 00 C4 70 00 00 00 00 00 Executing 'test unit ready' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 5A 00 2A 00 00 00 00 00 02 00 cmd finished after 0.029s timeout 40s Mode Sense Data 00 52 Mode Sense Data (converted) 4F Executing 'test unit ready' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 5A 00 2A 00 00 00 00 00 54 00 cmd finished after 0.029s timeout 40s Mode Sense Data 00 52 70 00 00 00 00 00 2A 4A 3F 17 F1 73 29 23 1B 90 01 00 07 D0 1B 90 00 00 1B 90 16 0C 00 01 00 00 00 00 16 0C 00 08 00 00 21 13 00 00 1B 90 00 00 16 0C 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 Mode Sense Data (converted) 4F 70 00 00 2A 4A 3F 17 F1 73 29 23 1B 90 01 00 07 D0 1B 90 00 00 1B 90 16 0C 00 01 00 00 00 00 16 0C 00 08 00 00 21 13 00 00 1B 90 00 00 16 0C 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 Mode Sense Data 4F 70 00 00 2A 4A 3F 17 F1 73 29 23 1B 90 01 00 07 D0 1B 90 00 00 1B 90 16 0C 00 01 00 00 00 00 16 0C 00 08 00 00 21 13 00 00 1B 90 00 00 16 0C 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 Mode Page Data 2A 4A 3F 17 F1 73 29 23 1B 90 01 00 07 D0 1B 90 00 00 1B 90 16 0C 00 01 00 00 00 00 16 0C 00 08 00 00 21 13 00 00 1B 90 00 00 16 0C 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 Executing 'test unit ready' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'mode sense g1' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 5A 00 2A 00 00 00 00 00 54 00 cmd finished after 0.029s timeout 40s Mode Sense Data 00 52 70 00 00 00 00 00 2A 4A 3F 17 F1 73 29 23 1B 90 01 00 07 D0 1B 90 00 00 1B 90 16 0C 00 01 00 00 00 00 16 0C 00 08 00 00 21 13 00 00 1B 90 00 00 16 0C 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 Mode Sense Data (converted) 4F 70 00 00 2A 4A 3F 17 F1 73 29 23 1B 90 01 00 07 D0 1B 90 00 00 1B 90 16 0C 00 01 00 00 00 00 16 0C 00 08 00 00 21 13 00 00 1B 90 00 00 16 0C 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 Mode Sense Data 4F 70 00 00 2A 4A 3F 17 F1 73 29 23 1B 90 01 00 07 D0 1B 90 00 00 1B 90 16 0C 00 01 00 00 00 00 16 0C 00 08 00 00 21 13 00 00 1B 90 00 00 16 0C 00 00 10 89 00 00 0D C8 00 00 0B 06 00 00 06 E4 00 00 02 C1 00 00 00 00 00 00 00 00 00 00 00 00 Executing 'test unit ready' command on Bus 3 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s 'PIONEER ' 'DVD-RW DVR-216D' '1.09' Removable CD-ROM Executing 'test unit ready' command on Bus 3 Target 1, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 3,1,0 301) * Executing 'test unit ready' command on Bus 3 Target 2, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 3,2,0 302) * Executing 'test unit ready' command on Bus 3 Target 3, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 3,3,0 303) * Executing 'test unit ready' command on Bus 3 Target 4, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 3,4,0 304) * Executing 'test unit ready' command on Bus 3 Target 5, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 3,5,0 305) * Executing 'test unit ready' command on Bus 3 Target 6, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 3,6,0 306) * Executing 'test unit ready' command on Bus 3 Target 7, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 3,7,0 307) * Executing 'test unit ready' command on Bus 3 Target 8, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 3 Target 9, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 3 Target 10, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 3 Target 11, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 3 Target 12, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 3 Target 13, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 3 Target 14, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 3 Target 15, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s scsibus4: Executing 'test unit ready' command on Bus 4 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0xFFFFFFFF [], Segment 0 Sense Code: 0x00 Qual 0x00 (no additional sense information) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'test unit ready' command on Bus 4 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 load: 0.24 cmd: cdrecord 64 [cbwait] 58.71r 0.00u 0.00s 0% 1692k cdrecord: Input/output error. test unit ready: scsi sendcmd: cmd timeout after 40.007 (40) s CDB: 00 00 00 00 00 00 cmd finished after 40.007s timeout 40s 4,0,0 400) '' '' '' NON CCS Disk Executing 'test unit ready' command on Bus 4 Target 1, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 4,1,0 401) * Executing 'test unit ready' command on Bus 4 Target 2, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 4,2,0 402) * Executing 'test unit ready' command on Bus 4 Target 3, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 4,3,0 403) * Executing 'test unit ready' command on Bus 4 Target 4, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 4,4,0 404) * Executing 'test unit ready' command on Bus 4 Target 5, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 4,5,0 405) * Executing 'test unit ready' command on Bus 4 Target 6, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 4,6,0 406) * Executing 'test unit ready' command on Bus 4 Target 7, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 4,7,0 407) * Executing 'test unit ready' command on Bus 4 Target 8, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 4 Target 9, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 4 Target 10, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 4 Target 11, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 4 Target 12, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 4 Target 13, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 4 Target 14, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 4 Target 15, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s scsibus9: Executing 'test unit ready' command on Bus 9 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0C 00 00 00 00 3A 00 00 00 00 00 66 69 63 65 6A 65 74 20 50 72 6F 20 4C 37 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'test unit ready' command on Bus 9 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0C 00 00 00 00 3A 00 00 00 00 00 66 69 63 65 6A 65 74 20 50 72 6F 20 4C 37 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.000s timeout 40s Executing 'inquiry' command on Bus 9 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.000s timeout 40s Inquiry Data : 00 80 02 02 5B 00 00 00 48 50 20 20 20 20 20 20 4F 66 66 69 63 65 6A 65 74 20 50 72 6F 20 4C 37 31 2E 30 30 Executing 'inquiry' command on Bus 9 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 60 00 cmd finished after 0.000s timeout 40s Inquiry Data : 00 80 02 02 5B 00 00 00 48 50 20 20 20 20 20 20 4F 66 66 69 63 65 6A 65 74 20 50 72 6F 20 4C 37 31 2E 30 30 55 53 42 20 4D 61 73 73 20 53 74 6F 72 61 67 65 20 20 20 20 00 00 03 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9,0,0 900) Inquiry Data : ....[...HP Officejet Pro L71.00USB Mass Storage ... .................................... 'HP ' 'Officejet Pro L7' '1.00' Removable Disk Executing 'test unit ready' command on Bus 9 Target 1, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 9,1,0 901) * Executing 'test unit ready' command on Bus 9 Target 2, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 9,2,0 902) * Executing 'test unit ready' command on Bus 9 Target 3, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 9,3,0 903) * Executing 'test unit ready' command on Bus 9 Target 4, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 9,4,0 904) * Executing 'test unit ready' command on Bus 9 Target 5, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 9,5,0 905) * Executing 'test unit ready' command on Bus 9 Target 6, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 9,6,0 906) * Executing 'test unit ready' command on Bus 9 Target 7, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 9,7,0 907) * Executing 'test unit ready' command on Bus 9 Target 8, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 9 Target 9, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 9 Target 10, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 9 Target 11, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 9 Target 12, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 9 Target 13, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 9 Target 14, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 9 Target 15, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s scsibus10: Executing 'test unit ready' command on Bus 10 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'test unit ready' command on Bus 10 Target 0, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Input/output error. test unit ready: scsi sendcmd: retryable error CDB: 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Sense Key: 0x2 Not Ready, Segment 0 Sense Code: 0x3A Qual 0x00 (medium not present) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.001s timeout 40s Executing 'inquiry' command on Bus 10 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 24 00 cmd finished after 0.000s timeout 40s Inquiry Data : 00 80 00 00 29 00 00 00 47 65 6E 65 72 69 63 20 53 54 4F 52 41 47 45 20 44 45 56 49 43 45 20 20 39 33 33 39 Executing 'inquiry' command on Bus 10 Target 0, Lun 0 timeout 40s CDB: 12 00 00 00 2E 00 cmd finished after 0.000s timeout 40s Inquiry Data : 00 80 00 00 29 00 00 00 47 65 6E 65 72 69 63 20 53 54 4F 52 41 47 45 20 44 45 56 49 43 45 20 20 39 33 33 39 05 E3 07 0E 47 45 4E 45 08 03 10,0,0 1000) Inquiry Data : ....)...Generic STORAGE DEVICE 9339....GENE.. 'Generic ' 'STORAGE DEVICE ' '9339' Removable Disk Executing 'test unit ready' command on Bus 10 Target 1, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 10,1,0 1001) * Executing 'test unit ready' command on Bus 10 Target 2, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 10,2,0 1002) * Executing 'test unit ready' command on Bus 10 Target 3, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 10,3,0 1003) * Executing 'test unit ready' command on Bus 10 Target 4, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 10,4,0 1004) * Executing 'test unit ready' command on Bus 10 Target 5, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 10,5,0 1005) * Executing 'test unit ready' command on Bus 10 Target 6, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 10,6,0 1006) * Executing 'test unit ready' command on Bus 10 Target 7, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s 10,7,0 1007) * Executing 'test unit ready' command on Bus 10 Target 8, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 10 Target 9, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 10 Target 10, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 10 Target 11, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 10 Target 12, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 10 Target 13, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 10 Target 14, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s Executing 'test unit ready' command on Bus 10 Target 15, Lun 0 timeout 40s CDB: 00 00 00 00 00 00 cdrecord: Error 0. test unit ready: scsi sendcmd: fatal error CDB: 00 00 00 00 00 00 cmd finished after 0.000s timeout 40s # ^D From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 15:43:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C4A106568C for ; Sat, 15 Aug 2009 15:43:00 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay09.ispgateway.de (smtprelay09.ispgateway.de [80.67.29.23]) by mx1.freebsd.org (Postfix) with ESMTP id E976C8FC3F for ; Sat, 15 Aug 2009 15:42:59 +0000 (UTC) Received: from [62.143.132.83] (helo=r500.local) by smtprelay09.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1McLRE-0003V6-FF; Sat, 15 Aug 2009 17:45:02 +0200 Date: Sat, 15 Aug 2009 17:42:41 +0200 From: Fabian Keil To: Lawrence Stewart Message-ID: <20090815174241.60dd9b12@r500.local> In-Reply-To: <4A7C2395.6020600@freebsd.org> References: <20090807142027.1a30e8ba@fabiankeil.de> <4A7C2395.6020600@freebsd.org> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; amd64-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/avzo__pNTjlBnhkfBtqgYLw"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 12: page fault while in kernel mode - current process: flowcleaner X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 15:43:00 -0000 --Sig_/avzo__pNTjlBnhkfBtqgYLw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Lawrence Stewart wrote: > Fabian Keil wrote: > > Using: > >=20 > > FreeBSD TP51.local 8.0-BETA2 FreeBSD 8.0-BETA2 #36: Sat Aug 1 00:07:09= CEST 2009 > > fk@TP51.local:/usr/obj/usr/src/sys/THINKPAD i386 > >=20 > > I got the following panic: > >=20 > > fk@TP51 /usr/crash $kgdb /boot/kernel/kernel.symbols vmcore.6 > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and yo= u are > > welcome to change it and/or distribute copies of it under certain condi= tions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for deta= ils. > > This GDB was configured as "i386-marcel-freebsd"... > >=20 > > Unread portion of the kernel message buffer: > >=20 > >=20 > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x0 > > fault code =3D supervisor read, page not present > > instruction pointer =3D 0x20:0x0 > > stack pointer =3D 0x28:0xf1a2fc94 > > frame pointer =3D 0x28:0xf1a2fcd8 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 40 (flowcleaner) > > panic: from debugger > > cpuid =3D 0 > > Uptime: 2m1s > > Physical memory: 998 MB > > Dumping 144 MB: 129 113 97 81 65 49 33 17 1 > >=20 > > Reading symbols from /boot/kernel/unionfs.ko...Reading symbols from /bo= ot/kernel/unionfs.ko.symbols...done. > > done. > > [...] > > Loaded symbols for /boot/kernel/fdescfs.ko > > #0 doadump () at pcpu.h:246 > > 246 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) where > > #0 doadump () at pcpu.h:246 > > #1 0xc0678e66 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown= .c:419 > > #2 0xc06790a2 in panic (fmt=3DVariable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:575 > > #3 0xc04f2e57 in db_panic (addr=3DCould not find the frame base for "d= b_panic". > > ) at /usr/src/sys/ddb/db_command.c:478 > > #4 0xc04f33e1 in db_command (last_cmdp=3D0xc0a1f31c, cmd_table=3D0x0, = dopager=3D1) at /usr/src/sys/ddb/db_command.c:445 > > #5 0xc04f353a in db_command_loop () at /usr/src/sys/ddb/db_command.c:4= 98 > > #6 0xc04f532d in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_= main.c:229 > > #7 0xc06a33c6 in kdb_trap (type=3D12, code=3D0, tf=3D0xf1a2fc54) at /u= sr/src/sys/kern/subr_kdb.c:534 > > #8 0xc0913a8f in trap_fatal (frame=3D0xf1a2fc54, eva=3D0) at /usr/src/= sys/i386/i386/trap.c:924 > > #9 0xc0913cc3 in trap_pfault (frame=3D0xf1a2fc54, usermode=3D0, eva=3D= 0) at /usr/src/sys/i386/i386/trap.c:846 > > #10 0xc091469a in trap (frame=3D0xf1a2fc54) at /usr/src/sys/i386/i386/t= rap.c:528 > > #11 0xc08f83bb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > > #12 0x00000000 in ?? () > > Previous frame inner to this frame (corrupt stack?) > >=20 > > The backtrace in ddb mentioned several flow* functions, > > but unfortunately it doesn't seem to have survived the > > dump. > >=20 > > The problem occurred after booting the system with the rc.conf line: > > ifconfig_wlan0=3D"inet 192.168.178.49 -wme" > > changing it to: > > ifconfig_wlan0=3D"inet 192.168.178.49 ssid [...] wepkey 1:[0x...] def= txkey 1 wepmode on chanlist 7 -wme" > > running: > > /etc/rc.d/netif restart > > followed by: > > ifconfig wlan0 > > which showed that wlan0 got associated. > > The panic happened less than a second later. > >=20 > > The system is an IBM ThinkPad R51 with iwi0 as wlandev. > > em0 was configured and up but unconnected. > I can reliably trigger a flowcleaner panic as well on my Toshiba R600=20 > laptop with a rum based WIFI dongle (D-Link DWA-110). I only get it on=20 > teardown/detach though. Kip is aware of the issue and will hopefully=20 > have a patch for us at some point. Thanks for the information. Did you try disabling options FLOWTABLE already? It doesn't strike me as particularly useful on a laptop anyway. Fabian --Sig_/avzo__pNTjlBnhkfBtqgYLw Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqG13sACgkQBYqIVf93VJ01WQCgv2bkE7g+x29tbP/4qOr6uw/x F9oAoI9Dhjm5Phw0fRny1Fn/P9ZW8zH0 =z+nt -----END PGP SIGNATURE----- --Sig_/avzo__pNTjlBnhkfBtqgYLw-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 15:43:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C82431065696 for ; Sat, 15 Aug 2009 15:43:45 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [80.67.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 516908FC69 for ; Sat, 15 Aug 2009 15:43:45 +0000 (UTC) Received: from [62.143.132.83] (helo=r500.local) by smtprelay07.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1McLPz-00007R-H1 for freebsd-current@freebsd.org; Sat, 15 Aug 2009 17:43:43 +0200 Date: Sat, 15 Aug 2009 17:43:39 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20090815174339.6317be31@r500.local> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; amd64-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/KW9T6obJ/5k3GGXy7nC.Z2i"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: snd_uaudio: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 15:43:45 -0000 --Sig_/KW9T6obJ/5k3GGXy7nC.Z2i Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I reproducible get the following panic less than a second after inserting a Turtle Beach AudioAdvantage stick with the snd_uaudio module loaded: fk@r500 /usr/crash $kgdb /boot/kernel/kernel.symbols vmcore.0=20 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x20 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff803f31c1 stack pointer =3D 0x28:0xffffff803a393440 frame pointer =3D 0x28:0xffffff803a393460 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 36 (usbus4) panic: from debugger cpuid =3D 0 Uptime: 2m12s Dumping 1992 MB (5 chunks) chunk 0: 1MB (155 pages) ... ok chunk 1: 1990MB (509345 pages) 1974 1958 1942 1926 1910 1894 [...]... ok chunk 2: 2MB (273 pages) ... ok chunk 3: 1MB (184 pages) Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kerne= l/zfs.ko.symbols...done. done. [...] done. Loaded symbols for /boot/kernel/snd_uaudio.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:223 #1 0xffffffff803bb25d in boot (howto=3D260) at /usr/src/sys/kern/kern_shut= down.c:419 #2 0xffffffff803bb64c in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff801eddf7 in db_panic (addr=3DVariable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801ee201 in db_command (last_cmdp=3D0xffffffff8081d240, cmd_t= able=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801ee450 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:498 #6 0xffffffff801f03a9 in db_trap (type=3DVariable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff803e6935 in kdb_trap (type=3D12, code=3D0, tf=3D0xffffff803a3= 93390) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff805ac48d in trap_fatal (frame=3D0xffffff803a393390, eva=3DVar= iable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #9 0xffffffff805ad04e in trap (frame=3D0xffffff803a393390) at /usr/src/sys= /amd64/amd64/trap.c:345 #10 0xffffffff805943f3 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:224 #11 0xffffffff803f31c1 in turnstile_broadcast (ts=3D0x0, queue=3D0) at /usr= /src/sys/kern/subr_turnstile.c:831 #12 0xffffffff803aee70 in _mtx_unlock_sleep (m=3D0xffffffff81e37120, opts= =3DVariable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:677 #13 0xffffffff80331d4f in usbd_do_request_flags (udev=3D0xffffff003fcfe000,= mtx=3D0xffffffff81e37120, req=3D0xffffff803a393550, data=3D0xffffff803a393= 560, flags=3D0, actlen=3D0x0,=20 timeout=3D5000) at /usr/src/sys/dev/usb/usb_request.c:312 #14 0xffffffff824272e2 in uaudio_mixer_get (udev=3DVariable "udev" is not a= vailable. ) at /usr/src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uau= dio.c:2961 #15 0xffffffff8242741a in uaudio_mixer_add_ctl (sc=3D0xffffff003f3c3000, mc= =3D0xffffff803a3938a0) at /usr/src/sys/modules/sound/driver/uaudio/../../..= /../dev/sound/usb/uaudio.c:1604 #16 0xffffffff82429165 in uaudio_attach (dev=3D0xffffff003f723400) at /usr/= src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uaudio.c:1944 #17 0xffffffff803e1569 in device_attach (dev=3D0xffffff003f723400) at devic= e_if.h:178 #18 0xffffffff80326941 in usb_probe_and_attach_sub (udev=3D0xffffff003fcfe0= 00, uaa=3D0xffffff803a393ae0) at /usr/src/sys/dev/usb/usb_device.c:1146 #19 0xffffffff80326dfd in usb_probe_and_attach (udev=3D0xffffff003fcfe000, = iface_index=3DVariable "iface_index" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:1305 #20 0xffffffff8032f7ca in uhub_explore (udev=3D0xffffff000380a000) at /usr/= src/sys/dev/usb/usb_hub.c:238 #21 0xffffffff8031be61 in usb_bus_explore (pm=3DVariable "pm" is not availa= ble. ) at /usr/src/sys/dev/usb/controller/usb_controller.c:235 #22 0xffffffff803319f0 in usb_process (arg=3DVariable "arg" is not availabl= e. ) at /usr/src/sys/dev/usb/usb_process.c:161 #23 0xffffffff80398182 in fork_exit (callout=3D0xffffffff80331930 , arg=3D0xffffff80002dee88, frame=3D0xffffff803a393c80) at /usr/src/sys= /kern/kern_fork.c:838 #24 0xffffffff805948ce in fork_trampoline () at /usr/src/sys/amd64/amd64/ex= ception.S:561 #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000001 in ?? () #28 0x0000000000000000 in ?? () This is on: FreeBSD 8.0-BETA2 #3: Fri Aug 14 15:19:08 CEST 2009 fk@r500.local:/usr/obj/= usr/src/sys/ZOEY amd64 but also happens with a slightly older kernel on i386. Fabian --Sig_/KW9T6obJ/5k3GGXy7nC.Z2i Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqG168ACgkQBYqIVf93VJ2C7ACgmAykqUY99gDWE9hJeeHv+9uk K5QAoLSrba/ImTRz+VbsNNkCFvtXku7k =8b7h -----END PGP SIGNATURE----- --Sig_/KW9T6obJ/5k3GGXy7nC.Z2i-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 15:48:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04E861065690; Sat, 15 Aug 2009 15:48:33 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id B91628FC43; Sat, 15 Aug 2009 15:48:32 +0000 (UTC) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1McLUS-00061w-Mh; Sat, 15 Aug 2009 16:48:31 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1McLUS-0007eE-0t; Sat, 15 Aug 2009 16:48:20 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n7FFmJ3N098228; Sat, 15 Aug 2009 16:48:19 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n7FFmJX6098227; Sat, 15 Aug 2009 16:48:19 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Sat, 15 Aug 2009 16:48:19 +0100 From: Anton Shterenlikht To: freebsd-ia64@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090815154819.GA96052@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -4.1 X-Spam-Level: ---- Cc: Subject: Regression: fxp0: device timeout - SCB timeout: 0x70 0x0 0x80 0x0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 15:48:33 -0000 This seems to be a regression. On FreeBSD 8.0-BETA2 ia64 after a recent buildworld I get: fxp0: device timeout with lines similar to these: fxp0: SCB timeout: 0x70 0x0 0x80 0x0 fxp0: SCB timeout: 0x70 0x0 0x80 0x400 fxp0: SCB timeout: 0xf0 0x0 0x80 0x400 The cable seems to be in place, no change happend there. All my local network is unreachable! from dmesg: fxp0: port 0xd00-0xd3f mem 0x80020000-0x80020fff,0x80000000-0x8001ffff irq 20 at device 3.0 on pci0 miibus0: on fxp0 fxp0: Ethernet address: xx:xx:xx:xx:xx:xx fxp0: [ITHREAD] % ifconfig fxp0 fxp0: flags=8843 metric 0 mtu 1500 options=219b ether xx:xx:xx:xx:xx:xx inet 10.10.10.31 netmask 0xffffff00 broadcast 10.10.10.255 media: Ethernet autoselect (100baseTX ) status: active % This problem appears in archives from time to time since FBSD 4.x. But nothing that helps me. What am I to do? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 16:21:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8074106568C; Sat, 15 Aug 2009 16:21:27 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id E6DB58FC45; Sat, 15 Aug 2009 16:21:26 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=JAPMNGAjvIUA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=QfffTQpC29NImtPssZgA:9 a=874Zfjy30BxU10ys5-oA:7 a=fSrNWaB9QzW3wmoDVEDAYdvH360A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1292936779; Sat, 15 Aug 2009 18:21:24 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, alfred@freebsd.org Date: Sat, 15 Aug 2009 18:21:32 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090815174339.6317be31@r500.local> In-Reply-To: <20090815174339.6317be31@r500.local> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908151821.33881.hselasky@c2i.net> Cc: Subject: Re: snd_uaudio: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 16:21:27 -0000 On Saturday 15 August 2009 17:43:39 Fabian Keil wrote: > I reproducible get the following panic less than a second after > inserting a Turtle Beach AudioAdvantage stick with the snd_uaudio > module loaded: > > fk@r500 /usr/crash $kgdb /boot/kernel/kernel.symbols vmcore.0 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are welcome to change it and/or distribute copies of it under certain > conditions. Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > cpuid = 0; apic id = 00 > fault virtual address = 0x20 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff803f31c1 > stack pointer = 0x28:0xffffff803a393440 > frame pointer = 0x28:0xffffff803a393460 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 36 (usbus4) > panic: from debugger > cpuid = 0 > Uptime: 2m12s > Dumping 1992 MB (5 chunks) > chunk 0: 1MB (155 pages) ... ok > chunk 1: 1990MB (509345 pages) 1974 1958 1942 1926 1910 1894 [...]... ok > chunk 2: 2MB (273 pages) ... ok > chunk 3: 1MB (184 pages) > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from > /boot/kernel/zfs.ko.symbols...done. done. > [...] > done. > Loaded symbols for /boot/kernel/snd_uaudio.ko > #0 doadump () at pcpu.h:223 > 223 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:223 > #1 0xffffffff803bb25d in boot (howto=260) at > /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff803bb64c in panic > (fmt=Variable "fmt" is not available. ) at > /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xffffffff801eddf7 in db_panic (addr=Variable "addr" is not available. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff801ee201 in db_command (last_cmdp=0xffffffff8081d240, > cmd_table=Variable "cmd_table" is not available. ) at > /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff801ee450 in db_command_loop () at > /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801f03a9 in db_trap > (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff803e6935 in kdb_trap (type=12, code=0, tf=0xffffff803a393390) > at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff805ac48d in trap_fatal > (frame=0xffffff803a393390, eva=Variable "eva" is not available. ) at > /usr/src/sys/amd64/amd64/trap.c:847 > #9 0xffffffff805ad04e in trap (frame=0xffffff803a393390) at > /usr/src/sys/amd64/amd64/trap.c:345 #10 0xffffffff805943f3 in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:224 #11 0xffffffff803f31c1 in > turnstile_broadcast (ts=0x0, queue=0) at > /usr/src/sys/kern/subr_turnstile.c:831 #12 0xffffffff803aee70 in > _mtx_unlock_sleep (m=0xffffffff81e37120, opts=Variable "opts" is not > available. ) at /usr/src/sys/kern/kern_mutex.c:677 > #13 0xffffffff80331d4f in usbd_do_request_flags (udev=0xffffff003fcfe000, > mtx=0xffffffff81e37120, req=0xffffff803a393550, data=0xffffff803a393560, > flags=0, actlen=0x0, timeout=5000) at > /usr/src/sys/dev/usb/usb_request.c:312 > #14 0xffffffff824272e2 in uaudio_mixer_get (udev=Variable "udev" is not > available. ) at > /usr/src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uaudio.c >:2961 #15 0xffffffff8242741a in uaudio_mixer_add_ctl (sc=0xffffff003f3c3000, > mc=0xffffff803a3938a0) at > /usr/src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uaudio.c >:1604 #16 0xffffffff82429165 in uaudio_attach (dev=0xffffff003f723400) at > /usr/src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uaudio.c >:1944 #17 0xffffffff803e1569 in device_attach (dev=0xffffff003f723400) at > device_if.h:178 #18 0xffffffff80326941 in usb_probe_and_attach_sub > (udev=0xffffff003fcfe000, uaa=0xffffff803a393ae0) at > /usr/src/sys/dev/usb/usb_device.c:1146 #19 0xffffffff80326dfd in > usb_probe_and_attach (udev=0xffffff003fcfe000, iface_index=Variable > "iface_index" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:1305 > #20 0xffffffff8032f7ca in uhub_explore (udev=0xffffff000380a000) at > /usr/src/sys/dev/usb/usb_hub.c:238 #21 0xffffffff8031be61 in > usb_bus_explore (pm=Variable "pm" is not available. ) at > /usr/src/sys/dev/usb/controller/usb_controller.c:235 > #22 0xffffffff803319f0 in usb_process (arg=Variable "arg" is not available. > ) at /usr/src/sys/dev/usb/usb_process.c:161 > #23 0xffffffff80398182 in fork_exit (callout=0xffffffff80331930 > , arg=0xffffff80002dee88, frame=0xffffff803a393c80) at > /usr/src/sys/kern/kern_fork.c:838 #24 0xffffffff805948ce in fork_trampoline > () at /usr/src/sys/amd64/amd64/exception.S:561 #25 0x0000000000000000 in ?? > () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000001 in ?? () > #28 0x0000000000000000 in ?? () > > This is on: > FreeBSD 8.0-BETA2 #3: Fri Aug 14 15:19:08 CEST 2009 > fk@r500.local:/usr/obj/usr/src/sys/ZOEY amd64 but also happens with a > slightly older kernel on i386. > > Fabian Hi, This issue should have been solved, but it looks like not committed to 8- current yet. Try fetching latest uaudio.c from USB P4: http://perforce.freebsd.org/chv.cgi?CH=167030 http://perforce.freebsd.org/chv.cgi?CH=167032 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 16:48:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 866E9106568B for ; Sat, 15 Aug 2009 16:48:57 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 1E3E48FC5B for ; Sat, 15 Aug 2009 16:48:56 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n7FGmt1M060363 for ; Sat, 15 Aug 2009 18:48:56 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id n7FGmstA062179 for ; Sat, 15 Aug 2009 18:48:54 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id n7FGmsQd062176; Sat, 15 Aug 2009 18:48:54 +0200 (CEST) (envelope-from arno) To: current@freebsd.org From: "Arno J. Klaassen" Date: Sat, 15 Aug 2009 18:48:53 +0200 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9701/Sat Aug 15 15:32:49 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 4A86E6F7.00A by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 4A86E6F7.00A/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: Subject: 8-stable: nfs-hang on VIA C7 diskless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 16:48:57 -0000 Hello, I updated to today's 8-stable, and now my C7 diskless test-box wonn't boot multiuser anymore; it solidly hangs after the following lines : No suitable dump device was found. Entropy harvesting:. Fast boot: skipping disk checks. mount_nfs: can't update /var/db/mounttab for 172.16.1.7:/raid1/pxeboot/root Starting Network: lo0. Mounting NFS file systems:. /etc/rc: WARNING: Dump device does not exist. Savecore not run. and I cann't break into the debugger (Ctl-Alt-d is supposed to work under serial console as well? (sorry, long time ago I did these kind of things)) 8.0-beta2 works OK I can provide tcpdump for the nfs-server thanks, best, Arno From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 17:00:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5283B1065672; Sat, 15 Aug 2009 17:00:45 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id D5C0C8FC45; Sat, 15 Aug 2009 17:00:44 +0000 (UTC) Received: from [62.143.132.83] (helo=r500.local) by smtprelay08.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1McMcV-0004PU-8o; Sat, 15 Aug 2009 19:00:43 +0200 Date: Sat, 15 Aug 2009 19:00:36 +0200 From: Fabian Keil To: Hans Petter Selasky Message-ID: <20090815190036.79ea2f73@r500.local> In-Reply-To: <200908151821.33881.hselasky@c2i.net> References: <20090815174339.6317be31@r500.local> <200908151821.33881.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; amd64-portbld-freebsd8.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ii6/M/P9bx7VDM/8vQP+aKt"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-current@freebsd.org, alfred@freebsd.org Subject: Re: snd_uaudio: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 17:00:45 -0000 --Sig_/ii6/M/P9bx7VDM/8vQP+aKt Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hans Petter Selasky wrote: > On Saturday 15 August 2009 17:43:39 Fabian Keil wrote: > > I reproducible get the following panic less than a second after > > inserting a Turtle Beach AudioAdvantage stick with the snd_uaudio > > module loaded: > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x20 > > fault code =3D supervisor read data, page not present > > instruction pointer =3D 0x20:0xffffffff803f31c1 > > stack pointer =3D 0x28:0xffffff803a393440 > > frame pointer =3D 0x28:0xffffff803a393460 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags =3D resume, IOPL =3D 0 > > current process =3D 36 (usbus4) > > panic: from debugger > > cpuid =3D 0 > > Uptime: 2m12s > > #9 0xffffffff805ad04e in trap (frame=3D0xffffff803a393390) at > > /usr/src/sys/amd64/amd64/trap.c:345 #10 0xffffffff805943f3 in calltrap = () > > at /usr/src/sys/amd64/amd64/exception.S:224 #11 0xffffffff803f31c1 in > > turnstile_broadcast (ts=3D0x0, queue=3D0) at > > /usr/src/sys/kern/subr_turnstile.c:831 #12 0xffffffff803aee70 in > > _mtx_unlock_sleep (m=3D0xffffffff81e37120, opts=3DVariable "opts" is not > > available. ) at /usr/src/sys/kern/kern_mutex.c:677 > > #13 0xffffffff80331d4f in usbd_do_request_flags (udev=3D0xffffff003fcfe= 000, > > mtx=3D0xffffffff81e37120, req=3D0xffffff803a393550, data=3D0xffffff803a= 393560, > > flags=3D0, actlen=3D0x0, timeout=3D5000) at > > /usr/src/sys/dev/usb/usb_request.c:312 > > #14 0xffffffff824272e2 in uaudio_mixer_get (udev=3DVariable "udev" is n= ot > > available. ) at > > /usr/src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uaud= io.c > >:2961 #15 0xffffffff8242741a in uaudio_mixer_add_ctl (sc=3D0xffffff003f3= c3000, > > mc=3D0xffffff803a3938a0) at > > /usr/src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uaud= io.c > >:1604 #16 0xffffffff82429165 in uaudio_attach (dev=3D0xffffff003f723400)= at > > /usr/src/sys/modules/sound/driver/uaudio/../../../../dev/sound/usb/uaud= io.c > >:1944 #17 0xffffffff803e1569 in device_attach (dev=3D0xffffff003f723400)= at > > device_if.h:178 #18 0xffffffff80326941 in usb_probe_and_attach_sub > > (udev=3D0xffffff003fcfe000, uaa=3D0xffffff803a393ae0) at > > /usr/src/sys/dev/usb/usb_device.c:1146 #19 0xffffffff80326dfd in > > usb_probe_and_attach (udev=3D0xffffff003fcfe000, iface_index=3DVariable > > "iface_index" is not available. ) at /usr/src/sys/dev/usb/usb_device.c:= 1305 > > #20 0xffffffff8032f7ca in uhub_explore (udev=3D0xffffff000380a000) at > > /usr/src/sys/dev/usb/usb_hub.c:238 #21 0xffffffff8031be61 in > > usb_bus_explore (pm=3DVariable "pm" is not available. ) at > > /usr/src/sys/dev/usb/controller/usb_controller.c:235 > > #22 0xffffffff803319f0 in usb_process (arg=3DVariable "arg" is not avai= lable. > > ) at /usr/src/sys/dev/usb/usb_process.c:161 > > #23 0xffffffff80398182 in fork_exit (callout=3D0xffffffff80331930 > > , arg=3D0xffffff80002dee88, frame=3D0xffffff803a393c80) at > > /usr/src/sys/kern/kern_fork.c:838 #24 0xffffffff805948ce in fork_trampo= line > > () at /usr/src/sys/amd64/amd64/exception.S:561 #25 0x0000000000000000 i= n ?? > > () > > #26 0x0000000000000000 in ?? () > > #27 0x0000000000000001 in ?? () > > #28 0x0000000000000000 in ?? () > > > > This is on: > > FreeBSD 8.0-BETA2 #3: Fri Aug 14 15:19:08 CEST 2009 > > fk@r500.local:/usr/obj/usr/src/sys/ZOEY amd64 but also happens with a > > slightly older kernel on i386. > This issue should have been solved, but it looks like not committed to 8- > current yet. >=20 > Try fetching latest uaudio.c from USB P4: >=20 > http://perforce.freebsd.org/chv.cgi?CH=3D167030 > http://perforce.freebsd.org/chv.cgi?CH=3D167032 Applying these changes indeed solved the problem and the stick is working n= ow. Thanks a lot. Fabian --Sig_/ii6/M/P9bx7VDM/8vQP+aKt Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqG6boACgkQBYqIVf93VJ097QCgmzqRJiV+UW+TqecN4higAt2e y14An1R93DHQl8dBIEQBT5oDdaW79Lbp =7Cm2 -----END PGP SIGNATURE----- --Sig_/ii6/M/P9bx7VDM/8vQP+aKt-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 17:04:47 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 172A7106568C; Sat, 15 Aug 2009 17:04:47 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id E2B188FC45; Sat, 15 Aug 2009 17:04:46 +0000 (UTC) Received: from draco.over-yonder.net (c-75-65-240-232.hsd1.ms.comcast.net [75.65.240.232]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 9BB5837B612; Sat, 15 Aug 2009 12:04:44 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id A576961C41; Sat, 15 Aug 2009 12:04:43 -0500 (CDT) Date: Sat, 15 Aug 2009 12:04:43 -0500 From: "Matthew D. Fuller" To: Juergen Lock Message-ID: <20090815170443.GR1720@over-yonder.net> References: <20090815110630.GA1925@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090815110630.GA1925@triton8.kn-bremen.de> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.20-fullermd.4 (2009-06-14) X-Virus-Scanned: clamav-milter 0.95.2 at thyme.infocus-llc.com X-Virus-Status: Clean Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: ahci(4) hang reproduced, this time it was cdrdao scanbus X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 17:04:47 -0000 On Sat, Aug 15, 2009 at 01:06:30PM +0200 I heard the voice of Juergen Lock, and lo! it spake thus: > > after which ahci(4) hung again with the board's > disk access led on solid. > > cdrdao is in ports as sysutils/cdrdao and is mostly used for writing > or cloning audio cds or vcds. (I haven't tried cdrecord's -scanbus > command tho I wouldn't be surprised if it behaves the same... It does. http://lists.freebsd.org/pipermail/freebsd-current/2009-August/010189.html -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 17:34:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66E84106568E for ; Sat, 15 Aug 2009 17:34:09 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 4FFC48FC3D for ; Sat, 15 Aug 2009 17:34:09 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id DDA1ECD35; Sat, 15 Aug 2009 10:34:08 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 864EB2D6013; Sat, 15 Aug 2009 10:34:08 -0700 (PDT) Message-ID: <4A86F190.5040809@elischer.org> Date: Sat, 15 Aug 2009 10:34:08 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: grarpamp References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, ivoras@freebsd.org Subject: Re: What's cooking pages X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 17:34:09 -0000 grarpamp wrote: > ivan... can you pages be commit to freebsd somewhere? > they are really cool and contain collected references/links > to such as main announce/wiki/commit messages that > do not appear in the freebsd release notes. thus such > info is mostly lost in the noise and harder to find such > first, main and final researches on these things. maybe > merge every thing into the wiki pages. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" amusing that that the first few itesm are: "Will be in 8.0: No" maybe put those ones a bit lower :-) From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 17:57:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E8561065693 for ; Sat, 15 Aug 2009 17:57:42 +0000 (UTC) (envelope-from daimler3@googlemail.com) Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com [209.85.219.206]) by mx1.freebsd.org (Postfix) with ESMTP id 7AEEA8FC52 for ; Sat, 15 Aug 2009 17:57:41 +0000 (UTC) Received: by ewy2 with SMTP id 2so167225ewy.43 for ; Sat, 15 Aug 2009 10:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LMLqQuOB1vmSkFElMiL4Yzf8K5FUacDFm2Ib6Dge5o0=; b=cWsupNxvxoqOEX2KnEYc8UDSM9A1IIft/WvHNNL01gT834Sy8PlMZmR+FmoyemZPGu Dtcad7QINlXxhqEmPMW6O481cDAi9rVT3Lyj3AX+gvBn0ozpmaP766yYXgdA7hOV+06O 2fhwI/iRaiv0IaHLOSkKZNrKJbG/7S2WeU5uY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YHG68kOBQDJU8N6XMbDRtyNFSQNUglks6J8qhMp/D+EkOu1Myk9azHQ3ZobFkKbmh4 jajhOagft9xXMNnN4T0lBqkKX/SDBzVZaUWBXAlIl9jQrmMJuELAdkoJ7+hVfkRbPQFF g5We9C5NJJ/osoQUXEzQOvkyrHUyoprLke/sg= MIME-Version: 1.0 Received: by 10.216.53.83 with SMTP id f61mr690172wec.33.1250357154624; Sat, 15 Aug 2009 10:25:54 -0700 (PDT) Date: Sat, 15 Aug 2009 19:25:54 +0200 Message-ID: <791271c80908151025k344d906ar17cc585ae70927c7@mail.gmail.com> From: Deniz To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: unable to mount root from USB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 17:57:42 -0000 Hello, today I updated my sources (CURRENT) and built a new system (world + kernel). But unfortunately, this action didn't end well 'cause I'm not able to boot Freebsd from my Maxtor One Touch USB HDD anymore. Even booting from kernel.old doesnt't work anymore (tried everything: normal, single user mode, acpi disabled/enabled). Here is a short part of the boot messages (copied it manually): ################################## usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 SMP: AP CPU #1 Launched! Root mount wainting for: usbus4 usbus3 usbus2 usbus1 usbus0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 2 ports with 2 removable, self powered ugen1.1: at usbus0 uhub1: on usbus1 uhub1: 2 ports with 2 removable, self powered ugen4.1: at usbus4 uhub2: on usbus 4 Root mount wainting for: usbus4 usbus3 usbus2 Root mount wainting for: usbus4 usbus3 usbus2 Root mount wainting for: usbus4 usbus3 usbus2 uhub2: 8 ports with 8 removable, self powered ugen2.1: at usbus2 uhub3: on usbus2 uhub3: 2 ports with 2 removable, self powered ugen3.1: at usbus3 uhub4: on usbus3 uhub4: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 usb_alloc_device:1626: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Root mount wainting for: usbus4 Root mount wainting for: usbus4 usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Root mount wainting for: usbus4 Root mount wainting for: usbus4 usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! ugen4.2: <(null)> at usbus4 (disconnected) uhub_reattach_port:440: could not allocate new device! Trying to mount root from ufs:/dev/da0s4a ######## [and the HDD suddenly shuts down] ########## ROOT MOUNT ERROR: If you have invalid mount options, rebott, and first try the following from the loader prompt: set vfs.root.mountfrom.options=rw and the remove invalid mount options from /etc/fstab. Loader variables: vfs.root.mountfrom=ufs:/dev/da0s4a vfs.root.mountform.options=rw [manual boot prompt] mountroot> ? List of GEOM managed disk devices: Loader variables: .... ################################## I hope this problem wasn't reported already, but I did not found everything. This was not reported as a PR, 'cause I don't know if this is a real bug or just my fault. Regards, Deniz From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 18:22:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15456106568B; Sat, 15 Aug 2009 18:22:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id CAF708FC16; Sat, 15 Aug 2009 18:22:58 +0000 (UTC) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7FIMuT8060024; Sat, 15 Aug 2009 14:22:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n7FIMuP6088480; Sat, 15 Aug 2009 14:22:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B91787302F; Sat, 15 Aug 2009 14:22:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090815182255.B91787302F@freebsd-current.sentex.ca> Date: Sat, 15 Aug 2009 14:22:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 18:22:59 -0000 TB --- 2009-08-15 15:48:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-08-15 15:48:50 - starting HEAD tinderbox run for i386/i386 TB --- 2009-08-15 15:48:50 - cleaning the object tree TB --- 2009-08-15 15:49:36 - cvsupping the source tree TB --- 2009-08-15 15:49:36 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-08-15 15:49:43 - building world TB --- 2009-08-15 15:49:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 15:49:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 15:49:43 - TARGET=i386 TB --- 2009-08-15 15:49:43 - TARGET_ARCH=i386 TB --- 2009-08-15 15:49:43 - TZ=UTC TB --- 2009-08-15 15:49:43 - __MAKE_CONF=/dev/null TB --- 2009-08-15 15:49:43 - cd /src TB --- 2009-08-15 15:49:43 - /usr/bin/make -B buildworld >>> World build started on Sat Aug 15 15:49:45 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Aug 15 17:12:02 UTC 2009 TB --- 2009-08-15 17:12:02 - generating LINT kernel config TB --- 2009-08-15 17:12:02 - cd /src/sys/i386/conf TB --- 2009-08-15 17:12:02 - /usr/bin/make -B LINT TB --- 2009-08-15 17:12:02 - building LINT kernel TB --- 2009-08-15 17:12:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 17:12:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 17:12:02 - TARGET=i386 TB --- 2009-08-15 17:12:02 - TARGET_ARCH=i386 TB --- 2009-08-15 17:12:02 - TZ=UTC TB --- 2009-08-15 17:12:02 - __MAKE_CONF=/dev/null TB --- 2009-08-15 17:12:02 - cd /src TB --- 2009-08-15 17:12:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Aug 15 17:12:02 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sat Aug 15 17:46:23 UTC 2009 TB --- 2009-08-15 17:46:23 - building GENERIC kernel TB --- 2009-08-15 17:46:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 17:46:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 17:46:23 - TARGET=i386 TB --- 2009-08-15 17:46:23 - TARGET_ARCH=i386 TB --- 2009-08-15 17:46:23 - TZ=UTC TB --- 2009-08-15 17:46:23 - __MAKE_CONF=/dev/null TB --- 2009-08-15 17:46:23 - cd /src TB --- 2009-08-15 17:46:23 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Aug 15 17:46:23 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Aug 15 18:12:43 UTC 2009 TB --- 2009-08-15 18:12:43 - building PAE kernel TB --- 2009-08-15 18:12:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 18:12:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 18:12:43 - TARGET=i386 TB --- 2009-08-15 18:12:43 - TARGET_ARCH=i386 TB --- 2009-08-15 18:12:43 - TZ=UTC TB --- 2009-08-15 18:12:43 - __MAKE_CONF=/dev/null TB --- 2009-08-15 18:12:43 - cd /src TB --- 2009-08-15 18:12:43 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Sat Aug 15 18:12:44 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Sat Aug 15 18:19:34 UTC 2009 TB --- 2009-08-15 18:19:34 - building XEN kernel TB --- 2009-08-15 18:19:34 - MAKEOBJDIRPREFIX=/obj TB --- 2009-08-15 18:19:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-08-15 18:19:34 - TARGET=i386 TB --- 2009-08-15 18:19:34 - TARGET_ARCH=i386 TB --- 2009-08-15 18:19:34 - TZ=UTC TB --- 2009-08-15 18:19:34 - __MAKE_CONF=/dev/null TB --- 2009-08-15 18:19:34 - cd /src TB --- 2009-08-15 18:19:34 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Sat Aug 15 18:19:34 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh XEN cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug trap.o(.text+0xb82): In function `trap': /src/sys/i386/i386/trap.c:216: undefined reference to `ipi_nmi_handler' *** Error code 1 Stop in /obj/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-08-15 18:22:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-08-15 18:22:55 - ERROR: failed to build XEN kernel TB --- 2009-08-15 18:22:55 - 7530.23 user 631.52 system 9245.15 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 18:27:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C38C106568B for ; Sat, 15 Aug 2009 18:27:55 +0000 (UTC) (envelope-from perigran.falcon@gmail.com) Received: from mail-px0-f224.google.com (mail-px0-f224.google.com [209.85.216.224]) by mx1.freebsd.org (Postfix) with ESMTP id E3C0E8FC45 for ; Sat, 15 Aug 2009 18:27:54 +0000 (UTC) Received: by pxi21 with SMTP id 21so943684pxi.19 for ; Sat, 15 Aug 2009 11:27:54 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A86E502.8090902@FreeBSD.org> Received: by 10.114.55.16 with SMTP id d16mr736088waa.25.1250359197785; Sat, 15 Aug 2009 10:59:57 -0700 (PDT) Message-ID: <001636b2aee6d36199047131efe9@google.com> Date: Sat, 15 Aug 2009 17:59:57 +0000 From: perigran.falcon@gmail.com To: freebsd-current@freebsd.org, dougb@freebsd.org X-Mailman-Approved-At: Sat, 15 Aug 2009 18:57:22 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Re: Going to BSD 8 from RELENG_7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 18:27:55 -0000 Doug Barton wrote: > If you're interested in testing the new 8.0 version before it is > released we would all be very glad to have you do that. :) The more > testers we get before release the more certain we can be that there > are no problems with it. I would like to make one suggestion though, > if you could hold off until the 8.0-BETA3 is ready and test a clean > install using the cd iso image that would be great! We never get > enough people testing clean installations so this is something that is > very valuable. I downloaded the 8.0-BETA2-amd64-bootonly.iso and burned it last night. After the installation, I immediately cvsuped and did a buildworld and build kernel. Then, after reboot I did the installworld and I ran out of room on my root partition. The thing is, in the disklabel editor I chose Auto Defaults for all, giving me a root partition of 500 megs. Maybe the Auto Defaults for all should make the root partition larger than 500 megs. -Mike From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 19:34:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CC161065695 for ; Sat, 15 Aug 2009 19:34:48 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id E643B8FC61 for ; Sat, 15 Aug 2009 19:34:47 +0000 (UTC) Received: (qmail 18922 invoked by uid 399); 15 Aug 2009 19:34:42 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Aug 2009 19:34:42 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A870DCC.10903@FreeBSD.org> Date: Sat, 15 Aug 2009 12:34:36 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090729) MIME-Version: 1.0 To: John Baldwin References: <200903282317.n2SNHIjI015202@svn.freebsd.org> <4A846206.7010803@FreeBSD.org> <200908141004.09354.jhb@freebsd.org> In-Reply-To: <200908141004.09354.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: multipart/mixed; boundary="------------000103030504020104010107" Cc: "Bjoern A. Zeeb" , freebsd-current@freebsd.org Subject: Re: svn commit: r190514 - head/sys/conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 19:34:48 -0000 This is a multi-part message in MIME format. --------------000103030504020104010107 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit John Baldwin wrote: > On Thursday 13 August 2009 2:57:10 pm Doug Barton wrote: >> Bjoern A. Zeeb wrote: >>> Author: bz >>> Date: Sat Mar 28 23:17:18 2009 >>> New Revision: 190514 >>> URL: http://svn.freebsd.org/changeset/base/190514 >>> >>> Log: >>> For kernel builds reduce the impact of svnversion, just scanning >>> src/sys and not the entire src/ tree. >> Also, what problem are we really trying to solve here? With a >> populated cache it takes on average 5 seconds to run all of src, and >> just under 1 to do only sys. Is 4 seconds really that important to >> save? With a dry cache I'm sure it takes a little longer, but has >> anyone actually measured this? > > It takes far longer than 5 seconds here against a local SVN repo over NFS. Looking at this in a little more depth, the only place that the svnversion feature is relevant is for the kernel build. The other places that call newvers.sh don't make use of that information. So I've got a patch to the current version that only does the svn stuff if newvers.sh is being called for the kernel build. I've attached the regular svn diff and a -bB version since it's a bit hard to read. It's easier to see what's going on if you apply it. If no one objects I'll ask re@ for approval to commit it. Doug -- This .signature sanitized for your protection --------------000103030504020104010107 Content-Type: text/plain; name="newvers.sh-diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="newvers.sh-diff" SW5kZXg6IG5ld3ZlcnMuc2gKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbmV3dmVycy5zaAkocmV2aXNp b24gMTk2MjU3KQorKysgbmV3dmVycy5zaAkod29ya2luZyBjb3B5KQpAQCAtODcsMjkgKzg3 LDI1IEBACiB2PWBjYXQgdmVyc2lvbmAgdT0ke1VTRVI6LXJvb3R9IGQ9YHB3ZGAgaD0ke0hP U1ROQU1FOi1gaG9zdG5hbWVgfSB0PWBkYXRlYAogaT1gJHtNQUtFOi1tYWtlfSAtViBLRVJO X0lERU5UYAogCi1mb3IgZGlyIGluIC9iaW4gL3Vzci9iaW4gL3Vzci9sb2NhbC9iaW47IGRv Ci0JaWYgWyAteCAiJHtkaXJ9L3N2bnZlcnNpb24iIF07IHRoZW4KLQkJc3ZudmVyc2lvbj0k e2Rpcn0vc3ZudmVyc2lvbgotCQlTUkNESVI9JHtkIyMqb2JqfQotCQlpZiBbIC1uICIkTUFD SElORSIgXTsgdGhlbgotCQkJU1JDRElSPSR7U1JDRElSIyMvJE1BQ0hJTkV9CitjYXNlICIk ZCIgaW4KKyovc3lzLyopCisJZm9yIGRpciBpbiAvYmluIC91c3IvYmluIC91c3IvbG9jYWwv YmluOyBkbworCQlpZiBbIC14ICIke2Rpcn0vc3ZudmVyc2lvbiIgXTsgdGhlbgorCQkJc3Zu dmVyc2lvbj0ke2Rpcn0vc3ZudmVyc2lvbgorCQkJU1JDRElSPSR7ZCMjKm9ian0KKwkJCWlm IFsgLW4gIiRNQUNISU5FIiBdOyB0aGVuCisJCQkJU1JDRElSPSR7U1JDRElSIyMvJE1BQ0hJ TkV9CisJCQlmaQorCQkJU1JDRElSPSR7U1JDRElSJSUvc3lzLyp9CisJCQlicmVhawogCQlm aQotCQlTUkNESVI9JHtTUkNESVIlJS9zeXMvKn0KLQkJYnJlYWsKLQlmaQotZG9uZQorCWRv bmUKIAotaWYgWyAtbiAiJHN2bnZlcnNpb24iIC1hIC1kICIke1NSQ0RJUn0vLnN2biIgXSA7 IHRoZW4KLQkjIElmIHdlIGFyZSBjYWxsZWQgZnJvbSB0aGUga2VybmVsIGJ1aWxkLCBsaW1p dAotCSMgdGhlIHNjb3BlIG9mIHN2bnZlcnNpb24gdG8gc3lzLyAuCi0JaWYgWyAtZSAiJHtT UkNESVJ9L3N5cy9jb25mL25ld3ZlcnMuc2giIF0gOyB0aGVuCi0JCXN2bj0iIHJgY2QgJFNS Q0RJUi9zeXMgJiYgJHN2bnZlcnNpb25gIgotCWVsc2UKLQkJc3ZuPSIgcmBjZCAkU1JDRElS ICYmICRzdm52ZXJzaW9uYCIKKwlpZiBbIC1uICIkc3ZudmVyc2lvbiIgLWEgLWQgIiR7U1JD RElSfS9zeXMvLnN2biIgXSA7IHRoZW4KKwkJc3ZuPSIgcmBjZCAke1NSQ0RJUn0vc3lzICYm ICRzdm52ZXJzaW9uYCIKIAlmaQotZWxzZQotCXN2bj0iIgotZmkKKwk7OworZXNhYwogCiBj YXQgPDwgRU9GID4gdmVycy5jCiAkQ09QWVJJR0hUCg== --------------000103030504020104010107 Content-Type: text/plain; name="newvers.sh-diffbB" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="newvers.sh-diffbB" LS0tIC5zdm4vdGV4dC1iYXNlL25ld3ZlcnMuc2guc3ZuLWJhc2UJMjAwOS0wNy0xNiAxMzoy MDozMS4wMDAwMDAwMDAgLTA3MDAKKysrIG5ld3ZlcnMuc2gJMjAwOS0wOC0xNSAxMjoyOToy Ny4wMDAwMDAwMDAgLTA3MDAKQEAgLTI4LDcgKzI4LDcgQEAKICMgU1VDSCBEQU1BR0UuCiAj CiAjCUAoIyluZXd2ZXJzLnNoCTguMSAoQmVya2VsZXkpIDQvMjAvOTQKLSMgJEZyZWVCU0Qk CisjICRGcmVlQlNEOiBoZWFkL3N5cy9jb25mL25ld3ZlcnMuc2ggMTk1NzEyIDIwMDktMDct MTUgMTc6Mjk6MDVaIGtlbnNtaXRoICQKIAogVFlQRT0iRnJlZUJTRCIKIFJFVklTSU9OPSI4 LjAiCkBAIC04Nyw3ICs4Nyw5IEBACiB2PWBjYXQgdmVyc2lvbmAgdT0ke1VTRVI6LXJvb3R9 IGQ9YHB3ZGAgaD0ke0hPU1ROQU1FOi1gaG9zdG5hbWVgfSB0PWBkYXRlYAogaT1gJHtNQUtF Oi1tYWtlfSAtViBLRVJOX0lERU5UYAogCi1mb3IgZGlyIGluIC9iaW4gL3Vzci9iaW4gL3Vz ci9sb2NhbC9iaW47IGRvCitjYXNlICIkZCIgaW4KKyovc3lzLyopCisJZm9yIGRpciBpbiAv YmluIC91c3IvYmluIC91c3IvbG9jYWwvYmluOyBkbwogCWlmIFsgLXggIiR7ZGlyfS9zdm52 ZXJzaW9uIiBdOyB0aGVuCiAJCXN2bnZlcnNpb249JHtkaXJ9L3N2bnZlcnNpb24KIAkJU1JD RElSPSR7ZCMjKm9ian0KQEAgLTk3LDE5ICs5OSwxMyBAQAogCQlTUkNESVI9JHtTUkNESVIl JS9zeXMvKn0KIAkJYnJlYWsKIAlmaQotZG9uZQorCWRvbmUKIAotaWYgWyAtbiAiJHN2bnZl cnNpb24iIC1hIC1kICIke1NSQ0RJUn0vLnN2biIgXSA7IHRoZW4KLQkjIElmIHdlIGFyZSBj YWxsZWQgZnJvbSB0aGUga2VybmVsIGJ1aWxkLCBsaW1pdAotCSMgdGhlIHNjb3BlIG9mIHN2 bnZlcnNpb24gdG8gc3lzLyAuCi0JaWYgWyAtZSAiJHtTUkNESVJ9L3N5cy9jb25mL25ld3Zl cnMuc2giIF0gOyB0aGVuCi0JCXN2bj0iIHJgY2QgJFNSQ0RJUi9zeXMgJiYgJHN2bnZlcnNp b25gIgotCWVsc2UKLQkJc3ZuPSIgcmBjZCAkU1JDRElSICYmICRzdm52ZXJzaW9uYCIKKwlp ZiBbIC1uICIkc3ZudmVyc2lvbiIgLWEgLWQgIiR7U1JDRElSfS9zeXMvLnN2biIgXSA7IHRo ZW4KKwkJc3ZuPSIgcmBjZCAke1NSQ0RJUn0vc3lzICYmICRzdm52ZXJzaW9uYCIKIAlmaQot ZWxzZQotCXN2bj0iIgotZmkKKwk7OworZXNhYwogCiBjYXQgPDwgRU9GID4gdmVycy5jCiAk Q09QWVJJR0hUCg== --------------000103030504020104010107-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 19:38:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE5E1106568D for ; Sat, 15 Aug 2009 19:38:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 2A7608FC3F for ; Sat, 15 Aug 2009 19:38:54 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=ztB5IKwwM-XClAVvM08A:9 a=iL-M_UcLpLzaTi7DFysA:7 a=U6eVZ8IpzliUeIXAWma8Ahxn-6IA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1193709724; Sat, 15 Aug 2009 21:38:53 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 15 Aug 2009 21:39:01 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <791271c80908151025k344d906ar17cc585ae70927c7@mail.gmail.com> In-Reply-To: <791271c80908151025k344d906ar17cc585ae70927c7@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908152139.02493.hselasky@c2i.net> Cc: Deniz Subject: Re: unable to mount root from USB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 19:38:55 -0000 On Saturday 15 August 2009 19:25:54 Deniz wrote: > Hello, > > today I updated my sources (CURRENT) and built a new system (world + > kernel). > But unfortunately, this action didn't end well 'cause I'm not able to boot > Freebsd > from my Maxtor One Touch USB HDD anymore. > Even booting from kernel.old doesnt't work anymore (tried everything: > normal, single user mode, acpi disabled/enabled). > > Here is a short part of the boot messages (copied it manually): > > ################################## > > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > SMP: AP CPU #1 Launched! > Root mount wainting for: usbus4 usbus3 usbus2 usbus1 usbus0 > ugen0.1: at usbus0 > uhub0: on usbus0 > uhub0: 2 ports with 2 removable, self powered > ugen1.1: at usbus0 > uhub1: on usbus1 > uhub1: 2 ports with 2 removable, self powered > ugen4.1: at usbus4 > uhub2: on usbus 4 > Root mount wainting for: usbus4 usbus3 usbus2 > Root mount wainting for: usbus4 usbus3 usbus2 > Root mount wainting for: usbus4 usbus3 usbus2 > uhub2: 8 ports with 8 removable, self powered > ugen2.1: at usbus2 > uhub3: on usbus2 > uhub3: 2 ports with 2 removable, self powered > ugen3.1: at usbus3 > uhub4: on usbus3 > uhub4: 2 ports with 2 removable, self powered > Root mount waiting for: usbus4 > usb_alloc_device:1626: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT! > Root mount wainting for: usbus4 > Root mount wainting for: usbus4 > usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT! > Root mount wainting for: usbus4 > Root mount wainting for: usbus4 > usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT! > ugen4.2: <(null)> at usbus4 (disconnected) > uhub_reattach_port:440: could not allocate new device! > Trying to mount root from ufs:/dev/da0s4a > > ######## [and the HDD suddenly shuts down] ########## > > ROOT MOUNT ERROR: > If you have invalid mount options, rebott, and first try the following from > the loader prompt: > > set vfs.root.mountfrom.options=rw > > and the remove invalid mount options from /etc/fstab. > > Loader variables: > vfs.root.mountfrom=ufs:/dev/da0s4a > vfs.root.mountform.options=rw > > [manual boot prompt] > mountroot> ? > > List of GEOM managed disk devices: > > Loader variables: > .... > > ################################## > > I hope this problem wasn't reported already, but I did not found > everything. This was not reported as a PR, 'cause I don't know if this is a > real bug or just my fault. You could try setting the following sysctl: hw.usb.ehci.no_hs=1 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Aug 15 21:14:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA519106568B for ; Sat, 15 Aug 2009 21:14:42 +0000 (UTC) (envelope-from lexasoft@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 804D58FC15 for ; Sat, 15 Aug 2009 21:14:42 +0000 (UTC) Received: by qyk29 with SMTP id 29so1737831qyk.3 for ; Sat, 15 Aug 2009 14:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=lANzO3f1L8m+NQN/B+eUwyIZxmQ45UenfT3Kq1zeCoQ=; b=TWKCRoEIx4zCCrm01SVP9CBaH5IJ4JgCxEWruMxPAHzU0V4GY5lJFWun/w1cuxTEzm UF8r0SXRA2SkSD9T6J7w+rmKUmLXXbxwH7nZUH0674Fhnpk1KB/MVrK+shhdTrkkuF9b uJq6Z+ezkVBO5cOZXBRzlgIL7KR0Ou/GCNKFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ku7l3gW4vqkr0GTdTnYO+Be/xTpOrNDwLacMJfPP8+CGpOau6mkreScrXqC3reVaLC EioH+EIyz2aoxI5R8l+4Q1YGltFbhLC0IEvYGXoF7w8ZZ+8sGToFfXd46KanElerY1BT R53Daf6ufED8iTtV4nZR1EVHSs0/QLlpVjQPY= MIME-Version: 1.0 Received: by 10.229.9.83 with SMTP id k19mr1579014qck.47.1250370880286; Sat, 15 Aug 2009 14:14:40 -0700 (PDT) In-Reply-To: <4A86F1CA.1090304@elischer.org> References: <4A858F5C.5060500@haruhiism.net> <4A86F1CA.1090304@elischer.org> Date: Sun, 16 Aug 2009 01:14:40 +0400 Message-ID: From: Alexey Tarasov To: Julian Elischer , current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Kernel panic on all versions of FreeBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 21:14:42 -0000 Oh my god. 6.0 6.1 6.2 7.0 7.1 7.2 2009/8/15 Julian Elischer > Alexey Tarasov wrote: > >> Hello. >> Here is core.txt: >> http://lexasoft.ru/metamphetamine/Panic/core.txt.0 >> >> 'All versions' means all versions before and including 7-STABLE. >> This servers were used before on Linux. There were no problems. >> >> I have not tried latest 8.0 version. >> > > what about 4.11? > > > >> >> 2009/8/14 Kamigishi Rei >> >> Alexey Tarasov wrote: >>> >>> I have more than 30 Supermicro servers with same config and on all of >>>> them >>>> I >>>> get kernel panic. >>>> >>>> I have vmcore in /var/crash folder. What debug information is needed t= o >>>> debug this problem? >>>> >>>> >>>> Please elaborate what's "all versions of FreeBSD" in this case. Have >>> you >>> tried the latest -current revision (f.ex. 196200)? >>> If you have a core.txt file, it would surely help. (You can use >>> "crashinfo >>> -d /var/crash" to produce it if it's not there). >>> >>> -- >>> Kamigishi Rei >>> KREI-RIPE >>> >>> >> >> >> > --=20 (\__/) (=3D'.'=3D) E[: | | | | :]=D0=97 (")_(") Alexey Tarasov